One of the attendees of the ProgrammableFlow webinar sent me an interesting observation:

Though there is separate control plane and separate data plane, it appears that there is crossover from one to the other. Consider the scenario when flow tables are not programmed and so the packets will be punted by the ingress switch to PFC. The PFC will then forward these packets to the egress switch so that the initial packets are not dropped. So in some sense: we are seeing packet traversing the boundaries of typical data-plane and control-plane and vice-versa.

He’s absolutely right, and if the above description reminds you of fast and process switching you’re spot on. There really is nothing new under the sun.

There were numerous great presentations at last week’s MENOG 12 meeting. The best technical ones (from my perspective): BGP Traffic Engineering by Andy Davidson, problems WIMAX operators face in IPv6 world by Reza Mahmoudi and Regional Threat Profile by Dave Monnier (Team Cymru).

Once you get rid of spanning tree and associated kludges (not too hard in OpenFlow-based networks), BUM flooding becomes your biggest enemy. NEC’s engineers implemented some interesting features in the ProgrammableFlow switches and controllers: rate-limiting of unknown unicast frames, flooding control, and ARP snooping (if only they’d go for ARP proxy).

A heated debate on one of the IPv6 mailing lists (more about that later) contained a gem I simply have to share with you: The importance of IPv6 application testing from Apricot 2013. Enjoy!

One of my readers sent me an interesting question:

Are you aware of any studies looking at the effectiveness of IPv6 address allocation policies? I'm specifically interested in the affects of allocation policy on RIB/FIB sizes.

Well, we haven’t solved a single BGP-inflating problem with IPv6, so expect the IPv6 BGP table to be similar to IPv4 BGP table once IPv6 is widely deployed.

Sander Steffann, Iljitsch van Beijnum and Rick van Rein recently published an amazing IETF draft comparing IPv6-over-IPv4 tunneling mechanisms. If you’re even remotely interested in this topic, the draft is an absolute must-read (and if you want to know about other transitional mechanisms, check out this webinar).

OpenFlow is not exactly known for its quality-of-service features (hint: there are none), but as I described in the ProgrammableFlow Technical Deep Dive webinar NEC implemented numerous OpenFlow extensions in their edge switches and the ProgrammableFlow controller to give you a robust set of QoS features.

I stumbled upon a fantastic RFC - Evolution of IP Model (RFC 6250) - that should be made mandatory reading for everyone remotely involved with networking. It describes numerous "truths" (politely called misconceptions) that everyone from programmers to network designers still rely upon. Some of my favorites: reachability is symmetric and transitive, loss is rare, addresses are stable, each host has a single interface and a single IP address ... Enjoy!

Finally found time to list all the events I’m scheduled to present at in the next few months. Hope you understand why I might occasionally miss one of the daily blog posts … but if you’re attending one of those events, please do send me an email or look for me there and we’ll have a nice cup of conversation (as one of my old friends used to say).

Smaller Clos fabrics are built with two layers of switches: leaf and spine switches. The oversubscription ratio you want to achieve dictates the number of uplinks on the leaf switch, which in turn dictates the maximum number of spine switches and thus the fabric size.

You have to use multi-stage Clos architecture if you want to build bigger fabrics; Brad Hedlund described a sample fabric with over 24.000 server-facing ports in the Clos Fabrics Explained webinar.