Global Lambda Integrated Facility

Subject Re: globally unique identifiers for lightpaths?
From Jerry Sobieski <jerrys@xxxxxxxxxxxxxx>
Date Fri, 07 Dec 2007 09:48:37 -0500

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