[Nsi-wg] NSI Identifier format
Jerry Sobieski
jerry at nordu.net
Wed Jan 22 00:47:25 EST 2014
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.
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.
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.
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
More information about the nsi-wg
mailing list