A Paradigm Shift coming to the networking arena

In Wikipedia "Paradigm Shift" is defined as "a change in the basic assumptions, or paradigms, within the ruling theory of science".  It is defined by Thomas Kuhn, in his influential book The Structure of Scientific Revolutions

It has been adopted in the business world to describe a "Fundamental change in an individual's or a society's view of how things work in the world".  One classic example of a Paradigm Shift in the business world is how the Japanese Automaker Toyota changed it car manufacturing process making it able to adjust to external demands or changes and thus making Toyota a major thread to the Big 3 U.S. Automakers.


DevOps is a Paradigm Shift in the IT industry and is becoming a popular way of agile software deployment methodology.

Then what is a Paradigm Shift in the networking arena?

I think most of us will think that Software Defined Networking (SDN) is a Paradigm Shift for the networking arena.  

Well if you think this way you are only half correct. I am sure you will agree with me after reading this post.

What is SDN?

Different people have different definition on what Software Defined Networking is.  I have a blog post that defines what SDN is.  This TechTarget article describe SDN as "an umbrella term encompassing several kinds of network technology aimed at making the network as agile and flexible as the virtualized server and storage infrastructure of the modern data center."

Overlay technologies such as VXLAN, STT or NVGRE is sometimes considered as a form of SDN.  In the blog post we will look at SDN as the separation of the control and data plane and there is a centralized SDN controller to program the traffic flow on the physical network device.

 image source: https://www.sdxcentral.com/wp-content/uploads/2013/08/sdn-framework.jpg

In this SDN model, there is the concept of:

• Northbound Interface - Interface between the business application and the SDN controller
• Southbound Interface - Interface between the SDN controller and physical network device

Both the southbound and northbound interface has a set of APIs.

 

Southbound API

OpenFlow is the most common protocol used in the Southbound Interface to manage the flow dictating how the packers are moved from the source to the destination. (Note: OVSDB is the configuration management protocol used by the SDN controller to configure the Open vSwitch that is running on the physical network device).

Northbound API

The beauty of SDN is that it abstracted the physical networking devices with software and thus making the network programmable in respond to external changes.  The Northbound API is the channel for the network applications to interface with the SDN controller.  This article is a good primer on Northbound API.

The Paradigm Shift - IBN

Separating the control and forwarding plane in SDN is not exactly a fundamental change on how networking is done.  The true change on how networking is the concept of Intent-Based Networking (IBN).  This article (Intent: Don't tell me What to do! (Tell Me What You Want) by David Lenrow has a good description of what Intent-Based Networking is. This article described Intent-Based Networking with these characteristics:

• Intent is invariant
• Intent is portable
• Intent is compose-able
• Intent scales out, not up
• Intent provides context

Intent-Based Networking is another abstraction to the physical network where network application only specifies it intent and does not specifies how to achieve the intent.  This is similar to the Declarative Language where user only specifies the end result.  One example of Declarative Language is Puppet the Configuration Management Tool where user only list out the end state of the device that he/she wants to manage.

This is a Paradigm Shift in networking as we are shifting from the how to the what when network application interface with the SDN Controller.

 

The Advantages of Intent-Based Networking

There are several advantages for Intent-Based Networking:

Portability: Workload in the infrastructure tends to move around and in the case of Docker Containers, the application come and go in a rapid manner and the same application may be provisioned on different physical host.  By specifying only the what and not the how, it makes the application more agile or in other words more portable.

Composability:  By specifying the intent, the operator or developer of the network application does not need to know the protocol, network attributes or vendor.  "It is possible to provide an integrated system where multiple, discrete SDN services are offered, while resolving and avoiding potential conflicts over shared resources such as forwarding table" as described in David Lenrow's more recent article on this subject

Security: In the traditional SDN Northbound API, it is possible for the attacker to manipulation the flow creation or deletion. In the Intent-based Networking model, the Northbound API only specifies the what and not the how thus making is more save.

Currently this Intent-Based Networking concept is still under development but is gaining support from the following well know networking bodies:

• The Open Network Foundation
• Open Source SDN boulder Project
• OpenDayLight Network Intent Composition 
• Open Networking Lab
• OpenStack
• OPNFV
• European Telecommunication Standards Institute (ETSI)

Further Reading on this subject

"Intent: What. Not How"

“Could Intent Modeling Save the NFV Business Case?“,

“Intent Models in NFV: More than “Useful”,

“Diving Deeper into Intent Models for NFV“

Reference:
"Intent: Don't Tell Me What to Do! (Tell Me What You Want)." SDxCentral. N.p., 12 Feb. 2015. Web. 22 Sept. 2015.
"Intent-Based Networking Seeks Network Effect." SDxCentral. N.p., 18 Sept. 2015. Web. 22 Sept. 2015.
"What Is Software-defined Networking (SDN)? - Definition from WhatIs.com." SearchSDN. N.p., n.d. Web. 22 Sept. 2015.
Wikipedia. Wikimedia Foundation, n.d. Web. 22 Sept. 2015. 
"What Is a Paradigm Shift? Definition and Meaning." BusinessDictionary.com. N.p., n.d. Web. 22 Sept. 2015.  

Computer Networking 101 Part 4: You are right and I am not wrong

Usually we see things as either right or wrong but there are so many gray areas.

I have a friend who has a customer facing job and often times we don’t want to tell the customer that they are wrong.  One of his famous lines is 

“You are right and I am not wrong”.  

 I think this has saved his day a few times with the customer.

So how does this related to computer networking?

Today we are going to take a look at one view to logically divide a switch/router according to its function.  There are other ways to look at a switch/router but this is the most common way and if you are to read the hottest technology SDN you will have to know this logical view of looking at a switch/router.  

Also, to use this "You are right and I am not wrong" as the title, I am trying to make a boring subject a little more fun.  This is something I learn in a conference. A successful presenter will be talking on a boring subject and yet the audience is still willing to listen because it is fun. This is a boring but important concept and this is why I decided to touch on this.

There are tons of good articles about this subject - different planes of a networking device.  Why do you want to spend time reading this blog post?  Can I write better then those networking experts?  Well, I will try and ....

I hope you will still read on:

image source: http://faithfulbloggers.com/wp-content/uploads/havefunreadingblogs.png

As I have mentioned in my previous post, various vendors claim they have a SDN solution and each has it own definition and implementation of SDN (Software Defined Networking).  One of the ways to describe SDN is the “separation of the control and data plane”. If you “Google” SDN, a lot of article will use the beginning of to explain what control and data plane is before getting into SDN.

Traditional switch or router from networking equipment vendors comes in the form of a physical device with propitiatory software running on it.

image source: http://i.dailymail.co.uk/i/pix/2012/10/17/article-2219188-158CE597000005DC-42_964x507.jpg

With the arrival of the "Software Defined ___" era, SDN is a hot topic because it can catch up with the server virtualization.  There is a saying, we use a few minutes to provision a virtual machine (server) but we have to wait for weeks to get the networking or security (firewall) done.

When we need to virtualize networking equipment, the very first thing is to logically divide the equipment according to its functions.  Networking equipment can be divided into 3 functions:

1. Data Plane (sometimes call the Forwarding Plane also)
2. Control Plane
3. Management Plane

We can define what each plane is but how are they related is not so easy to explain. 

This diagram from this blog post by Greg Ferro explains the relationship of the 3 planes very nicely:

image source: http://etherealmind.com/wp-content/uploads/2010/12/controller-lan-11.jpg

Data Plane

This is the logical function to switch or route the data from one port to another port so that it can reach its destination.

Control Plane

This is the logical functions that builds the Forwarding Information Base for switch or routers.  Remember in my previous post, layer 2 switch uses "source learning" and routing protocols are used by layer 3 routers to build this Forwarding Information Base.

Management Plane

This is the logical function where user configure the networking device via the console of the device, SNMP (Simple Network Management Protocol) or NETCONF (Network Configuration Protocol).

If you want to dig into this right now I recommend this article as well as this article.  This post is meant for beginners to pick up the essential concepts of networking. Keeping the information as simple as possible and yet capture the essence.

Hope you enjoy reading this post.  Stay tune for more post in the coming days.

Is VMware's NSX a SDN, NFV or NV?

Next week is VMworld 2014.  Two weeks ago, there was already a lot of traffic on the internet about this event.  People are waiting to see what new product VMware is going to introduce and how these product can help solve their business or technical problem at work. 

I believe vSphere 6 will be announced.  Both vSAN and VVol will be a hot topic.  Integration of Dockers and VMware will be another hot topic as people are saying Dockers will replace VMs and VMware will be saying otherwise.  

Many people also talk about sessions and hands on lab on NSX.  This got me to look in to what NSX is.

Acronyms

The title of this blog has lots of acronyms:

• SDN – Software Defined Network
• NFV – Network Function Virtualization
• NV – Network Virtualization
• NSX – just like ESX it is a VMware product name.  

If one is in the IT industry, one would have heard about these acronyms at some point and one can say what these acronyms is abbreviating.  But do we really understand what they really are.

SDN – Software Defined Networking

The acronym SDN is a widely used term.  When I type in “What is SDN” on my favorite search engine I got 36,300,000 hits.

Most articles defines SDN as an architecture that separate the network control plane from the forwarding plane in which the control plane is generally centralized.

Image source: http://twimgs.com/networkcomputing/2012/5/sdn-arch.png

NFV – Network Function Virtualization

Network Function Virtualization as the word suggested is the virtualization of network functions.  Virtualize means to abstract from the physical.  Network Function is often refers to Layer 4 to Layer 7 functions such as firewall, load balancer, DNS or IDS/IPS.  A quick reference of the OSI layer can be found here

Image source: http://wikibon.org/w/images/7/70/NFV_Wikibon.png

Network Virtualization

Network virtualization is the abstraction of the physical network into logical segments with network overlay/tunneling technologies.  VXLAN, NVGRE and STT are good examples of network overlay technology.

Image source: http://www.cisco.com/c/dam/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-729383.doc/_jcr_content/renditions/white-paper-c11-729383-07.jpg

With VXLAN as the network overlay, tunnels are established between the VTEPs (VXLAN Tunnel End Point).

After reading all these, what is your answer to the title of this blog post: “Is VMware's NSX a SDN, NFV or NV?”

To me the answer is – VMware NSX is all three. While these are 3 distinct terms but they are interrelated.  All 3 technologies have the same purpose of solving the networking demand of the contemporary data center.

VMware NSX

NSX was officially announced last year at VMworld 2013.  During the announcement there is one presentation slide that caught the whole world’s attention (well part of the tech world may be).  This slide is the companies that support NSX.  Cisco was missing in that slide.  For a long time Cisco’s v1000 virtual switch is working in vSphere as the Distributed Virtual Switch option.  While VMware introduces NSX, a few months later Cisco announced Application Centric Infrastructure (ACI). These are 2 different approaches for solving problems in the contemporary data center.

Image source: http://commondatastorage.googleapis.com/bradhedlund/blog/what-is-network-virtualization/What_is_Network_Virtualization.PNG

This picture is from a blog by Brad Hedlund, engineering architect for VMware’s Networking and Security Business Unit (NSBU).  This is the best way to understand what NSX is - Just like how ESI virtualized the compute platform, NSX is to virtualize the network.

VMware has good articles to describe what NSX is here and here is and I am not going into the details of it in this post. 

VMware NSX comes with 2 flavors:

• NSX for multi-hypervisor
• NSX for vSphere

NSX can integrate with OpenStack. Scott Lowe has a nice blog series on NSX/NVP and this particular post talks about NSX and OpenStack integration

VMware NSX components

According to this article by Hatem Naguib there are 5 basic components for NSX:

• Controller Cluster
• Hypervisor vSwitches
• Gateways
• Ecosystem partners
•  NSX Manager

Also, in another VMware document – the VMware NSX Data sheet, the key feature of NSX are

•  Logical Switching – Reproduce the complete L2 and L3 switching functionality in a virtual environment, decoupled from underlying hardware
• NSX Gateway – L2 gateway for seamless connection to physical workloads and legacy VLANs
•  Logical Routing –Routing between logical switches, providing dynamic routing within different virtual networks.
•  Logical Firewall –Distributed firewall, kernel enabled line rate performance, virtualization and identity aware, with activity monitoring 
•  Logical Load Balancer – Full featured load balancer with SSL termination.
•  Logical VPN – Site-to-Site & Remote Access VPN in software  
•  NSX API – RESTful API for integration into any cloud management platform

From this we can see portion of NSX is meeting the requirement of SDN, NFV and NV.

NSX is a big topic and in the future will dig deeper but this is my preparation for next week’s VMworld 2014.