From nobody Tue Jul 1 19:19:24 2014 Return-Path: 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 191E51B2842 for ; Tue, 1 Jul 2014 19:19:23 -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 p-mv_xyqcVnW for ; Tue, 1 Jul 2014 19:19:21 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C81631A007B for ; Tue, 1 Jul 2014 19:19:21 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id w10so11071805pde.17 for ; Tue, 01 Jul 2014 19:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=s+AmxIe5zY6ql8w2KQ110285Lg0gB92vha9ZkL0uK2E=; b=A5z9HQxkd8Yflt6DMdlPKype86tktIvU0VoCVe7wG47S5pQBBgggOoxMO4mKBxLNSN FNesdqKO0Mq6Ug7Mo0meUycK8FFJJd6CtRhn1OdxA99Oq2lHzaDu7Dp2gt9XcH7yEkMM ygTPgZPP3bfJYKD2YpscB92ba90iJLpeYIN6pwhh8iL+SA/5JalN0uH1V3z6EgwOWthI F6JvIoHBhfTvtwOTqdW53ABtUddAGHf1reRw3OWUjGcLcA45my3HFlB4szQLaxG9sKma bkv/pQmIZx1uUUq0i++sTG1BNuTbzlG6EDDa8bfLtU005Ft2Kq8sT+fdxZkYwrOY+5sz f2OA== X-Received: by 10.66.147.99 with SMTP id tj3mr596416pab.47.1404267561418; Tue, 01 Jul 2014 19:19:21 -0700 (PDT) Received: from [130.216.38.108] (sc-cs-567-laptop.cs.auckland.ac.nz. [130.216.38.108]) by mx.google.com with ESMTPSA id eh4sm34632487pbc.79.2014.07.01.19.19.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Jul 2014 19:19:20 -0700 (PDT) Message-ID: <53B36C2D.1060202@gmail.com> Date: Wed, 02 Jul 2014 14:19:25 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: anima@ietf.org References: <53B0D8D3.4070403@gmail.com> In-Reply-To: <53B0D8D3.4070403@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/3wuL5w7Ny32dMbBsoWd-oh_GyOU Subject: Re: [Anima] Preparing the UCAN BOF agenda X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 02:19:23 -0000 An addition to the BOF agenda: 3. What operators want from autonomic networking (Diego Lopez, Telefonica) (10 min) Regards Brian On 30/06/2014 15:26, Brian E Carpenter wrote: > Hi, > > While Michael Behringer is on leave, I will continue to prepare the > BOF agenda. Some comments: > > - The initial overview is fairly short. As always, please read the drafts > in advance. Those two drafts will be discussed in more detail in > NMRG on Monday. > > - We propose to give a short slot to each use case announced so far. > There won't be much time for questions, so again please read in > advance. I will contact the various authors soon with a plan for > getting through the main points of each case efficiently. > > - We've added a short item on solution space. This is not intended > as a thorough discussion on solutions. The idea is to show that > there are concrete mechanisms that can realistically be implemented. > > For now the latest agenda is in the wiki, and today > it looks like this: > > 1. Agenda bashing (5 min) > 2. Overview of autonomic networking ideas and the need, > scope and criteria for use cases > (draft-irtf-nmrg-autonomic-network-definitions, > draft-irtf-nmrg-an-gap-analysis) (20 min) > 3. Use cases (5 min each): > - homenet (draft-carpenter-nmrg-homenet-an-use-case) > - large network address management (draft-jiang-auto-addr-management) > - securely bootstrapping new devices (draft-behringer-autonomic-bootstrap) > - autonomic control plane (draft-behringer-autonomic-control-plane) > - distributed detection of SLA violations > (draft-irtf-nmrg-autonomic-sla-violation-detection) > - mobile backhaul (draft-bogdanovic-nmrg-mobile-backhaul-use-case) > - risk aware routing (draft-TBD) > 4. Approaches to solution space (10 min) > Discovery + negotiation (draft-jiang-config-negotiation-protocol, > draft-jiang-config-negotiation-ps) > Autonomic bootstrap of an Autonomic Control Plane > (draft-pritikin-bootstrapping-keyinfrastructures, > draft-behringer-autonomic-control-plane) > 5. Discussion, including identifying other uses cases & next steps (50 min) > > Regards > Brian Carpenter > > From nobody Wed Jul 9 18:55:15 2014 Return-Path: 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 871BB1A01A0 for ; Wed, 9 Jul 2014 18:55:13 -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 yT9TYAI745Ba for ; Wed, 9 Jul 2014 18:55:12 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E15E51A0193 for ; Wed, 9 Jul 2014 18:55:11 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id v10so9913363pde.40 for ; Wed, 09 Jul 2014 18:55:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=uoHqKM9oyV8+gohKECMbbHCTQlMtCWHFy2d7BTx66ag=; b=XYuhTwB4/L3+lCdEHoW50J7HPM4hJUdCojsMDYkjw7nDY4fc9KydHllSQI0gARk42x mxuKVe4PXFxZIT2Ln2rtqMbHCv8M1eXIctJlVd9UXyjnlcefzz/nD4YPnhqWMtgSTKDt YxGMm5INm5cF96zhCnx2tvA55CW/OV00//6TEJy4vWdHpjSNzt8dZUS7shjRSbTs1r1c UMKSYnQj1Hf99/2y5mfzhQ3KZK5CIwUzUKEKFMquTkrf5LDCcwRhGVrwCcKZE74NjrY/ w+3QHxex1EshZ0/7BxQKur2XS+IcvQ3aTLuBl//F7XkfZHcxxsMlB798wSwXVPZJMCSL JQag== X-Received: by 10.68.173.65 with SMTP id bi1mr462474pbc.130.1404957311623; Wed, 09 Jul 2014 18:55:11 -0700 (PDT) Received: from [130.216.38.108] (sc-cs-567-laptop.cs.auckland.ac.nz. [130.216.38.108]) by mx.google.com with ESMTPSA id z3sm221847074pas.15.2014.07.09.18.55.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Jul 2014 18:55:11 -0700 (PDT) Message-ID: <53BDF284.4030403@gmail.com> Date: Thu, 10 Jul 2014 13:55:16 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: anima@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/6yk6ID8-Gmo_Cc9CBGfEfsdmTZw Subject: [Anima] UCAN BOF progress, and some requests X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 01:55:13 -0000 Hi, There are already some slides for the UCAN BOF at the meeting materials page (https://datatracker.ietf.org/meeting/90/materials.html) and more will be added as soon as I receive them. Please look at the various drafts mentioned in the agenda and in the BOF description (http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#UCANApprovedforIETF90). Discussion on the list will help us to be more efficient in the meeting, so please email your comments and questions. Please can somebody volunteer to take minutes in the session, and somebody else to act as a jabber scribe? Neither of these jobs needs constant typing. The minutes only need to contain main points and results, and jabber only needs to keep track of which slide is displayed. Brian From nobody Fri Jul 11 12:33:19 2014 Return-Path: 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 BF8431B2CA1 for ; Fri, 11 Jul 2014 12:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 Z5BjczCIvCFN for ; Fri, 11 Jul 2014 12:33:17 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F08451B2C9E for ; Fri, 11 Jul 2014 12:33:16 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id v6so1000448lbi.30 for ; Fri, 11 Jul 2014 12:33:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=uwmIKiLLosg6RB2Vbfhw5NZTfqj9+T2/JwI6ZVpCTHI=; b=zBqe5gos6NHlQGW3TgNp5s9WW0bdDOvcV9QSmyrZSwv4+H5+UQibOhYE2hZMy63QlA TsPvIjoFTwm4b/QhO2NvHr7EjQVr3WbN2JU4CFN8NL9nY+zR5WF1pyUGf/Zuxcr9QGbB XHdpCFRP8hoAc+jFkIXCjh4BX5Ti7JCzbsnBAu0p6KhxmD/brIYI9k6p/aaOkOIz5PFP sWAUI4QEJvwkYJYp/b6YuTFVUWI+u9iwqi1tGir/S5cAT2BpE8HoTIY8OsvdkIj2RXI+ 150OxGbGqCLxU6N9sfSv7h4T6jgysS56KDwpdLpvhCBb6/Mft0jpqrXFBoXXT4AD9ZL7 Lhcg== MIME-Version: 1.0 X-Received: by 10.152.87.207 with SMTP id ba15mr749903lab.15.1405107195163; Fri, 11 Jul 2014 12:33:15 -0700 (PDT) Sender: jeferson.nobre@gmail.com Received: by 10.112.146.228 with HTTP; Fri, 11 Jul 2014 12:33:15 -0700 (PDT) In-Reply-To: <53BDF284.4030403@gmail.com> References: <53BDF284.4030403@gmail.com> Date: Fri, 11 Jul 2014 16:33:15 -0300 X-Google-Sender-Auth: jzuohxC1Fd0PSqv2drKVJ7Ba7sw Message-ID: From: =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/anima/CAEoTtbUitvekFyf-QwRSAxzLaA Cc: anima@ietf.org Subject: Re: [Anima] UCAN BOF progress, and some requests X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 19:33:18 -0000 Hi Brian. I volunteer as jabber scribe. Cheers. J=C3=A9ferson Campos Nobre PhD Student Computer Networks Group - Institute of Informatics Federal University of Rio Grande do Sul http://www.inf.ufrgs.br/~jcnobre On Wed, Jul 9, 2014 at 10:55 PM, Brian E Carpenter wrote: > Hi, > > There are already some slides for the UCAN BOF at the > meeting materials page > (https://datatracker.ietf.org/meeting/90/materials.html) > and more will be added as soon as I receive them. > > Please look at the various drafts mentioned in the agenda > and in the BOF description > (http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#UCANApprovedforIETF90= ). > > Discussion on the list will help us to be more efficient in > the meeting, so please email your comments and questions. > > Please can somebody volunteer to take minutes in the session, > and somebody else to act as a jabber scribe? > > Neither of these jobs needs constant typing. The minutes > only need to contain main points and results, and jabber > only needs to keep track of which slide is displayed. > > Brian > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Tue Jul 15 21:12:07 2014 Return-Path: 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 BAC591B2A72 for ; Tue, 15 Jul 2014 21:11:55 -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 vEPXj5rXXKXl for ; Tue, 15 Jul 2014 21:11:46 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0865E1B2A6D for ; Tue, 15 Jul 2014 21:11:34 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id v10so496398pde.6 for ; Tue, 15 Jul 2014 21:11:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=2uEI7H1zJToBuBDkF6y8eV6ScQAGIszzSl+6ybwYmBA=; b=piY5dMp+Zqz7EVmjpvwGWNJcHVlilzQFEfqehmD9B8UQTqyQsj6HS0K9B9TMgJLlhi 1DfI4CM4TMTwWguWi1LdKkGnxIAJttzWYe3rLurXLmxB2BuSaecxg/ePMSludvsi9QDN 4k4v26WP2hHPFtatEg9lnMtlpcaVbyinXsK8Qlo4PIZWz2UixyZospzWBvCcqw/vi7i3 di3ayU3s8mCwBN0kS/pWGQOaeanPFkS7h/bn5B6bRHqYsLQy7Y76oroBsfkR9kPO3+US nKx66guSwlHhiJIO2nuu33UzShiFJDYWQAbzrnVaXmsxFTPl7Rx6yFH5AqHkh0DvSL9f tk8g== X-Received: by 10.68.138.227 with SMTP id qt3mr27370699pbb.6.1405483893634; Tue, 15 Jul 2014 21:11:33 -0700 (PDT) Received: from [192.168.178.23] (36.198.69.111.dynamic.snap.net.nz. [111.69.198.36]) by mx.google.com with ESMTPSA id qy8sm16823719pab.12.2014.07.15.21.11.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jul 2014 21:11:33 -0700 (PDT) Message-ID: <53C5FB78.4010904@gmail.com> Date: Wed, 16 Jul 2014 16:11:36 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: anima@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/EDcGcY8WwxNtOFX4p24VKKLkmCI Subject: [Anima] UCAN BOF slides, and one request X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 04:11:57 -0000 Hi, There are now about half of the slides for the UCAN BOF at the meeting materials page (https://datatracker.ietf.org/meeting/90/materials.html) I'm looking forward to receiving the remaining slides within about 24 hours (hint to the responsible authors). Please look at the various drafts mentioned in the agenda and in the BOF description (http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#UCANApprovedforIETF90). We're still in need of a volunteer to take minutes. Brian From nobody Tue Jul 22 06:49:58 2014 Return-Path: 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 5B0241B283E for ; Tue, 22 Jul 2014 06:49:57 -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=unavailable 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 oKOXZX-_VPBU for ; Tue, 22 Jul 2014 06:49:56 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEA151B27E3 for ; Tue, 22 Jul 2014 06:49:55 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id n3so5949925wiv.0 for ; Tue, 22 Jul 2014 06:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=GiQrapd0fKSy0UNW1cSZ9kgI/aoe4O23TxMx9pQOXFg=; b=uPkp8R3nnJSPyGwd1AryZvqy6WHfukzAYC32ZI2fUp3CrOPVRW6vfJvqFgsRBdxe51 K17XBiSuleTLRMw5YS2pxrDW0ogam0fzEASaSvfy9ePiqvmnGOMroGDr7kNcq2QEu1Hb c39s+Cam96ZuZEPfGkWJOdo7Ll6ILKqQpRN97sVfDecRdwGPsyAxno4a7yy0hvXUHNgC FPTZvgXlGpz1vkjYZ+wYuW5SgE+4QzuvS+7Ndu0KkX3v//3lxRg0DWE8vJ5D2RkIMIng owvKWyng1k5QjBrl3ByGIjHwNR4ppQ4AppkQN2jF1w0C5yowBSgOTb9xBmJwTEiM/z54 ZM3Q== X-Received: by 10.194.205.132 with SMTP id lg4mr35133836wjc.80.1406036993685; Tue, 22 Jul 2014 06:49:53 -0700 (PDT) Received: from [31.133.162.184] (dhcp-a2b8.meeting.ietf.org. [31.133.162.184]) by mx.google.com with ESMTPSA id a13sm1167158wjs.12.2014.07.22.06.49.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Jul 2014 06:49:52 -0700 (PDT) Message-ID: <53CE6C03.3080908@gmail.com> Date: Wed, 23 Jul 2014 01:49:55 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: anima@ietf.org, nmrg@irtf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/43x6v0VA7wOMrI59D7_K9LeqVkA Subject: [Anima] UCAN BOF slides and logistics X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 13:49:57 -0000 The slides for the UCAN BOF are almost all loaded now on the meeting materials page: https://datatracker.ietf.org/meeting/90/materials.html See you at 1300 (1 p.m.) Wednesday in the Ballroom. For remote participation links, see the tools agenda at http://tools.ietf.org/agenda/90/ or for Meetecho see http://www.meetecho.com/ietf90/ucan Regards Brian Carpenter From nobody Tue Jul 22 13:07:19 2014 Return-Path: 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 1AA771A01E4 for ; Tue, 22 Jul 2014 13:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 kf-Y05oD_0BN for ; Tue, 22 Jul 2014 13:07:13 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C97161A035B for ; Tue, 22 Jul 2014 13:07:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=655; q=dns/txt; s=iport; t=1406059622; x=1407269222; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=t+I9KTaRK4Sl4yHqNS/s+UeVtprpzN94Zcesqs+RZlk=; b=kO1O5BFStlpEZw+8kGufDEchcxxtA9Icw9dgN540orBdFET3tYBgk4FF VtSmRS2tn9S0U0hPH67a/6PobZd6HlBk1mfcyXvH6kEVR78BVUboz7xD1 JdvdJNzrK40c1H1+HKA/GYJ2uqM+njsPoriay5DUJBrUTbT+qEII+tC5H A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAH7DzlOtJA2M/2dsb2JhbABYgw6BLc5cAYETFnaEBQEEOlEBKhRCJgEEG4g6mUymJRePGoNmgRgFr1qDRoIx X-IronPort-AV: E=Sophos;i="5.01,711,1400025600"; d="scan'208";a="63120153" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-2.cisco.com with ESMTP; 22 Jul 2014 20:07:02 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s6MK717Y008395 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 22 Jul 2014 20:07:01 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.221]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Tue, 22 Jul 2014 15:07:00 -0500 From: "Michael Behringer (mbehring)" To: "anima@ietf.org" Thread-Topic: Presenters tomorrow: Please focus on "next steps" Thread-Index: Ac+l6G9Jj9n9Vn4xSlKPqeKCe4m1Vw== Date: Tue, 22 Jul 2014 20:06:59 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BF040D@xmb-rcd-x14.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.238.193] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/anima/8lvtIr5Oe6vThq1BFDESIIkdcpM Subject: [Anima] Presenters tomorrow: Please focus on "next steps" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 20:07:15 -0000 Anima,=20 Brian and I met with the Opsarea ADs yesterday to discuss the UCAN BoF and = potential next steps. In this discussion the ADs asked us specifically to f= ocus on next steps in the IETF for this work.=20 We would therefore like to ask the presenters tomorrow to specifically focu= s on potential next steps in the IETF, such as: - which type of protocols are required between which points - need for policy=20 - which data models are required - etc Obviously, the slides are done and uploaded; too late to change them now. B= ut please try to focus your attention in particular on these points.=20 Thanks, Brian and Michael From nobody Sat Jul 26 05:58:54 2014 Return-Path: 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 090471B27DF for ; Sat, 26 Jul 2014 05:58:53 -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 3dsUd_fxklML for ; Sat, 26 Jul 2014 05:58:51 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 881161B27DA for ; Sat, 26 Jul 2014 05:58:51 -0700 (PDT) Received: by mail-qg0-f54.google.com with SMTP id z60so6379968qgd.13 for ; Sat, 26 Jul 2014 05:58:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=7mnbChGso9WSO+EzlNCH1bwerLwYoqOhhHEhCzOfdjw=; b=DWRPHggKPTXP9zrMoLnck9jNKjzcNHNiyNSEteTNMgj4IaZvHgQVp0dIInz16jvRxr T21RL2xxkULEsB5I4uvSUaWx7ib41ORAsncUnoOh57wyDitnQzQ8aQuo+KSDO+/mgzso etmFMgjJkN2VxwEPWjF523fz6DLFSH34M8nlPm4CAzHm6qEOdppdJCruW8waBHfixAMl fqKfm3gbdrOH+jB4GYZ2MWKh09M+lJh/7X+QrseEI8yrlcLEzY0VdqTicmCFSTqY/K3U OEEv7AE/C/tUGWFU/+ThU8n2MKTWeM6L2VcvrEFTIG/xRJENekKV3v9sogs2BwhdHiDR 4OcA== X-Received: by 10.224.119.198 with SMTP id a6mr8663516qar.39.1406379530710; Sat, 26 Jul 2014 05:58:50 -0700 (PDT) Received: from [142.131.64.169] ([206.47.221.210]) by mx.google.com with ESMTPSA id n3sm18749258qai.14.2014.07.26.05.58.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 26 Jul 2014 05:58:49 -0700 (PDT) Message-ID: <53D3A616.5090401@gmail.com> Date: Sun, 27 Jul 2014 00:59:02 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: anima@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/yvlITnztK5N6X5CFILTe6FnnvFI Subject: [Anima] AN and I2RS X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 12:58:53 -0000 Hi, It was mentioned during the UCAN BOF that we should consider any relationship to I2RS. While waiting to check out of the hotel later this morning, I have quickly glanced at the I2RS architecture (http://tools.ietf.org/html/draft-ietf-i2rs-architecture-05). One aspect is how a future I2RS instance could interact with AN. I2RS says: > Routing Element: A Routing Element implements some subset of the > routing system. It does not need to have a forwarding plane > associated with it. Examples of Routing Elements can include: > > * A router with a forwarding plane and RIB Manager that runs > ISIS, OSPF, BGP, PIM, etc., > > * A BGP speaker acting as a Route Reflector, > > * An LSR that implements RSVP-TE, OSPF-TE, and PCEP and has a > forwarding plane and associated RIB Manager, > > * A server that runs ISIS, OSPF, BGP and uses ForCES to control a > remote forwarding plane, > > A Routing Element may be locally managed, whether via CLI, SNMP, > or NETCONF. So, I suppose we could argue that an I2RS Routing Element could act as an Autonomic Networking Service Agent, i.e. it could act as an interface between the routing system and AN, instead of being traditionally managed. We could also wonder whether I2RS isn't a nice AN use case, but it's very complex - the I2RS WG itself is deep into multiple use case analysis and information model development - to say it bluntly, ANIMA doesn't need that much complexity right now ;-). I think it is far too soon to even hypothetically consider whether I2RS and AN have overlapping protocol requirements. I2RS has a line its charter: > - An analysis of existing IETF and other protocols and encoding > languages against the requirements. but I don't see any sign of an active draft on that topic. Unfortunately I didn't get a chance to talk with any of the I2RS protagonists during the IETF. If anybody here can comment further, please do so. Regards Brian From nobody Sat Jul 26 07:36:42 2014 Return-Path: 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 3DC891A02DE for ; Sat, 26 Jul 2014 07:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 BvgeV831y1Q3 for ; Sat, 26 Jul 2014 07:36:38 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4F921A023E for ; Sat, 26 Jul 2014 07:36:37 -0700 (PDT) Received: by mail-yk0-f178.google.com with SMTP id 142so3578018ykq.37 for ; Sat, 26 Jul 2014 07:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d959vLkIUrGG5YjTa+0Qoi9tH+rPSJa4Il//t9w+Grk=; b=kByMMDTm2BLRFRwyCchq3Qc9CDLgZ0PF3e0ZnRna8/99GVpFUKAmauxWO/hfpSU2M2 4A4r3UdOMVIdmBux/aGuag25e5DnBvJTieaX0JN9PnPYihdBUkSbluKSVWAsGxqpK2Ge rqQT36+wS5WlHYVDUxIUdriOqDhbyynVthtmq4C3YtiPFOR6aLaEz341YYNGV9HLu1sn MlnZBbVxY/itb9ckZzDYCmTyAOZThUGzwQ5f4RZHBbtYPKMWDzuMOCpeTaRSRPfKllpX fos32mRPX5LCtQuQx69Zg7se20x/Nj4tEtWAZBXR/gZ6BIUldBMFVE4Uqfq+O5NUTdws 8G7Q== MIME-Version: 1.0 X-Received: by 10.236.1.167 with SMTP id 27mr25444065yhd.25.1406385397148; Sat, 26 Jul 2014 07:36:37 -0700 (PDT) Received: by 10.170.130.201 with HTTP; Sat, 26 Jul 2014 07:36:37 -0700 (PDT) Received: by 10.170.130.201 with HTTP; Sat, 26 Jul 2014 07:36:37 -0700 (PDT) In-Reply-To: <53D3A616.5090401@gmail.com> References: <53D3A616.5090401@gmail.com> Date: Sat, 26 Jul 2014 10:36:37 -0400 Message-ID: From: Alia Atlas To: Brian E Carpenter Content-Type: multipart/alternative; boundary=089e011825d003b6fc04ff199e17 Archived-At: http://mailarchive.ietf.org/arch/msg/anima/4UeAQkPP4vTDQF8w7GLz3UfGXbc Cc: anima@ietf.org Subject: Re: [Anima] AN and I2RS X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 14:36:40 -0000 --089e011825d003b6fc04ff199e17 Content-Type: text/plain; charset=UTF-8 I2RS has selected YANG for the modeling language and RestConf/NetConf as the protocol base for I2RS. Regrettably, I could not attend the BOF, but there might be some synergy where I2RS provides the mechanisms for learning information & modifying the routing plane. Alia On Jul 26, 2014 8:58 AM, "Brian E Carpenter" wrote: > Hi, > > It was mentioned during the UCAN BOF that we should consider any > relationship to I2RS. While waiting to check out of the hotel > later this morning, I have quickly glanced at the I2RS architecture > (http://tools.ietf.org/html/draft-ietf-i2rs-architecture-05). > > One aspect is how a future I2RS instance could interact with AN. > I2RS says: > > > Routing Element: A Routing Element implements some subset of the > > routing system. It does not need to have a forwarding plane > > associated with it. Examples of Routing Elements can include: > > > > * A router with a forwarding plane and RIB Manager that runs > > ISIS, OSPF, BGP, PIM, etc., > > > > * A BGP speaker acting as a Route Reflector, > > > > * An LSR that implements RSVP-TE, OSPF-TE, and PCEP and has a > > forwarding plane and associated RIB Manager, > > > > * A server that runs ISIS, OSPF, BGP and uses ForCES to control a > > remote forwarding plane, > > > > A Routing Element may be locally managed, whether via CLI, SNMP, > > or NETCONF. > > So, I suppose we could argue that an I2RS Routing Element could act > as an Autonomic Networking Service Agent, i.e. it could act as an > interface between the routing system and AN, instead of being > traditionally managed. > > We could also wonder whether I2RS isn't a nice AN use case, but it's > very complex - the I2RS WG itself is deep into multiple use case > analysis and information model development - to say it bluntly, > ANIMA doesn't need that much complexity right now ;-). > > I think it is far too soon to even hypothetically consider whether > I2RS and AN have overlapping protocol requirements. I2RS has a > line its charter: > > > - An analysis of existing IETF and other protocols and encoding > > languages against the requirements. > > but I don't see any sign of an active draft on that topic. > > Unfortunately I didn't get a chance to talk with any of the > I2RS protagonists during the IETF. If anybody here can comment > further, please do so. > > Regards > Brian > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > --089e011825d003b6fc04ff199e17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I2RS has selected YANG for the modeling language and RestCon= f/NetConf as the protocol base for I2RS.

Regrettably, I could not attend the BOF, but there might be = some synergy where I2RS provides the mechanisms for learning information &a= mp; modifying the routing plane.

Alia

On Jul 26, 2014 8:58 AM, "Brian E Carpenter= " <brian.e.carpenter= @gmail.com> wrote:
Hi,

It was mentioned during the UCAN BOF that we should consider any
relationship to I2RS. While waiting to check out of the hotel
later this morning, I have quickly glanced at the I2RS architecture
(http://tools.ietf.org/html/draft-ietf-i2rs-architecture-05).

One aspect is how a future I2RS instance could interact with AN.
I2RS says:

> =C2=A0 =C2=A0Routing Element: =C2=A0 A Routing Element implements some= subset of the
> =C2=A0 =C2=A0 =C2=A0 routing system. =C2=A0It does not need to have a = forwarding plane
> =C2=A0 =C2=A0 =C2=A0 associated with it. =C2=A0Examples of Routing Ele= ments can include:
>
> =C2=A0 =C2=A0 =C2=A0 * =C2=A0A router with a forwarding plane and RIB = Manager that runs
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ISIS, OSPF, BGP, PIM, etc.,
>
> =C2=A0 =C2=A0 =C2=A0 * =C2=A0A BGP speaker acting as a Route Reflector= ,
>
> =C2=A0 =C2=A0 =C2=A0 * =C2=A0An LSR that implements RSVP-TE, OSPF-TE, = and PCEP and has a
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0forwarding plane and associated RIB = Manager,
>
> =C2=A0 =C2=A0 =C2=A0 * =C2=A0A server that runs ISIS, OSPF, BGP and us= es ForCES to control a
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0remote forwarding plane,
>
> =C2=A0 =C2=A0 =C2=A0 A Routing Element may be locally managed, whether= via CLI, SNMP,
> =C2=A0 =C2=A0 =C2=A0 or NETCONF.

So, I suppose we could argue that an I2RS Routing Element could act
as an Autonomic Networking Service Agent, i.e. it could act as an
interface between the routing system and AN, instead of being
traditionally managed.

We could also wonder whether I2RS isn't a nice AN use case, but it'= s
very complex - the I2RS WG itself is deep into multiple use case
analysis and information model development - to say it bluntly,
ANIMA doesn't need that much complexity right now ;-).

I think it is far too soon to even hypothetically consider whether
I2RS and AN have overlapping protocol requirements. I2RS has a
line its charter:

> - An analysis of existing IETF and other protocols and encoding
> =C2=A0 languages against the requirements.

but I don't see any sign of an active draft on that topic.

Unfortunately I didn't get a chance to talk with any of the
I2RS protagonists during the IETF. If anybody here can comment
further, please do so.

Regards
=C2=A0 =C2=A0 Brian

_______________________________________________
Anima mailing list
Anima@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/anima
--089e011825d003b6fc04ff199e17-- From nobody Tue Jul 29 07:29:59 2014 Return-Path: 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 A4C1E1B2806 for ; Tue, 29 Jul 2014 07:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 Uzq4GClZHH3o for ; Tue, 29 Jul 2014 07:29:55 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1A8A1B280D for ; Tue, 29 Jul 2014 07:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5851; q=dns/txt; s=iport; t=1406644196; x=1407853796; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=D+05jm8CJA6XWLFzlUETUllyfawOmQERgAFy34Tz5I0=; b=TCiWJVb0+OtlCBgcil797YFiqzU+kYRYxkdJ7oArGDJ+nvzJT4STGHVI jkVfcLzoKnk6m7VvwuhUPmuanf8BEsX8j1d3UFG3Vae8+U16C5AaTKJAG IfOIMqPH5dFv9xuCyPsnEohsSwqzdY+G6SSenOVOV8oifxh8Y8B1gmekF k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0FAI2u11OtJV2Q/2dsb2JhbABZgw5SVwTLbodJAYEOFneEBQECAjozDBIBKgsJQiYBBAENDQGIOQ2/KBeOewEBHjERgyWBGwWXKoV0knyDSWwBgQs5 X-IronPort-AV: E=Sophos;i="5.01,757,1400025600"; d="scan'208";a="64876375" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-4.cisco.com with ESMTP; 29 Jul 2014 14:29:55 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s6TETsMo021005 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jul 2014 14:29:54 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.221]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Tue, 29 Jul 2014 09:29:53 -0500 From: "Michael Behringer (mbehring)" To: "nmrg@irtf.org" , "anima@ietf.org" Thread-Topic: Next version of draft-irtf-nmrg-autonomic-network-definitions Thread-Index: Ac+rCQxbzwgPqhqRSmS/RLN8kfw5tA== Date: Tue, 29 Jul 2014 14:29:53 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BF933F@xmb-rcd-x14.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.72.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/anima/Ps9f19tGPqRfiEO-lSW29JBNTe8 Cc: "draft-irtf-nmrg-autonomic-network-definitions@tools.ietf.org" Subject: [Anima] Next version of draft-irtf-nmrg-autonomic-network-definitions X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 14:29:57 -0000 [excuse cross-posting, but I do believe that this is relevant to both lists= ] Anima, NMRG,=20 Before and at the IETF there was a lot of discussion around the autonomic p= aradigms discussed in draft-irtf-nmrg-autonomic-network-definitions. I trie= d to now consolidate all input into a new version of the document (link bel= ow). I'm not commenting every single mail, although mostly I replied to eac= h mail. High level, I tried to capture the discussions in this way:=20 1. Coexistence with config / other management paradigms.=20 There was a lot of discussion around what takes priority, autonomic behavio= ur or config. I believe we have consensus that config always overrides auto= nomic behaviour. There was some discussion about "emergency disable" in cas= e an autonomic function gets into unknown conditions. The consensus I think= is that we do NOT want an automatic shut-down in such cases, because it ad= ds even more uncertainty to the network.=20 This is highly important, so I felt the best way to capture this discussion= was to introduce a new section in the design goals on co-existence. Sectio= n 3.2.=20 In the definitions, for intent, I now point to this section, because the qu= estion arose also at this point.=20 The document -01 states "Fully Autonomic Node: A node which employs exclusi= vely autonomic functions. It requires no configuration." I expanded that no= w with "It requires (!) no configuration. Note that configuration can be us= ed to override an autonomic function. See fo= r more details." 2. What is a "fully autonomic network". Some folks commented that autonomic =3D self-management =3D self-CHOP (conf= iguring, healing, optimising, protecting), and that a truly autonomic funct= ion MUST contain all four elements.=20 I suggest that we don't become too rigid in our argumentation, but leave a = bit of flexibility in the definitions. My arguments are:=20 A) there is no generally accepted, precise definition of which self-propert= ies must be present in a system so that it can be called "autonomic". The K= ephart paper itself is not clear for starters, while it focuses MAINLY on t= he self-CHOP, it also uses terms "self-maintaining" and "self-governing".=20 The paper cited by Olivier (http://hal.inria.fr/docs/00/53/12/15/PDF/renumb= ering_cameraReadyv2.pdf) leaves out self-healing, but introduces self-monit= oring.=20 Other terms, such as self-discovering, self-learning, etc can be found all = over the literature.=20 Therefore: In the absence of a clear reference I do NOT think it makes sens= e to be too academic on MUST contain self-features.=20 B) I can see implementations of autonomic that do not implement all self-* = properties. For example, in a simple network self-healing may just not be r= elevant. (And indeed, the paper mentioned by Olivier doesn't contain it any= how). Do we really NOT want to call this autonomic? The term "more religiou= s than the pope" comes to mind ;-)=20 I suggest to actually not add too much wording around it in order to not ma= ke it even more confusing. Instead, I will remove the "and" in the definiti= on, so that it reads " Autonomic: Self-managing (self-configuring, self-pro= tecting, self-healing, self-optimizing); however, allowing high-level guida= nce by a central entity, through intent." For practical purposes this shou= ld be ok. Can everyone live with this? If not, can you propose concrete tex= t / changes?=20 3. Changed section title: Simplification of Autonomic Node Northbound Inter= faces (changed from "simplification of the northbound interfaces") (suggest= ion of Benoit).=20 4. difference between automatic and autonomic (request by Benoit): I added = some text in the introduction:=20 There is an important difference between "automatic" and "autonomi= c". "Automatic" refers to a pre-defined, linear process, such as a script. = "Autonomic" is used in the context of self-management. It includes feedback= loops between elements as well as northbound. Comments welcome.=20 5. References. Added two references, and Brian suggested some text around t= his for the intro.=20 6. A clarification that the Autonomic Control Plane can be implemented in t= he global context, or in a separate context (section 7) I believe this should account for all the comments received to date on this= draft. If I missed something, please respond!=20 Michael ---- A new version of I-D, draft-irtf-nmrg-autonomic-network-definitions-02.txt has been successfully submitted by Michael Behringer and posted to the IETF= repository. Name: draft-irtf-nmrg-autonomic-network-definitions Revision: 02 Title: Autonomic Networking - Definitions and Design Goals Document date: 2014-07-28 Group: nmrg Pages: 15 URL: http://www.ietf.org/internet-drafts/draft-irtf-nmrg-autonom= ic-network-definitions-02.txt Status: https://datatracker.ietf.org/doc/draft-irtf-nmrg-autonomic-= network-definitions/ Htmlized: http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-networ= k-definitions-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-irtf-nmrg-autonomi= c-network-definitions-02 Abstract: Autonomic systems were first described in 2001. The fundamental goal is self-management, including self-configuration, self-optimization, self-healing and self-protection. This document applies the concepts of autonomic systems to a network, and describes the definitions and design goals of Autonomic Networking. The high-level goal for an autonomic function is to have minimal dependencies on human administrators or centralized management systems. This usually implies distribution across network elements. From nobody Tue Jul 29 08:51:50 2014 Return-Path: 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 1D9EF1B2952 for ; Tue, 29 Jul 2014 08:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.319 X-Spam-Level: X-Spam-Status: No, score=-0.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, RP_MATCHES_RCVD=-0.001] 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 qFMQR_uIrcKJ for ; Tue, 29 Jul 2014 08:51:46 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA6801B29E9 for ; Tue, 29 Jul 2014 08:49:56 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 2E42847DB400A; Tue, 29 Jul 2014 15:49:52 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s6TFnnwm017315 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jul 2014 17:49:52 +0200 Received: from [172.27.204.45] (135.239.27.40) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 29 Jul 2014 17:49:43 +0200 Message-ID: <53D7C297.3080700@alcatel-lucent.com> Date: Tue, 29 Jul 2014 17:49:43 +0200 From: Laurent Ciavaglia Organization: Alcatel-Lucent Bell Labs France User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , "nmrg@irtf.org" , "anima@ietf.org" References: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BF933F@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BF933F@xmb-rcd-x14.cisco.com> Content-Type: multipart/alternative; boundary="------------060502000500060101080905" X-Originating-IP: [135.239.27.40] Archived-At: http://mailarchive.ietf.org/arch/msg/anima/nx3KnFz1ByBWT1g_rLjSxqtrFQM Cc: "draft-irtf-nmrg-autonomic-network-definitions@tools.ietf.org" Subject: Re: [Anima] Next version of draft-irtf-nmrg-autonomic-network-definitions X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 15:51:49 -0000 --------------060502000500060101080905 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Dear Michael, all, Please find below some remarks/question on point 6: -To what extent is/needs (or not) the control plane to be autonomic? For me the "plane" we are talking below is the set of common control protocols/processes that autonomic functions must/should? support to interwork properly. As a whole, and in parts, this set is not necessarily autonomic. so, it might be worth adding a sentence like "the autonomic control plane is not necessarily autonomic itself". -It is not clear/straightforward what "in the global context of each device" means. If we want to say that the control protocols can run in-band/out-band, let's just say that. -If we agree to keep working on the architectural aspects in NMRG, then, we have to strengthen the NMRG definitions/goals I-D with more architectural aspects or create a dedicated document. Wrt. the state-of-the-art, the content and guidelines of the NMRG document are not enough. As for the architectural model, this is a Pandora box, there has been plenty of models all more or less equals (see the reference you have added for a start). The important thing to agree on are the definitions/terminology, design goals/principles, requirements to design the right protocols(in the IETF WGs). The architectural I-D should allow us to better understand what are the implications/impact of introducing autonomic networking principles/mechanisms to the operations on internet protocols. (at the end of the day, the model is just (another) arbitrary grouping). HTH, best regards, Laurent. On 29/07/2014 16:29, Michael Behringer (mbehring) wrote: > [excuse cross-posting, but I do believe that this is relevant to both lists] > > Anima, NMRG, > > Before and at the IETF there was a lot of discussion around the autonomic paradigms discussed in draft-irtf-nmrg-autonomic-network-definitions. I tried to now consolidate all input into a new version of the document (link below). I'm not commenting every single mail, although mostly I replied to each mail. High level, I tried to capture the discussions in this way: > > 1. Coexistence with config / other management paradigms. > There was a lot of discussion around what takes priority, autonomic behaviour or config. I believe we have consensus that config always overrides autonomic behaviour. There was some discussion about "emergency disable" in case an autonomic function gets into unknown conditions. The consensus I think is that we do NOT want an automatic shut-down in such cases, because it adds even more uncertainty to the network. > This is highly important, so I felt the best way to capture this discussion was to introduce a new section in the design goals on co-existence. Section 3.2. > In the definitions, for intent, I now point to this section, because the question arose also at this point. > > The document -01 states "Fully Autonomic Node: A node which employs exclusively autonomic functions. It requires no configuration." I expanded that now with "It requires (!) no configuration. Note that configuration can be used to override an autonomic function. See for more details." > > 2. What is a "fully autonomic network". > Some folks commented that autonomic = self-management = self-CHOP (configuring, healing, optimising, protecting), and that a truly autonomic function MUST contain all four elements. > I suggest that we don't become too rigid in our argumentation, but leave a bit of flexibility in the definitions. My arguments are: > A) there is no generally accepted, precise definition of which self-properties must be present in a system so that it can be called "autonomic". The Kephart paper itself is not clear for starters, while it focuses MAINLY on the self-CHOP, it also uses terms "self-maintaining" and "self-governing". > The paper cited by Olivier (http://hal.inria.fr/docs/00/53/12/15/PDF/renumbering_cameraReadyv2.pdf) leaves out self-healing, but introduces self-monitoring. > Other terms, such as self-discovering, self-learning, etc can be found all over the literature. > Therefore: In the absence of a clear reference I do NOT think it makes sense to be too academic on MUST contain self-features. > B) I can see implementations of autonomic that do not implement all self-* properties. For example, in a simple network self-healing may just not be relevant. (And indeed, the paper mentioned by Olivier doesn't contain it anyhow). Do we really NOT want to call this autonomic? The term "more religious than the pope" comes to mind ;-) > > I suggest to actually not add too much wording around it in order to not make it even more confusing. Instead, I will remove the "and" in the definition, so that it reads " Autonomic: Self-managing (self-configuring, self-protecting, self-healing, self-optimizing); however, allowing high-level guidance by a central entity, through intent." For practical purposes this should be ok. Can everyone live with this? If not, can you propose concrete text / changes? > > 3. Changed section title: Simplification of Autonomic Node Northbound Interfaces (changed from "simplification of the northbound interfaces") (suggestion of Benoit). > > 4. difference between automatic and autonomic (request by Benoit): I added some text in the introduction: > There is an important difference between "automatic" and "autonomic". "Automatic" refers to a pre-defined, linear process, such as a script. "Autonomic" is used in the context of self-management. It includes feedback loops between elements as well as northbound. > Comments welcome. > > 5. References. Added two references, and Brian suggested some text around this for the intro. > > 6. A clarification that the Autonomic Control Plane can be implemented in the global context, or in a separate context (section 7) > > I believe this should account for all the comments received to date on this draft. If I missed something, please respond! > > Michael > > > ---- > > A new version of I-D, draft-irtf-nmrg-autonomic-network-definitions-02.txt > has been successfully submitted by Michael Behringer and posted to the IETF repository. > > Name: draft-irtf-nmrg-autonomic-network-definitions > Revision: 02 > Title: Autonomic Networking - Definitions and Design Goals > Document date: 2014-07-28 > Group: nmrg > Pages: 15 > URL: http://www.ietf.org/internet-drafts/draft-irtf-nmrg-autonomic-network-definitions-02.txt > Status: https://datatracker.ietf.org/doc/draft-irtf-nmrg-autonomic-network-definitions/ > Htmlized: http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-network-definitions-02 > Diff: http://www.ietf.org/rfcdiff?url2=draft-irtf-nmrg-autonomic-network-definitions-02 > > Abstract: > Autonomic systems were first described in 2001. The fundamental goal > is self-management, including self-configuration, self-optimization, > self-healing and self-protection. > > This document applies the concepts of autonomic systems to a network, > and describes the definitions and design goals of Autonomic > Networking. The high-level goal for an autonomic function is to have > minimal dependencies on human administrators or centralized > management systems. This usually implies distribution across network > elements. > > -- Bien cordialement, Best regards, *Laurent Ciavaglia* Research Manager | Project Manager Network Algorithms, Protocols and Security Group Bell Labs | Alcatel Lucent phone: +33 160 402 636 email: laurent.ciavaglia@alcatel-lucent.com linkedin: laurentciavaglia address: Route de Villejust | 91620 NOZAY | France * English - detected * English * French * English * French --------------060502000500060101080905 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Dear Michael, all,

Please find below some remarks/question on point 6:

-To what extent is/needs (or not) the control plane to be autonomic?
For me the "plane" we are talking below is the set of common control protocols/processes that autonomic functions must/should? support to interwork properly.
As a whole, and in parts, this set is not necessarily autonomic. so, it might be worth adding a sentence like "the autonomic control plane is not necessarily autonomic itself".

-It is not clear/straightforward what "in the global context of each device" means. If we want to say that the control protocols can run in-band/out-band, let's just say that.

-If we agree to keep working on the architectural aspects in NMRG, then, we have to strengthen the NMRG definitions/goals I-D with more architectural aspects or create a dedicated document. Wrt. the state-of-the-art, the content and guidelines of the NMRG document are not enough.
As for the architectural model, this is a Pandora box, there has been plenty of models all more or less equals (see the reference you have added for a start). The important thing to agree on are the definitions/terminology, design goals/principles, requirements to design the right protocols (in the IETF WGs). The architectural I-D should allow us to better understand what are the implications/impact of introducing autonomic networking principles/mechanisms to the operations on internet protocols.
(at the end of the day, the model is just (another) arbitrary grouping).

HTH, best regards, Laurent.

 
On 29/07/2014 16:29, Michael Behringer (mbehring) wrote:
[excuse cross-posting, but I do believe that this is relevant to both lists]

Anima, NMRG, 

Before and at the IETF there was a lot of discussion around the autonomic paradigms discussed in draft-irtf-nmrg-autonomic-network-definitions. I tried to now consolidate all input into a new version of the document (link below). I'm not commenting every single mail, although mostly I replied to each mail. High level, I tried to capture the discussions in this way: 

1. Coexistence with config / other management paradigms. 
There was a lot of discussion around what takes priority, autonomic behaviour or config. I believe we have consensus that config always overrides autonomic behaviour. There was some discussion about "emergency disable" in case an autonomic function gets into unknown conditions. The consensus I think is that we do NOT want an automatic shut-down in such cases, because it adds even more uncertainty to the network. 
This is highly important, so I felt the best way to capture this discussion was to introduce a new section in the design goals on co-existence. Section 3.2. 
In the definitions, for intent, I now point to this section, because the question arose also at this point. 

The document -01 states "Fully Autonomic Node: A node which employs exclusively autonomic functions. It requires no configuration." I expanded that now with "It requires (!) no configuration. Note that configuration can be used to override an autonomic function. See <xref target="coexistence"/> for more details."

2. What is a "fully autonomic network".
Some folks commented that autonomic = self-management = self-CHOP (configuring, healing, optimising, protecting), and that a truly autonomic function MUST contain all four elements. 
I suggest that we don't become too rigid in our argumentation, but leave a bit of flexibility in the definitions. My arguments are: 
A) there is no generally accepted, precise definition of which self-properties must be present in a system so that it can be called "autonomic". The Kephart paper itself is not clear for starters, while it focuses MAINLY on the self-CHOP, it also uses terms "self-maintaining" and "self-governing". 
The paper cited by Olivier (http://hal.inria.fr/docs/00/53/12/15/PDF/renumbering_cameraReadyv2.pdf) leaves out self-healing, but introduces self-monitoring. 
Other terms, such as self-discovering, self-learning, etc can be found all over the literature. 
Therefore: In the absence of a clear reference I do NOT think it makes sense to be too academic on MUST contain self-features. 
B) I can see implementations of autonomic that do not implement all self-* properties. For example, in a simple network self-healing may just not be relevant. (And indeed, the paper mentioned by Olivier doesn't contain it anyhow). Do we really NOT want to call this autonomic? The term "more religious than the pope" comes to mind ;-) 

I suggest to actually not add too much wording around it in order to not make it even more confusing. Instead, I will remove the "and" in the definition, so that it reads " Autonomic: Self-managing (self-configuring, self-protecting, self-healing, self-optimizing); however, allowing high-level guidance by a central entity, through intent."  For practical purposes this should be ok. Can everyone live with this? If not, can you propose concrete text / changes? 

3. Changed section title: Simplification of Autonomic Node Northbound Interfaces (changed from "simplification of the northbound interfaces") (suggestion of Benoit). 

4. difference between automatic and autonomic (request by Benoit): I added some text in the introduction: 
      <t>There is an important difference between "automatic" and "autonomic". "Automatic" refers to a pre-defined, linear process, such as a script. "Autonomic" is used in the context of self-management. It includes feedback loops between elements as well as northbound. </t>
Comments welcome. 

5. References. Added two references, and Brian suggested some text around this for the intro. 

6. A clarification that the Autonomic Control Plane can be implemented in the global context, or in a separate context (section 7)

I believe this should account for all the comments received to date on this draft. If I missed something, please respond! 

Michael


----

A new version of I-D, draft-irtf-nmrg-autonomic-network-definitions-02.txt
has been successfully submitted by Michael Behringer and posted to the IETF repository.

Name:		draft-irtf-nmrg-autonomic-network-definitions
Revision:	02
Title:		Autonomic Networking - Definitions and Design Goals
Document date:	2014-07-28
Group:		nmrg
Pages:		15
URL:            http://www.ietf.org/internet-drafts/draft-irtf-nmrg-autonomic-network-definitions-02.txt
Status:         https://datatracker.ietf.org/doc/draft-irtf-nmrg-autonomic-network-definitions/
Htmlized:       http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-network-definitions-02
Diff:           http://www.ietf.org/rfcdiff?url2=draft-irtf-nmrg-autonomic-network-definitions-02

Abstract:
   Autonomic systems were first described in 2001.  The fundamental goal
   is self-management, including self-configuration, self-optimization,
   self-healing and self-protection.

   This document applies the concepts of autonomic systems to a network,
   and describes the definitions and design goals of Autonomic
   Networking.  The high-level goal for an autonomic function is to have
   minimal dependencies on human administrators or centralized
   management systems.  This usually implies distribution across network
   elements.

--

Bien cordialement, Best regards,

 

Laurent Ciavaglia

Research Manager | Project Manager

Network Algorithms, Protocols and Security Group

Bell Labs | Alcatel Lucent

 

phone: +33 160 402 636

email: laurent.ciavaglia@alcatel-lucent.com

linkedin: laurentciavaglia

address: Route de Villejust | 91620 NOZAY | France

--------------060502000500060101080905-- From nobody Tue Jul 29 13:22:01 2014 Return-Path: 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 A1F871B28E3 for ; Tue, 29 Jul 2014 13:21:58 -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 P3qFMJI1igWu for ; Tue, 29 Jul 2014 13:21:56 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB9311A0AE6 for ; Tue, 29 Jul 2014 13:21:56 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id y10so194699pdj.21 for ; Tue, 29 Jul 2014 13:21:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=j6DkjW6reejzAaHq8ro1bcL18xqGfCJC7B6T7C86wH8=; b=l0Xhpv/EZLw4g3lKyJACyjXw3FidIhg+drYpP+wu5DCQFiRecIHiTXSFGOSOCvcR0D VzmyYYQYfaorn/827jismONtcTOuSQzLSildD9CjwILX5FBuoV46UtSRALmnOfiGRexZ WItLHG0U0SJAhOq3uQVigkHVFw8lBmN+4AuFxAW/kxruDalfA7PJJTfFuV2zAuUcSqJK dBsX9o4sT5ASdbEw6nr/kRCRO+ssmzmiEp3F1Rzq23LI+HTYpXGPVzyeToEyFuAYSYtU YFNYOYJnw8r4mqyQury7avknDplcLk7VOj8n19eKCraYzSL54lE+7pAQ7BdwuEXrZT8J su9w== X-Received: by 10.70.91.73 with SMTP id cc9mr4433171pdb.138.1406665316583; Tue, 29 Jul 2014 13:21:56 -0700 (PDT) Received: from [192.168.178.23] (148.197.69.111.dynamic.snap.net.nz. [111.69.197.148]) by mx.google.com with ESMTPSA id ee5sm10475pbc.47.2014.07.29.13.21.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jul 2014 13:21:55 -0700 (PDT) Message-ID: <53D80265.8070404@gmail.com> Date: Wed, 30 Jul 2014 08:21:57 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Laurent Ciavaglia References: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BF933F@xmb-rcd-x14.cisco.com> <53D7C297.3080700@alcatel-lucent.com> In-Reply-To: <53D7C297.3080700@alcatel-lucent.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/aqTNh89FpXAWxLjGxOdmSRD_fUk Cc: "draft-irtf-nmrg-autonomic-network-definitions@tools.ietf.org" , "nmrg@irtf.org" , "anima@ietf.org" , "Michael Behringer \(mbehring\)" Subject: [Anima] Control plane [was Next version of draft-irtf-nmrg-autonomic-network-definitions] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 20:21:58 -0000 Just commenting on one point from Laurent. I'll stick to cross-posting for this point. In due course I think we should avoid it, but OK for now. > -It is not clear/straightforward what "in the global context of each device" means. If we want to say that the control protocols can run in-band/out-band, let's just say that. Yes, I think we have to be more explicit. One approach is to have an explicit autonomic control plane which is an in-band overlay on the physical network. Another approach is to make this implicit - just use the existing L2/L3 network but without considering it to be a control plane at all (that's what most routing protocols do). A third approach would be a truly separate control plane such as a dedicated L2VPN. The point is that they could all support autonomic behaviour; it's a design choice. Brian From nobody Tue Jul 29 17:58:20 2014 Return-Path: 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 7B2721B29F4 for ; Tue, 29 Jul 2014 17:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_92=0.6, SPF_PASS=-0.001] 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 uBX5Jj--IqjD for ; Tue, 29 Jul 2014 17:58:17 -0700 (PDT) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC35E1B28F8 for ; Tue, 29 Jul 2014 17:58:17 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id g18so498382oah.23 for ; Tue, 29 Jul 2014 17:58:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yXBoM6NPfY//OsIttMpO3dJ0dLUB0TVFnOf726JBhLE=; b=EeT/OSnGGfYhUpnyvoLZkuiCYdmwAdxHSua80zuN6jXsOgBH3XoNd0B8w8wUkYcZ7e RESuNdOe85EsKvtvQgHE5IJkHY+6l8FwvUOlzXH5/pOD6vFqBoNWD7PkZ828jXm5giqJ /EjcGnK2dyMmj0JhT/rg8ItsnZM38yinAJ3l+giX6LTUB4ZjuFoGsVIpTcFDc90No7BU K4vIsBqPmmMLS2QVl7+4ksDSoki9AWsVgkRnhxuoQVcRO6jtVbVt2htiVtAAG72fVbiQ 7NQwF8lxN/XTtNJW6ObPXX3JYWOg3RN20PJ5cXiNlVk5FcUnc8d19EjmILp7ek6kXvKq EGfg== X-Received: by 10.60.70.205 with SMTP id o13mr872247oeu.38.1406681897148; Tue, 29 Jul 2014 17:58:17 -0700 (PDT) Received: from [172.24.60.8] (wireless-nat-21.auckland.ac.nz. [130.216.30.132]) by mx.google.com with ESMTPSA id of9sm1392525obb.25.2014.07.29.17.58.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jul 2014 17:58:16 -0700 (PDT) Message-ID: <53D8432A.5060204@gmail.com> Date: Wed, 30 Jul 2014 12:58:18 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Laurent Ciavaglia References: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BF933F@xmb-rcd-x14.cisco.com> <53D7C297.3080700@alcatel-lucent.com> In-Reply-To: <53D7C297.3080700@alcatel-lucent.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/e7fQ3WCRfjKCmhfJeWYk1LDRRPE Cc: "draft-irtf-nmrg-autonomic-network-definitions@tools.ietf.org" , "nmrg@irtf.org" , "anima@ietf.org" , "Michael Behringer \(mbehring\)" Subject: [Anima] Architecture [was Next version of draft-irtf-nmrg-autonomic-network-definitions] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 00:58:19 -0000 On 30/07/2014 03:49, Laurent Ciavaglia wrote: ... > -If we agree to keep working on the architectural aspects in NMRG, then, > we have to strengthen the NMRG definitions/goals I-D with more > architectural aspects or create a dedicated document. Wrt. the > state-of-the-art, the content and guidelines of the NMRG document are > not enough. > As for the architectural model, this is a Pandora box, there has been > plenty of models all more or less equals (see the reference you have > added for a start). The important thing to agree on are the > definitions/terminology, design goals/principles, requirements to design > the right protocols(in the IETF WGs). The architectural I-D should allow > us to better understand what are the implications/impact of introducing > autonomic networking principles/mechanisms to the operations on internet > protocols. Precisely because it's Pandora's box, I am strongly in favour of making such a document a separate NMRG draft, and keeping the definitions document roughly as it is (so that we can get it finished in the next few weeks, and so that we can rely on it for IETF work). Brian > (at the end of the day, the model is just (another) arbitrary grouping). > > HTH, best regards, Laurent. > > > On 29/07/2014 16:29, Michael Behringer (mbehring) wrote: >> [excuse cross-posting, but I do believe that this is relevant to both >> lists] >> >> Anima, NMRG, >> >> Before and at the IETF there was a lot of discussion around the >> autonomic paradigms discussed in >> draft-irtf-nmrg-autonomic-network-definitions. I tried to now >> consolidate all input into a new version of the document (link below). >> I'm not commenting every single mail, although mostly I replied to >> each mail. High level, I tried to capture the discussions in this way: >> >> 1. Coexistence with config / other management paradigms. >> There was a lot of discussion around what takes priority, autonomic >> behaviour or config. I believe we have consensus that config always >> overrides autonomic behaviour. There was some discussion about >> "emergency disable" in case an autonomic function gets into unknown >> conditions. The consensus I think is that we do NOT want an automatic >> shut-down in such cases, because it adds even more uncertainty to the >> network. >> This is highly important, so I felt the best way to capture this >> discussion was to introduce a new section in the design goals on >> co-existence. Section 3.2. >> In the definitions, for intent, I now point to this section, because >> the question arose also at this point. >> >> The document -01 states "Fully Autonomic Node: A node which employs >> exclusively autonomic functions. It requires no configuration." I >> expanded that now with "It requires (!) no configuration. Note that >> configuration can be used to override an autonomic function. See > target="coexistence"/> for more details." >> >> 2. What is a "fully autonomic network". >> Some folks commented that autonomic = self-management = self-CHOP >> (configuring, healing, optimising, protecting), and that a truly >> autonomic function MUST contain all four elements. >> I suggest that we don't become too rigid in our argumentation, but >> leave a bit of flexibility in the definitions. My arguments are: >> A) there is no generally accepted, precise definition of which >> self-properties must be present in a system so that it can be called >> "autonomic". The Kephart paper itself is not clear for starters, while >> it focuses MAINLY on the self-CHOP, it also uses terms >> "self-maintaining" and "self-governing". >> The paper cited by Olivier >> (http://hal.inria.fr/docs/00/53/12/15/PDF/renumbering_cameraReadyv2.pdf) >> leaves out self-healing, but introduces self-monitoring. >> Other terms, such as self-discovering, self-learning, etc can be found >> all over the literature. >> Therefore: In the absence of a clear reference I do NOT think it makes >> sense to be too academic on MUST contain self-features. >> B) I can see implementations of autonomic that do not implement all >> self-* properties. For example, in a simple network self-healing may >> just not be relevant. (And indeed, the paper mentioned by Olivier >> doesn't contain it anyhow). Do we really NOT want to call this >> autonomic? The term "more religious than the pope" comes to mind ;-) >> >> I suggest to actually not add too much wording around it in order to >> not make it even more confusing. Instead, I will remove the "and" in >> the definition, so that it reads " Autonomic: Self-managing >> (self-configuring, self-protecting, self-healing, self-optimizing); >> however, allowing high-level guidance by a central entity, through >> intent." For practical purposes this should be ok. Can everyone live >> with this? If not, can you propose concrete text / changes? >> >> 3. Changed section title: Simplification of Autonomic Node Northbound >> Interfaces (changed from "simplification of the northbound >> interfaces") (suggestion of Benoit). >> >> 4. difference between automatic and autonomic (request by Benoit): I >> added some text in the introduction: >> There is an important difference between "automatic" and >> "autonomic". "Automatic" refers to a pre-defined, linear process, such >> as a script. "Autonomic" is used in the context of self-management. It >> includes feedback loops between elements as well as northbound. >> Comments welcome. >> >> 5. References. Added two references, and Brian suggested some text >> around this for the intro. >> >> 6. A clarification that the Autonomic Control Plane can be implemented >> in the global context, or in a separate context (section 7) >> >> I believe this should account for all the comments received to date on >> this draft. If I missed something, please respond! >> >> Michael >> >> >> ---- >> >> A new version of I-D, >> draft-irtf-nmrg-autonomic-network-definitions-02.txt >> has been successfully submitted by Michael Behringer and posted to the >> IETF repository. >> >> Name: draft-irtf-nmrg-autonomic-network-definitions >> Revision: 02 >> Title: Autonomic Networking - Definitions and Design Goals >> Document date: 2014-07-28 >> Group: nmrg >> Pages: 15 >> URL: >> http://www.ietf.org/internet-drafts/draft-irtf-nmrg-autonomic-network-definitions-02.txt >> >> Status: >> https://datatracker.ietf.org/doc/draft-irtf-nmrg-autonomic-network-definitions/ >> >> Htmlized: >> http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-network-definitions-02 >> >> Diff: >> http://www.ietf.org/rfcdiff?url2=draft-irtf-nmrg-autonomic-network-definitions-02 >> >> >> Abstract: >> Autonomic systems were first described in 2001. The fundamental goal >> is self-management, including self-configuration, self-optimization, >> self-healing and self-protection. >> >> This document applies the concepts of autonomic systems to a network, >> and describes the definitions and design goals of Autonomic >> Networking. The high-level goal for an autonomic function is to have >> minimal dependencies on human administrators or centralized >> management systems. This usually implies distribution across network >> elements. >> >> > From nobody Tue Jul 29 21:50:58 2014 Return-Path: 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 D47AB1A0880 for ; Tue, 29 Jul 2014 21:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 NdRDA924B42V for ; Tue, 29 Jul 2014 21:50:55 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A888A1A002A for ; Tue, 29 Jul 2014 21:50:54 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id s7so464175lbd.14 for ; Tue, 29 Jul 2014 21:50:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=K97q2Ia0/wdAq3N9CCbzfFvhFtYkhdrGCZl5BoKq8WQ=; b=ztpVzRZgl1myyrRWKgHe0tQ72mgJIJPgfPus8SyM65Srd8HkRm+T+WW/r1TopJ90lb kda16MO1uDoUdMwaA8mnpkfh9E4KEl9jZOyNwt5MfuSa1zxWm2EbUFteVmPet8IOzSPB 9VbKBLjAdog+wIf2SStdj2QER31iTPbtkcxNyFeHFdxHE8zklkORXgLKw4cJfZSvwghe bNWFVfrdnxjc/w0+efAa0EXwLnYtlMiXjnwofXYxR+Q/uxvo5feBb+8JmsJJD+Ua9UNl rlZml9SHrYlpypgWDwveqdejBhwAp9VasyTOPxk9A59uFmK3cEPKNl010bernYte2WFQ XRWQ== MIME-Version: 1.0 X-Received: by 10.112.255.36 with SMTP id an4mr1327383lbd.31.1406695852902; Tue, 29 Jul 2014 21:50:52 -0700 (PDT) Sender: jeferson.nobre@gmail.com Received: by 10.112.3.2 with HTTP; Tue, 29 Jul 2014 21:50:52 -0700 (PDT) In-Reply-To: <53D3A616.5090401@gmail.com> References: <53D3A616.5090401@gmail.com> Date: Wed, 30 Jul 2014 01:50:52 -0300 X-Google-Sender-Auth: f3EL0xZnUfmDUSbOXdsow79CYWo Message-ID: From: =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/anima/KGXArpYY-fJfBPyNuoweAgAd7xw Cc: anima@ietf.org Subject: Re: [Anima] AN and I2RS X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 04:50:57 -0000 Hi, Inline comments. Cheers. J=C3=A9ferson On Sat, Jul 26, 2014 at 9:59 AM, Brian E Carpenter wrote: > Hi, > > It was mentioned during the UCAN BOF that we should consider any > relationship to I2RS. While waiting to check out of the hotel > later this morning, I have quickly glanced at the I2RS architecture > (http://tools.ietf.org/html/draft-ietf-i2rs-architecture-05). > > One aspect is how a future I2RS instance could interact with AN. > I2RS says: > >> Routing Element: A Routing Element implements some subset of the >> routing system. It does not need to have a forwarding plane >> associated with it. Examples of Routing Elements can include: >> >> * A router with a forwarding plane and RIB Manager that runs >> ISIS, OSPF, BGP, PIM, etc., >> >> * A BGP speaker acting as a Route Reflector, >> >> * An LSR that implements RSVP-TE, OSPF-TE, and PCEP and has a >> forwarding plane and associated RIB Manager, >> >> * A server that runs ISIS, OSPF, BGP and uses ForCES to control a >> remote forwarding plane, >> >> A Routing Element may be locally managed, whether via CLI, SNMP, >> or NETCONF. > > So, I suppose we could argue that an I2RS Routing Element could act > as an Autonomic Networking Service Agent, i.e. it could act as an > interface between the routing system and AN, instead of being > traditionally managed. Do you mean the I2RS agent? For me it seems the Autonomic Networking Service Agent is closer to the I2RS agent (not the routing element as a whole). However, considering this means that the AN agent would need to speak the I2RS protocol... > We could also wonder whether I2RS isn't a nice AN use case, but it's > very complex - the I2RS WG itself is deep into multiple use case > analysis and information model development - to say it bluntly, > ANIMA doesn't need that much complexity right now ;-). BTW, I think the I2RS use case requirements I-D (http://tools.ietf.org/html/draft-hares-i2rs-usecase-reqs-summary-00) can be an example for an integrated use case I-D for ANIMA. They also have several use cases and this I-D gives a consistent view of them regarding the WG (e.g., classes of use cases). > I think it is far too soon to even hypothetically consider whether > I2RS and AN have overlapping protocol requirements. I2RS has a > line its charter: > >> - An analysis of existing IETF and other protocols and encoding >> languages against the requirements. > > but I don't see any sign of an active draft on that topic. Probably it would be also good to have this kind of analysis for ANIMA. For example, an alternative for CDNP was mentioned during the BoF, thus at least the IETF alternatives protocols/mechanisms (if they exist) should be cited in the ANIMA I-Ds. > Unfortunately I didn't get a chance to talk with any of the > I2RS protagonists during the IETF. If anybody here can comment > further, please do so. > > Regards > Brian > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Wed Jul 30 01:45:47 2014 Return-Path: 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 A5EAF1B298A for ; Wed, 30 Jul 2014 01:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable 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 JNYcjzMqAHem for ; Wed, 30 Jul 2014 01:45:39 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9175C1A002D for ; Wed, 30 Jul 2014 01:45:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2936; q=dns/txt; s=iport; t=1406709939; x=1407919539; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=VCWZaO5qqqdon52MC6etQjD/WruyzxsYG5OREYRsPrg=; b=O8OOuHT88CtkSxLu0MKhOm3K4F8xUuZ2IPNo+DHtVOfgtowpE5kw1yOz +uJ762s3hPb1rd4JcG/QabFX4DVd/ZM7iS3whxJBv8+krw7ijE1z7cSO/ 4h8f/MhOgerxQaAo0uvqU25K4lHXAoYc8VoIO7PmO6qIAqAvjee9GhkgA s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsFAByw2FOtJV2Q/2dsb2JhbABZgw6BKQSCdNACARl1FneEAwEBAQMBIxFFBQcEAgEIEQQBAQMCBh0DAgICHxEUAQgIAgQBDQUIiCYDCQioGZBWDYcJF4Esi3OBfDEHBoJzNoEbAQSZT5AwhiWCA4FGbAGBRA X-IronPort-AV: E=Sophos;i="5.01,762,1400025600"; d="scan'208";a="343771660" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-7.cisco.com with ESMTP; 30 Jul 2014 08:45:39 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s6U8jcQv001022 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Jul 2014 08:45:38 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.221]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Wed, 30 Jul 2014 03:45:38 -0500 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , Laurent Ciavaglia Thread-Topic: Control plane [was Next version of draft-irtf-nmrg-autonomic-network-definitions] Thread-Index: AQHPq2rA3rMubLfWP0mlRS/Nd/Fr5Zu4PF+Q Date: Wed, 30 Jul 2014 08:45:37 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BFA22A@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BF933F@xmb-rcd-x14.cisco.com> <53D7C297.3080700@alcatel-lucent.com> <53D80265.8070404@gmail.com> In-Reply-To: <53D80265.8070404@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.72.28] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/anima/lrOkwWdonrY215_8LivwSUyD3fg Cc: "draft-irtf-nmrg-autonomic-network-definitions@tools.ietf.org" , "nmrg@irtf.org" , "anima@ietf.org" Subject: Re: [Anima] Control plane [was Next version of draft-irtf-nmrg-autonomic-network-definitions] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 08:45:44 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBb bWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbV0NCj4gU2VudDogMjkgSnVseSAyMDE0 IDIyOjIyDQo+IFRvOiBMYXVyZW50IENpYXZhZ2xpYQ0KPiBDYzogTWljaGFlbCBCZWhyaW5nZXIg KG1iZWhyaW5nKTsgbm1yZ0BpcnRmLm9yZzsgYW5pbWFAaWV0Zi5vcmc7IGRyYWZ0LQ0KPiBpcnRm LW5tcmctYXV0b25vbWljLW5ldHdvcmstZGVmaW5pdGlvbnNAdG9vbHMuaWV0Zi5vcmcNCj4gU3Vi amVjdDogQ29udHJvbCBwbGFuZSBbd2FzIE5leHQgdmVyc2lvbiBvZiBkcmFmdC1pcnRmLW5tcmct YXV0b25vbWljLQ0KPiBuZXR3b3JrLWRlZmluaXRpb25zXQ0KPiANCj4gSnVzdCBjb21tZW50aW5n IG9uIG9uZSBwb2ludCBmcm9tIExhdXJlbnQuIEknbGwgc3RpY2sgdG8gY3Jvc3MtcG9zdGluZyBm b3INCj4gdGhpcyBwb2ludC4gSW4gZHVlIGNvdXJzZSBJIHRoaW5rIHdlIHNob3VsZCBhdm9pZCBp dCwgYnV0IE9LIGZvciBub3cuDQo+IA0KPiA+IC1JdCBpcyBub3QgY2xlYXIvc3RyYWlnaHRmb3J3 YXJkIHdoYXQgImluIHRoZSBnbG9iYWwgY29udGV4dCBvZiBlYWNoIGRldmljZSINCj4gbWVhbnMu IElmIHdlIHdhbnQgdG8gc2F5IHRoYXQgdGhlIGNvbnRyb2wgcHJvdG9jb2xzIGNhbiBydW4gaW4t YmFuZC9vdXQtDQo+IGJhbmQsIGxldCdzIGp1c3Qgc2F5IHRoYXQuDQo+IA0KPiBZZXMsIEkgdGhp bmsgd2UgaGF2ZSB0byBiZSBtb3JlIGV4cGxpY2l0LiBPbmUgYXBwcm9hY2ggaXMgdG8gaGF2ZSBh biBleHBsaWNpdA0KPiBhdXRvbm9taWMgY29udHJvbCBwbGFuZSB3aGljaCBpcyBhbiBpbi1iYW5k IG92ZXJsYXkgb24gdGhlIHBoeXNpY2FsDQo+IG5ldHdvcmsuIEFub3RoZXIgYXBwcm9hY2ggaXMg dG8gbWFrZSB0aGlzIGltcGxpY2l0IC0ganVzdCB1c2UgdGhlIGV4aXN0aW5nDQo+IEwyL0wzIG5l dHdvcmsgYnV0IHdpdGhvdXQgY29uc2lkZXJpbmcgaXQgdG8gYmUgYSBjb250cm9sIHBsYW5lIGF0 IGFsbCAodGhhdCdzDQo+IHdoYXQgbW9zdCByb3V0aW5nIHByb3RvY29scyBkbykuIEEgdGhpcmQg YXBwcm9hY2ggd291bGQgYmUgYSB0cnVseSBzZXBhcmF0ZQ0KPiBjb250cm9sIHBsYW5lIHN1Y2gg YXMgYSBkZWRpY2F0ZWQgTDJWUE4uIFRoZSBwb2ludCBpcyB0aGF0IHRoZXkgY291bGQgYWxsDQo+ IHN1cHBvcnQgYXV0b25vbWljIGJlaGF2aW91cjsgaXQncyBhIGRlc2lnbiBjaG9pY2UuDQoNClN1 Z2dlc3Rpb25zIGZvciBiZXR0ZXIgd29yZGluZyBpcyB3ZWxjb21lLiBGb3IgYSBMMyBkZXZpY2Ug aXQncyByZWxhdGl2ZWx5IGNsZWFyOiBJdCdzIGVpdGhlciB0aGUgZ2xvYmFsIHJvdXRpbmcgdGFi bGUgb3IgYSB2aXJ0dWFsIHJvdXRpbmcgdGFibGUsIHN1Y2ggYXMgYSBWUkYsIG9yIGEgdmlydHVh bCByb3V0ZXIuIFByb2JsZW0gaXMgdGhhdCB0aGUgY29uY2VwdCBvZiB0aGUgQXV0b25vbWljIENv bnRyb2wgUGxhbmUgYXMgZGVzY3JpYmVkIGluIGRyYWZ0LWJlaHJpbmdlci1hdXRvbm9taWMtY29u dHJvbC1wbGFuZSBhcHBsaWVzIGFsc28gdG8gbm9uLUwzIGRldmljZXMsIGZvciBleGFtcGxlIHRv IHN3aXRjaGVzIG9yIE5NUyBzeXN0ZW1zLCBvciAuLi4uIA0KDQpTbywgd2hhdCBpcyB0aGUgZ2Vu ZXJpYyB0ZXJtIGZvciAiZ2xvYmFsIHJvdXRpbmcgdGFibGUiIGFuZCAidmlydHVhbCByb3V0aW5n IHRhYmxlIiB3aGljaCBpcyB2YWxpZCBhbHNvIGZvciBub24tTDMgZGV2aWNlcz8gDQoNClNvLCB0 aGUgZnVsbCByYW5nZSBvZiBvcHRpb25zIGlzOiANCi0gaW5iYW5kLCBhcyB3ZSBydW4gZm9yIGV4 YW1wbGUgSUdQcyB0b2RheQ0KLSBPdmVyIGEgY29uZmlndXJlZCBWUE4gKCJtYW5hZ2VtZW50IFZQ TiIpDQotIE92ZXIgdGhlIHNlbGYtbWFuYWdpbmcgQXV0b25vbWljIENvbnRyb2wgUGxhbmUgKFNl ZSBhYm92ZSBtZW50aW9uZWQgZHJhZnQpDQotIE92ZXIgYSAicmVhbCIgb3V0IG9mIGJhbmQgbmV0 d29yay4gDQoNClNob3VsZCB3ZSBsaXN0IHRob3NlLCBhbmQgZXhwbGFpbiB3aGF0IHRoZXkgZG8g aW4gYSBiaXQgbW9yZSBkZXRhaWw/IE1heWJlIHRoYXQgd291bGQgbWFrZSB0aGluZ3MgY2xlYXJl ci4uLiANCg0KTWljaGFlbA0KIA0KPiAgICAgQnJpYW4NCg== From nobody Wed Jul 30 13:07:49 2014 Return-Path: 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 265061A038B for ; Wed, 30 Jul 2014 13:07:46 -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 grae3aZ9kRvl for ; Wed, 30 Jul 2014 13:07:43 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FB841A0359 for ; Wed, 30 Jul 2014 13:07:42 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id fa1so2148476pad.13 for ; Wed, 30 Jul 2014 13:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=fy+PJ7iRDA6OdKexGZkCBjjBfm+2yAGd8eYXCzMMM88=; b=0yf+GoeiJ+/IruKGl/aZubuhEl33lLwsoxajU7DUSw03YtxK5V0qAeaptLFkmTUZvS KwkS31adsl64lTBeZT5OaZ5OVcYDF7iVKCacy4SSJfzn+uVqWjn72o9XdlstPDzpGk0g eNqvEOY3R/iAHPmfe2bI9pirWMzK3QFQK2cs4wf7/rP8WmUFVUSmm2oswLLgXgZ1YPER U1EQ1bmfVgCrL23oxXIqm7W1U9LCGE/F3Frp9rMUub7JpVinIRqmEYIMAC4dCuay0J6q wvSrBu+Ab/gCPzf+tk5KRJ/3b6iBNJoVF5Rcbyzd8MyIoHPBuEYyVnWP0+rHwudvJ7Rl MDTQ== X-Received: by 10.70.55.227 with SMTP id v3mr6592509pdp.82.1406750861392; Wed, 30 Jul 2014 13:07:41 -0700 (PDT) Received: from [192.168.178.23] (147.199.69.111.dynamic.snap.net.nz. [111.69.199.147]) by mx.google.com with ESMTPSA id z4sm4785222pda.84.2014.07.30.13.07.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 13:07:40 -0700 (PDT) Message-ID: <53D95090.2090904@gmail.com> Date: Thu, 31 Jul 2014 08:07:44 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Michael Behringer (mbehring)" References: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BF933F@xmb-rcd-x14.cisco.com> <53D7C297.3080700@alcatel-lucent.com> <53D80265.8070404@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BFA22A@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BFA22A@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/mm9fRcYb0egj4NGKb0nRL70gn7c Cc: Laurent Ciavaglia , "draft-irtf-nmrg-autonomic-network-definitions@tools.ietf.org" , "nmrg@irtf.org" , "anima@ietf.org" Subject: Re: [Anima] Control plane [was Next version of draft-irtf-nmrg-autonomic-network-definitions] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 20:07:46 -0000 On 30/07/2014 20:45, Michael Behringer (mbehring) wrote: >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: 29 July 2014 22:22 >> To: Laurent Ciavaglia >> Cc: Michael Behringer (mbehring); nmrg@irtf.org; anima@ietf.org; draft- >> irtf-nmrg-autonomic-network-definitions@tools.ietf.org >> Subject: Control plane [was Next version of draft-irtf-nmrg-autonomic- >> network-definitions] >> >> Just commenting on one point from Laurent. I'll stick to cross-posting for >> this point. In due course I think we should avoid it, but OK for now. >> >>> -It is not clear/straightforward what "in the global context of each device" >> means. If we want to say that the control protocols can run in-band/out- >> band, let's just say that. >> >> Yes, I think we have to be more explicit. One approach is to have an explicit >> autonomic control plane which is an in-band overlay on the physical >> network. Another approach is to make this implicit - just use the existing >> L2/L3 network but without considering it to be a control plane at all (that's >> what most routing protocols do). A third approach would be a truly separate >> control plane such as a dedicated L2VPN. The point is that they could all >> support autonomic behaviour; it's a design choice. > > Suggestions for better wording is welcome. For a L3 device it's relatively clear: It's either the global routing table or a virtual routing table, such as a VRF, or a virtual router. Problem is that the concept of the Autonomic Control Plane as described in draft-behringer-autonomic-control-plane applies also to non-L3 devices, for example to switches or NMS systems, or .... > > So, what is the generic term for "global routing table" and "virtual routing table" which is valid also for non-L3 devices? > > So, the full range of options is: > - inband, as we run for example IGPs today > - Over a configured VPN ("management VPN") > - Over the self-managing Autonomic Control Plane (See above mentioned draft) > - Over a "real" out of band network. > > Should we list those, IMHO, we should definitely list them. > and explain what they do in a bit more detail? Maybe that would make things clearer... I'm not sure that is needed in the definitions draft; it might get a bit complicated. But I certainly have no objection to one or two sentences for each one. We should probably avoid pros and cons, since that is not the job of a definition. Brian From nobody Wed Jul 30 15:59:07 2014 Return-Path: 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 9F3211A0242 for ; Wed, 30 Jul 2014 15:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.378 X-Spam-Level: X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, J_CHICKENPOX_92=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 lC7e5DDmL8OY for ; Wed, 30 Jul 2014 15:58:56 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E5001A01E2 for ; Wed, 30 Jul 2014 15:58:55 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id e16so1415092lan.39 for ; Wed, 30 Jul 2014 15:58:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=LMqd2pEjcqcn7pNHgilsKPuW9vS3OZD0iNzlka5nKDQ=; b=ypDEZyJytGbjtlYeZ7Kpuf2GaX42ALZvEFWf+36sLQ5OUJbUzRNu+K7fzJziZRZhSn HSTHGAvSYAGv6O1V0Cxfv36g/ZhFyZB0FjX2Yk835di6TwzqHrcGpexiRpduhxvpCRUQ AZ7lBJM55hnTK3ZPGOlpS+JNHjfmVnWzCMl8l/mu2H8QrCVyHOJIky/TPCsqwP2gG6qK MKg6iY4/uFftwOcazjSFuq6LjhaWKH0wltPBQ1/eaZk9NH6t/oVsawMq8Ue18RMztCdL Om58gbhqRliuV+PV5YKPbY5WGTcUsLJDXVmwwPQRmWoyxpnAsIdCxBc6AUa30T/DLCKN YzlA== MIME-Version: 1.0 X-Received: by 10.152.245.9 with SMTP id xk9mr7948925lac.80.1406761133801; Wed, 30 Jul 2014 15:58:53 -0700 (PDT) Sender: jeferson.nobre@gmail.com Received: by 10.112.3.2 with HTTP; Wed, 30 Jul 2014 15:58:53 -0700 (PDT) In-Reply-To: <53D8432A.5060204@gmail.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BF933F@xmb-rcd-x14.cisco.com> <53D7C297.3080700@alcatel-lucent.com> <53D8432A.5060204@gmail.com> Date: Wed, 30 Jul 2014 19:58:53 -0300 X-Google-Sender-Auth: JOc0rlLKycM6SFY0avzuCs5gqAQ Message-ID: From: =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/anima/5N6fwR-xokBctldJNAYCjp4JEco Cc: Laurent Ciavaglia , "draft-irtf-nmrg-autonomic-network-definitions@tools.ietf.org" , "nmrg@irtf.org" , "Michael Behringer \(mbehring\)" , "anima@ietf.org" Subject: Re: [Anima] Architecture [was Next version of draft-irtf-nmrg-autonomic-network-definitions] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 22:58:59 -0000 On Tue, Jul 29, 2014 at 9:58 PM, Brian E Carpenter wrote: > On 30/07/2014 03:49, Laurent Ciavaglia wrote: > ... >> -If we agree to keep working on the architectural aspects in NMRG, then, >> we have to strengthen the NMRG definitions/goals I-D with more >> architectural aspects or create a dedicated document. Wrt. the >> state-of-the-art, the content and guidelines of the NMRG document are >> not enough. >> As for the architectural model, this is a Pandora box, there has been >> plenty of models all more or less equals (see the reference you have >> added for a start). The important thing to agree on are the >> definitions/terminology, design goals/principles, requirements to design >> the right protocols(in the IETF WGs). The architectural I-D should allow >> us to better understand what are the implications/impact of introducing >> autonomic networking principles/mechanisms to the operations on internet >> protocols. > > Precisely because it's Pandora's box, I am strongly in favour of > making such a document a separate NMRG draft, and keeping the > definitions document roughly as it is (so that we can get it finished > in the next few weeks, and so that we can rely on it for IETF work). +1 > Brian >> (at the end of the day, the model is just (another) arbitrary grouping). >> >> HTH, best regards, Laurent. >> >> >> On 29/07/2014 16:29, Michael Behringer (mbehring) wrote: >>> [excuse cross-posting, but I do believe that this is relevant to both >>> lists] >>> >>> Anima, NMRG, >>> >>> Before and at the IETF there was a lot of discussion around the >>> autonomic paradigms discussed in >>> draft-irtf-nmrg-autonomic-network-definitions. I tried to now >>> consolidate all input into a new version of the document (link below). >>> I'm not commenting every single mail, although mostly I replied to >>> each mail. High level, I tried to capture the discussions in this way: >>> >>> 1. Coexistence with config / other management paradigms. >>> There was a lot of discussion around what takes priority, autonomic >>> behaviour or config. I believe we have consensus that config always >>> overrides autonomic behaviour. There was some discussion about >>> "emergency disable" in case an autonomic function gets into unknown >>> conditions. The consensus I think is that we do NOT want an automatic >>> shut-down in such cases, because it adds even more uncertainty to the >>> network. >>> This is highly important, so I felt the best way to capture this >>> discussion was to introduce a new section in the design goals on >>> co-existence. Section 3.2. >>> In the definitions, for intent, I now point to this section, because >>> the question arose also at this point. >>> >>> The document -01 states "Fully Autonomic Node: A node which employs >>> exclusively autonomic functions. It requires no configuration." I >>> expanded that now with "It requires (!) no configuration. Note that >>> configuration can be used to override an autonomic function. See >> target="coexistence"/> for more details." >>> >>> 2. What is a "fully autonomic network". >>> Some folks commented that autonomic = self-management = self-CHOP >>> (configuring, healing, optimising, protecting), and that a truly >>> autonomic function MUST contain all four elements. >>> I suggest that we don't become too rigid in our argumentation, but >>> leave a bit of flexibility in the definitions. My arguments are: >>> A) there is no generally accepted, precise definition of which >>> self-properties must be present in a system so that it can be called >>> "autonomic". The Kephart paper itself is not clear for starters, while >>> it focuses MAINLY on the self-CHOP, it also uses terms >>> "self-maintaining" and "self-governing". >>> The paper cited by Olivier >>> (http://hal.inria.fr/docs/00/53/12/15/PDF/renumbering_cameraReadyv2.pdf) >>> leaves out self-healing, but introduces self-monitoring. >>> Other terms, such as self-discovering, self-learning, etc can be found >>> all over the literature. >>> Therefore: In the absence of a clear reference I do NOT think it makes >>> sense to be too academic on MUST contain self-features. >>> B) I can see implementations of autonomic that do not implement all >>> self-* properties. For example, in a simple network self-healing may >>> just not be relevant. (And indeed, the paper mentioned by Olivier >>> doesn't contain it anyhow). Do we really NOT want to call this >>> autonomic? The term "more religious than the pope" comes to mind ;-) >>> >>> I suggest to actually not add too much wording around it in order to >>> not make it even more confusing. Instead, I will remove the "and" in >>> the definition, so that it reads " Autonomic: Self-managing >>> (self-configuring, self-protecting, self-healing, self-optimizing); >>> however, allowing high-level guidance by a central entity, through >>> intent." For practical purposes this should be ok. Can everyone live >>> with this? If not, can you propose concrete text / changes? >>> >>> 3. Changed section title: Simplification of Autonomic Node Northbound >>> Interfaces (changed from "simplification of the northbound >>> interfaces") (suggestion of Benoit). >>> >>> 4. difference between automatic and autonomic (request by Benoit): I >>> added some text in the introduction: >>> There is an important difference between "automatic" and >>> "autonomic". "Automatic" refers to a pre-defined, linear process, such >>> as a script. "Autonomic" is used in the context of self-management. It >>> includes feedback loops between elements as well as northbound. >>> Comments welcome. >>> >>> 5. References. Added two references, and Brian suggested some text >>> around this for the intro. >>> >>> 6. A clarification that the Autonomic Control Plane can be implemented >>> in the global context, or in a separate context (section 7) >>> >>> I believe this should account for all the comments received to date on >>> this draft. If I missed something, please respond! >>> >>> Michael >>> >>> >>> ---- >>> >>> A new version of I-D, >>> draft-irtf-nmrg-autonomic-network-definitions-02.txt >>> has been successfully submitted by Michael Behringer and posted to the >>> IETF repository. >>> >>> Name: draft-irtf-nmrg-autonomic-network-definitions >>> Revision: 02 >>> Title: Autonomic Networking - Definitions and Design Goals >>> Document date: 2014-07-28 >>> Group: nmrg >>> Pages: 15 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-irtf-nmrg-autonomic-network-definitions-02.txt >>> >>> Status: >>> https://datatracker.ietf.org/doc/draft-irtf-nmrg-autonomic-network-definitions/ >>> >>> Htmlized: >>> http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-network-definitions-02 >>> >>> Diff: >>> http://www.ietf.org/rfcdiff?url2=draft-irtf-nmrg-autonomic-network-definitions-02 >>> >>> >>> Abstract: >>> Autonomic systems were first described in 2001. The fundamental goal >>> is self-management, including self-configuration, self-optimization, >>> self-healing and self-protection. >>> >>> This document applies the concepts of autonomic systems to a network, >>> and describes the definitions and design goals of Autonomic >>> Networking. The high-level goal for an autonomic function is to have >>> minimal dependencies on human administrators or centralized >>> management systems. This usually implies distribution across network >>> elements. >>> >>> >> > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Wed Jul 30 23:00:46 2014 Return-Path: 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 016181A0276 for ; Wed, 30 Jul 2014 23:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.602 X-Spam-Level: X-Spam-Status: No, score=-3.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 VjQGlTGa51ZM for ; Wed, 30 Jul 2014 23:00:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AAA01A0298 for ; Wed, 30 Jul 2014 23:00:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHT65230; Thu, 31 Jul 2014 06:00:37 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 31 Jul 2014 07:00:36 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.249]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Thu, 31 Jul 2014 14:00:29 +0800 From: Sheng Jiang To: Brian E Carpenter , Laurent Ciavaglia Thread-Topic: [Anima] Architecture [was Next version of draft-irtf-nmrg-autonomic-network-definitions] Thread-Index: AQHPq5Fgjxhpk5UYSEm0tBm7KfAIZ5u5ra+Q Date: Thu, 31 Jul 2014 06:00:29 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AED558F@nkgeml512-mbx.china.huawei.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BF933F@xmb-rcd-x14.cisco.com> <53D7C297.3080700@alcatel-lucent.com> <53D8432A.5060204@gmail.com> In-Reply-To: <53D8432A.5060204@gmail.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/anima/qjF77oiojSmEZrj6jY036wyPpzo Cc: "draft-irtf-nmrg-autonomic-network-definitions@tools.ietf.org" , "nmrg@irtf.org" , "Michael Behringer \(mbehring\)" , "anima@ietf.org" Subject: Re: [Anima] Architecture [was Next version of draft-irtf-nmrg-autonomic-network-definitions] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 06:00:44 -0000 Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogQW5pbWEgW21haWx0bzphbmltYS1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gRQ0KPkNhcnBlbnRlcg0KPg0KPj5P biAzMC8wNy8yMDE0IDAzOjQ5LCBMYXVyZW50IENpYXZhZ2xpYSB3cm90ZToNCj4+Li4uDQo+PiAt SWYgd2UgYWdyZWUgdG8ga2VlcCB3b3JraW5nIG9uIHRoZSBhcmNoaXRlY3R1cmFsIGFzcGVjdHMg aW4gTk1SRywgdGhlbiwNCj4+IHdlIGhhdmUgdG8gc3RyZW5ndGhlbiB0aGUgTk1SRyBkZWZpbml0 aW9ucy9nb2FscyBJLUQgd2l0aCBtb3JlDQo+PiBhcmNoaXRlY3R1cmFsIGFzcGVjdHMgb3IgY3Jl YXRlIGEgZGVkaWNhdGVkIGRvY3VtZW50LiBXcnQuIHRoZQ0KPj4gc3RhdGUtb2YtdGhlLWFydCwg dGhlIGNvbnRlbnQgYW5kIGd1aWRlbGluZXMgb2YgdGhlIE5NUkcgZG9jdW1lbnQgYXJlDQo+PiBu b3QgZW5vdWdoLg0KPj4gQXMgZm9yIHRoZSBhcmNoaXRlY3R1cmFsIG1vZGVsLCB0aGlzIGlzIGEg UGFuZG9yYSBib3gsIHRoZXJlIGhhcyBiZWVuDQo+PiBwbGVudHkgb2YgbW9kZWxzIGFsbCBtb3Jl IG9yIGxlc3MgZXF1YWxzIChzZWUgdGhlIHJlZmVyZW5jZSB5b3UgaGF2ZQ0KPj4gYWRkZWQgZm9y IGEgc3RhcnQpLiBUaGUgaW1wb3J0YW50IHRoaW5nIHRvIGFncmVlIG9uIGFyZSB0aGUNCj4+IGRl ZmluaXRpb25zL3Rlcm1pbm9sb2d5LCBkZXNpZ24gZ29hbHMvcHJpbmNpcGxlcywgcmVxdWlyZW1l bnRzIHRvIGRlc2lnbg0KPj4gdGhlIHJpZ2h0IHByb3RvY29scyhpbiB0aGUgSUVURiBXR3MpLiBU aGUgYXJjaGl0ZWN0dXJhbCBJLUQgc2hvdWxkIGFsbG93DQo+PiB1cyB0byBiZXR0ZXIgdW5kZXJz dGFuZCB3aGF0IGFyZSB0aGUgaW1wbGljYXRpb25zL2ltcGFjdCBvZiBpbnRyb2R1Y2luZw0KPj4g YXV0b25vbWljIG5ldHdvcmtpbmcgcHJpbmNpcGxlcy9tZWNoYW5pc21zIHRvIHRoZSBvcGVyYXRp b25zIG9uIGludGVybmV0DQo+PiBwcm90b2NvbHMuDQo+DQo+UHJlY2lzZWx5IGJlY2F1c2UgaXQn cyBQYW5kb3JhJ3MgYm94LCBJIGFtIHN0cm9uZ2x5IGluIGZhdm91ciBvZg0KPm1ha2luZyBzdWNo IGEgZG9jdW1lbnQgYSBzZXBhcmF0ZSBOTVJHIGRyYWZ0LCBhbmQga2VlcGluZyB0aGUNCj5kZWZp bml0aW9ucyBkb2N1bWVudCByb3VnaGx5IGFzIGl0IGlzIChzbyB0aGF0IHdlIGNhbiBnZXQgaXQg ZmluaXNoZWQNCj5pbiB0aGUgbmV4dCBmZXcgd2Vla3MsIGFuZCBzbyB0aGF0IHdlIGNhbiByZWx5 IG9uIGl0IGZvciBJRVRGIHdvcmspLg0KDQpGdWxseSBhZ3JlZS4gSXQgd291bGQgTk9UIGJlIGVh c3kgdG8gcmVhY2ggY29uc2Vuc3VzIG9uICJ0aGUiIGFyY2hpdGVjdHVyYWwgbW9kZWwuIFRoZXJl IGlzIGEgZ29vZCBjaGFuY2UgdGhhdCB3ZSBtYXkgc3RydWdnbGUgYW5kIHNwZW5kIHRvbyBtdWNo IHRpbWUgb24gYXJjaGl0ZWN0dXJlIGFuZCByZXF1aXJlbWVudHMuIFRoYXQncyBleGFjdGx5IHRo ZSBtZXNzYWdlIGZyb20gT1BTIEFEcyAtIHdlIHNob3VsZCB0cnkgdG8gYXZvaWQgaXQgYW5kIGZv Y3VzIG9uIHNvbHV0aW9ucywgd2hpY2ggbWF5IGJlIHNtYWxsIHN0ZXBzLCBidXQgcmVhbCBzdGVw cyBtb3ZpbmcgZm9yd2FyZC4gQSBzZXBhcmF0ZSBOTVJHIGRyYWZ0IHdpbGwgaXNvbGF0ZSB0aGUg cmlzayB3aXRoaW4gbWluaW11bSBpbXBhY3RzLiBXZSBzaG91bGQgY29tcGxldGUgdGhlIGhpZ2gt bGV2ZWwgY29uY2VwdCB3b3JrcyAoZGVmaW5pdGlvbiBhbmQgZ2FwIGFuYWx5c2lzKSBhcyBzb29u IGFzIHBvc3NpYmxlLCB0aGVuIGZvY3VzIG9uIHByb2R1Y2UgY29kZS1wcm92ZW4gcHJvdG9jb2xz L3NvbHV0aW9ucy4gTWVhbndoaWxlLCBhIHNlcGFyYXRlLCB3aWRlci1zY29wZSBhcmNoaXRlY3R1 cmUgYW5kIHJlcXVpcmVtZW50IGRvY3VtZW50IGluIE5NUkcgaXMgYWxzbyBoZWxwZnVsLiBJdCBj b3VsZCBsZWFkIHVzIG9uIHRoZSBleHBsb3JpbmcgdGhlIHBvdGVudGlhbCBuZXh0IHN0ZXBzIGFm dGVyIHdlIG1ha2UgdGhlIGVuYWJsaW5nIGNvbW1vbiBpbmZyYXN0cnVjdHVyZSBhdmFpbGFibGUu DQoNCkJlc3QgcmVnYXJkcywNCg0KU2hlbmcNCg0KPiAgICBCcmlhbg0KPj4gKGF0IHRoZSBlbmQg b2YgdGhlIGRheSwgdGhlIG1vZGVsIGlzIGp1c3QgKGFub3RoZXIpIGFyYml0cmFyeSBncm91cGlu ZykuDQo+Pg0KPj4gSFRILCBiZXN0IHJlZ2FyZHMsIExhdXJlbnQuDQo+Pg0KPj4NCj4+IE9uIDI5 LzA3LzIwMTQgMTY6MjksIE1pY2hhZWwgQmVocmluZ2VyIChtYmVocmluZykgd3JvdGU6DQo+Pj4g W2V4Y3VzZSBjcm9zcy1wb3N0aW5nLCBidXQgSSBkbyBiZWxpZXZlIHRoYXQgdGhpcyBpcyByZWxl dmFudCB0byBib3RoDQo+Pj4gbGlzdHNdDQo+Pj4NCj4+PiBBbmltYSwgTk1SRywNCj4+Pg0KPj4+ IEJlZm9yZSBhbmQgYXQgdGhlIElFVEYgdGhlcmUgd2FzIGEgbG90IG9mIGRpc2N1c3Npb24gYXJv dW5kIHRoZQ0KPj4+IGF1dG9ub21pYyBwYXJhZGlnbXMgZGlzY3Vzc2VkIGluDQo+Pj4gZHJhZnQt aXJ0Zi1ubXJnLWF1dG9ub21pYy1uZXR3b3JrLWRlZmluaXRpb25zLiBJIHRyaWVkIHRvIG5vdw0K Pj4+IGNvbnNvbGlkYXRlIGFsbCBpbnB1dCBpbnRvIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRvY3Vt ZW50IChsaW5rIGJlbG93KS4NCj4+PiBJJ20gbm90IGNvbW1lbnRpbmcgZXZlcnkgc2luZ2xlIG1h aWwsIGFsdGhvdWdoIG1vc3RseSBJIHJlcGxpZWQgdG8NCj4+PiBlYWNoIG1haWwuIEhpZ2ggbGV2 ZWwsIEkgdHJpZWQgdG8gY2FwdHVyZSB0aGUgZGlzY3Vzc2lvbnMgaW4gdGhpcyB3YXk6DQo+Pj4N Cj4+PiAxLiBDb2V4aXN0ZW5jZSB3aXRoIGNvbmZpZyAvIG90aGVyIG1hbmFnZW1lbnQgcGFyYWRp Z21zLg0KPj4+IFRoZXJlIHdhcyBhIGxvdCBvZiBkaXNjdXNzaW9uIGFyb3VuZCB3aGF0IHRha2Vz IHByaW9yaXR5LCBhdXRvbm9taWMNCj4+PiBiZWhhdmlvdXIgb3IgY29uZmlnLiBJIGJlbGlldmUg d2UgaGF2ZSBjb25zZW5zdXMgdGhhdCBjb25maWcgYWx3YXlzDQo+Pj4gb3ZlcnJpZGVzIGF1dG9u b21pYyBiZWhhdmlvdXIuIFRoZXJlIHdhcyBzb21lIGRpc2N1c3Npb24gYWJvdXQNCj4+PiAiZW1l cmdlbmN5IGRpc2FibGUiIGluIGNhc2UgYW4gYXV0b25vbWljIGZ1bmN0aW9uIGdldHMgaW50byB1 bmtub3duDQo+Pj4gY29uZGl0aW9ucy4gVGhlIGNvbnNlbnN1cyBJIHRoaW5rIGlzIHRoYXQgd2Ug ZG8gTk9UIHdhbnQgYW4gYXV0b21hdGljDQo+Pj4gc2h1dC1kb3duIGluIHN1Y2ggY2FzZXMsIGJl Y2F1c2UgaXQgYWRkcyBldmVuIG1vcmUgdW5jZXJ0YWludHkgdG8gdGhlDQo+Pj4gbmV0d29yay4N Cj4+PiBUaGlzIGlzIGhpZ2hseSBpbXBvcnRhbnQsIHNvIEkgZmVsdCB0aGUgYmVzdCB3YXkgdG8g Y2FwdHVyZSB0aGlzDQo+Pj4gZGlzY3Vzc2lvbiB3YXMgdG8gaW50cm9kdWNlIGEgbmV3IHNlY3Rp b24gaW4gdGhlIGRlc2lnbiBnb2FscyBvbg0KPj4+IGNvLWV4aXN0ZW5jZS4gU2VjdGlvbiAzLjIu DQo+Pj4gSW4gdGhlIGRlZmluaXRpb25zLCBmb3IgaW50ZW50LCBJIG5vdyBwb2ludCB0byB0aGlz IHNlY3Rpb24sIGJlY2F1c2UNCj4+PiB0aGUgcXVlc3Rpb24gYXJvc2UgYWxzbyBhdCB0aGlzIHBv aW50Lg0KPj4+DQo+Pj4gVGhlIGRvY3VtZW50IC0wMSBzdGF0ZXMgIkZ1bGx5IEF1dG9ub21pYyBO b2RlOiBBIG5vZGUgd2hpY2ggZW1wbG95cw0KPj4+IGV4Y2x1c2l2ZWx5IGF1dG9ub21pYyBmdW5j dGlvbnMuIEl0IHJlcXVpcmVzIG5vIGNvbmZpZ3VyYXRpb24uIiBJDQo+Pj4gZXhwYW5kZWQgdGhh dCBub3cgd2l0aCAiSXQgcmVxdWlyZXMgKCEpIG5vIGNvbmZpZ3VyYXRpb24uIE5vdGUgdGhhdA0K Pj4+IGNvbmZpZ3VyYXRpb24gY2FuIGJlIHVzZWQgdG8gb3ZlcnJpZGUgYW4gYXV0b25vbWljIGZ1 bmN0aW9uLiBTZWUgPHhyZWYNCj4+PiB0YXJnZXQ9ImNvZXhpc3RlbmNlIi8+IGZvciBtb3JlIGRl dGFpbHMuIg0KPj4+DQo+Pj4gMi4gV2hhdCBpcyBhICJmdWxseSBhdXRvbm9taWMgbmV0d29yayIu DQo+Pj4gU29tZSBmb2xrcyBjb21tZW50ZWQgdGhhdCBhdXRvbm9taWMgPSBzZWxmLW1hbmFnZW1l bnQgPSBzZWxmLUNIT1ANCj4+PiAoY29uZmlndXJpbmcsIGhlYWxpbmcsIG9wdGltaXNpbmcsIHBy b3RlY3RpbmcpLCBhbmQgdGhhdCBhIHRydWx5DQo+Pj4gYXV0b25vbWljIGZ1bmN0aW9uIE1VU1Qg Y29udGFpbiBhbGwgZm91ciBlbGVtZW50cy4NCj4+PiBJIHN1Z2dlc3QgdGhhdCB3ZSBkb24ndCBi ZWNvbWUgdG9vIHJpZ2lkIGluIG91ciBhcmd1bWVudGF0aW9uLCBidXQNCj4+PiBsZWF2ZSBhIGJp dCBvZiBmbGV4aWJpbGl0eSBpbiB0aGUgZGVmaW5pdGlvbnMuIE15IGFyZ3VtZW50cyBhcmU6DQo+ Pj4gQSkgdGhlcmUgaXMgbm8gZ2VuZXJhbGx5IGFjY2VwdGVkLCBwcmVjaXNlIGRlZmluaXRpb24g b2Ygd2hpY2gNCj4+PiBzZWxmLXByb3BlcnRpZXMgbXVzdCBiZSBwcmVzZW50IGluIGEgc3lzdGVt IHNvIHRoYXQgaXQgY2FuIGJlIGNhbGxlZA0KPj4+ICJhdXRvbm9taWMiLiBUaGUgS2VwaGFydCBw YXBlciBpdHNlbGYgaXMgbm90IGNsZWFyIGZvciBzdGFydGVycywgd2hpbGUNCj4+PiBpdCBmb2N1 c2VzIE1BSU5MWSBvbiB0aGUgc2VsZi1DSE9QLCBpdCBhbHNvIHVzZXMgdGVybXMNCj4+PiAic2Vs Zi1tYWludGFpbmluZyIgYW5kICJzZWxmLWdvdmVybmluZyIuDQo+Pj4gVGhlIHBhcGVyIGNpdGVk IGJ5IE9saXZpZXINCj4+Pg0KPihodHRwOi8vaGFsLmlucmlhLmZyL2RvY3MvMDAvNTMvMTIvMTUv UERGL3JlbnVtYmVyaW5nX2NhbWVyYVJlYWR5djIucGRmKQ0KPj4+IGxlYXZlcyBvdXQgc2VsZi1o ZWFsaW5nLCBidXQgaW50cm9kdWNlcyBzZWxmLW1vbml0b3JpbmcuDQo+Pj4gT3RoZXIgdGVybXMs IHN1Y2ggYXMgc2VsZi1kaXNjb3ZlcmluZywgc2VsZi1sZWFybmluZywgZXRjIGNhbiBiZSBmb3Vu ZA0KPj4+IGFsbCBvdmVyIHRoZSBsaXRlcmF0dXJlLg0KPj4+IFRoZXJlZm9yZTogSW4gdGhlIGFi c2VuY2Ugb2YgYSBjbGVhciByZWZlcmVuY2UgSSBkbyBOT1QgdGhpbmsgaXQgbWFrZXMNCj4+PiBz ZW5zZSB0byBiZSB0b28gYWNhZGVtaWMgb24gTVVTVCBjb250YWluIHNlbGYtZmVhdHVyZXMuDQo+ Pj4gQikgSSBjYW4gc2VlIGltcGxlbWVudGF0aW9ucyBvZiBhdXRvbm9taWMgdGhhdCBkbyBub3Qg aW1wbGVtZW50IGFsbA0KPj4+IHNlbGYtKiBwcm9wZXJ0aWVzLiBGb3IgZXhhbXBsZSwgaW4gYSBz aW1wbGUgbmV0d29yayBzZWxmLWhlYWxpbmcgbWF5DQo+Pj4ganVzdCBub3QgYmUgcmVsZXZhbnQu IChBbmQgaW5kZWVkLCB0aGUgcGFwZXIgbWVudGlvbmVkIGJ5IE9saXZpZXINCj4+PiBkb2Vzbid0 IGNvbnRhaW4gaXQgYW55aG93KS4gRG8gd2UgcmVhbGx5IE5PVCB3YW50IHRvIGNhbGwgdGhpcw0K Pj4+IGF1dG9ub21pYz8gVGhlIHRlcm0gIm1vcmUgcmVsaWdpb3VzIHRoYW4gdGhlIHBvcGUiIGNv bWVzIHRvIG1pbmQgOy0pDQo+Pj4NCj4+PiBJIHN1Z2dlc3QgdG8gYWN0dWFsbHkgbm90IGFkZCB0 b28gbXVjaCB3b3JkaW5nIGFyb3VuZCBpdCBpbiBvcmRlciB0bw0KPj4+IG5vdCBtYWtlIGl0IGV2 ZW4gbW9yZSBjb25mdXNpbmcuIEluc3RlYWQsIEkgd2lsbCByZW1vdmUgdGhlICJhbmQiIGluDQo+ Pj4gdGhlIGRlZmluaXRpb24sIHNvIHRoYXQgaXQgcmVhZHMgIiBBdXRvbm9taWM6IFNlbGYtbWFu YWdpbmcNCj4+PiAoc2VsZi1jb25maWd1cmluZywgc2VsZi1wcm90ZWN0aW5nLCBzZWxmLWhlYWxp bmcsIHNlbGYtb3B0aW1pemluZyk7DQo+Pj4gaG93ZXZlciwgYWxsb3dpbmcgaGlnaC1sZXZlbCBn dWlkYW5jZSBieSBhIGNlbnRyYWwgZW50aXR5LCB0aHJvdWdoDQo+Pj4gaW50ZW50LiIgIEZvciBw cmFjdGljYWwgcHVycG9zZXMgdGhpcyBzaG91bGQgYmUgb2suIENhbiBldmVyeW9uZSBsaXZlDQo+ Pj4gd2l0aCB0aGlzPyBJZiBub3QsIGNhbiB5b3UgcHJvcG9zZSBjb25jcmV0ZSB0ZXh0IC8gY2hh bmdlcz8NCj4+Pg0KPj4+IDMuIENoYW5nZWQgc2VjdGlvbiB0aXRsZTogU2ltcGxpZmljYXRpb24g b2YgQXV0b25vbWljIE5vZGUgTm9ydGhib3VuZA0KPj4+IEludGVyZmFjZXMgKGNoYW5nZWQgZnJv bSAic2ltcGxpZmljYXRpb24gb2YgdGhlIG5vcnRoYm91bmQNCj4+PiBpbnRlcmZhY2VzIikgKHN1 Z2dlc3Rpb24gb2YgQmVub2l0KS4NCj4+Pg0KPj4+IDQuIGRpZmZlcmVuY2UgYmV0d2VlbiBhdXRv bWF0aWMgYW5kIGF1dG9ub21pYyAocmVxdWVzdCBieSBCZW5vaXQpOiBJDQo+Pj4gYWRkZWQgc29t ZSB0ZXh0IGluIHRoZSBpbnRyb2R1Y3Rpb246DQo+Pj4gICAgICAgIDx0PlRoZXJlIGlzIGFuIGlt cG9ydGFudCBkaWZmZXJlbmNlIGJldHdlZW4gImF1dG9tYXRpYyIgYW5kDQo+Pj4gImF1dG9ub21p YyIuICJBdXRvbWF0aWMiIHJlZmVycyB0byBhIHByZS1kZWZpbmVkLCBsaW5lYXIgcHJvY2Vzcywg c3VjaA0KPj4+IGFzIGEgc2NyaXB0LiAiQXV0b25vbWljIiBpcyB1c2VkIGluIHRoZSBjb250ZXh0 IG9mIHNlbGYtbWFuYWdlbWVudC4gSXQNCj4+PiBpbmNsdWRlcyBmZWVkYmFjayBsb29wcyBiZXR3 ZWVuIGVsZW1lbnRzIGFzIHdlbGwgYXMgbm9ydGhib3VuZC4gPC90Pg0KPj4+IENvbW1lbnRzIHdl bGNvbWUuDQo+Pj4NCj4+PiA1LiBSZWZlcmVuY2VzLiBBZGRlZCB0d28gcmVmZXJlbmNlcywgYW5k IEJyaWFuIHN1Z2dlc3RlZCBzb21lIHRleHQNCj4+PiBhcm91bmQgdGhpcyBmb3IgdGhlIGludHJv Lg0KPj4+DQo+Pj4gNi4gQSBjbGFyaWZpY2F0aW9uIHRoYXQgdGhlIEF1dG9ub21pYyBDb250cm9s IFBsYW5lIGNhbiBiZSBpbXBsZW1lbnRlZA0KPj4+IGluIHRoZSBnbG9iYWwgY29udGV4dCwgb3Ig aW4gYSBzZXBhcmF0ZSBjb250ZXh0IChzZWN0aW9uIDcpDQo+Pj4NCj4+PiBJIGJlbGlldmUgdGhp cyBzaG91bGQgYWNjb3VudCBmb3IgYWxsIHRoZSBjb21tZW50cyByZWNlaXZlZCB0byBkYXRlIG9u DQo+Pj4gdGhpcyBkcmFmdC4gSWYgSSBtaXNzZWQgc29tZXRoaW5nLCBwbGVhc2UgcmVzcG9uZCEN Cj4+Pg0KPj4+IE1pY2hhZWwNCj4+Pg0KPj4+DQo+Pj4gLS0tLQ0KPj4+DQo+Pj4gQSBuZXcgdmVy c2lvbiBvZiBJLUQsDQo+Pj4gZHJhZnQtaXJ0Zi1ubXJnLWF1dG9ub21pYy1uZXR3b3JrLWRlZmlu aXRpb25zLTAyLnR4dA0KPj4+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTWlj aGFlbCBCZWhyaW5nZXIgYW5kIHBvc3RlZCB0byB0aGUNCj4+PiBJRVRGIHJlcG9zaXRvcnkuDQo+ Pj4NCj4+PiBOYW1lOiAgICAgICAgZHJhZnQtaXJ0Zi1ubXJnLWF1dG9ub21pYy1uZXR3b3JrLWRl ZmluaXRpb25zDQo+Pj4gUmV2aXNpb246ICAgIDAyDQo+Pj4gVGl0bGU6ICAgICAgICBBdXRvbm9t aWMgTmV0d29ya2luZyAtIERlZmluaXRpb25zIGFuZCBEZXNpZ24gR29hbHMNCj4+PiBEb2N1bWVu dCBkYXRlOiAgICAyMDE0LTA3LTI4DQo+Pj4gR3JvdXA6ICAgICAgICBubXJnDQo+Pj4gUGFnZXM6 ICAgICAgICAxNQ0KPj4+IFVSTDoNCj4+Pg0KPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWlydGYtbm1yZy1hdXRvbm9taWMtbmV0d29yay1kZWZpDQo+bml0aW9ucy0w Mi50eHQNCj4+Pg0KPj4+IFN0YXR1czoNCj4+Pg0KPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlydGYtbm1yZy1hdXRvbm9taWMtbmV0d29yay1kZWZpbml0aW8NCj5ucy8N Cj4+Pg0KPj4+IEh0bWxpemVkOg0KPj4+DQo+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaXJ0Zi1ubXJnLWF1dG9ub21pYy1uZXR3b3JrLWRlZmluaXRpb25zLTAyDQo+Pj4NCj4+PiBE aWZmOg0KPj4+DQo+aHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaXJ0Zi1u bXJnLWF1dG9ub21pYy1uZXR3b3JrLWRlZmluaXRpDQo+b25zLTAyDQo+Pj4NCj4+Pg0KPj4+IEFi c3RyYWN0Og0KPj4+ICAgICBBdXRvbm9taWMgc3lzdGVtcyB3ZXJlIGZpcnN0IGRlc2NyaWJlZCBp biAyMDAxLiAgVGhlIGZ1bmRhbWVudGFsDQo+Z29hbA0KPj4+ICAgICBpcyBzZWxmLW1hbmFnZW1l bnQsIGluY2x1ZGluZyBzZWxmLWNvbmZpZ3VyYXRpb24sIHNlbGYtb3B0aW1pemF0aW9uLA0KPj4+ ICAgICBzZWxmLWhlYWxpbmcgYW5kIHNlbGYtcHJvdGVjdGlvbi4NCj4+Pg0KPj4+ICAgICBUaGlz IGRvY3VtZW50IGFwcGxpZXMgdGhlIGNvbmNlcHRzIG9mIGF1dG9ub21pYyBzeXN0ZW1zIHRvIGEN Cj5uZXR3b3JrLA0KPj4+ICAgICBhbmQgZGVzY3JpYmVzIHRoZSBkZWZpbml0aW9ucyBhbmQgZGVz aWduIGdvYWxzIG9mIEF1dG9ub21pYw0KPj4+ICAgICBOZXR3b3JraW5nLiAgVGhlIGhpZ2gtbGV2 ZWwgZ29hbCBmb3IgYW4gYXV0b25vbWljIGZ1bmN0aW9uIGlzIHRvDQo+aGF2ZQ0KPj4+ICAgICBt aW5pbWFsIGRlcGVuZGVuY2llcyBvbiBodW1hbiBhZG1pbmlzdHJhdG9ycyBvciBjZW50cmFsaXpl ZA0KPj4+ICAgICBtYW5hZ2VtZW50IHN5c3RlbXMuICBUaGlzIHVzdWFsbHkgaW1wbGllcyBkaXN0 cmlidXRpb24gYWNyb3NzDQo+bmV0d29yaw0KPj4+ICAgICBlbGVtZW50cy4NCj4+Pg0KPj4+DQo+ Pg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ QW5pbWEgbWFpbGluZyBsaXN0DQo+QW5pbWFAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hDQo= From nobody Thu Jul 31 00:35:25 2014 Return-Path: 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 708AE1A0397 for ; Thu, 31 Jul 2014 00:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 hbbT5poU9nsK for ; Thu, 31 Jul 2014 00:35:19 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31EDC1A0377 for ; Thu, 31 Jul 2014 00:35:19 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id E88D9DE1A8ED8; Thu, 31 Jul 2014 07:35:14 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s6V7ZEKf030807 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Jul 2014 09:35:15 +0200 Received: from [172.27.204.75] (135.239.27.40) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 31 Jul 2014 09:35:14 +0200 Message-ID: <53D9F1B2.7020802@alcatel-lucent.com> Date: Thu, 31 Jul 2014 09:35:14 +0200 From: Laurent Ciavaglia Organization: Alcatel-Lucent Bell Labs France User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brian E Carpenter , "Michael Behringer (mbehring)" References: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BF933F@xmb-rcd-x14.cisco.com> <53D7C297.3080700@alcatel-lucent.com> <53D80265.8070404@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BFA22A@xmb-rcd-x14.cisco.com> <53D95090.2090904@gmail.com> In-Reply-To: <53D95090.2090904@gmail.com> Content-Type: multipart/alternative; boundary="------------020901000909080205010804" X-Originating-IP: [135.239.27.40] Archived-At: http://mailarchive.ietf.org/arch/msg/anima/UiSSoJT60t1hZLEA-ax3Ak2vR1o Cc: "draft-irtf-nmrg-autonomic-network-definitions@tools.ietf.org" , "nmrg@irtf.org" , "anima@ietf.org" Subject: Re: [Anima] Control plane [was Next version of draft-irtf-nmrg-autonomic-network-definitions] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 07:35:22 -0000 --------------020901000909080205010804 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Hi, Isn't there some ITU-T Rec defining such options? i.e. we could cite/re-use these agreed definitions. I will check... but if someone has some pointers, feel free to share them. Best regards, Laurent. On 30/07/2014 22:07, Brian E Carpenter wrote: > On 30/07/2014 20:45, Michael Behringer (mbehring) wrote: >>> -----Original Message----- >>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >>> Sent: 29 July 2014 22:22 >>> To: Laurent Ciavaglia >>> Cc: Michael Behringer (mbehring); nmrg@irtf.org; anima@ietf.org; draft- >>> irtf-nmrg-autonomic-network-definitions@tools.ietf.org >>> Subject: Control plane [was Next version of draft-irtf-nmrg-autonomic- >>> network-definitions] >>> >>> Just commenting on one point from Laurent. I'll stick to cross-posting for >>> this point. In due course I think we should avoid it, but OK for now. >>> >>>> -It is not clear/straightforward what "in the global context of each device" >>> means. If we want to say that the control protocols can run in-band/out- >>> band, let's just say that. >>> >>> Yes, I think we have to be more explicit. One approach is to have an explicit >>> autonomic control plane which is an in-band overlay on the physical >>> network. Another approach is to make this implicit - just use the existing >>> L2/L3 network but without considering it to be a control plane at all (that's >>> what most routing protocols do). A third approach would be a truly separate >>> control plane such as a dedicated L2VPN. The point is that they could all >>> support autonomic behaviour; it's a design choice. >> Suggestions for better wording is welcome. For a L3 device it's relatively clear: It's either the global routing table or a virtual routing table, such as a VRF, or a virtual router. Problem is that the concept of the Autonomic Control Plane as described in draft-behringer-autonomic-control-plane applies also to non-L3 devices, for example to switches or NMS systems, or .... >> >> So, what is the generic term for "global routing table" and "virtual routing table" which is valid also for non-L3 devices? >> >> So, the full range of options is: >> - inband, as we run for example IGPs today >> - Over a configured VPN ("management VPN") >> - Over the self-managing Autonomic Control Plane (See above mentioned draft) >> - Over a "real" out of band network. >> >> Should we list those, > IMHO, we should definitely list them. > >> and explain what they do in a bit more detail? Maybe that would make things clearer... > I'm not sure that is needed in the definitions draft; it might get a bit > complicated. But I certainly have no objection to one or two sentences > for each one. We should probably avoid pros and cons, since that is > not the job of a definition. > > Brian > -- Bien cordialement, Best regards, *Laurent Ciavaglia* Research Manager | Project Manager Network Algorithms, Protocols and Security Group Bell Labs | Alcatel Lucent phone: +33 160 402 636 email: laurent.ciavaglia@alcatel-lucent.com linkedin: laurentciavaglia address: Route de Villejust | 91620 NOZAY | France --------------020901000909080205010804 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit Hi,

Isn't there some ITU-T Rec defining such options? i.e. we could cite/re-use these agreed definitions. I will check... but if someone has some pointers, feel free to share them.

Best regards, Laurent.
On 30/07/2014 22:07, Brian E Carpenter wrote:
On 30/07/2014 20:45, Michael Behringer (mbehring) wrote:

-----Original Message-----
From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
Sent: 29 July 2014 22:22
To: Laurent Ciavaglia
Cc: Michael Behringer (mbehring); nmrg@irtf.org; anima@ietf.org; draft-
irtf-nmrg-autonomic-network-definitions@tools.ietf.org
Subject: Control plane [was Next version of draft-irtf-nmrg-autonomic-
network-definitions]

Just commenting on one point from Laurent. I'll stick to cross-posting for
this point. In due course I think we should avoid it, but OK for now.


-It is not clear/straightforward what "in the global context of each device"

means. If we want to say that the control protocols can run in-band/out-
band, let's just say that.

Yes, I think we have to be more explicit. One approach is to have an explicit
autonomic control plane which is an in-band overlay on the physical
network. Another approach is to make this implicit - just use the existing
L2/L3 network but without considering it to be a control plane at all (that's
what most routing protocols do). A third approach would be a truly separate
control plane such as a dedicated L2VPN. The point is that they could all
support autonomic behaviour; it's a design choice.

Suggestions for better wording is welcome. For a L3 device it's relatively clear: It's either the global routing table or a virtual routing table, such as a VRF, or a virtual router. Problem is that the concept of the Autonomic Control Plane as described in draft-behringer-autonomic-control-plane applies also to non-L3 devices, for example to switches or NMS systems, or .... 

So, what is the generic term for "global routing table" and "virtual routing table" which is valid also for non-L3 devices? 

So, the full range of options is: 
- inband, as we run for example IGPs today
- Over a configured VPN ("management VPN")
- Over the self-managing Autonomic Control Plane (See above mentioned draft)
- Over a "real" out of band network. 

Should we list those, 

IMHO, we should definitely list them.


and explain what they do in a bit more detail? Maybe that would make things clearer... 

I'm not sure that is needed in the definitions draft; it might get a bit
complicated. But I certainly have no objection to one or two sentences
for each one. We should probably avoid pros and cons, since that is
not the job of a definition.

   Brian

--

Bien cordialement, Best regards,

 

Laurent Ciavaglia

Research Manager | Project Manager

Network Algorithms, Protocols and Security Group

Bell Labs | Alcatel Lucent

 

phone: +33 160 402 636

email: laurent.ciavaglia@alcatel-lucent.com

linkedin: laurentciavaglia

address: Route de Villejust | 91620 NOZAY | France

--------------020901000909080205010804-- From nobody Thu Jul 31 01:03:08 2014 Return-Path: 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 AA6D31A03B3 for ; Thu, 31 Jul 2014 01:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, RP_MATCHES_RCVD=-0.001] 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 YgvEvg58wMGH for ; Thu, 31 Jul 2014 01:03:01 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D88E1A0397 for ; Thu, 31 Jul 2014 01:03:01 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 6587F8FABC596; Thu, 31 Jul 2014 08:02:57 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s6V82sYI011767 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Jul 2014 10:02:58 +0200 Received: from [172.27.204.75] (135.239.27.38) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 31 Jul 2014 10:02:57 +0200 Message-ID: <53D9F831.9040107@alcatel-lucent.com> Date: Thu, 31 Jul 2014 10:02:57 +0200 From: Laurent Ciavaglia Organization: Alcatel-Lucent Bell Labs France User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Sheng Jiang , Brian E Carpenter References: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BF933F@xmb-rcd-x14.cisco.com> <53D7C297.3080700@alcatel-lucent.com> <53D8432A.5060204@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923AED558F@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AED558F@nkgeml512-mbx.china.huawei.com> Content-Type: multipart/alternative; boundary="------------090709080906090409010407" X-Originating-IP: [135.239.27.38] Archived-At: http://mailarchive.ietf.org/arch/msg/anima/njOqydC7I4FZNtprCmPW-tqc_uQ Cc: "draft-irtf-nmrg-autonomic-network-definitions@tools.ietf.org" , "nmrg@irtf.org" , "anima@ietf.org" , "Michael Behringer \(mbehring\)" Subject: Re: [Anima] Architecture [was Next version of draft-irtf-nmrg-autonomic-network-definitions] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 08:03:06 -0000 --------------090709080906090409010407 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Hi, please see below for additional comments. Best regards, Laurent. On 31/07/2014 08:00, Sheng Jiang wrote: >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >> Carpenter >> >>> On 30/07/2014 03:49, Laurent Ciavaglia wrote: >>> ... >>> -If we agree to keep working on the architectural aspects in NMRG, then, >>> we have to strengthen the NMRG definitions/goals I-D with more >>> architectural aspects or create a dedicated document. Wrt. the >>> state-of-the-art, the content and guidelines of the NMRG document are >>> not enough. >>> As for the architectural model, this is a Pandora box, there has been >>> plenty of models all more or less equals (see the reference you have >>> added for a start). The important thing to agree on are the >>> definitions/terminology, design goals/principles, requirements to design >>> the right protocols(in the IETF WGs). The architectural I-D should allow >>> us to better understand what are the implications/impact of introducing >>> autonomic networking principles/mechanisms to the operations on internet >>> protocols. >> Precisely because it's Pandora's box, I am strongly in favour of >> making such a document a separate NMRG draft, and keeping the >> definitions document roughly as it is (so that we can get it finished >> in the next few weeks, and so that we can rely on it for IETF work). > Fully agree. It would NOT be easy to reach consensus on "the" architectural model. There is a good chance that we may struggle and spend too much time on architecture and requirements. Agreed on the difficulty to reach consensus on the model (from several past experiences in SDOs and projects), I think it is not even advisable to seek such consensus on the model itself (as I said "at the end of the day, the model is just (another) arbitrary grouping"). What would be more useful in my opinion, is to study how the autonomic networking principles adapt/apply to new/emerging and combined environments such as IoT, NFV, SDN... and thus to document the design/architectural/operational implications, to provide guidelines/recommendations to enhance IETF protocols with autonomic networking principles, to improve Internet manageability and performance... by using autonomic networking. Another objective/output of such a draft could also be to identify research directions and gaps (within autonomic networking concepts and techniques, and with internet protocols) in order to steer more work/investigation in these gap areas. Do you see other objectives, agree with these ones? > That's exactly the message from OPS ADs - we should try to avoid it and focus on solutions, which may be small steps, but real steps moving forward. A separate NMRG draft will isolate the risk within minimum impacts. We should complete the high-level concept works (definition and gap analysis) as soon as possible, then focus on produce code-proven protocols/solutions. Meanwhile, a separate, wider-scope architecture and requirement document in NMRG is also helpful. It could lead us on the exploring the potential next steps after we make the enabling common infrastructure available. I also agree with Sheng on the fact that such a document could help shape the future of the activity in IRTF/IETF, in coordination with ANIMA work. > > Best regards, > > Sheng > >> Brian >>> (at the end of the day, the model is just (another) arbitrary grouping). >>> >>> HTH, best regards, Laurent. >>> >>> >>> On 29/07/2014 16:29, Michael Behringer (mbehring) wrote: >>>> [excuse cross-posting, but I do believe that this is relevant to both >>>> lists] >>>> >>>> Anima, NMRG, >>>> >>>> Before and at the IETF there was a lot of discussion around the >>>> autonomic paradigms discussed in >>>> draft-irtf-nmrg-autonomic-network-definitions. I tried to now >>>> consolidate all input into a new version of the document (link below). >>>> I'm not commenting every single mail, although mostly I replied to >>>> each mail. High level, I tried to capture the discussions in this way: >>>> >>>> 1. Coexistence with config / other management paradigms. >>>> There was a lot of discussion around what takes priority, autonomic >>>> behaviour or config. I believe we have consensus that config always >>>> overrides autonomic behaviour. There was some discussion about >>>> "emergency disable" in case an autonomic function gets into unknown >>>> conditions. The consensus I think is that we do NOT want an automatic >>>> shut-down in such cases, because it adds even more uncertainty to the >>>> network. >>>> This is highly important, so I felt the best way to capture this >>>> discussion was to introduce a new section in the design goals on >>>> co-existence. Section 3.2. >>>> In the definitions, for intent, I now point to this section, because >>>> the question arose also at this point. >>>> >>>> The document -01 states "Fully Autonomic Node: A node which employs >>>> exclusively autonomic functions. It requires no configuration." I >>>> expanded that now with "It requires (!) no configuration. Note that >>>> configuration can be used to override an autonomic function. See >>> target="coexistence"/> for more details." >>>> >>>> 2. What is a "fully autonomic network". >>>> Some folks commented that autonomic = self-management = self-CHOP >>>> (configuring, healing, optimising, protecting), and that a truly >>>> autonomic function MUST contain all four elements. >>>> I suggest that we don't become too rigid in our argumentation, but >>>> leave a bit of flexibility in the definitions. My arguments are: >>>> A) there is no generally accepted, precise definition of which >>>> self-properties must be present in a system so that it can be called >>>> "autonomic". The Kephart paper itself is not clear for starters, while >>>> it focuses MAINLY on the self-CHOP, it also uses terms >>>> "self-maintaining" and "self-governing". >>>> The paper cited by Olivier >>>> >> (http://hal.inria.fr/docs/00/53/12/15/PDF/renumbering_cameraReadyv2.pdf) >>>> leaves out self-healing, but introduces self-monitoring. >>>> Other terms, such as self-discovering, self-learning, etc can be found >>>> all over the literature. >>>> Therefore: In the absence of a clear reference I do NOT think it makes >>>> sense to be too academic on MUST contain self-features. >>>> B) I can see implementations of autonomic that do not implement all >>>> self-* properties. For example, in a simple network self-healing may >>>> just not be relevant. (And indeed, the paper mentioned by Olivier >>>> doesn't contain it anyhow). Do we really NOT want to call this >>>> autonomic? The term "more religious than the pope" comes to mind ;-) >>>> >>>> I suggest to actually not add too much wording around it in order to >>>> not make it even more confusing. Instead, I will remove the "and" in >>>> the definition, so that it reads " Autonomic: Self-managing >>>> (self-configuring, self-protecting, self-healing, self-optimizing); >>>> however, allowing high-level guidance by a central entity, through >>>> intent." For practical purposes this should be ok. Can everyone live >>>> with this? If not, can you propose concrete text / changes? >>>> >>>> 3. Changed section title: Simplification of Autonomic Node Northbound >>>> Interfaces (changed from "simplification of the northbound >>>> interfaces") (suggestion of Benoit). >>>> >>>> 4. difference between automatic and autonomic (request by Benoit): I >>>> added some text in the introduction: >>>> There is an important difference between "automatic" and >>>> "autonomic". "Automatic" refers to a pre-defined, linear process, such >>>> as a script. "Autonomic" is used in the context of self-management. It >>>> includes feedback loops between elements as well as northbound. >>>> Comments welcome. >>>> >>>> 5. References. Added two references, and Brian suggested some text >>>> around this for the intro. >>>> >>>> 6. A clarification that the Autonomic Control Plane can be implemented >>>> in the global context, or in a separate context (section 7) >>>> >>>> I believe this should account for all the comments received to date on >>>> this draft. If I missed something, please respond! >>>> >>>> Michael >>>> >>>> >>>> ---- >>>> >>>> A new version of I-D, >>>> draft-irtf-nmrg-autonomic-network-definitions-02.txt >>>> has been successfully submitted by Michael Behringer and posted to the >>>> IETF repository. >>>> >>>> Name: draft-irtf-nmrg-autonomic-network-definitions >>>> Revision: 02 >>>> Title: Autonomic Networking - Definitions and Design Goals >>>> Document date: 2014-07-28 >>>> Group: nmrg >>>> Pages: 15 >>>> URL: >>>> >> http://www.ietf.org/internet-drafts/draft-irtf-nmrg-autonomic-network-defi >> nitions-02.txt >>>> Status: >>>> >> https://datatracker.ietf.org/doc/draft-irtf-nmrg-autonomic-network-definitio >> ns/ >>>> Htmlized: >>>> >> http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-network-definitions-02 >>>> Diff: >>>> >> http://www.ietf.org/rfcdiff?url2=draft-irtf-nmrg-autonomic-network-definiti >> ons-02 >>>> >>>> Abstract: >>>> Autonomic systems were first described in 2001. The fundamental >> goal >>>> is self-management, including self-configuration, self-optimization, >>>> self-healing and self-protection. >>>> >>>> This document applies the concepts of autonomic systems to a >> network, >>>> and describes the definitions and design goals of Autonomic >>>> Networking. The high-level goal for an autonomic function is to >> have >>>> minimal dependencies on human administrators or centralized >>>> management systems. This usually implies distribution across >> network >>>> elements. >>>> >>>> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > > -- Bien cordialement, Best regards, *Laurent Ciavaglia* Research Manager | Project Manager Network Algorithms, Protocols and Security Group Bell Labs | Alcatel Lucent phone: +33 160 402 636 email: laurent.ciavaglia@alcatel-lucent.com linkedin: laurentciavaglia address: Route de Villejust | 91620 NOZAY | France --------------090709080906090409010407 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Hi,

please see below for additional comments.

Best regards, Laurent.

On 31/07/2014 08:00, Sheng Jiang wrote:
-----Original Message-----
From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E
Carpenter


On 30/07/2014 03:49, Laurent Ciavaglia wrote:
...
-If we agree to keep working on the architectural aspects in NMRG, then,
we have to strengthen the NMRG definitions/goals I-D with more
architectural aspects or create a dedicated document. Wrt. the
state-of-the-art, the content and guidelines of the NMRG document are
not enough.
As for the architectural model, this is a Pandora box, there has been
plenty of models all more or less equals (see the reference you have
added for a start). The important thing to agree on are the
definitions/terminology, design goals/principles, requirements to design
the right protocols(in the IETF WGs). The architectural I-D should allow
us to better understand what are the implications/impact of introducing
autonomic networking principles/mechanisms to the operations on internet
protocols.

Precisely because it's Pandora's box, I am strongly in favour of
making such a document a separate NMRG draft, and keeping the
definitions document roughly as it is (so that we can get it finished
in the next few weeks, and so that we can rely on it for IETF work).

Fully agree. It would NOT be easy to reach consensus on "the" architectural model. There is a good chance that we may struggle and spend too much time on architecture and requirements.

Agreed on the difficulty to reach consensus on the model (from several past experiences in SDOs and projects), I think it is not even advisable to seek such consensus on the model itself (as I said "at the end of the day, the model is just (another) arbitrary grouping").

What would be more useful in my opinion, is to study how the autonomic networking principles adapt/apply to new/emerging and combined environments such as IoT, NFV, SDN... and thus to document the design/architectural/operational implications, to provide guidelines/recommendations to enhance IETF protocols with autonomic networking principles, to improve Internet manageability and performance... by using autonomic networking.

Another objective/output of such a draft could also be to identify research directions and gaps (within autonomic networking concepts and techniques, and with internet protocols) in order to steer more work/investigation in these gap areas.

Do you see other objectives, agree with these ones?

That's exactly the message from OPS ADs - we should try to avoid it and focus on solutions, which may be small steps, but real steps moving forward. A separate NMRG draft will isolate the risk within minimum impacts. We should complete the high-level concept works (definition and gap analysis) as soon as possible, then focus on produce code-proven protocols/solutions. Meanwhile, a separate, wider-scope architecture and requirement document in NMRG is also helpful. It could lead us on the exploring the potential next steps after we make the enabling common infrastructure available.
I also agree with Sheng on the fact that such a document could help shape the future of the activity in IRTF/IETF, in coordination with ANIMA work.


Best regards,

Sheng


   Brian

(at the end of the day, the model is just (another) arbitrary grouping).

HTH, best regards, Laurent.


On 29/07/2014 16:29, Michael Behringer (mbehring) wrote:

[excuse cross-posting, but I do believe that this is relevant to both
lists]

Anima, NMRG,

Before and at the IETF there was a lot of discussion around the
autonomic paradigms discussed in
draft-irtf-nmrg-autonomic-network-definitions. I tried to now
consolidate all input into a new version of the document (link below).
I'm not commenting every single mail, although mostly I replied to
each mail. High level, I tried to capture the discussions in this way:

1. Coexistence with config / other management paradigms.
There was a lot of discussion around what takes priority, autonomic
behaviour or config. I believe we have consensus that config always
overrides autonomic behaviour. There was some discussion about
"emergency disable" in case an autonomic function gets into unknown
conditions. The consensus I think is that we do NOT want an automatic
shut-down in such cases, because it adds even more uncertainty to the
network.
This is highly important, so I felt the best way to capture this
discussion was to introduce a new section in the design goals on
co-existence. Section 3.2.
In the definitions, for intent, I now point to this section, because
the question arose also at this point.

The document -01 states "Fully Autonomic Node: A node which employs
exclusively autonomic functions. It requires no configuration." I
expanded that now with "It requires (!) no configuration. Note that
configuration can be used to override an autonomic function. See <xref
target="coexistence"/> for more details."

2. What is a "fully autonomic network".
Some folks commented that autonomic = self-management = self-CHOP
(configuring, healing, optimising, protecting), and that a truly
autonomic function MUST contain all four elements.
I suggest that we don't become too rigid in our argumentation, but
leave a bit of flexibility in the definitions. My arguments are:
A) there is no generally accepted, precise definition of which
self-properties must be present in a system so that it can be called
"autonomic". The Kephart paper itself is not clear for starters, while
it focuses MAINLY on the self-CHOP, it also uses terms
"self-maintaining" and "self-governing".
The paper cited by Olivier


(http://hal.inria.fr/docs/00/53/12/15/PDF/renumbering_cameraReadyv2.pdf)

leaves out self-healing, but introduces self-monitoring.
Other terms, such as self-discovering, self-learning, etc can be found
all over the literature.
Therefore: In the absence of a clear reference I do NOT think it makes
sense to be too academic on MUST contain self-features.
B) I can see implementations of autonomic that do not implement all
self-* properties. For example, in a simple network self-healing may
just not be relevant. (And indeed, the paper mentioned by Olivier
doesn't contain it anyhow). Do we really NOT want to call this
autonomic? The term "more religious than the pope" comes to mind ;-)

I suggest to actually not add too much wording around it in order to
not make it even more confusing. Instead, I will remove the "and" in
the definition, so that it reads " Autonomic: Self-managing
(self-configuring, self-protecting, self-healing, self-optimizing);
however, allowing high-level guidance by a central entity, through
intent."  For practical purposes this should be ok. Can everyone live
with this? If not, can you propose concrete text / changes?

3. Changed section title: Simplification of Autonomic Node Northbound
Interfaces (changed from "simplification of the northbound
interfaces") (suggestion of Benoit).

4. difference between automatic and autonomic (request by Benoit): I
added some text in the introduction:
       <t>There is an important difference between "automatic" and
"autonomic". "Automatic" refers to a pre-defined, linear process, such
as a script. "Autonomic" is used in the context of self-management. It
includes feedback loops between elements as well as northbound. </t>
Comments welcome.

5. References. Added two references, and Brian suggested some text
around this for the intro.

6. A clarification that the Autonomic Control Plane can be implemented
in the global context, or in a separate context (section 7)

I believe this should account for all the comments received to date on
this draft. If I missed something, please respond!

Michael


----

A new version of I-D,
draft-irtf-nmrg-autonomic-network-definitions-02.txt
has been successfully submitted by Michael Behringer and posted to the
IETF repository.

Name:        draft-irtf-nmrg-autonomic-network-definitions
Revision:    02
Title:        Autonomic Networking - Definitions and Design Goals
Document date:    2014-07-28
Group:        nmrg
Pages:        15
URL:


http://www.ietf.org/internet-drafts/draft-irtf-nmrg-autonomic-network-defi
nitions-02.txt

Status:


https://datatracker.ietf.org/doc/draft-irtf-nmrg-autonomic-network-definitio
ns/

Htmlized:


http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-network-definitions-02

Diff:


http://www.ietf.org/rfcdiff?url2=draft-irtf-nmrg-autonomic-network-definiti
ons-02


Abstract:
    Autonomic systems were first described in 2001.  The fundamental

goal

    is self-management, including self-configuration, self-optimization,
    self-healing and self-protection.

    This document applies the concepts of autonomic systems to a

network,

    and describes the definitions and design goals of Autonomic
    Networking.  The high-level goal for an autonomic function is to

have

    minimal dependencies on human administrators or centralized
    management systems.  This usually implies distribution across

network

    elements.




        

        
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima


      

      
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima




    

    

    
-- 

      
      
      
      
      
      
      
      
      
      
      

        
Bien
            cordialement,
            Best regards,

        
 

        
Laurent
              Ciavaglia

        
Research
            Manager | Project Manager

        
Network
            Algorithms, Protocols and Security Group

        
Bell
            Labs | Alcatel Lucent

        
 

        
phone: +33 160
            402 636 

        
email: laurent.ciavaglia@alcatel-lucent.com

        
linkedin: laurentciavaglia

        
address: Route de Villejust | 91620 NOZAY | France

      

    

  


--------------090709080906090409010407--


From nobody Thu Jul 31 07:00:53 2014
Return-Path: 
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 BF4E51B2819 for ; Thu, 31 Jul 2014 07:00:50 -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 PR8GOp755Iau for ; Thu, 31 Jul 2014 07:00:43 -0700 (PDT)
Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD3811B2829 for ; Thu, 31 Jul 2014 07:00:35 -0700 (PDT)
Received: by mail-ig0-f176.google.com with SMTP id hn18so9462303igb.9 for ; Thu, 31 Jul 2014 07:00:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=d8gGNynJ9XC3We5AiyWe1YgUdrwsr/0uPKpaMV1RrXU=; b=HklqZG1NHzRXmo/ksSkYrLzpLwMi1iuWqBoUB9jir7mmGKjtH0fijSsc6M4oQnPue5 /DBQlhqJf3WHXIqTA0vtRB3h8E0Vd2LetvLQLsepKN3vrO3q9uGqZsMcYtw1RGQgkTDx 2xZV0c+FoMyyenljnmr+SN1cZwd1yCYWkP9viiwu07C52hd50Mxvwrz0iNEozJ9c0v0y a+eKGyKZWjRUi0vN6nQEJq7aCyTzR4f/dn8PuqrAnSRGNNs3uAetZZFWtkCq8MxqPEmq 52t5MN+6P9/acHMSzrEIRdQgRrfNGN28L+XJoGz6ooPn5pgGQxsTaz4Ju8AXTyUzQiEr ZD6Q==
X-Received: by 10.50.111.80 with SMTP id ig16mr8901098igb.43.1406815234876; Thu, 31 Jul 2014 07:00:34 -0700 (PDT)
Received: from [192.168.97.253] ([67.210.160.130]) by mx.google.com with ESMTPSA id yt6sm4017347igb.10.2014.07.31.07.00.34 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Jul 2014 07:00:34 -0700 (PDT)
Message-ID: <53DA4BFF.30407@gmail.com>
Date: Thu, 31 Jul 2014 10:00:31 -0400
From: Tom Taylor 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: anima@ietf.org
References: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BF933F@xmb-rcd-x14.cisco.com> <53D7C297.3080700@alcatel-lucent.com> <53D8432A.5060204@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923AED558F@nkgeml512-mbx.china.huawei.com> <53D9F831.9040107@alcatel-lucent.com>
In-Reply-To: <53D9F831.9040107@alcatel-lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/anima/moXlPpIWBjb7lNEYonrk8QQaRw0
Subject: Re: [Anima] Architecture [was Next version of draft-irtf-nmrg-autonomic-network-definitions]
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jul 2014 14:00:51 -0000

On 31/07/2014 4:02 AM, Laurent Ciavaglia wrote:
> Hi,
>
> please see below for additional comments.
>
> Best regards, Laurent.
>
...
> Agreed on the difficulty to reach consensus on the model (from several
> past experiences in SDOs and projects), I think it is not even advisable
> to seek such consensus on the model itself (as I said "at the end of the
> day, the model is just (another) arbitrary grouping").
>
> What would be more useful in my opinion, is to study how the autonomic
> networking principles adapt/apply to new/emerging and combined
> environments such as IoT, NFV, SDN... and thus to document the
> design/architectural/operational implications, to provide
> guidelines/recommendations to enhance IETF protocols with autonomic
> networking principles, to improve Internet manageability and
> performance... by using autonomic networking.
>
...
I was teelling Brian that one of the things I used to wwork on in BNR 
(Bell-Northern Research) several decades ago was operator services 
planning. There, a few seconds of work time per call was worth a lot due 
to volume. The same ideas for reducing work time were always around, but 
only became cost-effective as teechnology evolved to support them.

In a similar way, Anima might identify the promising ideas and what has 
to happen before they can be supported at the business level. Either 
Anima or other groups can then periodically review whether a particular 
solution approach has matured to the point of development and deployment.

Tom Taylor


From nobody Thu Jul 31 12:48:50 2014
Return-Path: 
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 A88F31A000F for ; Thu, 31 Jul 2014 12:48:48 -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 bJwt3IeW50l5 for ; Thu, 31 Jul 2014 12:48:47 -0700 (PDT)
Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08C861A005C for ; Thu, 31 Jul 2014 12:48:39 -0700 (PDT)
Received: by mail-pa0-f42.google.com with SMTP id lf10so4266947pab.29 for ; Thu, 31 Jul 2014 12:48:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=gUvqt0LMMr+EIj0eeBZX5JwkcTNXLT4dKySSjZDyGhQ=; b=YmBeZlaEGVt6Zg3bhUtjYToWN9fUhJkGlsjMC8HZOkaKtcIx6yhla3bAkOybgdEUJI zlsy8phiY53Vu0C3hfldtqfwoZDIzn1cen6yJtSYiexAcGY+Qt0dxZoZ2NqgLooJ29k4 1/zGYYMIC5ZCZGlGTDWa+mKq+bcM6mOH9VGNypXTpcgh1BoJz+/FCHb0MxKikfiGbrX1 hmR+Ky6WpxDvVVQ+gxwlmcSXnRF5+gP32kc8l/IWqIpuIr6HcvSjYovnPY8J5dZ5fbCO ozsYYmhKYt8UWQ0az1hubm88bzVtQK9BoMDSawf6FISv8uUqWKJgUp1UJmDKT0U1fo8d kU0w==
X-Received: by 10.66.123.36 with SMTP id lx4mr426802pab.21.1406836118686; Thu, 31 Jul 2014 12:48:38 -0700 (PDT)
Received: from [192.168.178.23] (207.199.69.111.dynamic.snap.net.nz. [111.69.199.207]) by mx.google.com with ESMTPSA id q6sm9590804pdp.5.2014.07.31.12.48.37 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Jul 2014 12:48:38 -0700 (PDT)
Message-ID: <53DA9D9C.6050700@gmail.com>
Date: Fri, 01 Aug 2014 07:48:44 +1200
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: anima@ietf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/anima/3VolLBb9bj17XyedzvxuEdplFPo
Subject: [Anima] UCAN BOF minutes delayed.
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jul 2014 19:48:48 -0000

Unfortunately one the minute-takers for the UCAN BOF, Tom Taylor,
has some health problems so the minutes are a little delayed.

Regards
   Brian Carpenter