# SR-TE Pt. 3 (Using a PCE)

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 <a href="#id-8fa7df0a-8127-4971-ad9f-dfa3064c9f97" id="id-8fa7df0a-8127-4971-ad9f-dfa3064c9f97"></a>

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.

<figure><img src="https://1203572585-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgAMH3CMtmYTBkob03NUj%2Fuploads%2FOP6UKB1zqIakH9gfpN1W%2FUntitled.png?alt=media&#x26;token=a90527bd-13c7-4614-99f5-ee284a422cac" alt=""><figcaption></figcaption></figure>

```
#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.

```
#R2
pce
 address ipv4 2.2.2.2
!
router ospf 1
 distribute link-state instance-id 1
!
router ospf 2
 distribute link-state instance-id 2
```



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
segment-routing traffic-eng
 pcc
  pce address ipv4 2.2.2.2
  exit
 exit
 policy RED
  candidate-paths preference 100 dynamic pcep
 policy BLUE
  candidate-paths preference 100 dynamic pcep
```



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.

```
#R3
segment-routing traffic-eng
 pcc
  pce address ipv4 2.2.2.2
 policy TO_R6
  color 10 end-point ipv4 6.6.6.6
  candidate-paths preference 100 
   dynamic
    pcep
   constraints
    disjoint-path group-id 1 type node

#R6
segment-routing traffic-eng
 pcc
  pce address ipv4 2.2.2.2
 policy TO_R3
  color 10 end-point ipv4 3.3.3.3
  candidate-paths preference 100 
   dynamic
    pcep
   constraints
    disjoint-path group-id 1 type node
```



Examine the path that was calculated for each headend:

```
RP/0/RP0/CPU0:R3#show segment-routing traffic-eng policy 
Mon Sep  5 19:22:59.852 UTC

SR-TE policy database
---------------------

Color: 10, End-point: 6.6.6.6
  Name: srte_c_10_ep_6.6.6.6
  Status:
    Admin: up  Operational: up for 00:00:04 (since Sep  5 19:22:55.444)
  Candidate-paths:
    Preference: 100 (configuration) (active)
      Name: TO_R6
      Requested BSID: dynamic
      PCC info:
        Symbolic name: cfg_TO_R6_discr_100
        PLSP-ID: 1
        Maximum SID Depth: 10 
      Dynamic (pce 2.2.2.2) (valid)
        Metric Type: TE,   Path Accumulated Metric: 2 
          16006 [Prefix-SID, 6.6.6.6]
  Attributes:
    Binding SID: 24003
    Forward Class: Not Configured
    Steering labeled-services disabled: no
    Steering BGP disabled: no
    IPv6 caps enable: yes


RP/0/RP0/CPU0:R6#show segment-routing traffic-eng policy 
Mon Sep  5 19:23:28.047 UTC

SR-TE policy database
---------------------

Color: 10, End-point: 3.3.3.3
  Name: srte_c_10_ep_3.3.3.3
  Status:
    Admin: up  Operational: up for 00:00:02 (since Sep  5 19:23:25.592)
  Candidate-paths:
    Preference: 100 (configuration) (active)
      Name: TO_R3
      Requested BSID: dynamic
      PCC info:
        Symbolic name: cfg_TO_R3_discr_100
        PLSP-ID: 1
        Maximum SID Depth: 10 
      Dynamic (pce 2.2.2.2) (valid)
        Metric Type: TE,   Path Accumulated Metric: 3 
          16005 [Prefix-SID, 5.5.5.5]
          16003 [Prefix-SID, 3.3.3.3]
  Attributes:
    Binding SID: 24003
    Forward Class: Not Configured
    Steering labeled-services disabled: no
    Steering BGP disabled: no
    IPv6 caps enable: yes
```

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.

<figure><img src="https://1203572585-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgAMH3CMtmYTBkob03NUj%2Fuploads%2F3nA7UIaFFVPxLg4VQzCv%2FUntitled%201.png?alt=media&#x26;token=ba3c33cb-d35f-46eb-8393-7d8379b8a375" alt=""><figcaption></figcaption></figure>

* 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



<figure><img src="https://1203572585-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgAMH3CMtmYTBkob03NUj%2Fuploads%2FqBfSNrpMblljXUovxV5r%2FUntitled%202.png?alt=media&#x26;token=e398af22-ec09-4f61-b89b-c458f721413a" alt=""><figcaption></figcaption></figure>

* 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:

<figure><img src="https://1203572585-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgAMH3CMtmYTBkob03NUj%2Fuploads%2FdNpVJQ25dJd6XijjHkpj%2FUntitled%203.png?alt=media&#x26;token=13778c99-4d2b-4ab7-b3f7-fa97c48cf1f5" alt=""><figcaption></figcaption></figure>



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:

<figure><img src="https://1203572585-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgAMH3CMtmYTBkob03NUj%2Fuploads%2FlKeSGlPb8iHC6PZ9m2Fr%2FUntitled%204.png?alt=media&#x26;token=d2baf824-bb6c-4b51-9019-352483b2fef8" alt=""><figcaption></figcaption></figure>

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 <a href="#id-193e8895-5ed3-4377-b053-8d09d8599f70" id="id-193e8895-5ed3-4377-b053-8d09d8599f70"></a>

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.
