QinQ - Basic initial functionality (no vlan translation)

[ITJamie]

NetBox version

v3.5.7

Feature type

Data model extension

Proposed functionality

There would be two new sections under IPAM, svlan + svlan groups When editing an interface there would be an additional option under 802.1 mode (Double tagged) When selected two additional fields would appear (svlan group + svlan)

When viewing an svlan object it should list any interfaces that have that svlan assigned

on the API the interface model should include the svlan object

Use case

This would allow for basic documentation of basic QinQ uses

NOTE: im excluding vlan translation for the initial feature request:

• IMHO a larger PR needs to be had for general vlan translation options + ui features to allow cross-referencing objects)
• In a lot of cases the interface name will be a hint to the user if there needs to be vlan translation happening and could be handled in automation tooling (which is already the way many folks handle this right now)

Documenting that svlan's exist and showing that an svlan exists on an interface would be a major improvement.

Database changes

new svlan + svlan groups model (an exact clone of vlan + vlan groups models)

Interfaces model:

• Additional option under mode (double tagged)
• New fields:
  • Svlan (foreign key to svlan)

External dependencies

N/A

[sleepinggenius2]

This is something that I've definitely struggled with documenting in our network. In order to support properly modeling an EPL service, we would also need something like Double Tagged (All) to allow for associating all CVLANs with that SVLAN. Unfortunately, for EVPLs, we would also need the ability to map the CVLANs on an interface to multiple SVLANs, i.e. CVLAN 1 to SVLAN 1001 and CVLANs 2, 3 to SVLAN 1002. IMHO, there really needs to be a larger effort to support proper MEF modeling for Ethernet services to accurately document UNIs, ENNIs, EVCs, and OVCs. This FR could help on the ENNI side, but just ends up a bit confusing on the UNI or INNI side.

[ITJamie]

From my pov getting basic svlan models in will allow iteration of features as people use it and better describe their additional needs

Vlan translation is something thats needed but that will affect multiple areas (vxlan, vlans, svlan) and possibly new style of ui/forms. I would honnestly think that we would a new m2m relationship model to track translations and mappings (which should then make it possible to document all way way upto EVPLs.

Hence trying to get the basic svlan concept in first and then figure out a translation model + all of the additional ui complexity for translations

[ITJamie]

@sleepinggenius2 im on the netdev slack instance if you want to discuss alternatives directly or even work together on an alternative proposal that would cover more usecases

[sleepinggenius2]

@sleepinggenius2 im on the netdev slack instance if you want to discuss alternatives directly or even work together on an alternative proposal that would cover more usecases

I've never used Slack before, so it will take me a little bit to get that set up and up to speed on it. I would suggest getting @jsenecal involved in the discussion as well though, as this FR has a direct relation to #10558 and #13086.

IMHO, I would like to see full modeling for all the MEF models, especially EVC/OVC, L1VC, and IPVC, in addition to the various UNI and NNI models. That's the only place I've really seen QinQ in practice in our network.

[jsenecal]

@sleepinggenius2 This specific issue is aimed towards supporting the documentation of QinQ which on its own is not a small task.

I'm not sure how to tackle this but this issue could serve as a ground for discussing the implementation if any.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

[github-actions[bot]]

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

[jeffgdotorg]

Reviving as a starting point for work of this kind proposed for a future version's roadmap. There's some good conversation captured here. This issue will need additional detailing and breaking down into smaller chunks.