Re: globally unique identifiers for lightpaths?

[Jerry Sobieski <jerrys@xxxxxxxxxxxxxx>]

THis is an interesting discussion.   A couple observations:

We do need this to be simple yet scalable - and secure.

A globally unique session ID  should not be generated centrally.    I 
suggests a standard Global Resouce Identifier format something like:
      <Global_resource_ID>  ::=  <admin_domain_id>-<admin_resource_id>
This would allow any domain to create a globally unique identifier 
simply by prefixing their administrative domain identifier to a locally 
unique number.   The domain id could be an ASN, or some other Enterprise 
ID (ala SNMP MIBs), or something else.  The key is that an 
administrative domain only needs to obtain a globally unique domain ID 
once from a central issuing authority.  

We could stipulate formats for the GRI in general.  For example, the 
<admin_domain_id>  could be seven characters, alphanumeric, Left 
justified, underscore filled, case insensitive.   Followed by a single 
dash.    Followed by <admin_resource_id>  of 16 characters, 
alphanumeric, case insitive, underscore filled.
...or something like this...

As for security:   I don't think any information about the light path 
itself should be present in the GRI.   An agent (outside of the control 
plane itself) wishing to learn more information should be authorized by 
the issuing domain. (I don't think just anybody should be able to query 
the details of a light path - there should be some authroization 
architecture associated with giving out such information)   If an 
arbitrary agent has a GRI, there is enough information present in the 
name to locate the authoritative domain that established (or "owns") the 
light path.   The curious agent should ask the "owner" to provide 
details about the light path. (such as a loose hop ERO, or Next Hop 
Admin_Doamin_ID)  Network agents that are authorized components of the 
the domains along the path will already have access to information about 
the lightpath as allocated within their local domain, but (IMO) they 
need to be authorized and authenticated to query any information about 
the light path beyond their domain (information such as path details 
thru other domains).   Access Authorization by the administrative domain 
responsible for the component resources is important.

I think there also needs to be a means for authenticating a GRI.  I can 
imagine the situation where GRIs are spoofed, or otherwise duplicated.  
The confusion caused could be substantial, and could be a malicious act.

Further, there is no guarrantee that a single GRI represents the 
end-to-end path.   It is easy to concatenate two (or more) separate LSPs 
together, which completely  torpedos the  ability to discern 
information  about and  end-to-end notion.    Note that this can be the 
case even if the entire [real] end to end light path is provisioned 
using automated/dynamic agents

Fundamentally, I think the aspect of end-to-end perfomance analysis of 
light paths is going to be extremely difficult as the capability becomes 
more widely adopted.   There will be many (most) domains that will be 
very reluctant to provide outside agents with access to internal 
detailed information on a LSP by LSP basis.   "peered" models of ENNI 
provisioning may never be common.    I believe we need to develop an 
architecture that allows each domain to independently characterize 
and/or verify the performance across their specific components 
regardless of upstream or down stream network engineering or 
performance, and then commnicate just those results along to authorized 
agents.   I think for scalability reasons (and policy reasons) we should 
pursue a performance verification (or fault isolation) architecture that 
does not rely on full end-to-end visibility.   A "a trusted, delegated, 
blackbox performance verification process" is whats needed (IMHO:-)

Jerry


Freek Dijkstra wrote:
> Ronald van der Pol wrote:
>
>   
> > Two possibilities, I think:
> > - central repository
> > - random number
> >     
>
> For scalability reasons, I prefer the latter.
>
> As to ensure global uniqueness, Ronald proposed timestamps. Another
> method is to use a hierarchy and use DNS, AS numbers, or -as Ronald
> suggested- location of the nearest city. This reduces the global
> uniqueness constraint to a more local uniqueness constraint, which is
> often manageable. As an example, put the timestamp and your GPS
> coordinates together, and as long as your not standing to a big random
> generator, you are pretty sure it is a unique number.
>
> - RDF uses URIs as unique identifiers, and relies on DNS + whatever the
> domain name owner comes up with.
> - Universally Unique IDentifiers (UUID) rely on timestamp and node ID
> (See RFC 4122, ITU-T X.667 or ISO/IEC 9834-8)
>
> Note that cities in UN Location codes
> (http://www.unece.org/cefact/locode/) are country dependent. For
> example, there is also an "AMS" in the United States. So this example:
>
>   
> > 20071205200042-AMS-CHI
> > 20071206070809-NYC-TYO
> >     
>
> Ought to be:
> 20071205200042-NLAMS-USCHI
> 20071206070809-USNYC-JPTYO
>
> As Kevin Pointed out, these are not unique. What if we get two GOLEs in
> the same city? That is not unthinkable. (The problem of 1 GOLE in more
> cities is solvable. Pacific Wave can either use US-SEA, US-SNN or
> US-LAX, depending on the terminating device).
>
> I would not create a repository for GOLE codes. This has two problems:
> 1) Yet Another Global Name Repository. Why not use an existing one. If
> UN location codes or AS numbers (not all GOLEs have IP addresses) are
> not sufficient, simply use another, like their domain name.
> 2) We should not restrict the end points to GOLEs. While that is the
> current practice, our goal is lightpaths towards end-users (at least
> it's mine!). So the end points in user domains should be possible.
>
>
> The discussion seems to be whether the ID should be contain information
> or not. I personally don't like UUIDs, and I now think why. I never can
> remember them!
>
> The -AMS-CHI appendix are really nice. It helps me, as a human,
> understand it. Why not use the domain name of the requester, rather than
> the GOLE id? So:
> 20071205200042-amc.nl
> 20071206070809-uhvem.osaka-u.ac.jp
>
>
> Regards,
> Freek
>
>
> PS: When checking the ITU-T reference for UUID, I just found that since
> last month you can download ITU-T recommendations for free! That is
> excellent news; with RFCs and W3C recommendations always free and the
> Get IEEE program, only ISO standards have restricted access.
> http://www.itu.int/ITU-T/newslog/Free+Access+For+All+To+ITUT+Standards.aspx
>
>