Re: [Anima] Self-Managed Networks

["Toy, Mehmet" <[e-mail]>]

Toerless,
Please see below.
Thanks
Mehmet

-----Original Message-----
From: Toerless Eckert [mailto:[e-mail]] 
Sent: Wednesday, October 14, 2015 7:16 PM
To: Toy, Mehmet
Cc: [e-mail]; [e-mail]; [e-mail]; Romascanu, Dan (Dan) ([e-mail])
Subject: Re: Self-Managed Networks

Toy:

Unless you feel its more appropriate to keep this discussion in this closed mailing list, i would suggest to have it on the anima mailing list. 

First off: You've compressed really a lot of crucial arch design from your detailed first slidedeck into this a lot more pithy, yet comprehensive first draft. I think my main concern is how we can work on the SW engineering aspects of how to build it and build upon the anima infrastructure.

I think i did ask you some IETFs ago when you presented your slides, that it would be good if we could focus on that aspect.

Eg: Could we add a section to the document outlining a summary of how this framework would leverage and benefit from the the currently planned anima infrastructure - why/ how to use it - so we know the requirements we have, especially if those are any we would need to consider during recharter.
MT: As you can see from my previous email, I am not on board with current architectural definitions.  Once we are sync on the definitions of architectural components, I should make an attempt to address your concerns.

If you'd ask me, primarily as a contributor considering what would best help to make this happen - and move ANIMA forward, i think the key aspects are: 

1) easily, ideally autonomous downloadable agent/application infra.

Eg: I don't see any way that either vendors or operators could realistically build this framework if these components are tied into the classical router OS software delivery model where it takes months to validate a sofftware update and more months to deploy it. If this can be downloaded, as separate apps then its so much easier to incrementally build/deploy it on a totally different deployment process. 

How exactly should this be done so operators like comcast will most likely start incrementally deploying this ?

Eg: I am sure autonomic agents will be the next re-charter item, the functionality you describe for fault-management via such agents is great, and i can see how that is just good work to refine, so i am mostly worred about the sW-engineering and operational aspects of such autonomic agents.

MT: What I propose is unlikely to be done completely just by autonomic agents or software, but can be partially done by autonomic agents.  This is the key reason for these email exchanges.

2) Clear APIs to existing router operations.

We would need to have an idea how these new components would talk to the rest of the router. This seems like an eay "oh, we can have those agents do 30 year old router CLI locally, but we'd prefer Netconf/Yang with IETF standardized models, and we do need the following yang models for the first important FP operations". There is also talk about expanding into Thrift for higher performance data collection (beyond netconf, still with yang).

MT: Agree, but we are far from these steps.  We have to agree on the fundamentals.
3) connectivity between the agents.

This is primarily where at the lowest layer the ACP would come in and it would be great to see argument if/how security, zero-touch build-up and indestructibility are required and/or beneficial for these agents functions.  You already mention the security aspect in your security section. Great. 

Next layer is leveraging GRASP as a protocol for agent-to-agent communication. Is it feasible/beneficial to expect a common new message signaling layer with GRAP ? If so, it would be great to describee why and how. Eg: what communication patterns would your agents have, do the patterns GRASP support suit your agents ?
MT: In general I am not in favor of defining another control layer for this purposes. Therefore, my proposed design  does not need and does not have a protocol for communications.  

Your section 7 already has one specific layer of message communicartions, but it is directly tied to ethernet frame. I'd like to understand this better. I for once would think one would define for the message eleemnts a Yang/CBOR data model "failure management yang model". Then we look how to carry it. agent-to-agent, i would propose to actually run over GRASP (using CBOR representation of course), but to humans behind an NMS its more likely via netconf/yang from an agent into the NMS.
MT: Ethernet frame is just an example. We can collectively decide to have something else. The key point here is to have one message format for all FM related communications.

There may be other aspects, but if this makes sense to you, it would be great if we could get such a section added. Let me know if you need any help with that.
MT: Appreciate the offer. Again we need to sync up on the fundamentals first.

Cheers
    Toerless

On Mon, Oct 05, 2015 at 05:14:19PM +0000, Toy, Mehmet wrote:
> Dear All:
> I couldn't attend the Prague meeting, but luckily Dan was able to present my slides on "Self-Managed Networks with Fault Management Hierarchy".   The feedback was to position the work in the ANIMA WG scope and framework.
> 
> ANIMA charter in "M. Behringer, et. al., A Reference Model for Autonomic Networking
> draft-behringer-anima-reference-model-03" refers to "self-healing".  RFC7575,  "M. Behringer, et al.,   Autonomic Networking: Definitions and Design Goals",  refers to "self-management". However, both documents do not  articulate fault management aspect of the self-management.  It is possible to interpret the fault management aspect of autonomic networks as part of "self-healing" and therefore as part of the ANIMA charter.  In that case, the "Architectural Framework for Self-Managed Networks with Fault Management Hierarchy, draft-mtoy-anima-self-faultmang-framework-00.txt" contribution can target to fill that gap.  The control plane aspect of self-healing is addressed by "M. Behringer, et al., An Autonomic Control Plane, draft-behringer-anima-autonomic-control-plane-03".  I believe these contributions are complementary to each other. I can try to address that in the contribution.
> 
> Please let me know if you agree with me. If not, I suggest to modify the charter since without covering fault management aspect of the autonomic networks, the concept of autonomic network will be incomplete.
> 
> Regards,
> Mehmet
> 
> 

--
---
Toerless Eckert, [e-mail]