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

[John Strassner <[e-mail]>]

Hi Brian,

please see <jcs2/>. I'm on a mailer with limited capabilities, so
please excuse the verbosity...

> 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>

To be blunt, I found a clear statement of purpose in Sue's draft
(draft-hares-ibnemo-overview) and I have never found that for SUPA except
in language that is too abstract for my thought processes.

<jcs2>
Does the following help:
>From the abstract of draft-klyus-supa-proposition-02:
   Simplified Use of Policy Abstractions (SUPA) defines an interface
   to a network management function that takes high-level, possibly
   network-wide policies as input and creates element configuration
   snippets as output. SUPA expresses policies using a generic policy
   information model, and outputs generic YANG data models.
</jcs2>

>> However, both IBNEMO and SUPA are definitely in the top/down
>> north/south configuration management tradition.
>
> <jcs>
> As opposed to what?
> </jcs>

Interactions between autonomic service agents (ASAs) are peer-to-peer;
there is no assumed hierarchy. Even intent could in theory come from
anywhere (anywhere authorized, that is) although we tend to assume it
will come from a NOC.

<jcs2>
Yup, this is how FOCALE worked. If you think that SUPA implies a
hierarchy, then that is bad and it should be fixed.
</jcs2>

>> 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>

I could imagine a particular ASA or group of collaborating ASAs
that are designed to use SUPA, for whatever their purpose in life
is. We have to co-exist with traditional NMS methods, and with
NETCONF, so why not with SUPA too?

<jcs>
Indeed, ANIMA should be able to handle other types of policies,
not just those of SUPA.
</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.

It's possible. Personally I want to put myself in the shoes of a NOC
operator or a network designer and ask: what does she want to tell or
authorize the network to do? That will set the level of abstraction or
detail in intent statements.

<jcs2>
I absolutely agree with this. In fact, this is why I stood up in the SUPA
BoF and said that SUPA intent is different than ANIMA, mainly because
ANIMA intent is not yet formally defined. But since ANIMA intent is
not yet formally defined, I don't understand why people immediately
conclude that ANIMA is different from SUPA.

Note that I am not arguing whether ANIMA intent should be different
than SUPA intent (or not); I am simply saying that you cannot compare
something that is not formally defined to anything else.
</jcs2>

> This also clearly influences the underlying data model that you choose.
> </jcs>

Well, if the syntax is sufficiently flexible, we should be able to
cope with a wide range of levels of abstraction. As for declarative
vs imperative, I think it's too soon to know for sure, but my feeling
is that we will find use cases that need both.

<jcs2>
SUPA is (at least right now) envisioned as primarily an effort in modeling.
I have posted on SUPA that a model, all by its lonesome, does NOT
provide any type of policy management solution. A data model is just
a set of data structures, it lacks the logic requirement to implement the
policy. I've also posted that a DSL whose nouns and verbs are
defined by an info model is likely what is needed.

 Rgds
   Brian



regards,
John

On Wed, Aug 19, 2015 at 7:00 PM, Brian E Carpenter <
[e-mail]> wrote:

> Hello John,
>
> On 20/08/2015 09:13, John Strassner wrote:
> > 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>
>
> To be blunt, I found a clear statement of purpose in Sue's draft
> (draft-hares-ibnemo-overview) and I have never found that for SUPA except
> in language that is too abstract for my thought processes.
>
> >> However, both IBNEMO and SUPA are definitely in the top/down
> >> north/south configuration management tradition.
> >
> > <jcs>
> > As opposed to what?
> > </jcs>
>
> Interactions between autonomic service agents (ASAs) are peer-to-peer;
> there is no assumed hierarchy. Even intent could in theory come from
> anywhere (anywhere authorized, that is) although we tend to assume it
> will come from a NOC.
>
> >> 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>
>
> I could imagine a particular ASA or group of collaborating ASAs
> that are designed to use SUPA, for whatever their purpose in life
> is. We have to co-exist with traditional NMS methods, and with
> NETCONF, so why not with SUPA too?
>
> >> 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.
>
> It's possible. Personally I want to put myself in the shoes of a NOC
> operator or a network designer and ask: what does she want to tell or
> authorize the network to do? That will set the level of abstraction or
> detail in intent statements.
>
> > This also clearly influences the underlying data model that you choose.
> > </jcs>
>
> Well, if the syntax is sufficiently flexible, we should be able to
> cope with a wide range of levels of abstraction. As for declarative
> vs imperative, I think it's too soon to know for sure, but my feeling
> is that we will find use cases that need both.
>
> Rgds
>    Brian
>
> >
> >>     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