John wrote to the NSI implementation group
> Guy is unavailable for an NSI call so I will run an implementation one this week.
>
[..]
> Agenda:
>
> - Validate the proposed default behaviours for the SwitchingService within our NML topologies.
Hi all,
Unfortunately, due to a scheduling conflict, I'm not able to attend
today's call, so here are my remarks by email.
On procedure: I think this discussion is mostly about standardisation,
so I'll cc the nml-wg list. Since I suspect a majority of the
subscribers are on both lists, I apologize for the duplicate mails you
receive.
See also slide 5-9 from the OGF40 NML session about this topic. I've
attached them for your convenience.
You propose two changes:
1. Allowing other attributes to the defined ones
(other elements is already allowed)
2. Add the LabelType to the SwitchingService.
I agree with the changes, but have four remarks, I like the group to
consider before accepting or rejecting the changes.
1. Adding ##other to the attributes makes it more forward compatible,
which I think is good. It would allow future NML extensions, so an
attribute ca be added. Right now, the addition of an attribute would not
be a simple extension, but a whole new version of NML.
A small recommendation: I do recommend extensions to use elements rather
than attributes, to avoid naming collisions (elements use namespaces.
attributes formally can use them too, but I've rarely seen that in practice)
2. Each of the ports of a SwitchingService has one encoding (e.g. 'IEEE
802' for Ethernet), and thus the SwitchingService also has one encoding.
However, I would like to allow the possibility in the future that a
single SwitchingServices has Ports with different types of labels (e.g.
tagged and untagged). So I recommend to interpret this attribute as
follows: it is not a property of the SwitchingService, but rather: it is
a property of all Port of the SwitchingService that has this attribute.
This would us to leave out the LabelType of the SwitchingService, and
instead defined it for all Ports individually.
3. A small note on the labelSwapping attribute: the default is now
"False", meaning that by default we assume that a device can not convert
between Ethernet VLANs (or other labels). In retrospect, a default value
of "True" would have been better. labelSwapping is a limitation of the
devices, and I would now argue that by default, a path finder should not
expect limitations in the path, unless it is explicitly specified.
However, this change is mostly cosmetic, so I'm perfectly fine with
keeping it as it is.
4. Asusming that 1, 2 or 3 of the above changes will be made to the
schema: should we update the URI of the schema?
In other words, what should be the headline of the XSD schema?
A patch only, no URI change (only a small version update):
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> targetNamespace="http://schemas.ogf.org/nml/2013/05/base#"
> xmlns:nml="http://schemas.ogf.org/nml/2013/05/base#"
> elementFormDefault="qualified" version="1.1">
or a full URI change:
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> targetNamespace="http://schemas.ogf.org/nml/2014/06/base#"
> xmlns:nml="http://schemas.ogf.org/nml/2014/06/base#"
> elementFormDefault="qualified" version="1.0">
My recommendation is to consider this as a patch, without URI change.
Regards,
Freek Dijkstra
--
Freek Dijkstra
| Group Leader & Network Expert | Infrastructure Services | SURFsara |
| Science Park 140 | 1098 XG Amsterdam | +31 6 4484 7459 |
| Freek.Dijkstra(a)surfsara.nl | www.surfsara.nl |
Available on Mon | Tue | Wed | Thu |
