Re: [Anima] Self-Managed Networks

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 15 October 2015 22:48 UTC

Return-Path: <brian.e.carpenter@gmail.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 3836D1A87D5 for <anima@ietfa.amsl.com>; Thu, 15 Oct 2015 15:48:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 QnVo_RwXCheV for <anima@ietfa.amsl.com>; Thu, 15 Oct 2015 15:48:48 -0700 (PDT)
Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D07651A87D4 for <anima@ietf.org>; Thu, 15 Oct 2015 15:48:48 -0700 (PDT)
Received: by pabws5 with SMTP id ws5so2404041pab.2 for <anima@ietf.org>; Thu, 15 Oct 2015 15:48:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=9FCZ2zhOMdoeTfaEvFOctnq5BX9Zd/OwiAig5vlmOYI=; b=jj/zS5yKCGp18rIAnK75yyxEasQd9I3Z/AxN7nCkkvtQL9FMoFKAwWEMM7f+ajC7ET qjjouE2JLV1DE9uW2BbnBT7Kgo8lhvVsV5od2vcvV0sz+eYUhlCY6E3gvlkBO6H8zpB9 Q2rPwn8kAhH5UOLV0r3Fh3t5t779eTxzUbg5SNTviyC5y4MOaZ9Sm3HiAf71avE5pyRJ OzUG8sl1GC+Eh4kjTimZxkE1EJCee8+Y/j5pzv1RU5GQ9LVt32oltRqMjksb5s50XLBw zJLaLYZTT3bIGUr6pYle0HD3LxLs2WzDFCeBLTOjKQaAFtah+RReMKpVQOGyJnv1Y3EI uUjg==
X-Received: by 10.66.253.229 with SMTP id ad5mr12604331pad.101.1444949328346; Thu, 15 Oct 2015 15:48:48 -0700 (PDT)
Received: from [192.168.137.82] (14-202-184-134.tpgi.com.au. [14.202.184.134]) by smtp.gmail.com with ESMTPSA id pf7sm17342229pbc.6.2015.10.15.15.48.44 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Oct 2015 15:48:46 -0700 (PDT)
To: "Michael Behringer (mbehring)" <mbehring@cisco.com>, "Toy, Mehmet" <Mehmet_Toy@cable.comcast.com>, "anima@ietf.org" <anima@ietf.org>
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> <c1e45907707f42d3ae1e9beb0647a760@VAADCEX37.cable.comcast.com> <03347fe65bce48e9ba28827f5c4c0624@XCH-RCD-006.cisco.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <56202D54.6060208@gmail.com>
Date: Fri, 16 Oct 2015 11:48:52 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <03347fe65bce48e9ba28827f5c4c0624@XCH-RCD-006.cisco.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/anima/sy_x6j-Qw7pcY_Doy_xFYFeDKcg>
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 22:48:52 -0000

On 15/10/2015 21:57, Michael Behringer (mbehring) wrote:
> Toy, thanks for raising those questions. Obviously, we're not doing a good job yet in describing what the ACP is, and that needs to be fixed. And obviously, we all need the same view to progress further. So this is a very important discussion, and I really welcome it. 
> 
> Before formalising better text, let me see whether we get agreement on the fundamental idea. 
> 
> In my head, there are two layers: The ACP, and on top of that the Autonomic Functions: 
> 
> * The ACP is the "tool kit". It comprises various "mechanics", such as negotiation, synchronisation, discovery of various sorts, messaging, etc. Those are all based on a common addressing and naming concept. 

Well, hold on. The ACP is the substrate for GRASP, but GRASP is defined so that in theory
it could run without the ACP (e.g. running over TLS). ACP+GRASP+etc = ANI (AN infrastructure).

> 
> * Autonomic Functions use that tool kit to do something clever. In other words, the true autonomic "intelligence" sits on that level. 
> 
> There is *one* ACP, there are *many* autonomic functions on top. 

Indeed, and fault management mechanisms are certainly important ones.

   Brian

> 
> One way to decide to which layer something belongs is to ask: "is this (1) a generic functionality which many functions require, or is this (2) one specific function?". If the answer is (1), it belongs into the ACP, if (2) it belongs into an autonomic function. 
> 
> So, in this light, my understanding (!) of fault management is that this is an autonomic function, and would use common blocks of the underlying ACP. Conversely, it would not offer services to other autonomic functions on top. This is my way of thinking when I write "this is an autonomic function".  And I'm not 100% certain I understand what you're suggesting, so please chime in here! (And I haven't read your draft fully yet, sorry)
> 
> Look at http://tools.ietf.org/id/draft-jiang-anima-prefix-management-01.txt
> This draft describes "intelligence". In that case, a way to automatically manage address space. Sections 2.2 and 2.3 explain which parameters and information exchanges such a function would require. Sheng wrote this document to explain how an autonomic function would use a common ACP. 
> 
> Probably we should take some off-line time in Yokohama to discuss this in a small team? 
> 
> Michael
> 
> 
>> -----Original Message-----
>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Toy, Mehmet
>> Sent: 15 October 2015 04:26
>> To: Brian E Carpenter <brian.e.carpenter@gmail.com>; Michael Behringer
>> (mbehring) <mbehring@cisco.com>; anima@ietf.org
>> Subject: Re: [Anima] Self-Managed Networks
>>
>> 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
>>>
>>>
>>
>>
>> _______________________________________________
>> Anima mailing list
>> Anima@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima