In the previous article, paths were calculated on the headend itself. This is called distributed calculation, because SR-TE path calculation in a network is distributed amongst all routers. Each router calculates its own path for which it is a headend.
In certain circumstances a centralized path calculation device is needed. When paths among different headends need to be disjoint from each other, bandwidth needs to be allocated for paths, or paths need to traverse multi-area/domain, a PCE is needed. This is called centralized calculation, because a central entity needs to do path calculation for all headend routers in the network.
A PCE (Path Computation Element) is a device which supports PCEP (PCE protocol) and can calculate paths on behalf of clients. A headend router that delegates path calculation to a PCE is called a PCC (Path Computation Client). The PCC and PCE follow a client/service model, using PCEP for communication.
The PCE needs to have every IGP’s LSDB in its SR-TE DB that it will support. The PCE can support multiple IGP areas or instances. Typically BGP-LS (BGP Link State) is used to feed the PCE’s SR-TE DB. The PCE can also learn the LSDB from a locally attached IGP. You can deploy PCEs in a RR-like manner, with multiple independent PCEs for redundancy. The PCE is stateful because it stores each path request, which allows it to calculate paths based on other existing paths (path disjoint, bandwidth allocation, etc).
In this lab we will use IOS-XR as a PCE.
Lab
We will split the topology from the previous article into two separate IGP domains to demonstrate the need for a PCE. R1 and R2 run OSPF process 2, and all other routers run OSPF process 1. R2 is an inter-domain border router as it participates in both IGPs.
#R1
no router ospf 1
!
router ospf 2
segment-routing mpls
area 0
mpls traffic-eng
interface Loopback0
prefix-sid index 1
!
interface GigabitEthernet0/0/0/0
network point-to-point
!
!
mpls traffic-eng router-id Loopback0
#R2
router ospf 1
area 0
no int Gi0/0/0/0
!
router ospf 2
segment-routing mpls
area 0
mpls traffic-eng
int Gi0/0/0/0
network point-to-point
int lo0
prefix-sid index 2
mpls traffic-eng router-id Lo0
All SR-TE policies are currently down on R1.
RP/0/RP0/CPU0:R1#show segment-routing traffic-eng policy summary
Mon Sep 5 18:50:57.650 UTC
SR-TE policy database summary:
----------------------------
Total policies: 3
Operational: up 0 down 3
Per-Destination Policies Summary:
Total configured: 3
Operational: up 0 down 3
Per-Flow Policies Summary:
Total configured: 0
Operational: up 0 down 0
Total candidate paths: 3
State: active 0 inactive 3
Let’s configure R2 to be a PCE. Normally this would be a different router in each domain and they would peer with the RR in their domain using BGP-LS, but for simplicity we’ll configure R2 as PCE to focus on the interaction between PCC and PCE.
As you saw in the previous article, we need to distribute the IGP LSDB into the SR-TE DB. When you have multiple IGP DBs, you keep them separate by using an instance id.
You can verify that R2 is acting as a PCE and has both IGP LSDBs in its topology with the following command:
RP/0/RP0/CPU0:R2#show pce ipv4 top br
Mon Sep 5 18:56:19.810 UTC
PCE's topology database - brief:
--------------------------------
Node 1
TE router ID: 2.2.2.2
OSPF router ID: 2.2.2.2 area ID: 0 ASN: 0 domain ID: 1
OSPF router ID: 10.1.2.2 area ID: 0 ASN: 0 domain ID: 2
Link[0]: local address 10.2.3.2, remote address 10.2.3.3
Link[1]: local address 10.2.5.2, remote address 10.2.5.5
Link[2]: local address 10.2.4.2, remote address 10.2.4.4
Link[3]: local address 10.1.2.2, remote address 10.1.2.1
Node 2
TE router ID: 3.3.3.3
OSPF router ID: 10.2.3.3 area ID: 0 ASN: 0 domain ID: 1
Link[0]: local address 10.2.3.3, remote address 10.2.3.2
Link[1]: local address 10.3.4.3, remote address 10.3.4.4
Node 3
TE router ID: 10.2.5.5
OSPF router ID: 10.2.5.5 area ID: 0 ASN: 0 domain ID: 1
Link[0]: local address 10.2.5.5, remote address 10.2.5.2
Link[1]: local address 10.5.6.5, remote address 10.5.6.6
Node 4
TE router ID: 4.4.4.4
OSPF router ID: 10.3.4.4 area ID: 0 ASN: 0 domain ID: 1
Link[0]: local address 10.2.4.4, remote address 10.2.4.2
Link[1]: local address 10.3.4.4, remote address 10.3.4.3
Link[2]: local address 10.4.6.4, remote address 10.4.6.6
Node 5
TE router ID: 6.6.6.6
OSPF router ID: 10.4.6.6 area ID: 0 ASN: 0 domain ID: 1
Link[0]: local address 10.5.6.6, remote address 10.5.6.5
Link[1]: local address 10.4.6.6, remote address 10.4.6.4
Node 6
TE router ID: 1.1.1.1
OSPF router ID: 1.1.1.1 area ID: 0 ASN: 0 domain ID: 2
Link[0]: local address 10.1.2.1, remote address 10.1.2.2
On R1 we will configure it to act as PCC, using the PCE at 2.2.2.2, and to use the PCE for each policy’s calculation. Since the GREEN policy was a strict path, it cannot use a PCE, and it also cannot calculate the adjacency SID for 10.5.6.5 because it is is another IGP now. We will skip the GREEN policy and leave it down.
R1’s paths for the RED and BLUE policies are now up and valid. The PCE, with both IGP LSDBs in its SR-TE DB, can calculate the two paths with the link affinity constraints.
RP/0/RP0/CPU0:R1#show segment-routing traffic-eng policy
Mon Sep 5 19:05:37.808 UTC
SR-TE policy database
---------------------
Color: 20, End-point: 6.6.6.6
Name: srte_c_20_ep_6.6.6.6
Status:
Admin: up Operational: up for 00:00:01 (since Sep 5 19:05:36.392)
Candidate-paths:
Preference: 100 (configuration) (active)
Name: RED
Requested BSID: dynamic
PCC info:
Symbolic name: cfg_RED_discr_100
PLSP-ID: 3
Constraints:
Affinity:
include-all:
RED
Maximum SID Depth: 10
Dynamic (pce 2.2.2.2) (valid)
Metric Type: TE, Path Accumulated Metric: 4
24000 [Adjacency-SID, 10.1.2.1 - 10.1.2.2]
16003 [Prefix-SID, 3.3.3.3]
16006 [Prefix-SID, 6.6.6.6]
Attributes:
Binding SID: 24011
Forward Class: Not Configured
Steering labeled-services disabled: no
Steering BGP disabled: no
IPv6 caps enable: yes
Color: 30, End-point: 6.6.6.6
Name: srte_c_30_ep_6.6.6.6
Status:
Admin: up Operational: up for 00:00:02 (since Sep 5 19:05:35.404)
Candidate-paths:
Preference: 100 (configuration) (active)
Name: BLUE
Requested BSID: dynamic
PCC info:
Symbolic name: cfg_BLUE_discr_100
PLSP-ID: 4
Constraints:
Affinity:
include-all:
BLUE
Maximum SID Depth: 10
Dynamic (pce 2.2.2.2) (valid)
Metric Type: TE, Path Accumulated Metric: 3
24000 [Adjacency-SID, 10.1.2.1 - 10.1.2.2]
16004 [Prefix-SID, 4.4.4.4]
16006 [Prefix-SID, 6.6.6.6]
Attributes:
Binding SID: 24010
Forward Class: Not Configured
Steering labeled-services disabled: no
Steering BGP disabled: no
IPv6 caps enable: yes
On R2 you can see the PCEP session and statistics:
RP/0/RP0/CPU0:R2#show pce ipv4 peer 1.1.1.1 detail
Mon Sep 5 19:11:43.958 UTC
PCE's peer database:
--------------------
Peer address: 1.1.1.1
State: Up
Capabilities: Stateful, Segment-Routing, Update, Instantiation
PCEP has been up for: 00:06:06
PCEP session ID: local 0, remote 0
Sending KA every 30 seconds
Minimum acceptable KA interval: 20 seconds
Peer timeout after 120 seconds
Maximum SID Depth: 10
Statistics:
Keepalive messages: rx 13 tx 13
Request messages: rx 0 tx 0
Reply messages: rx 0 tx 0
Error messages: rx 0 tx 0
Open messages: rx 1 tx 1
Report messages: rx 11 tx 0
Update messages: rx 0 tx 2
Initiate messages: rx 0 tx 0
Last PCError:
Received: None
Sent: None
Path Disjointness
If you would like two policies on separate headends to use different paths, you must use a PCE. This is because each headend can only know its own locally calculated path. If both headends use a common PCE, the PCE can intelligently calculate two paths that are disjoint from each other and give the results to each headend.
To demostrate this in our lab, we will configure a policy between R3 and R6 that has a node-disjoint LSP in each direction. The LSP from R3 to R6 should use a completely separate path from the LSP from R6 to R3.
The configuration for this is actually quite simple. You just use the same disjoint-path group-id on each policy.
The path on R3 simply uses the prefix SID of 16006 and will take the lowest cost IGP path to 6.6.6.6. The path on R6 requires traffic to first be steered to R5 (16005), and then it will take R5’s lowest cost IGP path to R3 which is via R2.
Examining the PCEP messages between PCC and PCE
The PCC first sends the PCE a Report message. This contains information about the LSPs with an empty ERO. Essentially the PCC is indirectly asking the PCE to calculate the ERO, by telling the PCE the paths it has with no ERO.
Here we see the Report for the RED policy. The ERO is empty. You can also see that TCP port 4189 is used by PCEP
The next section in the same packet shows the information about the BLUE policy. The ERO is empty.
The PCE responds with an Update message, first for the RED policy. It contains the ERO for the LSP:
The PCC responds with a Report message containing the same information. This report message is similar to the previous one, except now it contains the ERO.
The PCE then responds with the Update message for the BLUE policy:
The PCC responds with another Report message for the BLUE policy with the ERO now populated.
This workflow is called Report/Update/Report because the PCC sends a Report with an empty ERO, the PCE sends the Update with the ERO populated, and the PCC confirms with another Report. The last Report is essentially a confirmation that the headend has programmed this SID list into its policy.
Conclusion
We’ve now seen how to create SR-TE policies both locally on the headend and using a PCE. We have not steered traffic along these LSPs yet. In the next article, we will see how traffic actually gets steered along these paths.
