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. 

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@ogf.org
http://www.ogf.org/mailman/listinfo/nsi-wg