Re: [Anima] Not the Intents we were looking for: SUPA Intents

["Natale, Bob" <[e-mail]>]

[Lurker alert!]

John just wrote on a related posting:
"If you want simplicity, then the easiest way to build that is to have a model that facilitates translation from some high-level form to an intermediate form that the system understands."

Simplicity is required. The model that facilitates translation is required because that is the way the world works from (declarative) high-level business policies to (imperative) executable configuration. The Policy Continuum is one such translation model that I will use for reference purposes here.

One potential problem I see with this overall discussion (not Toerless' posting immediately below, which is very helpful in my judgment) is that the matter of declarative and imperative policies is not, in the general end-to-end PBM case, an either/or situation:

   - Imperative is needed at the policy execution endpoint (roughly the "device" and "instance" views of the policy continuum) -- even though that might be "hidden" to a greater or lesser degree.

   - Declarative is needed at the policy creation point (roughly the "business", "system", and "admin" views of the policy continuum).

The "dividing line" in the middle of the continuum is not clear-cut ... it is very jagged, with spikes of declarative going farther "down" and spikes of imperative going farther "up" ... but a lot more of the latter than the former. And that's the crux of the matter. We have never standardized declarative at the level that it is needed and pushing imperative too far up the continuum ultimately becomes counterproductive.

Autonomic solutions of any kind are attempts to shorten the distance between the declarative and imperative endpoints, usually via greater degrees of "hidden" stuff. Shortening that distance is a good thing but -- to be done correctly (esp. for uptake) -- depends (among other things) on (1) a solution to the declarative problem and (2) transparency on the imperative side.

We have never effectively standardized the declarative capability for policy-based network management (PBNM, using a very liberal meaning for "network management" here). That is a show-stopper requirement. If we don't do that, we will just produce a new breed of partial solutions, resulting ultimately in more fragmentation and operational inefficiency due mainly from the large "expression gap" between how business decision-makers think and speak and how network technologists think and build.

I was really hoping that SUPA would tackle the declarative problem head on and not confound things with the imperative problem as well. I am not convinced that there should be one standard model for both at this stage. Imperative technology is widely deployed already (and growing constantly) ... of necessity. We've been able to survive without enabling the declarative capability, but that has not produced optimal PBNM solutions -- by a long shot! -- and is becoming ever less tenable as the scope, scale, and pace of requirements continue to increase at growing rates.

Regardless, ANIMA needs the declarative solution that SUPA (and/or IBNEMO) will provide.

Avanti,
BobN

-----Original Message-----
From: Anima [mailto:[e-mail]] On Behalf Of Toerless Eckert (eckert)
Sent: Thursday, August 20, 2015 10:33 AM
To: Michael Behringer (mbehring) <[e-mail]>
Cc: Duzongpeng <[e-mail]>; Michael Richardson <[e-mail]>; Jason Coleman (colemaj) <[e-mail]>; Anima WG <[e-mail]>; John Strassner <[e-mail]>
Subject: Re: [Anima] Not the Intents we were looking for: SUPA Intents

The question really is what the requirements are to support us trying to have an opinion about intent (in anima).

Systems to build more intelligent networks start to incooperate a whole slew of layers/concepts and intent is thrown around everywhere. Then you have big data and intent is expressed in that context, and you have semantic reasoners trying to fulfill intent and so on and so forth.

IMHO, anima would do well try to figure out what problems exist outside anima in the IETF and how anima can help. In the same was as more shorter term in bootstrap, this could longer term (re-chartering) apply to stuff around intent.

IMHO, it seems we already want to break up a system into components we call ASAs, and Laurent has started to explain in his draft how multiple ASA need coordination, and the way i read it, that would come through appropriate declarative information that lays out eg: dependencies,which can then be resolved. I am not sure if these dependencies are intent, but they are clearly important declarative informatoin we need to tackle once we deal with ASAs.

Cheers
    Toerless


On Thu, Aug 20, 2015 at 12:03:08PM +0000, Michael Behringer (mbehring) wrote:
> Probably we need to decide on a case-by-case basis. If (!) we allow imperative statements (I???d still like to see why we couldn???t do it declarative first), I???d like a way to separate them out logically in the structure of whichever encoding we???ll use. At least we can then keep the ???clean??? Intent separate from temporary workarounds.
> 
> Michael
> 
> From: Duzongpeng [mailto:[e-mail]]
> Sent: 20 August 2015 13:29
> To: Michael Behringer (mbehring); Jason Coleman (colemaj); John 
> Strassner; Toerless Eckert (eckert)
> Cc: Michael Richardson; Anima WG
> Subject: RE: [Anima] Not the Intents we were looking for: SUPA Intents
> 
> Hi Michael Behringer:
> 
> I agree that declarative intent has advantages.
> 
> But IMO, in the beginning, we should start defining intent using the simplest way no matter the intent is imperative or declarative.
> 
>          Perhaps in future, when the autonomic node is intelligent enough to understand the declarative intent, we can replace all the imperative ones.
> 
> However in this time, we should not preclude imperative intents.
> 
> Of course, in your example, ???Device x, do y???, this kind of Imperative intent should be avoided.
> 
> Best Regartds
> Zongpeng Du
> 
> 
> From: Anima [mailto:[e-mail]] On Behalf Of Michael 
> Behringer (mbehring)
> Sent: Thursday, August 20, 2015 6:54 PM
> To: Jason Coleman (colemaj); John Strassner; Toerless Eckert (eckert)
> Cc: Michael Richardson; Anima WG
> Subject: Re: [Anima] Not the Intents we were looking for: SUPA Intents
> 
> My view: Let???s keep intent purely declarative. If you need to support imperative concepts, do this through traditional methods, like CLI, netconf, etc.
> 
> Imperative says: Device x, do y. To me, that is not autonomic. And we shouldn???t pretend it is.
> 
> Now, this is a bit of a purist view, and I???ve heard comments along the lines: ???well, if we have this nice Intent concept, we want to use it for everything???. I???d rather keep it separate, but that is just a personal opinion of course ???  (A strong one though! ???
> 
> Michael
> 
> From: Jason Coleman (colemaj)
> Sent: 20 August 2015 12:18
> To: Michael Behringer (mbehring); John Strassner; Toerless Eckert 
> (eckert)
> Cc: Michael Richardson; Anima WG
> Subject: Re: [Anima] Not the Intents we were looking for: SUPA Intents
> 
> Why not allow both declarative and imperative in the structure of ANIMA and the delivery through and by the ACP and GRASP.
> How the Intent is then used by the end node is up to the developer of that node at that point.
> The node could be developed to only digest declarative or always allow declarative and only imperative for a discreet set of items that it supports in that regard.
> 
> --
> Jason Coleman CCIE#12069
> [e-mail]<mailto:[e-mail]>
> phone: [phone]
> Technical Lead Engineer CMS
> 
> This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
> 
> 
> From: Anima on behalf of "Michael Behringer (mbehring)"
> Date: Thursday, August 20, 2015 at 3:58 AM
> To: John Strassner, "Toerless Eckert (eckert)"
> Cc: Michael Richardson, Anima WG
> Subject: Re: [Anima] Not the Intents we were looking for: SUPA Intents
> 
> To me it is clear that ANIMA Intent is declarative. It describes the desired outcome, not the way to get to it. That???s exactly what Autonomics is all about, in fact. Different devices have different way to achieve things, different capabilities. In an imperative approach those different ways and capabilities would have to be expressed.
> 
> The reason the industry is having trouble with ACL management is exactly because it is imperative. It???s just the wrong approach for most use cases.
> 
> Autonomics aims to abstract away device specifics and to provide one higher level view of the network. That???s exactly the declarative approach. I really hope we have agreement on that.
> 
> Disclaimer: For practical reasons (device capabilities) it may well be required for some time to do some hacks in Intent that are imperative. As long as we all understand it???s a temporary hack, and are explicit about it, that???s ok.
> 
> So, do we agree that Intent is declarative? Any objections? We should really get agreement on that???
> 
> Michael
> 
> From: Anima [mailto:[e-mail]] On Behalf Of John 
> Strassner
> Sent: 20 August 2015 04:53
> To: Toerless Eckert (eckert); John Strassner
> Cc: Michael Richardson; Anima WG
> Subject: Re: [Anima] Not the Intents we were looking for: SUPA Intents
> 
> Hi Toerless,
> 
> I don't think it is that simple, unfortunately. Let's say that a NOC 
> operator wants to issue something like the following:
> 
>    "Any CPU in any VM whose utilization is > 70% should be
>     load-balanced."
> 
> The imperative version is, well, ugly:
> 
>    1) First, you have to translate what this means into a form
>        that a device could consume. This isn't particularly hard
>        in this example, but it still has to be done.
>    2) If the policy repository did not have a matching rule,
>        then you have to build one. But, how do you find every
>        device that should be affected? Even if we change the
>        rule to make it more explicit (e.g., s./CPU/router CPU),
>        this is a nightmare, because you now need to look at
>        the topology and build n of these rules just to do the
>        check, and some smaller number to do the load-balancing.
>    3) If the policy repository does have matches, how do you
>        know that they cover all of the cases?
> 
> In contrast, the declarative version is trivial: just do a distributed 
> transitive closure which finds all of the devices that meet the 
> criteria, and then apply the load balancing to this set.
> 
> So, in theory, you could use declarative to identify what devices you 
> could then apply imperative policies to.
> 
> In contrast, setting an ACL would be trivial with imperative, but much 
> more difficult with declarative (because you would have to translate 
> the declarative policy to something the device could consume).
> 
> This is likely one reason I have gray hair.
> 
> regards,
> John
> 
> On Wed, Aug 19, 2015 at 5:22 PM, Toerless Eckert (eckert) <[e-mail]<mailto:[e-mail]>> wrote:
> Does supa have opinions about the reaction time of imperative logic ? If it wants to support fast reaction, that would then imply the logic has to run in eg: the routers as opposed to an sdn controller.
> 
> I am also not sure i could decide between declarative and imperative... is an acces list imperative ? Is the name of a well known access list declarative ?
> 
> Toerless
> 
> 
> 
> 
> Sent from my Samsung Captivate Glide on AT&T
> 
> John Strassner <[e-mail]<mailto:[e-mail]>> wrote:
> Hi Michael,
> 
> I've been involved in SUPA, but also in ANIMA; here is my perspective:
> 
> > I found that the use cases from the SUPA BOF do not really match how 
> > we envision Intents to work with ANIMA ASAs.
> 
> <jcs>
> I'm not sure what is envisioned with intent in ANIMA; I have 
> previously posted that I don't think that there is enough detail on 
> what intent is and what it is supposed to do in ANIMA.
> </jcs>
> 
> > In particular, the model that is envisioned is far more SDN-like; 
> > that is with a uber-intelligent centralized command and control 
> > system that interprets SUPA Intents into things like Virtual Private 
> > Cloud (VPC/VPN) configurations, via various things like 
> > YANG/NETCONF/RESTCONF models, (but probably other data models)
> 
> <jcs>
> I'm personally not a big SDN fan for a number of reasons, and at least 
> in the I-Ds that I've written for SUPA, that is far from the vision 
> that I have had. But this is just my opinion; others may differ.
> 
> SUPA defines an information model (i.e., a model that is independent 
> of language, protocol, and repository) that consists of three pieces:
> 
>    1) generic policy concepts (e.g., the target of a policy, and
>        how policy is represented and structured)
>    2) an imperative model (i.e., event-condition-action) that is
>        derived from (1)
>    3) a declarative model (i.e., propositional or first order logic)
>        that is also derived from (1)
> 
> This structure enables sets of policies to be defined, where a 
> declarative policy could then trigger the evaluation of declarative 
> and/or imperative policies, and vice-versa.
> 
> I **think** that in ANIMA, the assumption has been that intent should 
> be declarative in nature. Please correct me if I am wrong.
> Please also realize that SUPA is both more than this, and models 
> declarative policy as formal logic. This has a large number of 
> advantages, especially for autonomics; please let me know if these are 
> not obvious.
> </jcs>
> 
> > It isn't clear to me if SUPA Intents are going to be designed to 
> > cross-AS boundaries, but it seems like they could easily do this.
> 
> <jcs>
> Indeed, they are. In my policy work, there is the concept of a policy 
> domain, which is any domain whose entities are governed by a common 
> set of policies. So the concept is actually broader than just ASs.
> </jcs>
> 
> > It seems like the ANIMA ACP is critically important for SUPA to be 
> > able to implement policies, but that's an operator convenience.  
> > They could equally well use other (more expensive!) management 
> > networks.
> 
> <jcs>
> Michael Behringer and I (and others, but I'm old so I have now 
> forgotten who, sorry!) talked about this at IETF92.
> FOCALE (my autonomic architecture) chose the latter (mainly because 
> ACP did not exist!) and I reflected that I wished I had thought of 
> doing something like ACP. I feel that this would have made FOCALE more 
> powerful and robust.
> </jcs>
> 
> > In the recording, I heard various things about ANIMA...
> > I don't think anyone overstated the situation, but I think that the 
> > message that ANIMA Intents != SUPA Intents was too understated.
> 
> <jcs>
> I have not seen ANIMA intent formally defined. I think it would be 
> interesting to determine first, if ANIMA intent should use declarative 
> logic or not (besides SUPA, ONF, OpenStack Congress, and to an extent, 
> ODL GBP all use declarative logic), and second, if ANIMA intent is not 
> going to use declarative logic, then why not?
> </jcs>
> 
> > Bert Wijnen (didn't he declare he was retired?) points on the list 
> > to
> >    IBNEMO - https://www.ietf.org/mailman/listinfo/ibnemo
> 
> <jcs>
> Note that NEMO says that they are defining a declarative policy, but 
> in reality, NEMO implements this with imperative (i.e., 
> condition-action) constructs.
> </jcs>
> 
> > It seems that there ought to be significant overlap, and yet I don't 
> > see it.
> 
> <jcs>
> IF ANIMA intent decides to use declarative logic or imperative logic 
> (in the form of event-condition-action), then I would hope that the 
> two indeed overlap. However, until ANIMA formally defines what intent 
> is, it is impossible to say.
> </jcs>
> 
> regards,
> John
> 
> 
> On Tue, Aug 18, 2015 at 12:50 PM, Michael Richardson <[e-mail]<mailto:[e-mail]>> wrote:
> 
> {intentionally not cross-posted to SUPA}
> 
> While working on other things today (and being at home with a 
> pink-eyed kid), I found the tab that was open to watch the IETF93 SUPA BOF.
> 
> I also had saved ~80 emails from the SUPA list to read.
> I found that the use cases from the SUPA BOF do not really match how 
> we envision Intents to work with ANIMA ASAs.  In particular, the model 
> that is envisioned is far more SDN-like; that is with a 
> uber-intelligent centralized command and control system that 
> interprets SUPA Intents into things like Virtual Private Cloud 
> (VPC/VPN) configurations, via various things like 
> YANG/NETCONF/RESTCONF models, (but probably other data models)
> 
> It isn't clear to me if SUPA Intents are going to be designed to 
> cross-AS boundaries, but it seems like they could easily do this.
> 
> It seems like the ANIMA ACP is critically important for SUPA to be 
> able to implement policies, but that's an operator convenience.  They 
> could equally well use other (more expensive!) management networks.
> 
> In the recording, I heard various things about ANIMA... I don't think 
> anyone overstated the situation, but I think that the message that 
> ANIMA Intents != SUPA Intents was too understated.
> 
> Bert Wijnen (didn't he declare he was retired?) points on the list to
>      IBNEMO - https://www.ietf.org/mailman/listinfo/ibnemo
> 
> There was a SUPA telecon yesterday morning, but I had a nomcom call, 
> so I missed it.  It seems that there ought to be significant overlap, 
> and yet I don't see it.
> 
> --
> Michael Richardson 
> <[e-mail]<mailto:[e-mail]>>, Sandelman 
> Software Works  -= IPv6 IoT consulting =-
> 
> 
> 
> 
> _______________________________________________
> Anima mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/anima
> 
> 
> 
> --
> regards,
> John
> 
> 
> 
> --
> regards,
> John

--
---
Toerless Eckert, [e-mail]

_______________________________________________
Anima mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/anima