Global Lambda Integrated Facility

Fwd: Re: RE: GLIF subgroup on Global Lightpath IDs

  • Subject: Fwd: Re: RE: GLIF subgroup on Global Lightpath IDs
  • From: Ronald van der Pol <Ronald.vanderPol@xxxxxxxx>
  • Date: Tue, 3 Jun 2008 13:07:10 +0200


Do you have any thoughts to share about the global identifiers?


----- Forwarded message from Thomas Tam <thomas.tam@xxxxxxxxxx> -----

From: Thomas Tam <thomas.tam@xxxxxxxxxx>
Date: Thu, 29 May 2008 13:23:05 -0400
To: global-id@xxxxxxx
CC: Tom Lehman <tlehman@xxxxxxxxxxxx>,
	'Ronald van der Pol' <Ronald.vanderPol@xxxxxxxx>,
	'Lars Fischer' <lars@xxxxxxxxx>
Subject: Re: [global-id] RE: GLIF subgroup on Global Lightpath IDs

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  

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

----- End forwarded message -----

Attachment: signature.asc
Description: Digital signature