Subject: Re: [Anima] What is intent ?

From: Toerless Eckert <[email-masked]>
Date: Wed, 26 Jul 2017 19:39:00 +0200

Another aspect to consider: IMHO, industry player/marketeers use the term "intent" not
to describe a particular subset of instructions into the network but as a term to
describe the overall systems operation.

Eg: Google: https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/45687.pdf
Intent driven operations, from slide 22 on.

IMHO Cisco also jumped onto this terminology in its latest intent based networking pitch.

In this context, intent based networking is simply that the operator specifies a target
("intended") state of the network and some "rendering engine(s)" try to continuously modify
the network to match that intended state. Including changes to the network due to failures.
Eg: re-establish services such as BGP speakers on other nodes when current instances fail.

IMHO: with this notion of intent, it would be perfectly valid to enter any type of high
or low level declarative and even instructive data into the network - including my favourite
instance of an rfc8049 L3VPN service. The input into the network has no name in these models.
It is whatever operators put into SDN controllers or workflow engines, or whatever the tool
of the day is called.

My vision for ANIMA and intent is something like this:

  We come up with a term for everything operators would want to send into a network.
  Lets say we call it "directives". And we can keep the term for everything the operator
  gets out of a network "reporting".

  We structure and define some taxonomy for "directives", eg: "service definitions",
  "service instances", {user, topology, reliability, performance, acc-control,...}-policies, workflows,
  ...

  We describe an architecture how directives are rendered, eg: how the network is made to
  match the directives.  Different type of directives may require different rendering.

  The key difference between existing systems (google, cisco, ..) is that we define a
  hybrid central + distributed rendering architecture:

  draft-du-anima-intent IMHO would be the basis for the distributed rendering: This is
  used whenever there are self-rendering autonomic functions (aka: a group of ASA
  that know how to render directives).

  Even for central rendering there are no well established standards. That too IMHO would be
  worth looking at. Maybe some other IETF WG would like to do this as well, which would be fine
  too, as long as we allow this option in ANIMA as well.

The word intent does not happen in these definitions, and we are totally free to decide
later if we call the whole system "intent based", or iwf we call all of the directives
or just a subset of the directives "intent".

I am not sure if we would still want to take this step for the reference model. For
me it would be fine not to change reference model at all, and take the step above afterwards.
Its afer all not really a functional change to what we describe in the reference model,
but really only a refinemenet and then renaming to match evolving industry terminologies.

Cheers
    Toerless

P.S.: I  would have gone for "Objectives" instead of "Directives", but that word is
already occupied by GRASP and reuse would IMHO be confusing...

In-Reply-To: <[email-masked]>

On Wed, Jul 26, 2017 at 10:58:06AM +0000, Sheng Jiang wrote:
> 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
> 
> > -----Original Message-----
> > From: Anima [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> > Sent: Wednesday, July 26, 2017 7:05 AM
> > To: Toerless Eckert; [email-masked]
> > Subject: Re: [Anima] What is intent ?
> > 
> > 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:
> > > 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
> > >
> > > _______________________________________________
> > > Anima mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/anima
> > >
> > 
> > _______________________________________________
> > Anima mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/anima

-- 
---
[email-masked]

---

From: Alexander Clemm <[email-masked]>
Date: Wed, 26 Jul 2017 17:56:49 +0000

Maybe "directives" is a good term because less overloaded.  Of course, now there is one more term that needs to be differentiated from the others that came before. 

In my view, "intent" as it is used today really is not much more than a higher-level policy.  From this perspective, no new term would be needed.  

One distinction that one could perhaps make is that a policy is very specific concerning what needs to happen, typically expressed using some kind of rule sets based on event/condition/action, containing a well-defined set of events, conditions, as well as actions that need to occur.  So, a policy, like a directive, is very specific not just about what the network needs to do but how to do it.  

"Intent", on the other hand, would be less specific in terms of what needs to occur, e.g. the types of actions that need to be taken.  Those might be determined non-deterministically, potentially through collaborating systems; really the intent providing more of a desired "range of state" without trying to "program" how to reach or maintain it.  So, in that sense it would be very different from a directive.  Yes, more of a goal.  

When we first started using the term intent, my view at the time is that "intent" would be something that the network would have to infer from the operator's actions and utterances - an important aspect would be for the network to speak the language of the operator, as opposed to the other way around (forcing the operator to speak the network's language).  The discussion of intent languages put that viewpoint to rest, of course.  

--- Alex

-----Original Message-----
From: Anima [mailto:[email-masked]] On Behalf Of Toerless Eckert
Sent: Wednesday, July 26, 2017 10:39 AM
To: Sheng Jiang <[email-masked]>
Cc: J?ferson Campos Nobre <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Anima] What is intent ?

Another aspect to consider: IMHO, industry player/marketeers use the term "intent" not to describe a particular subset of instructions into the network but as a term to describe the overall systems operation.

In this context, intent based networking is simply that the operator specifies a target
("intended") state of the network and some "rendering engine(s)" try to continuously modify the network to match that intended state. Including changes to the network due to failures.
Eg: re-establish services such as BGP speakers on other nodes when current instances fail.

IMHO: with this notion of intent, it would be perfectly valid to enter any type of high or low level declarative and even instructive data into the network - including my favourite instance of an rfc8049 L3VPN service. The input into the network has no name in these models.
It is whatever operators put into SDN controllers or workflow engines, or whatever the tool of the day is called.

The word intent does not happen in these definitions, and we are totally free to decide later if we call the whole system "intent based", or iwf we call all of the directives or just a subset of the directives "intent".

I am not sure if we would still want to take this step for the reference model. For me it would be fine not to change reference model at all, and take the step above afterwards.
Its afer all not really a functional change to what we describe in the reference model, but really only a refinemenet and then renaming to match evolving industry terminologies.

Cheers
    Toerless

P.S.: I  would have gone for "Objectives" instead of "Directives", but that word is already occupied by GRASP and reuse would IMHO be confusing...

On Wed, Jul 26, 2017 at 10:58:06AM +0000, Sheng Jiang wrote:
> Toerless> Other folks in the IETF clearly think that a service 
> Toerless> 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 
> > apply to all information we would want to distribute into an 
> > autonomic network.
> > 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
> > 
> > > 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 ?
> > >
> > > 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
> > >

--
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 26 Jul 2017 20:42:50 +0200

> In my view, "intent" as it is used today really is not much more than a higher-level policy.  From this perspective, no new term would be needed.  

But thats not how its used in google/cisco for intent based networking. And if more
industry player catch on to how these compnies use intent very vaguely, any more
specific but contradictory definition we come up with would just be confusing.

Just tell me what in Googles definition is the intent. You saw my interpretation
in my prior mail.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Alexander Clemm <[email-masked]>
Date: Wed, 26 Jul 2017 20:15:44 +0000

OK, so it *is* used like in the subsequent paragraph.  ["Intent", on the other hand, would be less specific in terms of what needs to occur, e.g. the types of actions that need to be taken.  Those might be determined non-deterministically, potentially through collaborating systems; really the intent providing more of a desired "range of state" without trying to "program" how to reach or maintain it.]

This is then a way to distinguish it.  Specify a desired objective, or "range of state" (whatever state means), without needing to program how that would actually be accomplished.  This is different from a directive, or policy defined using E/C/A.   Which raises another question in the Anima context, namely whether it is just "intent" that is needed, or "intent + something else" (such as policy, directives, etc)

Cheers
--- Alex

-----Original Message-----
From: Toerless Eckert [mailto:[email-masked]] 
Sent: Wednesday, July 26, 2017 11:43 AM
To: Alexander Clemm <[email-masked]>
Cc: Sheng Jiang <[email-masked]>; J?ferson Campos Nobre <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Anima] What is intent ?

> In my view, "intent" as it is used today really is not much more than a higher-level policy.  From this perspective, no new term would be needed.  

But thats not how its used in google/cisco for intent based networking. And if more industry player catch on to how these compnies use intent very vaguely, any more specific but contradictory definition we come up with would just be confusing.

Just tell me what in Googles definition is the intent. You saw my interpretation in my prior mail.

Cheers
    Toerless

> Cc: J?ferson Campos Nobre <[email-masked]>; 
> [email-masked]; [email-masked]
> Eg: Google: 
> https://static.googleusercontent.com/media/research.google.com/en//pub
> s/archive/45687.pdf Intent driven operations, from slide 22 on.
> 
> In-Reply-To: 
> <[email-masked]
> om>
> 
> > > 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.
> > 
> > > 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".
> > > 
> > > Converting abstract Intent to concrete parameters can be 
> > > completely separate from this, and could well be a centralised operation.
> > > 
> > > > 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.
> > > >
> > > > 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 

--
---
[email-masked]

---

From: "Natale, Bob" <[email-masked]>
Date: Wed, 26 Jul 2017 20:27:51 +0000

I have been a real lurker on this and other ietf work for some time now (day job imperatives), so calibrate accordingly ... but I have long been an advocate of intent-based management (by whatever name) and find it easier to think of it as "mirroring" E/C/A with "G/C/M" ... "Goal / Constraints / Metrics". That "logical" symmetry helps me understand the standardization problem better, whether private, de facto, or de jure ... just like with events, conditions, and actions for ECA, we need to agree on the set, expression, etc., for goals, constraints, and metrics for intent-based management.

("Metrics" would include something like "Min / Max" or "Threshold / Objective" as applied to the "Goal" element. "Constraints" might often be metrics-based elements in their own right.)

Avanti,
BobN

-----Original Message-----
From: Anima [mailto:[email-masked]] On Behalf Of Alexander Clemm
Sent: Wednesday, July 26, 2017 4:16 PM
To: Toerless Eckert <[email-masked]>
Cc: J?ferson Campos Nobre <[email-masked]>; [email-masked]; [email-masked]; Sheng Jiang <[email-masked]>
Subject: Re: [Anima] What is intent ?

Cheers
--- Alex

-----Original Message-----
From: Toerless Eckert [mailto:[email-masked]]
Sent: Wednesday, July 26, 2017 11:43 AM
To: Alexander Clemm <[email-masked]>
Cc: Sheng Jiang <[email-masked]>; J?ferson Campos Nobre <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Anima] What is intent ?

Cheers
    Toerless

--
---
[email-masked]