[Nml-wg] NML-NSI integration

[Freek Dijkstra]

Roman,

Can I forward the following to the list?

Freek


All,

Roman created an update to the AutoGOLE topology. This lead to an
off-list discussion regarding the namespaces.

Since this may be relevant to the group, I would like to take this
discussion on-list.

Freek

-------- Original Message --------
Subject: Re: [Nml-wg] Notes for teleconference Feb 16
Date: Fri, 17 Feb 2012 15:53:09 +0100
From: Roman Łapacz <romradz at man.poznan.pl>
To: Freek Dijkstra <Freek.Dijkstra at sara.nl>
CC: Jeroen van der Ham <vdham at uva.nl>,
    Jason Zurawski <zurawski at internet2.edu>

Freek suggested:

>>>>> * Use NML namespace over NML-NSI namespace where possible

Roman:

>>>> nml-nsi:port indicates that the port element represents NSI's STP
>>>> nml-nsi:link indicates that the link element represents NSI's SDP
>>>> nm-nsi:network indicates that the network element represents NSI's nsnetwork
>>>> All three things are specific to NSI so I would keep their nsi
>>>> namespaces to stress that.

Freek:

>>> I understand your point, and agree that is may be beneficial to denote
>>> somehow that these are SDP or STP to NSI.
>>>
>>> However, would using a different namespace not defeat the purpose of NML
>>> of having a single schema that everyone uses?
>>>
>>> (Also, I'm not sure if that should be in the topology; I'm actually
>>> hoping that we can keep the topology clean from control plane
>>> information, and have the the control plane simply refer to the topology.)

Roman:

>> I see your point. Just one basic NML namespace would be an ideal
>> situation. But still think that extensions/namespaces should be allowed
>> to assign more and specific information to the basic NML elements. The
>> NSI application(s) may want such extension to easily identify NSI
>> abstract connections or points.

Freek:

> I was perhaps a bit quick in saying "let's use NML (base) namespace
> everywhere". I don't know what the best option is. I try to make up my
> mind as we discuss this.
>
> It is certainly possible to overload (subclass? I'm not sure about the
> correct term here) a namespace to let's say include NSI-specific
> attributes next to the regular NML-attributes.
>
> However, I see a big risk there: in the past we have been discussing the
> option to overload (subclass?) a namespace for the purpose of
> differentiating between different technologies (Ethernet, WDM, ...).
> I don't see a clean way to put something in both a nml-nsi AND a
> nml-ethernet namespace. Unless we are creating nml-base, nml-nsi,
> nml-ethernet, and also nml-nsi-ethernet namespaces. I have a feeling
> that that solution does not scale. What if tomorrow some policy working
> group comes along, and we have to create a nml-nsi-ethernet-public and
> nml-nsi-ethernet-restricted namespace (or whatever someone may come up
> with).
>
> In programming patterns, I think we need to use has-a instead of is-a (a
> Port has-a STP-attribute, rather than a Port is-a STP).
>
>
> Here is my current thinking.
>
> I understand there is a need for NSI (and perhaps others) to tag a given
> port as being a "STP", and perhaps it should go in the topology. It
> actually is a matter how to refer to it. The option above tags certain
> ports as "an STP" by being in a different namespace. My thought (hope)
> was that the NSI protocol could add a tag somewhere like this:

If we allow adding new tags as extensions in any place in the structure
then we don't have too much control over the structure. Generic parsers
will not know how to interpret such unexpected (not included in the base
NML schema) changes. On the contrary, namespaces as extensions allow
parsers to, at least, understand their standard properties, others would
be ignored. The structures defined in the base NML schema are still
followed. (Of course it is possible to define a schema in such way that
any element could be inserted in any place but I don't think it's the
right direction).

Roman

> <nml:topology id="1234">
>    ....
>    <!-- regular NML topology info -->
>    ...
>      <nsi:stp-list>
>        <nml:port idref="...."/>
>        <nml:port idref="...."/>
>        <nml:port idref="...."/>
>      </nsi:stp-list>
> </nml:topology>
> <nsi:domain>
>    <contact>
>      <vCard>
>    </contact>
>    <controller>
>      <url>http://example.net/webservices/NSI-controller</url>
>      <topology idref="1234"/>
>    <controller>
> </nsi-domain>