Re: [Anima] Self-Managed Networks

[John Strassner <[e-mail]>]

Hi Mehmet,

you lost me. I don't see how your response answers any of the 3 points I
made.

regards,
John

On Sun, Oct 18, 2015 at 8:13 AM, Toy, Mehmet <[e-mail]>
wrote:

> John,
>
> As I mentioned in my previous email, the reference model for Autonomic
> Networking is the model for auto routing and auto-discovery of nodes.
>
> There are FM and PM that can be associated with these functions(i.e. FM an
> d PM for ACP), but there are FM and PM associated with infrastructure. For
> example, FM and PM associated with policing, queuing, hardware redundancy,
> link redundancy (i.e.LAG/LACP), etc.
>
>
>
> I am not sure how we can model non-ACP related FM and PM as part of
> autonomous agents above ACP.
>
>
>
> I feel that Autonomic Networks (Self-Managed Networks) must be defined
> beyond routing and discovery, although it could be OK as an initial scope.
>
> Regards,
>
> Mehmet
>
>
>
> *From:* John Strassner [mailto:[e-mail]]
> *Sent:* Saturday, October 17, 2015 2:58 PM
> *To:* Toy, Mehmet; John Strassner; Toerless Eckert
> *Cc:* Romascanu, Dan (Dan) ([e-mail]); [e-mail];
> [e-mail]; [e-mail]
> *Subject:* Re: [Anima] Self-Managed Networks
>
>
>
> 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
>



-- 
regards,
John