[Nsi-wg] NSI Identifier format

[Henrik Thostrup Jensen]

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