openconfig subinterface support for untagged to double tagged.

[lesmurray]

In most service provider networks you have customer traffic coming into the UNI ports untagged and then being double tagged with an S/C tag in a 1:1 customer VLAN which goes all the way to the router.
In looking at the subinterfaces oc-vlan:vlan it has something similar to IETF sub interface tagging but has fewer options. On the match side it should be matching untagged traffic, there is no option for this. The action should be a push of two VLANs. The push option only has a single VLAN push option and is not a list, so can't put two tags onto untagged traffic. Perhaps I'm misinterpreting the model, but that how it decodes in the yang suite tool.
Can someone explain how to implement this given the model. We are actively implementing this and are unclear how to get it to work.
I do see a double tag on the match, but that would imply match on packets that ingress with two tags, no untagged traffic. (i.e. as it is legit on some ports to just pass through doubly tagged traffic.)

[lesmurray]

Hello.... is anyone out there???? Does anyone actually answer questions in this group?

[dplore]

I am not very familiar with the vlan models, but reading through them just now I see there are ingress and egress push actions which refer to a vlan-id of type oc-vlan-types:vlan-id.

In vlan-types I see the vlan-id which is only for a single vlan as you observed.

However, there is a qinq-id which allows for a 2 vlan stack as an id.

So one way to get the schema you are looking for is to add a leaf that uses the qinq-id. For example, a 'qinq-vlan-id' leaf that looks similar to the existing leaf, but with a qinq id.

[lesmurray]

First I wanted to thank you for offering your help and support, it is greatly appreciated. Agreed, I can definitely extend the model, could copy over from the IETF model which covers all this quite well. Also it is missing the match criteria for untagged traffic. So how would people use this model to "recognize" and tag untagged incoming frames with the existing model. Thanks on the qinq-id I saw that as well, but as you pointed out it isn't a part of this part of the model. Also a few other questions:

• Is there someone who is kind of in charge of this model? how do I find the right person? Most standards bodies usually have a group driving the model and usually best to work through them to get acceptance. How does it become part of the official release.
• The model is missing a number of elements, do I just submit some changes, or what is the process. I don't want to be running proprietary MIBs.

[lesmurray]

Also would you comment on why there isn't a vlan Match action for untagged?

[robshakir]

@chrisy -- could you PTAL at this issue? I'm happy to reload context here, but I think you'd tried to consider as many of these VLAN cases as we could when we made the last change.

[chrisy]

Apologies for the late response. Much of what is in the model now is based on meeting the needs we had at the time. OpenConfig doesn't strive for completeness, only coverage of requirements, and it accepts that this means models evolve iteratively. When something is missing it's because nobody needed when it was authored, but proposals are welcome to extend the coverage. We generally avoid simply copying over IETF models. If you want an IETF model, use it.

As for untagged matching, these structures are attached to subinterfaces. The OpenConfig convention is that subinterface 0 represents the "parent" interface, which implies it matches untagged already, and I can imagine thinking at the time that this meant no explicit match was necessary. It wasn't a case I needed to cover (our topology doesn't match untagged on the PE but on a separate layer 2 aggregation switch) so didn't document that assumption.

[github-actions[bot]]

This issue is stale because it has been open 180 days with no activity. If you wish to keep this issue active, please remove the stale label or add a comment, otherwise will be closed in 14 days.