[Nsi-wg] NSI endpoint references

[Jerry Sobieski]

Hi all and John :-)   -

I don't have an aversion to XML - I actually sorta like it due to its 
structured high level specifications.  And even namespaces are not so 
bad - if they are well considered.   But you must admit defining where 
XML ends and Web Service begin is a slippery slope  :-)

The problem at hand is thus:  How do we identify service "endpoints" or 
STPs within the NSI context?

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.

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 know Inder (and probably Tomohiro) have questions about how you select 
VLANs at a remote endpoint, 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 have a couple other comments below...



On 3/12/11 8:42 PM, John MacAuley wrote:
> On 2011-03-10, at 11:16 AM, Jerry Sobieski wrote:
>
> > 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,...
>
> Jerry,
>
> It makes me giggle just imagining you in front of our computer having 
> a seizure every time you think of web services.
Well I'm glad I entertain you all:-)

I am truly sorry we have such differing opinions on this.  But I have 
not seen much compelling to change my opinion that Web Services is 
highly structured to very little practical effect.   A noble vision, but 
it got buried in a mountain of software and specifications.  Where is 
the  K&R and Hello World of web services?

> 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:complexTypename="StpType">
> <xsd:sequence>
> <xsd:elementname="domain"type="xsd:anyURI"/>
> <xsd:elementname="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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110312/f0901d3d/attachment.html