4. IS-IS

4.1. Configuring IS-IS

Intermediate-system-to-intermediate-system (IS-IS) is a link-state interior gateway protocol (IGP) which uses the Shortest Path First (SPF) algorithm to determine routes. Routing decisions are made using the link-state information. IS-IS evaluates topology changes and, if necessary, performs SPF recalculations.

Entities within IS-IS include networks, intermediate systems, and end systems. In IS-IS, a network is an autonomous system (AS), or routing domain, with end systems and intermediate systems. A router is an intermediate system. End systems are network devices which send and receive protocol data units (PDUs), the OSI term for packets. Intermediate systems send, receive, and forward PDUs.

End system and intermediate system protocols allow routers and nodes to identify each other. IS-IS sends out link-state updates periodically throughout the network, so each router can maintain current network topology information.

IS-IS supports large ASs by using a two-level hierarchy. A large AS can be administratively divided into smaller, more manageable areas. A system logically belongs to one area. Level 1 routing is performed within an area. Level 2 routing is performed between areas. The routers can be configured as Level 1, Level 2, or both Level 1/2.

Figure 15 displays an example of an IS-IS routing domain.

Figure 15:  IS-IS Routing Domain 

4.1.1. Routing

OSI IS-IS routing uses two-level hierarchical routing. A routing domain can be partitioned into areas. Level 1 routers know the topology in their area, including all routers and end systems in their area but do not know the identity of routers or destinations outside of their area. Level 1 routers forward traffic with destinations outside of their area to a Level 2 router in their area.

Level 2 routers know the Level 2 topology, and know which addresses are reachable by each Level 2 router. Level 2 routers do not need to know the topology within any Level 1 area, except to the extent that a Level 2 router can also be a Level 1 router within a single area. By default, only Level 2 routers can exchange PDUs or routing information directly with external routers located outside the routing domain.

In IS-IS, there are two types of routers:

  1. Level 1 intermediate systems — Routing is performed based on the area ID portion of the ISO address called the network entity title (NET). Level 1 systems route within an area. They recognize, based on the destination address, whether the destination is within the area. If so, they route toward the destination. If not, they route to the nearest Level 2 router.
  2. Level 2 intermediate systems — Routing is performed based on the area address. They route toward other areas, disregarding other area’s internal structure. A Level 2 intermediate system can also be configured as a Level 1 intermediate system in the same area.

The Level 1 router’s area address portion is manually configured (see ISO Network Addressing). A Level 1 router does not become a neighbor with a node that does not have a common area address. However, if a Level 1 router has area addresses A, B, and C, and a neighbor has area addresses B and D, then the Level 1 router accepts the other node as a neighbor, as address B is common to both routers. Level 2 adjacencies are formed with other Level 2 nodes whose area addresses do not overlap. If the area addresses do not overlap, the link is considered by both routers to be Level 2 only and only Level 2 LSPDUs flow on the link.

Within an area, Level 1 routers exchange LSPs which identify the IP addresses reachable by each router. Specifically, zero or more IP address, subnet mask, and metric combinations can be included in each LSP. Each Level 1 router is manually configured with the IP address, subnet mask, and metric combinations, which are reachable on each interface. A Level 1 router routes as follows:

  1. If a specified destination address matches an IP address, subnet mask, or metric reachable within the area, the PDU is routed via Level 1 routing.
  2. If a specified destination address does not match any IP address, subnet mask, or metric combinations listed as reachable within the area, the PDU is routed towards the nearest Level 2 router.

Level 2 routers include in their LSPs, a complete list of IP address, subnet mask, and metrics specifying all the IP addresses which reachable in their area. This information can be obtained from a combination of the Level 1 LSPs (by Level 1 routers in the same area). Level 2 routers can also report external reachability information, corresponding to addresses reachable by routers in other routing domains or autonomous systems.

4.1.2. IS-IS Frequently Used Terms

  1. Area — An area is a routing sub-domain which maintains detailed routing information about its own internal composition, and also maintains routing information which allows it to reach other routing sub-domains. Areas correspond to the Level 1 sub-domain.
  2. End system — End systems send NPDUs to other systems and receive NPDUs from other systems, but do not relay NPDUs. This International Standard does not specify any additional end system functions beyond those supplied by ISO 8473 and ISO 9542.
  3. Neighbor — A neighbor is an adjacent system reachable by traversing a single sub-network by a PDU.
  4. Adjacency — An adjacency is a portion of the local routing information which pertains to the reachability of a single neighboring end or intermediate system over a single circuit. Adjacencies are used as input to the decision process to form paths through the routing domain. A separate adjacency is created for each neighbor on a circuit and for each level of routing (Level 1 and Level 2) on a broadcast circuit.
  5. Circuit — The subset of the local routing information base pertinent to a single local Subnetwork Point of Attachments (SNPAs).
  6. Link — The communication path between two neighbors. A link is up when communication is possible between the two SNPAs.
  7. Designated IS — The intermediate system on a LAN which is designated to perform additional duties. In particular, the designated IS generates link-state PDUs on behalf of the LAN, treating the LAN as a pseudonode.
  8. Pseudonode — Where a broadcast sub-network has n connected intermediate systems, the broadcast sub-network itself is considered to be a pseudonode. The pseudonode has links to each of the n intermediate systems and each of the ISs has a single link to the pseudonode (rather than n-1 links to each of the other intermediate systems). Link-state PDUs are generated on behalf of the pseudonode by the designated IS.
  9. Broadcast sub-network — A multi-access subnetwork that supports the capability of addressing a group of attached systems with a single PDU.
  10. General topology sub-network — A topology that is modeled as a set of point-to-point links, each of which connects two systems. There are several generic types of general topology subnetworks, multipoint links, permanent point-to-point links, dynamic and static point-to-point links.
  11. Routing sub-domain — A routing sub-domain consists of a set of intermediate systems and end systems located within the same routing domain.
  12. Level 2 sub-domain — Level 2 sub-domain is the set of all Level 2 intermediate systems in a routing domain.

4.1.3. ISO Network Addressing

IS-IS uses ISO network addresses. Each address identifies a point of connection to the network, such as a router interface, and is called a Network Service Access Point (NSAP).

An end system can have multiple NSAP addresses, in which case the addresses differ only by the last byte (called the n-selector). Each NSAP represents a service that is available at that node. In addition to having multiple services, a single node can belong to multiple areas.

Each network entity has a special network address called a Network Entity Title (NET). Structurally, a NET is identical to an NSAP address but has an n-selector of 00. Most end systems have one NET. Intermediate systems can have up to three area IDs (area addresses).

NSAP addresses are divided into three parts. Only the area ID portion is configurable.

  1. Area ID — A variable length field between 1 and 13 bytes long. This includes the Authority and Format Identifier (AFI) as the most significant byte and the area ID.
  2. System ID — A six-byte system identification. This value is not configurable. The system ID is derived from the system or router ID.
  3. Selector ID — A one-byte selector identification that must contain zeros when configuring a NET. This value is not configurable. The selector ID is always 00.

Of the total 20 bytes comprising the NET, only the first 13 bytes, the area ID portion, can be manually configured. As few as one byte can be entered or, at most, 13 bytes. If less than 13 bytes are entered, the rest is padded with zeros.

Routers with common area addresses form Level 1 adjacencies. Routers with no common NET addresses form Level 2 adjacencies, if they are capable (Figure 16).

Figure 16:  Using Area Addresses to Form Adjacencies 

4.1.3.1. IS-IS PDU Configuration

The following PDUs are used by IS-IS to exchange protocol information:

  1. IS-IS hello PDU — Routers with IS-IS enabled send hello PDUs to IS-IS-enabled interfaces to discover neighbors and establish adjacencies.
  2. Link-state PDUs — Contain information about the state of adjacencies to neighboring IS-IS systems. LSPs are flooded periodically throughout an area.
  3. Complete sequence number PDUs — In order for all routers to maintain the same information, CSNPs inform other routers that some LSPs can be outdated or missing from their database. CSNPs contain a complete list of all LSPs in the current IS-IS database.
  4. Partial sequence number PDUs (PSNPs) — PSNPs are used to request missing LSPs and acknowledge that an LSP was received.

4.1.3.2. IS-IS Operations

The routers perform IS-IS routing as follows:

  1. Hello PDUs are sent to the IS-IS-enabled interfaces to discover neighbors and establish adjacencies.
  2. IS-IS neighbor relationships are formed if the hello PDUs contain information that meets the criteria for forming an adjacency.
  3. The routers can build a link-state PDU based upon their local interfaces that are configured for IS-IS and prefixes learned from other adjacent routers.
  4. The routers flood LSPs to the adjacent neighbors except the neighbor from which they received the same LSP. The link-state database is constructed from these LSPs.
  5. A Shortest Path Tree (SPT) is calculated by each IS, and from this SPT the routing table is built.

4.1.4. IS-IS Route Summarization

IS-IS IPv4 route summarization allows users to create aggregate IPv4 addresses that include multiple groups of IPv4 addresses for a given IS-IS level. IPv4 Routes redistributed from other routing protocols also can be summarized. It is similar to the OSPF area-range command. IS-IS IPv4 route summarization helps to reduce the size of the LSDB and the IPv4 routing table, and it also helps to reduce the chance of route flapping.

IPv4 route summarization supports:

  1. Level 1, Level 1-2, and Level 2
  2. Route summarization for the IPv4 routes redistributed from other protocols
  3. Metric used to advertise the summary address is the smallest metric of all the more specific IPv4 routes.

4.1.4.1. Partial SPF Calculation

IS-IS supports partial SPF calculation, also referred to as partial route calculation. When an event does not change the topology of the network, IS-IS is not perform full SPF but instead performs an IP reach calculation for the impacted routes. Partial SPF is performed at the receipt of IS-IS LSPs with changes to IP reach TLVs and in general, for any IS-IS LSP TLV and sub-TLV change that does not impact the network topology.

4.1.5. IS-IS MT-Topology Support

Multi-Topology IS-IS (MT-ISIS) support within SR OS allows for the creation of different topologies within IS-IS that contribute routes to specific route tables for IPv4 unicast, IPv6 unicast, IPv4 multicast, and IPv6 multicast. This capability allows for non-congruent topologies between these different routing tables. As a result, networks are able to control which links or nodes are to be used for forwarding different types of traffic.

For example, MT-ISIS could allow all links to carry IPv4 traffic, while only a subset of links can also carry IPv6 traffic.

SR OS supports the following Multi-Topologies:

  1. IPv4 Unicast – MT-ID 0
  2. IPv6 Unicast – MT-ID 2
  3. IPv4 Multicast – MT-ID 3
  4. IPv6 Multicast – MT-ID 4

4.1.5.1. Native IPv6 Support

IS-IS IPv6 TLVs for IPV6 routing is supported in SR OS. This support is considered native IPv6 routing within IS-IS. However, it has limitations in that IPv4 and IPv6 topologies must be congruent, otherwise traffic may be blackholed. Service providers should ensure that the IPv4 topology and IPv6 topologies are the same if native IPv6 routing is used within IS-IS.

4.1.6. IS-IS Administrative Tags

IS-IS admin tags enable a network administrator to configure route tags to tag IS-IS route prefixes. These tags can subsequently be used to control Intermediate System-to-Intermediate System (IS-IS) route redistribution or route leaking.

The IS-IS support for route tags allows the tagging of IP addresses of an interface and use the tag to apply administrative policy with a route map. A network administrator can also tag a summary route and then use a route policy to match the tag and set one or more attributes for the route.

Using these administrative policies allow the operator to control how a router handles the routes it receives from and sends to its IS-IS neighboring routers. Administrative policies are also used to govern the installation of routes in the routing table.

Route tags allow:

  1. Policies to redistribute routes received from other protocols in the routing table to IS-IS.
  2. Policies to redistribute routes between levels in an IS-IS routing hierarchy.
  3. Policies to summarize routes redistributed into IS-IS or within IS-IS by creating aggregate (summary) addresses.

4.1.6.1. Setting Route Tags

IS-IS route tags are configurable in the following ways:

  1. Setting a route tag for an IS-IS interface.
  2. Setting a route tag on an IS-IS passive interface.
  3. Setting a route tag for a route redistributed from another protocol to IS-IS.
  4. Setting a route tag for a route redistributed from one IS-IS level to another IS-IS level.
  5. Setting a route tag for an IS-IS default route.
  6. Setting a route tag for an IS-IS summary address.

4.1.6.2. Using Route Tags

Although an operator on this or on a neighboring IS-IS router has configured the setting of the IS-IS administrative tags, it does not have any effect unless policies are configured to instruct how to process the given tag value.

Policies can process tags where IS-IS is either the origin, destination or both origin and destination protocol.

config>router>policy-options>policy-statement>entry>from
     config>router>policy-options>policy-statement>entry>action tag tag-value
     config>router>policy-options>policy-statement# default-action tag tag-value

4.1.6.3. Unnumbered Interface Support

IS-IS supports unnumbered point-to-point interface with both Ethernet and PPP encapsulations.

Unnumbered interfaces borrow the address from other interfaces such as system or loopback interfaces and uses it as the source IP address for packets originated from the interface. This feature supports both dynamic and static ARP for unnumbered interfaces to allow interworking with unnumbered interfaces that may not support dynamic ARP.

An unnumbered interface is an IPv4 capability only used in cases where IPv4 is active (IPv4-only and mixed IPv4/IPv6 environments). When configuring an unnumbered interface, the interface specified for the unnumbered interface (system or other) must have an IPv4 address. Also, the interface type for the unnumbered interface automatically is point-to-point. The unnumbered option can be used in IES and VPRN access interfaces, as well as in a network interface with MPLS support.

4.1.7. Segment Routing in Shortest Path Forwarding

Segment routing adds to IS-IS and OSPF routing protocols the ability to perform shortest path routing and source routing using the concept of abstract segment. A segment can represent a local prefix of a node, a specific adjacency of the node (interface/next-hop), a service context, or a specific explicit path over the network. For each segment, the IGP advertises an identifier referred to as Segment ID (SID).

When segment routing is used together with MPLS data plane, the SID is a standard MPLS label. A router forwarding a packet using segment routing pushes one or more MPLS labels. This is the scope of the features described in this section.

Segment routing using MPLS labels can be used in both shortest path routing applications and in traffic engineering applications. This section focuses on the shortest path forwarding applications.

When a received IPv4 or IPv6 prefix SID is resolved, the Segment Routing module programs the ILM with a swap operation and also the LTN with a push operation both pointing to the primary/LFA NHLFE. An IPv4 or IPv6 SR tunnel to the prefix destination is also added to the TTM and is available for use by shortcut applications and L2/L3 services.

Segment routing introduces the remote LFA feature which expands the coverage of the LFA by computing and automatically programming SR tunnels which are used as backup next-hops. The SR shortcut tunnels terminate on a remote alternate node which provides loop-free forwarding for packets of the resolved prefixes. When the loopfree-alternates option is enabled in an IS-IS or OSPF instance, SR tunnels are protected with an LFA backup next-hop. If the prefix of a given SR tunnel is not protected by the base LFA, the remote LFA automatically computes a backup next-hop using an SR tunnel if the remote-lfa option is also enabled in the IGP instance.

4.1.7.1. Configuring Segment Routing in Shortest Path

The user enables segment routing in an IGP routing instance using the following sequence of commands.

First, the user configures the global label block, referred to as Segment Routing Global Block (SRGB), which is reserved for assigning labels to segment routing prefix SIDs originated by this router. This range is carved from the system dynamic label range and is not instantiated by default:

CLI Syntax:
config>router>mpls-labels>sr-labels start start-value end end-value

Next, the user enables the context to configure segment routing parameters within a given IGP instance:

CLI Syntax:
config>router>isis>segment-routing
config>router>ospf>segment-routing

The key parameter is the configuration of the prefix SID index range and the offset label value which this IGP instance uses. Because each prefix SID represents a network global IP address, the SID index for a prefix must be unique network-wide. Thus, all routers in the network are expected to configure and advertise the same prefix SID index range for a given IGP instance. However, the label value used by each router to represent this prefix, that is, the label programmed in the ILM, can be local to that router by the use of an offset label, referred to as a start label:

Local Label (Prefix SID) = start-label + {SID index}

The label operation in the network becomes thus very similar to LDP when operating in the independent label distribution mode (RFC 5036) with the difference that the label value used to forward a packet to each downstream router is computed by the upstream router based on advertised prefix SID index using the above formula.

Figure 17 shows an example of a router advertising its loopback address and the resulting packet label encapsulation throughout the network.

Figure 17:  Packet Label Encapsulation using Segment Routing Tunnel 

Router N-6 advertises loopback 10.10.10.1/32 with a prefix index of 5.Routers N-1 to N-6 are configured with the same SID index range of [1,100] and an offset label of 100 to 600 respectively. The following are the actual label values programmed by each router for the prefix of PE2:

  1. N-6 has a start label value of 600 and programs an ILM with label 605.
  2. N-3 has a start label of 300 and swaps incoming label 305 to label 605.
  3. N-2 has a start label of 200 and swaps incoming label 205 to label 305.

Similar operations are performed by N-4 and N-5 for the bottom path.

N-1 has an SR tunnel to N-6 with two ECMP paths. It pushes label 205 when forwarding an IP or service packet to N-6 via downstream next-hop N-2 and pushes label 405 when forwarding via downstream next-hop N-4.

The CLI for configuring the prefix SID index range and offset label value for a given IGP instance is as follows:

CLI Syntax:
config>router>isis>segment-routing>prefix-sid-range {global | start-label label-value max-index index-value}
config>router>ospf>segment-routing>prefix-sid-range {global | start-label label-value max-index index-value}

There are two mutually-exclusive modes of operation for the prefix SID range on the router. In the global mode of operation, the user configures the global value and this IGP instance assumes the start label value as the lowest label value in the SRGB and the prefix SID index range size equal to the range size of the SRGB. After one IGP instance selected the global option for the prefix SID range, all IGP instances on the system are restricted to do the same.

The user must shutdown the segment routing context and delete the prefix-sid-range command in all IGP instances in order to change the SRGB. After the SRGB is changed, the user must re-enter the prefix-sid-range command again. The SRGB range change fails if an already allocated SID index/label goes out of range.

In the per-instance mode of operation, the user partitions the SRGB into non-overlapping sub-ranges among the IGP instances. The user thus configures a subset of the SRGB by specifying the start label value and the prefix SID index range size. All resulting net label values (start-label + index) must be within the SRGB or the configuration fails. Furthermore, the code checks for overlaps of the resulting net label value range across IGP instances and strictly enforces that these ranges do not overlap.

The user must shutdown the segment routing context of an IGP instance in order to change the SID index/label range of that IGP instance using the prefix-sid-range command. In addition, any range change fails if an already allocated SID index/label goes out of range.

The user can, however, change the SRGB on the fly as long as it does not reduce the current per-IGP instance SID index/label range defined with the prefix-sid-range. Otherwise, the user must shutdown the segment routing context of the IGP instance and delete and re-configure the prefix-sid-range command.

Finally, the user brings up segment routing on that IGP instances by un-shutting the context:

CLI Syntax:
config>router>isis>segment-routing>no shutdown
config>router>ospf>segment-routing>no shutdown

This command fails if the user has not previously enabled the router-capability option in the IGP instance. Segment routing is a new capability and needs to be advertised to all routers in a given domain so that routers which support the capability only programs the node SID in the data path towards neighbors which support it.

CLI Syntax:
config>router>isis>advertise-router-capability {area | as}
config>router>ospf>advertise-router-capability {link | area | as}

The IGP segment routing extensions are area-scoped. As a consequence, the user must configure the flooding scope to area in OSPF and to area or as in IS-IS, otherwise performing no shutdown of the segment-routing node fail.

Next, the user assigns a node SID index or label to the prefix representing the primary address of an IPv4 or IPv6 network interface of type loopback using one of the following commands:

CLI Syntax:
config>router>isis>interface>ipv4-node-sid index value
config>router>ospf>interface>node-sid index value
config>router>isis>interface>ipv4-node-sid label value
config>router>ospf>interface>node-sid label value
config>router>isis>interface>ipv6-node-sid index value
config>router>isis>interface>ipv6-node-sid label value

Only a single node SID can be assigned to an interface. The secondary address of an IPv4 interface cannot be assigned a node SID index and does not inherit the SID of the primary IPv4 address. The same applies to the non-primary IPv6 addresses of an interface.

Above commands should fail if the network interface is not of type loopback or if the interface is defined in an IES or a VPRN context. Also, assigning the same SID index/label value to the same interface in two different IGP instances is not allowed within the same node.

Also, for OSPF the protocol version number and the instance number dictates if the node-SID index/label is for an IPv4 or IPv6 address of the interface. Specifically, the support of address families in OSPF is as follows:

  1. ospfv2: always IPv4 only

The value of the label or index SID is taken from the range configured for this IGP instance. When using the global mode of operation, a new segment routing module checks that the same index or label value cannot be assigned to more than one loopback interface address. When using the per-instance mode of operation, this check is not required because the index, and thus the label ranges, of the various IGP instances are not allowed to overlap.

For an individual adjacency, values for the label may be provisioned for an IS-IS or OSPF interface. If they are not provisioned, then they are dynamically allocated by the system from the dynamic label range. The following CLI commands are used:

config>router>isis>interface
   [no] ipv4-adjacency-sid label <value> 
   [no] ipv6-adjacency-sid label <value> 
 
config>router>ospf>area>interface
   [no] adjacency-sid label <value>

The value must correspond to a label in a reserved label block in provisioned mode referred to by the srlb command (see Segment Routing Local Block for more details of SRLBs).

A static label value for an adjacency SID is persistent. Therefore, the P-bit of the Flags field in the Adjacency-SID TLV advertised in the IGP is set to 1.

By default, a dynamic adjacency SID is advertised for an interface. However, if a static adjacency SID value is configured, then the dynamic adjacency SID is deleted and only the static adjacency SID used. Changing an adjacency SID from dynamic (for example, no adjacency-sid) to static, or vice versa, may result in traffic being dropped as the ILM is reprogrammed.

For a provisioned adjacency SID for an interface, a backup is calculated similar to a regular adjacency SID when sid-protection is enabled for that interface.

Provisioned adjacency SIDs are only supported on point-to-point interfaces.

4.1.7.2. Announcing ELC, MSD-ERLD, and MSD-BMI with IS-IS

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

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

  1. ELC is automatically announced for host prefixes associated with an IPv4 or IPv6 node SID, when segment-routing and 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.
  2. The router maximum node ERLD is announced for IS-IS when segment-routing and segment-routing entropy-label is enabled together with advertise-router-capability.
  3. The router maximum node MSD-BMI for IS-IS is announced when segment-routing and advertise-router-capability are enabled.
  4. 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.
  5. 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 help 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 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

4.1.7.3. Segment Routing Operational Procedures

4.1.7.3.1. Prefix Advertisement and Resolution

After segment routing is successfully enabled in the IS-IS or OSPF instance, the router performs the following operations. See IS-IS Control Protocol Changes for details of all TLVs and sub-TLVs for both IS-IS and OSPF protocols.

  1. Advertise the Segment Routing Capability Sub-TLV to routers in all areas/levels of this IGP instance. However, only neighbors with which it established an adjacency interprets the SID/label range information and use it for calculating the label to swap to or push for a given resolved prefix SID.
  2. Advertise the assigned index for each configured node SID in the new prefix SID sub-TLV with the N-flag (node-SID flag) set. Then the segment routing module programs the incoming label map (ILM) with a pop operation for each local node SID in the data path.
  3. Assign and advertise automatically an adjacency SID label for each formed adjacency over a network IP interface in the new Adjacency SID sub-TLV. The following points should be considered.
    1. Adjacency SID is advertised for both numbered and unnumbered network IP interface.
    2. Adjacency SID is not advertised for an IES interface because access interfaces do not support MPLS.
    3. The adjacency SID must be unique per instance and per adjacency. Furthermore, ISIS MT=0 can establish an adjacency for both IPv4 and IPv6 address families over the same link and in such a case a different adjacency SID is assigned to each next-hop. However, the existing IS-IS implementation assigns a single Protect-Group ID (PG-ID) to the adjacency and as such when the state machine of a BFD session tracking the IPv4 or IPv6 next-hop times out, an action is triggered for the prefixes of both address families over that adjacency.
    The segment routing module programs the incoming label map (ILM) with a swap to an implicit null label operation, for each advertised adjacency SID.
  4. Resolve received prefixes and, if a prefix SID sub-TLV exists, the Segment Routing module programs the ILM with a swap operation and an LTN with a push operation, both pointing to the primary/LFA NHLFE. An SR tunnel is also added to the TTM. If a node SID resolves over an IES interface, the data path is not programmed and a trap is raised. Thus, only next-hops of an ECMP set corresponding to network IP interfaces are programmed in data path; next-hops corresponding to IES interfaces are not programmed. However, if the user configures the interface as network on one side and IES on the other side, MPLS packets for the SR tunnel received on the access side are dropped.
  5. LSA filtering causes SIDs not to be sent in one direction which means some node SIDs is resolved in parts of the network upstream of the advertisement suppression.

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

4.1.7.3.2. Error and Resource Exhaustion Handling

When the prefix corresponding to a node SID is being resolved, the following procedures are followed.

4.1.7.3.2.1. Procedure 1: Providing support of multiple topologies for the same destination prefix

The SR OS supports assigning different prefix-SID indexes and labels to the same prefix in different IGP instances. While other routers that receive these prefix SIDs programs a single route into RTM, based on the winning instance ID as per RTM route type preference, the SR OS adds two tunnels to this destination prefix in TTM. This provides for the support of multiple topologies for the same destination prefix.

For example: In two different instances (L2, IS-IS instance 1 and L1, IS-IS instance 2—see Figure 18), Router D has the same prefix destination, with different SIDs (SIDx and SIDy).

Figure 18:  Programming multiple tunnels to the same destination 

Assume the following route type preference in RTM and tunnel type preference in TTM are configured:

  1. ROUTE_PREF_ISIS_L1_INTER (RTM) 15
  2. ROUTE_PREF_ISIS_L2_INTER (RTM) 18
  3. ROUTE_PREF_ISIS_TTM 10
Note:

The TTM tunnel type preference is not used by the SR module. It is put in the TTM and is used by other applications such as VPRN auto-bind and BGP shortcut to select a TTM tunnel.

  1. Router A performs the following resolution within the single IS-IS instance 1, level 2. All metrics are the same, and ECMP = 2.
    1. For prefix N, the RTM entry is:
      1. prefix N
      2. nhop1 = B
      3. nhop2 = C
      4. preference 18
    2. For prefix N, the SR tunnel TTM entry is:
      1. tunnel-id 1: prefix N-SIDx
      2. nhop1 = B
      3. nhop2 = C
      4. tunl-pref 10
  2. Add IS-IS instance 2 (Level 1) in the same setup, but in routers A, B, and C only.
    1. For prefix N, the RTM entry is:
      1. prefix N
      2. nhop1 = B
      3. preference 15
      RTM prefers L1 route over L2 route
    2. For prefix N, there are two SR tunnel entries in TTM:
      SR entry for L2:
      1. tunnel-id 1: prefix N-SIDx
      2. nhop1 = B
      3. nhop2= C
      4. tunl-pref 10
      SR entry for L1:
      1. tunnel-id 2: prefix N-SIDy

4.1.7.3.2.2. Procedure 2: Resolving received SID indexes or labels to different routes of the same prefix within the same IGP instance

Two variations of this procedure can occur.

  1. While SR OS does not allow assigning the same SID index or label to different routes of the same prefix within the same IGP instance, it resolves only one of the duplicate SIDs if received from another SR implementation and based on the RTM active route selection.
  2. While SR OS does not allow assigning different SID indexes or labels to different routes of the same prefix within the same IGP instance, it resolves only one of the duplicate SIDs if received from another SR implementation and based on the RTM active route selection.
    The selected SID is used for ECMP resolution to all neighbors. If the route is inter-area and the conflicting SIDs are advertised by different ABRs, ECMP towards all ABRs uses the selected SID.

4.1.7.3.2.3. Procedure 3: Checking for SID error prior to programming ILM and NHLFE

If any of the following conditions are true, the router logs a trap and generates a syslog error message and does not program the ILM and NHLFE for the prefix SID.

  1. Received prefix SID index falls outside of the locally configured SID range.
  2. One or more resolved ECMP next-hops for a received prefix SID did not advertise SR Capability sub-TLV.
  3. Received prefix SID index falls outside the advertised SID range of one or more resolved ECMP next-hops.

4.1.7.3.2.4. Procedure 4: Programming ILM/NHLFE for duplicate prefix-SID indexes/labels for different prefixes

Two variations of this procedure can occur.

  1. For received duplicate prefix-SID indexes or labels for different prefixes within the same IGP instance, the router:
    1. programs ILM/NHLFE for the first one
    2. logs a trap and a syslog error message
    3. does not program the subsequent one in data path
  2. For received duplicate prefix-SID index for different prefixes across IGP instances, there are two options.
    1. In the global SID index range mode of operation, the resulting ILM label values is the same across the IGP instances. The router:
      1. programs ILM/NHLFE for the prefix of the winning IGP instance based on the RTM route type preference
      1. logs a trap and a syslog error message
      1. does not program the subsequent prefix SIDs in data path
    2. In per-instance SID index range mode of operation, the resulting ILM label has different values across the IGP instances. The router programs ILM/NHLFE for each prefix as expected.

4.1.7.3.2.5. Procedure 5: Programming ILM/NHLFE for the same prefix across IGP instances

The behavior in the case of a global SID index range is illustrated by the IS-IS example in Figure 19.

In global SID index range mode of operation, the resulting ILM label values is the same across the IGP instances. The router programs ILM/NHLFE for the prefix of the winning IGP instance based on the RTM route type preference. The router logs a trap and a syslog error message, and does not program the other prefix SIDs in data path.

In per-instance SID index range mode of operation, the resulting ILM label has different values across the IGP instances. The router programs ILM/NHLFE for each prefix as expected.

Figure 19:  Handling of Same Prefix and SID in different IS-IS Instances 

Assume the following route type preference in RTM and tunnel type preference in TTM are configured:

  1. ROUTE_PREF_ISIS_L1_INTER (RTM) 15
  2. ROUTE_PREF_ISIS_L2_INTER (RTM) 18
  3. ROUTE_PREF_ISIS_TTM 10
Note:

The TTM tunnel type preference is not used by the SR module. It is put in the TTM and is used by other applications such as VPRN auto-bind and BGP shortcut to select a TTM tunnel.

  1. Router A performs the following resolution within the single IS-IS instance 1, level 2. All metrics are the same, and ECMP = 2.
    1. For prefix N, the RTM entry is:
      1. prefix N
      2. nhop1 = B
      3. nhop2 = C
      4. preference 18
    2. For prefix N, the SR tunnel TTM entry is:
      1. tunnel-id 1: prefix N-SIDx
      2. nhop1 = B
      3. nhop2 = C
      4. tunl-pref 10
  2. Add IS-IS instance 2 (Level 1) in the same setup, but in routers A, B, and E only.
    1. For prefix N, the RTM entry is:
      1. prefix N
      2. nhop1 = B
      3. preference 15
      RTM prefers L1 route over L2 route.
    2. For prefix N, there is one SR tunnel entry for L2 in TTM:
      1. tunnel-id 1: prefix N-SIDx
      2. nhop1 = B
      3. nhop2 = C
      4. tunl-pref 10

4.1.7.3.2.6. Procedure 6: Handling ILM resource exhaustion while assigning an SID index/label

If the system exhausted an ILM resource while assigning an SID index/label to a local loopback interface, then index allocation is failed and an error is returned in CLI. In addition, the router logs a trap and generates a syslog error message.

4.1.7.3.2.7. Procedure 7: Handling ILM/NHLFE/other IOM or CPM resource exhaustion while resolving or programming an SID index/label

If the system exhausted an ILM, NHLFE, or any other IOM or CPM resource while resolving and programming a received prefix SID or programming a local adjacency SID, then following occurs.

  1. The IGP instance goes into overload and a trap and syslog error message are generated.
  2. The segment routing module deletes the tunnel.

The user must manually clear the IGP overload condition after freeing resources. After the IGP is brought back up, it attempts to program at the next SPF all tunnels which previously failed the programming operation.

4.1.7.4. Segment Routing Tunnel Management

The segment routing module adds to TTM a shortest path SR tunnel entry for each resolved remote node SID prefix and programs the data path with the corresponding LTN with the push operation pointing to the primary and LFA backup NHLFEs. The LFA backup next-hop for a given prefix which was advertised with a node SID is only computed if the loopfree-alternates option is enabled in the IS-IS or OSPF instance. The resulting SR tunnel which is populated in TTM is automatically protected with FRR when an LFA backup next-hop exists for the prefix of the node SID.

With ECMP, a maximum of 32 primary next-hops (NHLFEs) are programmed for the same tunnel destination per IGP instance. ECMP and LFA next-hops are mutually exclusive as per existing implementation.

The default preference for shortest path SR tunnels in the TTM is set lower than LDP tunnels but higher than BGP tunnels to allow controlled migration of customers without disrupting their current deployment when they enable segment routing. The following is the setting of the default preference of the various tunnel types. This includes the preference of both SR tunnels based on shortest path (referred to as SR-ISIS and SR-OSPF).

The global default TTM preference for the tunnel types is as follows:

  1. ROUTE_PREF_RSVP               7
  2. ROUTE_PREF_SR_TE             8
  3. ROUTE_PREF_LDP                  9
  4. ROUTE_PREF_OSPF_TTM     10
  5. ROUTE_PREF_ISIS_TTM        11
  6. ROUTE_PREF_BGP_TTM       12
  7. ROUTE_PREF_GRE                 255

The default value for SR-ISIS or SR-OSPF is the same regardless if one or more IS-IS or OSPF instances programmed a tunnel for the same prefix. The selection of an SR tunnel in this case is based on lowest IGP instance ID.

The TTM preference is used in the case of BGP shortcuts, VPRN auto-bind, or BGP transport tunnel when the tunnel binding commands are configured to the any value which parses the TTM for tunnels in the protocol preference order. The user can choose to either go with the global TTM preference or list explicitly the tunnel types to be used. When the tunnel types are listed explicitly, the TTM preference is still used to select one type over the other. In both cases, a fallback to the next preferred tunnel type is performed if the selected one fails. Also, a reversion to a more preferred tunnel type is performed as soon as one is available. See BGP Shortcut Using Segment Routing Tunnel, BGP Label Route Resolution Using Segment Routing Tunnel, and Service Packet Forwarding with Segment Routing for the detailed service and shortcut binding CLI.

For SR-ISIS and SR-OSPF, the user can configure the preference of each specific IGP instance away from the above default values.

CLI Syntax:
config>router>isis>segment-routing>tunnel-table-pref preference <1 to 255>
config>router>ospf>segment-routing>tunnel-table-pref preference <1 to 255>
Note:

The preference of SR-TE LSP is not configurable and is the second most preferred tunnel type after RSVP-TE. This is independent if the SR-TE LSP was resolved in IS-IS or OSPF.

4.1.7.4.1. Tunnel MTU Determination

The MTU of an SR tunnel populated into TTM is determined as in the case of 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.

Based on the above, the user is provided with a CLI to configure the MTU of all SR tunnels within each IGP instance:

CLI Syntax:
config>router>isis (ospf)>segment-routing>tunnel-mtu bytes

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

The MTU of the SR tunnel, in bytes, is then determined as follows:

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

Where:

  1. Cfg_SR_MTU is the MTU configured by the user for all SR tunnels within a given IGP instance using the above CLI. If no value was configured by the user, the SR tunnel MTU is fully determined by the IGP interface calculation explained next.
  2. 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.
  3. frr-overhead is set the following parameters:
    1. value of ti-lifa [max-sr-frr-labels labels] if loopfree-alternates and ti-lfa are enables in this IGP instance
    2. 1 if loopfree-alternates and remote-lfa are enabled but ti-lfa is disabled in this IGP instance
    3. Otherwise, it is set to 0

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

Note:

The above calculated SR tunnel 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 an SR shortest path tunnel, the data path always deducts the worst case MTU (5 labels or 6 labels if hash label feature is enabled) from the outgoing interface MTU for the decision to fragment or not the packet. In this case, the above formula is not used.

4.1.7.5. Segment Routing Local Block

Some labels that are provisioned through CLI or a management interface must be allocated from the Segment Routing Local Block (SRLB). The SRLB references a reserved label block configured under config>router>mpls-labels. Refer to the 7450 ESS, 7750 SR, 7950 XRS, and VSR MPLS Guide for further information on reserved label blocks.

The label block to use is specified by the srlb command under IS-IS or OSPF:

config>router>isis>segment-routing
   [no] srlb <reserved-label-block-name>
 
config>router>ospf> segment-routing
   [no] srlb <reserved-label-block-name>

Provisioned labels for adjacency SIDs and adjacency SID sets must be allocated from the configured SRLB. If no SRLB is specified, or the requested label does not fall within the SRLB, or the label is already allocated, then the request is rejected.

4.1.7.5.1. Bundling Adjacencies in Adjacency Sets

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 those interfaces’ respective links terminate on the same node.

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

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 in the range 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. The system raises a trap, when the parallel command is configured, 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. In addition, 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, coordination may be required by an external controller of 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, as described). Non-parallel adjacency sets are not added to TTM or RTM, meaning that 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.

4.1.7.5.1.1. Associating an Interface with an Adjacency Set

IS-IS or OSPF interfaces are associated with one or more adjacency sets using the following CLI. Both numbered and unnumbered interfaces can be assigned to the same adjacency set.

config
   router
      isis 
         interface
           [no] adjacency-set <id>
           [no] adjacency-set <id>
           [no] adjacency-set <id>
config
   router
      ospf 
         area
            interface
               [no] adjacency-set <id>
               [no] adjacency-set <id>
               [no] adjacency-set <id>

If an interface is assigned to an adjacency set, then a common adjacency SID value is advertised for every interface in the set, in addition to the adjacency SID corresponding to the IPv4 and or IPv6 adjacency for the interface. Each IS-IS or OSPF advertisement therefore contains two adjacency SID TLVs for an address family:

  1. an adjacency SID for the interface (a locally-unique value).
  2. an adjacency SID TLV for the adjacency set.
    This TLV is distinguished by having the S-bit (IS-IS) or G-bit (OSPF) in the flags field set to 1. Its value is the same as other adjacency SIDs in the set at that node.

By default, both the adjacency SID for an interface and the adjacency SID for a set are dynamically allocated by the system. However, it is possible for the user to configure an alternative, static value for the SID (see Provisioning Adjacency SID Values for an Adjacency Set for more information).

A maximum of 32 interfaces can be bound to a common adjacency set. Configuration of more than 32 interfaces is blocked by the system and a CLI error is generated.

Only point-to-point interfaces can be assigned to an adjacency set.

If a user attempts to assign an IES interface to an adjacency set, the system generates a CLI warning and segment routing does not program the association.

The IGP blocks the configuration of an adjacency set under an interface when the adjacency set has not yet been created under segment-routing.

In IS-IS, it is possible to add Layer 1, Layer 2, or a mix of Layer 1 and Layer 2 adjacencies to the same adjacency set.

4.1.7.5.1.2. Provisioning Adjacency SID Values for an Adjacency Set

For an adjacency set, static values are configured using the sid CLI command, as follows:

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

If no sid is configured, a dynamic value is allocated to the adjacency set. A user may change the dynamic value to specify a static SID value. Changing an adjacency set value from dynamic to a static, or vice versa, may result in traffic being dropped as the ILM is reprogrammed.

The value must correspond to a label in the reserved label block in provisioned mode referred to by the srlb command. A CLI error is generated if a user attempts to configure an invalid value. If a label is not configured, then the label value is dynamically allocated by the system from the dynamic labels range. If a static adjacency set label is configured, then the system does not advertise a dynamic adjacency set label.

A static label value for an adjacency set SID is persistent. Therefore, the P-bit of the Flags field in the Adjacency-SID TLV, referring to the adjacency set should be set to 1.

4.1.7.6. Entropy Label for IS-IS Segment Routing

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. Refer to the MPLS Guide for more information.

Announcing of Entropy Label Capability (ELC) is supported, however processing of Entropy Label Capability (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.

4.1.7.7. Remote LFA with Segment Routing

The user enables the remote LFA next-hop calculation by the IGP LFA SPF by appending the following new option in the existing command which enables LFA calculation:

CLI Syntax:
config>router>isis>loopfree-alternates remote-lfa
config>router>ospf>loopfree-alternates remote-lfa

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

  1. The remote-lfa option is enabled in an IGP instance.
  2. The LFA next hop calculation did not result in protection for one or more prefixes resolved to a given interface.

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

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

Figure 20:  Remote LFA Algorithm 

When the LFA SPF in node C computes the per-prefix LFA next-hop, prefixes which use link C-B as the primary next-hop has no LFA next-hop due to the ring topology. If node C used node link C-D as a back-up next-hop, node D would loop a packet back to node C. The remote LFA then runs the following algorithm, referred to as the “PQ Algorithm” in RFC 7490:

  1. Compute the extended P space of Node C with respect to link C-B: set of nodes reachable from node C without any path transiting the protected link (link C-B). This yields nodes D, E, and F.
    The determination of the extended P space by node C uses the same computation as the regular LFA by running SPF on behalf of each of the neighbors of C.
    Note:

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

    The user can limit the search for candidate P nodes to reduce the amount of SPF calculations in topologies where many eligible P nodes can exist. A CLI command is provided to configure the maximum IGP cost from node C for a P node to be eligible:
    1. config>router>isis>loopfree-alternates remote-lfa max-pq-cost value
    2. config>router>ospf>loopfree-alternates remote-lfa max-pq-cost value
  2. Compute the Q space of node B with respect to link C-B: set of nodes from which the destination proxy (node B) can be reached without any path transiting the protected link (link C-B).
    The Q space calculation is effectively a reverse SPF on node B. In general, one reverse SPF is run on behalf of each of C neighbors to protect all destinations resolving over the link to the neighbor. This yields nodes F and A in the example of Figure 20.
    The user can limit the search for candidate Q nodes to reduce the amount of SPF calculations in topologies where many eligible Q nodes can exist. The CLI above is also used to configure the maximum IGP cost from node C for a Q node to be eligible.
  3. Select the best alternate node: this is the intersection of extended P and Q spaces. The best alternate node or PQ node is node F in the example of Figure 20. From node F onwards, traffic follows the IGP shortest path.
    If many PQ nodes exist, the lowest IGP cost from node C is used to narrow down the selection and if more than one PQ node remains, the node with lowest router-id is selected.

The details of the label stack encoding when the packet is forwarded over the remote LFA next-hop is shown in Figure 21.

Figure 21:  Remote LFA Next-Hop in Segment Routing 

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

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

  1. In IS-IS, the label stack is always reduced to a single label, which is the label of the resolved prefix owned by the PQ node.
  2. In OSPF, the label stack is reduced to the single label of the resolved prefix when the PQ node advertised a single node SID in this OSPF instance. If the PQ node advertised a node SID for multiple of its loopback interfaces within this same OSPF instance, the label stack is reduced to a single label only in the case where the SID of the resolved prefix is the lowest SID value.

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

  1. If the user excludes a network IP interface from being used as an LFA next-hop using the CLI command loopfree-alternate-exclude under the interface’s IS-IS or OSPF context, the interface is also excluded from being used as the outgoing interface for a remote LFA tunnel next-hop.
  2. As with the regular LFA algorithm, the remote LFA algorithm computes a backup next-hop to the ABR advertising an inter-area prefix and not to the destination prefix itself.

4.1.7.8. Topology Independent LFA

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 since traffic always flows on the same path when transitioning to the FRR next-hop and then onto 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 a SR-ISIS IPV4/IPv6 tunnel (node SID and adjacency SID), for a IPv4 SR-TE LSP, and for LDP IPv4 FEC when the LDP fast-reroute backup-sr-tunnel option is enabled.

4.1.7.8.1. TI-LFA Configuration

Users can enable TI-LFA in an IS-IS instance using one of the following command:

config>router>isis>loopfree-alternates [remote-lfa [max-pq-cost value]] [ti-lfa [max-sr-frr-labels value]]

When the ti-lfa option is enabled in IS-IS, it provides a TI-LFA link-protect backup path in IS-IS MT=0 for an SR-ISIS IPV4 and IPv6 tunnel (node SID and adjacency SID), for a IPv4 SR-TE LSP, and for an LDP IPv4 FEC when the LDP fast-reroute backup-sr-tunnel option is enabled. See more details of the applicability of the various LFA options in LFA Protection Option Applicability.

The max-sr-frr-labels parameter limits the search for the LFA backup next-hop:

  1. 0 — The IGP LFA SPF restricts the search to TI-LFA backup next-hop which does not require a repair tunnel, meaning that P node and Q node are the same and match a neighbor. This is also the case when both P and Q node match the advertising router for a prefix.
  2. 1 to 3 — The IGP LFA SPF widens the search to include a repair tunnel to a P node which itself is connected to the Q nodes with a 0-to-2 hops for a total of maximum of three labels: one node SID to P node and two adjacency SIDs from P node to the Q node. If the P node is a neighbor of the computing node, its node SID is compressed and meaning that up to three adjacency SIDs can separate the P and Q nodes.
  3. 2 (default) — Corresponds to a repair tunnel to a non-adjacent P which is adjacent to the Q node. If the P node is a neighbor of the computing node, then the node SID of the P node is compressed and the default value of two labels corresponds to two adjacency SIDs between the P and Q nodes.

When the user attempts to change the max-sr-frr-labels parameter to a value that results in a change to the computed FRR overhead, then IGP checks that all SR-TE LSPs can properly account for the overhead based on the configuration of the LSP max-sr-labels and additional-frr-labels parameter values or the change is rejected.

The FRR overhead is computed by IGP and its value is set as follows:

  1. 0 if segment-routing is disabled in the IGP instance
  1. 0 if segment-routing is enabled but remote-lfa is disabled and ti-lfa is disabled
  1. 1 if segment routing is enabled and remote-lfa is enabled but ti-lfa is disabled, or if segment-routing is enabled and remote-lfa is enabled and ti-lfa is enabled but ti-lfa max-sr-frr-labels labels is set to 0.
  1. The value of ti-lfa max-sr-frr-labels labels, if segment-routing is enabled and ti-lfa is enabled regardless if remote-lfa is enabled or disabled.

4.1.7.8.2. TI-LFA Link-Protect Operation

This section describes TI-LFA protection behavior when the loopfree-alternates command is enabled with the remote-lfa and ti-lfa options as described in TI-LFA Configuration.

4.1.7.8.2.1. LFA Protection Option Applicability

Depending on the configured options of the loopfree-alternates command, the LFA SPF in an IGP instance runs algorithms in the following order:

  1. Computes a regular LFA for each node and prefix. In this step, a computed backup next-hop satisfies any applied LFA policy.
    This backup next-hop protects that specific prefix or node in the context of IP FRR, LDP FRR, SR FRR, and SR-TE FRR.
  2. Follows with the TI-LFA, if the ti-lfa option is enabled for all prefixes and nodes, regardless of the outcome of the first step.
    A prefix or node for which a TI-LFA backup next-hop is found overrides the result from the first step in the context of LDP FRR, if the LDP fast-reroute backup-sr-tunnel option is enabled, in SR FRR and in SR-TE FRR.
    With SR FRR and SR-TE FRR, the TI-LFA next-hop protects the node-SID of that prefix and any adjacency-SID terminating on the node-SID of that prefix.
    The prefix or node continues to use the backup next hop found in Step 1 in the context of LDP FRR (if the LDP fast-reroute backup-sr-tunnel option is disabled), or in IP FRR.
  3. Runs remote LFA only for the next-hop of prefixes and nodes which remain unprotected after Step 1 and Step  2 if the remote-lfa option is enabled. A prefix or node for which a remote LFA backup next-hop is found uses it in the context of LDP FRR, when the LDP fast-reroute backup-sr-tunnel option is enabled, in SR FRR and in SR-TE FRR.

To protect an adjacency SID, the LFA selection algorithm uses the following preference order:

  1. Adjacency of an alternate parallel link to the same neighbor. If more than one adjacency exists, select one as follows:
    1. adjacency with the lowest metric
    2. adjacency to the neighbor with the lowest router ID (OSPF) or system ID (IS-IS), and the lowest metric
    3. with the lowest interface index and the lowest router ID (OSPF) or system ID (IS-IS)
  2. An ECMP next hop to a node-SID of the same neighbor that is different from the next hop of the protected adjacency. If more than one next hop exists, select one as follows:
    1. next hop with the lowest metric
    2. next hop to the neighbor with the lowest router ID (OSPF) or system ID (IS-IS) if same lowest metric
    3. next hop to the lowest interface index if same neighbor router ID (OSPF) or system ID (IS-IS
  3. LFA backup outcome of a node SID of the same neighbor, in the following preference order:
    1. TI-LFA backup
    2. LFA backup
    3. RLFA backup

4.1.7.8.2.2. TI-LFA Algorithm

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 number of labels corresponding to the value of ti-lfa max-sr-frr-labels labels, on each of the post-convergence paths to each destination node or prefix D. Consider the topology in Figure 22 where router R3 computes a TI-LFA next-hop for protecting link R3-R4.

Figure 22:  Selecting Link-Protect TI-LFA Backup Path 

For each destination node D:

  1. Compute the post-convergence SPF on the topology without the protected link.
    In Figure 22, R3 finds a single post-convergence path to destination D via R1.
    Note:

    The post-convergence SPF does not include IGP shortcut.

  2. Compute the extended P-Space of R3 with respect to protected link R3-R4 on the post-convergence paths.
    This is the set of nodes Yi in the post-convergence paths which are reachable from R3 neighbors without any path transiting the protected link R3-R4.
    R3 computes an LFA SPF rooted at each of its neighbors within the post-convergence paths, that is, R1, using the following equation:
    Distance_opt(R1, Yi) < Distance_opt(R1, R3) + Distance_opt(R3, Yi)
    Where, Distance_opt(A,B) is the shortest distance between A and B. The extended P-space calculation yields only node R1.
  3. Compute Q-space of R3 with respect to protected link R3-R4 in the post-convergence paths.
    This is the set of nodes Zi in the post-convergence paths from which the neighbor node R4 of the protected link, acting as a proxy for all destinations D, can be reached without any path transiting the protected link R3-R4.
    Distance_opt(Zi, R4) < Distance_opt(Zi, R3) + Distance_opt(R3, R4)
    The Q-space calculation yields nodes R2 and R4.
    This is the same computation of the Q-space performed by the remote LFA algorithm, except that the TI-LFA Q-space computation is performed only on the post-convergence.
  4. For each post-convergence path, search for the closest Q-node and select the closest P-node to this Q-node, up to a number of labels corresponding to the value of ti-lfa max-sr-frr-labels labels.
    In the topology in Figure 22, there is a single post-convergence path, a single P-node (R1), and the closest of the two found Q-nodes to the P-Node is R2.
    R3 installs the repair tunnel to the P-Q set and includes the node-SID of R1 and the adjacency SID of the adjacency over link R1-R2 in the label stack. Note that since the P-node R1 is a neighbor of the computing node R3, the node SID of R1 is not needed and the label stack of the repair tunnel is compressed to the adjacency SID over link R1-R2 as shown in Figure 22.
    When a P-Q set is found on multiple ECMP post-convergence paths, the following selection rules are applied, in ascending order, to select a set from a single path:
    1. the lowest number of labels
    2. the next-hop to the neighbor router with the lowest router-id (OSPF) or system-id (ISIS)
    3. the next-hop corresponding to the Q node with the lowest router-id (OSPF) or system-id (ISIS)
    If multiple links with adjacency SID exist between the selected P node and the selected Q node, the following rules are used to select one of them:
    1. the adjacency SID with the lowest metric
    2. the adjacency SID with the lowest SID value if same lowest metric

4.1.7.8.2.3. TI-LFA Feature Interaction and Limitations

The following are feature interactions and limitations of the TI-LFA link protection.

  1. Enabling the ti-lfa option in an IS-IS or OSPF instance overrides the user configuration of the loopfree-alternate-exclude command under the interface’s context in that IGP instance. In other words, the TI-LFA SPF uses that interface as a backup next-hop if it matches the post-convergence next-hop.
  1. Any prefix excluded from LFA protection using the loopfree-alternates exclude prefix-policy prefix-policy command under the IGP instance context is also excluded from TI-LFA.
  1. Since the post-convergence SPF does not use paths transiting on a node in IS-IS overload, the TI-LFA backup path automatically does not transit on the a node.
  1. IES interfaces are skipped in TI-LFA computation since they do not support Segment Routing with MPLS encapsulation. If the only found TI-LFA backup next-hop matches an IES interface, IGP treats this as if there were no TI-LFA backup paths and falls back to using either a remote LFA or regular LFA backup path as per the selection rules in LFA Protection Option Applicability.
  1. The TI-LFA feature provides link-protection only. Thus, if the protected link is a broadcast interface, the TI-LFA algorithm only guarantees protection of that link and not of the Pseudo-Node (PN) corresponding to that shared subnet. In other words, if the PN is in the post-convergence path, the TI-LFA backup path may still traverse again the PN. For example, node E in Figure 23 computes a TI-LFA backup path to destination D via E-C-PN-D because it is the post-convergence path when excluding link E-PN from the topology. This TI-LFA backup does not protect against the failure of the PN.
Figure 23:  TI-LFA Backup Path via a Pseudo-Node  
  1. When the computing router selects an adjacency SID among a set of parallel adjacencies between the P and Q nodes, the selection rules in step 4 of TI-LFA Algorithm are used. However, these rules may not yield the same interface the P node itself would have selected in its post-convergence SPF since the latter is based on the lowest value of the locally managed interface index.
    For example, node A in Figure 24 computes the link-protect TI-LFA backup path for destination node E as path A-C-E, where C is the P node and E is the Q node and destination. C has a pair of adjacency SIDs with the same metric to E. Node A selects the adjacency over the P2P link C-E because it has the lowest SID value but node C may select the interface C-PN in its post-convergence path calculation if that interface has a lower interface index than P2P link C-E.
    Figure 24:  Parallel Adjacencies between P and Q Nodes 
  1. When a node SID is advertised by multiple routers (anycast SID), the TI-LFA algorithm on a router which resolves the prefix of this SID computes the backup next-hop toward a single node owner of the prefix based on the rules for prefix and SID ECMP next-hop selection.

4.1.7.8.3. Data Path Support

The TI-LFA repair tunnel can have a maximum of three additional labels pushed in addition to the label of the destination node or prefix. The user can set a lower maximum value for the additional FRR labels by configuring the ti-lfa max-sr-frr-labels labels CLI option. The default value is 2.

The data path models the backup path like a SR-TE LSP and thus uses a super-NHLFE pointing to the NHLFE of the first hop in the repair tunnel. That first hop corresponds to either an adjacency SID or a node SID of the P node.

There is the special case where the P node is adjacent to the node computing the TI-LFA backup, and the Q node is the same as the P node or adjacent to the P node. In this case, the data path at the computing router pushes either zero labels or one label for the adjacency SID between P and Q nodes. The backup path uses a regular NHLFE in this case like in base LFA or remote LFA features. Figure 22 shows and example of a single label in the backup NHLFE.

4.1.7.9. Node Protection Support in TI-LFA and Remote LFA

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

4.1.7.9.1. Feature Configuration

The following are the CLI commands to configure the remote LFA and TI-LFA node protection feature.

CLI Syntax:
configure
router
[no] isis
[no] loopfree-alternates
[no] remote-lfa [max-pq-cost 0..4294967295, default=4261412864]
[no] node-protect [max-pq-nodes 1..32, default=16]
[no] ti-lfa [max-sr-frr-labels 0..3, default=2]
[no] node-protect
exclude
[no] prefix-policy prefix-policy [prefix-policy…(up to 5 max)]
exit
exit

A command is added to enable node-protect calculation to both Remote LFA (node-protect [max-pq-nodes <1..32, default=16>]) and TI-LFA (node-protect).

When the node-protect command is enabled, the router prefers a node-protect over a link-protect repair tunnel for a given prefix if both are found in the Remote LFA or TI-LFA SPF computations. The SPF computations may only find a link-protect repair tunnel for prefixes owned by the protected node. 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.

The parameter max-pq-nodes in Remote LFA controls the maximum number of candidate PQ nodes found in the LFA SPFs for which the node protection check is performed. As explained in Remote LFA Node-Protect Operation, the node-protect condition means the router must run the original link-protect Remote LFA algorithm plus one extra forward SPF on behalf of each PQ node found, potentially after applying the max-pq-cost parameter, to check if the path from the PQ node to the destination does not traverse the protected node. Setting this parameter to a lower value means the LFA SPFs uses less computation time and resources but may result in not finding a node-protect repair tunnel. The default value is 16.

4.1.7.9.2. TI-LFA Node-Protect Operation

The SR OS supports the node-protect extensions to the TI-LFA algorithm as described in draft-bashandy-rtgwg-segment-routing-ti-lfa-05.

Figure 25 shows a simple topology to illustrate the operation of the node-protect in the TI-LFA Algorithm.

Figure 25:  Application of the TI-LFA Algorithm for Node Protection 

The first change is that the algorithm has to protect a node instead of a link.

The following topology computations pertain to Figure 25:

  1. Compute post-convergence SPF on the topology without the protected node.
    In Figure 25, R1 computes TI-LFA on the topology without the protected node R2 and finds a single post-convergence path to destination D via R3 and R6.
    Prefixes owned by all other nodes in the topology have a post-convergence path via R3 and R6 except for prefixes owned by node R2. The latter uses the link R3-R2 and they can only benefit from link protection.
  2. Compute extended P-Space of R1 with respect to protected node R2 on the post-convergence paths.
    This is the set of nodes Yi in the post-convergence paths that are reachable from R1 neighbors, other than protected node R2, without any path transiting the protected node R2.
    R1 computes an LFA SPF rooted at each of its neighbors within the post-convergence paths, for example, R3, using the following equation:
    Distance_opt(R3, Yi) < Distance_opt(R3, R2) + Distance_opt(R2, Yi)
    Where:
    Distance_opt(A,B) is the shortest distance between A and B.
    The extended P-space calculation yields node R3 only.
  3. Compute Q-space of R1 with respect to protected link R1-R2 on the post-convergence paths.
    This is the set of nodes Zi in the post-convergence paths from which node R2 can be reached without any path transiting the protected link R1-R2.
    Distance_opt(Zi, R2) < Distance_opt(Zi, R1) + Distance_opt(R1, R2)
    The reverse SPF for the Q-space calculation is the same as in the link-protect algorithm and uses the protected node R2 as the proxy for all destination prefixes. Note that if the Q-space were to be computed with respect to the protected node R2 instead of link R1-R2, a reverse SPF would have to be done to each destination D which is very costly and would not scale. Computing Q-space with respect to link R1-R2 however means the algorithm only guarantees the path from the computing node to the Q node is node-protecting. The path from the Q node to the destination Dis not guaranteed to avoid the protected node R2. The intersection of the Q-space with post-convergence path is modified in the next step to mitigate this risk.
    This step yields nodes R3, R4, R5, and R6.
  4. For each post-convergence path, search for the closest Q-node to destination D and select the closest P-node to this Q-node, up to a number of labels corresponding to the value of ti-lfa max-sr-frr-labels labels.
    This step yields the following P-Q sets depending on the value of the parameter max-sr-frr-labels:
    1. max-sr-frr-labels=0, R3 is the closest Q node to the destination D and R3 is the only P node. This case is the one which results in link protection via PQ node R3.
    2. max-sr-frr-labels=1, R6 is the closest Q node to the destination D and R3 is the only P node. The repair tunnel for this case uses the SID of the adjacency over link R3-R6 and is illustrated in Figure 25.
    3. max-sr-frr-labels=2, R5 is the closest Q node to the destination D and R3 is the only P node. The repair tunnel for this case uses the SIDs of the adjacencies over links R3-R6 and R6-R5.
    4. max-sr-frr-labels=3, R4 is the closest Q node to the destination D and R3 is the only P node. The repair tunnel for this case uses the SIDs of the adjacencies over links R3-R6, R6-R5, and R5-R4.
    Note this step of the algorithm is modified from link protection which prefers Q nodes which are the closest to the computing router R1. This is to minimize the probability that the path from the Q node to the destination D goes via the protected node R2 as explained in step 2. There is however still a probability that the found P-Q set achieves link protection only.
  5. Select the P-Q Set.
    If a candidate P-Q set is found on each of the multiple ECMP post-convergence paths in step 4, the following selection rules are applied in ascending order to select a single set:
    1. lowest number of labels
    2. lowest next-hop router-id
    3. lowest interface index if same next-hop router-id
    If multiple parallel links with adjacency SID exist between the P and Q nodes of the selected P-Q set, the following rules are used to select one of them:
    1. Adjacency SID with lowest metric
    2. Adjacency SID with the lowest SID value if same lowest metric

For each destination prefix D, R1 programs the TI-LFA repair tunnel (max-sr-frr-labels=1):

  1. For prefixes other than those owned by node R2 and R3, R1 programs a node-protect repair tunnel to the P-Q pair R3-R6 by pushing the SID of adjacency R3-R6 on top of the SID for destination D and programming a next-hop of R3.
  2. For prefixes owned by node R2, R1 runs the link-protect TI-LFA algorithm and programs a simple link-protect repair tunnel which consists of a backup next-hop of R3 and pushing no additional label on top of the SID for the destination prefix.
  3. Prefixes owned by node R3 are not impacted by the failure of R2 since their primary next-hop is R3.

4.1.7.9.3. Remote LFA Node-Protect Operation

SR OS supports the node-protect extensions to the Remote LFA algorithm as described in RFC 8102.

Remote LFA follows a similar algorithm as TI-LFA but does not limit the scope of the calculation of the extended P-Space and of the Q-Space to the post-convergence paths.

Remote LFA adds an extra forward SPF on behalf of the PQ node to make sure that for each destination the selected PQ node does not use a path via the protected node.

Figure 26 shows a slightly modified topology from that in Figure 25. A new node R7 is added to the top ring and the metric for link R3-R6 is modified to 100.

Figure 26:  Application of the Remote LFA Algorithm for Node Protection 

Applying the node protect remote LFA algorithm to this topology yields the following steps:

  1. Compute extended P-Space of R1 with respect to protected node R2.
    This is the set of nodes Yi which are reachable from R1 neighbors, other than protected node R2, without any path transiting the protected node R2.
    R1 computes a LFA SPF rooted at each of its neighbors, in this case, R7, using the following equation:
    Distance_opt(R7, Yi) < Distance_opt(R7, R2) + Distance_opt(R2, Yi)
    Where Distance_opt(A,B) is the shortest distance between A and B.
    Nodes R7, R3 and R6 satisfy this inequality.
  2. Compute Q-space of R1 with respect to protected link R1-R2.
    This is the set of nodes Zi from which node R2 can be reached without any path transiting the protected link R1-R2.
    Distance_opt(Zi, R2) < Distance_opt(Zi, R1) + Distance_opt(R1, R2)
    The reverse SPF for the Q-space calculation is the same as in the remote LFA link-protect algorithm and uses the protected node R2 as the proxy for all destination prefixes.
    This step yields nodes R3, R4, R5, and R6.
    Therefore, the candidate PQ nodes after this step are nodes R3 and R6.
  3. For each PQ node found, run a forward SPF to each destination D.
    This step is required to select only the subset of PQ nodes which does not traverse protected node R2.
    Distance_opt(PQi, D) < Distance_opt(PQi, R2) + Distance_opt(R2, D)
    Of the candidates PQ nodes R3 and R6, only PQ node R6 satisfies this inequality.
    Note this step of the algorithm is applied to the subset of candidate PQ nodes out of steps 1 and 2 and to which the parameter max-pq-cost was already applied. This subset is further reduced in this step by retaining the candidate PQ nodes which provide the highest coverage among all protected nodes in the topology and which number does not exceed the value of parameter max-pq-nodes.
    In case of multiple candidate PQ nodes out of this step, the detailed selection rules of a single PQ node from the candidate list is provided in Step 4.
  4. Select a PQ Node.
    If multiple PQ nodes satisfy the criteria in all the above steps, then R1 further selects the PQ node as follows:
    1. selects the lowest IGP cost from R1
    2. If more than one remains, R1 selects the PQ node reachable via the neighbor with the lowest router-id (OSPF) or system-id (ISIS);
    3. If more than one remains, R1 selects the PQ node with the lowest router-id (OSPF) or system-id (ISIS).

For each destination prefix D, R1 programs the remote LFA backup path:

  1. For prefixes of R5, R4 or downstream of R4, R1 programs a node-protect remote LFA repair tunnel to the PQ node R6 by pushing the SID of node R6 on top of the SID for destination D and programming a next-hop of R7.
  2. For prefixes owned by node R2, R1 runs the link-protect remote LFA algorithm and programs a simple link-protect repair tunnel which consists of a backup next-hop of R7 and pushing the SID of PQ node R3 on top of the SID for the destination prefix D.
  3. Prefixes owned by nodes R7, R3, and R6 are not impacted by the failure of R2 since their primary next-hop is R7.

4.1.7.9.4. TI-LFA and Remote LFA Node Protection Feature Interaction and Limitations

LFA Protection Option Applicability describes the order of activation of the various LFA types on a per prefix basis: TI-LFA, followed by base LFA, followed by remote LFA.

Node protection is enabled for TI-LFA and remote LFA separately. The base LFA prefers node protection over link protection.

The order of activation of the LFA types supersedes the protection type (node versus link). Consequently, it is possible that a prefix can be programmed with a link-protect backup next-hop by the more preferred LFA type. For example, a prefix is programmed with the only link-protect backup next-hop found by the base LFA while there exists a node-protect remote LFA next-hop.

4.1.7.10. IPv6 Segment Routing using MPLS Encapsulation

This feature implements support for 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 then gets 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.

4.1.7.10.1. IS-IS MT=0 Extensions

The IS-IS MT=0 extensions consist of supporting the advertising and resolution of the prefix SID sub-TLV within the IP Reach TLV-236 (IPv6), which is defined in RFC 5308.The adjacency SID is still advertised as a sub-TLV of the Extended IS Reachability TLV 22, as defined in RFC 5305, IS-IS Extensions for Traffic Engineering, as in the case of an IPv4 adjacency. The router sets the V-Flag and I-Flag in the SR-Capabilities Sub-TLV to indicate that it is capable of processing SR MPLS encapsulated IPv4 and IPv6 packets on its network interfaces.

4.1.7.10.2. Service and Forwarding Contexts Supported

The service and forwarding contexts supported with the SR-ISIS IPv6 tunnels are:

  1. SDP of type sr-isis with far-end option using IPv6 address
  2. VLL, VPLS, IES/VPRN spoke-interface, R-VPLS
  3. Support of PW redundancy within Epipe/Ipipe VLL, Epipe spoke termination on VPLS and R-VPLS, and Epipe/Ipipe spoke termination on IES/VPRN
  4. IPv6 static route resolution to indirect next-hop using Segment Routing IPv6 tunnel
  5. Remote mirroring and L3 encap LI

4.1.7.10.3. Services Using SDP with a SR IPv6 Tunnel

The MPLS SDP of type sr-isis with a far-end option using an IPv6 address is supported. Note the SDP must have the same IPv6 far-end address, used by the control plane for the T-LDP session, as the prefix of the node SID of the SR IPv6 tunnel.

Example:
configure
service
[no] sdp sdp-id mpls
[no] far-end ipv6-address
sr-isis
no sr-isis

The bgp-tunnel, lsp, sr-te lsp, sr-ospf, and mixed-lsp-mode commands are blocked within the SDP configuration context when the far-end is an IPv6 address.

SDP admin groups are not supported with an SDP using an SR IPv6 tunnel, or with SR-OSPF for IPv6 tunnels, and the attempt to assign them is blocked in the CLI.

Services that use LDP control plane such as T-LDP VPLS and R-VPLS, VLL, and IES/VPRN spoke interface have the spoke SDP (PW) signaled with an IPv6 T-LDP session because the far-end option is configured to an IPv6 address. The spoke SDP for these services binds to an SDP that uses an SR IPv6 tunnel where the prefix matches the far-end address. SR OS also supports the following:

  1. the IPv6 PW control word with both data plane packets and VCCV OAM packets
  2. Hash Label and Entropy Label, with the above services
  3. network domains in VPLS

The PW switching feature is not supported with LDP IPv6 control planes. As a result, the CLI does not allow the user to enable the vc-switching option whenever one or both spoke SDPs uses an SDP that has the far-end configured as an IPv6 address.

L2 services that use BGP control plane such as dynamic MS-PW, BGP-AD VPLS, BGP-VPLS, BGP-VPWS, and EVPN MPLS cannot bind to an SR IPv6 tunnel because a BGP session to a BGP IPv6 peer does not support advertising an IPv6 next-hop for the L2 NLRI. As a result, these services do not auto-generate SDPs using an SR IPv6 tunnel. In addition, they skip any provisioned SDPs with far-end configured to an IPv6 address when the use-provisioned-sdp option is enabled.

SR OS also supports multi-homing with T-LDP active/standby FEC 128 spoke SDP using SR IPv6 tunnel to a VPLS/B-VPLS instance. BGP multi-homing is not supported because BGP IPv6 does not support signaling an IPv6 next-hop for the L2 NLRI.

The Shortest Path Bridging (SPB) feature works with spoke SDPs bound to an SDP that uses an SR IPv6 tunnel.

4.1.7.11. Data Path Support

A packet received with a label matching either a node SID or an adjacency SID is forwarded according to the ILM type and operation, as described in Table 11.

Table 11:  Data Path Support  

Label type

Operation

Top label is a local node SID

Label is popped and the packet is further processed.

If the popped node SID label is the bottom of stack label, the IP packet is looked up and forwarded in the appropriate FIB.

Top or next label is a remote node SID

Label is swapped to the calculated label value for the next-hop and forwarded according to the primary or backup NHLFE.

With ECMP, a maximum of 32 primary next-hops (NHLFEs) are programmed for the same destination prefix and for each IGP instance. ECMP and LFA next-hops are mutually exclusive as per existing implementation.

Top or next label is an adjacency SID

Label is popped and the packet is forwarded out on the interface to the next-hop associated with this adjacency SID label.

In effect, the data path operation is modeled like a swap to an implicit-null label instead of a pop.

Next label is BGP 3107 label

The packet is further processed according to the ILM operation as in current implementation.

  1. The BGP label may be popped and the packet looked up in the appropriate FIB.
  2. The BGP label may be swapped to another BGP label.
  3. The BGP label may be stitched to an LDP label.

Next label is a service label

The packet is looked up and forwarded in the Layer 2 or VPRN FIB as in current implementation.

A router forwarding an IP or a service packet over an SR tunnel pushes a maximum of two transport labels with a remote LFA next-hop. This is illustrated in Figure 27.

Figure 27:  Transport Label Stack in Shortest Path Forwarding with Segment Routing 

Assume that a VPRN service in node B forwards a packet received on a SAP to a destination VPN-IPv4 prefix X advertised by a remote PE2 via ASBR/ABR node A. Router B is in a segment routing domain while PE2 is in an LDP domain. BGP label routes are used to distribute the PE /32 loopbacks between the two domains.

When node B forwards over the primary next-hop for prefix X, it pushes the node SID of the ASBR followed by the BGP 3107 label for PE2, followed by the service label for prefix X. When the remote LFA next-hop is activated, node B pushes one or more segment routing label: the node SID for the remote LFA backup node (node N).

When node N receives the packet while the remote LFA next-hop is activated, it pops the top segment routing label which corresponds to a local node SID. This results in popping this label and forwarding of the packet to the ASBR node over the shortest path (link N-Z).

When the ABR/ASBR node receives the packet from either node B or node Z, it pops the segment routing label which corresponds to a local node SID, then swaps the BGP label and pushes the LDP label of PE2 which is the next-hop of the BGP label route.

4.1.7.11.1. Hash Label and Entropy Label Support

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:

  1. 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.
  2. If the lbl-ip option is enabled, the LSR hashes on the EL and the IP headers.
  3. 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.

4.1.7.12. IS-IS Control Protocol Changes

This section describes the IS-IS Control Protocol Changes. See OSPF Control Protocol Changes for details on OSPF control protocol changes.

4.1.7.12.1. IS-IS Control Protocol Changes

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

  1. the prefix SID sub-TLV
  2. the adjacency SID sub-TLV
  3. the SID/Label Binding TLV
  4. SR-Capabilities Sub-TLV
  5. 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 explained 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:

  1. 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.
  2. The N-flag is always set because SR OS supports prefix SID of type node SID only.
  3. The P-Flag (no-PHP flag) is always set, meaning that the label for the prefix SID is pushed by the PHP router when forwarding to this router. The SR OS PHP router processes properly a received prefix SID with the P-flag set to zero and uses implicit-null for the outgoing label towards the router which advertised it as long as the P-Flag is also set to 1.
  4. The E-flag (Explicit-Null flag) is always set to zero. An SR OS PHP router, however, processes properly 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 towards the router which advertised it.
  5. The V-flag is always set to 0 to indicate an index value for the SID.
  6. The L-flag is always set to 0 to indicate that the SID index value is not locally significant.
  7. 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.
  8. The SR OS still 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.
  9. 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.
  10. The SR OS resolves a prefix SID received within a IP reachability TLV based on the following route preference:
    1. SID received via L1 in a prefix SID sub-TLV part of IP reachability TLV
    2. SID received via L2 in a prefix SID sub-TLV part of IP reachability TLV
  11. A prefix received in an IP reachability TLV is propagated, along with the prefix SID sub-TLV, by default from L1 to L2 by an L1L2 router. A router in L2 sets up an SR tunnel to the L1 router via the L1L2 router, which acts as an LSR.
  12. A prefix received in an IP reachability TLV is not propagated, along with the prefix SID sub-TLV, by default from L2 to L1 by an L1L2 router. If the user adds a policy to propagate the received prefix, then a router in L1 sets up an SR tunnel to the L2 router via the L1L2 router, which acts as an LSR.
  13. 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.
  14. 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:

  1. the F-flag is set to zero to indicate the IPv4 family and is set to 1 to indicate an IPv6 family for the adjacency encapsulation
  2. the B-Flag is set to zero and is not processed on receipt
  3. the V-flag is always set to 1
  4. the L-flag is always set to 1
  5. the S-flag is set to zero as assigning adjacency SID to parallel links between neighbors is not supported. An adjacency received SID with S-Flag set is not processed.
  6. 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  4.1.8 for more information). It can process it properly if received. The following rules and limitations should be considered.

  1. 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.
  2. The range and FEC prefix fields are processed. Each FEC prefix is resolved normally, as for the prefix SID sub-TLV, meaning there must be an IP Reachability TLV received for the exact matching prefix.
  3. 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:
    1. SID received via L1 in a prefix SID sub-TLV part of IP reachability TLV
    2. SID received via L2 in a prefix SID sub-TLV part of IP reachability TLV
    3. SID received via L1 in a mapping server Prefix-SID sub-TLV
    4. SID received via L2 in a mapping server Prefix-SID sub-TLV
  4. 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  4.1.8 for more information). Finally, an L1L2 router is not propagated 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.
  5. The mapping server which advertised the SID/Label Binding TLV does not need to be in the shortest path for the FEC prefix.
  6. If the same FEC prefix is advertised in multiple binding TLVs by different routers, the SID in the binding TLV of the first router which is reachable is used. If that router becomes unreachable, the next reachable one is used.
  7. No check is performed if the content of the binding TLVs from different mapping servers are consistent or not.
  8. Any other sub-TLV, for example, the SID/Label Sub-TLV, 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.

4.1.7.13. BGP Shortcut Using Segment Routing Tunnel

The user enables the resolution of IPv4 prefixes using SR tunnels to BGP next-hops in TTM with the following command:

CLI Syntax:
config>router>bgp>next-hop-resolution
shortcut-tunnel
[no] family {ipv4}
resolution {any | disabled | filter}
resolution-filter
[no] sr-isis
[no] sr-ospf
[no] disallow-igp
exit
exit
exit

When resolution is set to any, any supported tunnel type in BGP shortcut context is selected following TTM preference. The following tunnel types are supported in a BGP shortcut context and in order of preference: RSVP, LDP, Segment Routing and BGP.

When the sr-isis or sr-ospf value is enabled, an SR tunnel to the BGP next-hop is selected in the TTM from the lowest preference IS-IS or OSPF instance. If many instances have the same lowest preference from the lowest numbered IS-IS or OSPF instance.

See the BGP chapter for more details.

4.1.7.14. BGP Label Route Resolution Using Segment Routing Tunnel

The user enables the resolution of RFC 3107 BGP label route prefixes using SR tunnels to BGP next-hops in TTM with the following command:

CLI Syntax:
config>router>bgp>next-hop-resolution
labeled-routes
transport-tunnel
[no] family {label-ipv4 | label-ipv6 | vpn}
resolution {any | disabled | filter}
resolution-filter
[no] sr-isis
[no] sr-ospf
exit
exit
exit
exit

When the resolution option is explicitly set to disabled, the default binding to LDP tunnel resumes. If resolution is set to any, any supported tunnel type in BGP label route context is selected following TTM preference.

The following tunnel types are supported in a BGP label route context and in order of preference: RSVP, LDP, and Segment Routing.

When the sr-isis or sr-ospf is specified using the resolution-filter option, a tunnel to the BGP next-hop is selected in the TTM from the lowest numbered IS-IS or OSPF instance.

See the BGP chapter for more details.

4.1.7.15. Service Packet Forwarding with Segment Routing

SDP subtypes of the MPLS type are available to allow service binding to an SR tunnel programmed in TTM by OSPF or IS-IS:

*A:7950 XRS-20# configure service sdp 100 mpls create

*A:7950 XRS-20>config>service>sdp$ sr-ospf

*A:7950 XRS-20>config>service>sdp$ sr-isis

The SDP of type sr-isis or sr-ospf can be used with the far-end option. When the sr-isis or sr-ospf value is enabled, a tunnel to the far-end address is selected in the TTM from the lowest preference IS-IS or OSPF instance. If many instances have the same lowest preference from the lowest numbered IS-IS or OSPF instance. The SR-ISIS or SR-OSPF tunnel is selected at the time of the binding, following the tunnel selection rules. If a more preferred tunnel is subsequently added to the TTM, the SDP does not automatically switch to the new tunnel until the next time the SDP is being re-resolved.

The tunnel-far-end option is not supported. In addition, the mixed-lsp-mode option does not support the sr-isis and sr-ospf tunnel types.

The signaling protocol for the service labels for an SDP using an SR tunnel can be configured to static (off), T-LDP (tldp), or BGP (bgp).

SR tunnels can be used in VPRN and BGP EVPN with the auto-bind-tunnel command. See Next-Hop Resolution for more information.

Both VPN-IPv4 and VPN-IPv6 (6VPE) are supported in a VPRN or BGP EVPN service using segment routing transport tunnels with the auto-bind-tunnel command.

See BGP and refer to the 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 3 Services Guide: IES and VPRN for more information about the VPRN auto-bind-tunnel CLI command.

4.1.7.16. Mirror Services and Lawful Intercept

The user can configure a spoke-SDP bound to an SR tunnel to forward mirrored packets from a mirror source to a remote mirror destination. In the configuration of the mirror destination service at the destination node, the remote-source command must use a spoke-sdp with VC-ID which matches the one the user configured in the mirror destination service at the mirror source node. The far-end option is not supported with an SR tunnel.

This also applies to the configuration of the mirror destination for an LI source.

Configuration at mirror source node:

CLI Syntax:
config mirror mirror-dest 10
no spoke-sdp sdp-id:vc-id
spoke-sdp sdp-id:vc-id [create]
egress
vc-label egress-vc-label
Note:

  1. sdp-id matches an SDP which uses an SR tunnel
  2. for vc-label, both static and t-ldp egress vc labels are supported

Configuration at mirror destination node:

CLI Syntax:
*A:7950 XRS-20# configure mirror mirror-dest 10 remote-source
spoke-sdp <SDP-ID>:<VC-ID> create <-- VC-ID matching that of spoke-sdp configured in mirror destination context at mirror source node.
ingress
vc-label <ingress-vc-label> <--- optional: both static and t-ldp ingress vc label are supported.
exit
no shutdown
exit
exit
Note:

  1. the far-end command is not supported with SR tunnel at mirror destination node; user must reference a spoke-SDP using a segment routing SDP coming from mirror source node:
    1. far-end ip-address [vc-id vc-id] [ing-svc-label ingress-vc-label | tldp] [icb]
    2. no far-end ip-address
  2. for vc-label, both static and t-ldp ingress vc labels are supported

Mirroring and LI are also supported with the PW redundancy feature when the endpoint spoke-sdp, including the ICB, is using an SR tunnel. Routable Lawful Intercept Encapsulation (config>mirror>mirror-dest>encap# layer-3-encap) when the remote L3 destination is reachable over an SR tunnel is also supported.

4.1.7.17. Class-Based Forwarding for SR-ISIS over RSVP-TE LSPs

To enable CBF+ECMP for SR-ISIS over RSVP-TE:

  1. configure the resolution of SR over RSVP-TE LSPs as IGP shortcuts
  2. configure class based forwarding parameters in the MPLS context (a class forwarding policy, forwarding classes to sets associations, and RSVP-TE LSPs to forwarding sets associations)
  3. enable class forwarding in the segment routing context

When SR-ISIS resolves to an ECMP set of RSVP-TE LSPs and class forwarding is enabled in the segment routing context, the following behaviors apply:

  1. If no LSP in the full ECMP set, has been assigned with a class forwarding policy configuration, the set is considered as inconsistent from a CBF perspective. The system programs, in the forwarding path, the whole ECMP set and regular ECMP spraying occurs over the full set.
  2. If the ECMP set refers to more than one class forwarding policy, the set is inconsistent from a CBF perspective. The system programs, in the forwarding path, the whole ECMP set without any CBF information, and regular ECMP spraying occurs over the full set.
  3. In all other cases the ECMP set is considered consistent from a CBF perspective and the following rules apply:
    1. If there is no default set (either user-defined or implicit) referenced in a CBF-consistent ECMP set, the system automatically selects one set as the default one. The selected set is the non-empty one with the lowest ID amongst those referenced by the LSPs of the ECMP set.
    2. The system programs the data-path such that a packet which has been classified to a particular forwarding class is forwarded using the LSP(s) associated to the forwarding set which itself is associated to that forwarding class. In the event where the forwarding set is composed of multiple LSPs, the system performs ECMP over these LSPs.
    3. Forwarding classes which are either not explicitly mapped to a set or which are mapped to a set for which all LSPs are down are forwarded using the default-set. The system re-elects a default set in cases where all the LSPs of the current default-set become inactive. The system also adapts (updates data-path programming) to configuration or state changes.
    4. The CBF capability is available with any system profile. The number of sets is limited to four with system profile None or A, and to six with system profile B.

4.1.7.18. Segment Routing Traffic Statistics

This section describes capabilities and procedures applicable to IS-IS, OSPFv2, and OSPFv3.

SR OS can enable and collect SID traffic statistics on the ingress and egress data paths. Statistics can also be shown, monitored, and cleared, as well as accessed using telemetry.

IS-IS and OSPFv2 support Node SID, Adjacency SID, and Adjacency Set statistics. OSPFv3 supports Node SID and Adjacency SID statistics. The following commands are used to enter the context that allows for configuring the types of SIDs for which to collect traffic statistics.

  1. configure router isis segment-routing egress-statistics
  2. configure router ospf segment-routing egress-statistics
  3. configure router ospf3 segment-routing egress-statistics
  4. configure router isis segment-routing ingress-statistics
  5. configure router ospf segment-routing ingress-statistics
  6. configure router ospf3 segment-routing ingress-statistics

By default, statistics collection is disabled on all types of SIDs. If statistics are disabled (after having been enabled), the statistics indices that were allocated are released and the counter values are cleared.

On ingress, depending on which types of SIDs have statistics enabled, the following apply:

  1. The system allocates a statistic index to each programmed ILM, corresponding to the local node SID (including backup node SID) and to the local adjacency SIDs (including adjacencies advertised as set m embers).
  2. The system allocates a statistic index to each programmed ILM, corresponding to the received node SID advertisements.

On egress, depending on which types of SIDs have statistics enabled, the following apply:

  1. The system allocates a statistic index shared by the programmed NHLFEs (primary, and backup if any) corresponding to the local Adjacency SIDs and to the received Adjacency SIDs advertisements, and a statistic index shared by the primary NHLFEs (as many as members) of each adjacency set.
  2. The system allocates a statistic index shared by the programmed NHLFEs (one or more primaries, and backup if any) corresponding to each of the received node SID advertisements.
Note:

The statistic indices constitute a finite resource. The system may not be able to allocate as many indices as needed. In this case, the system issues a notification and automatically retries to allocate statistic indices, but does not issue further notifications in case it still fails to allocate the needed statistic indices. If the system successfully allocates all the required statistic indices to IGP SIDs, then a second notification is issued to inform the user. A state variable records whether a SID has an index allocated.

Note:

The allocation of statistic indices is non-deterministic. If more statistic indices are required system-wide, for example, upon a reboot, the system may not be able to re-allocate the statistic indices to the same entities as before the reboot.

4.1.8. Segment Routing Mapping Server Function for IPv4 Prefixes

4.1.8.1. Segment Routing Mapping Server

The mapping server feature allows the configuration and advertisement via IS-IS 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 the SID/Label binding TLV in IS-IS.

The user configures the SR mapping database in IS-IS using the following CLI command:

CLI Syntax:
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 can enter 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. The user can enter the first prefix with a mask lower than 32 and the SID/Label Binding TLV is advertised but the routers do not resolve these prefix SIDs and instead originates 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.

By setting the S-flag, the user can indicate to the IS-IS routers in the rest of 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 should leak it between IS-IS levels. If leaked from level 2 to level 1, the D-flag must be set, after which the TLV cannot be leaked back into level 2. Otherwise, the S-flag is clear by default and the TLV must not be leaked by routers receiving the mapping server advertisement.

Note:

SR OS does not leak this TLV between IS-IS instances and does not support the multi-topology SID/Label Binding TLV format. In addition, the user can specify the mapping server’s flooding scope for the generated SID/Label binding TLV using the level option. This option allows further narrowing of the flooding scope configured under the router IS-IS level-capability for a one or more SID/Label binding TLVs if required. The default flooding scope of the mapping server is L1/L2, which can be narrowed by what is configured under the router IS-IS level-capability.

The A-flag is used to indicate that a prefix for which the mapping server prefix SID is advertised is directly attached. The M-flag is used to advertise 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 a IS-IS SID/label binding TLV in that instance. The flooding scope of the TLV from the mapping server is determined as explained above. No further check of the reachability of that prefix in the mapping server route table is performed and no check if the SID index is duplicate with some existing prefix in the local IGP instance database or if the SID index is out of range with the local SRGB.

4.1.8.2. Prefix SID Resolution for Segment Routing Mapping Server

  1. IP Prefix Resolution
    1. SPF calculates the next-hops, up to max-ecmp, to reach a destination node.
    2. Each prefix inherits the next-hops of one or more destination nodes advertising it.
    3. A prefix advertised by multiple nodes, all reachable with same cost, inherits up to max-ecmp next-hops from the advertising nodes.
    4. The next-hop selection, up to max-ecmp, value is deterministic and is based on sorting the next-hops by:
      1. lowest next-hop router-id
      2. lowest interface index, for parallel links to same router-id
      Each next-hop keeps a reference to the destination nodes of whom it was inherited.
  2. Prefix SID Resolution
    1. For a specified prefix, IGP selects the SID value among multiple advertised values respecting the following preference order:
      1. the local intra-area SID owned by this router
      2. the prefix SID sub-TLV advertised within an IP Reach TLV
        If multiple SIDs exist, select the SID corresponding to the destination router or the ABR with the lowest system ID that is reachable using the first next-hop of the prefix.
      3. the IS-IS SID and label binding TLV from the mapping server
        If multiple SIDs exist, select the following the preference rules in draft-ietf-spring-conflict-resolution-05 [sid-conflict-resolution] when applied to the SRMS entries of the conflicting SIDs. The order of these rules is as follows:
        - smallest range
        - smallest starting address
        - smallest algorithm
        - smallest starting SID
      Note:

      If an L1L2 router acts as a mapping server and also re-advertises the mapping server prefix SID from other mapping servers, the redistributed mapping server prefix SID is preferred by other routers resolving the prefix, which may result in not selecting the mapping server respecting these rules.

    2. The selected SID is used with all ECMP next-hops step (I) towards all destination nodes or ABR nodes which advertised the prefix.
    3. If duplicate prefix SIDs exist for different prefixes after the above steps, the first SID that is processed is programmed for its corresponding prefix. Subsequent SIDs cause a duplicate SID trap and are not programmed. The corresponding prefixes themselves are still resolved and programmed normally using IP next-next-hops.
  3. SR Tunnel Programming
    1. If the prefix SID is resolved from a prefix SID sub-TLV advertised within an IP Reach TLV, one of the following applies.
      1. The SR ILM label is swapped to a SR NHLFE label as in regular SR tunnel resolution when the next-hop of the ISIS prefix is SR enabled.
      2. The SR ILM label is stitched to an LDP FEC of the same prefix when either the next-hop of the ISIS prefix is not SR enabled (no SR NHLFE) or an import policy rejects the prefix (SR NHLFE deprogrammed).
        The LDP FEC could also be resolved using the same or a different IGP instance as that of the prefix SID sub-TLV or using a static route.
    2. If the prefix SID is resolved from a mapping server advertisement, one of the following applies.
      1. The SR ILM label is stitched to an LDP FEC of the same prefix, if one exists. The stitching is performed even if an import policy rejects the prefix in the local ISIS instance.
        The LDP FEC could also be resolved using a static route, a route within an IS-IS instance, or a route within an OSPF instance. The latter two can be the same as, or different from the IGP instance that advertised the mapping server prefix SID sub-TLV.
      2. Otherwise, the SR ILM label is swapped to a SR NHLFE label. This is only possible if a route is exported from another IGP instance into the local IGP instance without propagating the prefix SID sub-TLV with the route. Otherwise, the SR ILM label is swapped to a SR NHLFE label towards the stitching node.

4.1.9. Micro-Loop Avoidance Using Loop-Free SR Tunnels (IS-IS)

Transient forwarding loops, or micro loops, occur during IGP convergence as a result of the transient inconsistency among forwarding states of the nodes of the network. The micro-loop avoidance feature supports the use of loop-free SR paths and a configurable time as a solution to the micro-loop issue for SR IS-IS SID tunnels.

4.1.9.1. Configuring Micro-loop Avoidance

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

CLI Syntax:
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 given 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:

  1. IS-IS MT=0 for a SR-ISIS IPv4/IPv6 tunnel (node SID)
  2. IPv4 and IPv6 SR-TE LSP that use a node SID in their segment list
  3. IPv4 and IPv6 SR policy that use a node SID in their segment list

4.1.9.2. Micro-Loop Avoidance Algorithm Process

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:

  1. link addition or restoration
  2. link removal or failure
  3. 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 hop(s) and metric(s).
  4. No action is performed for a node or a prefix if the SPF has resulted in a change to its next-hop(s) and/or metric(s), 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 since 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 hop(s) or metric(s). The router performs the following:
    1. 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 ECMP next hops
    2. computes and activates for each SR node SID that uses a micro-loop avoidance eligible route, with a single next hop loop-free SR tunnel that is 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.
    3. 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 hop(s) are programmed for node SID routes that are marked eligible for the micro-loop avoidance procedure upon the expiration of the fib-delay timer.
Note:

If a new SPF is scheduled while the fib-delay timer is running, the timer is forced to expire and the entire procedure is aborted.

If a CPM switchover is triggered while the fib-delay timer is running, the timer is forced to expire and the entire procedure is aborted.

In both cases, the next hops from the most recently run SPF are programmed for all impacted node SIDs. A subsequent event restarts the procedure at Step 1.

4.1.9.3. Micro-Loop Avoidance for Link Addition, Restoration, or Metric Decrease

The network topology in Figure 28 depicts an example of link addition or restoration.

Figure 28:  Micro-Loop Avoidance in Link Addition or Restoration 

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

  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 main and LFA SPFs.
    1. all nodes downstream of the added link in Dijkstra tree see a next-hop change: nodes 6 and 9
    2. all nodes upstream of the added link see no route change: nodes 1, 2, and 7
    3. nodes 1', 2', and 7' are not using node 6 or 7 as parent node 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.
    1. The algorithm pushes node SID 7 and adjacency SID of link 7-6 in 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.

4.1.9.4. Micro-Loop Avoidance for Link Removal, Failure, or Metric Increase

The network topology in Figure 29 depicts an example of link removal or failure.

Figure 29:  Micro-Loop Avoidance in Link Removal or Failure 

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

  1. Link 6-9 is removed or fails.
  2. Router 3 detects a single link event and runs main and LFA SPFs.
    1. all nodes downstream of the removed link in the Dijkstra tree see a next-hop change: nodes 9, 10, 11, and 12
    2. plus nodes 10, 11, and 12 are no longer downstream of node 9
    3. all nodes upstream of the removed link see no route change: nodes 1, 2, 7, and 6
    4. nodes 1', 2', and 7' are not using node 6 or 9 as parent nodes and are therefore are not impacted by the link removal event
  3. For each impacted node, the algorithm computes and activates a loop-free SR tunnel to the farthest node in the shortest path that did not see a next-hop change, and then uses the adjacency SIDs to reach destination node.
    1. For SR IS-IS tunnel of node 12, push SID of node 7 and then SIDs of adjacencies 7-11 and 11-12.
    2. Similar to P-Q set calculation in TI-LFA, but the P node is defined as the farthest node in the shortest path to the destination in the new topology with no next-hop change.
    3. The maximum number of labels used for the P-Q set is determined as follows.
      1. If TI-LFA is enabled, use the value of max-sr-frr-labels.
      2. If TI-LFA is disabled, use the value of 3 that matches the maximum value of TI-LFA parameter max-sr-frr-labels.
      3. In both cases, this value is passed to MPLS for checking against parameter max-sr-label [additional-frr-labels] for all configured SR-TE LSPs and SR-TE LSP templates.
    4. A future implementation compresses the path from the P node to the destination using an extra Q node calculation.
    5. The path to the P node may travel over an RSVP-TE LSP used as an IGP shortcut. In this case, the RSVP-TE LSP must have CSPF enabled to avoid churn in IGP and to avoid micro-loop in the path of the RSVP control plane messages that are generated following the convergence of IGP, because the next hop in the ERO is looked up in the routing table.
    6. When SR-LDP stitching is enabled and the path to the P node or the path between the P and Q nodes is partly on the LDP domain, no loop-free SR tunnel is programmed and IGP programs the new next hop or hops.
  4. The same method applies to a metric increase of link 6-9 that causes traffic to move away from that link; for example, a metric change from 1 to 200.

4.2. FIB Prioritization

The RIB processing of specific routes can be prioritized through the use of the rib-priority command. This command allows specific routes to be prioritized through the protocol processing so that updates are propagated to the FIB as quickly as possible.

The rib-priority command is configured within the global IS-IS routing context, and the administrator has the option to either specify a prefix-list or an IS-IS tag value. If a prefix list is specified then route prefixes matching any of the prefix list criteria is considered high priority. If instead an IS-IS tag value is specified then any IS-IS route with that tag value is considered high priority.

The routes that have been designated as high priority are the first routes processed and then passed to the FIB update process so that the forwarding engine can be updated. All known high priority routes should be processed before the IS-IS routing protocol moves on to other standard priority routes. This feature has the most impact when there are a large number of routes being learned through the IS-IS routing protocols.

4.3. IS-IS Graceful Restart Helper

IS-IS supports the graceful restart helper function which provides an IS-IS neighbor a grace period during a control plane restart to minimize service disruption. When the control plane of a GR-capable router fails or restarts, the neighboring routers supporting the graceful restart helper mode (GR helpers) temporarily preserve IS-IS forwarding information. Traffic continues to be forwarded to the restarting router using the last known forwarding tables. If the control plane of the restarting router comes back up within the grace period, the restarting router resumes normal IS-IS operation. If the grace period expires, then the restarting router is presumed inactive and the IS-IS topology is recalculated to route traffic around the failure.

4.3.1. BFD Interaction with Graceful Restart

If the SR OS router is providing a grace period to an adjacent neighbor and the BFD session associated with that neighbor fails, the behavior is determined by the C-bit values sent by each neighbor.

  1. If both BFD end-points have set their C-bit value, then the graceful restart helper mode is canceled and any routes from that neighbor that are marked as stale are removed from the forwarding table.
  2. If either of the BFD end-points has not set their C-bit value, then the graceful restart helper mode continues.

4.4. IS-IS Configuration Process Overview

Figure 30 displays the process to provision basic IS-IS parameters.

Figure 30:  IS-IS Configuration and Implementation Flow 

4.5. Configuration Notes

This section describes IS-IS configuration caveats.

4.5.1. General

  1. IS-IS must be enabled on each participating router.
  2. There are no default network entity titles.
  3. There are no default interfaces.
  4. By default, the routers are assigned a Level 1/Level 2 level capability.