Segment routing with MPLS data plane (SR-MPLS)

New TLV and sub-TLVs are defined in draft-ietf-isis-segment-routing-extensions and are supported in the implementation of segment routing in IS-IS. Specifically:

• prefix SID sub-TLV

• adjacency SID sub-TLV

• SID/Label Binding TLV

• SR-Capabilities sub-TLV

• SR-Algorithm sub-TLV

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

SR OS supports advertising the IS router capability TLV (RFC 4971) only for topology MT=0. As a result, the segment routing capability sub-TLV can only be advertised in MT=0 which restricts the segment routing feature to MT=0.

Similarly, if prefix SID sub-TLVs for the same prefix are received in different MT numbers of the same IS-IS instance, then only the one in MT=0 is resolved. When the prefix SID index is also duplicated, an error is logged and a trap is generated, as described in Error and resource exhaustion handling.

I and V flags are both set to 1 when originating the SR capability sub-TLV to indicate support for processing both SR MPLS encapsulated IPv4 and IPv6 packets on its network interfaces. These flags are not checked when the sub-TLV is received. Only the SRGB range is processed.

The algorithm field is set to 0, meaning Shortest Path First (SPF) algorithm based on link metric, when originating the SR-Algorithm capability sub-TLV but is not checked when the sub-TLV is received.

Both IPv4 and IPv6 prefix and adjacency SID sub-TLVs originate within MT=0.

SR OS originates a single prefix SID sub-TLV per IS-IS IP-reachability TLV and processes the first prefix SID sub-TLV only if multiple are received within the same IS-IS IP-reachability TLV.

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

SR OS originates a prefix SID sub-TLV with the following encoding of the flags and the following processing rules:

• The R-flag is set if the prefix SID sub-TLV, along with its corresponding IP-reachability TLV, is propagated between levels. See below for more details about prefix propagation.

• The N-flag is always set because SR OS supports a prefix SID type that is node SID only.

• The P-Flag (no-PHP flag) is always set, meaning 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 P-flag set to zero and uses implicit-null for the outgoing label toward the router which advertised it as long as the P-Flag is also set to 1.

• The E-flag (Explicit-Null 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 P-flag is also set to 1, it pushes explicit-null for the outgoing label toward the router which 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 always set to zero to indicate Shortest Path First (SPF) algorithm based on link metric and is not checked on a received prefix SID sub-TLV.

• The SR OS resolves a prefix SID sub-TLV received without the N-flag set but with the prefix length equal to 32. A trap, however, is raised by IS-IS.

• The SR OS does not resolve a prefix SID sub-TLV received with the N-flag set and a prefix length different than 32. A trap is raised by IS-IS.

• The SR OS resolves a prefix SID received within a IP-reachability TLV based on the following route preference:

  • SID received via Level 1 in a prefix SID sub-TLV part of IP-reachability TLV

  • SID received via Level 2 in a prefix SID sub-TLV part of IP-reachability TLV

• A prefix received in an IP-reachability TLV is propagated, along with the prefix SID sub-TLV, by default from Level 1 to Level 2 by an Level 1 or Level 2 router. A router in Level 2 sets up an SR tunnel to the Level 1 router via the Level 1 or Level 2 router, which acts as an LSR.

• A prefix received in an IP-reachability TLV is not propagated, along with the prefix SID sub-TLV, by default from Level 2 to Level 1 by an Level 1 or Level 2 router. If the user adds a policy to propagate the received prefix, then a router in Level 1 sets up an SR tunnel to the Level 2 router via the Level 1 or Level 2 router, which acts as an LSR.

• If a prefix is summarized by an ABR, the prefix SID sub-TLV is not propagated with the summarized route between levels. To propagate the node SID for a /32 prefix, route summarization must be disabled.

• SR OS propagates the prefix SID sub-TLV when exporting the prefix to another IS-IS instance; however, it does not propagate it if the prefix is exported from a different protocol. Thus, when the corresponding prefix is redistributed from another protocol such as OSPF, the prefix SID is removed.

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

• The F-flag is set to zero for IPv4 family and is set to 1 to for IPv6 family for the adjacency encapsulation.

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

• The V-flag is always set to 1.

• The L-flag is always set to 1.

• The S-flag is set to zero because assigning adjacency SID to parallel links between neighbors is not supported. An adjacency received SID with S-Flag set is not processed.

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

SR OS can originate the SID/Label Binding TLV as part of the Mapping Server feature (see Segment routing mapping server function for IPv4 prefixes for more information). The following rules and limitations should be considered:

• Only the mapping server prefix-SID sub-TLV within the TLV is processed and the ILMs installed if the prefixes in the provided range are resolved.

• The range and FEC prefix fields are processed. Each FEC prefix is resolved, similar to the prefix SID sub-TLV, meaning there must be an IP-reachability TLV received for the exact matching prefix.

• If the same prefix is advertised with both a prefix SID sub-TLV and a mapping server prefix-SID sub-TLV. The resolution follows the following route preference:

  • SID received via Level 1 in a prefix SID sub-TLV part of IP-reachability TLV

  • SID received via Level 2 in a prefix SID sub-TLV part of IP-reachability TLV

  • SID received via Level 1 in a mapping server Prefix-SID sub-TLV

  • SID received via Level 2 in a mapping server Prefix-SID sub-TLV

• The entire TLV can be propagated between levels based on the settings of the S-flag. The TLV cannot be propagated between IS-IS instances (see Segment routing mapping server function for IPv4 prefixes for more information). Finally, an Level 1 or Level 2 router does not propagate the prefix-SID sub-TLV from the SID/label binding TLV (received from a mapping server) into the IP-reachability TLV if the latter is propagated between levels.

• The mapping server which advertised the SID/label binding TLV does not need to be in the shortest path for the FEC prefix.

• If the same FEC prefix is advertised in multiple binding TLVs by different routers, the SID in the binding TLV of the first router that is reachable is used. If that router becomes unreachable, the next reachable one is used.

• No check is performed if the content of the binding TLVs from different mapping servers are consistent or not.

• Any other sub-TLV, for example, the SID/label sub-TLV, ERO metric and unnumbered interface ID ERO, is ignored but the user can view the octets of the received-but-not-supported sub-TLVs using the IGP show command.

IS-IS can announce node Entropy Label Capability (ELC), the Maximum Segment Depth (MSD) for node Entropy Readable Label Depth (ERLD) and the MSD for node Base MPLS Imposition (BMI). If needed, exporting the IS-IS extensions into BGP-LS requires no additional configuration. These extensions are standardized through draft-ietf-isis-mpls-elc-10, Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS, and RFC 8491, Signaling Maximum SID Depth (MSD) Using IS-IS.

When entropy and segment routing are enabled on a router, it automatically announces the ELC, ERLD, and BMI IS-IS values when IS-IS prefix attributes and router capabilities are announced. The following configuration logic is used.

• The router automatically announces ELC for host prefixes associated with an IPv4 or IPv6 node SID when segment-routing , segment-routing entropy-label, and prefix-attributes-tlv are enabled for IS-IS. Although the ELC capability is a node property, it is assigned to prefixes to allow inter-area or inter-AS signaling. Consequently, the prefix-attribute TLV must be enabled accordingly within IS-IS.

• The router announces the maximum node ERLD for IS-IS when segment-routing and segment-routing entropy-label are enabled together with advertise-router-capability.

• The router announces the maximum node MSD-BMI for IS-IS when segment-routing and advertise-router-capability are enabled.

• Exporting ELC, MSD-ERLD, and MSD-BMI IS-IS extensions into BGP-LS encoding is enabled automatically when database-export for BGP-LS is configured.

• The announced value for maximum node MSD-ERLD and MSD-BMI can be modified to a smaller number using the override-bmi and override-erld commands. This can be useful when services (such as EVPN) or more complex link protocols (such as Q-in-Q) are deployed. Provisioning correct ERLD and BMI values helps controllers and local Constrained Shortest Path First (CSPF) to construct valid segment routing label stacks to be deployed in the network.

Segment routing parameters are configured in the following contexts:

configure>router>isis>segment-routing>maximum-sid-depth
configure>router>isis>segment-routing>maximum-sid-depth>override-bmi value
configure>router>isis>segment-routing>maximum-sid-depth>override-erld value

The router supports the MPLS entropy label, as specified in RFC 6790, on IS-IS segment-routed tunnels. LSR nodes in a network can load-balance labeled packets in a more granular way than by hashing on the standard label stack. See the MPLS Guide for more information.

Announcing of Entropy Label Capability (ELC) is supported, however processing of ELC signaling is not supported for IS-IS segment-routed tunnels. Instead, ELC is configured at the head-end LER using the configure router isis entropy-label override-tunnel-elc command. This command causes the router to ignore any advertisements for ELC that may or may not be received from the network, and instead to assume that the whole domain supports entropy labels.

This feature supports SR IPv6 tunnels in IS-IS MT=0. The user can configure a node SID for the primary IPv6 global address of a loopback interface, which is then advertised in IS-IS. IS-IS automatically assigns and advertises an adjacency SID for each adjacency with an IPv6 neighbor. After the node SID is resolved, it is used to install an IPv6 SR-ISIS tunnel in the TTM for use by the services.

The mapping server feature supports the configuration and advertisement, in IS-IS, of the node SID index for prefixes of routers in the LDP domain. This is performed in the router acting as a mapping server and using a prefix-SID sub-TLV within the SID/label binding TLV in IS-IS.

Use the following command syntax to configure the SR mapping database in IS-IS:

configure
        — router
            — [no] isis
                — segment-routing
                — no segment-routing
                    — mapping-server
                        — sid-map node-sid {index 0..4294967295 [range  0..65535]} prefix {{ip-address/mask} | {ip-address}{netmask}} [set-flags {s}] [level {1 | 2 | 1/2}]
                        — no sid-map node-sid index 0..4294967295

The user enters the node SID index, for one prefix or a range of prefixes, by specifying the first index value and, optionally, a range value. The default value for the range option is 1. Only the first prefix in a consecutive range of prefixes must be entered. If the user enters the first prefix with a mask lower than 32, the SID/label binding TLV is advertised, but a router that receives it does not resolve the prefix SID and instead generates a trap.

The no form of the sid-map command deletes the range of node SIDs beginning with the specified index value. The no form of the mapping-server command deletes all node SID entries in the IS-IS instance.

The S-flag indicates to the IS-IS routers in the network that the flooding scope of the SID/label binding TLV is the entire domain. In that case, a router receiving the TLV advertisement leaks it between IS-IS levels. If leaked from Level 2 to Level 1, the D-flag must be set; this prevents the TLV from being leaked back into level 2. Otherwise, the S-flag is clear by default and routers receiving the mapping server advertisement do not leak the TLV.

The A-flag indicates that a prefix for which the mapping server prefix SID is advertised is directly attached. The M-flag advertises a SID for a mirroring context to provide protection against the failure of a service node. None of these flags are supported on the mapping server; the mapping client ignores them.

Each time a prefix or a range of prefixes is configured in the SR mapping database in any routing instance, the router issues for this prefix, or range of prefixes, a prefix-SID sub-TLV within an IS-IS SID/label binding TLV in that instance. The flooding scope of the TLV from the mapping server is determined as previously described. No further check of the reachability of that prefix in the mapping server route table is performed. No check of the SID index is performed to determine whether the SID index is a duplicate of an existing prefix in the local IGP instance database or if the SID index is out of range with the local SRGB.

New 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. Specifically:

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

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

• 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 TLV 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. SR OS PHP routers process a received prefix SID with the NP-flag set to zero and use implicit-null for the outgoing label toward the router which 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. SR OS PHP routers process a received prefix SID with the E-flag set to 1, and when the NP-flag is also set to 1 they push explicit-null for the outgoing label toward the router which 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 Extended Prefix TLV

• SID received via an inter-area route in a prefix SID sub-TLV part of 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 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

• Leaking does not occur within the TLV between areas. Also, an ABR does not propagate the prefix-SID sub-TLV from the Extended Prefix Range TLV (received from a mapping server) 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 of 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 get a dump of the octets of the received-but-not-supported sub-TLVs using the existing IGP show command.

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 NSSA area 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 RTM and the corresponding tunnels in TTM. So, a prefix removed by the policy does not appear as both a route in RTM and as an SR tunnel in TTM.

The OSPFv3 extensions support the following TLVs:

• a prefix SID that is a sub-TLV of the OSPFv3 prefix TLV

  The OSPFv3 prefix TLV is a new top-level TLV of the extended prefix LSA introduced in draft-ietf-ospf-ospfv3-lsa-extend. The OSPFv3 instance can operate in either LSA sparse mode or extended LSA mode.

  The config>router>extended-lsa only command advertises the prefix SID sub-TLV in the extended LSA format in both cases.

• an adjacency SID that is a sub-TLV of the OSPFv3 router-link TLV

  The OSPFv3 router-link TLV is a new top-level TLV in the extended router LSA introduced in draft-ietf-ospf-ospfv3-lsa-extend. The OSPFv3 instance can operate in either LSA sparse mode or extended LSA mode. The config>router>extended-lsa only command advertises the adjacency SID sub-TLV in the extended LSA format in both cases.

• the SR-Algorithm TLV and the SID/Label range TLV

  Both of these TLVs are part of the TLV-based OSPFv3 Router Information Opaque LSA defined in RFC 7770.

OSPF has the ability to announce node Entropy Label Capability (ELC), the Maximum Segment Depth (MSD) for node Entropy Readable Label Depth (ERLD), and the Maximum Segment Depth (MSD) for node Base MPLS Imposition (BMI). If needed, exporting these OSPF extensions into BGP-LS requires no additional configuration. These extensions are standardized through draft-ietf-ospf-mpls-elc-12, Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF, and RFC 8476, Signaling Maximum SID Depth (MSD) Using OSPF.

The ELC, ERLD, and BMI OSPF values are announced automatically when entropy and segment routing is enabled on the router. The following configuration logic is used:

• ELC is automatically announced for host prefixes associated with a node SID when segment-routing and segment-routing entropy-label are enabled for OSPF.

• The router maximum node ERLD is announced for OSPF when segment-routing and segment-routing entropy-label is enabled together with advertise-router-capability.

• The router maximum node MSD-BMI for OSPF is announced when segment-routing advertise-router-capability are enabled.

• Exporting ELC, MSD-ERLD and MSD-BMI OSPF extensions into BGP-LS encoding occurs automatically when database-export for BGP-LS is configured.

• The announced value for maximum node MSD-ERLD and MSD-BMI can be modified to a smaller number using the override-bmi and override-erld commands. This can be useful when services (such as EVPN) or more complex link protocols (such as Q-in-Q) are deployed. Provisioning correct ERLD and BMI values helps controllers and local-cspf to construct valid segment routing label stacks to be deployed in the network.

Segment routing parameters are configured in the following context:

configure>router>ospf>segment-routing
configure>router>ospf>segment-routing>override-bmi value
configure>router>ospf>segment-routing>override-erld value

The router supports the MPLS entropy label, as specified in RFC 6790, on OSPF segment-routed tunnels. LSR nodes in a network can load-balance labeled packets in a more granular way than by hashing on the standard label stack. See the MPLS Guide for more information.

Announcing of Entropy Label Capability (ELC) is supported, however, processing of ELC signaling is not supported for OSPF segment-routed tunnels. Instead, ELC is configured at the head-end LER using the configure router ospf entropy-label override-tunnel-elc command. This command causes the router to ignore any advertisements for ELC that may or may not be received from the network, and to assume that the whole domain supports entropy labels.

This feature supports SR IPv6 tunnels in OSPFv3 instances 0 to 31. The user can configure a node SID for the primary IPv6 global address of a loopback interface, which then gets advertised in OSPFv3. OSPFv3 automatically assigns and advertises an adjacency SID for each adjacency with an IPv6 neighbor. After the node SID is resolved, it is used to install an IPv6 SR-OSPF3 tunnel in the TTMv6 for use by the routes and services.

The mapping server feature configures and advertises, in OSPF, of the node SID index for prefixes of routers which are in the LDP domain. This is performed in the router acting as a mapping server and using a prefix-SID sub-TLV within an OSPF Extended Prefix Range TLV.

Use the following command syntax to configure the SR mapping database in OSPF:

configure
        — router
            — [no]ospf
                — segment-routing
                — no segment-routing
                    — mapping-server
                        — sid-map node-sid {index value 0 to 4294967295 [range value 1 to 65535]} prefix {{ip-address/mask}|{netmask}}[scope {area area-id | as}]
                        — no sid-map node-sid index value

The user enters the node SID index, for one prefix or a range of prefixes, by specifying the first index value and, optionally, a range value. The default value for the range option is 1. Only the first prefix in a consecutive range of prefixes must be entered. If the user enters the first prefix with a mask lower than 32, the OSPF Extended Prefix Range TLV is advertised but a router that receives the OSPF Extended Prefix Range TLV does not resolve the SID and instead generates a trap.

The no form of the sid-map command deletes the range of node SIDs beginning with the specified index value. The no form of the mapping-server command deletes all node SID entries in the OSPF instance.

Use the scope option to specify the flooding scope of the mapping server for the generated OSPF Extended Prefix Range TLV. There is no default value. If the scope is a specific area, the TLV is flooded only in that area.

An ABR that propagates an intra-area OSPF Extended Prefix Range TLV flooded by the mapping server in that area into other areas sets the inter-area flag (IA-flag). The ABR also propagates the TLV if it is received with the inter-area flag set from other ABR nodes but only from the backbone to leaf areas and not leaf areas to the backbone. However, if the identical TLV was advertised as an intra-area TLV in a leaf area, the ABR does not flood the inter-area TLV into that leaf area.

Each time a prefix or a range of prefixes is configured in the SR mapping database in any routing instance, the router issues for this prefix, or range of prefixes, a prefix-SID sub-TLV within an OSPF Extended Prefix Range TLV in that instance. The flooding scope of the TLV from the mapping server is determined as previously described. The reachability of that prefix in the mapping server route table is not checked. Additionally, the SR OS does not check whether the SID index is a duplicate of an existing prefix in the local IGP instance database or if the SID index is out of range with the local SRGB.

The MTU of an SR tunnel populated into TTM is determined like an IGP tunnel; for example, LDP LSP is based on the outgoing interface MTU minus the label stack size. Segment routing, however, supports remote LFA and TI-LFA, which can program an LFA repair tunnel by adding one or more labels.

To configure the MTU of all SR tunnels within each IGP instance:

config>router>isis>segment-routing>tunnel-mtu bytes bytes
config>router>ospf>segment-routing>tunnel-mtu bytes bytes

There is no default value for this command. If the user does not configure an SR tunnel MTU, the MTU is determined by IGP as described below.

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

Where:

• Cfg_SR_MTU is the MTU configured by the user for all SR tunnels within an IGP instance using the CLI shown above. If no value was configured by the user, the SR tunnel MTU is determined by the IGP interface calculation.

• 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 this SR tunnel.

• frr-overhead is set the following parameters:

  • 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

  • otherwise, it is set to 0

The SR tunnel MTU is dynamically updated anytime any of the parameters used in its calculation change. This includes when the set of the tunnel next-hops changes or the user changes the configured SR MTU or interface MTU value.

An adjacency set is a bundle of adjacencies, represented by a common adjacency SID for the bundled set. It enables, for example, a path for an SR-TE LSP through a network to be specified while allowing the local node to spray packets across the set of links identified by a single adjacency SID.

SR OS supports both parallel adjacency sets (for example, those where adjacencies originating on one node terminate on a second, common node), and the ability to associate multiple interfaces on a specified node, irrespective of whether the far end of the respective links of those interfaces terminate on the same node.

An adjacency set is created under IS-IS or OSPF using the following CLI commands:

config
   router
      isis | ospf
         segment-routing
            [no] adjacency-set id
               family [ipv4 | ipv6]
               parallel [no-advertise]
               no parallel
               exit
...
.              exit
            exit
config
   router
      ospf
         segment-routing
            [no] adjacency-set id
               parallel [no-advertise]
               no parallel
               exit
...
. 
            exit

The adjacency-set id command specifies an adjacency set, where id is an unsigned integer from 0 to 4294967295.

In IS-IS, each adjacency set is assigned an address family, IPv4 or IPv6. The family command for IS-IS indicates the address family of the adjacency set. For OSPF, the address family of the adjacency set is implied by the OSPF version and the instance.

The parallel command indicates that all members of the adjacency set must terminate on the same neighboring node. When the parallel command is configured, the system generates a trap message if a user attempts to add an adjacency terminating on a neighboring node that differs from the existing members of the adjacency set. See Associating an interface with an adjacency set for details about how to add interfaces to an adjacency set. The system stops advertising the adjacency set and deprograms it from TTM. The parallel command is enabled by default.

By default, parallel adjacency sets are advertised in the IGP. The no-advertise option prevents a parallel adjacency set from being advertised in the IGP; it is only advertised if the parallel command is configured. To prevent issues in the case of ECMP if a non-parallel adjacency set is used, an external controller may be needed to coordinate the label sets for SIDs at all downstream nodes. As a result, non-parallel adjacency sets are not advertised in the IGP. The label stack below the adjacency set label must be valid at any downstream node that exposes it, even though it is sprayed over multiple downstream next-hops.

Parallel adjacency sets are programmed in TTM (unless there is an erroneous configuration of a non-parallel adjacency). Non-parallel adjacency sets are not added to TTM or RTM, meaning they cannot be used as a hop at the originating node. Parallel adjacency sets that are advertised are included in the link-state database and TE database, but non-parallel adjacency sets are not included because they are not advertised.

An adjacency set with only one next hop is also advertised as an individual adjacency SID with the S flag set. However, the system does not calculate a backup for an adjacency set even if it has only one next hop.

The Topology-Independent LFA (TI-LFA) feature improves the protection coverage of a network topology by computing and automatically instantiating a repair tunnel to a Q node which is not in the shortest path from the computing node. The repair tunnel uses the shortest path to the P node and a source-routed path from the P node to the Q node.

In addition, the TI-LFA algorithm selects the backup path that matches the post-convergence path. This helps capacity planning in the network because traffic always flows on the same path when transitioning to the FRR next hop and then on to the new primary next hop.

At a high level, the TI-LFA link protection algorithm searches for the closest Q node to the computing node and then selects the closest P node to this Q node, up to a maximum number of labels. This is performed on each of the post-convergence paths to each destination node or prefix D.

When the TI-LFA feature is enabled in IS-IS, it provides a TI-LFA link-protect backup path in IS-IS MT=0 for an SR-ISIS IPV4/IPv6 tunnel (node SID and adjacency SID), for an IPv4 SR-TE LSP, and for LDP IPv4 FEC when the LDP fast-reroute backup-sr-tunnel option is enabled.

This feature extends the Remote LFA and TI-LFA features by adding support for node protection. The extensions are additions to the original link-protect LFA SPF algorithm.

When node protection is enabled, the router prefers a node-protect over a link-protect repair tunnel for a prefix if both are found in the Remote LFA or TI-LFA SPF computations. This feature protects against the failure of a downstream node in the path of the prefix of a node SID except for the node owner of the node SID.

One of the challenges in MPLS deployments across multiple IGP areas or domains, such as in seamless MPLS design, is the provisioning of FRR local protection in access and metro domains that make use of a ring, a square, or a partial mesh topology. To implement IP, LDP, or SR FRR in these topologies, the remote LFA feature must be implemented. Remote LFA provides a Segment Routing (SR) tunneled LFA next hop for an IP prefix, an LDP tunnel, or an SR tunnel. For prefixes outside of the area or domain, the access or aggregation router must push four labels: service label, BGP label for the destination PE, LDP/RSVP/SR label to reach the exit ABR/ASBR, and one label for the remote LFA next hop. Small routers deployed in these parts of the network have limited MPLS label stack size support.

Label stack for remote LFA in ring topology illustrates 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 FRR requires up to four labels to be pushed by AGN2, as shown in Label stack for remote LFA in ring topology.

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 ensures that the label stack of the LFA next hop is the same size as that of the primary next hop and of the remote LFA next hop for the local prefix within the ring.

When the hash-label option is enabled in a service context, hash label is always inserted at the bottom of the stack as per RFC 6391.

The LSR adds the capability to check a maximum of 16 labels in a stack. The LSR is able to hash on the IP headers when the payload below the label stack of maximum size of 16 is IPv4 or IPv6, including when a MAC header precedes it (eth-encap-ip option).

The Entropy Label (EL) feature, as specified in RFC 6790, is supported on RSVP, LDP, segment-routed, and BGP transport tunnels. It uses the Entropy Label Indicator (ELI) to indicate the presence of the entropy label in the label stack. The ELI, followed by the actual entropy label, is inserted immediately below the transport label for which entropy label feature is enabled. If multiple transport tunnels have the entropy label feature enabled, the ELI/EL is inserted below the lowest transport label in the stack.

The LSR hashing operates as follows:

• If the lbl-only hashing option is enabled, or if one of the other LSR hashing options is enabled but a IPv4 or IPv6 header is not detected below the bottom of the label stack, the LSR hashes on the EL only.

• If the lbl-ip option is enabled, the LSR hashes on the EL and the IP headers.

• If the ip-only or eth-encap-ip is enabled, the LSR hashes on the IP headers only.

For more information about the Hash Label and Entropy Label features, see the ‟MPLS Entropy Label and Hash Label” section of the 7450 ESS, 7750 SR, 7950 XRS, and VSR MPLS Guide.

The following command enables the micro-loop avoidance feature within each IGP instance:

config>router>isis>segm-rtng# micro-loop-avoidance
    — micro-loop-avoidance [fib-delay fib-delay]
    — no micro-loop-avoidance

fib-delay : [1..300] - default: 15, in 100s of milliseconds

The fib-delay timer should be configured to a value that corresponds to the worst-case IGP convergence in a network domain. The default value of 1.5 seconds (1500 milliseconds) corresponds to a network with a nominal convergence time.

When this feature is disabled using the no micro-loop-avoidance command, any active FIB delay timer is forced to expire immediately and the new next hops are programmed for all impacted node SIDs. The feature is disabled for the next SPF runs.

When this feature is enabled, the following scenarios apply:

• IS-IS MT=0 for a SR-ISIS IPv4/IPv6 tunnel (node SID)

• IPv4 and IPv6 SR-TE LSP that use a node SID in their segment list

• IPv4 and IPv6 SR policy that use a node SID in their segment list

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 for only 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 SPFs (base LFA, remote LFA, and, 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 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 and, or metrics, 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, 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, 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.

   • 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. The new primary next hops are programmed for node SID routes that are marked eligible for the micro-loop avoidance procedure upon the expiration of the fib-delay timer.

The following figure shows an example of link addition or restoration in a network topology.

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

1. Link 7-6 is added to the topology.

2. Router 3 detects a single link addition between remote nodes 7 and 6.

3. Router 3 runs the main and LFA SPFs.

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

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

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

4. For all nodes downstream from the added link, the algorithm computes and activates an SR tunnel that forces traffic to remote endpoint 6 of the added link.

   The algorithm pushes node SID 7 and adjacency SID of link 7-6 in the SR IS-IS tunnel for these nodes.

5. The use of the adjacency SID of link 7-6 skips the FIB state on node 7 and traffic to all nodes downstream of 6 are not impacted by micro-loop convergence.

6. The same method applies to metric decrease of link 7-6 that causes traffic to be attracted to that link.

In this mode of operation, the user configures the LSP name, primary path name and optional 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 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 an address of a loopback address, it is translated into an adjacency SID as described below and therefore does not guarantee that the same specific TE link is picked.

MPLS assigns a Tunnel-ID to the SR-TE LSP and a path-ID to each new instantiation of the primary or secondary path. These IDs represent both the MBB path and the original path of an SR-TE LSP, which both exist during the process of an MBB update of the primary path.

The router retains full control of the path of the LSP. The LSP path label stack size is checked by MPLS against the maximum value configured for the LSP after the TE-DB returns the label stack. See Service and shortcut application SR-TE label stack check for more information about this check.

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

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 outgoing interface and next hop where the packet is to be forwarded and programs the data path according to the following conditions:

   • If the first hop corresponds to an adjacency SID (host address of next hop on the link’s subnet), the adjacency SID label is not pushed. In other words, 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 some downstream router, then 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 which has the pce-report option enabled. 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 Path Computation Element Communication Protocol (PCEP) to communicate with a PCE-based external TE controller (also referred to as the PCE). The router instantiates a PCEP session to the PCE. The router is referred to as the PCE Client (PCC).

The following PCE control modes are supported:

Passive Control Mode

In this mode, the user enables the path-computation-method pce command for one or more SR-TE LSPs and 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 a SR-TE LSP, the router implements the extensions to PCEP in support of segment routing (see the PCEP section for more information).This feature works with the Nokia stateful PCE, which is part of the NSP.

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

1. The SR-TE LSP configuration is created on the PE router via CLI or via OSS/SAM. The configuration dictates which PCE control mode is needed: active (pce-control option 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 uniquely identifies the LSP on a PCEP session and must remain constant during its lifetime. 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 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. 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 database.

6. The PE router updates the CPM and the data path with the new path.

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

7. 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 re-optimization, 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 data path with the new path.

10. The PE router sends a new PCRpt message to update 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 any configuration change to the PCE-computed or PCE-controlled LSP, MPLS requests PCC to first revoke delegation in a PCRpt message (PCE-controlled only), and then MPLS and PCC follow the above steps to convey the changed constraint to PCE, which results in a new path programmed into the data path, the LSP databases of PCC and PCE to be synchronized, and the delegation to be returned to PCE.

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

The following steps are followed for an LSP with an active path:

• If the user enabled the path-computation-method pce option on a PCC-controlled LSP which has an active path, no action is performed until the next time the router needs a path for the LSP following a network event of an LSP parameter change. At that point the procedures above are followed.

• If the user enabled the pce-control option on a PCC-controlled or PCE-computed LSP which has an active path, PCC issues a PCRpt message to PCE with the state of up and the RRO of the active path. It sets delegation control flag to delegate control to PCE. PCE keeps the active path of the LSP and does not update until the next network event or re-optimization. At that point the procedures above are followed.

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

The association of the optional path group ID is to allow PCE determine which profile ID this path group ID must be used with. One path group ID is allowed per profile ID. The user can, however, enter the same path group ID with multiple profile IDs by executing this command multiple times. A maximum of five entries of path-profile [path-group] can be associated with the same LSP. More details of the operation of the PCE path profile are provided in the PCEP section of this guide.

The following are the MPLS and TE database features for extending CSPF support to SR-TE LSP:

• Supports IPv4 SR-TE LSP.

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

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

• Supports 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 is 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.

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

• Provides 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.

• Uses 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.

• Uses 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.

• Supports using unnumbered interfaces in the path computation. There is no support for configuring an unnumbered interface as a hop in the path of the LSP is not required. So, 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.

• Supports 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. Thus, 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.

With the RSVP-TE LSP feature, the TE-DB only populates OSPFv2 local and remote TE-enabled links. 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 a SRLG or an Admin-Group.

The SR-TE LSP path computation supports using SR-enabled links which may or may not have TE attributes and therefore the TE-DB is enhanced with, the following changes:

• OSPFv2 is modified to pass all links, regardless if they are TE-enabled or SR-enabled, to 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 change, 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 which uses this interface does not go operationally down.

The local CSPF for an SR-TE LSP is performed in two phases. The first phase (Phase 1) computes a fully explicit path with all TE links to the destination specified as in the case of a RSVP-TE LSP.

If the user enabled label stack reduction or compression for this LSP, a second phase (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 the first phase remains mostly unchanged from its behavior for an RSVP-TE LSP.

The meaning of a strict and loose hop in the path of the LSP are the same as in CSPF for an 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, it is possible that a strict hop is 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 wherein 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 and which label stack may contain protected adjacency SIDs, unprotected adjacency SIDs, and adjacency set SIDs. The user can influence the type of adjacency protection for the SR-TE LSP using a CLI command as described in SR-TE LSP path protection.

The 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.

Each path may be locally protected through the network using LFA/remote-LFA nexthop whenever possible. The protection of a SID node re-uses the LFA and remote LFA features introduced with segment routing shortest path tunnels; the protection of an adjacency SID has been added to the SR OS in the specific context of an SR-TE LSP to augment the protection level. The user must enable the loopfree-alternates remote-lfa option in IS-IS or OSPF.

This behavior is already supported in the SR shortest path tunnel feature at both LER and LSR. As such, 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 data path, while 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 configures 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, then 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 may 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 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.

For more details of end to end protection of SR-TE LSPs with S-BFD, see section Seamless BFD for SR-TE LSPs.

For PCC-initiated or PCC-controlled LSPs, an operator can configure an S-BFD session under the bfd context of SR-TE LSP, the primary path, the SR-TE secondary path, and the lsp-template by using:

• Classic CLI commands

  config>router>mpls>lsp bfd

  config>router>mpls >lsp>primary bfd

  config>router>mpls>lsp>secondary bfd

  config>router>mpls>lsp-template bfd

• MD-CLI commands

  configure router mpls lsp bfd

  configure router mpls lsp primary bfd

  configure router mpls lsp secondary bfd

  configure router mpls lsp-template bfd

The operator can configure S-BFD to operate in one of the following modes:

• routed return path

  In this mode, the session initiator sends BFD packets on the LSP toward the reflector node. The reflector node sends the BFD reply packet back to the initiator through a routed return path. The remote discriminator value is determined by passing the ‟to” address of the LSP to BFD, which then matches it to a mapping table of peer IP addresses to reflector remote discriminators that are created by the centralized configuration under the IGP. If no match for the ‟to” address of the LSP exists, a BFD session is not established on the LSP or path. For more information, see the 7450 ESS, 7750 SR, 7950 XRS, and VSR OAM and Diagnostics Guide.

  Note: A remote peer IP address to discriminator mapping must exist before bringing an LSP administratively up.

• controlled return path

  In this mode, operators configure a return path label for the BFD session to the initiator. The router pushes an additional MPLS label on S-BFD packets at the bottom of the stack and the BFD session operates in echo mode. The return path label refers to an MPLS binding SID of an SR policy programmed at the far end of the SR-TE LSP. The operator can use this SR policy to forward S-BFD reply packets along an explicit TE path back to the initiator, avoiding the IGP shortest path. The operator can configure different LSPs or LSP paths using different return path labels referring to different SR policies at the LSP far end. The SR policies can have segment lists with different paths, ensuring the BFD reply packets from different LSP paths do not share the same outcome. S-BFD packets on these sessions bypass the reflector at the far end of the LSP. Therefore, the operator does not need to configure a reflector discriminator for these sessions.

The referenced BFD template must specify parameters consistent with an S-BFD session. For example, the endpoint type is cpm-np for platforms supporting a CPM P-chip; otherwise, a CLI error is generated. Operators can use the same BFD template for both S-BFD and any other type of BFD session requested by MPLS.

If S-BFD is configured at the LSP level, sessions are created on all paths of the LSP.

• Classic CLI commands

  config>router>mpls
     lsp-template name on-demand-p2p-srte template-id
        bfd
          bfd-enable
          bfd-template name
          return-path-label label value
          wait-for-up-timer seconds
  

• MD-CLI commands

  *[gl:/configure router "Base" mpls lsp-template name]
                    type p2p-sr-te-on-demand
                    bfd              
                        bfd-liveness {true|false}
                        bfd-template reference
                        return-path-label number
                        wait-for-up-timer number

Operators can also configure S-BFD on the primary or a specific secondary path of the LSP, as follows:

• Classic CLI commands

  config>router>mpls>lsp name sr-te
     primary name
        bfd
          bfd-enable
          bfd-template name
          return-path-label label
          wait-for-up-timer seconds
          exit
  

  config>router>mpls>lsp name sr-te
     secondary name
        bfd
          bfd-enable
          bfd-template name
          return-path-label label
          wait-for-up-timer seconds
          exit
        
  

• MD-CLI commands

  *[gl:/configure router "Base" mpls lsp name primary name]
                  bfd
                    bfd-liveness {true|false}
                    bfd-template reference
                    return-path-label number
                    wait-for-up-timer number
                    exit

  *[gl:/configure router "Base" mpls lsp name secondary name]
                  bfd
                    bfd-liveness {true|false}
                    bfd-template reference
                    return-path-label number
                    wait-for-up-timer number
                    exit

The wait-for-up-timer is only applicable if a failure action is configured using the failover-or-down command. For more information, see Support for BFD failure action with SR-TE LSPs.

For PCE-initiated LSPs and SR-TE auto-LSPs, the operator specifies the S-BFD session parameters in the LSP template. The ‟to” address used for determining the remote discriminator is derived from the far-end address of the auto-LSP or PCE-initiated LSP.

• Classic CLI commands

  config>router>mpls
     lsp-template name mesh-p2p-srte 
        bfd
          bfd-enable
          bfd-template name
          wait-for-up-timer seconds
  

  config>router>mpls
     lsp-template name one-hop-p2p-srte 
        bfd
          bfd-enable
          bfd-template
          wait-for-up-timer seconds
  

  config>router>mpls
     lsp-template name on-demand-p2p-srte 
        bfd
          bfd-enable
          bfd-template name
          wait-for-up-timer seconds
  

• MD-CLI commands

  *[gl:/configure router "Base" mpls lsp-template name]
                    type p2p-sr-te-mesh
                    bfd
                      bfd-liveness {true|false}
                      bfd-template reference
                      wait-for-up-timer number
  

  *[gl:/configure router "Base" mpls lsp-template name]
                    type p2p-sr-te-one-hop
                    bfd
                      bfd-liveness {true|false}
                      bfd-template reference
                      wait-for-up-timer number
  

  *[gl:/configure router "Base" mpls lsp-template name]
                    type p2p-sr-te-on-demand
                    bfd
                      bfd-liveness {true|false}
                      bfd-template reference
                      wait-for-up-timer number

SR OS supports the configuration of a failure-action of type failover-or-down for SR-TE LSPs. The failure-action command is configured at the LSP level or in the LSP template. It can be configured whether S-BFD is applied at the LSP level or the individual path level.

For LSPs with a primary path and a standby or secondary path and failure-action of type failover-or-down:

• A path is held in an operationally down state when its S-BFD session is down.

• If all paths are operationally down, then the SR-TE LSP is taken operationally down and a trap is generated.

• If S-BFD is enabled at the LSP or active path level, a switchover from the active path to an available path is triggered on failure of the S-BFD session on the active path (primary or standby).

• If S-BFD is not enabled on the active path, and this path is shut down, then a switchover is triggered.

• If S-BFD is enabled on the candidate standby or secondary path, then this path is only selected if S-BFD is up.

• An inactive standby path with S-BFD configured is only considered as available to become active if it is not operationally down; for example, if the S-BFD session is up and all other criteria for it to become operational are true. It is held in an inactive state if the S-BFD session is down.

• The system does not revert to the primary path nor start a reversion timer when the primary path is either administratively down or operationally down because the S-BFD session is not up or down for any other reason.

For LSPs with only one path and failure-action of type failover-or-down:

• A path is held in an operationally down state when its S-BFD session is down.

• If the path is operationally down, then the LSP is taken operationally down and a trap is generated.

  Note: S-BFD and other OAM packets can still be sent on an operationally down SR-TE LSP.

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 of the next hop of an LSP path at the head end must be avoided. It is therefore recommended that LFA is not configured at the head end LER when using S-BFD 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 a TE-LSP the maximum LSP metric value of 16777215 when the local router provides the hop-to-label translation for its path. For a TE-LSP that uses the local CSPF or the PCE for path computation (path-computation-method pce option enabled) by PCE and, or which has its control delegated to PCE (pce-control enabled), the latter returns the computed LSP IGP or TE metric in the PCReq and PCUpd messages. In both cases, the user can override the returned value by configuring an admin metric using the command config>router>mpls>lsp>metric.

• The MTU setting of a 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 are the details of this calculation:

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

  Where:

  • Cfg_SR_MTU is the MTU configured by the user for all SR tunnels within an IGP instance using config>router>ospf/isis>segment-routing>tunnel-mtu. If no value was configured by the user, the SR tunnel MTU is fully determined by the IGP interface calculation (described below).

  • 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 this 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 it changes because of an updated resolution of the node SID.

  SR OS also provides the MTU for adjacency SID tunnel because it is needed in a SR-TE LSP if the first hop in the ERO is an adjacency SID. In that case, this calculation for SR_Tunnel_MTU, initially introduced for a node SID tunnel, is applied to get 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 the SR-TE LSP is riding. The formula is as specified above.

  • numLabels is the number of labels found in the super NHLFE of the SR-TE LSP. Note that at LER, the super NHLFE is pointing to the SR tunnel NHLFE, which itself has a primary and a backup NHLFEs.

  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. For the purpose of fragmentation of IP packets forwarded in GRT or in a VPRN over a SR-TE LSP, the data path always deducts the worst case MTU (12 labels) from the outgoing interface MTU for the decision to fragment or not the packet. In this case, the above formula is not used.

The LSR supports hashing up to a maximum of 16 labels in a stack. The LSR is able to hash on the IP headers when the payload below the label stack is IPv4 or IPv6, including when a MAC header precedes it (ethencap-ip option). Alternatively, it is able to hash based only on the labels in the stack, which may include the entropy label (EL) or the hash label. See the 7450 ESS, 7750 SR, 7950 XRS, and VSR MPLS Guide for more information about the hash label and entropy label features.

When the hash-label option is enabled in a service context, a hash label is always inserted at the bottom of the stack as per RFC 6391.

The EL feature, as specified in RFC 6790, indicates the presence of a flow on an LSP that should not be reordered during load balancing. It can be used by an LSR as input to the hash algorithm. The Entropy Label Indicator (ELI) is used to indicate the presence of the EL in the label stack. The ELI, followed by the actual EL, is inserted immediately below the transport label for which the EL feature is enabled. If multiple transport tunnels have the EL feature enabled, the ELI and EL are inserted below the lowest transport label in the stack.

The EL feature is supported with an SR-TE LSP. See the 7450 ESS, 7750 SR, 7950 XRS, and VSR MPLS Guide for more information.

The LSR hashing operates as follows:

• If the lbl-only hashing option is enabled, or if one of the other LSR hashing options is enabled but an IPv4 or IPv6 header is not detected below the bottom of the label stack, the LSR parses the label stack and hashes only on the EL or hash label.

• If the lbl-ip option is enabled, the LSR parses the label stack and hashes on the EL or hash label and the IP headers.

• If the ip-only or eth-encap-ip is enabled, the LSR hashes on the IP headers only.

This feature behaves the same way as the RSVP-TE auto-LSP using an LSP template of type mesh-p2p.

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 never 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 = the name of the template

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

• TunnelId = 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. Range:

  • for provisioned SR-TE LSP, 65536 to 81920

  • for SR-TE auto-LSP, 81921 to 131070

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

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

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

This feature like the RSVP-TE auto-LSP using an LSP template of one-hop-p2p type. 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 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

In this case, 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 independent 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 and so, does also not protect 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 that of the default path specified in the LSP template.

The SR-TE on-demand LSP simplifies provisioning for networks that may or may not be managed by a network service manager, such as the Nokia NSP. Instead of using a full mesh, LSPs can be automatically created on-demand when a suitable tunnel does not exist for a specific BGP prefix next hop. The prefix could be for VPRN, EVPN, BGP-LU, or BGP shortcut routes. Both intradomain and inter-domain use cases are supported.

The following figure shows an application of SR-TE on-demand LSPs.

This example combines route transport coloring and auto LSPs to simplify provisioning for intent-based networking for specific services. In this use case, intent means the ability to meet traffic engineering requirements for a service. This could be, for example, a delay or loss, or the ability to steer the service traffic to avoid LSPs that transit specific geographies or prefer those that take another route.

In this example, a BGP route is advertised for a VRF in a PE for a VPRN service. An extended color community is assigned to the route. This color implies an intent associated with the transport requirements.

This causes the head-end router to create an SR-TE auto-LSP that matches the red-lsps admin-tag policy and steers the traffic associated with "red" routes to the far-end PE, into the red LSP. This SR-TE auto-LSP is created based on the configuration in the matching LSP template.

SR OS also offers the ability to use the local CSPF, hop-to-label-translation, or a PCE to provide a path for the red LSP. This is determined by a configuration in the matching LSP template.

Template-based SR-TE auto-LSPs, with the exception of on-demand SR-TE LSPs, can only be operated as a PCC-controlled LSP. They can, however, be reported to the PCE using the pce-report command. They 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.

The following are the forwarding contexts that can be used by an auto-LSP:

• resolution of IPv4 BGP label routes and IPv6 BGP label routes (6PE) in TTM

• resolution of IPv4 BGP route in TTM (BGP shortcut)

• resolution of IPv4 static route to indirect next hop in TTM

• VPRN and BGP-EVPN auto-bind for both IPv4 and IPv6 prefixes

The auto-LSP is, however, not available to be used in a provisioned SDP for explicit binding by services. Therefore, an auto-LSP can also not be used directly for auto-binding of a PW template with the use-provisioned-sdp option in BGP-AD VPLS or FEC129 VLL service. However, an auto-binding of a PW template to an LDP LSP, which is then tunneled over an SR-TE auto-LSP is supported.

If a packet forwarded in a service or a shortcut application has resulted 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 adds the additional, context-specific labels, such as service label, entropy/hash label, and control-word, required to forward the packet in that context and to 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 is bound or the prefix is resolved to the SR-TE LSP.

If the check fails, the service does not bind to this SR-TE LSP. Instead, it either finds another SR-TE LSP or another tunnel of a different type to bind to, if the user has configured the use of other tunnel types. Otherwise, the service goes down. When the service uses a 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 does not get 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 parameter frr-overhead. This parameter is computed within an IGP instance as described in frr-overhead parameter values .

When the user configures or changes the configuration of additional-frr-labels, MPLS ensures that the new value accommodates the frr-overhead value across all IGP instances.

Example:

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

2. The user creates a new SR-TE LSP or changes the configuration of an existing 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 result is lower 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 tries a configuration change that results in a change to the computed frr-overhead, IGP checks that all SR-TE LSPs can properly account for the overhead or the change is rejected. On the IGP, enabling remote-lfa may cause the frr-overhead to change.

Example:

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

• The current configuration in IS-IS has the loopfree-alternates command disabled.

• The user attempts to configure

  isis>loopfree-alternates remote-lfa. This changes frr-overhead to 1.

  This configuration change is blocked.

As described in Data path 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.

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

The total number of labels configured in the command max-sr-labels label-stack-size [additional-frr-labels labels] must not exceed the labels indicated in the "Maximum available transport labels with/without options" rows in Label stack egress IOM restrictions on FP-based hardware for IPVPN and EVPN services . If the configured LSP labels exceed the available labels in the 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. Maximum available transport labels for IP shortcuts and spoke SDP services 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.

To enable the advertisement of additional link IPv6 and TE parameters, a new traffic-engineering-options CLI construct is used.

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 existing traffic-engineering command continues its role as the main command for enabling TE in an IS-IS instance. This command enables the advertisement of the IPv4 and TE link parameters using the legacy TE encoding as per 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 also enabled, then 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 still supported but can be disabled by using the no legacy command that enables the per-application TE attribute advertisement for RSVP-TE as well.

Additional details of the feature behavior and the interaction of the previously mentioned CLI commands are described in IS-IS IPv4 and IPv6 SR-TE and IPv4 RSVP-TE feature behavior.

IS-IS control plane extensions add support for the following RFC 6119 TLVs in IS-IS advertisements and in 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 advertising which protocol is enabled on a TE-link (SR-TE, RSVP-TE, or both) by using the Application Specific Link Attributes (ASLA) sub-TLV as per RFC 8919. This causes the advertising router to send potentially different Link TE attributes for RSVP-TE and SR-TE applications and allows the router receiving the link TE attributes to know which application 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 it.

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

The new 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, then this information is also added in the Enhanced TE-DB.

This feature adds the following enhancements to support advertising of the TE parameters in BGP-LS routes over a 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 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), then they are carried in the new BGP-LS ASLA TLV (TLV Type TBD) as per draft-ietf-idr-bgp-ls-app-specific-attr.

  • When a TE attribute of a link is advertised for both RSVP-TE and SR-TE 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 details are provided in IS-IS IPv4 and IPv6 SR-TE and IPv4 RSVP-TE feature behavior.

    • In 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 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 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 Legacy (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 Legacy (L) flag cleared and the specific application (RSVP-TE or SR-TE) flags set. This mode is also used to advertise the TE attributes for the SR-TE application when RSVP-TE is disabled on the router.

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

• exporting from the local BGP process to the local Enhanced TE-DB of IPv6 and TE link TLVs received from a BGP peer via BGP-LS route family enabled on a IPv4 or IPv6 transport BGP session

• support of 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).

   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, 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 ipv6 knob is also enabled, the RFC 6119 IPv6 and TE link TLVs described in the preceding bullet 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 LSPs and IPv4 SR-TE LSPs. The receiving node cannot determine if truly 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: IPv6 TE Router ID TLV, IPv6 Interface Address sub-TLV, and IPv6 Neighbor Address sub-TLV, or 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 knob 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 that are allowed by the application-link-attributes command.

   • legacy mode

     For legacy mode, use the no application-link-attributes command.

     The application-link-attributes command is disabled by default and the no form matches the behavior described in list item 2. It enables the existing traffic engineering behavior for IPv4 RSVP-TE and IPv4 SR-TE. Only the RSVP-TE attributes are advertised in the legacy TE TLVs that are used by both RSVP-TE and SR-TE LSP CSPF in the TE domain routers. No separate SR-TE attributes are advertised.

     If the ipv6 command is also enabled, the RFC 6119 IPv6 and TE link TLVs are advertised in the legacy TLVs. A router in the TE domain receiving these advertisements can compute paths for IPv6 SR-TE LSPs.

     If the user shuts down the rsvp context on the router or on a specific interface, the legacy TE attributes of all the MPLS interfaces or of that specific MPLS interface are not advertised. Routers can still compute SR-TE LSPs using those links but LSP path TE constraints are not enforced because the links appear in the TE Database as if they did not have TE parameters.

     Legacy link TE TLV support in TE-DB and BGP-LS shows the encoding of the legacy TE TLVs in both IS-IS and BGP-LS.

   • legacy mode with application indication

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

     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.

     IS-IS continues to advertise the legacy TE attributes for both RSVP-TE and SR-TE applications and includes the new Application Specific Link Attributes TLV with the application flag set to RSVP-TE or SR-TE but without the sub-sub-TLVs. IS-IS also advertises the Application Specific SRLG TLV with the application flag set to RSVP-TE or SR-TE but without the actual values of the SRLGs.

     Routers in the TE domain use these attributes to compute CSPF for IPv4 RSVP-TE LSP and IPv4 SR-TE LSP.

     If the ipv6 command is also enabled, the RFC 6119 IPv6 and TE TLVs are advertised. A router in the TE domain that receives 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 flag for the SR-TE application is not set in the Application Specific Link Attributes TLV or in the Application Specific SRLG TLV.

     To disable advertising of RSVP-TE attributes, shut down the rsvp context on the router.

     Note: Doing this reverts to advertising the link SR-TE attributes using the Application Specific Link Attributes TLV and the TE sub-sub-TLVs as shown in Details of link TE advertisement methods. If legacy attributes were used, legacy routers wrongly interpret that this router enabled RSVP and may signal RSVP-TE LSPs using its links.

     Legacy link TE TLV support in TE-DB and BGP-LS lists the code points for IS-IS and BGP-LS legacy TLVs.

     The following excerpt from the Link State Database (LSDB) shows the advertisement of TE parameters for a link with both RSVP-TE and SR-TE applications enabled.

   • 

   • 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 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 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 begins to advertise 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 RSVP-TE application and is sent separately.

     

     Routers in the TE domain use these attributes to compute CSPF for IPv4 SR-TE LSP 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, shut down the rsvp context on the router.

     Details of link TE advertisement methods summarizes the IS-IS link TE parameter advertisement details for the three modes of operation of the IS-IS advertisement.

     Table 13. Details of link TE advertisement methods

     IGP traffic engineering options		Link TE advertisement details
     		RSVP-TE (rsvp enabled on interface)	SR-TE (segment-routing enabled in IGP instance)	RSVP-TE and SR-TE (rsvp enabled on interface and segment-routing enabled in IGP instance)
     Legacy mode: Use the no application-link-attributes command.		Legacy TE TLVs	—	Legacy TE TLVs
     Legacy mode with application indication: Enable configure router isis traffic-engineering-options application-link-attributes legacy	rsvp disabled on router (rsvp operationally down on all interfaces)	—	Legacy TE TLVs ASLA TLV -Flags: {Legacy=0, SR-TE=1}; TE sub-sub-TLVs	Legacy TE TLVs ASLA TLV -Flags: {Legacy=1, RSVP-TE=0, SR-TE=1}
     	rsvp enabled on router	Legacy TE TLVs ASLA TLV -Flags: {Legacy=1, RSVP-TE=1}	Legacy TE TLVs ASLA TLV -Flags: {Legacy=1, SR-TE=1}	Legacy TE TLVs ASLA TLV -Flags: {Legacy=1, RSVP-TE=1, SR-TE=1}
     Application specific mode: Disable configure router isis traffic-engineering-options application-link-attributes legacy		ASLA TLV -Flags: {Legacy=0, RSVP-TE=1}; TE sub-sub-TLVs	ASLA TLV -Flags: {Legacy=0, SR-TE=1}; TE sub-sub-TLVs	ASLA TLV -Flags: {Legacy=0, RSVP-TE=1; SR-TE=1}; TE sub-sub-TLVs (common attributes) ASLA TLV -Flags: {Legacy=0, RSVP-TE=1}; TE sub-sub-TLVs (RSVP-TE specific attributes; for example, Unreserved BW and Resvble BW) ASLA TLV -Flags: {Legacy=0, SR-TE=1}; TE sub-sub-TLVs (SR-TE specific attributes; not supported in SR OS 19.10.R1)

This feature is supported with the hop-to-label, the local CSPF, and the PCE (PCC-initiated and PCE-initiated) path computation methods.

All capabilities of an IPv4 provisioned SR-TE LSP are supported with an IPv6 SR-TE LSP unless indicated otherwise. This section describes some important differences between an IPv4 and IPv6 SR-TE LSP support in MPLS.

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. The configuration fails.

A TE link with no global unicast IPv6 address and only a link local IPv6 address can be used in the path computation by the local CSPF. The address shown in the Computed Hops and in the Actual Hops fields of the output of the path show command uses the neighbor’s IPv6 TE router ID and the Link-Local Interface Identifiers sub-TLV. The exceptions are if the interface is of type broadcast or type point-to-point but also has a local IPv4 address. Only the neighbor’s IPv6 TE router ID is shown, as the Link-Local Interface Identifiers sub-TLV is not advertised in these situations.

The UP value of the global MPLS IPv4 state requires that the system interface be in the admin UP state and to have a valid IPv4 address.

The UP value of the global MPLS IPv6 state requires that the interface used for the IPv6 TE router ID be in admin UP state and to have a valid preferred primary IPv6 global unicast address.

The UP value of the TE interface MPLS IPv4 state requires the interface be in the admin UP state in the router context and the global MPLS IPv4 state be in UP state.

The UP value of the TE interface MPLS IPv6 state requires the interface be in the admin UP state in the router context and the global MPLS IPv6 state be in UP state.

Existing OSPFv2 TE-related link attribute advertisement (for example, bandwidth) definitions are used in RSVP-TE deployments (see draft-ietf-spring-segment-routing-policy-07.txt for more information). In the beginning only the RSVP-TE was using these TE-related link attributes, however additional applications (for example, Segment Routing Traffic Engineering (SR-TE)) emerged and require link attributes. The link attributes for these new applications may not always be identical as those advertised for RSVP-TE.

This usage has introduced ambiguity in deployments that include a mix of RSVP-TE and SR-TE support. For example, it is not possible to unambiguously indicate the specific advertisements used by RSVP-TE and SR-TE. Although this may not be an issue for fully congruent topologies, any incongruence causes ambiguity. An additional issue arises in cases where both applications are supported on a link but the link attribute values associated with each application differ. Advertisements without OSPFv2 application specific TE link attributes do not support the advertisement of application specific values for the same attribute on a specific link.

CLI syntax:

Config
   router
      ospf
         traffic-engineering-options
               sr-te {legacy|application-specific-link-attributes}
               no sr-te 

The traffic-engineering-options command enables the context to configure 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 still supported. In addition, the following configuration options are allowed:

no sr-te

advertises the TE information for RSVP links using TE Opaque LSAs. The no form is the default value.

sr-te legacy

advertises the TE information for MPLS-enabled SR links using TE Opaque LSAs

Note: The operator should not use the sr-te legacy option if the network has both RSVP-TE and SR-TE, and the links are not congruent.

sr-te application-specific-link-attributes

advertises the TE information for MPLS-enabled SR links using the new Application Specific Link Attributes (ASLA) TLVs

The RFC 8920 defines a subset of all possible TE extensions and TE Metric Extensions that can be encoded within Application Specific Link sub TLVs. Nokia support for ASLA extended link TLV encoding describes the relevant values for SR OS.

The solution proposed in the OSPF Link Traffic Engineering Attribute Reuse Draft (draft-ietf-ospf-te-link-attr-reuse-14.txt) assumes that OSPF does not need to move all RSVP-TE attributes from the TE Opaque LSA into the Extended Link LSA. For, RSVP-TE, consequently, there is no significant modification and it can continue to be advertised using existing OSPF TLVs. For SR-TE and future applications, the ASLA TLVs may be used. Alternatively, existing TE Opaque LSAs could be used through configuration. Configuration considerations for TE opaque LSAs describes the possible configurations for TE Opaque LSAs.