Many years ago SDN was the new term in IT which started off as an idea no one really knew about, to what it is today. Although, still, there are those still debating who actually has “real SDN” implemented; however, I think the majority agree SDN is “settled”. Now, depending on who you are, who you work for, and what you actually believe, IBN is either the next “thing” in networking, or IBN is an evolution of SDN. Aside from the previous mentioned ongoing debate, there also exists those who are fighting to determine exactly what IBN is.
IBN – New or evolved SDN
The first debate largely depends on whose views you’re taking in regards to whether IBN is the new “next-best-thing”, separate from SDN, or IBN is an evolution of SDN. This doesn’t get easier because there are varying degrees of what existing vendors and new vendors are implementing and promoting. I align myself on the latter of the issue, I believe IBN is an evolution inside/from SDN.
Can you have IBN in a non-SDN network? I cannot see why not; however, I challenge you to think about how complex IBN would be to implement with environments not utilizing SDN technologies, including but not limited to such concepts as overlays, which play a key role in SDN. Sure, IBN is supposed to provide the abstraction so you’re not worrying about configuring via the CLI, but you lose all the tremendous flexibility with SDN oriented networks. Thus, in my opinion, IBN is an evolution of SDN because I don’t believe you can achieve the same degree of flexibility without SDN. Now, arguably, I would say IBN wouldn’t exist today without SDN, but that is merely my opinion.Where SDN provided abstraction from standard networking constructs, and limitations, IBN takes it further by interpreting the intent of the business to dynamically configure the network based on ever changing business demands.
IBN – What and How
Most are thinking “Isn’t the entire concept of IBN to eliminate the ‘how’ part in networking?’, and you are correct; however, the how in this post relates to how you actually implement IBN itself and what it actually does for you, the engineer.
When I mention how it comes down to what you’re using, the tool, to interact with your network to deploy IBN, and what it actually provides you. The ever elusive goal of IBN, like it was in SDN, was to be vendor agnostic, and we all know exactly how well this played out in the SDN space, but there are vendors today who have a vendor neutral IBN solution, albeit with limitations. The vendor/tool you use, in today’s IBN landscape, determines the IBN ideology, so a decision today aligns you with a specific viewpoint of IBN. If you’ve chosen an IBN solution, you’ve committed to how you’re going to deploy IBN, which determines what IBN is. The what of it is where there is still debate and I’ll explain what IBN is, based on my own professional views, which align with what I believe is a majority of the industry.
IBN is, from my perspective, an ideology in networking which provides abstraction from “how” you have to configure the network to support servers, applications, and security devices individually, to eventually allow them to work together. Instead, IBN allows the engineer to consider business oriented goals, including but not limited to: “I have an application which has data here and it needs to communicate with other applications here. Also, this data and application need only to be accessible to users based on these specific values”.
With SDN, you have a network built which natively supports things like: multi-tenancy and micro-segmentation; thus, you have a highly flexible foundation to which you can build your intent on. An IBN solution would understand how to interpret this intent the engineers configures in the “IBN tool” and this “tool” should automatically know how to build the logical constructs of things like: the basic network communication, network security configuration, IDS/IPS services, load-balancers, firewalls, and even advertising/controlling routing information. One thing which I left out is the initial stand-up of the network itself, and I did this on purpose.
The network designs which best support SDN are the spine-leaf networks we know as the CLOS-network. CLOS networks operate on the concept of all end-nodes being equidistant; thus, you only have one way to build them, with the only decision being the speed and number of links between each leaf, to each spine, all being equal. However, there are some IBN vendors whose only solution is based on/around building the underlay and overlay of this network type, claiming this is the complex piece of it. I believe what people are looking for is automation of the initial stand up and addition/removal of new spine/leaf switches in the network, which some vendors who’re already in the SDN space, already handle. These existing vendors, perhaps, could integrate this into their IBN such as: “I want to add another pair of 10GBaseSR switches with (X) number of ports configured like this, associated with contracts/policies, and then connected into the fabric with (Y) number of 100GbE spine up-links to each spine”.
I waited to write the last sentence above, because, to me, this is where you can see how IBN is an actual evolution of SDN, because it allows you built intent with high level “language” for everything from deploying/expanding the network, to building all your other policies to support the applications and users who use them.