As Seen by A Wireless Guy at a Networking Field Day Event

Since the first time I saw a Tech Field Day event, I’ve always tried to keep up with everything that the folks at Gestalt IT do for the industry. Usually, the events feature a group of people who are pretty good at what they do getting asked to attend a field day in their specific industry. This exclusive group of analysts and influencers get chauffeured around from tech company to tech company for a week. They get seats in deep-dive presentations while the vendors get to show off their latest and greatest gear. Audiences with product managers, C-level executives, and embargoed briefings round out the list of events of their time together. Throw in some great customer success stories and it’s the kind of event that creates a pretty sizeable impact.

That’s only half the story though, because there’s something amazing that each one of these companies gets out of this as well. Aside from the number of tweets, retweets, mentions and blog posts that follow afterwards, instant feedback is king. The ability to have this cross-section of deeply involved industry individuals in one room, at one time, enables an opportunity for relevant, balanced, and constructive feedback for the host companies. I am a huge fan of this realistic human-based marketing cycle, but now so even more, after this invitation to my first Network field day. This time proved to be a little bit different.

A Wolf in Sheep’s Clothing?

Let me explain. People who know me, follow me, and read my blog, know that I am in the wireless space. It’s the corner of the tech and networking sandbox that I love to play in. This doesn’t mean I don’t know anything about other technology, however my primary focus is definitely on wireless.

This time it was a little more exciting for me, having been invited to come over to another side of the industry: the Networking side. My invitation to sit in the Networking Field Day group, which actively focuses on routers, switches, virtualization, and other things in the data center was well received. Surrounded by Wireless CCIEs and the like versus the Wireless folks I am used to was sure to be a little daunting. While wireless and data networks are practically one in the same when it comes to purpose, the equipment and engineering for both are drastically different.

In a growingly segmented IT industry, wireless engineers have to understand the RF and specifics of the equipment, with a firm understanding of networking. Realizing how the equipment they are plugging into affects the wireless system is essential.

The Networking folks have to understand the deepest elements of data transport. Through routing and switching, whether it be physical, logical, or virtual, they have to understand how everything that is feeding into their network requires specific types of data, and how that data can affect the entire network. This can be a bit difficult.

The two worlds share the common bond of connecting data, but there are more things drastically different than that are the same.

So, to say that I felt like an interloper is a bit of an understatement. Not only did I feel like there were a few things I wouldn’t be able to keep up with, but I also felt like the people who were in the room with me, dedicated network geeks that are all brilliant each in their own ways, were going to have conversations that ran circles around my network abilities .. and I consider myself pretty good!

As challenging as I thought it would be, to avoid it would have meant to live in my little happy wireless bubble and continue to be reactionary to the changing tide of networking. So I grabbed on to the mane, spurred the bronco in the thigh and headed to Silicon Valley to see how dumb I really was.

It was a pretty eye-opening experience.

As someone who has a background in data networking and switching, there were a lot of basics that I figured wouldn’t get past me; pretty much what ended up being only slide 1 of every deck. The rest was going to be awesomely uncharted territory. I knew I was in for a treat when I looked at the list of companies that we were going to be visiting, obviously with VMware being one of the standout companies when it comes to this. Once we got into the presentations though, I quickly realized that I am not as up-to-date as I could be on SDN and network virtualization.

What I will tell you, from the perspective of someone who has some dated experience in the industry, is that we are going to an amazing place when it comes to networking. The product demonstrations, vendor information, customers standing in front of us discussing what they were doing, and detailed walk-throughs on how to make it all happen, showed how everything coming down the line is pretty exciting stuff.

Obviously for me, poking my head in from a different industry, it’s bright and shiny and new. But if there’s one thing I learned about open networking, software defined networking, and network virtualization, it’s that there are no set veterans or even clear leaders yet. This is still very much a new frontier where people are trying, trying and failing, and trying and succeeding. This made it that much more interesting for me honestly.

A day at the Open Networking Summit

This point couldn’t of been more clear than when we were at the opening networking summit. My takeaway observation was that everyone seemed to be bickering over the right way and the wrong way to do things with no one out in front as a transformative leader.

You have these amazing presenters on stage, like Sandra Rivera from Intel, Jan from Ericcson, Margaret Chiosi from Huawei and Srinivasa Kalapala from Verizon all talking very inspirationally about how to trudge forward using the history of the past as an example to the great things that are ahead.

Once it was opened up to questions though, it was commentary from people who weren’t asking questions, but standing on one side of the room telling the presenters why they thought the other side of the room was doing it wrong. Obviously that was volleyed by the other side of the room now taking the mic and getting up to tell the presenter why the other side of the room was wrong.

I found it a little comical to be honest, but I also saw that you had a handful of passionate groups all trying to figure out the best way through this. The absence of a clear leader made me imagine a scenario where instead of a clear leader pushing through the jungle chopping through vines with a machete, you had a bunch of groups with knives trying to out run each other. To the point of the Vice President of Technology and Supplier Strategy at Verizon, he flat out said that they would love to support it but the industry had “no clear direction”, a point absolutely proven by the audience.

Zooming back out to the larger view of Software Defined and Virtualization..

One of the first sessions we sat in was with IP Infusion. IP Infusion produces Network Operating Systems. I pretty much had very little idea what that meant at this point, so let’s fast forward a bit.

One of the standout conversations at the show was at a networking dinner where Networking Field Day delegates, current and previous vendors, as well as surprise guests and Mobility Field Day Delegates Blake, Jenn, and Jake showed up (with Robb in tow!)

We mingled with the groups from IP Infusion, TeloIP, and more, but it wasn’t until I parked in a corner with Ed from Barefoot Networks that things really started to click. We had a very open, fun, candid, and no holds barred conversation with the VP of one of the stand outs in SDN. Fresh off the great deal with AT&T, I got to pick his brain about how all this stuff works together and what directions it will be taking. Being a n00b has it’s benefits sometimes and this time the benefit was getting industry folks to help me understand in language an angry 14 year-old could appreciate.

I asked very basic questions, laden with expletives and terribly basic examples of things, but in the end, I got knowledge. After filtering through, here’s the gist. May I present to you:

What the Hell is in an SDN: A technology ecosystem breakdown, direct from the bar

Basically, you have 3 groups of companies in the SDN ecosystem:

1. Those that make “bare-metal” equipment

2. Those that make the silicon that run that bare-metal gear.

3. Those that make software that interfaces with the silicon to move your data.

So what the hell is bare-metal?

It’s a chassis with ports on it. It relies on the silicon manufactures to make things happen. Think of bare-metal as a build-your-own-pc, without a processor.

The silicon guys make the processors. Think “intel inside” or AMD. You pick the chip that makes the thing tick. Except, these chips vary and enable different functionality when used with the right software, so choose wiselyand based on what you want to do with it.

The software vendors are the people that make the software that does stuff with the processor and makes data and whatnot flow in and out of the ports. This is where the ONS stuff comes in. Think about closed source stuff as Microsoft and the Windows OS and the open stuff like Linux, for your switch. Coincidently it is actually Linux for your switch. Haha :)

Rewind..

Back to IP Infusion here: they produce software that can tell the silicon on the bare-metal switch what to do. Now it all made sense to me. What was crazy to learn was that IP Infusion has been around for about 20 years. They had partner in just about every corner of the networking world and were running on hardware that most of us had deployed. It was pretty cool to realize that this was a group that had been doing it behind the scenes for a little while.

The OcNOS product seem to be pretty straight-forward, giving you option after option of how to configure your network. With support for just about everything you could want to do and combined with two decades of experience, IP Infusion definitely seems to have it together when it comes to the software behind a Software Defined Network.

Now back at the bar, about that SDN Stuff..

Sounds pretty simple huh? I’m not sure if all of this makes sense to you at this point, but I was starting to catch on.

There are a ton of places to read up on SDN, and I would encourage you to. The place to start is with the Open Network Foundation and their overview of SDN.

Once I wrapped my head around that overly simplified concept, we ordered another round and applied virtualization to it.

So you’ve got this software defined switch, now let’s scale up and build a full network out of multiple software defined devices and make it do neat stuff.

Scaling Your Software Defined Network

Here’s how it works: Stick a virtual server running the VMWare NSX software on some server hardware in a data center, some bare-metal switches with bad ass silicon running open switch software throughout your enterprise and voila: software defined networks.

From the VMWare Blog: NSX-V: Multi-site Options and Cross-VC NSX Design Guide

Branching Out

Next, let’s bridge some other remote locations!

Grab a bear-metal box and connect it to a few different types of internet connections at the remote site. Say, a cable modem connection, a satellite connection and an LTE connection.

Into the weeds for a second: Using SD-WAN on Your SDN

This part is called SD-WAN: plugging in different internets and letting the software figure out which to use, for what. You can even get optimized performance over the web by using services like TeloIP.

Back at Your Network…

So you have this bear-metal box with ports plugged into a few different providers, it’s the same concept as before: setup a local stack of VMWare running to host the brains of the bare metal at this remote location. What’s cool is you can get this stack to sync with the main data center over the internet (or even up to a cloud service).

Now we can load on things like load balancing for the 3 links, fail over, firewalling, security profiles etc. all of which are defined at the main site which is connected to the remote site via its internet connections to the main data center.

Boom: software defined distributed virtualized networks.

The beauty of this, as I see it, is being able to manage, change, adapt, and build your network the way that you see fit. Instead of having a canned set of features and functions defined by a vendor, running on crazy expensive hardware, you get to do what you need, when you need it, where you need it. It’s controlled by you, it’s cost-effective, and it scales with you. The real power here isn’t about next generations of new network gear, it’s about transforming Information Technology from being about how you MOVE data, to a network that is about the data. It’s no longer going to be about pipes to provide access to data, its about data creating pipes to move itself more efficiently.

When you start to do things like defining profiles, it gets very interesting, very quickly. As virtual servers spin up with security profiles assigned, a series of events can happen. For example, a virtual switch port is created to immediately and automatically apply firewall services attached to it so that as soon as it’s online it’s protected. Things like this are almost magic to me.

You don’t have to stand up a case for a server, install the hardware in to the box, and then install the software. You don’t have to take it to the data center, plug it a power strip, find a switch port to plug it into. On top of that you don’t need a network engineer to configure the settings on that port, assign it to a VLAN then go to the firewall, apply firewall policies to the port or IP of the server, and then make sure it all works.

You click a few buttons, test it, deploy it, and it’s all done.

It’s amazing.

So how does this apply to wireless?

Network constructs built to support all types of data delivery methods will be easy to rapidly deploy, that’s gonna be a given. The data center is going to change because of this though I would imagine. Instead of a stable full of network engineers, you’ll have a few engineers that tell a group of developers and administrators how the network needs to be deployed. They will hammer away on keyboards to script and program automation and the network engineers will build the policies, routes, and so on for the network to operate. From a central facility you will be able to efficiently setup you’re entire network, branch offices and so on. You’ll do it on cost-effective equipment, custom silicon, and power it all with software.

Could Network services be moving closer towards developers and programming?

Now, from the network administrator perspective, because Wi-Fi is essentially just another way to get data on the network data plane, it will be provisioned as just another line of code on the virtual network. As far as all the other technologies, a LoRA gateway, an IoT collector, a small cell, or a DAS; it’s all just an extension of the network at that point. A programmer or developer will make the appropriate markup and any device that falls into that profile or on a created NIC instance which will follow the same rules as everything else.

Authentication will take place over 802.11x as alot of it is done today, and policies will be provisioned down to the user level device. Assuming all the future equipment supports it, which most of today’s gear does, its going to be as seamless an integration as running a cable, which I imagine is going to be phased out just about everywhere except to interconnect devices. ‘Cus why cable if you don’t have to? No switches = no switch ports for users = no cables.

What that means to me now, is that from a centralized location I can set policies to handle how data is ingested into the network. What type of data, when and where it comes from, how to secure it and prioritize it can all be taken into account. Worrying about how and if it will all be connected and how and if it will all be secured gets normalized across my network. Network troubleshooting is replaced by machine to machine learning, dogs and cats living together .. you get my point.

Where Does Wi-Fi and a Wireless Engineer fit into This?

For the wireless network to operate efficiently, obviously there is still some hardcore engineering and design that needs to take place, and it will honestly become more important than ever. For now. No seriously, if there’s one thing we know is that the clock is ticking on the introduction of automated RF tools fed data by sensors and the network itself to handle the on-going calibration of the wireless network off to processes and artificially intelligent controllers.

Think about it. In 5 years a room full of programmers and network analysts will be taking direction from a CCIE-type. None of those folks are going to know a thing about RF, nor are they going to care. The network will take care of itself and if it doesn’t they’ll find a vendor that can provide that. There are already some manufacturers on the market and more will adapt. No network team is going to want to hassle with RF because there will be so few of them. The importance of building a stable wireless environment will mean an investment in resources, tools, software, and sensors to ensure its functionality.

There will still need to be someone to coordinate this though, and that’s where I see the transitions coming for wireless network engineers. Coordinating frequencies across multiple RF devices, ensuring proper design and installation, making sure the wireless equipment is installed in a way that the processes that are configuring the wireless devices packet-by-packet can work effectively, and so on.

It’s crazy to think that bringing network services together can push the engineering folks back apart. There used to be two types of people in the back of the facility: RF people and network people. Then, that transformed into Wireless Network Engineers. What’s crazy to see is that as services become easier to deploy and bridge together, but using a more complicated back-end like VMWare NSX, it takes away from the “simple networking” that enables wireless nerds to be route / switch nerds as well. As the networking world becomes more centralized and driven by an IT team that consists of more developers than engineers, I think the wireless folks will find themselves getting back to their roots.

Specializing in the “wireless” component of a wireless network engineer will be the key. Having skilled staff dedicated to making sure that the RF environments are stable and the machines aren’t destroying them is gonna be paramount. However, I think the days of someone wearing two hats to deploy large-scale enterprise networks, especially when you have something as powerful as SDN looming, are numbered.

I could be wrong though. Just an opinion… ;)

Originally published on Blogger