[Nml-wg] [Nsi-wg] STPs in NSI v2.0

[Freek Dijkstra]

On 11-07-2012 16:39, Roman Łapacz wrote:

>> What do you suggest?
> 
> I would not use nml namespace if the elements don't apply NML schema. 
> Simply, I would remove it from your examples.

OK, I got the same feedback in the NSI conference call today.
I will remove it and leave it up to the NSI-WG what namespace to use,
but will make it clear that "Port", "PortGroup" and "label" are NML
constructs.

I'm going to update my proposal to the NSI-WG. What should I use:

Unless you have a strong preference, I'm going to use:

> <sink>
>     <PortGroup>urn:ogf:network:nordu.net:2012:surfnet-nordunet</PortGroup>
>     <labelgroup labeltype="http://schemas.ogf.org/nml/2013/10/ethernet/vlan">1800-1899</labelgroup>
> </sink>

Instead of:

> <sink>
>     <PortGroup idRef="urn:ogf:network:nordu.net:2012:surfnet-nordunet"/>
>     <labelgroup labeltype="http://schemas.ogf.org/nml/2013/10/ethernet/vlan">1800-1899</labelgroup>
> </sink>

(The reason is that I didn't bother to introduce NML constructs in the
NSI. In short, I really want to to REFER to NML, but I don't want them
to BE NML. However, if you really think I should introduce idRef to NSI,
this is a good time.).

>> I can understand the desire to make it a short piece of NML, but that
>> would require introducing id/idRef, the hasInboundPort/hasOutboundPort
>> relations, hence the nml:Relation construct. The original proposal used
>> query parts in the URN, which is not part of NML (I'm not even sure if
>> the query part is part of the URN or not -- see my mail
>> http://www.ogf.org/pipermail/nml-wg/2012-July/001012.html).
> 
> I like Aaron proposal to use child elements and keep URN
> identifiers/strings static.

For those not on the NSI list, Aaron's proposal is here:
http://www.ogf.org/pipermail/nsi-wg/2012-July/001984.html
And my proposal to the NSI-WG is here:
http://www.ogf.org/pipermail/nsi-wg/2012-July/001993.html

I tried to base my proposal on Aaron's examples, with the child element
for labels. (Although I did change some of the names, and made the label
syntax a bit more generic to support non-VLAN labels).

Consider this the (over)due credit to Aaron for helping get this work going.

Freek