[Nsi-wg] NSI endpoint references

[Jerry Sobieski]

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.)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110310/d3fc74cf/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GLIF Naming Conventions for GID.pdf
Type: application/pdf
Size: 56255 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/nsi-wg/attachments/20110310/d3fc74cf/attachment-0001.pdf