Multiple L2VPN terminations to the physical interface

[MarianRychtecky]

NetBox version

v3.6.4

Feature type

Change to existing functionality

Proposed functionality

We document VLANs transferred through an EVPN/VxLAN fabric with L2VPNs.
Currently, we cannot add the interface to two different L2VPN instances, which means that we cannot document all services bound to the specific physical interface.
Therefore, we propose to allow multiple L2VPNs to be terminated on the physical interface.

Additionally, expanding the L2VPN port GUI with a device box:

Recent GUI forms do not show the device for selection, only the interface. It is tough to select the correct device/interface combination.

Use case

We need a model where the service provided to the customer is a unique bind between the physical interface and the VLAN provided. L2VPN Termination is an excellent option.
Another possible option is to assign VLAN to the physical interface, but this association does not provide an association with unique parameters.
We run a service with private peering and public peering; we need to terminate both services (VNIs) on a physical interface with multiple different parameters, such as Service ID, client's MAC address, tenant, etc.

Database changes

No response

External dependencies

No response

[DanSheps]

Please see previous discussion on this topic in #10404 and #10419. This has been discussed and while your idea is not without merit the way I have typically seen this done is VIA subinterfaces, service templates or service instances (I live in Cisco world). There is no built in method to create a service instance/template in NetBox currently and it is unlikely to be added before this FR so you would have to make do with subinterfaces. The other way it is typically done is VIA vlans on device (Nexus) but typically not to a physical interface directly

There is also #11466 which will add a device to the VLAN + Device model.

If you want to share your config (privately if you wish) with me I can take a look and see what options we have.

As it stands right now, this FR does not add anything further then already discussed. Please continue the discussion in the linked discussion until a viable, actionable FR can be proposed.