Resolving BGP-VPLS over Segment Routing (SR-OSPF) in Nokia SR OS

[leofurtadonyc]

Objective

One goal of the nokia-sr-mpls lab is to offer a variety of customer-focused Layer 2 and Layer 3 services using different technologies for experimentation, including L2VPN VPWS LDP, L2VPN VPLS LDP, L2VPN BGP VPLS, BGP EVPN, and L3VPN (VPRN).

All services, except for L2VPN BGP VPLS, operated smoothly with minimal issues.

For the L2VPN BGP VPLS, the objective was to deploy BGP-AD (Auto-Discovery) to establish a VPLS service within a multi-vendor, multi-node environment where the transport underlay uses Segment Routing (SR-OSPF), replacing traditional LDP or RSVP-TE.

The Problem: PathMTUTooSmall and SdpOperDown

Initially, the dynamically discovered SDPs (IDs in the 327xx range) remained in an Oper Down state with the following symptoms:

• MTU Flags: PathMTUTooSmall or MTU Mismatch errors appeared because the Service MTU (1514) and SAP MTU (1518) were inconsistent, and the dynamic SDPs were calculating overhead incorrectly.

• LSP Type Mismatch: The dynamic SDPs defaulted to LSP Types: LDP/BGP. Since the network used Segment Routing and not LDP, no transport labels were available, preventing the SDP from coming up.

• Command Availability: Modern MD-CLI versions – such as the Nokia SR OS image I am running for these labs – often lack the auto-bind-tunnel or resolution-filter commands directly under the vpls or pw-template contexts for BGP-VPLS, making it difficult to force the service to use the SR-OSPF tunnel table.

Challenges Faced

• Default Behavior: BGP-VPLS is "LDP-centric" by default. Without explicit instructions, it ignores the SR-OSPF Node-SIDs in the Tunnel Table.

• Resolution Policies: Applying global next-hop-resolution policies for vpn-family often only affects VPRN (Layer 3) and not VPLS (Layer 2) dynamic bindings.

• MD-CLI Constraints: Certain "hidden" or version-specific commands for tunnel resolution were unavailable in the local SR OS release.

The Solution: Provisioned SDPs with SR-OSPF

The fix involved bypassing the fully dynamic LDP-based SDP creation in favor of Provisioned (Manual) SDPs that use Segment Routing.

Key Steps to Resolution:

• Align MTUs: Ensure the VPLS mtu matches the SAP adm-mtu (e.g., 1518) and enable ignore-l2vpn-mtu-mismatch to prevent logical blocks.

• Manual SDP Creation: Define manual SDPs for each peer PE with delivery-type mpls.

• Force SR-OSPF: Explicitly enable sr-ospf true within the manual SDP to bind it to the Segment Routing Node-SID.

• BGP Signaling: Set signaling bgp on the manual SDP. This is the "hook" that allows BGP-AD to claim the manual SDP.

• Template Override: Update the pw-template with provisioned-sdp { use true }. This tells the BGP discovery process: "If you find a manual SDP for this peer, use it instead of trying to build a dynamic LDP one."

I was particularly frustrated that I had to manually define SDPs for the BGP VPLS to function, which somewhat defeats the purpose of this approach. How does this compare to VPLS LDP regarding manual neighbor definitions? Not much, though the underlying mechanisms differ significantly. Frustrating.

Here's the story and its caveats if you're looking for workarounds.

I expect these limitations will disappear once I deploy SR-TE, as I believe that traffic-engineering options combined with sr-te legacy might enable BGP VPLS to operate with Segment Routing as its label switching method. We'll see how it turns out!