[Nsi-wg] NSI endpoint references

Sun Mar 13 00:43:09 CST 2011

Jerry,

I am going to jump in with some questions to better my understanding -  
embedded below

>
> If we look at some high successful aspects of the internet we see:   
> Names that map to IP addresses, IP addresses that map globally to an  
> interface, and interface addresses that can be moved locally to  
> other hardware without changing references to those interfaces.
>
> The <network>:<endpoint> tuple is analogous to the global IP address  
> with its <network>/<host> definition.  So we can call the NSI tuple  
> a symbolic global addressing scheme.   I think this is an important  
> feature for NSI. AS it turns out, this tuple is sufficient to route  
> a request across the global NSI topology, but is independent of the  
> physical topology.  It is the leaf NSA's job to know how to  
> translate an NSI EPR to the local NRM.   Indeed, since the leaf NSA  
> is just a PA frontend to the NRM, we can say that translating from  
> NSI EPR to local NRM is the job of the NRM-PA. THis makes the  
> translation to local topology a function of the NRM and out of scope  
> for NSI.
>
Please do not use EPR as a sub for STPs - it is already a standardized  
term..could cause confusion. http://en.wikipedia.org/wiki/WS- 
Addressing  :)

> We could allow a topological specification as well.   But this has  
> the drawback that every application globally referencing that end  
> point will need to know the topological location.  If that physical  
> location changes for any reason, all applications need to be  
> changed.  Just as IP address *can* be used for URLs, DNS names are  
> used in order to abstract the desired endpoint from the physical  
> location it occupies at the moment.    In addition, advertising  
> endpoints by their topological specification allows internal  
> topology to leak out globally.

I understand what you are saying - but to me what you are suggesting  
falls within best practices and you cannot mandate someone not to  
encode topological spec into their local string. for example

3  te-1-4-ur03.santaclara.ca.sfba.comcast.net (68.86.248.17)  17.047  
ms  18.316 ms  33.941 ms
  4  te-1-10-0-5-ar01.sfsutro.ca.sfba.comcast.net (68.85.155.58)   
62.206 ms  72.866 ms  52.751 ms
  5  pos-1-7-0-0-cr01.sanjose.ca.ibone.comcast.net (68.86.90.153)   
52.351 ms  72.093 ms  32.664 ms
  6  pos-0-0-0-0-pe01.529bryant.ca.ibone.comcast.net

I just want to be sure you are not referring to encoding like the  
above which can be done?

>
> I know Inder (and probably Tomohiro) have questions about how you  
> select VLANs at a remote endpoint,

The question is how to specify aggregate end-points using this method  
of uninterpretable local strings. The number of these end-points when  
you consider virtual ones can be huge. So there is a benefit in having  
a specification that can aggregate those. The other question is how to  
show interconnectivity between two STPs - one in each domain.

> but I view this as a pathfinding issue within each domain - not a  
> global issue.  While this is related to topology and visibility, if  
> we stay within the confines/context of the NSI-CS protcol I do not  
> think we need to address this in the standard.  At least not  
> immediately.
>
> So whether we use a "urn:blah <domain>:<endpoint>" or just a raw  
> tuple "//<domainname>/<endpointname>" is not a big issue with me.   
> As long as we support the tuple and agree on *one* convention that  
> all NSAs must recognize.

I prefer the urn representation (even though we could define our own  
string delimiter and format) and I imagine that OGF urn will be  
registered with IANA (http://tools.ietf.org/html/draft-dijkstra-urn-ogf-01 
  and http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xml)

Inder

>
>
>> Just to make sure we are clear on definitions, URNs are not  
>> specifically associated with web services, and in fact, have little  
>> to do with web services.  Here is the introduction from RFC2141  
>> that defines the URN:
>>
>> Uniform Resource Names (URNs) are intended to serve as persistent  
>> location-independent, resource identifiers and are designed to make  
>> it easy to map other namespaces (which share the properties of  
>> URNs) into URN-space. Therefore, the URN syntax provides a means to  
>> encode character data in a form that can be sent in existing  
>> protocols, transcribed on most keyboards, etc.
>>
>> By definition it is exactly what you have been asking for with  
>> physical location independent naming.  Whether you are using web  
>> services or some other binary protocol, a URN is just a syntax for  
>> identification and naming.  This mechanism has been chosen for use  
>> by the GLIF, perfSONAR, and the NML group.
>>
>> Now, a URN also qualifies as an instance of a URI similar to how a  
>> URL is also an instance of a URI.  Perhaps this is why you may have  
>> confused it with  web services?
> I think my concern is that the endpoints we are trying to reference  
> are not values passed to application services - they are endpoints  
> of conenctions.   Is it apropriate to force all users of NSI to  
> adopt OGF naming conventions for their network endpoints?  It is one  
> thing to say NSI uses these namepsaces internal to the protocol, its  
> is another to say all users of NSI services must also use OGF name  
> spaces to name their endpoints. If we specify any namesapce, it  
> seems to me we are also excluding all others.   Is this necessary to  
> identify endpoints suitably?- or just a habit we've gotten into?
>>
>> Personally, I do not like to be wishy washy with types when  
>> defining protocols.  Stating that an endpoint mush be from a URN  
>> namespace, or more specifically, the OGF URN namespace, will give  
>> more clarity in the protocol definition, and bind the protocol  
>> definition to other OGF specifications.
> Speaking of clarity, how much "clarity" does it really need?  What  
> is not clear?   We are talking about a two part tuple...  That  
> carries no NSI relevant information in the names.   Why would more  
> namespaces provide more "clarity"?   Namespaces just qualify  
> the ...uh..namespace.   duh.  I think what you want is not just  
> namespaces but XML schemas.
>
> Remember - these names are not places we are sending HTTP commands -  
> these are dataplane end points.   Putting all that clarity on them  
> sure seems to me to be unnecessary ...I don't see the confusion.
>> I would probably define a compound type as follows (I use XML  
>> schema since I know it well):
>>
>>    <xsd:complexType name="StpType">
>>       <xsd:sequence>
>>          <xsd:element name="domain" type="xsd:anyURI" />
>>          <xsd:element name="endpoint" type="xsd:anyURI" />
>>       </xsd:sequence>
>>    </xsd:complexType>
>>
>> However, I am not going to argue is people think it should be two  
>> strings instead of two URN.
>>
>> John.
>>
> Thanks John and all of you for the thoughtful discussion.
> Jerry
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110312/2bf009c3/attachment-0001.html 