RE: RE: GLIF subgroup on Global Lightpath IDs

["Tom Lehman" <tlehman@xxxxxxxxxxxx>]

Ronald,

thanks for the feedback.  i am mostly in agreement with your points.  the
main objective is to have an identifier, which can be presented to other
systems to get more data.  and hopefully we do not need to have centralized
databases to make all this work.  

and as you describe, perhaps the perfsonar community will converge on
solution that will be able to handle these functions as part of their
distributed lookup service.

regards,
Tom

> -----Original Message-----
> From: Ronald van der Pol [mailto:Ronald.vanderPol@xxxxxxxx] 
> Sent: Friday, May 23, 2008 10:50 AM
> To: Tom Lehman
> Cc: 'Ronald van der Pol'; 'Thomas Tam'; 'Lars Fischer'; 
> global-id@xxxxxxx
> Subject: Re: [global-id] RE: GLIF subgroup on Global Lightpath IDs
> 
> 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.
> 
> > -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?
> 
> 	rvdp
>