5.1.3.1. Designated Routers

In multi-access broadcast networks, such as Ethernet networks, with at least two attached routers, a designated router can be elected. The IS-IS protocol refers to the designated router as the designated intermediate system (DIS).

The concept of a designated router was developed in order to avoid the formation of adjacencies between all attached routers. Without a designated router, the area would be flooded with link-state PDUs (LSPs)—a router would send LSPs to all its adjacent neighbors, and each in turn would send LSPs to all their neighbors, and so on. This would create multiple copies of the same LSP on the same link.

The designated router reduces the number of adjacencies required because each router forms an adjacency only with the designated router. Only the designated router sends LSPs in multicast format to the rest of the network, reducing the amount of routing protocol traffic.

In IS-IS, a broadcast subnetwork with multiple connected routers is considered to be a pseudonode. The pseudonode has links to each of the routers and each of the routers has a single link to the pseudonode (rather than links to each of the other routers). LSPs are generated on behalf of the pseudonode by the DIS.

The DIS has two tasks:

The DIS is automatically elected based on the interface priority of the router and/or if it has the highest MAC address of all routers in the LAN. If all interface priorities are the same, the router with the highest subnetwork point of attachment (SNPA) is selected. The SNPA is the MAC address on a LAN.

Every IS-IS router interface is assigned both a level 1 priority and a level 2 priority. If a new router starts up in the LAN and has a higher interface priority, the new router preempts the original DIS and becomes the new DIS. The new DIS purges the old pseudonode LSP and floods a new set of LSPs.

Because different priorities can be set according to level 1 or level 2 routing, there can be two different routers in an Ethernet LAN that are DIS-designated. One DIS supports all level 1 routers, and the other DIS supports all level 2 routers on that segment.

The DIS generates the pseudonode LSP. The DIS reports all LAN neighbors (including itself) in the pseudonode link-state PDU (LSP). All LAN routers communicate with the pseudonode via their LSPs. The pseudonode reduces the number of adjacencies by having all physical devices exchange information only with the pseudonode. Each router listens for updates to the pseudonode and updates its individual topology according to those updates.

Note: In point-to-point networks, where a single pair of routers is connected, no designated router is elected. An adjacency must be formed with the neighbor router. To significantly improve adjacency forming and network convergence, a network should be configured as point-to-point if only two routers are connected, even if the network is a broadcast media such as Ethernet.

5.1.3.2. IS-IS Packet Types

Table 60 describes the packet types used by IS-IS to exchange protocol information.

When a change takes place, IS-IS sends only the changed information, not the whole topology information or whole link-state database. From the topological database, each router constructs a tree of shortest paths with itself as root (that is, runs the Dijkstra algorithm). IS-IS distributes routing information between routers belonging to a single AS.

To summarize:

5.1.5.1. Authentication Key

For explicit authentication keys, IS-IS supports plain text (simple password) and Message Digest 5 (MD5) authentication.

When authentication is enabled on a link, a text string password must be configured. Neighbor IS-IS routers must supply the password in all IS-IS packets they send to an interface.

Plain text authentication includes the password in each IS-IS packet sent on a link.

MD5 authentication is more secure than plain text authentication. MD5 authentication uses the password as an encryption key. Routers in the same routing domain must be configured with the same key. When the MD5 hashing algorithm is used for authentication, MD5 is used to verify data integrity by creating a 128-bit message digest from the data input that is included in each packet. The packet is transmitted to the router neighbor and can only be decrypted if the neighbor has the correct password.

The following authentication commands can be configured in the IS-IS global and IS-IS level contexts:

The following Hello PDU authentication commands can be configured in the IS-IS interface and IS-IS interface level contexts:

5.1.5.2. Authentication Keychains

The keychain mechanism allows for the creation of keys used to authenticate IS-IS communications. Each keychain entry defines the authentication attributes to be used in authenticating IS-IS messages from remote peers or neighbors; the entry must include at least one key entry to be valid. The keychain mechanism also allows authentication keys to be changed without affecting the state of the IS-IS adjacencies and supports stronger authentication algorithms than plain text and MD5.

Keychains are configured in the config>system>security>keychain context. For more information about configuring keychains, refer to the 7705 SAR System Management Guide, “TCP Enhanced Authentication and Keychain Authentication”.

The authentication keychain is then associated with IS-IS in the global or level contexts with the auth-keychain command. The Hello authentication keychain is associated with IS-IS in the global, interface, or interface level contexts with the hello-auth-keychain command.

For a key entry to be valid, it must include a valid key, the current system clock value must be within the begin and end time of the key entry, and the algorithm specified must be supported by IS-IS.

IS-IS supports the following authentication algorithms:

Keychain errors are handled as follows.

5.1.6.1. Route Redistribution

Route redistribution is the taking of routes from one protocol and sending them to another protocol. The 7705 SAR supports the redistribution of static routes into OSPF and IS-IS and the redistribution of routes between IS-IS levels. The routes can be redistributed as level 1, level 2, or level 1/2 routes, depending on the level capability of the IS-IS router.

Multi-instance IS-IS (MI-IS-IS) supports route redistribution:

Route redistribution involves the use of routing policies. For information on routing policies, refer to the 7705 SAR Router Configuration Guide, “Route Policies”. To configure route redistribution, see Redistributing External IS-IS Routes.

5.1.6.2. 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. Routes redistributed from other routing protocols can also be summarized.

IS-IS route summarization helps to reduce the size of the link-state database and the routing table. It also helps to reduce the chance of route flapping, which may occur when a router alternately advertises a destination network via one route then another route in quick sequence (or advertises a route as unavailable then available again).

5.1.9.1. Configuring Segment Routing in Shortest Path

Segment routing is enabled in an IGP routing instance using the following sequence of commands.

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

config>router>mpls-labels>sr-labels start start-value end end-value

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

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 that 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. All routers in the network are expected to configure and advertise the same prefix SID index range for an 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 is very similar to LDP when operating in independent label distribution mode (RFC 5036), with the difference being that the label value used to forward a packet to each downstream router is computed by the upstream router based on the advertised prefix SID index using the above formula.

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

Figure 19:  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.

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 commands for configuring the prefix SID index range and offset label value for an IGP instance are as follows:

  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: global mode and per-instance mode.

In the global mode of operation, the user configures the global value and the IGP instance assumes that the start label value is the lowest label value in the SRGB and the prefix SID index range size is equal to the range size of the SRGB. When one IGP instance selects the global option for the prefix SID range, all IGP instances on the system must do the same.

The user must shut down the segment routing context and disable the prefix-sid-range command in all IGP instances in order to change the SRGB. When the SRGB is changed, the user must re-enable the prefix-sid-range command. 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 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. The 7705 SAR checks for overlaps of the resulting net label value range across IGP instances and strictly enforces no overlapping of the ranges.

The user must shut down 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. A range change fails if an already allocated SID index/label goes out of range.

The user can, however, change the SRGB without shutting down the segment routing context as long as it does not reduce the current per-IGP instance SID index/label range defined with the prefix-sid-range command. Otherwise, the user must shut down the segment routing context of the IGP instance and disable and re-enable the prefix-sid-range command.

Finally, the user brings up segment routing on the IGP instance by using the no shutdown command:

  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 advertise-router-capability option in the IGP instance. Segment routing capability must be advertised to all routers in a particular domain so that routers that support the capability only program the node SID in the data path toward neighbors that also support it.

  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. The user must therefore configure the flooding scope to area in OSPF and to area or as in IS-IS; otherwise, performing a no shutdown of the segment-routing node will fail.

The segment-routing command and the igp-shortcut and advertise-tunnel-link are mutually exclusive under IGP, because an SR tunnel cannot resolve to an RSVP tunnel next hop.

IS-IS supports node SID indexes or labels on IPv4 and IPv6 interfaces, and OSPF supports node SID indexes or labels on IPv4 addresses only, because OSPFv3 does not support segment routing.

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:

  config>router>isis>interface>ipv4-node-sid index value

  config>router>ospf>area>interface>node-sid index value

  config>router>isis>interface>ipv4-node-sid label value

  config>router>ospf>area>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.

The above commands will fail if the network interface is not of type loopback or if the interface is defined in an IES or a VPRN context. Assigning the same SID index/label value to the same interface in two different IGP instances is not allowed within the same node.

The value of the label or index SID is taken from the range configured for the IGP instance. When using the global mode of operation, a new segment routing module checks that the same index or label value is not 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 therefore the label ranges, of IGP instances are not allowed to overlap.

5.1.9.2. Segment Routing Operational Procedures

5.1.9.2.3. Error and Resource Exhaustion Handling

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

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

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

Example:

In two different instances (level 2, IS-IS instance 1 and level1, IS-IS instance 2—see Figure 20), Router D has the same prefix destination with different SIDs (SIDx and SIDy).

Figure 20:  Programming Multiple Tunnels to the Same Destination 

Assume that the following route type preference in the RTM and tunnel type preference in the 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 shortcuts 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. Router A performs the resolution.
   1. For prefix N, the RTM entry is:
      1. prefix N
      2. nhop1 = B
      3. preference 15
      The RTM prefers level 1 route over level 2 route.
   2. For prefix N, there are two SR tunnel entries in the TTM:
      SR entry for level 2:
      1. tunnel-id 1: prefix N-SIDx
      2. nhop1 = B
      3. nhop2= C
      4. tunl-pref 10
      SR entry for level 1:
      1. tunnel-id 2: prefix N-SIDy

5.1.9.2.3.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. If the 7705 SAR 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 SID index or label if it is received from another SR implementation and based on the RTM active route selection.
2. If the 7705 SAR 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 SID index or label if received from another SR implementation and based on the RTM active route selection.
   The selected SID will be used for ECMP resolution to all neighbors. If the route is inter-area and the conflicting SIDs are advertised by different ABRs, ECMP toward all ABRs uses the selected SID.

5.1.9.2.3.3. Procedure 3: Checking for SID errors 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 will not program the ILM and NHLFE for the prefix SID:

1. the received prefix SID index falls outside 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. the received prefix SID index falls outside the advertised SID range of one or more resolved ECMP next hops

5.1.9.2.3.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 prefix SID
   2. logs a trap and a syslog error message
   3. does not program the subsequent prefix SID in the data path
2. For received duplicate prefix SID indexes 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 are 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 the data path
   2. In the per-instance SID index range mode of operation, the resulting ILM label will have different values across the IGP instances. The router programs ILM/NHLFE for each prefix as expected.

5.1.9.2.3.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 21.

In the global SID index range mode of operation, the resulting ILM label values are 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 the data path.

In the 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 21:  Handling of Same Prefix and SID in Different IS-IS Instances 

Assume that the following route type preference in the RTM and tunnel type preference in the 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 shortcuts 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. Router A performs the resolution.
   1. For prefix N, the RTM entry is:
      1. prefix N
      2. nhop1 = B
      3. preference 15
      The RTM prefers level 1 route over level 2 route.
   2. For prefix N, there is one SR tunnel entry for level 2 in the TTM:
      1. tunnel-id 1: prefix N-SIDx
      2. nhop1 = B
      3. nhop2 = C
      4. tunl-pref 10

5.1.9.2.3.6. Procedure 6: Handling ILM resource exhaustion while assigning a SID index/label

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

5.1.9.2.3.7. Procedure 7: Handling ILM, NHLFE, or other IOM or CSM resource exhaustion while resolving or programming a SID index/label

If the system exhausted an ILM, NHLFE, or any other IOM or CSM resource while resolving and programming a received prefix SID or programming a local adjacency SID, the 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 that previously failed the programming operation.

5.1.9.3. Segment Routing Tunnel Management

The segment routing module adds to the 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 prefix that was advertised with a node SID will only be computed if the loopfree-alternate option is enabled in the IS-IS or OSPF instance. The resulting SR tunnel that is populated in the 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 8 primary next hops (NHLFEs) are programmed for the same tunnel destination per IGP instance. ECMP and LFA next hops are mutually exclusive.

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 preferences for 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:

The default value for SR-ISIS or SR-OSPF is the same regardless of whether 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 the lowest IGP instance ID.

The TTM preference is used for 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 accept the global TTM preference or explicitly list 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. A reversion to a more preferred tunnel type is performed as soon as one is available. See BGP Label Route Resolution Using Segment Routing Tunnel, and Service Packet Forwarding with Segment Routing for the detailed service and shortcut binding CLI commands.

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

Note: The preference of the SR-TE LSP is not configurable and is the second most preferred tunnel type after RSVP-TE. The preference is the same whether the SR-TE LSP was resolved in IS-IS or OSPF.

5.1.9.3.1. Tunnel MTU Determination

The MTU of an SR tunnel populated into the TTM is determined as in the same way as the MTU of an IGP tunnel (for example, LDP LSP), based on the outgoing interface MTU minus the label stack size. Segment routing, however, supports remote LFA, which programs an LFA backup next hop, adding another label to the tunnel for a total of two labels.

The following commands are used 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 command. If the user does not configure an SR tunnel MTU, the MTU, in bytes, is fully determined by IGP 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 an IGP instance using the tunnel-mtu command. If no value is configured by the user, the SR tunnel MTU is fully determined by the IGP interface calculation explained in the following bullet point
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 to 1 if the segment-routing and remote-lfa options are enabled in the IGP instance. Otherwise, it is set to 0.

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

Note: If fragmentation is used for IP packets forwarded in the GRT or in a VPRN over an SR shortest path tunnel, the IOM always deducts the worst-case MTU (5 labels, or 6 labels if the hash label feature is enabled) from the outgoing interface MTU when deciding whether to fragment the packet. In this case, the above formula is not used.

5.1.9.4. Remote LFA with Segment Routing

The remote LFA next-hop calculation by the IGP LFA SPF is enabled by appending the following option to the loopfree-alternate command:

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

Remote LFA extends the protection coverage of LFA-FRR to any topology by automatically computing and establishing or tearing down shortcut tunnels, also referred to as repair tunnels, to a remote LFA node that puts the packets back into the shortest path without looping them back to the node that forwarded them over the repair tunnel. A repair tunnel can, in theory, be an RSVP-TE LSP, an LDP-in-LDP tunnel, or an SR tunnel. On the 7705 SAR, this feature is restricted to using 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. The algorithm 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 the destinations. An example is shown in Figure 22.

Figure 22:  Remote LFA Algorithm 

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

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

Figure 23:  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 forwarding the packets 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.

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

5.1.9.5. 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 that is not in the shortest path from the computing node. The repair tunnel uses the shortest path to the P node and a source-routed path from the P node to the Q node.

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

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

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

5.1.9.5.2. TI-LFA Link-Protect Operation

5.1.9.5.2.1. LFA Protection Option Applicability

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

1. The algorithm first 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 the specific prefix or node in the context of IP FRR, SR FRR, or SR-TE FRR.
2. Next, the algorithm always 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.
   With SR FRR and SR-TE FRR, the TI-LFA next hop protects the node SID of that prefix and protects any adjacency SID terminating on the node SID of that prefix.
3. Finally, the algorithm runs remote LFA only for the next hop of prefixes and nodes that remain unprotected after the first and second steps if the remote-lfa option is enabled.

When protecting an adjacency SID, a parallel ECMP adjacency takes precedence over any other type of LFA backup path. Applying the above algorithm applicability rules results in the following selection:

1. adjacency SID of an alternate ECMP next hop
2. TI-LFA backup next hop
3. LFA backup next hop
4. remote LFA backup next hop

5.1.9.5.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 the 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. Figure 24 shows a topology where router R3 computes a TI-LFA next hop for protecting link R3-R4.

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

For each destination node D:

1. The algorithm computes the post-convergence SPF on the topology without the protected link.
   In Figure 24, R3 finds a single post-convergence path to destination D via R1.
   The post-convergence SPF does not include IGP shortcut tunnels, unless advertised as forwarding adjacencies.
2. The algorithm computes 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 that 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 two nodes, A and B. The extended P space calculation yields only node R1.
3. The algorithm computes the 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, the algorithm searches for the closest Q node and selects the closest P node to this Q node, up to the number of labels corresponding to the value of ti-lfa max-sr-frr-labels labels.
   In the topology in Figure 24, there is a single post-convergence path, and 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. Because 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 24.
   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 lowest next-hop router ID
   3. the lowest interface index if the same next-hop router ID is the same
   If multiple links with adjacency SIDs exist between the selected P node and the selected Q node, the following rules are used to select one link:
   1. the adjacency SID with the lowest metric
   2. the adjacency SID with the lowest SID value if the lowest metric is the same

5.1.9.5.2.3. TI-LFA Feature Interaction and Limitations

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

1. Enabling the ti-lfa option in overrides the user configuration of the loopfree-alternate-exclude command under the interface context in the 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-alternate-exclude prefix-policy prefix-policy command under the IGP instance context is also excluded from TI-LFA.

1. Because the post-convergence SPF does not use paths transiting on a node in IS-IS overload, the TI-LFA backup path automatically will not transit on such a node.

1. As with remote LFA, a user-configured LFA policy is not applied in the selection of a TI-LFA backup next hop when multiple candidates are available.

1. IES interfaces are skipped in TI-LFA computations because they do not support segment routing with MPLS encapsulation. If the only found TI-LFA backup next hop matches an IES interface, the IGP will treat this as if there were no TI-LFA backup paths and will fall 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. If the protected link is a broadcast interface, the TI-LFA algorithm only guarantees protection of that link and not of the pseudonode corresponding to that shared subnet. In other words, if the pseudonode is in the post-convergence path, the TI-LFA backup path may still traverse the pseudonode. For example, node E in Figure 25 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 pseudonode (PN).

Figure 25:  TI-LFA Backup Path via a Pseudonode  

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 that the P node would have selected in its post-convergence SPF because the latter is based on the lowest value of the locally managed interface index.
   For example, node A in Figure 26 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 point-to-point 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 point-to-point link C-E.

   Figure 26:  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 that 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.

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

5.1.9.7. 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 61.

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 

In Figure 27, 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 a packet 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 labels: 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. Th packet is then forwarded 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 that 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.

5.1.9.8. Control Protocol Changes

This section describes both IS-IS Control Protocol Changes and OSPF Control Protocol Changes.

5.1.9.9. BGP Label Route Resolution Using Segment Routing Tunnel

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

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

The following tunnel types are supported in a BGP label route context and in order of preference: RSVP, SR-TE, LDP, SR-OSPF, and SR-ISIS.

If the sr-isis or sr-ospf option 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.

5.1.9.10. Service Packet Forwarding with Segment Routing

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

The SDP of type sr-isis or sr-ospf can be used with the far-end option. When the sr-isis or sr-ospf option is enabled, a tunnel to the far-end address is selected in the TTM from the lowest-preference IS-IS or OSPF instance. If multiple instances have the same lowest preference, the lowest-numbered IS-IS or OSPF instance is selected. 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 will not automatically switch to the new tunnel until the next time the SDP is being resolved.

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

SR tunnels can be used in VPRN services and BGP EVPN with the auto-bind-tunnel command. See Next-hop Resolution of BGP Labeled Routes to Tunnelsfor more information.

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

For more information about the VPRN auto-bind-tunnel command, see BGP. Additionally, refer to the “VPRN Auto-binding Tunnels” section in the 7705 SAR Services Guide.

The following are the service contexts that are supported with SR tunnels:

The following service contexts are not supported:

5.1.9.11. Segment Routing Mapping Server for IPv4 /32 Prefixes (IS-IS)

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

For more information on prefix SID sub-TLVs and SID/Label Binding TLVs, as well as information on the setting of the various types of flags associated with IS-IS support of SR TLV and sub-TLVs, see to IS-IS Control Protocol Changes. For more information on LDP-to-SR stitching, refer to the 7705 SAR MPLS Guide, “LDP-to-Segment Routing Stitching for IPv4 /32 Prefixes (IS-IS)”.

An SR mapping server is configured using the following CLI commands:

A user can enter the node-sid index for one prefix or a range of prefixes by specifying the index value or a value range. Only the first prefix in a consecutive range of prefixes must be entered. If the user enters the first prefix with a mask lower than 32, the SID/Label Binding TLV is advertised but the router does not resolve the prefix SIDs; a trap is originated instead.

The user can configure the S-flag using the set-flags option to indicate to the IS-IS network routers that the flooding of the SID/Label Binding TLV applies to the entire domain. A router that receives the TLV advertisement leaks it between IS-IS levels 1 and 2. If leaked from level 2 to level 1, the D-flag must be set; this prevents the TLV from being leaked back into level 2. The S-flag is not defined by default; if it is not configured, the TLV is not leaked by routers receiving the mapping server advertisement.

The user can specify the mapping server’s flooding scope for the generated SID/Label Binding TLV using the level option. The default flooding scope of the mapping server is level 1/2.

Note: The 7705 SAR does not leak the SID/Label Binding TLV between IS-IS instances.

Each time a prefix or a range of prefixes is configured in the SR mapping database in any routing instance, the router issues a prefix SID sub-TLV within an IS-IS SID/Label Binding TLV for the prefix or range of prefixes. 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 is done to determine if the SID index is a duplicate of an existing prefix in the local IGP instance database or if the SID index is out of range with the local SRGB.

An SR-capable router, including the mapping server and its clients, attempts to resolve each received prefix SID to either an SR tunnel endpoint or an LDP tunnel endpoint. See Prefix SID Resolution for a Segment Routing Mapping Server.

5.1.9.12. Mirror Services

A spoke SDP can be 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 a VC-ID that matches the one configured in the mirror destination service at the mirror source node. The far-end option is not supported with an SR tunnel.

Configuration at mirror source node:

Note: The sdp-id matches an SDP that uses an SR tunnel. For vc-label, both static and T-LDP egress VC labels are supported.

Configuration at mirror destination node:

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

Mirroring is also supported with the PW redundancy feature when the endpoint spoke SDP, including the ICB, is using an SR tunnel.

5.3.1.1. Selection Algorithm

For a point-to-point interface, if SPF finds multiple LFA next hops for a given primary next hop, the selection algorithm is as follows:

For a broadcast interface, a node-protect LFA is not necessarily a link-protect LFA if the path to the LFA next hop goes over the same pseudonode as the primary next hop. Similarly, a link-protect LFA may not guarantee link protection if it goes over the same pseudonode as the primary next hop.

When SPF finds multiple LFA next hops for a given primary next hop, the selection algorithm is as follows:

Note: A node-protect LFA that does not guarantee link protection can still be selected as a last resort; as well, a link-protect LFA that does not guarantee node protection can still be selected as a last resort.

Both the calculated primary next hop and LFA next hop for a given prefix are programmed into the RTM.

5.3.1.2. LFA Configuration

To enable LFA for IS-IS prefixes, enter the following command at the IS-IS instance level:

  config>router>isis>loopfree-alternate

Next, enable FRR for LDP and/or IP by entering the following commands:

  config>router>ldp>fast-reroute

  config>router>ip-fast-reroute

These commands instruct the IS-IS SPF algorithm to precalculate a primary next hop and LFA next hop for every learned prefix, in order to provide FRR to LDP FEC packets and/or IP packets.

To exclude all interfaces within a specific IS-IS level or to exclude a specific IP interface from being included in the LFA SPF calculation, enter the following commands:

  config>router>isis>level>loopfree-alternate-exclude

  config>router>isis>interface>loopfree-alternate-exclude

If IGP shortcuts are also enabled, any LSPs with a destination address in that IS-IS level are not included in the LFA SPF calculation.

If an interface is excluded from the LFA SPF in IS-IS, it is excluded in both level 1 and level 2.

5.3.2.1. Selection Algorithm

If there are multiple LFA next hops for a primary next hop, the selection algorithm is as follows:

5.3.2.2. Forwarding Adjacency

The forwarding adjacency feature allows IS-IS to advertise an RSVP-TE LSP as a link so that other routers in the network can include it in the SPF calculations. The RSVP-TE is advertised as an unnumbered point-to-point link and the link-state PDU (LSP) has no traffic engineering opaque sub-TLVs as per RFC 3906, Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels.

The forwarding adjacency feature can be enabled independently from the IGP shortcut feature. If both features are enabled for a given IS-IS instance, forwarding adjacency takes precedence.

When forwarding adjacency is enabled, each node advertises a point-to-point unnumbered link for each best-metric tunnel to the router ID of any endpoint node. The node does not include the tunnels as IGP shortcuts in the SPF calculation directly. Instead, when the LSP advertising the corresponding point-to-point unnumbered link is installed in the local routing database, the node performs an SPF calculation using the link like any other link LSP. The link bidirectional check requires that a regular link or tunnel link exist in the reverse direction for the tunnel to be used in SPF calculations.

5.3.2.3. IGP Shortcut Configuration

To enable the use of IGP shortcuts by IS-IS, enter the following command at the IS-IS instance level:

  config>router>isis>rsvp-shortcut

To enable forwarding adjacency, enter the following command at the IS-IS instance level:

  config>router>isis>advertise-tunnel-link

To enable the use of an RSVP-TE LSP by IS-IS as a shortcut or as a forwarding adjacency for resolving IGP routes, enter the following command:

  config>router>mpls>lsp>igp-shortcut

When the rsvp-shortcut or advertise-tunnel-link option is enabled at the IS-IS instance level, all RSVP-TE LSPs originating on this node are eligible by default as long as the destination address of the LSP, as configured with the config>router> mpls>lsp>to command, corresponds to a router ID of a remote node. A specific LSP can be excluded from being used as a shortcut or forwarding adjacency with the no form of the igp-shortcut command.

5.3.3.1. LFA SPF Policy Configuration

To create a route next-hop policy template, enter the following command:

  config>router>route-next-hop-policy template

Configure the template with policy constraints for the items in the preceding list.

Note: To configure constraints for admin groups and SRLG groups, these groups must already be created in the config>router>if-attribute>admin-group and config>router>if-attribute>srlg-group contexts.

Next, apply the template to IS-IS interfaces by entering the following command:

  config>router>isis>interface>lfa-policy-map>route-nh-template

The template is applied to all prefixes using the specified interface name.

Optionally, exclude prefixes in a prefix policy from the LFA SPF calculation by entering the following command:

  config>router>isis>loopfree-alternate-exclude prefix-policy