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.
-Thomas
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
numbers:
-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
question.
-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?
Tom
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------
GRI dcn.internet2.edu-5862
Status FINISHED
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
Source
urn:ogf:network:domain=dcn.internet2.edu:node=LOSA:port=S27391:link=10.100.1
00.13
Destination
urn:ogf:network:domain=es.net:node=fnal-mr1:port=TenGigabitEthernet7/4:link=
*
Intradomain hops
urn:ogf:network:domain=dcn.internet2.edu:node=LOSA:port=S27391:link=10.100.1
00.13, desc: [ingress], VLAN: [3160],
urn:ogf:network:domain=dcn.internet2.edu:node=LOSA:port=DTL1:link=10.100.90.
98,
urn:ogf:network:domain=dcn.internet2.edu:node=SUNN:port=DTL9:link=10.100.90.
97,
urn:ogf:network:domain=dcn.internet2.edu:node=SUNN:port=DTL1:link=10.100.90.
94,
urn:ogf:network:domain=dcn.internet2.edu:node=SALT:port=DTL9:link=10.100.90.
93,
urn:ogf:network:domain=dcn.internet2.edu:node=SALT:port=DTL1:link=10.100.90.
82,
urn:ogf:network:domain=dcn.internet2.edu:node=DENV:port=DTL9:link=10.100.90.
81,
urn:ogf:network:domain=dcn.internet2.edu:node=DENV:port=DTL1:link=10.100.90.
74,
urn:ogf:network:domain=dcn.internet2.edu:node=KANS:port=DTL9:link=10.100.90.
73,
urn:ogf:network:domain=dcn.internet2.edu:node=KANS:port=DTL1:link=10.100.90.
66,
urn:ogf:network:domain=dcn.internet2.edu:node=CHIC:port=DTL9:link=10.100.90.
65,
urn:ogf:network:domain=dcn.internet2.edu:node=CHIC:port=S27647:link=10.100.8
0.181, desc: [egress], VLAN: [3160]
Interdomain path
urn:ogf:network:domain=dcn.internet2.edu:node=LOSA:port=S27391:link=10.100.1
00.13,
urn:ogf:network:domain=dcn.internet2.edu:node=CHIC:port=S27647:link=10.100.8
0.181,
urn:ogf:network:domain=es.net:node=chic-sdn1:port=TenGigabitEthernet7/3:link
=*,
urn:ogf:network:domain=es.net:node=fnal-mr1:port=TenGigabitEthernet7/4:link=
*
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.
Erik-Jan,
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.
rvdp
