Global Lambda Integrated Facility

Re: GLIF subgroup on Global Lightpath IDs

  • Subject: Re: GLIF subgroup on Global Lightpath IDs
  • From: Thomas Tam <thomas.tam@xxxxxxxxxx>
  • Date: Thu, 05 Jun 2008 13:50:52 -0400

Hi Ronald,

Again, sorry for the delay.

There is one thing I would like to mention again, which is the purpose of the Global ID. I think you are pretty clear outlined in the 3rd paragraph of the introduction. Anything we propose should be based on this purpose.

“Global identifiers complement the local naming schemes that are in use in the various do-mains. It is assumed that most domains will use the global identifiers as aliases for their local names. The global identifiers are used in communication with other domains.”

First, let me comment on the questions in the section 3.

- Is a global registry needed?
I hope not. We might need some references but not a global registry that needs to be managed by someone.

- Is a central registry per domain needed?
I can't say for domain administrators, it is really up to each domain of how to manage their information.

- What's the maximum length of the identifier?
I have no preference but we definitely need to define a recommended length.

- Can the identifier be generated by provisioning software.
It would be nice, however, this shouldn't be a part of the consideration. Since the purpose of the ID is to be used for communication with other domains. Each domain can come up their own ideas of how to use the IDs and how to generate them.

-Is the identifier unique or only statistically unique?
IMO, statistically unique would be acceptable.

- What is the allowed character set?
No preference.

My comments on the global ID.

I think we’re all favor on an ID that consists of two parts format, the GOLE and local portions. In fact, I’m kind of thinking of the Dante naming scheme, it clearly identifies the lightpath end points and also it’s one of LHCOPN lightpaths

Now my question is who should take the responsibility to generate the ID. I would think that the first network/GOLE that initiates the initial cross-domain lightpath should be responsible for generating the ID. e.g CANARIE, SURnet

In the GOLE portion, I do like the idea of using short abbreviation in the GOLE portion. In these days, most of networks, institutions are using short abbreviation to represent their organizations. So I don’t think we have any issue for the abbreviated naming. eg. Starlight, MANLAN, CANARIE. A list of abbreviated names can be posted on the GLIF site. I think the abbreviated naming is straight-forward and simple.

In the local portion, I would think it should be up to the local domain to generate a unique ID with a maximum recommended length. As long as the local is unique internally, I think it’s safe to say that the global is unique globally. IMO, we might provide recommendations but should not impose how this number should be generated.

So combining the two parts, the global ID that generated by CANARIE could look like this: CANARIE-LP013. The GOLE portion is CANARIE, the local part is the internal lightpath tracking number, which is unique internally.

There is one more piece of information is missing in the picture. A prefix “GLIF” could be added. This would indicate that this is a GLIF related global ID. The global ID would look like this: GLIF-CANAIRE-LP013.

As you can see, my recommendation isn’t much different from the Dante and Internet2 naming schemes. However, instead of one organization controlling the ID generation, the responsibility is handing over the local admin.


Tom Lehman wrote:
Ronald, and all,

I have reviewed the latest draft, I have a few questions i would like to
raise relative to the recommendation to go with statistically unique

-I think we all agree that the global id will be used as a key which can be
used across multiple domains to get additional information on the circuit in
-so my question is, if we go with the statistically unique number approach,
how do we find out about where the information repositories/databases/lookup
servers are which contain the additional detail?

-one additional thought regarding use of dns style name in the id, was that
it would also provide an indication of where to go for additional
information, at least as a start.  This relies on the assumption that there
is (or will be) a well known service associated with each domain, which
would provide this type of information (a perfsonar style lookup service
being one suggested possibility)
-one of the objectives here was that when a domain provisions a circuit
(even if it is taking care of only one piece of a multi-domain circuit) it
does not have to update a central registry/database with any details.  All
details are kept locally, and authorized people can query a domain service.
This may require making multiple queries to multiple domain information
services, but by starting at the first, there would be enough information to
figure out which other domains needed to be queried.   Below is an example
of data kept locally for I2 DCN service.

-we could use the statistically unique numbers, and update a central
database so that others could figure out where to start the detail query
process, but then we have to try a keep a centralized database dynamically
updated as circuits come and go.

What do others think about this?


Here is an example of the data kept for I2 DCN service.  This is a
multidomain circuit which went thru Internet2 DCN and ESnet SDN.  As you can
see we have explcit route details (Intradomain hops) about the internal
domain (I2 DCN), but only ingress and egress (Interdomain path) info about
ESNet domain.  So this would be an indication to go to ESnet information
service if more details are needed.

----circuit detail example------
User	lambdastation
Description	test
Start time	4/16/2008 6:16
End time	4/16/2008 6:33
Created time 	4/16/2008 6:17
Bandwidth	2000000000
Intradomain hops
00.13, desc: [ingress], VLAN: [3160],
0.181, desc: [egress], VLAN: [3160]
Interdomain path
VLAN	3160
----circuit detail example------

-----Original Message-----
From: Ronald van der Pol [mailto:Ronald.vanderPol@xxxxxxxx] Sent: Friday, May 16, 2008 10:51 AM
To: Erik-Jan Bos
Cc: Ronald van der Pol; Thomas Tam; Lars Fischer; Tom Lehman
Subject: Re: GLIF subgroup on Global Lightpath IDs

On Fri, May 16, 2008 at 09:31:03 +0200, Erik-Jan Bos wrote:

Hi Ronald (and subgroup members!):

I would appreciate a short update on the work of your GLIF
Tech subgroup
on Global Lightpath IDs.

Attached is the first draft proposal for internal task force review.
We will try to reach consensus within the task force over a naming
scheme that we can recommend to the glif community. I hope we can
send our recommendation to the glif community somewhere next month.