Flexible Algorithms in IS-IS for Segment Routing Traffic Engineering

Benefits of Configuring Flexible Algorithm

• A lightweight version of segment routing traffic engineering that can be used in the core of the network.

• Allows you to configure traffic engineering using segment routing even without installing a network controller.

• Utilize equal-cost multipath (ECMP) and TI-LFA per-slice without configuring BGP-LS or static path.

• Compute TI-LFA backup path using the same flexible algorithm definition and constraints computation.

• Take advantage of segment routing traffic engineering using only IS-IS without configuring RSVP or LDP.

• Ability to provision constrained primary path based on a single label.

What is Flexible Algorithm Definition (FAD)?

A flexible algorithm allows IGP to calculate additional best paths based on specified constraints thereby providing simple traffic engineering without using a network controller. This is a lightweight solution for networks that have not implemented a controller with full fledged segment routing but still want to reap the benefits of segment routing in their network. Every operator can define separate constraints or colors depending on their requirements.

To define a flexible algorithm, include flex-algorithm id statement at the [edit routing-options] hierarchy level. The flexible algorithm definition (FAD) is assigned with an identifier ranging from 128 through 255. This flexible algorithm can be defined on one or more routers in a network. A flexible algorithm computes a best path based on the following parameters:

• Calculation type—SPF or strict SPF are the two available calculation type options. You can specify one of these calculation types in your FAD. Select the SPF calculation type if you want to influence the SPF computation on your device based on a certain local policy such as traffic engineering shortcuts. If you select strict SPF then the local policy cannot influence the SPF path selection.

• Metric type- IGP metric or TE metric are the available metric type options. You can specify one of these metric types in your FAD depending on your network requirement. If you do not want to use the IGP metric for a specific link you can configure a TE metric that IS-IS can use for calculating the route.

• Priority- You can assign a priority to your FADs as per your requirement and IS-IS prioritizes a particular FAD advertisement over another FAD based on your assigned priority.

  Note:

  For FADs with link-constraints to work, all relevant links should advertise the admin-colors in IS-IS, which means either RSVP is enabled on the interfaces or set protocols isis traffic-engineering advertise always is configured.

• Set of Link constraints- You can configure admin-groups for many protocols at the [edit protocols mpls admin-groups] hierarchy level to color an individual link. These admin-groups can then be defined as include any, include-all or exclude at the [edit routing-options flex-algorithm definition admin-groups] hierarchy level.

We recommend configuring flexible algorithm definitions on only a few routers to provide redundancy and to avoid conflicts. Flexible algorithm definition is advertised in IGP as FAD sub-TLVs. In very large networks, we do not recommend configuring more than 8 flexible algorithms as each flexible algorithm will compute its own path and might cause performance issues beyond that.

Its also recommended that you configure multiple FAD servers in a specific ISIS Level before configuring any devices to participate in that FAD. In the case of an ISIS L1/L2 node (ABR), it's also recommended that you configure the FAD at both ISIS Level 1 and Level 2. If a FAD is configured only on a single ABR, traffic drops over flex algorithm paths are possible if the routing process restarts on that ABR. Its therefore a good design practice to have multiple ABRs, each of which has the FAD configured at both ISIS levels.

The default FAD has the following parameters:

• calculation type: spf

• metric type: igp-metric

• priority: 0

• Link constraints: none

Note:

Modifying the flexible algorithm definition in a live network or on the fly could cause traffic disruptions until all the nodes converge on the new paths.

Participation in a Flexible Algorithm

You can configure specific routers to participate in a particular flexible algorithm as per your requirement. Paths computed based on a flexible algorithm definition is used by various applications each potentially using its own specific data plane for forwarding the data over such paths. The participating device must explicitly advertise its participation in a particular flexible algorithm to every application in the segment routing flexible algorithm sub TLV for IS-IS. You can configure a node to participate in a certain flexible algorithm provided it can support the constraints specified in that FAD.

To configure participation in a flexible algorithm include the flex-algorithm statement at the [edit protocols isis source-packet- routing] hierarchy level. The same device can advertise a FAD and also participate in a flexible algorithm.

Network Topology Configured with Flexible Algorithm Definitions

Figure 1 shows the sample topology, there are 8 routers R0, R1, R2, R3, R4, R5, R6, and R7. Four flexible algorithms, 128, 129, 130, and 135 are defined and configured with admin-groups as listed in the following table:

Flex Algorithm Definition (FAD)	Color
128	Include any Red
129	Include any Green
130	Include any Green and Blue
135	Exclude Red

Figure 2 shows how FAD 128 routes traffic on any interface that is configured with admin group red.

Figure 3 shows how FAD 129 routes traffic on any interface that is configured with admin group green.

Figure 4 shows how FAD 130 routes traffic on any interface that is configured with admin group green and blue.

Figure 5 shows how FAD 135 routes traffic on any interface that is not configured with admin group red.

Flexible Algorithm RIBs

For every flexible algorithm that a router participates in the corresponding flexible algorithm routes are installed in the corresponding flexible algorithm RIB groups also known as routing tables. By default, labeled IS-IS flexible algorithm routes are installed in the inet.color, inet(6)color.0 and mpls.0 RIBs.

BGP Community and Flexible Algorithms

A flexible algorithm can be associated with a color. When a service prefix, such as a VPN service carries a BGP color extended community, by default the BGP service prefix resolves a flex-algo route that has the same associated color value. The flexible algorithm ingress routes that are installed in the inet(6)color.0 tables will have this color value associated with the route. However, you can configure a different associate color value at the [edit routing-options flex-algorithm id color color] hierarchy level.

Note:

Changing the associated color value in a flexible algorithm might result in traffic disruption. If you modify the color in a flexible algorithm definition, all routes pertaining to that flexible algorithm are removed from the RIB and added again with the new color.

Flexible Algorithm and Flexible Algorithm Prefix Metrics Leaking across IS-IS Multi-Instance

We've added support to readvertise flexible algorithm (flex algo) prefix-segment identifiers (SIDs) and Flexible Algorithm Prefix Metrics (FAPMs) across interior gateway protocol (IGP) instances. We’ve also added support to readvertise prefixes from other protocols and assign flex algo prefix-SIDs via policy to those prefixes.

In the sample topology shown in Figure 6, different IS-IS domains, metro-A, metro-B, and the core, constitute a single-segment routing domain. For an end-to-end segment routing flex algo path, nodes 02 and 05 must readvertise flex algo prefix-SIDs and FAPMs across IGP instances.

Flex algo routes are installed in inet(6)color.0 tables. They could also be installed in colored RIBs, such as junos-rti-tc-<color>.inet(6).3 when use-transport-class statement is configured under routing-options flex-algorithm <id>. To support leaking flex algo prefix-SIDs across IGP instances, the use-transport-class statement must be configured for that flex algo. Leaking of flex algo prefix-SIDs across IGP instances is policy driven. A sample policy configuration is as follows:

When flex algo prefix-SIDs are leaked across IGP instances, FAPM sub-TLV will be advertised with the metric derived from the export policy or the route’s own metric. The metric defined in the export policy has higher precedence over the route’s own metric. Additionally, IS-IS installs a stitched route in the mpls.0 tables to stitch incoming MPLS traffic from one IGP instance to the other.

For information on how to apply export policy on multi-instance IS-IS, see export.

Leaking BGP-LU Prefixes into Flexible Algorithm

You can leak BGP-LU prefixes into the IGP with flex algo prefix-SIDs. You can configure the prefix-segment (and metric) in the policy-statement to leak BGP-LU learned prefixes into flex algo.

For example, in the topology shown in Understanding IS-IS Flexible Algorithms for Segment Routing, the IGP domain includes flex algos 128 and 129. The device R9 resides outside the IGP domain. The device R9 is not reachable via flex algo in the IGP domain. Any traffic destined for device R9 follows a flex algo path till device R5 and then follows the device R5 to R9 link.

When flex algo prefix-SIDs are leaked from BGP-LU to an IGP instance, FAPM sub-TLV will be advertised with the metric derived from the export policy or the route’s own metric. The metric defined in the export policy has higher precedence over the route’s own metric. Additionally, IS-IS installs a stitched route in the mpls.0 tables to stitch incoming MPLS traffic from BGP-LU to IS-IS.

Leaking BGP-CT Prefixes into Flexible Algorithm

You can now leak BGP-CT prefixes into flex algo and vice-versa.

For example, the topology shown in Understanding IS-IS Flexible Algorithms for Segment Routing consists of multiple IS-IS IGP instances. The ISIS-A has flex algo but does not have BGP-CT. In such deployments, BGP-CT prefixes can be leaked into flex algo and vice-versa via policy configurations.

Currently, BGP-CT prefixes do not support carrying the prefix-SID information. Configure a policy for the prefix and associate a prefix-SID on the router that is redistributing the prefix into IS-IS flex algo.

When flex algo prefix-SIDs are leaked from BGP-CT, FAPM sub-TLV will be advertised with the metric derived from the export policy or the route’s metric. The Metric defined in the export policy has higher precedence over the route’s metric. Additionally, IS-IS installs a stitched route in the mpls.0 tables to stitch the incoming MPLS traffic from BGP-CT to IS-IS.

Supported and Unsupported Features

Junos OS supports flexible algorithms in the following scenarios:

• Support for configuring and advertising prefix SIDs for different flexible algorithms.

• Partially supports Internet Draft draft-ietf-lsr-flex-algo-05.txt IGP Flexible Algorithm

• Inter-level (IS_IS) leaking of flexible algorithm prefix SIDs is supported.

Junos OS does not support the following features in conjunction with flexible algorithms:

• Flexible algorithm is applicable only for default unicast topology, IS-IS multi-topology is not supported.

• IS-IS shortcuts and other IS-IS traffic engineering configuration options are not applicable for flexible algorithm computation

• Prefix and SID conflict resolution is not supported.

• Remote loop free alternate functionality is not supported because TI-LFA is the preferred FRR computation

• Extended Admin-Groups (EAG) are not supported because they are not supported in IS-IS.