Subject: Re: [Anima] Confirmation of consensus to adopt draft-behringer-anima-reference-model as ANIMA WG document, ends December 13, 2015,

From: "Toy, Mehmet" <[email-masked]>
Date: Tue, 1 Dec 2015 14:37:59 +0000

Given the definition of ANI in the document, I am still struggling how to address FM  functions  in draft-mtoy-anima-self-faultmang-framework-00.txt<https://tools.ietf.org/html/draft-mtoy-anima-self-faultmang-framework-00.txt>  as ASA functions on top of ANI. How do we do this?  Can we simply modify ANI definition to include HW redundancy and self-diagnostics of each component, and availability of infrastructure level measurements so that we can address the remaining FM and PM functionalities with ASAs?
Thanks
Mehmet

Autonomic Networking Infrastructure                        |
   |    - Data structures (ex: certificates, peer information)  |
   |    - Autonomic Control Plane                               |
   |    - Autonomic Node Addressing                             |
   |    - Discovery, negotiation and synchronisation functions  |
   |    - Intent distribution                                   |
   |    - Aggregated reporting and feedback loops               |
   |    - Routing

From: Liubing (Leo) [mailto:[email-masked]]
Sent: Monday, November 30, 2015 10:09 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Anima] Confirmation of consensus to adopt draft-behringer-anima-reference-model as ANIMA WG document, ends December 13, 2015,

Hi Dear all,

I believe this is a must to have document to describe the technologies in a whole picture. So I support the adoption (as a co-author).

Best regards,
Bing

From: Anima [mailto:[email-masked]] On Behalf Of Jéferson Campos Nobre
Sent: Tuesday, December 01, 2015 12:12 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Anima] Confirmation of consensus to adopt draft-behringer-anima-reference-model as ANIMA WG document, ends December 13, 2015,

I am a co-author and I support the adoption of this draft.
Cheers.
Jéferson
Em seg, 30 de nov de 2015 às 02:06, Joel M. Halpern <[email-masked]<mailto:[email-masked]>> escreveu:
I strongly support adoption by the working group of this document.  It
is provides a very necessary reference for our work, and is a good
sstart on what we need for that.

Yours,
Joel M. Halpern

On 11/29/15 9:03 PM, Sheng Jiang wrote:
> There was clear consensus for adopting draft-behringer-anima-reference-model as a
> ANIMA working group document in the IETF 94 ANIMA WG meeting, Yokohama.
> This message starts a two-week call on confirming the consensus from the WG meeting.
>
>    Title:      A Reference Model for Autonomic Networking
>    Authors :   Carpenter, et al.
>    Filename:  draft-behringer-anima-reference-model-04
>
>    https://tools.ietf.org/html/draft-behringer-anima-reference-model-04
>
> Please express your support or rejection. If you think this document should _not_ be
> adopted, please also explicitly indicate the reasons.
>
> This adoption call will end on December 13, 2015.
>
> Regards,
>
> Sheng + Toerless
> _______________________________________________
> Anima mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/anima
>

_______________________________________________
Anima mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/anima

---

From: Laurent Ciavaglia <[email-masked]>
Date: Wed, 2 Dec 2015 10:24:15 +0100

Hello,

I am a co-author of this draft and I support its adoption as WG document.
The document has matured and the structure is quite stable.
It provides the necessary framework to illustrate how the current and 
future components of ANIMA fits together and thus provides a useful 
internal and external reference.
I share Brian's comment that the document should remain "open".

Best regards, Laurent.

On 30/11/2015 19:07, John Strassner wrote:
> I also strongly support adoption by the working group of this 
> document. I am planning to review and add to it. Note: I am a co-author.
>
> regards,
> John
>
> On Sun, Nov 29, 2015 at 8:06 PM, Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I strongly support adoption by the working group of this
>     document.  It is provides a very necessary reference for our work,
>     and is a good sstart on what we need for that.
>
>     Yours,
>     Joel M. Halpern
>
>         There was clear consensus for adopting
>         draft-behringer-anima-reference-model as a
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
> -- 
> regards,
> John
> [email-masked]

-- 

Bien cordialement, Best regards,

*Laurent Ciavaglia*

Secure Cloud Networking

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

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Wed, 2 Dec 2015 16:03:59 +0000

I support the adoption of this document. 

- max

> On Nov 29, 2015, at 7:03 PM, Sheng Jiang <[email-masked]> wrote:
>

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 14 Dec 2015 15:21:37 +0000

Mehmet,

Sorry for the delay, I’m currently heavily under water from my day job...

I see the FM functions as logically on top of the ANI. The ANI is really the bare infrastructure, very simple and basic. FM needs to cover hardware faults, but also faults of the ANI and service faults.

As long as fault management is local to a network element, the ANI may not even be required at all. For any information, messageing, etc with an NMS system, the ANI should be the default mechanism. So the messaging you talk about

The intelligent agent (your picture 4) resides on top of the ANI, in my view. If it needs to communicate off-box, it should use the ANI, if available.

My overall concern is that we keep the ANI as simple as possible, focus on the most basic operations only, so that it is maximum robust. Since RM functions could become quite elaborate, I’d like them to be on top of the ANI. Also, a fallback to the data plane is desirable in my opinion, in which case it doesn’t even make sense to have the FM function inside the ANI.

Now, the ANI may not be available for a number of reasons either, in which case we can fall back to the data plane, or a physical DCN.

So, I have really two main comments on your draft for now:

-          Anything purely local on a node is outside scope for our work, in my opinion. ANI is about inter-node transactions. Of course an autonomic domain certificate may be used locally, but how it gets there is a function of the ANI. So I would focus more on the transactions in ANIMA.

-          All transactions in FM should be by default in the ACP, thus are logically “on top” of the ANI. To a FM function, the ANI is an underlying layer of networking.

Thoughts?
Michael

From: Anima [mailto:[email-masked]] On Behalf Of Toy, Mehmet
Sent: 01 December 2015 15:38
To: Liubing (Leo) <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Anima] Confirmation of consensus to adopt draft-behringer-anima-reference-model as ANIMA WG document, ends December 13, 2015,

Hi Dear all,

Best regards,
Bing

Yours,
Joel M. Halpern

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Dec 2015 08:17:12 +1300

Michael,

> I see the FM functions as logically on top of the ANI. The ANI is really the bare infrastructure, very simple and basic. FM needs to cover hardware faults, but also faults of the ANI and service fa…

I fully agree with that, except to note that if there is a fault in the ANI,
fault management cannot use the ANI. So I think the ANI really needs to be
flawlessly self-repairing.

However, I do have a somewhat philosophical question for Mehmet. I would
expect each subsystem to take care of its own fault management in an AN,
and I would expect the design of fault management itself to be as distributed
as possible. Isn't that what Paul Baran told us to do in 1962, and the reason
that TCP/IP succeeded in the first place? Integrated *reporting* of fault
management is clearly desirable, but the actual work of managing a fault should
be performed as close to the site of the fault as possible, shouldn't it?

That argues for every autonomic service agent handling fault management for
its own function, e.g. taking over for its own peers if they fail.

Regards
   Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 15 Dec 2015 09:18:22 +0000

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: 14 December 2015 19:17
> To: Michael Behringer (mbehring) <[email-masked]>; Toy, Mehmet
> <[email-masked]>; [email-masked]
> Subject: Re: [Anima] Confirmation of consensus to adopt draft-behringer-
> anima-reference-model as ANIMA WG document, ends December 13, 2015,
> 
> Michael,
> 
> > I see the FM functions as logically on top of the ANI. The ANI is really the
> bare infrastructure, very simple and basic. FM needs to cover hardware
> faults, but also faults of the ANI and service faults.
> 
> I fully agree with that, except to note that if there is a fault in the ANI, fault
> management cannot use the ANI. So I think the ANI really needs to be

That is absolutely correct. In my view, the ANI must be as simple as possible, to be as robust as possible. Anything "intelligent" shouldn't be part of the ANI. Fault management can get quite complex, so we want that complexity in a layer above the ANI. But yes, absolutely, that means the ANI must be self-healing, self-optimising, in short: autonomic!

> management is clearly desirable, but the actual work of managing a fault
> should be performed as close to the site of the fault as possible, shouldn't it?
> 
> That argues for every autonomic service agent handling fault management
> for its own function, e.g. taking over for its own peers if they fail.

I completely share your views. 
Michael

---

From: "Toy, Mehmet" <[email-masked]>
Date: Wed, 16 Dec 2015 03:23:58 +0000

Michael,
Thanks for the reply.
Due to the same reasons, I am replying late!  Sorry…

Please see below.
Mehmet

From: Michael Behringer (mbehring) [mailto:[email-masked]]
Sent: Monday, December 14, 2015 10:22 AM
To: Toy, Mehmet <[email-masked]>; Liubing (Leo) <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: [Anima] Confirmation of consensus to adopt draft-behringer-anima-reference-model as ANIMA WG document, ends December 13, 2015,

Mehmet,

MT: This is the problem that I am pointing out. The way as ANI defined, we cannot express all FM on top of ANI.
Here is the ANI definition
| Autonomic Networking Infrastructure                        |
   |    - Data structures (ex: certificates, peer information)  |
   |    - Autonomic Control Plane                               |
   |    - Autonomic Node Addressing                             |
   |    - Discovery, negotiation and synchronisation functions  |
   |    - Intent distribution                                   |
   |    - Aggregated reporting and feedback loops               |
   |    - Routing

With this definition, how do we express redundant hardware for protection (as part of fault management) with Intelligent Agents?
How do we express hardware requiring traffic management and PM capabilities with Intelligent agents?  These are all infrastructure components.

-          Anything purely local on a node is outside scope for our work,

MT: Let’s have a proper architectural definitions  first and then we can say this is not covered. The  future work will be  based on this architecture.

in my opinion. ANI is about inter-node transactions. Of course an autonomic domain certificate may be used locally, but how it gets there is a function of the ANI. So I would focus more on the transactions in ANIMA.

-          All transactions in FM should be by default in the ACP, thus are logically “on top” of the ANI. To a FM function, the ANI is an underlying layer of networking.
MT:  This is simply not possible with existing definitions.

Thoughts?
Michael

To: Liubing (Leo) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Hi Dear all,

Best regards,
Bing

Yours,
Joel M. Halpern

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 17 Dec 2015 22:28:57 +0000

I’m consciously posting not inline any more, it’s getting a bit messy.

You write: “The way as ANI defined, we cannot express all FM on top of ANI.”

I don’t see why not, and think there must be some misunderstanding between us. An FM agent runs on a device. This agent does two jobs:

1)      it monitors and manages the local node. This part has nothing to do with the ANI. It runs the same way as today.

2)      It talks to a controller and other nodes for specific fault management interactions. These are all interactions about the state of the node, negotiations, etc. And those interactions are on top of the ANI, in other words, would use the ACP, GRASP for messaging, etc. So how you represent redundant hardware is entirely up to that FM agent. The ANI just passes the messages.

I’m not a FM specialist at all, so please educate me where I’m going wrong above, and what we cannot do in this way?

Michael

From: Toy, Mehmet [mailto:[email-masked]]
Sent: 16 December 2015 04:24
To: Michael Behringer (mbehring) <[email-masked]>; Liubing (Leo) <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: [Anima] Confirmation of consensus to adopt draft-behringer-anima-reference-model as ANIMA WG document, ends December 13, 2015,

Michael,
Thanks for the reply.

Please see below.
Mehmet

To: Toy, Mehmet <[email-masked]<mailto:[email-masked]>>; Liubing (Leo) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Mehmet,

Thoughts?
Michael

Hi Dear all,

Best regards,
Bing

Yours,
Joel M. Halpern