Global Lambda Integrated Facility

Re: RE: GLIF subgroup on Global Lightpath IDs

  • Subject: Re: RE: GLIF subgroup on Global Lightpath IDs
  • From: Ronald van der Pol <Ronald.vanderPol@xxxxxxxx>
  • Date: Fri, 23 May 2008 16:50:09 +0200

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?


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.

> -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.

> -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.

> -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.

> What do others think about this?

I am curious too. Lars, 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?