Segment routing with MPLS data plane (SR-MPLS)

Segment Routing with IS-IS is supported with Multi-topology IS-IS MT0 (standard IPv4 and IPv6 topology) and MT2 (IPv6-only topology). Some Segment Routing functionality is restricted to MT0 only. The following table lists the functionality constraints that apply when MT2 is used.

configure router isis segment-routing multi-topology mt2

configure router ipv6-routing
configure router isis multi-topology ipv6-unicast

TE IS Nbrs   :
    Nbr   : Dut-A.00                            
    Default Metric  : 10
    Sub TLV Len     : 153
    IF Addr   : 1.1.3.3
    IPv6 Addr : 3ffe::101:303
    Nbr IP    : 1.1.3.1               
    Nbr IPv6  : 3ffe::101:301
    MaxLink BW: 10000000 kbps
    Resvble BW: 10000000 kbps
    Unresvd BW: 
        BW[0] : 10000000 kbps
        BW[1] : 10000000 kbps
        BW[2] : 10000000 kbps
        BW[3] : 10000000 kbps
        BW[4] : 10000000 kbps
        BW[5] : 10000000 kbps
        BW[6] : 10000000 kbps
        BW[7] : 10000000 kbps
    Admin Grp : 0x0
    TE Metric : 1000
    TE APP LINK ATTR    :
      SABML-flag:Non-Legacy SABM-flags:   X
        Delay Min : 1000000 Max : 1000000
        TE Metric : 1000
    Adj-SID: Flags:v4BVL Weight:0 Label:524287
    Adj-SID: Flags:v4VL Weight:0 Label:524285
    Adj-SID: Flags:v6BVL Weight:0 Label:524286
    Adj-SID: Flags:v6VL Weight:0 Label:524284

TE IS Nbrs   :
    Nbr   : Dut-A.00                            
    Default Metric  : 10
    Sub TLV Len     : 103
    IF Addr   : 1.1.3.3
    Nbr IP    : 1.1.3.1
    MaxLink BW: 10000000 kbps
    Resvble BW: 10000000 kbps
    Unresvd BW: 
        BW[0] : 10000000 kbps
        BW[1] : 10000000 kbps
        BW[2] : 10000000 kbps
        BW[3] : 10000000 kbps
        BW[4] : 10000000 kbps
        BW[5] : 10000000 kbps
        BW[6] : 10000000 kbps
        BW[7] : 10000000 kbps
    Admin Grp : 0x0
    TE Metric : 1000
    TE APP LINK ATTR    :
      SABML-flag:Non-Legacy SABM-flags:   X
        Delay Min : 1000000 Max : 1000000
        TE Metric : 1000
    Adj-SID: Flags:v4BVL Weight:0 Label:524287
    Adj-SID: Flags:v4VL Weight:0 Label:524281
  MT IS Nbrs     :
    MT ID           : 2                    
    Nbr   : Dut-A.00                            
    Default Metric  : 10
    Sub TLV Len     : 220
    IPv6 Addr : 3ffe::101:303
    TE APP LINK ATTR    :             
      SABML-flag:Non-Legacy SABM-flags:   X
        Delay Min : 1000000 Max : 1000000
        TE Metric : 1000
    Adj-SID: Flags:v6BVL Weight:0 Label:524286
    Adj-SID: Flags:v6VL Weight:0 Label:524280
    End.X-SID: 300::2000 flags:BP algo:0 weight:0 endpoint:End.X-PSP
    End.X-SID: 310::2000 flags:BP algo:128 weight:0 endpoint:End.X-PSP
    End.X-SID: 320::2000 flags:BP algo:129 weight:0 endpoint:End.X-PSP
    End.X-SID: 330::2000 flags:BP algo:130 weight:0 endpoint:End.X-PSP
    End.X-SID: 340::2000 flags:BP algo:131 weight:0 endpoint:End.X-PSP
    End.X-SID: 350::2000 flags:BP algo:132 weight:0 endpoint:End.X-PSP
    End.X-SID: 360::2000 flags:BP algo:133 weight:0 endpoint:End.X-PSP

TE IS Nbrs   :
    Nbr   : Dut-A.00                            
    Default Metric  : 10
    Sub TLV Len     : 146             
    IF Addr   : 1.1.3.3
    IPv6 Addr : 3ffe::101:303
    Nbr IP    : 1.1.3.1
    Nbr IPv6  : 3ffe::101:301
    MaxLink BW: 10000000 kbps
    Resvble BW: 10000000 kbps
    Unresvd BW: 
        BW[0] : 10000000 kbps
        BW[1] : 10000000 kbps
        BW[2] : 10000000 kbps
        BW[3] : 10000000 kbps
        BW[4] : 10000000 kbps
        BW[5] : 10000000 kbps
        BW[6] : 10000000 kbps
        BW[7] : 10000000 kbps
    Admin Grp : 0x0
    TE Metric : 1000
    TE APP LINK ATTR    :
      SABML-flag:Non-Legacy SABM-flags:   X
        Delay Min : 1000000 Max : 1000000
        TE Metric : 1000
    Adj-SID: Flags:v4BVL Weight:0 Label:524275
    Adj-SID: Flags:v4VL Weight:0 Label:524273
    Adj-SID: Flags:v6VL Weight:0 Label:524272
  MT IS Nbrs     :
    MT ID           : 2                    
    Nbr   : Dut-A.00                            
    Default Metric  : 10
    Sub TLV Len     : 220
    IPv6 Addr : 3ffe::101:303
    TE APP LINK ATTR    :
      SABML-flag:Non-Legacy SABM-flags:   X
        Delay Min : 1000000 Max : 1000000
        TE Metric : 1000
    Adj-SID: Flags:v6BVL Weight:0 Label:524274
    Adj-SID: Flags:v6VL Weight:0 Label:524272
    End.X-SID: 300::2000 flags:BP algo:0 weight:0 endpoint:End.X-PSP
    End.X-SID: 310::2000 flags:BP algo:128 weight:0 endpoint:End.X-PSP
    End.X-SID: 320::2000 flags:BP algo:129 weight:0 endpoint:End.X-PSP
    End.X-SID: 330::2000 flags:BP algo:130 weight:0 endpoint:End.X-PSP
    End.X-SID: 340::2000 flags:BP algo:131 weight:0 endpoint:End.X-PSP
    End.X-SID: 350::2000 flags:BP algo:132 weight:0 endpoint:End.X-PSP
    End.X-SID: 360::2000 flags:BP algo:133 weight:0 endpoint:End.X-PSP

The following TLVs and sub-TLVs are defined in draft-ietf-ospf-segment-routing-extensions-04 and are required for the implementation of segment routing in OSPF:

• the prefix SID sub-TLV part of the OSPFv2 Extended Prefix TLV

• the prefix SID sub-TLV part of the OSPFv2 Extended Prefix Range TLV

• the adjacency SID sub-TLV part of the OSPFv2 Extended Link TLV

• SID/Label Range capability TLV

• SR-Algorithm capability TLV

This section describes the behaviors and limitations of OSPF support of segment routing TLVs and sub-TLVs.

SR OS originates a single prefix SID sub-TLV per OSPFv2 Extended Prefix TLV and processes the first one only if multiple prefix SID sub-TLVs are received within the same OSPFv2 Extended Prefix TLV.

SR OS encodes the 32-bit index in the prefix SID sub-TLV. The 24-bit label or variable IPv6 SID is not supported.

SR OS originates a prefix SID sub-TLV with the following encoding of the flags.

• The NP-Flag is always set. The label for the prefix SID is pushed by the PHP router when forwarding to this router. The SR OS PHP router processes a received prefix SID with the NP-flag set to zero and uses implicit-null for the outgoing label toward the router that advertised it.

• The M-Flag is always unset because SR OS does not support originating a mapping server prefix-SID sub-TLV.

• The E-flag is always set to zero. An SR OS PHP router, however, processes a received prefix SID with the E-flag set to 1, and when the NP-flag is also set to 1, it pushes explicit-null for the outgoing label toward the router that advertised it.

• The V-flag is always set to 0 to indicate an index value for the SID.

• The L-flag is always set to 0 to indicate that the SID index value is not locally significant.

• The algorithm field is set to zero to indicate Shortest Path First (SPF) algorithm based on link IGP metric or to the flexible algorithm number.

SR OS resolves a prefix SID received within an Extended Prefix TLV based on the following route preference:

• SID received via an intra-area route in a prefix SID sub-TLV part of the Extended Prefix TLV

• SID received via an inter-area route in a prefix SID sub-TLV part of the Extended Prefix TLV

SR OS originates an adjacency SID sub-TLV with the following encoding of the flags.

• The B-flag is set to zero and is not processed on receipt.

• The V-flag is always set.

• The L-flag is always set.

• The G-flag is not supported.

• The weight octet is not supported and is set to all zeros.

An adjacency SID is assigned to next hops over both the primary and secondary interfaces.

SR OS can originate the OSPFv2 Extended Prefix Range TLV as part of the Mapping Server feature and can process it properly, if received. Consider the following rules and limitations:

• Only the prefix SID sub-TLV within the TLV is processed and the ILMs are installed if the prefixes are resolved.

• The range and address prefix fields are processed. Each prefix is resolved separately.

• If the same prefix is advertised with both a prefix SID sub-TLV in an IP-reachability TLV and a mapping server Prefix-SID sub-TLV, the resolution follows the following route preference:

  • the SID received via an intra-area route in a prefix SID sub-TLV part of Extended Prefix TLV

  • the SID received via an inter-area route in a prefix SID sub-TLV part of Extended Prefix TLV

  • the SID received via an intra-area route in a prefix SID sub-TLV part of a OSPFv2 Extended Range Prefix TLV

  • the SID received via an inter-area route in a prefix SID sub-TLV part of a OSPFv2 Extended Range Prefix TLV

• No leaking of the entire TLV is performed between areas. An ABR does not propagate the prefix-SID sub-TLV from the Extended Prefix Range TLV into an Extended Prefix TLV if the latter is propagated between areas.

• The mapping server which advertised the OSPFv2 Extended Prefix Range TLV does not need to be in the shortest path for the FEC prefix.

• If the same FEC prefix is advertised in multiple OSPFv2 Extended Prefix Range TLVs by different routers, the SID in the TLV on the first router that is reachable is used. If that router becomes unreachable, the next reachable one is used.

• There is no check to determine whether the contents of the OSPFv2 Extended Prefix Range TLVs received from different mapping servers are consistent.

• Any other sub-TLV (for example, the ERO metric and unnumbered interface ID ERO) is ignored, but the user can use the IGP show command to see the octets of the received but not supported sub-TLVs.

SR OS supports propagation on the ABR of external prefix LSAs into other areas with routeType set to 3 as per draft-ietf-ospf-segment-routing-extensions-04.

SR OS supports propagation on the ABR of external prefix LSAs with route type 7 from a Not-So-Stubby Area (NSSA) into other areas with route type set to 5 as per draft-ietf-ospf-segment-routing-extensions-04. SR OS does not support propagating the prefix SID sub-TLV between OSPF instances.

When the user configures an OSPF import policy, the outcome of the policy applies to prefixes resolved in the RTM and the corresponding tunnels in the TTM. A prefix removed by the policy does not appear as both a route in the RTM and as a segment routing tunnel in the TTM.

After segment routing is successfully enabled in the IS-IS or OSPF instance, the router performs the following operations:

1. The router advertises the Segment Routing Capability sub-TLV to routers in all areas or levels of this IGP instance. Only neighbors with which the router established an adjacency can interpret the SID and label range information and use it for calculating the label to swap to or push for a specific resolved prefix SID.

2. The router advertises the assigned index for each configured node SID in the new prefix SID sub-TLV with the N-flag (node SID flag) set. The segment routing module then programs the ILM with a pop operation for each local node SID in the datapath.

3. The router assigns and advertise an adjacency SID label for each formed adjacency over a network IP interface in the Adjacency SID sub-TLV, according to the following rules and limitations:

   • The Adjacency SID sub-TLV is advertised for both numbered and unnumbered network IP interfaces.

   • The Adjacency SID is not advertised for an IES interface because access interfaces do not support MPLS.

   • The Adjacency SID sub-TLV must be unique per instance and per adjacency.

     ISIS MT=0 can establish an adjacency for both IPv4 and IPv6 address families over the same link. In this case, a different adjacency SID is assigned to each next hop. However, the existing IS-IS implementation assigns a single Protect-Group ID (PG-ID) to the adjacency and therefore when the state machine of a BFD session tracking the IPv4 or IPv6 next hop times out, an action is triggered for the prefixes of both address families over that adjacency.

   The segment routing module programs the ILM with a swap to an implicit null label operation for each advertised adjacency SID.

4. The router resolves received prefixes. If a prefix SID sub-TLV exists, the segment routing module programs the ILM with a swap operation and an LTN with a push operation, both pointing to the primary/LFA NHLFE. A segment routing tunnel is also added to the TTM. If a node SID resolves over an IES interface, the datapath is not programmed and a trap message is generated. Only next-hops of an ECMP set corresponding to network IP interfaces are programmed in the datapath; next-hops corresponding to IES interfaces are not programmed. If the user configures the interface as network on one side and IES on the other side, MPLS packets for the segment routing tunnel received on the access side are dropped.

When the user enables segment routing in an IGP instance, the main SPF and LFA SPF are computed normally and the primary next-hop and LFA backup next-hop for a received prefix are added to RTM without the label information advertised in the prefix SID sub-TLV. In all cases, the SR tunnel is not added into RTM.

See the following sections for more information about all TLVs and sub-TLVs for both IS-IS and OSPF protocols.

• IS-IS control protocol changes
• OSPFv2 control protocol changes
• OSPFv3 control protocol changes

The router performs the procedures described in the following sections when resolving a node SID prefix.

The user enables the remote LFA next-hop calculation by the IGP LFA SPF by configuring the remote-lfa option in the command that enables LFA calculation:

config>router>isis>loopfree-alternates remote-lfa
config>router>ospf>loopfree-alternates remote-lfa

SPF performs the additional remote LFA computation following the regular LFA next-hop calculation when both of the following conditions are met.

• The remote-lfa option is enabled in an IGP instance.

• The LFA next-hop calculation did not result in protection for one or more prefixes resolved to a specific interface.

Remote LFA extends the protection coverage of LFA-FRR to any topology by automatically computing and establishing or tearing down shortcut tunnels or repair tunnels, to a remote LFA node, which puts the packets back into the shortest path without looping them back to the node that forwarded them over the repair tunnel. A repair tunnel can, in theory, be an RSVP LSP, an LDP-in-LDP tunnel, or an SR tunnel. In SR OS, this feature is restricted to use an SR repair tunnel to the remote LFA node.

The remote LFA algorithm for link protection is described in RFC 7490, Remote Loop-Free Alternate (LFA) Fast Reroute (FRR). Unlike a typical LFA calculation, which is calculated per prefix, the LFA algorithm for link protection is a per-link LFA SPF calculation. The algorithm provides protection for all destination prefixes that share the protected link by using the neighbor on the other side of the protected link as a proxy for all of these destinations. Assume the topology in the following figure.

When the LFA SPF in node C computes the per-prefix LFA next hop, prefixes that use link C-B as the primary next hop have no LFA next hop because of the ring topology. If node C used node link C-D as a backup next hop, node D would loop a packet back to node C. The remote LFA then runs the following PQ algorithm, per RFC 7490.

1. Compute the extended P space of Node C with respect to link C-B. The extended P space is the set of nodes reachable from node C without any path transiting the protected link (link C-B). This computation yields nodes D, E, and F.

   The determination of the extended P space by node C uses the same computation as the regular LFA by running SPF on behalf of each of the neighbors of C.

   Note:

   RFC 7490 introduced the concept of P space, which would have excluded node F because, from the node C perspective, node C has a couple of ECMP paths, one of which goes via link C-B. However, because the remote LFA next hop is activated when link C-B fails, this rule can be relaxed and node F can be included, which then yields the extended P space.

   The user can limit the search for candidate P nodes to reduce the number of SPF calculations in topologies where many eligible P nodes can exist. The following commands can be used to configure the maximum IGP cost from node C for a P node to be eligible:

   • config>router>isis>loopfree-alternates remote-lfa max-pq-cost value

   • config>router>ospf>loopfree-alternates remote-lfa max-pq-cost value

2. Compute the Q space of node B with respect to link C-B: the set of nodes from which the destination proxy (node B) can be reached without any path transiting the protected link (link C-B).

   The Q space calculation is effectively a reverse SPF of node B. In general, one reverse SPF is run on behalf of each neighbor of C to protect all destinations resolving over the link to the neighbor. This yields nodes F and A in the example of Example of remote LFA topology.

   The user can limit the search for candidate Q nodes to reduce the number of SPF calculations in topologies where many eligible Q nodes can exist. The CLI commands in step 1 are also used to configure the maximum IGP cost from node C for a Q node to be eligible.

3. Select the best alternate node: this is the intersection of extended P and Q spaces. The best alternate node or PQ node is node F in the example of Example of remote LFA topology. From node F onwards, traffic follows the IGP shortest path.

   If many PQ nodes exist, the lowest IGP cost from node C is used to narrow down the selection, and if more than one PQ node remains, the node with lowest router ID is selected.

The details of the label stack encoding when the packet is forwarded over the remote LFA next hop are shown in the following figure.

The label corresponding to the node SID of the PQ node is pushed on top of the original label of the SID of the resolved destination prefix. If node C has resolved multiple node SIDs corresponding to different prefixes of the selected PQ node, it pushes the lowest node SID label on the packet when forwarded over the remote LFA backup next hop.

If the PQ node is also the advertising router for the resolved prefix, the label stack is compressed in the following cases, depending on the IGP.

• In IS-IS, the label stack is always reduced to a single label, which is the label of the resolved prefix owned by the PQ node.

• In OSPF, the label stack is reduced to the single label of the resolved prefix when the PQ node advertised a single node SID in this OSPF instance. If the PQ node advertised a node SID for multiple loopback interfaces within this same OSPF instance, the label stack is reduced to a single label only if the SID of the resolved prefix is the lowest SID value.

The following rules and limitations apply to the remote LFA implementation.

• If the user excludes a network IP interface from being used as an LFA next-hop using the loopfree-alternate-exclude command under the IS-IS or OSPF context of the interface, the interface is also excluded from being used as the outgoing interface for a remote LFA tunnel next hop.

• As with the regular LFA algorithm, the remote LFA algorithm computes a backup next hop to the ABR advertising an inter-area prefix and not to the destination prefix.

This section describes the application of LFA policies.

Label stack for remote LFA in ring topology shows the label stack required for the primary next hop and the remote LFA next hop computed by aggregation node AGN2 for the inter-area prefix of a remote PE. For an inter-area BGP label unicast route prefix for which ABR1 is the primary exit ABR, AGN2 resolves the prefix to the transport tunnel of ABR1 and, therefore, uses the remote LFA next hop of ABR1 for protection. The primary next hop uses two transport labels plus a service label. The remote LFA next hop for ABR1 uses PQ node AGN5 and pushes three transport labels plus a service label.

Seamless MPLS with Fast Restoration requires up to four labels to be pushed by AGN2, as shown in the following figure.

The objective of the LFA protection with a backup node SID feature is to reduce the label stack pushed by AGN2 for BGP label unicast inter-area prefixes. When link AGN2-AGN1 fails, packets are directed away from the failure and forwarded toward ABR2, which acts as the backup for ABR1 (and the other way around when ABR2 is the primary exit ABR for the BGP label unicast inter-area prefix). This requires that ABR2 advertise a special label for the loopback of ABR1 that attracts packets normally destined for ABR1. These packets are forwarded by ABR2 to ABR1 via the inter-ABR link.

As a result, AGN2 pushes the label advertised by ABR2 to back up ABR1 on top of the BGP label for the remote PE and the service label. This keeps the label stack the same size for the LFA next hop to be the same size as that of the primary next hop. It is also the same size as the remote LFA next hop for the local prefix within the ring.

This feature makes use of the Multi-Homed Prefix (MHP) model described in RFC 8518 to compute a backup IP next-hop using an alternate ABR or ASBR for external prefixes and to an alternate router owner for local anycast prefixes.

The feature applies to OSPF routes of external /32 prefixes (OSPFv2 routes types 3, 4, 5, and 7) and local /32 anycast prefixes if the prefix is not protected by base LFA.

The computed IP next-hop based backup path is programmed for SR-OSPF node SID tunnels of external /32 prefixes and to /32 prefixes in same area as the computing node and which are advertised by multiple routers (anycast prefixes) in both algorithm 0 and flexible-algorithm numbers.

See “Multi-homed prefix LFA extensions in OSPF” in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Unicast Routing Protocols Guide for more information about the configuration of this feature.

This feature makes use of the Multi-Homed Prefix (MHP) model described in RFC 8518 to compute a backup IP next-hop using an alternate ABR or ASBR for external prefixes and to an alternate router owner for local anycast prefixes.

The algorithm described in RFC 8518 is limited in scope to only computed backup paths consisting of direct IP next hops and tunneled next hops (IGP shortcuts).

The computed backup paths are added to IS-IS routes of external /32 and /128 prefixes and intra-area /32 and /128 anycast prefixes in the Routing Table Manager (RTM) if the prefix is not protected by the base LFA.

The computed backup path is also programmed for the following tunnels:

• SR IS-IS IPv4 and IPv6 node SID tunnels of external /32 and /128 prefixes and of intra-area /32 and /128 anycast prefixes, in both algorithm 0 and flexible algorithm numbers
• SRv6 IS-IS locator routes and tunnels of external prefixes and of intra-area anycast prefixes of any size, in both algorithm 0 and flexible algorithm numbers

As a result, an SR-TE LSP, an SR-MPLS policy, or an SRv6 policy that uses an SR IS-IS SID or an SRv6 IS-IS SID of those same prefixes in its configured or computed SID list benefits from the multihomed prefix LFA protection.

See “Multi-homed prefix LFA extensions in IS-IS” in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Unicast Routing Protocols Guide for more information about the configuration of this feature.

This feature enhances the IP next-hop based MHP backup path calculation specified in RFC 8518 with the addition of the support of an SR repair tunnel. The SR repair tunnel uses a PQ node or a P-Q set to reach the alternate exit ABR or ASBR for external prefixes, or alternate owner router for intra-area anycast prefixes. This capability is in addition to supporting the RFC 8518 algorithm used in the case where the path to prefix P using the alternate exit ABR or ASBR (or alternate owner router) is in the shortest path from the neighbor of the computing node.

This feature applies the computed backup path to SR-OSPF node SID tunnels of external /32 prefixes and to /32 prefixes in the same area as the computing node, and which are advertised by multiple routers (anycast prefixes) in both algorithm 0 and flexible-algorithm numbers. It also extends the protection to any SR-TE LSP or SR policy that uses an SR-OSPF SID of those same prefixes in its configured or computed SID list.

This feature shares the same configuration CLI commands as the MHP LFA feature as described in Multi-homed prefix LFA extensions in SR-OSPF. After the IP next-hop based MHP LFA is enabled, the extensions to compute an SR repair tunnel for the MHP LFA in the case of SR-OSPF are automatically enabled if the user enables TI-LFA or RLFA. The computation reuses the SID list of the primary path or of the TI-LFA or RLFA backup path of the alternate ABR, ASBR, or alternate owner router. The algorithm details are described in Extending MHP LFA coverage with repair tunnels for SR OSPF.

This feature enhances the backup path calculation for the IP next-hop based multihomed path prefix in RFC 8518 with the addition of repair tunnels that make use of a PQ node or a P-Q set to reach the alternate exit ABR or ASBR of external prefixes or the alternate owner router for intra-area anycast prefixes.

The feature programs the computed backup path for the following tunnels:

• SR IS-IS node SID tunnels of external /32 IPv4 prefixes and /128 IPv6 prefixes, and node SID tunnels of intra-area /32 IPv4 anycast prefixes and /128 anycast IPv6 prefixes, in both algorithm 0 and flexible-algorithms
• SRv6 IS-IS locator routes and tunnels of external prefixes and of intra-area anycast prefixes of any size, in both algorithm 0 and flexible algorithm numbers

As a result, an SR-TE LSP, an SR-MPLS policy, or an SRv6 policy that uses an SR IS-IS SID or an SRv6 IS-IS SID of those same prefixes in its configured or computed SID list benefits from the multihomed prefix LFA protection.

After the IP next-hop based multihomed prefix LFA is enabled, the extensions to compute a SR-TE repair tunnel for the multihomed prefix LFA in the case of SR IS-IS and SRv6 IS-IS are automatically enabled if the user also enabled TI-LFA or Remote LFA. The computation reuses the SID list of the primary path or of the TI-LFA or Remote LFA backup path of the alternate ABR or ASBR or alternate owner router.

The behavior of this feature is the same as in OSPF. See LFA solution across IGP area or instance boundary using SR repair tunnel in SR-OSPF.

The SR OS micro-loop avoidance algorithm provides a loop-free mechanism in accordance with IETF draft-bashandy-rtgwg-segment-routing-uloop. The algorithm supports a single event on a P2P link or broadcast link with two neighbors only for the following cases:

• link addition or restoration

• link removal or failure

• link metric change

Using the algorithm, the router applies the following micro-loop avoidance process.

1. After it receives the topology updates and before the new SPF is started, the router verifies that the update corresponds to a single link event. Updates for the two directions of the link are treated as a single link event.

   If two or more link events are detected, the micro-loop avoidance procedure is aborted for this SPF and the existing behavior is maintained.

   Note: The micro-loop avoidance procedure is aborted if the subsequent link event received by an ABR is from a different area than the one that triggered the event initially. However, if the received event comes from a different IGP instance, the ABR handles it independently and triggers the micro-loop avoidance procedure, as long as it is a single event in that IGP instance.

2. The main SPF and LFA SPF algorithms (base LFA, remote LFA or TI-LFA, based on the user configuration in that IGP instance) are run.

3. No action is performed for a node or a prefix if the SPF calculation has resulted in no change to its next hops and metrics.

4. No action is performed for a node or a prefix if the SPF has resulted in a change to its next-hops or metrics, or both, and the new next hops are resolved over RSVP-TE LSPs used as IGP shortcuts.

   Note: Nokia strongly recommends enabling CSPF for the RSVP-TE LSP used in IGP shortcut application. This avoids IGP churn and ensures micro-loop avoidance in the path of the RSVP control plane messages which would otherwise be generated following the convergence of IGP because the next hop in the ERO is looked up in the routing table.

5. The route is marked as micro-loop avoidance eligible for a node or a prefix if the SPF has resulted in a change to its next hops or metrics. The router performs the following:

   • For each SR node SID that uses a micro-loop avoidance eligible route with ECMP next hops, the router activates the common set of next hops between the previous and new SPF.

   • For each SR node SID that uses a micro-loop-avoidance eligible route with a single next hop, the router computes and activates a loop-free SR tunnel applicable to the specific link event.

     This tunnel acts as the micro-loop avoidance primary path for the route and uses the same outgoing interface as the newly computed primary next hop.

     See Micro-loop avoidance for link addition, restoration, or metric decrease and Micro-loop avoidance for link removal, failure, or metric increase for more information.

   • The router programs the TI-LFA, base LFA, or remote LFA backup path that protects the new primary next hop of the node SID.

6. The fib-delay timer is started to delay the programming of the new main and LFA SPF results into the FIB.

7. After the fib-delay expires, the new primary next hops are programmed for node SID routes that are marked as eligible for the micro-loop avoidance procedure.

The following figure depicts an example of link removal or failure in a network topology.

The micro-loop avoidance algorithm performs the following steps in the preceding network topology example.

1. Link 6-9 is removed or fails.

2. Router 3 detects a single link event and runs main and LFA SPFs.

   • All nodes downstream of the removed link in the Dijkstra tree (in this case, nodes 9, 10, 11, and 12) see a next-hop change.

   • Nodes 10, 11, and 12 are no longer downstream of node 9.

   • All nodes upstream of the removed link (in this case, nodes 1, 2, 7, and 6) see no route change.

   • Nodes 1', 2', and 7' are not using node 6 or 9 as parent nodes and are not impacted by the link removal event.

3. For each impacted node, the algorithm computes and activates a loop-free SR tunnel to the farthest node in the shortest path that did not see a next hop change, then uses the adjacency SIDs to reach destination node.

   • For the SR IS-IS tunnel of node 12, push the SID of node 7, then the SIDs of adjacencies 7-11 and 11-12.

   • This loop-free SR tunnel computation is similar to the P-Q set calculation in TI-LFA (see Topology-independent LFA), but the P node is defined as the farthest node in the shortest path to the destination in the new topology with no next-hop change.

   • The maximum number of labels used for the P-Q set is determined as follows:

     • If TI-LFA is enabled, use the configured value of the max-sr-frr-labels parameter.

     • If TI-LFA is disabled, use the value of 3, which matches the maximum value of TI-LFA max-sr-frr-labels parameter.

     In both cases, this value is passed to MPLS for checking against the max-sr-labels [additional-frr-labels] parameter for all configured SR-TE LSPs and SR-TE LSP templates.

   • The path to the P node may travel over an RSVP-TE LSP used as an IGP shortcut. In this case, the RSVP-TE LSP must have CSPF enabled. This is to avoid churn in IGP and to avoid micro-loops in the path of the RSVP control plane messages that are generated following the convergence of IGP, because the next hop in the ERO is looked up in the routing table.

   • When SR-LDP stitching is enabled and the path to the P node or the path between the P and Q nodes is partly on the LDP domain, no loop-free SR tunnel is programmed and IGP programs the new next hop or hops.

4. The same method (steps 2 and 3) applies to a metric increase of link 6-9 that causes traffic to move away from that link; for example, a metric change from 1 to 200.

IGP protocols traditionally compute best paths over the network based on the IGP metric assigned to the links. Many network deployments use RSVP-TE based or SR-based TE to enforce traffic over a path that is computed using different metrics or constraints than the shortest IGP path. The SR Flexible Algorithm (Flex-Algorithm) solution allows IGPs to compute constraint-based paths over the network. This section describes the use of SR prefix SIDs to compute a constraint topology and send packets along the constraint-based paths.

Using Flex-Algorithms can reduce the number of SR SIDs that must be imposed to send packets along a constrained path; this implementation simplifies the hardware capabilities of the head-end devices of SR routing tunnels.

The supported depth of the label stack is considered in an SR network when SR-TE tunnels or SR policies are deployed. In such tunnel policies, the packet source routing is based on the SR label stack pushed on the packet. The depth of the label stack that a router can push on a packet determines the complexity of the SR-TE tunnel construction that the router can support.

The SR Flex-Algorithm solution allows the creation of composed metrics based upon arbitrary parameters (for example, delay, link administrative group, cost, and so on) when using Flex-Algorithms. A network-wide set of composed topology constraints, known as the Flexible Algorithm Definition (FAD), creates an SR Flex-Algorithm topology. The IGP calculates the best path using constraint-based SPF and the FAD to create the best paths through the Flex-Algorithm topology.

With Flex-Algorithms, each Flex-Algorithm topology can send data flows along the most optimal constrained path toward its destination using a single label, which reduces the imposed label stack along.

Using this solution, backup path calculations (for example, Loop Free Alternate (LFA), Remote LFA (R-LFA) and Topology Independent LFA (TI-LFA)) can be constrained to the SR Flex-Algorithm topology during link failure.

Perform the following tasks to configure Flex-Algorithms using IS-IS.

1. Configuring the flexible algorithm definition

2. Configuring IS-IS Flex-Algorithm participation

3. Configuring IS-IS Flex-Algorithm prefix node SID

4. Verifying basic Flex-Algorithm behavior

Basic flexible algorithms configuration tasks for an IGP are described in Configuring IS-IS for flexible algorithms for SR-MPLS.

BGP-based network services (VPRN, EVPN and VPLS) can be automatically steered to a flexible algorithm using service-based import policies. To configure BGP automated steering, a policy-statement must first be defined. Within this policy-statement, all BGP criteria is identified to steer traffic towards certain prefixes towards a flexible algorithm topology. Often the BGP color community is used to identify which flex-algorithm is used for a BGP prefix, however, Nokia SR OS has the capability to match upon any existing policy-statement BGP attribute criteria.

The following example shows policy-statement configuration.

[ex: /configure router policy-options]
A:admin@node-2# info
policy-options {
        policy-statement "ExamplePolicy" {
            entry 10 {
                from {
                    color 128
                }
                action {
                    action-type accept
                    flex-algo 128
                }
            }
            default-action {
                action-type accept
                flex-algo 128
            }
        }
    }

A:node-2>config>router>policy-options# info
----------------------------------------------
            policy-statement "ExamplePolicy"
                entry 10
                    from
                        color 128
                    exit
                    action accept
                        flex-algo 128
                    exit
                exit
                default-action accept
                    flex-algo 128
                exit
            exit

[ex: /configure service]
A:admin@node-2# info
vpn-apply-import true
    ebgp-default-reject-policy {
        import false
        export false
    }
    import {
        policy ["ExamplePolicy"]
    }
    next-hop-resolution {
        shortcut-tunnel {
            family ipv4 {
                allow-flex-algo-fallback true
            }
        }
        labeled-routes {
            transport-tunnel {
                family vpn {
                    allow-flex-algo-fallback true
                }
                family label-ipv4 {
                    allow-flex-algo-fallback true
                }
                family label-ipv6 {
                    allow-flex-algo-fallback true
                }
            }
        }
    }

   

A:node-2>config>router>bgp# info
----------------------------------------------
            vpn-apply-import
            import "ExamplePolicy"
            next-hop-resolution
                shortcut-tunnel
                    family ipv4
                        allow-flex-algo-fallback
                        resolution disabled
                    exit
                exit
                labeled-routes
                    transport-tunnel
                        family vpn
                            resolution filter
                            allow-flex-algo-fallback
                        exit
                        family label-ipv4
                            resolution filter
                            allow-flex-algo-fallback
                        exit
                        family label-ipv6
                            resolution filter
                            allow-flex-algo-fallback
                        exit
                    exit
                exit
            exit
            no shutdown

[ex: /configure service]
A:admin@node-2# info
    epipe "3" {
        customer "1"
        bgp 1 {
            vsi-import ["ExamplePolicy"]
        }
    }
    vpls "2" {
        customer "1"
        bgp 1 {
            vsi-import ["ExamplePolicy"]
        }
    }
    vprn "1" {
        customer "1"
        bgp-ipvpn {
            mpls {
                vrf-import {
                    policy ["ExamplePolicy"]
                }
                auto-bind-tunnel {
                    allow-flex-algo-fallback true
                }
            }
        }
    }

A:node-2>config>service# info
----------------------------------------------
        customer 1 name "1" create
            description "Default customer"
        exit
        vprn 1 name "1" customer 1 create
            shutdown
            bgp-ipvpn
                mpls
                    shutdown
                    auto-bind-tunnel
                        allow-flex-algo-fallback
                    exit
                    vrf-import "ExamplePolicy"
                exit
            exit
        exit
        vpls 2 name "2" customer 1 create
            shutdown
            bgp
                vsi-import "ExamplePolicy"
            exit
            stp
                shutdown
            exit
        exit
        epipe 3 name "3" customer 1 create
            shutdown
            bgp
                vsi-import "ExamplePolicy"
            exit
        exit

In this mode of operation, the user configures the LSP name and the primary and (optionally) secondary path name with the path information in the referenced path name, entering a full or partial explicit path with all or some hops to the destination of the LSP. Each hop is specified as an address of a node or an address of the next hop of a TE link. Optionally, each hop may be specified as a SID value corresponding to the MPLS label to use on a specific hop. In this case, the whole path must consist of SIDs.

To configure a primary or secondary path to always use a specific link whenever it is up, the strict hop must be entered as an address corresponding to the next hop of an adjacency SID, or the path must consist of SID values for every hop. If the strict hop corresponds to a loopback address, it is translated into an adjacency SID, and therefore does not guarantee that the same specific TE link is chosen.

To use an SR-TE path that consists of unprotected adjacency SIDs, each hop of the path must be configured as a strict hop with the address matching the next hop of the adjacency SID. Protection on each of these adjacencies must be disabled. See SR-TE LSP path computation for more information.

MPLS assigns a tunnel ID to the SR-TE LSP and a path ID to each new instantiation of the primary path, as in an RSVP-TE LSP. These IDs are useful for representing the MBB path of the same SR-TE LSP, which need to coexist during the update of the primary path.

The router retains full control of the path of the LSP. CSPF is not supported and, as a result, the full or partially explicit path is instantiated as-is and no other constraint (such as SRLG, admin-group, hop count, or bandwidth) is checked. Only the LSP path label stack size is checked by MPLS against the maximum value configured for the LSP after the TE database (TE-DB) hop-to-label translation returns the label stack. See SR-TE LSP path computation for more information about this check.

The ingress LER performs the following steps to resolve the user-entered path before programming it in the datapath.

1. MPLS passes the path information to the TE-DB, which uses the hop-to-label translation or the full CSPF method to convert the list of hops into a label stack. The TE database returns the actual selected hop SIDs plus labels as well the configured path hop addresses which were used as the input for this conversion.

2. The ingress LER validates the first hop of the path to determine the next hop and the associated egress interfaces and programs the datapath according to the following conditions.

   • If the first hop corresponds to an adjacency SID (host address of the next hop on the subnet of the link), the adjacency SID label is not pushed. The ingress LER treats forwarding to a local interface as a push of an implicit-null label.

   • If the first hop is a node SID of a downstream router, the node SID label is pushed.

   In both cases, the SR-TE LSP tracks and rides the SR shortest path tunnel of the SID of the first hop.

3. In the case where the router is configured as a PCC and has a PCEP session to a PCE, the router sends a PCRpt message to update PCE with the state of UP and the RRO object for each LSP where the pce-report command is enabled. The PE router does not set the delegation control flag to keep LSP control. The state of the LSP is now synchronized between the router and the PCE.

In this mode of operation, the ingress LER uses PCEP to communicate with a PCE-based external TE controller (called the PCE). Acting as the PCC, the router instantiates a PCEP session to the PCE.

The following PCE control modes are supported:

• passive control mode

  In this mode, the user enables the path-computation-method pce option for one or more SR-TE LSPs. A PCE performs path computations at the request of the PCC.

• active control mode

  In this mode, the user enables the pce-control command for an LSP, which allows the PCE to perform both path computation and periodic reoptimization of the LSP path without an explicit request from the PCC.

For the PCC to communicate with a PCE about the management of the path of an SR-TE LSP, the router implements the extensions to PCEP in support of segment routing. This feature works with the Nokia stateful PCE, which is part of the NSP.

The following sequence describes configuring and programming a PCC-initiated SR-TE LSP when passive or active control is assigned to the PCE.

1. The SR-TE LSP configuration is created on the PE router using the CLI or OSS/SAM.

   The configuration dictates the PCE control mode: active (pce-control command enabled) or passive (path-computation-method pce enabled and pce-control disabled).

2. The PCC assigns a unique PLSP-ID to the LSP. The PLSP-ID identifies the LSP on a PCEP session and must remain constant during its lifetime. The PCC on the router tracks the association of {PLSP-ID, SRP-ID} to {Tunnel-ID, Path-ID} and uses the latter to communicate with MPLS about a specific path of the LSP.

3. The PE router does not validate the entered path. While the PCC can include the IRO objects for any loose or strict hop in the configured LSP path in the Path Computation Request (PCReq) message to the PCE, the PCE ignores them and computes the path with the other constraints, excepting the IRO.

4. The PE router sends a PCReq message to the PCE to request a path for the LSP and includes the LSP parameters in the METRIC object, the LSPA object, and the Bandwidth object. It also includes the LSP object with the assigned PLSP-ID. At this point, the PCC does not delegate control of the LSP to the PCE.

5. The PCE computes a new path, reserves the bandwidth, and returns the path in a Path Computation Reply (PCRep) message with the computed ERO in the ERO object. It also includes the LSP object with the unique PLSP-ID, the METRIC object with the computed metric value (if any), and the Bandwidth object.

   Note:

   For the PCE to use the SRLG path diversity and admin-group constraints in the path computation, the user must configure the SRLG and admin-group membership against the MPLS interface and verify that the traffic-engineering option is enabled in IGP. This causes IGP to flood the link SRLG and admin-group membership in its participating area and for the PCE to learn it in its TE-DB.

6. The PE router updates the Control Processor Module (CPM) and the datapath with the new path.

   Note:

   Up to step 6, the PCC and PCE are using passive stateful PCE procedures. The following steps synchronize the LSP database of the PCC and PCE for both PCE-computed and PCE-controlled LSPs. The steps also initiate the active PCE stateful procedures for the PCE-controlled LSP only.

7. The PE router sends a PCRpt message to update PCE with the state of UP and the RRO as confirmation, including the LSP object with the unique PLSP-ID. For a PCE-controlled LSP, the PE router also sets a delegation control flag to delegate control to the PCE. The state of the LSP is now synchronized between the router and the PCE.

8. Following a network event or reoptimization, the PCE computes a new path for a PCE-controlled LSP and returns it in a Path Computation Update (PCUpd) message with the new ERO. It includes the LSP object with the same unique PLSP-ID assigned by the PCC and the Stateful Request Parameter (SRP) object with a unique SRP-ID number to track error and state messages specific to this new path.

   Note: If the no pce-control command is performed while a PCUpdate MBB is in progress on the LSP, the router aborts and removes the information and state related to the in-progress PCUpdate MBB. As the LSP is no longer controlled by the PCE, the router may take further actions depending on the state of the LSP. For example, if the LSP is up, and has FRR active or pre-emption, then the router starts a GlobalRevert or pre-emption MBB. If the LSP is down, the router starts the retry-timer to trigger setup.

9. The PE router updates the CPM and the datapath with the new path.

10. The PE router sends a new PCRpt message to update the PCE with the state of UP and the RRO as confirmation. The state of the LSP is now synchronized between the router and the PCE.

11. If the user makes a configuration change to the PCE-computed or PCE-controlled LSP, MPLS requests PCC to first revoke delegation in a PCRpt message (PCE-controlled only). Next, MPLS and PCC follow steps 1 to 10 to convey the changed constraint to the PCE, which results in a new path programmed into the datapath, the LSP databases of the PCC and the PCE to be synchronized, and the delegation to be returned to the PCE.

    In the case of an SR-TE LSP, MBB is not supported. Therefore, the PCC takes down the LSP and sends a PCRpt message to the PCE with the Remove flag set to 1 before following the preceding configuration change procedure.

For an LSP with an active path, the following applies.

• If the path-computation-method pce option is enabled on a PCC-controlled LSP that has an active path, no action is performed until the router needs a path for the LSP following a network event of an LSP parameter change. At this point, the preceding procedure is followed.

• If the pce-control command is enabled on a PCC-controlled or PCE-computed LSP that has an active path, the PCC issues a PCRpt message to the PCE with the state of UP and the RRO of the active path. It sets the delegation control flag to delegate control to the PCE. The PCE keeps the active path of the LSP and does not update until the next network event or reoptimization. At this point, the preceding procedure is followed.

The PCE supports the computation of disjointed paths for two different LSPs originating or terminating on the same or different PE routers. To indicate this constraint to the PCE, the user must configure the PCE path profile ID and path group ID to which the LSP belongs. These parameters are passed transparently by the PCC to the PCE and are opaque data to the router. Use the path-profile profile-id [path-group group-id] CLI command to configure the path profile and path group.

The association of the optional path group ID allows the PCE to determine which profile ID this path group ID must be used with. One path group ID is allowed per profile ID. However, the user can run the path-profile command multiple times to enter the same path group ID with multiple profile IDs. A maximum of five entries of the path-profile command can be associated with the same LSP. See Path Computation Element Protocol (PCEP) for more information about the operation of the PCE path profile.

The following MPLS and TE database features extend CSPF support to SR-TE LSP:

• IPv4 SR-TE LSP

• local CSPF on both primary and secondary standby paths of an IPv4 SR-TE LSP

• local CSPF in LSP templates of types mesh-p2p-srte and one-hop-p2p-srte of SR-TE auto-LSP

• support path computation in single area OSPFv2 and IS-IS IGP instances

• computes full explicit TE paths using TE links as hops and returning a list of SIDs consisting of adjacency SIDs and parallel adjacency set SIDs. SIDs of a non-parallel adjacency set are not used in CSPF. The details of the CSPF path computation are provided in SR-TE specific TE-DB changes. Loose-hop paths, using a combination of node SID and adjacency SID, are not required.

• use random path selection in the presence of ECMP paths that satisfy the LSP and path constraints. Least-fill path selection is not required.

• provide an option to reduce or compress the label stack such that the adjacency SIDs corresponding to a segment of the explicit path are replaced with a node SID whenever the constraints of the path are met by all the ECMP paths to that node SID. The details of the label reduction are provided in SR-TE LSP path label stack reduction.

• use legacy TE link attributes as in RSVP-TE LSP CSPF

• Uses timer re-optimization of all paths of the SR-TE LSP that are in the operational up state. This differs from RSVP-TE LSP resignal timer feature which re-optimizes the active path of the LSP only.

  MPLS provides the current path of the SR-TE LSP and TE-DB updates the total IGP or TE metric of the path, checking the validity of the hops and labels as per current TE-DB link information. CSPF then calculates a new path and provides both the new and metric updated current path back to MPLS. MPLS programs the new path only if the total metric of the new computed path is different than the updated metric of the current path, or if one or more hops or labels of the current path are invalid. Otherwise, the current path is considered one of the most optimal ECMP paths and is not updated in the data path.

  Timer resignal applies only to the CSPF computation method and not to the ip-to-label computation method.

• use manual re-optimization of a path of the SR-TE LSP. In this case, the new computed path is always programmed even if the metric or SID list is the same.

• Supports ad-hoc re-optimization. This SR-TE LSP feature for SR-TE LSP triggers the ad-hoc resignaling of all SR-TE LSPs if one or more IGP link down events are received in TE-DB.

  After the re-optimization is triggered, the behavior is the same as the timer-based resignal or the delay option of the manual resignal. MPLS forces the expiry of the resignal timer and asks TE-DB to re-evaluate the active paths of all SR-TE LSPs. The re-evaluation consists of updating the total IGP or TE metric of the current path, checking the validity of the hops and labels, and computing a new CSPF for each SR-TE LSP. MPLS programs the new path only if the total metric of the new computed path is different than the updated metric of the current path, or if one or more hops or labels of the current path are invalid. Otherwise, the current path is considered one of the most optimal ECMP paths and is not updated in the data path.

• support unnumbered interfaces in the path computation. There is no support for configuring an unnumbered interface as a hop in the path of the LSP. The path can be empty or include hops with the address of a system or loopback interface, but path computation can return a path that uses TE links corresponding to unnumbered interfaces.

• support admin-group, hop-count, IGP metric, and TE-metric constraints

• Bandwidth constraint is not supported because SR-TE LSP does not have an LSR state to book bandwidth. The bandwidth parameter, when enabled on the LSP path, has no impact on local CSPF path calculation. However, the bandwidth parameter is passed to PCE when it is the selected path computation method. PCE reserves bandwidth for the SR-TE LSP path accordingly.

When the traffic-engineering command is enabled in an OSPFv2 instance, only local and remote TE-enabled links are added into the TE-DB. A TE-link is a link that has one or more TE attributes added to it in the MPLS interface context. Link TE attributes are TE metric, bandwidth, and membership in an SRLG or an Admin-Group.

To allow the SR-TE LSP path computation to use SR-enabled links that do not have TE attributes, the following changes are made:

• OSPFv2 passes all links, whether they are TE-enabled or SR-enabled, to the TE-DB, as currently performed by IS-IS.

• TE-DB relaxes the link back-check when performing a CSPF calculation to ensure that there is at least one link from the remote router to the local router. Because OSPFv2 advertises the remote link IP address or remote link identifier only when a link is TE-enabled, the strict check about the reverse direction of a TE-link cannot be performed if the link is SR-enabled but not TE-enabled.

As a consequence of this implementation, CSPF can compute an SR-TE LSP with SR-enabled links that do not have TE attributes. This means that if the user admin shuts down an interface in MPLS, an SR-TE LSP path that uses this interface does not go operationally down.

The local CSPF for an SR-TE LSP is performed in two phases. Phase 1 computes a fully explicit path with all TE links to the destination specified, as in the case of an RSVP-TE LSP. If the user has enabled label stack reduction or compression for this LSP, Phase 2 is applied to reduce the label stack so that adjacency SIDs corresponding to a segment of the explicit path are replaced with a node SID whenever the constraints of the path are met by all the ECMP paths to that node SID. The details of the label reduction are provided in SR-TE LSP path label stack reduction.

The CSPF computation algorithm for the fully explicit path in Phase 1 remains mostly unchanged from its behavior in RSVP-TE LSP.

The meaning of a strict and loose hop in the path of the LSP is the same as in CSPF for RSVP-TE LSP. A strict hop means that the path from the previous hop must be a direct link. A loose hop means the path from the previous hop can traverse intermediate routers.

A loose hop may be represented by a set of back-to-back adjacency SIDs if not all paths to the node SID of that loose hop satisfy the path TE constraints. This is different from the IP-to-label path computation method where a loose hop always matches a node SID because no TE constraints are checked in the path to that loose hop.

When the label stack of the path is reduced or compressed, a strict hop may be represented by a node SID if all the links from the previous hop satisfy the path TE constraints. This is different from the IP-to-label path computation method where a strict hop always matches an adjacency SID or a parallel adjacency set SID.

The first phase of CSPF returns a full explicit path with each TE link specified all the way to the destination. The label stack may contain protected adjacency SIDs, unprotected adjacency SIDs, and adjacency set SIDs. The user can configure the type of adjacency protection for the SR-TE LSP using a CLI command as described in SR-TE LSP path protection.

SR OS does not support the origination of a global adjacency SID. If received from a third-party router implementation, it is added into the TE database but is not used in any CSPF path computation.

Whenever possible, an LFA next hop protects each path locally along the network. The protection of a SID node reuses the base LFA, TI-LFA, and remote LFA features introduced with segment routing shortest path tunnels. To augment the protection level, the SR OS adds the protection of an adjacency SID in the specific context of an SR-TE LSP. You must enable the loopfree [remote-lfa] [ti-lfa] command in IS-IS or OSPF.

• MD-CLI

  configure router isis loopfree-alternate remote-lfa
  configure router isis loopfree-alternate ti-lfa
  configure router ospf loopfree-alternate remote-lfa
  configure router ospf loopfree-alternate ti-lfa

• classic CLI

  configure router isis loopfree-alternates remote-lfa
  configure router isis loopfree-alternates ti-lfa
  configure router ospf loopfree-alternates remote-lfa
  configure router ospf loopfree-alternates ti-lfa

This behavior is already supported in the SR shortest path tunnel feature at both LER and LSR. An SR-TE LSP that transits at an LSR and that matches the ILM of a downstream SID node automatically takes advantage of this protection, when enabled. If required, SID node protection can be disabled under the IGP instance by excluding the prefix of the SID node from LFA.

This section provides a brief introduction to end to end protection for SR-TE LSPs. See Seamless BFD for SR-TE LSPs for more detailed description of protection switching using Seamless BFD and a configured failure-action.

End-to-end protection for SR-TE LSPs is provided using secondary or standby paths. Standby paths are permanently programmed in the datapath, whereas secondary paths are only programmed when they are activated. S-BFD is used to provide end-to-end connectivity checking. The failure-action failover-or-down command under the bfd context of the LSP is used to configure a switchover from the currently active path to an available standby or secondary path if the S-BFD session fails on the currently active path. If S-BFD is not configured, the router that is local to a segment can only detect failures of the top SID for that segment. End-to-end protection with S-BFD can be combined with local protection, but it is recommended that the S-BFD control packet timers be set to 1 second or more to allow sufficient time for any local protection action for a specific segment to complete without triggering S-BFD to go down on the end-to-end LSP path.

To prevent failure between the paths of an SR-TE LSP, that is to avoid, for example, a failure of a primary path that affects its standby backup path, then disjoint paths should be configured or the srlg command configured on the secondary paths.

As with RSVP-TE LSPs, SR-TE standby paths support the configuration of a path preference. This value is used to select the standby path to be used when more than one available path exists.

See Seamless BFD for SR-TE LSPs for more information about end-to-end protection of SR-TE LSPs with S-BFD.

A minimum control packet timer transmit interval of 10 ms can be configured. To maximize the reliability of S-BFD connectivity checking in scaled scenarios with short timers, cases where BFD can go down because of normal changes to the next hop of an LSP path at the head end must be avoided. Nokia recommends that LFA should not be configured at the head-end LER when S-BFD is used with sub-second timers. When the LFA is not configured, protection of the SR-TE LSP is still provided end-to-end by the combination of S-BFD connectivity checking and primary or secondary path protection.

Similar to the case of LDP and RSVP, S-BFD uses a single path for a loose hop; multiple S-BFD sessions for each of the ECMP paths or spraying of S-BFD packets across the paths is not supported. S-BFD is not down until all the ECMP paths of the loose hop go down.

The MPLS module assigns the maximum LSP metric value (16777215) to a TE LSP when the local router provides the hop-to-label translation for its path. If a TE LSP uses the local CSPF (path-computation-method local-cspf option enabled) or PCE for path computation (path-computation-method pce option enabled) or delegates control to the PCE (pce-control enabled), the PCE returns the computed LSP IGP or TE metric in the PCReq and PCUpd messages.

In all cases, using the config router mpls lsp metric command to configure an admin metric overrides the returned value.

The MTU computations are as follows:

• The MTU setting of an SR-TE LSP is derived from the MTU of the outgoing SR shortest path tunnel it is riding, adjusted with the size of the super NHLFE label stack size.

  The following calculation is used:

  SR_Tunnel_MTU = MIN {Cfg_SR_MTU, IGP_Tunnel_MTU- (1 + frr-overhead) × 4}

  where:

  • Cfg_SR_MTU is the MTU configured for all SR tunnels within a specific IGP instance using the config router ospf segment-routing tunnel-mtu or config router isis segment-routing tunnel-mtu command. If no value is configured, the SR tunnel MTU is fully determined by the IGP interface calculation, described in the next bullet point.

  • IGP_Tunnel_MTU is the minimum of the IS-IS or OSPF interface MTU among all the ECMP paths or among the primary and LFA backup paths of the SR tunnel.

  • frr-overhead is set to:

    • value of ti-lfa [max-sr-frr-labels labels] if loopfree-alternates and ti-lfa are enabled in this IGP instance

    • 1 if loopfree-alternates and remote-lfa are enabled but ti-lfa is disabled in this IGP instance

    • 0 for all other cases

  This calculation is performed by IGP and passed to the SR module each time there is a change because of an updated resolution of the node SID.

  The SR OS also provides the MTU for the adjacency SID tunnel because it is needed in an SR-TE LSP if the first hop in the ERO is an adjacency SID. In this case, the calculation for SR_Tunnel_MTU, initially introduced for a node SID tunnel, is applied to derive the MTU of the adjacency SID tunnel.

• The MTU of the SR-TE LSP is derived as follows:

  SRTE_LSP_MTU= SR_Tunnel_MTU - numLabels × 4

  where:

  • SR_Tunnel_MTU is the MTU SR tunnel shortest path that the SR-TE LSP is riding. The formula for this is provided in the previous bullet point.

  • numLabels is the number of labels found in the super NHLFE of the SR-TE LSP. At the LER, the super NHLFE points to the SR tunnel NHLFE, which itself has a primary and a backup NHLFE.

  This calculation is performed by the SR module and is updated each time the SR-TE LSP path changes or the SR tunnel it is riding is updated.

  Note:

  The above calculated SR-TE LSP MTU is used for the determination of an SDP MTU and for checking the Layer 2 service MTU. In the case of fragmentation of IP packets forwarded in GRT or in a VPRN over an SR-TE LSP, the IOM always deducts the worst-case MTU (12 labels) from the outgoing interface MTU when deciding whether to fragment the packet. In this case, the preceding formula is not used.

The auto-lsp command binds an LSP template of type mesh-p2p-srte with one or more prefix lists. When the TE database discovers a router that has a router ID matching an entry in the prefix list, it triggers MPLS to instantiate an SR-TE LSP to that router using the LSP parameters in the LSP template.

The prefix match can be exact or longest. Prefixes in the prefix list that do not correspond to a router ID of a destination node cannot match.

The path of the LSP is that of the default path name specified in the LSP template. The hop-to-label translation tool or the local CSPF determines the node SID and adjacency SID corresponding to each loose and strict hop in the default path definition, respectively.

The LSP has an auto-generated name using the following structure:

TemplateName-DestIpv4Address-TunnelId

where:

• TemplateName is the name of the template

• DestIpv4Address is the address of the destination of the auto-created LSP

• TunnelId is the TTM tunnel ID

In SR OS, an SR-TE LSP uses three different identifiers:

• LSP Index is used for indexing the LSP in the MIB table shared with RSVP-TE LSP. The LSP Index range is as follows:

  • provisioned SR-TE LSP: 65536 to 81920

  • SR-TE auto-LSP: 81921 to 131070

• LSP Tunnel ID is used in the interaction with the PCC or PCE. Range: 1 to 65536

• TTM Tunnel ID is the tunnel ID service, shortcut, and steering applications use to bind to the LSP. Range: 655362 to 720897

The path name is the default path specified in the LSP template.

Although the provisioning model and CLI syntax differ from that of a mesh LSP by the absence of a prefix list, the actual behavior is quite different. When the one-hop-p2p command is executed, the TE database keeps track of each TE link that comes up to a directly connected IGP neighbor. It then instructs the MPLS to instantiate an SR-TE LSP with the following parameters:

• the source address of the local router

• an outgoing interface matching the interface index of the TE link

• a destination address matching the router ID of the neighbor on the TE link

The hop-to-label translation or the local CSPF returns the SID for the adjacency to the remote address of the neighbor on this link. Therefore, the auto-lsp command binding an LSP template of type one-hop-p2p-srte with the one-hop option results in one SR-TE LSP instantiated to the IGP neighbor for each adjacency over any interface.

Because the local router installs the adjacency SID to a link regardless of whether the neighbor is SR-capable, the TE-DB finds the adjacency SID and a one-hop SR-TE LSP can still come up to such a neighbor. However, remote LFA using the neighbor’s node SID does not protect the adjacency SID or the one-hop SR-TE LSP because the node SID is not advertised by the neighbor.

The LSP has an auto-generated name using the following structure:

TemplateName-DestIpv4Address-TunnelId

where:

• TemplateName = the name of the template

• DestIpv4Address = the address of the destination of the auto-created LSP

• TunnelId = the TTM tunnel ID

The path name is the default path specified in the LSP template.

A template-based SR-TE auto-LSP, with the exception of on-demand SR-TE LSPs, can only be operated as a PCC-controlled LSP. It can, however, be reported to the PCE using the pce-report command. It cannot be operated as a PCE-computed or PCE-controlled LSP. This is the same interaction with PCEP as that of a template-based RSVP-TE LSP.

On-demand SR-TE LSPs can be reported to the PCE and operated as PCE-computed or PCE-controlled LSPs.

The auto LSP can be delegated to a PCE in the configuration of the SR-TE on-demand P2P LSP template, using the pce-control or path-computation-method pce commands.

Fallback to local CSPF or hop-to-label translation is also supported for SR-TE on-demand P2P LSPs in case the PCE becomes unreachable.

In general, an on-demand SR-TE auto-LSP that is PCE controlled or has path computation method PCE is treated as any other PCC-initiated LSP by PCC. Path profile and path group are also supported. Path profile and path group IDs are passed to the PCC in the same way as for a PCC-initiated SR-TE LSP.

If a packet forwarded in a service results in the net label stack size being pushed on the packet to exceed the maximum label stack supported by the router, the packet is dropped on the egress. Each service and shortcut application on the router performs a check of the resulting net label stack after pushing all the labels required for forwarding the packet in that context.

To that effect, the MPLS module populates each SR-TE LSP in the TTM with the maximum transport label stack size, which consists of the sum of the values in max-sr-labels label-stack-size and additional-frr-labels labels.

Each service or shortcut application then adds the additional, context-specific labels such as service label, entropy or hash label, and control-word, required to forward the packet in that context and check that the resulting net label stack size does not exceed the maximum label stack supported by the router.

If the check succeeds, the service binds or the prefix resolves to the SR-TE LSP.

If the check fails, the service does not bind to this SR-TE LSP. Instead, the service either finds another SR-TE LSP or another tunnel type to bind to, if the user has configured other tunnel types. Otherwise, the service goes down. If the service uses an SDP with one or more SR-TE LSP names, the spoke SDP bound to this SDP remains operationally down as long as at least one SR-TE LSP fails the check. In this case, a new spoke SDP flag is displayed in the show output of the service: labelStackLimitExceeded. Similarly, the prefix is not resolved to the SR-TE LSP and is either resolved to another SR-TE LSP or another tunnel type, or becomes unresolved.

The value of additional-frr-labels labels is checked against the maximum value across all IGP instances of the frr-overhead parameter. This parameter is computed within a specific IGP instance. The following table lists the parameter values.

If the user configures or changes the configuration of the additional-frr-labels command, MPLS ensures that the new value accommodates the frr-overhead value across all IGP instances. Consider the sequence in the following example:

1. The user configures the config router isis loopfree-alternate remote-lfa command.

2. The user creates an SR-TE LSP or changes the configuration of an existing one, as follows:

   mpls>lsp>max-sr-labels 10 additional-frr-labels 0.

If the check is successful, MPLS adds max-sr-labels and additional-frr-labels and checks that the value is less than or equal to the maximum label stack supported by the router. MPLS then populates the value of {max-sr-labels + additional-frr-labels}, along with tunnel information in TTM, and also passes max-sr-labels to the PCEP module.

Conversely, if the user attempts a configuration change that may result in a change to the computed frr-overhead value, IGP checks that all SR-TE LSPs can properly account for the overhead; if the check fails, the change is rejected. On the IGP, enabling the remote-lfa command may cause the frr-overhead value to change. Consider the sequence in the following example:

1. An MPLS LSP is administratively enabled and has mpls>lsp>max-sr-labels 10 additional-frr-overhead 0 configured.

2. The current configuration in IS-IS has the loopfree-alternate command disabled.

3. The user attempts to configure isis loopfree-alternate remote-lfa. This changes the frr-overhead value to 1.

   This configuration change is blocked.

As described in Datapath support, the egress IOM can push a maximum of 12 labels; however, this number may be reduced if other fields are pushed into the packets. For example, for a VPRN service, the ingress LER can send an IP VPN packet with 12 labels in the stack, including one service label, one label for OAM, and 10 transport labels. However, if entropy is configured, the number of transport labels is reduced by two (Entropy Label (EL) and Entropy Label Indicator (ELI)). Similarly, for EVPN services, the egress IOM may push specific fields that reduce the total number of supported transport labels.

To avoid silent packet drops in cases where the egress IOM cannot push the required number of labels, SR OS implements a set of procedures that prevent the system from sending packets if it is determined that the SR-TE label stack to be pushed exceeds the number of bytes that the egress IOM can put on the wire.

The following table describes the label stack egress IOM restrictions on FP-based hardware for IPVPN and EVPN services.

The total number of labels configured in the max-sr-labels label-stack-size [additional-frr-labels labels] command must not exceed the labels indicated in the Maximum available transport labels without options and Maximum available transport labels with options rows in the preceding table. If the configured LSP labels exceed the available labels listed in the preceding table, the BGP route next hop for the LSP is not resolved and the system does not even try to send packets to that LSP.

For example, for a VPRN service with EVPN-IFL where the user configures entropy-label, the maximum available transport labels is eight. If an IP Prefix route for next-hop X is received for the service and the SR-TE LSP to-X is the best tunnel to reach X, the system checks that (max-sr-labels + additional-frr-labels) is less than or equal to eight. Otherwise, the IP Prefix route is not resolved.

The same control plane check is performed for other service types, including IP shortcuts, spoke SDPs on IP interfaces, spoke SDPs on Epipes, VPLS, B-VPLS, R-VPLS, and R-VPLS in I-VPLS or PW-SAP. In all cases, the spoke SDP is brought down if the configured (max-sr-labels + additional-frr-labels) is greater than the maximum available transport labels. The following table indicates the maximum available transport labels for IP shortcuts and spoke SDP services.

In general, the labels shown in Label stack egress IOM restrictions on FP-based hardware for IPVPN and EVPN services and Maximum available transport labels for IP shortcuts and spoke SDP services are valid for network ports that are null or dot1q encapsulated. For QinQ network ports, the available labels are deducted by one.

SR OS supports a dynamic egress label limit configuration mode that extends the number of allowed MPLS labels in the egress label stack by not counting specific labels in the BGP next-hop resolution check when those labels are not used. The configuration mode exists in EVPN services configured on Epipe, VPLS, and VPRN (EVPN-IFL), and in IP-VPN services.

• Classic CLI

  
  +-- dynamic-egress-label-limit
      no dynamic-egress-label-limit
  

• MD CLI

  
  +-- dynamic-egress-label-limit <boolean>
      

When the dynamic-egress-label-limit command is configured, the always-computed labels are no longer considered when resolving the next hop of the route. As a result, the following rules apply to the specified services:

• For VPRN services, the OAM label is never computed. This is true whether the BGP next hop is being resolved over an auto-bind tunnel or an SDP in the vprn>spoke-sdp context. The dynamic mode is supported for EVPN-IFL and IP-VPN families.
• For EVPN (Epipe or VPLS) services with dynamic-egress-label-limit configured, the control word (CW) and ESI label are only computed if they are used.
  • In the case of the CW, the system reduces the egress label limit by one label when the CW is configured in the service. The CW is always accounted when the dynamic-egress-label-limit command is not configured.
  • When the dynamic-egress-label-limit command is configured, the ESI label is not accounted for in Epipes or VPLS services without an ES; however, the ESI label is always accounted if dynamic-egress-label-limit is not configured.

When no dynamic-egress-label-limit is configured, the behavior follows the procedures described in Control plane handling of egress label stack limitations.

In summary, when the dynamic-egress-label-limit is configured, the total amount of labels (X) configured in X= (max-sr-labels Y + additional-frr-labels Z) can go higher for EVPN and IP-VPN services.

The following table summarizes the required behavior.

R-VPLS and B-VPLS services, with EVPN-MPLS enabled, also support the dynamic-egress-label-limit command when dynamic-egress-label-limit is configured, the CW is accounted for only if the control-word command is added.

• In R-VPLS services, the ESI label is not accounted because the routed encapsulation is always larger (and either ESI label for bridged traffic, or routed traffic without ESI label is transmitted by the R-VPLS).
• In B-VPLS services, only the CW applies; there is no ESI label.

To enable IPv6 TE on the router, the IPv6 TE router ID must have a valid IPv6 address. Use the following CLI command to configure the IPv6 TE router ID:

configure>router>ipv6-te-router-id interface interface-name

The IPv6 TE router ID is a mandatory parameter that uniquely identifies the router as being IPv6 TE capable to other routers in an IGP TE domain. IS-IS advertises this information using the IPv6 TE Router ID TLV as described in TE attributes supported in IGP and BGP-LS.

When the command is not configured or the no form of the command is configured, the value of the IPv6 TE router ID reverts to the preferred primary global unicast address of the system interface. The user can also explicitly enter the name of the system interface to achieve the same outcome.

In addition, the user can specify a different interface and the preferred primary global unicast address of that interface is used instead. Only the system or a loopback interface is allowed because the TE router ID must use the address of a stable interface.

This address must be reachable from other routers in a TE domain and the associated interface must be added to IGP for reachability. Otherwise, IS-IS withdraws the advertisement of the IPv6 TE router ID TLV.

When configuring a new interface name for the IPv6 TE router ID, or when the same interface begins using a new preferred primary global unicast address, IS-IS immediately floods the new value.

If the referenced system is shut down or the referenced loopback interface is deleted or is shut down, or the last IPv6 address on the interface is removed, IS-IS withdraws the advertisement of the IPv6 TE router ID TLV.

To enable the advertisement of additional link IPv6 and TE parameters, use the following traffic-engineering-options CLI syntax.

configure
     router
          ipv6-te-router-id interface interface-name
          no ipv6-te-router-id
          [no] isis [instance]
               traffic-engineering
               no traffic-engineering
               traffic-engineering-options
               no traffic-engineering-options
                    ipv6
                    no ipv6  
                    application-link-attributes
                    no application-link-attributes
                         legacy
                         no legacy

The traffic-engineering command is the main CLI command used to enable TE in an IS-IS instance. This command enables the advertisement of the IPv4 and TE link parameters using the legacy TE encoding, in accordance with RFC 5305. These parameters are used in IPv4 RSVP-TE and IPv4 SR-TE.

When the ipv6 command under the traffic-engineering-options context is enabled, the traffic engineering behavior with IPv6 TE links is enabled. This IS-IS instance automatically advertises the new RFC 6119 IPv6 and TE TLVs and sub-TLVs, as described in TE attributes supported in IGP and BGP-LS.

The application-link-attributes context allows the advertisement of the TE attributes of each link on a per-application basis. Two applications are supported in SR OS: RSVP-TE and SR-TE. The legacy mode of advertising TE attributes that is used in RSVP-TE is supported. Use the no legacy command to disable the legacy mode and also enable the per-application TE attribute advertisement for RSVP-TE.

See IS-IS IPv4/IPv6 SR-TE and IPv4 RSVP-TE feature behavior for more information about feature behavior and the interaction of the preceding CLI commands.

The SR-TE LSP configuration can accept an IPv6 address in the to and from parameters.

In addition, the MPLS path configuration can accept a hop index with an IPv6 address. The IPv6 address used in the from and to commands in the IPv6 SR-TE LSP, as well as the address used in the hop command of the path used with the IPv6 SR-TE LSP must correspond to the preferred primary global unicast IPv6 address of a network interface or a loopback interface of the corresponding LER or LSR router. The IPv6 address can also be set to the system interface IPv6 address. Failure to follow the preceding IPv6 address guidelines for the from, to, and hop commands causes path computation to fail with failure code ‟noCspfRouteToDestination".

A link-local IPv6 address of a network interface is also not allowed in the hop command of the path used with the IPv6 SR-TE LSP.

All other MPLS-level, LSP-level, and primary or secondary path-level configuration parameters available for an IPv4 SR-TE LSP are supported.

IS-IS control plane extensions add support for the following RFC 6119 TLVs in IS-IS advertisements and TE-DB.

• IPv6 interface Address TLV (ISIS_TLV_IPv6_IFACE_ADDR 0xe8)

• IPv6 Neighbor Address sub-TLV (ISIS_SUB_TLV_NBR_IPADDR6 0x0d)

• IPv6 Global Interface Address TLV (only used by ISIS in IIH PDU)

• IPv6 TE Router ID TLV

• IPv6 SRLG TLV

IS-IS also supports the use of the Application Specific Link Attributes (ASLA) sub-TLV to advertise the protocol enabled on a specific TE-link (SR-TE, RSVP-TE, or both), as defined in draft-ietf-isis-te-app. The advertising router sends potentially different link TE attributes for RSVP-TE and SR-TE applications, and the router receiving the link TE attributes can identify the application that is enabled on the advertising router. For backward compatibility, the router continues to support the legacy mode of advertising link TE attributes, as recommended in RFC 5305, but the user can disable this mode.

See IS-IS IPv4/IPv6 SR-TE and IPv4 RSVP-TE feature behavior for more information about the behavior of the per-application TE capability.

These TLVs and sub-TLVs are advertised in IS-IS and added into the local TE-DB when received from IS-IS neighbors. In addition, if the database-export command is enabled in this ISIS instance, this information is also added in the Enhanced TE-DB.

The following enhancements are added to support advertisement of TE parameters in BGP-LS routes over an IPv4 or IPv6 transport.

• Importing IPv6 TE link TLVs from a local Enhanced TE-DB into the local BGP process for exporting to other BGP peers using the BGP-LS route family that is enabled on an IPv4 or an IPv6 transport BGP session

  • RFC 6119 IPv6 and TE TLVs and sub-TLVs are carried in the BGP-LS link NLRI, as per RFC 7752.

  • When the link TE attributes are advertised by IS-IS on a per-application basis using the ASLA TLV (ISIS TLV Type 16), they are carried in the new BGP-LS ASLA TLV (TLV Type TBD), in accordance with draft-ietf-idr-bgp-ls-app-specific-attr.

  • When a TE attribute of a link is advertised for both RSVP-TE and SRTE applications, there are three methods IS-IS can use. Each method results in a specific way the BGP-LS originator carries this information. These methods are summarized here, but more information is provided in IS-IS IPv4/IPv6 SR-TE and IPv4 RSVP-TE feature behavior.

    • In the legacy mode of operation, all TE attributes are carried in the legacy IS-IS TE TLVs and the corresponding BGP-LS link attributes TLVs, as listed in Legacy link TE TLV support in TE-DB and BGP-LS.

    • In the legacy with application indication mode of operation, IGP and BGP-LS advertises the legacy TE attribute TLVs, and also advertises the ASLA TLV with the Legacy (L) flag set and the RSVP-TE and SR-TE application flags set. No TE sub-sub-TLVs are advertised within the ASLA TLV.

      The legacy with application indication mode is intended for cases where link TE attributes are common to RSVP-TE and SR-TE applications and have the same value, but the user wants to indicate on a per-link basis which application is enabled.

    • In the application-specific mode of operation, the TE attribute TLVs are sent as sub-sub-TLVs within the ASLA TLV. Common attributes to RSVP-TE and SR-TE applications have the main TLV L-flag cleared and the RSVP-TE and SR-TE application flags set. Any attribute that is specific to an application (RSVP-TE or SR-TE) is advertised in a separate ASLA TLV with the main TLV L-flag cleared and the specific application (RSVP-TE or SR-TE) flags set.

      The application-specific mode of operation is intended for future cases where TE attributes may have different values in RSVP-TE and SR-TE applications or are specific to one application (for example, RSVP-TE uses the Unreserved Bandwidth and Max Reservable Bandwidth attributes).

• Exporting of any IPv6 and TE link TLVs that have been received from a BGP peer from the local BGP process to the local Enhanced TE-DB via a BGP-LS route family that is enabled on an IPv4 or IPv6 transport BGP session

• Exporting of IPv6 and TE link TLVs from local Enhanced TE-DB to NSP via the CPROTO channel on the VSR-NRC

The TE feature in IS-IS allows the advertising router to indicate to other routers in the TE domain which applications the advertising router has enabled: RSVP-TE, SR-TE, or both. As a result, a receiving router can safely prune links that are not enabled in one of the applications from the topology when computing a CSPF path in that application.

TE behavior consists of the following steps.

1. A valid IPv6 address value must exist for the system or loopback interface assigned to the ipv6-te-router-id command. The IPv6 address value can be either the preferred primary global unicast address of the system interface (default value) or that of a loopback interface (user-configured value).

   The IPv6 TE router ID is mandatory for enabling IPv6 TE and enabling the router to be uniquely identified by other routers in an IGP TE domain as being IPv6 TE capable. If a valid value does not exist, then the IPv6 and TE TLVs described in IS-IS, BGP-LS, and TE database extensions are not advertised.

2. The traffic-engineering command enables the existing traffic engineering behavior for IPv4 RSVP-TE and IPv4 SR-TE. Enable the rsvp context on the router and enable rsvp on the interfaces to have IS-IS begin advertising TE attributes in the legacy TLVs. By default, the rsvp context is enabled as soon as the mpls context is enabled on the interface. If the ipv6 command is also enabled, then the RFC 6119 IPv6 and TE link TLVs described above are advertised such that a router receiving these advertisements can compute paths for IPv6 SR-TE LSP in addition to paths for IPv4 RSVP-TE LSP and IPv4 SR-TE LSP. The receiving node cannot determine if IPv4 RSVP-TE, IPv4 SR-TE, or IPv6 SR-TE applications are enabled on the other routers. Legacy TE routers must assume that RSVP-TE is enabled on those remote TE links it received advertisements for.

3. When the ipv6 command is enabled, IS-IS automatically begins advertising the RFC 6119 TLVs and sub-TLVs: the IPv6 TE router ID TLV, the IPv6 interface Address sub-TLV and Neighbor Address sub-TLV, or the Link-Local Interface Identifiers sub-TLV if the interface has no global unicast IPv6 address. The TLVs and sub-TLVs are advertised regardless of whether TE attributes are added to the interface in the mpls context. The advertisement of these TLVs is only performed when the ipv6 command is enabled and ipv6-routing is enabled in this IS-IS instance and ipv6-te-router-id has a valid IPv6 address.

   A network IP interface is advertised with the Link-Local Interface Identifiers sub-TLV if the network IP interface meets the following conditions:

   • network IP interface has a link-local IPv6 address and no global unicast IPv6 address on the interface ipv6 context

   • network IP interface has no IPv4 address (and may or may not have the unnumbered option enabled on the interface ipv4 context)

4. The application-link-attributes command enables the ability to send the link TE attributes on a per-application basis and explicitly conveys that RSVP-TE or SR-TE is enabled on that link on the advertising router.

   Three modes of operation are allowed by the application-link-attributes command.

   • Legacy mode
   • Legacy mode with application indication
   • Application-specific mode

The following table summarizes the IS-IS link TE parameter advertisement details for the three modes of operation of the IS-IS advertisement.

 TE IS Nbrs   :                      
    Nbr   : Dut-A.00                            
    Default Metric  : 10
    Sub TLV Len     : 124
    IF Addr   : 10.10.2.3
    IPv6 Addr : 3ffe::10:10:2:3
    Nbr IP    : 10.10.2.1
    Nbr IPv6  : 3ffe::10:10:2:1
    MaxLink BW: 100000 kbps
    Resvble BW: 500000 kbps 
    Unresvd BW: 
        BW[0] : 500000 kbps
        BW[1] : 500000 kbps
        BW[2] : 500000 kbps
        BW[3] : 500000 kbps
        BW[4] : 500000 kbps
        BW[5] : 500000 kbps
        BW[6] : 500000 kbps
        BW[7] : 500000 kbps
    Admin Grp : 0x1
    TE Metric : 123
    TE APP LINK ATTR    :
         SABML-flags:Legacy SABM-flags:RSVP-TE SR-TE
    Adj-SID: Flags:v4VL Weight:0 Label:524287
    Adj-SID: Flags:v6BVL Weight:0 Label:524284 
    TE SRLGs     :
       SRLGs : Dut-A.00
       Lcl Addr  : 10.10.2.3
       Rem Addr  : 10.10.2.1
       Num SRLGs       : 1
              1003
    TE APP SRLGs     :
        Nbr : Dut-A.00
        SABML-flags:Legacy SABM-flags: SR-TE
        IF Addr   : 10.10.2.3
        Nbr IP    : 10.10.2.1

Application-specific mode

To use legacy mode with application indication, disable the legacy command in the configure router isis traffic-engineering-options application-link-attributes context.

The application-specific mode of operation is intended for future use cases where TE attributes may have different values in RSVP-TE and SR-TE applications (this capability is not supported in SR OS) or are specific to one application (for example, RSVP-TE uses the Unreserved Bandwidth and Max Reservable Bandwidth attributes).

IS-IS advertises the TE attributes that are common to RSVP-TE and SR-TE applications in the sub-sub-TLVs of the new ASLA sub-TLV. IS-IS also advertises the link SRLG values in the Application-Specific SRLG TLV. In both cases, the application flags for RSVP-TE and SR-TE are also set in the sub-TLV.

IS-IS advertises the TE attributes that are specific to the RSVP-TE application separately in the sub-sub-TLVs of the new application attribute sub-TLV. The application flag for RSVP-TE is also set in the sub-TLV.

SR OS does not support configuring and advertising TE attributes that are specific to the SR-TE application.

Common value RSVP-TE and SR-TE TE attributes are combined in the same application attribute sub-TLV with both application flags set, while the non-common value TE attributes are sent in their own application attribute sub-TLV with the corresponding application flag set.

Attribute mapping per application shows an excerpt from the Link State Database (LSDB). Attributes in green font are common to both RSVP-TE and SR-TE applications and are combined, while the attribute in red font is specific to the RSVP-TE application and is sent separately.

Routers in the TE domain use these attributes to compute CSPF for IPv4 RSVP-TE LSPs and IPv4 SR-TE LSPs. If the ipv6 command is also enabled, the RFC 6119 IPv6 TLVs are advertised. A router in the TE domain receiving these advertisements can compute paths for IPv6 SR-TE LSP.

Note:

The segment-routing command must be enabled in the IS-IS instance or the common TE attribute is not advertised for the SR-TE application.

To disable advertising of RSVP-TE attributes, use the rsvp shutdown command on the router.

The use can configure an SR-TE LSP as a label switched path (LSP) under the MPLS context by specifying the sr-te LSP type.

config>router>mpls>lsp lsp-name [mpls-tp src-tunnel-num | sr-te]

The user can configure a primary path for an RSVP LSP.

Use the following CLI syntax to associate an empty path or a path with strict or loose explicit hops with the primary paths of the SR-TE LSP:

config>router>mpls>path>hop hop-index ip-address {strict | loose}
    — config>router>mpls>lsp>primary path-name

Use the following syntax to configure the path computation requests only (PCE-computed) or both path computation requests and path updates (PCE-controlled) to the PCE for a specific LSP:

config>router>mpls>lsp>path-computation-method pce
    — config>router>mpls>lsp>pce-control

Use the following command syntax to ensure the PCC LSP database is synchronized with the PCE LSP database using the PCEP PCRpt (PCE Report) message for LSPs that have the following commands enabled:

config>router>mpls>pce-report sr-te {enable | disable}
    — config>router>mpls>lsp>pce-report {enable | disable | inherit}

Use the following CLI command syntax to configure the maximum number of labels that the ingress LER can push for a specific SR-TE LSP.

config>router>mpls>lsp>max-sr-labels label-stack-size

This command allows the user to reduce the SR-TE LSP label stack size by accounting for additional transport, service, and other labels when packets are forwarded in a particular context. See Datapath support for more information about label stack size requirements in various forwarding contexts. If the CSPF on the PCE or the hop-to-label translation of the router cannot find a path that meets the maximum SR label stack, the SR-TE LSP remains on its current path or remains down if it has no path. The range is 1-10 labels with a default value of 6.

Configure the adjacency hold timer for the LFA or remote LFA backup next hop of an adjacency SID.

Use the following CLI command syntax to configure the length of the interval during which LTN or ILM records of an adjacency SID are kept:

config>router>ospf>segment-routing>adj-sid-hold seconds[1..300, default 15]
    — config>router>isis>segment-routing>adj-sid-hold seconds[1..300, default 15]

adj-sid-hold 15
    — no entropy-label-capability
    — prefix-sid-range global
    — no tunnel-table-pref
    — no tunnel-mtu
    — no backup-node-sid
    — no shutdown

When protection is enabled globally for all node SIDs and local adjacency SIDs with the loopfree-alternates command in IS-IS or OSPF at the LER and LSR, applications may exist for which the user wants traffic to never divert from the strict hop computed by CSPF for an SR-TE LSP. In such cases, use the following CLI command syntax to disable protection for all adjacency SIDs formed over a network IP interface:

config>router>ospf>area>if>no sid-protection
    — config>router>isis>if>no sid-protection

node-sid index 194
    — no sid-protection
    — no shutdown

The following examples are configuration outputs.

keepalive 30
    — dead-timer 120
    — no local-address
    — unknown-message-rate 10
    — report-path-constraints
    — peer 192.168.48.226
        — no shutdown
    — exit
    — no shutdown

lsp "to-SanFrancisco" sr-te
        — to 192.168.48.211
        — path-computation-method local-cspf
        — pce-report disable
        — metric 10
        — primary "loose-anycast"
        — exit
        — no shutdown
    — exit

lsp "to-SanFrancisco" sr-te
        — to 192.168.48.211
        — path-computation-method local-cspf
        — pce-report enable
        — metric 10
        — primary "loose-anycast"
        — exit
        — no shutdown
    — exit

lsp "to-SanFrancisco" sr-te
        — to 192.168.48.211
        — path-computation-method local-cspf
        — pce-report enable
        — metric 10
        — primary "loose-anycast"
        — exit
        — no shutdown
    — exit

lsp "from Reno to Atlanta no Profile" sr-te
        — to 192.168.48.224
        — path-computation-method local-cspf
        — pce-report enable
        — pce-control
        — primary "empty"
        — exit
        — no shutdown
    — exit

lsp "from Reno to Atlanta no Profile" sr-te
        — to 192.168.48.224
        — max-sr-labels 8 additional-frr-labels 1
        — path-computation-method pce
        — pce-report enable
        — pce-control
        — path-profile 10 path-group 2
        — primary "empty"
            — bandwidth 15
        — exit
        — no shutdown
    — exit

The following shows the detailed configuration for the creation of a mesh of SR-TE auto-LSPs. The network uses IS-IS with the backbone area being in Level 2 and the leaf areas being in Level 1.

The NSP is used for network discovery only and the NRC-P learns the network topology using BGP-LS.

The following figure shows the view of the multi-level IS-IS topology in the NSP GUI. The backbone Level 2 area is highlighted in green.

The mesh of SR-TE auto-LSPs is created in the backbone area and originates on an ABR node with address 192.168.48.199 (Phoenix 199). The LSP template uses a default path that includes an anycast SID prefix corresponding to transit routers 192.168.48.184 (Dallas 184) and 192.168.48.185 (Houston 185).

*A:Dallas 184>config>router# info
---------------------------------------------------
echo "IP Configuration"
#--------------------------------------------------
        if-attribute
            admin-group "olive" value 20
            admin-group "top" value 10
            srlg-group "top" value 10
        exit
        interface "anycast-sid"                                                    *
            address 192.168.48.99/32                                               *
            loopback                                                               *
            no shutdown                                                            *
        exit
        interface "system"
            address 192.168.48.184/32
            no shutdown
        exit
        interface "toJun164"
            address 10.19.2.184/24
            port 1/1/4:10
            no shutdown
        exit
        interface "toSim185"
            address 10.0.3.184/24
            port 1/1/2
            no shutdown
        exit
        interface "toSim198"
            address 10.0.2.184/24
            port 1/1/3
            if-attribute
                admin-group "olive"
            exit
            no shutdown
        exit
        interface "toSim199"
            address 10.0.13.184/24
            port 1/1/5
            no shutdown
        exit
        interface "toSim221"
            address 10.0.4.184/24
            port 1/1/1
            no shutdown
        exit
        interface "toSim223"
            address 10.0.14.184/24
            port 1/1/6
            no shutdown
        exit
#--------------------------------------------------

*A:Dallas 184>config>router>isis# info
----------------------------------------------
            level-capability level-2
            area-id 49.0000
            database-export identifier 10 bgp-ls-identifier 10
            traffic-engineering
            advertise-router-capability area
            level 2
                wide-metrics-only
            exit
            interface "system"
                ipv4-node-sid index 384
                no shutdown
            exit
            interface "toSim198"
                interface-type point-to-point
                no shutdown
            exit
            interface "toSim185"
                interface-type point-to-point
                no shutdown
            exit
            interface "toSim221"
                interface-type point-to-point
                no shutdown
            exit
            interface "toSim199"
                interface-type point-to-point
                level 2
                    metric 100
                exit
                no shutdown
            exit
            interface "toSim223"
                interface-type point-to-point
                level 2
                    metric 100
                exit
                no shutdown
            exit
            interface "anycast-sid"                                                *
                ipv4-node-sid index 99                                             *
                no shutdown                                                        *
            exit
            segment-routing
                prefix-sid-range global
                no shutdown
            exit
            no shutdown
----------------------------------------------

*A:Phoenix 199# show router isis prefix-sids
===============================================================================
Rtr Base ISIS Instance 0 Prefix/SID Table
===============================================================================
Prefix                            SID        Lvl/Typ    SRMS   AdvRtr
                                                         MT     Flags
-------------------------------------------------------------------------------
192.168.48.194/32                  399        1/Int.      N     Reno 194
                                                            0       NnP
192.168.48.194/32                  399        2/Int.      N     Salt Lake 198
                                                            0       RNnP
192.168.48.194/32                  399        2/Int.      N     Phoenix 199
                                                            0       RNnP
192.168.48.99/32                   99         2/Int.      N     Dallas 184         *
                                                            0       NnP            *
192.168.48.99/32                   99         2/Int.      N     Houston 185        *
                                                            0       NnP            *
192.168.48.184/32                  384        2/Int.      N     Dallas 184
                                                            0       NnP
192.168.48.185/32                  385        2/Int.      N     Houston 185
                                                            0       NnP
192.168.48.190/32                  390        2/Int.      N     Chicago 221
                                                            0       RNnP
192.168.48.190/32                  390        2/Int.      N     St Louis 223
                                                            0       RNnP
192.168.48.194/32                  394        1/Int.      N     Reno 194
                                                            0       NnP
192.168.48.194/32                  394        2/Int.      N     Salt Lake 198
                                                            0       RNnP
192.168.48.194/32                  394        2/Int.      N     Phoenix 199
                                                            0       RNnP
192.168.48.198/32                  398        1/Int.      N     Salt Lake 198
                                                            0       NnP
192.168.48.198/32                  398        2/Int.      N     Salt Lake 198
                                                            0       NnP
192.168.48.198/32                  398        2/Int.      N     Phoenix 199
                                                            0       RNnP
192.168.48.199/32                  399        2/Int.      N     Salt Lake 198
                                                            0       RNnP
192.168.48.199/32                  399        1/Int.      N     Phoenix 199
                                                            0       NnP
192.168.48.199/32                  399        2/Int.      N     Phoenix 199
                                                            0       NnP
192.168.48.219/32                  319        2/Int.      N     Salt Lake 198
                                                            0       RNnP
192.168.48.219/32                  319        2/Int.      N     Phoenix 199
                                                            0       RNnP
192.168.48.219/32                  319        1/Int.      N     Las Vegas 219
                                                            0       NnP
192.168.48.221/32                  321        2/Int.      N     Chicago 221
                                                            0       NnP
192.168.48.221/32                  321        2/Int.      N     St Louis 223
                                                            0       RNnP
192.168.48.223/32                  323        2/Int.      N     Chicago 221
                                                            0       RNnP
192.168.48.223/32                  323        2/Int.      N     St Louis 223
                                                            0       NnP
192.168.48.224/32                  324        2/Int.      N     Chicago 221
                                                            0       RNnP
192.168.48.224/32                  324        2/Int.      N     St Louis 223
                                                            0       RNnP
192.168.48.226/32                  326        2/Int.      N     PCE Server 226
                                                            0       NnP
3ffe::a14:194/128                  294        1/Int.      N     Reno 194
                                                            0       NnP
3ffe::a14:194/128                  294        2/Int.      N     Phoenix 199
                                                            0       RNnP
3ffe::a14:199/128                  299        1/Int.      N     Phoenix 199
                                                            0       NnP
3ffe::a14:199/128                  299        2/Int.      N     Phoenix 199
                                                            0       NnP
-------------------------------------------------------------------------------
No. of Prefix/SIDs: 32 (15 unique)
-------------------------------------------------------------------------------
SRMS : Y/N  = prefix SID advertised by SR Mapping Server (Y) or not (N)
       S    = SRMS prefix SID is selected to be programmed
Flags: R    = Re-advertisement
       N    = Node-SID
       nP   = no penultimate hop POP
       E    = Explicit-Null
       V    = Prefix-SID carries a value
       L    = value/index has local significance
===============================================================================

*A:Phoenix 199# tools dump router segment-routing tunnel
====================================================================================
Legend: (B) - Backup Next-hop for Fast Re-Route                                 
        (D) - Duplicate                                                         
====================================================================================
-----------------------------------------------------------------------------------+
 Prefix                                                                            |
 Sid-Type        Fwd-Type       In-Label  Prot-Inst                                |
                 Next Hop(s)                      Out-Label(s) Interface/Tunnel-ID |
-----------------------------------------------------------------------------------+
 192.168.48.99                                                                     *
 Node            Orig/Transit   200099    ISIS-0                                   *
                 10.0.5.185                       200099      toSim185             *
 3ffe::a14:194
 Node            Orig/Transit   200294    ISIS-0
                 fe80::62c2:ffff:fe00:0           200294      toSim194
 3ffe::a14:199
 Node            Terminating    200299    ISIS-0
 192.168.48.219
 Node            Orig/Transit   200319    ISIS-0
                 10.202.5.194                     200319      toSim194
 192.168.48.221
 Node            Orig/Transit   200321    ISIS-0
                 10.0.5.185                       200321      toSim185
 192.168.48.223
 Node            Orig/Transit   200323    ISIS-0
                 10.0.5.185                       200323      toSim185
 192.168.48.224
 Node            Orig/Transit   200324    ISIS-0
                 10.0.5.185                       200324      toSim185
 192.168.48.226
 Node            Orig/Transit   200326    ISIS-0
                 10.0.1.2                         100326      toSim226PCEServer
 192.168.48.184
 Node            Orig/Transit   200384    ISIS-0
                 10.0.5.185                       200384      toSim185
 192.168.48.185
 Node            Orig/Transit   200385    ISIS-0
                 10.0.5.185                       200385      toSim185
 192.168.48.190
 Node            Orig/Transit   200390    ISIS-0
                 10.0.5.185                       200390      toSim185
 192.168.48.194
 Node            Orig/Transit   200394    ISIS-0
                 10.202.5.194                     200394      toSim194
 192.168.48.198
 Node            Orig/Transit   200398    ISIS-0
                 10.0.9.198                       100398      toSim198
 192.168.48.199
 Node            Terminating    200399    ISIS-0
 10.0.9.198
 Adjacency       Transit        262122    ISIS-0
                 10.0.9.198                       3           toSim198
 10.202.1.219
 Adjacency       Transit        262124    ISIS-0
                 10.202.1.219                     3           toSim219
 10.0.5.185
 Adjacency       Transit        262133    ISIS-0
                 10.0.5.185                       3           toSim185
 fe80::62c2:ffff:fe00:0
 Adjacency       Transit        262134    ISIS-0
                 fe80::62c2:ffff:fe00:0           3           toSim194
 10.0.1.2
 Adjacency       Transit        262137    ISIS-0
                 10.0.1.2                         3           toSim226PCEServer
 10.0.13.184
 Adjacency       Transit        262138    ISIS-0
                 10.0.13.184                      3           toSim184
 10.0.2.2
 Adjacency       Transit        262139    ISIS-0
                 10.0.2.2                         3           toSim226PCEserver202
 10.202.5.194
 Adjacency       Transit        262141    ISIS-0
                 10.202.5.194                     3           toSim194
------------------------------------------------------------------------------------
No. of Entries: 22
------------------------------------------------------------------------------------

*A:Phoenix 199>config>router>policy-options# info
----------------------------------------------
            prefix-list "sr-te-level2"
                prefix 192.168.48.198/32 exact
                prefix 192.168.48.221/32 exact
                prefix 192.168.48.223/32 exact
            exit
            policy-statement "sr-te-auto-lsp"
                entry 10
                    from
                        prefix-list "sr-te-level2"
                    exit
                    action accept
                    exit
                exit
                default-action drop
                exit
            exit
----------------------------------------------

*A:Phoenix 199>config>router>mpls# info
----------------------------------------------
            cspf-on-loose-hop
            interface "system"
                no shutdown
            exit
            interface "toESS195"
                no shutdown
            exit
            interface "toSim184"
                no shutdown
            exit
            interface "toSim185"
                admin-group "bottom"
                srlg-group "bottom"
                no shutdown
            exit
            interface "toSim194"
                admin-group "bottom"
                srlg-group "bottom"
                no shutdown
            exit
            interface "toSim198"
                no shutdown
            exit
            interface "toSim219"
                no shutdown
            exit
            path "loose-anycast-sid"                                               *
                hop 1 192.168.48.99 loose                                          *
                no shutdown                                                        *
            exit                                                                   *
            lsp-template "sr-te-level2-mesh" mesh-p2p-srte                         *
                default-path "loose-anycast-sid"                                   *
                max-sr-labels 8 additional-frr-labels 2                            *
                pce-report enable                                                  *
                no shutdown                                                        *
            exit                                                                   *
            auto-lsp lsp-template "sr-te-level2-mesh" policy "sr-te-auto-lsp"      *
            no shutdown                                                            *
----------------------------------------------

*A:Phoenix 199# show router mpls sr-te-lsp
===============================================================================
MPLS SR-TE LSPs (Originating)
===============================================================================
LSP Name                           To               Tun     Protect   Adm  Opr
                                                    Id      Path
-------------------------------------------------------------------------------
Phoenix-SL-1                       192.168.48.223    1       N/A       Up   Up
Phoenix-SL-2-Profile               192.168.48.223    2       N/A       Up   Up
Phoenix-SL-3-Profile               192.168.48.223    3       N/A       Up   Up
Phoenix-SL-4-Profile               192.168.48.223    4       N/A       Up   Up
Phoenix-SL-1-Profile               192.168.48.223    5       N/A       Up   Up
Phoenix-SL-2                       192.168.48.223    6       N/A       Up   Up
Phoenix-SL-3                       192.168.48.223    7       N/A       Up   Up
Phoenix-SL-4                       192.168.48.223    8       N/A       Up   Up
sr-te-level2-mesh-192.168.48.198-  192.168.48.198    61442   N/A       Up   Up     *
716803                                                                             *
sr-te-level2-mesh-192.168.48.221-  192.168.48.221    61443   N/A       Up   Up     *
716804                                                                             *
sr-te-level2-mesh-192.168.48.223-  192.168.48.223    61444   N/A       Up   Up     *
716805                                                                             *
-------------------------------------------------------------------------------
LSPs : 17
===============================================================================

*A:Phoenix 199# show router mpls sr-te-lsp "sr-te-level2-mesh-192.168.48.223-
716805" detail
===============================================================================
MPLS SR-TE LSPs (Originating) (Detail)
===============================================================================
-------------------------------------------------------------------------------
Type : Originating
-------------------------------------------------------------------------------
LSP Name        : sr-te-level2-mesh-192.168.48.223-716805
LSP Type        : MeshP2PSrTe               LSP Tunnel ID        : 61444           *
LSP Index       : 126979                    TTM Tunnel Id        : 716805          *
From            : 192.168.48.199            To                   : 192.168.48.223
Adm State       : Up                        Oper State           : Up
LSP Up Time     : 0d 00:02:12               LSP Down Time        : 0d 00:00:00
Transitions     : 3                         Path Changes         : 3
Retry Limit     : 0                         Retry Timer          : 30 sec
CSPF            : Enabled
Metric          : N/A                       Use TE metric        : Disabled
Include Grps    :                           Exclude Grps         :
None                                           None
VprnAutoBind    : Enabled
IGP Shortcut    : Enabled                   BGP Shortcut         : Enabled
IGP LFA         : Disabled                  IGP Rel Metric       : Disabled
BGPTransTun     : Enabled
Oper Metric     : 16777215
PCE Report      : Enabled
PCE Compute     : Disabled                  PCE Control          : Disabled
Max SR Labels   : 8                         Additional FRR Labels: 2
Path Profile    :
None
Primary(a)      : loose-anycast-sid         Up Time              : 0d 00:02:12
Bandwidth       : 0 Mbps
===============================================================================

*A:Phoenix 199# show router tunnel-table
===============================================================================
IPv4 Tunnel Table (Router: Base)
===============================================================================
Destination       Owner     Encap TunnelId  Pref     Nexthop        Metric
-------------------------------------------------------------------------------
10.0.5.185/32     isis (0)  MPLS  524370    11       10.0.5.185     0
10.0.9.198/32     isis (0)  MPLS  524368    11       10.0.9.198     0
10.0.13.184/32    isis (0)  MPLS  524340    11       10.0.13.184    0
10.202.1.219/32   isis (0)  MPLS  524333    11       10.202.1.219   0
10.202.5.194/32   isis (0)  MPLS  524355    11       10.202.5.194   0
10.0.1.2/32       isis (0)  MPLS  524364    11       11.0.1.2       0
10.0.2.2/32       isis (0)  MPLS  524363    11       11.0.2.2       0
192.168.48.99/32  isis (0)  MPLS  524294    11       10.0.5.185     10
192.168.48.184/32 ldp       MPLS  65605     9        10.0.5.185     20
192.168.48.184/32 isis (0)  MPLS  524341    11       10.0.5.185     20
192.168.48.185/32 ldp       MPLS  65602     9        10.0.5.185     10
192.168.48.185/32 isis (0)  MPLS  524371    11       10.0.5.185     10
192.168.48.190/32 ldp       MPLS  65606     9        10.0.5.185     40
192.168.48.190/32 isis (0)  MPLS  524362    11       10.0.5.185     40
192.168.48.194/32 ldp       MPLS  65577     9        10.202.5.194   10
192.168.48.194/32 isis (0)  MPLS  524331    11       10.202.5.194   10
192.168.48.198/32 sr-te     MPLS  716803    8        192.168.48.99  16777215      *
192.168.48.198/32 ldp       MPLS  65601     9        10.0.9.198     10
192.168.48.198/32 isis (0)  MPLS  524369    11       10.0.9.198     10
192.168.48.219/32 ldp       MPLS  65579     9        10.202.5.194   20
192.168.48.219/32 isis (0)  MPLS  524334    11       10.202.5.194   20
192.168.48.221/32 sr-te     MPLS  716804    8        192.168.48.99  16777215      *
192.168.48.221/32 ldp       MPLS  65607     9        10.0.5.185     30
192.168.48.221/32 isis (0)  MPLS  524358    11       10.0.5.185     30
192.168.48.223/32 sr-te     MPLS  655362    8        10.0.13.184    200
192.168.48.223/32 sr-te     MPLS  655363    8        10.0.13.184    200
192.168.48.223/32 sr-te     MPLS  655364    8        10.0.5.185     40
192.168.48.223/32 sr-te     MPLS  655365    8        10.0.13.184    120
192.168.48.223/32 sr-te     MPLS  655366    8        10.0.5.185     120
192.168.48.223/32 sr-te     MPLS  655367    8        10.0.13.184    120
192.168.48.223/32 sr-te     MPLS  655368    8        10.0.13.184    200
192.168.48.223/32 sr-te     MPLS  655369    8        10.0.5.185     40
192.168.48.223/32 sr-te     MPLS  716805    8        192.168.48.99  16777215      *
192.168.48.223/32 ldp       MPLS  65603     9        10.0.5.185     20
192.168.48.223/32 isis (0)  MPLS  524306    11       10.0.5.185     20
192.168.48.224/32 ldp       MPLS  65604     9        10.0.5.185     30
192.168.48.224/32 isis (0)  MPLS  524361    11       10.0.5.185     30
192.168.48.226/32 isis (0)  MPLS  524365    11       11.0.1.2       65534
-------------------------------------------------------------------------------
Flags: B = BGP backup route available
       E = inactive best-external BGP route
===============================================================================

*A:Phoenix 199# show router mpls sr-te-lsp "sr-te-level2-mesh-192.168.48.223-
716805" path detail
===============================================================================
MPLS SR-TE LSP sr-te-level2-mesh-192.168.48.223-716805 Path  (Detail)
===============================================================================
Legend :
    S      - Strict                      L      - Loose
    A-SID  - Adjacency SID               N-SID  - Node SID
    +      - Inherited
===============================================================================
-------------------------------------------------------------------------------
SR-TE LSP sr-te-level2-mesh-192.168.48.223-716805 Path loose-anycast-sid
-------------------------------------------------------------------------------
LSP Name         : sr-te-level2-mesh-192.168.48.223-716805
Path LSP ID      : 20480
From             : 192.168.48.199       To                   : 192.168.48.223
Admin State      : Up                   Oper State           : Up
Path Name        : loose-anycast-sid    Path Type            : Primary
Path Admin       : Up                   Path Oper            : Up
Path Up Time     : 0d 02:30:28          Path Down Time       : 0d 00:00:00
Retry Limit      : 0                    Retry Timer          : 30 sec
Retry Attempt    : 1                    Next Retry In        : 0 sec
CSPF             : Enabled              Oper CSPF            : Enabled
Bandwidth        : No Reservation       Oper Bandwidth       : 0 Mbps
Hop Limit        : 255                  Oper HopLimit        : 255
Setup Priority   : 7                    Oper Setup Priority  : 7
Hold Priority    : 0                    Oper Hold Priority   : 0
Inter-area       : N/A
PCE Updt ID      : 0                    PCE Updt State       : None
PCE Upd Fail Code: noError
PCE Report       : Enabled              Oper PCE Report      : Disabled
PCE Control      : Disabled             Oper PCE Control     : Disabled
PCE Compute      : Disabled
Include Groups   :                      Oper Include Groups  :
None                                           None
Exclude Groups   :                      Oper Exclude Groups  :
None                                           None
IGP/TE Metric    : 16777215             Oper Metric          : 16777215
Oper MTU         : 1492                 Path Trans           : 1
Failure Code     : noError
Failure Node     : n/a
Explicit Hops    :
    192.168.48.99(L)
Actual Hops      :
    192.168.48.99 (192.168.48.185)(N-SID)          Record Label        : 200099    *
 -> 192.168.48.223 (192.168.48.223)(N-SID)         Record Label        : 200323    *
===============================================================================

For an unlabeled IPv4 BGP route to be resolved by an SR policy:

• A color-extended community must be attached to the IPv4 route.

• The base instance BGP next-hop-resolution configuration of shortcut-tunnel>family ipv4 must allow SR policy tunnels.

For example, to resolve an IPv4 route with a color-extended community (value C) and BGP next-hop address N under these conditions, the router performs the following steps:

1. If there is an SR policy in the TTMv4 for the following are true, then use this tunnel to resolve the BGP next hop:

   • end-point = BGP next-hop address
   • color = Cn

2. If no SR policy is found in the previous step and the Cn color-extended community has its color-only (CO) bits set to 01 or 10, then search for an SR policy in the TTMv4 for which the following are true:

   • endpoint = null (0.0.0.0)
   • color = Cn

   If there is such a policy, use it to resolve the BGP next hop.

3. If no SR policy is found in the previous steps and the Cn color-extended community has its CO bits set to 01 or 10, then search for an SR policy in the TTMv6 for which the following are true.

   • endpoint = null (0::0)
   • color = Cn

   If there is such a policy, use it to resolve the BGP next hop.

4. If no SR policy is found in the previous steps but there is a non-SR policy tunnel in the TTMv4 that is allowed by the resolution options and for which endpoint = BGP next-hop address (and for which the admin tag meets the admin-tag-policy requirements applied to the BGP route, if applicable), then use this tunnel to resolve the BGP next hop if it has the highest TTM preference.
5. Otherwise, fall back to IGP, unless the disallow-igp option is configured.

For example, to resolve an IPv6 route with a color-extended community (value C) and BGP next-hop address N under these conditions, the router performs the following steps:

1. If there is an SR policy in the TTMv6 for which the following are true, then use this tunnel to resolve the BGP next hop.
   • endpoint = the BGP next-hop address
   • color = Cn

2. If no SR policy is found in the previous step and the Cn color-extended community has its CO bits set to 01 or 10, then search for an SR policy in the TTMv6 for which the following are true:

   • endpoint = null (0::0)
   • color = Cn

   If there is such a policy, use it to resolve the BGP next hop.

3. If no SR policy is found in the previous steps, and the Cn color-extended community has its CO bits set to 01 or 10 and there is an SR policy in the TTMv4 for which the following are true, then use this tunnel to resolve the BGP next hop.

   • endpoint = null (0.0.0.0)
   • color = Cn
4. If no SR policy is found in the previous steps but there is a non-SR policy tunnel in the TTMv6 that is allowed by the resolution options and for which endpoint = BGP next-hop address (and for which the admin-tag meets the admin-tag-policy requirements applied to the BGP route, if applicable), then use this tunnel to resolve the BGP next hop if it has the highest TTM preference.
5. Otherwise, fall back to IGP, unless the disallow-igp option is configured.

For a label-unicast IPv4 BGP route to be resolved by an SR policy:

• A color-extended community must be attached to the label-IPv4 route.

• The base instance BGP next-hop-resolution configuration of labeled-routes>transport-tunnel>family label-ipv4 must allow SR policy tunnels.

For example, to resolve a label-IPv4 route with a color-extended community (value C) and BGP next-hop address N, the router performs the following steps:

1. If there is an interface route that can resolve the BGP next hop, then use the direct route.
2. If the allow-static command is configured and there is a static route that can resolve the BGP next hop, then use the static route.
3. If there is no interface route or static route available or allowed to resolve the BGP next hop and the next hop uses IPv4, then:

   1. Look for an SR policy in the TTMv4 for which the following are true:

      • end-point = BGP next-hop address
      • color = Cn

      If there is such an SR policy, use it to resolve the BGP next hop. If the selected SR policy has any segment list with more than {11 - max-sr-frr-labels under the IGPs} labels or segments, then the label-IPv4 route is unresolved.

   2. If no SR policy is found in the previous steps and the Cn color-extended community has its CO bits set to 01 or 10, then search for an SR policy in the TTMv4 for which the following are true:

      • endpoint = null (0.0.0.0)
      • color = Cn

      If there is such a policy, use it to resolve the BGP next hop. If the selected SR policy has any segment list with more than {11- max-sr-frr-labels under the IGPs} labels or segments, then the label-IPv4 route is unresolved.

   3. If no SR policy is found in the previous steps and the Cn color-extended community has its CO bits set to 01 or 10, then search for an SR policy in the TTMv6 for the following are true:

      • endpoint = null (0::0)
      • color = Cn

      If there is such a policy, use it to resolve the BGP next hop. If the selected SR policy has any segment list with more than {11- max-sr-frr-labels under the IGPs} labels or segments, then the label-IPv4 route is unresolved.

4. If there is no interface route or static route that is available or allowed to resolve the BGP next hop and the next hop uses IPv6, then:

   1. Search for an SR policy in the TTMv6 for which the following are true:

      • end-point = BGP next-hop address
      • color = Cn

      If there is such an SR policy, use it to resolve the BGP next hop. If the selected SR policy has any segment list with more than {11- max-sr-frr-labels under the IGPs} labels or segments, then the label-IPv4 route is unresolved.

   2. If no SR policy is found in the previous steps and the Cn color-extended community has its CO bits set to 01 or 10, then search for an SR policy in the TTMv6 for which the following are true:

      • endpoint = null (0::0)
      • color = Cn

      If there is such a policy, use it to resolve the BGP next hop. If the selected SR policy has any segment list with more than {11- max-sr-frr-labels under the IGPs} labels or segments, then the label-IPv4 route is unresolved.

   3. If no SR policy is found in the previous steps and the Cn color-extended community has its CO bits set to 01 or 10, then search for an SR policy in the TTMv4 for which the following are true:

      • endpoint = null (0.0.0.0)
      • color = Cn

      If there is such a policy, use it to resolve the BGP next hop. If the selected SR policy has any segment list with more than {11- max-sr-frr-labels under the IGPs} labels or segments, then the label-IPv4 route is unresolved.

5. If no SR policy is found in the previous steps but there is a non-SR policy tunnel in the TTMv4 (the next hop uses IPv4) or TTMv6 (the next hop uses IPv6) that is allowed by the resolution options and for which endpoint = BGP next-hop address (and for which the admin tag meets the admin-tag-policy requirements applied to the BGP route, if applicable), then use this tunnel to resolve the BGP next hop if it has the highest TTM preference.