Intent-Based Hype

It all started with a realistic response I got to my automation and orchestration blog post (here’s a unicorn-driving-a-DeLorean one in case you missed it):

Maybe you could also add the “intent-based network” which is also not so far from orchestration?

It got me thinking. The way I understand intent-based whatever, it’s an approach where I tell a system what I want it to do, not how to do it.

A Bit of History

Before I even start: if you believe that intent-based whatever means the controller will guess what you want to do without you being able to specify precisely what it is, you clearly missed the Fifth Generation Programming Language hype.

I don’t blame you; that hype peaked in 1980s, proving yet again Rule 11.

What Is Intent?

Now think about the way we configure network devices. Do you tell them how to do things, or do you just tell them what you want them to do? When you configure OSPF on an interface, do you really tell the box how to discover neighbors or just what you want it to do (figure out if there are any neighbors on that interface and exchange information with them)?

When I started going down that route the engineer who sent me the initial remark tried to be helpful (we were both struggling at this point to figure out whether we’re dealing with something real or pure marketing hype). He started with:

I think the result is “multi-devices configuration”

As anyone watching my Network Automation 101 webinar or attending the Building Network Automation Solutions course knows I totally agree that dealing with network devices on a box-by-box basis is wrong and that we should look at the network as a whole and then derive device configurations from network-wide data model.

Obviously, I’m not the only one thinking along these lines. Dinesh Dutt (Cumulus Networks) and David Barroso (Fastly) described the same ideas in their parts of Network Automation Use Cases webinar.

However, coming back to the basics: how is “multi-device configuration” different from Juniper’s QFabric, or using a single ginormous box to build your network?

A Down-to-Earth Definition

David Barroso came up with a good definition in an email exchange:

Intent: I want vlans 10, 20 in my network device.

Imperative: Configure vlan 10, remove vlan 11, configure vlan 20, remove vlan 21, 30, 40 and pray.

You probably know that David got so frustrated dealing with so many broken devices that cannot take new configuration and apply it the way we handle configuration changes in Linux world where we usually just reload the server that he started the NAPALM project to deal with it… and got infinitely more exposure to the network device brokenness than he would have had otherwise.

Is intent-based networking just the capability to apply new device configuration without worrying how to get from the old to the new one? That would make sense, but it’s not flashy enough for vendor marketing.

It’s All about the Policy

Next attempt in the automation vs. orchestration discussion I mentioned in the beginning of the blog post.

Maybe I’m wrong but my understanding is that the main difference is to use a “policy model” which is abstracting the classical network constructs. Of course, state of the network, automation, remediation or other assurance stuff still there but everything is “policy centric”.

I still fail to see how that’s different from configuring OSPF on all interfaces ;) After all, that’s my routing policy. Likewise, isn’t my ACL expression of my security policy?

Or Maybe It’s All about Abstraction Layers

Before you start telling me how stupid I am not to appreciate all the wizardry done by whatever startup… I agree we’re doing lots of things at the wrong level of abstraction, I’ve been preaching the need for automation and network-centric (as opposed to device-centric) data models, and I agree that an end-user shouldn’t know about VLANs when all she needs is connectivity between two VMs.

But seriously, I still think calling that intent-based networking instead of what it really is (a different, not necessarily better abstraction model) is a lot of meaningless marketing BS. Unfortunately, we’ll likely be stuck with it like we are with software-defined whatever.

What Could Possibly Go Wrong?

Every time someone adds yet another layer of abstraction, it reminds me of RFC 1925 rule 6 and 6a:

(6) It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it.
(6a) (corollary). It is always possible to add another level of indirection.

There’s also the Law of Leaky Abstractions, which will definitely bite you (intentionally or otherwise).

Every time someone claims their solution will reduce the complexity of whatever, I start thinking about squashed complexity sausage.

And every time someone tells me about an umbrella system that will tie together disparate systems, I hear lock-in.

Then there’s lack of standards. Somehow you have to communicate with the wonderful intent-based system (whatever it really is). Will you use GUI to do that? I wish you luck. Will you use an API? Is it standardized? Hint: no.

And finally, today you’re complaining that the network devices do only what vendors want them to do. Tomorrow you’ll be complaining that you can only express intent the vendors thought you might want to express, and that it got implemented in the way the vendors thought it might be implemented, not the way you want to see it work. The more things change, the more they stay the same.

Still Not Enough?

Here are a few interesting blog posts I collected on this topic:

I also covered intent-based networking details in the Network Automation Concepts webinar.

5 comments:

  1. Evolution is an iterative process and while I'm a huge fan of RFC1925, after "N" attempts at tackling the issue, some progress is eventually made. With the same logic / skepticism we would have never seen planes after centuries of failures.

    That being said, I agree that "intent networking" has a lot of hype to it and that there are no shortage of opportunists to take advantage of it.

    Last week as part of Future:Net, a full block of the conference was on that topic with interesting research and attempts at solving the problem. 2 broad focus areas: "implementing intent" and "verifying / validating" that what you wanted as an intent is indeed what got deployed with the later accounting for the bulk of the talks.

    Dr David Cheriton developed an analogy that hit home for me to explain “intent”. He used a comparison with programming languages that evolved from assembly language, to structure languages such a C / C++, etc which slowly abstracted things like registers and memory locations, introduced libraries, etc. to eventually end up with things like SQL where instructions are literally “give me all records containing Bob” that has no ties back to where the data resides, how it is stored, its format, etc. To link it back to networking, we are still pretty much at the C / C++ level of abstraction.

    Will we get it right this time? Who knows but I'm not overly optimistic. Is the need real and the work / efforts put in it useful ? absolutely. There are some good minds looking at this and while we "practitioners" often dismiss the objectives of these researches as "unicorns" because of the battle scars accunulated from operating networks (rule #4), I got some nuggets out of it even if it is possibly just to cut thru the BS presented by vendors.
    Replies
    1. What you described are just many layers of abstraction. Let's call it that and move on to getting it done (and at least we'll know what we talk about).
    2. the analogy I related did point to abstractions but not the rest of my post.

      To help with your last point, you may want to check the keynote delivered by Ratul Mahajan https://www.vmware.com/content/microsites/futurenet/live.html?src=em_59948f31df0cd&cid=70134000001CaYR
  2. "I could read his thoughts in 5 minutes instead of listening to him speak for 15);"

    No offence... but I have the same problem with your webminars;) They are great but it takes to long to go through them (and find single thing you are looking for), especially for someone being in the networking business for 20+ years (still being an engineer).

    Please write books, especially those showing Rule 11 in last 25+ years of networking;)
    Replies
    1. Yeah, I know ;) ... and no, I won't write another book. I'm not as prolific as Russ White ;))
  3. Hi Ivan,

    Great article as usual. I have a point here. What if tge business have a conflicting or opposing requirements (or intention) how the network is going to respond to this
    Replies
    1. Karim Tarek, network engineer @etisalat
    2. Your guess is as good as mine ;) Do keep in mind that we're far away from applying AI or machine learning to this - so whatever the vendor of the controller will think is a good idea will happen... from "sorry, can't do that" to overloading the network (in case they wouldn't have figured out that there's a problem in the requirements).

      You're just replacing your engineers with vendor's programmers.
  4. Great article. To be honest this whole intent-based thing just sounds like more propaganda from big vendors to get us to buy old products. It's painful to see how many people get sold on purely marketing material.

    That said, I am a fan of the concept of Intent as I first heard of which was at the ON Lab. It would be great to configure a network in high level terms rather than configuring each device. On the other side that also seems a little simplistic and superficial for current enterprise needs.
  5. So things doesn't seem to have changed much in last 5 years since it all started :)

    https://anetworkartist.blogspot.com/2017/11/few-questions-you-should-ask-your-fav.html

    https://www.linkedin.com/posts/anetworkartist_sdn-ibn-networkautomation-activity-6839372954795675648-Hjnb

Add comment
Sidebar