L2VPNs: Roles and Redundancy

[ggidofalvy-tc]

Hey folks,

I've recently started looking at the relatively new L2VPN feature to model some of our L2VPNs (instead of relying on circuits to virtually model them). In the current implementation, all L2VPN members are counted as equal: there is no differentiation in which role a given interface assignment functions in terms of the L2VPN.

I believe that the existing L2VPN abstraction could be enhanced by introducing one or two "Role" fields in the L2VPN termination model. These role(s) could refer to either to the role in the overall L2VPN (customer-facing, network-facing, etc), as well as functional roles (active, backup, root, leaf). The latter is especially important for our use case, pseudowire redundancy (which I figure is not unique).

This leads to the second idea to add to the L2VPN model, which is to add support for pseudowire redundancy in case of P2P L2VPNs -- this would mean reducing a constraint from two participant interfaces to 2 active, and 2 backup interfaces at most. Given that it is not evident which active interface would correspond to which backup interface, the "L2VPN role" could be used to pair the active interface to the backup interface -- one active-backup interface pair would serve the network-facing role, while the other active-backup interface pair would serve the customer-facing role.

Adding further functional roles, such as root and leaf, would also enable multi-root E-Trees to be modelled, which would address the redundancy functionality in case of E-Trees. Thankfully, no such ambiguity appears in case of E-Trees as P2P L2VPNs have. VPLS, EVPLAN, and ELANs, by their design, require no redundancy modelling.

As it stands right now, E-Trees cannot be accurately, or even functionally modelled in the L2VPN abstraction of NetBox.

[NT5G]

I agree. I would also like to document the pseudowire.