[Nml-wg] [NSI imp] Wednesday NSI Implementation Task-force meeting

[John MacAuley]

On 2014-06-25, at 8:04 AM, Freek Dijkstra <Freek.Dijkstra at surfsara.nl> wrote:

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

The labelType and encoding seem a bit redundant, but we can take advantage of them for reducing the size of the XML document by defining wildcard behaviours as I have outlined in the proposal.

Why are the labelType and encoding redundant?
- A Port can only have a single labelType, and a SwitchingService can only switch on a single labelType.  This means all ports in a SwitchingService must be of the same labelType, otherwise the SwitchingService is malformed.  Therefore, having labelType in the SwitchingService is duplicate information.
- A Port can only have a single encoding type, and a SwitchingService can switch on a single encoding type.  This means all ports in a SwitchingService must be of the same encoding type, otherwise the SwitchingService is malformed.  Therefore, having encoding in the SwitchingService is duplicate information.

Having said that we want to keep it for dynamically populating SwitchingService contents.

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

Although your example of tagged and untagged ports makes sense for the encoding attribute, it does not make sense for the SwitchingService itself because it is switching on labelType, and an untagged port does not have the appropriate label, so it should not be in the SwitchingService.  I was under the impression that I would need to adapt the untagged port first to add a label, then have that adapted port in the SwitchingService?

Is your intent to combine adaption into the SwitchingService for label push and pops?

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

Is a network not just a bunch of limitations placed on the man?

Does this also mean that you would like to change the behaviour of a topology when a SwitchingService has not been defined?  Currently labelSwapping == false in this case.

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

I would recommend the same.

John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20140625/00947de2/attachment-0001.html>