SR-TE PCE Instantiated Policy

Load isis.sr.vpnv4.and.te.enabled.cfg

configure
load bootflash:isis.sr.vpnv4.and.te.enabled.cfg
commit replace
y

Configure R10 as a PCE and R1 as a PCC.

Configure a policy on R10 that uses R1 as a headend and R7 as the end-point. This policy should take the strict path R1-R4-R6-R7. Push this policy to R1 so that it will use this policy for routes with color 10 and nexthop 7.7.7.1.

Answer

#R1
segment-routing
 traffic-eng
  pcc
   source-address ipv4 1.1.1.1
   pce address ipv4 10.10.10.1

#R10
pce
 address ipv4 10.10.10.1
 segment-routing
  traffic-eng
   segment-list name R1_TO_R7
    index 1 address ipv4 10.1.4.4
    index 2 address ipv4 6.6.6.1
    index 3 address ipv4 7.7.7.1
   !
   peer ipv4 1.1.1.1
    policy POL1
     color 10 end-point ipv4 7.7.7.1
     candidate-paths
      preference 100
       explicit segment-list R1_TO_R7

Explanation

You can instantiate policies on PCCs from the PCE itself. To do this, you configure the policy under the pce configuration. The policy configuration looks identical to regular SR-TE policy config, but you do it under the peer configuration.

#R10
pce
 segment-routing
  traffic-eng
   segment-list name R1_TO_R7
    index 1 address ipv4 10.1.4.4
    index 2 address ipv4 6.6.6.1
    index 3 address ipv4 7.7.7.1
   !
   peer ipv4 1.1.1.1
    policy POL1
     color 10 end-point ipv4 7.7.7.1
     candidate-paths
      preference 100
       explicit segment-list R1_TO_R7

R10 pushes this policy to R1 using a PCEP Initiate message. This contains all aspects of the policy - the name, candidate path pref, the path itself and its SID list, etc. R1 replies with a PCEP Report to acknowledge that it has locally installed the policy.

The policy can be viewed on the PCE. There does not appear to be any difference in the show output between an instantiated policy and a PCC-requested policy:

More importantly, we can see that R1 has the policy even though it has no policies in its SR-TE config:

If we do the same on R7 and color the service routes, we should see an end-to-end LSP that follows the explicit path:

#R7
segment-routing
 traffic-eng
  pcc
   source-address ipv4 7.7.7.1
   pce address ipv4 10.10.10.1

#R10
pce
 segment-routing
  traffic-eng
   segment-list name R7_TO_R1
    index 1 address ipv4 10.6.7.6
    index 2 address ipv4 4.4.4.1
    index 3 address ipv4 1.1.1.1
   !
   peer ipv4 7.7.7.1
    policy POL1
     color 10 end-point ipv4 1.1.1.1
     candidate-paths
      preference 100
       explicit segment-list R7_TO_R1

We’ll now color the CE routes:

#R1, R7
extcommunity-set opaque COLOR10
 10
end-set
!
route-policy SET_COLOR
 set extcommunity color COLOR10
end-policy

#R1
router bgp 100
 vrf BLUE
  neighbor 192.168.101.101
   address-family ipv4 unicast
    route-policy SET_COLOR in

#R7
router bgp 100
 vrf BLUE
  neighbor 192.168.107.107
   address-family ipv4 unicast
    route-policy SET_COLOR in

Traffic takes the expected path:

Note that it is possible that the PCE pushes a candidate path with the same pref, color and end-ponit that exists in local config on the PCC. When candidate paths tie with the same preference on a headend, the headend will prefer the locally configured path over the PCEP-originated path.

Also, the PCE can explicitly choose the BSID for the PCC to use, using the following configuration:

pce
 segment-routing
  traffic-eng
   peer ipv4 7.7.7.1
    policy POL1
     binding-sid mpls label <num>