SR-MPLS Flex-Algo

Traditionally, IGPs can use only the SPF algorithm to calculate the shortest paths to destination addresses based on link costs. As the SPF algorithm is fixed and cannot be adjusted by users, the optimal paths cannot be calculated according to users' diverse requirements, such as the requirement for traffic forwarding along the lowest-delay path or without passing through certain links.

On a network, constraints used for path calculation may be different. For example, as autonomous driving requires an ultra-low delay, an IGP needs to use delay as the constraint to calculate paths on such a network. Another constraint that needs to be considered is cost, so some links with high costs need to be excluded in path calculation. These constraints may also be combined.

To make path calculation more flexible, users may want to customize IGP route calculation algorithms to meet their varying requirements. They can define an algorithm value to identify a fixed algorithm. When all devices on a network use the same algorithm, their calculation results are also the same, preventing loops. Since users, not standards organizations, are the ones to define these algorithms, they are called Flex-Algos.

With Flex-Algo, an IGP can automatically calculate eligible paths based on the link cost, delay, or TE constraint to flexibly meet TE requirements. This means that when SR-MPLS uses an IGP to calculate paths, prefix SIDs can be associated with Flex-Algos to calculate SR-MPLS BE paths that meet different requirements.

SR-MPLS Flex-Algo Advertisement

Each device can use an IGP to advertise their supported Flex-Algos and the related calculation rules through the FAD Sub-TLV.

These Flex-Algos can also be associated with prefix SIDs during prefix SID configuration. The IGP then advertises the Flex-Algos and prefix SIDs through the Prefix-SID Sub-TLV.

The Flex-Algo value occupies 8 bits in the FAD Sub-TLV and Prefix-SID Sub-TLV. Values 128 to 255 are reserved for users to customize the Flex-Algos represented by these values.

To ensure that the forwarding path calculated by an IGP is loop free, the same Flex-Algo must be used across an IGP domain. IS-IS advertises its Flex-Algo Definition (FAD) through the IS-IS FAD Sub-TLV.

IS-IS FAD Sub-TLV

IS-IS uses the IS-IS Router Capability TLV-242 to carry the IS-IS FAD Sub-TLV and advertises the sub-TLV to neighbors. Figure 1 shows the format of the IS-IS FAD Sub-TLV.

Figure 1 Format of the IS-IS FAD Sub-TLV

Table 1 describes the fields in the IS-IS FAD Sub-TLV.

**Table 1** Fields in the IS-IS FAD Sub-TLV
Field	Length	Description
Type	8 bits	Type of the sub-TLV.
Length	8 bits	Total length of the sub-TLV (excluding the Type and Length fields).
Flex-Algo	8 bits	Flex-Algo ID, which is an integer ranging from 128 to 255.
Metric-Type	8 bits	Metric type used during calculation, which can be IGP metric, link delay, or TE metric.
Calc-Type	8 bits	Calculation type, which currently can only be SPF and does not need setting.
Priority	8 bits	Priority of the sub-TLV.
Sub-TLVs	Variable	Optional sub-TLVs, which can define some constraints.

A Flex-Algo is defined by users and generally represented by a 3-tuple: Metric-Type, Calc-Type, and Constraints. Metric-Type and Calc-Type have been described in Table 1. Constraints include the following:

Exclude Admin Group: A link is excluded from path calculation if any bit in the link's administrative group has the same name as an affinity bit referenced by the administrative group.
Include-Any Admin Group: A link is included in path calculation as long as one bit in the link's administrative group has the same name as an affinity bit referenced by the administrative group.
Include-All Admin Group: A link is included in path calculation only if all bits in the link's administrative group have the same names as the affinity bits referenced by the administrative group.

These constraints are described by the Sub-TLVs field in the FAD Sub-TLV and share the same format, as shown in Figure 2.

Figure 2 Format of the Exclude/Include-Any/Include-All Admin Group Sub-TLV

In the same IGP domain, different devices may define Flex-Algos that have the same value but different meanings. When FADs are different, the devices select a FAD according to the following rules:

The FAD with the highest priority is preferentially selected.
If the priorities of the FADs advertised by devices are the same, the FAD advertised by the device with the largest system ID is selected.

SR-Algorithm Sub-TLV

A node may use different algorithms to calculate reachability to other nodes or to prefixes attached to these nodes. Examples of these algorithms are SPF and various SPF variant algorithms. The SR-Algorithm sub-TLV allows the node to advertise the algorithms that the node is currently using. It is also inserted into the IS-IS Router Capability TLV-242 for transmission. The SR-Algorithm sub-TLV can be propagated only within the same IS-IS level and must not be propagated across IS-IS levels.

Figure 3 shows the format of the SR-Algorithm sub-TLV.

Figure 3 SR-Algorithm sub-TLV format

**Table 2** Fields in the SR-Algorithm sub-TLV
Field	Length	Description
Type	8 bits	Unassigned. The recommended value is 2.
Length	8 bits	Packet length.
Algorithm	8 bits	Algorithm that is used.

SR-MPLS Flex-Algo Implementation

Figure 4 is used as an example to describe how SR-MPLS Flex-Algo is implemented.

A device using Flex-Algos for path calculation must advertise its Flex-Algos to other devices.

PE1 and PE2 use both Flex-Algos 128 and 129, which are advertised to all the other nodes on the network through an IGP's SR-Algorithm Sub-TLVs.
P1 to P4 use Flex-Algo 128, which is also advertised through the IGP.
P5 to P8 use Flex-Algo 129, which is also advertised through the IGP.

Besides Flex-Algos 128 and 129, all devices support the most basic IGP cost-based algorithm, which has value 0. This algorithm is not advertised through the SR-Algorithm Sub-TLV.

Figure 4 SR-MPLS Flex-Algo implementation

After a prefix SID is associated with a Flex-Algo on PE2, other devices on the network calculate a route to the prefix SID based on the Flex-Algo. As this configuration method repeats, different prefix SID routes that represent different paths calculated using different Flex-Algos can be generated, meeting diverse service requirements.

For example, in Figure 4, Flex-Algo 128 is defined as follows: calculate a path based on the IGP cost and link affinity, with the constraint being Exclude Admin Group (excluding the links between P2 and P3 as well as between P2 and P4). Figure 5 shows the possible path obtained on PE1 with this Flex-Algo.

Figure 5 PE1 calculating a path to PE2 based on Flex-Algo 128

Conflict Handling of Flex-Algo-Associated Prefix SIDs

Prefix SIDs are manually set and therefore may conflict on different devices. Prefix SID conflicts can occur in either the prefix or SID. A prefix conflict indicates that the same prefix with the same Flex-Algo is associated with different SIDs, whereas a SID conflict indicates that the same SID is associated with different prefixes.

If prefix SIDs conflict, handle prefix conflicts before SID conflicts by matching the following rules to preferentially select a route:

The route with the largest prefix mask is preferred.
The route with the smallest prefix is preferred.
The route with the smallest SID is preferred.
The route with the smallest algorithm value is preferred.

For example, there are prefix SID conflicts in the following 7 routes expressed in the prefix/mask length SID Flex-Algo format:

a. 1.1.1.1/32 1 128
b. 1.1.1.1/32 2 128
c. 2.2.2.2/32 3 0
d. 3.3.3.3/32 1 0
e. 1.1.1.1/32 4 129
f. 1.1.1.1/32 1 0
g. 1.1.1.1/32 5 128

The process for handling the prefix SID conflicts is as follows:

Prefix conflicts are handled first. Routes a, b, and g encounter a prefix conflict because they share the same prefix and algorithm but contain different SIDs. Route a has the smallest SID, and therefore is preferred. After routes b and g are excluded, the following routes are left:
- a. 1.1.1.1/32 1 128
- c. 2.2.2.2/32 3 0
- d. 3.3.3.3/32 1 0
- e. 1.1.1.1/32 4 129
- f. 1.1.1.1/32 1 0
SID conflicts are then handled. Routes a, d, and f encounter a SID conflict. Routes a and f have a smaller prefix than route d, and therefore a and f are preferred to d. As f has a smaller algorithm value than a, f is preferred. After the SID conflict is removed, the following three routes are left:
- c. 2.2.2.2/32 3 0
- e. 1.1.1.1/32 4 129
- f. 1.1.1.1/32 1 0

Service Traffic Steering into an SR-MPLS BE Path Based on Flex-Algo

Figure 6 shows how service traffic is steered into an SR-MPLS BE path based on Flex-Algo. The specific process is as follows:

Configure PE1 and PE2 to use both Flex-Algos 128 and 129; configure P1 to P4 to use Flex-Algo 128, and P5 to P8 to use Flex-Algo 129.
On PE2, configure the prefix SID with index 200 to use Flex-Algo 128. The prefix SID with index 100 uses the default algorithm 0, that is, the IGP cost-based SPF algorithm.
Configure BGP on PE2 to advertise a VPNv4 route with prefix 10.1.1.0/24 and next hop 10.1.1.1. The extended community attribute color 100 is added to the route based on an export route-policy.
Configure the mapping between the color and Flex-Algo on PE1. IGP uses algorithm 0 to calculate a common SR-MPLS BE tunnel for the prefix SID with index 100 and uses Flex-Algo 128 to calculate a Flex-Algo-based SR-MPLS BE tunnel for the prefix SID with index 200.
Configure a tunnel policy on PE1 and apply the tunnel policy to the VPN instance.
After the configuration is complete, the VPN route is recursed based on the tunnel policy. Specifically, if the tunnel policy specifies a preferential use of Flex-Algo-based SR-MPLS BE tunnels, the VPN route is recursed to the target Flex-Algo-based SR-MPLS BE tunnel based on the next hop address and color attribute of the route; if the tunnel policy specifies a preferential use of common SR-MPLS tunnels, the VPN route is recursed to the target common SR-MPLS BE tunnel based on the next hop address of the route.

Figure 6 Service traffic steering into an SR-MPLS BE path based on Flex-Algo