Skip to content

Conversation

@KyoyaTeramae
Copy link

@KyoyaTeramae KyoyaTeramae commented Dec 10, 2025

Change Scope

*   This PR enhances to support an RSVP-TE Fast Reroute (FRR) capability by introducing a mechanism to explicitly assign pre-configured LSPs as bypass tunnels. This is a common requirement for service providers who want deterministic failover paths for protected interfaces. When an interface running RSVP-TE with FRR enabled fails, traffic can be redirected onto specified bypass LSPs, which have their own explicit paths.
 
    To support this, the following changes are made:
    1.  A new leaf-list named bypass-tunnel is added to the RSVP interface protection configuration (openconfig-mpls-rsvp.yang). This allows one or more pre-configured TE tunnels to be designated as bypass LSPs.
    2.  To differentiate these bypass LSPs from regular LSPs, a new BYPASS_P2P identity is introduced under the TUNNEL_TYPE base (openconfig-mpls-types.yang).
    3.  The description for the tunnel type leaf has been updated accordingly (openconfig-mpls-te.yang).
 
*   This change is backwards compatible as it only introduces new optional data nodes and a new identity.
 

Platform Implementations

*   Cisco IOS-XR: The backup-path command under the protected interface allows specifying one or more tunnel interfaces to act as bypass LSPs. This directly corresponds to the proposed bypass-tunnel leaf-list.
 
    https://www.cisco.com/c/en/us/td/docs/iosxr/cisco8000/mpls/command/reference/b-mpls-cr-8k/b-mpls-te-commands.html#:~:text=backup%2Dbw-,backup%2Dpath%20tunnel%2Dte,-bandwidth%2Daccounting
 

mpls traffic-eng
 interface GigabitEthernet0/0/0/0
  backup-path tunnel-te 20020
  backup-path tunnel-te 30040
 !
 interface tunnel-te20020
  description NHOP_xxxxx
  ipv4 unnumbered Loopback0
  signalled-name NHOP_20020_xxxx
  priority 7 7
  destination xx.xx.xx.xx
  record-route
  path-option 50 explicit name NHOP_20020-EPath_50
 !
 interface tunnel-te30040
  description NNHOP_30040_xxxx
  ipv4 unnumbered Loopback0
  signalled-name NNHOP_30040_xxxx
  priority 7 7
  destination xx.xx.xx.xx
  record-route
  path-option 50 explicit name NNHOP_30040-EPath_50

 
*   Drivenets DNOS: The bypass-tunnel command under protocols rsvp interface <interface-name> protection is used to assign bypass LSPs. The bypass tunnel itself is also explicitly configured with bypass differentiated from a regular tunnel. This implicitly requires the proposed BYASS_P2P tunnel type.
 

protocols rsvp interface ge100-0/0/0 protection bypass-tunnel NHOP_XXXX
protocols rsvp interface ge100-0/0/0 protection bypass-tunnel NNHOP_XXXX

protocols rsvp tunnel NHOP_XXXX bypass admin-state enabled
protocols rsvp tunnel NHOP_XXXX bypass description NHOP_XXXX
protocols rsvp tunnel NHOP_XXXX bypass destination-address xx.xx.xx.xx
protocols rsvp tunnel NHOP_XXXX bypass primary path-options 5 path explicit NHOP_xxxx

protocols rsvp tunnel NNHOP_XXXX bypass admin-state enabled
protocols rsvp tunnel NNHOP_XXXX bypass description NNHOP_XXXX
protocols rsvp tunnel NNHOP_XXXX bypass destination-address xx.xx.xx.xx
protocols rsvp tunnel NNHOP_XXXX bypass primary path-options 5 path explicit NNHOP_xxxx

 
*   Nokia SR OS: The bypass-only command option for the configure router mpls lsp context explicitly defines the LSP as a dedicated manual configured bypass tunnel. This creates an exclusive LSP type that is differentiated from carrying regular service traffic, directly supporting the proposed BYPASS_P2P identity. When a manual path (ERO) is applied to this LSP type, it functions as a deterministic bypass tunnel.

 https://documentation.nokia.com/sr/24-7/7x50-shared/mpls/mpls-rsvp.html#ai9emdyo7f

configure
 router
  mpls
   path "bypass-path"
    hop 1 xx.xx.xx.xx strict
    hop 2 xx.xx.xx.xx strict
    no shutdown
   exit
   lsp "bypass-lsp" bypass-only
    to xx.xx.xx.xx
    primary "bypass-path"
    exit
    no shutdown
   exit
  exit
 exit

Tree View

*   The following diff shows the addition of the bypass-tunnel leaf-list to the RSVP-TE interface protection configuration.
 

 module: openconfig-mpls
   +--rw network-instances
      +--rw network-instance* [name]
         +--rw mpls
            +--rw signaling-protocols
               +--rw rsvp-te
                  +--rw interface-attributes
                     +--rw interface* [interface-id]
                        +--rw protection
                           +--rw config
                              +--rw link-protection-style-requested?   identityref
                              +--rw bypass-optimize-interval?          uint16
+                             +--rw bypass-tunnel*                     -> ../../../../../../../lsps/constrained-path/tunnels/tunnel/name

@dplore dplore self-assigned this Dec 12, 2025
@dplore dplore moved this to Ready to discuss in OC Operator Review Dec 13, 2025
@dplore
Copy link
Member

dplore commented Dec 13, 2025

/gcbrun

@OpenConfigBot
Copy link

OpenConfigBot commented Dec 13, 2025

No major YANG version changes in commit 3998c51

@KyoyaTeramae KyoyaTeramae requested a review from earies December 15, 2025 08:53
@dplore
Copy link
Member

dplore commented Dec 23, 2025

/gcbrun

@KyoyaTeramae KyoyaTeramae requested a review from dplore December 28, 2025 11:38
@dplore
Copy link
Member

dplore commented Dec 29, 2025

/gcbrun

Copy link
Member

@dplore dplore left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. To be reviewed at next OC Operators meeting.

@ElodinLaarz
Copy link
Contributor

Discussed in the OC Operators Meeting Jan 6th 2026:

Seems reasonable; no objections raised. Setting this last-call to 2 weeks from now.

@ElodinLaarz ElodinLaarz moved this from Ready to discuss to last-call in OC Operator Review Jan 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: last-call

Development

Successfully merging this pull request may close these issues.

5 participants