SR-TE Disjoint Planes using Flex-Algo
Last updated
Last updated
Load sr-te.dual.plane.init.cfg
The core routers (R3, R5, R4, R6, R9, R10) are in two separate “planes”: odd and even. The IGP costs have been adjusted so that core links between routers in different planes are high, but links connecting each PE to each plane are the same (10). Also, each router has already configured its TE RID and is distributing link-state under the IGP.
Using flex-algo, configure two ODN policies on R1 as follows:
Color 10 uses the “odd” plane
Color 20 uses the “even” plane
Using flex algo can be a more graceful way to implement disjoint planes without configuring link affinities or anycast SIDs (which require additional prefixes).
To completely separate the planes, the core routers will only belong to one of the two flex algos: either 128 or 129. To do this, we only configure support for either flex algo on each core router.
For example, R3 only supports flex algo 128:
R4 only supports flex algo 129:
The PEs support both algos. This allows them to steer traffic along either plane.
When a router calculates a path for either flex algo, all the nodes that don’t support that algo are pruned from the topology. This explicitly creates two completely separate planes. Note that this does not allow for failover between the planes in case of multiple link failures. However, if a link failure within a flex-algo plane causes a policy to go down, that policy can failover to the IGP path.
R7 advertises two additional prefix SIDs, one per plane:
Note that the core nodes don’t even install the prefix SID into the LFIB for an algorithm for which it does not support. For example, R4 only installs an LFIB entry for prefix SID with index 207.
R1 creates two ODN policies, one per plane. This is much more scalable than using anycast SIDs, which requires an explicit path for each policy, and one policy for every remote PE. (This is because we must use the anycast SID as part of the policy, which requires an explicit path. ODN policies cannot use an explicit path.)
R7 can now set color to steer traffic along one of the planes. For example, let’s steer traffic along the “odd” plane:
By changing the color to 20, we can steer traffic along the “even” plane:
This concept is highly utilized in 5G environments, where there are lots of different applications which might have different constraints and require disjoint paths or planes. Flex algo can be used to define separate logical topologies and constraints for each logical topology.
When using flex-algo for inter-domain LSPs, you should only use the metric-type on the ODN policy, and not the flex-algo as a constraint.
So use a policy like this:
Not like this:
The reason is two fold:
The sid algorithm is not supported as a constraint for PCEP
The flex-algo number might have a different meaning for each domain
However, when still using the explicit dynamic metric type, the PCE will still calculate the path using the flex algo SIDs if they solve the path. So the signalled path will still use an end-to-end flex-algo prefix SID if both domains have the same definition for that flex algo number.
