Re: [Anima] Self-Managed Networks

[Brian E Carpenter <[e-mail]>]

On 18/10/2015 14:17, Joel M. Halpern wrote:
> I see two ways to looking at this.
> One way, which is I think what Toerless is suggesting, is that being able to dynamically install ASAs into devices dramatically
> increases the power of the autonomic data plane.

Exactly. The idea is that a programmer who is an expert in topic X should be able
to write an ASA for topic X without needing to know the fine details of either
the ACP or GRASP. That's why I'm spending some of my time on a topic that the IETF
is popularly supposed to avoid: the API that an ASA-writer will use to access
the autonomic infrastructure.

> 
> The converse is that if Anima requires replacement of the OS on all devices in the environment, then I confidently predict
> failure of our effort.

Agreed. ASAs are management entities and should not be needed in every device.

    Brian

> 
> Yours,
> Joel
> 
> On 10/17/15 9:02 PM, Toerless Eckert (eckert) wrote:
>> Of course, being easily in@tallable and uninstallable does not make the
>> majorities of android/ios apps useful, but if ios/android only had
>> preinstalled software and you had to upgrade the os to get other apps -
>> those os would not exist.
>>
>> I dont understand how router vendor os survive without that concept, and
>> if at all possible id like to make  sure we do worry about aspects like
>> these to nmake the autonomic vision operationally successful.
>>
>>
>>
>>
>> Sent from my Samsung Captivate Glide on AT&T
>>
>> John Strassner <[e-mail]> wrote:
>> Hi all,
>>
>> Toerless wrote:
>>
>>  > 1) easily, ideally autonomous downloadable agent/application infra.
>> <jcs>
>> Frankly, I've never thought of that. However, I'm not sure that this is a
>> complete answer. Without specifications that define how the agents
>> and app infrastructure are built, how they communicate, etc., I don't
>> see how this works. So shouldn't the ANIMA WG build those specs?
>>
>> Just because something can be downloaded and deployed doesn't
>> mean it is useful. Remember the disaster that was Active Networks,
>> which set AI in networking back two decades.
>> </jcs>
>>
>> Mehmet wrote:
>>
>> 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.
>> <jcs>
>> You lost me. If it isn't software, then it must be hardware. I like ASICs
>> and FPGAs, but they can't do everything, especially in an adaptive
>> environment. Please elaborate more.
>> </jcs>
>>
>>   ...
>>
>> Mehmet wrote:
>> 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.
>> <jcs>
>> Then how do different autonomic elements find each other and form
>> themselves into a group that can do something useful?
>> </jcs>
>> ...
>>
>> regards,
>> John
>>
>> On Wed, Oct 14, 2015 at 8:02 PM, Toy, Mehmet
>> <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>     Toerless,
>>     Please see below.
>>     Thanks
>>     Mehmet
>>
>>     -----Original Message-----
>>     From: Toerless Eckert [mailto:[e-mail]
>>     <mailto:[e-mail]>]
>>     Sent: Wednesday, October 14, 2015 7:16 PM
>>     To: Toy, Mehmet
>>     Cc: [e-mail]
>>     <mailto:[e-mail]>; [e-mail]
>>     <mailto:[e-mail]>; [e-mail]
>>     <mailto:[e-mail]>; Romascanu, Dan (Dan)
>>     ([e-mail] <mailto:[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] <mailto:[e-mail]>
>>
>>     _______________________________________________
>>     Anima mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/anima
>>
>>
>>
>>
>> -- 
>> regards,
>> John
>>
>>
>> _______________________________________________
>> Anima mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/anima
>>
> 
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima
> .
>