Re: [Nml-wg] [NSI imp] Wednesday NSI Implementation Task-force meeting
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@surfsara.nl | www.surfsara.nl | Available on Mon | Tue | Wed | Thu |
On 2014-06-25, at 8:04 AM, Freek Dijkstra <Freek.Dijkstra@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
On 25-6-2014 15:18, John MacAuley replied to Freek Dijkstra:
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). [...]
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?
We indeed agreed that we use a AdaptationService to add/remove a label. However, NML is technology-independant, and it is possible to make a slightly different description of Ethernet. What I am saying is that it is *possible* to do simple E-NNI functionality (adding/removing a label) in a SwitchingService. (You would still need a AdaptationService to adapt between different encodings). We don't this right now. While it likely makes the description more compact, it is non-trivial to understand, especially in the case of Q-in-Q. For the reason of complexity to understand the later option, I have not pursued it. However, I like to leave the possibility open for the future. I think we can make the proposed changes while keeping this option open, so that's my recommendation.
So I recommend to interpret this attribute [LabelType] 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.
Regards, Freek -- Freek Dijkstra | Group Leader & Network Expert | Infrastructure Services | SURFsara | | Science Park 140 | 1098 XG Amsterdam | +31 6 4484 7459 | | Freek.Dijkstra@surfsara.nl | www.surfsara.nl | Available on Mon | Tue | Wed | Thu |
participants (2)
-
Freek Dijkstra -
John MacAuley