Segment Routing

BGP Egress Peer Engineering in Segment Routing

Egress Peer Engineering | This article explains how BGP egress peer engineering in Segment Routing enables ingress node to steer traffic via specific egress node to a particular BGP peer or peering link. Segment Routing implementation of BGP egress peer engineering overrides BGP best-path selection criteria while selecting path to the BGP peer in another Autonomous system or peering link. To achieve this, centralized controller (SR-PCE) instructs ingress node to steer traffic via specific path. SR BGP EPE (Egress peer Engineering) uses peering-SID to accomplish such traffic engineering. Peering-SID can be thought of BGP variant of IGP adjacency-SID. More details on SR-PCE can be found here (SR-PCE for multi-domain SRTE) and details on IGP & BGP segments here (Segment Routing control plane).

A brief on existing BGP engineering (without Segment Routing)

Lets first understand existing BGP egress peer engineering which uses classic BGP best-path selection criteria. Refer here for details information on BGP best-path selection algorithm. Please refer below topology,

BGP Multi autonomous system Network.

BGP Multi-AS Network

In the above network, AS1 has BGP peering with AS2 and AS3 via nodes N3 and N4. Destination prefixes 100.100.100.0/24 and 200.200.200.0/24 are present in AS4 . AS4 advertises these prefixes to AS2 & AS3 which in turn advertises these prefixes to AS1. AS1 receives these prefixes from different sources such as node 5 in AS2 and eBGP peers Node 6 and Node 7 of AS3 .

Now , there are multiple paths available to reach prefixes in AS4 , there are four different paths available from AS1 to reach AS4, these are N3 to N5, N4 to N5, N4 to N6 and N4 to N7. BGP uses best-path selection rules to select one path . Moreover, routing policies are also used by operator to influence the best-path selection. Such routing policies offers some sort of flexibility and control on how traffic exit AS. These mechanisms are limited by BGP best-path selection algorithm and does not offers much granularity.

BGP Egress Peer Engineering – Leveraging Segment Routing

Segment Routing based BGP Egress Peer Engineering provides fine grained control over egress path selection. This solution uses centralized controller , which instructs ingress PE node to use specific egress ASBR or a particular peer link/interface or neighbour to reach destination prefix. Refer to the IETF draft here (draft-ietf-spring-segment-routing-central-epe-10).

To provide this functionality, BGP peering SIDs are used which steer traffic to specific BGP peer or specific peering interface/link. This is similar to what is achieved using IGP adjacency-SID. Lets understand this with help of example , refer below topology,

BGP Egress Peer Engineering in Segment Routing.

Segment Routing Egress Peer Engineering

Suppose Segment Routing is enabled on nodes in AS1 (N1, N2, N3 and N4). Nodes in AS2, AS3 and AS4 does not support or enabled for Segment Routing. Now, operator wants to send traffic via Node 5 in AS2 if destination prefix is 100.100.100.0/24 , and via N7 in AS3 if destination prefix is 200.200.200.0/24. Segment Routing offers this level of granularity and lets see the steps below how to achieve this,

  1. Node 3 and Node 4 advertises IGP prefix-SID as 17003 and 17004 in AS1.
  2. Node 4 is allocated BGP peering SID 30405 for its peering session with Node 5 in AS2.
  3. Node 4 is allocated BGP peering SID 30407 for its peering session with Node 7 in AS3.
  4. Suppose ingress node is N1 where traffic flows are initiated for the destination prefixes in AS4.
  5. SR Policy is configured on Node 1(N1) , SID-list on N1 will be (17004, 30405) for destination prefix 100.100.100.0/24. 17004 is the top label SID to reach N4 (using IGP shortest path) , then 30405 SID will steer traffic over BGP peer link to Node N5.
  6. Another SR Policy is configured on N1 with SID-list (17004, 30407) for destination prefix 200.200.200.0/24.
  7. Any other traffic will follow default forwarding behaviour using BGP bets-path selection rules.

SR Egress peer engineering is to be enabled only on egress peer nodes (ASBR) and SR-PCE controller. These border nodes also advertise BGP peering SIDs in BGP-LS so that SR-PCE controller can learn this information and leverage this information in SR policies.

Conclusion

Segment Routing enables more granular mechanism for BGP egress peer engineering in multi-AS network. It can be used in use cases such as creating SR policies using peering-SID as explained in above example. Another use case is inter-domain (inter-AS) SR policy path . SR-PCE controller receives all information via BGP-LS to have consolidated view of all domains. SR-PCE can then compute the required end-to-end SR Policy path across multi-domain (Multi-AS) network. In summary, BGP Egress peer Engineering in Segment Routing is more flexible and granular in providing BGP egress traffic engineering . Also, if you want to become expert on Segment Routing with in-depth knowledge , you can buy these highly recommended books , segment routing part-1 and segment routing part-II

I hope this article is useful . Please provide comments below if you have any query or clarification.

Advertisements

SD-WAN over Segment Routing

SD-WAN over SR | This article explains how SD-WAN over Segment Routing enables a service provider to run per flow services to provide differentiated SLAs to their SD-WAN customers. SD-WAN as overlay technology rides over segment routing for the desired underlay transport treatment. SD-WAN enables customer to mark traffic with desired Qos value , and service provider leverage Qos marking for the classification of traffic per flow basis to provide differentiated treatment to traffic. SR building blocks such as on-demand next-hop, automated steering and Flex-algo are used to accomplish such traffic differentiation and provide SLAs basis customer marking. With existing LDP based MPLS transport, all SD-WAN traffic flows traverse a single path across provider’s transport network.

A brief on SD-WAN (Software defined WAN)

SD-WAN is a Software-defined wide area network overlay technology which spans across geographically dispersed locations. It can connect several enterprise branch locations to central hub office or data center or even public cloud. One of model to deploy SD-WAN where Enterprise can use managed service provider , who owns all networking equipments and maintains them to provide SLAs based services . Service provider in this case give some control to Enterprise to manage Qos policies . These Qos policies or marking helps service providers to differentiate traffic flows when enters their network ( service provider Edge or PE ingress node) .

One of the biggest motivation and selling point behind SD-WAN is the ability to cost-effectively mix and match network links according to traffic type or priority. Internet broadband and 4G LTE/5G are less expensive than MPLS (or SR) , so customers can choose those links instead of the expensive MPLS network for certain types of lower-priority traffic. Even within Service provider network, high priority traffic can traverse certain path, for example low latency path and other traffic can be sent across best effort path (based in IGP shortest path). Please go through basics of SD-WAN here. Also, a good high level article on SD-WAN benefits and summary visit here

SD-WAN over SR

Integration of SD-WAN and SR enables operators to provide transport SLAs to their Enterprise Sd-WAN customers. Here are the high level mechanism to deploy SD-WAN overlay services over segment Routing ,

  1. traffic is marked by customer edge with desired Qos and transport treatment.
  2. Operators leverages Qos marking done by customer edge , transport SLAs are provided using Per-flow ODN and automated steering . Details on ODN and AS , visit here (ODN +AS)
  3. Along with per-flow automated traffic steering, Flex-algo is also used to create non-default IGP path like minimum delay path . More details of Flex-algo visit here (Flex-algo)

Lets understand this with help of example , please refer below sample topology ,

SD-WAN over Segment Routing
SD-WAN over Segment Routing

In the above topology, CE1 and CE2 are SD-WAN customer edge device which are connected to S1 and S4 respectively in the service provider network . S1 and S4 are the PE nodes . In the above topology, links are marked with latency and IGP cost information. Cost of each link is assumed as 10 except link between S2 and S4 which is 100.

Assume, there are two customer’s application , one of them requires lowest latency path to reach between CE1 and CE2 and other requires best effort IGP shortest path. Customer edge device marks different DSCP values to indicate SLA required for these two applications, and operators PE device classifies the traffic flows based on DSCP values. See figure below,

SD-WAN over Segment Routing
SD-WAN Over Segment Routing

Here are the detailed steps followed which allows two different paths for these applications from CE1 to CE2 , one low latency path and other is best effort IGP shortest path. We will use Cisco configuration CLI to illustrate few steps below,

  1. CE1 marks traffic flow with different DSCP values . For example , Traffic for application flow A is marked with DSCP value 46 and traffic for application flow B is marked with DSCP value 8. Application A requires low latency path and application B will send across best effort path.
  2. When traffic received at ingress PE (S1 in this case), S1 match these DSCP values and put into respective forwarding class. Below is the sample configuration ,
Sample Configuration

3. There is MP-BGP between S1 and S4, S1 and S4 exchange L3VPN routes along with color information associated with traffic type A (say color 10) and B (say color 20). If you want more details around the concept , please refer here

4. Nodes S1,S2,S3,S4 and S5 are are participating and configured with Flex-algo, for low latency path with metric as delay (traffic A) . No need to create Flex-algo for best effort path with metric IGP cost (traffic B) as this is default algorithm 0. Below is the sample config needs to be done under IGP (ISIS or OSPF)

Sample Config

5. Now, SR Policy has to be defined for both traffic types as next step , and, map forwarding class 1 with Traffic type A which will use Flex-algo 128 (shown above) . Similarly, map forwarding class 0 with traffic type B which will use default algorithm (IGP shortest path). Below is the sample config for that,

Sample Config

6. In the above config, On-demand Next-hop with color 20 is for traffic Type B which is mapped to forward class 0 , metric used for class 0 traffic is IGP Cost. Similarly, ODN with color 10 for traffic type A which is mapped to forward class 1 will use delay as metric computed using Flex-algo 128.

7. Traffic type A will traverse path as S1-S2-S3-S4 as this is the lowest delay path as compare to any other path (total 20ms) . Traffic type B will traverse S1-S2-S5-S4 as this is lowest cost path.

8. This is how, SR building blocks such as per-flow ODN, Automated steering , Flex-algo can be used to define differential SLA treatment to traffic flows. More details on these concepts can be found here ODN and automated steering.

SD-WAN over SR use case

With Segment Routing network operator can monetize its infrastructure and offer customize per application (per flow) Enterprise SLAs services for SD-WAN customers. To achieve this , as an inherent benefit of segment routing is used which is no per-flow state information is maintained in operator’s network , which means no extra overhead on the network. Operator decides which flow should go via which path. Operators can provide premium SLAs for critical traffic flows and best effort SLAs for less critical traffic .

Conclusion

In Summary , with existing MPLS based transport network, all traffic follows same path, no differential treatment can be given . With Segment routing and its building blocks such as ODN, Automated steering and Flex-algo, SD-WAN traffic flow can be treated differently depending upon the criticality of the traffic . This further provides opportunity for Operators to offer customize SLAs to Enterprise SD-WAN customers. Please visit here if you want see demo of SD-WAN over SR. 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

I hope this article is useful . Please provide comments below if you have any query or clarification.

Advertisements

Dual-plane Disjoint path in Segment Routing

Dual-plane Disjoint paths | In this article we will discuss how Anycast-SID can be used to send different traffic types across dual-plane disjoints path networks. Though, there are other SR based methods to achieve same functionality , one of them is using IGP Flex-algo and other is by dynamic SR policy using SDN controller (SR-PCE) . In today’s discussion , will see how to use Anycast-SID and define Explicit candidate path to achieve the same functionality .

A brief on Anycast-SID , it is a Node Prefix-SID that is advertised by more than one node (typically two or more ). The set of nodes advertising the same anycast-SID form a group called as anycast set. By using an Anycast-SID in the SID list of an SR policy path , it helps achieving traffic load-sharing and resiliency. Apart from this, it can be used to have traffic engineered path through a set of nodes or region (can be called as plane in the network) . More details on this topic can be found here (Anycast-SID in Segment Routing )

Understand Dual-plane vs Single-plane in context with Segment Routing

Dual-plane is the mechanism to enforce disjointness in the network , where , the traffic path towards destination node stays within a set of nodes ( called plane). There can be multiple planes in the network, so that different planes in the network can be. used for different kind of traffic types depending upon the SLA, a service provider signs with customer. Anycast-SID allows creation of such macro policies, such as , “flow of traffic 1 from node A to B must go via plane 1” and “flow of traffic 2 from node A to B must go via plane 2.” This is practically called dual-plane disjoint path architecture.

Example with Sample topology

Lets look at below sample topology to understand how Anycast-SID makes it possible.

dual-plane disjoint path using anycast-sid
Dual-plane disjoint paths using Anycast-SID

In the above diagram, there are two planes , orange plane consists of nodes S2 , S3, S4 and S5. Green plane consists of nodes S6, S7, S8 and S9. Node S1 is ingress and S10 is egress nodes , each of them connects to both planes.

All nodes in orange plane are configured with same Anycast-SID 16100, similarly, all nodes in green plane are configured with same anycast-SID 16200. Below is the sample configuration of Cisco Router for the illustration purpose,

Sample Configuration

Above configuration is common to all nodes in orange plane with prefix-sid as 16100 and to green plane with prefix-sid as 16200. Node S10 is configured with prefix-sid 16110.

Now, in this dual-plane topology, to steer traffic via orange plane towards node S10 consists of SID-list (16100, 16110) and to steer traffic via green plane towards S10 , SID-list consists of (16200, 16110), where 16110 is the node prefix-sid of S10.

So, operator will configure two SR-policies, one for orange plane and other for green plane. Orange plane SR-Policy consists of endpoint which is node S10, color 100 (it can be any value) , which identifies explicit SID list defined for orange plane. Similarly, Green plane SR-Policy consists of endpoint which is node S10, color 200 (it can be any value) , which identifies explicit SID list defined for green plane . More details on SR policy can be found here (SR Policy) and SRTE fundamentals .

Dual-plane disjoint path use case

Assume there is L3 VPN service required between nodes S1 and S10 with two VRFs. These two VRFs should be carried over disjoint paths. Traffic of first VRF should be send across orange plane and traffic of second VRF should be carried via green plane.This can be simply achieved by steering traffic of first VRF into SR-Policy of orange plane , similarly, steering traffic of second VRF into SR-Policy of green plane. More details on traffic steering can be found here (Automated steering).

Conclusion

In Summary , Anycast-SID plays a vital role in dual-plane disjoint path architecture. As i said earlier, dual-plane functionality can also be achieved using Flex-algo and dynamic SR policy using SDN controller (using SR-PCE). For any further detailed explanation and demonstration, you can visit here . 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

I hope this article is helpful , please write comment below for any query or clarification.

Advertisements

%d bloggers like this: