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 |