Re: [Anima] Self-Managed Networks

[John Strassner <[e-mail]>]

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]>
wrote:

> 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]
>
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima
>



-- 
regards,
John