From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb
Complexity – My Friend, My Enemy
Over my years of network engineering, I've learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer

CCDE Bootcamp with Jeremy Filliben, Day Four

359 Words. Plan about 2 minute(s) to read this.

In today’s technical lectures, we covered multicast & MPLS. And maybe something else. I’d have to look. Frankly, the week is getting a bit blurry, but I know that we at least covered the bulk of those two topics today. Multicast was a great conversation. I’ve had to study multicast several times over the years, always in the context of preparing for an exam. I have never properly understood many of multicast’s details. Somehow, the nitty-gritty of multicast’s moving pieces along with the mroute table were inscrutable. I was competent enough to bash my way through a configuration and match up key terms with use-cases, but I never quite “got it.” I think that as of today, I’m a lot closer to “getting it,” thanks to Jeremy. I have never heard an explanation of multicast (specifically how sparse mode shared trees and shortest path trees are built) that was so clear. While I’ve always ranked Narbik Kocharians’ OSPF talk as perhaps the best technical lecture I’ve ever heard, Jeremy’s multicast lecture is at that same level. Great stuff.

Another thought that struck me today is that I have a pretty good structure for approaching the wiki creation now. While Cisco provides a solid blueprint for the written exam, there’s nothing quite so detailed for the practical. I think that while topically the wiki could be built around the written blueprint (with perhaps a few additions), the item I’ve been wrestling with the most is how to present the information. There needs to be a format that explains technical topics in the context of solving a design problem. Ergo, explain the technology briefly, then apply it to a use case. That should create a good foundation of “tools in the toolbox” that could be built upon to then start going after complex design scenarios. I must admit that I’m a little overwhelmed by the sheer volume of information that will need to be covered in my proposed CCDE wiki to make it as comprehensive as I’d like. There’s a lot of tech to discuss. Then again, if other folks in the community contribute, it will go faster than I think.