128 Technology and Secure Vector Routing

The basic idea, as far as I can tell, is that you replace or augment your existing routers with the company’s x86-based boxes. You’re not replacing the underlying Internet, despite what some of the claims might lead you to think — instead they have a proprietary encapsulation/tunneling technology. It’s a lot like a dynamic multi-point VPN, where your traffic moves from one node in your network to another over encrypted tunnels, except here the system builds “tunnels” based on sessions and flows rather than network nodes. What makes the technology really interesting, though, is that it seeks to combine many functions that you get when you maintain a lot of state and know more about your traffic and flows.

In addition to encrypting traffic from point A to point B, it allows you to do traffic engineering / optimization in the vein of SD-WAN — the presentation doesn’t go into full detail, but it’s easy to think of ways that you could optimize for cost and bandwidth, and if application-aware, send VoIP and media streams over low-latency, expensive links and bulk traffic over higher-latency but cheaper links, for example; or shift traffic patterns, allow for overflow peaking to metered links and so forth.

Simply offering an easy-to-manage multipoint VPN — which is currently a major headache that takes a lot of engineer hours to implement — and SD-WAN — which saves money — is a winner, but they aim higher.

If the system knows flows and applications, it’s an easy jump to add security functions to it — firewalls, possibly even IPS/IDS/DLP. Perhaps traffic shaping and policing as well.

There’s a lot of telemetry and visibility that is possible from a modern system that has flow and application-level visibility at every hop. It’s not that current routers couldn’t do this, but they’re badly hamstrung by lagging legacy management schemes such as SNMP.

Configuration of traffic patterns, routing, IP addressing etc. can be done centrally, in the vein of overlays and SDN.

No need to reconfigure anything on the underlying network. The idea that you don’t want to have to ask carriers for anything is pervasive, and it’s attractive for a reason as anyone who’s ever dealt with carriers can attest.

An x86-hardware agnostic approach might allow for a nice range from affordable to high-performance hardware to support many low-cost branches.

High-touch services on the routers? If Cisco is putting container support in their LAN access switches and routers, this may be the way to go.

Where’s the catch? Well, a lot of these things aren’t exactly new ideas, and the difference between wanting to do something and being able to do so is fundamental. Making firewalls is hard. Coming up with a way to route and prioritize traffic is hard even before you add more complex decision criteria to it. Troubleshooting underlying transport issues and how they present through this vector-routed mesh might be a challenge. A particular detail I’m curious about is whether the scheme requires either a transport MTU of more than 1500 bytes, or if it limits the TCP/UDP payload. It says it’s inband signaling and doesn’t have the complexity of MPLS, but it’s still an encapsulation with effectively another set of headers, unless they have a surefire way to compress every packet enough. How is the reliability, and how does it deal with outages of underlying networks?

With the advent of SD-WAN, NSX, ACI, and the already boringly old MPLS infrastructure the engineering and conceptual framework for something like this might be there, though. It does seem to me that if they can deliver on their promises, this would be the perfect time to offer any distributed businesses a simple, single-vendor solution that replaces dozens of expensive, complex, difficult-to-manage products with one centrally managed, software-defined networking stack.