Re: [Anima] What is intent ?

"Natale, Bob" <RNATALE@mitre.org> Wed, 26 July 2017 20:27 UTC

Return-Path: <RNATALE@mitre.org>
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 D4278129B7F; Wed, 26 Jul 2017 13:27:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mitre.onmicrosoft.com
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 C5vV4-r7-BiV; Wed, 26 Jul 2017 13:27:54 -0700 (PDT)
Received: from smtpvmsrv1.mitre.org (smtpvmsrv1.mitre.org [192.52.194.136]) by ietfa.amsl.com (Postfix) with ESMTP id 4C32E12942F; Wed, 26 Jul 2017 13:27:54 -0700 (PDT)
Received: from smtpvmsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 83C4E6C0A05; Wed, 26 Jul 2017 16:27:53 -0400 (EDT)
Received: from imshyb02.MITRE.ORG (imshyb02.mitre.org [129.83.29.3]) by smtpvmsrv1.mitre.org (Postfix) with ESMTP id 70B296C0940; Wed, 26 Jul 2017 16:27:53 -0400 (EDT)
Received: from imshyb01.MITRE.ORG (129.83.29.2) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 26 Jul 2017 16:27:53 -0400
Received: from gcc01-dm2-obe.outbound.protection.outlook.com (10.140.19.249) by imshyb01.MITRE.ORG (129.83.29.2) with Microsoft SMTP Server (TLS) id 15.0.1263.5 via Frontend Transport; Wed, 26 Jul 2017 16:27:52 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mitre.onmicrosoft.com; s=selector1-mitre-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WDarWxpRS8AsnuoPYgl39IJ1qIFC2dLvj4w/srXwB9g=; b=WowLVNLXESn0rdMIhc9KHFgr8zy8NYSGZ+N+/sngtzTfATTUloLqJW3yifpHguLNXyVoZZRAVo3COLUDMiNJ5YP16AGiGWbWT+6buMCB30Wtnj9av8mfkfgz+4vOgpM2EczCJK6J3UuxiJTkYxerE/t8a8TFNAB6bbHjMT5jAK0=
Received: from CY1PR09MB0922.namprd09.prod.outlook.com (10.163.89.140) by CY1PR09MB0921.namprd09.prod.outlook.com (10.163.89.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.14; Wed, 26 Jul 2017 20:27:51 +0000
Received: from CY1PR09MB0922.namprd09.prod.outlook.com ([10.163.89.140]) by CY1PR09MB0922.namprd09.prod.outlook.com ([10.163.89.140]) with mapi id 15.01.1304.014; Wed, 26 Jul 2017 20:27:51 +0000
From: "Natale, Bob" <RNATALE@mitre.org>
To: Alexander Clemm <alexander.clemm@huawei.com>, Toerless Eckert <tte@cs.fau.de>
CC: J?ferson Campos Nobre <jcnobre@inf.ufrgs.br>, "anima@ietf.org" <anima@ietf.org>, "draft-du-anima-an-intent.authors@ietf.org" <draft-du-anima-an-intent.authors@ietf.org>, Sheng Jiang <jiangsheng@huawei.com>
Thread-Topic: [Anima] What is intent ?
Thread-Index: AQHTBjYQNUmj713ia0SIjHx2HSToP6JmZK+AgAAM2wCAABn1AIAAAT+w
Importance: low
X-Priority: 5
Date: Wed, 26 Jul 2017 20:27:51 +0000
Message-ID: <CY1PR09MB092216B8D6137759AC30D2E7A8B90@CY1PR09MB0922.namprd09.prod.outlook.com>
References: <20170726173859.GA5750@faui40p.informatik.uni-erlangen.de> <644DA50AFA8C314EA9BDDAC83BD38A2E0E0EAA35@SJCEML703-CHM.china.huawei.com> <20170726184250.GC5750@faui40p.informatik.uni-erlangen.de> <644DA50AFA8C314EA9BDDAC83BD38A2E0E0EAB5C@SJCEML703-CHM.china.huawei.com>
In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0E0EAB5C@SJCEML703-CHM.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=RNATALE@mitre.org;
x-originating-ip: [192.80.55.87]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY1PR09MB0921; 7:r1llfLTJcWtX4d3BWzM5Fe+78CXj8+r1aDd4S8Ohhr0UNI2PxsRs74FuNAGLWHaPfD6v3poJisE4NsPiklay3KjRaMR0uB6g91wD98149dvVisuKxtnH0nVKxOud8jQERUSfLdpt6UZ2xEFh/K94A+A+3ojupzhy0auE2jfJPG+tXTPAPfad+WhkWzaVK/KPKPOMQeAiB4NE6r0u1g94CPdvl0YmV4f2m7S5y/f1FR72EBrl+3u7mSItG8Fz47yrzuGj19NGw6IDuBk6MMN/qKyt97RfCH6uLZnCcJfaUQUZbieG3J8+ohwIZU0nEYW0rNIFPPUVp/NWWU6uJMf2AAd2kokx7ZGz24xZPAS/EqCvtz93UHUabD0veUmMzSHZaT3bLhLwapZxI7927pCGWT0ZuCMRVqRxu0Ufc24eYhgI7dOZiXlaO295NbxIZk4l0SbhH531p4T1Qd4CnFOG04o9o1kKXpK+v/0p6H01DR4HgMTY2vXLmn3STfmbuYHGZRi/64Yf1VFkp/gSRuxTzlvpaSA3FAZh3fqsxvk3EpELrozjooM7yuE+2mzri3xz56a7IWXav1fdSOmaTySXY8pAfnA0/XUBFjDJGhZoO05XzRuhqNwh4aDfSbc9ptVI9s+hvADVtX+12P7rUxFJLhgJAQ9ths/4XJar5hVUvuovuw/GL7L9eQTwicmdzxRQL9CA5IKCIfYh64eUM6NHjGGFWXBjzEXIGONq7zMdI/MArzpeItFL0nulHC+41xbOafdc3AtEw0poSsMCLMrsSxegoIRvBAoH4y8LwxLEP94=
x-ms-office365-filtering-correlation-id: 1b814ec0-dd7c-44de-3b5f-08d4d464c9d0
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR09MB0921;
x-ms-traffictypediagnostic: CY1PR09MB0921:
x-exchange-antispam-report-test: UriScan:(271806183753584)(131327999870524)(50582790962513)(211936372134217)(100405760836317)(179696456005106)(211171220733660)(68840517438536);
x-microsoft-antispam-prvs: <CY1PR09MB0921E6F8554BCC66E798DE68A8B90@CY1PR09MB0921.namprd09.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(920511095)(920507026)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123555025)(20161123562025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR09MB0921; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR09MB0921;
x-forefront-prvs: 038002787A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(39840400002)(39410400002)(39450400003)(39850400002)(39400400002)(377454003)(13464003)(24454002)(51444003)(189002)(199003)(7736002)(7696004)(305945005)(8936002)(2900100001)(966005)(74316002)(86362001)(72206003)(53546010)(478600001)(34040400001)(6116002)(102836003)(25786009)(105586002)(106356001)(3846002)(14454004)(77096006)(2906002)(229853002)(6436002)(2950100002)(50986999)(3660700001)(81686999)(54356999)(81156014)(3280700002)(54906002)(53936002)(99286003)(6306002)(68736007)(66066001)(8676002)(101416001)(9686003)(5660300001)(6246003)(76176999)(93886004)(38730400002)(6506006)(4326008)(97736004)(55016002)(81166006)(33656002)(189998001)(156664002)(17260700006); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR09MB0921; H:CY1PR09MB0922.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: mitre.org does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2017 20:27:51.2517 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0921
X-OriginatorOrg: mitre.org
X-MITRE: 8GQsMWxq66rxk57w
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/rXZ-kgnX3prWVYV1D19g8_pXFkA>
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 20:27:58 -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:anima-bounces@ietf.org] On Behalf Of Alexander Clemm
Sent: Wednesday, July 26, 2017 4:16 PM
To: Toerless Eckert <tte@cs.fau.de>
Cc: J?ferson Campos Nobre <jcnobre@inf.ufrgs.br>; anima@ietf.org; draft-du-anima-an-intent.authors@ietf.org; Sheng Jiang <jiangsheng@huawei.com>
Subject: Re: [Anima] What is intent ?

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:tte@cs.fau.de]
Sent: Wednesday, July 26, 2017 11:43 AM
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; anima@ietf.org
Subject: Re: [Anima] What is intent ?

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//pub
> s/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.c
> om>
> 
> 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

_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima