[Nsi-wg] NSI endpoint references

[Jerry Sobieski]

Hi Vangelis-

You are right except for one part:...  As I see this, it is really only 
the NRM that cares about the endpoint name.  NSI has no interest in what 
the endpoint string looks like other than maybe some purely aesthetic 
lexical conventions (e.g. no backspace characters, etc.)    Therefore, 
the *NSI* protocol implementers must explicitly treat the string as just 
a string.    If one domain wants to name its endpoints with topology 
info encoded, they can do that, but no other domain or NSA will look for 
that info in their string...as far as the other NSAs are concerned, the 
string is just a string.

I will say though that for the mapping of the NSI endpoint reference to 
the NRM resource *is* the responsibility of the implementors who are 
coding the PA frontend onto an NRM.  They do need to know if local 
convention expects or requires local endpoints to be named a certain 
way.  But again it is only relevant for the local endpoints, and so is 
only of local significance and only for that particular NRM.   So this 
is not an NSI issue.

I recommend that we are explicit in the NSI standard and say the following:
The <local part> of the endpoint reference is a string that uniquely 
identifies a particular endpoint within the <domain> specified.   The 
NSI framework and protocol explicitly leave the value of the endpoint 
reference string to be assigned by the network domain within which the 
endpoint resides.   The NSI Framework and protocol do not encode any 
information directly into the endpoint reference string.

How is that?   This insures that local domains have full sway to name 
their own endpoints as they see fit.

Best regards
Jerry


On 3/10/11 11:48 AM, Evangelos Chaniotakis wrote:
> 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
>