Home > Networking, Software Defined Networking > The Tyranny Of Taming (Network) Traffic: Steering, Service Insertion and Chaining…

The Tyranny Of Taming (Network) Traffic: Steering, Service Insertion and Chaining…

November 29th, 2012 Leave a comment Go to comments

You know what’s hard?

Describing the difficulties to anyone who doesn’t work inside of an actual “networking” company why the notions of traffic steering, services insertion and chaining across multiple physical boxes and/or combinations of physical and virtual service instantiations is freaking difficult.

12/3/12 [Ed: I realized I didn’t actually define these terms.  Added below.]

What do I mean by these terms?  Simplified definitions here:

  • Traffic Steering: directing and delivering traffic (flows/packets, tagged or otherwise) from one processing point to another
  • Service Insertion: addition of some form of processing (terminated or mirrored,) delivered as a service, that is interposed dynamically between processing points
  • Service Chaining: chaining (serialized or parallelized) and insertion of services with other services.
I didn’t get into the nuances of these capabilities with things like state, flow to service mapping tables, replication across flow/state tables in “clustered” processing points, etc., but I spoke to some of them in the “Four Horsemen of the Virtualization Security Apocalypse” presentation. See Pwnie #1 – War | Episode 7: Revenge Of the UTM Clones.

Now, with that out of the way and these terms simply defined, I suppose the “networking is simple” people are right.

I mean, all you have to do is agree on a common set of protocols, a consistent tagging format, flow and/or packet metadata, disposition mechanisms, flow redirection mechanisms beyond next hop unicast, tunneling, support for protocols other than unicast, state machine handling across disparate service chains, performance/availability/QoS telemetry across network domains and diameters, disparate control and data planes, session termination versus pass-through deltas, and then incidental stuff like MAC and routing table updates with convergence latencies across distributed entities, etc.

…and support for legacy while we’re at it.

It ain’t nuthin’ but a peanut, right?

Oh, this just must be an issue with underlay (physical) networks, right?

Overlays have this handled, right?

All these new APIs and control planes are secure by default, too, right?

Uh-huh.

Glad we’ve got this covered, apparently:

Things need to change dramatically at networking companies

This is true, by the way.

However, allow me to suggest that networking companies have experience, footprint, capabilities and relationships and are quite motivated to add value, increase feature velocity, reduce complexity in deployment and operation, and add more efficiency to their solutions.

Change is good.

See 18:45 if you want the juicy bits.

/Hoff

 

  1. No comments yet.
  1. No trackbacks yet.