Jerome has just published the second version of our BGP operations and security Internet draft. Most of the typos and obvious blunders have been fixed (or so we hope) and we’ve incorporated numerous comments received online or during the Paris IETF meeting. Feedback is (as always) highly welcome.

The latest draft is available here.

A few days after Brocade unveiled its SDN/OpenFlow strategy, Katie Bromley organized a phone call with Keith Stewart who kindly explained to me some of the background behind their current OpenFlow support. Apart from the fact that it runs on the 100GE adapters, the most interesting part is their twist on the hybrid OpenFlow deployment.

As expected, Cisco launched its programmable networks strategy (Cisco Open Networking Environment – ONE) at Cisco Live US ... and as we all hoped, it was more than just OpenFlow support on Nexus 3000. It was also totally different from the usual we support OpenFlow on our gear me-too announcements we’ve seen in the last few months.

A few days ago Big Switch announced they’ll support overlay networks in their upcoming software release. After a brief “told you so” moment (because virtual networks in physical devices don’t scale all that well) I started wondering whether they simply gave up and decided to become a Nicira copycat, so I was more than keen to have a brief chat with Kyle Forster (graciously offered by Isabelle Guis).

QFabric from Juniper is probably the best data center fabric architecture (not implementation) I’ve seen so far – single management plane, implemented in redundant controllers, and distributed control plane. The “only” problem it had was that it was way too big for data centers that most of us are building (how many times do you need 6000 10GE ports?). Juniper just solved that problem with a scaled-down version of QFabric, officially named QFX3000-M.

Last autumn Todd Hoff (the author of the fantastic High Scalability blog) asked me to write a short article explaining the scalability challenges SDN and OpenFlow in particular might be facing. It took me “a while”, but I finally got it done – the OpenFlow/SDN Is Not a Silver Bullet for Network Scalability article was published last Monday.

In case the industry press hasn’t told you yet, tomorrow is the World IPv6 Launch day. While the obstinate naysayers will still claim IPv6 doesn’t matter (but then there are people believing in flat Earth being ~6000 years old and riding on a stack of turtles), the rest of us should be prepared to enable IPv6 when needed … and it all starts with the networking equipment that supports IPv6 and has IPv6 performance that has at least the same order of magnitude as the IPv4 performance.

Understanding equal-cost multipathing in Brocade’s VCS Fabric is a bit tricky, not because it would be a complex topic, but because it’s a bit counter-intuitive (while still being perfectly logical once you understand it). Michael Schipp tried to explain how it works, Joel Knight went even deeper, and I’ll try to draw a parallel with the routed networks because most of us understand them better than the brave new fabric worlds.

A while ago I was writing about the behavior of Microsoft’s Network Load Balancing, the problems it’s causing and how Microsoft tried to hack around them using multicast MAC addresses as the hardware address of sender in ARP replies (which is illegal). A few days ago one of my readers asked me whether I know which RFC prohibits the use of multicast MAC address in ARP replies.

A quick consultation with friendly Google search engine returned this web page, which contained the answer: section 3.3.2 of RFC 1812 (Requirements for IP Version 4 Routers):

A router MUST not believe any ARP reply that claims that the Link Layer address of another host or router is a broadcast or multicast address.

Problem solved – now I know the real reason we have to configure static ARP entries on Cisco routers and switches.

This topic has been on my to-write list for over a year and its working title was phrased as a question, but all the horror stories you’ve shared with me over the last year or so (some of them published in my blog) have persuaded me that there’s no question – it’s a fact.

If you think I’m rephrasing the same topic ad nauseam, you’re right, but every month or so I get an external trigger that pushes me back to the same discussion, this time an interesting comment thread on Massimo Re Ferre’s blog.

No comment necessary.

We knew Brocade has OpenFlow support in its devices for at least a year; now it’s official: OpenFlow is supported on its MLX-series routers. But wait, there’s more: that’s just the first step in Brocade’s long-term SDN strategy, according to their press release. Let’s take a deeper look at that strategy.

When I mentioned the uselessness of stateless NAT64, I got in nice discussion with Tore Anderson who wanted to use stateless NAT64 in reverse direction (stateless NAT46) to build an IPv6-only data center. Some background information first (to define the context of his thinking before we jump into the technical details):

Some of you have noticed that I’d changed the commenting system on my blog recently. Here’s the full story (with a question for you at the very end).

I was totally fed up with Blogger comments years ago and decided to look for an alternative. JS-Kit was a perfect solution and it even allowed me to import Blogger comments and synchronize new entries with Blogger (so I could turn it off at any time and retain my comments).

Stumbled across this marvel while updating my IPv6 presentations for a 2-day seminar in Milano and Rome (straight from 15.2M&T command reference):

With IPv6 support added in Cisco IOS Release 12.2(2)T, the ip http server command simultaneously enables and disables both IP and IPv6 access to the HTTP server. However, an access list configured with the ip http access-class command will only be applied to IPv4 traffic. IPv6 traffic filtering is not supported.

Wait ... WHAT? I cannot control who can access the HTTP(S) server running in Cisco IOS over IPv6 (apart from kludges like ingress ACLs on all interfaces or CoPP), and this stupidity has been left unfixed for nine(9) years?. Are we really in 2012, less than a month away from World IPv6 Launch or have I been transported to 1990’s?