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.
Last updated