Re: [Anima] Self-Managed Networks

["Joel M. Halpern" <[e-mail]>]

Maybe I phrased my concern in a confusing fashion.
If adding Anima (ASA) capabilities to a device requires a complete 
rewrite of the operating system, that will be a serious impediment to 
deployment.

Adding APIs to existing routers to support Anima capabilities is quite 
achievable.  Adding download capabilities to add software to existing 
network elements has been done, and can be expanded upon.  Defining the 
API seems sensible.  defining the mechanism for installing new software 
components is WAY outside the IETF expertise (although the mechanism to 
communicate the component, and signatures on the component, are things 
well within IETF scope, but probably outside of the charter for Anima.)

The note I was responding to was a claim that we can't add ASAs to 
existing routers unless we replace the OS.  If that is true, I see major 
challenges.  Even white-box packet handlers have OS that in practice are 
pretty similar to those in commercial bridges and routers.

Yours,
Joel

On 10/18/15 3:14 PM, Brian E Carpenter wrote:
> 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
>> .
>>