Re: [Anima] What is intent ?

Toerless Eckert <tte@cs.fau.de> Wed, 26 July 2017 18:42 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B490D131C95; Wed, 26 Jul 2017 11:42:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id an9fjxs_XS22; Wed, 26 Jul 2017 11:42:55 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C181A126CD8; Wed, 26 Jul 2017 11:42:55 -0700 (PDT)
Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 23B2858C4C3; Wed, 26 Jul 2017 20:42:51 +0200 (CEST)
Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 0C209B0C6D4; Wed, 26 Jul 2017 20:42:50 +0200 (CEST)
Date: Wed, 26 Jul 2017 20:42:50 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Alexander Clemm <alexander.clemm@huawei.com>
Cc: Sheng Jiang <jiangsheng@huawei.com>, J?ferson Campos Nobre <jcnobre@inf.ufrgs.br>, "draft-du-anima-an-intent.authors@ietf.org" <draft-du-anima-an-intent.authors@ietf.org>, "anima@ietf.org" <anima@ietf.org>
Message-ID: <20170726184250.GC5750@faui40p.informatik.uni-erlangen.de>
References: <20170726173859.GA5750@faui40p.informatik.uni-erlangen.de> <644DA50AFA8C314EA9BDDAC83BD38A2E0E0EAA35@SJCEML703-CHM.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0E0EAA35@SJCEML703-CHM.china.huawei.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/KcQzm8MfxecYiL-hthnYdc4ZZsU>
Subject: Re: [Anima] What is intent ?
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jul 2017 18:42:58 -0000

On Wed, Jul 26, 2017 at 05:56:49PM +0000, Alexander Clemm wrote:
> 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.  

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

> 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:anima-bounces@ietf.org] On Behalf Of Toerless Eckert
> Sent: Wednesday, July 26, 2017 10:39 AM
> To: Sheng Jiang <jiangsheng@huawei.com>
> Cc: J?ferson Campos Nobre <jcnobre@inf.ufrgs.br>; draft-du-anima-an-intent.authors@ietf.org; anima@ietf.org
> 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.
> 
> 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: <5D36713D8A4E7348A7E10DF7437A4B927CE3A55E@NKGEML515-MBX.china.huawei.com>
> 
> 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 
> > 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 
> > > 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:anima-bounces@ietf.org] On Behalf Of Brian E 
> > > Carpenter
> > > Sent: Wednesday, July 26, 2017 7:05 AM
> > > To: Toerless Eckert; anima@ietf.org
> > > 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
> > > > Anima@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/anima
> > > >
> > > 
> > > _______________________________________________
> > > Anima mailing list
> > > Anima@ietf.org
> > > https://www.ietf.org/mailman/listinfo/anima
> 
> --
> ---
> tte@cs.fau.de
> 
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
tte@cs.fau.de