[Nsi-wg] NSI endpoint references

[Evangelos Chaniotakis]

Jerry,

If I may distill your email to:

"Let's define an NSI-CS endpoint reference as this tuple: (globally  
unique domain identifier, locally scoped opaque identifier)."

I'm fine with that definition.

The actual implementation/representation/format of such a tuple should  
be left to the implementors of the protocol. It's just an ordered pair  
of strings, it does not deserve a big discussion about formats.




On Mar 10, 2011, at 8:16 AM, Jerry Sobieski wrote:

> 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.)
>
> <GLIF Naming Conventions for  
> GID.pdf>_______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg

-- 
Evangelos Chaniotakis
Network Engineer, ESnet
Visit our blog: http://bit.ly/9mNapV