SR-TE Flex-Algo w/ Latency

Load sr-te.flex-algo.init.cfg

configure
load bootflash:sr-te.flex-algo.init.cfg
commit replace
y

Latency is configured in the core so that the lowest delay path from R1 to R7 is R1-R4-R3-R6-R7. Using flex algo and ODN, produce an LSP from R1-R7 that only uses a single prefix SID and follows this path.

Answer

#All routers
router isis 1
 flex-algo 128
  metric-type delay
  advertise-definition

#R1
segment-routing
 traffic-eng
  on-demand color 10
   dynamic
    sid-algorithm 128

#R7
router isis 1
 interface Loopback1
  address-family ipv4 unicast
   prefix-sid algorithm 128 index 107

Explanation

By default, two algorithms are supported for prefix SIDs. Algo 0 means “IGP path” and algo 1 means “strict IGP path.” Algo 0 is not “strict” because it allows routers along the path to steer traffic into non-IGP paths based on local policy, such as using as MPLS-TE tunnels that use autoroute announce.

We are also given the ability to define our own custom algorithms and attach them to prefix SIDs. Algorithms 0-127 are reserved for standardized algorithms, and algorithms 128-255 are available for operator use, hence these are “flexible algorithms” or “flex algos.”

Each flex algo can have its own custom definition. Think of these as taking place of SR-TE policies. For example, flex algo #130 can mean “use delay as the metric and avoid BLUE links.”

You must associate a flex algo with a prefix SID. You can use multiple prefix SIDs per loopback, which allows for scalability. (You don’t need a new loopback prefix for each flex algo. You only need a unique SID for each flex algo).

You usually use flex algos with an ODN policy. However, it seems you can also use flex algo as a constraint for a manual policy with an explicit endpoint.

segment-routing
 traffic-eng
  policy TEST
   color 10 end-point ipv4 7.7.7.1
   candidate-paths
    preference 10
     dynamic
     !
     constraints
      segments
       sid-algorithm 128

To begin, you must configure support for the flex algo on each router which you want to support this algorithm. (To produce disjoint planes, you might not want some routers to support certain flex algos). This is done using the following command under the IGP:

router isis 1
 flex-algo 128

Next, you specify the flex-algo defintion on any router in the IGP. Only one router needs to advertise the flex algo definition. However, for redundancy, multiple routers should advertise this, or you can configure it on all routers. A priority is used to determine which definition to use in case there are conflicting definitions being advertised in the IGP. By default, priority 128 is used. A value between 0-255 can be specified. If you do not specify a metric-type, the default is “IGP.”

router isis 1
 flex-algo 128
  metric-type delay
  affinity exclude-any ...
  advertise-definition

In the solution for this lab, we can simply enable support for the flex algo and configure the definition using:

router isis 1
 flex-algo 128
  metric-type delay
  advertise-definition

At this point, all routers should advertise that they support the new algorithm in their Router Capabilities TLV. They support it even though there is no prefix SIDs advertised in the IGP for this algorithm yet. Additionally, all routers are advertising the flex algo defintion.

• The Algorithm is shown first, 128 here

• Metric-type 1 means “latency”

• Algorithm type 0 means “IGP”

  • This is the only available option on IOS-XR

• The default priority is 128

When the priority is a tie, the tiebreaker is the highest ISIS SysID or OSPF RID. We can see that all routers should be using R10’s definition since it has the highest SysID. Even though each router is locally advertising the definition, the basic tiebreaker rules still apply. The local definition doesn’t have any special preference.

Now all that is left to do is advertise prefix SIDs using this flex algo. Normally you would do this on all nodes in order to support TI-LFA for this flex algo. When TI-LFA is enabled, it will by default calculate backup paths on a per-algo basis, and the backup path will honor that particular flex algo’s definition. This means that prefix SIDs for algo 128 will have FRR protection that uses algo 128 (not algo 0). This is a very nice way to automatically get full FRR protection that honors the intent of the flex algo. But for this lab, we only need to advertise a prefix SID from R7 since that is our egress node.

#R7
router isis 1
 interface Loopback1
  address-family ipv4 unicast
   prefix-sid algorithm 128 index 107

We should see that R7 now includes an additional prefix SID for its lo1 address:

All routers will install an LFIB entry for this prefix SID that uses the flex algo algorithm instead of IGP shortest path. For instance, on R4, the outgoing interface is R3, not R5. This is because the minimized latency path is via R3.

You can almost think of this as all routers independently calculating an SR-TE policy per prefix SID matching the flex algo. The flex algo definition defines the common SR-TE policy. Another way to look at this, is that it re-introduces the old concept of multi-topology routing with ISIS. You have multiple metrics advertised into the IGP, and you can choose which metric to optimize for SPF. However, this is of course slightly different, as the flex algo is bound to the MPLS or SRv6 data plane.

We should also briefly explore the latency metrics that were pre-configured in the init file. Each router manually defines a latency value under the performance-measurement config section. Latency values are only defined on the links in the R1-R4-R3-R6-R7 path for this lab. When using latency for flex-algo, any links that do not have a latency defined are pruned from the flex-algo topology. (However, when using latency for SR-TE policies, any links that do not have latency defined have the TE metric substitued for the latency value when CSPF runs).

#R1
performance-measurement
 interface GigabitEthernet0/0/0/4
  delay-measurement
   advertise-delay 1000

This value is advertised into the IGP here:

R1 now can define an SR-TE ODN policy that matches some color (ex. 10) and uses flex-algo 128.

#R1
segment-routing
 traffic-eng
  on-demand color 10
   dynamic
    sid-algorithm 128

We’ll now color routes from R7:

#R7
extcommunity-set opaque LOW_LATENCY
 10
end-set
!
route-policy LOW_LATENCY_ODN
 set extcommunity color LOW_LATENCY
end-policy
!
router bgp 100
vrf BLUE
  neighbor 192.168.107.107
   address-family ipv4 unicast
    route-policy LOW_LATENCY_ODN in

R1 will auto-instantiate the policy. Notice that flex-algo 128 is a constraint, and that the path is simply the prefix SID for flex-algo 128 from R7.

A traceroute from CE101 to CE107 shows that only one transport label is used to steer along this low-latency path.

Using flex algo instead of a SR-TE policy that minimizes delay provides a few benefits. One, it reduces the SID list to a single prefix SID. Two, it makes TI-LFA more robust, as the TI-LFA backup route must adhear to the flex algo definition. (When simply using flex-algo 0 and a latency optimization SR-TE policy, FRR will not use the post-convergence latency optimized path).

Also note that no IP-to-MPLS entires are installed in the FIB for flex algo labels. The IP to label mapping will always be algo 0. You can only use a flex-algo LSP by specifically steering traffic into it, which will most often be done using ODN. Below, we see that the prefix 7.7.7.1/32 is still resolved to the algo 0 prefix SID that R7 advertised: