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

[Freek Dijkstra]

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 at surfsara.nl | www.surfsara.nl |

Available on Mon | Tue | Wed | Thu |