Subject: Re: [Anima] Self-Managed Networks

From: "Toy, Mehmet" <[email-masked]>
Date: Thu, 15 Oct 2015 03:02:04 +0000

Toerless,
Please see below.
Thanks
Mehmet

-----Original Message-----
From: Toerless Eckert [mailto:[email-masked]] 
Sent: Wednesday, October 14, 2015 7:16 PM
To: Toy, Mehmet
Cc: [email-masked]; [email-masked]; [email-masked]; Romascanu, Dan (Dan) ([email-masked])
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, [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Oct 2015 11:57:37 +1300

> 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.

Anima has decided to run over a secure layer 3 by default (i.e. the ACP). And our plan
is to have a globally applicable signaling protocol (i.e. GRASP). Of course, if GRASP
isn't suitable for a given use case, we would have two alternatives
1. Extend GRASP, which is relatively easy thanks to CBOR;
2. Use something else, which has its own complications.

GRASP can carry any format, YANG if you like, but whether you can model
any particular use case is of course TBD.
Please review https://tools.ietf.org/html/draft-ietf-anima-grasp

Regards
   Brian Carpenter

---

From: "Toy, Mehmet" <[email-masked]>
Date: Fri, 16 Oct 2015 04:17:20 +0000

Brian,
I would have no objection using GRASP (or extended GRASP) for FM communications as long as we can support the network types that we want. I understand that ANIMA is considering only L3 networks.
I wish we can generalize our approach so that we can cover both L2 and L3.  Despite of my Ethernet example, my approach is applicable to L2 and L3 networks.

Regards,,
Mehmet

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Thursday, October 15, 2015 6:58 PM
To: Toy, Mehmet; Toerless Eckert
Cc: [email-masked]; [email-masked]; Romascanu, Dan (Dan) ([email-masked]); [email-masked]
Subject: Re: Self-Managed Networks

> 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.

Anima has decided to run over a secure layer 3 by default (i.e. the ACP). And our plan is to have a globally applicable signaling protocol (i.e. GRASP). Of course, if GRASP isn't suitable for a given use case, we would have two alternatives 1. Extend GRASP, which is relatively easy thanks to CBOR; 2. Use something else, which has its own complications.

GRASP can carry any format, YANG if you like, but whether you can model any particular use case is of course TBD.
Please review https://tools.ietf.org/html/draft-ietf-anima-grasp

Regards
   Brian Carpenter

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Oct 2015 18:40:09 +1300

Mehmet,

ANIMA communication is over a secure L3*, which is exactly the reason that the ACP
is defined as it is. But of course the targets of a use case could be at any level of the
stack.

*except for discovery messages, which cannot always be secure.

Also of course we cannot claim that GRASP is the solution to all problems.
For example, I recently reviewed draft-ietf-pwe3-iccp-stp. There's no
reason we would use GRASP to solve the fault-management problem that's
already solved by ICCP and the 802 spanning tree.

Regards
   Brian Carpenter

---

From: John Strassner <[email-masked]>
Date: Sat, 17 Oct 2015 11:58:13 -0700

Hi all,

> 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 <[email-masked]>
wrote:

> Cc: [email-masked]; [email-masked];
> [email-masked]; Romascanu, Dan (Dan) ([email-masked])
> 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:
>
> 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.
>
> 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.
>
> 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).
>
> 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.
> > 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.
> >
> > 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
> >
> >
>
> --
> ---
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

-- 
regards,
John

---

From: "Toerless Eckert (eckert)" <[email-masked]>
Date: Sun, 18 Oct 2015 01:02:48 +0000

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 <[email-masked]> wrote:
Hi all,

<jcs>

Mehmet wrote:

 ...

Mehmet wrote:

regards,
John

On Wed, Oct 14, 2015 at 8:02 PM, Toy, Mehmet <[email-masked]<mailto:[email-masked]>> wrote:
Toerless,
Please see below.
Thanks
Mehmet

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

Toy:

Cheers
    Toerless

--
---
Toerless Eckert, [email-masked]<mailto:[email-masked]>

_______________________________________________
Anima mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/anima

--
regards,
John

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 17 Oct 2015 21:17:59 -0400

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.

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.

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.
>
>
>
>
> agents or software, but can be partially done by autonomic agents.  This
> is the key reason for these email exchanges.
> <jcs>
> On Wed, Oct 14, 2015 at 8:02 PM, Toy, Mehmet
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Toerless,
>     Please see below.
>     Thanks
>     Mehmet
>
>     Cc: [email-masked]
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>; Romascanu, Dan (Dan)
>     ([email-masked] <mailto:[email-masked]>)
>     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:
>
>     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 ?
>
>     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.
>
>     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).
>
>     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.
>
>     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.
>     Hierarchy".   The feedback was to position the work in the ANIMA WG
>     scope and framework.
>      >
>      > 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, [email-masked] <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>

---

From: "Toy, Mehmet" <[email-masked]>
Date: Sun, 18 Oct 2015 15:13:18 +0000

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:[email-masked]]
Sent: Saturday, October 17, 2015 2:58 PM
To: Toy, Mehmet; John Strassner; Toerless Eckert
Cc: Romascanu, Dan (Dan) ([email-masked]); [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Anima] Self-Managed Networks

Hi all,

<jcs>

Mehmet wrote:

 ...

Mehmet wrote:

regards,
John

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

Toy:

Cheers
    Toerless

--
regards,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 19 Oct 2015 08:14:34 +1300

On 18/10/2015 14:17, Joel M. Halpern wrote:
> 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

> .

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 18 Oct 2015 15:27:53 -0400

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

---

From: John Strassner <[email-masked]>
Date: Sun, 18 Oct 2015 15:23:56 -0700

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 <[email-masked]>
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 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:[email-masked]]
> *Sent:* Saturday, October 17, 2015 2:58 PM
> *To:* Toy, Mehmet; John Strassner; Toerless Eckert
> *Cc:* Romascanu, Dan (Dan) ([email-masked]); [email-masked];
> [email-masked]; [email-masked]
> *Subject:* Re: [Anima] Self-Managed Networks
>
>
>
> Hi all,
>
>
>
> Toerless wrote:
>
>
>

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Sun, 18 Oct 2015 15:37:10 -0700

Hi Joel and Toerless,

I think I now understand what Toerless was getting at. Clearly, the current
way of building big device OSs (e.g., for routers and switches) won't
continue to be successful. I strongly agree that ASAs MUST be able to be
dynamically installed without adversely affecting the environment.

The reason I talked about specifications and Active Networks was to plant
the seed early in the ANIMA WG that such things WILL FAIL unless we
provide a well-defined framework to develop those ASAs, as well as to
enable them to communicate with each other and with non-autonomic
entities.

I don't really care where we start (though I hope we can reuse past work
from FIPA, IFIP, etc.), but without defining such a framework, I don't see
how we will succeed.

Finally, I agree with Joel - we MUST NOT require OS replacement in order
for ANIMA to work.

regards,
John

On Sat, Oct 17, 2015 at 6:17 PM, Joel M. Halpern <[email-masked]>
wrote:

> 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.
>

-- 
regards,
John