SR-TE Disjoint Planes using Flex-Algo

Load sr-te.dual.plane.init.cfg

configure
load bootflash:sr-te.dual.plane.init.cfg
commit replace
y

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

Answer

#R1, R3, R5, R7, R9
router isis 1
 flex-algo 128
  advertise

#R1, R4, R6, R10, R7
router isis 1
 flex-algo 129
  advertise

#R7
router isis 1
 int lo1
  add ipv4 uni
   prefix-sid algo 128 index 107
   prefix-sid algo 129 index 207

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

Explanation

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:

#R3
router isis 1
 flex-algo 128
  advertise-definition

R4 only supports flex algo 129:

#R4
router isis 1
 flex-algo 129
  advertise-definition

The PEs support both algos. This allows them to steer traffic along either plane.

#R1
router isis 1
 flex-algo 128
  advertise-definition
 !
 flex-algo 129
  advertise-definition

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:

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

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.)

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

R7 can now set color to steer traffic along one of the planes. For example, let’s steer traffic along the “odd” plane:

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

By changing the color to 20, we can steer traffic along the “even” plane:

#R7
extcommunity-set opaque EVEN
  20
end-set
!
route-policy SRTE
  set extcommunity color EVEN
end-policy

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.

Note for Inter-Domain Flex-Algo

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:

segment-routing
 traffic-eng
  on-demand color 10
   dynamic
    pcep
    !
    metric
     type latency

Not like this:

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

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.