Re: RE: GLIF subgroup on Global Lightpath IDs
- Subject: Re: RE: GLIF subgroup on Global Lightpath IDs
- From: Thomas Tam <thomas.tam@xxxxxxxxxx>
- Date: Thu, 29 May 2008 13:23:05 -0400
Hi Ronald and Tom,
Sorry for my lack of responses.
Ronald van der Pol wrote:
On Fri, May 16, 2008 at 13:41:33 -0400, 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?
Tom,
This is very useful. It turns out you see the global id a bit different
than I do. I think of it as an identifier, nothing more, nothing less.
Some domains may use it as local identifier too. Other domains use their
own local names and they need to maintain a mapping between local and
global names.
The idea of querying a domain for additional information about a lightpath
is very useful. When we can define a naming scheme that helps in this lookup
function, that is nice, but our primary task is proposing a naming scheme.
I do agree with Ronald, the global ID is just an identifier for
inter-domain communications. What I think each network/institution/GOLE
maintains the control of generating their internal circuit ID and
follows the recommended syntax for generating a global ID as a reference
for external communication. It is really up to an individual
network/institution/GOLE of how to a global ID is being mapped
internally. As Ronald mentioned in his previous email, the local ID
portion of the global ID will be controlled by an individual
network/institution/GOLE. As long as the local ID is unique, we should
have an unique global ID.
-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)
I think this is overloading the semantics of a lightpath identifier. I
am not sure this is a good idea. When you attach many semantics to a name,
it makes changes later on difficult.
I think it is better to have a separate lookup service for perfsonar.
The global identifier is only a key that tells the perfsonar framework
which lightpath we want information about. How to reach the MPs and MAs
is something that perfsonar should solve in a generic way, if it is
not already done.
So the way I see it is like this. At some time we will have a
distributed perfsonar setup. Each domain runs MPs and MAs.
There is a lookup service that tells you how to reach the
MPs and MAs and information about the services that these
MPs and MAs offer. One of them is E2EMON. I can immagine that
you give a global identifier as parameter to a lookup service,
and tell the lookup service that you wat to reach the E2EMON
service and the lookup service will give you all MP/MA that
have information about the lightpath with the global identifier
given as a parameter and how to reach these MPs/MAs.
Another service could be a list of domains where the lightpath
traverses through. The lookup service will also give you information
about how to reach each domain. And then you can contact a domain,
give the global identifier as parameter and the MP returns all kind
of information about the lightpath for that domain only.
I don't have enough background of how perfSONAR works in relate to the
looking up service. I believe the global ID is used to enhance the
communication between NOCs so that we all understand what we're dealing on.
-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.
I fully agree that this is useful and that the distributed way is the
right approach.
Fully agree. The distributed way is the right approach. Each domain
maintains the full control of their internal process.
-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.
When global identifiers are just used to indicate which lightpath
we are talking about, we do not need a central database.
To be clear: I do not think we should setup someting that needs a
central repository or central database.
Absolutely agree. One of the GLIF philosophies is to develop best
practice documents to assure the interoperability and interconnectivity
of participating networks so distributed ways would be a right approach.
What do others think about this?
I am curious too. Lars, Thomas?
I have a few comments on the ID, I'll send it out in the next couple of
days.
-Thomas
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.
Very interesting and useful. However, it does not map directly to the
way we use devices, interfaces and links. So we need to have a discussion
about this too. I am not sure what the right platform for this is.
OGF? perfsonar?
rvdp
