Segment Routing

PCEP in SR Traffic Engineering

PCEP (Path Computation Element Protocol) | In this article , we will discuss PCEP and its role in Segment Routing.

PCE (Path computation Element) is network entity responsible for computation and maintaining paths (traffic engineered paths) in those cases when headend node cannot compute by itself such as inter-domain or dis-joint paths. In other words, it extends SR-TE capability of headend node in segment routing domain. Path computation client (PCC) is the entity which uses PCE for the SR-TE path computation , that is, headend node. SR-PCE communicates with its clients (headend node PCC) using PCEP (path computation element protocol). Here we will focus on the role of PCEP in SRTE as we already discussed SR-PCE in detail in my earlier article and below is the link for the same,


PCE and PCC works in server-client model, wherein PCC request PCE to compute a path, PCE computes and return the result. PCEP mechanism to communicate with PCE in this case is stateful, means , PCE not only computes a path but also learn SLA constraints using SR policies . PCE also updates SR policies and paths when there is any change or during any path or node failure.There is IETF draft which extends PCEP to support Segment Routing traffic engineering policy (earlier PCEP was supporting RSVP based traffic engineering). Here is the link to IETF draft ,

PCEP mechanism in stateful PCE consists of “report-update-report” messages exchange between PCE and PCC. PCC initiated SR policy CLI configuration or NETCONF through orchestration or using ODN template. Here is the sequence of message exchange happens between PCE and PCC using PCEP , refer below sample topology for the explanation,

PCEP in segment routing traffic engineering
PCEP Session between S1 and SR-PCE
  1. PCE builds its SRTE database using IGP and BGP-LS (link , node, prefix, SR policy information)
  2. SR Policy is configured on PCE with SLA constraint parameters such a bandwidth or delay etc along with endpoint information.
  3. PCC sends “Report message” to PCE along with SR policy information and delegates control of the path to PCE .
  4. PCE accepts delegation, computes new path as per SR Policy parameters .
  5. PCE returns the path to PCC using “Update message”.
  6. Headend or PCC installs the path and sends “Report message” to PCE regarding the state of the new path.
  7. PCE controls the path updates during any change or failure scenarios.

This is how PCEP with SR extensions helps achieving dynamic SRTE . I hope this article is helpful. Please write comment if you have any clarification or query.




SRv6 L3 VPN | In this article we will discuss SRv6 L3VPN service using IPV6 dataplane. We have already discussed basics of SRv6 and SRv6 header in my previous articles .Please go through following links for the same,

SRv6 SID represents 128 bit majorly consist of Locator and Function, (it can have optional argument bits as well)

Locator – This is the first part of the SID which identify address of SRV6 node

Function – This is the other part of SRv6 SID which identify network instruction that is executed on a particular node (node is identified by locator bits). For example, Network instruction can be L3 VPN function .

Lets understand how L3 VPN service works using SRv6. We will use below sample topology for the illustration purpose,

How SRv6 L3VPN works . Also explains locator and function used in L3vpn using Srv6
Figure 1.SRv6 L3VPN

In the above topology, CE nodes exchanging IPV4 prefixes with respective PE nodes S1 and S8. PE-CE routing protocol can be EBGP, OSPF or IS-IS. L3VPN service is required between PE nodes S1 and S8 which are SRv6 enabled nodes.CE nodes need not to be SRv6 aware . Here are the steps of SRv6 L3 VPN to work,

  1. As part of SRv6 base configuration, admin has to define locator information along with prefix associated with it. For example, SRv6 locator for S1 is 2001:DB8:0:A1::/64 and for S8 is 2001:DB8:0:A8::/64. IGP (ISIS or OSPF) will distribute locator prefix in the IPv6 network (with neighbours) .
  2. SRv6 manager in the each node automatically allocates SIDs for each SRv6 application or function , remember SID is combination of locator + Function. In this example , SRv6 manager in S8 allocates 2001:DB8:0:A8:40::/64 for End.DX4 function associated with CE routes and SRv6 manager in S1 allocates 2001:DB8:0:A1:40::/64 for End.DX4 function for ingress CE routes. SIDs to these functions are allocated automatically .
  3. End.DX4 is a BGP function and SID allocated for End.DX4 is called BGP SID under VPNv4 address family. End.DX4 represents PE endpoint with decapsulation and IPv4 cross-connect, means egress PE will decapsulate packet while sending original IPv4 packet towards CE link.
  4. MP-BGP encodes SRv6 SID in L3 VPN NLRI advertisement towards its BGP peer over IPv6 network. And each node install these SID information in the forwarding table which is combination and mapping between SID (locator+function) and CE prefixes.
  5. See below figure for packet walk,
How SRv6 L3VPN works . Also explains locator and function used in L3vpn using Srv6. Packet walk is also explained here.
SRv6 L3VPN packet flow

When packet arrives at S8 (ingress node) with destination address of remote CE , S8 encapsulate VRF IPV4 packet with SRv6 BGP VPN SID and send it over to egress PE node S1. S1 decapsulate packet and send original IPv4 packet towards directly connected CE. Same process happens when traffic flows in other direction.

This is how L3 VPN establish using SRv6 over IPv6 network and customer device neither support SRv6 nor aware of SRv6 in the provider network. I hope this article is helpful , please drop comment below if you have any query or clarification.


Flex-algo Anycast-SID use case

Flex-algo and Anycast-SID | In this article we will discuss how Flex-algo Anycast-SID can be used in scenarios where some part of the network does’t support Flex-algo (or Segment Routing)

We already discussed details of Anycast-SID and Flex-algo in separate articles. Please refer to below links for more detailed articles, and

Flex-algo helps to compute and identify non-default path in the network based on custom user-defined metric such as delay or TE-Metric . There might be situation when some part of the network is still using traditional LDP based MPLS and rest is SR based network and still want to use Flex-algo to compute a path end-to-end .Thats where the Anycast-SID helps to accomplish the same. In such situations, Flex-algo is used in SR nodes which provided low-delay path and IGP shortest path is used where delay information is not available ( on LDP nodes).

Lets understand with the help sample topology and see how it works, refer figure 1 below,

Flex-algo Anycast-SID
Figure 1. Flex-algo with Anycast-SID

In the topology above, Nodes S1,S2,S3,S4 and S5 are SR enabled and Nodes S6,S7 and S8 are LDP enabled. SR enabled nodes can participate in Flex-algo with delay as definition (metric) and LDP enabled nodes cannot participate in Flex-algo. Now, the requirement is have low delay path from Ingress node S1 towards egress node S8. In this example, path from S1 to S4 or S5 will be low delay path using Flex-algo and from node S4 or S5 to S8 will be based on IGP shortest path , means LDP network is not delay aware. Here are the different SR building blocks or steps used while computing path between node S1 and S8,

  1. The selection of the optimal path in the SR domain will leverage Anycast-SID on the border nodes S4 and S5. These nodes will advertise same Flex-algo Anycast-SID within SR domain.
  2. Flex-algo definition on SR nodes is delay , means, metric used to calculate path between node S1 towards nodes S4 or S5 is delay.
  3. Nodes S4 and S5 will advertise Flex-algo SID 16820, this will allow to send packets towards closest SR node with least delay from node S1. As per the link delay mentioned in the topology, optimal path from node S1 will be through node S4 . Therefore path of Flex-algo Anycast-SID 16820 is S1-S2-S4.
  4. Path from node S4 towards S8 will be based on IGP shortest path as this is LDP domain which is not delay aware network.
  5. As Node S8 is not SR node, one or more nodes will act as mapping server and will advertise prefix-SID on behalf of Node S8 which is 16100.
  6. SR border nodes S4 and S5 will take care of mapping function and stitch S8 prefix SID 16100 with LDP LSP towards S8.
  7. IGP shortest path from Node S4 towards S4 is S4-S6-S8.
  8. End -to-end path from node S1 to S8 will be,


9. SR policy on S1 will have SID-list (16820,16100) with 16820 as top label and 16100 bottom label.

Solution is fully automatic and dynamic once configured , IGP dynamically adjust low delay path in the SR domain with the help of Flex-algo Anycast-SID and shortest path in the LDP domain . Anycast-SID also provide node resiliency between border nodes.In this use case, different SR building blocks such as Flex-algo, Anycast-SID, LDP-SR interworking and SR-TE combines to provide solution to given problem. I hope this article is helpful in understanding how Flex-algo leverages Anycast-SID . Please write comment below if you have any query or clarification. Also, if you want to be expert on Segment Routing , you can buy these highly recommended books , segment routing part-1 and segment routing part-II


%d bloggers like this: