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

There have been many articles describing overlay networks in the past few quarters. It's a relatively straightforward concept, not far removed from some of the older VPN technologies very popular a while ago. The actual transport of packets is probably the simplest, it is the control plane that is much harder to construct and therefore explain. It is therefore also that the control plane in overlay networks has seen the most innovation and change, and is likely to change some more in standard and proprietary ways in the next little while. A perfect example is the use of IP Multicast for unknown, multicast and broadcast traffic as defined in the latest IETF draft for VXLAN, but controller implementations try and avoid IP Multicast as part of the necessary data path. Which will continue to lead to changes in the control plane for learning, distribution of destinations... (more)

Red Sox, Pumpkins and Packet Encapsulation

[This is not really about the Red Sox or pumpkins this Halloween, but how could I not use those in the title? Go Red Sox] I left an awful teaser at the end of my article last week. In Brent Salisbury's original article that triggered some of these additional virtualization thoughts, he articulated two very clear differences between native network based L2 virtualization mechanisms and the mechanisms that are being provided by overlay solutions based mostly in server vSwitch infrastructure. These two fundamental functions are MAC learning and tunnel encapsulation. In today's post... (more)

Stateless Transport Tunneling (STT) Meets the Network

Last week I walked through the packet formats for VXLAN and NVGRE specifically focused on ways by which the overlay packets provide information to the physical network that help the physical network. Some of the initial extreme thoughts that the overlay and physical network can and should be completely ignorant of each other have softened more recently and more pragmatic thoughts of collaborating layers are being articulated. At Plexxi we have often mentioned that we believe the physical network and the overlay need to be closely orchestrated to get the most benefit out of the to... (more)

Fabric Engineering Is More than Traffic Engineering

It is human nature to try and relate new information and new ways of doing things to something that we know, something we are familiar with. Often when we talk about the way we fit traffic onto a Plexxi mesh network, the reaction is “I know what you mean, you are doing traffic engineering like we (used to) do in MPLS”. The response to that is usually “kinda, but not really”. In the most basic meaning, everything that has to do with the placement of traffic onto links, routing and forwarding choices being programmed, etc., would be part of Traffic Engineering. But like too many w... (more)

OpenFlow Evolution: Standardized Packet Processing Abstraction Is Hard

With the Open Network Summit 2014 about to start in Santa Clara next week, I realized I had not done much OpenFlow reading recently. It is no secret that Plexxi does not use OpenFlow as the API between our switches and controller due to restrictions in what OpenFlow can do (or in some cases could do when we needed to make architecture and design choices). When I saw the ONS announcement I thought it an opportune moment to sync myself to the latest and greatest in OpenFlow world. What started out as a mechanism to program flows into network switches and routers in a standard way ... (more)