Rethinking the Network

Marten Terpstra

Subscribe to Marten Terpstra: eMailAlertsEmail Alerts
Get Marten Terpstra via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Top Stories by Marten Terpstra

Triggered by a discussion with a customer yesterday, it occurred to me (again?) that network engineers are creatures of habit and control. We have strong beliefs of how networks should be architected, designed and build. We have done so for long times and understand it well. We have tweaked our methods, our tools, our configuration templates. We understand our networks inside out. We have a very clear mental view of how they behave and how packets get forwarded, how they should be forwarded. It’s comfort, it’s habit, we feel (mostly) in control of the network because we have a clear model in our head. I don’t believe this is a network engineering trait per se. Software engineers want to understand algorithms inside out, they want to understand the data modeling, types structures and relationships. Uncomfortable Many of us know the feeling. Something new comes around... (more)

Attention: Overlay Tunnel Construction Ahead

A while ago I wrote a few articles describing the various tunnel protocols used for network virtualization between vSwitches on servers, and between vSwitches and physical network gateways. These are the mechanisms that construct overlay networks on top of a physical network. VMWare uses STT as the tunneling mechanism between vSwitches on servers and VXLAN to communicate with gateways to the non virtualized world. NVGRE is used mostly by Microsoft, and is an extension to GRE tunneling that has been around for a while. Each one of these mechanisms have their pros and cons. They ... (more)

Training Wheels and Protective Gear By @PlexxiInc | @CloudExpo [#SDN]

Throughout the development cycle of new features and functions for any network platform (or probably most other products not targeted at the mass market consumer) this one question will always come up: should we protect the user of our product from doing this? And “this” is always something that would allow the user of the product to really mess things up if not done right. As a product management organization you almost have to take a philosophical stand when it comes to these questions. Protect the user Sure enough, the question came up last week as part of the development of on... (more)

Resiliency in Controller-Based Network Architectures

Last week Ivan Pepelnjak wrote an article about the failure domains of controller based network architectures. At the core of SDN solutions is the concept of a controller, which in most cases lives outside the network devices themselves. A controller as a central entity controlling the network (hence its name) provides very significant values and capabilities to the network. We have talked about these in this blog many times. Centralized Control When introducing a centralized entity into any inherently distributed system, the architecture of such a system needs to carefully consi... (more)

Network Services, Abstracted and Consumable

Perhaps not as popular as its brothers and sisters I, P and S, Network-As-A-Service or NaaS has slowly started to appear in industry press, articles and presentations. While sometimes associated with a hypervisor based overlay solution, its definition is not very clear, which is not at all surprising. Our industry does not do too well in defining new terms. I ran across this presentation from Usenix 2012 that details a NaaS solution that adds a software forwarding engine to switches and routers that provide specific services for some well known cloud computing workloads. I have ... (more)