SRv6 uSID w/ Flex Algo
Load 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
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.
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.
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:
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:
Alternatively, we can leave the CCIE locator as the default locator under BGP, but specify the CUSTOMER VRF locator as the LATENCY locator.
Note that you can also control which locator is used on a per-prefix basis with an RPL:
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
