Subject: [Anima] What is intent ?

From: Toerless Eckert <[email-masked]>
Date: Tue, 25 Jul 2017 22:34:55 +0200

I have an autonomic network, and i want for another customer another
L3VPN service instance in it.  How would i tell the network that i want
this ? Via intent or via something else ?

If it is something else, what is it ? I do not see any other information flow from
operator to network beside intent in RFC7575 or draft-ietf-anima-reference-model. 
Maybe i am missing something.

If it is intent, how would it look like ? Could it simply be a definition
of an L3VPN service instance in the model defined in rfc8049 ? If not, why not ?

IMHO: Intent in ANIMA includes service definitions such as what rfc8049 is,
except that we would reserve the right to eliminate all parameters of rfc8049
for which we figure out autonomic ways to determine them. Which alas seems to
be quite difficult for most parameters. 

Other folks in the IETF clearly think that a service definition is NOT intent,
but intent can only be some yet unclear high level policy. If thats the
prevailing opinion/wisdom in the IETF, then IMHO we need to be more explicit about the
fact that Intent is not the only input into the network but that there is
also other input. Such as services. And anything else that people do not want to
call Intent.

Lets assume service and other necessary data operator->network should not
be called intent. But lets say the superset of intent + services + everything
else is called eg: "information". I think that draft-du-anima-an-intent
would equally apply to all information we would want to distribute into
an autonomic network. 

Cheers
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Jul 2017 11:04:42 +1200

Distribution trimmed to Anima:

Whenever I've asked "Is X Intent?", I've usually been told "No" except for
cases where X is too abstract to interpret algorithmically.

But in practice, I believe that many ASAs will need instructions from
the NOC to modify their default behaviour. I don't care what we call
those instructions; for the prefix management use case we just called
them "parameters".

So maybe Anima should focus on parameter distribution more than on
Intent. I think that's the point of draft-liu-anima-grasp-distribution.
A fairly simple change to the wording of draft-du-anima-an-intent
would adapt it to generic parameter distribution.

Converting abstract Intent to concrete parameters can be completely
separate from this, and could well be a centralised operation.

Or we could spend another 6 months discussing how to know Intent
when we see it. But I would prefer that to happen in NMRG.

Regards
   Brian

On 26/07/2017 08:34, Toerless Eckert wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Jéferson Campos Nobre <[email-masked]>
Date: Wed, 26 Jul 2017 00:05:37 +0000

Hi.
The current wording in draft-du-anima-an-intent is "ANIMA Intent Policy".
This sounds a little repetitive, but it highlights the problematic nature
of intent in ANIMA.
I'm not sure if only parameters can be enough, but it is also depends on
the definition of "parameters"... Maybe some form of policies (for example,
ECA rules) can be included in the discussion. In any case, I believe this
could be addressed in draft-du-anima-an-intent.
I agree with Brian, the intent "philosophical" discussion fits better the
NMRG. BTW, there is a discussion about it in Prague and this could lead to
a new NMRG workshop (like the autonomic ones).
Best.
Jéferson

---

From: Zoran Despotovic <[email-masked]>
Date: Wed, 26 Jul 2017 07:29:41 +0000

Hi,

A little bit off the thread started by Toerless, I believe that the development of the infrastructure on which intents are distributed should not be tightly bound to our understanding of and consensus on what intents are (and what they are not). This, at least, as long as there are other parameters to be distributed over that infrastructure. In that sense, I do agree with Brian's mail. 

Regards, 
Zoran

-----Original Message-----
From: Anima [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Wednesday, July 26, 2017 1:05 AM
To: Toerless Eckert; [email-masked]
Subject: Re: [Anima] What is intent ?

Whenever I've asked "Is X Intent?", I've usually been told "No" except for cases where X is too abstract to interpret algorithmically.

But in practice, I believe that many ASAs will need instructions from the NOC to modify their default behaviour. I don't care what we call those instructions; for the prefix management use case we just called them "parameters".

So maybe Anima should focus on parameter distribution more than on Intent. I think that's the point of draft-liu-anima-grasp-distribution.
A fairly simple change to the wording of draft-du-anima-an-intent would adapt it to generic parameter distribution.

Converting abstract Intent to concrete parameters can be completely separate from this, and could well be a centralised operation.

Or we could spend another 6 months discussing how to know Intent when we see it. But I would prefer that to happen in NMRG.

Regards
   Brian

On 26/07/2017 08:34, Toerless Eckert wrote:
> L3VPN service instance in it.  How would i tell the network that i 
> want this ? Via intent or via something else ?
> 
> If it is something else, what is it ? I do not see any other 
> information flow from operator to network beside intent in RFC7575 or draft-ietf-anima-reference-model.
> If it is intent, how would it look like ? Could it simply be a 
> definition of an L3VPN service instance in the model defined in rfc8049 ? If not, why not ?
> 
> IMHO: Intent in ANIMA includes service definitions such as what 
> rfc8049 is, except that we would reserve the right to eliminate all 
> parameters of rfc8049 for which we figure out autonomic ways to 
> determine them. Which alas seems to be quite difficult for most parameters.
> 
> Other folks in the IETF clearly think that a service definition is NOT 
> intent, but intent can only be some yet unclear high level policy. If 
> thats the prevailing opinion/wisdom in the IETF, then IMHO we need to 
> be more explicit about the fact that Intent is not the only input into 
> the network but that there is also other input. Such as services. And 
> anything else that people do not want to call Intent.
> 
> Lets assume service and other necessary data operator->network should 
> not be called intent. But lets say the superset of intent + services + 
> everything else is called eg: "information". I think that 
> draft-du-anima-an-intent would equally apply to all information we 
> would want to distribute into an autonomic network.
> 
> Cheers
>     Toerless
>

---

From: Artur Hecker <[email-masked]>
Date: Wed, 26 Jul 2017 08:44:28 +0000

Hi

Aren't intents something related to the actual autonomics of the ANI, while the use case described by Toerless would be more from an operated context?

RFC7575 in particular does not exclude operated environments, and the latter might or might not use intents or policy-based management principles. So, what is autonomic is the establishment and maintenance of the ACP, I,.e. the means to manage the environment (in any way you like). So, from my understanding, solely the autonomic part related to the self-* properties of the ACP and the autonomic domain (AD) as such would be driven by intents, and not more than that. Corroborating this interpretation, the scope of the intent is intrinsically bound to the very notion of AD by the definition of the latter, cf. RFC7575.

Therefore, we could try to agree on something like this:
- Within the scope of the ANIMA WG, we could interpret intents as solely related to the ANIMA itself, not to its usage. In other words, the existence, constraints, form, shapes and parameters of the AD per se (=the enabling substrate, the mandatory ASAs, the implementation of the ANI) are ruled by and derived from intents. [What is meant here is a form of policy based management, where instead of precise actions (do this), the expected conditions (pre- and post-) are formulated for and within the limits of the AD (pre-condition => post-condition). The only interesting property of this is that it is implementation agnostic, i.e. you are not prescribing how the post-condition is to be achieved. In my interpretation, this means that in particular the standardization effort is minimized (since we do not prescribe how to arrive at a particular situation, we do not have to worry about specific mechanisms within the ANIMA itself; a conforming implementation has different ways how to achieve it)].

- How the AD is used, e.g. by an operator, or by some end-user ASA, should rather be outside of the scope of ANIMA WG and is solely constrained by the API that ANIMA would propose and the imagination of the respective owners/developers.

Note that this does not preclude any kind of "recursive" definitions, where an AF implemented on top of an ANI would constitute another AD, where the same would apply (ASAs would become "nodes"), etc.

Does that make any sense?

Regards
artur

-----Original Message-----
From: Anima [mailto:[email-masked]] On Behalf Of Zoran Despotovic
Sent: 26 July 2017 09:30
To: [email-masked]
Subject: Re: [Anima] What is intent ?

Hi,

Regards,
Zoran

-----Original Message-----
From: Anima [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Wednesday, July 26, 2017 1:05 AM
To: Toerless Eckert; [email-masked]
Subject: Re: [Anima] What is intent ?

Regards
   Brian

---

From: Eliot Lear <[email-masked]>
Date: Wed, 26 Jul 2017 12:56:12 +0200

Hi Toerless,

I've heard MUD called a form of intent, but it's not a perfect fit.  MUD
expresses needs rather than intent.  That is- "I need the network to
allow X."  One could *infer* an intent, but but such inferences get
riskier the higher up the stack one goes.  In your case, though, one
could extend the MUD file to describe the need for a VPN, so long as the
parameters of that VPN are well understood in the terms of the MUD
abstractions at the time of manufacturer ("my-controller",
"same-manufacturer", etc).

As a formalism between ANIs, MUD is not the droid you're looking for, as
currently scoped.

Eliot

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 26 Jul 2017 10:58:06 +0000

Hi, Toerless, Brian & Jeferson,

Please see my replies in line with quotas from you.

Toerless> Other folks in the IETF clearly think that a service definition is NOT intent, but
> intent can only be some yet unclear high level policy. If thats the prevailing
> opinion/wisdom in the IETF, then IMHO we need to be more explicit about the
> fact that Intent is not the only input into the network but that there is also
> other input. Such as services. And anything else that people do not want to call
> Intent.

I prefer such distinguish definitions. Intent itself does not have a clear definition. It does not a clear role in Autonomic network either. This word has been abused a lot. If we cannot reach consensus on its semantics. It may be wise to give up it and choose more precise terminologies.

Toerless>I think that draft-du-anima-an-intent would equally
> apply to all information we would want to distribute into an autonomic
> network.
Jeferson>I believe this could be addressed in draft-du-anima-an-intent.

As a co-author of this draft, I also think we have a very good base already. However, we may need to rename the document in order to avoid the too-hot term "intent".

Brian>we could spend another 6 months discussing how to know Intent when we see it. But I would prefer that to happen in NMRG.
Jeferson>I agree with Brian, the intent "philosophical" discussion fits better the NMRG.

This suggestion is actually very pragmatic. Let's focus on these concrete and generic solutions first.

Regards,

Sheng

> Sent: Wednesday, July 26, 2017 7:05 AM
> Whenever I've asked "Is X Intent?", I've usually been told "No" except for cases
> where X is too abstract to interpret algorithmically.
> 
> But in practice, I believe that many ASAs will need instructions from the NOC to
> modify their default behaviour. I don't care what we call those instructions; for
> the prefix management use case we just called them "parameters".
> 
> So maybe Anima should focus on parameter distribution more than on Intent. I
> think that's the point of draft-liu-anima-grasp-distribution.
> Converting abstract Intent to concrete parameters can be completely separate
> from this, and could well be a centralised operation.
> 
> Or we could spend another 6 months discussing how to know Intent when we
> see it. But I would prefer that to happen in NMRG.
> 
> Regards
>    Brian
>