SRv6: One Tool to Rule Them All

I got some interesting feedback from one of my readers on Segment Routing with IPv6 extension headers:

Some people position SRv6 as the universal underlay and overlay due to its capabilities for network programming by means of feature+locator SRH separation.

Stupid me replied “SRv6 is NOT an overlay solution but a source routing solution.

Want to get a second (or third or fourth) opinion? Check out:

So where would I need source routing?

Considering that, where would you need source routing (the ability to specify intermediate hops in the path)? For example, it doesn’t work well with service chaining unless your VNFs support it

There are some supposed use cases where you could use your ISP as global transport backbone even when your end sites are connected to another ISP. This might even make sense…

Then there are actual use cases for source routing in WAN edge of large content providers – they want to send the traffic to from their web proxy servers to some destinations over multiple uplinks. Not surprisingly, every solution along these lines that I’m aware of uses either L2 tricks or MPLS because they work (as opposed to works-with-engineering-code-in-PowerPoint technologies).

Back to one-tool-to-rule-them-all

I should have known better. Here’s what I got back from the same reader:

I guess their point is that in case of SRv6 you get a single mechanism that can be used for underlay (like MPLS transport in fabric) and for overlay (send instructions to particular end points where l3vpn should start for example), so instead of MPLS or VXLAN+IP you get SRv6 with IPv6 :)

RFC 1925 Rule 5 immediately comes to mind:

It is always possible to agglutinate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea.

In plain English: Just because you could doesn’t mean that you should.

In a word: Don’t.

Also, if you’re looking for a universal tool, why don’t you start with this one… and once you cut down a tree with it, and make a table out of that tree, while brushing your teeth, cutting your fingernails, and opening a bottle of wine, do let me know how it worked out.

2 comments:

  1. It's not because we always did somthing one way we should not improve what we do. Without this spirit, we will not have walk to the moon, we will not have the Internet.

    40 years ago when we started with IP, we didn't tougth we will have the success we do have today. IPv4 header was define without taking in account all modern services such as L3VPN, L2VPN, Traffic Engineering, Security, Network Programming... To address theses services we had to insert all kind of encapsulations (MPLS, VxLAN, NSH, IPSec,...) between the Link Layer (L2) and the Network Layer (L3).

    The IPv6 Flow Header, the IPv6 Security Header and the IPv6 Segment-Routing Header gives the industry the opportunity to integrate theses functions in the IPv6 header, gives the opportunity to do better route summarization, gives us the opportunity to start theses services from compute platform in secure way.

    Why should we address IPv6 like we always did for IPv4 ???
Add comment
Sidebar