Once again, MPLS World Congress 2017 proves to be a major event for the Networking industry and a key milestone for Segment Routing debates between vendors and customers.
Industry at large is backing up Segment Routing:
- we are seeing adoption across all customer market segments – Telcos, Web Providers, Enterprise
- we’ve been working with lead operators and IETF since day one
- there’s a strong consensus across vendors that participate into Interop testings
I’m really pleased to see how the conversations around Segment Routing have evolved. Attendees are no longer questioning whether they should be implementing Segment Routing … They are all convinced they should be doing so.
Now the question revolves more around the breadth of implementation. Segment Routing is no longer contained to Core networks – it is not only spreading to Metro and Aggregation networks but also to Data Centers and even to the Host!
With Segment Routing, you can set up end-to-end policies across your independent Metro, WAN and Data Center domains. This way, you avoid complex protocol conversion between network domains while maintaining scalability – simplification at its best.
This is a game-changer as this was simply not possible before! What makes that possible?
On-Demand Next Hop
Provisioning multi-domain services (L2VPN & L3VPN) comes with complexity and scalability issues notably when routing information need to be redistributed across domains … With the On-Demand Next Hop (ODN) feature, no need to do any redistribution. ODN does trigger delegation of computation of an end-to-end LSP to XR Transport Controller (XTC) – a PCE controller, including constraints and policies. It then installs the replied multi-domain LSP for the duration of the service into the local FIB.
That way, you can easily set up a path from the Top-of-Rack through your entire network infrastructure up to an Egress Peering router with constraints such as low latency or disjointness.
On-Demand Next Hop is a great example of what Segment Routing architecture has been designed for – seeking the right balance between distributed intelligence and centralized optimization.
Broad Segment Routing support
Since day one, we had this end-to-end vision in mind and made the decision to have Segment Routing support across our portfolio, encompassing both IOS XR, IOS XE and NX-OS hardware platforms.
And there’s even more on the horizon – Segment Routing IPv6 starts getting increased traction in the industry and several IETF drafts have just been released.
Segment Routing not only works in a native IPv6 environment but when combined together they open up a complete new paradigm.
IPv6 packet header has been designed from the ground up to support Extension headers, notably Routing Extension Headers. Without getting too technical here, you should consider these Extension headers as a mean to pass instructions to each packet … By using the Routing Extension headers to pass Segment Routing IDs, you can simply direct your application on the appropriate path in the network. But in an IPv6 world, your Segment Routing ID has 128 bits! You don’t need all these bits for destination addresses … that leaves you with let’s say 64 bits to use for pointing to a function and passing some arguments to this function!
Doesn’t ring a bell to you? I bet so –that should remind you about 101 programming courses.
Welcome to the world of Infrastructure as Code – that’s what the new paradigm is about.
If you’re interested into getting more details, listen to the following videos recorded at MPLS World Congress 2017:
- Segment Routing for Data Center Interconnect at scale – Paul Mattes, Microsoft.
- Central Office transformation – Daniel Voyer, Bell Canada.
- Deployment experience and technology update – Clarence Filsfils, Cisco.