[Nsi-wg] NSI Identifier format

John MacAuley macauley at es.net
Tue Jan 21 10:25:49 EST 2014


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?  If the IETF can I can only assume we are smart enough to do it as well.

> 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?

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.
2. The STP Id must be parsed into the Network Id and the Local Id.

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

> 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.  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.

> 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.

> 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.

John

On 2014-01-21, at 5:10 AM, Henrik Thostrup Jensen <htj at nordu.net> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20140121/6428c9c5/attachment.html>


More information about the nsi-wg mailing list