Segment Routing

SR and LDP Interworking

SR and LDP Interworking | In this article we will discuss how SR based network can interwork with existing LDP based network. LDP and SR based networks will co-exist for sometime . Suggest to to have basic understanding of Segment Routing to fully grasp this article, if you want to read basics of SR, visit here (Why segment Routing)

Generation old networks are operated using LDP based MPLS and it is not possible to migrate to Segment Routing based network over-night or some part of the network may not support SR due to hardware or software limitations. For that reason , existing LDP and SR will co-exist for some time and there has to be interworking with each other. SR and LDP interworking helps in migration process.

Seamless interworking between LDP and SR is achieved by Mapping server functionality. Mapping server basically map LDP label to Prefix SID and sits at the border of two networks.

Lets understand LDP-SR interworking with example . Refer figure 1 below,

Figure 1. LDP and SR Interworking

Nodes on left side are LDP enabled nodes and on right side are SR enabled nodes. Node S3  on the border of two networks is enabled for both LDP and SR and acts as mapping server. Node N1,N2 and N3 are LDP nodes so they use dynamic label range above 24000 and nodes S1 and S2 are SR nodes so they use SRGB range for prefix segment id (SID) . Node S3 is enabled for both LDP and SR so it uses both. Lets see how LDP Node N1 can reach SR enabled node S1 over label switched path.Here are the steps how forwarding entries are stitches to have end-to-end LSP ,

Step 1 – Node S1 advertise its Prefix SID 16302 for its loopback address , node S2 and  S3 installs the forwarding entry for prefix SID 16302 to Node S1.

Step 2 – LDP on Node S3 dynamically allocates label 90001 for the loopback address of node S1 and advertise this binding information to its LDP neighbours. So , border Node S3 (mapping server ) keeps mapping between LDP label and Prefix SID for the loopback address of node S1.

Step 3 – LDP on Node N3 install local label 90010 with out going label 90001 . Similarly, all other nodes install LDP local label and out going label for the loopback prefix address of Node S1.

Step 4 – Node S3 automatically connects LDP LSP to the prefix segment to reach Node S1 and provides seamless label switch path from node N1 to node S1. This functionality is called mapping server functionality.

Interworking applies to only labeled packets . For unlabeled IP packets with destination to Node S1 above, node S3 imposes prefix SID 16302.

In Summary, interworking is automatic and seamless and no specific configuration is required except mapping server functionality. This is the easiest way that LDP and SR based networks can not only co-exist but also communicate with each other to provide end-to-end LSP path. I hope this article is useful in understanding LDP/SR interworking concept.



Flex-algo and On-demand Next-hop/Automated Steering together

Flex-algo and ODN/Automated Steering | In this topic, we will bring all SR-TE ingredients together like Flex-algo, On-demand Next-hop and Automated Steering.


Till now in my earlier articles , we have discussed Flex-algo , ODN and Automated Steering and their usage  in SR traffic engineering . Please refer to below links for those detailed articles,

On-demand Next-hop
SR Policy

Now, we will see how ODN and Automated steering leverages Flex-algo. As a reminder, ODN enables automatic instantiation of SR Policy path when service routes are received from egress node via BGP (VPN routes). Automated Steering steers service routes into the SR policy . SR policy is identified by color of the service route and Next-hop. There is no change in their functionalities  while leveraging Flex-algo to encode SR-TE path.

The way it is done , Flex-algo SID algorithm is mapped to color which expresses the SLA constraint in the ODN template. For example, low-delay SLA constraint which is identified by color 100 and Flex-algo 130 is defined to provide low-delay path. So, SR Policy color is mapped to Flex-algo in the ODN template configured on Headend node. Below is the sample config for that, (using Cisco CLI commands for illustration purpose only).



Mapping Color with Flex-algo in ODN template example

Now, will use sample topology as given below for further illustration,

Figure 1

Suppose there is requirement of L3VPN from Node S1 to Node S4 with SR-TE ODN and SLA optimization of low-delay path.When VPN routes are received on headend node S1 with BGP nexthop as S4 with color 100 , ODN functionality instantiates SR Policy 1 to Node S4  based on the ODN template for color 100.ODN template restricts SR Policy to use Flex-algo SID as described earlier on how SR policy color is mapped with Flex-algo . SID list consists of just single SID , that is, Flex-algo prefix-SID 16304 correspond to Flex-algo 130 of Node S4 as shown .

BGP on Node S1 uses Automated Steering to steer the VPN routes into ODN based SR Policy which is identified by color 100. This is how ODN, Automated steering in SR-TE leverages Flex-algo to fulfil SLA optimization requirements.

Flex-algo is integral part of SR-TE architecture , Flex-algo SIDs are considered for SR-TE path calculation and can be included while creating SR policy.

I hope you will like this articles, please don’t hesitate to write comment below for any clarification or question you may have.


Flex-algo and SRTE together

Flex-algo and SRTE |In my earlier articles , we have discussed SR-TE and Flex-algo in silos, now we will discuss both together how Flex-algo can be used in SR traffic engineering. Please refer to below links for Flex-algo and SR-TE articles.


SRTE Fundamentals

SR Policy

Flex-algo is integral part of SR-TE functionality. Flex-algo and SRTE together compliments each other and Flex-algo enriches SR-TE functionality to provide SLA paths and , is fully integrated with other SR-TE mechanisms such as Automated steering and On-demand Next-hop (ODN).

Lets understand how Flex-algo combines with SR-TE with below example topology, refer figure 1 below,

Flex-algo and SRTE togetheer
Flex-algo and SRTE

By default IGP algorithm 0 is enabled on all nodes which uses IGP metric as cost of the links and assume algo-130 is configured with metric definition as delay and enabled on all nodes shown in the topology. IGP metric for all links is 10 except link between node S2 to S3 which is 100 (cost of the links) and delay of each link is shown above against each link.

When defining SR policy with optimization metric as IGP (cost) to compute dynamic path from Node S1 to Node S4, computed path is going to be S1-S2-S5-S4 as lowest cost path.SR-TE would encode this path as SID list 16004 only which belongs to default algorithm 0.

When defining SR policy with optimization metric as delay to compute dynamic path from Node S1 to Node S4, computed path is going to be S1-S2-S3-S4 as lowest delay path. SR-TE would encode this path as SID list 16304 only which belongs to Flexible algorithm 130.

Flex-algo SID allows to express path as single SID instead of stack of SIDs.Encoding Flex-algo SID by SR-TE provides benefits in terms of scalability (SID list scale) and resiliency. Even upon failure of the link , SR-TE does not have to update SID list because IGP will update the path to Prefix-SID (to 16004 or 16304).

Moreover, TI-LFA will compute port-convergence back-up path(with delay metric) for Flex-algo SID 16304 and computes back-up path (with metric cost) for Flex-algo Prefix-SID 16004.

In Summary, any node participating in Flex-algo computes the paths to the prefix-SIDs of that Flex-algo. I hope this article will help understanding how Flex-algo compliments SR traffic engineering .


%d bloggers like this: