[Nsi-wg] NSI Identifier format
John MacAuley
john.macauley at surfnet.nl
Wed Jan 22 16:43:55 EST 2014
Comments in line. I gave up part way through.
On 2014-01-22, at 12:47 AM, Jerry Sobieski <jerry at nordu.net> wrote:
> Here is my recommendation:
>
> First, We should not parse URNs. This overloads semantic interpretation onto the identifier string which is a Bad Idea. An identifier is just that - a handle that represents an object. Not a datastructure. Don't break this rule. The URN hierarchy is a means of delegating authority to the naming process in order to insure authoritative control of that process - not to insure it means something particular.
You are correct saying that "The URN hierarchy is a means of delegating authority to the naming process", however, the meaning, opaqueness, and any hierarchy definition is left up to the delegating authority. We are totally free to decide to create a hierarchical name that can be parsed to determine member components. The IETF has done this for URN identifying their documents. There are also other examples.
There is a large volume of examples within the industry where hierarchical names, or names containing components, have been standardized. As I said in Oxford, the ITU X.500 series of recommendations on directory services based their whole naming scheme off of hierarchy, which then led to the LDAP set of specifications, the most widely used enterprise directory service protocol in the world.
>
> Second, and more to the point - we should drop the use of URNs from NSI. NSI does not require them. They contribute nothing but extra baggage to the objects we use them for. And the existing structure and immutability requirements are confusing and arguably unneccesary and impractical in practice. URNs are not validated and so the use of strings other than URNs is indistinguishable from the use of a URN - unless you parse them. And parsing a URN every time you see one to determine if it is legally constructed is context sensitive. ugh! Besides, users and most real people hate URNs - they are long and contain a very low signal to noise ratio due to the hierarchy of authoritative domains. So they really are just unique strings who's object mapping is not known except from context anyway.
I don't really understand this argument:
1. "NSI does not require them. " - NSI requires a standardized naming scheme to identify objects. It needs to support unique object naming. We need to be able to parse names for components. These are the requirements. We can argue the level of parsing required, but as a basis we need to pull bits out. URNs provide us a way of specifying a standard name that is unique, and with the ability to identify the format of the name. There are other standard mechanism that can achieve a similar outcome. We happened to chose the URN format. We could have chosen something else, or come up with our very own naming mechanism. Basing off of the URN standard allows us to specify different naming formats if we desire, and be able to identify the applicable format based on the URN prefix. It is a flexible solution. Of course "NSI does not require them", but NSI requires a naming solution, and URN provide a usable solution.
2. "They contribute nothing but extra baggage to the objects we use them for. " - Are you referring to the "urn:prefix" component as extra baggage?
3. "And the existing structure and immutability requirements are confusing and arguably unneccesary and impractical in practice." - I think you may be confused by the "urn:ogn:network" restrictions placed on the URN versus its use as a name.
4. "We can argue the level of parsing required, but as a basis we need to pull bits out." - Agreed, but a URN does not restrict this.
5. "URNs are not validated and so the use of strings other than URNs is indistinguishable from the use of a URN - unless you parse them." - Given we are going to parse them then there is a difference.
6. "And parsing a URN every time you see one to determine if it is legally constructed is context sensitive." - Not sure I understand this one. I only need to parse a URN when I need to pull something out of it. A URN does not need to be context sensitive as we can encode context in the URN. The "urn:ogn:network" is context sensitive at the moment, and Henrik's request is context sensitive also. My proposal is not.
7. "Besides, users and most real people hate URNs - they are long and contain a very low signal to noise ratio due to the hierarchy of authoritative domains." - I think hate is such a harsh term. You dislike them. If you dislike them, then you dislike all things web as URI/URL/URN are used everywhere. I think you dislike the "urn:ogf:network" component. Perhaps a shorter "urn:ogf:nsi" would be more pleasing to your eye? Do you dislike the organization name?
8. "So they really are just unique strings who's object mapping is not known except from context anyway." - Once again I need to stress that this is not true. You are referring specifically to the current "urn:ogf:network" URN and not URN in general. Please be clear in you distinction. You HATE the "urn:ogf:network" definition.
>
> Third, the primary reason we have such confusion is because peoples decided that the simple NSI topology model of Networks, 2-tuple STPs, and SDPs was too simple and incapable of expressing the old way of doing things....and so they have incrementally tried to get back to that old plumbing based technology oriented topology model. We arrived at the NSI topology model of *service* domains and SDPs for very good reasons - it deterministically relegates all infrastructure to one domain or another. And the SDP did exactly what is was named for and is supposed to do: it defines the demarcation point - the boundary of responsibility - the adjacency between the two domains. And by walking the SDPs, a pathfinder is easily able to determine the global adjancency graph. And the beauty is that this is the only information that is fundamentally required to do end to end path finding. The additional detail of NML topology descriptions is unnecessary. SO by adding all the NML cruft and all that hard technodetail, we have made the problem enormously more complex.
With the current NML topology model I am totally capable building a full NSI topology model of ServiceDomains, SDP, and STP. I can do path finding using a global view, and have no need to parse the URN. However, I must know all the STP in the network to validate a request if I cannot look into the STP to pull out a network identifier. I also understand Henrik's need to parse for chain-based signalling. Whether Henrik calls it a link or SDP they are conceptually the same. I stayed true to the NSI topology model in my implementation.
I read through the rest of your proposal. I think you still suffer from the issue of needing context to determine what the identifier represents.
John.
>
> Let me define a couple terms first that I think will help explain my proposal:
>
> 1. A Service Termination Point is an interface on the edge of a network where Connections can terminate. Please note that the "STP" is the "thing", and the "STP Identifier" is a name or handle that allows us to refer to the "thing". I.e. there is are many STPs, and each has a unique name or an Identifier that is associated with it.
>
> An STP, the thing, is a *single* terminal where only one connection can terminate. (I'll address Identifiers and "labels" below.)
>
> 2. An STP "2-tuple" Identifier is a handle that represents a particular STP at any given point in time. The 2-tuple Identifier consists of a <NetworkID>:<localID> pair. These two components can use a colon delineated list as just shown, or we could specify it using simple Type-Value pairs: NetworkID=Nordunet, LocalID=CPH-1-1 ;
>
> (Note: The 2-tuple form works just fine even if both components are URNs - while it is long and tedious, it still works as long as each component is handled as a separate string. However, if you concatenate the network id and localid using the colon syntax into a single string, you will end up with indecipherable garbage. I believe this is one problem that is leading to the current discontent.)
>
> 3. An STP "n-tuple" Reference consists of a set of Type-Value pairs that uniquely identify a particular STP. The n-tuple reference is *NOT* an "Identifier" but rather a set of constraints that resolve a particular STP. Typically, an n-tuple reference might use physical constraints (if known) such as:
> Domain=Nordu.net, Switch=CPH, Port=CPH-ge-2-0, vlan=100;
> An alternative n-tuple reference might use NML objects:
> NMLTopology=urn:ogf:network:nordu.net:1987:ets, port=urn:ogf:network:nordu.net:1987:ets:foo, label=2;
>
> In most (all?) instance, the NSI contexts are simply *referencing* an STP - i.e. they are refering to it, as an endpoint in a reservation request for example. In these reference contexts, the STP can be refered to by using either the STP IDentifier handle associated with it, or by using the n-tuple reference that uniquely resolves the STP. In this context, either reference is semantically acceptable. Thus if you know the physical or NML elements of a desired STP, you can use them in the Reservation request just as effectively as using a specific STP 2-tuple Identifier.
>
>
> 4. The "localID" component of an STP Identifier can be a simple string handle e.g. "abc234" or it can be something far more powerful. The notion of labels was pushed forward to address a laziness issue on the part of human topology managers - they did not want to explicitly enumerate each STP Identifier. I think it is appropriate to have a more succinct form of specifying a set of STPs...but I am not sure "labels" are an appropriate mechanism for doing so. Think of the number of labels you need to map a SDH link = 2^192, and consider how "labels" are unworkable for tunable bandwidth optics where the conventional spectral channels are split or combined as needed. The current typical use is to assume that the label corresponds to a VLAN Tag...but this would be wrong.
> And certain assumptions about labels are not reliable and cannot be verified. For instance, the assumption that the STPs on either side of an SDP have corresponding labels is not required. Indeed, the assumption that *any* SDP is actually present or engineered as indicated in the announced topology is fundamentally unreliable. And therefore it is of questionable value or success to apply any technology specific concepts to global path planning.
>
> STP enumeration is not really a big problem.
>
> However, the other place where the label was used is in an STP n-tuple reference as the constraints for a Reservation request: port=foo, label=100..200 taken to mean any VLAN in the range 100 to 200 is requested. A more powerful form would be to allow 100..120, 134, 150..164, 190..200, or to use " * " meaning "any" [available] label. If a * can be a wild card for the label/subscript, why not allow the wildcard as the localid: nordu.net:* meaning ANY localid within Nordu.net - if this construct was used in an ero, it would force the path to transit NORDuet at any local STP.
>
> I propose that we introduce a different form of localid that uses opaque subscripts ala "abs123[200]". This whole expression becomes the localid component. The index can be an expression as well such as "abc123[100..200]" or abc[*] etc.
>
> sentiment, the solution was not well thought out. AS currently implemented, labels are *expected* to tie to underlying technology - i.e. for an ethernet port, a label is expected to be a VLAN. And so we have this
>
> may be a subscripted handle of the sort abc123[200]. The proposal that we use "subscripts" rather than labels is new - but really only differs slightly from the current Localid+label usage that we have now.
>
> The subscript must be positive integer from 0 to any large number. These subscripts allow the handle to represent a group of STPs, and the subscript to enumerate them.
> The value of using a "subscripted" syntax rather than a "label" allows us to define an STP in a technology agnostic manner. i.e. the subscripts do not represent technology labels, they simply indicate a set of instances. The local domain may elect to define their subscript to be VLANs, or PVCs, or MPLS tags, or even ITU Grid chanels...but they are not required to map them in any particular fashion.
>
> 5. We retain the SDP. The SDP describes the conenction(s) between domains, the adjacency. This is fundamental to path finding. If you ditch the SDP you will have to replace it with...uh... something just like it that describes the adjacency between NSI network domains. The subscript syntax allows us to enumerate large sets of STPs succintly.
>
> We probably should minimize the change in v2. This is done. So do not parse the URN. I thought the wsdl had the networkID and localID components in separate data objects: If so, the existing URNs will work and so I suggest we leave it for now. We should absolutely maintain the 2-tuple STP Identifier. And in v3 we should study a more powerful syntax for
>
> Sorry for the late/long post, but it is really REALY important that we get back to the NSI fundamentals.
>
> Best regards
> Jerry
> On 1/21/14 5:10 AM, Henrik Thostrup Jensen wrote:
>> On Fri, 17 Jan 2014, John MacAuley wrote:
>>
>>> Update based on Han's feedback.
>>
>> Han shot first.
>>
>>> NSI has the requirement that the networkId of a resource must be parseable from the resource identifier. This is especially true for the STP identifier as we have a specific requirement that an STP identifier need not be exposed in topology, and therefore, the network identifier must be derivable from the STP identifier if the target network is to be determined. The current URN format specification document published by the NML group for use as identifiers in NML [ref] defines the resource identifier as opaque, which also implies non-parseable. We need to resolve this issue.
>>
>> Yes, please.
>>
>>
>>> I have captured a proposal below for an NSI identifier that removes the opaque URN restriction and imposes structure on the URN. I hope this generates positive discussions :-)
>>
>> The important thing is to be able to split an STP into domain and port.
>>
>> I don't really see a need for all the other stuff. It it just rules without a good reason for it. I mean, why even bother writing all the stuff down and making the standards bigger without a real need?
>>
>> It is pretty close to what most would advertise anyway though, but I don't really see a need for it. It makes some of the base cases more complicated, i.e., most domains will have a single NSA, why should they use ...:nsa:1?
>>
>>> <prefix> ::= "urn:ogf:network" /* Should this be "urn:ogf:nsi". */
>>
>> I think the intention is to have URNs that are not system specific. However by doing this, we are making them system specific.
>>
>> The whole thing seems a bit silly:
>>
>> 1. Most organization will already have identifiers for their ports.
>>
>> 2. We come up with the scheme domain:localID, but no topology model.
>>
>> 3. NML comes along. Has actual topology model (I think we forget to give
>> them credit for this). Everything has an opague uri, port-topology
>> relationship must be defined explicitely, which sucks.
>>
>> 4. We come up with a scheme that crams 3 into 2. I do think we need
>> something like this, but at some point someone should figure out a sane
>> model.
>>
>>> <network> :: = "network:" <networkId>
>>> <networkId> ::= <string>
>>> <stp> ::= "stp:" <networkId> ":" <stpId>
>>> <stpId> ::= <localId> <label>
>>
>> What we did was to restrict the <stpId> such that there cannot be any ':' characters in it, and then we split from the back. This allows arbitrary prefixes, where as the above allows arbitrary suffixes. Arguably, both suck in one way or another, but we do need one of them.
>>
>> NORDUnet, SURFnet, and GEANT have made up their mind and gone with the split from the back here. It is NOT a permanent solution. But the suggestion here doesn't really feel like it either.
>>
>>> <sdp> ::= "sdp:" <sdpId>
>>> <sdpId> ::= <string> /* Should this be some type of source/destination stpId combination. */
>>
>> I don't think we need SDP anywhere. They are just a conceptual thing. Initially I had an SDP abstraction in OpenNSA, but it was removed as I didn't use it anywhere. Instead I use the concept of a link. I know you do the opposite is fine. But both links and SDPs are currently not used anywhere for describing stuff.
>>
>>> <serviceDomain> ::= "serviceDomain:" <networkId> ":" <serviceDomainId>
>>> <serviceDomainId> ::= <string>
>>
>> If we do this, could we use lowercase all the way please. We are not doing Java here :-).
>>
>>
>> Best regards, Henrik
>>
>> Henrik Thostrup Jensen <htj at nordu.net>
>> Software Developer, NORDUnet
>>
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org
>> https://www.ogf.org/mailman/listinfo/nsi-wg
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg
More information about the nsi-wg
mailing list