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

[Ronald van der Pol <Ronald.vanderPol@xxxxxxxx>]

Lars,

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

	rvdp

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


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

Attachment: signature.asc
Description: Digital signature