ACI Gets Support for Segment Routing on MPLS

I’m pleased to announce that Cisco’s Application Centric Infrastruture (ACI) version 5.0 introduces support for Segment Routing on Mulitprotocol Label Switching (SR-MPLS). This will make it easier for service provider architects to roll out new 5G networks quickly, while meeting strict service-level agreements.

With this new feature, service providers can roll out 5G networks using Segment Routing as the data plane — all the way from their data centers, across the transport network, and to the edge. Using a single data plane across an entire wide-area network empowers service provider architects to design more efficient and flexible 5G networks. Also, a single data and control plane across data center and transport makes it easier for operations teams to maintain networks.

Powering Service Providers with ACI

Many of our service provider customers are using Cisco ACI to streamline operations for distributed central, regional, and edge data centers; and to build new distributed, 5G-ready telecom data centers. ACI provides consistent policy, automation, and telemetry, in addition to intelligent service chaining.

When building the 5G transport domains, many service providers use a SR-MPLS handoff, from service provider data center, across the transport, to the provider data center edge. ACI’s SR-MPLS feature offers the potential for dramatically simpler automation, through consistent policy applied end-to-end.

SR-MPLS handoff is supported directly in ACI 5.0. The handoff solution works in any data center topology, including ACI multi-site, ACI multi-pod, and remote leaf. It also improves day-2 operations by simplifying the network from their data center to the 5G edge.

Here are some key ways we leverage SR-MPLS handoff in ACI 5.0:

Unified SR-MPLS transport

ACI was built to solve data center challenges, such as workload mobility, and integration with different types of virtual environments — such as VMware, Microsoft and KVM Hypervisors for OpenStack, as well as container workloads — to support automation and visibility.  ACI uses a VXLAN data plane within the fabric. Many SP transport networks are built using an SR-MPLS data plane. An SR-MPLS data center handoff allows service providers to use a single data plane protocol on their transport devices.

Traditionally the handoff from the ACI fabric was done either with native IP or with VXLAN. In these cases, the transport devices needed to support VXLAN, and the handoff had to be manually configured. With SR-MPLS handoff in ACI, service provder customers no longer have to worry about supporting VXLAN, nor manually configuring an IP handoff on their transport devices.

A new automated and scalable data center handoff

To provide connectivity from the data center to the transport or external device, an IP handoff from the data center requires a separate interface and routing protocol for each virtual routing and forwarding (VRF) instance. This type of connectivity is referred to as a VRF-lite. At a service provider or in a large enterprise environment there might be many VRFs deployed. Creating separate sub-interfaces and routing protocol adjacencies for each VRF causes automation and scale issues.

But with SR-MPLS handoff, a single BGP EVPN session can exchange information about all prefixes and all VRFs, instead of having a routing protocol session and sub-interface for each VRF. This leads to better scalability and simplified automation.

Consistent policy across data center and transport

Customers can simply advertise a BGP color community for a prefix from the ACI Border Leaf (BL) and use the community on the Provider Edge (PE) to define an SR policy in the transport. Allowing this mapping between the data center and transport provides better automation and policy consistency across the domains. The following diagram shows how to achieve this.

Another option to achieve consistent policy end-to-end is to mark packets with specific DSCP or EXP values when they leave the data center, and use these values in the transport to define SR policies. The following diagram shows how.

Lastly, if the transport doesn’t support BGP color community or SR policies based on DSCP/EXP values, customers can define prefix-based SR policies based on prefixes advertised by the ACI fabric using the BGP EVPN session between border leaf and the data center-provider edge.