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

[Brian E Carpenter <[e-mail]>]

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