Subject: [Anima] Fwd: New Version Notification for draft-du-anima-an-intent-04.txt

From: Laurent Ciavaglia <[email-masked]>
Date: Fri, 8 Jul 2016 17:45:23 +0200

Dear ANIMA WG,

FYI: a new version of the I-D has been posted.

The main update is the addition of a section on Intent Life Cycle based 
on the initial text provided by Michael Behringer 
(https://mailarchive.ietf.org/arch/msg/anima/rk2CgO62nmXFuKOBX-Gtb5v0p5E).
Michael is now also co-author of the I-D.

*We've asked the ANIMA WG chairs for a slot at IETF96/Berlin to present 
the updates on this draft and report on the discussion on Intent and way 
forward.**
**Your comments are thus highly welcome before the meet**ing**.*

Best regards, Laurent.

-------- Forwarded Message --------
Subject: 	New Version Notification for draft-du-anima-an-intent-04.txt
Date: 	Fri, 8 Jul 2016 08:39:49 -0700
From: 	[email-masked]
To: 	Laurent Ciavaglia <[email-masked]>, Jeferson 
Campos Nobre <[email-masked]>, Michael Behringer 
<[email-masked]>, Sheng Jiang <[email-masked]>, Zongpeng Du 
<[email-masked]>, Michael H. Behringer <[email-masked]>, 
Laurent Ciavaglia <[email-masked]>

A new version of I-D, draft-du-anima-an-intent-04.txt
has been successfully submitted by Laurent Ciavaglia and posted to the
IETF repository.

Name:		draft-du-anima-an-intent
Revision:	04
Title:		ANIMA Intent Policy and Format
Document date:	2016-07-08
Group:		Individual Submission
Pages:		13
URL:            https://www.ietf.org/internet-drafts/draft-du-anima-an-intent-04.txt
Status:         https://datatracker.ietf.org/doc/draft-du-anima-an-intent/
Htmlized:       https://tools.ietf.org/html/draft-du-anima-an-intent-04
Diff:           https://www.ietf.org/rfcdiff?url2=draft-du-anima-an-intent-04

Abstract:
    One of the goals of autonomic networking is to simplify the
    management of networks by human operators.  Intent Based Networking
    (IBN) is a possible approach to realize this goal.  With IBN, the
    operator indicates to the network what to do (i.e. her intent) and
    not how to do it.  In the field of Policy Based Management (PBM), the
    concept of intent is called a declarative policy.  This document
    proposes a refinement of the intent concept initially defined in
    [RFC7575] for autonomic networks by providing a more complete
    definition, a life-cycle, some use cases and a tentative format of
    the ANIMA Intent Policy.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

-- 

Laurent Ciavaglia

Nokia, Bell Labs

+33 160 402 636

route de Villejust - Nozay, France

linkedin.com/in/laurent.ciavaglia

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 9 Jul 2016 22:38:35 +1200

Hi,

Thanks for this. One point raises some questions in my mind:

> 5.   Intent splitting (on each node): Intent is split into sections,	
> one for the ANI itself, others for specific Autonomic Functions.	
> ASAs are notified if there is new Intent for them.  Some intent	
> sections may not apply to a particular node.  Now each component	
> of a node (ANI, all ASAs) know their respective Intent.

I am wondering why, in this case, Intent would be broadcasted in
a single operation as a single file. Why wouldn't we simply send out
each section separately?

Also, how is the relevance for each ASA known? And is that the correct
granularity of the section? Maybe the granularity should be individual
objectives, or certain groups of objectives? I think this needs more
discussion.

Regards
   Brian

On 09/07/2016 03:45, Laurent Ciavaglia wrote:
> The main update is the addition of a section on Intent Life Cycle based on the initial text provided by Michael Behringer
> *We've asked the ANIMA WG chairs for a slot at IETF96/Berlin to present the updates on this draft and report on the discussion
> on Intent and way forward.**
> To:     Laurent Ciavaglia <[email-masked]>, Jeferson Campos Nobre <[email-masked]>, Michael
> Behringer <[email-masked]>, Sheng Jiang <[email-masked]>, Zongpeng Du <[email-masked]>, Michael H. Behringer
> <[email-masked]>, Laurent Ciavaglia <[email-masked]>
> 
> 
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 11 Jul 2016 07:22:26 +0000

> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of Brian E
> Carpenter
> Sent: 09 July 2016 12:39
> To: Laurent Ciavaglia <[email-masked]>; anima
> <[email-masked]>
> Subject: Re: [Anima] Fwd: New Version Notification for draft-du-anima-an-
> intent-04.txt
> 
> Hi,
> 
> I am wondering why, in this case, Intent would be broadcasted in a single
> operation as a single file. Why wouldn't we simply send out each section
> separately?

Simplicity. We've discussed many ways of making Intent distribution more granular, optimised, etc. My argument was and is: Let's start simple, and see whether we actually need to make it more granular, optimised, etc. If Intent is really a high level policy, it will change very infrequently, so I think optimisations are not required. Having said this, we should have a "plan b" in case we find later that the simple method isn't good enough. 
 
> Also, how is the relevance for each ASA known? 

My proposal: Intent comes in sections; those sections are labelled with the name of the ASA / autonomic function they belong to. Also here, there are many ways to do this, it's a simple proposal which could be optimised in many ways. 

> And is that the correct

On this one I agree!! We should have more discussions on that. Your point from the other mail, that we should try implementing some ASAs would help understand this better. 

But: I suggest we make things more complicated only if we really can see why the proposed approach wouldn't work. 

Michael

> > The main update is the addition of a section on Intent Life Cycle
> > based on the initial text provided by Michael Behringer
> > *We've asked the ANIMA WG chairs for a slot at IETF96/Berlin to
> > present the updates on this draft and report on the discussion on
> > Intent and way forward.** **Your comments are thus highly welcome
> > before the meet**ing**.*
> >
> > Best regards, Laurent.
> >
> >
> Campos Nobre <[email-masked]>, Michael
> > Behringer <[email-masked]>, Sheng Jiang
> <[email-masked]>,
> > Zongpeng Du <[email-masked]>, Michael H. Behringer
> > A new version of I-D, draft-du-anima-an-intent-04.txt has been
> > successfully submitted by Laurent Ciavaglia and posted to the IETF
> > repository.
> >
> > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >
> >
> >
> >
> >

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Jul 2016 00:15:36 +1200

> Simplicity. We've discussed many ways of making Intent distribution more granular, optimised, etc. My argument was and is: Let's start simple, and see whether we actually need to make it more granu…

I'm all for simplicity. However, it might be that sending the sections separately
would actually be simpler. I think we don't know yet.

> On this one I agree!! We should have more discussions on that. Your point from the other mail, that we should try implementing some ASAs would help understand this better.

Yes. There's been an assumption, I think, that one "autonomic function" == one ASA.
We need to be clear if that is an axiom, and we need to think about how ASAs are
named, and if those names need to be registered somehow.

> But: I suggest we make things more complicated only if we really can see why the proposed approach wouldn't work.

Agreed. As far as I can see, if we naively assume that we use GRASP to distribute Intent,
we can flood Intent as long as it fits in one packet; if that doesn't apply, we can
synchronize it via GRASP/TCP. That seems OK for now. Since Intent is supposed to change
rarely, we don't need to optimise performance.

Regards
    Brian

---

From: Laurent Ciavaglia <[email-masked]>
Date: Mon, 11 Jul 2016 14:37:37 +0200

Hello,

> named, and if those names need to be registered somehow.

Mmmh... where does this assumption come from...?
I think we've been quite clear the general case is one AF == multiple 
ASAs. An AF instantiated by (only) one ASA is a sub-case. Cf. figure 1 
of the Reference model draft.

Why would ASAs need a name? That ASA need an ID is ok, but machines 
don't care about having stuff referenced with names... and I don't think 
human operators will have to deal with ASAs (one of the goals of 
ANetworking), or at least not often enough to justify the use of a 
naming scheme.
AFs could have names (and would actually need more than just name, e.g. 
version number, description of what it does, requires, etc.).

Or am I completely overlooking something?

Best regards, Laurent.

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 11 Jul 2016 12:39:24 +0000

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: 11 July 2016 14:16
> To: Michael Behringer (mbehring) <[email-masked]>; Laurent Ciavaglia
> <[email-masked]>; anima <[email-masked]>
> >> Subject: Re: [Anima] Fwd: New Version Notification for
> >> draft-du-anima-an- intent-04.txt
> >>
> >> Hi,
> >>
> >>> sections may not apply to a particular node.  Now each component of
> >>> a node (ANI, all ASAs) know their respective Intent.
> >>
> >> I am wondering why, in this case, Intent would be broadcasted in a
> >> single operation as a single file. Why wouldn't we simply send out
> >> each section separately?
> >
> > Simplicity. We've discussed many ways of making Intent distribution more
> granular, optimised, etc. My argument was and is: Let's start simple, and see
> whether we actually need to make it more granular, optimised, etc. If Intent
> is really a high level policy, it will change very infrequently, so I think
> optimisations are not required. Having said this, we should have a "plan b" in
> case we find later that the simple method isn't good enough.
> 
> I'm all for simplicity. However, it might be that sending the sections
> separately would actually be simpler. I think we don't know yet.

I doubt that, but let's leave our mind open! :-) 
 
> > My proposal: Intent comes in sections; those sections are labelled with the
> name of the ASA / autonomic function they belong to. Also here, there are
> many ways to do this, it's a simple proposal which could be optimised in many
> ways.
> >
> >> And is that the correct
> >> granularity of the section? Maybe the granularity should be
> >> individual objectives, or certain groups of objectives? I think this
> >> needs more discussion.
> >
> > On this one I agree!! We should have more discussions on that. Your point
> from the other mail, that we should try implementing some ASAs would help
> understand this better.
> 
> We need to be clear if that is an axiom, and we need to think about how
> ASAs are named, and if those names need to be registered somehow.

Yes, that misunderstanding keeps popping up all the time.  I think RFC7575 is quite clear: 

   Autonomic Function: A feature or function that requires no
   configuration and can derive all required information through self-
   knowledge, discovery, or Intent.

   Autonomic Service Agent: An agent implemented on an autonomic node
   that implements an autonomic function, either in part (in the case of
   a distributed function) or whole.

Example: There is the "autonomic function" "bootstrapping of new nodes". It consists of 3 different ASAs: The new_device ASA, the proxy ASA and the registrar ASA. 

How can we make that clearer? (I thought RFC7575 *is* clear).

> Agreed. As far as I can see, if we naively assume that we use GRASP to
> distribute Intent, we can flood Intent as long as it fits in one packet; if that
> doesn't apply, we can synchronize it via GRASP/TCP. That seems OK for now.
> Since Intent is supposed to change rarely, we don't need to optimise
> performance.

Yes, we need to settle on that. As mentioned, I suggest we keep the signalling "there is Intent version x" and the actual transfer strictly separate. That's really an orthogonal observation to yours, but I'd really hope we can settle on that. 

Michael

> >>> URL:            https://www.ietf.org/internet-drafts/draft-du-anima-an-
> intent-
> >> 04.txt

---

From: Laurent Ciavaglia <[email-masked]>
Date: Mon, 11 Jul 2016 14:53:47 +0200

> Example: There is the "autonomic function" "bootstrapping of new nodes". It consists of 3 different ASAs: The new_device ASA, the proxy ASA and the registrar ASA.
Michael: in your example, the agents represent different parts of the AF 
functionality.
There is an additional dimension: an AF can be deployed over multiple 
resources(/devices). An ASA, encompassing the whole AF functionality, 
would then be instantiated on each device. E.g. a load-balancing AF 
deployed over a set of routers (each router will get an ASA of the load 
balancing AF).

> How can we make that clearer? (I thought RFC7575 *is* clear).
I think that progressing on the life-cycle management will describe how 
the different elements (AF, ASA, management functions) interacts and 
when/why/how they are instantiated. This will be presented (again) with 
more details in IETF96/Berlin.
The other discussion thread on the "code" thing is also useful to get a 
better understanding IMO.
finally, the text on ASA in the reference model (or larger side 
document) could be used to augment / improve the text of RFC7575.

Best regards, Laurent.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 11 Jul 2016 08:55:28 -0400

I believe your description, and that of others as to what we "intend", 
does not line up with the definition you quote.

The text says that an ASA "implements an autonomic function."  That 
seems to say that I sould expect an autonomic function to be implemented 
by an ASA, thus implying a 1-1 relationship.

yet, your example states an AF of "bootstrapping", but the funcitonality 
of the ASA being a much smaller piece.

Net: No, the words do not clearly state what we intend.

Yours,
Joel

On 7/11/16 8:39 AM, Michael Behringer (mbehring) wrote:
...
>> name of the ASA / autonomic function they belong to. Also here,
>> there are many ways to do this, it's a simple proposal which could
>> be optimised in many ways.
>>>
>>>> And is that the correct granularity of the section? Maybe the
>>>> granularity should be individual objectives, or certain groups
>>>> of objectives? I think this needs more discussion.
>>>
>> from the other mail, that we should try implementing some ASAs
>> would help understand this better.
>>
>> Yes. There's been an assumption, I think, that one "autonomic
>> function" == one ASA. We need to be clear if that is an axiom, and
>> we need to think about how ASAs are named, and if those names need
>> to be registered somehow.
>
> that implements an autonomic function, either in part (in the case
> of a distributed function) or whole.
>
> Example: There is the "autonomic function" "bootstrapping of new
> nodes". It consists of 3 different ASAs: The new_device ASA, the
> proxy ASA and the registrar ASA.
>
...

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Jul 2016 01:10:52 +1200

Just blending the two response sub-threads:

On 12/07/2016 00:37, Laurent Ciavaglia wrote:
> I think we've been quite clear the general case is one AF == multiple ASAs. An AF instantiated by (only) one ASA is a sub-case.
> Cf. figure 1 of the Reference model draft.

> Michael: in your example, the agents represent different parts of the AF functionality.
> There is an additional dimension: an AF can be deployed over multiple resources(/devices). An ASA, encompassing the whole AF functionality, would then be instantiated on each device. E.g. a load-balancing AF deployed over a set of routers (each router will get an ASA of the load balancing AF).

Right. So an AF can have multiple ASAs in one node, as well as multiple ASAs on
different nodes. And if a section of Intent is aimed at a particular AF, then
the AF needs a name. But the AF is *realised* by a set of ASAs, which must
somehow be associated with the AF's name (otherwise they could not select
the relevant Intent).

> 
> Why would ASAs need a name? That ASA need an ID is ok, but machines don't care about having stuff referenced with names... and I
> don't think human operators will have to deal with ASAs (one of the goals of ANetworking), or at least not often enough to
> justify the use of a naming scheme

Well, I used the word 'name' in a computer science sense ;-). Indeed it could be
a binary number or it could be a string. I don't see any harm in making it a string,
for the sake of debugging convenience (as I have in my prototype) but it isn't
required.

I remind you that we have so far ducked the question of authorization
of ASAs to manage particular objectives.

> AFs could have names (and would actually need more than just name, e.g. version number, description of what it does, requires,
> etc.).
> 

No, I don't think so, and some of this needs to be captured for the Reference Model.

Regards
    Brian

---

From: Laurent Ciavaglia <[email-masked]>
Date: Mon, 11 Jul 2016 16:45:55 +0200

Hello,

There is some text in draft-peloso-anima-autonomic-function-01 
(https://tools.ietf.org/html/draft-peloso-anima-autonomic-function-01) 
detailing what should be considered when installing, instantiating and 
operating AF/ASA.
Please see sections 3+.

Feedback on the text is most welcome as this will be presented at 
IETF96/Berlin.

Best regards, Laurent.

On 11/07/2016 14:55, Joel M. Halpern wrote:
> seems to say that I sould expect an autonomic function to be 
> implemented by an ASA, thus implying a 1-1 relationship.
>
> yet, your example states an AF of "bootstrapping", but the 
> funcitonality of the ASA being a much smaller piece.
>

-- 

Laurent Ciavaglia

Nokia, Bell Labs

+33 160 402 636

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 11 Jul 2016 10:55:57 -0400

Laurent, the text in section 3 of your document is informative.

I am left confused about what are the actual definitions of and 
relationships between an AF (Autonomic Function) and an ASA (Autonomic 
Service Agent)?  The definition Michael pointed at and the conversation 
on the list seem quite different.

Yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Jul 2016 04:29:01 +1200

Is the attached drawing correct? It's supposed to be an Autonomic Function
implemented across three Autonomic Nodes X, Y and Z containing a total of
four ASAs managing two different technical objectives A and B.

(If anyone wants to fire back a corrected version I have attached the PPT
as well as the PDF.)

Regards
   Brian

On 12/07/2016 02:45, Laurent Ciavaglia wrote:
> (https://tools.ietf.org/html/draft-peloso-anima-autonomic-function-01) detailing what should be considered when installing,
> instantiating and operating AF/ASA.
> Please see sections 3+.
> 
> Feedback on the text is most welcome as this will be presented at IETF96/Berlin.
> 
> Best regards, Laurent.
> 
> 
>> I believe your description, and that of others as to what we "intend", does not line up with the definition you quote.
>>
>> The text says that an ASA "implements an autonomic function." That seems to say that I sould expect an autonomic function to
>> be implemented by an ASA, thus implying a 1-1 relationship.
>>
>> yet, your example states an AF of "bootstrapping", but the funcitonality of the ASA being a much smaller piece.
>>

---

From: Laurent Ciavaglia <[email-masked]>
Date: Mon, 11 Jul 2016 23:21:07 +0200

Hi Brian,

The drawing is interesting...

Some questions/remarks come to mind:
-Could an ASA handle both objectives (A,B)?
-Could ASAs be of different implementations, or from different vendors?
-What are the possible options
     . for intra-AF-inter-node-ASAs communication? 
(developer's/operator's choice, GRASP, other options?)
     . for intra-AF-intra-node-ASAs communication? 
(developer's/operator's choice, GRASP, node OS bus/protocols, other 
options?)
-Although I think it is a possible model, why having ASA1 and ASA2 on 
node X? I mean what is the criteria that decides if an AF is 
instantiated by one or multiple ASAs on a given node?
-Are ASA1 and ASA2 managing different resources on node X? In case they 
are, what does it mean to "attach" them to node X (instead of the set of 
resources they manage)?
-Could ASAs have a hierarchy?
-A case to add is one ASA managing a remote node (the ASA is installed 
on an "installation host").
-A case to add is one ASA managing multiple nodes.
-Do we have examples of AFs that can illustrate the (variations in the) 
diagram? (secure bootstrap seems like a workable case...)
-Constraints in the deployment/instantiation should be captured at some 
point, i.e. matching between the ASA capabilities (e.g. what types of 
resources it can control,
    what types of hosts it can be installed on...), the installation 
hosts capabilities (e.g. support dynamic installation, location and 
reachability...) and the operator's needs (what deployment schemes are 
favored, functionality coverage vs. cost trade-off...).

Sections 3 and 4 of draft-peloso-anima-autonomic-function-01 provides 
explanations on some of the above questions/remarks.
Section 2.2 describes a series of variations in line (but broader / mode 
detailed) with "Brian's" drawing.

HTH, best regards, Laurent.

-- 

Laurent Ciavaglia

Nokia, Bell Labs

+33 160 402 636

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Jul 2016 18:45:23 +1200

Hi Laurent,

> The drawing is interesting...

It was intended to provoke questions and I see that it succeeded ;-)
> -Could an ASA handle both objectives (A,B)?

Yes, I see no reasons why not.

> -Could ASAs be of different implementations, or from different vendors?

I think so, if the Objectives have open specifications.

>     . for intra-AF-inter-node-ASAs communication? (developer's/operator's choice, GRASP, other options?)

I hope we would RECOMMEND to use GRASP, but is clearly not the only option.

>     . for intra-AF-intra-node-ASAs communication? (developer's/operator's choice, GRASP, node OS bus/protocols, other options?)

Again GRASP would work, and if the ASAs are independently developed, it would
seem to be the natural choice.

> -Although I think it is a possible model, why having ASA1 and ASA2 on node X? I mean what is the criteria that decides if an AF
> is instantiated by one or multiple ASAs on a given node?

I tend to agree that a single ASA would be more natural, but IMHO we should allow
flexibility.

> -Are ASA1 and ASA2 managing different resources on node X? In case they are, what does it mean to "attach" them to node X
> (instead of the set of resources they manage)?

I think the answer to that is hidden in the definition of the Objectives. If I take the
prefix management use case, there is a local pool of IPv6 prefixes which definitely
belong to the node and can be allocated to users by the node. But if the node runs
short of prefixes, the ASA will have to negotiate with its peer in another node
to increase its pool. So two fundamentally identical ASAs in two nodes, but each
with its own resource pool.

> -Could ASAs have a hierarchy?

I think the answer to that is in the semantics of the AF, not a question of principle.

> -A case to add is one ASA managing a remote node (the ASA is installed on an "installation host").

Right, but then the remote node is *not* an autonomic node; it's a slave.

> -A case to add is one ASA managing multiple nodes.

...multiple slaves.

> -Do we have examples of AFs that can illustrate the (variations in the) diagram? (secure bootstrap seems like a workable case...)

I think bootstrap is one, and for some aspects, prefix management.

> -Constraints in the deployment/instantiation should be captured at some point, i.e. matching between the ASA capabilities (e.g.
> what types of resources it can control,
>    what types of hosts it can be installed on...), the installation hosts capabilities (e.g. support dynamic installation,
> location and reachability...) and the operator's needs (what deployment schemes are favored, functionality coverage vs. cost
> trade-off...).
> 
> Sections 3 and 4 of draft-peloso-anima-autonomic-function-01 provides explanations on some of the above questions/remarks.
> Section 2.2 describes a series of variations in line (but broader / mode detailed) with "Brian's" drawing.

Yes. It was only an illustration that I started for my own understanding.

Thanks
    Brian