How SR-MPLS Is Changing the Way We Think About IP Networking

Over the years, we have been conditioned to think of IP networking within the classical boundaries of shortest path routing and refrained from customizable yet complex traditional traffic engineering solutions. Enter Segment Routing with MPLS, referred to as SR-MPLS. 

This technology, invented by Cisco systems in 2012, is quickly gaining ground in the service provider and large enterprise markets along with universities. Internet2®, a non-profit, member-driven advanced technology community founded by the nation's leading higher education institutions in 1996, recently formed a strategic alliance with Cisco to adopt SR-MPLS as the next-generation standard. Also, SR-MPLS is piquing interest among public utilities and government organizations who often rely heavily on MPLS for transport.

SR-MPLS paving the future

Cisco's invention of SR-MPLS is dramatically changing the game and opening the door to possibilities seldom if never before entertained. For example, most IP networks rely on underlying optical infrastructures to provide Fast Reroute/Fast Convergence path protection. However, DWDM path protection requires a great deal of capacity planning and pre-provisioning. Ironically, the need for IP Fast Reroute has increased as IP networks have become more vital over recent years as they carry mission-critical data, voice and video traffic. 

Let's explore how SR-MPLS is automating the implementation of IP Fast Reroute and providing simplified and scalable traffic engineering, along with something new called BGP Egress Peer Engineering.

TI-LFA simplifies Fast Reroute

It is hard to believe that in the year 2020, so many mission-critical networks still do not deploy IP Fast Reroute (IP FRR) for fast convergence and instead rely on Interior Gateway Protocol, or IGP convergence. But when you think of the options, maybe it's not surprising.  

Until recently, the only option for IP Fast Reroute or IP FRR was RSVP-TE Fast Reroute. Not only is RSVP-TE intricate and challenging to deploy, but it is even more complex to manage. Also, RSVP-TE FRR created a capacity planning nightmare for ring topologies. In the event of link or node failure, RSVP-TE FRR would often traverse nodes that were not in the post-convergence path, and quite often it would traverse those nodes in both the forward and reverse direction during an FRR event.

Now more than ever, Fast Reroute is no longer a luxury but an absolute necessity. Enter SR-MPLS with TI-LFA, or Topology Independent Loop-Free Alternate Fast Reroute. IGP convergence can take upwards of two seconds, and with voice, video or real-time data, a 2-second failure can seem like an eternity. Therefore, it is not surprising to find that the single biggest reason that organizations deploy SR-MPLS is TI-LFA. 

Cisco Systems reports that there have been over 70 deployments of SR-MPLS with another 130 planned deployments over 2020 and 2021. TI-LFA quite simply provides 100 percent coverage, 50-msec link and node protection for any topology. TI-LFA protects not only SR-MPLS traffic but also LDP and native IP traffic. Therefore, you can deploy SR-MPLS in parallel with MPLS LDP and you are not required to make SR-MPLS the preferred method for IP to MPLS label imposition at the ingress PE routers. 

It is simple to operate and understand, supported by most modern hardware, automatically computed by the IGP and always uses the post-convergence path, as illustrated in the figure below. So ask yourself, why are you waiting?

TI-LFA alone is a compelling reason for deploying SR-MPLS, however let's look at some of the other advantages of SR-MPLS. SR-TE (Segment Routing Traffic Engineering) is another feature available with SR-MPLS that provides many benefits over traditional shortest-path routing. With support for both distributed and centralized Traffic Engineering, the SR-MPLS simplified implementation of Traffic Engineering is extremely attractive to many organizations. 

Not all traffic is considered equal. Networks often consist of high bandwidth data or Internet traffic and delay-sensitive voice or real-time data. The ability to do constraint-based dynamic steering of traffic to avoid certain network links is desirable to many organizations. For example, you choose the high bandwidth path, the low delay-based path or the high bandwidth path with a bound delay.

Traffic engineering simplified

Cisco's SR-MPLS simplified traffic engineering model allows for a streamlined policy-based configuration method for both dynamic and explicit paths and supports traffic steering via BGP route coloring. BGP route coloring is a method whereby the destination router assigns a color community value to the advertised prefix. 

ODN/AS (On-Demand Next Hop with Automated Steering) is a feature that works in conjunction with BGP color communities to tag prefixes and automatically steer packets from a source to a destination, on-demand, without the need to create complex policies on every Provider Edge or PE router. The headend router delegates an SR-TE Policy to the destination prefix instead of a next-hop IP address. Furthermore, SR-MPLS also supports delay-based paths like discussed above, along with flow-based SR-MPLS Traffic Engineering.

Flow-based SR-MPLS Traffic Engineering works in conjunction with BGP route coloring. The traffic is steered into the SR Policy and subsequently assigned a traffic class value based on either DSCP markings or 5-tuple ACL match and then steered to the specified destination. An additional benefit is that SR-TE, in conjunction with a centralized controller, supports end-to-end dynamic paths across multiple autonomous systems, which increases scale for large networks.

The diagram below shows an example of two prefixes being colored and advertised via BGP from node Z to node A. The blue prefix 1.0.0.0/24 is steered along the high bandwidth path, and the green prefix 2.0.0.0/24 is steered over the low delay path. For more information on SR-TE, check out another article: Take Control of the Packet Path With Segment Routing Traffic Engineering.

In a distributed SR-TE deployment, the headend router calculates the destination's path based on the input criteria and constraints. It applies the SR Policy to the destination traffic. For example, to forward traffic over two diverse paths, the headend router can calculate and deliver traffic to the destination over two paths that do not share any common nodes or links. 

This model is extremely scalable and easy to implement, but it does not work if the two paths originate from different headend routers or traverse multiple Autonomous Systems unless you use an SR-TE traffic controller. With Cisco's SR PCE (Path Computation Element), you can receive topology information from BGP Link-State (BGP-LS) and direct traffic across two diverse paths from multiple headends. The SR PCE can also handle the traffic across multiple autonomous systems by receiving IGP Link-State information from multiple IGP domains via BGP-LS. 

To simplify the implementation of SR-TE even further, we can utilize a feature called Flex-Algo. Flex-Algo allows us to customize our ISIS or OSPF IGP algorithm based on real-time performance monitoring data. For example, use the shortest delay path instead of the high bandwidth path or use the high bandwidth with a bound delay, or we can incorporate constraints that allow us to avoid certain links or nodes to provide a more customized path.  

This approach can be accomplished without an SR-TE policy and can be thought of as an IGP customizable algorithm available to the operator. The article Pick Your Path: Maximize Agility with Segment Routing with Flexible Algorithm discusses Flex-Algo further.

Introducing BGP Egress Peer Engineering

Finally, let's look at SR BGP Egress Peer Engineering, often referred to as just Egress Peer Engineering, or EPE. Egress Peer Engineering utilizes a centralized controller to instruct an ingress peer BGP node to use a specified egress BGP neighbor or interface for a given destination prefix.  

EPE requires no iBGP network design changes and no redistribution of eBGP peering links into the IGP. It relies on a function similar to Adjacency SIDs to steer traffic to a specified BGP peer or peering link. SR aware egress BGP nodes accomplish this by sharing their EPE SIDs via BGP-LS with an SR PCE controller who, in turn, instructs the ingress BGP node to forward traffic accordingly.

In the figure below, let's assume the default BGP path to prefix 6.1.1.1.0/24 for nodes 2 and 3 in AS1 is via their eBGP peer node, node 4, in AS4. The SR PCE controller instructs node 1 via an SR Policy to use SID label stack <16003, 35006> to forward traffic to destination address 6.1.1.0/24. Not only does this override the default iBGP behavior to deliver traffic to destination 6.1.1.0/24 via node 2, but it also takes advantage of node 3's BGP peer SID 35006 to force node 3 to use AS5 instead of the default AS4.  

Conclusion

We've explored some of the most compelling reasons for transitioning to SR-MPLS: TI-LFA, Traffic Engineering and Egress Peer Engineering. These features provide capabilities seldom — if never before — available in IP networks. I hope you're now convinced that SR-MPLS does change the way we think about classical IP networking. The advantages are clear, and the future is now!

Feel free to contact us today with any questions or to discuss transitioning to SR-MPLS.