Subject: [Anima] ANIMA status

From: Benoit Claise <[email-masked]>
Date: Thu, 11 Sep 2014 12:37:53 +0200

Dear all,

Sorry for the delay in providing guidance. Back to normal operation mode 
(from vacation), I'll be more responsive from now on.
I've been reviewing the entire email archive, and Joel & I discussed the 
ANIMA status yesterday, based on the charter v8.

A few observations, to start with:
1. Autonomic Networking could be a huge explanatory field.
2. From the BoF, we heard (among other points):
     There is interest but focus ... focus ... focus on things that 
could be done quickly
3. The IESG has also been realizing that the process of problem 
statement/use cases/requirements/architecture/protocol takes way too 
long for the industry.
4. If a great architecture document to rule all autonomic functions 
would have been easy, it would been done already. In NMRG for example, 
which had plenty of time to think about it! So an architecture as a 
starting point is not the right approach.
5. A WG can always be re-chartered in future phases

These are the reasons why Joel and I asked the BoF chairs to lead a 
charter discussion, focusing on only 2 use cases.
In the mean time, the charter moved in the direction of developing 
reusable infrastructure components for distributed autonomic networking 
functions plus 2 uses case to demonstrate the usage of those 
infrastructure components. Even better.

Regarding the "architecture" (see point 4 above), we like the phrasing of:

    It is essential that these components and solutions fit together as
    an integrated whole.
    For this reason, an overview document will be developed in parallel
    with the individual
    specifications.

Coming back to the number of use cases and the sentence "A second simple 
example may be added by agreement with the Area Director", we believe 
that the second use case is in the charter already, but somehow hidden. 
We read that "Autonomic Control Plane" and/or "bootstrap a trust 
infrastructure" (not sure about the second one though) are at the same 
time reusable component and a use case. Can you please describe your use 
case in a bullet point, next to "Definition of solution for IPv6 prefix 
management within a network"
Also, wrt "Definition of solution for IPv6 prefix management within a 
network", can you please describe the use case some more. This is a 
little bit too high level.

Looking at the charter v9 now.
Regarding the starting points mentioning the draft names, I actually 
believe that pointing to existing work is a plus, to see some 
description behind a single bullet point. Let's imagine that you read 
"Definition of a solution for a separated Autonomic Control Plane" for 
the first time (this is what will happen when/if this charter is 
proposed for last-call), I'm sure that would lead to many questions or 
potential wrong assumptions.
Note, however, that mentioning starting points doesn't imply that we ask 
you to adopt those document as WG items now.

One final edit. From the email discussion, I read that one of the AN 
goal is OPEX reduction. That's maybe an obvious but a key message to 
mention in the charter. In the problem statement paragraph, this could 
introduce in the last sentence.

Regards, Benoit (OPS AD)

---

From: Laurent Ciavaglia <[email-masked]>
Date: Thu, 11 Sep 2014 21:15:50 +0200

Dear Benoit, all,

Thanks for your feedback.

One point puzzles me: why go through the whole process of a working 
group to specify 2 protocols the quickest way possible? Why not just 
submit the work as AD-sponsored or independent submissions?
I am being a bit provocative here ;) don't get me wrong I am supportive 
of the initiative.
At the UCAN BoF, we got support to form a group on AN. Has the group 
shown support for the 2 use cases / protocols mentioned?

"There is interest but focus ... focus ... focus on things that could be 
done quickly".
It should be quick _*and*_ right, i.e. more emphasis and speed in 
developing the right set of functionality (operators' expectations) 
instead of point-solution protocols (necessary but not ultimate goal).

To my view, the group should start with focus on 1-2 functionalities 
(and not protocols).

In your other email, you consider charter-09 as the stable version. I 
have produced version -10 which combines the main charter contributions 
and comments so far, in the spirit of creating a larger basis for this 
working group and highlighting the implications of the different 
approaches presented (i.e. protocol driven vs. functionality driven). 
Did you had time to consider it?

Thanks, best regards, Laurent.

On 11/09/2014 12:37, Benoit Claise wrote:
> Dear all,
>
> Sorry for the delay in providing guidance. Back to normal operation 
> mode (from vacation), I'll be more responsive from now on.
> I've been reviewing the entire email archive, and Joel & I discussed 
> the ANIMA status yesterday, based on the charter v8.
>
> reusable infrastructure components for distributed autonomic 
> networking functions plus 2 uses case to demonstrate the usage of 
> those infrastructure components. Even better.
>
>     It is essential that these components and solutions fit together
>     as an integrated whole.
>     For this reason, an overview document will be developed in
>     parallel with the individual
>     specifications.
>
>
> Coming back to the number of use cases and the sentence "A second 
> simple example may be added by agreement with the Area Director", we 
> believe that the second use case is in the charter already, but 
> somehow hidden. We read that "Autonomic Control Plane" and/or 
> "bootstrap a trust infrastructure" (not sure about the second one 
> though) are at the same time reusable component and a use case. Can 
> you please describe your use case in a bullet point, next to 
> "Definition of solution for IPv6 prefix management within a network"
> Note, however, that mentioning starting points doesn't imply that we 
> ask you to adopt those document as WG items now.
>
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

-- 

Bien cordialement, Best regards,

*Laurent Ciavaglia*

Advanced Internet Research

Bell Labs | Alcatel Lucent

phone: +33 160 402 636

email: [email-masked] 
<mailto:[email-masked]>

linkedin: laurentciavaglia <http://fr.linkedin.com/in/laurentciavaglia/>

address: Route de Villejust | 91620 Nozay | France

  * English - detected
  * English
  * French

  * English
  * French

<javascript:void(0);>
2

---

From: Benoit Claise <[email-masked]>
Date: Fri, 12 Sep 2014 17:21:40 +0200

Dear Laurent,

> I am being a bit provocative here ;) don't get me wrong I am 
> supportive of the initiative.
> "There is interest but focus ... focus ... focus on things that could 
> be done quickly".
There is definitively some values in AN and we (Joel and I) see it.
On the other hand, NMRTG had plenty of time to dedicate to AN, and the 
progresses there have been slow (there is no points to delve into the 
reasons on this mailing list, but that's a fact). So we took the 
approach to have a reduced charter. Note that we wrote "focus on things 
that could be done quickly", and not the "focus on things that could be 
done the quickest way possible".
 From day one, we said "two use cases", and we gave freedom to the 
community to select which ones. I understand that the two use cases in 
the charter have running code: that also helps.
I'm hoping that this WG will be successful, and that plenty of charter 
updates will follow, but I have to make sure that the WG has a 
reasonable probability of having success.
> To my view, the group should start with focus on 1-2 functionalities 
functionality isn't equal to use case?
> have produced version -10 which combines the main charter 
> contributions and comments so far, in the spirit of creating a larger 
> basis for this working group and highlighting the implications of the 
> different approaches presented (i.e. protocol driven vs. functionality 
> driven). 
The issue is that it's a complete rewrite of the 9 previous iterations.

> Did you had time to consider it?
Yes, and I don't believe that the described "main goals of the ANIMA WG" 
are the right ones.
And the dual approach of bottom-up and top-down will not work IMO.
However, during a call this morning, Michael propose to use 2 paragraphs 
from your charter proposal.
Let me post it shortly.

Regards, Benoit
>> would have been easy, it would been done already. In NMRG for 
>> example, which had plenty of time to think about it! So an 
>> architecture as a starting point is not the right approach.
>> "Definition of a solution for a separated Autonomic Control Plane" 
>> for the first time (this is what will happen when/if this charter is 
>> proposed for last-call), I'm sure that would lead to many questions 
>> or potential wrong assumptions.
>> mention in the charter. In the problem statement paragraph, this 
>> could introduce in the last sentence.
>>
>> Regards, Benoit (OPS AD)
>>
>>
>>

---

From: Laurent Ciavaglia <[email-masked]>
Date: Mon, 15 Sep 2014 12:44:03 +0200

Dear Benoit, all,

Please see below in-line for my replies.

Thanks, Laurent.

On 12/09/2014 17:21, Benoit Claise wrote:
> approach to have a reduced charter. Note that we wrote "focus on 
> things that could be done quickly", and not the "focus on things that 
> could be done the quickest way possible".
> community to select which ones.

Early in the charter drafting process, issues have been raised on the 
"selection" of use cases, and on the term "use case" itself.
An alternative is proposed to possibly avoid these issues by: having (at 
least) 2 functionalities. The (n) use cases would serve to define the 
boundaries / problems these functionalities have to solve (and ensure in 
return a certain level of re-usability among use cases).

> I understand that the two use cases in the charter have running code: 
> that also helps.

As presented in IETF86, IETF88 and IETF 89: running codes exist for the 
risk-aware routing use case, and for the unified management framework 
(or ACP).
Is it proving something?

> functionality isn't equal to use case?

Depends on the definition(s)... ;)
Functionalities are the common components we are trying to define.
A use case may need several functionalities to solve its problem(s), but 
the goal is to have m (functionality) < or << to n (use cases).

>> different approaches presented (i.e. protocol driven vs. 
>> functionality driven). 

As explained, it is a tentative to capture the different viewpoints 
towards a common direction. It certainly led to rewrite/reorganize the 
document, yet several parts are from the previous versions.

> Yes, and I don't believe that the described "main goals of the ANIMA 
> WG" are the right ones.

Could you develop? (e.g. on which basis...)

Goal n°2 is expressed similarly in charter v-09 (" /The _main goal_ of 
the ANIMA WG is therefore to _develop common infrastructure components_ 
for distributed functions./ "), and in several emails on the list.

You also wrote: "/the charter moved in the direction of _developing 
reusable infrastructure components for distributed autonomic networking 
functions_ plus 2 uses case to demonstrate the usage of those 
infrastructure components. Even better./"

> And the dual approach of bottom-up and top-down will not work IMO.
I also think/said the hybridation may not be the right/best choice; even 
more, I think themethodologyissue is misleading.
What I would like this WG to deliver a set of protocols:
     -that are applicable to as many use case as possible.
     -that have the ability to cope / apply to new use cases without 
major extensions / re-design (i.e. profiling might be a good way).
     -that are not generic to the point of being inapplicable (i.e. 
useless).

> However, during a call this morning, Michael propose to use 2 
> paragraphs from your charter proposal.
> Let me post it shortly.

Thanks, appreciated.

>>> Also, wrt "Definition of solution for IPv6 prefix management within 
>>> a network", can you please describe the use case some more. This is 
>>> a little bit too high level.
>>>
>>> description behind a single bullet point. Let's imagine that you 
>>> read "Definition of a solution for a separated Autonomic Control 
>>> Plane" for the first time (this is what will happen when/if this 
>>> charter is proposed for last-call), I'm sure that would lead to many 
>>> questions or potential wrong assumptions.

-- 

*Laurent Ciavaglia*

phone: +33 160 402 636