Re: [Anima] What is intent ?

Toerless Eckert <tte@cs.fau.de> Wed, 26 July 2017 17:39 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 91B301320C8; Wed, 26 Jul 2017 10:39:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.714
X-Spam-Level:
X-Spam-Status: No, score=-2.714 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, 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 DSVN_Odv9TKs; Wed, 26 Jul 2017 10:39:07 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB1B9131D2E; Wed, 26 Jul 2017 10:39:06 -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 C67A058C4E5; Wed, 26 Jul 2017 19:39:00 +0200 (CEST)
Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id A8995B0C6D4; Wed, 26 Jul 2017 19:39:00 +0200 (CEST)
Date: Wed, 26 Jul 2017 19:39:00 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Sheng Jiang <jiangsheng@huawei.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, "anima@ietf.org" <anima@ietf.org>, J?ferson Campos Nobre <jcnobre@inf.ufrgs.br>, "draft-du-anima-an-intent.authors@ietf.org" <draft-du-anima-an-intent.authors@ietf.org>
Message-ID: <20170726173859.GA5750@faui40p.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/Zg69IKy_4xr3lD6Tipv6LW6PhRE>
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 17:39:18 -0000

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