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,
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,
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,
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 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,
https://segmentroutingexpert.com/2020/05/29/anycast-sid-in-segment-routing/ and https://segmentroutingexpert.com/2020/03/18/flex-algo-explained-allows-sharing-single-network-infrastructure-resources-among-multiple-virtual-services/
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,
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,
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