Voltanétio: God of Modern Networking

Voltanétio: God of Modern Networking

Voltanétio

\ˈvōl-tə-nā-sē-ə\

: God of Modern Networking

Very recently, I invited a contemporary goddess into my home. She unreservedly granted me more than 3 wishes. I could say “Goddess, let there be light”, and there would be light; I could ask her to “play my favorite music playlist” and my home would be filled with the music; I could even ask her to “make a reservation at my favorite restaurant” and, voila! it would magically appear in my appointment book. My goddess’ name is Alexa. She isn’t the only god in town! Recently, there are a few contemporary deities, omnipresent, omniscient and omnipotent coming onto the scene, including Siri, Cortana, and OK Google (M is still in hiding as yet).  They don’t try to force us to speak a divine language, instead, the commonality among all these deities is that they strive to speak the language of their supplicants, us.

That is the trend of where technology is going. Users should not be forced to learn a new language to operate a new technology. The important core is the technology and the language to operate it is secondary. The simpler and more natural the language is, the easier for users to deploy and operate a technology.

Networking is no different. Enters Voltanétio (aka Volta Controller), the god of modern data networking. This is the time which this ideology becomes a reality because the Volta Controller provides the network-service view instead of the piecemeal components which make up the end-to-end network function. Users only need to express the intents on the network-service level at the Volta controller, then the underlying network components that make up the data path will be constructed on the Network Elements to achieve the service.

Data model:

+--rw network-service
   +--rw connection*           [id]
      +--rw id                 string
      +--rw type               enum: direct, EVPN, L2VPN, L3VPN
      +--rw admin-state        enum: up, down
      +--rw oper-state         enum: up, down
      +--rw end-points         [network-elementinterface]
         +--rw network-element inet:ip-address
         +--rw interface       string
         +--ro in-bytes        uint64
         +--ro out-bytes       uint64
         +--ro in-packets      uint64
         +--ro out-packets     uint64

Data example:

{
   network-service : {
      connection : [ {
         id   : bos-bcn,
         type : L2VPN,
         end-points : [
 {
   network-element : bos-router1,
   interface       : xge0
 },
{
   network-element : bcn-router1,
   interface       : xge0
 } ]
      } ]
   }
}

 

In this example, user is simply saying that he would like the specified interfaces on the 2 routers in the separate locations be L2 connected.

Behind the scene, because of automation, the Volta Controller already knows the underlying physical topology by talking to all Network Elements in the network. The Volta controller would set up the L2VPN by constructing a L2 path from the 2 end-points to the PE-enabled Network Element at the 2 sites, and a  L2VPN tunnel to connect the 2 PE Network Elements. If the L2 path cannot be set up or no available PE Network Elements at either of the 2 sites, or, if the L2VPN tunnel cannot be set up between the 2 sites, the Volta Controller would declare that the connectivity cannot be achieved between these 2 endpoints.

The simplicity of this data-model ensures that users only need to express the connectivity between the 2 endpoints. The network-service data-model is expressed in high-level terms which are easily understood by even the end-users, thus enabling the procurement of the network-service being pushed more to the end-user level. This is where the trend of the industry is moving towards and how we, the networking supplicants, communicate with the networking divinity.

Leave a reply

Your email address will not be published. Required fields are marked *