-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Add SPB in L2VPN #18434
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
This is not a "Tunnel" in the NetBox sense. Should likely be part of a routing protocol extension/plugin.
This is not a "Tunnel" in the NetBox sense. Again, part of this should be part of a routing protocol extension/plugin. Please revisit your request and constrain it to SPB on the L2VPN model only (which I am not sure is even correct) |
Hello Daniel, Thank you for your feedback. Indeed, VRF object is the one for L3VPNs. I’ve updated my request to include only SPB in L2VPN, which is definitely correct. If you have any doubts, please refer to the "9. L2 Services" section of this document: SPB Architecture Technical Brief. Best regards, |
I still have doubts, and nothing in that tech brief clears it up. L2VPN is pretty much exclusively to model L2 services over L3 connectivity. SPB seems to be running L2 over L2 with IS-IS for a control-plane. I am not sure if it makes sense to document it as a L2VPN. Typical SPB seems to uses mac-in-mac There does appear to be a SPB over MPLS, which is a distinct thing, where it uses MPLS to establish the VPN, but it doesn't seem to be the norm or widely adopted (from what I can tell) |
SPB operates as L2 over L2 with IS-IS as the control plane and uses MAC-in-MAC. While it doesn’t rely on an L3 underlay, its purpose aligns with the L2VPN concept: virtualizing Layer 2 services across the network. In fact, PBB-EVPN, which is already part of the L2VPN model, is conceptually identical to SPB in terms of data plane with MAC-in-MAC. The only difference is that SPB uses IS-IS as the control plane, whereas PBB-EVPN uses MP-BGP with EVPN.
I'm not proposing to add SPB over MPLS, but rather pure SPB, which is widely adopted by service providers, universities, transportation, government and defense, retail, and healthcare sectors, primarily for its simplicity, flexibility, and scalability. |
Everything I have read suggests pure SPB is more of a replacement for STP and not a replacement for L2VPNs. Going over that, which appears to be a quick primer (at least the first part) that bills SPB as more of a replacement for STP, not L2VPNs
None of this suggests L2VPNS, it all suggests Layer 2. Unless someone else chimes in and suggests otherwise, I don't think we will go forward to adding SPB to Layer 2 VPNs. That said, there is a need to document things like STP (Yuck), VPC, MLAG, TRILL and SPB. Perhaps someone will see the need and develop a plugin or we can develop for core something that incorporates all of this.
PBB-EVPN is a layer 2 point to point EVPN over MPLS. Yes, PBB and SPB are interrelated, but what we are documenting in the L2VPNs is not the fact that there is a PBB, but the fact that there is a L2 tunnel over an MPLS/IP network. |
Thank you for your feedback and thoughtful response. While it’s true that SPB was initially designed to replace STP (Spanning Tree Protocol) and address Layer 2 scalability and performance challenges, its functionality extends far beyond STP replacement. Specifically, SPB (as defined in IEEE 802.1aq) can also be leveraged for Layer 2 VPN services, aligning conceptually and functionally with the goals of the L2VPN model. SPB and Layer 2 VirtualizationSPB provides a robust framework for virtualizing Layer 2 networks using MAC-in-MAC encapsulation. By using IS-IS as its control plane, SPB distributes MAC address reachability information across the network, enabling virtualized Layer 2 connectivity between endpoints. This is the exact purpose of an L2VPN: to create seamless Layer 2 communication over a shared infrastructure. The IEEE 802.1aq standard explicitly defines support for Virtual Private LAN Services (VPLS) and point-to-point connectivity, making SPB a suitable candidate for modeling L2VPNs. For example, in service provider environments, SPB is used to provision VLAN-based L2VPN services for customers while maintaining isolation between different tenants. SPB achieves this using an I-SID (Service Identifier), which is equivalent to the VNID (Virtual Network Identifier) in VXLAN. The I-SID identifies the service across the backbone network, ensuring proper encapsulation and forwarding of traffic. Access ports are then mapped to the service using VLAN tags (802.1Q), enabling tenant-specific traffic isolation. This approach mirrors the functionality of other L2VPN protocols, providing the same virtualization and segmentation capabilities within SPB. Resources Supporting SPB for L2VPNsTo further substantiate this, the IEEE 802.1aq standard specifies SPB as a solution for building scalable and virtualized Ethernet networks. Its application to L2VPN use cases is well-documented in:
ConclusionSPB’s role as a replacement for STP is only part of the story. Its ability to virtualize Layer 2 services using MAC-in-MAC encapsulation and IS-IS control plane aligns directly with the L2VPN model. By including SPB in the L2VPN framework, we acknowledge its widespread adoption and powerful capabilities. I hope this clarifies why SPB belongs in the L2VPN model. If you’d like, I can provide additional references or real-world examples of SPB in L2VPN deployments. |
@Mathias-gt I will assign this to you for implementation since you seem to have an idea as to how to implement this. To be clear, if we require, in the future, to add isid, sap, etc this will require a new model as it is untenable with the existing model (which is geared more towards MPLS) |
Great news, thanks for assigning it to me! Actually, I don't believe a new model is necessary. The current model is perfectly suited for this implementation. By using L2VPN with SPB, I plan to add L2VPN terminations with sub-interfaces, which will correspond to the Service Access Port. This approach keeps things aligned with the existing structure and doesn’t require changes to the model. I'll also create a repository and a YouTube video to demonstrate the full implementation, so everyone can see the approach in action. Let me submit a Pull request! |
NetBox version
v4.2.2
Feature type
Data model extension
Proposed functionality
This feature request proposes adding support for Shortest Path Bridging (SPB) as an option in NetBox's
L2VPNTypeChoices
. These addition aim to enhance NetBox’s ability to model and document SPB networks effectively.Specific Changes:
L2VPNTypeChoices:
TYPE_SPB
with a user-facing label of "SPB."CHOICES
tuple to include a new category or entry for SPB.Workflows and Data Models:
L2VPNTypeChoices
.User Interface:
L2VPNTypeChoices
is used.Note: I am ready to submit a pull request with the proposed modifications. My commit is already available here: Mathias-gt@ecc679a.
Use case
Adding support for SPB addresses the need for modern networks to document and manage increasingly diverse protocols. This protocol is widely deployed in enterprise networks for its scalability, flexibility, and simplicity.
Benefits:
Supporting this L2VPN type ensures that NetBox can serve as a comprehensive source of truth for organizations using this protocol.
Database changes
No changes to the database schema are required. The proposed functionality involves extending the existing
L2VPNTypeChoices
. These changes will only add new constants and options to existing enumerations, leveraging the current model structure.External dependencies
No new external dependencies are introduced by this feature. The proposed changes only extend existing functionality within NetBox's existing framework.
The text was updated successfully, but these errors were encountered: