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