Hi On Tue, 21 Jan 2014, John MacAuley wrote:

I got nervous when hans explained the parsing from the right.  It seems we are giving up on agreement of the format parsing from the left, but still forcing a specific format when parsing from the right.  I understanding what you are trying to do, but surely we can agree on a full format that can provide a consistently parsable URN?

Well, your suggestion assumes that it starts with urn:ogf:network:... That might be okay, but it is not assumption that is required for us as such.

If the IETF can I can only assume we are smart enough to do it as well.

Not sure what you are referring to here.

...

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?

My issue is incompleteness of specification.  You need two URN formats specified for this to work:

1. The Network Id must be parsed from the NML Topology Id for you to determine the available networks.

Or have another mechanism to discover the networks/topologies.

2. The STP Id must be parsed into the Network Id and the Local Id.

Yep.

Why would we specify the format of only two of the identifiers in the specification when we can easily specify them all?

Because we only need the two. I don't see a reason to standardise something we don't need to standardise.

...

 What we did was to restrict the <stpId> such that there cannot be any ':' characters in it, and then we split from the back.

Not an unreasonable restriction, but both the networkId and localId will need to be free of colons.

Ehh... AFAICT, only the local id needs to be free of colons.

 Your name is also only parsable given the context of the name, where as the proposal here provide naming context in the name its self.

Yes, but there is no need for that. I also assume that people/implementations are sane enough to use the right identifiers in the right place. Trying to provide explicit context for all identifiers doesn't prevent anything anyway.

...

 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.

Understood, but I would like a solution agreed and documented for standard, unless of course we believe there should be nothing documented in the standard and we are free to make it deployment specific.

Yes.

...

 If we do this, could we use lowercase all the way please. We are not doing Java here :-).

It is CamelCase, but comment is understood.

I think what I intended to say is that case comparison with urns is a mess, due to the case-insensitivity of the initialy part and potential case sensisitivity in the latter part. Having all lowercase is just much less brittle. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet

Comments in line. I gave up part way through. On 2014-01-22, at 12:47 AM, Jerry Sobieski <jerry@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@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg

_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg

Freek,

Given a Port identifier, a NSA wants to figure out in which Topology this Port is located, and what the NSA is for this Port identifier.

Being a perfectionist I would like to generalize the problem statement to include any identifier. But I understand the NSI-CS only requires extracting the containing networkId of an STP from the STP. It looks like your proposal for STP resolution is based on an external lookup service instead of a parsable URN. Do we think it wise to bring in a global lookup service to just resolve an STP to a network? John On 2014-01-22, at 10:45 AM, Freek Dijkstra <Freek.Dijkstra@surfsara.nl> wrote:

Hi John,

...

NSI has the requirement that the networkId of a resource must be parseable from the resource identifier.

I don't think this is a requirement. In this email, I'm going to: I. Try to clarify your proposal. II. Suggest what should be the question/discussion. III. Conclude that we can keep the current identifier, regardless of the answer.

What's not in this email is the solution that solves our problems, sorry about that.

I.

...

<NML identifier> ::= <prefix> ":" <organization> ":" <opaque-stuff> <NSI identifier> ::= <prefix> ":" <organization> ":" <type> ":" <opaque-stuff>

Right now NSI and NML uses a schema like this:

<network id="some-opaque-urn">

What you are proposing is something like this:

<resource id="network:rest-of-the-identifier">

I don't see the advantage of your proposal. The change seems syntactical only. Am I missing something?

II.

This discussion was in the wake of a discussion on topology discovery. I think the following question needs to be answered first:

Is there a fixed or loose relation between a network and resource?

In other words, is there any use case where a STP (or other resource) can be moved from one Topology to another Topology?

The use cases mentioned at OGF40 where: * NORDUnet: split one network in two (e.g. NORDUnet-West and NORDUnet-East) * SURFnet: move a port from the testbed to the production network

In the current NML schema and identifiers, there is a loose relation. If this is the requirements, we must find a good way to distribute these relations in a scalable way. (The previously proposed lookup-service may be part of the solution here, but it is unclear how well this scales)

If the requirement is that this relation is fixed, clearly it is best that is possible to find the network by just looking at the resource ID. i think that can work with both existing and your proposal:

...

<NML identifier> ::= <prefix> ":" <organization> ":" <opaque-stuff> <NSI identifier> ::= <prefix> ":" <organization> ":" <type> ":" <opaque-stuff>

In either case, you can extract the organization identifier. While I am aware that organization ≠ network, if the relations are strict, I think we can actually use this organization ID for path finding and topology distribution.

III.

In either case, regardless if there a fixed or loose relation between a network and resource, I don't see how a new URI syntax does not seem to fix the actual problem.

The actually problem seems to be a choice between flexibility and scalability.

I don't have a solution that provides both. So the best way forward is to clearly describe the proposals we have. I sent a (very short) draft of three proposals to Henrik last week. It is attached for your reference. I hope we can use this as a basis to discuss the merits of the different proposals.

Regards, Freek <20140115 NML-WG identifiers.txt>_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg

1. Identifiers should not change. Otherwise the 'isAlias' connection between domains is not going to work.

I am not a big fan of this requirement. I have no issue if an identifier changes when a port changes a network. Part of the migration would be informing peers and end users of the change. The isAlias would be addresses as part of this migration. I understand what you are trying to achieve, but introducing the additional infrastructure overhead to do the location independent resolution may not be worth the effort. Of course, this is just my opinion and I would love if other people weighed in on the topic. On 2014-01-23, at 8:03 AM, Freek Dijkstra <Freek.Dijkstra@surfsara.nl> wrote:

On 22-01-2014 23:13, John MacAuley wrote:

...

It looks like your proposal for STP resolution is based on an external lookup service instead of a parsable URN.

That is correct.

...

Do we think it wise to bring in a global lookup service to just resolve an STP to a network?

That's indeed the question.

So far I made two premises:

1. Identifiers should not change. Otherwise the 'isAlias' connection between domains is not going to work.

2. STP (and perhaps other resources) may migrate from one Topology to another. See the two use case in my previous email [*]

From this I reasoned that we need a lookup service (though 'global' can still mean distributed or delegated, just like DNS and Handle).

If you can convince me that either one of my premises is wrong, or that there are other solutions that can cope with these requirements, please do.

I think the reasoning by Henrik is that premise #2 is wrong.

What do you think?

Regards, Freek

[*] * NORDUnet: split one network in two (e.g. NORDUnet-West and NORDUnet-East) * SURFnet: move a port from the testbed to the production network

-- Freek Dijkstra | Group Leader & Network Expert | Infrastructure Services | SURFsara | | Science Park 140 | 1098 XG Amsterdam | +31 6 4484 7459 | | Freek.Dijkstra@surfsara.nl | www.surfsara.nl |

Available on Mon | Tue | Wed | Thu | _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg

On Fri, 28 Feb 2014, John MacAuley wrote:

Would it be possible to make progress on this topic so we could perhaps close in Atlanta? We have had discussions, and Freek has presented the difference between an identifier and an address, but I believe we need something more concrete. I have proposed the structured URN approach to address the problem.

Can we please come to agreement soon?

I still don't see the need for this. It doesn't solve any problems AFAICT. It just introduces more things to adhere to without providing any value. Furthermore, I think it is clear that NML - at least in its current incarnation - will not be the long term solution for us. Adding a lot of rules for how to generate identifiers for it just seems like a waste of time. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet