Service VLANs

[ipspace]

The more I think about it, the more it looks like the discussions we have in #866 and #868 (and the underlying never-ending "this is not how my box works" complaints) might be caused by a missing VLAN mode-of-operation: a service VLAN.

netlab supports the "traditional" way of using VLANs, either as a bridge, router-on-a-stick, or IRB (which by definition also implies a bridge). However, there are use cases where the PE-router is providing an Ethernet transport service, and the customer frames might arrive with a VLAN tag (or be part of an access VLAN, in which case one shouldn't use a VLAN at all, but I'm digressing).

We could model such use cases with mode: service which would:

• Behave similar to mode: route and generate VLAN subinterfaces from the parent interface for trunks, and keep the parent interface intact for access VLANs.
• When creating subinterfaces, copy parent VLAN trunk attributes into subinterfaces
• Disable IPv4/IPv6 address allocation on the service node unless the VLAN would have an explicit pool or prefix attribute.

Please note that this model could be used for an E-Line or an E-Tree service but not for an E-LAN service. E-LAN service implies a bridge between local ports attached to the same VLAN in front of the service.

What one would do with such a service VLAN would remain beyond the scope of netlab, just like tunnels where netlab provides basic subnet allocation functionality and overlay configuration but does not touch the underlay tunnel provisioning.

Thoughs/ideas @jbemmel @ssasso?

[jbemmel]

I was thinking about a 'service' construct with a subtype 'vlan' as one of the options. The reason for doing it that way, is that it would enable plugins (or modules) to add support for additional types of services (by extending the list of allowed 'type' values) without interfering with existing templates

The above mode: service could work for my immediate use case, but it wouldn't provide this extensibility mechanism

Also, you may already be thinking this but the moving of attributes from physical interfaces to the 'service' vlan interface should be skipped too

[jbemmel]

Case in point is your E-LAN service example - that would become a plugin, and - on sros - would create the VPLS instance required for the local bridging

See e.g. https://documentation.nokia.com/html/0_add-h-f/93-0084-HTML/7750_SR_OS_L2_Services_Guide/services_EVPN.html#1023928

[ipspace]

I have nothing against someone creating a well-thought-out service framework ;) That framework could then behind-the-scenes tweak other link/interface parameters as needed.

If we go down that path, then we don't need service VLANs because they are almost like routed VLANs but without IP addresses, and the service framework can tweak that.

Also, I will stop worrying about configuring parameters on VLAN access links and implement a stricter interpretation of #868.