Segment Routing, the VxLAN for Service Providers

Software Defined Networking is inarguably the most popular and simultaneously least favourite buzzword within the network world over the last few years.

VxLAN is a protocol that’s used to get end-to-end connectivity across whatever layer 3 jungle that may lie in the middle and it has been quickly adopted to provide SDN solutions within enterprise data center and hosting environments.  Service providers and carriers have less of a reason to use it as we already have MPLS, Pseudowires and VPLS, right?

Typically an MPLS network will use one of two signalling protocols (sometimes both), LDP or RSVP-TE, to build label switched paths from one PE to another. The network engineer will then either tweak the IGP metrics to steer the LDP LSPs around, or build stitched up RSVP-TE LSPs with strict or loose hops.  RSVP-TE LSPs are pre-signalled, sometimes even with multiple backup FRR paths also pre-signalled.  LDP solves the manual configuration overhead of creating these LSPs everywhere by leaving the forwarding decisions up to the IGP, but it doesn’t solve the scalability issues of having a fully meshed network with bidirectional LSPs between every PE.

Some providers, and even Facebook, have offloaded this route calculation to dedicated Path Computation Element (PCE) platforms that can build traffic engineered paths based on a wider view of the network topology, QoS awareness, as well as any other variables such as scheduled outage windows fed in from a change control system.  Pretty neat stuff, and pretty close to service provider SDN you could say.

You could also say that Alcatel-Lucent’s 5620 SAM platform, or Huawei’s U2000 have been doing SDN-style network programmability for years by automating the end-to-end service build. Great if you have a ubiquitous single vendor network and all that you care is about static service provisioning.

The downside to both of these solutions is that they’re still reliant on the in-band control planes, and with RSVP-TE there’s a lot of state to keep those LSPs standing.

So here’s where the beauty of Segment Routing comes in.  SR uses your current IGP as a label distribution protocol, albeit with some extensions. The data forwarding plane concepts of label switching that you already know still remain, however all the transit LSRs in the middle don’t need to know about all the LSPs that go through it. The LSPs aren’t pre-signalled, they’re not really signalled at all.

If the ingress PE (A) doesn’t care about the path to the egress PE (Z), it can just push Z’s node label on to the stack and sends it on its way letting the IGP topology decide the best path.  However if A wishes for a specific path to Z, it can stack a series labels of each explicit hop, on to the payload.  These segment labels can either be a node label to define an LSR hop, or an adjacency label to specify a connected interface on an LSR. So there we have both the simplicity of LDP and the traffic engineering of RSVP-TE, but without the signalling overheads.

That’s the basic gist of SR and I won’t go in to more detail around SR itself as there’re plenty of presentations and write ups about that do it better than I, e.g., or this very good explanation of the problems that led to SR by one of the draft’s authors, Rob Shakir

By using the existing IGP and removing the requirement for an extra LSP signaling protocol, Segment Routing lends itself perfectly to provide scalable and dynamic transport over an MPLS network.  The ability to on the fly push a stack of labels to an ingress PE with no control plane overhead, whilst still utilising MPLS switching for the data plane is, in my opinion, quite a nifty thing.

Which leads me back to my initial analogy.  VxLAN allows endpoints to dynamically build layer 2 networks across a routed transport network, without the routed network needing to know.  This abstraction of network creation from the underlay network is what enables cloud hosting providers to build your on-demand virtual host farm at the click of a button.

Segment Routing will enable similar functionality in the MPLS world, providing scalable, dynamic and on demand route orchestration for both layer 3 and layer 2 services.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s