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

[Brian E Carpenter]

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

 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.
>>>
>>> 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).
>> ...
>>
>> ___
>> Anima mailing list
>> Anima@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima
>>
> 


AF-ASA-Obj.pdf
Description: Adobe PDF document


AF-ASA-Obj.ppt
Description: MS-Powerpoint presentation
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Joel M. Halpern]

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

On 7/11/16 10:45 AM, Laurent Ciavaglia wrote:

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:

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

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

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.


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

...

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



--

Laurent Ciavaglia

Nokia, Bell Labs



+33 160 402 636

route de Villejust - Nozay, France

linkedin.com/in/laurent.ciavaglia



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

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

[Brian E Carpenter]

Just blending the two response sub-threads:

On 12/07/2016 00:37, Laurent Ciavaglia wrote:
> Hello,
> 
>> 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.
> 
> 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.

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

> 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.).
> 
> Or am I completely overlooking something?

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

Regards
Brian
> 
> Best regards, Laurent.
> 

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

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

[Michael Behringer (mbehring)]

> -Original Message-
> From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Brian E
> Carpenter
> Sent: 09 July 2016 12:39
> To: Laurent Ciavaglia <laurent.ciavag...@nokia-bell-labs.com>; anima
> <anima@ietf.org>
> Subject: Re: [Anima] Fwd: New Version Notification for draft-du-anima-an-
> intent-04.txt
> 
> 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?

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

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

Michael


> 
> Regards
>Brian
> 
> On 09/07/2016 03:45, Laurent Ciavaglia wrote:
> > 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: internet-dra...@ietf.org
> > To: Laurent Ciavaglia <laurent.ciavag...@alcatel-lucent.com>, Jeferson
> Campos Nobre <jcno...@inf.ufrgs.br>, Michael
> > Behringer <mbehr...@cisco.com>, Sheng Jiang
> <jiangsh...@huawei.com>,
> > Zongpeng Du <duzongp...@huawei.com>, Michael H. Behringer
> > <mbehr...@cisco.com>, Laurent Ciavaglia
> > <laurent.ciavag...@alcatel-lucent.com>
> >
> >
> >
> > 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 o

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

[Brian E Carpenter]

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:
> 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: internet-dra...@ietf.org
> To: Laurent Ciavaglia , Jeferson 
> Campos Nobre , Michael
> Behringer , Sheng Jiang , Zongpeng 
> Du , Michael H. Behringer
> , Laurent Ciavaglia 
> 
> 
> 
> 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
> 
> 
> 
> 
> 
> ___
> 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

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

[Laurent Ciavaglia]

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:   internet-dra...@ietf.org
To: 	Laurent Ciavaglia , Jeferson 
Campos Nobre , Michael Behringer 
, Sheng Jiang , Zongpeng Du 
, Michael H. Behringer , 
Laurent Ciavaglia 




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

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