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

[John Strassner <[e-mail]>]

> Although sharing the name “intent”, SUPA intent and ANIMA intent
> have different motivations and ways to define intent.

<jcs>
That will likely confuse people that are not part of ANIMA. Note that in
SUPA,
I try and avoid using the word "intent", because it is used differently in
different SDOs. In SUPA, I call it declarative logic. However, ONF,
OpenStack
Congress, and ODL call it intent.
</jcs>

>        SUPA intent begins with a common information model, while the
>        ANIMA intent will likely be defined by using some use cases first.

<jcs>
SUPA had a large number of use cases, most from operators. The reason
we define an information model is because of 2 reasons:
   1) we envisioned the translation to multiple data models, and
   2) I wanted an information model to build definitions for various
       parts of a language (e.g., nouns and verbs) if we did a DSL

More importantly, SUPA is NOT an "information model of the world."
SUPA is JUST an information model that defines policy.
</jcs>


 >        Furthermore, the aim of autonomic is to make intent as less as
>         possible, and as simple as possible to ease the network
>         management jobs.

<jcs>
You lost me. Why does something as complex as autonomics require
a simple policy?

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.
</jcs>


 >        ANIMA intent will increase bit-by-bit while the autonomic
>         service agents are being defined bit-by-bit.

<jcs>
An information model enables the representation and definition of
policy to grow with time. It seems to me that since you haven't
defined what your policy is, an information model would help.
</jcs>

>       IMO, any input from the operator to make the network more autonomic
can be considered as an “intent” in ANIMA.

>       Currently, perhaps because the use cases are not too many, I do not
find too much overlap between SUPA intent and ANIMA intent.

>       My suggestion is to develop them separately unless clear evidence
is found that autonomic network needs the information model defined in SUPA.
<jcs>
There are plenty of use cases in SUPA, or did you mean ANIMA?
</jcs>

regards,
John

On Wed, Aug 19, 2015 at 7:17 PM, Duzongpeng <[e-mail]> wrote:

> Hi John,
>
>
>
>          Some personal understanding to share.
>
>
>
>          Although sharing the name “intent”, SUPA intent and ANIMA intent
> have different motivations and ways to define intent.
>
>
>
>          SUPA intent begins with a common information model, while the
> ANIMA intent will likely be defined by using some use cases first.
>
>
>
>          Furthermore, the aim of autonomic is to make intent as less as
> possible, and as simple as possible to ease the network management jobs.
>
>
>
>          ANIMA intent will increase bit-by-bit while the autonomic service
> agents are being defined bit-by-bit.
>
>
>
> IMO, any input from the operator to make the network more autonomic can be
> considered as an “intent” in ANIMA.
>
>
>
>          Currently, perhaps because the use cases are not too many, I do
> not find too much overlap between SUPA intent and ANIMA intent.
>
>
>
>          My suggestion is to develop them separately unless clear evidence
> is found that autonomic network needs the information model defined in SUPA.
>
>
>
> Best Regards
>
> Zongpeng Du
>
>
>
> *From:* Anima [mailto:[e-mail]] *On Behalf Of *John
> Strassner
> *Sent:* Thursday, August 20, 2015 5:14 AM
> *To:* Brian E Carpenter; John Strassner
> *Cc:* Michael Richardson; Anima WG
> *Subject:* Re: [Anima] Not the Intents we were looking for: SUPA Intents
>
>
>
> Hi Brian,
>
>
>
> > I didn't do that, but having looked at the SUPA minutes, I then
>
> > looked at the IBNEMO documents, which make more sense to
>
> > me than SUPA.
>
>
>
> <jcs>
>
> I'd like to know why. This could actually help both SUPA and NEMO.
>
> </jcs>
>
>
> > However, both IBNEMO and SUPA are definitely in the top/down
>
> > north/south configuration management tradition.
>
>
>
> <jcs>
>
> As opposed to what?
>
> </jcs>
>
> > I don't see much overlap with SUPA.
>
>
>
> <jcs>
>
> I'd like to know why. Is this because you don't envision using ECA
>
> or logic rules, or some other reason?
>
> </jcs>
>
>
> > But actually the Nemo intent language looks more specific
>
> > than I expect Anima intent to be: compare with
> > draft-du-anima-an-intent and
> >
> https://tools.ietf.org/html/draft-jiang-anima-prefix-management-01#section-5.1
>
>
>
> <jcs>
>
> Please see my earlier reply to Michael Richardson.
>
> One could argue that this example is not "intent" as defined by ONF,
>
> ODL GBP, OpenStack Congress, or SUPA's declarative logic
>
> (though SUPA's ECA policy rule could easily express this). This is
>
> because in other declarative designs, those SDOs have decided
>
> that intent should NOT specify low-level parameters like IP
>
> addresses or port numbers or DSCPs. That of course doesn't
>
> mean that ANIMA couldn't do this, but it would mean that ANIMA's
>
> intent model diverges from the industry.
>
>
>
> This also clearly influences the underlying data model that you choose.
>
> </jcs>
>
>
>
>
> >     Brian
>
>
>
> regards,
>
> John
>
>
>
> On Tue, Aug 18, 2015 at 1:12 PM, Brian E Carpenter <
> [e-mail]> wrote:
>
> On 19/08/2015 07:50, Michael Richardson 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 didn't do that, but having looked at the SUPA minutes, I then looked
> at the IBNEMO documents, which make more sense to me than SUPA.
> However, both IBNEMO and SUPA are definitely in the top/down north/south
> configuration management tradition.
>
> > 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.
>
> Agreed, judging by the documents. Anyway it seems clear that SUPA is
> not yet ready to get chartered.
>
> > Bert Wijnen (didn't he declare he was retired?)
>
> Well yes, but as I told him when he said that, retirement often
> doesn't work first time ;-).
>
> > 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.
>
> I don't see much overlap with SUPA.
>
> If IBNEMO comes up with a good data model and syntax for expressing
> intent, we should consider using it. I guess one of the authors of
> draft-zhou-netmod-intent-nemo and draft-xia-sdnrg-nemo-language
> can advise us about that. But actually the Nemo intent language looks
> more specific than I expect Anima intent to be: compare with
> draft-du-anima-an-intent and
>
> https://tools.ietf.org/html/draft-jiang-anima-prefix-management-01#section-5.1
>
>     Brian
>
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima
>
>
>
>
> --
>
> regards,
>
> John
>
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima
>
>


-- 
regards,
John