SRv6 uSID w/ Flex Algo

Load top1.vpnv4v6.srv6.usid.flex.algo.init.cfg

#IOS-XR
configure
load top1.vpnv4v6.srv6.usid.flex.algo.init.cfg
commit replace
y

#IOS-XE
config replace flash:top1.vpnv4v6.srv6.usid.flex.algo.init.cfg

Configure a new flex algo that minimizes latency.

• Use flex algo #127

• Use fd00:1::/32 for the uSID block

Latency values are already statically configured on all links.

Ensure that L3VPN traffic for the CUSTOMER VRF that is directed towards XR7 minimizes latency, by using flex algo #128.

Answer

# All XR routers
segment-routing
 srv6
  locators
   locator LATENCY
    micro-segment behavior unode psp-usd
    algorithm 128
    prefix fd00:1:<#>::/48
!
router isis 1
 flex-algo 128
  metric-type delay
  advertise-definition
 !
 exit
 !
 address-family ipv6 unicast
  segment-routing srv6
   locator LATENCY

#XR7
router bgp 100
 segment-routing srv6
  no locator CCIE
 !
 vrf CUSTOMER
  address-family ipv4 unicast
   segment-routing srv6
    locator LATENCY
  !
  address-family ipv6 unicast
   segment-routing srv6
    locator LATENCY

Explanation

In link-state routing protocols, each router independently calculates a shortest cost path to every prefix. Because each router calculates this independently using the same algorithm, loop-freeness is ensured, and hop-by-hop routing works. (A circuit does not need to be established; routing is connectionless).

Flex-algo gives us the power to create a second topology by specifying a different optimization metric besides the IGP shortest cost, and also by specifying constraints. This allows us to gain TE capabilities without any state at all. (No SR-TE policies and no connection-oriented LSPs). This only works because every router in the IGP agrees that a given SID will use the associated algorithm for determining the best path. All routers in the IGP use the same exact algorithm for determining a SID’s best path, and hence the TE objective is realized without any state.

First we advertise the flex-algo definition into the IGP. Only one router must have this config, but for redundancy you should configure this on multiple routers. It’s no problem if every single router has this configuration.

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

This FAD (flex algo definition) is advertised into the IGP.

If there are any conflicts in the definition for a given flex algo, the prioirty is used as the tiebreaker. The highest priority is best, and then the highest RID is best. We can see the results of the flex algo “election” using the following command:

Next we must create a SID that is associated with this flex algo. With SR-MPLS, we would simply add another prefix-SID to the loopback. With SRv6, we create a new locator.

segment-routing
 srv6
  locators
   locator LATENCY
    micro-segment behavior unode psp-usd
    algorithm 128
    prefix fd00:1:<#>::/48
!
router isis 1
 address-family ipv6 unicast
  segment-routing srv6
   locator LATENCY

The locator is advertised with algorithm 128 into the IGP:

Now we can steer traffic using this locator. This will achieve routing based on lowest latency instead of lowest IGP cost, and it will do this without any SR-TE policies needed.

Although we have the ability to create an ODN policy that uses a particular flex algo, the SRv6 PCE cannot use flex algo as part of path computation. Normally we could do this:

segment-routing
 traffic-eng
  on-demand color 10
   srv6
    locator CCIE binding-sid dynamic behavior ub6-insert-reduced
   !
   source-address ipv6 2001:db8:200::5
   dynamic
   !
   constraints
    segments
     sid-algorithm 128

However, the PCE will not successfully calculate a path. We can see this in the SRv6 SR-TE guidelines:

Additionally, the headend can never compute its own dynamic paths. A PCE is always needed for dynamic SR-TE SRv6 policies.

Therefore, our only option appears to be to simply use the flex algo locator for the CUSTOMER VRF on R7. First we remove the global BGP locator and then set the specific locator for the address-families under the VRF:

#XR7
router bgp 100
 segment-routing srv6
  no locator CCIE
 !
 vrf CUSTOMER
  address-family ipv4 unicast
   segment-routing srv6
    locator LATENCY
  !
  address-family ipv6 unicast
   segment-routing srv6
    locator LATENCY

Alternatively, we can leave the CCIE locator as the default locator under BGP, but specify the CUSTOMER VRF locator as the LATENCY locator.

#XR7
router bgp 100
 segment-routing srv6
  locator CCIE
 !
 vrf CUSTOMER
  address-family ipv4 unicast
   segment-routing srv6
    locator LATENCY
    alloc mode per-vrf
  !
  address-family ipv6 unicast
   segment-routing srv6
    locator LATENCY
    alloc mode per-vrf

Note that you can also control which locator is used on a per-prefix basis with an RPL:

route-policy SRv6_POLICY
  if destination in (3.3.3.3/32) then
    set srv6-alloc-mode per-vrf locator LATENCY
  else
    set srv6-alloc-mode per-vrf locator CCIE
  endif
end-policy
!
router bgp 100
 vrf CUSTOMER
  address-family ipv4 unicast
   segment-routing srv6
    alloc mode route-policy SRv6_POLICY

We can see that XR7 now allocates a SID from the LATENCY locator instead of the CCIE locator:

A traceroute to this SID gives us a sort of OAM verification. We can see that the path takes the lowest latency path to XR7:

The beauty of this is that there is no complex SID list needed for this. There is simply a single SID, which has the instruction to forward over the lowest latency path instead of the lowest IGP cost path. This essentially enables a multi-topology network.