Skip to content

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

Closed
Mathias-gt opened this issue Jan 20, 2025 · 8 comments · Fixed by #18523
Closed

Add SPB in L2VPN #18434

Mathias-gt opened this issue Jan 20, 2025 · 8 comments · Fixed by #18523
Assignees
Labels
complexity: low Requires minimal effort to implement status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application

Comments

@Mathias-gt
Copy link
Contributor

Mathias-gt commented Jan 20, 2025

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:

  1. L2VPNTypeChoices:

    • Add TYPE_SPB with a user-facing label of "SPB."
    • Update the CHOICES tuple to include a new category or entry for SPB.
  2. Workflows and Data Models:

    • This change would expand the selection of supported protocols in L2VPNTypeChoices.
    • They would not alter existing workflows but offer more options for documenting and managing network infrastructures.
  3. User Interface:

    • These new options would be visible in any form or interface where the L2VPNTypeChoices is used.

L2VPNType Choices

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:

  • SPB: Enables users to document deployments of Shortest Path Bridging, used for simplifying and scaling Layer 2 networks.

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.

@Mathias-gt Mathias-gt added status: needs triage This issue is awaiting triage by a maintainer type: feature Introduction of new functionality to the application labels Jan 20, 2025
@DanSheps
Copy link
Member

DanSheps commented Jan 20, 2025

MPLS with BGP VPNv4

This is not a "Tunnel" in the NetBox sense. Should likely be part of a routing protocol extension/plugin.

EVPN VXLAN

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)

@DanSheps DanSheps added status: revisions needed This issue requires additional information to be actionable and removed status: needs triage This issue is awaiting triage by a maintainer labels Jan 20, 2025
@Mathias-gt
Copy link
Contributor Author

Mathias-gt commented Jan 21, 2025

MPLS with BGP VPNv4

This is not a "Tunnel" in the NetBox sense. Should likely be part of a routing protocol extension/plugin.

EVPN VXLAN

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,
Mathias

@DanSheps
Copy link
Member

DanSheps commented Jan 21, 2025

If you have any doubts, please refer to the "9. L2 Services" section of this document: SPB Architecture Technical Brief.

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)

@Mathias-gt
Copy link
Contributor Author

Mathias-gt commented Jan 22, 2025

If you have any doubts, please refer to the "9. L2 Services" section of this document: SPB Architecture Technical Brief.

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

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.

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)

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.

@DanSheps
Copy link
Member

DanSheps commented Jan 22, 2025

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.

Everything I have read suggests pure SPB is more of a replacement for STP and not a replacement for L2VPNs.

https://r5.ieee.org/houston/wp-content/uploads/sites/32/2015/12/Team-Generra-Oliver-Marquise-Cooper3.pdf

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

Summary

• IS-IS builds the network topology
• SPB creates shortest path
• Shortest Path Bridging provides the value of network virtualization with the overall ease of deployment and on-going maintenance
• Future developments to include reduce complexity of networks

Competing Standards

• TRILL - Transparent Interconnection of Lots of Links
• MLAG
• VPC
• Qfabric

Why

• By getting rid of STP and freeing up more Layer 2 paths-
– Enterprises will be better able to migrate virtual machines
– More available bandwidth
– Make switches more cost effect
– Allow switches to load balance traffic

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.

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.

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.

@Mathias-gt
Copy link
Contributor Author

Mathias-gt commented Jan 24, 2025

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 Virtualization

SPB 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.
For a detailed explanation, refer to this video: https://youtu.be/cG8RwgDXsus?si=Ke-2wXZ49SsRqyZi (check from minute 27:53 to 29:43). It is explicitly stated that SPB can do L2VPN.

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 L2VPNs

To 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:

  1. "Shortest Path Bridging - Creating Services - L2VPNs"
    • A document explaining how to configure L2VPNs on Alcatel-Lucent Enterprise OmniSwitches.
  2. "IS-IS in Avaya’s SPB Fabric: One Protocol to Bind Them All"
    • A document from Avaya (now part of Extreme Networks) explicitly states that SPB supports L2VPN functionality.
  3. "Enabling L2VPN"
    • A document from HPE explicitly explaining how to configure L2VPNs in SPB.
  4. "IEEE 802.1aq-2012: Standard for Local and Metropolitan Area Networks"
  5. MEF Standards (e.g., MEF 6.2, MEF 10.3):
    • SPB aligns with MEF-defined Carrier Ethernet service models, including E-LAN and E-Tree, which are integral to L2VPNs.

Conclusion

SPB’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 Mathias-gt changed the title Add L2VPN and Tunnel choices Add SPB in L2VPN Jan 24, 2025
@DanSheps DanSheps added status: accepted This issue has been accepted for implementation complexity: low Requires minimal effort to implement and removed status: revisions needed This issue requires additional information to be actionable labels Jan 27, 2025
@DanSheps
Copy link
Member

@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)

@Mathias-gt
Copy link
Contributor Author

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!

@DanSheps DanSheps linked a pull request Feb 18, 2025 that will close this issue
jeremystretch pushed a commit that referenced this issue Feb 25, 2025
* Add SPB in L2VPN

* Change category as Other

Co-authored-by: Daniel Sheppard <dans@dansheps.com>

---------

Co-authored-by: Daniel Sheppard <dans@dansheps.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
complexity: low Requires minimal effort to implement status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants