NANOG 67 Review

This post is really late. It was supposed to be done for June. And then I was going to get it done in July. And then I didn’t. So it’s August now. I was lucky enough to have the privilege of attending NANOG 67 in Chicago, IL in June 2016. I’m going to write about my take aways from the event instead of going over all the presentations because they are online and a great resource. The presentations can all be found on the NANOG 67 page.

The biggest thing that I realized is that there is so much to networks. There are so many smart people out there that are willing to talk about what they are doing. One of the things that can be hard is that we can sometimes get stuck in our way of doing things. Talking with other engineers helps to see that there are other ways that may be better. Even though NANOG is mainly focused on the ISPs and large content providers, we (the smaller networking organizations) can take some of the things the bigger fish have figured out and apply it to our own scenario.

As an example, one of the presentations was on automating maintenance notifications. Now, we may not receive the amount of maintenance notifications from providers that someone like Facebook does, but could we implement something with our internal clients so that there is consistency when we contact them for an outage on their circuit/service/site? Most likely. Will it be implemented this year? Most likely not. But it is a good goal and something that we can work towards and start selling to the key internal people.

Another realization I came to is that, automation is the future of networking. The days of the CLI and logging on to 50 switches for a change are coming to an end. Carlos Vicente’s presentation on network automation at Dyn Inc. was a really good introduction for me on how to actually start implementing some of this automation. The Dyn “network pipeline” is a really good model. Would those tools work for our use case? Maybe. Maybe not. But the fact is, it’s a good pipeline and the tools that are used to implement it doesn’t really matter.

As a final thought/realization/ah-ha moment, I realized, it doesn’t matter what vendor you use. Knowing the protocols and how they work is more important. At NANOG there was very little “here’s how you do it on Cisco.” Sure there were some code snippets but the presentations were focused on how the protocols or specifications work. After attending NANOG 67, I realized to be better in the networking field, I can’t focus on vendors, but on protocols and how the underlying infrastructure works. Sure, I can still study and test on vendor certs, but having a better knowledge of the protocols will work across vendors.

I was a little nervous with attending my first NANOG event. I wasn’t from a big network provider and I was the only one from my company there. I knew nobody there but everyone was very welcoming and great to talk to and learn from. I hope to attend more NANOG events in the future.