Hi folks-

We need to still decide on an NSI endpoint reference scheme.  This is essentially a means to uniquely identify end points within the *NSI* context.  

I think it is very important that we not confuse the "NSI endpoint reference"  with the topology information that the NSAs may internally associate with an end point, or that other non-NSI functions may require.  The NSI topology model only specifies "networks" and "edge/end points".   And where an end endpoint in one network coincides with an end point in another network, NSI topology captures this peering connection relationship too.  But this is all NSI has regarding topology(!)   This is the NSI "context". 

As far as I can see, all we really need within the NSI-CS specification is a "network identifier" : "endpoint identifier" tuple to uniquely identify an NSI-CS termination point.   These NSI references are only relevant within the NSI context.  I.e. Any mapping of NSI endpoint references to NRM resources is NRM specific and therefore (IMO) out of scope for the NSI standard  (i.e. put another way: it is the NRM's responsibility to perform that mapping.)   Further, I believe such mapping is only a local issue, so we should not promote other  information beyond that local scope by allowing (or requiring) other information in the NSI endpoint reference itself.   We should keep the NSI endpoint reference abstracted above any specific local or physical information.   If physical topological information is important to the NSI, then we have a much bigger problem.  And if an NSA requires such information, it should ask the owner/leaf NSA who presumably knows how to get that information from the NRM.

The attached GLIF Global ID recommendation provides a good coverage of names in this respect.  It defines a global identifier thusly:
            <GID> := <domain part> ":" <local part>.      
I think this is close to what JohnM was referring to on the call this week(?)    Since this does provide the two basic components that NSI requires, (a "network" name and a "local part" for endpoint name) I think this will be a good and minimally sufficient way to specify NSI-CS termination points in version 1.0.

The GLIF recommendation also allows for URN extensions.   However, I would not include these as part of the NSI specification unless a) it maintains the network::endpoint tuple of NSI, and b) we can specify exactly what that URN should be and why it is necessary for NSI to function properly.   At this time, I believe a simple name like  "nordu.net:CPH-AMS-10GE" or "NetherLight:pSonar" is sufficient for v1.0.  i.e. references without a urn: prefix. 

If someone thinks we need a URN specification for version 1.0, please pipe up and provide the reasoning - there may be such, I just am unaware of one in my mind at this moment.  (But please don't tell me its needed for web services-WS is not why we created NSI:-).  Adding a URN prefix qualifies the namespace - why does/should NSI need a qualified namespace for endpoint references?  If you think we do, or even if you think it is just a good idea, please explain how this reconciles with the NSI architecture - i.e. how the URN version maps the <network><endpoint> tuple, and how it improves the basic GID mentioned above?   Remember, we are only speaking to NSI endpoint references,...

I think as long as the basic <domain name><local part> tuple is maintained in an endpoint reference (in conformance with the NSI architecture), and the syntactic parsing is clear, then we do actually have a good bit of flexibility in the strings themselves.

Thoughts?
Jerry

PS:  With respect to how the NSI to NRM mapping takes place for each respective NRM, I think this should be described in the NRM implementation guide, not the NSI specification.  NSI is NRM agnostic.  While this does imply some translation function is required at the NSA, it keeps naming consistent across the entire NSI universe. (And I assert that the mapping is only meaningful locally anyway.)