Re: [Anima] Self-Managed Networks

"Toy, Mehmet" <Mehmet_Toy@cable.comcast.com> Thu, 15 October 2015 02:26 UTC

Return-Path: <Mehmet_Toy@cable.comcast.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B151B2F06 for <anima@ietfa.amsl.com>; Wed, 14 Oct 2015 19:26:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.225
X-Spam-Level:
X-Spam-Status: No, score=0.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qO2FVXg8qwYz for <anima@ietfa.amsl.com>; Wed, 14 Oct 2015 19:26:44 -0700 (PDT)
Received: from pacdcmhout01.cable.comcast.com (PACDCMHOUT01.cable.comcast.com [68.87.31.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C93EE1B2F0E for <anima@ietf.org>; Wed, 14 Oct 2015 19:26:36 -0700 (PDT)
X-AuditID: 44571fa7-f79776d000005d5f-ba-561f0edb4273
Received: from PACDCEXHUB02.cable.comcast.com (cas-umc02.ndceast.pa.bo.comcast.net [68.87.34.28]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by pacdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 78.EA.23903.BDE0F165; Wed, 14 Oct 2015 22:26:35 -0400 (EDT)
Received: from VAADCEX33.cable.comcast.com (147.191.103.210) by PACDCEXHUB02.cable.comcast.com (24.40.56.115) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 14 Oct 2015 22:26:34 -0400
Received: from VAADCEX37.cable.comcast.com (147.191.103.214) by VAADCEX33.cable.comcast.com (147.191.103.210) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 14 Oct 2015 22:26:26 -0400
Received: from VAADCEX37.cable.comcast.com ([fe80::3aea:a7ff:fe12:38b0]) by VAADCEX37.cable.comcast.com ([fe80::3aea:a7ff:fe12:38b0%19]) with mapi id 15.00.1044.021; Wed, 14 Oct 2015 22:26:21 -0400
From: "Toy, Mehmet" <Mehmet_Toy@cable.comcast.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, "Michael Behringer (mbehring)" <mbehring@cisco.com>, "anima@ietf.org" <anima@ietf.org>
Thread-Topic: Self-Managed Networks
Thread-Index: AdD/kRO6wwWTW9ATTCGfmWDsg6vmTgCHv4OwAAPvjp8AS70lMACaxAYgAB4NjsAAAQB6wAAvzJMAAAG8O7AAALH+8AASWYKAAAGIHpA=
Date: Thu, 15 Oct 2015 02:26:21 +0000
Message-ID: <c1e45907707f42d3ae1e9beb0647a760@VAADCEX37.cable.comcast.com>
References: <5D36713D8A4E7348A7E10DF7437A4B927BBB558B@nkgeml512-mbx.china.huawei.com> <7145ab65268b4fb3b279e2ce9da1fdaa@VAADCEX36.cable.comcast.com> <cbc6f29eda114b848f3dac35609b2da8@VAADCEX36.cable.comcast.com> <9c8b64c962c443f19f6fd784cb9927a7@VAADCEX36.cable.comcast.com> <7512f6b600904c49838fcf729e3000a5@XCH-RCD-006.cisco.com> <334e22acb30e487eb7f5a2d41fb54499@VAADCEX36.cable.comcast.com> <ff7789800a574fcb901e096a0a11f5bb@XCH-RCD-006.cisco.com> <dd5a46abd24c49d2a9acd31a608ef7e8@VAADCEX37.cable.comcast.com> <14fdc79570b54d0e9562382c5d53a3ef@XCH-RCD-006.cisco.com> <561EC845.9020505@gmail.com>
In-Reply-To: <561EC845.9020505@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [96.114.156.8]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLIsWRmVeSWpSXmKPExsXiEq4ko3ubTz7M4PZJfYuHi64zWbRd3Mdk cW3eRWYHZo8pvzeyeuycdZfdY8mSn0wBzFFcNimpOZllqUX6dglcGfNunGIqmFNW8b5pF1sD 44ziLkZODgkBE4lVb2czQthiEhfurWfrYuTiEBLYxSSxqP0VI4RzkFHiTO9KqMxhRomjh98z QTgnGSW6lncxg/SzCRhJzDtylQXEFhHoZZToneYKYgsLKEnc3HqPHSKuLPHw1DZmCLtMou3u GrDdLAKqEj+WrgWr4RXwktgxdRoLxIJXLBLTv6xlBUlwCmhK9O3bCVbECHTs91NrmEBsZgFx iVtP5jNBPCEgsWTPeWYIW1Ti5eN/rBC2gcTWpftYIGwFie37twHZHEC9mhLrd+lDjFGUmNL9 EOoGQYmTM5+AlQsBlUxadhFqpLjE4SM7WCcwSs1CsnkWwqRZSCbNQjJpASPLKka5gsTklOTc jPzSEgNDveTEpJxUveT83OTE4hIQvYkRHMnyy3cw3nvhdIhRgINRiYe3gl0+TIg1say4MvcQ owQHs5IIr/YGuTAh3pTEyqrUovz4otKc1OJDjNIcLErivJvv/QoVEkhPLEnNTk0tSC2CyTJx cEo1MFbvNduh+rfzkZChx1k7BqM37HezZK6/2fp1/6U5EV+2NPUdX845rztg86G/QU1MsnlZ EX8TTvw1SjobqlNwWyuxsXtLX4LG/mmBcZVrqhR4Nq7ZKfPuPQdnb37pDR0TVqfM85e4fMNZ ZLhfBxt8vlLNzL6UL2NS8TmB4pMeAi/KmI01bJOklViKMxINtZiLihMBzDaZ+eACAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/anima/EJ5yyvlpUIhnZ8iAdd1LIdtyoho>
Subject: Re: [Anima] Self-Managed Networks
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Oct 2015 02:26:46 -0000

Michael and Brian,
Per Toerless suggestion, I am including ANIMA group into the discussion.

I re-read the "A Reference Model for Autonomic Networking" document and I am not clear about the definitions.

a)  In the "A Reference Model for Autonomic Networking", ACP is defined as   "The Autonomic Control Plane is the summary of all interactions of the Autonomic Networking Infrastructure with other nodes and services.". 

b) Brian, you write as " The ACP is common infrastructure for all autonomic functions.(The ACP needs to be self-repairing, of course.) The signaling protocol is also common infrastructure."

Question: What is ACP? a or b or combination?

c) Section 4 in the reference model document , "The Autonomic Networking Infrastructure provides a layer of common  functionality across an Autonomic Network.  It comprises "must implement" functions and services, as well as extensions."
Question: What are the "must implement" functionalities?  How do you define "must implement" functionalities?

Thanks
Mehmet
-----Original Message-----
From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] 
Sent: Wednesday, October 14, 2015 5:25 PM
To: Michael Behringer (mbehring); Toy, Mehmet
Cc: 'dromasca@avaya.com'; 'jiangsheng@huawei.com'; 'anima-chairs@tools.ietf.org'
Subject: Re: Self-Managed Networks

I agree with Michael. The ACP is common infrastructure for all autonomic functions.
(The ACP needs to be self-repairing, of course.) The signaling protocol is also common infrastructure.

   Brian
On 15/10/2015 05:43, Michael Behringer (mbehring) wrote:
> I would argue they are part of an autonomic function, which runs on top of the ACP.
> There are really two different pieces here, and this is I think the confusion here:
> 
> -          The ACP is self-managing. It needs to do self-healing, and automatically adapt to new situations. But to me, this isn’t fault management or performance management as an operator understands it.
> 
> -          The network has FM and PM function. Those could be (and should be, imo) autonomic functions. Those run on top of the ACP.
> Bottom line: I’d like to keep the ACP itself as minimalistic and simple as we possibly can. Functions like FM / PM belong into an autonomic function, IMO.
> What do you think?
> Michael
> From: Toy, Mehmet [mailto:Mehmet_Toy@cable.comcast.com]
> Sent: 14 October 2015 18:30
> To: Michael Behringer (mbehring) <mbehring@cisco.com>
> Cc: 'dromasca@avaya.com' <dromasca@avaya.com>; 'jiangsheng@huawei.com' 
> <jiangsheng@huawei.com>; 'anima-chairs@tools.ietf.org' 
> <anima-chairs@tools.ietf.org>; 'brian.e.carpenter@gmail.com' 
> <brian.e.carpenter@gmail.com>
> Subject: RE: Self-Managed Networks
> 
> Michael,
> Instead of answering the question as Yes or No, let me give examples to see what makes sense.
> Let’s say in a data path, a router port is failed.  The router generates an AIS (Alarm Indication Signal) and the receiving  end generates RDI (remote Defect Indicator).  Both messages are generated by the hardware, not by a software or ACP.   As a result of this failure,  there would be packet loss. The hardware counts these losses, an ACP does not.
> For the FM and PM functions above, can we say they are part of an ACP?
> Thanks
> Mehmet
> From: Michael Behringer (mbehring) [mailto:mbehring@cisco.com]
> Sent: Wednesday, October 14, 2015 11:34 AM
> To: Toy, Mehmet
> Cc: 'dromasca@avaya.com'; 'jiangsheng@huawei.com'; 'anima-chairs@tools.ietf.org'; 'brian.e.carpenter@gmail.com'
> Subject: RE: Self-Managed Networks
> 
> Hi Toy,
> To understand better: To me, fault management *uses* the functions of the AN infrastructure. It uses the ACP to communicate, maybe GRASP for some signalling, might be influenced by Intent, etc. Right?  So to me, this is a logical component of an autonomic network that sits on top of the AN infrastructure.
> Do we agree?
> Michael
> 
> From: Toy, Mehmet [mailto:Mehmet_Toy@cable.comcast.com]
> Sent: 13 October 2015 23:46
> To: Michael Behringer (mbehring) 
> <mbehring@cisco.com<mailto:mbehring@cisco.com>>
> Cc: 'dromasca@avaya.com' 
> <dromasca@avaya.com<mailto:dromasca@avaya.com>>; 
> 'jiangsheng@huawei.com' 
> <jiangsheng@huawei.com<mailto:jiangsheng@huawei.com>>; 
> 'anima-chairs@tools.ietf.org' 
> <anima-chairs@tools.ietf.org<mailto:anima-chairs@tools.ietf.org>>; 
> 'brian.e.carpenter@gmail.com' 
> <brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>>
> Subject: RE: Self-Managed Networks
> 
> Michael,
> Appreciate the reply.
> FM is part of data plane and control plane (i.e. ANI in your diagram).
> My plan is to add a short paragraph for now either to section 2 to expand the description  of ANI or to section 4 to add a sub-section for Fault Management.
> 
> It is also possible too add a Performance Management section to describe what types of measurements and where and how are used.  Although there is a control feedback related measurement in the document, I don’t know if it is adequate.
> 
> Regards,
> Mehmet
> From: Michael Behringer (mbehring) [mailto:mbehring@cisco.com]
> Sent: Tuesday, October 13, 2015 12:27 PM
> To: Toy, Mehmet
> Cc: 'dromasca@avaya.com'; 'jiangsheng@huawei.com'; 'anima-chairs@tools.ietf.org'; 'brian.e.carpenter@gmail.com'
> Subject: RE: Self-Managed Networks
> 
> Sorry for the delay, it’s very busy at the moment here.
> To me, fault management refers generally to faults on the data plane, ie for user traffic. I see that happening at some point as an autonomic function (or several, for different aspects). Would you agree? Or do you see that as a function inside the AN infrastructure?
> So my feeling is that function would reside on top of the infrastructure that we’re currently defining. So, please have a look whether your thoughts can be described as an autonomic function. I think they probably can.
> Then I suggest we do the same that we’re planning to do with the NMS section, the model discussion, etc: Have a short paragraph describe the overall topic briefly, and point to an external doc for now, i.e., probably your draft.
> If you agree, can you suggest where in the reference model you would add a short paragraph about fault management, and I suppose we’d point to your draft, right?
> Michael
> 
> 
> From: Toy, Mehmet [mailto:Mehmet_Toy@cable.comcast.com]
> Sent: 13 October 2015 03:53
> To: Michael Behringer (mbehring) 
> <mbehring@cisco.com<mailto:mbehring@cisco.com>>
> Cc: 'dromasca@avaya.com' 
> <dromasca@avaya.com<mailto:dromasca@avaya.com>>; 
> 'jiangsheng@huawei.com' 
> <jiangsheng@huawei.com<mailto:jiangsheng@huawei.com>>; 
> 'anima-chairs@tools.ietf.org' 
> <anima-chairs@tools.ietf.org<mailto:anima-chairs@tools.ietf.org>>; 
> 'brian.e.carpenter@gmail.com' 
> <brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>>
> Subject: RE: Self-Managed Networks
> 
> Mike,
> I am waiting for your response.
> Thanks
> Mehmet
> 
> From: Toy, Mehmet
> Sent: Friday, October 09, 2015 8:13 PM
> To: 'mbehring@cisco.com'
> Cc: 'dromasca@avaya.com'; 'jiangsheng@huawei.com'; 'anima-chairs@tools.ietf.org'; 'brian.e.carpenter@gmail.com'
> Subject: RE: Self-Managed Networks
> 
> Mike,
> I can send you some text to include in section 2 and 4 of  “A Reference Model for Autonomic Networking,   draft-behringer-anima-reference-model-03”,  per Sheng’s suggestion.
> Should I just do that?
> Thanks
> Mehmet
> 
> 
> From: Toy, Mehmet
> Sent: Thursday, October 08, 2015 7:53 AM
> To: 'jiangsheng@huawei.com'; 'anima-chairs@tools.ietf.org'; 'brian.e.carpenter@gmail.com'; 'mbehring@cisco.com'
> Cc: 'dromasca@avaya.com'
> Subject: Re: Self-Managed Networks
> 
> Sheng,
> Appreciate a quick response.
> I will work on your suggestion.
> Mehmet
> 
> 
> From: Sheng Jiang [mailto:jiangsheng@huawei.com]
> Sent: Thursday, October 08, 2015 06:08 AM Eastern Standard Time
> To: Toy, Mehmet; 
> anima-chairs@tools.ietf.org<mailto:anima-chairs@tools.ietf.org> 
> <anima-chairs@tools.ietf.org<mailto:anima-chairs@tools.ietf.org>>; 
> brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com> 
> <brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>>; 
> mbehring@cisco.com<mailto:mbehring@cisco.com> 
> <mbehring@cisco.com<mailto:mbehring@cisco.com>>
> Cc: Romascanu, Dan (Dan) 
> (dromasca@avaya.com<mailto:dromasca@avaya.com>) 
> <dromasca@avaya.com<mailto:dromasca@avaya.com>>
> Subject: RE: Self-Managed Networks
> 
> Hi, Toy,
> First of all, for my understanding, your work is in the scope of the WG charter. However, we do not have work item or milestone for it. It looks like an upper-layer autonomic service agent for me. In our plan, autonomic service agents are mainly for the next period, which is after re-charter (this is the same with your suggestion of modifying the charter, but it cannot happen until we deliver the current milestones). For now, the best may be try to add some description, maybe mainly abstracted functionality, into the reference model document.
> Best regards,
> Sheng
> 
> From: Toy, Mehmet [mailto:Mehmet_Toy@cable.comcast.com]
> Sent: Tuesday, October 06, 2015 1:14 AM
> To: anima-chairs@tools.ietf.org<mailto:anima-chairs@tools.ietf.org>; 
> brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>; 
> mbehring@cisco.com<mailto:mbehring@cisco.com>
> Cc: Romascanu, Dan (Dan) 
> (dromasca@avaya.com<mailto:dromasca@avaya.com>)
> Subject: Self-Managed Networks
> 
> 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
> 
>