I’m always amazed at how fast the time flies. I have no idea where May disappeared to, it seems like it was only yesterday when I was writing about webinar plans in 2019… and yet it’s only a month till ipSpace.net Summer Break™.

During June 2019 I’ll continue updating Designing the Private Cloud Infrastructure webinar, and start a new pet project: How Networks Really Work – I’m literally minutes away from traveling to a quiet spot in the middle of nowhere where I’ll work on the materials. In between these webinars you’ll find me in Zurich where I’ll run Microsoft Azure Networking workshop on June 12^th in parallel with SIGS Technology Conference.

I hate listening to “this is what we were doing this year” podcasts as they usually turn into pointless blabbering, self-congratulations and meaningless plans (think New Year resolutions). The Full Stack Journey Episode 28 with Scott Lowe was an amazing deviation from this too-common template.

If you don’t have time to listen to the podcast (but you OUGHT TO do it) here’s what I loved most: “When faced with the onslaught of new technologies, don’t panic. Wait a few months to see which ones survive”.

TL&DR: MIA

Six years ago, when I was talking about overlay virtual networks at Interop, I loved to joke that we must be living on a weird planet where Microsoft has the best overlay virtual networking implementation… at least as far as IPv6 goes.

Even then, their data plane implementation which was fully dual-stack-aware on both tenant- and underlay level was way ahead of what System Center could do.

Last week I explained how you could take a typical first attempt at a network automation data model and reduce the amount of duplicate data… but the data model we used was still describing a set of seemingly disconnected boxes.

How about restructuring the whole thing and describing what networks really are - graphs made of nodes (network devices) and links?

More than a decade ago I decided to start a pet project: a blog describing interesting details of networking technologies. The idea quickly morphed into vendor-neutral webinars - the first one took place in February 2010. A year or two later I had my first guest speaker and as of today we had more than 50 industry experts participating in ipSpace.net webinars and online courses.

In the meantime the ipSpace.net team grew: I had video and audio editors for years, Irena Marčetič took over marketing, logistics, and production in 2018, and we got a team of webinar moderators that will help us with guest speaker webinars (last week we ran the first guest speaker webinar where I didn’t have to be involved - hooray ;)

Kate Matsudaira wrote a nice article explaining how to deal with emotional attachment to a project you spent a lot of time working on. While she's focusing on software development, the same fallacies apply to networking - sometimes it's time to let the old pile of **** die and replace it with something created in this decade.

A few years ago we “celebrated” 512K day - the size of the full Internet routing table exceeded 512K (for whatever value of K ;) prefixes, overflowing TCAMs in some IP routers and resulting in interesting brownouts.

We’re close to exceeding 768K mark and the beware 768K day blog posts have already started appearing. While you (RFC 2119) SHOULD check the size of your forwarding table and the maximum capabilities of your hardware, the more important question should be “Why do I need 768K forwarding entries if I’m not a Tier-1 provider”

This blog post was initially sent to subscribers of my SDN and Network Automation mailing list. Subscribe here.

Remember the “every device configuration is really an expression of our intent” discussion? Forgetting the wrong level of abstraction (we mostly don’t want to deal with all the idiosyncratic stuff network devices want to see in their configurations) and box-oriented thinking caused by device-level intent for the moment, let’s focus on another aspect: how hard is it to manage your intent?

Remember how Arista promoted VXLAN coupled with deep buffer switches as the perfect DCI solution a few years ago? Someone took Arista’s marketing too literally, ran with the idea and combined VXLAN-based DCI with traditional MLAG+STP data center fabric.

While I love that they wrote a blog post documenting their experience (if only more people would do that), it doesn’t change the fact that the design contains the worst of both worlds.

Here are just a few things that went wrong:

One of the toughest challenges in the hands-on part of Building Network Automation Solutions online course is the create a data model describing your service exercise.

Networking engineers never had to think about data models describing their networks or services, and the first attempt often results in something that looks like simplified device configuration in YAML or JSON format.

I wrote a long article describing how you can slowly redesign your box-focused data model into a network-focused one. The first parts describing the problem and initial deduplication are already online.