Intent Based Networking Explained

[that1guy15]

My buddy Phil dropped this video on his blog. Good intro
https://networkphil.com/2017/06/27/what-is-intent-based-networking

[icecream-guy]

My buddy Phil dropped this video on his blog. Good intro
https://networkphil.com/2017/06/27/what-is-intent-based-networking

There's a 'man in the suit' walking down the street..
(Person of Interest reference, US tv show)
http://www.imdb.com/title/tt1839578/

[NetworkGroover]

I don't get it... I mean - I get what he's saying, but where the rubber meets the road, what does this really mean?  Someone still has to tell the devices what they should do to meet a given intent.  Who determines what the "best" way is to meet a given intent is?  Does that "best" way fit in every use case/environment?  How does this intent engine know?  The vendor is going to program every possible use case there could ever be, for any possible environment it could be in, for any possible application that could have any number of varied requirements? What happens when things change and new technology is constantly being introduced that cause either small or large shifts in how we design networks?

I could very easily be wrong, but for now... I'm calling this a Unicorn alert.  Sounds similar to ACI and having to deal with a whitelist just to get EPGs to talk to each other... in other words it's still not application or service or intent-centric - it's still you-centric.

[Dieselboy]

Thanks for the link

[that1guy15]

I don't get it... I mean - I get what he's saying, but where the rubber meets the road, what does this really mean?  Someone still has to tell the devices what they should do to meet a given intent.  Who determines what the "best" way is to meet a given intent is?  Does that "best" way fit in every use case/environment?  How does this intent engine know?  The vendor is going to program every possible use case there could ever be, for any possible environment it could be in, for any possible application that could have any number of varied requirements? What happens when things change and new technology is constantly being introduced that cause either small or large shifts in how we design networks?

I could very easily be wrong, but for now... I'm calling this a Unicorn alert.  Sounds similar to ACI and having to deal with a whitelist just to get EPGs to talk to each other... in other words it's still not application or service or intent-centric - it's still you-centric.

Think of going to AWS and requesting specific services, email, web front end, DB etc. You select what you want and size appropriate and click submit. AWS then delivers these services in a nice neat package. As the end user, you dont care how they were created, how they communicate or even what OS they run on. Just that the service is presented to you for whatever function you need them for.  This is what intent based networking is trying to solve. 

At the end of the day you dont care if its BGP, RIP static routing. Leaf/Spine 3-tier, or flat networking. Or Cisco, Juniper or Belkin. Dosent matter, provide what you want the network to do and the  application spits out a design and stands up a network. Same thing, you dont care how its built just that it provides the service you want.

Now I do agree and think this gets much more complex and harder to solve when this starts covering multiple areas of the network (network fabric, LBs, Firewalls, etc). But back to the AWS example, its not about how its being delivered and plumbed in. Its about delivering a service. This is for the intent engine or application to hash out.

When things change on the network I think it will be smoother than how we handle it now. Day 2 work with intent based networking is fully understanding the state of the network and how it should function. So say you have to shift routing protocols or topologies. The engine or application knows what the network should provide and adjust design accordingly, the same as building it new.

Of course this is all very reliant on something providing the intelligence and decisions engine. This is what I see making and breaking companies in this space. I dont see this as an easy task. Why do you think Apstra, Glue etc only support spine/leaf fabrics at the moment. Crawl, walk run IMO.

Also just like anything else, some customers will get in the middle of these and muck them up good because they dont understand or want to use the product as fully intended.

Thats my take anyways. Intent based networking has only been around a year or so and its still running through the vetting process. There are multiple takes and opinions on this.

[wintermute000]

[
At the end of the day you dont care if its BGP, RIP static routing. Leaf/Spine 3-tier, or flat networking. Or Cisco, Juniper or Belkin. Dosent matter, provide what you want the network to do and the  application spits out a design and stands up a network. Same thing, you dont care how its built just that it provides the service you want.

......<raises hand slowly> I care if its Belkin.....

[NetworkGroover]

I agree that it's a great idea, and again I get the idea of how it's supposed to work at a 10,000 foot level.  I just think this is unrealistic.  As much as I'd like to see this happen, *PURE OPINION WARNING* there's too many factors involved for any company to realistically address this properly, especially if it doesn't make money for them immediately.  I think a lot of companies are like, "SQUIRREL!", when it comes to finding different ways/ideas to make money - and they drop what they were working on previously like a bad habit.  Being publicly-traded doesn't help staying focused either.

[that1guy15]

Saw this today and think it sides with your view in some ways.

http://webcache.googleusercontent.com/search?q=cache:DW3tj4GDbIoJ:forums.juniper.net/t5/var-blog/Intent-based-IT-Who-architects-the-intent/ba-p/309673+&cd=1&hl=en&ct=clnk&gl=us


NOTE: cached version because original post is not listed anymore.

[deanwebb]

Interesting discussion and the Juniper cached article is well worth reading.

It made me think of the line, "It's working as designed, but I guess we shouldn't have designed it to do that..."

The idea that I may not care *how* something is provisioned is true if I'm an application owner, but it's equally true that, as an application owner, I may not know anything about provisioning to be useful. Imagine a guy in charge of email going through an intent-based networking wizard, clicking "yes" to everything and getting SMTP bumped to the top of the priority queue and all the devices that send or receive email are suddenly taken off the office vlan and moved to their own vlan... which provides layer 2 adjacency across the entire enterprise, everyone on the 10.20.0.0/16 network...

I get it how the guy can be frustrated by a QoS policy, but we can also make that a global thing and use automation to push that config everywhere.  As for other applications, most developers wouldn't know what ports they needed, so they're usually happy with just any/any/all permissions.

In the Datacenter, though, this can make some big differences for traffic optimization. On the edge... well... just imagine someone having an intent to offer AD services. Pretty much a permit any/any/all scenario at that point...

[burnyd]

Im kind of not exactly Phil explaining a lot of this really the way he has explained.

Intent is great.  The overall idea here is obviously during the initial greenfield deployment of saying I want 4 spines, 100 leaf switches and I want different vlans assigned to each one of them and its just going to do it for you.  Apstra doing this on multi vendor is really interesting.

Day 2 things like he is referring to like make sure all IoT devices are secure is more or less orchestration.  You are going to touch firewalls,IPS,IP tables etc is needs orchestrated through multiple different devices and in different clouds / areas.  End to end orchestration is a completely different hurdle than most.  I hate doing anything other than forwarding packets on network devices then you get left with ACI. 

Intent is good.  In 100% of all cases where I have had to do greenfield implementations with customers everyone is entirely different and requires entirely different either ansible J2 templates with playbooks, Python ZTP scripts or different cloud vision configlet builders.  My point is that if all of that physical infrastructure had a wrapper in front of it where it was easy then it would be a huge success.

[that1guy15]

The idea that I may not care *how* something is provisioned is true if I'm an application owner, but it's equally true that, as an application owner, I may not know anything about provisioning to be useful. Imagine a guy in charge of email going through an intent-based networking wizard, clicking "yes" to everything and getting SMTP bumped to the top of the priority queue and all the devices that send or receive email are suddenly taken off the office vlan and moved to their own vlan... which provides layer 2 adjacency across the entire enterprise, everyone on the 10.20.0.0/16 network...

As Ive been digging deeper and deeper into automation and all this fun stuff we are talking about, I have realized, us network engineers have a hard time with the idea of losing control of how the network is managed and operated. WE setup those switches and WE configure those VLANS and firewall policies. How dare anyone take that away from us. WE are the only ones who know this functions end to end.

My self included its a hard pill to swallow that this control and these functions can easily be automated and rolled up into an application and integrated into other work flows. When I talk to all my server buddies who went through the virtualization transition I hear alot the same hesitation when spinning up VMs became an automated task.

Its understandable because its the whole "They took our jobs" mentality or some stupid Jr app guy is going to blow the whole DC up with a mis-step. But that is where I like the idea of IBN. Intent and policy is set from a central source and applied to the applications we use. The IT department can then work within these constraints and manage things holistically.

Are we there yet? nope. I think we have a long ways to go. But I think its coming and we are just in the first few key steps to make this happen. 

[deanwebb]

So, I'm in a discussion yesterday with some NAC guys and it dawns on us that what we've been calling "port-based ACLs assigned to devices that match specific conditions" is actually "intent-based networking." We celebrated that we were ahead of the curve on the buzzword, high-fived each other, and then got back to planning how to block more traffic from getting out. NAC is the new firewall, baby!

Seriously, though, a NAC system is, at its heart, intent-based networking. Consider:
1. Identify all devices on the network.
2. Find all the printers.
3. Create an ACL that only permits printer traffic to/from printers, regardless of VLAN. (ACL is a named ACL so it can be used on multiple ports with minimal overhead.)
4. Create rule in NAC to apply ACL to all ports with printers connected (permit TCP 80, 443, 515, 9100 and Jetdirect)... now all printers get the ACL and when somebody plugs in a new printer, that new printer gets an ACL - automagically!

Build an ACL for each unmanageable device type so that it can't be used as a host for doing port scans or delivering an SMB-based exploit and let your NAC do the talking.

This NAC connection is why ISE is *so* important to the Cisco version of intent-based networking. They don't want to admit that any NAC system can pretty much do that job because they want to push their own gear... But you'll definitely need a NAC up and running to do intent-based networking at the access edge.

You'll also want netflow running so that you can be sure about the ports being used by those device types. Even if the network folk are opposed to netflow everywhere all the time, doing it in several locations for a period of observation will collect information on all ports used by a device - including those the device owner never knew about or the vendor forgot to mention in its documentation. Once you know the ports used by an Axis Communications security camera in one location, you'll be able to provision an ACL for an Axis Communications security camera anywhere.

[that1guy15]

high-fived each other, and then got back to planning how to block more traffic from getting out.
"Security: If you can do your job we are not doing ours!"

"If you can do your job we are not doing ours!"
-Security

[deanwebb]

"If you can do your job we are not doing ours!"
-Security

That is our intent, yes. And when you call to say that you can't reach that website we blocked, we say, "You're welcome!" 

But, back to the OP... while I had a hard time wrapping my head around using tools like Prime to do intent-based networking or taking requirements from an app guy to provision a VLAN, I totally get intent-based networking when it comes to dynamic microsegmentation via port-based ACLs.

And, ultimately, I think intent-based networking gets into security very quickly. While one can see it as an opening action, IE "provide access for these addresses and ports", it is also a closing action when one adds "and deny all others" to that sentence.

When it gets into combining criteria, it's even more restrictive. Consider, "Only financial staff logged on to computers that have "Finance" in a DN on a certificate are allowed to connect to financial systems." That means an IT admin logged in to a finance PC cannot access financial systems. A finance account logged on to a PC without that cert cannot access financial systems. NAC will have data on PCs and accounts being used on them and will be able to dynamically modify the ACL for the financial systems. Consider:

If device is in group "financial systems" then apply ACL "Financial_Access" on the access port for that device.
If PC cert includes DN=Finance AND user is in AD group "Finance" then add IP of PC to ACL "Financial_Access".
If PC no longer meets above conditions, remove IP of PC from ACL "Financial_Access".

^ That is a business request, converted into terms the engineers will understand. Intent-based networking will need lots of guys that can take customer requirements and deliver them to the engineers.

[ggnfs000]

intent based networking = apple, mercedes (high permance, if it breaks you have to get another one)
traditional networking = android, ford bronco (high maintenance, always breaks down, if it breaks change parts)