RE: RE: GLIF subgroup on Global Lightpath IDs

["Tom Lehman" <tlehman@xxxxxxxxxxxx>]

Ronald and All,

I discussed some of these concepts with some working on the perfsonar
distributed lookup service.  I think there are still some concerns and
unresolved issues with the use of totally random global ids.  Similar to
what we were discussing with respect to distributed information services. If
the global ids are totally random, it is not clear how you will ever know
where in the distributed lookup service to go to get more information.  The
result may be that we will require the distributed lookup up service
distribute the ids globally.  

That is the main reason we decided to leverage the inherent hierarchy in the
dns name system, so that there is an established way to present an id to any
point in the distributed lookup service, and it is possible to find your way
back to the authorative information source, without having to distribute
data globally.

I suggest that we have some more discussions with the perfsonar/distributed
lookup service community before any decisions are made, and make sure we
have do have a global id scheme that will play nicely with the distributed
information services. 

Perhaps in this document we could lay out the pros/cons of random number
based ids and ids which leverage the dns naming or some other topology
schema hierarchy, and solicit input from the perfsonar subgroup, that was
also established at the last GLIF meeting?

Tom



> -----Original Message-----
> From: Tom Lehman [mailto:tlehman@xxxxxxxxxxxx] 
> Sent: Monday, May 26, 2008 6:40 PM
> To: 'Ronald van der Pol'
> Cc: 'Thomas Tam'; 'Lars Fischer'; global-id@xxxxxxx
> Subject: RE: [global-id] RE: GLIF subgroup on Global Lightpath IDs
> 
> 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
> > 
>