From nobody Fri Apr 1 00:05:41 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A165312D54E for ; Fri, 1 Apr 2016 00:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.539 X-Spam-Level: X-Spam-Status: No, score=-13.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 unU991Njqq_D for ; Fri, 1 Apr 2016 00:05:38 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5D2B12D54C for ; Fri, 1 Apr 2016 00:05:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=40866; q=dns/txt; s=iport; t=1459494337; x=1460703937; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=86GlHRCoDuv6NctTOGuUotxQG49qD/R6oe5CjNTZGPM=; b=HjZrMa0Uh4K78R6p08xRqqNaw+CHp2a6xxw45b+Pt7N5YbrOA9VdfqWA qTif/zLH1xg7sq4HSFEVFS7+1T6x77OII8jq45Vf176SxrB7do+Rr3yEl syzo0OoM7lVAXgqFioCRcGhSSX3eoq1kD9tdyc+vVyAo0koDsHCUndJJx Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D9AQCAHP5W/4oNJK1dgmdMU30GuQCCD?= =?us-ascii?q?wENgXKGDQIcgSw4FAEBAQEBAQFlJ4RBAQEBBCMEBkwQAgEIEQQBASEBBgMCAgI?= =?us-ascii?q?wFAkIAgQBDQUIiB+yR5EWAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYehEaERAcJI?= =?us-ascii?q?AKCSIJWBY1JhSWFBwGGX4chgW2NJ4YaiH0BHgEBQoIJFIFKbIdofgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,426,1454976000"; d="scan'208,217";a="255996250" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Apr 2016 07:05:25 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u3175PFb024081 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Apr 2016 07:05:25 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 1 Apr 2016 02:05:24 -0500 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.009; Fri, 1 Apr 2016 02:05:24 -0500 From: "Michael Behringer (mbehring)" To: Duzongpeng , Laurent Ciavaglia , anima Thread-Topic: ANIMA intent discussion Thread-Index: AQHRip6r6CBKKtp6FEycGBHZ8l3kKJ9002wA///fMyA= Date: Fri, 1 Apr 2016 07:05:24 +0000 Message-ID: <1341e3fd501e4cbb8cbe9fbdc1d158de@XCH-RCD-006.cisco.com> References: <56FBFA6A.4010400@alcatel-lucent.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.238.139] Content-Type: multipart/alternative; boundary="_000_1341e3fd501e4cbb8cbe9fbdc1d158deXCHRCD006ciscocom_" MIME-Version: 1.0 Archived-At: Cc: Pierre Peloso Subject: Re: [Anima] ANIMA intent discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 01 Apr 2016 07:05:40 -0000 --_000_1341e3fd501e4cbb8cbe9fbdc1d158deXCHRCD006ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2XigJlyZSBzdGFydGluZyB0byBjYWxsIGV2ZXJ5dGhpbmcgdGhhdCBmbGllcyB0aHJvdWdoIGFu IGF1dG9ub21pYyBuZXR3b3JrIEludGVudCwgYW5kIHRoZSBuYW1pbmcgaXMgZ2V0dGluZyB2ZXJ5 IGNvbmZ1c2luZy4NCg0KVG8gbWU6IEludGVudCA9IG5ldHdvcmsgd2lkZSBodW1hbiBpbnB1dCBw b2xpY3kNCmV2ZXJ5dGhpbmcgZWxzZTogbm90IEludGVudC4gQ2FsbCBpdCBzaWduYWxpbmcsIG1l c3NhZ2luZywgZmVlZGJhY2sgbG9vcHMsIFNOTVAsIEdSQVNQLCB3aGF0ZXZlci4NCg0KT2YgY291 cnNlIGEgbm9kZSBtYXksIGxvb2tpbmcgYXQgSW50ZW50LCBuZWVkIHRvIG5lZ290aWF0ZSBzb21l dGhpbmcgd2l0aCBhIG5laWdoYm91cjsgb3IsIHJ1biBhIGZlZWRiYWNrIGxvb3Agd2l0aCB0aGUg b3BlcmF0b3IgYWxlcnRpbmcgaGltIG9mIGFuIGV4Y2VwdGlvbmFsIGNvbmRpdGlvbjsgb3IgdGhl cmUgbWF5IGJlIHNwZWNpZmljIG1lc3NhZ2VzIGJldHdlZW4gbm9kZXMgdG8gcmVzb2x2ZSBhIGNv bmZsaWN0LiBOb25lIG9mIHRoZXNlIGFyZSBJbnRlbnQuDQoNClNvIGEgbm9kZSByZWNlaXZlcyB0 aGlzIGh1bWFuIGlucHV0IHBvbGljeSwgd2hpY2ggSSBzdWdnZXN0IHdlIGZsb29kIGFjcm9zcyB0 aGUgZW50aXJlIG5ldHdvcmsuIEV2ZXJ5dGhpbmcgYWZ0ZXIgdGhhdCBpcyBOT1QgSW50ZW50Lg0K DQpNaWNoYWVsDQoNCg0KRnJvbTogQW5pbWEgW21haWx0bzphbmltYS1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgRHV6b25ncGVuZw0KU2VudDogMDEgQXByaWwgMjAxNiAwNTo1Ng0KVG86 IExhdXJlbnQgQ2lhdmFnbGlhIDxsYXVyZW50LmNpYXZhZ2xpYUBub2tpYS5jb20+OyBhbmltYSA8 YW5pbWFAaWV0Zi5vcmc+DQpDYzogTWljaGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKSA8bWJlaHJp bmdAY2lzY28uY29tPjsgUGllcnJlIFBlbG9zbyA8UGllcnJlLlBlbG9zb0Bub2tpYS5jb20+DQpT dWJqZWN0OiBSZTogW0FuaW1hXSBBTklNQSBpbnRlbnQgZGlzY3Vzc2lvbg0KDQpIaSwgTWljaGFl bCwgTGF1cmVudCwgUGllcnJlDQoNCiAgICAgICAgIEFib3V0IHdoZXRoZXIgQVNBIGNhbiBpc3N1 ZSBpbnRlbnQsIGFjY29yZGluZyB0byBteSB1bmRlcnN0YW5kaW5nLCBpbnRlbnQgc2hvdWxkIGJl IGlzc3VlZCBieSBodW1hbiBieSBkZWZhdWx0Lg0KDQogICAgICAgICBCdXQgaW4gdGhlIGRpc2N1 c3Npb24sIEkgcmVhbGl6ZSB0aGF0IHdlIG1heSBoYXZlIHR3byBraW5kcyBvZiBpbnRlbnQuDQoN CiAgICAgICAgIFRoZSBmaXJzdCBraW5kIG9mIGludGVudHMgYXJlIHRoZSBvbmVzIGlzc3VlZCBm cm9tIGh1bWFucywgcGVyaGFwcyBub3Qgb25seSBmcm9tIG9uZSBwZXJzb24uDQoNCiAgICAgICAg IEFuZCBhbm90aGVyIGlzIHRoZSBpbnRlbnQgYWZ0ZXIgdGhlIGNvb3JkaW5hdGlvbi4gVGhleSBh cmUgdGhlIGludGVudCBpbmZsdWVuY2luZyB0aGUgbm9kZSBkaXJlY3RseS4gSSBtZWFuIGNvb3Jk aW5hdGlvbiBkb2VzIG5vdCBuZWVkIHRvIGhhcHBlbiBvbiBldmVyeSBub2RlLCBhbmQgdGhleSBv bmx5IG5lZWQgdGhlIHJlc3VsdC4NCg0KICAgICAgICAgVGhpcyBpcyBhbiBpbnRlcmVzdGluZyBt b2RlbC4gSWYgd2UgY2FuIGZpbmQgc29tZSBleGFtcGxlcywgSSB0aGluayBwZXJoYXBzIHNvbWUg QVNBcyBtYXkgY2hvb3NlIHRvIHVzZSBpbnRlbnQgbGlrZSB0aGlzLCBhbmQgQVNBIGNhbiBpc3N1 ZSB0aGUgc2Vjb25kIGtpbmQgb2YgaW50ZW50Lg0KDQogICAgICAgICBBZ2FpbiwgaWYgc29tZW9u ZSB0aGluayB0aGVzZSBhcmUganVzdCBzb21lIHNpZ25hbHMgb3IgbWVzc2FnZXMsIHdlIGNhbiBn aXZlIGl0IGFub3RoZXIgbmFtZSwgc3VjaCBhcyDigJxuZXR3b3JrLWxldmVsIHBvbGljeeKAnSBv ciDigJxpbnRlbnQgYWZ0ZXIgY29vcmRpbmF0aW9u4oCdLg0KDQpCZXN0IFJlZ2FyZHMNClpvbmdw ZW5nIER1DQoNCkZyb206IExhdXJlbnQgQ2lhdmFnbGlhIFttYWlsdG86bGF1cmVudC5jaWF2YWds aWFAbm9raWEuY29tXQ0KU2VudDogVGh1cnNkYXksIE1hcmNoIDMxLCAyMDE2IDEyOjEwIEFNDQpU bzogYW5pbWENCkNjOiBNaWNoYWVsIEJlaHJpbmdlcjsgUGllcnJlIFBlbG9zbzsgRHV6b25ncGVu ZzsgTGF1cmVudCBDaWF2YWdsaWENClN1YmplY3Q6IEFOSU1BIGludGVudCBkaXNjdXNzaW9uDQoN CkRlYXIgYWxsLA0KDQpNaWNoYWVsLCBab25ncGVuZywgUGllcnJlIGFuZCBJIGhhZCBhIGRpc2N1 c3Npb24gb24gQU5JTUEgaW50ZW50IHRoaXMgbW9ybmluZywgdHJ5aW5nIHRvIGNsYXJpZnkgc29t ZSBwb2ludHMgYW5kIHByb2dyZXNzIHRvd2FyZCBhIGNvbW1vbiB1bmRlcnN0YW5kaW5nLg0KDQpX ZSB1c2VkIGEgc21hbGwsIHBhcnRpYWwgc2V0IG9mIHF1ZXN0aW9ucyBhbmQgZXhhbXBsZXMgaW4g c3VwcG9ydC4NCg0KQmVsb3cgeW91IG1heSBmaW5kIGEgc3VtbWFyeSBmb3IgeW91ciBpbmZvcm1h dGlvbi4gQ29tbWVudHMgYW5kIGZ1cnRoZXIgaW50ZXJhY3Rpb25zIGFyZSBtb3N0IHdlbGNvbWUu DQoNClRoYW5rcywNCk1pY2hhZWwsIFpvbmdwZW5nLCBQaWVycmUgYW5kIExhdXJlbnQuDQotLS0N Cg0KLS0tIFF1ZXN0aW9ucw0KMS1XaG8gd3JpdGVzIGludGVudHM/DQoyLUhvdyBtYW55IGludGVu dHM/DQozLUhvdyBtYW55IGRvbWFpbnM/DQo0LVdoYXQgYXJlIHRoZSBpbnRlbnQgbGV2ZWxzL2hp ZXJhcmNoeT8NCjUtV2hlcmUvYnkgd2hhdCBpcyBpbnRlbnQgcHJvY2Vzc2VkL2NvbXBpbGVkPw0K Ni1GbG9vZGluZzogd2hhdCBhcmUgdGhlIHJlcXVpcmVtZW50cz8NClByb3BhZ2F0aW9uIGFtb25n IHdobz8gSG93IGRpc3RyaWJ1dGVkPyBIb3cgZnJlcXVlbnQ/IC0+IGlmIG1hbnkg4oCcb3Zlcmxh cHBpbmfigJ0gaW50ZW50cywgKHBhcnRpYWwpIHVwZGF0ZXMgbWF5IGJlY29tZSBmcmVxdWVudC4N CjctSG93IGlzIGludGVudCB1bmRlcnN0b29kIGJ5IG5vZGUvQVNBPyAtPiBtb2RlbCwgZGljdGlv bmFyeS4uLg0KOC1DYW4gYW4gQVNBIHdyaXRlIGFuIGludGVudCBmb3IgYW5vdGhlciBBU0E/DQpX aGF0IGFib3V0IGNvb3JkaW5hdGlvbiBvciBrbm93bGVkZ2Ugd3JpdGluZy9yZWNlaXZpbmcgaW50 ZW50cz8gQXJlIHRoZXNlIGZ1bmN0aW9ucyBBU0FzL290aGVyIHRoaW5ncy4uPw0KDQoNCi0tLSBJ bnRlbnQgZXhhbXBsZXMNCkEtRG8gdGhlIHJpZ2h0IHRoaW5nDQpCLUZyZWV6ZSBuZXR3b3JrIGVu cm9sbG1lbnQNCkMtQXJyYW5nZSBWTSBndWVzdCBkaXN0cmlidXRpb24gc28gdGhhdCAoQ1BVKSB1 dGlsaXphdGlvbiBpcyA8IDcwJQ0KRC1Bc3NpZ24gcHJlZml4ZXMgdG8gUkFOIG5vZGVzDQpFLVBy b3RlY3QgcHJlbWl1bSB1c2VycyB0cmFmZmljDQpGLU1heGltaXplIGVuZXJneSBzYXZpbmdzDQoN Cg0KLS0tIERpc2N1c3Npb24NCjEpIFdobyB3cml0ZXMgaW50ZW50cz8NCiAgIExhdXJlbnQncyB2 aWV3Og0KICAgIEludGVudHMgYXJlIGlzc3VlZCBieSBhIG1hbmFnZW1lbnQgZnVuY3Rpb24uIENh biBiZSBodW1hbiAvIHZpYSBCU1MvT1NTLg0KICAgTWljaGFlbCdzIHZpZXc6DQogICAgT3JpZ2lu IG9mIGludGVudCBpcyAibm9uLXRlY2huaWNhbCIuIGkuZS4sIHJlZ2lzdHJhciBkb2Vzbid0IGlz c3VlIGludGVudC4NCiAgIERpc2N1c3Npb246IGhvdyB0byBzZXQgdGhlIGN1cnNvciBvbiBub24t dGVjaG5pY2FsPyBJbiBleGFtcGxlcyBEIG9yIEUsIHRoZSBpbnRlbnQgd3JpdGVyIGhhcyBzb21l IHJvdWdoIGtub3dsZWRnZS91bmRlcnN0YW5kaW5nIG9mIHRlY2huaWNhbCBhc3BlY3RzIG9mIGEg bmV0d29yayAod2lyZWxlc3MgYW5kIGFkZHJlc3MgYXNwZWN0cyBmb3IgZXhhbXBsZSBEIDsgcHJv dGVjdGlvbi9yZXN0b3JhdGlvbiBhbmQgdHJhZmZpYyBlbmdpbmVlcmluZyBmb3IgZXhhbXBsZSBF KS4NCiAgIENvbnNlbnN1czogSW50ZW50IGlzIG9yaWdpbmF0ZWQgYnkgaHVtYW4vYXQgT1NTIGxl dmVsLCBOT1QgYnkgYSBuZXR3b3JrIGRldmljZSAvIGZ1bmN0aW9uLiAob2YgY291cnNlIEludGVu dCBjYW4gYmUgaW5nZXN0ZWQgLyBpbnB1dHRlZCBvbiBhIHNwZWNpZmljIGRldmljZSkNCg0KDQoy KSBIb3cgbWFueSBpbnRlbnRzPw0KICAgTGF1cmVudCdzIHZpZXc6DQogICAgVGhlcmUgbWF5IGJl IGRpZmZlcmVudCBvbmVzLCBsaWtlICJmcmVlemUgbmV0d29yayIsICJvcHRpbWl6ZSBlbmVyZ3kg c2F2aW5ncyIsIGNmIGV4YW1wbGVzLiBBbGwgYXJlIHZhbGlkIGFuZCBjb25jdXJyZW50Lg0KICAg IENhbiB3ZSB3cmFwIHRoYXQgaW50byBvbmUgZmlsZT8NCiAgICBIb3cgZG8gd2Ugc2hhcmUgdGhh dD8NCg0KICAgIERpc2N1c3Npb246DQogICAgV2UgY2Fubm90IGRlZmluZSBJbnRlbnQgdG9vIHBy ZWNpc2VseSB0b2RheS4NCiAgICBCdXQgd2UgY2FuIGRlZmluZSB3aGVyZSBJbnRlbnQgaXMgY29t aW5nIGZyb20gYW5kIGhvdyB0byBkaXN0cmlidXRlIGl0Lg0KDQogICAgQ2FuIEludGVudCBoYXZl IHRhcmdldHM/DQogICAgICAgIC0gRXg6IGFuIGludGVudCBmb3IgdHJhZmZpYyBlbmdpbmVlcmlu ZyBhbmQgYW4gaW50ZW50IGZvciBlbmVyZ3kgY29uc3VtcHRpb24gb3B0aW1pemF0aW9uIG1heSBu ZWVkIHNwZWNpZmljIChzYW1lIG9yIGRpZmZlcmVudCkgdGFyZ2V0cy4gdGhlIGZ1bmN0aW9ucyBj b3VsZCBoYXZlIGRpZmZlcmVudCBvYmplY3RpdmVzIHBlciBzZXQgb2YgdGFyZ2V0cy4NCiAgICAg ICAgLSBFeDogdHdvIG5ldHdvcmsgc2VnbWVudHMsIGNvcmUgYW5kIG1ldHJvLiBUaGVuIGludGVu dCBzaG91bGQgYmUgYWJsZSB0byBzYXkgIm9uIGNvcmU6IG9wdGltaXplIG9uIGF2YWlsYWJpbGl0 eSI7IG9uIGFjY2VzczogIm9wdGltaXplIG9uIGVuZXJneSBzYXZpbmcuIg0KICAgICAgICAtIFRo ZXJlZm9yZSB3ZSBuZWVkIHNjb3Blcy4NCg0KICAgICBIb3cgZG8geW91IGRlZmluZSAidGFyZ2V0 Ij8NCiAgICAgICAgLSBJcyBhIHJvbGUgZW5vdWdoPw0KICAgICAgICAtIFBpZXJyZTogU2hvdWxk IGJlIG1vcmUgdGhhbiByb2xlLiBFeGFtcGxlOiBNZXRybyBhbmQgY29yZS4gTmVlZCB0byBkaXN0 aW5ndWlzaCBiZXR3ZWVuIGRpZmZlcmVudCBtZXRybyBuZXR3b3JrcyBmb3IgZXhhbXBsZS4NCiAg ICAgICAgLSBNaWNoYWVsOiBJZiB3ZSBoYXZlIHN1Yi1kb21haW5zLCBhbmQgZGVmaW5lIGludGVu dCBwZXIgc3ViLWRvbWFpbiwgd291bGQgdGhhdCBkbz8NCiAgICAgICAgLSBMYXVyZW50OiBhIGNv bWJpbmF0aW9uIG9mIHJvbGVzIGFuZCAoc3ViLSlkb21haW4ocykgc2hvdWxkIGJlIGFibGUgdG8g Y292ZXIgbW9zdCBjYXNlcy4NCg0KICAgIENvbnNlbnN1czogYSBjb21iaW5hdGlvbiBvZiByb2xl cyBhbmQgKHN1Yi0pZG9tYWluKHMpIHNob3VsZCBiZSBhYmxlIHRvIGNvdmVyIG1vc3QgY2FzZXMu DQoNCg0KOCkgQ2FuIGFuIEFTQSB3cml0ZSBhbiBpbnRlbnQ/DQogICAgUGllcnJlOiBFeGFtcGxl IGlzIHRoZSBjb29yZGluYXRpb24gZnVuY3Rpb246IHRoYXQgZnVuY3Rpb24gY291bGQgc2VuZCBv dXQgaW50ZW50IGRpcmVjdGx5IHRvIG1vZGlmeSB0aGUgYmVoYXZpb3Igb2YgYSBncm91cCBvZiBB U0FzLg0KICAgICBNdWx0aXBsZSBBU0FzIGNvdWxkIGRvIGNvbmZsaWN0aW5nIHRoaW5ncy4gVGhl IGNvb3JkaW5hdGlvbiBmdW5jdGlvbiBtdXN0IHJlc29sdmUgdGhhdC4gU2hvdWxkIGl0IGlzc3Vl L21vZGlmeSBpbnRlbnQgaXRzZWxmPw0KICAgIExhdXJlbnQ6IHExOiBzaG91bGQgaXQgb3V0cHV0 IHNvbWV0aGluZyBpbiB0aGUgZm9ybSBvZiBhbiBpbnRlbnQ/IHEyOiBzaG91bGQgdGhlIGNvb3Jk aW5hdGlvbiBmdW5jdGlvbiB1cGRhdGUgaW50ZW50Pw0KICAgIE1pY2hhZWw6IElzbid0IGl0IHRo YXQgdGhlIGJlaGF2aW9yIG9mIHRoZSBjb29yZGluYXRpb24gZnVuY3Rpb24gbXVzdCBhbHNvIGJl IHJlc29sdmVkIGJ5IGEgaHVtYW4gb3JpZ2luYXRlZCBpbnRlbnQ/IGkuZS4gdGhlIGNvbmZsaWN0 aW5nIGZ1bmN0aW9ucyBpbmZvcm0gdGhlIG9wZXJhdG9yIHZpYSBhIGZlZWRiYWNrIGxvb3AgYW5k IHRoZSBvcGVyYXRvciBhZGp1c3QgdGhlIGludGVudHMuDQogICAgTGF1cmVudDogVGhpcyBpcyBw b3NzaWJsZSAvIGNvbXBsZW1lbnRhcnkuIEluIG9uY2UgY2FzZSwgdGhlIG9wZXJhdG9yIGlzIHRo ZSBvbmUgY2xvc2luZyB0aGUgY29udHJvbCBsb29wIC8gY2hhbmdpbmcgdGhlIGJlaGF2aW9ycyB2 aWEgaW50ZW50IHVwZGF0ZXMuIFdpdGggYSBjb29yZGluYXRpb24gZnVuY3Rpb24sIHBhcnQvYWxs IG9mIHRoYXQgcHJvY2VzcyBjb3VsZCBiZSBhdXRvbWF0ZWQvZHJpdmVuIGJ5IHRoZSBtYWNoaW5l ICh0aGUgY29vcmRpbmF0aW9uIGZ1bmN0aW9uIGNsb3NlcyB0aGUgY29udHJvbCBsb29wLCBpbiB0 aGUgY29udHJvbCByYW5nZSBhbGxvd2VkIGJ5IHRoZSBvcGVyYXRvcikuIFRoZXJlIG1heSBiZSBp bnRlcm1lZGlhdGUgc3RlcHMgd2hlcmUgdW5mb3Jlc2VlbiBjb25mbGljdHMgd2lsbCBiZSByZXNv bHZlZC4gVGhpcyBpcyBydW4gdGltZSBjb25mbGljdCByZXNvbHV0aW9uLg0KICAgIE1pY2hhZWw6 IERvIHdlIGZvcmVzZWUgYSBjYXNlIHdoZXJlIG5ldHdvcmtzIHJlc29sdmUgY29uZmxpY3RzIHdp dGhvdXQgaHVtYW4gY29udHJvbD8NCiAgICBMYXVyZW50OiB0aGlzIGlzIHBvc3NpYmxlIChoYXMg YmVlbiBkZW1vbnN0cmF0ZWQgaW4gc29tZSBwcm9qZWN0cykuIFdlIHNob3VsZCBhbGxvdyBmb3Ig Ym90aCBhcHByb2FjaGVzIHRvIHdvcmssIHBvc3NpYmx5IGluIGEgcGhhc2VkIGFwcHJvYWNoLg0K DQogICAgV2hlbiB1bmZvcmVzZWVuIGNvbmZsaWN0cyBhcmlzZSwgQVNBcyBjYW4gc2lnbmFsIHRv IGVhY2ggb3RoZXIsIGJ1dCB0aGV5IHdpbGwgbm90IGlzc3VlIEludGVudCB0aGVtc2VsdmVzLg0K DQogICAgQ29uc2Vuc3VzOiBDYW5ub3Qgc2F5IHRvZGF5IGlmIG90aGVyIGZ1bmN0aW9ucyBjYW4v YXJlIGFsbG93ZWQgdG8gaXNzdWUgaW50ZW50IC8gaW50ZW50IHVwZGF0ZXMuIEZ1bmN0aW9ucy9B U0FzIG1heSBoYXZlIHRvICpzaWduYWwqIG9yICptZXNzYWdlKiBzb21laG93LCBidXQgdGhhdCB0 aGlzIGlzbuKAmXQgY29uc2lkZXJlZCAgICAgaW50ZW50IHlldC4NCiAgICBGb3IgZnVydGhlciBz dHVkeTogdHJ5IHRvIGRlc2lnbiB0aGUgaW50ZW50IHN5c3RlbSBzbyB0aGF0IGJvdGggYXBwcm9h Y2hlcyAoZmVlZGJhY2sgbG9vcCwgY29vcmRpbmF0aW9uKSBhcmUgcG9zc2libGUuIE1vcmUgaW52 ZXN0aWdhdGlvbi9hbmFseXNpcyBuZWVkZWQuDQoNCg0KMykgSG93IG1hbnkgZG9tYWlucz8NCiAg ICBOYW1pbmcgaXNzdWU6ICJkb21haW4iIGJ5IExhdXJlbnQgaXMgYSBoaWdoIGxldmVsIGNvbmNl cHQ7IGNvdWxkIGJlIHVuZGVyc3Rvb2QgYXMgYSBETlMgZG9tYWluIG5hbWUuIE5lZWRzIHRvIGJl IGNsZWFyIHdoYXQgd2UncmUgdGFsa2luZyBhYm91dC4NCiAgICBXaXRoIGRvbWFpbi1uYW1lIGJh c2VkIGludGVudCAoaS5lLiwgYWNjZXNzLmF0dC5uZXQpIGFuZCByb2xlcyAoZS5nLCBhY2Nlc3Mg ZGV2aWNlcykgd2Ugc2hvdWxkIGJlIGFibGUgdG8gZXhwcmVzcyB3aGF0IHdlIG5lZWQgZm9yIG5v dy4gTm90IDEwMCUgY2xlYXIgZm9yIG5vdy4NCiAgICBUd28gdHlwZXMgb2YgZG9tYWluczogKGFk bWluaXN0cmF0aXZlLCB0ZWNobm9sb2d5KSBkb21haW5zIGRlZmluZWQgKGEgcHJpb3JpKSBieSB0 aGUgb3BlcmF0b3IgZS5nLiBSQU4sIE1BTiwgV0FOLiBhbmQgdGhlIGRvbWFpbiBvZiBhcHBsaWNh dGlvbiBvZiBhIHBvbGljeSBpLmUuIHJlc29sdmluZyB0aGUgcG9saWN5IGRlZmluZXMgYSBzZXQg b2YgdGFyZ2V0IGVudGl0aWVzIHRvIHdoaWNoIHRlaCBwb2xpY3kgYXBwbGllcywgdGhpcyBpcyB0 aGUgZG9tYWluIG9mIGFwcGxpY2F0aW9uIG9mIHRoZSBnaXZlbiBwb2xpY3kuDQoNCiAgICBDb25z ZW5zdXM6IE5lZWQgdG8gY2xhcmlmeSB3b3JkaW5nIHRvIGF2b2lkIGNvbmZ1c2lvbi4NCg0KDQo0 KSBXaGF0IGFyZSB0aGUgaW50ZW50IGxldmVscy9oaWVyYXJjaHk/DQogICAgUmVsYXRlZCB0byBw b2xpY3kgYmFzZWQgbWFuYW1lZ2VudCBtb2RlbDogYnVzaW5lc3MgbGV2ZWwsIHNlcnZpY2UgbGV2 ZWwsIG5ldHdvcmsgbGV2ZWwsIGRldmljZSBsZXZlbCwgZXRjLiBTbyBmYXIgaW4gQU5JTUEgd2Ug Y29uc2lkZXIgb25seSB0d28gbGV2ZWxzOiBVc2VyIGFuZCBBU0EuDQogICAgRG8gd2UgbmVlZCBh IHNlcnZpY2UgbGV2ZWw/IGUuZywgVlBOLg0KICAgIENhbiB3ZSBleHByZXNzIGRpZmZlcmVudCBs ZXZlbHMgd2l0aCB1c2luZyByb2xlcz8gU28gYSByb2xlIGNvdWxkIGJlIHZlcnkgc3BlY2lmaWMg KHJvdXRlIHJlZmxlY3RvciksIG9yIHNlcnZpY2UgcmVsYXRlZCAoZS5nLiwgVlBOIGhlYWQtZW5k KT8NCiAgICBCdXQgdGhlbiB3ZSBtYXkgbmVlZCB0byBuZXN0IHJvbGVzPyENCiAgICBNYXliZSB3 ZSBuZWVkICJidXNpbmVzcyIgInNlcnZpY2UiICJuZXR3b3JrIChBU0EpIiBsZXZlbD8NCg0KICAg IENvbnNlbnN1czogdG8gYmUgZnVydGhlciBkaXNjdXNzZWQuDQoNCg0KUXVlc3Rpb25zIDUsIDYs IDcgd2VyZSBub3QgZGlzY3Vzc2VkIGR1ZSB0byBsYWNrIG9mIHRpbWUuDQotLS0NCg== --_000_1341e3fd501e4cbb8cbe9fbdc1d158deXCHRCD006ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyBcLCBzZXJpZiI7DQoJcGFub3NlLTE6MCAwIDAgMCAw IDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OlNpbVN1bjsNCgljb2xvcjoj MzMzMzMzO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxT dHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAu MHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPldl4oCZcmUg c3RhcnRpbmcgdG8gY2FsbCBldmVyeXRoaW5nIHRoYXQgZmxpZXMgdGhyb3VnaCBhbiBhdXRvbm9t aWMgbmV0d29yayBJbnRlbnQsIGFuZA0KIHRoZSBuYW1pbmcgaXMgZ2V0dGluZyB2ZXJ5IGNvbmZ1 c2luZy4gPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNp emU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VG8gbWU6IEludGVudCA9IG5l dHdvcmsgd2lkZSBodW1hbiBpbnB1dCBwb2xpY3k8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZh Y2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5ldmVyeXRoaW5nIGVsc2U6IG5vdCBJbnRlbnQuIENhbGwgaXQgc2lnbmFs aW5nLCBtZXNzYWdpbmcsIGZlZWRiYWNrIGxvb3BzLCBTTk1QLCBHUkFTUCwNCiB3aGF0ZXZlci4g PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250 IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIi IGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+T2YgY291cnNlIGEgbm9kZSBtYXksIGxv b2tpbmcgYXQgSW50ZW50LCBuZWVkIHRvIG5lZ290aWF0ZSBzb21ldGhpbmcgd2l0aCBhIG5laWdo Ym91cjsNCiBvciwgcnVuIGEgZmVlZGJhY2sgbG9vcCB3aXRoIHRoZSBvcGVyYXRvciBhbGVydGlu ZyBoaW0gb2YgYW4gZXhjZXB0aW9uYWwgY29uZGl0aW9uOyBvciB0aGVyZSBtYXkgYmUgc3BlY2lm aWMgbWVzc2FnZXMgYmV0d2VlbiBub2RlcyB0byByZXNvbHZlIGEgY29uZmxpY3QuIE5vbmUgb2Yg dGhlc2UgYXJlIEludGVudC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJy aSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlNvIGEg bm9kZSByZWNlaXZlcyB0aGlzIGh1bWFuIGlucHV0IHBvbGljeSwgd2hpY2ggSSBzdWdnZXN0IHdl IGZsb29kIGFjcm9zcyB0aGUgZW50aXJlDQogbmV0d29yay4gRXZlcnl0aGluZyBhZnRlciB0aGF0 IGlzIE5PVCBJbnRlbnQuIDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPk1pY2hhZWw8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIg Y29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48Zm9udCBzaXplPSIyIiBjb2xv cj0iYmxhY2siIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6d2luZG93dGV4dDtmb250LXdlaWdodDpib2xkIj5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9iPjxm b250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4NCiBBbmltYSBbbWFpbHRvOmFuaW1hLWJv dW5jZXNAaWV0Zi5vcmddIDxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5PbiBCZWhh bGYgT2YNCjwvc3Bhbj48L2I+RHV6b25ncGVuZzxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDpib2xkIj5TZW50Ojwvc3Bhbj48L2I+IDAxIEFwcmlsIDIwMTYgMDU6NTY8YnI+DQo8Yj48 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86PC9zcGFuPjwvYj4gTGF1cmVudCBDaWF2 YWdsaWEgJmx0O2xhdXJlbnQuY2lhdmFnbGlhQG5va2lhLmNvbSZndDs7IGFuaW1hICZsdDthbmlt YUBpZXRmLm9yZyZndDs8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6 PC9zcGFuPjwvYj4gTWljaGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKSAmbHQ7bWJlaHJpbmdAY2lz Y28uY29tJmd0OzsgUGllcnJlIFBlbG9zbyAmbHQ7UGllcnJlLlBlbG9zb0Bub2tpYS5jb20mZ3Q7 PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6PC9zcGFuPjwv Yj4gUmU6IFtBbmltYV0gQU5JTUEgaW50ZW50IGRpc2N1c3Npb248bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNp emU9IjMiIGNvbG9yPSIjMzMzMzMzIiBmYWNlPSJTaW1TdW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmki PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTiI+SGksIE1pY2hhZWwsIExhdXJlbnQsIFBpZXJyZTxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xv cj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIg Y29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFib3V0IHdoZXRoZXIgQVNBIGNh biBpc3N1ZSBpbnRlbnQsIGFjY29yZGluZyB0byBteSB1bmRlcnN0YW5kaW5nLA0KIGludGVudCBz aG91bGQgYmUgaXNzdWVkIGJ5IGh1bWFuIGJ5IGRlZmF1bHQuPG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0 OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0i IzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQnV0IGluIHRoZSBkaXNjdXNzaW9uLCBJIHJl YWxpemUgdGhhdCB3ZSBtYXkgaGF2ZSB0d28ga2luZHMgb2YNCiBpbnRlbnQuPG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNv bG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIy IiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIGZpcnN0IGtpbmQgb2Yg aW50ZW50cyBhcmUgdGhlIG9uZXMgaXNzdWVkIGZyb20gaHVtYW5zLCBwZXJoYXBzDQogbm90IG9u bHkgZnJvbSBvbmUgcGVyc29uLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJy aSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNh bGlicmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEFuZCBhbm90aGVyIGlzIHRoZSBpbnRlbnQgYWZ0ZXIgdGhlIGNvb3JkaW5h dGlvbi4gVGhleSBhcmUgdGhlDQogaW50ZW50IGluZmx1ZW5jaW5nIHRoZSBub2RlIGRpcmVjdGx5 LiBJIG1lYW4gY29vcmRpbmF0aW9uIGRvZXMgbm90IG5lZWQgdG8gaGFwcGVuIG9uIGV2ZXJ5IG5v ZGUsIGFuZCB0aGV5IG9ubHkgbmVlZCB0aGUgcmVzdWx0LjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3 ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMx ZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoaXMgaXMgYW4gaW50ZXJlc3RpbmcgbW9kZWwu IElmIHdlIGNhbiBmaW5kIHNvbWUgZXhhbXBsZXMsIEkgdGhpbmsNCiBwZXJoYXBzIHNvbWUgQVNB cyBtYXkgY2hvb3NlIHRvIHVzZSBpbnRlbnQgbGlrZSB0aGlzLCBhbmQgQVNBIGNhbiBpc3N1ZSB0 aGUgc2Vjb25kIGtpbmQgb2YgaW50ZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0i Q2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZh Y2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFnYWluLCBpZiBzb21lb25lIHRoaW5rIHRoZXNlIGFyZSBqdXN0 IHNvbWUgc2lnbmFscyBvciBtZXNzYWdlcywNCiB3ZSBjYW4gZ2l2ZSBpdCBhbm90aGVyIG5hbWUs IHN1Y2ggYXMg4oCcbmV0d29yay1sZXZlbCBwb2xpY3nigJ0gb3Ig4oCcaW50ZW50IGFmdGVyIGNv b3JkaW5hdGlvbuKAnS48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJp Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPkJlc3QgUmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFj ZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5ab25ncGVuZyBEdTxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFm NDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iVGFob21h Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTjtmb250LXdlaWdodDpib2xkIj5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9i Pjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iVGFob21hIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+DQogTGF1cmVudCBDaWF2YWdsaWEgWzxhIGhyZWY9Im1haWx0bzpsYXVyZW50LmNpYXZhZ2xp YUBub2tpYS5jb20iPm1haWx0bzpsYXVyZW50LmNpYXZhZ2xpYUBub2tpYS5jb208L2E+XQ0KPGJy Pg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlNlbnQ6PC9zcGFuPjwvYj4gVGh1 cnNkYXksIE1hcmNoIDMxLCAyMDE2IDEyOjEwIEFNPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPlRvOjwvc3Bhbj48L2I+IGFuaW1hPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZv bnQtd2VpZ2h0OmJvbGQiPkNjOjwvc3Bhbj48L2I+IE1pY2hhZWwgQmVocmluZ2VyOyBQaWVycmUg UGVsb3NvOyBEdXpvbmdwZW5nOyBMYXVyZW50IENpYXZhZ2xpYTxicj4NCjxiPjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0Ojwvc3Bhbj48L2I+IEFOSU1BIGludGVudCBkaXNj dXNzaW9uPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBjb2xvcj0iIzMzMzMzMyIgZmFjZT0iU2lt U3VuIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxmb250IHNp emU9IjMiIGNvbG9yPSIjMzMzMzMzIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7LHNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5EZWFyIGFsbCw8YnI+DQo8 YnI+DQpNaWNoYWVsLCBab25ncGVuZywgUGllcnJlIGFuZCBJIGhhZCBhIGRpc2N1c3Npb24gb24g QU5JTUEgaW50ZW50IHRoaXMgbW9ybmluZywgdHJ5aW5nIHRvIGNsYXJpZnkgc29tZSBwb2ludHMg YW5kIHByb2dyZXNzIHRvd2FyZCBhIGNvbW1vbiB1bmRlcnN0YW5kaW5nLjxicj4NCjxicj4NCldl IHVzZWQgYSBzbWFsbCwgcGFydGlhbCBzZXQgb2YgcXVlc3Rpb25zIGFuZCBleGFtcGxlcyBpbiBz dXBwb3J0LiA8YnI+DQo8YnI+DQpCZWxvdyB5b3UgbWF5IGZpbmQgYSBzdW1tYXJ5IGZvciB5b3Vy IGluZm9ybWF0aW9uLiBDb21tZW50cyBhbmQgZnVydGhlciBpbnRlcmFjdGlvbnMgYXJlIG1vc3Qg d2VsY29tZS48YnI+DQo8YnI+DQpUaGFua3MsIDxicj4NCk1pY2hhZWwsIFpvbmdwZW5nLCBQaWVy cmUgYW5kIExhdXJlbnQuPGJyPg0KLS0tPGJyPg0KPGJyPg0KLS0tIFF1ZXN0aW9uczxicj4NCjEt V2hvIHdyaXRlcyBpbnRlbnRzPyA8YnI+DQoyLUhvdyBtYW55IGludGVudHM/IDxicj4NCjMtSG93 IG1hbnkgZG9tYWlucz8gPGJyPg0KNC1XaGF0IGFyZSB0aGUgaW50ZW50IGxldmVscy9oaWVyYXJj aHk/IDxicj4NCjUtV2hlcmUvYnkgd2hhdCBpcyBpbnRlbnQgcHJvY2Vzc2VkL2NvbXBpbGVkPyA8 YnI+DQo2LUZsb29kaW5nOiB3aGF0IGFyZSB0aGUgcmVxdWlyZW1lbnRzPyA8YnI+DQpQcm9wYWdh dGlvbiBhbW9uZyB3aG8/IEhvdyBkaXN0cmlidXRlZD8gSG93IGZyZXF1ZW50PyAtJmd0OyBpZiBt YW55IOKAnG92ZXJsYXBwaW5n4oCdIGludGVudHMsIChwYXJ0aWFsKSB1cGRhdGVzIG1heSBiZWNv bWUgZnJlcXVlbnQuDQo8YnI+DQo3LUhvdyBpcyBpbnRlbnQgdW5kZXJzdG9vZCBieSBub2RlL0FT QT8gLSZndDsgbW9kZWwsIGRpY3Rpb25hcnkuLi4gPGJyPg0KOC1DYW4gYW4gQVNBIHdyaXRlIGFu IGludGVudCBmb3IgYW5vdGhlciBBU0E/IDxicj4NCldoYXQgYWJvdXQgY29vcmRpbmF0aW9uIG9y IGtub3dsZWRnZSB3cml0aW5nL3JlY2VpdmluZyBpbnRlbnRzPyBBcmUgdGhlc2UgZnVuY3Rpb25z IEFTQXMvb3RoZXIgdGhpbmdzLi4/PGJyPg0KPGJyPg0KPGJyPg0KLS0tIEludGVudCBleGFtcGxl czxicj4NCkEtRG8gdGhlIHJpZ2h0IHRoaW5nPGJyPg0KQi1GcmVlemUgbmV0d29yayBlbnJvbGxt ZW50PGJyPg0KQy1BcnJhbmdlIFZNIGd1ZXN0IGRpc3RyaWJ1dGlvbiBzbyB0aGF0IChDUFUpIHV0 aWxpemF0aW9uIGlzICZsdDsgNzAlPGJyPg0KRC1Bc3NpZ24gcHJlZml4ZXMgdG8gUkFOIG5vZGVz PGJyPg0KRS1Qcm90ZWN0IHByZW1pdW0gdXNlcnMgdHJhZmZpYzxicj4NCkYtTWF4aW1pemUgZW5l cmd5IHNhdmluZ3M8YnI+DQo8YnI+DQo8YnI+DQotLS0gRGlzY3Vzc2lvbjxicj4NCjEpIFdobyB3 cml0ZXMgaW50ZW50cz8gPGJyPg0KJm5ic3A7Jm5ic3A7IExhdXJlbnQncyB2aWV3OiA8YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsgSW50ZW50cyBhcmUgaXNzdWVkIGJ5IGEgbWFuYWdlbWVudCBmdW5j dGlvbi4gQ2FuIGJlIGh1bWFuIC8gdmlhIEJTUy9PU1MuPGJyPg0KJm5ic3A7Jm5ic3A7IE1pY2hh ZWwncyB2aWV3OiA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgT3JpZ2luIG9mIGludGVudCBpcyAm cXVvdDtub24tdGVjaG5pY2FsJnF1b3Q7LiBpLmUuLCByZWdpc3RyYXIgZG9lc24ndCBpc3N1ZSBp bnRlbnQuPGJyPg0KJm5ic3A7Jm5ic3A7IDx1PkRpc2N1c3Npb246PC91PiBob3cgdG8gc2V0IHRo ZSBjdXJzb3Igb24gbm9uLXRlY2huaWNhbD8gSW4gZXhhbXBsZXMgRCBvciBFLCB0aGUgaW50ZW50 IHdyaXRlciBoYXMgc29tZSByb3VnaCBrbm93bGVkZ2UvdW5kZXJzdGFuZGluZyBvZiB0ZWNobmlj YWwgYXNwZWN0cyBvZiBhIG5ldHdvcmsgKHdpcmVsZXNzIGFuZCBhZGRyZXNzIGFzcGVjdHMgZm9y IGV4YW1wbGUgRCA7IHByb3RlY3Rpb24vcmVzdG9yYXRpb24gYW5kIHRyYWZmaWMgZW5naW5lZXJp bmcNCiBmb3IgZXhhbXBsZSBFKS48YnI+DQombmJzcDsmbmJzcDsgPHU+Q29uc2Vuc3VzOjwvdT4g SW50ZW50IGlzIG9yaWdpbmF0ZWQgYnkgaHVtYW4vYXQgT1NTIGxldmVsLCBOT1QgYnkgYSBuZXR3 b3JrIGRldmljZSAvIGZ1bmN0aW9uLiAob2YgY291cnNlIEludGVudCBjYW4gYmUgaW5nZXN0ZWQg LyBpbnB1dHRlZCBvbiBhIHNwZWNpZmljIGRldmljZSk8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGJyPg0KMikgSG93IG1hbnkgaW50ZW50cz8g PGJyPg0KJm5ic3A7Jm5ic3A7IExhdXJlbnQncyB2aWV3OiA8YnI+DQombmJzcDsmbmJzcDsmbmJz cDsgVGhlcmUgbWF5IGJlIGRpZmZlcmVudCBvbmVzLCBsaWtlICZxdW90O2ZyZWV6ZSBuZXR3b3Jr JnF1b3Q7LCAmcXVvdDtvcHRpbWl6ZSBlbmVyZ3kgc2F2aW5ncyZxdW90OywgY2YgZXhhbXBsZXMu IEFsbCBhcmUgdmFsaWQgYW5kIGNvbmN1cnJlbnQuDQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsg Q2FuIHdlIHdyYXAgdGhhdCBpbnRvIG9uZSBmaWxlPyA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsg SG93IGRvIHdlIHNoYXJlIHRoYXQ/IDxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyA8dT5E aXNjdXNzaW9uOjwvdT48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgV2UgY2Fubm90IGRlZmluZSBJ bnRlbnQgdG9vIHByZWNpc2VseSB0b2RheS4gPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IEJ1dCB3 ZSBjYW4gZGVmaW5lIHdoZXJlIEludGVudCBpcyBjb21pbmcgZnJvbSBhbmQgaG93IHRvIGRpc3Ry aWJ1dGUgaXQuIDxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBDYW4gSW50ZW50IGhhdmUg dGFyZ2V0cz8gPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAtIEV4 OiBhbiBpbnRlbnQgZm9yIHRyYWZmaWMgZW5naW5lZXJpbmcgYW5kIGFuIGludGVudCBmb3IgZW5l cmd5IGNvbnN1bXB0aW9uIG9wdGltaXphdGlvbiBtYXkgbmVlZCBzcGVjaWZpYyAoc2FtZSBvciBk aWZmZXJlbnQpIHRhcmdldHMuIHRoZSBmdW5jdGlvbnMgY291bGQgaGF2ZSBkaWZmZXJlbnQgb2Jq ZWN0aXZlcyBwZXIgc2V0IG9mIHRhcmdldHMuDQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBFeDogdHdvIG5ldHdvcmsgc2VnbWVudHMsIGNvcmUgYW5k IG1ldHJvLiBUaGVuIGludGVudCBzaG91bGQgYmUgYWJsZSB0byBzYXkgJnF1b3Q7b24gY29yZTog b3B0aW1pemUgb24gYXZhaWxhYmlsaXR5JnF1b3Q7OyBvbiBhY2Nlc3M6ICZxdW90O29wdGltaXpl IG9uIGVuZXJneSBzYXZpbmcuJnF1b3Q7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZu YnNwOyZuYnNwOyAtIFRoZXJlZm9yZSB3ZSBuZWVkIHNjb3Blcy4gPGJyPg0KPGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IEhvdyBkbyB5b3UgZGVmaW5lICZxdW90O3RhcmdldCZxdW90Oz8g PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAtIElzIGEgcm9sZSBl bm91Z2g/IDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgLSBQaWVy cmU6IFNob3VsZCBiZSBtb3JlIHRoYW4gcm9sZS4gRXhhbXBsZTogTWV0cm8gYW5kIGNvcmUuIE5l ZWQgdG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiBkaWZmZXJlbnQgbWV0cm8gbmV0d29ya3MgZm9yIGV4 YW1wbGUuDQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IC0gTWlj aGFlbDogSWYgd2UgaGF2ZSBzdWItZG9tYWlucywgYW5kIGRlZmluZSBpbnRlbnQgcGVyIHN1Yi1k b21haW4sIHdvdWxkIHRoYXQgZG8/DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5i c3A7Jm5ic3A7IC0gTGF1cmVudDogYSBjb21iaW5hdGlvbiBvZiByb2xlcyBhbmQgKHN1Yi0pZG9t YWluKHMpIHNob3VsZCBiZSBhYmxlIHRvIGNvdmVyIG1vc3QgY2FzZXMuDQo8YnI+DQo8YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsgPHU+Q29uc2Vuc3VzOjwvdT4gYSBjb21iaW5hdGlvbiBvZiByb2xl cyBhbmQgKHN1Yi0pZG9tYWluKHMpIHNob3VsZCBiZSBhYmxlIHRvIGNvdmVyIG1vc3QgY2FzZXMu DQo8YnI+DQo8YnI+DQo8YnI+DQo4KSBDYW4gYW4gQVNBIHdyaXRlIGFuIGludGVudD8gPGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBpZXJyZTogRXhhbXBsZSBpcyB0aGUgY29vcmRpbmF0aW9uIGZ1 bmN0aW9uOiB0aGF0IGZ1bmN0aW9uIGNvdWxkIHNlbmQgb3V0IGludGVudCBkaXJlY3RseSB0byBt b2RpZnkgdGhlIGJlaGF2aW9yIG9mIGEgZ3JvdXAgb2YgQVNBcy4NCjxicj4NCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBNdWx0aXBsZSBBU0FzIGNvdWxkIGRvIGNvbmZsaWN0aW5nIHRoaW5ncy4g VGhlIGNvb3JkaW5hdGlvbiBmdW5jdGlvbiBtdXN0IHJlc29sdmUgdGhhdC4gU2hvdWxkIGl0IGlz c3VlL21vZGlmeSBpbnRlbnQgaXRzZWxmPw0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IExhdXJl bnQ6IHExOiBzaG91bGQgaXQgb3V0cHV0IHNvbWV0aGluZyBpbiB0aGUgZm9ybSBvZiBhbiBpbnRl bnQ/IHEyOiBzaG91bGQgdGhlIGNvb3JkaW5hdGlvbiBmdW5jdGlvbiB1cGRhdGUgaW50ZW50Pw0K PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IE1pY2hhZWw6IElzbid0IGl0IHRoYXQgdGhlIGJlaGF2 aW9yIG9mIHRoZSBjb29yZGluYXRpb24gZnVuY3Rpb24gbXVzdCBhbHNvIGJlIHJlc29sdmVkIGJ5 IGEgaHVtYW4gb3JpZ2luYXRlZCBpbnRlbnQ/IGkuZS4gdGhlIGNvbmZsaWN0aW5nIGZ1bmN0aW9u cyBpbmZvcm0gdGhlIG9wZXJhdG9yIHZpYSBhIGZlZWRiYWNrIGxvb3AgYW5kIHRoZSBvcGVyYXRv ciBhZGp1c3QgdGhlIGludGVudHMuPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IExhdXJlbnQ6IFRo aXMgaXMgcG9zc2libGUgLyBjb21wbGVtZW50YXJ5LiBJbiBvbmNlIGNhc2UsIHRoZSBvcGVyYXRv ciBpcyB0aGUgb25lIGNsb3NpbmcgdGhlIGNvbnRyb2wgbG9vcCAvIGNoYW5naW5nIHRoZSBiZWhh dmlvcnMgdmlhIGludGVudCB1cGRhdGVzLiBXaXRoIGEgY29vcmRpbmF0aW9uIGZ1bmN0aW9uLCBw YXJ0L2FsbCBvZiB0aGF0IHByb2Nlc3MgY291bGQgYmUgYXV0b21hdGVkL2RyaXZlbiBieSB0aGUg bWFjaGluZSAodGhlIGNvb3JkaW5hdGlvbg0KIGZ1bmN0aW9uIGNsb3NlcyB0aGUgY29udHJvbCBs b29wLCBpbiB0aGUgY29udHJvbCByYW5nZSBhbGxvd2VkIGJ5IHRoZSBvcGVyYXRvcikuIFRoZXJl IG1heSBiZSBpbnRlcm1lZGlhdGUgc3RlcHMgd2hlcmUgdW5mb3Jlc2VlbiBjb25mbGljdHMgd2ls bCBiZSByZXNvbHZlZC4gVGhpcyBpcyBydW4gdGltZSBjb25mbGljdCByZXNvbHV0aW9uLg0KPGJy Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IE1pY2hhZWw6IERvIHdlIGZvcmVzZWUgYSBjYXNlIHdoZXJl IG5ldHdvcmtzIHJlc29sdmUgY29uZmxpY3RzIHdpdGhvdXQgaHVtYW4gY29udHJvbD8mbmJzcDsN Cjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBMYXVyZW50OiB0aGlzIGlzIHBvc3NpYmxlIChoYXMg YmVlbiBkZW1vbnN0cmF0ZWQgaW4gc29tZSBwcm9qZWN0cykuIFdlIHNob3VsZCBhbGxvdyBmb3Ig Ym90aCBhcHByb2FjaGVzIHRvIHdvcmssIHBvc3NpYmx5IGluIGEgcGhhc2VkIGFwcHJvYWNoLjxi cj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBXaGVuIHVuZm9yZXNlZW4gY29uZmxpY3RzIGFy aXNlLCBBU0FzIGNhbiBzaWduYWwgdG8gZWFjaCBvdGhlciwgYnV0IHRoZXkgd2lsbCBub3QgaXNz dWUgSW50ZW50IHRoZW1zZWx2ZXMuDQo8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgPHU+ Q29uc2Vuc3VzOjwvdT4gQ2Fubm90IHNheSB0b2RheSBpZiBvdGhlciBmdW5jdGlvbnMgY2FuL2Fy ZSBhbGxvd2VkIHRvIGlzc3VlIGludGVudCAvIGludGVudCB1cGRhdGVzLiBGdW5jdGlvbnMvQVNB cyBtYXkgaGF2ZSB0byAqc2lnbmFsKiBvciAqbWVzc2FnZSogc29tZWhvdywgYnV0IHRoYXQgdGhp cyBpc27igJl0IGNvbnNpZGVyZWQgJm5ic3A7Jm5ic3A7Jm5ic3A7IGludGVudCB5ZXQuPGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZvciBmdXJ0aGVyIHN0dWR5OiB0cnkgdG8gZGVzaWduIHRoZSBp bnRlbnQgc3lzdGVtIHNvIHRoYXQgYm90aCBhcHByb2FjaGVzIChmZWVkYmFjayBsb29wLCBjb29y ZGluYXRpb24pIGFyZSBwb3NzaWJsZS4gTW9yZSBpbnZlc3RpZ2F0aW9uL2FuYWx5c2lzIG5lZWRl ZC48YnI+DQo8YnI+DQo8YnI+DQozKSBIb3cgbWFueSBkb21haW5zPyA8YnI+DQombmJzcDsmbmJz cDsmbmJzcDsgTmFtaW5nIGlzc3VlOiAmcXVvdDtkb21haW4mcXVvdDsgYnkgTGF1cmVudCBpcyBh IGhpZ2ggbGV2ZWwgY29uY2VwdDsgY291bGQgYmUgdW5kZXJzdG9vZCBhcyBhIEROUyBkb21haW4g bmFtZS4gTmVlZHMgdG8gYmUgY2xlYXIgd2hhdCB3ZSdyZSB0YWxraW5nIGFib3V0Lg0KPGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7IFdpdGggZG9tYWluLW5hbWUgYmFzZWQgaW50ZW50IChpLmUuLCBh Y2Nlc3MuYXR0Lm5ldCkgYW5kIHJvbGVzIChlLmcsIGFjY2VzcyBkZXZpY2VzKSB3ZSBzaG91bGQg YmUgYWJsZSB0byBleHByZXNzIHdoYXQgd2UgbmVlZCBmb3Igbm93LiBOb3QgMTAwJSBjbGVhciBm b3Igbm93Lg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IFR3byB0eXBlcyBvZiBkb21haW5zOiAo YWRtaW5pc3RyYXRpdmUsIHRlY2hub2xvZ3kpIGRvbWFpbnMgZGVmaW5lZCAoYSBwcmlvcmkpIGJ5 IHRoZSBvcGVyYXRvciBlLmcuIFJBTiwgTUFOLCBXQU4uIGFuZCB0aGUgZG9tYWluIG9mIGFwcGxp Y2F0aW9uIG9mIGEgcG9saWN5IGkuZS4gcmVzb2x2aW5nIHRoZSBwb2xpY3kgZGVmaW5lcyBhIHNl dCBvZiB0YXJnZXQgZW50aXRpZXMgdG8gd2hpY2ggdGVoIHBvbGljeSBhcHBsaWVzLCB0aGlzIGlz IHRoZQ0KIGRvbWFpbiBvZiBhcHBsaWNhdGlvbiBvZiB0aGUgZ2l2ZW4gcG9saWN5Ljxicj4NCjxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyA8dT5Db25zZW5zdXM6PC91PiBOZWVkIHRvIGNsYXJpZnkg d29yZGluZyB0byBhdm9pZCBjb25mdXNpb24uPGJyPg0KPGJyPg0KPGJyPg0KNCkgV2hhdCBhcmUg dGhlIGludGVudCBsZXZlbHMvaGllcmFyY2h5PyA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgUmVs YXRlZCB0byBwb2xpY3kgYmFzZWQgbWFuYW1lZ2VudCBtb2RlbDogYnVzaW5lc3MgbGV2ZWwsIHNl cnZpY2UgbGV2ZWwsIG5ldHdvcmsgbGV2ZWwsIGRldmljZSBsZXZlbCwgZXRjLiBTbyBmYXIgaW4g QU5JTUEgd2UgY29uc2lkZXIgb25seSB0d28gbGV2ZWxzOiBVc2VyIGFuZCBBU0EuDQo8YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsgRG8gd2UgbmVlZCBhIHNlcnZpY2UgbGV2ZWw/IGUuZywgVlBOLiA8 YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgQ2FuIHdlIGV4cHJlc3MgZGlmZmVyZW50IGxldmVscyB3 aXRoIHVzaW5nIHJvbGVzPyBTbyBhIHJvbGUgY291bGQgYmUgdmVyeSBzcGVjaWZpYyAocm91dGUg cmVmbGVjdG9yKSwgb3Igc2VydmljZSByZWxhdGVkIChlLmcuLCBWUE4gaGVhZC1lbmQpPw0KPGJy Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IEJ1dCB0aGVuIHdlIG1heSBuZWVkIHRvIG5lc3Qgcm9sZXM/ ISA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgTWF5YmUgd2UgbmVlZCAmcXVvdDtidXNpbmVzcyZx dW90OyAmcXVvdDtzZXJ2aWNlJnF1b3Q7ICZxdW90O25ldHdvcmsgKEFTQSkmcXVvdDsgPC9zcGFu PjwvZm9udD48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyAsIHNlcmlmIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3ICwgc2VyaWYmcXVvdDssc2Vy aWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPmxldmVsPzxicj4NCjxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOyA8dT5Db25zZW5zdXM6PC91PiB0byBiZSBmdXJ0aGVyIGRpc2N1c3NlZC48YnI+ DQo8YnI+DQo8YnI+DQpRdWVzdGlvbnMgNSwgNiwgNyB3ZXJlIG5vdCBkaXNjdXNzZWQgZHVlIHRv IGxhY2sgb2YgdGltZS48YnI+DQotLS08L3NwYW4+PC9mb250PjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_1341e3fd501e4cbb8cbe9fbdc1d158deXCHRCD006ciscocom_-- From nobody Fri Apr 1 06:16:12 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8554612D5CA for ; Fri, 1 Apr 2016 06:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 xJDuXquIIBGZ for ; Fri, 1 Apr 2016 06:16:08 -0700 (PDT) Received: from maila1.tigertech.net (maila1.tigertech.net [208.80.4.151]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 685C812D159 for ; Fri, 1 Apr 2016 06:16:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila1.tigertech.net (Postfix) with ESMTP id 3D93C360613; Fri, 1 Apr 2016 06:16:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1459516568; bh=hcarjzjIvhNlYpOfltc1X5qNiAdeOuBUA/8u+6SvY0I=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=bv6WGQ0qVp/291qyLCHnRxx21DuArOWxFBdGXiTvOt9W1vh3N5xmdCiLyPT/yfSPl NKz1NYUsZxsyiA75Uf0DWsOWBCI+QI7fN+M2sEfzo1hxSzp6Dlzeeqh4PbEb910cJN 2TKCCjcMlxiGkMiyGqVPKOE+7J0CPvzQifSyjSTM= X-Virus-Scanned: Debian amavisd-new at maila1.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila1.tigertech.net (Postfix) with ESMTPSA id 5BDEA3607AF; Fri, 1 Apr 2016 06:16:07 -0700 (PDT) To: "Michael Behringer (mbehring)" , Duzongpeng , Laurent Ciavaglia , anima References: <56FBFA6A.4010400@alcatel-lucent.com> <1341e3fd501e4cbb8cbe9fbdc1d158de@XCH-RCD-006.cisco.com> From: "Joel M. Halpern" Message-ID: <56FE7492.1070308@joelhalpern.com> Date: Fri, 1 Apr 2016 09:16:02 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <1341e3fd501e4cbb8cbe9fbdc1d158de@XCH-RCD-006.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Pierre Peloso Subject: Re: [Anima] ANIMA intent discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 01 Apr 2016 13:16:11 -0000 I think even with this definition, we do not have a clear scope. let me use two very similar examples: 1) Intent: Turn of admission of new nodes to the system. This is human generate, in response to observed but unspecified conditions. It applies from now until the human turns it off. Anima can act on this. 2) Intent: If average network link load exceeds 70%, do not admit any new nodes to the system. This is also a human defined intent. However, I do not see how this intent can be distributed to the Anima participants and acted on. It has to be processed by some other system. And when the condition is observed, the system will generate something like intent 1, which will be processed by Anima, even thout it is not directly human input. Yours, Joel On 4/1/16 3:05 AM, Michael Behringer (mbehring) wrote: > We’re starting to call everything that flies through an autonomic > network Intent, and the naming is getting very confusing. > > To me: Intent = network wide human input policy > > everything else: not Intent. Call it signaling, messaging, feedback > loops, SNMP, GRASP, whatever. > > Of course a node may, looking at Intent, need to negotiate something > with a neighbour; or, run a feedback loop with the operator alerting him > of an exceptional condition; or there may be specific messages between > nodes to resolve a conflict. None of these are Intent. > > So a node receives this human input policy, which I suggest we flood > across the entire network. Everything after that is NOT Intent. > > Michael > > *From:*Anima [mailto:anima-bounces@ietf.org] *On Behalf Of *Duzongpeng > *Sent:* 01 April 2016 05:56 > *To:* Laurent Ciavaglia ; anima > > *Cc:* Michael Behringer (mbehring) ; Pierre Peloso > > *Subject:* Re: [Anima] ANIMA intent discussion > > Hi, Michael, Laurent, Pierre > > About whether ASA can issue intent, according to my > understanding, intent should be issued by human by default. > > But in the discussion, I realize that we may have two kinds of > intent. > > The first kind of intents are the ones issued from humans, > perhaps not only from one person. > > And another is the intent after the coordination. They are the > intent influencing the node directly. I mean coordination does not need > to happen on every node, and they only need the result. > > This is an interesting model. If we can find some examples, I > think perhaps some ASAs may choose to use intent like this, and ASA can > issue the second kind of intent. > > Again, if someone think these are just some signals or > messages, we can give it another name, such as “network-level policy” or > “intent after coordination”. > > Best Regards > > Zongpeng Du > > *From:*Laurent Ciavaglia [mailto:laurent.ciavaglia@nokia.com] > *Sent:* Thursday, March 31, 2016 12:10 AM > *To:* anima > *Cc:* Michael Behringer; Pierre Peloso; Duzongpeng; Laurent Ciavaglia > *Subject:* ANIMA intent discussion > > Dear all, > > Michael, Zongpeng, Pierre and I had a discussion on ANIMA intent this > morning, trying to clarify some points and progress toward a common > understanding. > > We used a small, partial set of questions and examples in support. > > Below you may find a summary for your information. Comments and further > interactions are most welcome. > > Thanks, > Michael, Zongpeng, Pierre and Laurent. > --- > > --- Questions > 1-Who writes intents? > 2-How many intents? > 3-How many domains? > 4-What are the intent levels/hierarchy? > 5-Where/by what is intent processed/compiled? > 6-Flooding: what are the requirements? > Propagation among who? How distributed? How frequent? -> if many > “overlapping” intents, (partial) updates may become frequent. > 7-How is intent understood by node/ASA? -> model, dictionary... > 8-Can an ASA write an intent for another ASA? > What about coordination or knowledge writing/receiving intents? Are > these functions ASAs/other things..? > > > --- Intent examples > A-Do the right thing > B-Freeze network enrollment > C-Arrange VM guest distribution so that (CPU) utilization is < 70% > D-Assign prefixes to RAN nodes > E-Protect premium users traffic > F-Maximize energy savings > > > --- Discussion > 1) Who writes intents? > Laurent's view: > Intents are issued by a management function. Can be human / via > BSS/OSS. > Michael's view: > Origin of intent is "non-technical". i.e., registrar doesn't issue > intent. > _Discussion:_ how to set the cursor on non-technical? In examples D or > E, the intent writer has some rough knowledge/understanding of technical > aspects of a network (wireless and address aspects for example D ; > protection/restoration and traffic engineering for example E). > _Consensus:_ Intent is originated by human/at OSS level, NOT by a > network device / function. (of course Intent can be ingested / inputted > on a specific device) > > > 2) How many intents? > Laurent's view: > There may be different ones, like "freeze network", "optimize > energy savings", cf examples. All are valid and concurrent. > Can we wrap that into one file? > How do we share that? > > _Discussion:_ > We cannot define Intent too precisely today. > But we can define where Intent is coming from and how to distribute > it. > > Can Intent have targets? > - Ex: an intent for traffic engineering and an intent for > energy consumption optimization may need specific (same or different) > targets. the functions could have different objectives per set of targets. > - Ex: two network segments, core and metro. Then intent should > be able to say "on core: optimize on availability"; on access: "optimize > on energy saving." > - Therefore we need scopes. > > How do you define "target"? > - Is a role enough? > - Pierre: Should be more than role. Example: Metro and core. > Need to distinguish between different metro networks for example. > - Michael: If we have sub-domains, and define intent per > sub-domain, would that do? > - Laurent: a combination of roles and (sub-)domain(s) should be > able to cover most cases. > > _Consensus:_ a combination of roles and (sub-)domain(s) should be able > to cover most cases. > > > 8) Can an ASA write an intent? > Pierre: Example is the coordination function: that function could > send out intent directly to modify the behavior of a group of ASAs. > Multiple ASAs could do conflicting things. The coordination > function must resolve that. Should it issue/modify intent itself? > Laurent: q1: should it output something in the form of an intent? > q2: should the coordination function update intent? > Michael: Isn't it that the behavior of the coordination function > must also be resolved by a human originated intent? i.e. the conflicting > functions inform the operator via a feedback loop and the operator > adjust the intents. > Laurent: This is possible / complementary. In once case, the > operator is the one closing the control loop / changing the behaviors > via intent updates. With a coordination function, part/all of that > process could be automated/driven by the machine (the coordination > function closes the control loop, in the control range allowed by the > operator). There may be intermediate steps where unforeseen conflicts > will be resolved. This is run time conflict resolution. > Michael: Do we foresee a case where networks resolve conflicts > without human control? > Laurent: this is possible (has been demonstrated in some projects). > We should allow for both approaches to work, possibly in a phased approach. > > When unforeseen conflicts arise, ASAs can signal to each other, but > they will not issue Intent themselves. > > _Consensus:_ Cannot say today if other functions can/are allowed to > issue intent / intent updates. Functions/ASAs may have to *signal* or > *message* somehow, but that this isn’t considered intent yet. > For further study: try to design the intent system so that both > approaches (feedback loop, coordination) are possible. More > investigation/analysis needed. > > > 3) How many domains? > Naming issue: "domain" by Laurent is a high level concept; could be > understood as a DNS domain name. Needs to be clear what we're talking > about. > With domain-name based intent (i.e., access.att.net) and roles > (e.g, access devices) we should be able to express what we need for now. > Not 100% clear for now. > Two types of domains: (administrative, technology) domains defined > (a priori) by the operator e.g. RAN, MAN, WAN. and the domain of > application of a policy i.e. resolving the policy defines a set of > target entities to which teh policy applies, this is the domain of > application of the given policy. > > _Consensus:_ Need to clarify wording to avoid confusion. > > > 4) What are the intent levels/hierarchy? > Related to policy based manamegent model: business level, service > level, network level, device level, etc. So far in ANIMA we consider > only two levels: User and ASA. > Do we need a service level? e.g, VPN. > Can we express different levels with using roles? So a role could > be very specific (route reflector), or service related (e.g., VPN > head-end)? > But then we may need to nest roles?! > Maybe we need "business" "service" "network (ASA)" level? > > _Consensus:_ to be further discussed. > > > Questions 5, 6, 7 were not discussed due to lack of time. > --- > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Fri Apr 1 08:22:08 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557E512D100 for ; Fri, 1 Apr 2016 08:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 LaQuFCDYPOV0 for ; Fri, 1 Apr 2016 08:22:05 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 772C012D184 for ; Fri, 1 Apr 2016 08:22:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12050; q=dns/txt; s=iport; t=1459524123; x=1460733723; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=kQcPpAMaTizzk9NIuoOnyZdLqtgS/nyBCzLyeKoODro=; b=Tt6Q0IXPYx3nAYvDnFM0bWwPnQKKIc2FBilD4S0ippPNHq0gMSDuHmYv S6Ljs/1ao1HVv7hiEB6BNAdPeDgc7dJPXHi62xEKAOFyXQeoqkLqvDNJ8 c0RhTKxEfoB6Pqwj0IUGOlhaG4gNOrCelYvjqqBPhqRz4PTanubRGTfJN A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAgCbkf5W/5pdJa1aA4J1TFN9BrYhg?= =?us-ascii?q?mCCDwENgXIhhWwCHIEoOBQBAQEBAQEBZSeEQQEBAQQjYgICAgEIEQMBAQEoAwI?= =?us-ascii?q?CAhkXFAkIAgQBEognDrMhkQABAQEBAQEBAQEBAQEBAQEBAQEBAQEVBIgPglGED?= =?us-ascii?q?hEBIwoHCgEVEYI5K4IrBYlWiT+EZAGOB4FmhE2IWo8XAR4BAUKDZ2wBhzE2fgE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos; i="5.24,427,1454976000"; d="scan'208,217"; a="88948197" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Apr 2016 15:22:02 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u31FM0HT012053 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Apr 2016 15:22:02 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 1 Apr 2016 11:20:51 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Fri, 1 Apr 2016 11:20:51 -0400 From: "Jason Coleman (colemaj)" To: Laurent Ciavaglia , "Michael Behringer (mbehring)" , Martin Vigoureux , "anima@ietf.org" Thread-Topic: [Anima] ANIMA intent discussion Thread-Index: AQHRjCoTZEilVhzOO0eSNltNsN15iA== Date: Fri, 1 Apr 2016 15:20:51 +0000 Message-ID: References: <56FBFA6A.4010400@alcatel-lucent.com> <1493.1459390266@obiwan.sandelman.ca> <9e9c9bd91fe94fafb7ec3280a6b494b6@XCH-RCD-006.cisco.com> <56FCE18B.6030600@alcatel-lucent.com> <97667ecb08b348d1937f88d00e597e01@XCH-RCD-006.cisco.com> <56FCEA32.3090101@alcatel-lucent.com> In-Reply-To: <56FCEA32.3090101@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.225.122] Content-Type: multipart/alternative; boundary="_000_F0465A7466EF438C991AFF91E3BE8333ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] ANIMA intent discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 01 Apr 2016 15:22:07 -0000 --_000_F0465A7466EF438C991AFF91E3BE8333ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3b3VsZCBsaWtlIHRvIHRoaW5rIHRoYXQgSW50ZW50IGNhbiBiZSBzb21ldGhpbmcgdGhhdCBj YW4gYmUgZGVmaW5lZCBieSBhIHRlY2huaWNhbCBwZXJzb24gYW5kIHRoZW4gaW4tYWN0ZWQgYnkg c29tZW9uZSBsZXNzIG9yIG5vbi10ZWNobmljYWwuDQpJIHRoaW5rIHRoYXQgTGF1cmVudCBpcyBy aWdodCB0aGF0IHRoZSBkZWZpbml0aW9uIG9mIEludGVudCwgaG93IGl0IHdyaXR0ZW4sIHByZXNl bnRlZCwgYW5kIGNoZWNrZWQgaXMgYSBwcm9qZWN0IHRoYXQgaXMgcXVpdGUgbGFyZ2UgYW5kIGxp a2VseSBvdXRzaWRlIHRoZSBzY29wZSBvZiBBTklNQS4gSSB0aGluayB0aGF0IEFOSU1BIHdpbGwg Y2xvc2VseSBtb25pdG9yIHRoZSBkZWZpbml0aW9uIG9mIEludGVudCBhbmQgaGF2ZSBpbXBhY3Qg b24gaXQgYXMgd2VsbCBhcyBvdGhlcnMgdGhhdCBhcmUgaW50ZXJlc3RlZCBpbiB1c2luZyBJbnRl bnQuICBTZWVtcyB0aGF0IGlmIGRvbmUgcHJvcGVybHkgQU5JTUEgd291bGQgYmUgb25lIG1ldGhv ZCB0byBkZWxpdmVyIEludGVudCwgYnV0IG5vdCB0aGUgb25seSBtZXRob2QuDQoNCi0tDQpKYXNv biBDb2xlbWFuIENDSUUjMTIwNjkNCmptY29sZW1hbkBjaXNjby5jb208bWFpbHRvOmptY29sZW1h bkBjaXNjby5jb20+DQpwaG9uZTogKzEgNTEyLTM0MC0zMTM0DQpUZWNobmljYWwgTGVhZCBFbmdp bmVlciBDTVMNCg0KVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZp bGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBp cyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50IChvciBhdXRob3JpemVkIHRvIHJlY2VpdmUgZm9yIHRoZSByZWNpcGllbnQpLCBwbGVhc2Ug Y29udGFjdCB0aGUgc2VuZGVyIGJ5IHJlcGx5IGVtYWlsIGFuZCBkZWxldGUgYWxsIGNvcGllcyBv ZiB0aGlzIG1lc3NhZ2UuDQpGb3IgY29ycG9yYXRlIGxlZ2FsIGluZm9ybWF0aW9uIGdvIHRvOg0K aHR0cDovL3d3dy5jaXNjby5jb20vd2ViL2Fib3V0L2RvaW5nX2J1c2luZXNzL2xlZ2FsL2NyaS9p bmRleC5odG1sDQoNCg0KRnJvbTogQW5pbWEgPGFuaW1hLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv OmFuaW1hLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgTGF1cmVudCBDaWF2YWdsaWEg PGxhdXJlbnQuY2lhdmFnbGlhQG5va2lhLmNvbTxtYWlsdG86bGF1cmVudC5jaWF2YWdsaWFAbm9r aWEuY29tPj4NCk9yZ2FuaXphdGlvbjogQmVsbCBMYWJzDQpEYXRlOiBUaHVyc2RheSwgTWFyY2gg MzEsIDIwMTYgYXQgNDoxMyBBTQ0KVG86ICJNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpIiA8 bWJlaHJpbmdAY2lzY28uY29tPG1haWx0bzptYmVocmluZ0BjaXNjby5jb20+PiwgTWFydGluIFZp Z291cmV1eCA8bWFydGluLnZpZ291cmV1eEBub2tpYS5jb208bWFpbHRvOm1hcnRpbi52aWdvdXJl dXhAbm9raWEuY29tPj4sICJhbmltYUBpZXRmLm9yZzxtYWlsdG86YW5pbWFAaWV0Zi5vcmc+IiA8 YW5pbWFAaWV0Zi5vcmc8bWFpbHRvOmFuaW1hQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbQW5p bWFdIEFOSU1BIGludGVudCBkaXNjdXNzaW9uDQoNCk9uIDMxLzAzLzIwMTYgMTA6NDAsIEVYVCBN aWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpIHdyb3RlOg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogQW5pbWEgW21haWx0bzphbmltYS1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgTWFydGluDQpWaWdvdXJldXgNClNlbnQ6IDMxIE1hcmNoIDIwMTYgMTA6MzYNClRv OiBhbmltYUBpZXRmLm9yZzxtYWlsdG86YW5pbWFAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0Fu aW1hXSBBTklNQSBpbnRlbnQgZGlzY3Vzc2lvbg0KDQpJIHRoaW5rIHRoYXQgdGhlIHBlcnNvbiBz aG91bGQgYXQgbGVhc3QgYmUga25vd2xlZGdlYWJsZSBlbm91Z2ggdG8NCnVuZGVyc3RhbmQgKHRo ZSBpbXBsaWNhdGlvbnMgb2YpIHdoYXQgaGUvc2hlIGlzIGFza2luZyBmb3IuDQoNCg0KQWdyZWUu IEJ1dCBhIGdvb2QgdXNlciBpbnRlcmZhY2UgY2FuIHNvbHZlIHRoYXQgLyBoZWxwIHdpdGggaXQu DQoNCk1pY2hhZWwNCg0KDQpJIGFncmVlIHdpdGggYm90aCBvZiB5b3UgOykNClVzaW5nIHNvbWUg c29ydCBvZiBjYXRhbG9nIChzdWdnZXN0ZWQgYnkgSm9obiBTLiBmZXcgZGF5cyBhZ28gb24gdGhl IGxpc3QpIGlzIGEgZmlyc3Qgc3RlcDogY2FwYWJpbGl0aWVzIG9mIHRoZSAibmV0d29yayIgKEFT QXMsIG90aGVyIHRoaW5ncy4uLikgYXJlIGV4cHJlc3NlZCwgYWdncmVnYXRlZCAobWF5YmUgYW5u b3RhdGVkKSBpbiBhIGNvbW1vbiBmb3JtYXQgdW5kZXJzdGFuZGFibGUgdG8gdGhlIHVzZXIgKHRl Y2huaWNhbCBhbmQvb3Igbm9uLXRlY2huaWNhbCkuIFRoaXMgc2V0cyBhIGZpcnN0IGJvdW5kIG9u IHdoYXQgdGhlIHVzZXIgY2FuIG9yIGNhbm5vdCBkby4NCk90aGVyIGFzcGVjdHMgdG8gY29uc2lk ZXI6IChwcm9wZXJ0aWVzIG9mKSBsYW5ndWFnZSAob3Igb3RoZXIgbWVhbnMpIG9mZmVyZWQgdG8g dGhlIHVzZXIgdG8gd3JpdGUgdGhlIGludGVudHMsIG9udG9sb2dpZXMgLyBjb21tb24gbGV4aWNv biwgc2FmZWd1YXJkcyBvbiB2YWx1ZXMvc3ludGF4IGNoZWNraW5nLCBldGMuDQphIGZ1bGwgcHJv amVjdCBvbiBpdHMgb3duISBsZXQncyBnbyBmb3IgYSBCb0YgOykNCg0KTGF1cmVudC4NCg0K --_000_F0465A7466EF438C991AFF91E3BE8333ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <50F0AE782463334EA7E53B5A499379E7@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+SSB3 b3VsZCBsaWtlIHRvIHRoaW5rIHRoYXQgSW50ZW50IGNhbiBiZSBzb21ldGhpbmcgdGhhdCBjYW4g YmUgZGVmaW5lZCBieSBhIHRlY2huaWNhbCBwZXJzb24gYW5kIHRoZW4gaW4tYWN0ZWQgYnkgc29t ZW9uZSBsZXNzIG9yIG5vbi10ZWNobmljYWwuPC9kaXY+DQo8ZGl2PkkgdGhpbmsgdGhhdCBMYXVy ZW50IGlzIHJpZ2h0IHRoYXQgdGhlIGRlZmluaXRpb24gb2YgSW50ZW50LCBob3cgaXQgd3JpdHRl biwgcHJlc2VudGVkLCBhbmQgY2hlY2tlZCBpcyBhIHByb2plY3QgdGhhdCBpcyBxdWl0ZSBsYXJn ZSBhbmQgbGlrZWx5IG91dHNpZGUgdGhlIHNjb3BlIG9mIEFOSU1BLiBJIHRoaW5rIHRoYXQgQU5J TUEgd2lsbCBjbG9zZWx5IG1vbml0b3IgdGhlIGRlZmluaXRpb24gb2YgSW50ZW50IGFuZCBoYXZl IGltcGFjdA0KIG9uIGl0IGFzIHdlbGwgYXMgb3RoZXJzIHRoYXQgYXJlIGludGVyZXN0ZWQgaW4g dXNpbmcgSW50ZW50LiAmbmJzcDtTZWVtcyB0aGF0IGlmIGRvbmUgcHJvcGVybHkgQU5JTUEgd291 bGQgYmUgb25lIG1ldGhvZCB0byBkZWxpdmVyIEludGVudCwgYnV0IG5vdCB0aGUgb25seSBtZXRo b2QuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9Ik1BQ19PVVRMT09L X1NJR05BVFVSRSI+DQo8ZGl2Pg0KPGRpdj4tLSZuYnNwOzwvZGl2Pg0KPGRpdj4NCjxkaXY+PHNw YW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJmb250LWZhbWlseTogVmVyZGFuYTsg Zm9udC1zaXplOiAxMnB4OyI+PGI+PGk+SmFzb24gQ29sZW1hbiBDQ0lFIzEyMDY5PC9pPjwvYj48 L3NwYW4+PC9kaXY+DQo8ZGl2Pjxmb250IGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBmYWNlPSJD YWxpYnJpLHNhbnMtc2VyaWYiPjwvZm9udD48c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIg c3R5bGU9ImZvbnQtZmFtaWx5OiBWZXJkYW5hOyBmb250LXNpemU6IDEycHg7Ij48Yj48aT48YSBo cmVmPSJtYWlsdG86am1jb2xlbWFuQGNpc2NvLmNvbSI+am1jb2xlbWFuQGNpc2NvLmNvbTwvYT48 L2k+PC9iPjwvc3Bhbj48L2Rpdj4NCjxkaXY+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4i IHN0eWxlPSJmb250LWZhbWlseTogVmVyZGFuYTsgZm9udC1zaXplOiAxMnB4OyI+cGhvbmU6ICYj NDM7MSA1MTItMzQwLTMxMzQ8L3NwYW4+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0 eWxlPSJmb250LXNpemU6IDEycHg7Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTog SGVsdmV0aWNhOyBtYXJnaW46IDBweDsiPjxmb250IGZhY2U9IlZlcmRhbmEiIHN0eWxlPSJmb250 LWZhbWlseTogVmVyZGFuYTsiPlRlY2huaWNhbCBMZWFkIEVuZ2luZWVyIENNUzwvZm9udD48L2Rp dj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsiPjxiciBjbGFz cz0ia2h0bWwtYmxvY2stcGxhY2Vob2xkZXIiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTogSGVsdmV0aWNhOyI+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJm b250LXNpemU6IG1lZGl1bTsiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0 OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xv cjogd2luZG93dGV4dDsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogNy41cHQ7IGNvbG9yOiBy Z2IoMTI3LCAxMjcsIDEyNyk7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsiPlRoaXMg ZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZv ciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudC4gQW55IHJldmlldywgdXNl LCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkNCiBwcm9o aWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IChvciBhdXRob3Jp emVkIHRvIHJlY2VpdmUgZm9yIHRoZSByZWNpcGllbnQpLCBwbGVhc2UgY29udGFjdCB0aGUgc2Vu ZGVyIGJ5IHJlcGx5IGVtYWlsIGFuZCBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGlzIG1lc3NhZ2Uu PG86cD48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IGNvbG9yOiB3aW5kb3d0ZXh0OyI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiA3LjVwdDsgY29s b3I6IHJnYigxMjcsIDEyNywgMTI3KTsgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyI+ Rm9yIGNvcnBvcmF0ZSBsZWdhbCBpbmZvcm1hdGlvbiBnbyB0bzo8YnI+DQo8c3BhbiBzdHlsZT0i dGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7Ij48YSBocmVmPSJodHRwOi8vd3d3LmNpc2NvLmNv bS93ZWIvYWJvdXQvZG9pbmdfYnVzaW5lc3MvbGVnYWwvY3JpL2luZGV4Lmh0bWwiIHN0eWxlPSJj b2xvcjogYmx1ZTsiPmh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9hYm91dC9kb2luZ19idXNpbmVz cy9sZWdhbC9jcmkvaW5kZXguaHRtbDwvYT48L3NwYW4+PC9zcGFuPjwvZGl2Pg0KPC9zcGFuPjwv ZGl2Pg0KPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJ T04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjEycHQ7IHRl eHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBC T1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVG VDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlk OyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+QW5pbWEgJmx0OzxhIGhyZWY9Im1h aWx0bzphbmltYS1ib3VuY2VzQGlldGYub3JnIj5hbmltYS1ib3VuY2VzQGlldGYub3JnPC9hPiZn dDsgb24gYmVoYWxmIG9mIExhdXJlbnQgQ2lhdmFnbGlhICZsdDs8YSBocmVmPSJtYWlsdG86bGF1 cmVudC5jaWF2YWdsaWFAbm9raWEuY29tIj5sYXVyZW50LmNpYXZhZ2xpYUBub2tpYS5jb208L2E+ Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Pcmdhbml6YXRpb246IDwv c3Bhbj5CZWxsIExhYnM8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTog PC9zcGFuPlRodXJzZGF5LCBNYXJjaCAzMSwgMjAxNiBhdCA0OjEzIEFNPGJyPg0KPHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+JnF1b3Q7TWljaGFlbCBCZWhyaW5nZXIg KG1iZWhyaW5nKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iZWhyaW5nQGNpc2NvLmNvbSI+ bWJlaHJpbmdAY2lzY28uY29tPC9hPiZndDssIE1hcnRpbiBWaWdvdXJldXggJmx0OzxhIGhyZWY9 Im1haWx0bzptYXJ0aW4udmlnb3VyZXV4QG5va2lhLmNvbSI+bWFydGluLnZpZ291cmV1eEBub2tp YS5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmFuaW1hQGlldGYub3JnIj5hbmlt YUBpZXRmLm9yZzwvYT4mcXVvdDsNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFuaW1hQGlldGYub3Jn Ij5hbmltYUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJv bGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW0FuaW1hXSBBTklNQSBpbnRlbnQgZGlzY3Vzc2lvbjxi cj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGJnY29sb3I9IiNGRkZG RkYiIHRleHQ9IiMzMzMzMzMiPk9uIDMxLzAzLzIwMTYgMTA6NDAsIEVYVCBNaWNoYWVsIEJlaHJp bmdlciAobWJlaHJpbmcpIHdyb3RlOjxicj4NCjxibG9ja3F1b3RlIGNpdGU9Im1pZDo5NzY2N2Vj YjA4YjM0OGQxOTM3Zjg4ZDAwZTU5N2UwMUBYQ0gtUkNELTAwNi5jaXNjby5jb20iIHR5cGU9ImNp dGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8cHJlIHdyYXA9IiI+LS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IEFuaW1hIFs8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0 ZXh0IiBocmVmPSJtYWlsdG86YW5pbWEtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmFuaW1hLWJv dW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgTWFydGluDQpWaWdvdXJldXgNClNlbnQ6 IDMxIE1hcmNoIDIwMTYgMTA6MzYNClRvOiA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlh dGVkIiBocmVmPSJtYWlsdG86YW5pbWFAaWV0Zi5vcmciPmFuaW1hQGlldGYub3JnPC9hPg0KU3Vi amVjdDogUmU6IFtBbmltYV0gQU5JTUEgaW50ZW50IGRpc2N1c3Npb24NCg0KSSB0aGluayB0aGF0 IHRoZSBwZXJzb24gc2hvdWxkIGF0IGxlYXN0IGJlIGtub3dsZWRnZWFibGUgZW5vdWdoIHRvDQp1 bmRlcnN0YW5kICh0aGUgaW1wbGljYXRpb25zIG9mKSB3aGF0IGhlL3NoZSBpcyBhc2tpbmcgZm9y Lg0KPC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlIHdyYXA9IiI+QWdyZWUuIEJ1dCBhIGdvb2Qg dXNlciBpbnRlcmZhY2UgY2FuIHNvbHZlIHRoYXQgLyBoZWxwIHdpdGggaXQuIA0KDQpNaWNoYWVs DQo8L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxicj4NCkkgYWdyZWUgd2l0aCBib3RoIG9mIHlvdSA7 KTxicj4NClVzaW5nIHNvbWUgc29ydCBvZiBjYXRhbG9nIChzdWdnZXN0ZWQgYnkgSm9obiBTLiBm ZXcgZGF5cyBhZ28gb24gdGhlIGxpc3QpIGlzIGEgZmlyc3Qgc3RlcDogY2FwYWJpbGl0aWVzIG9m IHRoZSAmcXVvdDtuZXR3b3JrJnF1b3Q7IChBU0FzLCBvdGhlciB0aGluZ3MuLi4pIGFyZSBleHBy ZXNzZWQsIGFnZ3JlZ2F0ZWQgKG1heWJlIGFubm90YXRlZCkgaW4gYSBjb21tb24gZm9ybWF0IHVu ZGVyc3RhbmRhYmxlIHRvIHRoZSB1c2VyICh0ZWNobmljYWwgYW5kL29yIG5vbi10ZWNobmljYWwp Lg0KIFRoaXMgc2V0cyBhIGZpcnN0IGJvdW5kIG9uIHdoYXQgdGhlIHVzZXIgY2FuIG9yIGNhbm5v dCBkby48YnI+DQpPdGhlciBhc3BlY3RzIHRvIGNvbnNpZGVyOiAocHJvcGVydGllcyBvZikgbGFu Z3VhZ2UgKG9yIG90aGVyIG1lYW5zKSBvZmZlcmVkIHRvIHRoZSB1c2VyIHRvIHdyaXRlIHRoZSBp bnRlbnRzLCBvbnRvbG9naWVzIC8gY29tbW9uIGxleGljb24sIHNhZmVndWFyZHMgb24gdmFsdWVz L3N5bnRheCBjaGVja2luZywgZXRjLjxicj4NCmEgZnVsbCBwcm9qZWN0IG9uIGl0cyBvd24hIGxl dCdzIGdvIGZvciBhIEJvRiA7KTxicj4NCjxicj4NCkxhdXJlbnQuPGJyPg0KPGJyPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_F0465A7466EF438C991AFF91E3BE8333ciscocom_-- From nobody Fri Apr 1 17:05:06 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3489412D0E8 for ; Fri, 1 Apr 2016 17:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 I5o85P5IEg4J for ; Fri, 1 Apr 2016 17:05:02 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DEE112D0C3 for ; Fri, 1 Apr 2016 17:05:02 -0700 (PDT) Received: by mail-lb0-x22a.google.com with SMTP id bc4so82394081lbc.2 for ; Fri, 01 Apr 2016 17:05:02 -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; bh=FsGbqP/mQoRU6ZQvWARcet+lA/FyDUH6WqAzaqmEdNM=; b=EPjBamivkItJAOHMSaORUlzpO09Djijzx0O/GjYCIVtp14YUnPXhRrB981n9Ut97oA S/vdaFPRPQcwDc/nevh4fHgynEqEc/lxcnPsrZ4kBT/IFRtKms2+QAgFs0GnCfoWI01I 3vmful11igCiNnLqcUcb4/ZCniCzhu9gM9KJLlkjD2sp3a2kXvPcPsE1YC9E59XEyUDm 1oWjFkVd0Kxh+p1eLAo6USQS+l48zz+GNLgzcnXtvmGpYbxcl656cNvEBTZJ2fDF9zhE 4hsHU6XEc49gGTS+tUbxwiRz8QCKoaMnU5VAP6QjlQaCmasRd2XtfFPDA2Utxs5AONC2 Dyjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=FsGbqP/mQoRU6ZQvWARcet+lA/FyDUH6WqAzaqmEdNM=; b=T/fclfTBlELbOPepFk1BxkiL0NKtKWF7MZmb+ZNexk3hsc5NXVTpcyR8XgbNetCpdB kBWyyq4h4M8QgnEcZjANiJXt/yT5vnfZBboXPVzhAs6u+MfXseZ8NFpIstT5i+kyDekA PqvfSLQUZuNhDpANsMwXSbcgFm2Ho6q6fvClxRFi+2lrH6D9jIxxPB0JBmNYrGednHOg hNsv7UoIZJr/HJudXos4Mm+QQ6rSyGFOfU2jVZfb0r62Ws1mMRdHQqiEI7xh+gz9f7lj sNr7K/PAeUZjLvBWCswxjXQ/gIcXAHmglNkhCwfCDVeFihcot7IFHyPSCNC66H5YxAD5 NIhg== X-Gm-Message-State: AD7BkJKlbCoHer0WxlTwVfu5ht9/Rkr0sXq1nFkyQP35y/GttlBBbYUx9hRfqwFlrSO8IGOv2Sno2V8DmlBcdA== MIME-Version: 1.0 X-Received: by 10.112.170.68 with SMTP id ak4mr2784477lbc.94.1459555500321; Fri, 01 Apr 2016 17:05:00 -0700 (PDT) Received: by 10.25.22.19 with HTTP; Fri, 1 Apr 2016 17:05:00 -0700 (PDT) In-Reply-To: <9c96c405709e4920bcb0e9c7483d1f90@XCH-RCD-006.cisco.com> References: <62b0d024950e4f73922b9fc6e63c05cf@XCH-RCD-006.cisco.com> <56F440D1.3060702@gmail.com> <56F5DFD6.90000@gmail.com> <56FAA188.2050901@joelhalpern.com> <9c96c405709e4920bcb0e9c7483d1f90@XCH-RCD-006.cisco.com> Date: Fri, 1 Apr 2016 17:05:00 -0700 Message-ID: From: John Strassner To: "Michael Behringer (mbehring)" , John Strassner Content-Type: multipart/alternative; boundary=001a11c259a820727f052f753f9b Archived-At: Cc: Laurent Ciavaglia , Duzongpeng , =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= , "Joel M. Halpern" , "anima@ietf.org" , Sheng Jiang Subject: Re: [Anima] Another use case for Intent: "Freeze network enrolment" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 02 Apr 2016 00:05:06 -0000 --001a11c259a820727f052f753f9b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, >> The notion of distributing all intents as a single blob seems like >> a really bad model. Policy always decomposes into pieces. >> Some of those pieces are related. I think that assuming that >> the total policy (intent) is small is asking for trouble. >> >> This is also why I worry a bit about flooding to everything. > Thanks Joel, I think we agree that *if* Intent can become big, > and / or *if* it changes frequently, we need to divide and conquer. I have a hard time imagining a "big" intent statement. I think that the **results** of a single intent could affect a lot of nodes (e.g., as in my utilization example), and hence the results could be big, but intent itself should not be large. That being said, I do agree with Joel. Intent is not like writing a script. Intent is a collection of high-level statements. Each of these statements could translate into multiple lower-level statements (as in the policy continuum), and this translation could be done several times before the intent is transformed into a form that a device can consume. So, the **total** set of policy instructions **will** be large. > If however Intent is "high level", it should *not* change frequently. And I > think we probably also agree that if an update is required say once a > month, we *can* flood, and deal with it in one blob. (right?) I do agree that intent should not change frequently. I could definitely liv= e with constrained flooding, though I still prefer a simple message queue (e.g., RabbitMQ) because of a key point: Why do we think that every autonomic node would be interested in intent, let alone be able to process it? I do not think that we should "blobify" (sorry, I'm jet-lagged) intent. Intent itself will almost certainly be small. Now, when we start translating that to a form devices can consume, I think that we will end up with a large number of small sets of commands. There could be some utility in sending a blob of related commands to a domain, or a targeted set of nodes, but I think that this is an optimization problem, not a first-order architecture problem. > So the real question is: What will Intent look like? Possibly we > should go back to the use cases, and see what Intent for such a > use case could look like. It depends on what the goal is here. If the goal is to ensure that the ANI can handle intent, I don't think that we need to know the precise form of intent - we simply need to know its requirements. That's what I thought we were talking about. regards, John On Tue, Mar 29, 2016 at 8:50 AM, Michael Behringer (mbehring) < mbehring@cisco.com> wrote: > Thanks Joel, I think we agree that *if* Intent can become big, and / or > *if* it changes frequently, we need to divide and conquer. > > If however Intent is "high level", it should *not* change frequently. And > I think we probably also agree that if an update is required say once a > month, we *can* flood, and deal with it in one blob. (right?) > > So the real question is: What will Intent look like? Possibly we should g= o > back to the use cases, and see what Intent for such a use case could look > like. > > Michael > > > > -----Original Message----- > > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > > Sent: 29 March 2016 17:39 > > To: Michael Behringer (mbehring) ; Brian E Carpente= r > > ; John Strassner ; > > Duzongpeng > > Cc: Laurent Ciavaglia ; J=C3=A9ferson Camp= os > Nobre > > ; anima@ietf.org; Sheng Jiang > > > > Subject: Re: [Anima] Another use case for Intent: "Freeze network > > enrolment" > > > > The notion of distributing all intents as a single blob seems like a > really bad > > model. Policy always decomposes into pieces. Some of those pieces are > > related. I think that assuming that the total policy > > (intent) is small is asking for trouble. > > > > This is also why I worry a bit about flooding to everything. > > > > Yours, > > Joel > > > > On 3/29/16 4:58 AM, Michael Behringer (mbehring) wrote: > > >> I just thought that if the NOC wants to send out some sort of urgent > > >> instruction to all nodes, it is by its nature a partial update of > > >> Intent. Of course a partial update can be achieved by sending > > >> everything. That's a trade-off of resource vs complexity, I suppose. > > > > > > Anything *can* be partial. My claim is that if Intent really is a hig= h > level > > policy, it should be so stable over time that the optimisation to suppo= rt > > partial updates just isn't required. > > > > > > In my proposal on "content distribution" > > (https://mailarchive.ietf.org/arch/msg/anima/KNIglx9abDMEejwEZu9hE4nD > > A08) I suggest a content type; I suggest to start with only one content > type > > supported ("Intent version 0") and get experience with that. If it turn= s > out > > that we need to slice it, we could define new content types, potentiall= y > much > > more granular, so that we could later support effectively a partial > update. If > > we do this job well, the distribution protocol doesn't need to change a= t > all. > > > > > > So my proposal is really: Let's start as simple as possible, but leav= e > space to > > grow if we need to. > > > > > > Michael > > > > > > _______________________________________________ > > > Anima mailing list > > > Anima@ietf.org > > > https://www.ietf.org/mailman/listinfo/anima > > > > --=20 regards, John --001a11c259a820727f052f753f9b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

>> The notion = of distributing all intents as a single blob seems like
>> = a really bad model.=C2=A0 Policy always decomposes into pieces.
&= gt;> Some of those pieces are related.=C2=A0 I think that assuming that<= br>>> the total policy (intent) is small is asking for trouble.
&g= t;>=C2=A0
>> This is also why I worry a bit about flooding to = everything.

> Thanks Joel, I think we agree tha= t *if* Intent can become big,
>=C2=A0and / or *if* it changes= frequently, we need to divide and conquer.

I have= a hard time imagining a "big" intent statement. I think that
the **results** of a single intent could affect a lot of nodes (e.g.= , as
in my utilization example), and hence the results could be= =C2=A0big, but
intent itself should not be large.

<= /div>
That being said, I do agree with Joel. Intent is not like writing= a script.
Intent is a collection of high-level statements. Each = of these
statements could translate into multiple lower-level sta= tements (as in
the policy continuum), and this translation could = be done several
times before the intent is transformed into a for= m that a device can
consume. So, the **total** set of policy inst= ructions **will** be large.

> If however Intent is "high lev= el", it should *not* change frequently. And I
>=C2=A0thin= k we probably also agree that if an update is required say once a
>=C2=A0month, we *can* flood, and deal with it in one blob. (right?)

I do agree that intent should not change frequently.= I could definitely live
with constrained flooding, though I stil= l prefer a simple message queue
(e.g., RabbitMQ) because of a key= point:

=C2=A0=C2=A0 Why do we think that every au= tonomic node would be interested
=C2=A0=C2=A0 in intent, let alon= e be able to process it?

I do not think that we sh= ould "blobify" (sorry, I'm jet-lagged) intent.
Inte= nt itself will almost certainly be small. Now, when we start
tran= slating that to a form devices can consume, I think that we will
= end up with a large number of small sets of commands. There
could= be some utility in sending a blob of related commands to a
domai= n, or a targeted set of nodes, but I think that this is an
optimi= zation problem, not a first-order architecture problem.

>= =C2=A0So the real question is: What will Intent look like? Possibly we
> should go back to the use cases, and see what Intent for such a<= /div>
> use case could look like.

It depends on what the goal= is here. If the goal is to ensure that the
ANI can handle intent= , I don't think that we need to know the precise
form of inte= nt - we simply need to know its requirements. That's what
I t= hought we were talking about.

regards,
J= ohn


On Tue, Mar 29, 2016 at 8:50 AM, Michael Behringer (mbehring) <mbeh= ring@cisco.com> wrote:
Than= ks Joel, I think we agree that *if* Intent can become big, and / or *if* it= changes frequently, we need to divide and conquer.

If however Intent is "high level", it should *not* change frequen= tly. And I think we probably also agree that if an update is required say o= nce a month, we *can* flood, and deal with it in one blob. (right?)

So the real question is: What will Intent look like? Possibly we should go = back to the use cases, and see what Intent for such a use case could look l= ike.

Michael


> -----Original Message-----
> From: Joel M. Halpern [mailto:j= mh@joelhalpern.com]
> Sent: 29 March 2016 17:39
> To: Michael Behringer (mbehring) <mbehring@cisco.com>; Brian E Carpenter
> <brian.e.carpenter@g= mail.com>; John Strassner <= strazpdj@gmail.com>;
> Duzongpeng <duzongpeng@hua= wei.com>
> Cc: Laurent Ciavaglia <laurent.ciavaglia@nokia.com>; J=C3=A9ferson Campos Nobre
> <jcnobre@inf.ufrgs.br&g= t;; anima@ietf.org; Sheng Jiang
> <jiangsheng@huawei.com= >
> Subject: Re: [Anima] Another use case for Intent: "Freeze network=
> enrolment"
>
> The notion of distributing all intents as a single blob seems like a r= eally bad
> model.=C2=A0 Policy always decomposes into pieces.=C2=A0 Some of those= pieces are
> related.=C2=A0 I think that assuming that the total policy
> (intent) is small is asking for trouble.
>
> This is also why I worry a bit about flooding to everything.
>
> Yours,
> Joel
>
> On 3/29/16 4:58 AM, Michael Behringer (mbehring) wrote:
> >> I just thought that if the NOC wants to send out some sort of= urgent
> >> instruction to all nodes, it is by its nature a partial updat= e of
> >> Intent. Of course a partial update can be achieved by sending=
> >> everything. That's a trade-off of resource vs complexity,= I suppose.
> >
> > Anything *can* be partial. My claim is that if Intent really is a= high level
> policy, it should be so stable over time that the optimisation to supp= ort
> partial updates just isn't required.
> >
> > In my proposal on "content distribution"
> (https://mailarchive.ietf.o= rg/arch/msg/anima/KNIglx9abDMEejwEZu9hE4nD
> A08) I suggest a content type; I suggest to start with only one conten= t type
> supported ("Intent version 0") and get experience with that.= If it turns out
> that we need to slice it, we could define new content types, potential= ly much
> more granular, so that we could later support effectively a partial up= date. If
> we do this job well, the distribution protocol doesn't need to cha= nge at all.
> >
> > So my proposal is really: Let's start as simple as possible, = but leave space to
> grow if we need to.
> >
> > Michael
> >
> > _______________________________________________
> > Anima mailing list
> > Anima@ietf.org
> > https://www.ietf.org/mailman/listinfo/anima=
> >



--
regards,
John
--001a11c259a820727f052f753f9b-- From nobody Fri Apr 1 17:43:06 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62FE212D18F for ; Fri, 1 Apr 2016 17:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 HuM2OCqXJ1Ks for ; Fri, 1 Apr 2016 17:43:02 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEB1312D17C for ; Fri, 1 Apr 2016 17:43:02 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id n5so101749923pfn.2 for ; Fri, 01 Apr 2016 17:43:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=H8+vJqlLwBUrEOjsxUaeC8ZkixsRtwNveS/JIgd2BZA=; b=SC5nImvKKpeGeBPYYQRm+gNX8T1acL5lpFJ1BOhwITwf3hkxd5O1xQ7CaJdRH2bSXI XoXMFtxDRW5RoNwaDfkdKE/+zgb7n7ujPaUuQ8sQs1yA4tmbERhmfWoFAC9zDtrhCb/P o4yoztEmAbXwrvv0B61Gxhs55hSrbY2ZsDDRmxkh4/tNCxI17xgpMEHkoT01ssKIoxjU AF9prmMmO1gIi8KBc3S1te4fULfH97LL0fAm/ufmpwIz+oOZ2xA5xgvM3HTLeVMDKBM3 iAI04CqBqZdLyamUjcLSQ+7FG8RZc8PowH/2ZfIbxtYT+4NNR5lxIgHHizIHXA0tlOE2 VmWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=H8+vJqlLwBUrEOjsxUaeC8ZkixsRtwNveS/JIgd2BZA=; b=W7olOfJMyvJhOsmZUAG4tVZHB4CpBlLFAoqulSDQpioGXi4HpZTjkZcIUQkbX9IuVW +MQfW6Lv3EDzdHcxHCAP2j1AndgpgRjHmfnaWc/CSvjtifNPg0HVCuSZGALkPrtwAwIK zUYeJjR6US3JY2gwRXiLiVwVaCw02vixfl4EfNo8EzmxyWAmLgOjomvG0c1URBIuvWNF m7MuS/ThjWnPgXAw21EeLnhq3b2waDRYwtR7CO82aNIjF3X160j7J0KWtmaMSSF/EfnS Wbu2SvLrYzQK4nXmhNiAPFAv090ihDkLxpl9znyAWjo0BTPXwZG/fqrwQP1fhkJ3FrN2 GCAg== X-Gm-Message-State: AD7BkJIqYDRxh/EPSdUZ5YRjBc7R/csT8CivgFyI25fUGXTl8heVAEMegzBD1MnZLYmgGw== X-Received: by 10.98.43.7 with SMTP id r7mr2621674pfr.24.1459557782380; Fri, 01 Apr 2016 17:43:02 -0700 (PDT) Received: from ?IPv6:2406:e007:6342:1:28cc:dc4c:9703:6781? ([2406:e007:6342:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id wy7sm24635779pab.5.2016.04.01.17.42.57 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Apr 2016 17:43:00 -0700 (PDT) To: John Strassner , "Michael Behringer (mbehring)" References: <62b0d024950e4f73922b9fc6e63c05cf@XCH-RCD-006.cisco.com> <56F440D1.3060702@gmail.com> <56F5DFD6.90000@gmail.com> <56FAA188.2050901@joelhalpern.com> <9c96c405709e4920bcb0e9c7483d1f90@XCH-RCD-006.cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56FF159B.8040608@gmail.com> Date: Sat, 2 Apr 2016 13:43:07 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Laurent Ciavaglia , Duzongpeng , =?UTF-8?Q?J=c3=a9ferson_Campos_Nobre?= , "Joel M. Halpern" , "anima@ietf.org" , Sheng Jiang Subject: Re: [Anima] Another use case for Intent: "Freeze network enrolment" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 02 Apr 2016 00:43:04 -0000 On 02/04/2016 13:05, John Strassner wrote: > Why do we think that every autonomic node would be interested > in intent, let alone be able to process it? I suggest that there will be items of Intent that really do apply to every single autonomic node and even to every single ASA. The "maintenance window" one that Michael suggested is an example, and power-saving vs performance* is another. Other items that might be specific to ASAs have the flavour of being configuration thresholds, and maybe shouldn't be called Intent at all. It doesn't matter though - if they have to be distributed, we need a mechanism to do so, whatever we call them. "Freeze network enrolment" is an interesting case, because at first sight, it's necessary and sufficient to send it to all bootstrap proxies; nodes that are not proxies don't need it. But then if the network partitions, a node might decide to become a new proxy. So the "freeze" Intent needs to be cached in that node in advance, before anyone knew it would be needed. So selective blobs of Intent might be a bad idea. ... > It depends on what the goal is here. If the goal is to ensure that the > ANI can handle intent, I don't think that we need to know the precise > form of intent - we simply need to know its requirements. That's what > I thought we were talking about. Indeed. It would be good to condense this discussion into those requirements. Rgds Brian * e.g., parameterised as 0..10 where 0 means always maximise power saving and 10 means always maximise performance. Brian From nobody Fri Apr 1 17:48:56 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A445B12D17C for ; Fri, 1 Apr 2016 17:48:54 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 B31gVr1aIq9g for ; Fri, 1 Apr 2016 17:48:52 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 873F612D0A5 for ; Fri, 1 Apr 2016 17:48:52 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id 184so2303990pff.0 for ; Fri, 01 Apr 2016 17:48:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=BUpmLR97rrm9rPYflZoaokISWfFMnYZSh4JxPuZXyjY=; b=HlMXHS7xypDYtSUp4uSsBmkIbaiZyBA8q0kzJ9+zxx/gKkFZC34Av3O13eC2gmWK8f 4q7tCfxfSQiqqhaOKhGSqf4B3An0jSbx84GpaK4dix5VOBQImZzk0g99rmk8nznNtr4e boZvgA/Aose+WCPpJqLCUg0Bj93OBRqIwiwLSTjptBJgKa7uhtHybfC+PkC+CpfGMfhx bx4ENoiSzWu34o5VcEkaLn8v4mAuPIF04wDFpbrAZBO1l7bmH3cL1kIeYVkwcRGUhIQF jR2Uy+adl3xk7JXEoW1r8EVCZwjhrERaNb0Ev6e9ZUUoA0T8yAzjkIaxv+AIaJWWnVSO UavQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=BUpmLR97rrm9rPYflZoaokISWfFMnYZSh4JxPuZXyjY=; b=e57yhUekV+Aeqy/nnRwhyY5YxoHXUNK2RPT1gPZ/Ek1mZ84XplIqpl2X5gJWcfW+BA TUnz23DTjYhdFTiaUWPiR+a5oymC4z51/NGe4aZBNuJrllzwJjCQRSEDZ8pNanPZFwzi XkrfH8mrAh1TFRp0x+o2t63B5sBpwTYWFoTOZFCzqcC5VgooFdOcFFLMsoZ2MCYWrsz4 LptYaMkCANtSWrISBPrm6P7u7njckce7EVhvA0fbac7K8FHgO8nWqJeRQxXBUVWAfHR2 gAU3zS+R4jzljgD4QeXVCsAL1uQUdpaiFx9GoW3IXK0NC8TkQpFDJYpJdf9eMZLLAozn 6YzQ== X-Gm-Message-State: AD7BkJKZIbgJMa1iHArPNGD7UihYMhZ1DwrEcmAj4nmyKmKAYnARkS5yK1H8Y//balv6SA== X-Received: by 10.98.74.209 with SMTP id c78mr2608406pfj.90.1459558132156; Fri, 01 Apr 2016 17:48:52 -0700 (PDT) Received: from ?IPv6:2406:e007:6342:1:28cc:dc4c:9703:6781? ([2406:e007:6342:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id to9sm24639006pab.27.2016.04.01.17.48.48 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Apr 2016 17:48:51 -0700 (PDT) To: "Jason Coleman (colemaj)" , Laurent Ciavaglia , "Michael Behringer (mbehring)" , Martin Vigoureux , "anima@ietf.org" References: <56FBFA6A.4010400@alcatel-lucent.com> <1493.1459390266@obiwan.sandelman.ca> <9e9c9bd91fe94fafb7ec3280a6b494b6@XCH-RCD-006.cisco.com> <56FCE18B.6030600@alcatel-lucent.com> <97667ecb08b348d1937f88d00e597e01@XCH-RCD-006.cisco.com> <56FCEA32.3090101@alcatel-lucent.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56FF16FA.3030400@gmail.com> Date: Sat, 2 Apr 2016 13:48:58 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] ANIMA intent discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 02 Apr 2016 00:48:54 -0000 > Seems that if done properly ANIMA would be one method to deliver Intent, but not the only method. Absolutely. That's one reason that GRASP is agnostic about the content (value) of any objective, including a synchronization objective used to transport Intent. The only rule is that it must have a defined CBOR encoding, which is a pretty general rule. We do need to get a feeling for how big that object will be though. It affects whether we can flood it via multicast. Regards Brian On 02/04/2016 04:20, Jason Coleman (colemaj) wrote: > I would like to think that Intent can be something that can be defined by a technical person and then in-acted by someone less or non-technical. > I think that Laurent is right that the definition of Intent, how it written, presented, and checked is a project that is quite large and likely outside the scope of ANIMA. I think that ANIMA will closely monitor the definition of Intent and have impact on it as well as others that are interested in using Intent. Seems that if done properly ANIMA would be one method to deliver Intent, but not the only method. > > -- > Jason Coleman CCIE#12069 > jmcoleman@cisco.com > phone: +1 512-340-3134 > Technical Lead Engineer CMS > > This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > From: Anima > on behalf of Laurent Ciavaglia > > Organization: Bell Labs > Date: Thursday, March 31, 2016 at 4:13 AM > To: "Michael Behringer (mbehring)" >, Martin Vigoureux >, "anima@ietf.org" > > Subject: Re: [Anima] ANIMA intent discussion > > On 31/03/2016 10:40, EXT Michael Behringer (mbehring) wrote: > > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Martin > Vigoureux > Sent: 31 March 2016 10:36 > To: anima@ietf.org > Subject: Re: [Anima] ANIMA intent discussion > > I think that the person should at least be knowledgeable enough to > understand (the implications of) what he/she is asking for. > > > Agree. But a good user interface can solve that / help with it. > > Michael > > > I agree with both of you ;) > Using some sort of catalog (suggested by John S. few days ago on the list) is a first step: capabilities of the "network" (ASAs, other things...) are expressed, aggregated (maybe annotated) in a common format understandable to the user (technical and/or non-technical). This sets a first bound on what the user can or cannot do. > Other aspects to consider: (properties of) language (or other means) offered to the user to write the intents, ontologies / common lexicon, safeguards on values/syntax checking, etc. > a full project on its own! let's go for a BoF ;) > > Laurent. > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Fri Apr 1 19:23:22 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F18412D510 for ; Fri, 1 Apr 2016 19:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 20WGcwToF9x8 for ; Fri, 1 Apr 2016 19:23:16 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0B4512D0BC for ; Fri, 1 Apr 2016 19:23:15 -0700 (PDT) Received: by mail-lb0-x229.google.com with SMTP id u8so84961349lbk.0 for ; Fri, 01 Apr 2016 19:23:15 -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; bh=Iy1u9oWoXrgXH3If+1z3ibjNic9S+7n+PcY7ki8jRWk=; b=IEzq6kuoHwFYLdPvrplO2FVzmioGhrsMD0EhPA+ZqV/S1CqkVS85Ma0vRMGVH/mKwP m8cvgEDw42X0ren7ezkHdgQ+lBJtk8PorXL/whFRsZmjThb7Idc4enZcCEosTuU4oCD9 O/rlaGYNkG0D9ukE5QA+ccIYq8AmaISKTEJA3bJ5YDSDyWllbWVs67EwPWsNYutCEqGC F1e/fqP3j4vHS/GvYSB8K05RyP4wIBlke+rQKNlyTAy6UbFinCmsvFIUbK0hgr1H2IzM QsF3SNiHq/Viwc5cIyUnIGx4lWWs1fufynD9ISO6dxWzb8X3dt6IQxQk1U2ik8qNkV5a hSHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Iy1u9oWoXrgXH3If+1z3ibjNic9S+7n+PcY7ki8jRWk=; b=NQkN2HyQpmFkJ4FCiuLL4DNAo0aV5NEs4SJNxijv1EJ3BWzglvtqjd+h65WJ0GILGs Hhf0gd70XHm41gH1ciV4RZFvjEqDnRZca0aeZBL/2VvBeIW/OmhDQJBhMzhAP1WzCT+K 1qWR3v4EeBWSkHLXBLjkqVorIRWLr0Ao85gFRIBIOeFsfPNDvzm/vP6JOEkHUBvbjwCN GGeuxy4As0Bqk67/JrYNdSZKBsI+FjXBTF94d6dhxYupRDIif07/X7mNonKlbNsb5A8F Eta2HU0fuL0Ca1ytZnBSjZTN+k29gvlp+PKT6GreOlRVwO4FjQcsZwN+C7ALpdEXh9lj 257g== X-Gm-Message-State: AD7BkJJxce8OlvWG6Hx3flN2+nuGKfZ/u95bMOh6kT7qImWnreDKT0YU3RpG3ap+zXuYSlfCRhMfhdZBC1tkCQ== MIME-Version: 1.0 X-Received: by 10.112.159.200 with SMTP id xe8mr3212177lbb.75.1459563793756; Fri, 01 Apr 2016 19:23:13 -0700 (PDT) Received: by 10.25.22.19 with HTTP; Fri, 1 Apr 2016 19:23:13 -0700 (PDT) In-Reply-To: <58704b9ce2cb43c0b07d9aac8b284187@XCH-RCD-006.cisco.com> References: <62b0d024950e4f73922b9fc6e63c05cf@XCH-RCD-006.cisco.com> <56FAA4B7.9010305@alcatel-lucent.com> <58704b9ce2cb43c0b07d9aac8b284187@XCH-RCD-006.cisco.com> Date: Fri, 1 Apr 2016 19:23:13 -0700 Message-ID: From: John Strassner To: "Michael Behringer (mbehring)" , John Strassner Content-Type: multipart/alternative; boundary=001a11c3c0927438bc052f772d69 Archived-At: Cc: Laurent Ciavaglia , Duzongpeng , =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= , "anima@ietf.org" , Sheng Jiang Subject: Re: [Anima] Another use case for Intent: "Freeze network enrolment" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 02 Apr 2016 02:23:20 -0000 --001a11c3c0927438bc052f772d69 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > When I say =E2=80=9Cfreeze=E2=80=9D I mean: All the nodes that the operat= or expected > to join, have joined; the next ones will come in 6 months. Until then, > I want to disable the enrolment function. This wasn't obvious to me. I can think of multiple meanings: 1) temporarily stop enrollment because the operations staff has determined that continued enrollment will likely do something bad 2) stop enrollment immediately because an event was received having those semantics For me, the key point of intent is that it does not necessarily mean "THOU SHALT DO THE FOLLOWING". Rather, I think of this as what is traditionally called in policy management theory a "goal policy". As such, it means that the system should try and achieve that goal (without specifying the algorithmic steps to do so), and hence, most "goal policies" expand into a fairly complex set of interacting statements. > Obviously, it **could** be understood as: for today, there are no more > installations of new devices expected; tomorrow at 9 I expect an > installation, so I unfreeze the network, once that device has enrolled I > freeze again until 10, when the next one it expected. That would not > be the right thing. > > I guess that=E2=80=99s exactly the same for all examples... It depends ho= w you > use them. This is why I am concerned with parts of the discussion. First, if intent can be interpreted as having different semantics, we are not specifying intent properly, and it will likely cause more harm than good. Second, if "vague intent" is flooded, then we have magnified the problem. I continue to think that intent SHOULD go to a parser/compiler first, and then the output of the parser/compiler (which very well could be some intermediate form, and not a final form) is then flooded, or put on a pub-sub bus. Just blindly flooding high-level intent does not seem wise., regards, John On Tue, Mar 29, 2016 at 9:34 AM, Michael Behringer (mbehring) < mbehring@cisco.com> wrote: > When I say =E2=80=9Cfreeze=E2=80=9D I mean: All the nodes that the operat= or expected to > join, have joined; the next ones will come in 6 months. Until then, I wan= t > to disable the enrolment function. > > Obviously, it **could** be understood as: for today, there are no more > installations of new devices expected; tomorrow at 9 I expect an > installation, so I unfreeze the network, once that device has enrolled I > freeze again until 10, when the next one it expected. That would not be t= he > right thing. > > I guess that=E2=80=99s exactly the same for all examples... It depends ho= w you use > them. > > Michael > > > > *From:* Laurent Ciavaglia [mailto:laurent.ciavaglia@nokia.com] > *Sent:* 29 March 2016 17:52 > *To:* Michael Behringer (mbehring) ; Brian E > Carpenter ; John Strassner < > strazpdj@gmail.com>; Duzongpeng > *Cc:* Laurent Ciavaglia ; J=C3=A9ferson Camp= os > Nobre ; anima@ietf.org; Sheng Jiang < > jiangsheng@huawei.com> > *Subject:* Re: Another use case for Intent: "Freeze network enrolment" > > > > Michael, > > It seems to me that "Freeze network enrollment" is a valid declarative > form of policy (intent), yet it seems to be a counter-example to the > argument of long-lasting intent, i.e. the operator will want to roll-back > to "normal" behavior as soon as the issue that raised the "freeze" intent > creation is cleared... > (I am not saying that the case is not a good one to investigate). > > Am I over-/mis-interpreting? > > Best regards, Laurent. > > On 24/03/2016 14:49, EXT Michael Behringer (mbehring) wrote: > > Maybe we should combine two threads here. I think there is a perfect use = case for Intent I mentioned in another mail, which would be even applicabl= e to what we do today: > > > > "Freeze network enrolment". > > > > Since any node can be a proxy node for bootstrap, it makes perfect sense = to flood this to all nodes. > > > > Local override possible via traditional config / netconf / etc. > > > > No parameters needed. Can't get any simpler. > > > > Michael > > > > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com ] > > Sent: 24 March 2016 05:53 > > To: John Strassner ; Duzongpeng > > > > Cc: Laurent Ciavaglia ; J=C3=A9ferson Campos Nobre > > ; anima@ietf.org; Michael Be= hringer (mbehring) > > ; Sheng Jiang > > Subject: Re: [Anima] Does Autonomic network need some intervention > > beyond intent > > > > On 24/03/2016 16:49, John Strassner wrote: > > I am confused as to why we would consider prefix-management as an > > autonomic intent. > > > > It's the other way round. Prefix management was chosen as an autonomic > > use case, so a follow-up question is: what intent is appropriate for that= use > > case? > > > > And the suggested answer is: the ISP's intent is that certain types of ed= ge > > network should get certain sizes of prefix. How the prefixes are actually > > divided up and assigned is left to the autonomic nodes. > > > > To me, this breaks a fundamental rule of what is intent by requiring > > the intent writer to understand too many details about the target of > > the intent. The analogy (at least in the ONF and TMF) was specifying > > to a taxi company that you want a taxi, but you need to take a certain > > route, because you (the customer) know traffic patterns better than > > the taxi driver. > > > > Surely we could pick a more appropriate example? > > > > By all means describe other use cases and what sort of intent they need. > > > > Brian > > > > > > regards, > > John > > > > On Wed, Mar 16, 2016 at 5:41 AM, Duzongpeng > > wrote: > > > > Hi, Michael, > > > > > > > > Thanks for the reply. I can understand that intent is not in > > the current milestones, and you are working on several milestones drafts > > now. > > > > > > > > You are welcome to contribute to the intent draft at any > > time, and thanks in advance. > > > > > > > > According to your statements, in my understanding, we can > > keep regarding the =E2=80=9Cintent=E2=80=9D example in =E2=80=9Cprefix-ma= nagement ID=E2=80=9D as an > > Autonomic intent. > > > > It=E2=80=99s semantics are just like =E2=80=9Call nodes of type = x do this; > > type y does that=E2=80=9D, so it is a high level policy. > > > > > > > > It really helps a lot. Thanks. > > > > > > > > I generally agree with your statement, while some other > > personal understandings exist (shown below). But perhaps they can be > > discussed later. > > > > > > > > Best > > Regards > > > > Zongpeng Du > > > > > > > > *From:* Michael Behringer (mbehring) [mailto:mbehring@cisco.com ] > > *Sent:* Wednesday, March 16, 2016 4:17 PM > > *To:* Duzongpeng; anima@ietf.org > > *Cc:* Laurent Ciavaglia; J=C3=A9ferson Campos Nobre; Sheng Jiang > > *Subject:* RE: [Anima] Does Autonomic network need some intervention > > beyond intent > > > > > > > > Hi Zongpeng, > > > > > > > > Yes, this is a recurring question and topic. Let me give my view on > > two > > levels: > > > > > > > > > > First, ANIMA isn=E2=80=99t the only thing =E2=80=9Cinfluencing=E2=80=9D o= r =E2=80=9Csteering=E2=80=9D a > > network, at least not initially. There is still traditional config, > > plus all the existing and emerging SDN models. My view has always > > been that ANIMA sets a =E2=80=9Cdefault=E2=80=9D policy in a network, and= all other > > means are more specific and can override intent. This is described in > > RFC7575. Main point here: ANIMA Intent isn=E2=80=99t the only tool in a n= etwork. > > > > > > > > [duzongpeng] I agree that intent can coexist with traditional config. > > > > I generally agree with the policy priorities, but I have some other > > concerns. > > > > Some default policies/parameters set through =E2=80=9Cintent=E2=80=9D per= haps are > > fundamental for the uplayer services. > > > > It should be prevented that human operator uses some CLIs to change > > them by mistake, and the uplayer services are interrupted. > > > > At least, some warning should be reported to the human operator. > > [duzongpeng] > > > > > > > > Intent could perfectly well cover a high level policy such as =E2=80=9Cal= l > > nodes of type x do this; type y does that=E2=80=9D. (Which I think is wha= t > > you mention > > below.) When we started with Intent, the vision was to keep it very > > high level, more along the line =E2=80=9Cdo the right thing=E2=80=9D J I= t has become > > clear that in today=E2=80=99s networking, people will want to push more > > =E2=80=9Cparameters=E2=80=9D than =E2=80=9Cpolicy=E2=80=9D, and I think w= e=E2=80=99ll just have to acknowledge > > that. > > > > > > > > Personally I think it=E2=80=99ll pan out like this: Intent will have sect= ions > > per autonomic function. An Intent parser will validate overall > > correctness (signature, etc), then segment the Intent into its bits: > > One part will be the autonomic fabric itself, then there will be bits > > for each autonomic function. > > > > > > > > So the Intent parser on a node will grab intent, see there is some > > Intent for autonomic function A, will see whether this is running > > locally, and if so, it=E2=80=99ll just pass that piece of Intent to that = function. > > > > > > > > In this way, a function owner defines both the intent itself, and how > > it is consumed by his/her function. > > > > > > > > [duzongpeng]Agree.[duzongpeng] > > > > > > > > The downside is that there is no =E2=80=9Ccontrol=E2=80=9D an//d people c= an do what > > they want, in the worst case even push config, which is clearly NOT > > what Intent is meant to do. I=E2=80=99d hope that people don=E2=80=99t st= art writing > > Intent like =E2=80=9Cnode > > 17: here is your CLI; node 23: here is your CLI=E2=80=9D; node 37: here i= s > > your CLI=E2=80=9D. But what I describe above COULD be abused in this way. > > RFC7575 says this is NOT Intent. > > > > > > > > [duzongpeng]Agree. It is hard to give an exact boundary. > > > > However, I think we have two choices here. > > > > The first one is to define a policy first in every ASA, but with some > > open parameters that can be configured. What we need to do is just to > > distribute the network-level parameters for that function. This way > > is suitable to some relatively static functions. > > > > The second is more advanced, in the ideal case, the human operator > > can communicate with network using natural language or something > > similar. This way is more flexible, but harder to realize. > > > > [duzongpeng] > > > > > > > > In other words: Let=E2=80=99s not be too prescriptive, and hope that folk= s > > will do more or less reasonable things. > > > > > > > > [duzongpeng]Agree.[duzongpeng] > > > > > > > > I=E2=80=99ve been meaning to comment on the Intent drafts and possibly > > contribute, I=E2=80=99m just struggling with priorities at the moment (as= you > > can see by my relative silence over the past weeks). > > > > > > > > Michael > > > > > > > > > > > > > > > > *From:* Anima [mailto:anima-bounces@ietf.org > > ] *On Behalf Of *Duzongp= eng > > *Sent:* 16 March 2016 02:38 > > *To:* anima@ietf.org > > *Cc:* Laurent Ciavaglia ; J=C3=A9ferson > > Campos Nobre ; Sheng Jiang > > > > *Subject:* [Anima] Does Autonomic network need some intervention > > beyond intent > > > > > > > > Hello, everyone > > > > > > > > I understand that Autonomic network should be able to work > > with as less configuration as possible. In the ideal case, an > > Autonomic network should be able to work well while only intent is > > needed from human operators. > > > > > > > > However, I wonder whether Autonomic network may need some > > intervention from human operators through some low-level policies > > beyond intents. > > > > > > > > For example, in the > > https://tools.ietf.org/html/draft-ietf-anima-prefix-management-00, it > > is suggested that the prefix lengths for the CSG, ASG, RSG (different > > roles in IP RAN) can be assigned as an "intent". These configuration > > parameters need to be distributed in the autonomic domain to > > influence the detail configurations on each autonomic node. > > > > > > > > As intent is described as an abstract, declarative, > > high-level policy used to operate an autonomic domain, such as an > > enterprise network. > > Perhaps we can rename the =E2=80=9Cintent=E2=80=9D in the =E2=80=9Cprefix= -management ID=E2=80=9D to > > some other words. > > > > > > > > Is =E2=80=9CASA parameters" ok here? > > > > > > > > I think some characteristics for this kind of low-level policies are > > > > 1. Network level parameters, need to be distributed by GRASP and > > ACP > > > > 2. Relatively static compared to intent, perhaps only needed to be > > configured once > > > > 3. Unavoidable in current network environment, mostly for > > establishing the network infrastructure > > > > 4. Rarely need coordinations with others parameters, usually is > > closed related to one specific autonomic function > > > > > > > > Welcome for comment. Your suggestions will be appreciated. > > > > > > > > > > > > Best Regards > > > > Zongpeng Du > > > > _______________________________________________ > > 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 > > > > > > > > -- > > Laurent Ciavaglia > > Senior Research Manager > > Bell Labs, Nokia > > > > +33 160 402 636 > > Route de Villejust | 91620 Nozay | France > > LinkedIn: laurentciavaglia > > > --=20 regards, John --001a11c3c0927438bc052f772d69 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

> When I say =E2=80=9Cfr= eeze=E2=80=9D I mean: All the nodes that the operator expecte= d

>=C2=A0to join, have joined; the next ones will come = in 6 months. Until then,

>=C2=A0I want = to disable the enrolment functi= on.


This wasn&= #39;t obvious to me. I can think of multiple meanings:

=
=C2=A0=C2=A0 1) temporarily stop enrollment because the operations
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 staff has determined that conti= nued enrollment will
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0li= kely do something bad
=C2=A0=C2=A0 2) stop enrollment immediately= because an event was
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 received havi= ng those semantics

For me, the key point of intent= is that it does not necessarily mean
"THOU SHALT DO THE FOL= LOWING". Rather, I think of this as what is
traditionally ca= lled in policy management theory a "goal policy". As such,
<= div>it means that the system should try and achieve that goal (without
specifying the algorithmic steps to do so), and hence, most "go= al policies"
expand into a fairly complex set of interacting= statements.

> Obviously, it *could* be understood as: for today, there are no mo= re

>=C2=A0installations of new devices expected; tomorrow at = 9 I expect an

> installation, so I unfreeze the network, once that device has enrolled I

>=C2=A0freeze again = until 10, when the next one it expected. That would not

> be = the right thing.

>

> I guess t= hat=E2=80=99s exactly the same for all examples... It depends how you

>=C2=A0use them.


This is why I am concerned with parts of the discussion.

First, if intent can be interpreted as having different sem= antics, we are
not specifying intent properly, and it will likely= cause more harm than good.

Second, if "vague= intent" is flooded, then we have magnified the problem.
I continue to think that intent SHOULD go to a parser/compiler = first, and
then the output of the parser/compiler (which very wel= l could be some
intermediate form, and not a final form) is then = flooded, or put on a
pub-sub bus. Just blindly flooding high-leve= l intent does not seem wise.,


regar= ds,
John

On Tue, Mar 29, 2016 at 9:34 AM, Michael Behringer (mbehri= ng) <mbehring@cisco.com> wrote:

= When I= say =E2=80=9Cfreeze=E2=80=9D I mean: All the nodes that the operator expec= ted to join, have joined; the next ones will come in 6 months. Until then, I want to disable the enrolment function.

= Obviou= sly, it *could* be understoo= d as: for today, there are no more installations of new devices expected; tomorrow at 9 I expect an installation, so I unfr= eeze the network, once that device has enrolled I freeze again until 10, wh= en the next one it expected. That would not be the right thing.

= I gues= s that=E2=80=99s exactly the same for all examples... It depends how you us= e them.

= Michae= l

= =C2=A0

From: Laurent Ciavaglia [mailto:laurent.ciavaglia@nokia.com]
Sent: 29 March 2016 17:52 To: Michael Behringer (mbehr= ing) <mbehring@c= isco.com>; Brian E Carpenter <brian.e.carpenter@gmail.com>; John Str= assner <strazpdj= @gmail.com>; Duzongpeng <duzongpeng@huawei.com>
Cc: Laurent Ciavaglia <laurent.ciav= aglia@nokia.com>; J=C3=A9ferson Campos Nobre <jcnobre@inf.ufrgs.br>; anima@ietf.org; Sheng Jia= ng <jiangshen= g@huawei.com>
Subject: Re: Another use cas= e for Intent: "Freeze network enrolment"

= =C2=A0=

Michael,

It seems to me that "Freeze network enrollment" is a valid declar= ative form of policy (intent), yet it seems to be a counter-example to the = argument of long-lasting intent, i.e. the operator will want to roll-back t= o "normal" behavior as soon as the issue that raised the "freeze" intent creation is cleared...
(I am not saying that the case is not a good one to investigate).

Am I over-/mis-interpreting?

Best regards, Laurent.

On 24/03/2016 14:49, EXT Michael Behringer (mbehring) wrote:= 

Maybe we should combine two threads here.=
 I think there is a perfect use case for Intent I=C2=A0 mentioned in anothe=
r mail, which would be even applicable to what we do today: <=
/span>
=C2=A0
"Freeze network enrolment". =

=C2=A0
Since any node can be a proxy node for bo=
otstrap, it makes perfect sense to flood this to all nodes. <=
/span>
=C2=A0
Local override possible via traditional c=
onfig / netconf / etc. 
=C2=A0
No parameters needed. Can't get any s=
impler. 
=C2=A0
Michael
=C2=A0
=C2=A0
-----Original Message-----<=
/span>
From: Brian E Carpenter [mailto:brian.e.carpenter@g=
mail.com]
Sent: 24 March 2016 05:53
To: John Strassner <strazpdj@gmail.com>; Duzongpen=
g
<duzongpeng@huawei.com>
Cc: Laurent Ciavaglia <laurent.ciavaglia@nokia.c=
om>; J=C3=A9ferson Campos Nobre
<jcnobre@inf.ufrgs.br>; anima@ietf.org; Michael Behringer (mbehring=
)
<mbehring@cisco.com>; Sheng Jiang <jiangsheng@huawei.com>
Subject: Re: [Anima] Does Autonomic netwo=
rk need some intervention
beyond intent=

=C2=A0
On 24/03/2016 16:49, John Strassner wrote=
:
I am confused as to why we would consider=
 prefix-management as an
autonomic intent.
=C2=A0
It's the other way round. Prefix mana=
gement was chosen as an autonomic
use case, so a follow-up question is: wha=
t intent is appropriate for that use
case?
=C2=A0
And the suggested answer is: the ISP'=
s intent is that certain types of edge
network should get certain sizes of prefi=
x. How the prefixes are actually
divided up and assigned is left to the au=
tonomic nodes.
=C2=A0
To me, this breaks a fundamental rule of =
what is intent by requiring
the intent writer to understand too many =
details about the target of
the intent. The analogy (at least in the =
ONF and TMF) was specifying
to a taxi company that you want a taxi, b=
ut you need to take a certain
route, because you (the customer) know tr=
affic patterns better than
the taxi driver.
=C2=A0
Surely we could pick a more appropriate e=
xample?
=C2=A0
By all means describe other use cases and=
 what sort of intent they need.
=C2=A0
=C2=A0=C2=A0=C2=A0 Brian
=C2=A0
=C2=A0
regards,

John


=C2=A0


On Wed, Mar 16, 2016 at 5:41 AM, Duzongpe=
ng


<duzongpeng@huawei.com> wrote:
=C2=A0
Hi, Michael,<=
/pre>

=C2=A0


=C2=A0


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 Thanks for the reply. I can understand that intent is not in


the current milestones, and you are worki=
ng on several milestones drafts


now.
=C2=A0
=C2=A0
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 You are welcome to contribute to the intent draft at any
time, and thanks in advance.
=C2=A0
=C2=A0
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 According to your statements, in my understanding, we can<=
u>
keep regarding the =E2=80=9Cintent=E2=80=
=9D example in =E2=80=9Cprefix-management ID=E2=80=9D as an
Autonomic intent.
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 It=E2=80=99s semantics are just like =E2=80=9Call nodes of type x=
 do this;
type y does that=E2=80=9D, so it is a hig=
h level policy.
=C2=A0
=C2=A0
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 It really helps a lot. Thanks.
=C2=A0
=C2=A0
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 I generally agree with your statement, while some other=

personal understandings exist (shown belo=
w). But perhaps they can be
discussed later.
=C2=A0
=C2=A0
=C2=A0
Best
Regards
=C2=A0
Zongpeng Du

=C2=A0


=C2=A0


=C2=A0


*From:* Michael Behringer (mbehring) [mailto:mbehring@cisco.=
com]


*Sent:* Wednesday, March 16, 2016 4:17 PM=



*To:* Duzongpeng; anima@ietf.org=



*Cc:* Laurent Ciavaglia; J=C3=A9ferson Ca=
mpos Nobre; Sheng Jiang


*Subject:* RE: [Anima] Does Autonomic net=
work need some intervention


beyond intent=



=C2=A0


=C2=A0


=C2=A0


Hi Zongpeng,<=
/pre>

=C2=A0


=C2=A0


=C2=A0


Yes, this is a recurring question and top=
ic. Let me give my view on


two


levels:


=C2=A0


=C2=A0


=C2=A0


=C2=A0


First, ANIMA isn=E2=80=99t the only thing=
 =E2=80=9Cinfluencing=E2=80=9D or =E2=80=9Csteering=E2=80=9D a


network, at least not initially. There is=
 still traditional config,


plus all the existing and emerging SDN mo=
dels. My view has always


been that ANIMA sets a =E2=80=9Cdefault=
=E2=80=9D policy in a network, and all other

means are more specific and can override =
intent. This is described in


RFC7575. Main point here: ANIMA Intent is=
n=E2=80=99t the only tool in a network.


=C2=A0


=C2=A0


=C2=A0


[duzongpeng] I agree that intent can coex=
ist with traditional config.


=C2=A0


I generally agree with the policy priorit=
ies, but I have some other


concerns.

=C2=A0


Some default policies/parameters set thro=
ugh =E2=80=9Cintent=E2=80=9D perhaps are


fundamental for the uplayer services.<=
/u>


=C2=A0


It should be prevented that human operato=
r uses some CLIs to change


them by mistake, and the uplayer services=
 are interrupted.


=C2=A0


At least, some warning should be reported=
 to the human operator.


[duzongpeng]<=
/pre>

=C2=A0


=C2=A0


=C2=A0


Intent could perfectly well cover a high =
level policy such as =E2=80=9Call


nodes of type x do this; type y does that=
=E2=80=9D. (Which I think is what


you mention

below.) When we started with Intent, the =
vision was to keep it very


high level, more along the line =E2=80=9C=
do the right thing=E2=80=9D J=C2=A0 It has become


clear that in today=E2=80=99s networking,=
 people will want to push more


=E2=80=9Cparameters=E2=80=9D than =E2=80=
=9Cpolicy=E2=80=9D, and I think we=E2=80=99ll just have to acknowledge


that.
=C2=A0
=C2=A0
=C2=A0
Personally I think it=E2=80=99ll pan out =
like this: Intent will have sections
per autonomic function. An Intent parser =
will validate overall
correctness (signature, etc), then segmen=
t the Intent into its bits:
One part will be the autonomic fabric its=
elf, then there will be bits
for each autonomic function.
=C2=A0
=C2=A0
=C2=A0
So the Intent parser on a node will grab =
intent, see there is some
Intent for autonomic function A, will see=
 whether this is running
locally, and if so, it=E2=80=99ll just pa=
ss that piece of Intent to that function.
=C2=A0
=C2=A0
=C2=A0
In this way, a function owner defines bot=
h the intent itself, and how
it is consumed by his/her function.
=C2=A0
=C2=A0
=C2=A0
[duzongpeng]Agree.[duzongpeng]<=
/u>
=C2=A0
=C2=A0
=C2=A0
The downside is that there is no =E2=80=
=9Ccontrol=E2=80=9D an//d people can do what

they want, in the worst case even push co=
nfig, which is clearly NOT


what Intent is meant to do. I=E2=80=99d h=
ope that people don=E2=80=99t start writing

Intent like =E2=80=9Cnode


17: here is your CLI; node 23: here is yo=
ur CLI=E2=80=9D; node 37: here is


your CLI=E2=80=9D. But what I describe ab=
ove COULD be abused in this way.


RFC7575 says this is NOT Intent.


=C2=A0


=C2=A0


=C2=A0


[duzongpeng]Agree. It is hard to give an =
exact boundary.


=C2=A0


However, I think we have two choices here=
.


=C2=A0


The first one is to define a policy first=
 in every ASA, but with some


open parameters that can be configured. W=
hat we need to do is just to


distribute the network-level parameters f=
or that function. This way


is suitable to some relatively static fun=
ctions.


=C2=A0


The second is more advanced, in the ideal=
 case, the human operator


can communicate with network using natura=
l language or something


similar. This way is more flexible, but h=
arder to realize.


=C2=A0


[duzongpeng]<=
/pre>

=C2=A0


=C2=A0


=C2=A0


In other words: Let=E2=80=99s not be too =
prescriptive, and hope that folks


will do more or less reasonable things.


=C2=A0


=C2=A0


=C2=A0


[duzongpeng]Agree.[duzongpeng]<=
/u>


=C2=A0


=C2=A0


=C2=A0


I=E2=80=99ve been meaning to comment on t=
he Intent drafts and possibly


contribute, I=E2=80=99m just struggling w=
ith priorities at the moment (as you


can see by my relative silence over the p=
ast weeks).


=C2=A0


=C2=A0


=C2=A0


Michael


=C2=A0


=C2=A0


=C2=A0


=C2=A0


=C2=A0


=C2=A0


=C2=A0


*From:* Anima [mailto:anima-bounces@ietf.org<=
u>


<anima-bounces@ietf.org>] *On Behalf Of *Duzon=
gpeng


*Sent:* 16 March 2016 02:38=



*To:* anima@ietf.org


*Cc:* Laurent Ciavaglia <laurent.ciavaglia@nokia=
.com>; J=C3=A9ferson


Campos Nobre <jcnobre@inf.ufrgs.br>; Sheng Jiang=



<jiangsheng@huawei.com>


*Subject:* [Anima] Does Autonomic network=
 need some intervention


beyond intent=



=C2=A0


=C2=A0


=C2=A0


Hello, everyone


=C2=A0


=C2=A0


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 I understand that Autonomic network should be able to work=



with as less configuration as possible. I=
n the ideal case, an


Autonomic network should be able to work =
well while only intent is


needed from human operators.


=C2=A0


=C2=A0


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 However, I wonder whether Autonomic network may need some<=
u>


intervention from human operators through=
 some low-level policies


beyond intents.


=C2=A0


=C2=A0


=C2=A0


=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0For example, in the


https://tools.ietf.o=
rg/html/draft-ietf-anima-prefix-management-00, it<=
/font>


is suggested that the prefix lengths for =
the CSG, ASG, RSG (different


roles in IP RAN) can be assigned as an &q=
uot;intent". These configuration


parameters need to be distributed in the =
autonomic domain to


influence the detail configurations on ea=
ch autonomic node.


=C2=A0


=C2=A0


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 As intent is described as an abstract, declarative,=



high-level policy used to operate an auto=
nomic domain, such as an


enterprise network.<=
/font>
Perhaps we can rename the =E2=80=9Cintent=
=E2=80=9D in the =E2=80=9Cprefix-management ID=E2=80=9D to
some other words.
=C2=A0
=C2=A0
=C2=A0
Is =E2=80=9CASA parameters" ok here?=

=C2=A0
=C2=A0
=C2=A0
I think some characteristics for this kin=
d of low-level policies are
=C2=A0
1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ne=
twork level parameters, need to be distributed by GRASP and
ACP
=C2=A0
2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Re=
latively static compared to intent, perhaps only needed to be=

configured once
=C2=A0
3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Un=
avoidable in current network environment, mostly for
establishing the network infrastructure
=C2=A0
4.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ra=
rely need coordinations with others parameters, usually is
closed related to one specific autonomic =
function
=C2=A0
=C2=A0
=C2=A0
Welcome for comment. Your suggestions wil=
l be appreciated.
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0
Best Regards<=
/pre>

=C2=A0


Zongpeng Du

=C2=A0


_________________________________________=
______


Anima mailing list


Anima@ietf.org


https://www.ietf.org/mailman/listinfo/anim=
a


=C2=A0


=C2=A0


=C2=A0
=C2=A0
=C2=A0
=C2=A0
_________________________________________=
______
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anim=
a
=C2=A0
=C2=A0

= =C2=A0=

--

Laurent Ciavaglia

Senior Research Manager

Bell Labs, Nokia

=C2=A0

+33=C2=A0160 402=C2=A0636

Route de Villejust | 91620 Nozay | France

LinkedIn: laurentciavaglia

=C2=A0




--
regards,
John
--001a11c3c0927438bc052f772d69-- From nobody Fri Apr 1 19:26:05 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D762A12D515 for ; Fri, 1 Apr 2016 19:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 AZBw5rlLQr10 for ; Fri, 1 Apr 2016 19:26:02 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A13C112D510 for ; Fri, 1 Apr 2016 19:26:01 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id c62so95667721lfc.1 for ; Fri, 01 Apr 2016 19:26:01 -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; bh=x/dvlHG26d1RoAr3HsEk2WkSTOUVDv0UUEW13vkID4E=; b=rpPjg3k5/XrX7/kL2crvH/7Zh22/onhxgvWUf5bhU0Q09qZcAqjdnHckw6BPpNGS1e KuDn1xGiiJYNxKegyun9USE1yzAaDfEzuAos0wv9j5PW/6zyALvNAnxpf9gZ9ex5q2CN gbYFCx+UL2ZRhxbfQ5YNkGiJ/yKlS2E97qR4THHq/bOjfk3C6WZk5P78nRFO2/q0GqRT YtaYf2pFyzJGxLYzwhya5rKhw7u3FDy9VhY1+eoF5h0p1JuQIJwVJUJAqgndifOY7sPD xM2iZZgr9yBGNGbqGjhAANbPeMDSEGMT7uTifpFO9k7wWKeohGmG5oChOUi77bmKgRH/ KIQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=x/dvlHG26d1RoAr3HsEk2WkSTOUVDv0UUEW13vkID4E=; b=VKRB1bQBJO7sI2op8QZhcYHU42/7St61okemr4G4w7nBdIP4/cJqVFKPKK5IuIFtnb zJw53IoiIUCySV5JEmyQo/cYU9PhuLlW2E2KTxYxy4ENXjMAS0+5xyRMcRmM/qZP+bPV J+hOE605++lSJz1dfgCqkkvLZjr9N9k/lA65/5dwKWcpwEvja/xJkQ/KTi9FLPwZhxs2 N7edGzZdgNtCBIlPfEkVCnX/usKHnqtcUpl//EMCAhaNmJcQkARtF1H32SgSGDbENwSI qTaCKF1sKl7VB+QHgaLAxnu28imADwCBKGXzfdeD2SEoKi5z7BcnkQtkqtyhYUx0w7sm 9EWQ== X-Gm-Message-State: AD7BkJKRchfU1HXrpHbWsD68BQqviE5OLNDU57tcDIGLCQvDdPIqgVxf03/Xqm59/CPatkqaEOqlUdyCDlQIyA== MIME-Version: 1.0 X-Received: by 10.25.20.222 with SMTP id 91mr3435998lfu.100.1459563959758; Fri, 01 Apr 2016 19:25:59 -0700 (PDT) Received: by 10.25.22.19 with HTTP; Fri, 1 Apr 2016 19:25:59 -0700 (PDT) In-Reply-To: References: <62b0d024950e4f73922b9fc6e63c05cf@XCH-RCD-006.cisco.com> <56F440D1.3060702@gmail.com> <56F5DFD6.90000@gmail.com> <56FAA188.2050901@joelhalpern.com> <9c96c405709e4920bcb0e9c7483d1f90@XCH-RCD-006.cisco.com> <56FAA6DD.30403@joelhalpern.com> Date: Fri, 1 Apr 2016 19:25:59 -0700 Message-ID: From: John Strassner To: "Michael Behringer (mbehring)" , John Strassner Content-Type: multipart/alternative; boundary=001a11466dee59372a052f7737f1 Archived-At: Cc: Laurent Ciavaglia , "Joel M. Halpern" , "anima@ietf.org" Subject: Re: [Anima] Another use case for Intent: "Freeze network enrolment" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 02 Apr 2016 02:26:04 -0000 --001a11466dee59372a052f7737f1 Content-Type: text/plain; charset=UTF-8 My example of "Arrange VM Guest Distribution so that CPU utilization is < 70%" is small, but may generate a large number of target nodes. regards, John On Tue, Mar 29, 2016 at 9:35 AM, Michael Behringer (mbehring) < mbehring@cisco.com> wrote: > > -----Original Message----- > > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > > Sent: 29 March 2016 18:02 > > To: Michael Behringer (mbehring) > > Cc: Laurent Ciavaglia ; anima@ietf.org > > Subject: Re: [Anima] Another use case for Intent: "Freeze network > > enrolment" > > > > I can buy the low change rate. In part because if we find that flooding > is > > awkward, it is easy enough to add a new mechanism later. > > > > But I find the assumption that being high level will somehow make intents > > small to be very unlikely. > > Do you have an example? > > Michael > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > -- regards, John --001a11466dee59372a052f7737f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My example of "Arrange VM Guest Distribution so = that
CPU utilization is < 70%" is small, but may generate= a
large number of target nodes.

regards= ,
John

On Tue, Mar 29, 2016 at 9:35 AM, Michael Behringer (mbehri= ng) <mbehring@cisco.com> wrote:
> -----Original Message-----
> From: Joel M. Halpern [mailto:j= mh@joelhalpern.com]
> Sent: 29 March 2016 18:02
> To: Michael Behringer (mbehring) <mbehring@cisco.com>
> Cc: Laurent Ciavaglia <laurent.ciavaglia@nokia.com>; a= nima@ietf.org
> Subject: Re: [Anima] Another use case for Intent: "Freeze network=
> enrolment"
>
> I can buy the low change rate.=C2=A0 In part because if we find that f= looding is
> awkward, it is easy enough to add a new mechanism later.
>
> But I find the assumption that being high level will somehow make inte= nts
> small to be very unlikely.

Do you have an example?

Michael

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



--
regards,
John
--001a11466dee59372a052f7737f1-- From nobody Sat Apr 2 08:31:36 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99BB112D570 for ; Sat, 2 Apr 2016 08:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 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_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 VM5n0VgzL6TT for ; Sat, 2 Apr 2016 08:31:29 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0517412D11E for ; Sat, 2 Apr 2016 08:31:28 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id p188so83809198lfd.0 for ; Sat, 02 Apr 2016 08:31:27 -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; bh=N9kRsG2pUG5k8QSOEffZRkafttNWuffEOJGtNZlMdZM=; b=Q9y0kXcE98jmpQG8A64ZAKdPwz10w7RhkBiVhHInhbsnNTZQNM+iEl6lmBpcJJJ3Dp cYg8+f5sQGVuM34R0vuJch8KklqDtBmXSo9s4K7AME/JarRZoxzF8EJJ6RspU1LfJAcn 1DSTFkkx6sE24prgYOVm9IhzaBK+B4MIWRj0eDH4dqn9HePOcSsOR0DdHshAvrIxQO2b FDoAe7uRJUtOLQ/T2ggnimsuL6YkzUoqqi/+D0/hUScP/eKLsAQmoPJ8+l1UJLhpJZo4 SUfO6WPlhfq7pjCiVw75Ux1plykEVQu6pseI/NFBreCpaKjXt8us+Ey2kd4vi1s8wLfY qBlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=N9kRsG2pUG5k8QSOEffZRkafttNWuffEOJGtNZlMdZM=; b=De89bTXD9QK5iAWf+UdEgRITNttNCFLctEgWxpJrGbNgIMj4Xb8rzLL32ZmLGoXLrE EvSVj2xsKyz02XLgQ6O23/JOJOrJzlX6UrF7vVjB14XSKg9vYkJ6F+p5gWPMDRRBwmUh bzeeL3TeZGIU5Qaf6LZlwO0b2IodK9gwV/h1P4qO2br21EVXnwcNy4sVznkIacQXl+0U afrZIBIFHsi5d/BE5GADKrPB+FrWcITrjzKO/hKYdovW4C4i4SmURIAmH2BK1i7kAm+E 4yecQg1gYcq7KXAbYP8k2pJgAE0ifNrL+nwie/vgVNVDuL59Xh6OkugMW9kWBImjGvMD 00dA== X-Gm-Message-State: AD7BkJJlBSzOa6prWP8V/hk2KI/6kkvB2A4w7ktrvq3b0RvQS8I3DB/E3FebZMd770+p3oHFV1BVsNLp77PPhw== MIME-Version: 1.0 X-Received: by 10.25.89.199 with SMTP id n190mr2744245lfb.16.1459611086067; Sat, 02 Apr 2016 08:31:26 -0700 (PDT) Received: by 10.25.22.19 with HTTP; Sat, 2 Apr 2016 08:31:25 -0700 (PDT) In-Reply-To: <56FBFA6A.4010400@alcatel-lucent.com> References: <56FBFA6A.4010400@alcatel-lucent.com> Date: Sat, 2 Apr 2016 08:31:25 -0700 Message-ID: From: John Strassner To: Laurent Ciavaglia , John Strassner Content-Type: multipart/alternative; boundary=001a114129104b9fa0052f8230aa Archived-At: Cc: Duzongpeng , Michael Behringer , anima , Pierre Peloso Subject: Re: [Anima] ANIMA intent discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 02 Apr 2016 15:31:34 -0000 --001a114129104b9fa0052f8230aa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Laurent, et al., thanks for doing this. I'm shortening to just provide my opinions... 1) Who writes intents? ... *Consensus:* Intent is originated by human/at OSS level, NOT by a network device / function. (of course Intent can be ingested / inputted on a specific device) Intent is originated by humans at the OSS/BSS level. Intent is one of many expressions of policies. It is translated to lower-level forms that are eventually consumed by devices. 2) How many intents? ... *Discussion**:* We cannot define Intent too precisely today. But we can define where Intent is coming from and how to distribute it. It is unlikely to have one set of intent APIs or DSL. This is because people have different concepts, terminologies, and vocabularies. Common models will help interoperability. I do not think that it is necessary to combine disparate intents into a single file. Can Intent have targets? - Ex: an intent for traffic engineering and an intent for energy consumption optimization may need specific (same or different) targets. the functions could have different objectives per set of targets. - Ex: two network segments, core and metro. Then intent should be able to say "on core: optimize on availability"; on access: "optimize on energy saving." - Therefore we need scopes. Policy management theory, dating back to at least 1994, has defined the concepts of Policy Subjects and Policy Targets. The main difference between intent and imperative (CA/ECA) policies is that intent should not need to explicitly specify either, whereas imperative policies do need to explicitly specify at least targets. How do you define "target"? ... *Consensus:* a combination of roles and (sub-)domain(s) should be able to cover most cases. Many past works have used the combination of role, domains, and context. Context is critical to enable the autonomic network to "do the right thing" in response to change. 8) Can an ASA write an intent? Pierre: Example is the coordination function: that function could send out intent directly to modify the behavior of a group of ASAs. Multiple ASAs could do conflicting things. The coordination function must resolve that. Should it issue/modify intent itself? Laurent: q1: should it output something in the form of an intent? q2: should the coordination function update intent? The fundamental difference between intent and other types of policies is that intent is at a higher level of abstraction. Therefore, an ASA would have to understand the nature of the intent (e.g., its grammar) in order to modify or generate intent. In systems that I have seen, this is typically done by the (equivalent of an ASA) sending instructions in its own grammar, and having a set of agents translate to intent and distribute it. Note that this has been typically done using a pub-sub bus; I don't personally know of any systems that used (hopefully constrained) flooding. Regarding conflict - IFF intent is truly declarative, then it should not (at least in principle) produce conflicts. Even if different subjects authored conflicts, when they are all combined into a declarative logic function, they MUST be resolved. (Note that here, I am using logic programming as an example of "truly declarative".) Michael: Isn't it that the behavior of the coordination function must also be resolved by a human originated intent? i.e. the conflicting functions inform the operator via a feedback loop and the operator adjust the intents. Laurent: This is possible / complementary. In once case, the operator is the one closing the control loop / changing the behaviors via intent updates. With a coordination function, part/all of that process could be automated/driven by the machine (the coordination function closes the control loop, in the control range allowed by the operator). There may be intermediate steps where unforeseen conflicts will be resolved. This is run time conflict resolution. Michael: Do we foresee a case where networks resolve conflicts without human control? Laurent: this is possible (has been demonstrated in some projects). We should allow for both approaches to work, possibly in a phased approach. Agreed. What's important is closing the loop. While there are some simple behaviors that can be automatically resolved by the network, this is the exception, not the rule. (In FOCALE, as well as other OODA-based control loops, this is facilitated by recognizing past and new states, and matching behavior to those states.) When unforeseen conflicts arise, ASAs can signal to each other, but they will not issue Intent themselves. Agree. *Consensus:* Cannot say today if other functions can/are allowed to issue intent / intent updates. Functions/ASAs may have to *signal* or *message* somehow, but that this isn=E2=80=99t considered intent yet. For further study: try to design the intent system so that both approaches (feedback loop, coordination) are possible. More investigation/analysis needed. In some systems, such as FOACLE, intent update was done by matching state (and its desired behavior) to context. Again, this is the exception, not the common case. In general, systems that I have worked on provide the operator with enough data to enable the operator to decide what to do. Even if the system thinks it knows what to do, it can still present this conclusion to the operator. (Aside: this is why I like logic-based declarative systems, as it is relatively simple to provide explanations of the decisions taken.) 3) How many domains? ... >From my book "Policy-Based Network Management": A **policy domain** is a collection of manageable entities that are operated on using a common set of policies. The policies are used to administer and control the set of characteristics and behavior of these manageable entities. This is a generalization of RFC1930. The idea is to define a collection of manageable entities whose behavior is governed by a common set of policies. Sub-domains MUST use the policies of their parent domains, but are free to define new policies as long as they do not conflict with the behavior of their parent domains. 4) What are the intent levels/hierarchy? Related to policy based manamegent model: business level, service level, network level, device level, etc. ... The above is the first four parts of the Policy Continuum. When I defined this, I also stated that the explicit number of continua is not that important - what is important is the set of constituencies that are using each continuum. In other words, if it is important to the system to differentiate between the roles of customer-facing and internal-facing application developers, then that should be reflected in the number of policy continua defined. Questions 5, 6, 7 were not discussed due to lack of time. 5-Where/by what is intent processed/compiled? 6-Flooding: what are the requirements? Propagation among who? How distributed? How frequent? -> if many =E2=80=9Coverlapping=E2=80=9D intents= , (partial) updates may become frequent. 7-How is intent understood by node/ASA? -> model, dictionary... 5: Intent is processed/compiled by dedicated entities (in my case, these are agents). This is because it takes specific resources and specific knowledge to do this. 6: I prefer pub-sub. If flooding, then it should be constrained. 7: In general, Intent is NOT understood by nodes or ASAs. This is because the node or ASA would have to have access to additional significant resources. In my experience, nodes and ASAs will implement the lower levels of the Policy Continuum only, and assume that any higher levels of policy are first transformed to a form that they can consume. regards, John On Wed, Mar 30, 2016 at 9:10 AM, Laurent Ciavaglia < laurent.ciavaglia@nokia.com> wrote: > Dear all, > > Michael, Zongpeng, Pierre and I had a discussion on ANIMA intent this > morning, trying to clarify some points and progress toward a common > understanding. > > We used a small, partial set of questions and examples in support. > > Below you may find a summary for your information. Comments and further > interactions are most welcome. > > Thanks, > Michael, Zongpeng, Pierre and Laurent. > --- > > --- Questions > 1-Who writes intents? > 2-How many intents? > 3-How many domains? > 4-What are the intent levels/hierarchy? > 5-Where/by what is intent processed/compiled? > 6-Flooding: what are the requirements? Propagation among who? How > distributed? How frequent? -> if many =E2=80=9Coverlapping=E2=80=9D inten= ts, (partial) > updates may become frequent. > 7-How is intent understood by node/ASA? -> model, dictionary... > 8-Can an ASA write an intent for another ASA? What about coordination or > knowledge writing/receiving intents? Are these functions ASAs/other > things..? > > > --- Intent examples > A-Do the right thing > B-Freeze network enrollment > C-Arrange VM guest distribution so that (CPU) utilization is < 70% > D-Assign prefixes to RAN nodes > E-Protect premium users traffic > F-Maximize energy savings > > > --- Discussion > 1) Who writes intents? > Laurent's view: > Intents are issued by a management function. Can be human / via > BSS/OSS. > Michael's view: > Origin of intent is "non-technical". i.e., registrar doesn't issue > intent. > *Discussion:* how to set the cursor on non-technical? In examples D or > E, the intent writer has some rough knowledge/understanding of technical > aspects of a network (wireless and address aspects for example D ; > protection/restoration and traffic engineering for example E). > *Consensus:* Intent is originated by human/at OSS level, NOT by a > network device / function. (of course Intent can be ingested / inputted o= n > a specific device) > > > 2) How many intents? > Laurent's view: > There may be different ones, like "freeze network", "optimize energy > savings", cf examples. All are valid and concurrent. > Can we wrap that into one file? > How do we share that? > > *Discussion**:* > We cannot define Intent too precisely today. > But we can define where Intent is coming from and how to distribute > it. > > Can Intent have targets? > - Ex: an intent for traffic engineering and an intent for energy > consumption optimization may need specific (same or different) targets. t= he > functions could have different objectives per set of targets. > - Ex: two network segments, core and metro. Then intent should be > able to say "on core: optimize on availability"; on access: "optimize on > energy saving." > - Therefore we need scopes. > > How do you define "target"? > - Is a role enough? > - Pierre: Should be more than role. Example: Metro and core. Need > to distinguish between different metro networks for example. > - Michael: If we have sub-domains, and define intent per > sub-domain, would that do? > - Laurent: a combination of roles and (sub-)domain(s) should be > able to cover most cases. > > *Consensus:* a combination of roles and (sub-)domain(s) should be > able to cover most cases. > > > 8) Can an ASA write an intent? > Pierre: Example is the coordination function: that function could sen= d > out intent directly to modify the behavior of a group of ASAs. > Multiple ASAs could do conflicting things. The coordination function > must resolve that. Should it issue/modify intent itself? > Laurent: q1: should it output something in the form of an intent? q2: > should the coordination function update intent? > Michael: Isn't it that the behavior of the coordination function must > also be resolved by a human originated intent? i.e. the conflicting > functions inform the operator via a feedback loop and the operator adjust > the intents. > Laurent: This is possible / complementary. In once case, the operator > is the one closing the control loop / changing the behaviors via intent > updates. With a coordination function, part/all of that process could be > automated/driven by the machine (the coordination function closes the > control loop, in the control range allowed by the operator). There may be > intermediate steps where unforeseen conflicts will be resolved. This is r= un > time conflict resolution. > Michael: Do we foresee a case where networks resolve conflicts withou= t > human control? > Laurent: this is possible (has been demonstrated in some projects). W= e > should allow for both approaches to work, possibly in a phased approach. > > When unforeseen conflicts arise, ASAs can signal to each other, but > they will not issue Intent themselves. > > *Consensus:* Cannot say today if other functions can/are allowed to > issue intent / intent updates. Functions/ASAs may have to *signal* or > *message* somehow, but that this isn=E2=80=99t considered intent yet. > For further study: try to design the intent system so that both > approaches (feedback loop, coordination) are possible. More > investigation/analysis needed. > > > 3) How many domains? > Naming issue: "domain" by Laurent is a high level concept; could be > understood as a DNS domain name. Needs to be clear what we're talking > about. > With domain-name based intent (i.e., access.att.net) and roles (e.g, > access devices) we should be able to express what we need for now. Not 10= 0% > clear for now. > Two types of domains: (administrative, technology) domains defined (a > priori) by the operator e.g. RAN, MAN, WAN. and the domain of application > of a policy i.e. resolving the policy defines a set of target entities to > which teh policy applies, this is the domain of application of the given > policy. > > *Consensus:* Need to clarify wording to avoid confusion. > > > 4) What are the intent levels/hierarchy? > Related to policy based manamegent model: business level, service > level, network level, device level, etc. So far in ANIMA we consider only > two levels: User and ASA. > Do we need a service level? e.g, VPN. > Can we express different levels with using roles? So a role could be > very specific (route reflector), or service related (e.g., VPN head-end)? > But then we may need to nest roles?! > Maybe we need "business" "service" "network (ASA)" level? > > *Consensus:* to be further discussed. > > > Questions 5, 6, 7 were not discussed due to lack of time. > --- > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > > --=20 regards, John --001a114129104b9fa0052f8230aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Laurent, et al.,

thanks f= or doing this. I'm shortening to just provide my opinions...
=
1) Who writes intents?=C2=A0
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0...
=C2=A0=C2=A0 Consensus: Intent is originated by hum= an/at OSS level, NOT by a network device / function. (of course Intent= can be ingested / inputted on a specific device)

<jcs>
Intent is originated by humans at the= OSS/BSS level. Intent is one
of many expressions of policies. It= is translated to lower-level
forms that are eventually consumed = by devices.
</jcs>


<jcs>
It is unlikely to have one= set of intent APIs or DSL. This is
because people have different= concepts, terminologies,
and vocabularies. Common models will he= lp interoperability.

I do not think that it is nec= essary to combine disparate
intents into a single file.
</jcs>
2) How many intents?=C2=A0
...
=C2=A0 Discussion:
=C2=A0=C2=A0=C2=A0 We cannot define Intent too precisely to= day.
=C2=A0=C2=A0=C2=A0 But we can define where Intent is coming = from and how to distribute it.


=C2=A0 Can Intent have targets?=C2=A0
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0- Ex: an intent for traffic engineering and an intent for = energy consumption optimization may need specific (same or differen= t) targets. the functions could have different objectives per set of t= argets.=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0- Ex: two network segm= ents, core and metro. Then intent should be able to say "on core:= optimize on availability"; on access: "optimize on energy s= aving."
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Therefore we need scopes.<= br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
<jcs>
Policy management theory, dating back to at least 1994, has defined the<= /div>
concepts of Policy Subjects and Policy Targets. The main differen= ce
between intent and imperative (CA/ECA) policies is that intent= should not
need to explicitly specify either, whereas imperative= policies do need to
explicitly specify at least targets.
</jcs>

=C2=A0=C2=A0=C2=A0 Consensus: a com= bination of roles and (sub-)domain(s) should be able to cover most cas= es.

<jcs>
Many past works have us= ed the combination of role, domains, and context.
Context is crit= ical to enable the autonomic network to "do the right thing" in
response to change.
</jcs>

=

8) Can an ASA write an= intent?
=C2=A0=C2=A0=C2=A0 Pierre: Example is the coordination f= unction: that function could send out intent directly to modify the be= havior of a group of ASAs.
=C2=A0=C2=A0=C2=A0=C2=A0 Multiple= ASAs could do conflicting things. The coordination function must reso= lve that. Should it issue/modify intent itself?
=C2=A0=C2= =A0=C2=A0 Laurent: q1: should it output something in the form of an in= tent? q2: should the coordination function update intent?

<jcs>
The fundamental difference between intent and= other types of policies
is that intent is at a higher level of a= bstraction. Therefore, an ASA
would have to understand the nature= of the intent (e.g., its grammar)
in order to modify or generate= intent.

In systems that I have seen, this is typi= cally done by the (equivalent of
an ASA) sending instructions in = its own grammar, and having a set of
agents translate to intent a= nd distribute it. Note that this has been
typically done using a = pub-sub bus; I don't personally know of any
systems that used= (hopefully constrained) flooding.

Regarding confl= ict - IFF intent is truly declarative, then it should not
(at lea= st in principle) produce conflicts. Even if different subjects
au= thored conflicts, when they are all combined into a declarative
l= ogic function, they MUST be resolved. (Note that here, I am using
logic programming as an example of "truly declarative".)
</jcs>

=C2=A0=C2= =A0=C2=A0 Michael: Isn't it that the behavior of the coordination = function must also be resolved by a human originated intent? i.e. the = conflicting functions inform the operator via a feedback loop and the = operator adjust the intents.
=C2=A0=C2=A0=C2=A0 Laurent: This is p= ossible / complementary. In once case, the operator is the one closing= the control loop / changing the behaviors via intent updates. With a = coordination function, part/all of that process could be automated/dri= ven by the machine (the coordination function closes the control loop,= in the control range allowed by the operator). There may be intermedi= ate steps where unforeseen conflicts will be resolved. This is run tim= e conflict resolution.
=C2=A0=C2=A0=C2=A0 Michael: Do we foresee a ca= se where networks resolve conflicts without human control?=C2=A0
= =C2=A0=C2=A0=C2=A0 Laurent: this is possible (has been demonstrated in= some projects). We should allow for both approaches to work, possibly= in a phased approach.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0

<jcs>
Agreed. What's important is closing the loop. While there are
some simple behaviors that can be automatically resolved by
th= e network, this is the exception, not the rule. (In FOCALE,
as we= ll as other OODA-based control loops, this is facilitated
by reco= gnizing past and new states, and matching behavior
to those state= s.)
</jcs>

When unforeseen conflicts ar= ise, ASAs can signal to each other, but they will not issue Intent the= mselves.

<jcs>
Agree.
<= /div>
</jcs>

Consensus: Cannot say today if other functions can/are allow= ed to issue intent / intent updates. Functions/ASAs may have to *signa= l* or *message* somehow, but that this isn=E2=80=99t considered =C2=A0= =C2=A0=C2=A0 intent yet.
=C2=A0=C2=A0=C2=A0 For further study: try= to design the intent system so that both approaches (feedback loop, c= oordination) are possible. More investigation/analysis needed.<= br>
<jcs>
In some systems, such as FOACL= E, intent update was done
by matching state (and its desired beha= vior) to context. Again,
this is the exception, not the common ca= se. In general, systems
that I have worked on provide the operato= r with enough data
to enable the operator to decide what to do. E= ven if the system
thinks it knows what to do, it can still presen= t this conclusion
to the operator. (Aside: this is why I like log= ic-based declarative
systems, as it is relatively simple to provi= de explanations of the
decisions taken.)
</jcs&g= t;

3) How many domains?
= =C2=A0=C2=A0=C2=A0 ...

<jcs>
From my book= "Policy-Based Network Management":

=C2= =A0=C2=A0=C2=A0 A **policy domain** is a collection of manageable entities = that
=C2=A0=C2=A0=C2=A0 are operated on using a common set of pol= icies. The policies
=C2=A0=C2=A0=C2=A0 are used to administer and= control the set of characteristics
=C2=A0=C2=A0=C2=A0 and behavi= or=C2=A0of these manageable entities.

This is a ge= neralization of RFC1930. The idea is to define a
collection of ma= nageable entities whose behavior is governed
by a common set of p= olicies.

Sub-domains MUST use the policies of thei= r parent domains,
but are free to define new policies as long as = they do not
conflict with the behavior of their parent domains.
</jcs>
<= br>
4) What are the intent levels/hierarchy? =
=C2=A0=C2=A0=C2=A0 Relat= ed to policy based manamegent model: business level, service level, network level, device level, etc.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0...
=

<jcs>The above is the first four parts of the Policy Continuum. When I
defined this, I also stated that the explicit number of continua is
=
not that important - what is important is the set of constituencies
that are using each continuum.

In other wo= rds, if it is important to the system to differentiate
between th= e roles of customer-facing and internal-facing
application develo= pers, then that should be reflected in the
number of policy conti= nua defined.
</jcs>

Questions 5, 6, = 7 were not discussed due to lack of time.
5-Where/by what is intent processed/compiled?
6-Flooding: wha= t are the requirements? Propagation among who? How distributed? How f= requent? -> if many =E2=80=9Coverlapping=E2=80=9D intents, (partial= ) updates may become frequent.
7-How is intent understood by node= /ASA? -> model, dictionary...


=

regards,
John

On Wed, Mar 30, 2016 at 9:10 AM, = Laurent Ciavaglia <laurent.ciavaglia@nokia.com> wr= ote:
=20 =20 =20
Dear all,

Michael, Zongpeng, Pierre and I had a discussion on ANIMA intent this morning, trying to clarify some points and progress toward a common understanding.

We used a small, partial set of questions and examples in support.

Below you may find a summary for your information. Comments and further interactions are most welcome.

Thanks,
Michael, Zongpeng, Pierre and Laurent.
---

--- Questions
1-Who writes intents?
2-How many intents?
3-How many domains?
4-What are the intent levels/hierarchy?
5-Where/by what is intent processed/compiled?
6-Flooding: what are the requirements? Propagation among who? How distributed? How frequent? -> if many =E2=80=9Coverlapping=E2=80= =9D intents, (partial) updates may become frequent.
7-How is intent understood by node/ASA? -> model, dictionary...
8-Can an ASA write an intent for another ASA? What about coordination or knowledge writing/receiving intents? Are these functions ASAs/other things..?


--- Intent examples
A-Do the right thing
B-Freeze network enrollment
C-Arrange VM guest distribution so that (CPU) utilization is < 70%
D-Assign prefixes to RAN nodes
E-Protect premium users traffic
F-Maximize energy savings


--- Discussion
1) Who writes intents?
=C2=A0=C2=A0 Laurent's view:
=C2=A0=C2=A0=C2=A0 Intents are issued by a management function. Can b= e human / via BSS/OSS.
=C2=A0=C2=A0 Michael's view:
=C2=A0=C2=A0=C2=A0 Origin of intent is "non-technical". i.e= ., registrar doesn't issue intent.
=C2=A0=C2=A0 Discussion: how to set the cursor on non-technica= l? In examples D or E, the intent writer has some rough knowledge/understanding of technical aspects of a network (wireless and address aspects for example D ; protection/restoration and traffic engineering for example E).
=C2=A0=C2=A0 Consensus: Intent is originated by human/at OSS l= evel, NOT by a network device / function. (of course Intent can be ingested / inputted on a specific device)

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
2) How many intents?
=C2=A0=C2=A0 Laurent's view:
=C2=A0=C2=A0=C2=A0 There may be different ones, like "freeze net= work", "optimize energy savings", cf examples. All are valid and concurrent.
=C2=A0=C2=A0=C2=A0 Can we wrap that into one file?
=C2=A0=C2=A0=C2=A0 How do we share that?

=C2=A0=C2=A0=C2=A0 Discussion:
=C2=A0=C2=A0=C2=A0 We cannot define Intent too precisely today.
=C2=A0=C2=A0=C2=A0 But we can define where Intent is coming from and = how to distribute it.

=C2=A0=C2=A0=C2=A0 Can Intent have targets?
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 - Ex: an intent for traffic eng= ineering and an intent for energy consumption optimization may need specific (same or different) targets. the functions could have different objectives per set of targets.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Ex: two network segments= , core and metro. Then intent should be able to say "on core: optimize on availability"; = on access: "optimize on energy saving."
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 - Therefore we need scopes.
=C2=A0=C2=A0=C2=A0=C2=A0 How do you define "target"?
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 - Is a role enough?
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 - Pierre: Should be more than r= ole. Example: Metro and core. Need to distinguish between different metro networks for example.
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 - Michael: If we have sub-domai= ns, and define intent per sub-domain, would that do?
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 - Laurent: a combination of rol= es and (sub-)domain(s) should be able to cover most cases.

=C2=A0=C2=A0=C2=A0 Consensus: a combination of roles and (sub-= )domain(s) should be able to cover most cases.


8) Can an ASA write an intent?
=C2=A0=C2=A0=C2=A0 Pierre: Example is the coordination function: that= function could send out intent directly to modify the behavior of a group of ASAs.
=C2=A0=C2=A0=C2=A0=C2=A0 Multiple ASAs could do conflicting things. T= he coordination function must resolve that. Should it issue/modify intent itself?
=C2=A0=C2=A0=C2=A0 Laurent: q1: should it output something in the for= m of an intent? q2: should the coordination function update intent?
=C2=A0=C2=A0=C2=A0 Michael: Isn't it that the behavior of the coo= rdination function must also be resolved by a human originated intent? i.e. the conflicting functions inform the operator via a feedback loop and the operator adjust the intents.
=C2=A0=C2=A0=C2=A0 Laurent: This is possible / complementary. In once= case, the operator is the one closing the control loop / changing the behaviors via intent updates. With a coordination function, part/all of that process could be automated/driven by the machine (the coordination function closes the control loop, in the control range allowed by the operator). There may be intermediate steps where unforeseen conflicts will be resolved. This is run time conflict resolution.
=C2=A0=C2=A0=C2=A0 Michael: Do we foresee a case where networks resol= ve conflicts without human control?=C2=A0
=C2=A0=C2=A0=C2=A0 Laurent: this is possible (has been demonstrated i= n some projects). We should allow for both approaches to work, possibly in a phased approach.

=C2=A0=C2=A0=C2=A0 When unforeseen conflicts arise, ASAs can signal t= o each other, but they will not issue Intent themselves.

=C2=A0=C2=A0=C2=A0 Consensus: Cannot say today if other functi= ons can/are allowed to issue intent / intent updates. Functions/ASAs may have to *signal* or *message* somehow, but that this isn=E2=80=99t conside= red =C2=A0=C2=A0=C2=A0 intent yet.
=C2=A0=C2=A0=C2=A0 For further study: try to design the intent system= so that both approaches (feedback loop, coordination) are possible. More investigation/analysis needed.


3) How many domains?
=C2=A0=C2=A0=C2=A0 Naming issue: "domain" by Laure= nt is a high level concept; could be understood as a DNS domain name. Needs to be clear what we're talking about.
=C2=A0=C2=A0=C2=A0 With domain-name based intent (i.e., access.att.net) and roles (e.g, access devices) we should be able to express what we need for now. Not 100% clear for now.
=C2=A0=C2=A0=C2=A0 Two types of domains: (administrative, technology)= domains defined (a priori) by the operator e.g. RAN, MAN, WAN. and the domain of application of a policy i.e. resolving the policy defines a set of target entities to which teh policy applies, this is the domain of application of the given policy.

=C2=A0=C2=A0=C2=A0 Consensus: Need to clarify wording to avoid= confusion.


4) What are the intent levels/hierarchy?
=C2=A0=C2=A0=C2=A0 Related to policy based manamegent model: business= level, service level, network level, device level, etc. So far in ANIMA we consider only two levels: User and ASA.
=C2=A0=C2=A0=C2=A0 Do we need a service level? e.g, VPN.
=C2=A0=C2=A0=C2=A0 Can we express different levels with using roles? = So a role could be very specific (route reflector), or service related (e.g., VPN head-end)?
=C2=A0=C2=A0=C2=A0 But then we may need to nest roles?!
=C2=A0=C2=A0=C2=A0 Maybe we need "business" "service&q= uot; "network (ASA)" leve= l?

=C2=A0=C2=A0=C2=A0 Consensus: to be further discussed.


Questions 5, 6, 7 were not discussed due to lack of time.
---


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




--
regards,
John
--001a114129104b9fa0052f8230aa-- From nobody Sat Apr 2 18:09:40 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F7512D0E1 for ; Sat, 2 Apr 2016 18:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 oHd-K6bSiBDm for ; Sat, 2 Apr 2016 18:09:36 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B181F12D0C3 for ; Sat, 2 Apr 2016 18:09:36 -0700 (PDT) Received: by mail-pa0-x236.google.com with SMTP id fe3so118167242pab.1 for ; Sat, 02 Apr 2016 18:09:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=f+dI2VNQNhETx6S+nyqZh9Iq0PndsiaUhV+KKmhrHwI=; b=InXznIjk98JB/boaUF/58Kiom8CuVorFdkWxeBuyRWOXKvfpBdVz+lTVYVt6uPsrZa CAl99aQv/n8kSit3kt7BfoDuNkiwFfVt1uftT2esKT6QHBmCND0BgOLR4DRg4xu2q/sT GC8xfejWVVWeIrWZyOH01lzrbqtR7nalxvy75wNf2C9c268/hZNLz5/KNr74hLzoHXig WpRh2RIygvhYWHqKDLr2aR+2PhHQF8debQ8gMFS6m9RnDX3/2QNyFFHp43shfwCcKMaN Yd/vCl3tGgpMRvhIbo80W0jG83+Juw9IlLGGQr23TGYdhEb5nH7GRc99ha8B3uhgQ2ZJ zX6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=f+dI2VNQNhETx6S+nyqZh9Iq0PndsiaUhV+KKmhrHwI=; b=LukJp8U1iUJRr5jCbdbutdtswX9uLH5scDITfhuEMPEmVP6FIoXPk6xtcNfvMhQNL3 SJcJKJenje7eaO/gNbumik8lXnqOhOeM5EGUqgluNuF1WD4oHzQqGrOiujdhliRYumK4 rKuENLGnLcblRreBGJo6yTqZQYp3pBzzzzSHyWj85PNSwfvyz0oWCbwOA+3DZfX1y5tD k9uTkXEyRdl4e/fwb/JvfPtPCp/DfN0yNNX9foCxkF5AwgLoT5wbYUzFF1v6bw9l77V8 1jW/x2S8Qg4Sajj7zr0G104tJy7W/1LTLgnlVW+OIsqkHuAqiMgLAJRnaU93xzsx8jav 6ERA== X-Gm-Message-State: AD7BkJLuzk8Bp5vNJt/eLtmNX5PvOw547F5h64kKgGGJCbxGnVlNSNJvds01qQe8P2orBg== X-Received: by 10.67.21.167 with SMTP id hl7mr41911931pad.16.1459645776339; Sat, 02 Apr 2016 18:09:36 -0700 (PDT) Received: from ?IPv6:2406:e007:7971:1:28cc:dc4c:9703:6781? ([2406:e007:7971:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id wy7sm31639506pab.5.2016.04.02.18.09.32 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 02 Apr 2016 18:09:35 -0700 (PDT) To: John Strassner , Laurent Ciavaglia References: <56FBFA6A.4010400@alcatel-lucent.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <57006D4A.6070005@gmail.com> Date: Sun, 3 Apr 2016 13:09:30 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Duzongpeng , anima , Michael Behringer , Pierre Peloso Subject: Re: [Anima] ANIMA intent discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 01:09:38 -0000 On 03/04/2016 03:31, John Strassner wrote: ... > I do not think that it is necessary to combine disparate > intents into a single file. That seems to mean that each recipient of multiple files has to performance consistency checks and conflict resolution, unless you have a watertight definition of 'disparate'. ... > 5: Intent is processed/compiled by dedicated entities (in my > case, these are agents). This is because it takes specific > resources and specific knowledge to do this. Well, we definitely need to talk about that. Do you mean that each autonomic node would contain such an agent, or that such agents would be few in number? > > 6: I prefer pub-sub. If flooding, then it should be constrained. Constrained flooding is the hardest case. If Intent is small, why can't we flood it, with unicast pub/sub to fill in any gaps? > 7: In general, Intent is NOT understood by nodes or ASAs. > This is because the node or ASA would have to have access > to additional significant resources. If there is Intent support code in each node, is that a problem? Also, if there is Intent that is meaningful only to certain ASAs, how can that semantic be handled in a generic Intent handler? Rgds Brian From nobody Sun Apr 3 04:57:25 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355F312D5DD for ; Sun, 3 Apr 2016 04:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.549 X-Spam-Level: X-Spam-Status: No, score=-13.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 6mhZMxlo1p2L for ; Sun, 3 Apr 2016 04:57:22 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 344E612D095 for ; Sun, 3 Apr 2016 04:57:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5104; q=dns/txt; s=iport; t=1459684642; x=1460894242; h=from:to:cc:subject:date:message-id:reply-to:mime-version; bh=E8nZUYampu8TMVQNKTKn/JIgjpEPGAnj8aJBlpDe12g=; b=EzBQdkZZzbqEUqiR+fFj3e3862aYGGnTLLkts3Ph7LpVU/AQRGVE2SGa gx86nk9sxxQuMuhDfRDnmfjLyfDBkNtMmvQuLpL4zwvlkNYGOg+a/LdjT HKs2d8rc9jsWeZ5HfcGY4ySHBaEygrt3sPc92rGWp98IQVEu+TEecKVWL 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BAAgBSBAFX/40NJK1dgmtMgVCvTIZlg?= =?us-ascii?q?mGCDwENgXKGDR6BBTgUAQEBAQEBAWUnhEICBCNWEgEIBAoTIQIEDRIRDhkEAQ0?= =?us-ascii?q?FiBIDEqFhh36GIYVIDYUXAQEBAQEBAQEBAQEBAQEBAQEBGIpqgkGEfoJWBYYuC?= =?us-ascii?q?ZEZMQGMEoF1jw+HRIdVAR4BAUKDZ2yICgEBAQ?= X-IronPort-AV: E=Sophos; i="5.24,436,1454976000"; d="scan'208,217"; a="89478817" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Apr 2016 11:57:21 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u33BvLx6012519 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 3 Apr 2016 11:57:21 GMT Received: from xch-rcd-003.cisco.com (173.37.102.13) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 3 Apr 2016 06:57:20 -0500 Received: from xch-rcd-003.cisco.com ([173.37.102.13]) by XCH-RCD-003.cisco.com ([173.37.102.13]) with mapi id 15.00.1104.009; Sun, 3 Apr 2016 06:57:20 -0500 From: "Toerless Eckert (eckert)" To: John Strassner , Laurent Ciavaglia Thread-Topic: [Anima] ANIMA intent discussion Thread-Index: AQHRjZ/5JFR1BElgvkGnwDo1H8dE1g== Date: Sun, 3 Apr 2016 11:57:20 +0000 Message-ID: <3ke25v1nc9hatkcqpmmwr9p3.1459684256186@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_3ke25v1nc9hatkcqpmmwr9p31459684256186emailandroidcom_" MIME-Version: 1.0 Archived-At: Cc: Duzongpeng , anima , "Michael Behringer \(mbehring\)" , Pierre Peloso Subject: Re: [Anima] ANIMA intent discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "Toerless Eckert \(eckert\)" List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 11:57:24 -0000 --_000_3ke25v1nc9hatkcqpmmwr9p31459684256186emailandroidcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sm9objoNCg0KWW91IHNheSBpbnRlbnQgZG9lcyBub3QgbmVlZCB0byBzcGVjaWZ5IHRhcmdldC4g SG93IHRoZW4gd291bGQgaW4gdGhlIGV4YW1wbGUgZ2l2ZW4sIHRoZSBpbnRlbnQgcmVzb2x1dGlv biBzeXN0ZW0ga25vdyB0aGF0IHlvdSB3YW50ZyBhdmFpbGFiaWxpdHkgaW4gdGhlIGNvcmUgYW5k IGVuZXJneSBzYXZpbmcgb24gdGhlIGVkZ2U/IEluc3RlYWQgb2Ygb3RoZXIgd2F5IHJvdW5kLiBP ciBib3RoIGV2ZXJ5d2hlcmUuDQoNCkRvZXMgaW50ZW50IHJlc29sdXRpb24gaGF2ZSB0byBiZSBh IGdvb2QgZ3Vlc3NlciA/DQoNCg0KDQoNCg0KU2VudCBmcm9tIG15IFNhbXN1bmcgQ2FwdGl2YXRl IEdsaWRlIG9uIEFUJlQNCg0KSm9obiBTdHJhc3NuZXIgPHN0cmF6cGRqQGdtYWlsLmNvbT4gd3Jv dGU6DQoNCiAgQ2FuIEludGVudCBoYXZlIHRhcmdldHM/DQogICAgICAtIEV4OiBhbiBpbnRlbnQg Zm9yIHRyYWZmaWMgZW5naW5lZXJpbmcgYW5kIGFuIGludGVudCBmb3IgZW5lcmd5IGNvbnN1bXB0 aW9uIG9wdGltaXphdGlvbiBtYXkgbmVlZCBzcGVjaWZpYyAoc2FtZSBvciBkaWZmZXJlbnQpIHRh cmdldHMuIHRoZSBmdW5jdGlvbnMgY291bGQgaGF2ZSBkaWZmZXJlbnQgb2JqZWN0aXZlcyBwZXIg c2V0IG9mIHRhcmdldHMuDQogICAgICAtIEV4OiB0d28gbmV0d29yayBzZWdtZW50cywgY29yZSBh bmQgbWV0cm8uIFRoZW4gaW50ZW50IHNob3VsZCBiZSBhYmxlIHRvIHNheSAib24gY29yZTogb3B0 aW1pemUgb24gYXZhaWxhYmlsaXR5Ijsgb24gYWNjZXNzOiAib3B0aW1pemUgb24gZW5lcmd5IHNh dmluZy4iDQogICAgICAtIFRoZXJlZm9yZSB3ZSBuZWVkIHNjb3Blcy4NCg0KPGpjcz4NClBvbGlj eSBtYW5hZ2VtZW50IHRoZW9yeSwgZGF0aW5nIGJhY2sgdG8gYXQgbGVhc3QgMTk5NCwgaGFzIGRl ZmluZWQgdGhlDQpjb25jZXB0cyBvZiBQb2xpY3kgU3ViamVjdHMgYW5kIFBvbGljeSBUYXJnZXRz LiBUaGUgbWFpbiBkaWZmZXJlbmNlDQpiZXR3ZWVuIGludGVudCBhbmQgaW1wZXJhdGl2ZSAoQ0Ev RUNBKSBwb2xpY2llcyBpcyB0aGF0IGludGVudCBzaG91bGQgbm90DQpuZWVkIHRvIGV4cGxpY2l0 bHkgc3BlY2lmeSBlaXRoZXIsIHdoZXJlYXMgaW1wZXJhdGl2ZSBwb2xpY2llcyBkbyBuZWVkIHRv DQpleHBsaWNpdGx5IHNwZWNpZnkgYXQgbGVhc3QgdGFyZ2V0cy4NCjwvamNzPg0KDQo= --_000_3ke25v1nc9hatkcqpmmwr9p31459684256186emailandroidcom_ Content-Type: text/html; charset="utf-8" Content-ID: <6DFCDEE731A52443B1E9528F36FBD04E@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdj5Kb2huOjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+WW91IHNheSBpbnRlbnQgZG9lcyBub3QgbmVl ZCB0byBzcGVjaWZ5IHRhcmdldC4gSG93IHRoZW4gd291bGQgaW4gdGhlIGV4YW1wbGUgZ2l2ZW4s IHRoZSBpbnRlbnQgcmVzb2x1dGlvbiBzeXN0ZW0ga25vdyB0aGF0IHlvdSB3YW50ZyBhdmFpbGFi aWxpdHkgaW4gdGhlIGNvcmUgYW5kIGVuZXJneSBzYXZpbmcgb24gdGhlIGVkZ2U/IEluc3RlYWQg b2Ygb3RoZXIgd2F5IHJvdW5kLiBPciBib3RoIGV2ZXJ5d2hlcmUuPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5Eb2VzIGludGVudCByZXNvbHV0aW9uIGhhdmUgdG8gYmUgYSBnb29kIGd1 ZXNzZXIgPzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOjc1JTtjb2xvcjojNTc1NzU3Ij5TZW50IGZyb20gbXkg U2Ftc3VuZyBDYXB0aXZhdGUgR2xpZGUgb24gQVQmYW1wO1Q8L2Rpdj4NCjwvZGl2Pg0KPGJyPg0K Sm9obiBTdHJhc3NuZXIgJmx0O3N0cmF6cGRqQGdtYWlsLmNvbSZndDsgd3JvdGU6PGJyPg0KPGRp diBkaXI9Imx0ciI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+PGZvbnQgZmFjZT0i Q291cmllciBOZXciPiZuYnNwOyBDYW4gSW50ZW50IGhhdmUgdGFyZ2V0cz8mbmJzcDs8YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstIEV4OiBhbiBpbnRlbnQgZm9yIHRy YWZmaWMgZW5naW5lZXJpbmcgYW5kIGFuIGludGVudCBmb3IgZW5lcmd5IGNvbnN1bXB0aW9uIG9w dGltaXphdGlvbiBtYXkgbmVlZCBzcGVjaWZpYyAoc2FtZSBvciBkaWZmZXJlbnQpIHRhcmdldHMu IHRoZSBmdW5jdGlvbnMgY291bGQgaGF2ZSBkaWZmZXJlbnQgb2JqZWN0aXZlcyBwZXIgc2V0IG9m IHRhcmdldHMuJm5ic3A7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 LSBFeDogdHdvIG5ldHdvcmsgc2VnbWVudHMsIGNvcmUgYW5kIG1ldHJvLiBUaGVuIGludGVudCBz aG91bGQgYmUgYWJsZSB0byBzYXkgJnF1b3Q7b24gY29yZTogb3B0aW1pemUgb24gYXZhaWxhYmls aXR5JnF1b3Q7OyBvbiBhY2Nlc3M6ICZxdW90O29wdGltaXplIG9uIGVuZXJneSBzYXZpbmcuJnF1 b3Q7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gVGhlcmVmb3JlIHdlIG5l ZWQgc2NvcGVzLjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L2ZvbnQ+PGJy Pg0KPC9kaXY+DQo8ZGl2PiZsdDtqY3MmZ3Q7PC9kaXY+DQo8ZGl2PlBvbGljeSBtYW5hZ2VtZW50 IHRoZW9yeSwgZGF0aW5nIGJhY2sgdG8gYXQgbGVhc3QgMTk5NCwgaGFzIGRlZmluZWQgdGhlPC9k aXY+DQo8ZGl2PmNvbmNlcHRzIG9mIFBvbGljeSBTdWJqZWN0cyBhbmQgUG9saWN5IFRhcmdldHMu IFRoZSBtYWluIGRpZmZlcmVuY2U8L2Rpdj4NCjxkaXY+YmV0d2VlbiBpbnRlbnQgYW5kIGltcGVy YXRpdmUgKENBL0VDQSkgcG9saWNpZXMgaXMgdGhhdCBpbnRlbnQgc2hvdWxkIG5vdDwvZGl2Pg0K PGRpdj5uZWVkIHRvIGV4cGxpY2l0bHkgc3BlY2lmeSBlaXRoZXIsIHdoZXJlYXMgaW1wZXJhdGl2 ZSBwb2xpY2llcyBkbyBuZWVkIHRvPC9kaXY+DQo8ZGl2PmV4cGxpY2l0bHkgc3BlY2lmeSBhdCBs ZWFzdCB0YXJnZXRzLjxicj4NCjwvZGl2Pg0KPGRpdj4mbHQ7L2pjcyZndDs8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9x dW90ZSI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAw IDAgLjhleDsgYm9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7IHBhZGRpbmctbGVmdDoxZXgiPg0K PGRpdiBiZ2NvbG9yPSIjRkZGRkZGIj48Zm9udCBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgZmFj ZT0iJ0NvdXJpZXIgTmV3JyI+PGJyPg0KPC9mb250PjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9zaWduYXR1cmUiPjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_3ke25v1nc9hatkcqpmmwr9p31459684256186emailandroidcom_-- From nobody Sun Apr 3 07:59:33 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB77A12D564 for ; Sun, 3 Apr 2016 07:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 LH0-ofngX61r for ; Sun, 3 Apr 2016 07:59:29 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5046512D530 for ; Sun, 3 Apr 2016 07:59:29 -0700 (PDT) Received: by mail-lb0-x229.google.com with SMTP id vo2so125647334lbb.1 for ; Sun, 03 Apr 2016 07:59:29 -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; bh=RjHYi4NMyw6mFwzvz6T6ozDKhr1Z0bol7QXq5Pjt/WY=; b=u5EwoRoHo+Agm6fuJruMFcX051S8z1OLMVCp/Si6P9cEMUFnLzcrAIVh+u9dMa7Q6V 0jwYrLQtgZio7nT+TVJfL4zJhtDXdt6yFgCO5LLx2n95U4nXJFIOMmxqI58iLaLWfi6L BI1cWnqtATTdnVJT8k1ULO/xXujAgOaM5aZE6JiIKdEBUGFAmR8UHaJFgO/KN0U0RutE UHRFmD2C7G8M3tmoW7v8TFrdLduxw5WydfhRTSj4HkrW+IwtBdsZTCcKHahbbpb31Chb 4AI+JqPh7+NRTxw7vNN4q3iAIqh6wY/euYBn9da5CrM9gshGmUiBI2oenSnCSpYl2Nwe r2Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=RjHYi4NMyw6mFwzvz6T6ozDKhr1Z0bol7QXq5Pjt/WY=; b=lFLu067IUVNTruEaHQ0H7oYErwSlnPPoH0zzMGYys+gXLfkyQBRTN+5KA+PRPUY7My 6mgbPV4dvL4g7qTiq/O6lrrivrss7dE4vETEABCaIMOFLDfr1xo0NydNOXKZhpBb7VjT r/TjzLYGncYLO3ezaDdbtH3bYe2UPxMlJsQlp06jAa8MdgKZ4WnsaHVBNoaMJ1tIrF+p DjIS11K6+JZsm5Khh/GWcN0x2bxH2ggYmvSg8Es11i0BMQNdDGiecL5FMaQLQ5wiS4Zy 4musILBn77vV2Yt2kmd18NITMIf5pt/3JI1kFxCQv3hMJmvjR69ak2A+FHJ4EM40UG7K laBg== X-Gm-Message-State: AD7BkJLLbMsoq7SwvRm+oXoR8XGnmp6WDnn224O6Zyde/w13TDOwlRSbkCT/94ubgd1Ma+X3h2KYSwBQFyhQXA== MIME-Version: 1.0 X-Received: by 10.112.52.230 with SMTP id w6mr4461146lbo.144.1459695567414; Sun, 03 Apr 2016 07:59:27 -0700 (PDT) Received: by 10.25.22.19 with HTTP; Sun, 3 Apr 2016 07:59:27 -0700 (PDT) In-Reply-To: <57006D4A.6070005@gmail.com> References: <56FBFA6A.4010400@alcatel-lucent.com> <57006D4A.6070005@gmail.com> Date: Sun, 3 Apr 2016 07:59:27 -0700 Message-ID: From: John Strassner To: Brian E Carpenter , John Strassner Content-Type: multipart/alternative; boundary=001a11c3eab4c6ade1052f95db7f Archived-At: Cc: Laurent Ciavaglia , Duzongpeng , anima , Michael Behringer , Pierre Peloso Subject: Re: [Anima] ANIMA intent discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 14:59:32 -0000 --001a11c3eab4c6ade1052f95db7f Content-Type: text/plain; charset=UTF-8 Hi Brian, > ... >> I do not think that it is necessary to combine disparate >> intents into a single file. > That seems to mean that each recipient of multiple files has to > performance consistency checks and conflict resolution, unless > you have a watertight definition of 'disparate'. No, it means that: a) I don't believe that network elements are, in general, autonomic b) I believe that higher level autonomic managers are needed to perform these and other tasks. > ... >> 5: Intent is processed/compiled by dedicated entities (in my >> case, these are agents). This is because it takes specific >> resources and specific knowledge to do this. > Well, we definitely need to talk about that. Do you mean that > each autonomic node would contain such an agent, or that such > agents would be few in number? That is dependent on the overall architectural approach. In systems that I have built, I have kept to the classic definition of agent, where it knows how to do a few things well. So, as in the AAMAS set of conferences, there are many types of agents that each perform one (or a few) tasks very well. In this approach, the nodes use however many agents they need. >> >> 6: I prefer pub-sub. If flooding, then it should be constrained. > Constrained flooding is the hardest case. If Intent is small, why > can't we flood it, with unicast pub/sub to fill in any gaps? Because I fail to see why most nodes would care about intent. The nodes are not autonomic, the autonomic managers are. You can't build an autonomic system by making every component autonomic - you can build an autonomic system by having the components collaborate to produce autonomic behavior. That's where we differ. >> 7: In general, Intent is NOT understood by nodes or ASAs. >> This is because the node or ASA would have to have access >> to additional significant resources. > If there is Intent support code in each node, is that a problem? If intent support code is present, then it is there for a good reason (or at least I hope so), and hence, no, that is not a problem. However, I don't believe that this is the normal case, since in my view, Intent is not a PERL script, a python program, or a set of APIs - it is instead a (restricted) natural language. Putting a compiler for this on a router or switch is not a good idea, since you would also need ontologies or some type of computational linguistic processing to handle not just synonyms, but variations in phrasing, etc. That's why I keep saying that these and other support functions should be in a (distributed) autonomic manager, and that the autonomic manager translate intent to a form that is consumable by the device. I haven't seen a good argument against this approach. To my knowledge, this approach is what has been commonly built. > Also, if there is Intent that is meaningful only to certain ASAs, > how can that semantic be handled in a generic Intent handler? That's why I prefer pub-sub to flooding. regards, John On Sat, Apr 2, 2016 at 6:09 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 03/04/2016 03:31, John Strassner wrote: > > > ... > > I do not think that it is necessary to combine disparate > > intents into a single file. > > That seems to mean that each recipient of multiple files has to > performance consistency checks and conflict resolution, unless > you have a watertight definition of 'disparate'. > > ... > > 5: Intent is processed/compiled by dedicated entities (in my > > case, these are agents). This is because it takes specific > > resources and specific knowledge to do this. > > Well, we definitely need to talk about that. Do you mean that > each autonomic node would contain such an agent, or that such > agents would be few in number? > > > > > 6: I prefer pub-sub. If flooding, then it should be constrained. > > Constrained flooding is the hardest case. If Intent is small, why > can't we flood it, with unicast pub/sub to fill in any gaps? > > > 7: In general, Intent is NOT understood by nodes or ASAs. > > This is because the node or ASA would have to have access > > to additional significant resources. > > If there is Intent support code in each node, is that a problem? > Also, if there is Intent that is meaningful only to certain ASAs, > how can that semantic be handled in a generic Intent handler? > > Rgds > Brian > > > -- regards, John --001a11c3eab4c6ade1052f95db7f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Brian,

> <snipped e= ven more vigorously>
...
>> I do not think that it is neces= sary to combine disparate
>> intents into a single file.

&= gt; That seems to mean that each recipient of multiple files has to
>= ; performance consistency checks and conflict resolution, unless
> y= ou have a watertight definition of 'disparate'.

No, it means that:

=C2=A0=C2=A0 a) I don'= ;t believe that network elements are, in general, autonomic
=C2= =A0=C2=A0 b) I believe that higher level autonomic managers are needed
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to perform these and other tasks= .

> =C2=A0...
>> 5:=C2=A0 Intent is processed/compiled b= y dedicated entities (in my
>> case, these are agents). This is be= cause it takes specific
>> resources and specific knowledge to do = this.

> Well, we definitely need to talk about that. Do you mean= that
> each autonomic node would contain such an agent, or that suc= h
> agents would be few in number?

That= is dependent on the overall architectural approach. In
systems t= hat I have built, I have kept to the classic definition of
agent,= where it knows how to do a few things well. So, as in
the AAMAS = set of conferences, there are many types of agents
that each perf= orm one (or a few) tasks very well.

In this approa= ch, the nodes use however many agents they need.

>> >> 6: I prefer pub-sub. If flooding, then it should be constrained.<= br>
> Constrained flooding is the hardest case. If Intent is small, = why
> can't we flood it, with unicast pub/sub to fill in any gap= s?

Because I fail to see why most nodes would care= about intent.
The nodes are not autonomic, the autonomic manager= s are.
You can't build an autonomic system by making every
component autonomic - you can build an autonomic system
b= y having the components collaborate to produce autonomic
behavior= . That's where we differ.

>> 7:=C2=A0 In general, Intent i= s NOT understood by nodes or ASAs.
>> This is because the node or = ASA would have to have access
>> to additional significant resourc= es.

> If there is Intent support code in each node, is that a pr= oblem?

If intent support code is present, then= it is there for a good reason
(or at least I hope so), and hence= , no, that is not a problem.
However, I don't believe that th= is is the normal case, since in my
view, Intent is not a PERL scr= ipt, a python program, or a set of
APIs - it is instead a (restri= cted) natural language. Putting a
compiler for this on a router o= r switch is not a good idea, since
you would also need ontologies= or some type of computational
linguistic processing to handle no= t just synonyms, but variations
in phrasing, etc. That's why = I keep saying that these and other
support functions should be in= a (distributed)=C2=A0autonomic manager,
and that the autonomic m= anager translate intent to a form that
is consumable by the devic= e.

I haven't seen a good argument against this= approach. To my
knowledge, this approach is what has been common= ly built.

> Also, if there is Intent that is me= aningful only to certain ASAs,
> how can that semantic be handled in = a generic Intent handler?

That's why I prefer = pub-sub to flooding.

regards,
John

On Sat,= Apr 2, 2016 at 6:09 PM, Brian E Carpenter <brian.e.carpenter@gm= ail.com> wrote:
On 03/04/20= 16 03:31, John Strassner wrote:

<snipped even more vigorously>
...
> I do not think that it is necessary to combine disparate
> intents into a single file.

That seems to mean that each recipient of multiple files has to
performance consistency checks and conflict resolution, unless
you have a watertight definition of 'disparate'.

...
> 5:=C2=A0 Intent is processed/compiled by dedicated entities (in my
> case, these are agents). This is because it takes specific
> resources and specific knowledge to do this.

Well, we definitely need to talk about that. Do you mean that
each autonomic node would contain such an agent, or that such
agents would be few in number?

>
> 6: I prefer pub-sub. If flooding, then it should be constrained.

Constrained flooding is the hardest case. If Intent is small, why
can't we flood it, with unicast pub/sub to fill in any gaps?

> 7:=C2=A0 In general, Intent is NOT understood by nodes or ASAs.
> This is because the node or ASA would have to have access
> to additional significant resources.

If there is Intent support code in each node, is that a problem?
Also, if there is Intent that is meaningful only to certain ASAs,
how can that semantic be handled in a generic Intent handler?

Rgds
=C2=A0 Brian





--
regards,
John
--001a11c3eab4c6ade1052f95db7f-- From nobody Sun Apr 3 08:03:00 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E68F12D194 for ; Sun, 3 Apr 2016 08:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 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_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 cjMRx-umt4pk for ; Sun, 3 Apr 2016 08:02:56 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C69A12D12B for ; Sun, 3 Apr 2016 08:02:56 -0700 (PDT) Received: by mail-lb0-x234.google.com with SMTP id u8so125734802lbk.0 for ; Sun, 03 Apr 2016 08:02:56 -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; bh=7ZVO0tAAQKkuJOFZ5h/dYihSBSEgP/WkkvUxclmzJg4=; b=UIP+ehWCm1K4X/lPn1Q65NzrF9sFaJvOxeQCTOuucgRyUilB9ma5qvh/TURKuuvjrE p+YCE8Lwqkzpa+Jr10On4mvuOuo0sdVPFSlzIwDTeQZ1fIzm6gUh/bFnC3PN49NTallN fWZ4OA0hMxzSzlAI1ou0sNlbV3o+mO7tk6soFYWuwhP6UDRZLMopBn/M5e18xRnRIq+f gea3UUxOzBxNFk+ca56NXsI+CO2FPnyHAx5WyaCdHWncF54UklkJ9p1gFqKIxEhdOveu DV1z3Psrg9oQVQFrLibi2e+SwkmLoenQN8NHH8eOxGlvgvFMWIhH/wts2IpmUtGphMqU 03Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=7ZVO0tAAQKkuJOFZ5h/dYihSBSEgP/WkkvUxclmzJg4=; b=HSRrzeb4qozmi8r/J1k6dykwwQWgSz1j3PhQVhmVprFBN+22PT+O5CXwSnl0hKOP4T B6sC0golgiGZ2MudteZj0ndcoPuwcGoPa+TwtO9t9VWwjQOUdVLyGsBX9Fs2lXJd/9i1 BI07JTslFPwlj3grcpkk1wFPF05EjBNZcBqR/fH1yrx9Lu1HCJ8HI25OMXnrBY4a7Lmv aX8QRyI4CwPJX11jAJ0Uj4atw+QBV5aDjlxYSnUIbLwACvE4ICizeVsDlY9wR8t8HFhc CgXjk3ASxfeu8TIFIjvXj4UwgqsMbWYcvY/ie0CRMqIHs8NroJ4+GxFvibNC0dsW09XJ bqEg== X-Gm-Message-State: AD7BkJJiX08JYjTNBycQGMh81BoM+7PthfNVxmP8xeHaI731kVUIlNTR3M8eJzPcvqe2HT4S5p8S0bvYtNb3uw== MIME-Version: 1.0 X-Received: by 10.112.84.202 with SMTP id b10mr3532810lbz.41.1459695774548; Sun, 03 Apr 2016 08:02:54 -0700 (PDT) Received: by 10.25.22.19 with HTTP; Sun, 3 Apr 2016 08:02:54 -0700 (PDT) In-Reply-To: <3ke25v1nc9hatkcqpmmwr9p3.1459684256186@email.android.com> References: <3ke25v1nc9hatkcqpmmwr9p3.1459684256186@email.android.com> Date: Sun, 3 Apr 2016 08:02:54 -0700 Message-ID: From: John Strassner To: "Toerless Eckert (eckert)" , John Strassner Content-Type: multipart/alternative; boundary=001a1135ea061f48ed052f95e806 Archived-At: Cc: Laurent Ciavaglia , Duzongpeng , anima , "Michael Behringer \(mbehring\)" , Pierre Peloso Subject: Re: [Anima] ANIMA intent discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 15:02:58 -0000 --001a1135ea061f48ed052f95e806 Content-Type: text/plain; charset=UTF-8 It depends on what the Intent is trying to do. My example of (CPU) optimization does not specify any one particular target, yet still works. In the core and edge example, these could be the default behaviors of those nodes. I didn't mean that you don't ever specify targets, but I did mean that you shouldn't have to say "this IP address on this port of this card of this chassis of this router" as we currently do. And no, guessing never works. On Sun, Apr 3, 2016 at 4:57 AM, Toerless Eckert (eckert) wrote: > John: > > You say intent does not need to specify target. How then would in the > example given, the intent resolution system know that you wantg > availability in the core and energy saving on the edge? Instead of other > way round. Or both everywhere. > > Does intent resolution have to be a good guesser ? > > > > > > Sent from my Samsung Captivate Glide on AT&T > > John Strassner wrote: > > Can Intent have targets? > - Ex: an intent for traffic engineering and an intent for energy > consumption optimization may need specific (same or different) targets. the > functions could have different objectives per set of targets. > - Ex: two network segments, core and metro. Then intent should be > able to say "on core: optimize on availability"; on access: "optimize on > energy saving." > - Therefore we need scopes. > > > Policy management theory, dating back to at least 1994, has defined the > concepts of Policy Subjects and Policy Targets. The main difference > between intent and imperative (CA/ECA) policies is that intent should not > need to explicitly specify either, whereas imperative policies do need to > explicitly specify at least targets. > > >> >> -- regards, John --001a1135ea061f48ed052f95e806 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It depends on what the Intent is trying to do.
<= div>
My example of (CPU) optimization does not specify any on= e
particular target, yet still works. In the core and edge exampl= e,
these could be the default behaviors of those nodes.

I didn't mean that you don't ever specify targets, = but I did mean
that you shouldn't have to say "this IP a= ddress on this port of this
card of this chassis of this router&q= uot; as we currently do.

And no, guessing never wo= rks.


On Sun, Apr 3, 2016 at 4:57 AM, Toerless Ecker= t (eckert) <eckert@cisco.com> wrote:
John:

You say intent does not need to specify target. How then would in the = example given, the intent resolution system know that you wantg availabilit= y in the core and energy saving on the edge? Instead of other way round. Or= both everywhere.

Does intent resolution have to be a good guesser ?
=C2=A0




Sent from my Samsung Capti= vate Glide on AT&T

John Strassner <= strazpdj@gmail.com> wrote:

=C2=A0 Can Intent have targets?=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0- Ex: an intent for traffic engineering= and an intent for energy consumption optimization may need specific (same = or different) targets. the functions could have different objectives per se= t of targets.=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0- Ex: two network segments, core and me= tro. Then intent should be able to say "on core: optimize on availabil= ity"; on access: "optimize on energy saving."
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Therefore we need scopes.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
<jcs>
Policy management theory, dating back to at least 1994, has defined th= e
concepts of Policy Subjects and Policy Targets. The main difference
between intent and imperative (CA/ECA) policies is that intent should = not
need to explicitly specify either, whereas imperative policies do need= to
explicitly specify at least targets.
</jcs>




--
regards,
John
--001a1135ea061f48ed052f95e806-- From nobody Sun Apr 3 13:14:47 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 479E312D1F0 for ; Sun, 3 Apr 2016 13:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 WNsJ2FsLkIjL for ; Sun, 3 Apr 2016 13:14:44 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FE7012D19D for ; Sun, 3 Apr 2016 13:14:44 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id e128so107354793pfe.3 for ; Sun, 03 Apr 2016 13:14:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=R8j31dTNgxApYdP2P9NooaZKTj+yksf+AOkySTE2Hek=; b=YTDVCMSZCMOr7dGhs94CqRPouIiV5iQnP4+FKLz0QehDby+6eKMpAqHAuQ90FBjrI3 XaK81qAHApbdxeSGI9yUp5jb2WvEiYLgNCzmFebOYYNDM6RpXiimpttFXQMEMg3YHLRi 3/IUs8y6Z58jaD3f0v3RXa4WBy9nAB/GMUitsagDQpWTKpQ1nRJ9uBv+U6nrGU+7hq7H Xo70abmp+ZnEdepiWZCV7UxQHCfTVvPdBjX1uqX6FS5p3S9rCvvqLmZQSfRbeevcUrUs iXJpH3Nk7ZQgUrDd8D4sQ8OHKK2CuqF1Rp0rXceAFxDEej+v7D3OZ/jETgAESJczCWnf epLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=R8j31dTNgxApYdP2P9NooaZKTj+yksf+AOkySTE2Hek=; b=KXBLFiQCH1tLFXEwKadqAxioVtu3lIJAlaW8dtVJaht2XZjWRsJGG9irqWJTqWE4lr aBOCIML0EndhMBbGjdVFXGr94HK6PxqTeQtLCbUno/uhLxZzsEarRflGPj7A3BiYGBxo toLBiHWTLNNnaLiMG7Sp26OQE8rMqc+uFvZmRBLTC0wo0xr6KcMd8mu1gvvOMsKO57Ib jlopqNZ/B+Xpr3KlIwZ8U4aOUXVyl6njarud9DR9Wrj/KdI2hFKAS2h3/rWhzUNC8/c0 kXO8yk/aZYO9vVcDvLALBQNfk0kK+vG1pLw10bXu5pfPV3ESq9c7mhNZMvQHsL90oVrY R9FA== X-Gm-Message-State: AD7BkJJqgp8ZFcvwJ7r6SzQrbjNl76/7bzDFMO5Gm3gKjcChC5DHCoYJ2ucB3uKA7ENz6w== X-Received: by 10.98.18.195 with SMTP id 64mr15225088pfs.131.1459714483910; Sun, 03 Apr 2016 13:14:43 -0700 (PDT) Received: from ?IPv6:2406:e007:483d:1:28cc:dc4c:9703:6781? ([2406:e007:483d:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id l11sm34147826pfb.56.2016.04.03.13.14.39 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Apr 2016 13:14:42 -0700 (PDT) To: John Strassner References: <56FBFA6A.4010400@alcatel-lucent.com> <57006D4A.6070005@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <570179AC.6090707@gmail.com> Date: Mon, 4 Apr 2016 08:14:36 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Laurent Ciavaglia , Duzongpeng , anima , Michael Behringer , Pierre Peloso Subject: Re: [Anima] ANIMA intent discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 20:14:46 -0000 John, On 04/04/2016 02:59, John Strassner wrote: > Hi Brian, > >> > ... >>> I do not think that it is necessary to combine disparate >>> intents into a single file. > >> That seems to mean that each recipient of multiple files has to >> performance consistency checks and conflict resolution, unless >> you have a watertight definition of 'disparate'. > > No, it means that: > > a) I don't believe that network elements are, in general, autonomic > b) I believe that higher level autonomic managers are needed > to perform these and other tasks. Of course, see my next comment. >> ... >>> 5: Intent is processed/compiled by dedicated entities (in my >>> case, these are agents). This is because it takes specific >>> resources and specific knowledge to do this. > >> Well, we definitely need to talk about that. Do you mean that >> each autonomic node would contain such an agent, or that such >> agents would be few in number? > > That is dependent on the overall architectural approach. In > systems that I have built, I have kept to the classic definition of > agent, where it knows how to do a few things well. So, as in > the AAMAS set of conferences, there are many types of agents > that each perform one (or a few) tasks very well. > > In this approach, the nodes use however many agents they need. > >>> >>> 6: I prefer pub-sub. If flooding, then it should be constrained. > >> Constrained flooding is the hardest case. If Intent is small, why >> can't we flood it, with unicast pub/sub to fill in any gaps? > > Because I fail to see why most nodes would care about intent. > The nodes are not autonomic, the autonomic managers are. Ah, I see that we have a slight terminology mismatch. When I write "flood" I mean, very specifically, something sent to all autonomic nodes. (Even more specifically, to all GRASP nodes, which listen to the GRASP link-local multicast address.) Certainly, each such node may be managing any number of non-autonomic nodes that don't understand Intent and will not receive it. > You can't build an autonomic system by making every > component autonomic - you can build an autonomic system > by having the components collaborate to produce autonomic > behavior. That's where we differ. > >>> 7: In general, Intent is NOT understood by nodes or ASAs. >>> This is because the node or ASA would have to have access >>> to additional significant resources. > >> If there is Intent support code in each node, is that a problem? Read "node" as "autonomic node". > If intent support code is present, then it is there for a good reason > (or at least I hope so), and hence, no, that is not a problem. > However, I don't believe that this is the normal case, since in my > view, Intent is not a PERL script, a python program, or a set of > APIs - it is instead a (restricted) natural language. Putting a > compiler for this on a router or switch is not a good idea, since Well, IMHO it would be an interpreter... > you would also need ontologies or some type of computational > linguistic processing to handle not just synonyms, but variations > in phrasing, etc. ... and IMHO the Intent language would *not* be like that; it would be algorithmic. What's the value in allowing it to be sloppy? Also, how can that approach be correctly internationalised? Whatever we do must be very straightforward whatever language the human operator speaks, which means that its syntax has to be rigid (and preferably 1:1 translatable from an English-like presentation to any other language). > That's why I keep saying that these and other > support functions should be in a (distributed) autonomic manager, > and that the autonomic manager translate intent to a form that > is consumable by the device. If you mean that an autonomic node will manage (configure) any number of subsidiary non-autonomic devices, we agree. And I think this is something we should state explicitly in the reference model, which I believe is missing at the moment. It is stated in the GRASP spec, which is probably the wrong place for it: It is understood that in realistic deployments, not all devices will support GRASP. It is expected that some autonomic service agents will directly manage a group of non-autonomic nodes, and that other non-autonomic nodes will be managed traditionally. > I haven't seen a good argument against this approach. To my > knowledge, this approach is what has been commonly built. > >> Also, if there is Intent that is meaningful only to certain ASAs, >> how can that semantic be handled in a generic Intent handler? > > That's why I prefer pub-sub to flooding. I find that contradictory with your description of it as pseudo-natural language; what we deliver to ASAs needs to be straightforward to interpret. Rgds Brian > > regards, > John > > On Sat, Apr 2, 2016 at 6:09 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> On 03/04/2016 03:31, John Strassner wrote: >> >> >> ... >>> I do not think that it is necessary to combine disparate >>> intents into a single file. >> >> That seems to mean that each recipient of multiple files has to >> performance consistency checks and conflict resolution, unless >> you have a watertight definition of 'disparate'. >> >> ... >>> 5: Intent is processed/compiled by dedicated entities (in my >>> case, these are agents). This is because it takes specific >>> resources and specific knowledge to do this. >> >> Well, we definitely need to talk about that. Do you mean that >> each autonomic node would contain such an agent, or that such >> agents would be few in number? >> >>> >>> 6: I prefer pub-sub. If flooding, then it should be constrained. >> >> Constrained flooding is the hardest case. If Intent is small, why >> can't we flood it, with unicast pub/sub to fill in any gaps? >> >>> 7: In general, Intent is NOT understood by nodes or ASAs. >>> This is because the node or ASA would have to have access >>> to additional significant resources. >> >> If there is Intent support code in each node, is that a problem? >> Also, if there is Intent that is meaningful only to certain ASAs, >> how can that semantic be handled in a generic Intent handler? >> >> Rgds >> Brian >> >> >> > > From nobody Sun Apr 3 14:48:38 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3312912D155 for ; Sun, 3 Apr 2016 14:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 twNiCgX0_n3H for ; Sun, 3 Apr 2016 14:48:32 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CF9E12D52E for ; Sun, 3 Apr 2016 14:48:31 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id c62so143239894lfc.1 for ; Sun, 03 Apr 2016 14:48:31 -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; bh=OiRzoXUVgvZb6P7mdXhSnZ7J7hT76C67sFiD1Hgd7rQ=; b=bY5MTqR+WmqxLZjSSrAYS9Cp/cz2o9AyYlvSc7OIE0JVFz/54tLjc/BpQX3zVmRYCw 1/cPBIH6V4YYT3AGTT6oAsXBAr/vJHDhVZ2EQAalF/meW0Jf4uBA6Rxk87RdbRU0nEPx Piu4e8lGgDHWogIQFLRWeyVqVWlXB86uRufBWPO8Js27fqfejSZjCCmY3T8HUPHHCebN XXCf2hriYNWk8WYQlHegfQen14zTciX5qq1Vrn3Ipug0VP4jDfv7sIoILoExZsZJhir4 jw1YR/lP8FeoIslc2+gTJ+JN52eJ9DBAv7qQyfkHStKqx9A7s/z/r4ZCSSqD8JYszXA3 nMIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=OiRzoXUVgvZb6P7mdXhSnZ7J7hT76C67sFiD1Hgd7rQ=; b=P9pHTnc34rEf75BB2+uB0vuqyM0ef977K8n7/na9pexE8RB/Q8ovX4vfG60UJJCVwm giER7Fhd+Lhvn7qNjqU4VFn5vh7mHz6N4P6YgTXOCqErLLaiHMlBcSql59gRQHzWyWJX II18ft8Y/1mhML2Ap9cZQRqBksztFGNayPLfuqcPLk5DK+50GczLEVLmsfJ1TjDnF4yT oKUjdjScMUZEfp8oS+R/ZnaT7dW0FmWUjnAEPPoF8c29dWjuZ8oLTLi4pfB34oyJCxIl kJVT0Qpcc5glaglamtiU+JmaXfDij95ElhcGPeyUY9cLJaWQcfHB9TigTP3vxt4GmkEO gw/A== X-Gm-Message-State: AD7BkJLd0wUQAisrq1C92Ay0Thw874btH2Oo2gisVWJQqGHmkI+iuphumSYQlZHvJCI26VMK3SD4lQAR5IYUcg== MIME-Version: 1.0 X-Received: by 10.25.218.196 with SMTP id r187mr6649525lfg.6.1459720109532; Sun, 03 Apr 2016 14:48:29 -0700 (PDT) Received: by 10.25.22.19 with HTTP; Sun, 3 Apr 2016 14:48:29 -0700 (PDT) In-Reply-To: <56FAD79E.2020504@gmail.com> References: <701d351267344c21b3ea053aa5b15728@XCH-RCD-006.cisco.com> <8368235337ea4adfab5c428d57c3bfb2@XCH-RCD-006.cisco.com> <56F60CE4.9040901@gmail.com> <56F6DAA1.8000206@gmail.com> <56F82FDD.7090405@gmail.com> <56FAAD7B.6080305@alcatel-lucent.com> <56FAD79E.2020504@gmail.com> Date: Sun, 3 Apr 2016 14:48:29 -0700 Message-ID: From: John Strassner To: Brian E Carpenter , John Strassner Content-Type: multipart/alternative; boundary=001a11401f3c99ab8b052f9b92a8 Archived-At: Cc: Laurent Ciavaglia , Duzongpeng , "Michael Behringer \(mbehring\)" , =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= , "anima@ietf.org" , Sheng Jiang Subject: Re: [Anima] Does Autonomic network need some intervention beyond intent X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 21:48:37 -0000 --001a11401f3c99ab8b052f9b92a8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Brian, could I request two points of clarification? >>> Indeed not. An ASA will have some default behaviour that amounts to having >>> default settings for intent, but by definition intent comes from humans= . >>> (One qualification: if the intent that reaches a given node is inconsistent, >>> then resolving that inconsistency might be autonomic.) >> >> Brian: could you explain what you mean here, especially "resolving that inconsistency might be autonomic"? >> I guess you mean that ASAs/nodes can autonomously detect inconsistency in intents and (try to) solve this inconsistency (on >> their own or via collaboration)...? > Yes. Actually if we allow more than one source of intent, this is essential. According to the reference architecture, an Autonomic Function (AF) can be made up of one or more ASAs, and each ASA is instantiated on an autonomic node. The set of AFs reside on the ANI. I would prefer that intent is sent to the ASA, not directly to the (autonomic) node. This means that the autonomic node has to be able to understand intent AND understand when intent conflicts, and the Industry has a poor of providing useful support functions. Even with the hype that is IoT, show me a vendor that wants to make their phone "intelligent" vs. providing higher-resolution cameras or more codecs. :-( Another consequence is that each ASA has to be able to understand intent AND understand when intent conflicts. OK, I could suppose that we could define AFs for this. But AFs are built on the ANI, so does this mean that the ANI has to support intent as well? The draft says: The ANI provides functions like naming, addressing, negotiation, synchronization, discovery and messaging. These are all functions that are needed by Intent, but Intent adds things that are not needed by the ANI. >> Without rewriting history, we are facing now with the "heavy" >> design/conceptual discussions on the list, the effect of some >> decisions to exclude architectural analysis / investigations in the >> early phase of ANIMA... > I maintain that these are issues of ASA design, not infrastructure design= . > We always knew that the infrastructure has to distribute Intent. I think that the infrastructure has to distribute the **results** of parsin= g intent. That is, the parsing is done in a dedicated agent, NOT in an autonomic node, and the agent transforms Intent to a form that is generally consumable. This "consumable form" has to be distributed, but the original intent does not. regards, John On Tue, Mar 29, 2016 at 12:29 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Hi Laurent, comments in line: > On 30/03/2016 05:29, Laurent Ciavaglia wrote: > > Hello, > > > > > >> Indeed not. An ASA will have some default behaviour that amounts to > having > >> default settings for intent, but by definition intent comes from human= s. > >> (One qualification: if the intent that reaches a given node is > inconsistent, > >> then resolving that inconsistency might be autonomic.) > > > > Brian: could you explain what you mean here, especially "resolving that > inconsistency might be autonomic"? > > I guess you mean that ASAs/nodes can autonomously detect inconsistency > in intents and (try to) solve this inconsistency (on > > their own or via collaboration)...? > > Yes. Actually if we allow more than one source of intent, this is > essential. > > > > >> > >>>> Of course, when we put Intent into the picture, there's a presumptio= n > >>>> that Intent comes from some authority such as a NOC, but that's an > >>>> external semantic, not an assumption of the autonomic model. > >>> Well, no - if the autonomic system is going to use intent, or at leas= t > >>> respond to it, then it must understand those external semantics. > >>> This is even more important if the network is supposed to form > >>> according to one or more intent rules. > >> Right, but what I meant is that the network will operate perfectly wel= l > >> if no intent is sent, by using defaults. That will always happen to th= e > >> extent that intent distribution will take a finite time. Until the > intent > >> reaches a node, it will operate on defaults. > > > > From collaborations with some operators on autonomic networking > projects: default behavior without policy must equal to "do > > nothing". But operators' views might change/evolve... > > That's certainly a possibility. I'm not sure it is always wise though. > For example, if a network is fragmented by a natural disaster, the > fragments > might not receive Intent for several days. > > > Also, and this is based on feedback from the field (e.g. 3GPP SON), > turning on autonomic functions, even with well-thought > > parameter settings, turns out most of the times in chaotic behaviors an= d > severe performance degradations. > > A key element to consider here is how to "gracefully" start/ramp-up an > autonomic network and aspects of coordination (cf > > draft-ciavaglia-anima-coordination-01). > > Agreed. Obviously the defaults must be conservative and fail-safe. > > > > >> Of course, the semantics of > >> intent must be well-defined, but it's an extra layer. > >> > >>> If intent is formulated at an abstract level, how is an autonomic > >>> network going to consume intent that may have drastically different > >>> syntactical structures, and likely, different semantics associated wi= th > >>> those syntactical structures? > >> Agreed. We need a model, syntax and semantics. > >> > >>>> I think the point is that AN *adds* a new mode of communication > >>>> between self-managing nodes, that doesn't exist in a strictly > >>>> north/south scenario. That is meant to reduce the amount of > >>>> north/south communication and reduce the amount of > >>>> centralized work. So there's a trade-off - more autonomic > >>>> messaging means less north-south messaging. > > > > north-south is a matter of convention / roles. > > if we consider PBM / intent, for me it implies a "vertical" (authority) > relationship. > > if we consider a more "flat" system of collaborative entities, then > let's have a look at MAS / DAI approaches and not reinvent > > (a squarred) wheel. > > we may end up pushing more or less intelligence in the autonomic > functions, but we also consider the scope of ANIMA to address > > "managed" networks (maybe not only this one), so it means some operator= s > will expect certain behavior/performance from the > > neworks. Intent is one way to inform the network what is expected. > > Sure. But always remember the disaster-recovery scenario where we are > forced > back to defaults. > > > > >>> There may indeed be a new mode of communication required. > >>> However, if intent is not standardized, how does this work? > >> It doesn't. My only point is that intent is layered on top of an > >> underlying autonomic behaviour based on default behaviours. Actually, > >> that's why the question of intent was deferred in the WG charter. > > > > Your explanation is "valid", but I don't remember this was the reason > used to consider intent FFS. > > OK, maybe that was just in my brain. Another aspect that Intent was > incompletely > understood. > > > Without rewriting history, we are facing now with the "heavy" > design/conceptual discussions on the list, the effect of some > > decisions to exclude architectural analysis / investigations in the > early phase of ANIMA... > > I maintain that these are issues of ASA design, not infrastructure design= . > We always > knew that the infrastructure has to distribute Intent. > > Regards > Brian > > > Laurent. > > > > > >> > >> Brian > >> > >>> I understand how unstructured and structured P2P networks > >>> work. Let's assume this is a structured P2P network. In that case, > >>> a DHT is used to assign ownership of each file to a peer. I fail to > >>> understand how this works in an intent case. Files are passive, > >>> intent is active. Please explain. > >>> > >>> Regards, > >>> John > >>> > >>> On Sat, Mar 26, 2016 at 11:53 AM, Brian E Carpenter < > >>> brian.e.carpenter@gmail.com> wrote: > >>> > >>>> Hi John, > >>>> On 27/03/2016 04:54, John Strassner wrote: > >>>>>> Correct, and there is also no presumption that individual nodes > >>>>>> have perfect knowledge of the topology. Of course the ACP > >>>>>> routing protocol will have perfect knowledge of the ACP topology, > >>>>>> but individual ASAs only know what they have gleaned from > >>>>>> discovery and what they have been told by Intent. > >>>>>> > >>>>>> It is, I think, a very different world view than the SDN or SUPA o= r > >>>>>> NVO4 or NFV view. > >>>>> Please note that I did NOT say anything about SDN, NFV, or SUPA > >>>>> here. In fact, I'm confused as to why you both think I did. > >>>> I can't speak for Zongpeng, but I was triggered by the mention of > >>>> northbound and southbound APIs. There is no presumed direction in > >>>> Anima relationships, since in the limit a network is self-forming; > >>>> all relationships are peer-to-peer. > >>>> > >>>> Of course, when we put Intent into the picture, there's a presumptio= n > >>>> that Intent comes from some authority such as a NOC, but that's an > >>>> external semantic, not an assumption of the autonomic model. > >>>> > >>>>> I specifically said "There are plenty of southbound APIs (from a > >>>>> management function to a device). There are very few northbound > APIs." > >>>>> > >>>>> Note the word "management function". > >>>>> > >>>>> For the record, I don't think that either Phase 2 of NFV or the SDN > 1.1 > >>>>> architecture have treated policy in any detail. Both architectures > lack a > >>>>> policy management component. I hope that ANIMA doesn't make the > >>>>> same mistake. > >>>> Certainly, Intent needs a number of properties such as > self-consistency > >>>> and stability that imply it is managed in some way. > >>>> > >>>>>>> However, in ANIMA network, perhaps we do not have a centralized > >>>>>>> parsing node (controller), which can replace almost all the > >>>>>>> communications between nodes. > >>>>> Earlier I wrote about intent requiring a translation function. I > never > >>>> said > >>>>> that it was centralized or distributed. In the autonomic > architectures I > >>>>> have built, it was in fact a decentralized (agent-driven) function. > >>>>> Furthermore, it did not "replace almost all the communications" - i= t > >>>>> was used for compilation. There was, in fact, a separate distributi= on > >>>>> mechanism (which I have also described), but that was limited to > >>>>> "just" distribution. > >>>>> > >>>>> I really don't understand what "replacing communications" means. > >>>> I think the point is that AN *adds* a new mode of communication > between > >>>> self-managing nodes, that doesn't exist in a strictly north/south > >>>> scenario. That is meant to reduce the amount of north/south > communication > >>>> and reduce the amount of centralized work. So there's a trade-off - > >>>> more autonomic messaging means less north-south messaging. > >>>> > >>>> Best regards > >>>> Brian > >>>> > >>>>> regards, > >>>>> John > >>>>> > >>>>> On Fri, Mar 25, 2016 at 9:15 PM, Brian E Carpenter < > >>>>> brian.e.carpenter@gmail.com> wrote: > >>>>> > >>>>>>> However, in ANIMA network, perhaps we do not have a centralized > parsing > >>>>>> node (controller), which can replace almost all the communications > >>>> between > >>>>>> nodes. > >>>>>> > >>>>>> Correct, and there is also no presumption that individual nodes ha= ve > >>>>>> perfect > >>>>>> knowledge of the topology. Of course the ACP routing protocol will > have > >>>>>> perfect > >>>>>> knowledge of the ACP topology, but individual ASAs only know what > they > >>>> have > >>>>>> gleaned from discovery and what they have been told by Intent. > >>>>>> > >>>>>> It is, I think, a very different world view than the SDN or SUPA o= r > NVO4 > >>>>>> or NFV view. > >>>>>> > >>>>>> Regards > >>>>>> Brian > >>>>>> > >>>>>> On 26/03/2016 16:46, Duzongpeng wrote: > >>>>>>> Hi John: > >>>>>>> > >>>>>>> Thanks for your reply. > >>>>>>> > >>>>>>> > >>>>>>> How is this different than running a script, or invoking an API? > There > >>>>>> are plenty of southbound APIs (from a management function to a > device). > >>>>>> There are very few northbound APIs. That's what the operators that= I > >>>> have > >>>>>> talked to want. > >>>>>>> > >>>>>>> > >>>>>>> I agree that intent belongs to northbound interface in the SDN > network. > >>>>>> And ANIMA network perhaps can share the same northbound interface. > >>>>>>> But, my understanding is that ANIMA network is a little different > from > >>>>>> SDN network. > >>>>>>> SDN controller will parse the intent, and transform to detailed > >>>>>> configurations of every device. It is a good model, and little > >>>>>> communications between nodes are needed. > >>>>>>> Some network level parameters can be handled in SDN controller. > >>>>>>> > >>>>>>> However, in ANIMA network, perhaps we do not have a centralized > parsing > >>>>>> node (controller), which can replace almost all the communications > >>>> between > >>>>>> nodes. > >>>>>>> So when a network operator is operating a ANIMA network, the > network > >>>>>> level parameters are still needed to be flooded. > >>>>>>> I mean the ANIMA interface is perhaps something like =E2=80=9Cnor= thbound + > part > >>>>>> of southbound=E2=80=9D. > >>>>>>> Best Regards > >>>>>>> Zongpeng Du > >>>>>>> > >>>>>>> > >>>>>>> From: John Strassner [mailto:strazpdj@gmail.com] > >>>>>>> Sent: Saturday, March 26, 2016 9:41 AM > >>>>>>> To: Duzongpeng; John Strassner > >>>>>>> Cc: Michael Behringer (mbehring); Laurent Ciavaglia; Sheng Jiang; > >>>>>> anima@ietf.org; J=C3=A9ferson Campos Nobre > >>>>>>> Subject: Re: [Anima] Does Autonomic network need some interventio= n > >>>>>> beyond intent > >>>>>>> Hi Zongpeng, > >>>>>>> > >>>>>>> I think we have a misunderstanding here. > >>>>>>> > >>>>>>> > >>>>>>> But I do not support that the intent writer should look every > detail in > >>>>>> the catalog. > >>>>>>> > >>>>>>> Most catalogs that I have seen have very few details. They instea= d > tell > >>>>>> the user what services or products are available. > >>>>>>> > >>>>>>> > >>>>>>> The intent writer may mainly care about what they want, but how t= o > do > >>>> it > >>>>>> can be left to the autonomic network to deal with. > >>>>>>> > >>>>>>> I agree completely. > >>>>>>> > >>>>>>> > >>>>>>> Perhaps several solutions exist, and autonomic management system > choose > >>>>>> one according to the abilities collected. > >>>>>>> > >>>>>>> This is one of the reasons why I would like to see capabilities > (and > >>>>>> needs) advertised. > >>>>>>> > >>>>>>> > >>>>>>> ... > >>>>>>> I mean in current status, some of the Autonomic Functions should = be > >>>>>> exposed to the network operator, and some of the Autonomic Functio= ns > >>>> can be > >>>>>> hidden to the network operator > >>>>>>> ... > >>>>>>> > >>>>>>> How is this different than running a script, or invoking an API? > There > >>>>>> are plenty of southbound APIs (from a management function to a > device). > >>>>>> There are very few northbound APIs. That's what the operators that= I > >>>> have > >>>>>> talked to want. > >>>>>>> regards, > >>>>>>> John > >>>>>>> > >>>>>>> On Fri, Mar 25, 2016 at 2:31 AM, Duzongpeng >>>>>> > wrote: > >>>>>>> Hi John > >>>>>>> > >>>>>>> Some personal understanding here. If any misunderstanding, please > >>>>>> correct me. Thanks. > >>>>>>> > >>>>>>> I would suggest a slight modification, to enable users of > >>>>>>> intent (and even intent writers) to NOT have to have > >>>>>>> detailed implementation information. > >>>>>>> > >>>>>>> What if all of the Autonomic Functions, after they joined > >>>>>>> the network, advertised both their capabilities as well as > >>>>>>> their needs? We can put aside the latter (needs) as this > >>>>>>> is more complex, but if the capabilities are advertised, > >>>>>>> then the autonomic management system can assemble > >>>>>>> those needs into a catalog. Then, the intent writer can > >>>>>>> look at the catalog and write a declarative request to > >>>>>>> use the functionality of the catalog. > >>>>>>> > >>>>>>> I will look at your YANG model in a bit (sorry, I'm woefully > >>>>>>> behind...). > >>>>>>> < /jcs2> > >>>>>>> > >>>>>>> I agree that autonomic node should have that self-advertisement > >>>> ability, > >>>>>> and autonomic management system should have this catalog. > >>>>>>> But I do not support that the intent writer should look every > detail in > >>>>>> the catalog. > >>>>>>> The intent writer may mainly care about what they want, but how t= o > do > >>>> it > >>>>>> can be left to the autonomic network to deal with. > >>>>>>> Perhaps several solutions exist, and autonomic management system > choose > >>>>>> one according to the abilities collected. > >>>>>>> In the ideal, the network operator may communicate with the > autonomic > >>>>>> network using network-level level intent and network-level report. > >>>>>>> I mean in current status, some of the Autonomic Functions should = be > >>>>>> exposed to the network operator, and some of the Autonomic Functio= ns > >>>> can be > >>>>>> hidden to the network operator > >>>>>>> Perhaps in future, when the network nodes become more intelligent= , > the > >>>>>> hidden part will increase. > >>>>>>> > >>>>>>> Best regards > >>>>>>> Zongpeng Du > >>>>>>> > >>>>>>> From: Anima [mailto:anima-bounces@ietf.org >>>> anima-bounces@ietf.org>] > >>>>>> On Behalf Of John Strassner > >>>>>>> Sent: Thursday, March 24, 2016 10:41 AM > >>>>>>> To: Michael Behringer (mbehring); John Strassner > >>>>>>> Cc: Duzongpeng; Laurent Ciavaglia; Sheng Jiang; anima@ietf.org > >>>>>> anima@ietf.org>; J=C3=A9ferson Campos Nobre > >>>>>>> Subject: Re: [Anima] Does Autonomic network need some interventio= n > >>>>>> beyond intent > >>>>>>> Hi Michael, > >>>>>>> > >>>>>>> thanks for your reply. I do think that we largely agree, and woul= d > >>>> enjoy > >>>>>> chatting during or (hopefully before) BA. Please see > ... > >>>> Also > >>>>>> trying to unclutter, so I am eliding points that we agree on. > >>>>>>> > >>>>>>> While *CIEs don=E2=80=99t like magic, they do understand the conc= ept of a > >>>>>> default behaviour which they can influence if needed. Any reasonab= le > >>>>>> network management approach tries to define =E2=80=9Cdefault=E2=80= =9D behaviour and > >>>>>> =E2=80=9Cexceptions=E2=80=9D. The AN story fills the =E2=80=9Cdefa= ult=E2=80=9D part very nicely, and > >>>> *CIEs > >>>>>> get that. > >>>>>>> > >>>>>>> Agreed! > >>>>>>> > >>>>>>> > >>>>>>> The =E2=80=9Cparameter=E2=80=9D versus =E2=80=9Cpolicy=E2=80=9D d= iscussion: My view is that we > >>>> shouldn=E2=80=99t > >>>>>> try to define exactly *what* intent allows and doesn=E2=80=99t all= ow, since > >>>> we=E2=80=99ve > >>>>>> heard from many sides that the boundary is not clear, and it may b= e > >>>>>> impossible to have a really clear, usable definition. So my point > was: > >>>>>> Let=E2=80=99s focus on the distribution model: Intent is flooded t= o all > nodes. > >>>>>> Let=E2=80=99s NOT do selective flooding, unicast Intent to specifi= c nodes, > etc, > >>>>>> because that would blur the boundary even worse. > >>>>>>> > >>>>>>> I like flooding intent to all nodes. In FOCALE (v1-3, and > remember, v1 > >>>>>> was 2006, almost 10 years ago), we used a message bus and pub-sub. > In > >>>> v2, > >>>>>> we flooded; in v3, we went back to pub-sub because we wanted to do > some > >>>>>> optimization and auditing. But I would be happy to try some type o= f > >>>>>> controlled flooding again. > >>>>>>> > >>>>>>> My suggestion: Intent is flooded to all nodes in a domain. The AS= A > >>>>>> owners define the content of what they want to push in their bit o= f > the > >>>>>> Intent. If we insist of full flooding, we encourage the right > behaviour. > >>>>>> And if someone really puts into his Intent =E2=80=9Cnode A: do thi= s; node > B: do > >>>> the > >>>>>> other; node C: do the third=E2=80=9D it is awkward enough for peop= le to > take a > >>>> step > >>>>>> back and think whether they=E2=80=99re doing the right thing =E2= =98=BA > >>>>>>> > >>>>>>> I agree in principle with what you said. Plus, see above. > >>>>>>> < /jcs2> > >>>>>>> > >>>>>>> Do you mean that the intent writer will **know the difference** > >>>>>>> between the fabric and each autonomic function? I hope not, > >>>>>>> but perhaps I'm misunderstanding you... > >>>>>>> < /jcs> > >>>>>>> Not sure I understand your concern. Yes, in my model there is a > section > >>>>>> for the fabric, and sections for the various functions. Seems a > natural > >>>>>> structure?!? > >>>>>>> The intent **writer** would have to know implementation > >>>>>>> details in order to place everything in a single file. I would > >>>>>>> rather not require this, and instead, have the intent engine > >>>>>>> (e.g., compiler and associated logic) do this. > >>>>>>> < /jcs2> > >>>>>>> =E2=80=9CFunction owner=E2=80=9D: Yes, I=E2=80=99m suggesting to = structure Intent around > >>>>>> Autonomic Functions. This is not optimal from a scientific point o= f > >>>> view, > >>>>>> but aligns very well with the way how things are organised. > Probably we > >>>>>> need to discuss that in BA. But refer to my YANG model sent a few > days > >>>> ago. > >>>>>>> > >>>>>>> I would suggest a slight modification, to enable users of > >>>>>>> intent (and even intent writers) to NOT have to have > >>>>>>> detailed implementation information. > >>>>>>> > >>>>>>> What if all of the Autonomic Functions, after they joined > >>>>>>> the network, advertised both their capabilities as well as > >>>>>>> their needs? We can put aside the latter (needs) as this > >>>>>>> is more complex, but if the capabilities are advertised, > >>>>>>> then the autonomic management system can assemble > >>>>>>> those needs into a catalog. Then, the intent writer can > >>>>>>> look at the catalog and write a declarative request to > >>>>>>> use the functionality of the catalog. > >>>>>>> > >>>>>>> I will look at your YANG model in a bit (sorry, I'm woefully > >>>>>>> behind...). > >>>>>>> < /jcs2> > >>>>>>> > >>>>>>> > >>>>>>> regards, > >>>>>>> John > >>>>>>> > >>>>>>> On Wed, Mar 23, 2016 at 3:57 AM, Michael Behringer (mbehring) < > >>>>>> mbehring@cisco.com> wrote: > >>>>>>> John, > >>>>>>> > >>>>>>> I think we=E2=80=99re on the same page. Couple of points, top pos= ting here, > >>>>>> otherwise it gets too messy. > >>>>>>> While *CIEs don=E2=80=99t like magic, they do understand the conc= ept of a > >>>>>> default behaviour which they can influence if needed. Any reasonab= le > >>>>>> network management approach tries to define =E2=80=9Cdefault=E2=80= =9D behaviour and > >>>>>> =E2=80=9Cexceptions=E2=80=9D. The AN story fills the =E2=80=9Cdefa= ult=E2=80=9D part very nicely, and > >>>> *CIEs > >>>>>> get that. > >>>>>>> The =E2=80=9Cparameter=E2=80=9D versus =E2=80=9Cpolicy=E2=80=9D d= iscussion: My view is that we > >>>> shouldn=E2=80=99t > >>>>>> try to define exactly *what* intent allows and doesn=E2=80=99t all= ow, since > >>>> we=E2=80=99ve > >>>>>> heard from many sides that the boundary is not clear, and it may b= e > >>>>>> impossible to have a really clear, usable definition. So my point > was: > >>>>>> Let=E2=80=99s focus on the distribution model: Intent is flooded t= o all > nodes. > >>>>>> Let=E2=80=99s NOT do selective flooding, unicast Intent to specifi= c nodes, > etc, > >>>>>> because that would blur the boundary even worse. > >>>>>>> My suggestion: Intent is flooded to all nodes in a domain. The AS= A > >>>>>> owners define the content of what they want to push in their bit o= f > the > >>>>>> Intent. If we insist of full flooding, we encourage the right > behaviour. > >>>>>> And if someone really puts into his Intent =E2=80=9Cnode A: do thi= s; node > B: do > >>>> the > >>>>>> other; node C: do the third=E2=80=9D it is awkward enough for peop= le to > take a > >>>> step > >>>>>> back and think whether they=E2=80=99re doing the right thing =E2= =98=BA > >>>>>>> > >>>>>>> Do you mean that the intent writer will **know the difference** > >>>>>>> between the fabric and each autonomic function? I hope not, > >>>>>>> but perhaps I'm misunderstanding you... > >>>>>>> > >>>>>>> > >>>>>>> Not sure I understand your concern. Yes, in my model there is a > section > >>>>>> for the fabric, and sections for the various functions. Seems a > natural > >>>>>> structure?!? > >>>>>>> =E2=80=9CFunction owner=E2=80=9D: Yes, I=E2=80=99m suggesting to = structure Intent around > >>>>>> Autonomic Functions. This is not optimal from a scientific point o= f > >>>> view, > >>>>>> but aligns very well with the way how things are organised. > Probably we > >>>>>> need to discuss that in BA. But refer to my YANG model sent a few > days > >>>> ago. > >>>>>>> We should schedule some discussion time outside the ANIMA meeting > >>>>>> window... > >>>>>>> Michael > >>>>>>> > >>>>>>> > >>>>>>> From: John Strassner [mailto:strazpdj@gmail.com >>>>>> strazpdj@gmail.com>] > >>>>>>> Sent: 22 March 2016 21:32 > >>>>>>> To: Michael Behringer (mbehring) >>>>>> mbehring@cisco.com>>; John Strassner >>>>>> strazpdj@gmail.com>> > >>>>>>> Cc: Duzongpeng >>; > >>>>>> anima@ietf.org; Laurent Ciavaglia < > >>>>>> laurent.ciavaglia@nokia.com>; > >>>>>> J=C3=A9ferson Campos Nobre jcnobre@inf.ufrgs.br > >>>>>> ; > >>>>>> Sheng Jiang > > >>>>>>> Subject: Re: [Anima] Does Autonomic network need some interventio= n > >>>>>> beyond intent > >>>>>>> In general, I agree with Michael. I'd like to emphasize and expan= d > on a > >>>>>> couple of key points: > >>>>>>> > >>>>>>> First, ANIMA isn=E2=80=99t the only thing =E2=80=9Cinfluencing=E2= =80=9D or =E2=80=9Csteering=E2=80=9D a > >>>> network, > >>>>>> at least not initially. There is still traditional config, plus al= l > the > >>>>>> existing and emerging SDN models. My view has always been that ANI= MA > >>>> sets a > >>>>>> =E2=80=9Cdefault=E2=80=9D policy in a network, and all other means= are more > specific and > >>>>>> can override intent. This is described in RFC7575. Main point here= : > >>>> ANIMA > >>>>>> Intent isn=E2=80=99t the only tool in a network. > >>>>>>> > >>>>>>> Absolutely agree. Note that even in the Congress case I mentioned > >>>>>>> earlier, it is NOT pushing config, and it is NOT viewed as the > >>>>>>> "only" policy > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Intent could perfectly well cover a high level policy such as =E2= =80=9Call > >>>> nodes > >>>>>> of type x do this; type y does that=E2=80=9D. (Which I think is wh= at you > mention > >>>>>> below.) When we started with Intent, the vision was to keep it ver= y > high > >>>>>> level, more along the line =E2=80=9Cdo the right thing=E2=80=9D = =E2=98=BA > >>>>>>> > >>>>>>> Agreed. Although to me, this means that we need to consider the > types > >>>> of > >>>>>> actors that are using intent. For example, most of my CCIE and JCI= E > >>>> friends > >>>>>> have no interest in using an intent language for pushing > configuration. > >>>> On > >>>>>> the other hand, when I talk to operators and application developer= s, > >>>> they > >>>>>> would love to be able to use a high-level intent and have the inte= nt > >>>> engine > >>>>>> take care of the details for them. > >>>>>>> > >>>>>>> > >>>>>>> It has become clear that in today=E2=80=99s networking, people wi= ll want to > >>>> push > >>>>>> more =E2=80=9Cparameters=E2=80=9D than =E2=80=9Cpolicy=E2=80=9D, a= nd I think we=E2=80=99ll just have to > >>>> acknowledge > >>>>>> that. > >>>>>>> > >>>>>>> Sorry Michael, I don't follow here. What do you mean > >>>>>>> by "parameters"? > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Personally I think it=E2=80=99ll pan out like this: Intent will h= ave > sections > >>>>>> per autonomic function. An Intent parser will validate overall > >>>> correctness > >>>>>> (signature, etc), then segment the Intent into its bits: One part > will > >>>> be > >>>>>> the autonomic fabric itself, then there will be bits for each > autonomic > >>>>>> function. > >>>>>>> > >>>>>>> Do you mean that the intent writer will **know the difference** > >>>>>>> between the fabric and each autonomic function? I hope not, > >>>>>>> but perhaps I'm misunderstanding you... > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> So the Intent parser on a node will grab intent, see there is som= e > >>>>>> Intent for autonomic function A, will see whether this is running > >>>> locally, > >>>>>> and if so, it=E2=80=99ll just pass that piece of Intent to that fu= nction. > >>>>>>> > >>>>>>> Agreed. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> In this way, a function owner defines both the intent itself, and > how > >>>> it > >>>>>> is consumed by his/her function. > >>>>>>> > >>>>>>> I'm not sure what you mean by "function owner". (Sorry to be > >>>>>>> picky, I'm likely under-caffeinated.) > >>>>>>> > >>>>>>> The above seemed like an autonomous decision, made by the parser. > >>>>>>> I don't think that the intent writer should be cognizant of how > many or > >>>>>>> what types of autonomic functions are present. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> The downside is that there is no =E2=80=9Ccontrol=E2=80=9D and pe= ople can do what > they > >>>>>> want, in the worst case even push config, which is clearly NOT wha= t > >>>> Intent > >>>>>> is meant to do. > >>>>>>> > >>>>>>> And hence, the "HAL 2000" scenario. :-) > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> I=E2=80=99d hope that people don=E2=80=99t start writing Intent l= ike =E2=80=9Cnode 17: > here is > >>>>>> your CLI; node 23: here is your CLI=E2=80=9D; node 37: here is you= r CLI=E2=80=9D. > But > >>>> what > >>>>>> I describe above COULD be abused in this way. RFC7575 says this is > NOT > >>>>>> Intent. > >>>>>>> > >>>>>>> Absolutely agree! > >>>>>>> > >>>>>>> > >>>>>>> regards, > >>>>>>> John > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Wed, Mar 16, 2016 at 1:16 AM, Michael Behringer (mbehring) < > >>>>>> mbehring@cisco.com> wrote: > >>>>>>> Hi Zongpeng, > >>>>>>> > >>>>>>> Yes, this is a recurring question and topic. Let me give my view > on two > >>>>>> levels: > >>>>>>> First, ANIMA isn=E2=80=99t the only thing =E2=80=9Cinfluencing=E2= =80=9D or =E2=80=9Csteering=E2=80=9D a > >>>> network, > >>>>>> at least not initially. There is still traditional config, plus al= l > the > >>>>>> existing and emerging SDN models. My view has always been that ANI= MA > >>>> sets a > >>>>>> =E2=80=9Cdefault=E2=80=9D policy in a network, and all other means= are more > specific and > >>>>>> can override intent. This is described in RFC7575. Main point here= : > >>>> ANIMA > >>>>>> Intent isn=E2=80=99t the only tool in a network. > >>>>>>> Intent could perfectly well cover a high level policy such as =E2= =80=9Call > >>>> nodes > >>>>>> of type x do this; type y does that=E2=80=9D. (Which I think is wh= at you > mention > >>>>>> below.) When we started with Intent, the vision was to keep it ver= y > high > >>>>>> level, more along the line =E2=80=9Cdo the right thing=E2=80=9D = =E2=98=BA It has become > clear > >>>> that > >>>>>> in today=E2=80=99s networking, people will want to push more =E2= =80=9Cparameters=E2=80=9D > than > >>>>>> =E2=80=9Cpolicy=E2=80=9D, and I think we=E2=80=99ll just have to a= cknowledge that. > >>>>>>> Personally I think it=E2=80=99ll pan out like this: Intent will h= ave > sections > >>>>>> per autonomic function. An Intent parser will validate overall > >>>> correctness > >>>>>> (signature, etc), then segment the Intent into its bits: One part > will > >>>> be > >>>>>> the autonomic fabric itself, then there will be bits for each > autonomic > >>>>>> function. > >>>>>>> So the Intent parser on a node will grab intent, see there is som= e > >>>>>> Intent for autonomic function A, will see whether this is running > >>>> locally, > >>>>>> and if so, it=E2=80=99ll just pass that piece of Intent to that fu= nction. > >>>>>>> In this way, a function owner defines both the intent itself, and > how > >>>> it > >>>>>> is consumed by his/her function. > >>>>>>> The downside is that there is no =E2=80=9Ccontrol=E2=80=9D and pe= ople can do what > they > >>>>>> want, in the worst case even push config, which is clearly NOT wha= t > >>>> Intent > >>>>>> is meant to do. I=E2=80=99d hope that people don=E2=80=99t start w= riting Intent like > >>>> =E2=80=9Cnode > >>>>>> 17: here is your CLI; node 23: here is your CLI=E2=80=9D; node 37:= here is > your > >>>>>> CLI=E2=80=9D. But what I describe above COULD be abused in this wa= y. RFC7575 > >>>> says > >>>>>> this is NOT Intent. > >>>>>>> In other words: Let=E2=80=99s not be too prescriptive, and hope t= hat folks > will > >>>>>> do more or less reasonable things. > >>>>>>> I=E2=80=99ve been meaning to comment on the Intent drafts and pos= sibly > >>>>>> contribute, I=E2=80=99m just struggling with priorities at the mom= ent (as > you > >>>> can > >>>>>> see by my relative silence over the past weeks). > >>>>>>> Michael > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> From: Anima [mailto:anima-bounces@ietf.org >>>> anima-bounces@ietf.org>] > >>>>>> On Behalf Of Duzongpeng > >>>>>>> Sent: 16 March 2016 02:38 > >>>>>>> To: anima@ietf.org > >>>>>>> Cc: Laurent Ciavaglia >>>>>> laurent.ciavaglia@nokia.com>>; J=C3=A9ferson Campos Nobre < > >>>> jcnobre@inf.ufrgs.br > >>>>>> >; Sheng Jiang >>>> >>>>>> jiangsheng@huawei.com>> > >>>>>>> Subject: [Anima] Does Autonomic network need some intervention > beyond > >>>>>> intent > >>>>>>> Hello, everyone > >>>>>>> > >>>>>>> I understand that Autonomic network should be able to > work > >>>> with > >>>>>> as less configuration as possible. In the ideal case, an Autonomic > >>>> network > >>>>>> should be able to work well while only intent is needed from human > >>>>>> operators. > >>>>>>> However, I wonder whether Autonomic network may need so= me > >>>>>> intervention from human operators through some low-level policies > beyond > >>>>>> intents. > >>>>>>> For example, in the > >>>>>> https://tools.ietf.org/html/draft-ietf-anima-prefix-management-00, > it > >>>> is > >>>>>> suggested that the prefix lengths for the CSG, ASG, RSG (different > >>>> roles in > >>>>>> IP RAN) can be assigned as an "intent". These configuration > parameters > >>>> need > >>>>>> to be distributed in the autonomic domain to influence the detail > >>>>>> configurations on each autonomic node. > >>>>>>> As intent is described as an abstract, declarative, > high-level > >>>>>> policy used to operate an autonomic domain, such as an enterprise > >>>> network. > >>>>>> Perhaps we can rename the =E2=80=9Cintent=E2=80=9D in the =E2=80= =9Cprefix-management ID=E2=80=9D to > some > >>>>>> other words. > >>>>>>> Is =E2=80=9CASA parameters" ok here? > >>>>>>> > >>>>>>> I think some characteristics for this kind of low-level policies > are > >>>>>>> > >>>>>>> 1. Network level parameters, need to be distributed by GRAS= P > and > >>>>>> ACP > >>>>>>> 2. Relatively static compared to intent, perhaps only neede= d > to > >>>> be > >>>>>> configured once > >>>>>>> 3. Unavoidable in current network environment, mostly for > >>>>>> establishing the network infrastructure > >>>>>>> 4. Rarely need coordinations with others parameters, usuall= y > is > >>>>>> closed related to one specific autonomic function > >>>>>>> Welcome for comment. Your suggestions will be appreciated. > >>>>>>> > >>>>>>> > >>>>>>> Best Regards > >>>>>>> Zongpeng Du > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Anima mailing list > >>>>>>> Anima@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/anima > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> regards, > >>>>>>> John > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> regards, > >>>>>>> John > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> regards, > >>>>>>> John > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Anima mailing list > >>>>>>> Anima@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/anima > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > > > --=20 regards, John --001a11401f3c99ab8b052f9b92a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Brian,

could I request tw= o points of clarification?

>>> Indeed not= . An ASA will have some default behaviour that amounts to having
>>= ;> default settings for intent, but by definition intent comes from huma= ns.
>>> (One qualification: if the intent that reaches a given = node is inconsistent,
>>> then resolving that inconsistency mig= ht be autonomic.)
>>
>> Brian: could you explain what yo= u mean here, especially "resolving that inconsistency might be autonom= ic"?
>> I guess you mean that ASAs/nodes can autonomously det= ect inconsistency in intents and (try to) solve this inconsistency (on
&= gt;> their own or via collaboration)...?

> Yes. Actually if w= e allow more than one source of intent, this is essential.
According to the reference architecture, an Autonomic Function= (AF) can
be made up of one or more ASAs, and each ASA is instant= iated on an
autonomic node. The set of AFs reside on the ANI.

I would prefer that intent is sent to the ASA, not di= rectly to the (autonomic)
node. This means that the autonomic nod= e has to be able to understand
intent AND understand when intent = conflicts, and the Industry has a poor
of providing useful suppor= t functions. Even with the hype that is IoT, show
me a vendor tha= t wants to make their phone "intelligent" vs. providing
higher-resolution cameras or more codecs. :-(

Ano= ther consequence is that=C2=A0each ASA has to be able to understand intent<= /div>
AND understand when intent conflicts. OK, I could suppose that we= could
define AFs for this. But AFs are built on the ANI, so does= this mean that
the ANI has to support intent as well? The draft = says:

=C2=A0=C2=A0=C2=A0=C2=A0 The ANI provides fu= nctions like naming, addressing, negotiation,
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 synchronization, discovery and messaging.

=
These are all functions that are needed by Intent, but Intent adds thi= ngs
that are not needed by the ANI.

>= > Without rewriting history, we are facing now with the "heavy"= ;
>> design/conceptual discussions on the list, the effect = of some
>> decisions to exclude architectural analysis / investiga= tions in the
>> early phase of ANIMA...

> I main= tain that these are issues of ASA design, not infrastructure design.
<= div>> We always knew that the infrastructure has to distribute Intent.

I think that the infrastructure has to distribute t= he **results** of parsing
intent. That is, the parsing is done in= a dedicated agent, NOT in an
autonomic node, and the agent trans= forms Intent to a form that is
generally consumable. This "c= onsumable form" has to be distributed,
but the original inte= nt does not.

regards,
John

On Tue, Mar 29, 201= 6 at 12:29 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
Hi Laurent, comments = in line:
On 30/03/2016 05:29, Laurent Ciavaglia wrote:
> Hello,
>
>
>> Indeed not. An ASA will have some default behaviour that amounts t= o having
>> default settings for intent, but by definition intent comes from h= umans.
>> (One qualification: if the intent that reaches a given node is inc= onsistent,
>> then resolving that inconsistency might be autonomic.)
>
> Brian: could you explain what you mean here, especially "resolvin= g that inconsistency might be autonomic"?
> I guess you mean that ASAs/nodes can autonomously detect inconsistency= in intents and (try to) solve this inconsistency (on
> their own or via collaboration)...?

Yes. Actually if we allow more than one source of intent, this is essential= .

>
>>
>>>> Of course, when we put Intent into the picture, there'= s a presumption
>>>> that Intent comes from some authority such as a NOC, but t= hat's an
>>>> external semantic, not an assumption of the autonomic mode= l.
>>> Well, no - if the autonomic system is going to use intent, or = at least
>>> respond to it, then it must understand those external semantic= s.
>>> This is even more important if the network is supposed to form=
>>> according to one or more intent rules.
>> Right, but what I meant is that the network will operate perfectly= well
>> if no intent is sent, by using defaults. That will always happen t= o the
>> extent that intent distribution will take a finite time. Until the= intent
>> reaches a node, it will operate on defaults.
>
> From collaborations with some operators on autonomic networking projec= ts: default behavior without policy must equal to "do
> nothing". But operators' views might change/evolve...

That's certainly a possibility. I'm not sure it is always wise thou= gh.
For example, if a network is fragmented by a natural disaster, the fragment= s
might not receive Intent for several days.

> Also, and this is based on feedback from the field (e.g. 3GPP SON), tu= rning on autonomic functions, even with well-thought
> parameter settings, turns out most of the times in chaotic behaviors a= nd severe performance degradations.
> A key element to consider here is how to "gracefully" start/= ramp-up an autonomic network and aspects of coordination (cf
> draft-ciavaglia-anima-coordination-01).

Agreed. Obviously the defaults must be conservative and fail-safe.

>
>>=C2=A0 =C2=A0Of course, the semantics of
>> intent must be well-defined, but it's an extra layer.
>>
>>> If intent is formulated at an abstract level, how is an autono= mic
>>> network going to consume intent that may have drastically diff= erent
>>> syntactical structures, and likely, different semantics associ= ated with
>>> those syntactical structures?
>> Agreed. We need a model, syntax and semantics.
>>
>>>> I think the point is that AN *adds* a new mode of communic= ation
>>>> between self-managing nodes, that doesn't exist in a s= trictly
>>>> north/south scenario. That is meant to reduce the amount o= f
>>>> north/south communication and reduce the amount of
>>>> centralized work. So there's a trade-off - more autono= mic
>>>> messaging means less north-south messaging.
>
> north-south is a matter of convention / roles.
> if we consider PBM / intent, for me it implies a "vertical" = (authority) relationship.
> if we consider a more "flat" system of collaborative entitie= s, then let's have a look at MAS / DAI approaches and not reinvent
> (a squarred) wheel.
> we may end up pushing more or less intelligence in the autonomic funct= ions, but we also consider the scope of ANIMA to address
> "managed" networks (maybe not only this one), so it means so= me operators will expect certain behavior/performance from the
> neworks. Intent is one way to inform the network what is expected.

Sure. But always remember the disaster-recovery scenario where we are force= d
back to defaults.

>
>>> There may indeed be a new mode of communication required.
>>> However, if intent is not standardized, how does this work? >> It doesn't. My only point is that intent is layered on top of = an
>> underlying autonomic behaviour based on default behaviours. Actual= ly,
>> that's why the question of intent was deferred in the WG chart= er.
>
> Your explanation is "valid", but I don't remember this w= as the reason used to consider intent FFS.

OK, maybe that was just in my brain. Another aspect that Intent was incompl= etely
understood.

> Without rewriting history, we are facing now with the "heavy"= ; design/conceptual discussions on the list, the effect of some
> decisions to exclude architectural analysis / investigations in the ea= rly phase of ANIMA...

I maintain that these are issues of ASA design, not infrastructure design. = We always
knew that the infrastructure has to distribute Intent.

Regards
=C2=A0 =C2=A0Brian

> Laurent.
>
>
>>
>>=C2=A0 =C2=A0 =C2=A0 Brian
>>
>>> I understand how unstructured and structured P2P networks
>>> work. Let's assume this is a structured P2P network. In th= at case,
>>> a DHT is used to assign ownership of each file to a peer. I fa= il to
>>> understand how this works in an intent case. Files are passive= ,
>>> intent is active. Please explain.
>>>
>>> Regards,
>>> John
>>>
>>> On Sat, Mar 26, 2016 at 11:53 AM, Brian E Carpenter <
>>> brian.e.carpent= er@gmail.com> wrote:
>>>
>>>> Hi John,
>>>> On 27/03/2016 04:54, John Strassner wrote:
>>>>>> Correct, and there is also no presumption that ind= ividual nodes
>>>>>> have perfect knowledge of the topology. Of course = the ACP
>>>>>> routing protocol will have perfect knowledge of th= e ACP topology,
>>>>>> but individual ASAs only know what they have glean= ed from
>>>>>> discovery and what they have been told by Intent.<= br> >>>>>>
>>>>>> It is, I think, a very different world view than t= he SDN or SUPA or
>>>>>> NVO4 or NFV view.
>>>>> Please note that I did NOT say anything about SDN, NFV= , or SUPA
>>>>> here. In fact, I'm confused as to why you both thi= nk I did.
>>>> I can't speak for Zongpeng, but I was triggered by the= mention of
>>>> northbound and southbound APIs. There is no presumed direc= tion in
>>>> Anima relationships, since in the limit a network is self-= forming;
>>>> all relationships are peer-to-peer.
>>>>
>>>> Of course, when we put Intent into the picture, there'= s a presumption
>>>> that Intent comes from some authority such as a NOC, but t= hat's an
>>>> external semantic, not an assumption of the autonomic mode= l.
>>>>
>>>>> I specifically said "There are plenty of southbou= nd APIs (from a
>>>>> management function to a device). There are very few n= orthbound APIs."
>>>>>
>>>>> Note the word "management function".
>>>>>
>>>>> For the record, I don't think that either Phase 2 = of NFV or the SDN 1.1
>>>>> architecture have treated policy in any detail. Both a= rchitectures lack a
>>>>> policy management component. I hope that ANIMA doesn&#= 39;t make the
>>>>> same mistake.
>>>> Certainly, Intent needs a number of properties such as sel= f-consistency
>>>> and stability that imply it is managed in some way.
>>>>
>>>>>>> However, in ANIMA network, perhaps we do not h= ave a centralized
>>>>>>> parsing node (controller), which can replace a= lmost all the
>>>>>>> communications between nodes.
>>>>> Earlier I wrote about intent requiring a translation f= unction. I never
>>>> said
>>>>> that it was centralized or distributed. In the autonom= ic architectures I
>>>>> have built, it was in fact a decentralized (agent-driv= en) function.
>>>>> Furthermore, it did not "replace almost all the c= ommunications" - it
>>>>> was used for compilation. There was, in fact, a separa= te distribution
>>>>> mechanism (which I have also described), but that was = limited to
>>>>> "just" distribution.
>>>>>
>>>>> I really don't understand what "replacing com= munications" means.
>>>> I think the point is that AN *adds* a new mode of communic= ation between
>>>> self-managing nodes, that doesn't exist in a strictly = north/south
>>>> scenario. That is meant to reduce the amount of north/sout= h communication
>>>> and reduce the amount of centralized work. So there's = a trade-off -
>>>> more autonomic messaging means less north-south messaging.=
>>>>
>>>> Best regards
>>>>=C2=A0 =C2=A0 =C2=A0Brian
>>>>
>>>>> regards,
>>>>> John
>>>>>
>>>>> On Fri, Mar 25, 2016 at 9:15 PM, Brian E Carpenter <= ;
>>>>> brian.e= .carpenter@gmail.com> wrote:
>>>>>
>>>>>>> However, in ANIMA network, perhaps we do not h= ave a centralized parsing
>>>>>> node (controller), which can replace almost all th= e communications
>>>> between
>>>>>> nodes.
>>>>>>
>>>>>> Correct, and there is also no presumption that ind= ividual nodes have
>>>>>> perfect
>>>>>> knowledge of the topology. Of course the ACP routi= ng protocol will have
>>>>>> perfect
>>>>>> knowledge of the ACP topology, but individual ASAs= only know what they
>>>> have
>>>>>> gleaned from discovery and what they have been tol= d by Intent.
>>>>>>
>>>>>> It is, I think, a very different world view than t= he SDN or SUPA or NVO4
>>>>>> or NFV view.
>>>>>>
>>>>>> Regards
>>>>>>=C2=A0 =C2=A0 =C2=A0Brian
>>>>>>
>>>>>> On 26/03/2016 16:46, Duzongpeng wrote:
>>>>>>> Hi John:
>>>>>>>
>>>>>>> Thanks for your reply.
>>>>>>>
>>>>>>> <jcs>
>>>>>>> How is this different than running a script, o= r invoking an API? There
>>>>>> are plenty of southbound APIs (from a management f= unction to a device).
>>>>>> There are very few northbound APIs. That's wha= t the operators that I
>>>> have
>>>>>> talked to want.
>>>>>>> </jcs>
>>>>>>>
>>>>>>> I agree that intent belongs to northbound inte= rface in the SDN network.
>>>>>> And ANIMA network perhaps can share the same north= bound interface.
>>>>>>> But, my understanding is that ANIMA network is= a little different from
>>>>>> SDN network.
>>>>>>> SDN controller will parse the intent, and tran= sform to detailed
>>>>>> configurations of every device. It is a good model= , and little
>>>>>> communications between nodes are needed.
>>>>>>> Some network level parameters can be handled i= n SDN controller.
>>>>>>>
>>>>>>> However, in ANIMA network, perhaps we do not h= ave a centralized parsing
>>>>>> node (controller), which can replace almost all th= e communications
>>>> between
>>>>>> nodes.
>>>>>>> So when a network operator is operating a ANIM= A network, the network
>>>>>> level parameters are still needed to be flooded. >>>>>>> I mean the ANIMA interface is perhaps somethin= g like =E2=80=9Cnorthbound + part
>>>>>> of southbound=E2=80=9D.
>>>>>>> Best Regards
>>>>>>> Zongpeng Du
>>>>>>>
>>>>>>>
>>>>>>> From: John Strassner [mailto:strazpdj@gmail.com]
>>>>>>> Sent: Saturday, March 26, 2016 9:41 AM
>>>>>>> To: Duzongpeng; John Strassner
>>>>>>> Cc: Michael Behringer (mbehring); Laurent Ciav= aglia; Sheng Jiang;
>>>>>> anima@ietf.org; J=C3=A9ferson Campos Nobre
>>>>>>> Subject: Re: [Anima] Does Autonomic network ne= ed some intervention
>>>>>> beyond intent
>>>>>>> Hi Zongpeng,
>>>>>>>
>>>>>>> I think we have a misunderstanding here.
>>>>>>>
>>>>>>>
>>>>>>> But I do not support that the intent writer sh= ould look every detail in
>>>>>> the catalog.
>>>>>>> <jcs>
>>>>>>> Most catalogs that I have seen have very few d= etails. They instead tell
>>>>>> the user what services or products are available.<= br> >>>>>>> </jcs>
>>>>>>>
>>>>>>> The intent writer may mainly care about what t= hey want, but how to do
>>>> it
>>>>>> can be left to the autonomic network to deal with.=
>>>>>>> <jcs>
>>>>>>> I agree completely.
>>>>>>> </jcs>
>>>>>>>
>>>>>>> Perhaps several solutions exist, and autonomic= management system choose
>>>>>> one according to the abilities collected.
>>>>>>> <jcs>
>>>>>>> This is one of the reasons why I would like to= see capabilities (and
>>>>>> needs) advertised.
>>>>>>> </jcs>
>>>>>>>
>>>>>>> ...
>>>>>>> I mean in current status, some of the Autonomi= c Functions should be
>>>>>> exposed to the network operator, and some of the A= utonomic Functions
>>>> can be
>>>>>> hidden to the network operator
>>>>>>> ...
>>>>>>> <jcs>
>>>>>>> How is this different than running a script, o= r invoking an API? There
>>>>>> are plenty of southbound APIs (from a management f= unction to a device).
>>>>>> There are very few northbound APIs. That's wha= t the operators that I
>>>> have
>>>>>> talked to want.
>>>>>>> regards,
>>>>>>> John
>>>>>>>
>>>>>>> On Fri, Mar 25, 2016 at 2:31 AM, Duzongpeng &l= t;duzongpeng@huawei.com
>>>>>> <mailto:duzongpeng@huawei.com>> wrote:
>>>>>>> Hi John
>>>>>>>
>>>>>>> Some personal understanding here. If any misun= derstanding, please
>>>>>> correct me. Thanks.
>>>>>>> <jcs2>
>>>>>>> I would suggest a slight modification, to enab= le users of
>>>>>>> intent (and even intent writers) to NOT have t= o have
>>>>>>> detailed implementation information.
>>>>>>>
>>>>>>> What if all of the Autonomic Functions, after = they joined
>>>>>>> the network, advertised both their capabilitie= s as well as
>>>>>>> their needs? We can put aside the latter (need= s) as this
>>>>>>> is more complex, but if the capabilities are a= dvertised,
>>>>>>> then the autonomic management system can assem= ble
>>>>>>> those needs into a catalog. Then, the intent w= riter can
>>>>>>> look at the catalog and write a declarative re= quest to
>>>>>>> use the functionality of the catalog.
>>>>>>>
>>>>>>> I will look at your YANG model in a bit (sorry= , I'm woefully
>>>>>>> behind...).
>>>>>>> < /jcs2>
>>>>>>>
>>>>>>> I agree that autonomic node should have that s= elf-advertisement
>>>> ability,
>>>>>> and autonomic management system should have this c= atalog.
>>>>>>> But I do not support that the intent writer sh= ould look every detail in
>>>>>> the catalog.
>>>>>>> The intent writer may mainly care about what t= hey want, but how to do
>>>> it
>>>>>> can be left to the autonomic network to deal with.=
>>>>>>> Perhaps several solutions exist, and autonomic= management system choose
>>>>>> one according to the abilities collected.
>>>>>>> In the ideal, the network operator may communi= cate with the autonomic
>>>>>> network using network-level level intent and netwo= rk-level report.
>>>>>>> I mean in current status, some of the Autonomi= c Functions should be
>>>>>> exposed to the network operator, and some of the A= utonomic Functions
>>>> can be
>>>>>> hidden to the network operator
>>>>>>> Perhaps in future, when the network nodes beco= me more intelligent, the
>>>>>> hidden part will increase.
>>>>>>>
>>>>>>> Best regards
>>>>>>> Zongpeng Du
>>>>>>>
>>>>>>> From: Anima [mailto:anima-bounces@ietf.org<mailto:
>>>> anima-bounces@ie= tf.org>]
>>>>>> On Behalf Of John Strassner
>>>>>>> Sent: Thursday, March 24, 2016 10:41 AM
>>>>>>> To: Michael Behringer (mbehring); John Strassn= er
>>>>>>> Cc: Duzongpeng; Laurent Ciavaglia; Sheng Jiang= ; anima@ietf.org<mailto:
>>>>>> anima@ietf.org>; J=C3=A9ferson Campos Nobre
>>>>>>> Subject: Re: [Anima] Does Autonomic network ne= ed some intervention
>>>>>> beyond intent
>>>>>>> Hi Michael,
>>>>>>>
>>>>>>> thanks for your reply. I do think that we larg= ely agree, and would
>>>> enjoy
>>>>>> chatting during or (hopefully before) BA. Please s= ee <jcs2>..</jcs2>.
>>>> Also
>>>>>> trying to unclutter, so I am eliding points that w= e agree on.
>>>>>>>
>>>>>>> While *CIEs don=E2=80=99t like magic, they do = understand the concept of a
>>>>>> default behaviour which they can influence if need= ed. Any reasonable
>>>>>> network management approach tries to define =E2=80= =9Cdefault=E2=80=9D behaviour and
>>>>>> =E2=80=9Cexceptions=E2=80=9D. The AN story fills t= he =E2=80=9Cdefault=E2=80=9D part very nicely, and
>>>> *CIEs
>>>>>> get that.
>>>>>>> <jcs2>
>>>>>>> Agreed!
>>>>>>> </jcs2>
>>>>>>>
>>>>>>> The =E2=80=9Cparameter=E2=80=9D versus =E2=80= =9Cpolicy=E2=80=9D discussion: My view is that we
>>>> shouldn=E2=80=99t
>>>>>> try to define exactly *what* intent allows and doe= sn=E2=80=99t allow, since
>>>> we=E2=80=99ve
>>>>>> heard from many sides that the boundary is not cle= ar, and it may be
>>>>>> impossible to have a really clear, usable definiti= on. So my point was:
>>>>>> Let=E2=80=99s focus on the distribution model: Int= ent is flooded to all nodes.
>>>>>> Let=E2=80=99s NOT do selective flooding, unicast I= ntent to specific nodes, etc,
>>>>>> because that would blur the boundary even worse. >>>>>>> <jcs2>
>>>>>>> I like flooding intent to all nodes. In FOCALE= (v1-3, and remember, v1
>>>>>> was 2006, almost 10 years ago), we used a message = bus and pub-sub. In
>>>> v2,
>>>>>> we flooded; in v3, we went back to pub-sub because= we wanted to do some
>>>>>> optimization and auditing. But I would be happy to= try some type of
>>>>>> controlled flooding again.
>>>>>>> </jcs2>
>>>>>>> My suggestion: Intent is flooded to all nodes = in a domain. The ASA
>>>>>> owners define the content of what they want to pus= h in their bit of the
>>>>>> Intent. If we insist of full flooding, we encourag= e the right behaviour.
>>>>>> And if someone really puts into his Intent =E2=80= =9Cnode A: do this; node B: do
>>>> the
>>>>>> other; node C: do the third=E2=80=9D it is awkward= enough for people to take a
>>>> step
>>>>>> back and think whether they=E2=80=99re doing the r= ight thing =E2=98=BA
>>>>>>> <jcs2>
>>>>>>> I agree in principle with what you said. Plus,= see above.
>>>>>>> < /jcs2>
>>>>>>> <jcs>
>>>>>>> Do you mean that the intent writer will **know= the difference**
>>>>>>> between the fabric and each autonomic function= ? I hope not,
>>>>>>> but perhaps I'm misunderstanding you... >>>>>>> < /jcs>
>>>>>>> Not sure I understand your concern. Yes, in my= model there is a section
>>>>>> for the fabric, and sections for the various funct= ions. Seems a natural
>>>>>> structure?!? <jcs2>
>>>>>>> The intent **writer** would have to know imple= mentation
>>>>>>> details in order to place everything in a sing= le file. I would
>>>>>>> rather not require this, and instead, have the= intent engine
>>>>>>> (e.g., compiler and associated logic) do this.=
>>>>>>> < /jcs2>
>>>>>>> =E2=80=9CFunction owner=E2=80=9D: Yes, I=E2=80= =99m suggesting to structure Intent around
>>>>>> Autonomic Functions. This is not optimal from a sc= ientific point of
>>>> view,
>>>>>> but aligns very well with the way how things are o= rganised. Probably we
>>>>>> need to discuss that in BA. But refer to my YANG m= odel sent a few days
>>>> ago.
>>>>>>> <jcs2>
>>>>>>> I would suggest a slight modification, to enab= le users of
>>>>>>> intent (and even intent writers) to NOT have t= o have
>>>>>>> detailed implementation information.
>>>>>>>
>>>>>>> What if all of the Autonomic Functions, after = they joined
>>>>>>> the network, advertised both their capabilitie= s as well as
>>>>>>> their needs? We can put aside the latter (need= s) as this
>>>>>>> is more complex, but if the capabilities are a= dvertised,
>>>>>>> then the autonomic management system can assem= ble
>>>>>>> those needs into a catalog. Then, the intent w= riter can
>>>>>>> look at the catalog and write a declarative re= quest to
>>>>>>> use the functionality of the catalog.
>>>>>>>
>>>>>>> I will look at your YANG model in a bit (sorry= , I'm woefully
>>>>>>> behind...).
>>>>>>> < /jcs2>
>>>>>>>
>>>>>>>
>>>>>>> regards,
>>>>>>> John
>>>>>>>
>>>>>>> On Wed, Mar 23, 2016 at 3:57 AM, Michael Behri= nger (mbehring) <
>>>>>> mbehring@cis= co.com<mailto:mbehring@cisco.c= om>> wrote:
>>>>>>> John,
>>>>>>>
>>>>>>> I think we=E2=80=99re on the same page. Couple= of points, top posting here,
>>>>>> otherwise it gets too messy.
>>>>>>> While *CIEs don=E2=80=99t like magic, they do = understand the concept of a
>>>>>> default behaviour which they can influence if need= ed. Any reasonable
>>>>>> network management approach tries to define =E2=80= =9Cdefault=E2=80=9D behaviour and
>>>>>> =E2=80=9Cexceptions=E2=80=9D. The AN story fills t= he =E2=80=9Cdefault=E2=80=9D part very nicely, and
>>>> *CIEs
>>>>>> get that.
>>>>>>> The =E2=80=9Cparameter=E2=80=9D versus =E2=80= =9Cpolicy=E2=80=9D discussion: My view is that we
>>>> shouldn=E2=80=99t
>>>>>> try to define exactly *what* intent allows and doe= sn=E2=80=99t allow, since
>>>> we=E2=80=99ve
>>>>>> heard from many sides that the boundary is not cle= ar, and it may be
>>>>>> impossible to have a really clear, usable definiti= on. So my point was:
>>>>>> Let=E2=80=99s focus on the distribution model: Int= ent is flooded to all nodes.
>>>>>> Let=E2=80=99s NOT do selective flooding, unicast I= ntent to specific nodes, etc,
>>>>>> because that would blur the boundary even worse. >>>>>>> My suggestion: Intent is flooded to all nodes = in a domain. The ASA
>>>>>> owners define the content of what they want to pus= h in their bit of the
>>>>>> Intent. If we insist of full flooding, we encourag= e the right behaviour.
>>>>>> And if someone really puts into his Intent =E2=80= =9Cnode A: do this; node B: do
>>>> the
>>>>>> other; node C: do the third=E2=80=9D it is awkward= enough for people to take a
>>>> step
>>>>>> back and think whether they=E2=80=99re doing the r= ight thing =E2=98=BA
>>>>>>> <jcs>
>>>>>>> Do you mean that the intent writer will **know= the difference**
>>>>>>> between the fabric and each autonomic function= ? I hope not,
>>>>>>> but perhaps I'm misunderstanding you... >>>>>>> </jcs>
>>>>>>>
>>>>>>> Not sure I understand your concern. Yes, in my= model there is a section
>>>>>> for the fabric, and sections for the various funct= ions. Seems a natural
>>>>>> structure?!?
>>>>>>> =E2=80=9CFunction owner=E2=80=9D: Yes, I=E2=80= =99m suggesting to structure Intent around
>>>>>> Autonomic Functions. This is not optimal from a sc= ientific point of
>>>> view,
>>>>>> but aligns very well with the way how things are o= rganised. Probably we
>>>>>> need to discuss that in BA. But refer to my YANG m= odel sent a few days
>>>> ago.
>>>>>>> We should schedule some discussion time outsid= e the ANIMA meeting
>>>>>> window...
>>>>>>> Michael
>>>>>>>
>>>>>>>
>>>>>>> From: John Strassner [mailto:strazpdj@gmail.com<mailto:
>>>>>> strazpdj@gma= il.com>]
>>>>>>> Sent: 22 March 2016 21:32
>>>>>>> To: Michael Behringer (mbehring) <mbehring@cisco.com<mailto:
>>>>>> mbehring@cis= co.com>>; John Strassner <strazpdj@gmail.com<mailto:
>>>>>> strazpdj@gma= il.com>>
>>>>>>> Cc: Duzongpeng <duzongpeng@huawei.com<mailto:duzongpeng@huawei.com>>;
>>>>>> anima@ietf.org<mailto:anima@ietf.org>; Laur= ent Ciavaglia <
>>>>>> lau= rent.ciavaglia@nokia.com<mailto:laurent.ciavaglia@nokia.com>>;
>>>>>> J=C3=A9ferson Campos Nobre <jcnobre@inf.ufrgs.br<mailto:jcnobre@inf.ufrgs.br
>>>>>> ;
>>>>>> Sheng Jiang <jiangsheng@huawei.com<mailto:jiangsheng@huawei.com>>
>>>>>>> Subject: Re: [Anima] Does Autonomic network ne= ed some intervention
>>>>>> beyond intent
>>>>>>> In general, I agree with Michael. I'd like= to emphasize and expand on a
>>>>>> couple of key points:
>>>>>>>
>>>>>>> First, ANIMA isn=E2=80=99t the only thing =E2= =80=9Cinfluencing=E2=80=9D or =E2=80=9Csteering=E2=80=9D a
>>>> network,
>>>>>> at least not initially. There is still traditional= config, plus all the
>>>>>> existing and emerging SDN models. My view has alwa= ys been that ANIMA
>>>> sets a
>>>>>> =E2=80=9Cdefault=E2=80=9D policy in a network, and= all other means are more specific and
>>>>>> can override intent. This is described in RFC7575.= Main point here:
>>>> ANIMA
>>>>>> Intent isn=E2=80=99t the only tool in a network. >>>>>>> <jcs>
>>>>>>> Absolutely agree. Note that even in the Congre= ss case I mentioned
>>>>>>> earlier, it is NOT pushing config, and it is N= OT viewed as the
>>>>>>> "only" policy
>>>>>>> </jcs>
>>>>>>>
>>>>>>>
>>>>>>> Intent could perfectly well cover a high level= policy such as =E2=80=9Call
>>>> nodes
>>>>>> of type x do this; type y does that=E2=80=9D. (Whi= ch I think is what you mention
>>>>>> below.) When we started with Intent, the vision wa= s to keep it very high
>>>>>> level, more along the line =E2=80=9Cdo the right t= hing=E2=80=9D =E2=98=BA
>>>>>>> <jcs>
>>>>>>> Agreed. Although to me, this means that we nee= d to consider the types
>>>> of
>>>>>> actors that are using intent. For example, most of= my CCIE and JCIE
>>>> friends
>>>>>> have no interest in using an intent language for p= ushing configuration.
>>>> On
>>>>>> the other hand, when I talk to operators and appli= cation developers,
>>>> they
>>>>>> would love to be able to use a high-level intent a= nd have the intent
>>>> engine
>>>>>> take care of the details for them.
>>>>>>> </jcs>
>>>>>>>
>>>>>>> It has become clear that in today=E2=80=99s ne= tworking, people will want to
>>>> push
>>>>>> more =E2=80=9Cparameters=E2=80=9D than =E2=80=9Cpo= licy=E2=80=9D, and I think we=E2=80=99ll just have to
>>>> acknowledge
>>>>>> that.
>>>>>>> <jcs>
>>>>>>> Sorry Michael, I don't follow here. What d= o you mean
>>>>>>> by "parameters"?
>>>>>>> </jcs>
>>>>>>>
>>>>>>>
>>>>>>> Personally I think it=E2=80=99ll pan out like = this: Intent will have sections
>>>>>> per autonomic function. An Intent parser will vali= date overall
>>>> correctness
>>>>>> (signature, etc), then segment the Intent into its= bits: One part will
>>>> be
>>>>>> the autonomic fabric itself, then there will be bi= ts for each autonomic
>>>>>> function.
>>>>>>> <jcs>
>>>>>>> Do you mean that the intent writer will **know= the difference**
>>>>>>> between the fabric and each autonomic function= ? I hope not,
>>>>>>> but perhaps I'm misunderstanding you... >>>>>>> </jcs>
>>>>>>>
>>>>>>>
>>>>>>> So the Intent parser on a node will grab inten= t, see there is some
>>>>>> Intent for autonomic function A, will see whether = this is running
>>>> locally,
>>>>>> and if so, it=E2=80=99ll just pass that piece of I= ntent to that function.
>>>>>>> <jcs>
>>>>>>> Agreed.
>>>>>>> </jcs>
>>>>>>>
>>>>>>>
>>>>>>> In this way, a function owner defines both the= intent itself, and how
>>>> it
>>>>>> is consumed by his/her function.
>>>>>>> <jcs>
>>>>>>> I'm not sure what you mean by "functi= on owner". (Sorry to be
>>>>>>> picky, I'm likely under-caffeinated.)
>>>>>>>
>>>>>>> The above seemed like an autonomous decision, = made by the parser.
>>>>>>> I don't think that the intent writer shoul= d be cognizant of how many or
>>>>>>> what types of autonomic functions are present.=
>>>>>>> </jcs>
>>>>>>>
>>>>>>>
>>>>>>> The downside is that there is no =E2=80=9Ccont= rol=E2=80=9D and people can do what they
>>>>>> want, in the worst case even push config, which is= clearly NOT what
>>>> Intent
>>>>>> is meant to do.
>>>>>>> <jcs>
>>>>>>> And hence, the "HAL 2000" scenario. = :-)
>>>>>>> </jcs>
>>>>>>>
>>>>>>>
>>>>>>> I=E2=80=99d hope that people don=E2=80=99t sta= rt writing Intent like =E2=80=9Cnode 17: here is
>>>>>> your CLI; node 23: here is your CLI=E2=80=9D; node= 37: here is your CLI=E2=80=9D. But
>>>> what
>>>>>> I describe above COULD be abused in this way. RFC7= 575 says this is NOT
>>>>>> Intent.
>>>>>>> <jcs>
>>>>>>> Absolutely agree!
>>>>>>> </jcs>
>>>>>>>
>>>>>>>=C2=A0 =C2=A0regards,
>>>>>>> John
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Mar 16, 2016 at 1:16 AM, Michael Behri= nger (mbehring) <
>>>>>> mbehring@cis= co.com<mailto:mbehring@cisco.c= om>> wrote:
>>>>>>> Hi Zongpeng,
>>>>>>>
>>>>>>> Yes, this is a recurring question and topic. L= et me give my view on two
>>>>>> levels:
>>>>>>> First, ANIMA isn=E2=80=99t the only thing =E2= =80=9Cinfluencing=E2=80=9D or =E2=80=9Csteering=E2=80=9D a
>>>> network,
>>>>>> at least not initially. There is still traditional= config, plus all the
>>>>>> existing and emerging SDN models. My view has alwa= ys been that ANIMA
>>>> sets a
>>>>>> =E2=80=9Cdefault=E2=80=9D policy in a network, and= all other means are more specific and
>>>>>> can override intent. This is described in RFC7575.= Main point here:
>>>> ANIMA
>>>>>> Intent isn=E2=80=99t the only tool in a network. >>>>>>> Intent could perfectly well cover a high level= policy such as =E2=80=9Call
>>>> nodes
>>>>>> of type x do this; type y does that=E2=80=9D. (Whi= ch I think is what you mention
>>>>>> below.) When we started with Intent, the vision wa= s to keep it very high
>>>>>> level, more along the line =E2=80=9Cdo the right t= hing=E2=80=9D =E2=98=BA=C2=A0 It has become clear
>>>> that
>>>>>> in today=E2=80=99s networking, people will want to= push more =E2=80=9Cparameters=E2=80=9D than
>>>>>> =E2=80=9Cpolicy=E2=80=9D, and I think we=E2=80=99l= l just have to acknowledge that.
>>>>>>> Personally I think it=E2=80=99ll pan out like = this: Intent will have sections
>>>>>> per autonomic function. An Intent parser will vali= date overall
>>>> correctness
>>>>>> (signature, etc), then segment the Intent into its= bits: One part will
>>>> be
>>>>>> the autonomic fabric itself, then there will be bi= ts for each autonomic
>>>>>> function.
>>>>>>> So the Intent parser on a node will grab inten= t, see there is some
>>>>>> Intent for autonomic function A, will see whether = this is running
>>>> locally,
>>>>>> and if so, it=E2=80=99ll just pass that piece of I= ntent to that function.
>>>>>>> In this way, a function owner defines both the= intent itself, and how
>>>> it
>>>>>> is consumed by his/her function.
>>>>>>> The downside is that there is no =E2=80=9Ccont= rol=E2=80=9D and people can do what they
>>>>>> want, in the worst case even push config, which is= clearly NOT what
>>>> Intent
>>>>>> is meant to do. I=E2=80=99d hope that people don= =E2=80=99t start writing Intent like
>>>> =E2=80=9Cnode
>>>>>> 17: here is your CLI; node 23: here is your CLI=E2= =80=9D; node 37: here is your
>>>>>> CLI=E2=80=9D. But what I describe above COULD be a= bused in this way. RFC7575
>>>> says
>>>>>> this is NOT Intent.
>>>>>>> In other words: Let=E2=80=99s not be too presc= riptive, and hope that folks will
>>>>>> do more or less reasonable things.
>>>>>>> I=E2=80=99ve been meaning to comment on the In= tent drafts and possibly
>>>>>> contribute, I=E2=80=99m just struggling with prior= ities at the moment (as you
>>>> can
>>>>>> see by my relative silence over the past weeks). >>>>>>> Michael
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> From: Anima [mailto:anima-bounces@ietf.org<mailto:
>>>> anima-bounces@ie= tf.org>]
>>>>>> On Behalf Of Duzongpeng
>>>>>>> Sent: 16 March 2016 02:38
>>>>>>> To: anima@ie= tf.org<mailto:anima@ietf.org&g= t;
>>>>>>> Cc: Laurent Ciavaglia <laurent.ciavaglia@nokia.com<mailto:
>>>>>> lau= rent.ciavaglia@nokia.com>>; J=C3=A9ferson Campos Nobre <
>>>> jcnobre@inf.ufrgs.= br
>>>>>> <mailto:jcnobre@inf.ufrgs.br>>; Sheng Jiang <jiangsheng@huawei.com
>>>> <mailto:
>>>>>> jiangshen= g@huawei.com>>
>>>>>>> Subject: [Anima] Does Autonomic network need s= ome intervention beyond
>>>>>> intent
>>>>>>> Hello, everyone
>>>>>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I unde= rstand that Autonomic network should be able to work
>>>> with
>>>>>> as less configuration as possible. In the ideal ca= se, an Autonomic
>>>> network
>>>>>> should be able to work well while only intent is n= eeded from human
>>>>>> operators.
>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Howeve= r, I wonder whether Autonomic network may need some
>>>>>> intervention from human operators through some low= -level policies beyond
>>>>>> intents.
>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0For ex= ample, in the
>>>>>> https://to= ols.ietf.org/html/draft-ietf-anima-prefix-management-00, it
>>>> is
>>>>>> suggested that the prefix lengths for the CSG, ASG= , RSG (different
>>>> roles in
>>>>>> IP RAN) can be assigned as an "intent". = These configuration parameters
>>>> need
>>>>>> to be distributed in the autonomic domain to influ= ence the detail
>>>>>> configurations on each autonomic node.
>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0As int= ent is described as an abstract, declarative, high-level
>>>>>> policy used to operate an autonomic domain, such a= s an enterprise
>>>> network.
>>>>>> Perhaps we can rename the =E2=80=9Cintent=E2=80=9D= in the =E2=80=9Cprefix-management ID=E2=80=9D to some
>>>>>> other words.
>>>>>>> Is =E2=80=9CASA parameters" ok here?
>>>>>>>
>>>>>>> I think some characteristics for this kind of = low-level policies are
>>>>>>>
>>>>>>> 1.=C2=A0 =C2=A0 =C2=A0 =C2=A0Network level par= ameters, need to be distributed by GRASP and
>>>>>> ACP
>>>>>>> 2.=C2=A0 =C2=A0 =C2=A0 =C2=A0Relatively static= compared to intent, perhaps only needed to
>>>> be
>>>>>> configured once
>>>>>>> 3.=C2=A0 =C2=A0 =C2=A0 =C2=A0Unavoidable in cu= rrent network environment, mostly for
>>>>>> establishing the network infrastructure
>>>>>>> 4.=C2=A0 =C2=A0 =C2=A0 =C2=A0Rarely need coord= inations with others parameters, usually is
>>>>>> closed related to one specific autonomic function<= br> >>>>>>> Welcome for comment. Your suggestions will be = appreciated.
>>>>>>>
>>>>>>>
>>>>>>> Best Regards
>>>>>>> Zongpeng Du
>>>>>>>
>>>>>>> ______________________________________________= _
>>>>>>> Anima mailing list
>>>>>>> Anima@ietf.o= rg<mailto:Anima@ietf.org> >>>>>>> https://www.ietf.org/mailman= /listinfo/anima
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> regards,
>>>>>>> John
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> regards,
>>>>>>> John
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> regards,
>>>>>>> John
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ______________________________________________= _
>>>>>>> Anima mailing list
>>>>>>> Anima@ietf.o= rg
>>>>>>> https://www.ietf.org/mailman= /listinfo/anima
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>




--
regards,
John
--001a11401f3c99ab8b052f9b92a8-- From nobody Sun Apr 3 16:39:44 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEA812D113 for ; Sun, 3 Apr 2016 16:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 2LkkKZQPjzYE for ; Sun, 3 Apr 2016 16:39:38 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A32112D0DE for ; Sun, 3 Apr 2016 16:39:38 -0700 (PDT) Received: by mail-pa0-x22a.google.com with SMTP id tt10so131074429pab.3 for ; Sun, 03 Apr 2016 16:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=nvQuOXlRuVv9/N5t+e48NxFWGMtiP3aFa9kvo3/4mWg=; b=jwDQcQY2MLXn+vvl2hxGGQG0crLfxdieBwMOpqm5CUr0kKmntzRQCL3RkCo7bebTM3 LBiqigiuaAE42tqj39b8IN/kK03gmyStIEY3+tjAFHy0Iz3P+z240IyhqWFiYUR+UOoP 42rHaaaLNfe0Cljh9yF2CIWY7+Us1HQgHiKJPVHd0e6e+j275Xhf7Ymd2iQT3lNlFeYO WVZ9w30csjxUJnBUSuqKBzRfrnpDasWYfwS0XwWaejY76ZipKD7BO0ke/rjhAC8IehTE f8dwmVBtE/4tcm9fLy40fQEgPclBCXS8QK6B9o8n5LBmhmmpLx2bUza9tVUpuTS/7I2f 5/3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=nvQuOXlRuVv9/N5t+e48NxFWGMtiP3aFa9kvo3/4mWg=; b=KUTreMz8ntKzWSVjlHlJp3auBnvKsf1RhFQE0yOQdRnI9bDBl/X0FIPOL4ge58dv1E TwuLCRFkDK7xscgNV8xedukYf8kHG008ARCR5LkxOZ1YGQwfTDiVdG8+p/JqndLAJOm4 zuJ+I2DmefzZxrScgWjIn11Bd/ReeIX3hD2Rwc4QSrhTTItGUBmP5KbtsoZvKyCY1FiC mtJVfNKim/7bURgypfU9QYNieQXpEwy/NNSCEtCBrpy/EWj43ejWohPp+pdiy/Ze/ha1 QzHzshNM5TB9G+ChunUkfde51+fKbupNmGDTUHWIXmQ8T0M8pJ+og0/d9qowzvf6hWba sLNg== X-Gm-Message-State: AD7BkJJtUk4NtqxYDIwTFb7ojZW4XUvEoyFHlt/wtiUQAeITcY4J0QX7VZhtWvqTQxr4Ew== X-Received: by 10.66.63.7 with SMTP id c7mr48477768pas.104.1459726778088; Sun, 03 Apr 2016 16:39:38 -0700 (PDT) Received: from ?IPv6:2406:e007:483d:1:28cc:dc4c:9703:6781? ([2406:e007:483d:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id r5sm36747038pap.7.2016.04.03.16.39.32 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Apr 2016 16:39:36 -0700 (PDT) To: John Strassner References: <701d351267344c21b3ea053aa5b15728@XCH-RCD-006.cisco.com> <8368235337ea4adfab5c428d57c3bfb2@XCH-RCD-006.cisco.com> <56F60CE4.9040901@gmail.com> <56F6DAA1.8000206@gmail.com> <56F82FDD.7090405@gmail.com> <56FAAD7B.6080305@alcatel-lucent.com> <56FAD79E.2020504@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5701A9B2.1060205@gmail.com> Date: Mon, 4 Apr 2016 11:39:30 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Laurent Ciavaglia , Duzongpeng , "Michael Behringer \(mbehring\)" , =?UTF-8?Q?J=c3=a9ferson_Campos_Nobre?= , "anima@ietf.org" , Sheng Jiang Subject: Re: [Anima] Does Autonomic network need some intervention beyond intent X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 23:39:42 -0000 On 04/04/2016 09:48, John Strassner wrote: > Hi Brian, >=20 > could I request two points of clarification? >=20 >>>> Indeed not. An ASA will have some default behaviour that amounts to > having >>>> default settings for intent, but by definition intent comes from hum= ans. >>>> (One qualification: if the intent that reaches a given node is > inconsistent, >>>> then resolving that inconsistency might be autonomic.) >>> >>> Brian: could you explain what you mean here, especially "resolving th= at > inconsistency might be autonomic"? >>> I guess you mean that ASAs/nodes can autonomously detect inconsistenc= y > in intents and (try to) solve this inconsistency (on >>> their own or via collaboration)...? >=20 >> Yes. Actually if we allow more than one source of intent, this is > essential. >=20 > According to the reference architecture, an Autonomic Function (AF) can= > be made up of one or more ASAs, and each ASA is instantiated on an > autonomic node. The set of AFs reside on the ANI. >=20 > I would prefer that intent is sent to the ASA, not directly to the > (autonomic) node.=20 [I'm going to use ANode to mean an autonomic node, because AN is presumably Autonomic Network.] Well yes, the ANode is just a carrier for information to and from ASAs, but if the Intent is needed by multiple ASAs in one ANode, I expect that it will be cached once in the ANode before being picked up by the individual ASAs. But see my next comment... > This means that the autonomic node has to be able to understand > intent AND understand when intent conflicts, and the Industry has a poo= r > of providing useful support functions. Even with the hype that is IoT, = show > me a vendor that wants to make their phone "intelligent" vs. providing > higher-resolution cameras or more codecs. :-( >=20 > Another consequence is that each ASA has to be able to understand inten= t > AND understand when intent conflicts. OK, I could suppose that we could= > define AFs for this. But AFs are built on the ANI, so does this mean th= at > the ANI has to support intent as well? The draft says: >=20 > The ANI provides functions like naming, addressing, negotiation, > synchronization, discovery and messaging. >=20 > These are all functions that are needed by Intent, but Intent adds thin= gs > that are not needed by the ANI. >=20 >>> Without rewriting history, we are facing now with the "heavy" >>> design/conceptual discussions on the list, the effect of some >>> decisions to exclude architectural analysis / investigations in the >>> early phase of ANIMA... >=20 >> I maintain that these are issues of ASA design, not infrastructure des= ign. >> We always knew that the infrastructure has to distribute Intent. >=20 > I think that the infrastructure has to distribute the **results** of pa= rsing > intent. That is, the parsing is done in a dedicated agent, NOT in an > autonomic node, and the agent transforms Intent to a form that is > generally consumable. This "consumable form" has to be distributed, > but the original intent does not. =2E..OK, terminology interrupt! Clearly what I (and I think others) mean = by Intent is the parsed, consumable intent in your terminology. But if we ad= mit that there may be multiple sources of parsed, consumable intent there may= still be a need for conflict resolution by the consumer, surely? Brian >=20 > regards, > John >=20 > On Tue, Mar 29, 2016 at 12:29 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: >=20 >> Hi Laurent, comments in line: >> On 30/03/2016 05:29, Laurent Ciavaglia wrote: >>> Hello, >>> >>> >>>> Indeed not. An ASA will have some default behaviour that amounts to >> having >>>> default settings for intent, but by definition intent comes from hum= ans. >>>> (One qualification: if the intent that reaches a given node is >> inconsistent, >>>> then resolving that inconsistency might be autonomic.) >>> >>> Brian: could you explain what you mean here, especially "resolving th= at >> inconsistency might be autonomic"? >>> I guess you mean that ASAs/nodes can autonomously detect inconsistenc= y >> in intents and (try to) solve this inconsistency (on >>> their own or via collaboration)...? >> >> Yes. Actually if we allow more than one source of intent, this is >> essential. >> >>> >>>> >>>>>> Of course, when we put Intent into the picture, there's a presumpt= ion >>>>>> that Intent comes from some authority such as a NOC, but that's an= >>>>>> external semantic, not an assumption of the autonomic model. >>>>> Well, no - if the autonomic system is going to use intent, or at le= ast >>>>> respond to it, then it must understand those external semantics. >>>>> This is even more important if the network is supposed to form >>>>> according to one or more intent rules. >>>> Right, but what I meant is that the network will operate perfectly w= ell >>>> if no intent is sent, by using defaults. That will always happen to = the >>>> extent that intent distribution will take a finite time. Until the >> intent >>>> reaches a node, it will operate on defaults. >>> >>> From collaborations with some operators on autonomic networking >> projects: default behavior without policy must equal to "do >>> nothing". But operators' views might change/evolve... >> >> That's certainly a possibility. I'm not sure it is always wise though.= >> For example, if a network is fragmented by a natural disaster, the >> fragments >> might not receive Intent for several days. >> >>> Also, and this is based on feedback from the field (e.g. 3GPP SON), >> turning on autonomic functions, even with well-thought >>> parameter settings, turns out most of the times in chaotic behaviors = and >> severe performance degradations. >>> A key element to consider here is how to "gracefully" start/ramp-up a= n >> autonomic network and aspects of coordination (cf >>> draft-ciavaglia-anima-coordination-01). >> >> Agreed. Obviously the defaults must be conservative and fail-safe. >> >>> >>>> Of course, the semantics of >>>> intent must be well-defined, but it's an extra layer. >>>> >>>>> If intent is formulated at an abstract level, how is an autonomic >>>>> network going to consume intent that may have drastically different= >>>>> syntactical structures, and likely, different semantics associated = with >>>>> those syntactical structures? >>>> Agreed. We need a model, syntax and semantics. >>>> >>>>>> I think the point is that AN *adds* a new mode of communication >>>>>> between self-managing nodes, that doesn't exist in a strictly >>>>>> north/south scenario. That is meant to reduce the amount of >>>>>> north/south communication and reduce the amount of >>>>>> centralized work. So there's a trade-off - more autonomic >>>>>> messaging means less north-south messaging. >>> >>> north-south is a matter of convention / roles. >>> if we consider PBM / intent, for me it implies a "vertical" (authorit= y) >> relationship. >>> if we consider a more "flat" system of collaborative entities, then >> let's have a look at MAS / DAI approaches and not reinvent >>> (a squarred) wheel. >>> we may end up pushing more or less intelligence in the autonomic >> functions, but we also consider the scope of ANIMA to address >>> "managed" networks (maybe not only this one), so it means some operat= ors >> will expect certain behavior/performance from the >>> neworks. Intent is one way to inform the network what is expected. >> >> Sure. But always remember the disaster-recovery scenario where we are >> forced >> back to defaults. >> >>> >>>>> There may indeed be a new mode of communication required. >>>>> However, if intent is not standardized, how does this work? >>>> It doesn't. My only point is that intent is layered on top of an >>>> underlying autonomic behaviour based on default behaviours. Actually= , >>>> that's why the question of intent was deferred in the WG charter. >>> >>> Your explanation is "valid", but I don't remember this was the reason= >> used to consider intent FFS. >> >> OK, maybe that was just in my brain. Another aspect that Intent was >> incompletely >> understood. >> >>> Without rewriting history, we are facing now with the "heavy" >> design/conceptual discussions on the list, the effect of some >>> decisions to exclude architectural analysis / investigations in the >> early phase of ANIMA... >> >> I maintain that these are issues of ASA design, not infrastructure des= ign. >> We always >> knew that the infrastructure has to distribute Intent. >> >> Regards >> Brian >> >>> Laurent. >>> >>> >>>> >>>> Brian >>>> >>>>> I understand how unstructured and structured P2P networks >>>>> work. Let's assume this is a structured P2P network. In that case, >>>>> a DHT is used to assign ownership of each file to a peer. I fail to= >>>>> understand how this works in an intent case. Files are passive, >>>>> intent is active. Please explain. >>>>> >>>>> Regards, >>>>> John >>>>> >>>>> On Sat, Mar 26, 2016 at 11:53 AM, Brian E Carpenter < >>>>> brian.e.carpenter@gmail.com> wrote: >>>>> >>>>>> Hi John, >>>>>> On 27/03/2016 04:54, John Strassner wrote: >>>>>>>> Correct, and there is also no presumption that individual nodes >>>>>>>> have perfect knowledge of the topology. Of course the ACP >>>>>>>> routing protocol will have perfect knowledge of the ACP topology= , >>>>>>>> but individual ASAs only know what they have gleaned from >>>>>>>> discovery and what they have been told by Intent. >>>>>>>> >>>>>>>> It is, I think, a very different world view than the SDN or SUPA= or >>>>>>>> NVO4 or NFV view. >>>>>>> Please note that I did NOT say anything about SDN, NFV, or SUPA >>>>>>> here. In fact, I'm confused as to why you both think I did. >>>>>> I can't speak for Zongpeng, but I was triggered by the mention of >>>>>> northbound and southbound APIs. There is no presumed direction in >>>>>> Anima relationships, since in the limit a network is self-forming;= >>>>>> all relationships are peer-to-peer. >>>>>> >>>>>> Of course, when we put Intent into the picture, there's a presumpt= ion >>>>>> that Intent comes from some authority such as a NOC, but that's an= >>>>>> external semantic, not an assumption of the autonomic model. >>>>>> >>>>>>> I specifically said "There are plenty of southbound APIs (from a >>>>>>> management function to a device). There are very few northbound >> APIs." >>>>>>> >>>>>>> Note the word "management function". >>>>>>> >>>>>>> For the record, I don't think that either Phase 2 of NFV or the S= DN >> 1.1 >>>>>>> architecture have treated policy in any detail. Both architecture= s >> lack a >>>>>>> policy management component. I hope that ANIMA doesn't make the >>>>>>> same mistake. >>>>>> Certainly, Intent needs a number of properties such as >> self-consistency >>>>>> and stability that imply it is managed in some way. >>>>>> >>>>>>>>> However, in ANIMA network, perhaps we do not have a centralized= >>>>>>>>> parsing node (controller), which can replace almost all the >>>>>>>>> communications between nodes. >>>>>>> Earlier I wrote about intent requiring a translation function. I >> never >>>>>> said >>>>>>> that it was centralized or distributed. In the autonomic >> architectures I >>>>>>> have built, it was in fact a decentralized (agent-driven) functio= n. >>>>>>> Furthermore, it did not "replace almost all the communications" -= it >>>>>>> was used for compilation. There was, in fact, a separate distribu= tion >>>>>>> mechanism (which I have also described), but that was limited to >>>>>>> "just" distribution. >>>>>>> >>>>>>> I really don't understand what "replacing communications" means. >>>>>> I think the point is that AN *adds* a new mode of communication >> between >>>>>> self-managing nodes, that doesn't exist in a strictly north/south >>>>>> scenario. That is meant to reduce the amount of north/south >> communication >>>>>> and reduce the amount of centralized work. So there's a trade-off = - >>>>>> more autonomic messaging means less north-south messaging. >>>>>> >>>>>> Best regards >>>>>> Brian >>>>>> >>>>>>> regards, >>>>>>> John >>>>>>> >>>>>>> On Fri, Mar 25, 2016 at 9:15 PM, Brian E Carpenter < >>>>>>> brian.e.carpenter@gmail.com> wrote: >>>>>>> >>>>>>>>> However, in ANIMA network, perhaps we do not have a centralized= >> parsing >>>>>>>> node (controller), which can replace almost all the communicatio= ns >>>>>> between >>>>>>>> nodes. >>>>>>>> >>>>>>>> Correct, and there is also no presumption that individual nodes = have >>>>>>>> perfect >>>>>>>> knowledge of the topology. Of course the ACP routing protocol wi= ll >> have >>>>>>>> perfect >>>>>>>> knowledge of the ACP topology, but individual ASAs only know wha= t >> they >>>>>> have >>>>>>>> gleaned from discovery and what they have been told by Intent. >>>>>>>> >>>>>>>> It is, I think, a very different world view than the SDN or SUPA= or >> NVO4 >>>>>>>> or NFV view. >>>>>>>> >>>>>>>> Regards >>>>>>>> Brian >>>>>>>> >>>>>>>> On 26/03/2016 16:46, Duzongpeng wrote: >>>>>>>>> Hi John: >>>>>>>>> >>>>>>>>> Thanks for your reply. >>>>>>>>> >>>>>>>>> >>>>>>>>> How is this different than running a script, or invoking an API= ? >> There >>>>>>>> are plenty of southbound APIs (from a management function to a >> device). >>>>>>>> There are very few northbound APIs. That's what the operators th= at I >>>>>> have >>>>>>>> talked to want. >>>>>>>>> >>>>>>>>> >>>>>>>>> I agree that intent belongs to northbound interface in the SDN >> network. >>>>>>>> And ANIMA network perhaps can share the same northbound interfac= e. >>>>>>>>> But, my understanding is that ANIMA network is a little differe= nt >> from >>>>>>>> SDN network. >>>>>>>>> SDN controller will parse the intent, and transform to detailed= >>>>>>>> configurations of every device. It is a good model, and little >>>>>>>> communications between nodes are needed. >>>>>>>>> Some network level parameters can be handled in SDN controller.= >>>>>>>>> >>>>>>>>> However, in ANIMA network, perhaps we do not have a centralized= >> parsing >>>>>>>> node (controller), which can replace almost all the communicatio= ns >>>>>> between >>>>>>>> nodes. >>>>>>>>> So when a network operator is operating a ANIMA network, the >> network >>>>>>>> level parameters are still needed to be flooded. >>>>>>>>> I mean the ANIMA interface is perhaps something like =E2=80=9Cn= orthbound + >> part >>>>>>>> of southbound=E2=80=9D. >>>>>>>>> Best Regards >>>>>>>>> Zongpeng Du >>>>>>>>> >>>>>>>>> >>>>>>>>> From: John Strassner [mailto:strazpdj@gmail.com] >>>>>>>>> Sent: Saturday, March 26, 2016 9:41 AM >>>>>>>>> To: Duzongpeng; John Strassner >>>>>>>>> Cc: Michael Behringer (mbehring); Laurent Ciavaglia; Sheng Jian= g; >>>>>>>> anima@ietf.org; J=C3=A9ferson Campos Nobre >>>>>>>>> Subject: Re: [Anima] Does Autonomic network need some intervent= ion >>>>>>>> beyond intent >>>>>>>>> Hi Zongpeng, >>>>>>>>> >>>>>>>>> I think we have a misunderstanding here. >>>>>>>>> >>>>>>>>> >>>>>>>>> But I do not support that the intent writer should look every >> detail in >>>>>>>> the catalog. >>>>>>>>> >>>>>>>>> Most catalogs that I have seen have very few details. They inst= ead >> tell >>>>>>>> the user what services or products are available. >>>>>>>>> >>>>>>>>> >>>>>>>>> The intent writer may mainly care about what they want, but how= to >> do >>>>>> it >>>>>>>> can be left to the autonomic network to deal with. >>>>>>>>> >>>>>>>>> I agree completely. >>>>>>>>> >>>>>>>>> >>>>>>>>> Perhaps several solutions exist, and autonomic management syste= m >> choose >>>>>>>> one according to the abilities collected. >>>>>>>>> >>>>>>>>> This is one of the reasons why I would like to see capabilities= >> (and >>>>>>>> needs) advertised. >>>>>>>>> >>>>>>>>> >>>>>>>>> ... >>>>>>>>> I mean in current status, some of the Autonomic Functions shoul= d be >>>>>>>> exposed to the network operator, and some of the Autonomic Funct= ions >>>>>> can be >>>>>>>> hidden to the network operator >>>>>>>>> ... >>>>>>>>> >>>>>>>>> How is this different than running a script, or invoking an API= ? >> There >>>>>>>> are plenty of southbound APIs (from a management function to a >> device). >>>>>>>> There are very few northbound APIs. That's what the operators th= at I >>>>>> have >>>>>>>> talked to want. >>>>>>>>> regards, >>>>>>>>> John >>>>>>>>> >>>>>>>>> On Fri, Mar 25, 2016 at 2:31 AM, Duzongpeng >>>>>>> > wrote: >>>>>>>>> Hi John >>>>>>>>> >>>>>>>>> Some personal understanding here. If any misunderstanding, plea= se >>>>>>>> correct me. Thanks. >>>>>>>>> >>>>>>>>> I would suggest a slight modification, to enable users of >>>>>>>>> intent (and even intent writers) to NOT have to have >>>>>>>>> detailed implementation information. >>>>>>>>> >>>>>>>>> What if all of the Autonomic Functions, after they joined >>>>>>>>> the network, advertised both their capabilities as well as >>>>>>>>> their needs? We can put aside the latter (needs) as this >>>>>>>>> is more complex, but if the capabilities are advertised, >>>>>>>>> then the autonomic management system can assemble >>>>>>>>> those needs into a catalog. Then, the intent writer can >>>>>>>>> look at the catalog and write a declarative request to >>>>>>>>> use the functionality of the catalog. >>>>>>>>> >>>>>>>>> I will look at your YANG model in a bit (sorry, I'm woefully >>>>>>>>> behind...). >>>>>>>>> < /jcs2> >>>>>>>>> >>>>>>>>> I agree that autonomic node should have that self-advertisement= >>>>>> ability, >>>>>>>> and autonomic management system should have this catalog. >>>>>>>>> But I do not support that the intent writer should look every >> detail in >>>>>>>> the catalog. >>>>>>>>> The intent writer may mainly care about what they want, but how= to >> do >>>>>> it >>>>>>>> can be left to the autonomic network to deal with. >>>>>>>>> Perhaps several solutions exist, and autonomic management syste= m >> choose >>>>>>>> one according to the abilities collected. >>>>>>>>> In the ideal, the network operator may communicate with the >> autonomic >>>>>>>> network using network-level level intent and network-level repor= t. >>>>>>>>> I mean in current status, some of the Autonomic Functions shoul= d be >>>>>>>> exposed to the network operator, and some of the Autonomic Funct= ions >>>>>> can be >>>>>>>> hidden to the network operator >>>>>>>>> Perhaps in future, when the network nodes become more intellige= nt, >> the >>>>>>>> hidden part will increase. >>>>>>>>> >>>>>>>>> Best regards >>>>>>>>> Zongpeng Du >>>>>>>>> >>>>>>>>> From: Anima [mailto:anima-bounces@ietf.org>>>>> anima-bounces@ietf.org>] >>>>>>>> On Behalf Of John Strassner >>>>>>>>> Sent: Thursday, March 24, 2016 10:41 AM >>>>>>>>> To: Michael Behringer (mbehring); John Strassner >>>>>>>>> Cc: Duzongpeng; Laurent Ciavaglia; Sheng Jiang; anima@ietf.org >> >>>>>>> anima@ietf.org>; J=C3=A9ferson Campos Nobre >>>>>>>>> Subject: Re: [Anima] Does Autonomic network need some intervent= ion >>>>>>>> beyond intent >>>>>>>>> Hi Michael, >>>>>>>>> >>>>>>>>> thanks for your reply. I do think that we largely agree, and wo= uld >>>>>> enjoy >>>>>>>> chatting during or (hopefully before) BA. Please see >> ... >>>>>> Also >>>>>>>> trying to unclutter, so I am eliding points that we agree on. >>>>>>>>> >>>>>>>>> While *CIEs don=E2=80=99t like magic, they do understand the co= ncept of a >>>>>>>> default behaviour which they can influence if needed. Any reason= able >>>>>>>> network management approach tries to define =E2=80=9Cdefault=E2=80= =9D behaviour and >>>>>>>> =E2=80=9Cexceptions=E2=80=9D. The AN story fills the =E2=80=9Cde= fault=E2=80=9D part very nicely, and >>>>>> *CIEs >>>>>>>> get that. >>>>>>>>> >>>>>>>>> Agreed! >>>>>>>>> >>>>>>>>> >>>>>>>>> The =E2=80=9Cparameter=E2=80=9D versus =E2=80=9Cpolicy=E2=80=9D= discussion: My view is that we >>>>>> shouldn=E2=80=99t >>>>>>>> try to define exactly *what* intent allows and doesn=E2=80=99t a= llow, since >>>>>> we=E2=80=99ve >>>>>>>> heard from many sides that the boundary is not clear, and it may= be >>>>>>>> impossible to have a really clear, usable definition. So my poin= t >> was: >>>>>>>> Let=E2=80=99s focus on the distribution model: Intent is flooded= to all >> nodes. >>>>>>>> Let=E2=80=99s NOT do selective flooding, unicast Intent to speci= fic nodes, >> etc, >>>>>>>> because that would blur the boundary even worse. >>>>>>>>> >>>>>>>>> I like flooding intent to all nodes. In FOCALE (v1-3, and >> remember, v1 >>>>>>>> was 2006, almost 10 years ago), we used a message bus and pub-su= b. >> In >>>>>> v2, >>>>>>>> we flooded; in v3, we went back to pub-sub because we wanted to = do >> some >>>>>>>> optimization and auditing. But I would be happy to try some type= of >>>>>>>> controlled flooding again. >>>>>>>>> >>>>>>>>> My suggestion: Intent is flooded to all nodes in a domain. The = ASA >>>>>>>> owners define the content of what they want to push in their bit= of >> the >>>>>>>> Intent. If we insist of full flooding, we encourage the right >> behaviour. >>>>>>>> And if someone really puts into his Intent =E2=80=9Cnode A: do t= his; node >> B: do >>>>>> the >>>>>>>> other; node C: do the third=E2=80=9D it is awkward enough for pe= ople to >> take a >>>>>> step >>>>>>>> back and think whether they=E2=80=99re doing the right thing =E2= =98=BA >>>>>>>>> >>>>>>>>> I agree in principle with what you said. Plus, see above. >>>>>>>>> < /jcs2> >>>>>>>>> >>>>>>>>> Do you mean that the intent writer will **know the difference**= >>>>>>>>> between the fabric and each autonomic function? I hope not, >>>>>>>>> but perhaps I'm misunderstanding you... >>>>>>>>> < /jcs> >>>>>>>>> Not sure I understand your concern. Yes, in my model there is a= >> section >>>>>>>> for the fabric, and sections for the various functions. Seems a >> natural >>>>>>>> structure?!? >>>>>>>>> The intent **writer** would have to know implementation >>>>>>>>> details in order to place everything in a single file. I would >>>>>>>>> rather not require this, and instead, have the intent engine >>>>>>>>> (e.g., compiler and associated logic) do this. >>>>>>>>> < /jcs2> >>>>>>>>> =E2=80=9CFunction owner=E2=80=9D: Yes, I=E2=80=99m suggesting t= o structure Intent around >>>>>>>> Autonomic Functions. This is not optimal from a scientific point= of >>>>>> view, >>>>>>>> but aligns very well with the way how things are organised. >> Probably we >>>>>>>> need to discuss that in BA. But refer to my YANG model sent a fe= w >> days >>>>>> ago. >>>>>>>>> >>>>>>>>> I would suggest a slight modification, to enable users of >>>>>>>>> intent (and even intent writers) to NOT have to have >>>>>>>>> detailed implementation information. >>>>>>>>> >>>>>>>>> What if all of the Autonomic Functions, after they joined >>>>>>>>> the network, advertised both their capabilities as well as >>>>>>>>> their needs? We can put aside the latter (needs) as this >>>>>>>>> is more complex, but if the capabilities are advertised, >>>>>>>>> then the autonomic management system can assemble >>>>>>>>> those needs into a catalog. Then, the intent writer can >>>>>>>>> look at the catalog and write a declarative request to >>>>>>>>> use the functionality of the catalog. >>>>>>>>> >>>>>>>>> I will look at your YANG model in a bit (sorry, I'm woefully >>>>>>>>> behind...). >>>>>>>>> < /jcs2> >>>>>>>>> >>>>>>>>> >>>>>>>>> regards, >>>>>>>>> John >>>>>>>>> >>>>>>>>> On Wed, Mar 23, 2016 at 3:57 AM, Michael Behringer (mbehring) <= >>>>>>>> mbehring@cisco.com> wrote: >>>>>>>>> John, >>>>>>>>> >>>>>>>>> I think we=E2=80=99re on the same page. Couple of points, top p= osting here, >>>>>>>> otherwise it gets too messy. >>>>>>>>> While *CIEs don=E2=80=99t like magic, they do understand the co= ncept of a >>>>>>>> default behaviour which they can influence if needed. Any reason= able >>>>>>>> network management approach tries to define =E2=80=9Cdefault=E2=80= =9D behaviour and >>>>>>>> =E2=80=9Cexceptions=E2=80=9D. The AN story fills the =E2=80=9Cde= fault=E2=80=9D part very nicely, and >>>>>> *CIEs >>>>>>>> get that. >>>>>>>>> The =E2=80=9Cparameter=E2=80=9D versus =E2=80=9Cpolicy=E2=80=9D= discussion: My view is that we >>>>>> shouldn=E2=80=99t >>>>>>>> try to define exactly *what* intent allows and doesn=E2=80=99t a= llow, since >>>>>> we=E2=80=99ve >>>>>>>> heard from many sides that the boundary is not clear, and it may= be >>>>>>>> impossible to have a really clear, usable definition. So my poin= t >> was: >>>>>>>> Let=E2=80=99s focus on the distribution model: Intent is flooded= to all >> nodes. >>>>>>>> Let=E2=80=99s NOT do selective flooding, unicast Intent to speci= fic nodes, >> etc, >>>>>>>> because that would blur the boundary even worse. >>>>>>>>> My suggestion: Intent is flooded to all nodes in a domain. The = ASA >>>>>>>> owners define the content of what they want to push in their bit= of >> the >>>>>>>> Intent. If we insist of full flooding, we encourage the right >> behaviour. >>>>>>>> And if someone really puts into his Intent =E2=80=9Cnode A: do t= his; node >> B: do >>>>>> the >>>>>>>> other; node C: do the third=E2=80=9D it is awkward enough for pe= ople to >> take a >>>>>> step >>>>>>>> back and think whether they=E2=80=99re doing the right thing =E2= =98=BA >>>>>>>>> >>>>>>>>> Do you mean that the intent writer will **know the difference**= >>>>>>>>> between the fabric and each autonomic function? I hope not, >>>>>>>>> but perhaps I'm misunderstanding you... >>>>>>>>> >>>>>>>>> >>>>>>>>> Not sure I understand your concern. Yes, in my model there is a= >> section >>>>>>>> for the fabric, and sections for the various functions. Seems a >> natural >>>>>>>> structure?!? >>>>>>>>> =E2=80=9CFunction owner=E2=80=9D: Yes, I=E2=80=99m suggesting t= o structure Intent around >>>>>>>> Autonomic Functions. This is not optimal from a scientific point= of >>>>>> view, >>>>>>>> but aligns very well with the way how things are organised. >> Probably we >>>>>>>> need to discuss that in BA. But refer to my YANG model sent a fe= w >> days >>>>>> ago. >>>>>>>>> We should schedule some discussion time outside the ANIMA meeti= ng >>>>>>>> window... >>>>>>>>> Michael >>>>>>>>> >>>>>>>>> >>>>>>>>> From: John Strassner [mailto:strazpdj@gmail.com>>>>>>> strazpdj@gmail.com>] >>>>>>>>> Sent: 22 March 2016 21:32 >>>>>>>>> To: Michael Behringer (mbehring) >>>>>>> mbehring@cisco.com>>; John Strassner >>>>>>> strazpdj@gmail.com>> >>>>>>>>> Cc: Duzongpeng >>> ; >>>>>>>> anima@ietf.org; Laurent Ciavaglia < >>>>>>>> laurent.ciavaglia@nokia.com>= ; >>>>>>>> J=C3=A9ferson Campos Nobre > jcnobre@inf.ufrgs.br >>>>>>>> ; >>>>>>>> Sheng Jiang = > >>>>>>>>> Subject: Re: [Anima] Does Autonomic network need some intervent= ion >>>>>>>> beyond intent >>>>>>>>> In general, I agree with Michael. I'd like to emphasize and exp= and >> on a >>>>>>>> couple of key points: >>>>>>>>> >>>>>>>>> First, ANIMA isn=E2=80=99t the only thing =E2=80=9Cinfluencing=E2= =80=9D or =E2=80=9Csteering=E2=80=9D a >>>>>> network, >>>>>>>> at least not initially. There is still traditional config, plus = all >> the >>>>>>>> existing and emerging SDN models. My view has always been that A= NIMA >>>>>> sets a >>>>>>>> =E2=80=9Cdefault=E2=80=9D policy in a network, and all other mea= ns are more >> specific and >>>>>>>> can override intent. This is described in RFC7575. Main point he= re: >>>>>> ANIMA >>>>>>>> Intent isn=E2=80=99t the only tool in a network. >>>>>>>>> >>>>>>>>> Absolutely agree. Note that even in the Congress case I mention= ed >>>>>>>>> earlier, it is NOT pushing config, and it is NOT viewed as the >>>>>>>>> "only" policy >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Intent could perfectly well cover a high level policy such as =E2= =80=9Call >>>>>> nodes >>>>>>>> of type x do this; type y does that=E2=80=9D. (Which I think is = what you >> mention >>>>>>>> below.) When we started with Intent, the vision was to keep it v= ery >> high >>>>>>>> level, more along the line =E2=80=9Cdo the right thing=E2=80=9D = =E2=98=BA >>>>>>>>> >>>>>>>>> Agreed. Although to me, this means that we need to consider the= >> types >>>>>> of >>>>>>>> actors that are using intent. For example, most of my CCIE and J= CIE >>>>>> friends >>>>>>>> have no interest in using an intent language for pushing >> configuration. >>>>>> On >>>>>>>> the other hand, when I talk to operators and application develop= ers, >>>>>> they >>>>>>>> would love to be able to use a high-level intent and have the in= tent >>>>>> engine >>>>>>>> take care of the details for them. >>>>>>>>> >>>>>>>>> >>>>>>>>> It has become clear that in today=E2=80=99s networking, people = will want to >>>>>> push >>>>>>>> more =E2=80=9Cparameters=E2=80=9D than =E2=80=9Cpolicy=E2=80=9D,= and I think we=E2=80=99ll just have to >>>>>> acknowledge >>>>>>>> that. >>>>>>>>> >>>>>>>>> Sorry Michael, I don't follow here. What do you mean >>>>>>>>> by "parameters"? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Personally I think it=E2=80=99ll pan out like this: Intent will= have >> sections >>>>>>>> per autonomic function. An Intent parser will validate overall >>>>>> correctness >>>>>>>> (signature, etc), then segment the Intent into its bits: One par= t >> will >>>>>> be >>>>>>>> the autonomic fabric itself, then there will be bits for each >> autonomic >>>>>>>> function. >>>>>>>>> >>>>>>>>> Do you mean that the intent writer will **know the difference**= >>>>>>>>> between the fabric and each autonomic function? I hope not, >>>>>>>>> but perhaps I'm misunderstanding you... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> So the Intent parser on a node will grab intent, see there is s= ome >>>>>>>> Intent for autonomic function A, will see whether this is runnin= g >>>>>> locally, >>>>>>>> and if so, it=E2=80=99ll just pass that piece of Intent to that = function. >>>>>>>>> >>>>>>>>> Agreed. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> In this way, a function owner defines both the intent itself, a= nd >> how >>>>>> it >>>>>>>> is consumed by his/her function. >>>>>>>>> >>>>>>>>> I'm not sure what you mean by "function owner". (Sorry to be >>>>>>>>> picky, I'm likely under-caffeinated.) >>>>>>>>> >>>>>>>>> The above seemed like an autonomous decision, made by the parse= r. >>>>>>>>> I don't think that the intent writer should be cognizant of how= >> many or >>>>>>>>> what types of autonomic functions are present. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The downside is that there is no =E2=80=9Ccontrol=E2=80=9D and = people can do what >> they >>>>>>>> want, in the worst case even push config, which is clearly NOT w= hat >>>>>> Intent >>>>>>>> is meant to do. >>>>>>>>> >>>>>>>>> And hence, the "HAL 2000" scenario. :-) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I=E2=80=99d hope that people don=E2=80=99t start writing Intent= like =E2=80=9Cnode 17: >> here is >>>>>>>> your CLI; node 23: here is your CLI=E2=80=9D; node 37: here is y= our CLI=E2=80=9D. >> But >>>>>> what >>>>>>>> I describe above COULD be abused in this way. RFC7575 says this = is >> NOT >>>>>>>> Intent. >>>>>>>>> >>>>>>>>> Absolutely agree! >>>>>>>>> >>>>>>>>> >>>>>>>>> regards, >>>>>>>>> John >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Mar 16, 2016 at 1:16 AM, Michael Behringer (mbehring) <= >>>>>>>> mbehring@cisco.com> wrote: >>>>>>>>> Hi Zongpeng, >>>>>>>>> >>>>>>>>> Yes, this is a recurring question and topic. Let me give my vie= w >> on two >>>>>>>> levels: >>>>>>>>> First, ANIMA isn=E2=80=99t the only thing =E2=80=9Cinfluencing=E2= =80=9D or =E2=80=9Csteering=E2=80=9D a >>>>>> network, >>>>>>>> at least not initially. There is still traditional config, plus = all >> the >>>>>>>> existing and emerging SDN models. My view has always been that A= NIMA >>>>>> sets a >>>>>>>> =E2=80=9Cdefault=E2=80=9D policy in a network, and all other mea= ns are more >> specific and >>>>>>>> can override intent. This is described in RFC7575. Main point he= re: >>>>>> ANIMA >>>>>>>> Intent isn=E2=80=99t the only tool in a network. >>>>>>>>> Intent could perfectly well cover a high level policy such as =E2= =80=9Call >>>>>> nodes >>>>>>>> of type x do this; type y does that=E2=80=9D. (Which I think is = what you >> mention >>>>>>>> below.) When we started with Intent, the vision was to keep it v= ery >> high >>>>>>>> level, more along the line =E2=80=9Cdo the right thing=E2=80=9D = =E2=98=BA It has become >> clear >>>>>> that >>>>>>>> in today=E2=80=99s networking, people will want to push more =E2= =80=9Cparameters=E2=80=9D >> than >>>>>>>> =E2=80=9Cpolicy=E2=80=9D, and I think we=E2=80=99ll just have to= acknowledge that. >>>>>>>>> Personally I think it=E2=80=99ll pan out like this: Intent will= have >> sections >>>>>>>> per autonomic function. An Intent parser will validate overall >>>>>> correctness >>>>>>>> (signature, etc), then segment the Intent into its bits: One par= t >> will >>>>>> be >>>>>>>> the autonomic fabric itself, then there will be bits for each >> autonomic >>>>>>>> function. >>>>>>>>> So the Intent parser on a node will grab intent, see there is s= ome >>>>>>>> Intent for autonomic function A, will see whether this is runnin= g >>>>>> locally, >>>>>>>> and if so, it=E2=80=99ll just pass that piece of Intent to that = function. >>>>>>>>> In this way, a function owner defines both the intent itself, a= nd >> how >>>>>> it >>>>>>>> is consumed by his/her function. >>>>>>>>> The downside is that there is no =E2=80=9Ccontrol=E2=80=9D and = people can do what >> they >>>>>>>> want, in the worst case even push config, which is clearly NOT w= hat >>>>>> Intent >>>>>>>> is meant to do. I=E2=80=99d hope that people don=E2=80=99t start= writing Intent like >>>>>> =E2=80=9Cnode >>>>>>>> 17: here is your CLI; node 23: here is your CLI=E2=80=9D; node 3= 7: here is >> your >>>>>>>> CLI=E2=80=9D. But what I describe above COULD be abused in this = way. RFC7575 >>>>>> says >>>>>>>> this is NOT Intent. >>>>>>>>> In other words: Let=E2=80=99s not be too prescriptive, and hope= that folks >> will >>>>>>>> do more or less reasonable things. >>>>>>>>> I=E2=80=99ve been meaning to comment on the Intent drafts and p= ossibly >>>>>>>> contribute, I=E2=80=99m just struggling with priorities at the m= oment (as >> you >>>>>> can >>>>>>>> see by my relative silence over the past weeks). >>>>>>>>> Michael >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> From: Anima [mailto:anima-bounces@ietf.org>>>>> anima-bounces@ietf.org>] >>>>>>>> On Behalf Of Duzongpeng >>>>>>>>> Sent: 16 March 2016 02:38 >>>>>>>>> To: anima@ietf.org >>>>>>>>> Cc: Laurent Ciavaglia >>>>>>> laurent.ciavaglia@nokia.com>>; J=C3=A9ferson Campos Nobre < >>>>>> jcnobre@inf.ufrgs.br >>>>>>>> >; Sheng Jiang >>>>> >>>>>>> jiangsheng@huawei.com>> >>>>>>>>> Subject: [Anima] Does Autonomic network need some intervention >> beyond >>>>>>>> intent >>>>>>>>> Hello, everyone >>>>>>>>> >>>>>>>>> I understand that Autonomic network should be able to= >> work >>>>>> with >>>>>>>> as less configuration as possible. In the ideal case, an Autonom= ic >>>>>> network >>>>>>>> should be able to work well while only intent is needed from hum= an >>>>>>>> operators. >>>>>>>>> However, I wonder whether Autonomic network may need = some >>>>>>>> intervention from human operators through some low-level policie= s >> beyond >>>>>>>> intents. >>>>>>>>> For example, in the >>>>>>>> https://tools.ietf.org/html/draft-ietf-anima-prefix-management-0= 0, >> it >>>>>> is >>>>>>>> suggested that the prefix lengths for the CSG, ASG, RSG (differe= nt >>>>>> roles in >>>>>>>> IP RAN) can be assigned as an "intent". These configuration >> parameters >>>>>> need >>>>>>>> to be distributed in the autonomic domain to influence the detai= l >>>>>>>> configurations on each autonomic node. >>>>>>>>> As intent is described as an abstract, declarative, >> high-level >>>>>>>> policy used to operate an autonomic domain, such as an enterpris= e >>>>>> network. >>>>>>>> Perhaps we can rename the =E2=80=9Cintent=E2=80=9D in the =E2=80= =9Cprefix-management ID=E2=80=9D to >> some >>>>>>>> other words. >>>>>>>>> Is =E2=80=9CASA parameters" ok here? >>>>>>>>> >>>>>>>>> I think some characteristics for this kind of low-level policie= s >> are >>>>>>>>> >>>>>>>>> 1. Network level parameters, need to be distributed by GR= ASP >> and >>>>>>>> ACP >>>>>>>>> 2. Relatively static compared to intent, perhaps only nee= ded >> to >>>>>> be >>>>>>>> configured once >>>>>>>>> 3. Unavoidable in current network environment, mostly for= >>>>>>>> establishing the network infrastructure >>>>>>>>> 4. Rarely need coordinations with others parameters, usua= lly >> is >>>>>>>> closed related to one specific autonomic function >>>>>>>>> Welcome for comment. Your suggestions will be appreciated. >>>>>>>>> >>>>>>>>> >>>>>>>>> Best Regards >>>>>>>>> Zongpeng Du >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Anima mailing list >>>>>>>>> Anima@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/anima >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> regards, >>>>>>>>> John >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> regards, >>>>>>>>> John >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> regards, >>>>>>>>> John >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Anima mailing list >>>>>>>>> Anima@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/anima >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> >=20 >=20 From nobody Sun Apr 3 20:01:13 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7509312D118 for ; Sun, 3 Apr 2016 20:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 dbZ0ov5cK6HA for ; Sun, 3 Apr 2016 20:01:06 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E63D112D153 for ; Sun, 3 Apr 2016 20:01:05 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id g184so74601893lfb.3 for ; Sun, 03 Apr 2016 20:01:05 -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; bh=k816hBPSINJSNaK/VMX8ar4ukvf2rmQEqNzq56dutWc=; b=CJ4VMaBG3bBU5IB9YQVs71rBIGvEa05f9HTeDEAgfGLEYBFDb+J/EkANKB9Dtdhwd3 EDuTODUrh2UgOm6HSHD5bd6oRLvKOOtefMaAxiR3gLEgyyVcmarrM7QxNdiQu0KRVVZ5 9f1ORAu5NUaj4bxmORmtGL2LhJnMw3e7Yq9hgI5tJRk42Frv9OVExziorNfyEaLS8ls+ cXkUEDaAwP7B9EpdOkFCmWISKzFjcrIVqsgHe/m8mrb8hFaT943Ush2LvjdB//JBKlLH 5OU0n8bPJOAZc3lqPU4XpWw9EwIrwluZhCHo+E9o6A9SbpajKvuMUFCnkfYRtY7f+FPM A8Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=k816hBPSINJSNaK/VMX8ar4ukvf2rmQEqNzq56dutWc=; b=UPnpFCH4jcV6eYQWKlBtVoJQPQl28DTbiOWHMCmCHFFCAsR5YAxETd9XadRzFGrS81 l8SRiBJyB2l4rjKBDwTV+IgHgQia522LpqVQ1Y9h/mQHu7ivj6kDMznC9ahJqKks2NIg HP+D40pEJJJSL03MwgWOgESamIt5I/Ntq0SfuG+Xc4RQXv1KhlBrMeQUS6ZtF0HyN6sM hHSOLjhoGGHArAyGQT3ZIM+euKLdnI3eqknezSkPRwodXindZGY4Z264bOIWHZu6TfLW OOyf3fRjcBIrCnVXTuXN0+zpY88GzDQD6nH/scMLV6V1mFcXjVKRIbYX/5HpYTRkBV+A GnQA== X-Gm-Message-State: AD7BkJJEk6bEZjr2iqgucSse9idru0Hxbyz9ET/lezmIzn9ezv8maamEgadVbnzpPJ/ksQ0HnNxCtEPROwR/ug== MIME-Version: 1.0 X-Received: by 10.25.218.196 with SMTP id r187mr7075161lfg.6.1459738862173; Sun, 03 Apr 2016 20:01:02 -0700 (PDT) Received: by 10.25.22.19 with HTTP; Sun, 3 Apr 2016 20:01:01 -0700 (PDT) In-Reply-To: <5701A9B2.1060205@gmail.com> References: <701d351267344c21b3ea053aa5b15728@XCH-RCD-006.cisco.com> <8368235337ea4adfab5c428d57c3bfb2@XCH-RCD-006.cisco.com> <56F60CE4.9040901@gmail.com> <56F6DAA1.8000206@gmail.com> <56F82FDD.7090405@gmail.com> <56FAAD7B.6080305@alcatel-lucent.com> <56FAD79E.2020504@gmail.com> <5701A9B2.1060205@gmail.com> Date: Sun, 3 Apr 2016 20:01:01 -0700 Message-ID: From: John Strassner To: Brian E Carpenter , John Strassner Content-Type: multipart/alternative; boundary=001a11401f3c584374052f9ff0c9 Archived-At: Cc: Laurent Ciavaglia , Duzongpeng , "Michael Behringer \(mbehring\)" , =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= , "anima@ietf.org" , Sheng Jiang Subject: Re: [Anima] Does Autonomic network need some intervention beyond intent X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 03:01:11 -0000 --001a11401f3c584374052f9ff0c9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Brian, thanks for the clarifications. Snipping violently :-) >> According to the reference architecture, an Autonomic Function (AF) can >> be made up of one or more ASAs, and each ASA is instantiated on an >> autonomic node. The set of AFs reside on the ANI. >> >> I would prefer that intent is sent to the ASA, not directly to the >> (autonomic) node. > > [I'm going to use ANode to mean an autonomic node, because AN is > presumably Autonomic Network.] > > Well yes, the ANode is just a carrier for information to and from > ASAs, but if the Intent is needed by multiple ASAs in one ANode, > I expect that it will be cached once in the ANode before being picked > up by the individual ASAs. But see my next comment... I think we agree, though for security purposes, it may be preferable to have a dedicated repository as part of the ANI, as opposed to an ANode. But that is a nit and TBD. ... >>> I maintain that these are issues of ASA design, not infrastructure design. >>> We always knew that the infrastructure has to distribute Intent. >> >> I think that the infrastructure has to distribute the **results** of parsing >> intent. That is, the parsing is done in a dedicated agent, NOT in an >> autonomic node, and the agent transforms Intent to a form that is >> generally consumable. This "consumable form" has to be distributed, >> but the original intent does not. > > ...OK, terminology interrupt! Clearly what I (and I think others) mean by > Intent is the parsed, consumable intent in your terminology. But if we admit > that there may be multiple sources of parsed, consumable intent there may > still be a need for conflict resolution by the consumer, surely? Now that I can agree to! Forgive me, but this terminology was not obvious to me, and I do think it will help for it to be clarified. Also, I do agree that there is a need for conflict resolution. Thanks for the clarification. regards, John On Sun, Apr 3, 2016 at 4:39 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 04/04/2016 09:48, John Strassner wrote: > > Hi Brian, > > > > could I request two points of clarification? > > > >>>> Indeed not. An ASA will have some default behaviour that amounts to > > having > >>>> default settings for intent, but by definition intent comes from > humans. > >>>> (One qualification: if the intent that reaches a given node is > > inconsistent, > >>>> then resolving that inconsistency might be autonomic.) > >>> > >>> Brian: could you explain what you mean here, especially "resolving th= at > > inconsistency might be autonomic"? > >>> I guess you mean that ASAs/nodes can autonomously detect inconsistenc= y > > in intents and (try to) solve this inconsistency (on > >>> their own or via collaboration)...? > > > >> Yes. Actually if we allow more than one source of intent, this is > > essential. > > > > According to the reference architecture, an Autonomic Function (AF) can > > be made up of one or more ASAs, and each ASA is instantiated on an > > autonomic node. The set of AFs reside on the ANI. > > > > I would prefer that intent is sent to the ASA, not directly to the > > (autonomic) node. > > [I'm going to use ANode to mean an autonomic node, because AN is > presumably Autonomic Network.] > > Well yes, the ANode is just a carrier for information to and from > ASAs, but if the Intent is needed by multiple ASAs in one ANode, > I expect that it will be cached once in the ANode before being picked > up by the individual ASAs. But see my next comment... > > > This means that the autonomic node has to be able to understand > > intent AND understand when intent conflicts, and the Industry has a poo= r > > of providing useful support functions. Even with the hype that is IoT, > show > > me a vendor that wants to make their phone "intelligent" vs. providing > > higher-resolution cameras or more codecs. :-( > > > > Another consequence is that each ASA has to be able to understand inten= t > > AND understand when intent conflicts. OK, I could suppose that we could > > define AFs for this. But AFs are built on the ANI, so does this mean th= at > > the ANI has to support intent as well? The draft says: > > > > The ANI provides functions like naming, addressing, negotiation, > > synchronization, discovery and messaging. > > > > These are all functions that are needed by Intent, but Intent adds thin= gs > > that are not needed by the ANI. > > > >>> Without rewriting history, we are facing now with the "heavy" > >>> design/conceptual discussions on the list, the effect of some > >>> decisions to exclude architectural analysis / investigations in the > >>> early phase of ANIMA... > > > >> I maintain that these are issues of ASA design, not infrastructure > design. > >> We always knew that the infrastructure has to distribute Intent. > > > > I think that the infrastructure has to distribute the **results** of > parsing > > intent. That is, the parsing is done in a dedicated agent, NOT in an > > autonomic node, and the agent transforms Intent to a form that is > > generally consumable. This "consumable form" has to be distributed, > > but the original intent does not. > > ...OK, terminology interrupt! Clearly what I (and I think others) mean by > Intent is the parsed, consumable intent in your terminology. But if we > admit > that there may be multiple sources of parsed, consumable intent there may > still be a need for conflict resolution by the consumer, surely? > > Brian > > > > > regards, > > John > > > > On Tue, Mar 29, 2016 at 12:29 PM, Brian E Carpenter < > > brian.e.carpenter@gmail.com> wrote: > > > >> Hi Laurent, comments in line: > >> On 30/03/2016 05:29, Laurent Ciavaglia wrote: > >>> Hello, > >>> > >>> > >>>> Indeed not. An ASA will have some default behaviour that amounts to > >> having > >>>> default settings for intent, but by definition intent comes from > humans. > >>>> (One qualification: if the intent that reaches a given node is > >> inconsistent, > >>>> then resolving that inconsistency might be autonomic.) > >>> > >>> Brian: could you explain what you mean here, especially "resolving th= at > >> inconsistency might be autonomic"? > >>> I guess you mean that ASAs/nodes can autonomously detect inconsistenc= y > >> in intents and (try to) solve this inconsistency (on > >>> their own or via collaboration)...? > >> > >> Yes. Actually if we allow more than one source of intent, this is > >> essential. > >> > >>> > >>>> > >>>>>> Of course, when we put Intent into the picture, there's a > presumption > >>>>>> that Intent comes from some authority such as a NOC, but that's an > >>>>>> external semantic, not an assumption of the autonomic model. > >>>>> Well, no - if the autonomic system is going to use intent, or at > least > >>>>> respond to it, then it must understand those external semantics. > >>>>> This is even more important if the network is supposed to form > >>>>> according to one or more intent rules. > >>>> Right, but what I meant is that the network will operate perfectly > well > >>>> if no intent is sent, by using defaults. That will always happen to > the > >>>> extent that intent distribution will take a finite time. Until the > >> intent > >>>> reaches a node, it will operate on defaults. > >>> > >>> From collaborations with some operators on autonomic networking > >> projects: default behavior without policy must equal to "do > >>> nothing". But operators' views might change/evolve... > >> > >> That's certainly a possibility. I'm not sure it is always wise though. > >> For example, if a network is fragmented by a natural disaster, the > >> fragments > >> might not receive Intent for several days. > >> > >>> Also, and this is based on feedback from the field (e.g. 3GPP SON), > >> turning on autonomic functions, even with well-thought > >>> parameter settings, turns out most of the times in chaotic behaviors > and > >> severe performance degradations. > >>> A key element to consider here is how to "gracefully" start/ramp-up a= n > >> autonomic network and aspects of coordination (cf > >>> draft-ciavaglia-anima-coordination-01). > >> > >> Agreed. Obviously the defaults must be conservative and fail-safe. > >> > >>> > >>>> Of course, the semantics of > >>>> intent must be well-defined, but it's an extra layer. > >>>> > >>>>> If intent is formulated at an abstract level, how is an autonomic > >>>>> network going to consume intent that may have drastically different > >>>>> syntactical structures, and likely, different semantics associated > with > >>>>> those syntactical structures? > >>>> Agreed. We need a model, syntax and semantics. > >>>> > >>>>>> I think the point is that AN *adds* a new mode of communication > >>>>>> between self-managing nodes, that doesn't exist in a strictly > >>>>>> north/south scenario. That is meant to reduce the amount of > >>>>>> north/south communication and reduce the amount of > >>>>>> centralized work. So there's a trade-off - more autonomic > >>>>>> messaging means less north-south messaging. > >>> > >>> north-south is a matter of convention / roles. > >>> if we consider PBM / intent, for me it implies a "vertical" (authorit= y) > >> relationship. > >>> if we consider a more "flat" system of collaborative entities, then > >> let's have a look at MAS / DAI approaches and not reinvent > >>> (a squarred) wheel. > >>> we may end up pushing more or less intelligence in the autonomic > >> functions, but we also consider the scope of ANIMA to address > >>> "managed" networks (maybe not only this one), so it means some > operators > >> will expect certain behavior/performance from the > >>> neworks. Intent is one way to inform the network what is expected. > >> > >> Sure. But always remember the disaster-recovery scenario where we are > >> forced > >> back to defaults. > >> > >>> > >>>>> There may indeed be a new mode of communication required. > >>>>> However, if intent is not standardized, how does this work? > >>>> It doesn't. My only point is that intent is layered on top of an > >>>> underlying autonomic behaviour based on default behaviours. Actually= , > >>>> that's why the question of intent was deferred in the WG charter. > >>> > >>> Your explanation is "valid", but I don't remember this was the reason > >> used to consider intent FFS. > >> > >> OK, maybe that was just in my brain. Another aspect that Intent was > >> incompletely > >> understood. > >> > >>> Without rewriting history, we are facing now with the "heavy" > >> design/conceptual discussions on the list, the effect of some > >>> decisions to exclude architectural analysis / investigations in the > >> early phase of ANIMA... > >> > >> I maintain that these are issues of ASA design, not infrastructure > design. > >> We always > >> knew that the infrastructure has to distribute Intent. > >> > >> Regards > >> Brian > >> > >>> Laurent. > >>> > >>> > >>>> > >>>> Brian > >>>> > >>>>> I understand how unstructured and structured P2P networks > >>>>> work. Let's assume this is a structured P2P network. In that case, > >>>>> a DHT is used to assign ownership of each file to a peer. I fail to > >>>>> understand how this works in an intent case. Files are passive, > >>>>> intent is active. Please explain. > >>>>> > >>>>> Regards, > >>>>> John > >>>>> > >>>>> On Sat, Mar 26, 2016 at 11:53 AM, Brian E Carpenter < > >>>>> brian.e.carpenter@gmail.com> wrote: > >>>>> > >>>>>> Hi John, > >>>>>> On 27/03/2016 04:54, John Strassner wrote: > >>>>>>>> Correct, and there is also no presumption that individual nodes > >>>>>>>> have perfect knowledge of the topology. Of course the ACP > >>>>>>>> routing protocol will have perfect knowledge of the ACP topology= , > >>>>>>>> but individual ASAs only know what they have gleaned from > >>>>>>>> discovery and what they have been told by Intent. > >>>>>>>> > >>>>>>>> It is, I think, a very different world view than the SDN or SUPA > or > >>>>>>>> NVO4 or NFV view. > >>>>>>> Please note that I did NOT say anything about SDN, NFV, or SUPA > >>>>>>> here. In fact, I'm confused as to why you both think I did. > >>>>>> I can't speak for Zongpeng, but I was triggered by the mention of > >>>>>> northbound and southbound APIs. There is no presumed direction in > >>>>>> Anima relationships, since in the limit a network is self-forming; > >>>>>> all relationships are peer-to-peer. > >>>>>> > >>>>>> Of course, when we put Intent into the picture, there's a > presumption > >>>>>> that Intent comes from some authority such as a NOC, but that's an > >>>>>> external semantic, not an assumption of the autonomic model. > >>>>>> > >>>>>>> I specifically said "There are plenty of southbound APIs (from a > >>>>>>> management function to a device). There are very few northbound > >> APIs." > >>>>>>> > >>>>>>> Note the word "management function". > >>>>>>> > >>>>>>> For the record, I don't think that either Phase 2 of NFV or the S= DN > >> 1.1 > >>>>>>> architecture have treated policy in any detail. Both architecture= s > >> lack a > >>>>>>> policy management component. I hope that ANIMA doesn't make the > >>>>>>> same mistake. > >>>>>> Certainly, Intent needs a number of properties such as > >> self-consistency > >>>>>> and stability that imply it is managed in some way. > >>>>>> > >>>>>>>>> However, in ANIMA network, perhaps we do not have a centralized > >>>>>>>>> parsing node (controller), which can replace almost all the > >>>>>>>>> communications between nodes. > >>>>>>> Earlier I wrote about intent requiring a translation function. I > >> never > >>>>>> said > >>>>>>> that it was centralized or distributed. In the autonomic > >> architectures I > >>>>>>> have built, it was in fact a decentralized (agent-driven) functio= n. > >>>>>>> Furthermore, it did not "replace almost all the communications" - > it > >>>>>>> was used for compilation. There was, in fact, a separate > distribution > >>>>>>> mechanism (which I have also described), but that was limited to > >>>>>>> "just" distribution. > >>>>>>> > >>>>>>> I really don't understand what "replacing communications" means. > >>>>>> I think the point is that AN *adds* a new mode of communication > >> between > >>>>>> self-managing nodes, that doesn't exist in a strictly north/south > >>>>>> scenario. That is meant to reduce the amount of north/south > >> communication > >>>>>> and reduce the amount of centralized work. So there's a trade-off = - > >>>>>> more autonomic messaging means less north-south messaging. > >>>>>> > >>>>>> Best regards > >>>>>> Brian > >>>>>> > >>>>>>> regards, > >>>>>>> John > >>>>>>> > >>>>>>> On Fri, Mar 25, 2016 at 9:15 PM, Brian E Carpenter < > >>>>>>> brian.e.carpenter@gmail.com> wrote: > >>>>>>> > >>>>>>>>> However, in ANIMA network, perhaps we do not have a centralized > >> parsing > >>>>>>>> node (controller), which can replace almost all the communicatio= ns > >>>>>> between > >>>>>>>> nodes. > >>>>>>>> > >>>>>>>> Correct, and there is also no presumption that individual nodes > have > >>>>>>>> perfect > >>>>>>>> knowledge of the topology. Of course the ACP routing protocol wi= ll > >> have > >>>>>>>> perfect > >>>>>>>> knowledge of the ACP topology, but individual ASAs only know wha= t > >> they > >>>>>> have > >>>>>>>> gleaned from discovery and what they have been told by Intent. > >>>>>>>> > >>>>>>>> It is, I think, a very different world view than the SDN or SUPA > or > >> NVO4 > >>>>>>>> or NFV view. > >>>>>>>> > >>>>>>>> Regards > >>>>>>>> Brian > >>>>>>>> > >>>>>>>> On 26/03/2016 16:46, Duzongpeng wrote: > >>>>>>>>> Hi John: > >>>>>>>>> > >>>>>>>>> Thanks for your reply. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> How is this different than running a script, or invoking an API= ? > >> There > >>>>>>>> are plenty of southbound APIs (from a management function to a > >> device). > >>>>>>>> There are very few northbound APIs. That's what the operators > that I > >>>>>> have > >>>>>>>> talked to want. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> I agree that intent belongs to northbound interface in the SDN > >> network. > >>>>>>>> And ANIMA network perhaps can share the same northbound interfac= e. > >>>>>>>>> But, my understanding is that ANIMA network is a little differe= nt > >> from > >>>>>>>> SDN network. > >>>>>>>>> SDN controller will parse the intent, and transform to detailed > >>>>>>>> configurations of every device. It is a good model, and little > >>>>>>>> communications between nodes are needed. > >>>>>>>>> Some network level parameters can be handled in SDN controller. > >>>>>>>>> > >>>>>>>>> However, in ANIMA network, perhaps we do not have a centralized > >> parsing > >>>>>>>> node (controller), which can replace almost all the communicatio= ns > >>>>>> between > >>>>>>>> nodes. > >>>>>>>>> So when a network operator is operating a ANIMA network, the > >> network > >>>>>>>> level parameters are still needed to be flooded. > >>>>>>>>> I mean the ANIMA interface is perhaps something like =E2=80=9Cn= orthbound > + > >> part > >>>>>>>> of southbound=E2=80=9D. > >>>>>>>>> Best Regards > >>>>>>>>> Zongpeng Du > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> From: John Strassner [mailto:strazpdj@gmail.com] > >>>>>>>>> Sent: Saturday, March 26, 2016 9:41 AM > >>>>>>>>> To: Duzongpeng; John Strassner > >>>>>>>>> Cc: Michael Behringer (mbehring); Laurent Ciavaglia; Sheng Jian= g; > >>>>>>>> anima@ietf.org; J=C3=A9ferson Campos Nobre > >>>>>>>>> Subject: Re: [Anima] Does Autonomic network need some > intervention > >>>>>>>> beyond intent > >>>>>>>>> Hi Zongpeng, > >>>>>>>>> > >>>>>>>>> I think we have a misunderstanding here. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> But I do not support that the intent writer should look every > >> detail in > >>>>>>>> the catalog. > >>>>>>>>> > >>>>>>>>> Most catalogs that I have seen have very few details. They > instead > >> tell > >>>>>>>> the user what services or products are available. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> The intent writer may mainly care about what they want, but how > to > >> do > >>>>>> it > >>>>>>>> can be left to the autonomic network to deal with. > >>>>>>>>> > >>>>>>>>> I agree completely. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Perhaps several solutions exist, and autonomic management syste= m > >> choose > >>>>>>>> one according to the abilities collected. > >>>>>>>>> > >>>>>>>>> This is one of the reasons why I would like to see capabilities > >> (and > >>>>>>>> needs) advertised. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> ... > >>>>>>>>> I mean in current status, some of the Autonomic Functions shoul= d > be > >>>>>>>> exposed to the network operator, and some of the Autonomic > Functions > >>>>>> can be > >>>>>>>> hidden to the network operator > >>>>>>>>> ... > >>>>>>>>> > >>>>>>>>> How is this different than running a script, or invoking an API= ? > >> There > >>>>>>>> are plenty of southbound APIs (from a management function to a > >> device). > >>>>>>>> There are very few northbound APIs. That's what the operators > that I > >>>>>> have > >>>>>>>> talked to want. > >>>>>>>>> regards, > >>>>>>>>> John > >>>>>>>>> > >>>>>>>>> On Fri, Mar 25, 2016 at 2:31 AM, Duzongpeng < > duzongpeng@huawei.com > >>>>>>>> > wrote: > >>>>>>>>> Hi John > >>>>>>>>> > >>>>>>>>> Some personal understanding here. If any misunderstanding, plea= se > >>>>>>>> correct me. Thanks. > >>>>>>>>> > >>>>>>>>> I would suggest a slight modification, to enable users of > >>>>>>>>> intent (and even intent writers) to NOT have to have > >>>>>>>>> detailed implementation information. > >>>>>>>>> > >>>>>>>>> What if all of the Autonomic Functions, after they joined > >>>>>>>>> the network, advertised both their capabilities as well as > >>>>>>>>> their needs? We can put aside the latter (needs) as this > >>>>>>>>> is more complex, but if the capabilities are advertised, > >>>>>>>>> then the autonomic management system can assemble > >>>>>>>>> those needs into a catalog. Then, the intent writer can > >>>>>>>>> look at the catalog and write a declarative request to > >>>>>>>>> use the functionality of the catalog. > >>>>>>>>> > >>>>>>>>> I will look at your YANG model in a bit (sorry, I'm woefully > >>>>>>>>> behind...). > >>>>>>>>> < /jcs2> > >>>>>>>>> > >>>>>>>>> I agree that autonomic node should have that self-advertisement > >>>>>> ability, > >>>>>>>> and autonomic management system should have this catalog. > >>>>>>>>> But I do not support that the intent writer should look every > >> detail in > >>>>>>>> the catalog. > >>>>>>>>> The intent writer may mainly care about what they want, but how > to > >> do > >>>>>> it > >>>>>>>> can be left to the autonomic network to deal with. > >>>>>>>>> Perhaps several solutions exist, and autonomic management syste= m > >> choose > >>>>>>>> one according to the abilities collected. > >>>>>>>>> In the ideal, the network operator may communicate with the > >> autonomic > >>>>>>>> network using network-level level intent and network-level repor= t. > >>>>>>>>> I mean in current status, some of the Autonomic Functions shoul= d > be > >>>>>>>> exposed to the network operator, and some of the Autonomic > Functions > >>>>>> can be > >>>>>>>> hidden to the network operator > >>>>>>>>> Perhaps in future, when the network nodes become more > intelligent, > >> the > >>>>>>>> hidden part will increase. > >>>>>>>>> > >>>>>>>>> Best regards > >>>>>>>>> Zongpeng Du > >>>>>>>>> > >>>>>>>>> From: Anima [mailto:anima-bounces@ietf.org >>>>>> anima-bounces@ietf.org>] > >>>>>>>> On Behalf Of John Strassner > >>>>>>>>> Sent: Thursday, March 24, 2016 10:41 AM > >>>>>>>>> To: Michael Behringer (mbehring); John Strassner > >>>>>>>>> Cc: Duzongpeng; Laurent Ciavaglia; Sheng Jiang; anima@ietf.org > >> >>>>>>>> anima@ietf.org>; J=C3=A9ferson Campos Nobre > >>>>>>>>> Subject: Re: [Anima] Does Autonomic network need some > intervention > >>>>>>>> beyond intent > >>>>>>>>> Hi Michael, > >>>>>>>>> > >>>>>>>>> thanks for your reply. I do think that we largely agree, and > would > >>>>>> enjoy > >>>>>>>> chatting during or (hopefully before) BA. Please see > >> ... > >>>>>> Also > >>>>>>>> trying to unclutter, so I am eliding points that we agree on. > >>>>>>>>> > >>>>>>>>> While *CIEs don=E2=80=99t like magic, they do understand the co= ncept of a > >>>>>>>> default behaviour which they can influence if needed. Any > reasonable > >>>>>>>> network management approach tries to define =E2=80=9Cdefault=E2= =80=9D behaviour > and > >>>>>>>> =E2=80=9Cexceptions=E2=80=9D. The AN story fills the =E2=80=9Cde= fault=E2=80=9D part very nicely, > and > >>>>>> *CIEs > >>>>>>>> get that. > >>>>>>>>> > >>>>>>>>> Agreed! > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> The =E2=80=9Cparameter=E2=80=9D versus =E2=80=9Cpolicy=E2=80=9D= discussion: My view is that we > >>>>>> shouldn=E2=80=99t > >>>>>>>> try to define exactly *what* intent allows and doesn=E2=80=99t a= llow, > since > >>>>>> we=E2=80=99ve > >>>>>>>> heard from many sides that the boundary is not clear, and it may > be > >>>>>>>> impossible to have a really clear, usable definition. So my poin= t > >> was: > >>>>>>>> Let=E2=80=99s focus on the distribution model: Intent is flooded= to all > >> nodes. > >>>>>>>> Let=E2=80=99s NOT do selective flooding, unicast Intent to speci= fic nodes, > >> etc, > >>>>>>>> because that would blur the boundary even worse. > >>>>>>>>> > >>>>>>>>> I like flooding intent to all nodes. In FOCALE (v1-3, and > >> remember, v1 > >>>>>>>> was 2006, almost 10 years ago), we used a message bus and pub-su= b. > >> In > >>>>>> v2, > >>>>>>>> we flooded; in v3, we went back to pub-sub because we wanted to = do > >> some > >>>>>>>> optimization and auditing. But I would be happy to try some type > of > >>>>>>>> controlled flooding again. > >>>>>>>>> > >>>>>>>>> My suggestion: Intent is flooded to all nodes in a domain. The > ASA > >>>>>>>> owners define the content of what they want to push in their bit > of > >> the > >>>>>>>> Intent. If we insist of full flooding, we encourage the right > >> behaviour. > >>>>>>>> And if someone really puts into his Intent =E2=80=9Cnode A: do t= his; node > >> B: do > >>>>>> the > >>>>>>>> other; node C: do the third=E2=80=9D it is awkward enough for pe= ople to > >> take a > >>>>>> step > >>>>>>>> back and think whether they=E2=80=99re doing the right thing =E2= =98=BA > >>>>>>>>> > >>>>>>>>> I agree in principle with what you said. Plus, see above. > >>>>>>>>> < /jcs2> > >>>>>>>>> > >>>>>>>>> Do you mean that the intent writer will **know the difference** > >>>>>>>>> between the fabric and each autonomic function? I hope not, > >>>>>>>>> but perhaps I'm misunderstanding you... > >>>>>>>>> < /jcs> > >>>>>>>>> Not sure I understand your concern. Yes, in my model there is a > >> section > >>>>>>>> for the fabric, and sections for the various functions. Seems a > >> natural > >>>>>>>> structure?!? > >>>>>>>>> The intent **writer** would have to know implementation > >>>>>>>>> details in order to place everything in a single file. I would > >>>>>>>>> rather not require this, and instead, have the intent engine > >>>>>>>>> (e.g., compiler and associated logic) do this. > >>>>>>>>> < /jcs2> > >>>>>>>>> =E2=80=9CFunction owner=E2=80=9D: Yes, I=E2=80=99m suggesting t= o structure Intent around > >>>>>>>> Autonomic Functions. This is not optimal from a scientific point > of > >>>>>> view, > >>>>>>>> but aligns very well with the way how things are organised. > >> Probably we > >>>>>>>> need to discuss that in BA. But refer to my YANG model sent a fe= w > >> days > >>>>>> ago. > >>>>>>>>> > >>>>>>>>> I would suggest a slight modification, to enable users of > >>>>>>>>> intent (and even intent writers) to NOT have to have > >>>>>>>>> detailed implementation information. > >>>>>>>>> > >>>>>>>>> What if all of the Autonomic Functions, after they joined > >>>>>>>>> the network, advertised both their capabilities as well as > >>>>>>>>> their needs? We can put aside the latter (needs) as this > >>>>>>>>> is more complex, but if the capabilities are advertised, > >>>>>>>>> then the autonomic management system can assemble > >>>>>>>>> those needs into a catalog. Then, the intent writer can > >>>>>>>>> look at the catalog and write a declarative request to > >>>>>>>>> use the functionality of the catalog. > >>>>>>>>> > >>>>>>>>> I will look at your YANG model in a bit (sorry, I'm woefully > >>>>>>>>> behind...). > >>>>>>>>> < /jcs2> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> regards, > >>>>>>>>> John > >>>>>>>>> > >>>>>>>>> On Wed, Mar 23, 2016 at 3:57 AM, Michael Behringer (mbehring) < > >>>>>>>> mbehring@cisco.com> wrote: > >>>>>>>>> John, > >>>>>>>>> > >>>>>>>>> I think we=E2=80=99re on the same page. Couple of points, top p= osting > here, > >>>>>>>> otherwise it gets too messy. > >>>>>>>>> While *CIEs don=E2=80=99t like magic, they do understand the co= ncept of a > >>>>>>>> default behaviour which they can influence if needed. Any > reasonable > >>>>>>>> network management approach tries to define =E2=80=9Cdefault=E2= =80=9D behaviour > and > >>>>>>>> =E2=80=9Cexceptions=E2=80=9D. The AN story fills the =E2=80=9Cde= fault=E2=80=9D part very nicely, > and > >>>>>> *CIEs > >>>>>>>> get that. > >>>>>>>>> The =E2=80=9Cparameter=E2=80=9D versus =E2=80=9Cpolicy=E2=80=9D= discussion: My view is that we > >>>>>> shouldn=E2=80=99t > >>>>>>>> try to define exactly *what* intent allows and doesn=E2=80=99t a= llow, > since > >>>>>> we=E2=80=99ve > >>>>>>>> heard from many sides that the boundary is not clear, and it may > be > >>>>>>>> impossible to have a really clear, usable definition. So my poin= t > >> was: > >>>>>>>> Let=E2=80=99s focus on the distribution model: Intent is flooded= to all > >> nodes. > >>>>>>>> Let=E2=80=99s NOT do selective flooding, unicast Intent to speci= fic nodes, > >> etc, > >>>>>>>> because that would blur the boundary even worse. > >>>>>>>>> My suggestion: Intent is flooded to all nodes in a domain. The > ASA > >>>>>>>> owners define the content of what they want to push in their bit > of > >> the > >>>>>>>> Intent. If we insist of full flooding, we encourage the right > >> behaviour. > >>>>>>>> And if someone really puts into his Intent =E2=80=9Cnode A: do t= his; node > >> B: do > >>>>>> the > >>>>>>>> other; node C: do the third=E2=80=9D it is awkward enough for pe= ople to > >> take a > >>>>>> step > >>>>>>>> back and think whether they=E2=80=99re doing the right thing =E2= =98=BA > >>>>>>>>> > >>>>>>>>> Do you mean that the intent writer will **know the difference** > >>>>>>>>> between the fabric and each autonomic function? I hope not, > >>>>>>>>> but perhaps I'm misunderstanding you... > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Not sure I understand your concern. Yes, in my model there is a > >> section > >>>>>>>> for the fabric, and sections for the various functions. Seems a > >> natural > >>>>>>>> structure?!? > >>>>>>>>> =E2=80=9CFunction owner=E2=80=9D: Yes, I=E2=80=99m suggesting t= o structure Intent around > >>>>>>>> Autonomic Functions. This is not optimal from a scientific point > of > >>>>>> view, > >>>>>>>> but aligns very well with the way how things are organised. > >> Probably we > >>>>>>>> need to discuss that in BA. But refer to my YANG model sent a fe= w > >> days > >>>>>> ago. > >>>>>>>>> We should schedule some discussion time outside the ANIMA meeti= ng > >>>>>>>> window... > >>>>>>>>> Michael > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> From: John Strassner [mailto:strazpdj@gmail.com >>>>>>>> strazpdj@gmail.com>] > >>>>>>>>> Sent: 22 March 2016 21:32 > >>>>>>>>> To: Michael Behringer (mbehring) >>>>>>>> mbehring@cisco.com>>; John Strassner >>>>>>>> strazpdj@gmail.com>> > >>>>>>>>> Cc: Duzongpeng duzongpeng@huawei.com > >>>> ; > >>>>>>>> anima@ietf.org; Laurent Ciavaglia < > >>>>>>>> laurent.ciavaglia@nokia.com>= ; > >>>>>>>> J=C3=A9ferson Campos Nobre >> jcnobre@inf.ufrgs.br > >>>>>>>> ; > >>>>>>>> Sheng Jiang = > > >>>>>>>>> Subject: Re: [Anima] Does Autonomic network need some > intervention > >>>>>>>> beyond intent > >>>>>>>>> In general, I agree with Michael. I'd like to emphasize and > expand > >> on a > >>>>>>>> couple of key points: > >>>>>>>>> > >>>>>>>>> First, ANIMA isn=E2=80=99t the only thing =E2=80=9Cinfluencing= =E2=80=9D or =E2=80=9Csteering=E2=80=9D a > >>>>>> network, > >>>>>>>> at least not initially. There is still traditional config, plus > all > >> the > >>>>>>>> existing and emerging SDN models. My view has always been that > ANIMA > >>>>>> sets a > >>>>>>>> =E2=80=9Cdefault=E2=80=9D policy in a network, and all other mea= ns are more > >> specific and > >>>>>>>> can override intent. This is described in RFC7575. Main point > here: > >>>>>> ANIMA > >>>>>>>> Intent isn=E2=80=99t the only tool in a network. > >>>>>>>>> > >>>>>>>>> Absolutely agree. Note that even in the Congress case I mention= ed > >>>>>>>>> earlier, it is NOT pushing config, and it is NOT viewed as the > >>>>>>>>> "only" policy > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Intent could perfectly well cover a high level policy such as > =E2=80=9Call > >>>>>> nodes > >>>>>>>> of type x do this; type y does that=E2=80=9D. (Which I think is = what you > >> mention > >>>>>>>> below.) When we started with Intent, the vision was to keep it > very > >> high > >>>>>>>> level, more along the line =E2=80=9Cdo the right thing=E2=80=9D = =E2=98=BA > >>>>>>>>> > >>>>>>>>> Agreed. Although to me, this means that we need to consider the > >> types > >>>>>> of > >>>>>>>> actors that are using intent. For example, most of my CCIE and > JCIE > >>>>>> friends > >>>>>>>> have no interest in using an intent language for pushing > >> configuration. > >>>>>> On > >>>>>>>> the other hand, when I talk to operators and application > developers, > >>>>>> they > >>>>>>>> would love to be able to use a high-level intent and have the > intent > >>>>>> engine > >>>>>>>> take care of the details for them. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> It has become clear that in today=E2=80=99s networking, people = will want > to > >>>>>> push > >>>>>>>> more =E2=80=9Cparameters=E2=80=9D than =E2=80=9Cpolicy=E2=80=9D,= and I think we=E2=80=99ll just have to > >>>>>> acknowledge > >>>>>>>> that. > >>>>>>>>> > >>>>>>>>> Sorry Michael, I don't follow here. What do you mean > >>>>>>>>> by "parameters"? > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Personally I think it=E2=80=99ll pan out like this: Intent will= have > >> sections > >>>>>>>> per autonomic function. An Intent parser will validate overall > >>>>>> correctness > >>>>>>>> (signature, etc), then segment the Intent into its bits: One par= t > >> will > >>>>>> be > >>>>>>>> the autonomic fabric itself, then there will be bits for each > >> autonomic > >>>>>>>> function. > >>>>>>>>> > >>>>>>>>> Do you mean that the intent writer will **know the difference** > >>>>>>>>> between the fabric and each autonomic function? I hope not, > >>>>>>>>> but perhaps I'm misunderstanding you... > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> So the Intent parser on a node will grab intent, see there is > some > >>>>>>>> Intent for autonomic function A, will see whether this is runnin= g > >>>>>> locally, > >>>>>>>> and if so, it=E2=80=99ll just pass that piece of Intent to that = function. > >>>>>>>>> > >>>>>>>>> Agreed. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> In this way, a function owner defines both the intent itself, a= nd > >> how > >>>>>> it > >>>>>>>> is consumed by his/her function. > >>>>>>>>> > >>>>>>>>> I'm not sure what you mean by "function owner". (Sorry to be > >>>>>>>>> picky, I'm likely under-caffeinated.) > >>>>>>>>> > >>>>>>>>> The above seemed like an autonomous decision, made by the parse= r. > >>>>>>>>> I don't think that the intent writer should be cognizant of how > >> many or > >>>>>>>>> what types of autonomic functions are present. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> The downside is that there is no =E2=80=9Ccontrol=E2=80=9D and = people can do what > >> they > >>>>>>>> want, in the worst case even push config, which is clearly NOT > what > >>>>>> Intent > >>>>>>>> is meant to do. > >>>>>>>>> > >>>>>>>>> And hence, the "HAL 2000" scenario. :-) > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> I=E2=80=99d hope that people don=E2=80=99t start writing Intent= like =E2=80=9Cnode 17: > >> here is > >>>>>>>> your CLI; node 23: here is your CLI=E2=80=9D; node 37: here is y= our CLI=E2=80=9D. > >> But > >>>>>> what > >>>>>>>> I describe above COULD be abused in this way. RFC7575 says this = is > >> NOT > >>>>>>>> Intent. > >>>>>>>>> > >>>>>>>>> Absolutely agree! > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> regards, > >>>>>>>>> John > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Wed, Mar 16, 2016 at 1:16 AM, Michael Behringer (mbehring) < > >>>>>>>> mbehring@cisco.com> wrote: > >>>>>>>>> Hi Zongpeng, > >>>>>>>>> > >>>>>>>>> Yes, this is a recurring question and topic. Let me give my vie= w > >> on two > >>>>>>>> levels: > >>>>>>>>> First, ANIMA isn=E2=80=99t the only thing =E2=80=9Cinfluencing= =E2=80=9D or =E2=80=9Csteering=E2=80=9D a > >>>>>> network, > >>>>>>>> at least not initially. There is still traditional config, plus > all > >> the > >>>>>>>> existing and emerging SDN models. My view has always been that > ANIMA > >>>>>> sets a > >>>>>>>> =E2=80=9Cdefault=E2=80=9D policy in a network, and all other mea= ns are more > >> specific and > >>>>>>>> can override intent. This is described in RFC7575. Main point > here: > >>>>>> ANIMA > >>>>>>>> Intent isn=E2=80=99t the only tool in a network. > >>>>>>>>> Intent could perfectly well cover a high level policy such as > =E2=80=9Call > >>>>>> nodes > >>>>>>>> of type x do this; type y does that=E2=80=9D. (Which I think is = what you > >> mention > >>>>>>>> below.) When we started with Intent, the vision was to keep it > very > >> high > >>>>>>>> level, more along the line =E2=80=9Cdo the right thing=E2=80=9D = =E2=98=BA It has become > >> clear > >>>>>> that > >>>>>>>> in today=E2=80=99s networking, people will want to push more =E2= =80=9Cparameters=E2=80=9D > >> than > >>>>>>>> =E2=80=9Cpolicy=E2=80=9D, and I think we=E2=80=99ll just have to= acknowledge that. > >>>>>>>>> Personally I think it=E2=80=99ll pan out like this: Intent will= have > >> sections > >>>>>>>> per autonomic function. An Intent parser will validate overall > >>>>>> correctness > >>>>>>>> (signature, etc), then segment the Intent into its bits: One par= t > >> will > >>>>>> be > >>>>>>>> the autonomic fabric itself, then there will be bits for each > >> autonomic > >>>>>>>> function. > >>>>>>>>> So the Intent parser on a node will grab intent, see there is > some > >>>>>>>> Intent for autonomic function A, will see whether this is runnin= g > >>>>>> locally, > >>>>>>>> and if so, it=E2=80=99ll just pass that piece of Intent to that = function. > >>>>>>>>> In this way, a function owner defines both the intent itself, a= nd > >> how > >>>>>> it > >>>>>>>> is consumed by his/her function. > >>>>>>>>> The downside is that there is no =E2=80=9Ccontrol=E2=80=9D and = people can do what > >> they > >>>>>>>> want, in the worst case even push config, which is clearly NOT > what > >>>>>> Intent > >>>>>>>> is meant to do. I=E2=80=99d hope that people don=E2=80=99t start= writing Intent > like > >>>>>> =E2=80=9Cnode > >>>>>>>> 17: here is your CLI; node 23: here is your CLI=E2=80=9D; node 3= 7: here is > >> your > >>>>>>>> CLI=E2=80=9D. But what I describe above COULD be abused in this = way. > RFC7575 > >>>>>> says > >>>>>>>> this is NOT Intent. > >>>>>>>>> In other words: Let=E2=80=99s not be too prescriptive, and hope= that > folks > >> will > >>>>>>>> do more or less reasonable things. > >>>>>>>>> I=E2=80=99ve been meaning to comment on the Intent drafts and p= ossibly > >>>>>>>> contribute, I=E2=80=99m just struggling with priorities at the m= oment (as > >> you > >>>>>> can > >>>>>>>> see by my relative silence over the past weeks). > >>>>>>>>> Michael > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> From: Anima [mailto:anima-bounces@ietf.org >>>>>> anima-bounces@ietf.org>] > >>>>>>>> On Behalf Of Duzongpeng > >>>>>>>>> Sent: 16 March 2016 02:38 > >>>>>>>>> To: anima@ietf.org > >>>>>>>>> Cc: Laurent Ciavaglia >>>>>>>> laurent.ciavaglia@nokia.com>>; J=C3=A9ferson Campos Nobre < > >>>>>> jcnobre@inf.ufrgs.br > >>>>>>>> >; Sheng Jiang < > jiangsheng@huawei.com > >>>>>> >>>>>>>> jiangsheng@huawei.com>> > >>>>>>>>> Subject: [Anima] Does Autonomic network need some intervention > >> beyond > >>>>>>>> intent > >>>>>>>>> Hello, everyone > >>>>>>>>> > >>>>>>>>> I understand that Autonomic network should be able to > >> work > >>>>>> with > >>>>>>>> as less configuration as possible. In the ideal case, an Autonom= ic > >>>>>> network > >>>>>>>> should be able to work well while only intent is needed from hum= an > >>>>>>>> operators. > >>>>>>>>> However, I wonder whether Autonomic network may need > some > >>>>>>>> intervention from human operators through some low-level policie= s > >> beyond > >>>>>>>> intents. > >>>>>>>>> For example, in the > >>>>>>>> https://tools.ietf.org/html/draft-ietf-anima-prefix-management-0= 0 > , > >> it > >>>>>> is > >>>>>>>> suggested that the prefix lengths for the CSG, ASG, RSG (differe= nt > >>>>>> roles in > >>>>>>>> IP RAN) can be assigned as an "intent". These configuration > >> parameters > >>>>>> need > >>>>>>>> to be distributed in the autonomic domain to influence the detai= l > >>>>>>>> configurations on each autonomic node. > >>>>>>>>> As intent is described as an abstract, declarative, > >> high-level > >>>>>>>> policy used to operate an autonomic domain, such as an enterpris= e > >>>>>> network. > >>>>>>>> Perhaps we can rename the =E2=80=9Cintent=E2=80=9D in the =E2=80= =9Cprefix-management ID=E2=80=9D > to > >> some > >>>>>>>> other words. > >>>>>>>>> Is =E2=80=9CASA parameters" ok here? > >>>>>>>>> > >>>>>>>>> I think some characteristics for this kind of low-level policie= s > >> are > >>>>>>>>> > >>>>>>>>> 1. Network level parameters, need to be distributed by > GRASP > >> and > >>>>>>>> ACP > >>>>>>>>> 2. Relatively static compared to intent, perhaps only > needed > >> to > >>>>>> be > >>>>>>>> configured once > >>>>>>>>> 3. Unavoidable in current network environment, mostly for > >>>>>>>> establishing the network infrastructure > >>>>>>>>> 4. Rarely need coordinations with others parameters, > usually > >> is > >>>>>>>> closed related to one specific autonomic function > >>>>>>>>> Welcome for comment. Your suggestions will be appreciated. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Best Regards > >>>>>>>>> Zongpeng Du > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> Anima mailing list > >>>>>>>>> Anima@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/anima > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> regards, > >>>>>>>>> John > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> regards, > >>>>>>>>> John > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> regards, > >>>>>>>>> John > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> Anima mailing list > >>>>>>>>> Anima@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/anima > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > >> > > > > > > --=20 regards, John --001a11401f3c584374052f9ff0c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Brian,

thanks for the cla= rifications. Snipping violently :-)

>> Accor= ding to the reference architecture, an Autonomic Function (AF) can
>&= gt; be made up of one or more ASAs, and each ASA is instantiated on an
&= gt;> autonomic node. The set of AFs reside on the ANI.
>>
&= gt;> I would prefer that intent is sent to the ASA, not directly to the<= br>>> (autonomic) node.
>
> [I'm going to use ANode = to mean an autonomic node, because AN is
> presumably Autonomic Netw= ork.]
>
> Well yes, the ANode is just a carrier for informatio= n to and from
> ASAs, but if the Intent is needed by multiple ASAs i= n one ANode,
> I expect that it will be cached once in the ANode befo= re being picked
> up by the individual ASAs. But see my next comment= ...

I think we agree, though for security purposes= , it may be preferable
to have a dedicated repository as part of = the ANI, as opposed to an
ANode. But that is a nit and TBD.
=


...

>>> I maintain that these are issue= s of ASA design, not infrastructure design.
>>> We always knew = that the infrastructure has to distribute Intent.
>>
>> = I think that the infrastructure has to distribute the **results** of parsin= g
>> intent. That is, the parsing is done in a dedicated agent, NO= T in an
>> autonomic node, and the agent transforms Intent to a fo= rm that is
>> generally consumable. This "consumable form&quo= t; has to be distributed,
>> but the original intent does not.
= >
> ...OK, terminology interrupt! Clearly what I (and I think oth= ers) mean by
> Intent is the parsed, consumable intent in your termi= nology. But if we admit
> that there may be multiple sources of pars= ed, consumable intent there may
> still be a need for conflict resol= ution by the consumer, surely?

Now that I can agre= e to! Forgive me, but this terminology was not obvious
to me, and= I do think it will help for it to be clarified.

A= lso, I do agree that there is a need for conflict resolution.
Thanks for the clarification.

regards,=
John

On Sun, Apr 3, 2016 at 4:39 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
On 04/04/2016 09:48, John Strassner wrote:
> Hi Brian,
>
> could I request two points of clarification?
>
>>>> Indeed not. An ASA will have some default behaviour that a= mounts to
> having
>>>> default settings for intent, but by definition intent come= s from humans.
>>>> (One qualification: if the intent that reaches a given nod= e is
> inconsistent,
>>>> then resolving that inconsistency might be autonomic.)
>>>
>>> Brian: could you explain what you mean here, especially "= resolving that
> inconsistency might be autonomic"?
>>> I guess you mean that ASAs/nodes can autonomously detect incon= sistency
> in intents and (try to) solve this inconsistency (on
>>> their own or via collaboration)...?
>
>> Yes. Actually if we allow more than one source of intent, this is<= br> > essential.
>
> According to the reference architecture, an Autonomic Function (AF) ca= n
> be made up of one or more ASAs, and each ASA is instantiated on an
> autonomic node. The set of AFs reside on the ANI.
>
> I would prefer that intent is sent to the ASA, not directly to the
> (autonomic) node.

[I'm going to use ANode to mean an autonomic node, because AN is
presumably Autonomic Network.]

Well yes, the ANode is just a carrier for information to and from
ASAs, but if the Intent is needed by multiple ASAs in one ANode,
I expect that it will be cached once in the ANode before being picked
up by the individual ASAs. But see my next comment...

> This means that the autonomic node has to be able to understand
> intent AND understand when intent conflicts, and the Industry has a po= or
> of providing useful support functions. Even with the hype that is IoT,= show
> me a vendor that wants to make their phone "intelligent" vs.= providing
> higher-resolution cameras or more codecs. :-(
>
> Another consequence is that each ASA has to be able to understand inte= nt
> AND understand when intent conflicts. OK, I could suppose that we coul= d
> define AFs for this. But AFs are built on the ANI, so does this mean t= hat
> the ANI has to support intent as well? The draft says:
>
>=C2=A0 =C2=A0 =C2=A0 The ANI provides functions like naming, addressing= , negotiation,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0synchronization, discovery and messaging. >
> These are all functions that are needed by Intent, but Intent adds thi= ngs
> that are not needed by the ANI.
>
>>> Without rewriting history, we are facing now with the "he= avy"
>>> design/conceptual discussions on the list, the effect of some<= br> >>> decisions to exclude architectural analysis / investigations i= n the
>>> early phase of ANIMA...
>
>> I maintain that these are issues of ASA design, not infrastructure= design.
>> We always knew that the infrastructure has to distribute Intent. >
> I think that the infrastructure has to distribute the **results** of p= arsing
> intent. That is, the parsing is done in a dedicated agent, NOT in an > autonomic node, and the agent transforms Intent to a form that is
> generally consumable. This "consumable form" has to be distr= ibuted,
> but the original intent does not.

...OK, terminology interrupt! Clearly what I (and I think others) mean by Intent is the parsed, consumable intent in your terminology. But if we admi= t
that there may be multiple sources of parsed, consumable intent there may still be a need for conflict resolution by the consumer, surely?

=C2=A0 =C2=A0Brian

>
> regards,
> John
>
> On Tue, Mar 29, 2016 at 12:29 PM, Brian E Carpenter <
> brian.e.carpenter@gmail= .com> wrote:
>
>> Hi Laurent, comments in line:
>> On 30/03/2016 05:29, Laurent Ciavaglia wrote:
>>> Hello,
>>>
>>>
>>>> Indeed not. An ASA will have some default behaviour that a= mounts to
>> having
>>>> default settings for intent, but by definition intent come= s from humans.
>>>> (One qualification: if the intent that reaches a given nod= e is
>> inconsistent,
>>>> then resolving that inconsistency might be autonomic.)
>>>
>>> Brian: could you explain what you mean here, especially "= resolving that
>> inconsistency might be autonomic"?
>>> I guess you mean that ASAs/nodes can autonomously detect incon= sistency
>> in intents and (try to) solve this inconsistency (on
>>> their own or via collaboration)...?
>>
>> Yes. Actually if we allow more than one source of intent, this is<= br> >> essential.
>>
>>>
>>>>
>>>>>> Of course, when we put Intent into the picture, th= ere's a presumption
>>>>>> that Intent comes from some authority such as a NO= C, but that's an
>>>>>> external semantic, not an assumption of the autono= mic model.
>>>>> Well, no - if the autonomic system is going to use int= ent, or at least
>>>>> respond to it, then it must understand those external = semantics.
>>>>> This is even more important if the network is supposed= to form
>>>>> according to one or more intent rules.
>>>> Right, but what I meant is that the network will operate p= erfectly well
>>>> if no intent is sent, by using defaults. That will always = happen to the
>>>> extent that intent distribution will take a finite time. U= ntil the
>> intent
>>>> reaches a node, it will operate on defaults.
>>>
>>> From collaborations with some operators on autonomic networkin= g
>> projects: default behavior without policy must equal to "do >>> nothing". But operators' views might change/evolve...=
>>
>> That's certainly a possibility. I'm not sure it is always = wise though.
>> For example, if a network is fragmented by a natural disaster, the=
>> fragments
>> might not receive Intent for several days.
>>
>>> Also, and this is based on feedback from the field (e.g. 3GPP = SON),
>> turning on autonomic functions, even with well-thought
>>> parameter settings, turns out most of the times in chaotic beh= aviors and
>> severe performance degradations.
>>> A key element to consider here is how to "gracefully"= ; start/ramp-up an
>> autonomic network and aspects of coordination (cf
>>> draft-ciavaglia-anima-coordination-01).
>>
>> Agreed. Obviously the defaults must be conservative and fail-safe.=
>>
>>>
>>>>=C2=A0 =C2=A0Of course, the semantics of
>>>> intent must be well-defined, but it's an extra layer.<= br> >>>>
>>>>> If intent is formulated at an abstract level, how is a= n autonomic
>>>>> network going to consume intent that may have drastica= lly different
>>>>> syntactical structures, and likely, different semantic= s associated with
>>>>> those syntactical structures?
>>>> Agreed. We need a model, syntax and semantics.
>>>>
>>>>>> I think the point is that AN *adds* a new mode of = communication
>>>>>> between self-managing nodes, that doesn't exis= t in a strictly
>>>>>> north/south scenario. That is meant to reduce the = amount of
>>>>>> north/south communication and reduce the amount of=
>>>>>> centralized work. So there's a trade-off - mor= e autonomic
>>>>>> messaging means less north-south messaging.
>>>
>>> north-south is a matter of convention / roles.
>>> if we consider PBM / intent, for me it implies a "vertica= l" (authority)
>> relationship.
>>> if we consider a more "flat" system of collaborative= entities, then
>> let's have a look at MAS / DAI approaches and not reinvent
>>> (a squarred) wheel.
>>> we may end up pushing more or less intelligence in the autonom= ic
>> functions, but we also consider the scope of ANIMA to address
>>> "managed" networks (maybe not only this one), so it = means some operators
>> will expect certain behavior/performance from the
>>> neworks. Intent is one way to inform the network what is expec= ted.
>>
>> Sure. But always remember the disaster-recovery scenario where we = are
>> forced
>> back to defaults.
>>
>>>
>>>>> There may indeed be a new mode of communication requir= ed.
>>>>> However, if intent is not standardized, how does this = work?
>>>> It doesn't. My only point is that intent is layered on= top of an
>>>> underlying autonomic behaviour based on default behaviours= . Actually,
>>>> that's why the question of intent was deferred in the = WG charter.
>>>
>>> Your explanation is "valid", but I don't remembe= r this was the reason
>> used to consider intent FFS.
>>
>> OK, maybe that was just in my brain. Another aspect that Intent wa= s
>> incompletely
>> understood.
>>
>>> Without rewriting history, we are facing now with the "he= avy"
>> design/conceptual discussions on the list, the effect of some
>>> decisions to exclude architectural analysis / investigations i= n the
>> early phase of ANIMA...
>>
>> I maintain that these are issues of ASA design, not infrastructure= design.
>> We always
>> knew that the infrastructure has to distribute Intent.
>>
>> Regards
>>=C2=A0 =C2=A0 Brian
>>
>>> Laurent.
>>>
>>>
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 Brian
>>>>
>>>>> I understand how unstructured and structured P2P netwo= rks
>>>>> work. Let's assume this is a structured P2P networ= k. In that case,
>>>>> a DHT is used to assign ownership of each file to a pe= er. I fail to
>>>>> understand how this works in an intent case. Files are= passive,
>>>>> intent is active. Please explain.
>>>>>
>>>>> Regards,
>>>>> John
>>>>>
>>>>> On Sat, Mar 26, 2016 at 11:53 AM, Brian E Carpenter &l= t;
>>>>> brian.e= .carpenter@gmail.com> wrote:
>>>>>
>>>>>> Hi John,
>>>>>> On 27/03/2016 04:54, John Strassner wrote:
>>>>>>>> Correct, and there is also no presumption = that individual nodes
>>>>>>>> have perfect knowledge of the topology. Of= course the ACP
>>>>>>>> routing protocol will have perfect knowled= ge of the ACP topology,
>>>>>>>> but individual ASAs only know what they ha= ve gleaned from
>>>>>>>> discovery and what they have been told by = Intent.
>>>>>>>>
>>>>>>>> It is, I think, a very different world vie= w than the SDN or SUPA or
>>>>>>>> NVO4 or NFV view.
>>>>>>> Please note that I did NOT say anything about = SDN, NFV, or SUPA
>>>>>>> here. In fact, I'm confused as to why you = both think I did.
>>>>>> I can't speak for Zongpeng, but I was triggere= d by the mention of
>>>>>> northbound and southbound APIs. There is no presum= ed direction in
>>>>>> Anima relationships, since in the limit a network = is self-forming;
>>>>>> all relationships are peer-to-peer.
>>>>>>
>>>>>> Of course, when we put Intent into the picture, th= ere's a presumption
>>>>>> that Intent comes from some authority such as a NO= C, but that's an
>>>>>> external semantic, not an assumption of the autono= mic model.
>>>>>>
>>>>>>> I specifically said "There are plenty of = southbound APIs (from a
>>>>>>> management function to a device). There are ve= ry few northbound
>> APIs."
>>>>>>>
>>>>>>> Note the word "management function".=
>>>>>>>
>>>>>>> For the record, I don't think that either = Phase 2 of NFV or the SDN
>> 1.1
>>>>>>> architecture have treated policy in any detail= . Both architectures
>> lack a
>>>>>>> policy management component. I hope that ANIMA= doesn't make the
>>>>>>> same mistake.
>>>>>> Certainly, Intent needs a number of properties suc= h as
>> self-consistency
>>>>>> and stability that imply it is managed in some way= .
>>>>>>
>>>>>>>>> However, in ANIMA network, perhaps we = do not have a centralized
>>>>>>>>> parsing node (controller), which can r= eplace almost all the
>>>>>>>>> communications between nodes.
>>>>>>> Earlier I wrote about intent requiring a trans= lation function. I
>> never
>>>>>> said
>>>>>>> that it was centralized or distributed. In the= autonomic
>> architectures I
>>>>>>> have built, it was in fact a decentralized (ag= ent-driven) function.
>>>>>>> Furthermore, it did not "replace almost a= ll the communications" - it
>>>>>>> was used for compilation. There was, in fact, = a separate distribution
>>>>>>> mechanism (which I have also described), but t= hat was limited to
>>>>>>> "just" distribution.
>>>>>>>
>>>>>>> I really don't understand what "repla= cing communications" means.
>>>>>> I think the point is that AN *adds* a new mode of = communication
>> between
>>>>>> self-managing nodes, that doesn't exist in a s= trictly north/south
>>>>>> scenario. That is meant to reduce the amount of no= rth/south
>> communication
>>>>>> and reduce the amount of centralized work. So ther= e's a trade-off -
>>>>>> more autonomic messaging means less north-south me= ssaging.
>>>>>>
>>>>>> Best regards
>>>>>>=C2=A0 =C2=A0 =C2=A0Brian
>>>>>>
>>>>>>> regards,
>>>>>>> John
>>>>>>>
>>>>>>> On Fri, Mar 25, 2016 at 9:15 PM, Brian E Carpe= nter <
>>>>>>> brian.e.carpenter@gmail.com> wrote:
>>>>>>>
>>>>>>>>> However, in ANIMA network, perhaps we = do not have a centralized
>> parsing
>>>>>>>> node (controller), which can replace almos= t all the communications
>>>>>> between
>>>>>>>> nodes.
>>>>>>>>
>>>>>>>> Correct, and there is also no presumption = that individual nodes have
>>>>>>>> perfect
>>>>>>>> knowledge of the topology. Of course the A= CP routing protocol will
>> have
>>>>>>>> perfect
>>>>>>>> knowledge of the ACP topology, but individ= ual ASAs only know what
>> they
>>>>>> have
>>>>>>>> gleaned from discovery and what they have = been told by Intent.
>>>>>>>>
>>>>>>>> It is, I think, a very different world vie= w than the SDN or SUPA or
>> NVO4
>>>>>>>> or NFV view.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>>=C2=A0 =C2=A0 =C2=A0Brian
>>>>>>>>
>>>>>>>> On 26/03/2016 16:46, Duzongpeng wrote:
>>>>>>>>> Hi John:
>>>>>>>>>
>>>>>>>>> Thanks for your reply.
>>>>>>>>>
>>>>>>>>> <jcs>
>>>>>>>>> How is this different than running a s= cript, or invoking an API?
>> There
>>>>>>>> are plenty of southbound APIs (from a mana= gement function to a
>> device).
>>>>>>>> There are very few northbound APIs. That&#= 39;s what the operators that I
>>>>>> have
>>>>>>>> talked to want.
>>>>>>>>> </jcs>
>>>>>>>>>
>>>>>>>>> I agree that intent belongs to northbo= und interface in the SDN
>> network.
>>>>>>>> And ANIMA network perhaps can share the sa= me northbound interface.
>>>>>>>>> But, my understanding is that ANIMA ne= twork is a little different
>> from
>>>>>>>> SDN network.
>>>>>>>>> SDN controller will parse the intent, = and transform to detailed
>>>>>>>> configurations of every device. It is a go= od model, and little
>>>>>>>> communications between nodes are needed. >>>>>>>>> Some network level parameters can be h= andled in SDN controller.
>>>>>>>>>
>>>>>>>>> However, in ANIMA network, perhaps we = do not have a centralized
>> parsing
>>>>>>>> node (controller), which can replace almos= t all the communications
>>>>>> between
>>>>>>>> nodes.
>>>>>>>>> So when a network operator is operatin= g a ANIMA network, the
>> network
>>>>>>>> level parameters are still needed to be fl= ooded.
>>>>>>>>> I mean the ANIMA interface is perhaps = something like =E2=80=9Cnorthbound +
>> part
>>>>>>>> of southbound=E2=80=9D.
>>>>>>>>> Best Regards
>>>>>>>>> Zongpeng Du
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> From: John Strassner [mailto:strazpdj@gmail.com]
>>>>>>>>> Sent: Saturday, March 26, 2016 9:41 AM=
>>>>>>>>> To: Duzongpeng; John Strassner
>>>>>>>>> Cc: Michael Behringer (mbehring); Laur= ent Ciavaglia; Sheng Jiang;
>>>>>>>> anima@ie= tf.org; J=C3=A9ferson Campos Nobre
>>>>>>>>> Subject: Re: [Anima] Does Autonomic ne= twork need some intervention
>>>>>>>> beyond intent
>>>>>>>>> Hi Zongpeng,
>>>>>>>>>
>>>>>>>>> I think we have a misunderstanding her= e.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> But I do not support that the intent w= riter should look every
>> detail in
>>>>>>>> the catalog.
>>>>>>>>> <jcs>
>>>>>>>>> Most catalogs that I have seen have ve= ry few details. They instead
>> tell
>>>>>>>> the user what services or products are ava= ilable.
>>>>>>>>> </jcs>
>>>>>>>>>
>>>>>>>>> The intent writer may mainly care abou= t what they want, but how to
>> do
>>>>>> it
>>>>>>>> can be left to the autonomic network to de= al with.
>>>>>>>>> <jcs>
>>>>>>>>> I agree completely.
>>>>>>>>> </jcs>
>>>>>>>>>
>>>>>>>>> Perhaps several solutions exist, and a= utonomic management system
>> choose
>>>>>>>> one according to the abilities collected.<= br> >>>>>>>>> <jcs>
>>>>>>>>> This is one of the reasons why I would= like to see capabilities
>> (and
>>>>>>>> needs) advertised.
>>>>>>>>> </jcs>
>>>>>>>>>
>>>>>>>>> ...
>>>>>>>>> I mean in current status, some of the = Autonomic Functions should be
>>>>>>>> exposed to the network operator, and some = of the Autonomic Functions
>>>>>> can be
>>>>>>>> hidden to the network operator
>>>>>>>>> ...
>>>>>>>>> <jcs>
>>>>>>>>> How is this different than running a s= cript, or invoking an API?
>> There
>>>>>>>> are plenty of southbound APIs (from a mana= gement function to a
>> device).
>>>>>>>> There are very few northbound APIs. That&#= 39;s what the operators that I
>>>>>> have
>>>>>>>> talked to want.
>>>>>>>>> regards,
>>>>>>>>> John
>>>>>>>>>
>>>>>>>>> On Fri, Mar 25, 2016 at 2:31 AM, Duzon= gpeng <duzongpeng@huawei.com
>>>>>>>> <mailto:duzongpeng@huawei.com>> wrote:
>>>>>>>>> Hi John
>>>>>>>>>
>>>>>>>>> Some personal understanding here. If a= ny misunderstanding, please
>>>>>>>> correct me. Thanks.
>>>>>>>>> <jcs2>
>>>>>>>>> I would suggest a slight modification,= to enable users of
>>>>>>>>> intent (and even intent writers) to NO= T have to have
>>>>>>>>> detailed implementation information. >>>>>>>>>
>>>>>>>>> What if all of the Autonomic Functions= , after they joined
>>>>>>>>> the network, advertised both their cap= abilities as well as
>>>>>>>>> their needs? We can put aside the latt= er (needs) as this
>>>>>>>>> is more complex, but if the capabiliti= es are advertised,
>>>>>>>>> then the autonomic management system c= an assemble
>>>>>>>>> those needs into a catalog. Then, the = intent writer can
>>>>>>>>> look at the catalog and write a declar= ative request to
>>>>>>>>> use the functionality of the catalog.<= br> >>>>>>>>>
>>>>>>>>> I will look at your YANG model in a bi= t (sorry, I'm woefully
>>>>>>>>> behind...).
>>>>>>>>> < /jcs2>
>>>>>>>>>
>>>>>>>>> I agree that autonomic node should hav= e that self-advertisement
>>>>>> ability,
>>>>>>>> and autonomic management system should hav= e this catalog.
>>>>>>>>> But I do not support that the intent w= riter should look every
>> detail in
>>>>>>>> the catalog.
>>>>>>>>> The intent writer may mainly care abou= t what they want, but how to
>> do
>>>>>> it
>>>>>>>> can be left to the autonomic network to de= al with.
>>>>>>>>> Perhaps several solutions exist, and a= utonomic management system
>> choose
>>>>>>>> one according to the abilities collected.<= br> >>>>>>>>> In the ideal, the network operator may= communicate with the
>> autonomic
>>>>>>>> network using network-level level intent a= nd network-level report.
>>>>>>>>> I mean in current status, some of the = Autonomic Functions should be
>>>>>>>> exposed to the network operator, and some = of the Autonomic Functions
>>>>>> can be
>>>>>>>> hidden to the network operator
>>>>>>>>> Perhaps in future, when the network no= des become more intelligent,
>> the
>>>>>>>> hidden part will increase.
>>>>>>>>>
>>>>>>>>> Best regards
>>>>>>>>> Zongpeng Du
>>>>>>>>>
>>>>>>>>> From: Anima [mailto:anima-bounces@ietf.org<mailto:
>>>>>> anima-bo= unces@ietf.org>]
>>>>>>>> On Behalf Of John Strassner
>>>>>>>>> Sent: Thursday, March 24, 2016 10:41 A= M
>>>>>>>>> To: Michael Behringer (mbehring); John= Strassner
>>>>>>>>> Cc: Duzongpeng; Laurent Ciavaglia; She= ng Jiang; anima@ietf.org
>> <mailto:
>>>>>>>> anima@ie= tf.org>; J=C3=A9ferson Campos Nobre
>>>>>>>>> Subject: Re: [Anima] Does Autonomic ne= twork need some intervention
>>>>>>>> beyond intent
>>>>>>>>> Hi Michael,
>>>>>>>>>
>>>>>>>>> thanks for your reply. I do think that= we largely agree, and would
>>>>>> enjoy
>>>>>>>> chatting during or (hopefully before) BA. = Please see
>> <jcs2>..</jcs2>.
>>>>>> Also
>>>>>>>> trying to unclutter, so I am eliding point= s that we agree on.
>>>>>>>>>
>>>>>>>>> While *CIEs don=E2=80=99t like magic, = they do understand the concept of a
>>>>>>>> default behaviour which they can influence= if needed. Any reasonable
>>>>>>>> network management approach tries to defin= e =E2=80=9Cdefault=E2=80=9D behaviour and
>>>>>>>> =E2=80=9Cexceptions=E2=80=9D. The AN story= fills the =E2=80=9Cdefault=E2=80=9D part very nicely, and
>>>>>> *CIEs
>>>>>>>> get that.
>>>>>>>>> <jcs2>
>>>>>>>>> Agreed!
>>>>>>>>> </jcs2>
>>>>>>>>>
>>>>>>>>> The =E2=80=9Cparameter=E2=80=9D versus= =E2=80=9Cpolicy=E2=80=9D discussion: My view is that we
>>>>>> shouldn=E2=80=99t
>>>>>>>> try to define exactly *what* intent allows= and doesn=E2=80=99t allow, since
>>>>>> we=E2=80=99ve
>>>>>>>> heard from many sides that the boundary is= not clear, and it may be
>>>>>>>> impossible to have a really clear, usable = definition. So my point
>> was:
>>>>>>>> Let=E2=80=99s focus on the distribution mo= del: Intent is flooded to all
>> nodes.
>>>>>>>> Let=E2=80=99s NOT do selective flooding, u= nicast Intent to specific nodes,
>> etc,
>>>>>>>> because that would blur the boundary even = worse.
>>>>>>>>> <jcs2>
>>>>>>>>> I like flooding intent to all nodes. I= n FOCALE (v1-3, and
>> remember, v1
>>>>>>>> was 2006, almost 10 years ago), we used a = message bus and pub-sub.
>> In
>>>>>> v2,
>>>>>>>> we flooded; in v3, we went back to pub-sub= because we wanted to do
>> some
>>>>>>>> optimization and auditing. But I would be = happy to try some type of
>>>>>>>> controlled flooding again.
>>>>>>>>> </jcs2>
>>>>>>>>> My suggestion: Intent is flooded to al= l nodes in a domain. The ASA
>>>>>>>> owners define the content of what they wan= t to push in their bit of
>> the
>>>>>>>> Intent. If we insist of full flooding, we = encourage the right
>> behaviour.
>>>>>>>> And if someone really puts into his Intent= =E2=80=9Cnode A: do this; node
>> B: do
>>>>>> the
>>>>>>>> other; node C: do the third=E2=80=9D it is= awkward enough for people to
>> take a
>>>>>> step
>>>>>>>> back and think whether they=E2=80=99re doi= ng the right thing =E2=98=BA
>>>>>>>>> <jcs2>
>>>>>>>>> I agree in principle with what you sai= d. Plus, see above.
>>>>>>>>> < /jcs2>
>>>>>>>>> <jcs>
>>>>>>>>> Do you mean that the intent writer wil= l **know the difference**
>>>>>>>>> between the fabric and each autonomic = function? I hope not,
>>>>>>>>> but perhaps I'm misunderstanding y= ou...
>>>>>>>>> < /jcs>
>>>>>>>>> Not sure I understand your concern. Ye= s, in my model there is a
>> section
>>>>>>>> for the fabric, and sections for the vario= us functions. Seems a
>> natural
>>>>>>>> structure?!? <jcs2>
>>>>>>>>> The intent **writer** would have to kn= ow implementation
>>>>>>>>> details in order to place everything i= n a single file. I would
>>>>>>>>> rather not require this, and instead, = have the intent engine
>>>>>>>>> (e.g., compiler and associated logic) = do this.
>>>>>>>>> < /jcs2>
>>>>>>>>> =E2=80=9CFunction owner=E2=80=9D: Yes,= I=E2=80=99m suggesting to structure Intent around
>>>>>>>> Autonomic Functions. This is not optimal f= rom a scientific point of
>>>>>> view,
>>>>>>>> but aligns very well with the way how thin= gs are organised.
>> Probably we
>>>>>>>> need to discuss that in BA. But refer to m= y YANG model sent a few
>> days
>>>>>> ago.
>>>>>>>>> <jcs2>
>>>>>>>>> I would suggest a slight modification,= to enable users of
>>>>>>>>> intent (and even intent writers) to NO= T have to have
>>>>>>>>> detailed implementation information. >>>>>>>>>
>>>>>>>>> What if all of the Autonomic Functions= , after they joined
>>>>>>>>> the network, advertised both their cap= abilities as well as
>>>>>>>>> their needs? We can put aside the latt= er (needs) as this
>>>>>>>>> is more complex, but if the capabiliti= es are advertised,
>>>>>>>>> then the autonomic management system c= an assemble
>>>>>>>>> those needs into a catalog. Then, the = intent writer can
>>>>>>>>> look at the catalog and write a declar= ative request to
>>>>>>>>> use the functionality of the catalog.<= br> >>>>>>>>>
>>>>>>>>> I will look at your YANG model in a bi= t (sorry, I'm woefully
>>>>>>>>> behind...).
>>>>>>>>> < /jcs2>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> regards,
>>>>>>>>> John
>>>>>>>>>
>>>>>>>>> On Wed, Mar 23, 2016 at 3:57 AM, Micha= el Behringer (mbehring) <
>>>>>>>> mbeh= ring@cisco.com<mailto:mbehring= @cisco.com>> wrote:
>>>>>>>>> John,
>>>>>>>>>
>>>>>>>>> I think we=E2=80=99re on the same page= . Couple of points, top posting here,
>>>>>>>> otherwise it gets too messy.
>>>>>>>>> While *CIEs don=E2=80=99t like magic, = they do understand the concept of a
>>>>>>>> default behaviour which they can influence= if needed. Any reasonable
>>>>>>>> network management approach tries to defin= e =E2=80=9Cdefault=E2=80=9D behaviour and
>>>>>>>> =E2=80=9Cexceptions=E2=80=9D. The AN story= fills the =E2=80=9Cdefault=E2=80=9D part very nicely, and
>>>>>> *CIEs
>>>>>>>> get that.
>>>>>>>>> The =E2=80=9Cparameter=E2=80=9D versus= =E2=80=9Cpolicy=E2=80=9D discussion: My view is that we
>>>>>> shouldn=E2=80=99t
>>>>>>>> try to define exactly *what* intent allows= and doesn=E2=80=99t allow, since
>>>>>> we=E2=80=99ve
>>>>>>>> heard from many sides that the boundary is= not clear, and it may be
>>>>>>>> impossible to have a really clear, usable = definition. So my point
>> was:
>>>>>>>> Let=E2=80=99s focus on the distribution mo= del: Intent is flooded to all
>> nodes.
>>>>>>>> Let=E2=80=99s NOT do selective flooding, u= nicast Intent to specific nodes,
>> etc,
>>>>>>>> because that would blur the boundary even = worse.
>>>>>>>>> My suggestion: Intent is flooded to al= l nodes in a domain. The ASA
>>>>>>>> owners define the content of what they wan= t to push in their bit of
>> the
>>>>>>>> Intent. If we insist of full flooding, we = encourage the right
>> behaviour.
>>>>>>>> And if someone really puts into his Intent= =E2=80=9Cnode A: do this; node
>> B: do
>>>>>> the
>>>>>>>> other; node C: do the third=E2=80=9D it is= awkward enough for people to
>> take a
>>>>>> step
>>>>>>>> back and think whether they=E2=80=99re doi= ng the right thing =E2=98=BA
>>>>>>>>> <jcs>
>>>>>>>>> Do you mean that the intent writer wil= l **know the difference**
>>>>>>>>> between the fabric and each autonomic = function? I hope not,
>>>>>>>>> but perhaps I'm misunderstanding y= ou...
>>>>>>>>> </jcs>
>>>>>>>>>
>>>>>>>>> Not sure I understand your concern. Ye= s, in my model there is a
>> section
>>>>>>>> for the fabric, and sections for the vario= us functions. Seems a
>> natural
>>>>>>>> structure?!?
>>>>>>>>> =E2=80=9CFunction owner=E2=80=9D: Yes,= I=E2=80=99m suggesting to structure Intent around
>>>>>>>> Autonomic Functions. This is not optimal f= rom a scientific point of
>>>>>> view,
>>>>>>>> but aligns very well with the way how thin= gs are organised.
>> Probably we
>>>>>>>> need to discuss that in BA. But refer to m= y YANG model sent a few
>> days
>>>>>> ago.
>>>>>>>>> We should schedule some discussion tim= e outside the ANIMA meeting
>>>>>>>> window...
>>>>>>>>> Michael
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> From: John Strassner [mailto:strazpdj@gmail.com<mailto:
>>>>>>>> stra= zpdj@gmail.com>]
>>>>>>>>> Sent: 22 March 2016 21:32
>>>>>>>>> To: Michael Behringer (mbehring) <<= a href=3D"mailto:mbehring@cisco.com">mbehring@cisco.com<mailto:
>>>>>>>> mbeh= ring@cisco.com>>; John Strassner <strazpdj@gmail.com<mailto:
>>>>>>>> stra= zpdj@gmail.com>>
>>>>>>>>> Cc: Duzongpeng <duzongpeng@huawei.com<mailto:duzongpeng@huawei.com
>>>> ;
>>>>>>>> anima@ie= tf.org<mailto:anima@ietf.org&g= t;; Laurent Ciavaglia <
>>>>>>>> laurent.ciavaglia@nokia.com<mailto:laurent.ciavaglia@nokia.com>>;
>>>>>>>> J=C3=A9ferson Campos Nobre <jcnobre@inf.ufrgs.br<mailto:
>> jcnobre@inf.ufrgs.br >>>>>>>> ;
>>>>>>>> Sheng Jiang <jiangsheng@huawei.com<mailto:jiangsheng@huawei.com>>
>>>>>>>>> Subject: Re: [Anima] Does Autonomic ne= twork need some intervention
>>>>>>>> beyond intent
>>>>>>>>> In general, I agree with Michael. I= 9;d like to emphasize and expand
>> on a
>>>>>>>> couple of key points:
>>>>>>>>>
>>>>>>>>> First, ANIMA isn=E2=80=99t the only th= ing =E2=80=9Cinfluencing=E2=80=9D or =E2=80=9Csteering=E2=80=9D a
>>>>>> network,
>>>>>>>> at least not initially. There is still tra= ditional config, plus all
>> the
>>>>>>>> existing and emerging SDN models. My view = has always been that ANIMA
>>>>>> sets a
>>>>>>>> =E2=80=9Cdefault=E2=80=9D policy in a netw= ork, and all other means are more
>> specific and
>>>>>>>> can override intent. This is described in = RFC7575. Main point here:
>>>>>> ANIMA
>>>>>>>> Intent isn=E2=80=99t the only tool in a ne= twork.
>>>>>>>>> <jcs>
>>>>>>>>> Absolutely agree. Note that even in th= e Congress case I mentioned
>>>>>>>>> earlier, it is NOT pushing config, and= it is NOT viewed as the
>>>>>>>>> "only" policy
>>>>>>>>> </jcs>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Intent could perfectly well cover a hi= gh level policy such as =E2=80=9Call
>>>>>> nodes
>>>>>>>> of type x do this; type y does that=E2=80= =9D. (Which I think is what you
>> mention
>>>>>>>> below.) When we started with Intent, the v= ision was to keep it very
>> high
>>>>>>>> level, more along the line =E2=80=9Cdo the= right thing=E2=80=9D =E2=98=BA
>>>>>>>>> <jcs>
>>>>>>>>> Agreed. Although to me, this means tha= t we need to consider the
>> types
>>>>>> of
>>>>>>>> actors that are using intent. For example,= most of my CCIE and JCIE
>>>>>> friends
>>>>>>>> have no interest in using an intent langua= ge for pushing
>> configuration.
>>>>>> On
>>>>>>>> the other hand, when I talk to operators a= nd application developers,
>>>>>> they
>>>>>>>> would love to be able to use a high-level = intent and have the intent
>>>>>> engine
>>>>>>>> take care of the details for them.
>>>>>>>>> </jcs>
>>>>>>>>>
>>>>>>>>> It has become clear that in today=E2= =80=99s networking, people will want to
>>>>>> push
>>>>>>>> more =E2=80=9Cparameters=E2=80=9D than =E2= =80=9Cpolicy=E2=80=9D, and I think we=E2=80=99ll just have to
>>>>>> acknowledge
>>>>>>>> that.
>>>>>>>>> <jcs>
>>>>>>>>> Sorry Michael, I don't follow here= . What do you mean
>>>>>>>>> by "parameters"?
>>>>>>>>> </jcs>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Personally I think it=E2=80=99ll pan o= ut like this: Intent will have
>> sections
>>>>>>>> per autonomic function. An Intent parser w= ill validate overall
>>>>>> correctness
>>>>>>>> (signature, etc), then segment the Intent = into its bits: One part
>> will
>>>>>> be
>>>>>>>> the autonomic fabric itself, then there wi= ll be bits for each
>> autonomic
>>>>>>>> function.
>>>>>>>>> <jcs>
>>>>>>>>> Do you mean that the intent writer wil= l **know the difference**
>>>>>>>>> between the fabric and each autonomic = function? I hope not,
>>>>>>>>> but perhaps I'm misunderstanding y= ou...
>>>>>>>>> </jcs>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> So the Intent parser on a node will gr= ab intent, see there is some
>>>>>>>> Intent for autonomic function A, will see = whether this is running
>>>>>> locally,
>>>>>>>> and if so, it=E2=80=99ll just pass that pi= ece of Intent to that function.
>>>>>>>>> <jcs>
>>>>>>>>> Agreed.
>>>>>>>>> </jcs>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In this way, a function owner defines = both the intent itself, and
>> how
>>>>>> it
>>>>>>>> is consumed by his/her function.
>>>>>>>>> <jcs>
>>>>>>>>> I'm not sure what you mean by &quo= t;function owner". (Sorry to be
>>>>>>>>> picky, I'm likely under-caffeinate= d.)
>>>>>>>>>
>>>>>>>>> The above seemed like an autonomous de= cision, made by the parser.
>>>>>>>>> I don't think that the intent writ= er should be cognizant of how
>> many or
>>>>>>>>> what types of autonomic functions are = present.
>>>>>>>>> </jcs>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The downside is that there is no =E2= =80=9Ccontrol=E2=80=9D and people can do what
>> they
>>>>>>>> want, in the worst case even push config, = which is clearly NOT what
>>>>>> Intent
>>>>>>>> is meant to do.
>>>>>>>>> <jcs>
>>>>>>>>> And hence, the "HAL 2000" sc= enario. :-)
>>>>>>>>> </jcs>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I=E2=80=99d hope that people don=E2=80= =99t start writing Intent like =E2=80=9Cnode 17:
>> here is
>>>>>>>> your CLI; node 23: here is your CLI=E2=80= =9D; node 37: here is your CLI=E2=80=9D.
>> But
>>>>>> what
>>>>>>>> I describe above COULD be abused in this w= ay. RFC7575 says this is
>> NOT
>>>>>>>> Intent.
>>>>>>>>> <jcs>
>>>>>>>>> Absolutely agree!
>>>>>>>>> </jcs>
>>>>>>>>>
>>>>>>>>>=C2=A0 =C2=A0regards,
>>>>>>>>> John
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Mar 16, 2016 at 1:16 AM, Micha= el Behringer (mbehring) <
>>>>>>>> mbeh= ring@cisco.com<mailto:mbehring= @cisco.com>> wrote:
>>>>>>>>> Hi Zongpeng,
>>>>>>>>>
>>>>>>>>> Yes, this is a recurring question and = topic. Let me give my view
>> on two
>>>>>>>> levels:
>>>>>>>>> First, ANIMA isn=E2=80=99t the only th= ing =E2=80=9Cinfluencing=E2=80=9D or =E2=80=9Csteering=E2=80=9D a
>>>>>> network,
>>>>>>>> at least not initially. There is still tra= ditional config, plus all
>> the
>>>>>>>> existing and emerging SDN models. My view = has always been that ANIMA
>>>>>> sets a
>>>>>>>> =E2=80=9Cdefault=E2=80=9D policy in a netw= ork, and all other means are more
>> specific and
>>>>>>>> can override intent. This is described in = RFC7575. Main point here:
>>>>>> ANIMA
>>>>>>>> Intent isn=E2=80=99t the only tool in a ne= twork.
>>>>>>>>> Intent could perfectly well cover a hi= gh level policy such as =E2=80=9Call
>>>>>> nodes
>>>>>>>> of type x do this; type y does that=E2=80= =9D. (Which I think is what you
>> mention
>>>>>>>> below.) When we started with Intent, the v= ision was to keep it very
>> high
>>>>>>>> level, more along the line =E2=80=9Cdo the= right thing=E2=80=9D =E2=98=BA=C2=A0 It has become
>> clear
>>>>>> that
>>>>>>>> in today=E2=80=99s networking, people will= want to push more =E2=80=9Cparameters=E2=80=9D
>> than
>>>>>>>> =E2=80=9Cpolicy=E2=80=9D, and I think we= =E2=80=99ll just have to acknowledge that.
>>>>>>>>> Personally I think it=E2=80=99ll pan o= ut like this: Intent will have
>> sections
>>>>>>>> per autonomic function. An Intent parser w= ill validate overall
>>>>>> correctness
>>>>>>>> (signature, etc), then segment the Intent = into its bits: One part
>> will
>>>>>> be
>>>>>>>> the autonomic fabric itself, then there wi= ll be bits for each
>> autonomic
>>>>>>>> function.
>>>>>>>>> So the Intent parser on a node will gr= ab intent, see there is some
>>>>>>>> Intent for autonomic function A, will see = whether this is running
>>>>>> locally,
>>>>>>>> and if so, it=E2=80=99ll just pass that pi= ece of Intent to that function.
>>>>>>>>> In this way, a function owner defines = both the intent itself, and
>> how
>>>>>> it
>>>>>>>> is consumed by his/her function.
>>>>>>>>> The downside is that there is no =E2= =80=9Ccontrol=E2=80=9D and people can do what
>> they
>>>>>>>> want, in the worst case even push config, = which is clearly NOT what
>>>>>> Intent
>>>>>>>> is meant to do. I=E2=80=99d hope that peop= le don=E2=80=99t start writing Intent like
>>>>>> =E2=80=9Cnode
>>>>>>>> 17: here is your CLI; node 23: here is you= r CLI=E2=80=9D; node 37: here is
>> your
>>>>>>>> CLI=E2=80=9D. But what I describe above CO= ULD be abused in this way. RFC7575
>>>>>> says
>>>>>>>> this is NOT Intent.
>>>>>>>>> In other words: Let=E2=80=99s not be t= oo prescriptive, and hope that folks
>> will
>>>>>>>> do more or less reasonable things.
>>>>>>>>> I=E2=80=99ve been meaning to comment o= n the Intent drafts and possibly
>>>>>>>> contribute, I=E2=80=99m just struggling wi= th priorities at the moment (as
>> you
>>>>>> can
>>>>>>>> see by my relative silence over the past w= eeks).
>>>>>>>>> Michael
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> From: Anima [mailto:anima-bounces@ietf.org<mailto:
>>>>>> anima-bo= unces@ietf.org>]
>>>>>>>> On Behalf Of Duzongpeng
>>>>>>>>> Sent: 16 March 2016 02:38
>>>>>>>>> To: = anima@ietf.org<mailto:anima@ietf.o= rg>
>>>>>>>>> Cc: Laurent Ciavaglia <laurent.ciavaglia@nokia.com<mailt= o:
>>>>>>>> laurent.ciavaglia@nokia.com>>; J=C3=A9ferson Campos Nobre &l= t;
>>>>>> jcnobre@in= f.ufrgs.br
>>>>>>>> <mailto:jcnobre@inf.ufrgs.br>>; Sheng Jiang <jiangsheng@huawei.com
>>>>>> <mailto:
>>>>>>>> j= iangsheng@huawei.com>>
>>>>>>>>> Subject: [Anima] Does Autonomic networ= k need some intervention
>> beyond
>>>>>>>> intent
>>>>>>>>> Hello, everyone
>>>>>>>>>
>>>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0I understand that Autonomic network should be able to
>> work
>>>>>> with
>>>>>>>> as less configuration as possible. In the = ideal case, an Autonomic
>>>>>> network
>>>>>>>> should be able to work well while only int= ent is needed from human
>>>>>>>> operators.
>>>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0However, I wonder whether Autonomic network may need some
>>>>>>>> intervention from human operators through = some low-level policies
>> beyond
>>>>>>>> intents.
>>>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0For example, in the
>>>>>>>> ht= tps://tools.ietf.org/html/draft-ietf-anima-prefix-management-00,
>> it
>>>>>> is
>>>>>>>> suggested that the prefix lengths for the = CSG, ASG, RSG (different
>>>>>> roles in
>>>>>>>> IP RAN) can be assigned as an "intent= ". These configuration
>> parameters
>>>>>> need
>>>>>>>> to be distributed in the autonomic domain = to influence the detail
>>>>>>>> configurations on each autonomic node.
>>>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0As intent is described as an abstract, declarative,
>> high-level
>>>>>>>> policy used to operate an autonomic domain= , such as an enterprise
>>>>>> network.
>>>>>>>> Perhaps we can rename the =E2=80=9Cintent= =E2=80=9D in the =E2=80=9Cprefix-management ID=E2=80=9D to
>> some
>>>>>>>> other words.
>>>>>>>>> Is =E2=80=9CASA parameters" ok he= re?
>>>>>>>>>
>>>>>>>>> I think some characteristics for this = kind of low-level policies
>> are
>>>>>>>>>
>>>>>>>>> 1.=C2=A0 =C2=A0 =C2=A0 =C2=A0Network l= evel parameters, need to be distributed by GRASP
>> and
>>>>>>>> ACP
>>>>>>>>> 2.=C2=A0 =C2=A0 =C2=A0 =C2=A0Relativel= y static compared to intent, perhaps only needed
>> to
>>>>>> be
>>>>>>>> configured once
>>>>>>>>> 3.=C2=A0 =C2=A0 =C2=A0 =C2=A0Unavoidab= le in current network environment, mostly for
>>>>>>>> establishing the network infrastructure >>>>>>>>> 4.=C2=A0 =C2=A0 =C2=A0 =C2=A0Rarely ne= ed coordinations with others parameters, usually
>> is
>>>>>>>> closed related to one specific autonomic f= unction
>>>>>>>>> Welcome for comment. Your suggestions = will be appreciated.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best Regards
>>>>>>>>> Zongpeng Du
>>>>>>>>>
>>>>>>>>> ______________________________________= _________
>>>>>>>>> Anima mailing list
>>>>>>>>> Anim= a@ietf.org<mailto:Anima@ietf.org>
>>>>>>>>> https://www.ietf.org= /mailman/listinfo/anima
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> regards,
>>>>>>>>> John
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> regards,
>>>>>>>>> John
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> regards,
>>>>>>>>> John
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ______________________________________= _________
>>>>>>>>> Anima mailing list
>>>>>>>>> Anim= a@ietf.org
>>>>>>>>> https://www.ietf.org= /mailman/listinfo/anima
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>
>




--
regards,
John
--001a11401f3c584374052f9ff0c9-- From nobody Mon Apr 4 07:48:10 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E51D12D72D for ; Mon, 4 Apr 2016 07:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 CSPHeF5TWMsO for ; Mon, 4 Apr 2016 07:48:03 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A47B12D175 for ; Mon, 4 Apr 2016 07:48:03 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 792582002A; Mon, 4 Apr 2016 10:51:27 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 47B4D6375A; Mon, 4 Apr 2016 10:48:02 -0400 (EDT) From: Michael Richardson To: "Michael Behringer \(mbehring\)" In-Reply-To: <1341e3fd501e4cbb8cbe9fbdc1d158de@XCH-RCD-006.cisco.com> References: <56FBFA6A.4010400@alcatel-lucent.com> <1341e3fd501e4cbb8cbe9fbdc1d158de@XCH-RCD-006.cisco.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: Duzongpeng , Laurent Ciavaglia , anima , Pierre Peloso Subject: Re: [Anima] ANIMA intent discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 14:48:06 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Michael Behringer (mbehring) wrote: > We=E2=80=99re starting to call everything that flies through an auton= omic > network Intent, and the naming is getting very confusing. > To me: Intent =3D network wide human input policy okay. So to use the server load situation, the Intent from the human might = be: "Keep all CPUs between 50% and 70% utilization" (The Human might even specify this more abstractly as: "Minimize power consumption, while protecting against CPU load spikes of up to 30%") > everything else: not Intent. Call it signaling, messaging, feedback > loops, SNMP, GRASP, whatever. So, a node that finds itself at lower than 50% utilization wants to migrate it's load elsewhere, and so it needs to signal that it is looking for something to take over so that it can turn itself off. That's a signal. Is that signal in scope? =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVwJ+n4CLcPvd0N1lAQL8jQf+J3ZOcBfEKAsH3QdOn2/VsJMT5vyP1ql+ pL/eqy3ro4VJZU3a0BlH9sZuUxeVPY3mKMZqHGRiQV/yPynp643zJzq5RmnhJTZF nLlh4GxGlWoUuGicZH5qy5dHdW3EozIiwuleJpGiUErZsLkJMt7lAPtAvJzLFmnR BAKHMf/bZ/GVufS2F7cXaTvAzBXwc8VZTTSswtzrh7y/pg7LJFXS1kgtEN5rYM0V cNTw4fw6okSbzku2Sp9nKhqn39tq4UeBT/Fd82B7mtRBmbR25ey3fy0cnupvxh9H UXKhC8fhC4AUTzSuR9pw5REFQQgfTeqira9cZufdV3oxxo4lJWbwZA== =fzxk -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Apr 4 07:53:17 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578DF12D74B for ; Mon, 4 Apr 2016 07:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 We-JaEj2vQX1 for ; Mon, 4 Apr 2016 07:52:42 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D031912D750 for ; Mon, 4 Apr 2016 07:52:08 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3CF522002A; Mon, 4 Apr 2016 10:55:33 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 04A5E6375A; Mon, 4 Apr 2016 10:52:08 -0400 (EDT) From: Michael Richardson To: "Joel M. Halpern" In-Reply-To: <56FE7492.1070308@joelhalpern.com> References: <56FBFA6A.4010400@alcatel-lucent.com> <1341e3fd501e4cbb8cbe9fbdc1d158de@XCH-RCD-006.cisco.com> <56FE7492.1070308@joelhalpern.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: Duzongpeng , Laurent Ciavaglia , anima , "Michael Behringer \(mbehring\)" , Pierre Peloso Subject: Re: [Anima] ANIMA intent discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 14:52:52 -0000 --=-=-= Content-Type: text/plain Joel M. Halpern wrote: > 1) Intent: Turn of admission of new nodes to the system. This is human > generate, in response to observed but unspecified conditions. It applies > from now until the human turns it off. Anima can act on this. I don't like this Intent; and I don't think that ANIMA Intents can be turned on/off, but rather given expiration dates which may be extended. Maybe that's a detail, but I think it's important that ANIMA Intents are never withdrawn. > 2) Intent: If average network link load exceeds 70%, do not admit any new > nodes to the system. This is also a human defined intent. However, I do not > see how this intent can be distributed to the Anima participants and acted > on. It has to be processed by some other system. And when the condition is > observed, the system will generate something like intent 1, which will be > processed by Anima, even thout it is not directly human input. The proxy/registrar, upon seeing this ANIMA Intent would have to do an ASA search for a system that would provide them with *AVERAGE* "network link load". An NMS might be able to respond to such an ASA search, but might then issue an ASA asking all nodes to report "network link load" to that NMS. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVwJ/lYCLcPvd0N1lAQIwrggAtRUZZB6Ab504DOdrK2pJ5aTD+ju/UDD1 /uWl4jsVyknufSzhWmPE/Cyum7tpVqUzLkxp2fpN+MUsZYwpQRVl6/N/qBOdw+l5 MOG3sZ8XY3HDMBEfT6mEpeHp71nrJVqY4IyiLmy1D0KAaNksaRBTRXIintC6RE97 2WB5L8JE4a/zmORyBaZVY9Y10Q0PPGxiWiUKCBh2JKM+1rBigOmmqcuz9LTCmP/0 FBUF3B9H+y9BJ9qcD4Ms5rcjbJEWgp+nkX+kweppJU5EPr5535B7/l/nGhXE0jTX lfsChUGFJCkRFcNf9XOcEStMqvQdvwrZpo2X74Wy2QXI0Xtkz1v3NA== =ppFQ -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Apr 4 07:54:42 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420E912D616 for ; Mon, 4 Apr 2016 07:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 rdkmOYQljdng for ; Mon, 4 Apr 2016 07:54:38 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D6A312D792 for ; Mon, 4 Apr 2016 07:54:07 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BE9612002A; Mon, 4 Apr 2016 10:57:31 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 86AE76375A; Mon, 4 Apr 2016 10:54:06 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter In-Reply-To: <57006D4A.6070005@gmail.com> References: <56FBFA6A.4010400@alcatel-lucent.com> <57006D4A.6070005@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: Laurent Ciavaglia , Pierre Peloso , Duzongpeng , Michael Behringer , John Strassner , anima Subject: Re: [Anima] ANIMA intent discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 14:54:40 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> I do not think that it is necessary to combine disparate >> intents into a single file. > That seems to mean that each recipient of multiple files has to > performance consistency checks and conflict resolution, unless > you have a watertight definition of 'disparate'. Yes/no. That could be a service from a device on the network to resolve them and issue revised Intents. For instance, de-corolating conflicting policies. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVwKAC4CLcPvd0N1lAQJLkAf/fetCtwS9C6sDkFdsOQxLcPzGaXcl0Cq8 MsKQKEK4i2w2nBe6Ecmq9CJ5fmpz5WO2ZfBRtRLMBkxkA0etBifIbU7y92CUO/OL WTSRXvt+y/p0QYZFQrm+YlcO42evG/N8qRVLIaBNpHXD5h0FxBbY/8y9nvKw5rhl 7t99uimPJEOcElARgPzCBQT9lFiywSk4KQ7LeCd9EPaHCUpKg3kUTz2NwC2v3RhD DIObAeevlJy6LxMBRb5qtiYgUk5JSZ0TnYeYC4NLJ1IhNWsFWy5BbH9bLazsdsP0 tRY7j50zmlpwhYLxZ1Ey9PNWtODw+j1gSY2xEWaZaE8Nvhy4YW3AIg== =1kJ5 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Apr 4 07:56:39 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80AFC12D7B9 for ; Mon, 4 Apr 2016 07:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 j84NaVBG3uuO for ; Mon, 4 Apr 2016 07:56:36 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51EA412D616 for ; Mon, 4 Apr 2016 07:56:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 2DCF6240A0A; Mon, 4 Apr 2016 07:56:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1459781780; bh=ysNLqDixrUgxpB4DKoVB3+YzBVB2R5ha3g5QOCrIG6M=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=TgM/QYyhpy2UpfMdcMIa8T4BK9IhoaiWaQnddCnpJ27s4jo938pKGcwCRTXgbMxRf 1LmmwmZd8e5iE3oa5m4+7PJ5+C+XjVOb6tuAkLNBoAiVqoRVWZEkLWeg0j+MOHFqE0 Ou30kRTkuROyx55VmmZFuq0OxFnFDC8TcOFbn3Rw= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from dhcp-b496.meeting.ietf.org (dhcp-b496.meeting.ietf.org [31.133.180.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id C39FC240345; Mon, 4 Apr 2016 07:56:18 -0700 (PDT) To: Michael Richardson References: <56FBFA6A.4010400@alcatel-lucent.com> <1341e3fd501e4cbb8cbe9fbdc1d158de@XCH-RCD-006.cisco.com> <56FE7492.1070308@joelhalpern.com> <31002.1459781527@obiwan.sandelman.ca> From: "Joel M. Halpern" Message-ID: <57028091.1060305@joelhalpern.com> Date: Mon, 4 Apr 2016 10:56:17 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <31002.1459781527@obiwan.sandelman.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Duzongpeng , Laurent Ciavaglia , anima , Pierre Peloso Subject: Re: [Anima] ANIMA intent discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 14:56:37 -0000 I must be missing something. You say "I don't think that ANIMA Intents can be turned on/off." I can't parse that. Two attempts: A) Clearly, there can be an intent not to allow something. WHether the intent it to turn off all admissions, or to prohibit all miliious traffic (if only we could), there are clearly negative intents as well as positive intents. B) Equally clearly, the human beings who originate intents can change their minds temporarily or permanently. Policies get changed (permanent), and sometimes people decide based on information outside the system scope taht policies need to be temporarily changed. So I don't know what you mean when you say that intents can't be turned off. Yours, Joel On 4/4/16 10:52 AM, Michael Richardson wrote: > > Joel M. Halpern wrote: > > 1) Intent: Turn of admission of new nodes to the system. This is human > > generate, in response to observed but unspecified conditions. It applies > > from now until the human turns it off. Anima can act on this. > > I don't like this Intent; and I don't think that ANIMA Intents can be turned > on/off, but rather given expiration dates which may be extended. Maybe > that's a detail, but I think it's important that ANIMA Intents are never > withdrawn. From nobody Mon Apr 4 11:38:38 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C25512D0A8 for ; Mon, 4 Apr 2016 11:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 bCWHbCXfa4Wp for ; Mon, 4 Apr 2016 11:38:35 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A90CA12D7CB for ; Mon, 4 Apr 2016 11:38:35 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9DE22200A3 for ; Mon, 4 Apr 2016 14:42:00 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D4EB86375A for ; Mon, 4 Apr 2016 14:38:34 -0400 (EDT) From: Michael Richardson To: anima In-Reply-To: <57028091.1060305@joelhalpern.com> References: <56FBFA6A.4010400@alcatel-lucent.com> <1341e3fd501e4cbb8cbe9fbdc1d158de@XCH-RCD-006.cisco.com> <56FE7492.1070308@joelhalpern.com> <31002.1459781527@obiwan.sandelman.ca> <57028091.1060305@joelhalpern.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] ANIMA intent discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 18:38:37 -0000 --=-=-= Content-Type: text/plain Joel M. Halpern wrote: > I must be missing something. You say "I don't think that ANIMA Intents can > be turned on/off." I can't parse that. Two attempts: > A) Clearly, there can be an intent not to allow something. WHether the > intent it to turn off all admissions, or to prohibit all miliious traffic (if > only we could), there are clearly negative intents as well as positive > intents. Yes, an Intent could be published to permit or deny something. That would be an ANIMA Intent to turn off traffic, and you'd have to 'Turn on' (publish) such an Intent. > B) Equally clearly, the human beings who originate intents can change their > minds temporarily or permanently. Policies get changed (permanent), and > sometimes people decide based on information outside the system scope taht > policies need to be temporarily changed. > So I don't know what you mean when you say that intents can't be turned > off. I'm saying that I don't think that ANIMA Intents should be published ("turned on") and then "withdrawn" (turned off). I think that they should only be published so that we don't have to worry about having old things lingering in systems. So this leaves us with two non-mutually exclusive possible ways to do things: 1) the CRL way -- you publish a new Intent identifying the ANIMA Intent that you want to anul by unique ID, and say that it's dead. New Intent is subject to the same flooding/distribution as the old one. 2) the expiry way -- all Intents should expire. If not renewed, they just die on their own. PKIX uses both mechanism, but the trend it towards using short expiry times and online renewals. (ACME is doing that). While we do have the OCSP, I find it silly in many ways... why even have a certificate authority if you are going to ask everyone online. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVwK0qICLcPvd0N1lAQJyfwf7BoaE8Px2mzWi7OJxo5eOo4n218yjmJuo fILr2SC3K8ZZF7cdyV8vTM0q69pe9wpM7qJkmI8hUYCnwGBiYBGcIzfNumUaF7Mx OWQxsryihWE1sMmWm3aHGomCT8CVgZOdqOjqCLpjLEt2DY2vtviiGngaBzdB662E KI9zyYBaWurXfrFoUz9MWdQ/iXrY/Kq+o7NZ5JmIH54wJflPOrNW2/0etMADd6Fp RH9jGpwtHX4Q3atB99aiwnY1aL6bh9hT8tIm5Eau2/zqqb1i8KCbncVQMdbA4jYl ILIUc2VaXfQ08lWCzANSCyogy1Bx0RgjlmvKqHbUAHWO0gwdDywSLg== =EAgs -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Apr 4 12:54:48 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0536B12D858 for ; Mon, 4 Apr 2016 12:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 4g3p1gi0E3e2 for ; Mon, 4 Apr 2016 12:54:44 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A815212D83F for ; Mon, 4 Apr 2016 12:54:43 -0700 (PDT) Received: by mail-pa0-x22f.google.com with SMTP id zm5so150646069pac.0 for ; Mon, 04 Apr 2016 12:54:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=TBI8jI19UiH2YO6hPcBoPeiK8GVOwnQulsCkymBBK00=; b=PSLZ2LcjUdjyjT5U6Mk2VO2wrU2Ix5YqWZsDYs1qRM2xbR1pkPLu6RaXJkEtBF2qnJ c9qZzc0w5QxAxbqE71R0DHB7eCIOHfMDUPg1JUWR2/BC5uOKo3XJzgBlhE9FBuIVVqg7 5I5MnfCcC8Tnb4grII3HXWEXr2jiqbBdiNsqmLbfZODA2bXgcq7p836mfkjCikPuNkCy Sa+SW55jehvlfNU2ibrlUieKrjtavcfjpOkDxlgqjqgKWWT37JKgZMJYYwFQEYBhZUDw cVu8V2Z+D8CAFTDDbmEq8UpFSFvMaP+1hpywksuY5dRe9+hocn+upvFAAL6hkNvN4Qap m83A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=TBI8jI19UiH2YO6hPcBoPeiK8GVOwnQulsCkymBBK00=; b=nHU5OZMxb+JbSDwr8gRSGgX0ieCrflce/IN+PAAl4n6/DER4BcLFtA88J5EhO7RVUM CtHz60yDS40yruc908am8um6xwiY4DuDv4qlVS9tummONMyqzSTU6NtXBsen3V5LNIEV hegNsLs8mKgZRaMKgDQ5h8P/dNL7qDgfAPxZTbOCKjMb2t+aKK4n1309A0bqqJsJaKW7 j5qZj/WMdIESRiIQsAyC0aJ3YcuzTUhQgPL81yIlCrpRVx5IREeV3+XLu1sqfjD/4ZAZ WitQbb8tsQpOU0Dgkn2r2yyqq22DyrAKF1FOswkM0OXsIEft9Pqzmk/wydM7XY9V/fFh fRkg== X-Gm-Message-State: AD7BkJJsl1KU18+5NY4H/ugkEYnav+YZmNr/H4zYGQCBQi2eFrsmhh7UdxHw02cEvTUdNw== X-Received: by 10.66.255.39 with SMTP id an7mr55985204pad.2.1459799683340; Mon, 04 Apr 2016 12:54:43 -0700 (PDT) Received: from ?IPv6:2406:e007:6365:1:28cc:dc4c:9703:6781? ([2406:e007:6365:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id p85sm41432335pfj.16.2016.04.04.12.54.39 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Apr 2016 12:54:42 -0700 (PDT) To: Michael Richardson , "Michael Behringer (mbehring)" References: <56FBFA6A.4010400@alcatel-lucent.com> <1341e3fd501e4cbb8cbe9fbdc1d158de@XCH-RCD-006.cisco.com> <30089.1459781282@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5702C67E.3060704@gmail.com> Date: Tue, 5 Apr 2016 07:54:38 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <30089.1459781282@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Duzongpeng , Laurent Ciavaglia , anima , Pierre Peloso Subject: Re: [Anima] ANIMA intent discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 19:54:47 -0000 On 05/04/2016 02:48, Michael Richardson wrote: >=20 > Michael Behringer (mbehring) wrote: > > We=E2=80=99re starting to call everything that flies through an a= utonomic > > network Intent, and the naming is getting very confusing. >=20 > > To me: Intent =3D network wide human input policy >=20 > okay. So to use the server load situation, the Intent from the human mi= ght be: > "Keep all CPUs between 50% and 70% utilization" >=20 > (The Human might even specify this more abstractly as: > "Minimize power consumption, while protecting against CPU load spi= kes > of up to 30%") >=20 > > everything else: not Intent. Call it signaling, messaging, feedba= ck > > loops, SNMP, GRASP, whatever. >=20 > So, a node that finds itself at lower than 50% utilization wants to mig= rate > it's load elsewhere, and so it needs to signal that it is looking for > something to take over so that it can turn itself off. That's a signal= =2E >=20 > Is that signal in scope? IMHO, definitely. It sounds like a classical negotiation, where the load-= management ASA concerned discovers and negotiates with another load-management ASA t= o migrate some or all of its load. And if two nodes running at 30% each found each = other, the negotiation would need a tie-break rule to decide which one took the = load and which one closed down. Brian From nobody Mon Apr 4 13:49:36 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF43912D88F for ; Mon, 4 Apr 2016 13:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 OA4KgNELYbT2 for ; Mon, 4 Apr 2016 13:49:34 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ABC112D870 for ; Mon, 4 Apr 2016 13:49:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id D97D31C0367; Mon, 4 Apr 2016 13:49:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1459802973; bh=DcUr0UdA3AtBXBZaLLpCLWalWghbqsTwd8qGvy+ljgw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Vz7maakBD555FmAGVbziMO4rQRoqX66ycPZk2Vr6QsBClN19KUShMRgHGzrtZcLg0 hZan3zaHgbS782Li5HBMsgsWbz/RBgIfXjYxKxezjvZ4JFdjAZm+z8eAcApbUIxJIR MyWy34Zf3J62eFuh80IHby545ZBrh4TmLIP8FmEE= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from dhcp-b496.meeting.ietf.org (dhcp-b496.meeting.ietf.org [31.133.180.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 145AF1C0B73; Mon, 4 Apr 2016 13:49:32 -0700 (PDT) To: Michael Richardson , anima References: <56FBFA6A.4010400@alcatel-lucent.com> <1341e3fd501e4cbb8cbe9fbdc1d158de@XCH-RCD-006.cisco.com> <56FE7492.1070308@joelhalpern.com> <31002.1459781527@obiwan.sandelman.ca> <57028091.1060305@joelhalpern.com> <16723.1459795114@obiwan.sandelman.ca> From: "Joel M. Halpern" Message-ID: <5702D35B.7060005@joelhalpern.com> Date: Mon, 4 Apr 2016 16:49:31 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <16723.1459795114@obiwan.sandelman.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] ANIMA intent discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 20:49:36 -0000 Hmmm. Yes, the system could work by having policies expire quickly, and be refreshed in a timely fashion. However, since policy may change at any time, there would still need to be a way to say that some policy no longer applies, and a new policy has superceded it. If we really want no delete / over-ride, we have to keep the timeouts very short, and spend a lot of resource reflooding identical policies with new expirations. I am not seeing the benefits of such a behavior. We are not dealing with a highly loosely coupled system, such as web certifications. Yours, Joel On 4/4/16 2:38 PM, Michael Richardson wrote: > > Joel M. Halpern wrote: > > I must be missing something. You say "I don't think that ANIMA Intents can > > be turned on/off." I can't parse that. Two attempts: > > > A) Clearly, there can be an intent not to allow something. WHether the > > intent it to turn off all admissions, or to prohibit all miliious traffic (if > > only we could), there are clearly negative intents as well as positive > > intents. > > Yes, an Intent could be published to permit or deny something. > That would be an ANIMA Intent to turn off traffic, and you'd have to 'Turn > on' (publish) such an Intent. > > > B) Equally clearly, the human beings who originate intents can change their > > minds temporarily or permanently. Policies get changed (permanent), and > > sometimes people decide based on information outside the system scope taht > > policies need to be temporarily changed. > > > So I don't know what you mean when you say that intents can't be turned > > off. > > I'm saying that I don't think that ANIMA Intents should be published ("turned > on") and then "withdrawn" (turned off). I think that they should only be > published so that we don't have to worry about having old things lingering in > systems. > > So this leaves us with two non-mutually exclusive possible ways to do things: > > 1) the CRL way -- you publish a new Intent identifying the ANIMA Intent that > you want to anul by unique ID, and say that it's dead. New Intent is > subject to the same flooding/distribution as the old one. > > 2) the expiry way -- all Intents should expire. If not renewed, they just > die on their own. > > PKIX uses both mechanism, but the trend it towards using short expiry times > and online renewals. (ACME is doing that). While we do have the OCSP, I find > it silly in many ways... why even have a certificate authority if you are > going to ask everyone online. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Tue Apr 5 12:46:19 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 857C012D63B for ; Tue, 5 Apr 2016 12:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 di6in8xHhjq9 for ; Tue, 5 Apr 2016 12:46:15 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77DDF12D642 for ; Tue, 5 Apr 2016 12:46:12 -0700 (PDT) Received: by mail-lb0-x230.google.com with SMTP id bc4so16270173lbc.2 for ; Tue, 05 Apr 2016 12:46:12 -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; bh=GrU03mCFhPpsydIMwhDcGcVXbTKGytCH8LjQU4sOatw=; b=F0XRY6lGkJQ6GrtAijFUeAsMcjhjjTUQSUQJNtUkdUS8p+lXK4AYOI3sksQ5tWr2KV dhJlLN86gCLvCYyAN7TFMJfH/yjh3E+Qm0zzk0fOTOw3dHx4T/Hpl+JEoLgHfhwrQf9k zRNQZ5Oj9uLyKCso4G4MWBwwg2kh5BWQLdtHf06hhJhnoB62m480RLR73t5SSBnf4maw ZKMxWrt3NioDi3htq/vmVM9Kz52f6bOJWrjvWbUKp0ydf1jkkJ8nfbRpG8GhlPj97QUF mQ3o++yok4VYK2C7XtHmzvkpT1ezQXZ9lTl78wlDGYhdEjK2UzrOFeUUWJnJLI+6vnoW hrjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=GrU03mCFhPpsydIMwhDcGcVXbTKGytCH8LjQU4sOatw=; b=my8jK8MHg0sV9c8bKQR3b7xzIc3LJMIbUc6F3XkuaAKt2D5PBw29xLxvmFrxdxH8c+ FjzeN5WL4yag1P93aeCI9AeZeuVlYzfakxK1ZYU0q8VASkYchQ8ayK+uvX5a24um/GXr dCQd3eEOu16BYanRR9idqjh3G+DEgkqQgdP8KCYeYFotg+nsMfZr+cFp/wpXOTMWXINf dfY/NoZUtxorpKvxxRFD9VBdRBLYuoxR4X2XBKY32SIp0rkwGlwbV3fSlSFlkx/cMRtJ dSPbfqgze7JUd7SSp3WhZ6eCDuw1xNBAp2xteOHYehqj8d5C08gnyDpirwxos0DHzubm ea8g== X-Gm-Message-State: AD7BkJLc61ZqiiPuVkuZJLGu61yfVkceg2p6+S9r5iTP4+RoqL494nC+JepKxJ+zGwFAwOotN+PO8v2kWYjz6Q== MIME-Version: 1.0 X-Received: by 10.112.84.202 with SMTP id b10mr9128128lbz.41.1459882048722; Tue, 05 Apr 2016 11:47:28 -0700 (PDT) Received: by 10.25.22.19 with HTTP; Tue, 5 Apr 2016 11:47:28 -0700 (PDT) In-Reply-To: <5702D35B.7060005@joelhalpern.com> References: <56FBFA6A.4010400@alcatel-lucent.com> <1341e3fd501e4cbb8cbe9fbdc1d158de@XCH-RCD-006.cisco.com> <56FE7492.1070308@joelhalpern.com> <31002.1459781527@obiwan.sandelman.ca> <57028091.1060305@joelhalpern.com> <16723.1459795114@obiwan.sandelman.ca> <5702D35B.7060005@joelhalpern.com> Date: Tue, 5 Apr 2016 11:47:28 -0700 Message-ID: From: John Strassner To: "Joel M. Halpern" , John Strassner Content-Type: multipart/alternative; boundary=001a1135ea06ed9e71052fc14627 Archived-At: Cc: Michael Richardson , anima Subject: Re: [Anima] ANIMA intent discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 05 Apr 2016 19:46:17 -0000 --001a1135ea06ed9e71052fc14627 Content-Type: text/plain; charset=UTF-8 (Hmmm)^2 I agree with Joel. In past implementations, the intent writer is tightly coupled to the agent (or node) that is transforming the intent into a form that is consumable by the ANI. While the ANI is highly distributed, I do not think that it is loosely coupled either. regards, John On Mon, Apr 4, 2016 at 1:49 PM, Joel M. Halpern wrote: > Hmmm. > > Yes, the system could work by having policies expire quickly, and be > refreshed in a timely fashion. However, since policy may change at any > time, there would still need to be a way to say that some policy no longer > applies, and a new policy has superceded it. > > If we really want no delete / over-ride, we have to keep the timeouts very > short, and spend a lot of resource reflooding identical policies with new > expirations. I am not seeing the benefits of such a behavior. We are not > dealing with a highly loosely coupled system, such as web certifications. > > Yours, > Joel > > On 4/4/16 2:38 PM, Michael Richardson wrote: > >> >> Joel M. Halpern wrote: >> > I must be missing something. You say "I don't think that ANIMA >> Intents can >> > be turned on/off." I can't parse that. Two attempts: >> >> > A) Clearly, there can be an intent not to allow something. >> WHether the >> > intent it to turn off all admissions, or to prohibit all miliious >> traffic (if >> > only we could), there are clearly negative intents as well as >> positive >> > intents. >> >> Yes, an Intent could be published to permit or deny something. >> That would be an ANIMA Intent to turn off traffic, and you'd have to 'Turn >> on' (publish) such an Intent. >> >> > B) Equally clearly, the human beings who originate intents can >> change their >> > minds temporarily or permanently. Policies get changed >> (permanent), and >> > sometimes people decide based on information outside the system >> scope taht >> > policies need to be temporarily changed. >> >> > So I don't know what you mean when you say that intents can't be >> turned >> > off. >> >> I'm saying that I don't think that ANIMA Intents should be published >> ("turned >> on") and then "withdrawn" (turned off). I think that they should only be >> published so that we don't have to worry about having old things >> lingering in >> systems. >> >> So this leaves us with two non-mutually exclusive possible ways to do >> things: >> >> 1) the CRL way -- you publish a new Intent identifying the ANIMA Intent >> that >> you want to anul by unique ID, and say that it's dead. New Intent is >> subject to the same flooding/distribution as the old one. >> >> 2) the expiry way -- all Intents should expire. If not renewed, they just >> die on their own. >> >> PKIX uses both mechanism, but the trend it towards using short expiry >> times >> and online renewals. (ACME is doing that). While we do have the OCSP, I >> find >> it silly in many ways... why even have a certificate authority if you are >> going to ask everyone online. >> >> -- >> Michael Richardson , Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> >> >> >> _______________________________________________ >> 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 > -- regards, John --001a1135ea06ed9e71052fc14627 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
(Hmmm)^2

I agree with Joel. = In past implementations, the intent writer is tightly coupled to the agent = (or node) that is transforming the intent into a form that is consumable by= the ANI. While the ANI is highly distributed, I do not think that it is lo= osely coupled either.

regards,
John

On Mon, Ap= r 4, 2016 at 1:49 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
Hmmm.

Yes, the system could work by having policies expire quickly, and be refres= hed in a timely fashion.=C2=A0 However, since policy may change at any time= , there would still need to be a way to say that some policy no longer appl= ies, and a new policy has superceded it.

If we really want no delete / over-ride, we have to keep the timeouts very = short, and spend a lot of resource reflooding identical policies with new e= xpirations.=C2=A0 I am not seeing the benefits of such a behavior.=C2=A0 We= are not dealing with a highly loosely coupled system, such as web certific= ations.

Yours,
Joel

On 4/4/16 2:38 PM, Michael Richardson wrote:

Joel M. Halpern <jmh@joelhalpern.com> wrote:
=C2=A0 =C2=A0 =C2=A0> I must be missing something.=C2=A0 You say "I= don't think that ANIMA Intents can
=C2=A0 =C2=A0 =C2=A0> be turned on/off."=C2=A0 I can't parse th= at.=C2=A0 Two attempts:

=C2=A0 =C2=A0 =C2=A0> A) Clearly, there can be an intent not to allow so= mething.=C2=A0 WHether the
=C2=A0 =C2=A0 =C2=A0> intent it to turn off all admissions, or to prohib= it all miliious traffic (if
=C2=A0 =C2=A0 =C2=A0> only we could), there are clearly negative intents= as well as positive
=C2=A0 =C2=A0 =C2=A0> intents.

Yes, an Intent could be published to permit or deny something.
That would be an ANIMA Intent to turn off traffic, and you'd have to &#= 39;Turn
on' (publish) such an Intent.

=C2=A0 =C2=A0 =C2=A0> B) Equally clearly, the human beings who originate= intents can change their
=C2=A0 =C2=A0 =C2=A0> minds temporarily or permanently.=C2=A0 Policies g= et changed (permanent), and
=C2=A0 =C2=A0 =C2=A0> sometimes people decide based on information outsi= de the system scope taht
=C2=A0 =C2=A0 =C2=A0> policies need to be temporarily changed.

=C2=A0 =C2=A0 =C2=A0> So I don't know what you mean when you say tha= t intents can't be turned
=C2=A0 =C2=A0 =C2=A0> off.

I'm saying that I don't think that ANIMA Intents should be publishe= d ("turned
on") and then "withdrawn" (turned off).=C2=A0 I think that t= hey should only be
published so that we don't have to worry about having old things linger= ing in
systems.

So this leaves us with two non-mutually exclusive possible ways to do thing= s:

1) the CRL way -- you publish a new Intent identifying the ANIMA Intent tha= t
=C2=A0 =C2=A0 you want to anul by unique ID, and say that it's dead.=C2= =A0 New Intent is
=C2=A0 =C2=A0 subject to the same flooding/distribution as the old one.

2) the expiry way -- all Intents should expire.=C2=A0 If not renewed, they = just
=C2=A0 =C2=A0 die on their own.

PKIX uses both mechanism, but the trend it towards using short expiry times=
and online renewals. (ACME is doing that).=C2=A0 While we do have the OCSP,= I find
it silly in many ways... why even have a certificate authority if you are going to ask everyone online.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
=C2=A0 -=3D IPv6 IoT consulting =3D-





_______________________________________________
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



--
regards,
John
--001a1135ea06ed9e71052fc14627-- From nobody Tue Apr 5 12:59:33 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFB212D80F for ; Tue, 5 Apr 2016 12:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 SXoEEPI7xrPn for ; Tue, 5 Apr 2016 12:59:29 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A52812D7FC for ; Tue, 5 Apr 2016 12:59:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32500; q=dns/txt; s=iport; t=1459886369; x=1461095969; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=L+IB/0hRxN78/858mTxv/fwQt08B8DrM6iv36v0NDyI=; b=GxN2+SeshOnSnTUsUGa2GKJs9ccDTtuuOltWCRuXdXwiMopOKpbJfX+n JDrvXNseBIOfEBj7fXuqJstpnW1sQBtiN103n/ZcldmM/Dr9p1G1c9cP2 EvWcU9Q1jWT67IyZUY3j5txQ6iNx4VceHToH6nBWXWP/r686QvdIK/bDZ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAgDDGARX/5BdJa1egmtMU30Gr16LV?= =?us-ascii?q?QENgXIXAQmCPIMwAhyBJzgUAQEBAQEBAWUnhEEBAQEDAQEBASAKQQsFCwIBCA4?= =?us-ascii?q?DBAEBASAHAwICAh8GCxQJCAIEAQ0FCIgKAwoIDq5jjF4NhQoBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQERBIYghEuCQYIrCYJKglYFkxiEODEBjBKBbo8Wh0SHVQEeAQF?= =?us-ascii?q?Cg2lshnokG34BAQE?= X-IronPort-AV: E=Sophos; i="5.24,445,1454976000"; d="scan'208,217"; a="90365801" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Apr 2016 19:59:28 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u35JxSUZ012042 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Apr 2016 19:59:28 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 5 Apr 2016 14:59:27 -0500 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.009; Tue, 5 Apr 2016 14:59:27 -0500 From: "Michael Behringer (mbehring)" To: John Strassner , "Joel M. Halpern" Thread-Topic: [Anima] ANIMA intent discussion Thread-Index: AQHRip6r6CBKKtp6FEycGBHZ8l3kKJ9002wA///fMyCAAL08AIAE0deAgAABKoCAAD4bAIAAJJaAgAFwOwD//76zkA== Date: Tue, 5 Apr 2016 19:59:27 +0000 Message-ID: References: <56FBFA6A.4010400@alcatel-lucent.com> <1341e3fd501e4cbb8cbe9fbdc1d158de@XCH-RCD-006.cisco.com> <56FE7492.1070308@joelhalpern.com> <31002.1459781527@obiwan.sandelman.ca> <57028091.1060305@joelhalpern.com> <16723.1459795114@obiwan.sandelman.ca> <5702D35B.7060005@joelhalpern.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.115.98] Content-Type: multipart/alternative; boundary="_000_e69ffb6e5b5f4855a76923adc2adf899XCHRCD006ciscocom_" MIME-Version: 1.0 Archived-At: Cc: Michael Richardson , anima Subject: Re: [Anima] ANIMA intent discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 05 Apr 2016 19:59:31 -0000 --_000_e69ffb6e5b5f4855a76923adc2adf899XCHRCD006ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWljaGFlbFI6IFdoYXTigJlzIHdyb25nIHdpdGg6DQoNCg0KLSAgICAgICAgICBJbnRlbnQoMSk6 DQoNCm8gICBmcmVlemUgbmV0d29yayBlbnJvbG1lbnQgKGp1c3QgYXMgYW4gZXhhbXBsZSkNCg0K LSAgICAgICAgICBJbnRlbnQoMik6DQoNCm8gICB1bmZyZWV6ZSBuZXR3b3JrIGVucm9sbWVudCAo anVzdCBhcyBhbiBleGFtcGxlKQ0KDQotICAgICAgICAgIEludGVudCgzKToNCg0KbyAgIGZyZWV6 ZSBuZXR3b3JrIGVucm9sbWVudCAoanVzdCBhcyBhbiBleGFtcGxlKQ0KDQpvciBldmVuOg0KDQot ICAgICAgICAgIEludGVudCg0KToNCg0KbyAgIChlbXB0eSkg4oCTIG1lYW5pbmcsIGdvIGJhY2sg dG8gZGVmYXVsdCBiZWhhdmlvdXINCg0KKGlnbm9yZSBoZXJlIHdoZXRoZXIg4oCcZnJlZXpl4oCd IGlzIHRoZSByaWdodCB3YXkgdG8gc3RvcCBlbnJvbG1lbnQsIGl04oCZcyBqdXN0IGFuIGV4YW1w bGUpDQpNaWNoYWVsDQoNCkZyb206IEFuaW1hIFttYWlsdG86YW5pbWEtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEpvaG4gU3RyYXNzbmVyDQpTZW50OiAwNSBBcHJpbCAyMDE2IDE1OjQ3 DQpUbzogSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPjsgSm9obiBTdHJhc3Nu ZXIgPHN0cmF6cGRqQGdtYWlsLmNvbT4NCkNjOiBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitpZXRm QHNhbmRlbG1hbi5jYT47IGFuaW1hIDxhbmltYUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbQW5p bWFdIEFOSU1BIGludGVudCBkaXNjdXNzaW9uDQoNCihIbW1tKV4yDQoNCkkgYWdyZWUgd2l0aCBK b2VsLiBJbiBwYXN0IGltcGxlbWVudGF0aW9ucywgdGhlIGludGVudCB3cml0ZXIgaXMgdGlnaHRs eSBjb3VwbGVkIHRvIHRoZSBhZ2VudCAob3Igbm9kZSkgdGhhdCBpcyB0cmFuc2Zvcm1pbmcgdGhl IGludGVudCBpbnRvIGEgZm9ybSB0aGF0IGlzIGNvbnN1bWFibGUgYnkgdGhlIEFOSS4gV2hpbGUg dGhlIEFOSSBpcyBoaWdobHkgZGlzdHJpYnV0ZWQsIEkgZG8gbm90IHRoaW5rIHRoYXQgaXQgaXMg bG9vc2VseSBjb3VwbGVkIGVpdGhlci4NCg0KcmVnYXJkcywNCkpvaG4NCg0KT24gTW9uLCBBcHIg NCwgMjAxNiBhdCAxOjQ5IFBNLCBKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb208 bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+PiB3cm90ZToNCkhtbW0uDQoNClllcywgdGhlIHN5 c3RlbSBjb3VsZCB3b3JrIGJ5IGhhdmluZyBwb2xpY2llcyBleHBpcmUgcXVpY2tseSwgYW5kIGJl IHJlZnJlc2hlZCBpbiBhIHRpbWVseSBmYXNoaW9uLiAgSG93ZXZlciwgc2luY2UgcG9saWN5IG1h eSBjaGFuZ2UgYXQgYW55IHRpbWUsIHRoZXJlIHdvdWxkIHN0aWxsIG5lZWQgdG8gYmUgYSB3YXkg dG8gc2F5IHRoYXQgc29tZSBwb2xpY3kgbm8gbG9uZ2VyIGFwcGxpZXMsIGFuZCBhIG5ldyBwb2xp Y3kgaGFzIHN1cGVyY2VkZWQgaXQuDQoNCklmIHdlIHJlYWxseSB3YW50IG5vIGRlbGV0ZSAvIG92 ZXItcmlkZSwgd2UgaGF2ZSB0byBrZWVwIHRoZSB0aW1lb3V0cyB2ZXJ5IHNob3J0LCBhbmQgc3Bl bmQgYSBsb3Qgb2YgcmVzb3VyY2UgcmVmbG9vZGluZyBpZGVudGljYWwgcG9saWNpZXMgd2l0aCBu ZXcgZXhwaXJhdGlvbnMuICBJIGFtIG5vdCBzZWVpbmcgdGhlIGJlbmVmaXRzIG9mIHN1Y2ggYSBi ZWhhdmlvci4gIFdlIGFyZSBub3QgZGVhbGluZyB3aXRoIGEgaGlnaGx5IGxvb3NlbHkgY291cGxl ZCBzeXN0ZW0sIHN1Y2ggYXMgd2ViIGNlcnRpZmljYXRpb25zLg0KDQpZb3VycywNCkpvZWwNCg0K T24gNC80LzE2IDI6MzggUE0sIE1pY2hhZWwgUmljaGFyZHNvbiB3cm90ZToNCg0KSm9lbCBNLiBI YWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4g d3JvdGU6DQogICAgID4gSSBtdXN0IGJlIG1pc3Npbmcgc29tZXRoaW5nLiAgWW91IHNheSAiSSBk b24ndCB0aGluayB0aGF0IEFOSU1BIEludGVudHMgY2FuDQogICAgID4gYmUgdHVybmVkIG9uL29m Zi4iICBJIGNhbid0IHBhcnNlIHRoYXQuICBUd28gYXR0ZW1wdHM6DQoNCiAgICAgPiBBKSBDbGVh cmx5LCB0aGVyZSBjYW4gYmUgYW4gaW50ZW50IG5vdCB0byBhbGxvdyBzb21ldGhpbmcuICBXSGV0 aGVyIHRoZQ0KICAgICA+IGludGVudCBpdCB0byB0dXJuIG9mZiBhbGwgYWRtaXNzaW9ucywgb3Ig dG8gcHJvaGliaXQgYWxsIG1pbGlpb3VzIHRyYWZmaWMgKGlmDQogICAgID4gb25seSB3ZSBjb3Vs ZCksIHRoZXJlIGFyZSBjbGVhcmx5IG5lZ2F0aXZlIGludGVudHMgYXMgd2VsbCBhcyBwb3NpdGl2 ZQ0KICAgICA+IGludGVudHMuDQoNClllcywgYW4gSW50ZW50IGNvdWxkIGJlIHB1Ymxpc2hlZCB0 byBwZXJtaXQgb3IgZGVueSBzb21ldGhpbmcuDQpUaGF0IHdvdWxkIGJlIGFuIEFOSU1BIEludGVu dCB0byB0dXJuIG9mZiB0cmFmZmljLCBhbmQgeW91J2QgaGF2ZSB0byAnVHVybg0Kb24nIChwdWJs aXNoKSBzdWNoIGFuIEludGVudC4NCg0KICAgICA+IEIpIEVxdWFsbHkgY2xlYXJseSwgdGhlIGh1 bWFuIGJlaW5ncyB3aG8gb3JpZ2luYXRlIGludGVudHMgY2FuIGNoYW5nZSB0aGVpcg0KICAgICA+ IG1pbmRzIHRlbXBvcmFyaWx5IG9yIHBlcm1hbmVudGx5LiAgUG9saWNpZXMgZ2V0IGNoYW5nZWQg KHBlcm1hbmVudCksIGFuZA0KICAgICA+IHNvbWV0aW1lcyBwZW9wbGUgZGVjaWRlIGJhc2VkIG9u IGluZm9ybWF0aW9uIG91dHNpZGUgdGhlIHN5c3RlbSBzY29wZSB0YWh0DQogICAgID4gcG9saWNp ZXMgbmVlZCB0byBiZSB0ZW1wb3JhcmlseSBjaGFuZ2VkLg0KDQogICAgID4gU28gSSBkb24ndCBr bm93IHdoYXQgeW91IG1lYW4gd2hlbiB5b3Ugc2F5IHRoYXQgaW50ZW50cyBjYW4ndCBiZSB0dXJu ZWQNCiAgICAgPiBvZmYuDQoNCkknbSBzYXlpbmcgdGhhdCBJIGRvbid0IHRoaW5rIHRoYXQgQU5J TUEgSW50ZW50cyBzaG91bGQgYmUgcHVibGlzaGVkICgidHVybmVkDQpvbiIpIGFuZCB0aGVuICJ3 aXRoZHJhd24iICh0dXJuZWQgb2ZmKS4gIEkgdGhpbmsgdGhhdCB0aGV5IHNob3VsZCBvbmx5IGJl DQpwdWJsaXNoZWQgc28gdGhhdCB3ZSBkb24ndCBoYXZlIHRvIHdvcnJ5IGFib3V0IGhhdmluZyBv bGQgdGhpbmdzIGxpbmdlcmluZyBpbg0Kc3lzdGVtcy4NCg0KU28gdGhpcyBsZWF2ZXMgdXMgd2l0 aCB0d28gbm9uLW11dHVhbGx5IGV4Y2x1c2l2ZSBwb3NzaWJsZSB3YXlzIHRvIGRvIHRoaW5nczoN Cg0KMSkgdGhlIENSTCB3YXkgLS0geW91IHB1Ymxpc2ggYSBuZXcgSW50ZW50IGlkZW50aWZ5aW5n IHRoZSBBTklNQSBJbnRlbnQgdGhhdA0KICAgIHlvdSB3YW50IHRvIGFudWwgYnkgdW5pcXVlIElE LCBhbmQgc2F5IHRoYXQgaXQncyBkZWFkLiAgTmV3IEludGVudCBpcw0KICAgIHN1YmplY3QgdG8g dGhlIHNhbWUgZmxvb2RpbmcvZGlzdHJpYnV0aW9uIGFzIHRoZSBvbGQgb25lLg0KDQoyKSB0aGUg ZXhwaXJ5IHdheSAtLSBhbGwgSW50ZW50cyBzaG91bGQgZXhwaXJlLiAgSWYgbm90IHJlbmV3ZWQs IHRoZXkganVzdA0KICAgIGRpZSBvbiB0aGVpciBvd24uDQoNClBLSVggdXNlcyBib3RoIG1lY2hh bmlzbSwgYnV0IHRoZSB0cmVuZCBpdCB0b3dhcmRzIHVzaW5nIHNob3J0IGV4cGlyeSB0aW1lcw0K YW5kIG9ubGluZSByZW5ld2Fscy4gKEFDTUUgaXMgZG9pbmcgdGhhdCkuICBXaGlsZSB3ZSBkbyBo YXZlIHRoZSBPQ1NQLCBJIGZpbmQNCml0IHNpbGx5IGluIG1hbnkgd2F5cy4uLiB3aHkgZXZlbiBo YXZlIGEgY2VydGlmaWNhdGUgYXV0aG9yaXR5IGlmIHlvdSBhcmUNCmdvaW5nIHRvIGFzayBldmVy eW9uZSBvbmxpbmUuDQoNCi0tDQpNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1h bi5jYTxtYWlsdG86bWNyJTJCSUVURkBzYW5kZWxtYW4uY2E+PiwgU2FuZGVsbWFuIFNvZnR3YXJl IFdvcmtzDQogIC09IElQdjYgSW9UIGNvbnN1bHRpbmcgPS0NCg0KDQoNCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQW5pbWEgbWFpbGluZyBsaXN0 DQpBbmltYUBpZXRmLm9yZzxtYWlsdG86QW5pbWFAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpBbmltYSBtYWlsaW5nIGxpc3QNCkFuaW1hQGlldGYub3Jn PG1haWx0bzpBbmltYUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vYW5pbWENCg0KDQoNCi0tDQpyZWdhcmRzLA0KSm9obg0K --_000_e69ffb6e5b5f4855a76923adc2adf899XCHRCD006ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBs MA0KCXttc28tbGlzdC1pZDoxMzgxODU1MTY2Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1z by1saXN0LXRlbXBsYXRlLWlkczo3MzY1MTkzMTIgNzgzNTY0MDkwIDEzNDgwNzU1NSAxMzQ4MDc1 NTcgMTM0ODA3NTUzIDEzNDgwNzU1NSAxMzQ4MDc1NTcgMTM0ODA3NTUzIDEzNDgwNzU1NSAxMzQ4 MDc1NTc7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoyOw0KCW1zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1z by1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxl dmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBj bTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5NaWNoYWVsUjog V2hhdOKAmXMgd3Jvbmcgd2l0aDoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2Fs aWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2 ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0 OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxmb250 IHNpemU9IjEiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvc3Bhbj48 L2ZvbnQ+PCFbZW5kaWZdPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxp YnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+SW50ZW50KDEpOg0KPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50 Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+ PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj5vPGZvbnQgc2l6ZT0iMSIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvZm9udD48L3NwYW4+PC9zcGFuPjwvZm9udD48IVtlbmRpZl0+PGZv bnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5mcmVlemUgbmV0d29y ayBlbnJvbG1lbnQgKGp1c3QgYXMgYW4gZXhhbXBsZSk8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTgu MHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48Zm9udCBz aXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPi08Zm9udCBzaXplPSIxIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9m b250Pjwvc3Bhbj48L3NwYW4+PC9mb250PjwhW2VuZGlmXT48Zm9udCBzaXplPSIyIiBjb2xvcj0i IzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkludGVudCgyKToNCjxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMiBsZm8xIj4NCjwh W2lmICFzdXBwb3J0TGlzdHNdPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJD b3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+bzxmb250IHNpemU9IjEiIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsNCjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvc3Bhbj48 L2ZvbnQ+PCFbZW5kaWZdPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxp YnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+dW5mcmVlemUgbmV0d29yayBlbnJvbG1lbnQgKGp1c3QgYXMgYW4gZXhhbXBsZSk8bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAh c3VwcG9ydExpc3RzXT48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJy aSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08Zm9udCBzaXplPSIxIiBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjwvc3Bhbj48L3NwYW4+PC9mb250PjwhW2VuZGlmXT48 Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkludGVudCgzKTo8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDps MCBsZXZlbDIgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48Zm9udCBzaXplPSIyIiBjb2xv cj0iIzFmNDk3ZCIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPm88 Zm9udCBzaXplPSIxIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9m b250Pjwvc3Bhbj48L3NwYW4+PC9mb250PjwhW2VuZGlmXT48Zm9udCBzaXplPSIyIiBjb2xvcj0i IzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPmZyZWV6ZSBuZXR3b3JrIGVucm9sbWVudCAoanVzdCBh cyBhbiBleGFtcGxlKTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPm9yIGV2ZW46DQo8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtp ZiAhc3VwcG9ydExpc3RzXT48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2Fs aWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08Zm9udCBzaXplPSIxIiBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjwvc3Bhbj48L3NwYW4+PC9mb250PjwhW2VuZGlm XT48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkludGVudCg0 KTo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlz dDpsMCBsZXZlbDIgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48Zm9udCBzaXplPSIyIiBj b2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi Pm88Zm9udCBzaXplPSIxIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250 OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PC9mb250Pjwvc3Bhbj48L3NwYW4+PC9mb250PjwhW2VuZGlmXT48Zm9udCBzaXplPSIyIiBjb2xv cj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPihlbXB0eSkg4oCTIG1lYW5pbmcsIGdvIGJhY2sg dG8gZGVmYXVsdCBiZWhhdmlvdXI8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGli cmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4oaWdu b3JlIGhlcmUgd2hldGhlciDigJxmcmVlemXigJ0gaXMgdGhlIHJpZ2h0IHdheSB0byBzdG9wIGVu cm9sbWVudCwgaXTigJlzIGp1c3QgYW4gZXhhbXBsZSkNCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3 ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPk1pY2hhZWw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9 IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2ZvbnQtd2VpZ2h0OmJvbGQiPkZyb206PC9zcGFuPjwvZm9udD48 L2I+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+DQogQW5pbWEgW21haWx0bzphbmltYS1ib3VuY2VzQGlldGYub3JnXSA8Yj48c3BhbiBz dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+T24gQmVoYWxmIE9mDQo8L3NwYW4+PC9iPkpvaG4gU3Ry YXNzbmVyPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlNlbnQ6PC9zcGFu PjwvYj4gMDUgQXByaWwgMjAxNiAxNTo0Nzxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5Ubzo8L3NwYW4+PC9iPiBKb2VsIE0uIEhhbHBlcm4gJmx0O2ptaEBqb2VsaGFscGVy bi5jb20mZ3Q7OyBKb2huIFN0cmFzc25lciAmbHQ7c3RyYXpwZGpAZ21haWwuY29tJmd0Ozxicj4N CjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzo8L3NwYW4+PC9iPiBNaWNoYWVs IFJpY2hhcmRzb24gJmx0O21jciYjNDM7aWV0ZkBzYW5kZWxtYW4uY2EmZ3Q7OyBhbmltYSAmbHQ7 YW5pbWFAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi PlN1YmplY3Q6PC9zcGFuPjwvYj4gUmU6IFtBbmltYV0gQU5JTUEgaW50ZW50IGRpc2N1c3Npb248 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPihIbW1tKV4y PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5JIGFncmVl IHdpdGggSm9lbC4gSW4gcGFzdCBpbXBsZW1lbnRhdGlvbnMsIHRoZSBpbnRlbnQgd3JpdGVyIGlz IHRpZ2h0bHkgY291cGxlZCB0byB0aGUgYWdlbnQgKG9yIG5vZGUpIHRoYXQgaXMgdHJhbnNmb3Jt aW5nIHRoZSBpbnRlbnQgaW50byBhIGZvcm0gdGhhdCBpcyBjb25zdW1hYmxlDQogYnkgdGhlIEFO SS4gV2hpbGUgdGhlIEFOSSBpcyBoaWdobHkgZGlzdHJpYnV0ZWQsIEkgZG8gbm90IHRoaW5rIHRo YXQgaXQgaXMgbG9vc2VseSBjb3VwbGVkIGVpdGhlci48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPnJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMi IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkpv aG48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPk9uIE1v biwgQXByIDQsIDIwMTYgYXQgMTo0OSBQTSwgSm9lbCBNLiBIYWxwZXJuICZsdDs8YSBocmVmPSJt YWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmptaEBqb2VsaGFscGVy bi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkhtbW0uPGJyPg0KPGJyPg0K WWVzLCB0aGUgc3lzdGVtIGNvdWxkIHdvcmsgYnkgaGF2aW5nIHBvbGljaWVzIGV4cGlyZSBxdWlj a2x5LCBhbmQgYmUgcmVmcmVzaGVkIGluIGEgdGltZWx5IGZhc2hpb24uJm5ic3A7IEhvd2V2ZXIs IHNpbmNlIHBvbGljeSBtYXkgY2hhbmdlIGF0IGFueSB0aW1lLCB0aGVyZSB3b3VsZCBzdGlsbCBu ZWVkIHRvIGJlIGEgd2F5IHRvIHNheSB0aGF0IHNvbWUgcG9saWN5IG5vIGxvbmdlciBhcHBsaWVz LCBhbmQgYSBuZXcgcG9saWN5IGhhcyBzdXBlcmNlZGVkDQogaXQuPGJyPg0KPGJyPg0KSWYgd2Ug cmVhbGx5IHdhbnQgbm8gZGVsZXRlIC8gb3Zlci1yaWRlLCB3ZSBoYXZlIHRvIGtlZXAgdGhlIHRp bWVvdXRzIHZlcnkgc2hvcnQsIGFuZCBzcGVuZCBhIGxvdCBvZiByZXNvdXJjZSByZWZsb29kaW5n IGlkZW50aWNhbCBwb2xpY2llcyB3aXRoIG5ldyBleHBpcmF0aW9ucy4mbmJzcDsgSSBhbSBub3Qg c2VlaW5nIHRoZSBiZW5lZml0cyBvZiBzdWNoIGEgYmVoYXZpb3IuJm5ic3A7IFdlIGFyZSBub3Qg ZGVhbGluZyB3aXRoIGEgaGlnaGx5IGxvb3NlbHkgY291cGxlZA0KIHN5c3RlbSwgc3VjaCBhcyB3 ZWIgY2VydGlmaWNhdGlvbnMuPGJyPg0KPGJyPg0KWW91cnMsPGJyPg0KSm9lbDxicj4NCjxicj4N Ck9uIDQvNC8xNiAyOjM4IFBNLCBNaWNoYWVsIFJpY2hhcmRzb24gd3JvdGU6PG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxicj4NCkpvZWwgTS4gSGFscGVy biAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iIHRhcmdldD0iX2JsYW5r Ij5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsmZ3Q7IEkgbXVzdCBiZSBtaXNzaW5nIHNvbWV0aGluZy4mbmJzcDsgWW91IHNheSAmcXVv dDtJIGRvbid0IHRoaW5rIHRoYXQgQU5JTUEgSW50ZW50cyBjYW48YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyZndDsgYmUgdHVybmVkIG9uL29mZi4mcXVvdDsmbmJzcDsgSSBjYW4ndCBwYXJzZSB0 aGF0LiZuYnNwOyBUd28gYXR0ZW1wdHM6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsm Z3Q7IEEpIENsZWFybHksIHRoZXJlIGNhbiBiZSBhbiBpbnRlbnQgbm90IHRvIGFsbG93IHNvbWV0 aGluZy4mbmJzcDsgV0hldGhlciB0aGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgaW50 ZW50IGl0IHRvIHR1cm4gb2ZmIGFsbCBhZG1pc3Npb25zLCBvciB0byBwcm9oaWJpdCBhbGwgbWls aWlvdXMgdHJhZmZpYyAoaWY8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgb25seSB3ZSBj b3VsZCksIHRoZXJlIGFyZSBjbGVhcmx5IG5lZ2F0aXZlIGludGVudHMgYXMgd2VsbCBhcyBwb3Np dGl2ZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBpbnRlbnRzLjxicj4NCjxicj4NClll cywgYW4gSW50ZW50IGNvdWxkIGJlIHB1Ymxpc2hlZCB0byBwZXJtaXQgb3IgZGVueSBzb21ldGhp bmcuPGJyPg0KVGhhdCB3b3VsZCBiZSBhbiBBTklNQSBJbnRlbnQgdG8gdHVybiBvZmYgdHJhZmZp YywgYW5kIHlvdSdkIGhhdmUgdG8gJ1R1cm48YnI+DQpvbicgKHB1Ymxpc2gpIHN1Y2ggYW4gSW50 ZW50Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBCKSBFcXVhbGx5IGNsZWFy bHksIHRoZSBodW1hbiBiZWluZ3Mgd2hvIG9yaWdpbmF0ZSBpbnRlbnRzIGNhbiBjaGFuZ2UgdGhl aXI8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgbWluZHMgdGVtcG9yYXJpbHkgb3IgcGVy bWFuZW50bHkuJm5ic3A7IFBvbGljaWVzIGdldCBjaGFuZ2VkIChwZXJtYW5lbnQpLCBhbmQ8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgc29tZXRpbWVzIHBlb3BsZSBkZWNpZGUgYmFzZWQg b24gaW5mb3JtYXRpb24gb3V0c2lkZSB0aGUgc3lzdGVtIHNjb3BlIHRhaHQ8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyZndDsgcG9saWNpZXMgbmVlZCB0byBiZSB0ZW1wb3JhcmlseSBjaGFuZ2Vk Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBTbyBJIGRvbid0IGtub3cgd2hh dCB5b3UgbWVhbiB3aGVuIHlvdSBzYXkgdGhhdCBpbnRlbnRzIGNhbid0IGJlIHR1cm5lZDxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBvZmYuPGJyPg0KPGJyPg0KSSdtIHNheWluZyB0aGF0 IEkgZG9uJ3QgdGhpbmsgdGhhdCBBTklNQSBJbnRlbnRzIHNob3VsZCBiZSBwdWJsaXNoZWQgKCZx dW90O3R1cm5lZDxicj4NCm9uJnF1b3Q7KSBhbmQgdGhlbiAmcXVvdDt3aXRoZHJhd24mcXVvdDsg KHR1cm5lZCBvZmYpLiZuYnNwOyBJIHRoaW5rIHRoYXQgdGhleSBzaG91bGQgb25seSBiZTxicj4N CnB1Ymxpc2hlZCBzbyB0aGF0IHdlIGRvbid0IGhhdmUgdG8gd29ycnkgYWJvdXQgaGF2aW5nIG9s ZCB0aGluZ3MgbGluZ2VyaW5nIGluPGJyPg0Kc3lzdGVtcy48YnI+DQo8YnI+DQpTbyB0aGlzIGxl YXZlcyB1cyB3aXRoIHR3byBub24tbXV0dWFsbHkgZXhjbHVzaXZlIHBvc3NpYmxlIHdheXMgdG8g ZG8gdGhpbmdzOjxicj4NCjxicj4NCjEpIHRoZSBDUkwgd2F5IC0tIHlvdSBwdWJsaXNoIGEgbmV3 IEludGVudCBpZGVudGlmeWluZyB0aGUgQU5JTUEgSW50ZW50IHRoYXQ8YnI+DQombmJzcDsgJm5i c3A7IHlvdSB3YW50IHRvIGFudWwgYnkgdW5pcXVlIElELCBhbmQgc2F5IHRoYXQgaXQncyBkZWFk LiZuYnNwOyBOZXcgSW50ZW50IGlzPGJyPg0KJm5ic3A7ICZuYnNwOyBzdWJqZWN0IHRvIHRoZSBz YW1lIGZsb29kaW5nL2Rpc3RyaWJ1dGlvbiBhcyB0aGUgb2xkIG9uZS48YnI+DQo8YnI+DQoyKSB0 aGUgZXhwaXJ5IHdheSAtLSBhbGwgSW50ZW50cyBzaG91bGQgZXhwaXJlLiZuYnNwOyBJZiBub3Qg cmVuZXdlZCwgdGhleSBqdXN0PGJyPg0KJm5ic3A7ICZuYnNwOyBkaWUgb24gdGhlaXIgb3duLjxi cj4NCjxicj4NClBLSVggdXNlcyBib3RoIG1lY2hhbmlzbSwgYnV0IHRoZSB0cmVuZCBpdCB0b3dh cmRzIHVzaW5nIHNob3J0IGV4cGlyeSB0aW1lczxicj4NCmFuZCBvbmxpbmUgcmVuZXdhbHMuIChB Q01FIGlzIGRvaW5nIHRoYXQpLiZuYnNwOyBXaGlsZSB3ZSBkbyBoYXZlIHRoZSBPQ1NQLCBJIGZp bmQ8YnI+DQppdCBzaWxseSBpbiBtYW55IHdheXMuLi4gd2h5IGV2ZW4gaGF2ZSBhIGNlcnRpZmlj YXRlIGF1dGhvcml0eSBpZiB5b3UgYXJlPGJyPg0KZ29pbmcgdG8gYXNrIGV2ZXJ5b25lIG9ubGlu ZS48YnI+DQo8YnI+DQotLTxicj4NCk1pY2hhZWwgUmljaGFyZHNvbiAmbHQ7PGEgaHJlZj0ibWFp bHRvOm1jciUyQklFVEZAc2FuZGVsbWFuLmNhIiB0YXJnZXQ9Il9ibGFuayI+bWNyJiM0MztJRVRG QHNhbmRlbG1hbi5jYTwvYT4mZ3Q7LCBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3M8YnI+DQombmJz cDsgLT0gSVB2NiBJb1QgY29uc3VsdGluZyA9LTxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4N Cjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KQW5pbWEgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkFuaW1hQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+QW5pbWFAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYSIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWE8L2E+PG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxm b250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KQW5pbWEgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkFuaW1h QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+QW5pbWFAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYSIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWE8L2E+PG86 cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPGJyPg0K LS0gPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+cmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Sm9o bjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_e69ffb6e5b5f4855a76923adc2adf899XCHRCD006ciscocom_-- From nobody Tue Apr 5 15:49:24 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B47812D16A for ; Tue, 5 Apr 2016 15:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 DFRjHuESdQga for ; Tue, 5 Apr 2016 15:49:11 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCAFA12D51B for ; Tue, 5 Apr 2016 15:49:11 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id e128so19685638pfe.3 for ; Tue, 05 Apr 2016 15:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=RVDA3wNcCf4zGWgdhD0zyI8WaUk7P3S2OLtblrI4ga8=; b=NKcNNH1P16OccBHgAJW9rBjjCMdhJ7imwsHMyxOTzBnvsnomIai3jKQt5TU5TSmFZ6 eth3RNqqcHN+X2yvhR62cf8SiY1aYWQ77B7TB01v1MFlmMQ93Z9EfKsnOUK7I0h2Wped d5qD8iE82XmPDRlu9iPY0c10pa1IaaAj1kyffFK6sJgqjWnNN5Q3zvJbaqNbCQhxKHW7 XAUu1vkyKyscH85RDCkXSHPP01bfNQRK6fkqWdyHPRqGBp0xDLPmUrKSXsBLxtZkKUBX EjPT/Py39C6NfD5dJQAhtuOuwvt0AGDO3lG8v0tftsjZ2RkuePIuUy86NkWnYWtHCb1j FCuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=RVDA3wNcCf4zGWgdhD0zyI8WaUk7P3S2OLtblrI4ga8=; b=QIO6sjgl8LSsfoPXySW3UESczvcYtXnrZPSR8ABMiM9ybgETbBgGq2hO//Pghcp/EW vyKd0T55rTnuD9NVWXL7ehEDTtD7w/FqCJfPfRgKXGX+WkWOK4FuKDauaOZChRUTWu8W LZXKamZgCdwbDIS0hJw2Wwu0VANIDBbbEeD4LiSubUfIDTbr8Gq45ydNrmUlbX+EnrtE mVQZvAMpMjuZCj427k8hS2TobgQnn7ClUM+DI/OvmJ7MZcetyXf/nFzKVZFeuG1Wll1U 2rEAUia52OrcORiMblBia9T2UWsldkJHqmPpS/o9q5ANQ2iB8n7Bxn52xEW55ea/4bzt o9IQ== X-Gm-Message-State: AD7BkJLvaa1qLhneW7tXTEzaF7FOzLzrWUSoK8WKxNbSWPrEucsgWskPl39/FeFUfklk7A== X-Received: by 10.98.80.70 with SMTP id e67mr33852279pfb.136.1459896551361; Tue, 05 Apr 2016 15:49:11 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id q72sm49117574pfa.70.2016.04.05.15.49.07 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2016 15:49:10 -0700 (PDT) To: John Strassner References: <56FBFA6A.4010400@alcatel-lucent.com> <57006D4A.6070005@gmail.com> <570179AC.6090707@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <570440E5.8030003@gmail.com> Date: Wed, 6 Apr 2016 10:49:09 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Laurent Ciavaglia , Duzongpeng , anima , Michael Behringer , Pierre Peloso Subject: Re: [Anima] ANIMA intent discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 05 Apr 2016 22:49:17 -0000 On 06/04/2016 06:40, John Strassner wrote: > Carrying on the snipping tradition... > >>> However, I don't believe that this is the normal case, since in my >>> view, Intent is not a PERL script, a python program, or a set of >>> APIs - it is instead a (restricted) natural language. Putting a >>> compiler for this on a router or switch is not a good idea, since > > > Well, IMHO it would be an interpreter... > > I don't have a strong feeling either way, but why (more out of > curiosity)? Oh, just because it avoids having a separate process to do the compilation, that's all. It's certainly not a standardization issue. > >>> you would also need ontologies or some type of computational >>> linguistic processing to handle not just synonyms, but variations >>> in phrasing, etc. > >> ... and IMHO the Intent language would *not* be like that; it would >> be algorithmic. What's the value in allowing it to be sloppy? > > Who says that natural language has to be sloppy? > > What I mean by restricted natural language is that it has a grammar > that matches the needs of the constituency that is using it. For me, > intent is not specifying an algorithm, it is specify what needs to be > done, and let the machine implement the algorithm. Well sure, and I guess it's true that COBOL was originally touted as a natural language, because you could write DIVIDE WAGES BY HOURS GIVING PAYRATE. In that sense, sure. > >> Also, >> how can that approach be correctly internationalised? Whatever we do >> must be very straightforward whatever language the human operator >> speaks, which means that its syntax has to be rigid (and preferably >> 1:1 translatable from an English-like presentation to any other >> language). > > Agreed. In past work, we've done exactly that. See above comment. > >> That's why I keep saying that these and other >> support functions should be in a (distributed) autonomic manager, >> and that the autonomic manager translate intent to a form that >> is consumable by the device. > >> If you mean that an autonomic node will manage (configure) any >> number of subsidiary non-autonomic devices, we agree. And I think >> this is something we should state explicitly in the reference model, >> which I believe is missing at the moment. It is stated in the >> GRASP spec, which is probably the wrong place for it: > > Agreed > ... > >>> I haven't seen a good argument against this approach. To my >>> knowledge, this approach is what has been commonly built. >>> >>> Also, if there is Intent that is meaningful only to certain ASAs, >>> how can that semantic be handled in a generic Intent handler? >>> >>> That's why I prefer pub-sub to flooding. >> >> I find that contradictory with your description of it as pseudo-natural >> language; what we deliver to ASAs needs to be straightforward to > interpret. > > How is it contradictory? The intent is translated to a form that the ASAs > can handle. Right, and that is where we aren't quite in agreement. I've been assuming that the Intent as distributed by GRASP *is* in the form that ASAs can handle. Rgds Brian > > regards, > John > > On Sun, Apr 3, 2016 at 1:14 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> John, >> On 04/04/2016 02:59, John Strassner wrote: >>> Hi Brian, >>> >>>> >>> ... >>>>> I do not think that it is necessary to combine disparate >>>>> intents into a single file. >>> >>>> That seems to mean that each recipient of multiple files has to >>>> performance consistency checks and conflict resolution, unless >>>> you have a watertight definition of 'disparate'. >>> >>> No, it means that: >>> >>> a) I don't believe that network elements are, in general, autonomic >>> b) I believe that higher level autonomic managers are needed >>> to perform these and other tasks. >> >> Of course, see my next comment. >> >>>> ... >>>>> 5: Intent is processed/compiled by dedicated entities (in my >>>>> case, these are agents). This is because it takes specific >>>>> resources and specific knowledge to do this. >>> >>>> Well, we definitely need to talk about that. Do you mean that >>>> each autonomic node would contain such an agent, or that such >>>> agents would be few in number? >>> >>> That is dependent on the overall architectural approach. In >>> systems that I have built, I have kept to the classic definition of >>> agent, where it knows how to do a few things well. So, as in >>> the AAMAS set of conferences, there are many types of agents >>> that each perform one (or a few) tasks very well. >>> >>> In this approach, the nodes use however many agents they need. >>> >>>>> >>>>> 6: I prefer pub-sub. If flooding, then it should be constrained. >>> >>>> Constrained flooding is the hardest case. If Intent is small, why >>>> can't we flood it, with unicast pub/sub to fill in any gaps? >>> >>> Because I fail to see why most nodes would care about intent. >>> The nodes are not autonomic, the autonomic managers are. >> >> Ah, I see that we have a slight terminology mismatch. When I write >> "flood" I mean, very specifically, something sent to all autonomic >> nodes. (Even more specifically, to all GRASP nodes, which listen >> to the GRASP link-local multicast address.) Certainly, each such >> node may be managing any number of non-autonomic nodes that don't >> understand Intent and will not receive it. >> >>> You can't build an autonomic system by making every >>> component autonomic - you can build an autonomic system >>> by having the components collaborate to produce autonomic >>> behavior. That's where we differ. >>> >>>>> 7: In general, Intent is NOT understood by nodes or ASAs. >>>>> This is because the node or ASA would have to have access >>>>> to additional significant resources. >>> >>>> If there is Intent support code in each node, is that a problem? >> >> Read "node" as "autonomic node". >> >>> If intent support code is present, then it is there for a good reason >>> (or at least I hope so), and hence, no, that is not a problem. >>> However, I don't believe that this is the normal case, since in my >>> view, Intent is not a PERL script, a python program, or a set of >>> APIs - it is instead a (restricted) natural language. Putting a >>> compiler for this on a router or switch is not a good idea, since >> >> Well, IMHO it would be an interpreter... >> >>> you would also need ontologies or some type of computational >>> linguistic processing to handle not just synonyms, but variations >>> in phrasing, etc. >> >> ... and IMHO the Intent language would *not* be like that; it would >> be algorithmic. What's the value in allowing it to be sloppy? Also, >> how can that approach be correctly internationalised? Whatever we do >> must be very straightforward whatever language the human operator >> speaks, which means that its syntax has to be rigid (and preferably >> 1:1 translatable from an English-like presentation to any other >> language). >> >>> That's why I keep saying that these and other >>> support functions should be in a (distributed) autonomic manager, >>> and that the autonomic manager translate intent to a form that >>> is consumable by the device. >> >> If you mean that an autonomic node will manage (configure) any >> number of subsidiary non-autonomic devices, we agree. And I think >> this is something we should state explicitly in the reference model, >> which I believe is missing at the moment. It is stated in the >> GRASP spec, which is probably the wrong place for it: >> It is understood that in realistic deployments, not all devices will >> support GRASP. It is expected that some autonomic service agents >> will directly manage a group of non-autonomic nodes, and that other >> non-autonomic nodes will be managed traditionally. >> >>> I haven't seen a good argument against this approach. To my >>> knowledge, this approach is what has been commonly built. >>> >>>> Also, if there is Intent that is meaningful only to certain ASAs, >>>> how can that semantic be handled in a generic Intent handler? >>> >>> That's why I prefer pub-sub to flooding. >> >> I find that contradictory with your description of it as pseudo-natural >> language; what we deliver to ASAs needs to be straightforward to interpret. >> >> Rgds >> Brian >> >>> >>> regards, >>> John >>> >>> On Sat, Apr 2, 2016 at 6:09 PM, Brian E Carpenter < >>> brian.e.carpenter@gmail.com> wrote: >>> >>>> On 03/04/2016 03:31, John Strassner wrote: >>>> >>>> >>>> ... >>>>> I do not think that it is necessary to combine disparate >>>>> intents into a single file. >>>> >>>> That seems to mean that each recipient of multiple files has to >>>> performance consistency checks and conflict resolution, unless >>>> you have a watertight definition of 'disparate'. >>>> >>>> ... >>>>> 5: Intent is processed/compiled by dedicated entities (in my >>>>> case, these are agents). This is because it takes specific >>>>> resources and specific knowledge to do this. >>>> >>>> Well, we definitely need to talk about that. Do you mean that >>>> each autonomic node would contain such an agent, or that such >>>> agents would be few in number? >>>> >>>>> >>>>> 6: I prefer pub-sub. If flooding, then it should be constrained. >>>> >>>> Constrained flooding is the hardest case. If Intent is small, why >>>> can't we flood it, with unicast pub/sub to fill in any gaps? >>>> >>>>> 7: In general, Intent is NOT understood by nodes or ASAs. >>>>> This is because the node or ASA would have to have access >>>>> to additional significant resources. >>>> >>>> If there is Intent support code in each node, is that a problem? >>>> Also, if there is Intent that is meaningful only to certain ASAs, >>>> how can that semantic be handled in a generic Intent handler? >>>> >>>> Rgds >>>> Brian >>>> >>>> >>>> >>> >>> >> > > > From nobody Tue Apr 5 15:50:18 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 628B212D178 for ; Tue, 5 Apr 2016 15:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9KpQuzpCEsF9 for ; Tue, 5 Apr 2016 15:50:14 -0700 (PDT) Received: from mail-lb0-x241.google.com (mail-lb0-x241.google.com [IPv6:2a00:1450:4010:c04::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA0E812D556 for ; Tue, 5 Apr 2016 15:50:09 -0700 (PDT) Received: by mail-lb0-x241.google.com with SMTP id gk8so2367517lbc.2 for ; Tue, 05 Apr 2016 15:50:09 -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; bh=NfK8K6SlBVANXrCqVzBGYll0xqZAuGLIjMExW1X08uQ=; b=OX5XS90bqv3rWZv80KHLb89JWGdT03gcclv4QpO5BwRJ9cXl4ulmtQb7XoAag/xiHM 05rOhZBanYXWg9W2BmiUFiAEkz+V1z1SaNrcG+WHsi4RNpwWoKdTYcZPMLxT+V2ZJ4ca LOKS00CYGvDhZOpZvaJrZgrKRKwEATcBUFaayxIbFcmr2Uu0eRpPqOtTcZ+ZR/R/cFOY MVnuTIdImmOUbVYlepIzpcQqsQLOsjKpQkyOQo52GFUqPNOs5KV8vzcKwoNovzLhUMUq xQz8uHgV5MQPcNMOKIddnUv7admjbX6jr2MQuzQh7RBvT2i6H0W2j9UVXTWDvxbVRgac LVxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=NfK8K6SlBVANXrCqVzBGYll0xqZAuGLIjMExW1X08uQ=; b=WvPduqgx9vm1LvFJiLCR8XTbH2vN9ftUX6pUaVsV8ucnfpmkHoaSBBt9scn9mThXJ6 5T6S28VeJPeCQY0HX8PWd1ot5sj7xnVORpJAYPcRRNwr7V4rrw1dp4mknaJyhCxkhyua H9UvMZAevCNIHVSlvyTehHR5jZ5wm73iTLznM72VgyniVz6iJ9chOYMI4+yINTGbyEvZ +FK5t/NvnpVpHQ6jAlIqifTKXXdnJAlsjc3FHNUNY9iqgPqWM5ez/KgF+b6d6o1SyJxm /UnpkD0/gdB75uu+np5q10JIfXccZXN0S2ZoD/EsFcUiFa3U8YhblB0TyCVKQRRgSBS/ rCKQ== X-Gm-Message-State: AD7BkJLar/OFf4/vFp2v/jQ/nM+j3BJoeyg7Z84CoJLy5RUl5r8x5vAfcJ2VK/WFW63S8vQk1NhTtATJ/Amgsw== MIME-Version: 1.0 X-Received: by 10.112.170.68 with SMTP id ak4mr141970lbc.94.1459881646776; Tue, 05 Apr 2016 11:40:46 -0700 (PDT) Received: by 10.25.22.19 with HTTP; Tue, 5 Apr 2016 11:40:46 -0700 (PDT) In-Reply-To: <570179AC.6090707@gmail.com> References: <56FBFA6A.4010400@alcatel-lucent.com> <57006D4A.6070005@gmail.com> <570179AC.6090707@gmail.com> Date: Tue, 5 Apr 2016 11:40:46 -0700 Message-ID: From: John Strassner To: Brian E Carpenter , John Strassner Content-Type: multipart/alternative; boundary=001a11c259a8f89d36052fc12e88 Archived-At: Cc: Laurent Ciavaglia , Duzongpeng , anima , Michael Behringer , Pierre Peloso Subject: Re: [Anima] ANIMA intent discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 05 Apr 2016 22:50:16 -0000 --001a11c259a8f89d36052fc12e88 Content-Type: text/plain; charset=UTF-8 Carrying on the snipping tradition... >> However, I don't believe that this is the normal case, since in my >> view, Intent is not a PERL script, a python program, or a set of >> APIs - it is instead a (restricted) natural language. Putting a >> compiler for this on a router or switch is not a good idea, since > Well, IMHO it would be an interpreter... I don't have a strong feeling either way, but why (more out of curiosity)? >> you would also need ontologies or some type of computational >> linguistic processing to handle not just synonyms, but variations >> in phrasing, etc. > ... and IMHO the Intent language would *not* be like that; it would >be algorithmic. What's the value in allowing it to be sloppy? Who says that natural language has to be sloppy? What I mean by restricted natural language is that it has a grammar that matches the needs of the constituency that is using it. For me, intent is not specifying an algorithm, it is specify what needs to be done, and let the machine implement the algorithm. > Also, > how can that approach be correctly internationalised? Whatever we do > must be very straightforward whatever language the human operator > speaks, which means that its syntax has to be rigid (and preferably > 1:1 translatable from an English-like presentation to any other > language). Agreed. In past work, we've done exactly that. See above comment. > That's why I keep saying that these and other > support functions should be in a (distributed) autonomic manager, > and that the autonomic manager translate intent to a form that > is consumable by the device. > If you mean that an autonomic node will manage (configure) any > number of subsidiary non-autonomic devices, we agree. And I think > this is something we should state explicitly in the reference model, > which I believe is missing at the moment. It is stated in the > GRASP spec, which is probably the wrong place for it: Agreed ... >> I haven't seen a good argument against this approach. To my >> knowledge, this approach is what has been commonly built. >> >> Also, if there is Intent that is meaningful only to certain ASAs, >> how can that semantic be handled in a generic Intent handler? >> >> That's why I prefer pub-sub to flooding. > > I find that contradictory with your description of it as pseudo-natural > language; what we deliver to ASAs needs to be straightforward to interpret. How is it contradictory? The intent is translated to a form that the ASAs can handle. regards, John On Sun, Apr 3, 2016 at 1:14 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > John, > On 04/04/2016 02:59, John Strassner wrote: > > Hi Brian, > > > >> > > ... > >>> I do not think that it is necessary to combine disparate > >>> intents into a single file. > > > >> That seems to mean that each recipient of multiple files has to > >> performance consistency checks and conflict resolution, unless > >> you have a watertight definition of 'disparate'. > > > > No, it means that: > > > > a) I don't believe that network elements are, in general, autonomic > > b) I believe that higher level autonomic managers are needed > > to perform these and other tasks. > > Of course, see my next comment. > > >> ... > >>> 5: Intent is processed/compiled by dedicated entities (in my > >>> case, these are agents). This is because it takes specific > >>> resources and specific knowledge to do this. > > > >> Well, we definitely need to talk about that. Do you mean that > >> each autonomic node would contain such an agent, or that such > >> agents would be few in number? > > > > That is dependent on the overall architectural approach. In > > systems that I have built, I have kept to the classic definition of > > agent, where it knows how to do a few things well. So, as in > > the AAMAS set of conferences, there are many types of agents > > that each perform one (or a few) tasks very well. > > > > In this approach, the nodes use however many agents they need. > > > >>> > >>> 6: I prefer pub-sub. If flooding, then it should be constrained. > > > >> Constrained flooding is the hardest case. If Intent is small, why > >> can't we flood it, with unicast pub/sub to fill in any gaps? > > > > Because I fail to see why most nodes would care about intent. > > The nodes are not autonomic, the autonomic managers are. > > Ah, I see that we have a slight terminology mismatch. When I write > "flood" I mean, very specifically, something sent to all autonomic > nodes. (Even more specifically, to all GRASP nodes, which listen > to the GRASP link-local multicast address.) Certainly, each such > node may be managing any number of non-autonomic nodes that don't > understand Intent and will not receive it. > > > You can't build an autonomic system by making every > > component autonomic - you can build an autonomic system > > by having the components collaborate to produce autonomic > > behavior. That's where we differ. > > > >>> 7: In general, Intent is NOT understood by nodes or ASAs. > >>> This is because the node or ASA would have to have access > >>> to additional significant resources. > > > >> If there is Intent support code in each node, is that a problem? > > Read "node" as "autonomic node". > > > If intent support code is present, then it is there for a good reason > > (or at least I hope so), and hence, no, that is not a problem. > > However, I don't believe that this is the normal case, since in my > > view, Intent is not a PERL script, a python program, or a set of > > APIs - it is instead a (restricted) natural language. Putting a > > compiler for this on a router or switch is not a good idea, since > > Well, IMHO it would be an interpreter... > > > you would also need ontologies or some type of computational > > linguistic processing to handle not just synonyms, but variations > > in phrasing, etc. > > ... and IMHO the Intent language would *not* be like that; it would > be algorithmic. What's the value in allowing it to be sloppy? Also, > how can that approach be correctly internationalised? Whatever we do > must be very straightforward whatever language the human operator > speaks, which means that its syntax has to be rigid (and preferably > 1:1 translatable from an English-like presentation to any other > language). > > > That's why I keep saying that these and other > > support functions should be in a (distributed) autonomic manager, > > and that the autonomic manager translate intent to a form that > > is consumable by the device. > > If you mean that an autonomic node will manage (configure) any > number of subsidiary non-autonomic devices, we agree. And I think > this is something we should state explicitly in the reference model, > which I believe is missing at the moment. It is stated in the > GRASP spec, which is probably the wrong place for it: > It is understood that in realistic deployments, not all devices will > support GRASP. It is expected that some autonomic service agents > will directly manage a group of non-autonomic nodes, and that other > non-autonomic nodes will be managed traditionally. > > > I haven't seen a good argument against this approach. To my > > knowledge, this approach is what has been commonly built. > > > >> Also, if there is Intent that is meaningful only to certain ASAs, > >> how can that semantic be handled in a generic Intent handler? > > > > That's why I prefer pub-sub to flooding. > > I find that contradictory with your description of it as pseudo-natural > language; what we deliver to ASAs needs to be straightforward to interpret. > > Rgds > Brian > > > > > regards, > > John > > > > On Sat, Apr 2, 2016 at 6:09 PM, Brian E Carpenter < > > brian.e.carpenter@gmail.com> wrote: > > > >> On 03/04/2016 03:31, John Strassner wrote: > >> > >> > >> ... > >>> I do not think that it is necessary to combine disparate > >>> intents into a single file. > >> > >> That seems to mean that each recipient of multiple files has to > >> performance consistency checks and conflict resolution, unless > >> you have a watertight definition of 'disparate'. > >> > >> ... > >>> 5: Intent is processed/compiled by dedicated entities (in my > >>> case, these are agents). This is because it takes specific > >>> resources and specific knowledge to do this. > >> > >> Well, we definitely need to talk about that. Do you mean that > >> each autonomic node would contain such an agent, or that such > >> agents would be few in number? > >> > >>> > >>> 6: I prefer pub-sub. If flooding, then it should be constrained. > >> > >> Constrained flooding is the hardest case. If Intent is small, why > >> can't we flood it, with unicast pub/sub to fill in any gaps? > >> > >>> 7: In general, Intent is NOT understood by nodes or ASAs. > >>> This is because the node or ASA would have to have access > >>> to additional significant resources. > >> > >> If there is Intent support code in each node, is that a problem? > >> Also, if there is Intent that is meaningful only to certain ASAs, > >> how can that semantic be handled in a generic Intent handler? > >> > >> Rgds > >> Brian > >> > >> > >> > > > > > -- regards, John --001a11c259a8f89d36052fc12e88 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Carrying on the snipping tradition...

<= /div>
>> However, I don't believe that this is the normal cas= e, since in my
>> view, Intent is not a PERL script, a python prog= ram, or a set of
>> APIs - it is instead a (restricted) natural la= nguage. Putting a
>> compiler for this on a router or switch is no= t a good idea, since

=C2=A0> Well, IMHO it would be an interprete= r...

I don't have a strong feeling either way,= but why (more out of
curiosity)?

>> you would also = need ontologies or some type of computational
>> linguistic proces= sing to handle not just synonyms, but variations
>> in phrasing, e= tc.

> ... and IMHO the Intent language would *not* be like that;= it would
>be algorithmic. What's the value in allowing it to be= sloppy?

Who says that natural language has to be = sloppy?

What I mean by restricted natural language= is that it has a grammar
that matches the needs of the constitue= ncy that is using it. For me,
intent is not specifying an algorit= hm, it is specify what needs to be
done, and let the machine impl= ement the algorithm.

> Also,
> how can t= hat approach be correctly internationalised? Whatever we do
> must b= e very straightforward whatever language the human operator
> speaks= , which means that its syntax has to be rigid (and preferably
> 1:1 = translatable from an English-like presentation to any other
> langua= ge).

Agreed. In past work, we've done exac= tly that. See above comment.

> That's why I keep sayin= g that these and other
> support functions should be in a (distribute= d) autonomic manager,
> and that the autonomic manager translate inte= nt to a form that
> is consumable by the device.

> If you = mean that an autonomic node will manage (configure) any
> number of = subsidiary non-autonomic devices, we agree. And I think
> this is so= mething we should state explicitly in the reference model,
> which I= believe is missing at the moment. It is stated in the
> GRASP spec,= which is probably the wrong place for it:

Agreed<= /div>
...

>> I haven't seen a good argument aga= inst this approach. To my
>> knowledge, this approach is what has = been commonly built.
>>
>> Also, if there is Intent that= is meaningful only to certain ASAs,
>> how can that semantic be h= andled in a generic Intent handler?
>>
>> That's why= I prefer pub-sub to flooding.
>
> I find that contradictory w= ith your description of it as pseudo-natural
> language; what we del= iver to ASAs needs to be straightforward to interpret.

=
How is it contradictory? The intent is translated to a form that the A= SAs
can handle.

regards,
John<= br>

On= Sun, Apr 3, 2016 at 1:14 PM, Brian E Carpenter <brian.e.carpent= er@gmail.com> wrote:
John,<= br> On 04/04/2016 02:59, John Strassner wrote:
> Hi Brian,
>
>> <snipped even more vigorously>
> ...
>>> I do not think that it is necessary to combine disparate
>>> intents into a single file.
>
>> That seems to mean that each recipient of multiple files has to >> performance consistency checks and conflict resolution, unless
>> you have a watertight definition of 'disparate'.
>
> No, it means that:
>
>=C2=A0 =C2=A0 a) I don't believe that network elements are, in gene= ral, autonomic
>=C2=A0 =C2=A0 b) I believe that higher level autonomic managers are nee= ded
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 to perform these and other tasks.

Of course, see my next comment.

>>=C2=A0 ...
>>> 5:=C2=A0 Intent is processed/compiled by dedicated entities (i= n my
>>> case, these are agents). This is because it takes specific
>>> resources and specific knowledge to do this.
>
>> Well, we definitely need to talk about that. Do you mean that
>> each autonomic node would contain such an agent, or that such
>> agents would be few in number?
>
> That is dependent on the overall architectural approach. In
> systems that I have built, I have kept to the classic definition of > agent, where it knows how to do a few things well. So, as in
> the AAMAS set of conferences, there are many types of agents
> that each perform one (or a few) tasks very well.
>
> In this approach, the nodes use however many agents they need.
>
>>>
>>> 6: I prefer pub-sub. If flooding, then it should be constraine= d.
>
>> Constrained flooding is the hardest case. If Intent is small, why<= br> >> can't we flood it, with unicast pub/sub to fill in any gaps? >
> Because I fail to see why most nodes would care about intent.
> The nodes are not autonomic, the autonomic managers are.

Ah, I see that we have a slight terminology mismatch. When I write
"flood" I mean, very specifically, something sent to all autonomi= c
nodes. (Even more specifically, to all GRASP nodes, which listen
to the GRASP link-local multicast address.) Certainly, each such
node may be managing any number of non-autonomic nodes that don't
understand Intent and will not receive it.

> You can't build an autonomic system by making every
> component autonomic - you can build an autonomic system
> by having the components collaborate to produce autonomic
> behavior. That's where we differ.
>
>>> 7:=C2=A0 In general, Intent is NOT understood by nodes or ASAs= .
>>> This is because the node or ASA would have to have access
>>> to additional significant resources.
>
>> If there is Intent support code in each node, is that a problem?
Read "node" as "autonomic node".

> If intent support code is present, then it is there for a good reason<= br> > (or at least I hope so), and hence, no, that is not a problem.
> However, I don't believe that this is the normal case, since in my=
> view, Intent is not a PERL script, a python program, or a set of
> APIs - it is instead a (restricted) natural language. Putting a
> compiler for this on a router or switch is not a good idea, since

Well, IMHO it would be an interpreter...

> you would also need ontologies or some type of computational
> linguistic processing to handle not just synonyms, but variations
> in phrasing, etc.

... and IMHO the Intent language would *not* be like that; it would
be algorithmic. What's the value in allowing it to be sloppy? Also,
how can that approach be correctly internationalised? Whatever we do
must be very straightforward whatever language the human operator
speaks, which means that its syntax has to be rigid (and preferably
1:1 translatable from an English-like presentation to any other
language).

> That's why I keep saying that these and other
> support functions should be in a (distributed) autonomic manager,
> and that the autonomic manager translate intent to a form that
> is consumable by the device.

If you mean that an autonomic node will manage (configure) any
number of subsidiary non-autonomic devices, we agree. And I think
this is something we should state explicitly in the reference model,
which I believe is missing at the moment. It is stated in the
GRASP spec, which is probably the wrong place for it:
=C2=A0 =C2=A0It is understood that in realistic deployments, not all device= s will
=C2=A0 =C2=A0support GRASP.=C2=A0 It is expected that some autonomic servic= e agents
=C2=A0 =C2=A0will directly manage a group of non-autonomic nodes, and that = other
=C2=A0 =C2=A0non-autonomic nodes will be managed traditionally.

> I haven't seen a good argument against this approach. To my
> knowledge, this approach is what has been commonly built.
>
>> Also, if there is Intent that is meaningful only to certain ASAs,<= br> >> how can that semantic be handled in a generic Intent handler?
>
> That's why I prefer pub-sub to flooding.

I find that contradictory with your description of it as pseudo-natural
language; what we deliver to ASAs needs to be straightforward to interpret.=

Rgds
=C2=A0 Brian

>
> regards,
> John
>
> On Sat, Apr 2, 2016 at 6:09 PM, Brian E Carpenter <
> brian.e.carpenter@gmail= .com> wrote:
>
>> On 03/04/2016 03:31, John Strassner wrote:
>>
>> <snipped even more vigorously>
>> ...
>>> I do not think that it is necessary to combine disparate
>>> intents into a single file.
>>
>> That seems to mean that each recipient of multiple files has to >> performance consistency checks and conflict resolution, unless
>> you have a watertight definition of 'disparate'.
>>
>> ...
>>> 5:=C2=A0 Intent is processed/compiled by dedicated entities (i= n my
>>> case, these are agents). This is because it takes specific
>>> resources and specific knowledge to do this.
>>
>> Well, we definitely need to talk about that. Do you mean that
>> each autonomic node would contain such an agent, or that such
>> agents would be few in number?
>>
>>>
>>> 6: I prefer pub-sub. If flooding, then it should be constraine= d.
>>
>> Constrained flooding is the hardest case. If Intent is small, why<= br> >> can't we flood it, with unicast pub/sub to fill in any gaps? >>
>>> 7:=C2=A0 In general, Intent is NOT understood by nodes or ASAs= .
>>> This is because the node or ASA would have to have access
>>> to additional significant resources.
>>
>> If there is Intent support code in each node, is that a problem? >> Also, if there is Intent that is meaningful only to certain ASAs,<= br> >> how can that semantic be handled in a generic Intent handler?
>>
>> Rgds
>>=C2=A0 =C2=A0Brian
>>
>>
>>
>
>



--
regards,
John
--001a11c259a8f89d36052fc12e88-- From nobody Tue Apr 5 16:02:11 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2463512D134 for ; Tue, 5 Apr 2016 16:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 3HzRtIBzrFSj for ; Tue, 5 Apr 2016 16:02:07 -0700 (PDT) Received: from mail-lb0-x242.google.com (mail-lb0-x242.google.com [IPv6:2a00:1450:4010:c04::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2185F12D0CC for ; Tue, 5 Apr 2016 16:02:07 -0700 (PDT) Received: by mail-lb0-x242.google.com with SMTP id gk8so2383071lbc.2 for ; Tue, 05 Apr 2016 16:02:07 -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; bh=y/nW0JC/ZCBMw/sh1/wb/GEkh5+CxmAtUCBuKat0GSQ=; b=CseWPNg5xxCs55VxjdxpJjzLvoUE3JuRvWrYiTEAEPUP5E4VaCxSq+3hXz3zLApW+Q yddaA3tRjHRAXx+TFuw/gSGOvfIN8M+7zYC7xYAj6QF/8Mktayoh1CbF9dL7oYNGM6xX CFGSaq7bfBrRhUaxVZl3naehG1UntC+VFkCAj7GkCJ79RM9ubig9aEysxbgyMQsPpWOP 3ZFbWmUXOrwS08WZo+GSHasfVs17o52xfYFRXc8Iy11or369j9uyHcbknT9K4+Gj9+BB 8oPA9OS7AmD9hn/hH3CtqyY9cEPOFQPNNPMmBbuXHFgwoq5dK8+zWW+yske2X11txpGt Gh4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=y/nW0JC/ZCBMw/sh1/wb/GEkh5+CxmAtUCBuKat0GSQ=; b=RPM6aMUzWMr4iLg5Eido2oEBixs8MMB4X+Px21G7bqWv697qUH1gc+JHSW/5RzhO8m DhCYyKY4SDOfWsOoLkHUxyxHN0u76wiP0RAgZlchHEc9nK+K21tW6gp1Nzi3fKR4ByTA +z2mH2ulqwxYd2+WdOJuF3q7+FKyE39Dfo9mztCtubDV7+iRQ5WXBhRKvMXV/dfI5+Lw okAzbjgFP1Ion6ZT4IkUtbZ90KbuC5YhcVVSTJ97NCkvraxSjIixI6TytyeygcNkzxM2 8ktwsaozoZRa4iv8EeDSugw5m5eiyMjIbTJIEtPzE/5HeRCcsjLPqH4U9yn0Z5dwyMhW oedQ== X-Gm-Message-State: AD7BkJJSR2snTP867hm9hHE9/f/BbU2NUFYHZVWZPzJCaA0NV5csyZ32Oe3ruOlH/7j4jqLPrLRIRpdN8lLoKw== MIME-Version: 1.0 X-Received: by 10.112.84.202 with SMTP id b10mr9132742lbz.41.1459882238280; Tue, 05 Apr 2016 11:50:38 -0700 (PDT) Received: by 10.25.22.19 with HTTP; Tue, 5 Apr 2016 11:50:38 -0700 (PDT) In-Reply-To: <5702C67E.3060704@gmail.com> References: <56FBFA6A.4010400@alcatel-lucent.com> <1341e3fd501e4cbb8cbe9fbdc1d158de@XCH-RCD-006.cisco.com> <30089.1459781282@obiwan.sandelman.ca> <5702C67E.3060704@gmail.com> Date: Tue, 5 Apr 2016 11:50:38 -0700 Message-ID: From: John Strassner To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a1135ea063a0ced052fc152c0 Archived-At: Cc: Laurent Ciavaglia , Pierre Peloso , Duzongpeng , Michael Richardson , "Michael Behringer \(mbehring\)" , anima Subject: Re: [Anima] ANIMA intent discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 05 Apr 2016 23:02:09 -0000 --001a1135ea063a0ced052fc152c0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree as well regards, John On Mon, Apr 4, 2016 at 12:54 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 05/04/2016 02:48, Michael Richardson wrote: > > > > Michael Behringer (mbehring) wrote: > > > We=E2=80=99re starting to call everything that flies through an a= utonomic > > > network Intent, and the naming is getting very confusing. > > > > > To me: Intent =3D network wide human input policy > > > > okay. So to use the server load situation, the Intent from the human > might be: > > "Keep all CPUs between 50% and 70% utilization" > > > > (The Human might even specify this more abstractly as: > > "Minimize power consumption, while protecting against CPU load > spikes > > of up to 30%") > > > > > everything else: not Intent. Call it signaling, messaging, feedba= ck > > > loops, SNMP, GRASP, whatever. > > > > So, a node that finds itself at lower than 50% utilization wants to > migrate > > it's load elsewhere, and so it needs to signal that it is looking for > > something to take over so that it can turn itself off. That's a signal= . > > > > Is that signal in scope? > > IMHO, definitely. It sounds like a classical negotiation, where the > load-management > ASA concerned discovers and negotiates with another load-management ASA t= o > migrate > some or all of its load. And if two nodes running at 30% each found each > other, > the negotiation would need a tie-break rule to decide which one took the > load > and which one closed down. > > Brian > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > --=20 regards, John --001a1135ea063a0ced052fc152c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree as well

regards,
John

On Mon, Apr 4, 2016 at 12:54 PM, Brian E Carpenter <br= ian.e.carpenter@gmail.com> wrote:
On 05/04/2016 02:48, Michael Richardson wrote:
>
> Michael Behringer (mbehring) <mbehring@cisco.com> wrote:
>=C2=A0 =C2=A0 =C2=A0> We=E2=80=99re starting to call everything that= flies through an autonomic
>=C2=A0 =C2=A0 =C2=A0> network Intent, and the naming is getting very= confusing.
>
>=C2=A0 =C2=A0 =C2=A0> To me: Intent =3D network wide human input pol= icy
>
> okay. So to use the server load situation, the Intent from the human m= ight be:
>=C2=A0 =C2=A0 "Keep all CPUs between 50% and 70% utilization"=
>
> (The Human might even specify this more abstractly as:
>=C2=A0 =C2=A0 =C2=A0 "Minimize power consumption, while protecting= against CPU load spikes
>=C2=A0 =C2=A0 =C2=A0 of up to 30%")
>
>=C2=A0 =C2=A0 =C2=A0> everything else: not Intent. Call it signaling= , messaging, feedback
>=C2=A0 =C2=A0 =C2=A0> loops, SNMP, GRASP, whatever.
>
> So, a node that finds itself at lower than 50% utilization wants to mi= grate
> it's load elsewhere, and so it needs to signal that it is looking = for
> something to take over so that it can turn itself off.=C2=A0 That'= s a signal.
>
> Is that signal in scope?

IMHO, definitely. It sounds like a classical negotiation, where the load-ma= nagement
ASA concerned discovers and negotiates with another load-management ASA to = migrate
some or all of its load. And if two nodes running at 30% each found each ot= her,
the negotiation would need a tie-break rule to decide which one took the lo= ad
and which one closed down.

=C2=A0 =C2=A0Brian

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



--
regards,
John
--001a1135ea063a0ced052fc152c0-- From nobody Tue Apr 5 20:34:19 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9075612D734 for ; Tue, 5 Apr 2016 20:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 iEvgoNT1DRjx for ; Tue, 5 Apr 2016 20:34:15 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C05B12D704 for ; Tue, 5 Apr 2016 20:34:14 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id j11so24268639lfb.1 for ; Tue, 05 Apr 2016 20:34:14 -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; bh=kVZkhtBUOgtk11TdLQWM4tsm2eYS3CqhcHdR2HOfiRo=; b=w9ZZTNZ4MSGUrWmDQYde4GE7m9dG2evTzvbZsx+eCjR+qyJOGQshb1menul7OOpAsN X4TtR7f//AOFjR1zmBQ5CuYbWGiIwrq7rpDKJFMtdbJAr6Bj7p9OtHoZMkzokGqiEqmp OZXEHKlr71e2U0jTTxWhiVDW3u43URWzBhAs86VfW6m2LZlqsWI6HTThnNYH9pBV0R67 +z+ushAozaMh7mlvjYxiqywBw00Y39ohPAe6yasOzlKeBjoIcA+fmyBncYwXkl4iJTFH TnFvLKOZtJ0Zw0Gb/bz0ACIj+02eF4ST4r+UqEqJNTv9sY0vgy1pc/jSiPrfl5so0Nl0 Zf1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=kVZkhtBUOgtk11TdLQWM4tsm2eYS3CqhcHdR2HOfiRo=; b=DOaN60boX7JgpJVSY3ksnXHhmOQ80jaXAn7wpxXz9qTeo8vSlZ7+8aCgePt41hOBPh ZS1BSOvV8PUEKo+CoEm3LQtl19bOkzRGxzqY46D9yjO00z/gAqifJUA9mdqeFgQuosF8 QJ3L+JAkifpjwc0jfg3EEpEajNSqeIc0c4QPjvMLJqwL87CpzUN5R3qhiplbrxaJa7yq Ltu1IjhUpKNUj7c8A4jD4MDrMAKvQkhLndxml7qN06t/W1nqRP0kM3+d/gS1J3kmedAZ m7p4f6PewuDZ/Hc9whgH1e50HHxOLMnE7OvM9fN45FW0DQrBNNGeHzrkYxPBd4TuHdzv qc4w== X-Gm-Message-State: AD7BkJJiDPqZeDPIiaTzHf//iA8nVqLKNoOuTnixUsTQw7cNr9s2D9/fsuXV0oG7G189MIgcCdX9SQ65p5mhtQ== MIME-Version: 1.0 X-Received: by 10.25.205.7 with SMTP id d7mr9717362lfg.70.1459913652685; Tue, 05 Apr 2016 20:34:12 -0700 (PDT) Received: by 10.25.22.19 with HTTP; Tue, 5 Apr 2016 20:34:12 -0700 (PDT) In-Reply-To: <570440E5.8030003@gmail.com> References: <56FBFA6A.4010400@alcatel-lucent.com> <57006D4A.6070005@gmail.com> <570179AC.6090707@gmail.com> <570440E5.8030003@gmail.com> Date: Tue, 5 Apr 2016 20:34:12 -0700 Message-ID: From: John Strassner To: Brian E Carpenter , John Strassner Content-Type: multipart/alternative; boundary=001a1142091aabcfe2052fc8a258 Archived-At: Cc: Laurent Ciavaglia , Duzongpeng , anima , Michael Behringer , Pierre Peloso Subject: Re: [Anima] ANIMA intent discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 06 Apr 2016 03:34:18 -0000 --001a1142091aabcfe2052fc8a258 Content-Type: text/plain; charset=UTF-8 >> How is it contradictory? The intent is translated to a form that the ASAs >> can handle. > Right, and that is where we aren't quite in agreement. I've been > assuming that the Intent as distributed by GRASP *is* in the form > that ASAs can handle. Perhaps we are closer than you think :-) IFF we ignore the initial transformation (which I readily concede COULD be done by an ASA), then I actually agree with you - the output of the transformation SHOULD (MUST?) be in a form that ASAs can handle. regards, John On Tue, Apr 5, 2016 at 3:49 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 06/04/2016 06:40, John Strassner wrote: > > Carrying on the snipping tradition... > > > >>> However, I don't believe that this is the normal case, since in my > >>> view, Intent is not a PERL script, a python program, or a set of > >>> APIs - it is instead a (restricted) natural language. Putting a > >>> compiler for this on a router or switch is not a good idea, since > > > > > Well, IMHO it would be an interpreter... > > > > I don't have a strong feeling either way, but why (more out of > > curiosity)? > > Oh, just because it avoids having a separate process to do the > compilation, that's all. It's certainly not a standardization issue. > > > > >>> you would also need ontologies or some type of computational > >>> linguistic processing to handle not just synonyms, but variations > >>> in phrasing, etc. > > > >> ... and IMHO the Intent language would *not* be like that; it would > >> be algorithmic. What's the value in allowing it to be sloppy? > > > > Who says that natural language has to be sloppy? > > > > What I mean by restricted natural language is that it has a grammar > > that matches the needs of the constituency that is using it. For me, > > intent is not specifying an algorithm, it is specify what needs to be > > done, and let the machine implement the algorithm. > > Well sure, and I guess it's true that COBOL was originally touted as a > natural language, because you could write DIVIDE WAGES BY HOURS GIVING > PAYRATE. > In that sense, sure. > > > >> Also, > >> how can that approach be correctly internationalised? Whatever we do > >> must be very straightforward whatever language the human operator > >> speaks, which means that its syntax has to be rigid (and preferably > >> 1:1 translatable from an English-like presentation to any other > >> language). > > > > Agreed. In past work, we've done exactly that. See above comment. > > > >> That's why I keep saying that these and other > >> support functions should be in a (distributed) autonomic manager, > >> and that the autonomic manager translate intent to a form that > >> is consumable by the device. > > > >> If you mean that an autonomic node will manage (configure) any > >> number of subsidiary non-autonomic devices, we agree. And I think > >> this is something we should state explicitly in the reference model, > >> which I believe is missing at the moment. It is stated in the > >> GRASP spec, which is probably the wrong place for it: > > > > Agreed > > ... > > > >>> I haven't seen a good argument against this approach. To my > >>> knowledge, this approach is what has been commonly built. > >>> > >>> Also, if there is Intent that is meaningful only to certain ASAs, > >>> how can that semantic be handled in a generic Intent handler? > >>> > >>> That's why I prefer pub-sub to flooding. > >> > >> I find that contradictory with your description of it as pseudo-natural > >> language; what we deliver to ASAs needs to be straightforward to > > interpret. > > > > How is it contradictory? The intent is translated to a form that the ASAs > > can handle. > > Right, and that is where we aren't quite in agreement. I've been > assuming that the Intent as distributed by GRASP *is* in the form > that ASAs can handle. > > Rgds > Brian > > > > > regards, > > John > > > > On Sun, Apr 3, 2016 at 1:14 PM, Brian E Carpenter < > > brian.e.carpenter@gmail.com> wrote: > > > >> John, > >> On 04/04/2016 02:59, John Strassner wrote: > >>> Hi Brian, > >>> > >>>> > >>> ... > >>>>> I do not think that it is necessary to combine disparate > >>>>> intents into a single file. > >>> > >>>> That seems to mean that each recipient of multiple files has to > >>>> performance consistency checks and conflict resolution, unless > >>>> you have a watertight definition of 'disparate'. > >>> > >>> No, it means that: > >>> > >>> a) I don't believe that network elements are, in general, autonomic > >>> b) I believe that higher level autonomic managers are needed > >>> to perform these and other tasks. > >> > >> Of course, see my next comment. > >> > >>>> ... > >>>>> 5: Intent is processed/compiled by dedicated entities (in my > >>>>> case, these are agents). This is because it takes specific > >>>>> resources and specific knowledge to do this. > >>> > >>>> Well, we definitely need to talk about that. Do you mean that > >>>> each autonomic node would contain such an agent, or that such > >>>> agents would be few in number? > >>> > >>> That is dependent on the overall architectural approach. In > >>> systems that I have built, I have kept to the classic definition of > >>> agent, where it knows how to do a few things well. So, as in > >>> the AAMAS set of conferences, there are many types of agents > >>> that each perform one (or a few) tasks very well. > >>> > >>> In this approach, the nodes use however many agents they need. > >>> > >>>>> > >>>>> 6: I prefer pub-sub. If flooding, then it should be constrained. > >>> > >>>> Constrained flooding is the hardest case. If Intent is small, why > >>>> can't we flood it, with unicast pub/sub to fill in any gaps? > >>> > >>> Because I fail to see why most nodes would care about intent. > >>> The nodes are not autonomic, the autonomic managers are. > >> > >> Ah, I see that we have a slight terminology mismatch. When I write > >> "flood" I mean, very specifically, something sent to all autonomic > >> nodes. (Even more specifically, to all GRASP nodes, which listen > >> to the GRASP link-local multicast address.) Certainly, each such > >> node may be managing any number of non-autonomic nodes that don't > >> understand Intent and will not receive it. > >> > >>> You can't build an autonomic system by making every > >>> component autonomic - you can build an autonomic system > >>> by having the components collaborate to produce autonomic > >>> behavior. That's where we differ. > >>> > >>>>> 7: In general, Intent is NOT understood by nodes or ASAs. > >>>>> This is because the node or ASA would have to have access > >>>>> to additional significant resources. > >>> > >>>> If there is Intent support code in each node, is that a problem? > >> > >> Read "node" as "autonomic node". > >> > >>> If intent support code is present, then it is there for a good reason > >>> (or at least I hope so), and hence, no, that is not a problem. > >>> However, I don't believe that this is the normal case, since in my > >>> view, Intent is not a PERL script, a python program, or a set of > >>> APIs - it is instead a (restricted) natural language. Putting a > >>> compiler for this on a router or switch is not a good idea, since > >> > >> Well, IMHO it would be an interpreter... > >> > >>> you would also need ontologies or some type of computational > >>> linguistic processing to handle not just synonyms, but variations > >>> in phrasing, etc. > >> > >> ... and IMHO the Intent language would *not* be like that; it would > >> be algorithmic. What's the value in allowing it to be sloppy? Also, > >> how can that approach be correctly internationalised? Whatever we do > >> must be very straightforward whatever language the human operator > >> speaks, which means that its syntax has to be rigid (and preferably > >> 1:1 translatable from an English-like presentation to any other > >> language). > >> > >>> That's why I keep saying that these and other > >>> support functions should be in a (distributed) autonomic manager, > >>> and that the autonomic manager translate intent to a form that > >>> is consumable by the device. > >> > >> If you mean that an autonomic node will manage (configure) any > >> number of subsidiary non-autonomic devices, we agree. And I think > >> this is something we should state explicitly in the reference model, > >> which I believe is missing at the moment. It is stated in the > >> GRASP spec, which is probably the wrong place for it: > >> It is understood that in realistic deployments, not all devices will > >> support GRASP. It is expected that some autonomic service agents > >> will directly manage a group of non-autonomic nodes, and that other > >> non-autonomic nodes will be managed traditionally. > >> > >>> I haven't seen a good argument against this approach. To my > >>> knowledge, this approach is what has been commonly built. > >>> > >>>> Also, if there is Intent that is meaningful only to certain ASAs, > >>>> how can that semantic be handled in a generic Intent handler? > >>> > >>> That's why I prefer pub-sub to flooding. > >> > >> I find that contradictory with your description of it as pseudo-natural > >> language; what we deliver to ASAs needs to be straightforward to > interpret. > >> > >> Rgds > >> Brian > >> > >>> > >>> regards, > >>> John > >>> > >>> On Sat, Apr 2, 2016 at 6:09 PM, Brian E Carpenter < > >>> brian.e.carpenter@gmail.com> wrote: > >>> > >>>> On 03/04/2016 03:31, John Strassner wrote: > >>>> > >>>> > >>>> ... > >>>>> I do not think that it is necessary to combine disparate > >>>>> intents into a single file. > >>>> > >>>> That seems to mean that each recipient of multiple files has to > >>>> performance consistency checks and conflict resolution, unless > >>>> you have a watertight definition of 'disparate'. > >>>> > >>>> ... > >>>>> 5: Intent is processed/compiled by dedicated entities (in my > >>>>> case, these are agents). This is because it takes specific > >>>>> resources and specific knowledge to do this. > >>>> > >>>> Well, we definitely need to talk about that. Do you mean that > >>>> each autonomic node would contain such an agent, or that such > >>>> agents would be few in number? > >>>> > >>>>> > >>>>> 6: I prefer pub-sub. If flooding, then it should be constrained. > >>>> > >>>> Constrained flooding is the hardest case. If Intent is small, why > >>>> can't we flood it, with unicast pub/sub to fill in any gaps? > >>>> > >>>>> 7: In general, Intent is NOT understood by nodes or ASAs. > >>>>> This is because the node or ASA would have to have access > >>>>> to additional significant resources. > >>>> > >>>> If there is Intent support code in each node, is that a problem? > >>>> Also, if there is Intent that is meaningful only to certain ASAs, > >>>> how can that semantic be handled in a generic Intent handler? > >>>> > >>>> Rgds > >>>> Brian > >>>> > >>>> > >>>> > >>> > >>> > >> > > > > > > > -- regards, John --001a1142091aabcfe2052fc8a258 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>> How is it contradictory? The intent is trans= lated to a form that the ASAs
>> can handle.

> Right, a= nd that is where we aren't quite in agreement. I've been
> a= ssuming that the Intent as distributed by GRASP *is* in the form
> t= hat ASAs can handle.

Perhaps we are closer than yo= u think :-)

IFF we ignore the initial transformati= on (which I readily concede COULD
be done by an ASA), then I actu= ally agree with you - the output of the
transformation SHOULD (MU= ST?) be in a form that ASAs can handle.

regards,
John

On Tue, Apr 5, 2016 at 3:49 PM, Brian E Carpenter <b= rian.e.carpenter@gmail.com> wrote:
On 06/04/2016 06:40, John Strassner wrote:
> Carrying on the snipping tradition...
>
>>> However, I don't believe that this is the normal case, sin= ce in my
>>> view, Intent is not a PERL script, a python program, or a set = of
>>> APIs - it is instead a (restricted) natural language. Putting = a
>>> compiler for this on a router or switch is not a good idea, si= nce
>
>=C2=A0 > Well, IMHO it would be an interpreter...
>
> I don't have a strong feeling either way, but why (more out of
> curiosity)?

Oh, just because it avoids having a separate process to do the
compilation, that's all. It's certainly not a standardization issue= .

>
>>> you would also need ontologies or some type of computational >>> linguistic processing to handle not just synonyms, but variati= ons
>>> in phrasing, etc.
>
>> ... and IMHO the Intent language would *not* be like that; it woul= d
>> be algorithmic. What's the value in allowing it to be sloppy?<= br> >
> Who says that natural language has to be sloppy?
>
> What I mean by restricted natural language is that it has a grammar > that matches the needs of the constituency that is using it. For me, > intent is not specifying an algorithm, it is specify what needs to be<= br> > done, and let the machine implement the algorithm.

Well sure, and I guess it's true that COBOL was originally touted as a<= br> natural language, because you could write DIVIDE WAGES BY HOURS GIVING PAYR= ATE.
In that sense, sure.
>
>> Also,
>> how can that approach be correctly internationalised? Whatever we = do
>> must be very straightforward whatever language the human operator<= br> >> speaks, which means that its syntax has to be rigid (and preferabl= y
>> 1:1 translatable from an English-like presentation to any other >> language).
>
> Agreed. In past work, we've done exactly that. See above comment.<= br> >
>> That's why I keep saying that these and other
>> support functions should be in a (distributed) autonomic manager,<= br> >> and that the autonomic manager translate intent to a form that
>> is consumable by the device.
>
>> If you mean that an autonomic node will manage (configure) any
>> number of subsidiary non-autonomic devices, we agree. And I think<= br> >> this is something we should state explicitly in the reference mode= l,
>> which I believe is missing at the moment. It is stated in the
>> GRASP spec, which is probably the wrong place for it:
>
> Agreed
> ...
>
>>> I haven't seen a good argument against this approach. To m= y
>>> knowledge, this approach is what has been commonly built.
>>>
>>> Also, if there is Intent that is meaningful only to certain AS= As,
>>> how can that semantic be handled in a generic Intent handler?<= br> >>>
>>> That's why I prefer pub-sub to flooding.
>>
>> I find that contradictory with your description of it as pseudo-na= tural
>> language; what we deliver to ASAs needs to be straightforward to > interpret.
>
> How is it contradictory? The intent is translated to a form that the A= SAs
> can handle.

Right, and that is where we aren't quite in agreement. I've been assuming that the Intent as distributed by GRASP *is* in the form
that ASAs can handle.

Rgds
=C2=A0 =C2=A0Brian

>
> regards,
> John
>
> On Sun, Apr 3, 2016 at 1:14 PM, Brian E Carpenter <
> brian.e.carpenter@gmail= .com> wrote:
>
>> John,
>> On 04/04/2016 02:59, John Strassner wrote:
>>> Hi Brian,
>>>
>>>> <snipped even more vigorously>
>>> ...
>>>>> I do not think that it is necessary to combine dispara= te
>>>>> intents into a single file.
>>>
>>>> That seems to mean that each recipient of multiple files h= as to
>>>> performance consistency checks and conflict resolution, un= less
>>>> you have a watertight definition of 'disparate'. >>>
>>> No, it means that:
>>>
>>>=C2=A0 =C2=A0 a) I don't believe that network elements are,= in general, autonomic
>>>=C2=A0 =C2=A0 b) I believe that higher level autonomic managers= are needed
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 to perform these and other tasks. >>
>> Of course, see my next comment.
>>
>>>>=C2=A0 ...
>>>>> 5:=C2=A0 Intent is processed/compiled by dedicated ent= ities (in my
>>>>> case, these are agents). This is because it takes spec= ific
>>>>> resources and specific knowledge to do this.
>>>
>>>> Well, we definitely need to talk about that. Do you mean t= hat
>>>> each autonomic node would contain such an agent, or that s= uch
>>>> agents would be few in number?
>>>
>>> That is dependent on the overall architectural approach. In >>> systems that I have built, I have kept to the classic definiti= on of
>>> agent, where it knows how to do a few things well. So, as in >>> the AAMAS set of conferences, there are many types of agents >>> that each perform one (or a few) tasks very well.
>>>
>>> In this approach, the nodes use however many agents they need.=
>>>
>>>>>
>>>>> 6: I prefer pub-sub. If flooding, then it should be co= nstrained.
>>>
>>>> Constrained flooding is the hardest case. If Intent is sma= ll, why
>>>> can't we flood it, with unicast pub/sub to fill in any= gaps?
>>>
>>> Because I fail to see why most nodes would care about intent.<= br> >>> The nodes are not autonomic, the autonomic managers are.
>>
>> Ah, I see that we have a slight terminology mismatch. When I write=
>> "flood" I mean, very specifically, something sent to all= autonomic
>> nodes. (Even more specifically, to all GRASP nodes, which listen >> to the GRASP link-local multicast address.) Certainly, each such >> node may be managing any number of non-autonomic nodes that don= 9;t
>> understand Intent and will not receive it.
>>
>>> You can't build an autonomic system by making every
>>> component autonomic - you can build an autonomic system
>>> by having the components collaborate to produce autonomic
>>> behavior. That's where we differ.
>>>
>>>>> 7:=C2=A0 In general, Intent is NOT understood by nodes= or ASAs.
>>>>> This is because the node or ASA would have to have acc= ess
>>>>> to additional significant resources.
>>>
>>>> If there is Intent support code in each node, is that a pr= oblem?
>>
>> Read "node" as "autonomic node".
>>
>>> If intent support code is present, then it is there for a good= reason
>>> (or at least I hope so), and hence, no, that is not a problem.=
>>> However, I don't believe that this is the normal case, sin= ce in my
>>> view, Intent is not a PERL script, a python program, or a set = of
>>> APIs - it is instead a (restricted) natural language. Putting = a
>>> compiler for this on a router or switch is not a good idea, si= nce
>>
>> Well, IMHO it would be an interpreter...
>>
>>> you would also need ontologies or some type of computational >>> linguistic processing to handle not just synonyms, but variati= ons
>>> in phrasing, etc.
>>
>> ... and IMHO the Intent language would *not* be like that; it woul= d
>> be algorithmic. What's the value in allowing it to be sloppy? = Also,
>> how can that approach be correctly internationalised? Whatever we = do
>> must be very straightforward whatever language the human operator<= br> >> speaks, which means that its syntax has to be rigid (and preferabl= y
>> 1:1 translatable from an English-like presentation to any other >> language).
>>
>>> That's why I keep saying that these and other
>>> support functions should be in a (distributed) autonomic manag= er,
>>> and that the autonomic manager translate intent to a form that=
>>> is consumable by the device.
>>
>> If you mean that an autonomic node will manage (configure) any
>> number of subsidiary non-autonomic devices, we agree. And I think<= br> >> this is something we should state explicitly in the reference mode= l,
>> which I believe is missing at the moment. It is stated in the
>> GRASP spec, which is probably the wrong place for it:
>>=C2=A0 =C2=A0 It is understood that in realistic deployments, not a= ll devices will
>>=C2=A0 =C2=A0 support GRASP.=C2=A0 It is expected that some autonom= ic service agents
>>=C2=A0 =C2=A0 will directly manage a group of non-autonomic nodes, = and that other
>>=C2=A0 =C2=A0 non-autonomic nodes will be managed traditionally. >>
>>> I haven't seen a good argument against this approach. To m= y
>>> knowledge, this approach is what has been commonly built.
>>>
>>>> Also, if there is Intent that is meaningful only to certai= n ASAs,
>>>> how can that semantic be handled in a generic Intent handl= er?
>>>
>>> That's why I prefer pub-sub to flooding.
>>
>> I find that contradictory with your description of it as pseudo-na= tural
>> language; what we deliver to ASAs needs to be straightforward to i= nterpret.
>>
>> Rgds
>>=C2=A0 =C2=A0Brian
>>
>>>
>>> regards,
>>> John
>>>
>>> On Sat, Apr 2, 2016 at 6:09 PM, Brian E Carpenter <
>>> brian.e.carpent= er@gmail.com> wrote:
>>>
>>>> On 03/04/2016 03:31, John Strassner wrote:
>>>>
>>>> <snipped even more vigorously>
>>>> ...
>>>>> I do not think that it is necessary to combine dispara= te
>>>>> intents into a single file.
>>>>
>>>> That seems to mean that each recipient of multiple files h= as to
>>>> performance consistency checks and conflict resolution, un= less
>>>> you have a watertight definition of 'disparate'. >>>>
>>>> ...
>>>>> 5:=C2=A0 Intent is processed/compiled by dedicated ent= ities (in my
>>>>> case, these are agents). This is because it takes spec= ific
>>>>> resources and specific knowledge to do this.
>>>>
>>>> Well, we definitely need to talk about that. Do you mean t= hat
>>>> each autonomic node would contain such an agent, or that s= uch
>>>> agents would be few in number?
>>>>
>>>>>
>>>>> 6: I prefer pub-sub. If flooding, then it should be co= nstrained.
>>>>
>>>> Constrained flooding is the hardest case. If Intent is sma= ll, why
>>>> can't we flood it, with unicast pub/sub to fill in any= gaps?
>>>>
>>>>> 7:=C2=A0 In general, Intent is NOT understood by nodes= or ASAs.
>>>>> This is because the node or ASA would have to have acc= ess
>>>>> to additional significant resources.
>>>>
>>>> If there is Intent support code in each node, is that a pr= oblem?
>>>> Also, if there is Intent that is meaningful only to certai= n ASAs,
>>>> how can that semantic be handled in a generic Intent handl= er?
>>>>
>>>> Rgds
>>>>=C2=A0 =C2=A0Brian
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
>



--
regards,
John
--001a1142091aabcfe2052fc8a258-- From nobody Wed Apr 6 05:25:28 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61B412D0C6 for ; Wed, 6 Apr 2016 05:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 V9LGqMZjMVQz for ; Wed, 6 Apr 2016 05:25:25 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5500812D0A9 for ; Wed, 6 Apr 2016 05:25:25 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 0D5872002A; Wed, 6 Apr 2016 08:28:56 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2A80F6375A; Wed, 6 Apr 2016 08:25:24 -0400 (EDT) From: Michael Richardson To: "Michael Behringer \(mbehring\)" In-Reply-To: References: <56FBFA6A.4010400@alcatel-lucent.com> <1341e3fd501e4cbb8cbe9fbdc1d158de@XCH-RCD-006.cisco.com> <56FE7492.1070308@joelhalpern.com> <31002.1459781527@obiwan.sandelman.ca> <57028091.1060305@joelhalpern.com> <16723.1459795114@obiwan.sandelman.ca> <5702D35B.7060005@joelhalpern.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: "Joel M. Halpern" , anima , John Strassner Subject: Re: [Anima] ANIMA intent discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 06 Apr 2016 12:25:27 -0000 --=-=-= Content-Type: text/plain Michael Behringer (mbehring) wrote: > - Intent(1): > o freeze network enrolment (just as an example) > - Intent(2): > o unfreeze network enrolment (just as an example) As long as there are expiry dates so that nodes know how long to cache this information, and how long until they should expect a new set of intents, I don't care. I'm also happy if Intent(2) says, "Intent(1) is cancelled" -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVwUAMYCLcPvd0N1lAQJwEgf+NDzOOL1Vh2bNg9ZwD2vlQtCAuNlIqgD8 0PnB5H+W0/p2y0O7R1vSlM1gPvzVZfE2/WXRJ+EwiPtz6u4zWG5XyqwI4q/HGLTv eYj3JCFFJv2XbKvBJxMnuJe0+X9cvkTiFWAZtS1MdGfSHv/tyz0AFlduQhkCQNZZ LlcAee2eOUVsRnufyd/qxwERvBQCVSNzvEdw183AnGwzfqs1izyWw87Q//i/xh9v sVAbRpbPzfA+MlXnjBPF/4SylQhW1jdQj2/kyQF4SPYFSoOnXVe/RAi5jqGaWCZt h6b13XG4ANv3oyZgxIX46l7nxxk+8zSEY2WHnuIMYp9+fd/8fBjMcg== =swzo -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 6 07:40:22 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5569312D51C for ; Wed, 6 Apr 2016 07:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 rFbxHBvXMZRU for ; Wed, 6 Apr 2016 07:40:20 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 C4E7D12D1E4 for ; Wed, 6 Apr 2016 07:40:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 93959240A9B; Wed, 6 Apr 2016 07:40:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1459953620; bh=7p3DMFWPB29lEVw2bL/eZusRYi8B4EeznaWyq7eX+3k=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=jfnw6AtJpSB7ogkoG39mfFaJsXAx2N1BMyrFXbrj8G2zz5GzROPYfh8AqXnlQ4Mly UrwK3UCoEt+Ycvqkqnc3W2j/mV0NpQp4BS5GFxnwbN6aTS+F7IGugEZonNcw1mTLgn rml5N0eTqRFuA94A9BzyuAzVDxQLcvEW5yUiLlHQ= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from dhcp-893a.meeting.ietf.org (unknown [31.133.138.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 5265B2407D7; Wed, 6 Apr 2016 07:40:19 -0700 (PDT) To: Michael Richardson , "Michael Behringer (mbehring)" References: <56FBFA6A.4010400@alcatel-lucent.com> <1341e3fd501e4cbb8cbe9fbdc1d158de@XCH-RCD-006.cisco.com> <56FE7492.1070308@joelhalpern.com> <31002.1459781527@obiwan.sandelman.ca> <57028091.1060305@joelhalpern.com> <16723.1459795114@obiwan.sandelman.ca> <5702D35B.7060005@joelhalpern.com> <16172.1459945524@obiwan.sandelman.ca> From: "Joel M. Halpern" Message-ID: <57051FCF.8010202@joelhalpern.com> Date: Wed, 6 Apr 2016 10:40:15 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <16172.1459945524@obiwan.sandelman.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: anima , John Strassner Subject: Re: [Anima] ANIMA intent discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 06 Apr 2016 14:40:22 -0000 I would expect that most policies will have an indefinite lifetime from the user perspective. We can inssit on some limited lifetime, but I would like to understand why we would want to. Yours, Joel On 4/6/16 8:25 AM, Michael Richardson wrote: > Michael Behringer (mbehring) wrote: > > - Intent(1): > > o freeze network enrolment (just as an example) > > > - Intent(2): > > o unfreeze network enrolment (just as an example) > > As long as there are expiry dates so that nodes know how long to cache this > information, and how long until they should expect a new set of intents, I > don't care. > I'm also happy if Intent(2) says, "Intent(1) is cancelled" > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > From nobody Wed Apr 6 08:05:44 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C9012D166 for ; Wed, 6 Apr 2016 08:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 hc6MASu1u7JG for ; Wed, 6 Apr 2016 08:05:41 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70BF212D697 for ; Wed, 6 Apr 2016 08:02:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1253; q=dns/txt; s=iport; t=1459954923; x=1461164523; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mG2zJN4jbbd2I2LdMN22uXsjiPK9cmrle/q0udrT0rg=; b=B299fU9p2TERQya5b3O2ZTCcwdyx1Sn+xZsv0LkynBcP0QFGxgHVWzgw /tMywC0qW+OWO2W+fmp31DyF7F7LrtWrCGzCi/+JpmqHMIbNk7yErRgFz jtZomq0omnQs2hNZLwpTSSrMh3bjZCN+3mzf3tG/bLE1umyWb6vn1Maqj 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ACAgCAJAVX/5xdJa1cgzeBUAaubolIg?= =?us-ascii?q?g8BDYFygl2DMAKBSTgUAQEBAQEBAWUnhEEBAQEEOj8MBAIBCBEEAQEBHgkHIRE?= =?us-ascii?q?UCQgCBAENBQiICgMSu2QNhHwBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhiGES4JBg?= =?us-ascii?q?ViFfAWHZYcaiFExAYwVgW6PFYdHh1kBHgEBQoNnbIc2BDt+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,447,1454976000"; d="scan'208";a="258044425" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Apr 2016 15:02:02 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u36F22v9028891 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Apr 2016 15:02:02 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 6 Apr 2016 10:02:01 -0500 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.009; Wed, 6 Apr 2016 10:02:01 -0500 From: "Michael Behringer (mbehring)" To: "Joel M. Halpern" , Michael Richardson Thread-Topic: [Anima] ANIMA intent discussion Thread-Index: AQHRip6r6CBKKtp6FEycGBHZ8l3kKJ9002wA///fMyCAAL08AIAE0deAgAABKoCAAD4bAIAAJJaAgAFwOwD//76zkIABaOIAgAAlroD//7I8oA== Date: Wed, 6 Apr 2016 15:02:01 +0000 Message-ID: <7af7958639a74ad892b2195dc990bbf1@XCH-RCD-006.cisco.com> References: <56FBFA6A.4010400@alcatel-lucent.com> <1341e3fd501e4cbb8cbe9fbdc1d158de@XCH-RCD-006.cisco.com> <56FE7492.1070308@joelhalpern.com> <31002.1459781527@obiwan.sandelman.ca> <57028091.1060305@joelhalpern.com> <16723.1459795114@obiwan.sandelman.ca> <5702D35B.7060005@joelhalpern.com> <16172.1459945524@obiwan.sandelman.ca> <57051FCF.8010202@joelhalpern.com> In-Reply-To: <57051FCF.8010202@joelhalpern.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.88.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: anima , John Strassner Subject: Re: [Anima] ANIMA intent discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 06 Apr 2016 15:05:42 -0000 +1 > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: 06 April 2016 11:40 > To: Michael Richardson ; Michael Behringer > (mbehring) > Cc: John Strassner ; anima > Subject: Re: [Anima] ANIMA intent discussion >=20 > I would expect that most policies will have an indefinite lifetime from t= he > user perspective. We can inssit on some limited lifetime, but I would li= ke to > understand why we would want to. >=20 > Yours, > Joel >=20 > On 4/6/16 8:25 AM, Michael Richardson wrote: > > Michael Behringer (mbehring) wrote: > > > - Intent(1): > > > o freeze network enrolment (just as an example) > > > > > - Intent(2): > > > o unfreeze network enrolment (just as an example) > > > > As long as there are expiry dates so that nodes know how long to cache > > this information, and how long until they should expect a new set of > > intents, I don't care. > > I'm also happy if Intent(2) says, "Intent(1) is cancelled" > > > > -- > > Michael Richardson , Sandelman Software > Works > > -=3D IPv6 IoT consulting =3D- > > > > > > From nobody Wed Apr 6 12:37:11 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD8A12D6D5 for ; Wed, 6 Apr 2016 12:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 pk8My827u0bv for ; Wed, 6 Apr 2016 12:37:08 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3338A12D614 for ; Wed, 6 Apr 2016 12:37:08 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 179C22002A for ; Wed, 6 Apr 2016 15:40:40 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 253206375A for ; Wed, 6 Apr 2016 15:37:07 -0400 (EDT) From: Michael Richardson To: "anima\@ietf.org" In-Reply-To: <56FAD4D0.3080009@gmail.com> References: <77a801fd616449f0bc4c8a664286b9cc@XCH-RCD-006.cisco.com> <56F5DE90.6010509@gmail.com> <405bab40b6694cc5893f2cd89ef8e913@XCH-RCD-006.cisco.com> <56FAD4D0.3080009@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] 7.2 Specific ASAs [was Reference Model Issues] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 06 Apr 2016 19:37:10 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >>> On 25/03/2016 06:52, Michael Behringer (mbehring) wrote: >>> ... >>>> 7.2 Specific ASAs [for the Enrolment Process] >>>> - should explain MUST implement >>> >>> And that they MUST be present in all nodes by default. In particular the >>> Proxy ASA MUST discover whether it needs to be active (see discussion >>> yesterday). I suppose the same applies to the Registrar ASA but possibly that >>> needs to be configured "on" by the NOC? >> >> Yes, agree, that's what I meant. Switching the proxy ASA off if not needed is an optimisation, in my view. (Also, once enrolled, you can switch off the enrolment ASA of course). >> >> The registrar is effectively a policy definition point (PDP), thus MUST be set up manually. > Yes, that seems reasonable in a "professionally managed network" which is the > Anima target. I wouldn't exclude an election process in a completely unmanaged > network, but that's out of scope here. We probably want only one active registrar, and we might want to have a passive backup in bigger networks. Setting those up is a manual process, but the election would still be useful. The machines likely are not co-located on the same LAN, so mechanisms like VRRP won't work. If GRASP can do elections across the ACP, then we should use that. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVwVlYICLcPvd0N1lAQJufAgAljYSTr07k407t/X5B5ak88hVhQq6rwyy 3hSWRJwnAOapzxvHp9JwCkMzwSghirq1lZyj6ScIFriYVHNosy4pOSJbb+8xAgf8 HY0y/ntxJwHDt6r6YRcITf2hJ097jV5n/lg2+n+eFyFs46jcsTNTJ0knlkIu26ng 6FxOw6h4lzjBc4jo39AXNtFf7ulfa4987qwg9ynL1aUkhMPa2u56+GiIWQumusZ3 dOB8OQ1dpDrsJ0vpmwruZBSQNQxP8Jp9+Tc8tJyhbIVQv8wnbc5xBZiRzDMv1bQ5 /7Zyrblloa33bNHVpQ2y33KBO56ukDGOKGzNHZ246BEGe1KHJftmCA== =zHoS -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 6 12:53:39 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317E912D12E for ; Wed, 6 Apr 2016 12:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 54HD9j4GbC4L for ; Wed, 6 Apr 2016 12:53:36 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BDB112D10C for ; Wed, 6 Apr 2016 12:53:36 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id c20so39919356pfc.1 for ; Wed, 06 Apr 2016 12:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=2irOI3NuE5FXlJgj6Hh25ko0jlXsKFV8Mzpt1Wzp/D4=; b=f7Hr+JOmo9ssxKfQqA5TKHT79PUQzYRlc2w/vJQ1jalughGDmFfaN882dkOVJ36AWH oPlDfFy3rPrwbAIHHT3WJJyqmEHwnYq2Aa1sEGDuZ7hPi7PxGvBaw7rptbpCe2QQA8gn kdCvPrw7svEMBPM3sBdlPPPygBo5cS98YLpvBQThdVck6cwi/qcKYcnYS0DVMSSimhIi lxEvHqRqzogHKQGRV06vIDKMNwAbXxrHM4MGwFRt3JfJzQ1ytVFUEXzG2Fo+Ft/NwLeQ B5iGscOmnHw43GtOCglNkaUwsncMSrzU1aluxGuqrq/MgH1lxq9aexE/XSP7ss/KZJEf dHtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=2irOI3NuE5FXlJgj6Hh25ko0jlXsKFV8Mzpt1Wzp/D4=; b=NLunxT8YUozVSC5P/2jS8aNuW3LHwGBQIHmDOLvGFwzT5/aUCq+Lh8DuAcaP2ifmeS U+BVmYgfIKknOpF94rssOkwJcv3aiIFYh+Ym/ho4LywqyXqMKO1fRT/qtmxJ56aj0mFd MDsoNoXt61NJ1DZyWNi/Zq1j1Ki41TcLGUlFWjz0P6s1O37q7G3k1Lra6zj9/ug7yWFs cQ+oAcDe/qGqb8OSRRAElwTXhOCw7X+LCwqguMkvu+PkjLNHbb9xgfRvOHDicWn5w1Z2 nJDUZBFZUf9coYnStfgzV5jwHiDXFZlW/ZlKRmbCUr5GuxfKGCmAaWRIudFOsh+LrmKf wU0Q== X-Gm-Message-State: AD7BkJL1ryvg8XLVHku3cJlDb8nJb+KbGOzN7EFKHVscD5Ht7TogmSpuXhnI9g22B/qY6g== X-Received: by 10.98.8.196 with SMTP id 65mr40517152pfi.53.1459972416066; Wed, 06 Apr 2016 12:53:36 -0700 (PDT) Received: from ?IPv6:2406:e007:481c:1:28cc:dc4c:9703:6781? ([2406:e007:481c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q20sm6792284pfi.63.2016.04.06.12.53.33 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2016 12:53:34 -0700 (PDT) To: Michael Richardson , "anima@ietf.org" References: <77a801fd616449f0bc4c8a664286b9cc@XCH-RCD-006.cisco.com> <56F5DE90.6010509@gmail.com> <405bab40b6694cc5893f2cd89ef8e913@XCH-RCD-006.cisco.com> <56FAD4D0.3080009@gmail.com> <15440.1459971427@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <57056942.50209@gmail.com> Date: Thu, 7 Apr 2016 07:53:38 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <15440.1459971427@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] 7.2 Specific ASAs [was Reference Model Issues] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 06 Apr 2016 19:53:39 -0000 On 07/04/2016 07:37, Michael Richardson wrote: > > Brian E Carpenter wrote: > >>> On 25/03/2016 06:52, Michael Behringer (mbehring) wrote: > >>> ... > >>>> 7.2 Specific ASAs [for the Enrolment Process] > >>>> - should explain MUST implement > >>> > >>> And that they MUST be present in all nodes by default. In particular the > >>> Proxy ASA MUST discover whether it needs to be active (see discussion > >>> yesterday). I suppose the same applies to the Registrar ASA but possibly that > >>> needs to be configured "on" by the NOC? > >> > >> Yes, agree, that's what I meant. Switching the proxy ASA off if not needed is an optimisation, in my view. (Also, once enrolled, you can switch off the enrolment ASA of course). > >> > >> The registrar is effectively a policy definition point (PDP), thus MUST be set up manually. > > > Yes, that seems reasonable in a "professionally managed network" which is the > > Anima target. I wouldn't exclude an election process in a completely unmanaged > > network, but that's out of scope here. > > We probably want only one active registrar, and we might want to have a > passive backup in bigger networks. Setting those up is a manual process, but > the election would still be useful. The machines likely are not co-located > on the same LAN, so mechanisms like VRRP won't work. > > If GRASP can do elections across the ACP, then we should use that. I'm sure we could model such an election as a negotiation (I'm imagining two ASAs called "Clinton" and "Cruz" as I write). But of course this won't work prior to ACP formation, so there's another bootstrapping situation. Brian From nobody Thu Apr 7 04:14:53 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1289012D6FC for ; Thu, 7 Apr 2016 04:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 eqyu_27lzIfH for ; Thu, 7 Apr 2016 04:14:49 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 643AB12D7C1 for ; Thu, 7 Apr 2016 04:14:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2396; q=dns/txt; s=iport; t=1460027682; x=1461237282; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=eXAYieW3VlyVxop2Q2rB8wUkGTNxBXH8KVb5hIICWqs=; b=d3u+49DUQw4qW7sVgcQEcc3yp4prAxI+deCZoZGso3OOFwPrR+RcgEIe jgYx/1KGR854nIa3CzP7IN10vXwpLA4M14YVp4XNqwzJ0QFBRk5r1P7F9 wpCbxPaPkTXAJmVPMpHWmJVZTd4+JoSC/JRuBcV2RiFcuLEumSQIumvDw U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AlAgCPQAZX/5NdJa1cgzeBVrpKAQ2Bc?= =?us-ascii?q?4dUOBQBAQEBAQEBZSeESCcTUQE+QiYBBBuIH59doU4BCwEdhiGIZYV7BZJ0hRA?= =?us-ascii?q?BjgSBbo0nhh+JBAEeAQFCg2eIIz5+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208";a="91169583" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Apr 2016 11:14:41 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u37BEf3F021888 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 7 Apr 2016 11:14:41 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 7 Apr 2016 06:14:40 -0500 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.009; Thu, 7 Apr 2016 06:14:40 -0500 From: "Michael Behringer (mbehring)" To: anima Thread-Topic: Intent Discussion Thread-Index: AdGQvf+xeVbNHCZJTzaTRxDR/JZAHg== Date: Thu, 7 Apr 2016 11:14:40 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.87.155] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Anima] Intent Discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 07 Apr 2016 11:14:51 -0000 Yesterday Joel, John, Toerless, Jeferson, Jason and I met to discuss about = Intent, and see where we agree / disagree. Below some notes for remote atte= ndees, to chime in. Obviously, nothing is cast in stone, these are still pe= rsonal views, just aggregated in a form that we are all more or less happy = with. Maybe that helps the discussion. Michael -- Intent Discussion=20 - some draft consensus between Joel, John, Toerless, Jeferson, Jason, Micha= el Naming:=20 - High level policy =3D Intent - Any messaging to enforce that, signalling of parameters resulting from it= ,=20 etc may be required but is NOT Intent Intent one single file?=20 - Intent may come from different entry points - should not enforce a single file. (but it may be initially) - but shouldn't be just lots of separate statements either.=20 Fragmenting Intent - however we express Intent, we don't want to require that Intent MUST be=20 able to be de-composed into its atomic bits with a fixed size limit --> we must not require that atomic bit MUST fit into a packet. - some form of fragmenting an Intent file is ok + could be done through using TCP (or similar) + could be done by fragmenting Intent into individual parts Updating / removing Intent - Intent doesn't have a mandatory expiration date - if no longer required / desired, remove or update Intent.=20 - it's ok to have a *statement* to remove a *statement*.=20 Flooded?=20 - good enough for now to flood. BUT: as long as we have a more granular way to "upgrade to" later.=20 Conflict resolution?=20 - device needs to deal with conflict and react predictably.=20 - device may not be able to resolve locally.=20 - but the conflict may need to be resolved centrally --> needs a feedback l= oop.=20 (we don't specify where those feedback loops are going - several posibili= ties) "Translating" Intent - Does Intent have to be "translated" from a high level policy to something= =20 more lower level before it gets distributed?=20 - Ex from John: "Platinum customer" - always best service.=20 But I shouldn't map everything (ex: FTP) into an EF queue.=20 - might require to translate to an intermediate Intent format.=20 - this tranlation should probably not happen on the devices. this translation could/should happen centrally; - more discussion needed on this point. From nobody Thu Apr 7 07:16:34 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF8612D509 for ; Thu, 7 Apr 2016 07:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 INFZGklhj0p0 for ; Thu, 7 Apr 2016 07:16:27 -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 4684C12D4FD for ; Thu, 7 Apr 2016 07:16:17 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id D10748579C8ED; Thu, 7 Apr 2016 14:16:12 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u37EGFtQ016567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Apr 2016 14:16:15 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 u37EFjhi026277 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Apr 2016 16:16:13 +0200 Received: from [135.224.220.139] (135.239.27.40) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 7 Apr 2016 16:15:59 +0200 To: "EXT Michael Behringer (mbehring)" , anima References: From: Laurent Ciavaglia Organization: Bell Labs Message-ID: <57066B9E.7020505@alcatel-lucent.com> Date: Thu, 7 Apr 2016 16:15:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------030604090900040604080601" X-Originating-IP: [135.239.27.40] Archived-At: Subject: Re: [Anima] Intent Discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 07 Apr 2016 14:16:31 -0000 --------------030604090900040604080601 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Dear Michael, all, Thanks for sharing the summary, it is appreciated to be able to stay connected with on-site discussion ;) >Re: Conflict resolution? >- device needs to deal with conflict and react predictably. >- device may not be able to resolve locally. >- but the conflict may need to be resolved centrally --> needs a feedback loop. > (we don't specify where those feedback loops are going - several possibilities) This is a perfect introduction for my talk in ANIMA session today: 16:35 - 16:45 Autonomic Functions Coordination - draft-ciavaglia-anima-coordination Thanks, Laurent. On 07/04/2016 13:14, EXT Michael Behringer (mbehring) wrote: > Yesterday Joel, John, Toerless, Jeferson, Jason and I met to discuss about Intent, and see where we agree / disagree. Below some notes for remote attendees, to chime in. Obviously, nothing is cast in stone, these are still personal views, just aggregated in a form that we are all more or less happy with. Maybe that helps the discussion. > > Michael > > -- > > Intent Discussion > - some draft consensus between Joel, John, Toerless, Jeferson, Jason, Michael > > Naming: > - High level policy = Intent > - Any messaging to enforce that, signalling of parameters resulting from it, > etc may be required but is NOT Intent > > Intent one single file? > - Intent may come from different entry points > - should not enforce a single file. (but it may be initially) > - but shouldn't be just lots of separate statements either. > > Fragmenting Intent > - however we express Intent, we don't want to require that Intent MUST be > able to be de-composed into its atomic bits with a fixed size limit > --> we must not require that atomic bit MUST fit into a packet. > - some form of fragmenting an Intent file is ok > + could be done through using TCP (or similar) > + could be done by fragmenting Intent into individual parts > > Updating / removing Intent > - Intent doesn't have a mandatory expiration date > - if no longer required / desired, remove or update Intent. > - it's ok to have a *statement* to remove a *statement*. > > Flooded? > - good enough for now to flood. > BUT: as long as we have a more granular way to "upgrade to" later. > > Conflict resolution? > - device needs to deal with conflict and react predictably. > - device may not be able to resolve locally. > - but the conflict may need to be resolved centrally --> needs a feedback loop. > (we don't specify where those feedback loops are going - several posibilities) > > "Translating" Intent > - Does Intent have to be "translated" from a high level policy to something > more lower level before it gets distributed? > - Ex from John: "Platinum customer" - always best service. > But I shouldn't map everything (ex: FTP) into an EF queue. > - might require to translate to an intermediate Intent format. > - this tranlation should probably not happen on the devices. > this translation could/should happen centrally; > - more discussion needed on this point. > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > -- Laurent Ciavaglia Senior Research Manager Bell Labs, Nokia +33 160 402 636 Route de Villejust | 91620 Nozay | France LinkedIn: laurentciavaglia --------------030604090900040604080601 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Dear Michael, all,

Thanks for sharing the summary, it is appreciated to be able to stay connected with on-site discussion ;)

>Re: Conflict resolution?
>- device needs to deal with conflict and react predictably.
>- device may not be able to resolve locally.
>- but the conflict may need to be resolved centrally --> needs a feedback loop.
>  (we don't specify where those feedback loops are going - several possibilities)

This is a perfect introduction for my talk in ANIMA session today:
    16:35 - 16:45 Autonomic Functions Coordination - draft-ciavaglia-anima-coordination
   
Thanks, Laurent.


On 07/04/2016 13:14, EXT Michael Behringer (mbehring) wrote:
Yesterday Joel, John, Toerless, Jeferson, Jason and I met to discuss about Intent, and see where we agree / disagree. Below some notes for remote attendees, to chime in. Obviously, nothing is cast in stone, these are still personal views, just aggregated in a form that we are all more or less happy with. Maybe that helps the discussion.

Michael

--

Intent Discussion 
- some draft consensus between Joel, John, Toerless, Jeferson, Jason, Michael

Naming: 
- High level policy = Intent
- Any messaging to enforce that, signalling of parameters resulting from it, 
  etc may be required but is NOT Intent

Intent one single file? 
- Intent may come from different entry points
- should not enforce a single file. (but it may be initially)
- but shouldn't be just lots of separate statements either. 

Fragmenting Intent
- however we express Intent, we don't want to require that Intent MUST be 
  able to be de-composed into its atomic bits with a fixed size limit
  --> we must not require that atomic bit MUST fit into a packet.
- some form of fragmenting an Intent file is ok
  + could be done through using TCP (or similar)
  + could be done by fragmenting Intent into individual parts

Updating / removing Intent
- Intent doesn't have a mandatory expiration date
- if no longer required / desired, remove or update Intent. 
- it's ok to have a *statement* to remove a *statement*. 

Flooded? 
- good enough for now to flood.
  BUT: as long as we have a more granular way to "upgrade to" later. 

Conflict resolution? 
- device needs to deal with conflict and react predictably. 
- device may not be able to resolve locally. 
- but the conflict may need to be resolved centrally --> needs a feedback loop. 
  (we don't specify where those feedback loops are going - several posibilities)

"Translating" Intent
- Does Intent have to be "translated" from a high level policy to something 
  more lower level before it gets distributed? 
- Ex from John: "Platinum customer" - always best service. 
  But I shouldn't map everything (ex: FTP) into an EF queue. 
- might require to translate to an intermediate Intent format. 
- this tranlation should probably not happen on the devices.
  this translation could/should happen centrally;
- more discussion needed on this point.

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

--

Laurent Ciavaglia

Senior Research Manager

Bell Labs, Nokia

 

+33 160 402 636

Route de Villejust | 91620 Nozay | France

LinkedIn: laurentciavaglia

 

--------------030604090900040604080601-- From nobody Thu Apr 7 09:03:45 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C9512D18F for ; Thu, 7 Apr 2016 09:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 5HaWa5ZVTorT for ; Thu, 7 Apr 2016 09:03:42 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4299612D16D for ; Thu, 7 Apr 2016 09:03:42 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8B6112009E for ; Thu, 7 Apr 2016 12:07:16 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A57D563755 for ; Thu, 7 Apr 2016 12:03:40 -0400 (EDT) From: Michael Richardson To: anima In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Intent Discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 07 Apr 2016 16:03:44 -0000 --=-=-= Content-Type: text/plain Michael Behringer (mbehring) wrote: > Michael Thanks for the notes. > Intent one single file? > - Intent may come from different entry points > - should not enforce a single file. (but it may be initially) > - but shouldn't be just lots of separate statements either. > Fragmenting Intent > - however we express Intent, we don't want to require that Intent MUST be > able to be de-composed into its atomic bits with a fixed size limit --> we must not require that atomic bit MUST fit into a packet. > - some form of fragmenting an Intent file is ok > + could be done through using TCP (or similar) > + could be done by fragmenting Intent into individual parts We are building an ACP that supports our entire suite of IP(v6) protocols. Fragmentation/segmentation, caching are already protocols that we have. Intents are going to be signed objects of some kind. (I favour JOSE, but xmldsig would be fine as well, or even S/MIME if someone has a good argument for that). I don't see any reason we should worry if Intents fit into a packet. So, can we stop? > Updating / removing Intent > - Intent doesn't have a mandatory expiration date Can I amend this to: An Intent doesn't have to have a finite expiration date? Couldn't an Intent apply until "Condition X" is met? > - if no longer required / desired, remove or update Intent. > - it's ok to have a *statement* to remove a *statement*. Yes, I agree strongly. Consider a base Intent that says that the network should move as much traffic as possible. (Imagine that in the future there were peering arrangements at IXs so that we had automatic bidding in the way that the electrical market works in some parts of the world) Imagine an Intent that is issued on Tuesday that says: "Limit committed traffic to an aggregate of less than PIPE X" (Inception Date: Thursday 23:59 Expiry Date: Monday 00:00) The reason to issue this Intent is because of planned maintenance on the weekend which will cause pipes Y and Z to become unstable. The above Intent would amend the original base intent for a period of time, and then it would expire. > Conflict resolution? > - device needs to deal with conflict and react predictably. > - device may not be able to resolve locally. > - but the conflict may need to be resolved centrally --> needs a feedback loop. > (we don't specify where those feedback loops are going - several posibilities) We'll have an ASA for that. Seriously. > "Translating" Intent > - Does Intent have to be "translated" from a high level policy to something > more lower level before it gets distributed? We'll have an ASA for that too. Maybe it requires that a VM be spun up with some vendor specific software that translates intents to CLI commands (I'm familiar with JUNOS Space..); but whatever works. > - Ex from John: "Platinum customer" - always best service. > But I shouldn't map everything (ex: FTP) into an EF queue. > - might require to translate to an intermediate Intent format. > - this tranlation should probably not happen on the devices. > this translation could/should happen centrally; I think that each device may well observe the Intent, and may well ask their oracle if they are compliant. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVwaE2oCLcPvd0N1lAQL+fgf/ZH+tp9rPK4we1b/+h0A/HXK4l2bmv80R 5FW9ScBBdpitJMYOSwW/zKth4u4zarAQw6+6nnd5Vg+eicldS58IxTAAP+4SL1VZ mGQPMXI/VKRHymF0af7uz/kVpnuue4o+9DEgDOyrMJR0G5il/LC5m3et1x2pxHnV r09V7TaP7h9R8XDrdo9FIzJqEk0G4/5PbRZ1DExaKth2BzcrkaeyfPXwRo1B38rr rts2QUGd9r1Ei6y6e623KiuU2VgRtX7xwSTFc4sl2ctHp+qRfzU9kLbWWF18iWTP Sdn3bceLeHedQVdtPyG96pEAkD9yoWRpDs3WupatWO0NgjR6Zzu0wg== =p1AA -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 7 11:06:42 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 742F212D592 for ; Thu, 7 Apr 2016 11:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 7dcugt7hOa9F for ; Thu, 7 Apr 2016 11:06:39 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1B5A12D5CF for ; Thu, 7 Apr 2016 11:06:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4031; q=dns/txt; s=iport; t=1460052399; x=1461261999; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=DOeLzT+LWL9ib0yspNG/uKKhPaST1bh1nNkm5E/Yo3k=; b=bxkAdvZdVR4h5QalN9EuJFv3L3hnyWGUJDhx6Iw8MH8Q7ui391UgH5/r 9T0xRjbwgBGm6PNOqlz3uZERhKGY/8u27x5A0u+k5tmbIT9rY7c+i7fDO O9Tal8YznFqipdhhJNWWI5r3pxr++a+oJOssoESoSBC6kesdnG/nwcaKo o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D9AQBtoAZX/4QNJK1cgzeBUAa6OwENg?= =?us-ascii?q?XOCXYMwAoFFOBQBAQEBAQEBZSeEQQEBAQMBJxNPAgEIFCIQMiUBAQQBEgiIFwj?= =?us-ascii?q?BZQEBAQEBAQQBAQEBAQEahiGES4QahXsFmAQBjgSBbo0nhh+JBAEeAQFCg2dsh?= =?us-ascii?q?zc+fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208";a="258590376" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Apr 2016 18:06:38 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u37I6cJ1005756 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Apr 2016 18:06:38 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 7 Apr 2016 13:06:38 -0500 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.009; Thu, 7 Apr 2016 13:06:37 -0500 From: "Michael Behringer (mbehring)" To: Michael Richardson , anima Thread-Topic: [Anima] Intent Discussion Thread-Index: AdGQvf+xeVbNHCZJTzaTRxDR/JZAHgAUvYcAAAcVKUA= Date: Thu, 7 Apr 2016 18:06:37 +0000 Message-ID: <326510e9e6674e40a82b8b74e21b47ff@XCH-RCD-006.cisco.com> References: <23755.1460045020@obiwan.sandelman.ca> In-Reply-To: <23755.1460045020@obiwan.sandelman.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.87.155] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Intent Discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 07 Apr 2016 18:06:41 -0000 inline... (expressing my views, not the groups, just to be clear) [...] > > Fragmenting Intent > > - however we express Intent, we don't want to require that Intent M= UST > be > > able to be de-composed into its atomic bits with a fixed size limit > --> we must not require that atomic bit MUST fit into a packet. > > - some form of fragmenting an Intent file is ok > > + could be done through using TCP (or similar) > > + could be done by fragmenting Intent into individual parts >=20 > We are building an ACP that supports our entire suite of IP(v6) protocols= . > Fragmentation/segmentation, caching are already protocols that we have. >=20 > Intents are going to be signed objects of some kind. > (I favour JOSE, but xmldsig would be fine as well, or even S/MIME if > someone has a good argument for that). >=20 > I don't see any reason we should worry if Intents fit into a packet. > So, can we stop? I think this is what we're trying to say. It doesn't make sense to try to a= lign Intent with packets. :-)=20 > > Updating / removing Intent > > - Intent doesn't have a mandatory expiration date >=20 > Can I amend this to: An Intent doesn't have to have a finite expiration d= ate? > Couldn't an Intent apply until "Condition X" is met? It *could*.=20 > > - if no longer required / desired, remove or update Intent. > > - it's ok to have a *statement* to remove a *statement*. >=20 > Yes, I agree strongly. >=20 > Consider a base Intent that says that the network should move as much > traffic as possible. (Imagine that in the future there were peering > arrangements at IXs so that we had automatic bidding in the way that the > electrical market works in some parts of the world) >=20 > Imagine an Intent that is issued on Tuesday that says: > "Limit committed traffic to an aggregate of less than PIPE X" > (Inception Date: Thursday 23:59 > Expiry Date: Monday 00:00) >=20 > The reason to issue this Intent is because of planned maintenance on the > weekend which will cause pipes Y and Z to become unstable. >=20 > The above Intent would amend the original base intent for a period of tim= e, > and then it would expire. We could do this.=20 =20 > > Conflict resolution? > > - device needs to deal with conflict and react predictably. > > - device may not be able to resolve locally. > > - but the conflict may need to be resolved centrally --> needs a fe= edback > loop. > > (we don't specify where those feedback loops are going - several > posibilities) >=20 > We'll have an ASA for that. Seriously. I think you mean an "autonomic function" (which consists of ASAs on some/al= l nodes). The point is a single device can't figure it out. So you needs so= me way to "coordinate" - do a feedback loop, etc. Yes, this could be implem= ented in the form of an autonomic function.=20 > > "Translating" Intent > > - Does Intent have to be "translated" from a high level policy to > something > > more lower level before it gets distributed? >=20 > We'll have an ASA for that too. > Maybe it requires that a VM be spun up with some vendor specific software > that translates intents to CLI commands (I'm familiar with JUNOS Space..)= ; > but whatever works. right.=20 =20 > > - Ex from John: "Platinum customer" - always best service. > > But I shouldn't map everything (ex: FTP) into an EF queue. > > - might require to translate to an intermediate Intent format. > > - this tranlation should probably not happen on the devices. > > this translation could/should happen centrally; >=20 > I think that each device may well observe the Intent, and may well ask th= eir > oracle if they are compliant. That's one way to do the above (some coordination).=20 Michael > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 From nobody Thu Apr 7 13:29:08 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2550812D129 for ; Thu, 7 Apr 2016 13:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 fJRvLJoYX0z3 for ; Thu, 7 Apr 2016 13:29:06 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8598B12D1AD for ; Thu, 7 Apr 2016 13:22:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1083; q=dns/txt; s=iport; t=1460060535; x=1461270135; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=x0jYI5uCO3cDD0cjjE6epyc4SI+Vs1LA6UZQPsZ2GhA=; b=biDYlgFepba0OYJz0rMkMgFljRsL3xFU8u8r7aYnDlxcKuILENBiApZc rkJXt1lTp+giF3yzlogIlhKr3vlJkfT4sPhYvWjRvtZwi9gikLSiJSAUd RufSbERqGkJzJn95gAw0a+9sZRWzbPWvk1usz2LHf2EnNmUgjrgdQGWc/ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAgBIwAZX/5RdJa1dgzeBVro9AQ2Bc?= =?us-ascii?q?4YNgUc4FAEBAQEBAQFlJ4REBDo/EgE+QiYBBA4NiB/CBgEBAQEBAQQBAQEBAQE?= =?us-ascii?q?BGYYhjmAFmAQBgSyMWI8VjyMBHgEBQoNniSd+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208";a="258822564" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Apr 2016 20:22:14 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u37KMEgl027626 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Apr 2016 20:22:14 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 7 Apr 2016 15:22:13 -0500 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.009; Thu, 7 Apr 2016 15:22:13 -0500 From: "Michael Behringer (mbehring)" To: "Ciavaglia, Laurent (Nokia - FR)" Thread-Topic: Comment to your presentation on draft-ciavaglia-anima-knowledge-00 Thread-Index: AdGRCV6PO3Rs5YusQfWrC4y7JZz+Gg== Date: Thu, 7 Apr 2016 20:22:13 +0000 Message-ID: <23644a1e52c44a8b900100f1a120a5f6@XCH-RCD-006.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.87.155] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: anima Subject: [Anima] Comment to your presentation on draft-ciavaglia-anima-knowledge-00 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 07 Apr 2016 20:29:08 -0000 Laurent,=20 Since we couldn't finish the discussion online, here my comment on the list= :=20 You won't be surprised to hear that I'm asking also here for the smallest, = simplest possible first step. To get us all on the same page, and understan= d the requirement better.=20 So I was thinking, we actually have a good use case for this: draft-ietf-an= ima-prefix-management could probably do with a small knowledge plane; in it= s simplest case, an operator wants to know the current status of assignment= s across the entire network; before a node requests more address space from= another node, it could ask a knowledge plane where the biggest free pools = are.=20 Disassembling this a bit: questions to the knowledge plane could be:=20 - "which node has the biggest free address pool?" - "what's the average / max / min usage of local pools across the network?" - "how much address space is still available?" (not quite the same as above= , I think) - etc.=20 Would that make a nice use case to understand the knowledge plane better?=20 Michael From nobody Thu Apr 7 13:51:33 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311D112D0AC for ; Thu, 7 Apr 2016 13:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 VMSMCiVwUMvc for ; Thu, 7 Apr 2016 13:51:29 -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 1968612D135 for ; Thu, 7 Apr 2016 13:51:29 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 564A7571E647E; Thu, 7 Apr 2016 20:51:23 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u37KpQqZ029045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Apr 2016 20:51:26 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u37KpQSG022319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Apr 2016 22:51:26 +0200 Received: from [135.224.198.34] (135.239.27.41) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 7 Apr 2016 22:51:26 +0200 To: anima , "Liubing (Leo)" , =?UTF-8?Q?J=c3=a9ferson_Campos_Nobre?= , Michael Behringer From: Laurent Ciavaglia Organization: Bell Labs Message-ID: <5706C848.10607@alcatel-lucent.com> Date: Thu, 7 Apr 2016 22:51:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------050405080204090400090100" X-Originating-IP: [135.239.27.41] Archived-At: Subject: [Anima] Questions during ANIMA II session X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 07 Apr 2016 20:51:32 -0000 --------------050405080204090400090100 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hello, Thanks for your patience re. the issues faced for the remote presentations. I hope you still managed to understand our messages ;) There have been comments on the coordination and knowledge presentations. Michael, JĂ©ferson and Bing: could you repeat your comment on the list? I caught the following: Q. Michael: examples of coordination, what a (minimal) policy engine could look like? start small. Q. Jeferson: implications on data models / measurement/monitoring... ? Q. Bing: use GRASP or other mechanisms. Clarify requirements for GRASP. Thanks, Laurent. --------------050405080204090400090100 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Hello,

Thanks for your patience re. the issues faced for the remote presentations.
I hope you still managed to understand our messages ;)

There have been comments on the coordination and knowledge presentations.
Michael, JĂ©ferson and Bing: could you repeat your comment on the list?
I caught the following:

Q. Michael: examples of coordination, what a (minimal) policy engine could look like? start small.

Q. Jeferson: implications on data models / measurement/monitoring... ?

Q. Bing: use GRASP or other mechanisms. Clarify requirements for GRASP.

Thanks, Laurent. --------------050405080204090400090100-- From nobody Thu Apr 7 13:59:25 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F17512D5D0 for ; Thu, 7 Apr 2016 13:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 Kvu2LS9Ul9QQ for ; Thu, 7 Apr 2016 13:59:22 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 8974912D5BB for ; Thu, 7 Apr 2016 13:59:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4B94A1C00F6 for ; Thu, 7 Apr 2016 13:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1460062761; bh=prcrjmRcsKLI/kMEy5mIe1kSMtjDmLUenup0mIXw/j8=; h=To:From:Subject:Date:From; b=OBYA5v+mTpS64utTNteW1c2tFZHQrUOvhR7iGEdi8DtKwVXl7KI6gtLrHQWGZenV2 jE5Vi6wMX0B7g4+vtd8/xy425z5C0ivB6D/DSRzF3XUJgaGcIfLd2rFqTaU3YIjCGo X0YTC+rMASOWzJ8jFQJVrUrmEVNvtPhT2uB2aCZo= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from dhcp-b496.meeting.ietf.org (dhcp-b496.meeting.ietf.org [31.133.180.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id AB1C69C0087 for ; Thu, 7 Apr 2016 13:59:20 -0700 (PDT) To: Anima WG From: "Joel M. Halpern" Message-ID: <5706CA26.6030203@joelhalpern.com> Date: Thu, 7 Apr 2016 16:59:18 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] GRASP, discovery, and roles X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 07 Apr 2016 20:59:23 -0000 I appear to have missed something in the descriptions. On the one hand, it is very clear that ASAs need to discover certain kinds of special entities. Registrars are one example. Prefix delegators or usage coordinators are others. On the other hand, when I look at the GRASP discovery mechanisms, what I see is text that ASAs discover peer ASAs who support a given objective. So how does this work if what I (as an ASA) need to discover is a resource coordinator. That is not an objective I offer. So how do I extablish communication with the right entity/ Or am I completely misreading the specs? Yours, Joel From nobody Thu Apr 7 14:11:57 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFE712D10C for ; Thu, 7 Apr 2016 14:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 9uuqR_mhnh6a for ; Thu, 7 Apr 2016 14:11:50 -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 8D8B912D665 for ; Thu, 7 Apr 2016 14:11:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLS47293; Thu, 07 Apr 2016 21:11:47 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 7 Apr 2016 22:11:46 +0100 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Fri, 8 Apr 2016 05:11:38 +0800 From: "Liubing (Leo)" To: Laurent Ciavaglia , anima , =?utf-8?B?SsOpZmVyc29uIENhbXBvcyBOb2JyZQ==?= , Michael Behringer Thread-Topic: Questions during ANIMA II session Thread-Index: AQHRkQ9GRToqrTWMZUaywg36mKpr859+/SuA Date: Thu, 7 Apr 2016 21:11:37 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2D64869@nkgeml514-mbx.china.huawei.com> References: <5706C848.10607@alcatel-lucent.com> In-Reply-To: <5706C848.10607@alcatel-lucent.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.196.179] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2D64869nkgeml514mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.5706CD13.0200, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b9c6964fbc875279dda7ae1053788d02 Archived-At: Subject: Re: [Anima] Questions during ANIMA II session X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 07 Apr 2016 21:11:55 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2D64869nkgeml514mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTGF1cmVudCwNCg0KVGhhbmtzIGZvciB0aGUgc3VtbWFyeS4gWW91IGNhcHR1cmVkIG15IHBv aW50Lg0KIEkgdGhpbmsgdGhlIGtub3dsZWRnZSBleGNoYW5nZSBpcyBhIHZhbHVhYmxlIHRvcGlj LiBXaGVuIHdlIHdyb3RlIHRoZSBkaXN0cmlidXRpb24gZHJhZnQsIHdlIGFsc28gZXhwZWN0ZWQg dGhlIEdSQVNQIGNvdWxkIG5vdCBvbmx5IGRpc3RyaWJ1dGUgSW50ZW50LCBidXQgYXMgd2VsbCBh cyBvdGhlciB2YWx1YWJsZSBpbmZvcm1hdGlvbi4gU28gSeKAmW0gaGFwcHkgdG8gc2VlIHlvdSBj YWxsIGl0IG91dC4NCkJ1dCBJIGRvbuKAmXQga25vdyBob3cgc29waGlzdGljYXRlIHRoZSBrbm93 bGVkZ2UgZXhjaGFuZ2Ugd291bGQgYmUsIHNvIGl0IHdpbGwgYmUgZ3JlYXQgaWYgeW91IGNhbiBz b3J0IG91dCB0aGUgc3BlY2lmaWMgcmVxdWlyZW1lbnRzLiBUaGVuIGxldOKAmXMgY2hlY2sgd2hl dGhlciBpdCBjb3VsZCBiZSBjb3ZlcmVkIGJ5IHRoZSBkaXN0cmlidXRpb24gZnVuY3Rpb24gKHBy b2JhYmx5IHdpdGggZXh0ZW5zaW9ucyB0byBjdXJyZW50IGRlc2lnbikuDQoNCkJlc3QgcmVnYXJk cywNCkJpbmcNCg0KRnJvbTogTGF1cmVudCBDaWF2YWdsaWEgW21haWx0bzpsYXVyZW50LmNpYXZh Z2xpYUBub2tpYS5jb21dDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMDcsIDIwMTYgNTo1MSBQTQ0K VG86IGFuaW1hOyBMaXViaW5nIChMZW8pOyBKw6lmZXJzb24gQ2FtcG9zIE5vYnJlOyBNaWNoYWVs IEJlaHJpbmdlcg0KU3ViamVjdDogUXVlc3Rpb25zIGR1cmluZyBBTklNQSBJSSBzZXNzaW9uDQoN CkhlbGxvLA0KDQpUaGFua3MgZm9yIHlvdXIgcGF0aWVuY2UgcmUuIHRoZSBpc3N1ZXMgZmFjZWQg Zm9yIHRoZSByZW1vdGUgcHJlc2VudGF0aW9ucy4NCkkgaG9wZSB5b3Ugc3RpbGwgbWFuYWdlZCB0 byB1bmRlcnN0YW5kIG91ciBtZXNzYWdlcyA7KQ0KDQpUaGVyZSBoYXZlIGJlZW4gY29tbWVudHMg b24gdGhlIGNvb3JkaW5hdGlvbiBhbmQga25vd2xlZGdlIHByZXNlbnRhdGlvbnMuDQpNaWNoYWVs LCBKw6lmZXJzb24gYW5kIEJpbmc6IGNvdWxkIHlvdSByZXBlYXQgeW91ciBjb21tZW50IG9uIHRo ZSBsaXN0Pw0KSSBjYXVnaHQgdGhlIGZvbGxvd2luZzoNCg0KUS4gTWljaGFlbDogZXhhbXBsZXMg b2YgY29vcmRpbmF0aW9uLCB3aGF0IGEgKG1pbmltYWwpIHBvbGljeSBlbmdpbmUgY291bGQgbG9v ayBsaWtlPyBzdGFydCBzbWFsbC4NCg0KUS4gSmVmZXJzb246IGltcGxpY2F0aW9ucyBvbiBkYXRh IG1vZGVscyAvIG1lYXN1cmVtZW50L21vbml0b3JpbmcuLi4gPw0KDQpRLiBCaW5nOiB1c2UgR1JB U1Agb3Igb3RoZXIgbWVjaGFuaXNtcy4gQ2xhcmlmeSByZXF1aXJlbWVudHMgZm9yIEdSQVNQLg0K DQpUaGFua3MsIExhdXJlbnQuDQo= --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2D64869nkgeml514mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzsNCgljb2xvcjojMzMzMzMzO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w cHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdj b2xvcj0id2hpdGUiIGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIExhdXJlbnQs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgdGhlIHN1bW1h cnkuIFlvdSBjYXB0dXJlZCBteSBwb2ludC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7SSB0aGluayB0aGUga25vd2xlZGdlIGV4Y2hhbmdlIGlzIGEg dmFsdWFibGUgdG9waWMuIFdoZW4gd2Ugd3JvdGUgdGhlIGRpc3RyaWJ1dGlvbiBkcmFmdCwgd2Ug YWxzbyBleHBlY3RlZCB0aGUgR1JBU1AgY291bGQgbm90IG9ubHkgZGlzdHJpYnV0ZQ0KIEludGVu dCwgYnV0IGFzIHdlbGwgYXMgb3RoZXIgdmFsdWFibGUgaW5mb3JtYXRpb24uIFNvIEnigJltIGhh cHB5IHRvIHNlZSB5b3UgY2FsbCBpdCBvdXQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkJ1dCBJIGRvbuKAmXQga25vdyBob3cgc29waGlzdGljYXRlIHRoZSBr bm93bGVkZ2UgZXhjaGFuZ2Ugd291bGQgYmUsIHNvIGl0IHdpbGwgYmUgZ3JlYXQgaWYgeW91IGNh biBzb3J0IG91dCB0aGUgc3BlY2lmaWMgcmVxdWlyZW1lbnRzLiBUaGVuIGxldOKAmXMNCiBjaGVj ayB3aGV0aGVyIGl0IGNvdWxkIGJlIGNvdmVyZWQgYnkgdGhlIGRpc3RyaWJ1dGlvbiBmdW5jdGlv biAocHJvYmFibHkgd2l0aCBleHRlbnNpb25zIHRvIGN1cnJlbnQgZGVzaWduKS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gTGF1cmVudCBDaWF2YWdsaWEgW21h aWx0bzpsYXVyZW50LmNpYXZhZ2xpYUBub2tpYS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1 cnNkYXksIEFwcmlsIDA3LCAyMDE2IDU6NTEgUE08YnI+DQo8Yj5Ubzo8L2I+IGFuaW1hOyBMaXVi aW5nIChMZW8pOyBKw6lmZXJzb24gQ2FtcG9zIE5vYnJlOyBNaWNoYWVsIEJlaHJpbmdlcjxicj4N CjxiPlN1YmplY3Q6PC9iPiBRdWVzdGlvbnMgZHVyaW5nIEFOSU1BIElJIHNlc3Npb248bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPkhlbGxvLDxicj4NCjxicj4NClRoYW5rcyBmb3IgeW91ciBwYXRpZW5j ZSByZS4gdGhlIGlzc3VlcyBmYWNlZCBmb3IgdGhlIHJlbW90ZSBwcmVzZW50YXRpb25zLjxicj4N CkkgaG9wZSB5b3Ugc3RpbGwgbWFuYWdlZCB0byB1bmRlcnN0YW5kIG91ciBtZXNzYWdlcyA7KTxi cj4NCjxicj4NClRoZXJlIGhhdmUgYmVlbiBjb21tZW50cyBvbiB0aGUgY29vcmRpbmF0aW9uIGFu ZCBrbm93bGVkZ2UgcHJlc2VudGF0aW9ucy48YnI+DQpNaWNoYWVsLCBKw6lmZXJzb24gYW5kIEJp bmc6IGNvdWxkIHlvdSByZXBlYXQgeW91ciBjb21tZW50IG9uIHRoZSBsaXN0Pzxicj4NCkkgY2F1 Z2h0IHRoZSBmb2xsb3dpbmc6PGJyPg0KPGJyPg0KUS4gTWljaGFlbDogZXhhbXBsZXMgb2YgY29v cmRpbmF0aW9uLCB3aGF0IGEgKG1pbmltYWwpIHBvbGljeSBlbmdpbmUgY291bGQgbG9vayBsaWtl PyBzdGFydCBzbWFsbC48YnI+DQo8YnI+DQpRLiBKZWZlcnNvbjogaW1wbGljYXRpb25zIG9uIGRh dGEgbW9kZWxzIC8gbWVhc3VyZW1lbnQvbW9uaXRvcmluZy4uLiA/PGJyPg0KPGJyPg0KUS4gQmlu ZzogdXNlIEdSQVNQIG9yIG90aGVyIG1lY2hhbmlzbXMuIENsYXJpZnkgcmVxdWlyZW1lbnRzIGZv ciBHUkFTUC48YnI+DQo8YnI+DQpUaGFua3MsIExhdXJlbnQuPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2D64869nkgeml514mbxchi_-- From nobody Thu Apr 7 14:49:55 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B9912D6D6 for ; Thu, 7 Apr 2016 14:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 l-36fDKBgalE for ; Thu, 7 Apr 2016 14:49:52 -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 8141F12D640 for ; Thu, 7 Apr 2016 14:49:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHA07203; Thu, 07 Apr 2016 21:49:43 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 7 Apr 2016 22:48:56 +0100 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Fri, 8 Apr 2016 05:48:48 +0800 From: "Liubing (Leo)" To: "Joel M. Halpern" , Anima WG Thread-Topic: [Anima] GRASP, discovery, and roles Thread-Index: AQHRkRBslXL8tzlD70Ktvlrwb3Tal59/BOHA Date: Thu, 7 Apr 2016 21:48:47 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2D648F6@nkgeml514-mbx.china.huawei.com> References: <5706CA26.6030203@joelhalpern.com> In-Reply-To: <5706CA26.6030203@joelhalpern.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.196.179] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.5706D5F7.0161, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d5a7ea1830c85255e3b4c2dd2fdc18ea Archived-At: Subject: Re: [Anima] GRASP, discovery, and roles X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 07 Apr 2016 21:49:55 -0000 Hi Joel, > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Thursday, April 07, 2016 5:59 PM > To: Anima WG > Subject: [Anima] GRASP, discovery, and roles >=20 > I appear to have missed something in the descriptions. >=20 > On the one hand, it is very clear that ASAs need to discover certain kind= s of > special entities. Registrars are one example. Prefix delegators or usag= e > coordinators are others. >=20 > On the other hand, when I look at the GRASP discovery mechanisms, what I = see > is text that ASAs discover peer ASAs who support a given objective. >=20 > So how does this work if what I (as an ASA) need to discover is a resourc= e > coordinator. That is not an objective I offer. So how do I extablish > communication with the right entity/ [Bing] My understanding: we could discover "resource coordination" as an ob= jective. If some entity is right the "coordinator", then it will response t= o that discovery. GRASP discovery only cares about whether some entities co= uld provide "resource coordination" function, and doesn't care about the en= tity's role. In my mind, "objective" is more regarding to function; and "role" more rega= rding to the device's character. So, they are two different dimensions. But= the "objective" might have a finer-granularity than "Role", which means, o= ne entity of a specific Role, might support multiple objectives. Brian: please shout out if I'm not sync with you:) Best regards, Bing > Or am I completely misreading the specs? >=20 > Yours, > Joel >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Thu Apr 7 14:57:33 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043EB12D10C for ; Thu, 7 Apr 2016 14:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 beBqlPRojJaD for ; Thu, 7 Apr 2016 14:57:26 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 CD37512D6F0 for ; Thu, 7 Apr 2016 14:57:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 99F9F2404D0; Thu, 7 Apr 2016 14:57:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1460066246; bh=9f0EtP13UDfg2GWrDWgoTULkzIP5dtbjVswsJwImYfk=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=ps/l6BBPzr9m3Ud3q0otuQqyzEzGvdCqH+EKXDSV6oxQYemew3rz6aPdWD9K6TRkl pfS31IfVT6g4/boiwfTg3iDkghnnsoA4raQPN+TvhYo6USe44czXk2PBDU7JiVbqPD w4faiJHsC7K1wbpGPaeyX683tLLXisu3z0igggZE= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from dhcp-b496.meeting.ietf.org (dhcp-b496.meeting.ietf.org [31.133.180.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 9A8372402AA; Thu, 7 Apr 2016 14:57:25 -0700 (PDT) To: "Liubing (Leo)" , Anima WG References: <5706CA26.6030203@joelhalpern.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2D648F6@nkgeml514-mbx.china.huawei.com> From: "Joel M. Halpern" Message-ID: <5706D7C3.3060308@joelhalpern.com> Date: Thu, 7 Apr 2016 17:57:23 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C2D648F6@nkgeml514-mbx.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] GRASP, discovery, and roles X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 07 Apr 2016 21:57:32 -0000 Given that I register in order to participate in teh discovery, it seems that I could just as easily end up "discovering" another participant when what I need is the coordinator. Am I mis-reading it? Yours, Joel On 4/7/16 5:48 PM, Liubing (Leo) wrote: > Hi Joel, > >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Joel M. Halpern >> Sent: Thursday, April 07, 2016 5:59 PM >> To: Anima WG >> Subject: [Anima] GRASP, discovery, and roles >> >> I appear to have missed something in the descriptions. >> >> On the one hand, it is very clear that ASAs need to discover certain kinds of >> special entities. Registrars are one example. Prefix delegators or usage >> coordinators are others. >> >> On the other hand, when I look at the GRASP discovery mechanisms, what I see >> is text that ASAs discover peer ASAs who support a given objective. >> >> So how does this work if what I (as an ASA) need to discover is a resource >> coordinator. That is not an objective I offer. So how do I extablish >> communication with the right entity/ > > [Bing] My understanding: we could discover "resource coordination" as an objective. If some entity is right the "coordinator", then it will response to that discovery. GRASP discovery only cares about whether some entities could provide "resource coordination" function, and doesn't care about the entity's role. > > In my mind, "objective" is more regarding to function; and "role" more regarding to the device's character. So, they are two different dimensions. But the "objective" might have a finer-granularity than "Role", which means, one entity of a specific Role, might support multiple objectives. > > Brian: please shout out if I'm not sync with you:) > > Best regards, > Bing > >> Or am I completely misreading the specs? >> >> Yours, >> Joel >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > From nobody Thu Apr 7 15:16:38 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E73D12D0C1 for ; Thu, 7 Apr 2016 15:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 d4V6S658NsO2 for ; Thu, 7 Apr 2016 15:16:34 -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 5CE6D12D0BF for ; Thu, 7 Apr 2016 15:16:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHA08361; Thu, 07 Apr 2016 22:16:31 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 7 Apr 2016 23:16:31 +0100 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Fri, 8 Apr 2016 06:16:26 +0800 From: "Liubing (Leo)" To: "Joel M. Halpern" , Anima WG Thread-Topic: [Anima] GRASP, discovery, and roles Thread-Index: AQHRkRBslXL8tzlD70Ktvlrwb3Tal59/BOHA//+Dz4CAAIb7QA== Date: Thu, 7 Apr 2016 22:16:26 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2D64966@nkgeml514-mbx.china.huawei.com> References: <5706CA26.6030203@joelhalpern.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2D648F6@nkgeml514-mbx.china.huawei.com> <5706D7C3.3060308@joelhalpern.com> In-Reply-To: <5706D7C3.3060308@joelhalpern.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.196.179] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5706DC41.0007, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d5a7ea1830c85255e3b4c2dd2fdc18ea Archived-At: Subject: Re: [Anima] GRASP, discovery, and roles X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 07 Apr 2016 22:16:37 -0000 > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Thursday, April 07, 2016 6:57 PM > To: Liubing (Leo); Anima WG > Cc: Brian E Carpenter > Subject: Re: [Anima] GRASP, discovery, and roles >=20 > Given that I register in order to participate in teh discovery, it seems = that I > could just as easily end up "discovering" another participant when what I= need > is the coordinator. [Bing] In terms of GRASP terminology, what you need is the "coordination fu= nction/service", and the one who response you, implies it is a "coordinator= " or whatever role which could provide identical coordination function/serv= ice as the "coordinator". So, just don't worry about the one who response y= ou is "another" guy who is not qualified to serve you.=20 Did I capture your concern correctly? B.R. Bing > Am I mis-reading it? >=20 > Yours, > Joel >=20 > On 4/7/16 5:48 PM, Liubing (Leo) wrote: > > Hi Joel, > > > >> -----Original Message----- > >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Joel M. > >> Halpern > >> Sent: Thursday, April 07, 2016 5:59 PM > >> To: Anima WG > >> Subject: [Anima] GRASP, discovery, and roles > >> > >> I appear to have missed something in the descriptions. > >> > >> On the one hand, it is very clear that ASAs need to discover certain > >> kinds of special entities. Registrars are one example. Prefix > >> delegators or usage coordinators are others. > >> > >> On the other hand, when I look at the GRASP discovery mechanisms, > >> what I see is text that ASAs discover peer ASAs who support a given > objective. > >> > >> So how does this work if what I (as an ASA) need to discover is a > >> resource coordinator. That is not an objective I offer. So how do I > >> extablish communication with the right entity/ > > > > [Bing] My understanding: we could discover "resource coordination" as a= n > objective. If some entity is right the "coordinator", then it will respon= se to that > discovery. GRASP discovery only cares about whether some entities could > provide "resource coordination" function, and doesn't care about the enti= ty's > role. > > > > In my mind, "objective" is more regarding to function; and "role" more > regarding to the device's character. So, they are two different dimension= s. But > the "objective" might have a finer-granularity than "Role", which means, = one > entity of a specific Role, might support multiple objectives. > > > > Brian: please shout out if I'm not sync with you:) > > > > Best regards, > > Bing > > > >> Or am I completely misreading the specs? > >> > >> Yours, > >> Joel > >> > >> _______________________________________________ > >> Anima mailing list > >> Anima@ietf.org > >> https://www.ietf.org/mailman/listinfo/anima > > From nobody Thu Apr 7 15:25:18 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E4612D732 for ; Thu, 7 Apr 2016 15:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 CwhVPuX6c5En for ; Thu, 7 Apr 2016 15:25:14 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 72DFB12D72D for ; Thu, 7 Apr 2016 15:25:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 3AF63250F6D; Thu, 7 Apr 2016 15:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1460067912; bh=ciV7UqJEezR1nmOfbuNxqoqxQNj4r4C9EEYQ+lqCYBw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Mwr42MPJ90ko05e9sajR1joFNLNeHKH+6m2xypHe9V/MNC3xRCR20mI5Ljs7ajNlA 8JNSSuiJrKLlLkdlMh2o4jcPFqNTp2y79oTT4xZWTqhRb0EDnm78L3mZmVqhiV0x05 h2nJx3jAGFB/MrFeHHM1PjfkQyobf1P6HHph2MpA= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from dhcp-b496.meeting.ietf.org (dhcp-b496.meeting.ietf.org [31.133.180.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 6AA69254956; Thu, 7 Apr 2016 15:25:11 -0700 (PDT) To: "Liubing (Leo)" , Anima WG References: <5706CA26.6030203@joelhalpern.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2D648F6@nkgeml514-mbx.china.huawei.com> <5706D7C3.3060308@joelhalpern.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2D64966@nkgeml514-mbx.china.huawei.com> From: "Joel M. Halpern" Message-ID: <5706DE44.8080407@joelhalpern.com> Date: Thu, 7 Apr 2016 18:25:08 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C2D64966@nkgeml514-mbx.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] GRASP, discovery, and roles X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 07 Apr 2016 22:25:17 -0000 If I could just ignore some responses, and be sure I would get the other responses, that would be a way to solve the problem. But as far as I understand GRASP< that isn't what happens. My discovery might prompt several answers, but along any given branch it stops when it hits any responder, even if they are just another participant. Yours, Joel On 4/7/16 6:16 PM, Liubing (Leo) wrote: >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Thursday, April 07, 2016 6:57 PM >> To: Liubing (Leo); Anima WG >> Cc: Brian E Carpenter >> Subject: Re: [Anima] GRASP, discovery, and roles >> >> Given that I register in order to participate in teh discovery, it seems that I >> could just as easily end up "discovering" another participant when what I need >> is the coordinator. > > [Bing] In terms of GRASP terminology, what you need is the "coordination function/service", and the one who response you, implies it is a "coordinator" or whatever role which could provide identical coordination function/service as the "coordinator". So, just don't worry about the one who response you is "another" guy who is not qualified to serve you. > > Did I capture your concern correctly? > > B.R. > Bing > >> Am I mis-reading it? >> >> Yours, >> Joel >> >> On 4/7/16 5:48 PM, Liubing (Leo) wrote: >>> Hi Joel, >>> >>>> -----Original Message----- >>>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Joel M. >>>> Halpern >>>> Sent: Thursday, April 07, 2016 5:59 PM >>>> To: Anima WG >>>> Subject: [Anima] GRASP, discovery, and roles >>>> >>>> I appear to have missed something in the descriptions. >>>> >>>> On the one hand, it is very clear that ASAs need to discover certain >>>> kinds of special entities. Registrars are one example. Prefix >>>> delegators or usage coordinators are others. >>>> >>>> On the other hand, when I look at the GRASP discovery mechanisms, >>>> what I see is text that ASAs discover peer ASAs who support a given >> objective. >>>> >>>> So how does this work if what I (as an ASA) need to discover is a >>>> resource coordinator. That is not an objective I offer. So how do I >>>> extablish communication with the right entity/ >>> >>> [Bing] My understanding: we could discover "resource coordination" as an >> objective. If some entity is right the "coordinator", then it will response to that >> discovery. GRASP discovery only cares about whether some entities could >> provide "resource coordination" function, and doesn't care about the entity's >> role. >>> >>> In my mind, "objective" is more regarding to function; and "role" more >> regarding to the device's character. So, they are two different dimensions. But >> the "objective" might have a finer-granularity than "Role", which means, one >> entity of a specific Role, might support multiple objectives. >>> >>> Brian: please shout out if I'm not sync with you:) >>> >>> Best regards, >>> Bing >>> >>>> Or am I completely misreading the specs? >>>> >>>> Yours, >>>> Joel >>>> >>>> _______________________________________________ >>>> 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 > From nobody Thu Apr 7 15:38:27 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E2212D718 for ; Thu, 7 Apr 2016 15:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 3JvHs_882lGz for ; Thu, 7 Apr 2016 15:38:23 -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 EC49B12D169 for ; Thu, 7 Apr 2016 15:38:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHA09384; Thu, 07 Apr 2016 22:38:20 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 7 Apr 2016 23:38:19 +0100 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Fri, 8 Apr 2016 06:38:13 +0800 From: "Liubing (Leo)" To: "Joel M. Halpern" , Anima WG Thread-Topic: [Anima] GRASP, discovery, and roles Thread-Index: AQHRkRBslXL8tzlD70Ktvlrwb3Tal59/BOHA//+Dz4CAAIb7QP//gMYAgACHPMA= Date: Thu, 7 Apr 2016 22:38:12 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2D649F4@nkgeml514-mbx.china.huawei.com> References: <5706CA26.6030203@joelhalpern.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2D648F6@nkgeml514-mbx.china.huawei.com> <5706D7C3.3060308@joelhalpern.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2D64966@nkgeml514-mbx.china.huawei.com> <5706DE44.8080407@joelhalpern.com> In-Reply-To: <5706DE44.8080407@joelhalpern.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.196.179] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.5706E15D.0031, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d5a7ea1830c85255e3b4c2dd2fdc18ea Archived-At: Subject: Re: [Anima] GRASP, discovery, and roles X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 07 Apr 2016 22:38:26 -0000 > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Thursday, April 07, 2016 7:25 PM > To: Liubing (Leo); Anima WG > Subject: Re: [Anima] GRASP, discovery, and roles >=20 > If I could just ignore some responses, and be sure I would get the other > responses, that would be a way to solve the problem. But as far as I > understand GRASP< that isn't what happens. My discovery might prompt > several answers, but along any given branch it stops when it hits any res= ponder, > even if they are just another participant. [Bing] This is the "multiple responses" open issue we used to discuss.=20 GRASP will not stop receiving other responses, (actually it just can't), ac= cording to discussion in last ietf, people tended to handle the multiple re= sponses to ASA, who will decide to use which discovered result. I think we'= ll need to clearly specify the behavior in the API document. B.R. Bing >=20 > Yours, > Joel >=20 > On 4/7/16 6:16 PM, Liubing (Leo) wrote: > >> -----Original Message----- > >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > >> Sent: Thursday, April 07, 2016 6:57 PM > >> To: Liubing (Leo); Anima WG > >> Cc: Brian E Carpenter > >> Subject: Re: [Anima] GRASP, discovery, and roles > >> > >> Given that I register in order to participate in teh discovery, it > >> seems that I could just as easily end up "discovering" another > >> participant when what I need is the coordinator. > > > > [Bing] In terms of GRASP terminology, what you need is the "coordinatio= n > function/service", and the one who response you, implies it is a "coordin= ator" > or whatever role which could provide identical coordination function/serv= ice as > the "coordinator". So, just don't worry about the one who response you is > "another" guy who is not qualified to serve you. > > > > Did I capture your concern correctly? > > > > B.R. > > Bing > > > >> Am I mis-reading it? > >> > >> Yours, > >> Joel > >> > >> On 4/7/16 5:48 PM, Liubing (Leo) wrote: > >>> Hi Joel, > >>> > >>>> -----Original Message----- > >>>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Joel M. > >>>> Halpern > >>>> Sent: Thursday, April 07, 2016 5:59 PM > >>>> To: Anima WG > >>>> Subject: [Anima] GRASP, discovery, and roles > >>>> > >>>> I appear to have missed something in the descriptions. > >>>> > >>>> On the one hand, it is very clear that ASAs need to discover > >>>> certain kinds of special entities. Registrars are one example. > >>>> Prefix delegators or usage coordinators are others. > >>>> > >>>> On the other hand, when I look at the GRASP discovery mechanisms, > >>>> what I see is text that ASAs discover peer ASAs who support a given > >> objective. > >>>> > >>>> So how does this work if what I (as an ASA) need to discover is a > >>>> resource coordinator. That is not an objective I offer. So how do > >>>> I extablish communication with the right entity/ > >>> > >>> [Bing] My understanding: we could discover "resource coordination" > >>> as an > >> objective. If some entity is right the "coordinator", then it will > >> response to that discovery. GRASP discovery only cares about whether > >> some entities could provide "resource coordination" function, and > >> doesn't care about the entity's role. > >>> > >>> In my mind, "objective" is more regarding to function; and "role" > >>> more > >> regarding to the device's character. So, they are two different > >> dimensions. But the "objective" might have a finer-granularity than > >> "Role", which means, one entity of a specific Role, might support mult= iple > objectives. > >>> > >>> Brian: please shout out if I'm not sync with you:) > >>> > >>> Best regards, > >>> Bing > >>> > >>>> Or am I completely misreading the specs? > >>>> > >>>> Yours, > >>>> Joel > >>>> > >>>> _______________________________________________ > >>>> 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 > > From nobody Thu Apr 7 15:53:35 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC34212D757; Thu, 7 Apr 2016 15:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 TSnuP-Y0aFko; Thu, 7 Apr 2016 15:53:31 -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 4414012D755; Thu, 7 Apr 2016 15:53:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHA10057; Thu, 07 Apr 2016 22:53:29 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 7 Apr 2016 23:53:25 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Fri, 8 Apr 2016 06:53:21 +0800 From: Sheng Jiang To: "anima@ietf.org" Thread-Topic: Abstract summary of ANIMA in IETF 95 Thread-Index: AdGRIEhATTOYIuH9Q6iXTvCNZAKwQA== Date: Thu, 7 Apr 2016 22:53:20 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927C650D5C@NKGEML515-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.196.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.5706E4E9.00A3, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 128895aa1b45f7110e04f36faf5b73ef Archived-At: Cc: "anima-chairs@ietf.org" Subject: [Anima] Abstract summary of ANIMA in IETF 95 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 07 Apr 2016 22:53:34 -0000 Hi, all, While the WG minutes is still in the way, an abstract summary of ANIMA WG m= eeting has made available at https://trac.tools.ietf.org/area/int/trac/wiki= /IETF95. If you have any suggestions for changes, let us know. And, there are other = Int Area WG summaries there as well. Regards, Sheng= From nobody Thu Apr 7 16:52:38 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0340712D15E for ; Thu, 7 Apr 2016 16:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 4HHimjHDDkkO for ; Thu, 7 Apr 2016 16:52:36 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 3D1E812D764 for ; Thu, 7 Apr 2016 16:52:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id A6A84250F6D; Thu, 7 Apr 2016 16:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1460073155; bh=YaFKBUbUEyiToyN3A7yuwsXqnA1vzqQmCVj7SPwOrA4=; h=Date:Subject:From:To:From; b=PYqJWAVu1j0rp83KLVGb9U6Q3hqTmHSVtH+IQunYoFiSkSjMVE4K/PT3AzCqe/FwV JiSkiUry42/WBS03Mbx7w1QwCJym6X5pS4MR63PcfzMSSJ4iQX00ypa7RdhZkU/44p 8DEujeD19SxlUPnqL2Y30Aros6cU3I/qVHzF4Of8= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [10.178.250.13] (unknown [166.177.249.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 04543240A9B; Thu, 7 Apr 2016 16:52:33 -0700 (PDT) Date: Thu, 07 Apr 2016 20:52:28 -0300 Message-ID: Importance: normal From: "jmh.direct" To: "Liubing (Leo)" , "Joel M. Halpern" , Anima WG MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_3097965272699180" Archived-At: Subject: Re: [Anima] GRASP, discovery, and roles X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 07 Apr 2016 23:52:38 -0000 ----_com.samsung.android.email_3097965272699180 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 QXMgSSB1bmRlcnN0YW5kIGl0LCBpZiBhbiBlbnRpdHkgaGFzIGF0IGxlYXN0IG9uZSBjYWNoZWQg YW5zd2VyLCBpdCB3aWxsIHNlbmQgbWUgdGhhdCBhbmQgc3RvcCBwcm9wYWdhdGluZyBteWJyZXF1 ZWR0LiDCoEFuZCBpdCBjYW4ndCB0ZWxsIGlmIHRoZSBhbnN3ZXIgaXMgaW5zdWZmaWNpZW50Lllv dXJzLEpvZWwKCgpTZW50IHZpYSB0aGUgU2Ftc3VuZyBHYWxheHkgU8KuIDYsIGFuIEFUJlQgNEcg TFRFIHNtYXJ0cGhvbmUtLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tRnJvbTogIkxp dWJpbmcgKExlbykiIDxsZW8ubGl1YmluZ0BodWF3ZWkuY29tPiBEYXRlOiA0LzcvMjAxNiAgNzoz OCBQTSAgKEdNVC0wMzowMCkgVG86ICJKb2VsIE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4u Y29tPiwgQW5pbWEgV0cgPGFuaW1hQGlldGYub3JnPiBTdWJqZWN0OiBSRTogW0FuaW1hXSBHUkFT UCwgZGlzY292ZXJ5LCBhbmQgcm9sZXMgCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KPiBG cm9tOiBKb2VsIE0uIEhhbHBlcm4gW21haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tXQo+IFNlbnQ6 IFRodXJzZGF5LCBBcHJpbCAwNywgMjAxNiA3OjI1IFBNCj4gVG86IExpdWJpbmcgKExlbyk7IEFu aW1hIFdHCj4gU3ViamVjdDogUmU6IFtBbmltYV0gR1JBU1AsIGRpc2NvdmVyeSwgYW5kIHJvbGVz Cj4gCj4gSWYgSSBjb3VsZCBqdXN0IGlnbm9yZSBzb21lIHJlc3BvbnNlcywgYW5kIGJlIHN1cmUg SSB3b3VsZCBnZXQgdGhlIG90aGVyCj4gcmVzcG9uc2VzLCB0aGF0IHdvdWxkIGJlIGEgd2F5IHRv IHNvbHZlIHRoZSBwcm9ibGVtLsKgIEJ1dCBhcyBmYXIgYXMgSQo+IHVuZGVyc3RhbmQgR1JBU1A8 IHRoYXQgaXNuJ3Qgd2hhdCBoYXBwZW5zLsKgIE15IGRpc2NvdmVyeSBtaWdodCBwcm9tcHQKPiBz ZXZlcmFsIGFuc3dlcnMsIGJ1dCBhbG9uZyBhbnkgZ2l2ZW4gYnJhbmNoIGl0IHN0b3BzIHdoZW4g aXQgaGl0cyBhbnkgcmVzcG9uZGVyLAo+IGV2ZW4gaWYgdGhleSBhcmUganVzdCBhbm90aGVyIHBh cnRpY2lwYW50LgoKW0JpbmddIFRoaXMgaXMgdGhlICJtdWx0aXBsZSByZXNwb25zZXMiIG9wZW4g aXNzdWUgd2UgdXNlZCB0byBkaXNjdXNzLiAKR1JBU1Agd2lsbCBub3Qgc3RvcCByZWNlaXZpbmcg b3RoZXIgcmVzcG9uc2VzLCAoYWN0dWFsbHkgaXQganVzdCBjYW4ndCksIGFjY29yZGluZyB0byBk aXNjdXNzaW9uIGluIGxhc3QgaWV0ZiwgcGVvcGxlIHRlbmRlZCB0byBoYW5kbGUgdGhlIG11bHRp cGxlIHJlc3BvbnNlcyB0byBBU0EsIHdobyB3aWxsIGRlY2lkZSB0byB1c2Ugd2hpY2ggZGlzY292 ZXJlZCByZXN1bHQuIEkgdGhpbmsgd2UnbGwgbmVlZCB0byBjbGVhcmx5IHNwZWNpZnkgdGhlIGJl aGF2aW9yIGluIHRoZSBBUEkgZG9jdW1lbnQuCgpCLlIuCkJpbmcKCj4gCj4gWW91cnMsCj4gSm9l bAo+IAo+IE9uIDQvNy8xNiA2OjE2IFBNLCBMaXViaW5nIChMZW8pIHdyb3RlOgo+ID4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4gPj4gRnJvbTogSm9lbCBNLiBIYWxwZXJuIFttYWlsdG86 am1oQGpvZWxoYWxwZXJuLmNvbV0KPiA+PiBTZW50OiBUaHVyc2RheSwgQXByaWwgMDcsIDIwMTYg Njo1NyBQTQo+ID4+IFRvOiBMaXViaW5nIChMZW8pOyBBbmltYSBXRwo+ID4+IENjOiBCcmlhbiBF IENhcnBlbnRlcgo+ID4+IFN1YmplY3Q6IFJlOiBbQW5pbWFdIEdSQVNQLCBkaXNjb3ZlcnksIGFu ZCByb2xlcwo+ID4+Cj4gPj4gR2l2ZW4gdGhhdCBJIHJlZ2lzdGVyIGluIG9yZGVyIHRvIHBhcnRp Y2lwYXRlIGluIHRlaCBkaXNjb3ZlcnksIGl0Cj4gPj4gc2VlbXMgdGhhdCBJIGNvdWxkIGp1c3Qg YXMgZWFzaWx5IGVuZCB1cCAiZGlzY292ZXJpbmciIGFub3RoZXIKPiA+PiBwYXJ0aWNpcGFudCB3 aGVuIHdoYXQgSSBuZWVkIGlzIHRoZSBjb29yZGluYXRvci4KPiA+Cj4gPiBbQmluZ10gSW4gdGVy bXMgb2YgR1JBU1AgdGVybWlub2xvZ3ksIHdoYXQgeW91IG5lZWQgaXMgdGhlICJjb29yZGluYXRp b24KPiBmdW5jdGlvbi9zZXJ2aWNlIiwgYW5kIHRoZSBvbmUgd2hvIHJlc3BvbnNlIHlvdSwgaW1w bGllcyBpdCBpcyBhICJjb29yZGluYXRvciIKPiBvciB3aGF0ZXZlciByb2xlIHdoaWNoIGNvdWxk IHByb3ZpZGUgaWRlbnRpY2FsIGNvb3JkaW5hdGlvbiBmdW5jdGlvbi9zZXJ2aWNlIGFzCj4gdGhl ICJjb29yZGluYXRvciIuIFNvLCBqdXN0IGRvbid0IHdvcnJ5IGFib3V0IHRoZSBvbmUgd2hvIHJl c3BvbnNlIHlvdSBpcwo+ICJhbm90aGVyIiBndXkgd2hvIGlzIG5vdCBxdWFsaWZpZWQgdG8gc2Vy dmUgeW91Lgo+ID4KPiA+IERpZCBJIGNhcHR1cmUgeW91ciBjb25jZXJuIGNvcnJlY3RseT8KPiA+ Cj4gPiBCLlIuCj4gPiBCaW5nCj4gPgo+ID4+IEFtIEkgbWlzLXJlYWRpbmcgaXQ/Cj4gPj4KPiA+ PiBZb3VycywKPiA+PiBKb2VsCj4gPj4KPiA+PiBPbiA0LzcvMTYgNTo0OCBQTSwgTGl1YmluZyAo TA== ----_com.samsung.android.email_3097965272699180 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PkFzIEkgdW5kZXJzdGFuZCBp dCwgaWYgYW4gZW50aXR5IGhhcyBhdCBsZWFzdCBvbmUgY2FjaGVkIGFuc3dlciwgaXQgd2lsbCBz ZW5kIG1lIHRoYXQgYW5kIHN0b3AgcHJvcGFnYXRpbmcgbXlicmVxdWVkdC4gJm5ic3A7QW5kIGl0 IGNhbid0IHRlbGwgaWYgdGhlIGFuc3dlciBpcyBpbnN1ZmZpY2llbnQuPC9kaXY+PGRpdj5Zb3Vy cyw8L2Rpdj48ZGl2PkpvZWw8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2IGlkPSJjb21wb3Nlcl9zaWduYXR1cmUiPjxkaXYgc3R5bGU9ImZvbnQt c2l6ZTo4NSU7Y29sb3I6IzU3NTc1NyI+U2VudCB2aWEgdGhlIFNhbXN1bmcgR2FsYXh5IFPCriA2 LCBhbiBBVCZhbXA7VCA0RyBMVEUgc21hcnRwaG9uZTwvZGl2PjwvZGl2PjxkaXYgc3R5bGU9ImZv bnQtc2l6ZToxMDAlO2NvbG9yOiMwMDAwMDAiPjwhLS0gb3JpZ2luYWxNZXNzYWdlIC0tPjxkaXY+ LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLTwvZGl2PjxkaXY+RnJvbTogIkxpdWJp bmcgKExlbykiICZsdDtsZW8ubGl1YmluZ0BodWF3ZWkuY29tJmd0OyA8L2Rpdj48ZGl2PkRhdGU6 IDQvNy8yMDE2ICA3OjM4IFBNICAoR01ULTAzOjAwKSA8L2Rpdj48ZGl2PlRvOiAiSm9lbCBNLiBI YWxwZXJuIiAmbHQ7am1oQGpvZWxoYWxwZXJuLmNvbSZndDssIEFuaW1hIFdHICZsdDthbmltYUBp ZXRmLm9yZyZndDsgPC9kaXY+PGRpdj5TdWJqZWN0OiBSRTogW0FuaW1hXSBHUkFTUCwgZGlzY292 ZXJ5LCBhbmQgcm9sZXMgPC9kaXY+PGRpdj48YnI+PC9kaXY+PC9kaXY+Jmd0OyAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLTxicj4mZ3Q7IEZyb206IEpvZWwgTS4gSGFscGVybiBbbWFpbHRvOmpt aEBqb2VsaGFscGVybi5jb21dPGJyPiZndDsgU2VudDogVGh1cnNkYXksIEFwcmlsIDA3LCAyMDE2 IDc6MjUgUE08YnI+Jmd0OyBUbzogTGl1YmluZyAoTGVvKTsgQW5pbWEgV0c8YnI+Jmd0OyBTdWJq ZWN0OiBSZTogW0FuaW1hXSBHUkFTUCwgZGlzY292ZXJ5LCBhbmQgcm9sZXM8YnI+Jmd0OyA8YnI+ Jmd0OyBJZiBJIGNvdWxkIGp1c3QgaWdub3JlIHNvbWUgcmVzcG9uc2VzLCBhbmQgYmUgc3VyZSBJ IHdvdWxkIGdldCB0aGUgb3RoZXI8YnI+Jmd0OyByZXNwb25zZXMsIHRoYXQgd291bGQgYmUgYSB3 YXkgdG8gc29sdmUgdGhlIHByb2JsZW0uJm5ic3A7IEJ1dCBhcyBmYXIgYXMgSTxicj4mZ3Q7IHVu ZGVyc3RhbmQgR1JBU1AmbHQ7IHRoYXQgaXNuJ3Qgd2hhdCBoYXBwZW5zLiZuYnNwOyBNeSBkaXNj b3ZlcnkgbWlnaHQgcHJvbXB0PGJyPiZndDsgc2V2ZXJhbCBhbnN3ZXJzLCBidXQgYWxvbmcgYW55 IGdpdmVuIGJyYW5jaCBpdCBzdG9wcyB3aGVuIGl0IGhpdHMgYW55IHJlc3BvbmRlciw8YnI+Jmd0 OyBldmVuIGlmIHRoZXkgYXJlIGp1c3QgYW5vdGhlciBwYXJ0aWNpcGFudC48YnI+PGJyPltCaW5n XSBUaGlzIGlzIHRoZSAibXVsdGlwbGUgcmVzcG9uc2VzIiBvcGVuIGlzc3VlIHdlIHVzZWQgdG8g ZGlzY3Vzcy4gPGJyPkdSQVNQIHdpbGwgbm90IHN0b3AgcmVjZWl2aW5nIG90aGVyIHJlc3BvbnNl cywgKGFjdHVhbGx5IGl0IGp1c3QgY2FuJ3QpLCBhY2NvcmRpbmcgdG8gZGlzY3Vzc2lvbiBpbiBs YXN0IGlldGYsIHBlb3BsZSB0ZW5kZWQgdG8gaGFuZGxlIHRoZSBtdWx0aXBsZSByZXNwb25zZXMg dG8gQVNBLCB3aG8gd2lsbCBkZWNpZGUgdG8gdXNlIHdoaWNoIGRpc2NvdmVyZWQgcmVzdWx0LiBJ IHRoaW5rIHdlJ2xsIG5lZWQgdG8gY2xlYXJseSBzcGVjaWZ5IHRoZSBiZWhhdmlvciBpbiB0aGUg QVBJIGRvY3VtZW50Ljxicj48YnI+Qi5SLjxicj5CaW5nPGJyPjxicj4mZ3Q7IDxicj4mZ3Q7IFlv dXJzLDxicj4mZ3Q7IEpvZWw8YnI+Jmd0OyA8YnI+Jmd0OyBPbiA0LzcvMTYgNjoxNiBQTSwgTGl1 YmluZyAoTGVvKSB3cm90ZTo8YnI+Jmd0OyAmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLTxicj4mZ3Q7ICZndDsmZ3Q7IEZyb206IEpvZWwgTS4gSGFscGVybiBbbWFpbHRvOmptaEBq b2VsaGFscGVybi5jb21dPGJyPiZndDsgJmd0OyZndDsgU2VudDogVGh1cnNkYXksIEFwcmlsIDA3 LCAyMDE2IDY6NTcgUE08YnI+Jmd0OyAmZ3Q7Jmd0OyBUbzogTGl1YmluZyAoTGVvKTsgQW5pbWEg V0c8YnI+Jmd0OyAmZ3Q7Jmd0OyBDYzogQnJpYW4gRSBDYXJwZW50ZXI8YnI+Jmd0OyAmZ3Q7Jmd0 OyBTdWJqZWN0OiBSZTogW0FuaW1hXSBHUkFTUCwgZGlzY292ZXJ5LCBhbmQgcm9sZXM8YnI+Jmd0 OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7IEdpdmVuIHRoYXQgSSByZWdpc3RlciBpbiBvcmRl ciB0byBwYXJ0aWNpcGF0ZSBpbiB0ZWggZGlzY292ZXJ5LCBpdDxicj4mZ3Q7ICZndDsmZ3Q7IHNl ZW1zIHRoYXQgSSBjb3VsZCBqdXN0IGFzIGVhc2lseSBlbmQgdXAgImRpc2NvdmVyaW5nIiBhbm90 aGVyPGJyPiZndDsgJmd0OyZndDsgcGFydGljaXBhbnQgd2hlbiB3aGF0IEkgbmVlZCBpcyB0aGUg Y29vcmRpbmF0b3IuPGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgW0JpbmddIEluIHRlcm1zIG9m IEdSQVNQIHRlcm1pbm9sb2d5LCB3aGF0IHlvdSBuZWVkIGlzIHRoZSAiY29vcmRpbmF0aW9uPGJy PiZndDsgZnVuY3Rpb24vc2VydmljZSIsIGFuZCB0aGUgb25lIHdobyByZXNwb25zZSB5b3UsIGlt cGxpZXMgaXQgaXMgYSAiY29vcmRpbmF0b3IiPGJyPiZndDsgb3Igd2hhdGV2ZXIgcm9sZSB3aGlj aCBjb3VsZCBwcm92aWRlIGlkZW50aWNhbCBjb29yZGluYXRpb24gZnVuY3Rpb24vc2VydmljZSBh czxicj4mZ3Q7IHRoZSAiY29vcmRpbmF0b3IiLiBTbywganVzdCBkb24ndCB3b3JyeSBhYm91dCB0 aGUgb25lIHdobyByZXNwb25zZSB5b3UgaXM8YnI+Jmd0OyAiYW5vdGhlciIgZ3V5IHdobyBpcyBu b3QgcXVhbGlmaWVkIHRvIHNlcnZlIHlvdS48YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyBEaWQg SSBjYXB0dXJlIHlvdXIgY29uY2VybiBjb3JyZWN0bHk/PGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZn dDsgQi5SLjxicj4mZ3Q7ICZndDsgQmluZzxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyBB bSBJIG1pcy1yZWFkaW5nIGl0Pzxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsgWW91 cnMsPGJyPiZndDsgJmd0OyZndDsgSm9lbDxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZn dDsgT24gNC83LzE2IDU6NDggUE0sIExpdWJpbmcgKEw8L2JvZHk+PC9odG1sPg== ----_com.samsung.android.email_3097965272699180-- From nobody Thu Apr 7 18:40:49 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB70612D6DB for ; Thu, 7 Apr 2016 18:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 tb1nr3hVspox for ; Thu, 7 Apr 2016 18:40:45 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A8CF12D6AC for ; Thu, 7 Apr 2016 18:40:45 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id c20so66350344pfc.1 for ; Thu, 07 Apr 2016 18:40:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=x9rz19VQRYXU1HQ8hdkqFezQgeH7WvaHvJTKAtuHjnM=; b=dz/KxfzroupTdfCbDCaQYdt2xvAF99fgYVBvvXT+2aYUWCQ8NrTFpBK6PD4Xch9c4t QwjCp3ErTUG5x/ZiOA3JYAbvP2NmRxtXUj9+q2M774Q0hme3QwvEBI98nrbRZIM/dDR6 SA1smMfzYZ2FmGduloZhs2NIY5T8Sh//SrdXglcVTpXrbKtdhYGpPRY1sthAsaOOCJOj 5kVu2Ya20CIzDs+1yhqIB/x4Vowqkoxym2FUmUodKphiEKSqmp5yiDIKEG5R9IvrqoPe I2wVcZEYXMRMyNM8ZbdPkjuwtdjNErU9WqUVAWQza1CAnZT+kCd/duAFUc26uxvixqw/ 9b/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=x9rz19VQRYXU1HQ8hdkqFezQgeH7WvaHvJTKAtuHjnM=; b=PNI+PHFl8tg6C0gqtqT3EnMY8morXavc1Ct5G6Ci9nj50pBKpW8vnbd0NuurnQKohg +wxNpZro5q2eEh62pRirEF5bRn3KRk19/A7q5ms7jQ84Sgcp3Brf5Mp3b7SNSgtOB6z2 pzO4q45MI9RWDO8yamXKedVc2g/IMD4UplBcow3++c21KmfRWC2ux4K0+7jJcZBTfqSe gsAqtNPoF2rKMsbsnVJHxIQN7YrmgiZdUoSirUI9eYhwWxzONvRMJk+b+0EW2vIKjmbJ B25eJniObyhFgMsuHbJIhkhp3E/qs7if9GF/lXJV4P9HghhBoiodGe9DMUyjgeDRpYpZ QFsA== X-Gm-Message-State: AD7BkJJCEmahYbflusXH0XenSIiw8SrWtxjspm956xd5HIiJngQxZPWrIByoNhc3RKwJuw== X-Received: by 10.98.42.211 with SMTP id q202mr8845040pfq.13.1460079644733; Thu, 07 Apr 2016 18:40:44 -0700 (PDT) Received: from ?IPv6:2406:e007:78d0:1:28cc:dc4c:9703:6781? ([2406:e007:78d0:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id v74sm14829220pfa.7.2016.04.07.18.40.41 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2016 18:40:43 -0700 (PDT) To: "jmh.direct" , "Liubing (Leo)" , "Joel M. Halpern" , Anima WG References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <57070C20.9070408@gmail.com> Date: Fri, 8 Apr 2016 13:40:48 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] GRASP, discovery, and roles X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 08 Apr 2016 01:40:48 -0000 On 08/04/2016 11:52, jmh.direct wrote: > As I understand it, if an entity has at least one cached answer, it wil= l send me that and stop propagating mybrequedt. Actually I don't think that's how I coded it but that hardly matters; we = can review the spec to be unambiguous on that point. But there's another point here which may need to be made a formal require= ment with some better terminology. You can discover an objective without supporting it yourself. For example= , we want exactly one node to support the AN_Registrar objective but any ot= her node may need to discover it. That was kind of intuitive when coding my prototype but we need to make it explicit. Brian > And it can't tell if the answer is insufficient.Yours,Joel >=20 >=20 > Sent via the Samsung Galaxy S=C2=AE 6, an AT&T 4G LTE smartphone-------= - Original message --------From: "Liubing (Leo)" = Date: 4/7/2016 7:38 PM (GMT-03:00) To: "Joel M. Halpern" , Anima WG Subject: RE: [Anima] GRASP, discovery= , and roles=20 >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Thursday, April 07, 2016 7:25 PM >> To: Liubing (Leo); Anima WG >> Subject: Re: [Anima] GRASP, discovery, and roles >> >> If I could just ignore some responses, and be sure I would get the oth= er >> responses, that would be a way to solve the problem. But as far as I >> understand GRASP< that isn't what happens. My discovery might prompt >> several answers, but along any given branch it stops when it hits any = responder, >> even if they are just another participant. >=20 > [Bing] This is the "multiple responses" open issue we used to discuss. = > GRASP will not stop receiving other responses, (actually it just can't)= , according to discussion in last ietf, people tended to handle the multi= ple responses to ASA, who will decide to use which discovered result. I t= hink we'll need to clearly specify the behavior in the API document. >=20 > B.R. > Bing >=20 >> >> Yours, >> Joel >> >> On 4/7/16 6:16 PM, Liubing (Leo) wrote: >>>> -----Original Message----- >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>> Sent: Thursday, April 07, 2016 6:57 PM >>>> To: Liubing (Leo); Anima WG >>>> Cc: Brian E Carpenter >>>> Subject: Re: [Anima] GRASP, discovery, and roles >>>> >>>> Given that I register in order to participate in teh discovery, it >>>> seems that I could just as easily end up "discovering" another >>>> participant when what I need is the coordinator. >>> >>> [Bing] In terms of GRASP terminology, what you need is the "coordinat= ion >> function/service", and the one who response you, implies it is a "coor= dinator" >> or whatever role which could provide identical coordination function/s= ervice as >> the "coordinator". So, just don't worry about the one who response you= is >> "another" guy who is not qualified to serve you. >>> >>> Did I capture your concern correctly? >>> >>> B.R. >>> Bing >>> >>>> Am I mis-reading it? >>>> >>>> Yours, >>>> Joel >>>> >>>> On 4/7/16 5:48 PM, Liubing (L >>>> >>>> >>>> _______________________________________________ >>>> Anima mailing list >>>> Anima@ietf.org >>>> https://www.ietf.org/mailman/listinfo/anima From nobody Fri Apr 8 01:28:41 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C434412D571 for ; Fri, 8 Apr 2016 01:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Xn5OKS_KrUGE for ; Fri, 8 Apr 2016 01:28:36 -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 77AD912D0B3 for ; Fri, 8 Apr 2016 01:28:36 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id D69FEDE81214E; Fri, 8 Apr 2016 08:28:32 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u388SYeg008336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Apr 2016 08:28:34 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 u388SVOF026049 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Apr 2016 10:28:33 +0200 Received: from [135.224.218.199] (135.239.27.41) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 8 Apr 2016 10:28:31 +0200 To: EXT Brian E Carpenter , "jmh.direct" , "Liubing (Leo)" , "Joel M. Halpern" , Anima WG References: <57070C20.9070408@gmail.com> From: Laurent Ciavaglia Organization: Bell Labs Message-ID: <57076BAE.2070807@alcatel-lucent.com> Date: Fri, 8 Apr 2016 10:28:30 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <57070C20.9070408@gmail.com> Content-Type: multipart/alternative; boundary="------------010006060101080101010609" X-Originating-IP: [135.239.27.41] Archived-At: Subject: Re: [Anima] GRASP, discovery, and roles X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 08 Apr 2016 08:28:40 -0000 --------------010006060101080101010609 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hello, I think it should be explicit in the specification of the ASA life-cycle what it does when it boots (and in other phases as well): e.g. discover / register to (entities playing) special roles such as registrar, coordination, intent, knowledge index... This set of "roles" and life-cycle must be fixed and specified by the standard, not left open to ASA developers' creativity because these are special roles/objectives that must be supported / understood by all ASAs / or ANodes (proxy) agents. What seems not fully defined yet is precisely a complete ASA life-cycle (cf discussion and drafts on the topic) and the minimal set of roles to deploy and have an autonomic networks ready for operation / operating. Shall we upgrade the reference model document section on theory of operations with these aspects or should it be another doc? FYI, draft-peloso-anima-autonomic-function attempts to describe such a life-cycle. Best regards, Laurent. On 08/04/2016 03:40, EXT Brian E Carpenter wrote: > On 08/04/2016 11:52, jmh.direct wrote: >> As I understand it, if an entity has at least one cached answer, it will send me that and stop propagating mybrequedt. > Actually I don't think that's how I coded it but that hardly matters; we can > review the spec to be unambiguous on that point. > > But there's another point here which may need to be made a formal requirement > with some better terminology. > > You can discover an objective without supporting it yourself. For example, > we want exactly one node to support the AN_Registrar objective but any other > node may need to discover it. That was kind of intuitive when coding my > prototype but we need to make it explicit. > > Brian > >> And it can't tell if the answer is insufficient.Yours,Joel >> >> >> Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone-------- Original message --------From: "Liubing (Leo)" Date: 4/7/2016 7:38 PM (GMT-03:00) To: "Joel M. Halpern" , Anima WG Subject: RE: [Anima] GRASP, discovery, and roles >>> -----Original Message----- >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>> Sent: Thursday, April 07, 2016 7:25 PM >>> To: Liubing (Leo); Anima WG >>> Subject: Re: [Anima] GRASP, discovery, and roles >>> >>> If I could just ignore some responses, and be sure I would get the other >>> responses, that would be a way to solve the problem. But as far as I >>> understand GRASP< that isn't what happens. My discovery might prompt >>> several answers, but along any given branch it stops when it hits any responder, >>> even if they are just another participant. >> [Bing] This is the "multiple responses" open issue we used to discuss. >> GRASP will not stop receiving other responses, (actually it just can't), according to discussion in last ietf, people tended to handle the multiple responses to ASA, who will decide to use which discovered result. I think we'll need to clearly specify the behavior in the API document. >> >> B.R. >> Bing >> >>> Yours, >>> Joel >>> >>> On 4/7/16 6:16 PM, Liubing (Leo) wrote: >>>>> -----Original Message----- >>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>>> Sent: Thursday, April 07, 2016 6:57 PM >>>>> To: Liubing (Leo); Anima WG >>>>> Cc: Brian E Carpenter >>>>> Subject: Re: [Anima] GRASP, discovery, and roles >>>>> >>>>> Given that I register in order to participate in teh discovery, it >>>>> seems that I could just as easily end up "discovering" another >>>>> participant when what I need is the coordinator. >>>> [Bing] In terms of GRASP terminology, what you need is the "coordination >>> function/service", and the one who response you, implies it is a "coordinator" >>> or whatever role which could provide identical coordination function/service as >>> the "coordinator". So, just don't worry about the one who response you is >>> "another" guy who is not qualified to serve you. >>>> Did I capture your concern correctly? >>>> >>>> B.R. >>>> Bing >>>> >>>>> Am I mis-reading it? >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 4/7/16 5:48 PM, Liubing (L >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 -- Laurent Ciavaglia Senior Research Manager Bell Labs, Nokia +33 160 402 636 Route de Villejust | 91620 Nozay | France LinkedIn: laurentciavaglia --------------010006060101080101010609 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Hello,

I think it should be explicit in the specification of the ASA life-cycle what it does when it boots (and in other phases as well):
    e.g. discover / register to (entities playing) special roles such as registrar, coordination, intent, knowledge index...

This set of "roles" and life-cycle must be fixed and specified by the standard, not left open to ASA developers' creativity because these are special roles/objectives that must be supported / understood by all ASAs / or ANodes (proxy) agents.

What seems not fully defined yet is precisely a complete ASA life-cycle (cf discussion and drafts on the topic) and the minimal set of roles to deploy and have an autonomic networks ready for operation / operating.

Shall we upgrade the reference model document section on theory of operations with these aspects or should it be another doc?

FYI, draft-peloso-anima-autonomic-function attempts to describe such a life-cycle.

Best regards, Laurent.

On 08/04/2016 03:40, EXT Brian E Carpenter wrote:
On 08/04/2016 11:52, jmh.direct wrote:

As I understand it, if an entity has at least one cached answer, it will send me that and stop propagating mybrequedt.

Actually I don't think that's how I coded it but that hardly matters; we can
review the spec to be unambiguous on that point.

But there's another point here which may need to be made a formal requirement
with some better terminology.

You can discover an objective without supporting it yourself. For example,
we want exactly one node to support the AN_Registrar objective but any other
node may need to discover it. That was kind of intuitive when coding my
prototype but we need to make it explicit.

    Brian


And it can't tell if the answer is insufficient.Yours,Joel


Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone-------- Original message --------From: "Liubing (Leo)" <leo.liubing@huawei.com> Date: 4/7/2016  7:38 PM  (GMT-03:00) To: "Joel M. Halpern" <jmh@joelhalpern.com>, Anima WG <anima@ietf.org> Subject: RE: [Anima] GRASP, discovery, and roles 

-----Original Message-----
From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
Sent: Thursday, April 07, 2016 7:25 PM
To: Liubing (Leo); Anima WG
Subject: Re: [Anima] GRASP, discovery, and roles

If I could just ignore some responses, and be sure I would get the other
responses, that would be a way to solve the problem.  But as far as I
understand GRASP< that isn't what happens.  My discovery might prompt
several answers, but along any given branch it stops when it hits any responder,
even if they are just another participant.

[Bing] This is the "multiple responses" open issue we used to discuss. 
GRASP will not stop receiving other responses, (actually it just can't), according to discussion in last ietf, people tended to handle the multiple responses to ASA, who will decide to use which discovered result. I think we'll need to clearly specify the behavior in the API document.

B.R.
Bing


Yours,
Joel

On 4/7/16 6:16 PM, Liubing (Leo) wrote:

-----Original Message-----
From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
Sent: Thursday, April 07, 2016 6:57 PM
To: Liubing (Leo); Anima WG
Cc: Brian E Carpenter
Subject: Re: [Anima] GRASP, discovery, and roles

Given that I register in order to participate in teh discovery, it
seems that I could just as easily end up "discovering" another
participant when what I need is the coordinator.

[Bing] In terms of GRASP terminology, what you need is the "coordination

function/service", and the one who response you, implies it is a "coordinator"
or whatever role which could provide identical coordination function/service as
the "coordinator". So, just don't worry about the one who response you is
"another" guy who is not qualified to serve you.

Did I capture your concern correctly?

B.R.
Bing


Am I mis-reading it?

Yours,
Joel

On 4/7/16 5:48 PM, Liubing (L


_______________________________________________
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

--

Laurent Ciavaglia

Senior Research Manager

Bell Labs, Nokia

 

+33 160 402 636

Route de Villejust | 91620 Nozay | France

LinkedIn: laurentciavaglia

 

--------------010006060101080101010609-- From nobody Fri Apr 8 04:06:52 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575CC12D877 for ; Fri, 8 Apr 2016 04:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 FfBPU80rqc2n for ; Fri, 8 Apr 2016 04:06:49 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFAEB12D87D for ; Fri, 8 Apr 2016 04:06:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21018; q=dns/txt; s=iport; t=1460113597; x=1461323197; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ZcPusN4DgLTiismQA/6mW+sqdL/He26TIQSP4uYjOik=; b=gzb8o+uYroPKCV+4rO7AS0VyCuyKpztkAcbzQtQSEen7lIGTRxlrp63K DgcfL1yZewKYA/aY7M9Y1Hz89AYH6siu66wKJRijqe19W0MSdHjJodGgG dZ5Y37IjewUW0Sw79BRHmzRp1hLnOoSLg0cz8OAaalR+p1UolMSMeN3e4 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AmBQD2jwdX/5hdJa1cgmtMU30GuDCCH?= =?us-ascii?q?YFzhg0CHIEaORMBAQEBAQEBZSeEQQEBAQQjClwCAQgRBAEBKAMCAgIwFAkIAgQ?= =?us-ascii?q?BEgiIH64ikgMBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhiGES4R1gkqCVgWYBAGOB?= =?us-ascii?q?I8UjyQBIgI+g2dsiDt+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208,217";a="258180014" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Apr 2016 11:06:36 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u38B6asa019923 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Apr 2016 11:06:36 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 8 Apr 2016 06:06:35 -0500 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.009; Fri, 8 Apr 2016 06:06:35 -0500 From: "Michael Behringer (mbehring)" To: Laurent Ciavaglia , anima , "Liubing (Leo)" , =?utf-8?B?SsOpZmVyc29uIENhbXBvcyBOb2JyZQ==?= Thread-Topic: Questions during ANIMA II session Thread-Index: AQHRkQ9CvLuhB7fGe0a9eYVwimAI059/5+HQ Date: Fri, 8 Apr 2016 11:06:35 +0000 Message-ID: <08d561938cba4acbac5b35a3b8769cc6@XCH-RCD-006.cisco.com> References: <5706C848.10607@alcatel-lucent.com> In-Reply-To: <5706C848.10607@alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.112.72] Content-Type: multipart/alternative; boundary="_000_08d561938cba4acbac5b35a3b8769cc6XCHRCD006ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Questions during ANIMA II session X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 08 Apr 2016 11:06:51 -0000 --_000_08d561938cba4acbac5b35a3b8769cc6XCHRCD006ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTGF1cmVudCwNCg0KWWVzLCBpbmRlZWQsIHRoYXQgd2FzIG15IHF1ZXN0aW9uLiBJIHVuZGVy c3RhbmQgdGhlIHRvcGljIGNvbmNlcHR1YWxseSwgaXTigJlzIGltcG9ydGFuY2UgYW5kIGFsbCwg YnV0IHdvdWxkIGxpa2UgdG8gc2VlIGhvdyBpdCBhY3R1YWxseSB3b3Jrcy4gV2hhdCB0aGUgaW50 ZXJmYWNlcyBhcmUuIEFuZCBhIHNpbXBsZSBleGFtcGxlLg0KDQpIZXJlIGlzIHdoZXJlIEnigJlt IGhhdmluZyBhIGhhcmQgdGltZTogSSBndWVzcyB0aGUgQVNBcyBuZWVkIHRvIGJlIGF3YXJlIG9m IHRoZSBjb29yZGluYXRpb24gZnVuY3Rpb24sIHJpZ2h0PyBNZWFucywgd2hlbiBJIHdyaXRlIGFu IEFTQSBJIG5lZWQgdG8gZXhwZWN0IG1lc3NhZ2VzIGZyb20gYSBjb29yZGluYXRpb24gZnVuY3Rp b24uDQoNClRoZW4gdGhlcmUgaXMgdGhlIGhvb2sgdG8gdGhlIGtub3dsZWRnZSBwbGFuZTogVGhl IGNvb3JkaW5hdGlvbiBmdW5jdGlvbiBtdXN0IGtub3cgaW4gdGhlIGZpcnN0IHBsYWNlIHdoaWNo IEFTQSBpcyBtYW5pcHVsYXRpbmcgd2hpY2ggdmFsdWVzLCByaWdodD8NCg0KQXQgdGhlIG1vbWVu dCBJ4oCZbSBpbWFnaW5pbmcgdGhpcyBwaWN0dXJlOg0KDQotICAgICAgICAgIGF0IGJvb3R1cCwg QVNBIG5lZWRzIHRvIOKAnHJlZ2lzdGVy4oCdIHNvbWV3aGVyZSAoaG9vayB0byBrbm93bGVkZ2Ug cGxhbmUgYXMgSSBzZWUgaXQpLCBhbmQgbGlzdCB0aGUgcGFyYW1ldGVycyBpdOKAmXMgbWFuaXB1 bGF0aW5nLiBTdWNoIHRoYXQgdGhlIGNvb3JkaW5hdGlvbiBmdW5jdGlvbiBnZXRzIHRvIGtub3cg d2hvIG1hbmlwdWxhdGVzIHdoYXQgb24gd2hpY2ggZGV2aWNlLg0KDQotICAgICAgICAgIFRoZSBj b29yZGluYXRpb24gZnVuY3Rpb24gZXNzZW50aWFsbHkgbW9uaXRvcnMgd2hldGhlciBhbnkgdHdv IChvciBtb3JlKSBBU0FzIGFyZSB3b3JraW5nIG9uIHRoZSBzYW1lIHBhcmFtZXRlcnMuIChBbHRo b3VnaCBJ4oCZbSBzdXJlIHdl4oCZbGwgYWxzbyBoYXZlIGNhc2VzIHdoZXJlIGNvbmZsaWN0cyBh cmlzZSBldmVuIGlmIHRoZSBBU0FzIG1hbmlwdWxhdGUgZGlzdGluY3QgcGFyYW1ldGVycykuDQoN Ci0gICAgICAgICAgSW4gc3VjaCBjYXNlcywgdGhlIGZ1bmN0aW9uIG1vbml0b3JzIHRob3NlIHBh cmFtZXRlcnM7IGlmIGl0IGRldGVjdHMgb3N6aWxsYXRpb24sIGZsYXBwaW5nLCBleHRyZW1lIHZh bHVlcywgZXRjLCBpdCB0ZWxscyBvbmUgQVNBIHRvIGJhY2sgb2ZmIGZvciB0aW1lIHguIE9yIGdp dmVzIGl0IGNvbnN0cmFpbnRzLCBsaWtlIOKAnG5vIGhpZ2hlciB0aGFuIHjigJ0sIG9yIOKAnGRv buKAmXQgbW9kaWZ5IGZvciB4IHNlY+KAnS4gT3IuLi4NCg0KU2VlIHdoYXQgSSBtZWFuLCB0aGF0 IGNvdWxkIGJlY29tZSBhIHByZXR0eSBjb21wbGV4IGJlYXN0LiBOZWVkIHRvIHVuZGVyc3RhbmQg Zmlyc3QgdGhlIGJhc2ljIGludGVyZmFjZXMuDQoNCk1pY2hhZWwNCg0KDQpGcm9tOiBMYXVyZW50 IENpYXZhZ2xpYSBbbWFpbHRvOmxhdXJlbnQuY2lhdmFnbGlhQG5va2lhLmNvbV0NClNlbnQ6IDA3 IEFwcmlsIDIwMTYgMTc6NTENClRvOiBhbmltYSA8YW5pbWFAaWV0Zi5vcmc+OyBMaXViaW5nIChM ZW8pIDxsZW8ubGl1YmluZ0BodWF3ZWkuY29tPjsgSsOpZmVyc29uIENhbXBvcyBOb2JyZSA8amNu b2JyZUBpbmYudWZyZ3MuYnI+OyBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpIDxtYmVocmlu Z0BjaXNjby5jb20+DQpTdWJqZWN0OiBRdWVzdGlvbnMgZHVyaW5nIEFOSU1BIElJIHNlc3Npb24N Cg0KSGVsbG8sDQoNClRoYW5rcyBmb3IgeW91ciBwYXRpZW5jZSByZS4gdGhlIGlzc3VlcyBmYWNl ZCBmb3IgdGhlIHJlbW90ZSBwcmVzZW50YXRpb25zLg0KSSBob3BlIHlvdSBzdGlsbCBtYW5hZ2Vk IHRvIHVuZGVyc3RhbmQgb3VyIG1lc3NhZ2VzIDspDQoNClRoZXJlIGhhdmUgYmVlbiBjb21tZW50 cyBvbiB0aGUgY29vcmRpbmF0aW9uIGFuZCBrbm93bGVkZ2UgcHJlc2VudGF0aW9ucy4NCk1pY2hh ZWwsIErDqWZlcnNvbiBhbmQgQmluZzogY291bGQgeW91IHJlcGVhdCB5b3VyIGNvbW1lbnQgb24g dGhlIGxpc3Q/DQpJIGNhdWdodCB0aGUgZm9sbG93aW5nOg0KDQpRLiBNaWNoYWVsOiBleGFtcGxl cyBvZiBjb29yZGluYXRpb24sIHdoYXQgYSAobWluaW1hbCkgcG9saWN5IGVuZ2luZSBjb3VsZCBs b29rIGxpa2U/IHN0YXJ0IHNtYWxsLg0KDQpRLiBKZWZlcnNvbjogaW1wbGljYXRpb25zIG9uIGRh dGEgbW9kZWxzIC8gbWVhc3VyZW1lbnQvbW9uaXRvcmluZy4uLiA/DQoNClEuIEJpbmc6IHVzZSBH UkFTUCBvciBvdGhlciBtZWNoYW5pc21zLiBDbGFyaWZ5IHJlcXVpcmVtZW50cyBmb3IgR1JBU1Au DQoNClRoYW5rcywgTGF1cmVudC4NCg== --_000_08d561938cba4acbac5b35a3b8769cc6XCHRCD006ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmOw0KCWNvbG9yOiMzMzMzMzM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwg ZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10 b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2lu LWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOiMzMzMzMzM7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNv LWxpc3QtaWQ6MTA3Nzg5NzY2MjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6LTE5Mjc3Nzg5NDYgMTg2Mzg2MjQ5MiAxMzQ4MDc1NTUgMTM0ODA3NTU3IDEz NDgwNzU1MyAxMzQ4MDc1NTUgMTM0ODA3NTU3IDEzNDgwNzU1MyAxMzQ4MDc1NTUgMTM0ODA3NTU3 O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFy ZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyIsc2VyaWY7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iixz ZXJpZjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFy Z2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9 IkVOLUdCIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMx ZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBMYXVyZW50LA0KPG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0 OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNl PSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+WWVzLCBpbmRlZWQsIHRoYXQgd2FzIG15IHF1ZXN0aW9uLiBJIHVuZGVyc3Rh bmQgdGhlIHRvcGljIGNvbmNlcHR1YWxseSwgaXTigJlzIGltcG9ydGFuY2UNCiBhbmQgYWxsLCBi dXQgd291bGQgbGlrZSB0byBzZWUgaG93IGl0IGFjdHVhbGx5IHdvcmtzLiBXaGF0IHRoZSBpbnRl cmZhY2VzIGFyZS4gQW5kIGEgc2ltcGxlIGV4YW1wbGUuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5 N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9 IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5IZXJlIGlzIHdoZXJlIEnigJltIGhhdmluZyBhIGhhcmQgdGltZTogSSBndWVz cyB0aGUgQVNBcyBuZWVkIHRvIGJlIGF3YXJlIG9mIHRoZSBjb29yZGluYXRpb24NCiBmdW5jdGlv biwgcmlnaHQ/IE1lYW5zLCB3aGVuIEkgd3JpdGUgYW4gQVNBIEkgbmVlZCB0byBleHBlY3QgbWVz c2FnZXMgZnJvbSBhIGNvb3JkaW5hdGlvbiBmdW5jdGlvbi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFm NDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFj ZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPlRoZW4gdGhlcmUgaXMgdGhlIGhvb2sgdG8gdGhlIGtub3dsZWRnZSBwbGFu ZTogVGhlIGNvb3JkaW5hdGlvbiBmdW5jdGlvbiBtdXN0IGtub3cgaW4NCiB0aGUgZmlyc3QgcGxh Y2Ugd2hpY2ggQVNBIGlzIG1hbmlwdWxhdGluZyB3aGljaCB2YWx1ZXMsIHJpZ2h0PyA8bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0i MiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9 IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5BdCB0aGUgbW9tZW50IEnigJltIGltYWdpbmluZyB0 aGlzIHBpY3R1cmU6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxl dmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFm NDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08Zm9u dCBzaXplPSIxIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250OjcuMHB0 ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjwvc3Bhbj48L3NwYW4+ PC9mb250PjwhW2VuZGlmXT48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2Fs aWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPmF0IGJvb3R1cCwgQVNBIG5lZWRzIHRvIOKAnHJlZ2lzdGVy4oCdIHNvbWV3aGVyZSAo aG9vayB0byBrbm93bGVkZ2UNCiBwbGFuZSBhcyBJIHNlZSBpdCksIGFuZCBsaXN0IHRoZSBwYXJh bWV0ZXJzIGl04oCZcyBtYW5pcHVsYXRpbmcuIFN1Y2ggdGhhdCB0aGUgY29vcmRpbmF0aW9uIGZ1 bmN0aW9uIGdldHMgdG8ga25vdyB3aG8gbWFuaXB1bGF0ZXMgd2hhdCBvbiB3aGljaCBkZXZpY2Uu DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48 IVtpZiAhc3VwcG9ydExpc3RzXT48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0i Q2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08Zm9udCBzaXplPSIxIiBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjwvc3Bhbj48L3NwYW4+PC9mb250PjwhW2Vu ZGlmXT48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoZSBj b29yZGluYXRpb24gZnVuY3Rpb24gZXNzZW50aWFsbHkgbW9uaXRvcnMgd2hldGhlciBhbnkgdHdv DQogKG9yIG1vcmUpIEFTQXMgYXJlIHdvcmtpbmcgb24gdGhlIHNhbWUgcGFyYW1ldGVycy4gKEFs dGhvdWdoIEnigJltIHN1cmUgd2XigJlsbCBhbHNvIGhhdmUgY2FzZXMgd2hlcmUgY29uZmxpY3Rz IGFyaXNlIGV2ZW4gaWYgdGhlIEFTQXMgbWFuaXB1bGF0ZSBkaXN0aW5jdCBwYXJhbWV0ZXJzKS4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwh W2lmICFzdXBwb3J0TGlzdHNdPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJD YWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxmb250IHNpemU9IjEiIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PCFbZW5k aWZdPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SW4gc3Vj aCBjYXNlcywgdGhlIGZ1bmN0aW9uIG1vbml0b3JzIHRob3NlIHBhcmFtZXRlcnM7IGlmIGl0DQog ZGV0ZWN0cyBvc3ppbGxhdGlvbiwgZmxhcHBpbmcsIGV4dHJlbWUgdmFsdWVzLCBldGMsIGl0IHRl bGxzIG9uZSBBU0EgdG8gYmFjayBvZmYgZm9yIHRpbWUgeC4gT3IgZ2l2ZXMgaXQgY29uc3RyYWlu dHMsIGxpa2Ug4oCcbm8gaGlnaGVyIHRoYW4geOKAnSwgb3Ig4oCcZG9u4oCZdCBtb2RpZnkgZm9y IHggc2Vj4oCdLiBPci4uLg0KPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJp Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+U2VlIHdo YXQgSSBtZWFuLCB0aGF0IGNvdWxkIGJlY29tZSBhIHByZXR0eSBjb21wbGV4IGJlYXN0LiBOZWVk IHRvIHVuZGVyc3RhbmQgZmlyc3QgdGhlDQogYmFzaWMgaW50ZXJmYWNlcy4gPG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNv bG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9m b250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0 OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+TWljaGFlbDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFj ZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJy aSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20g NC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ2FsaWJyaSI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0O2ZvbnQtd2VpZ2h0OmJv bGQiPkZyb206PC9zcGFuPjwvZm9udD48L2I+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBm YWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3Rl eHQiPg0KIExhdXJlbnQgQ2lhdmFnbGlhIFttYWlsdG86bGF1cmVudC5jaWF2YWdsaWFAbm9raWEu Y29tXSA8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U2VudDo8L3NwYW4+ PC9iPiAwNyBBcHJpbCAyMDE2IDE3OjUxPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0 OmJvbGQiPlRvOjwvc3Bhbj48L2I+IGFuaW1hICZsdDthbmltYUBpZXRmLm9yZyZndDs7IExpdWJp bmcgKExlbykgJmx0O2xlby5saXViaW5nQGh1YXdlaS5jb20mZ3Q7OyBKw6lmZXJzb24gQ2FtcG9z IE5vYnJlICZsdDtqY25vYnJlQGluZi51ZnJncy5iciZndDs7IE1pY2hhZWwgQmVocmluZ2VyICht YmVocmluZykgJmx0O21iZWhyaW5nQGNpc2NvLmNvbSZndDs8YnI+DQo8Yj48c3BhbiBzdHlsZT0i Zm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDo8L3NwYW4+PC9iPiBRdWVzdGlvbnMgZHVyaW5nIEFO SU1BIElJIHNlc3Npb248bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGNvbG9yPSIjMzMzMzMzIiBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZv bnQgc2l6ZT0iMyIgY29sb3I9IiMzMzMzMzMiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oyxz ZXJpZiI+SGVsbG8sPGJyPg0KPGJyPg0KVGhhbmtzIGZvciB5b3VyIHBhdGllbmNlIHJlLiB0aGUg aXNzdWVzIGZhY2VkIGZvciB0aGUgcmVtb3RlIHByZXNlbnRhdGlvbnMuPGJyPg0KSSBob3BlIHlv dSBzdGlsbCBtYW5hZ2VkIHRvIHVuZGVyc3RhbmQgb3VyIG1lc3NhZ2VzIDspPGJyPg0KPGJyPg0K VGhlcmUgaGF2ZSBiZWVuIGNvbW1lbnRzIG9uIHRoZSBjb29yZGluYXRpb24gYW5kIGtub3dsZWRn ZSBwcmVzZW50YXRpb25zLjxicj4NCk1pY2hhZWwsIErDqWZlcnNvbiBhbmQgQmluZzogY291bGQg eW91IHJlcGVhdCB5b3VyIGNvbW1lbnQgb24gdGhlIGxpc3Q/PGJyPg0KSSBjYXVnaHQgdGhlIGZv bGxvd2luZzo8YnI+DQo8YnI+DQpRLiBNaWNoYWVsOiBleGFtcGxlcyBvZiBjb29yZGluYXRpb24s IHdoYXQgYSAobWluaW1hbCkgcG9saWN5IGVuZ2luZSBjb3VsZCBsb29rIGxpa2U/IHN0YXJ0IHNt YWxsLjxicj4NCjxicj4NClEuIEplZmVyc29uOiBpbXBsaWNhdGlvbnMgb24gZGF0YSBtb2RlbHMg LyBtZWFzdXJlbWVudC9tb25pdG9yaW5nLi4uID88YnI+DQo8YnI+DQpRLiBCaW5nOiB1c2UgR1JB U1Agb3Igb3RoZXIgbWVjaGFuaXNtcy4gQ2xhcmlmeSByZXF1aXJlbWVudHMgZm9yIEdSQVNQLjxi cj4NCjxicj4NClRoYW5rcywgTGF1cmVudC48L3NwYW4+PC9mb250PiA8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_08d561938cba4acbac5b35a3b8769cc6XCHRCD006ciscocom_-- From nobody Fri Apr 8 04:43:07 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB90F12D6E0 for ; Fri, 8 Apr 2016 04:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 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_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 eIHDVwFN-dw3 for ; Fri, 8 Apr 2016 04:43:05 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 0911812D6AD for ; Fri, 8 Apr 2016 04:43:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 7C640240A43; Fri, 8 Apr 2016 04:43:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1460115784; bh=U3GV9o5Y8wdpamLuSWMeSzJQiC0WpWFAZkxZYiVZnts=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Vu5jpqD3DxyUEFKzI1McVfFg2oVkEkFuzo6w4lLZTKpzGHB00KXZtNox0+yOPbnAS xJbEYJRMxzIvZ8y6WvnTndffSBOBzS33+d6xxwAchBT/UiIB9GS6zK9+83T9836xlp PjlztcfvN1PIPZxhkD51fvUAQTZkcs5L9yxM197k= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (200-127-148-163.net.prima.net.ar [200.127.148.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 9B4472404D0; Fri, 8 Apr 2016 04:43:02 -0700 (PDT) To: Brian E Carpenter , "Liubing (Leo)" , Anima WG References: <57070C20.9070408@gmail.com> From: "Joel M. Halpern" Message-ID: <57079943.7010004@joelhalpern.com> Date: Fri, 8 Apr 2016 07:42:59 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <57070C20.9070408@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Anima] GRASP, discovery, and roles X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 08 Apr 2016 11:43:06 -0000 Yes, I think the issue here is that folks assume "but of course you can do that", and it is even natural to implement, but not the conclusion that I got reading the spec. So yes, a lot of what I am asking for probably is just more clarity in the spec. Yours, Joel On 4/7/16 9:40 PM, Brian E Carpenter wrote: > On 08/04/2016 11:52, jmh.direct wrote: >> As I understand it, if an entity has at least one cached answer, it will send me that and stop propagating mybrequedt. > > Actually I don't think that's how I coded it but that hardly matters; we can > review the spec to be unambiguous on that point. > > But there's another point here which may need to be made a formal requirement > with some better terminology. > > You can discover an objective without supporting it yourself. For example, > we want exactly one node to support the AN_Registrar objective but any other > node may need to discover it. That was kind of intuitive when coding my > prototype but we need to make it explicit. > > Brian > >> And it can't tell if the answer is insufficient.Yours,Joel >> >> >> Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone-------- Original message --------From: "Liubing (Leo)" Date: 4/7/2016 7:38 PM (GMT-03:00) To: "Joel M. Halpern" , Anima WG Subject: RE: [Anima] GRASP, discovery, and roles >>> -----Original Message----- >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>> Sent: Thursday, April 07, 2016 7:25 PM >>> To: Liubing (Leo); Anima WG >>> Subject: Re: [Anima] GRASP, discovery, and roles >>> >>> If I could just ignore some responses, and be sure I would get the other >>> responses, that would be a way to solve the problem. But as far as I >>> understand GRASP< that isn't what happens. My discovery might prompt >>> several answers, but along any given branch it stops when it hits any responder, >>> even if they are just another participant. >> >> [Bing] This is the "multiple responses" open issue we used to discuss. >> GRASP will not stop receiving other responses, (actually it just can't), according to discussion in last ietf, people tended to handle the multiple responses to ASA, who will decide to use which discovered result. I think we'll need to clearly specify the behavior in the API document. >> >> B.R. >> Bing >> >>> >>> Yours, >>> Joel >>> >>> On 4/7/16 6:16 PM, Liubing (Leo) wrote: >>>>> -----Original Message----- >>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>>> Sent: Thursday, April 07, 2016 6:57 PM >>>>> To: Liubing (Leo); Anima WG >>>>> Cc: Brian E Carpenter >>>>> Subject: Re: [Anima] GRASP, discovery, and roles >>>>> >>>>> Given that I register in order to participate in teh discovery, it >>>>> seems that I could just as easily end up "discovering" another >>>>> participant when what I need is the coordinator. >>>> >>>> [Bing] In terms of GRASP terminology, what you need is the "coordination >>> function/service", and the one who response you, implies it is a "coordinator" >>> or whatever role which could provide identical coordination function/service as >>> the "coordinator". So, just don't worry about the one who response you is >>> "another" guy who is not qualified to serve you. >>>> >>>> Did I capture your concern correctly? >>>> >>>> B.R. >>>> Bing >>>> >>>>> Am I mis-reading it? >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 4/7/16 5:48 PM, Liubing (L >>>>> >>>>> >>>>> _______________________________________________ >>>>> Anima mailing list >>>>> Anima@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/anima > From nobody Fri Apr 8 05:45:21 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5702412D810 for ; Fri, 8 Apr 2016 05:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 z_lLWWUsq3B7 for ; Fri, 8 Apr 2016 05:45:17 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0067812D711 for ; Fri, 8 Apr 2016 05:45:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15064; q=dns/txt; s=iport; t=1460119517; x=1461329117; h=from:to:subject:date:message-id:references:in-reply-to: reply-to:mime-version; bh=zOp27igqTj/Udshoj+jY5pvkIrl1hOHDbicavYy5vpY=; b=L+mWQY6DfOISaDfIkrJ0PtxkJda5ymsaAkF0cRydjcUlRY0erxlUbGZP dC3AudmlT3dRy9bCDd3w9dLxVCzJqIsPnq/jx23Osje6ckK26s9izZ6WY peQLQ9PmgMJTpwTInUMbNmbRlshpYRSgGl2aphEXUWlJpPWc+FlfSBTQ2 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAgClpwdX/4QNJK1cgmtMU321UoRzA?= =?us-ascii?q?Q2BcxcBCYI8gzACgTQ4FAEBAQEBAQFlJ4RBAQEBBAEBAWsXBAIBCBEDAQEBCh4?= =?us-ascii?q?HDxgLDgYJCAIEARIZiA4OtFOLYAEBAQEBAQEBAQEBAQEBAQEBAQEBARWJaoECh?= =?us-ascii?q?F+FNgWGLwmHTol+AYV2gnKFI48NjyQBDw8BAUKCBBmBSmyHfAaBNwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208,217";a="259081652" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Apr 2016 12:45:11 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u38CjBKl014845 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Apr 2016 12:45:11 GMT Received: from xch-rcd-003.cisco.com (173.37.102.13) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 8 Apr 2016 07:45:10 -0500 Received: from xch-rcd-003.cisco.com ([173.37.102.13]) by XCH-RCD-003.cisco.com ([173.37.102.13]) with mapi id 15.00.1104.009; Fri, 8 Apr 2016 07:45:10 -0500 From: "Toerless Eckert (eckert)" To: Laurent Ciavaglia , EXT Brian E Carpenter , "jmh.direct" , "Liubing (Leo)" , "Joel M. Halpern" , Anima WG Thread-Topic: [Anima] GRASP, discovery, and roles Thread-Index: AQHRkSiKhXKkFFx/Jk2XnpX/Iy9Esp9/oNoAgABx6QD///Pljg== Date: Fri, 8 Apr 2016 12:45:10 +0000 Message-ID: References: <57070C20.9070408@gmail.com>,<57076BAE.2070807@alcatel-lucent.com> In-Reply-To: <57076BAE.2070807@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_aaqnhjsncslenam6024bp2551460116807063emailandroidcom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] GRASP, discovery, and roles X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "Toerless Eckert \(eckert\)" List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 12:45:20 -0000 --_000_aaqnhjsncslenam6024bp2551460116807063emailandroidcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Forblifecycle, i would like to see us define the "lame" model of "magically= present on device" (classic router model of big blob software with everyth= ing you maybe need), and "good" where asa is an independent app that autono= mic functions can download and install when and where needed. One interesting question is how portable we would like good ASA to be. Sent from my Samsung Captivate Glide on AT&T Laurent Ciavaglia wrote: Hello, I think it should be explicit in the specification of the ASA life-cycle wh= at it does when it boots (and in other phases as well): e.g. discover / register to (entities playing) special roles such as re= gistrar, coordination, intent, knowledge index... This set of "roles" and life-cycle must be fixed and specified by the stand= ard, not left open to ASA developers' creativity because these are special = roles/objectives that must be supported / understood by all ASAs / or ANode= s (proxy) agents. What seems not fully defined yet is precisely a complete ASA life-cycle (cf= discussion and drafts on the topic) and the minimal set of roles to deploy= and have an autonomic networks ready for operation / operating. Shall we upgrade the reference model document section on theory of operatio= ns with these aspects or should it be another doc? FYI, draft-peloso-anima-autonomic-function attempts to describe such a life= -cycle. Best regards, Laurent. On 08/04/2016 03:40, EXT Brian E Carpenter wrote: On 08/04/2016 11:52, jmh.direct wrote: As I understand it, if an entity has at least one cached answer, it will se= nd me that and stop propagating mybrequedt. Actually I don't think that's how I coded it but that hardly matters; we ca= n review the spec to be unambiguous on that point. But there's another point here which may need to be made a formal requireme= nt with some better terminology. You can discover an objective without supporting it yourself. For example, we want exactly one node to support the AN_Registrar objective but any othe= r node may need to discover it. That was kind of intuitive when coding my prototype but we need to make it explicit. Brian And it can't tell if the answer is insufficient.Yours,Joel Sent via the Samsung Galaxy S=AE 6, an AT&T 4G LTE smartphone-------- Origi= nal message --------From: "Liubing (Leo)" Date: 4/7/2016 7:38 PM (GMT-03:00) To: "Joel M. Ha= lpern" , Anima WG Subject: RE: [Anima] GRASP, discovery, and = roles -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Thursday, April 07, 2016 7:25 PM To: Liubing (Leo); Anima WG Subject: Re: [Anima] GRASP, discovery, and roles If I could just ignore some responses, and be sure I would get the other responses, that would be a way to solve the problem. But as far as I understand GRASP< that isn't what happens. My discovery might prompt several answers, but along any given branch it stops when it hits any respo= nder, even if they are just another participant. [Bing] This is the "multiple responses" open issue we used to discuss. GRASP will not stop receiving other responses, (actually it just can't), ac= cording to discussion in last ietf, people tended to handle the multiple re= sponses to ASA, who will decide to use which discovered result. I think we'= ll need to clearly specify the behavior in the API document. B.R. Bing Yours, Joel On 4/7/16 6:16 PM, Liubing (Leo) wrote: -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Thursday, April 07, 2016 6:57 PM To: Liubing (Leo); Anima WG Cc: Brian E Carpenter Subject: Re: [Anima] GRASP, discovery, and roles Given that I register in order to participate in teh discovery, it seems that I could just as easily end up "discovering" another participant when what I need is the coordinator. [Bing] In terms of GRASP terminology, what you need is the "coordination function/service", and the one who response you, implies it is a "coordinat= or" or whatever role which could provide identical coordination function/servic= e as the "coordinator". So, just don't worry about the one who response you is "another" guy who is not qualified to serve you. Did I capture your concern correctly? B.R. Bing Am I mis-reading it? Yours, Joel On 4/7/16 5:48 PM, Liubing (L _______________________________________________ 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 -- Laurent Ciavaglia Senior Research Manager Bell Labs, Nokia +33 160 402 636 Route de Villejust | 91620 Nozay | France LinkedIn: laurentciavaglia --_000_aaqnhjsncslenam6024bp2551460116807063emailandroidcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Forblifecycle, i would like to see us define the "lame" mode= l of "magically present on device" (classic router model of big b= lob software with everything you maybe need), and "good" where as= a is an independent app that autonomic functions can download and install when and where needed.

One interesting question is how portable we would like good ASA to be.=



Sent from my Samsung Captivate = Glide on AT&T

Laurent Ciavaglia <laurent.ciavaglia@nokia.com> wrote:
Hello,

I think it should be explicit in the specification of the ASA life-cycle wh= at it does when it boots (and in other phases as well):
    e.g. discover / register to (entities playing) special r= oles such as registrar, coordination, intent, knowledge index...

This set of "roles" and life-cycle must be fixed and specified by= the standard, not left open to ASA developers' creativity because these ar= e special roles/objectives that must be supported / understood by all ASAs = / or ANodes (proxy) agents.

What seems not fully defined yet is precisely a complete ASA life-cycle (cf= discussion and drafts on the topic) and the minimal set of roles to deploy= and have an autonomic networks ready for operation / operating.

Shall we upgrade the reference model document section on theory of operatio= ns with these aspects or should it be another doc?

FYI, draft-peloso-anima-autonomic-function attempts to describe such a life= -cycle.

Best regards, Laurent.

On 08/04/2016 03:40, EXT Brian E Carpenter w= rote:
On 08/04/2016 11:52, jmh.direct wrote:

As I understand it, if an entity has at least one cached answer, it wi=
ll send me that and stop propagating mybrequedt.

Actually I don't think that's how I coded it but that hardly matters; we ca=
n
review the spec to be unambiguous on that point.

But there's another point here which may need to be made a formal requireme=
nt
with some better terminology.

You can discover an objective without supporting it yourself. For example,
we want exactly one node to support the AN_Registrar objective but any othe=
r
node may need to discover it. That was kind of intuitive when coding my
prototype but we need to make it explicit.

    Brian


And it can't tell if the answer is insufficient.Yours,Joel


Sent via the Samsung Galaxy S=AE 6, an AT&T 4G LTE smartphone-------- O=
riginal message --------From: "Liubing (Leo)" <leo.liubing@huaw=
ei.com> Date: 4/7/2016  7:38 PM  (GMT-03:00) To: "Joel M. Halpe=
rn" <jmh@joelhalpern.com>, Anima WG <anima@ietf.org> Subject: R=
E: [Anima] GRASP, discovery, and roles=20

-----Original Message-----
From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
Sent: Thursday, April 07, 2016 7:25 PM
To: Liubing (Leo); Anima WG
Subject: Re: [Anima] GRASP, discovery, and roles

If I could just ignore some responses, and be sure I would get the other
responses, that would be a way to solve the problem.  But as far as I
understand GRASP< that isn't what happens.  My discovery might prompt
several answers, but along any given branch it stops when it hits any respo=
nder,
even if they are just another participant.

[Bing] This is the "multiple responses" open issue we used to dis=
cuss.=20
GRASP will not stop receiving other responses, (actually it just can't), ac=
cording to discussion in last ietf, people tended to handle the multiple re=
sponses to ASA, who will decide to use which discovered result. I think we'=
ll need to clearly specify the behavior in the API document.

B.R.
Bing


Yours,
Joel

On 4/7/16 6:16 PM, Liubing (Leo) wrote:

-----Original Message-----
From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
Sent: Thursday, April 07, 2016 6:57 PM
To: Liubing (Leo); Anima WG
Cc: Brian E Carpenter
Subject: Re: [Anima] GRASP, discovery, and roles

Given that I register in order to participate in teh discovery, it
seems that I could just as easily end up "discovering" another
participant when what I need is the coordinator.

[Bing] In terms of GRASP terminology, what you need is the "coordinati=
on

function/service", and the one who response you, implies it is a =
"coordinator"
or whatever role which could provide identical coordination function/servic=
e as
the "coordinator". So, just don't worry about the one who respons=
e you is
"another" guy who is not qualified to serve you.

Did I capture your concern correctly?

B.R.
Bing


Am I mis-reading it?

Yours,
Joel

On 4/7/16 5:48 PM, Liubing (L


_______________________________________________
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

--

Laurent Ciavaglia

Senior Research Manager

Bell Labs, Nokia

 

+33 160 402 636

Route de Villejust | 91620 N= ozay | France

LinkedIn: laurentciavaglia

 

--_000_aaqnhjsncslenam6024bp2551460116807063emailandroidcom_-- From nobody Fri Apr 8 09:46:43 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E496612D0B4 for ; Fri, 8 Apr 2016 09:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ZICvj2OjZ_01 for ; Fri, 8 Apr 2016 09:46:39 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1404912D0B1 for ; Fri, 8 Apr 2016 09:46:39 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id j11so83762405lfb.1 for ; Fri, 08 Apr 2016 09:46:38 -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; bh=9CIvUu7rVjoB+c8ctMMPXHxqVZ4mSy70weaWNKNkYVM=; b=wV6ZEM6+Bu/Bmzkk961oBtcq5piWPFRPzAS9vCp3Vm2yMXqM3H3m8o8ZL0dC/2XV+t 8Rchi/Cap8r3RqIkR0fMfhtJjanHrUI2JLplOKsyi835Fw6GJSDpVcZZG0300lYM27pv lzPVYEhGW4pLSncn13q7COvXR092e3SQWUJOLUf6IvLQBsNvwCj+hmI44KORTcvzth5b sPFSIDqqFkjAmHBgEibnLmiE0l1fMb/c4hhinbi1/xRcSgEcCf4vUIRQQ4k/GSubjqQy k2WJu5EFgs7/xAwyRpVnq+G8bZwI4EJwraQ0IHOM+y5jgyHCT1oawPIFCoGMG+s7y+Oz PifQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=9CIvUu7rVjoB+c8ctMMPXHxqVZ4mSy70weaWNKNkYVM=; b=QoU4bDWp7Cdc8gyt5HWfCGjEtCWWJi7yW33/Ieg0wawQ0aQWbEiKvJ1uTGUrJlAPIb t4py4SFO0j+YB5q8fhADaCQgr0f4X1QO0Wc1BJIQ+jM+dwe0YHJtQAh0aFEIdgL+6nCb jw532DOHStrYlPju+QHnafCresC1lYzEgZU6JjC5MdFbwcQRL1rNBFF43xv3yNOw6wZV MgrArAE+blLheJzvjAEzBccrjIvvejWBl4e0mTzdwWY68dDikEdArl0AeoLmuVEMm9oG RyNmIVMfgi7NXqa6NIjTnt6Wybv3RSm6ObXUDSEYTOFGg3t6mnbjSKPwW3EHmPjK/z/B uD0A== X-Gm-Message-State: AD7BkJJKZ8Yd9ws9GeGqUFrXRaTEx3beshgwXGfxNNjNWyCQmNjLDlfkoCCHi3X1GBnaSorlgrlwUIOk3yz+cA== MIME-Version: 1.0 X-Received: by 10.112.84.202 with SMTP id b10mr3912284lbz.41.1460133997198; Fri, 08 Apr 2016 09:46:37 -0700 (PDT) Received: by 10.25.22.19 with HTTP; Fri, 8 Apr 2016 09:46:37 -0700 (PDT) In-Reply-To: <23755.1460045020@obiwan.sandelman.ca> References: <23755.1460045020@obiwan.sandelman.ca> Date: Fri, 8 Apr 2016 09:46:37 -0700 Message-ID: From: John Strassner To: Michael Richardson , John Strassner Content-Type: multipart/alternative; boundary=001a1135ea063a4382052ffbf0a8 Archived-At: Cc: anima Subject: Re: [Anima] Intent Discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 08 Apr 2016 16:46:42 -0000 --001a1135ea063a4382052ffbf0a8 Content-Type: text/plain; charset=UTF-8 Hi Michael, (snipping)... > Intent one single file? ... > I don't see any reason we should worry if Intents fit into a packet. > So, can we stop? I think we all agree here... >> Updating / removing Intent >> - Intent doesn't have a mandatory expiration date > Can I amend this to: An Intent doesn't have to have a finite expiration date? > Couldn't an Intent apply until "Condition X" is met? Agreed ... >> Conflict resolution? >> - device needs to deal with conflict and react predictably. >> - device may not be able to resolve locally. >> - but the conflict may need to be resolved centrally --> needs a feedback loop. >> (we don't specify where those feedback loops are going - several posibilities) > We'll have an ASA for that. Seriously. I would think that: a) there will be multiple ASAs for this b) there will be local (e.g., per-domain) and global (e.g., spanning domains) sources of conflict detection and resolution >> "Translating" Intent >> - Does Intent have to be "translated" from a high level policy to something >> more lower level before it gets distributed? > We'll have an ASA for that too. > Maybe it requires that a VM be spun up with some vendor specific software > that translates intents to CLI commands (I'm familiar with JUNOS Space..); > but whatever works. IMHO, intent is scoped by the tuple {domain, context, role}. So, we will likely have **multiple** ASAs for this. >> - Ex from John: "Platinum customer" - always best service. >> But I shouldn't map everything (ex: FTP) into an EF queue. >> - might require to translate to an intermediate Intent format. >> - this tranlation should probably not happen on the devices. >> this translation could/should happen centrally; > I think that each device may well observe the Intent, and may well ask their > oracle if they are compliant. Agreed On Thu, Apr 7, 2016 at 9:03 AM, Michael Richardson wrote: > > Michael Behringer (mbehring) wrote: > > Michael > > Thanks for the notes. > > > Intent one single file? > > - Intent may come from different entry points > > - should not enforce a single file. (but it may be initially) > > - but shouldn't be just lots of separate statements either. > > > Fragmenting Intent > > - however we express Intent, we don't want to require that Intent > MUST be > > able to be de-composed into its atomic bits with a fixed size limit > --> we must not require that atomic bit MUST fit into a packet. > > - some form of fragmenting an Intent file is ok > > + could be done through using TCP (or similar) > > + could be done by fragmenting Intent into individual parts > > We are building an ACP that supports our entire suite of IP(v6) protocols. > Fragmentation/segmentation, caching are already protocols that we have. > > Intents are going to be signed objects of some kind. > (I favour JOSE, but xmldsig would be fine as well, or even S/MIME if > someone > has a good argument for that). > > I don't see any reason we should worry if Intents fit into a packet. > So, can we stop? > > > Updating / removing Intent > > - Intent doesn't have a mandatory expiration date > > Can I amend this to: An Intent doesn't have to have a finite expiration > date? > Couldn't an Intent apply until "Condition X" is met? > > > - if no longer required / desired, remove or update Intent. > > - it's ok to have a *statement* to remove a *statement*. > > Yes, I agree strongly. > > Consider a base Intent that says that the network should move as much > traffic > as possible. (Imagine that in the future there were peering arrangements > at > IXs so that we had automatic bidding in the way that the electrical market > works in some parts of the world) > > Imagine an Intent that is issued on Tuesday that says: > "Limit committed traffic to an aggregate of less than PIPE X" > (Inception Date: Thursday 23:59 > Expiry Date: Monday 00:00) > > The reason to issue this Intent is because of planned maintenance on the > weekend which will cause pipes Y and Z to become unstable. > > The above Intent would amend the original base intent for a period of time, > and then it would expire. > > > Conflict resolution? > > - device needs to deal with conflict and react predictably. > > - device may not be able to resolve locally. > > - but the conflict may need to be resolved centrally --> needs a > feedback loop. > > (we don't specify where those feedback loops are going - several > posibilities) > > We'll have an ASA for that. Seriously. > > > "Translating" Intent > > - Does Intent have to be "translated" from a high level policy to > something > > more lower level before it gets distributed? > > We'll have an ASA for that too. > Maybe it requires that a VM be spun up with some vendor specific software > that translates intents to CLI commands (I'm familiar with JUNOS Space..); > but whatever works. > > > - Ex from John: "Platinum customer" - always best service. > > But I shouldn't map everything (ex: FTP) into an EF queue. > > - might require to translate to an intermediate Intent format. > > - this tranlation should probably not happen on the devices. > > this translation could/should happen centrally; > > I think that each device may well observe the Intent, and may well ask > their > oracle if they are compliant. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > > -- regards, John --001a1135ea063a4382052ffbf0a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Michael,

(snipping)...

> Intent one single file?
...
> = I don't see any reason we should worry if Intents fit into a packet. > So, can we stop?

I think we all agree here.= ..

>> Updating / removing Intent
>> - Intent doesn= 9;t have a mandatory expiration date

> Can I amend this to: An I= ntent doesn't have to have a finite expiration date?
> Couldn= 9;t an Intent apply until "Condition X" is met?

Agreed

...

>> Conflict resolution?
>> = - device needs to deal with conflict and react predictably.
>> - d= evice may not be able to resolve locally.
=C2=A0>> - but the confl= ict may need to be resolved centrally --> needs a feedback loop.
=C2= =A0>> (we don't specify where those feedback loops are going - se= veral posibilities)

> We'll have an ASA for that.=C2=A0 Seri= ously.

I would think that:

=C2=A0=C2=A0 a) there will be multiple ASAs for this
=C2=A0=C2= =A0 b) there will be local (e.g., per-domain) and global (e.g., spanning do= mains)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sources of conflict d= etection and resolution


>> "Translating" = Intent
>> - Does Intent have to be "translated" from a = high level policy to something
=C2=A0>> more lower level before it= gets distributed?

> We'll have an ASA for that too.
>= =C2=A0Maybe it requires that a VM be spun up with some vendor specific soft= ware
> that translates intents to CLI commands (I'm familiar wit= h JUNOS Space..);
> but whatever works.

IMH= O, intent is scoped by the tuple {domain, context, role}. So, we will likel= y
have **multiple** ASAs for this.

>> - Ex from John= : "Platinum customer" - always best service.
=C2=A0>> Bu= t I shouldn't map everything (ex: FTP) into an EF queue.
=C2=A0>&= gt; - might require to translate to an intermediate Intent format.
=C2= =A0>> - this tranlation should probably not happen on the devices.=C2=A0>> this translation could/should happen centrally;

>= ; I think that each device may well observe the Intent, and may well ask th= eir
> oracle if they are compliant.

Agreed<= br>

On= Thu, Apr 7, 2016 at 9:03 AM, Michael Richardson <mcr+ietf@sandelman.c= a> wrote:

Michael Behringer (mbehring) <mbeh= ring@cisco.com> wrote:
=C2=A0 =C2=A0 > Michael

Thanks for the notes.

=C2=A0 =C2=A0 > Intent one single file?
=C2=A0 =C2=A0 > - Intent may come from different entry points
=C2=A0 =C2=A0 > - should not enforce a single file. (but it may be initi= ally)
=C2=A0 =C2=A0 > - but shouldn't be just lots of separate statements = either.

=C2=A0 =C2=A0 > Fragmenting Intent
=C2=A0 =C2=A0 > - however we express Intent, we don't want to requir= e that Intent MUST be
=C2=A0 =C2=A0 > able to be de-composed into its atomic bits with a fixed= size limit
=C2=A0 =C2=A0 --> we must not require that atomic bit MUST fit into a pa= cket.
=C2=A0 =C2=A0 > - some form of fragmenting an Intent file is ok
=C2=A0 =C2=A0 > + could be done through using TCP (or similar)
=C2=A0 =C2=A0 > + could be done by fragmenting Intent into individual pa= rts

We are building an ACP that supports our entire suite of IP(v6) protocols.<= br> Fragmentation/segmentation, caching are already protocols that we have.

Intents are going to be signed objects of some kind.
(I favour JOSE, but xmldsig would be fine as well, or even S/MIME if someon= e
has a good argument for that).

I don't see any reason we should worry if Intents fit into a packet. So, can we stop?

=C2=A0 =C2=A0 > Updating / removing Intent
=C2=A0 =C2=A0 > - Intent doesn't have a mandatory expiration date
Can I amend this to: An Intent doesn't have to have a finite expiration= date?
Couldn't an Intent apply until "Condition X" is met?

=C2=A0 =C2=A0 > - if no longer required / desired, remove or update Inte= nt.
=C2=A0 =C2=A0 > - it's ok to have a *statement* to remove a *stateme= nt*.

Yes, I agree strongly.

Consider a base Intent that says that the network should move as much traff= ic
as possible.=C2=A0 (Imagine that in the future there were peering arrangeme= nts at
IXs so that we had automatic bidding in the way that the electrical market<= br> works in some parts of the world)

Imagine an Intent that is issued on Tuesday that says:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Limit committed traffic to an aggregate o= f less than PIPE X"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (Inception Date: Thursday 23:59
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Expiry Date: Monday 00:00)

The reason to issue this Intent is because of planned maintenance on the weekend which will cause pipes Y and Z to become unstable.

The above Intent would amend the original base intent for a period of time,=
and then it would expire.

=C2=A0 =C2=A0 > Conflict resolution?
=C2=A0 =C2=A0 > - device needs to deal with conflict and react predictab= ly.
=C2=A0 =C2=A0 > - device may not be able to resolve locally.
=C2=A0 =C2=A0 > - but the conflict may need to be resolved centrally --&= gt; needs a feedback loop.
=C2=A0 =C2=A0 > (we don't specify where those feedback loops are goi= ng - several posibilities)

We'll have an ASA for that.=C2=A0 Seriously.

=C2=A0 =C2=A0 > "Translating" Intent
=C2=A0 =C2=A0 > - Does Intent have to be "translated" from a h= igh level policy to something
=C2=A0 =C2=A0 > more lower level before it gets distributed?

We'll have an ASA for that too.
Maybe it requires that a VM be spun up with some vendor specific software that translates intents to CLI commands (I'm familiar with JUNOS Space.= .);
but whatever works.

=C2=A0 =C2=A0 > - Ex from John: "Platinum customer" - always b= est service.
=C2=A0 =C2=A0 > But I shouldn't map everything (ex: FTP) into an EF = queue.
=C2=A0 =C2=A0 > - might require to translate to an intermediate Intent f= ormat.
=C2=A0 =C2=A0 > - this tranlation should probably not happen on the devi= ces.
=C2=A0 =C2=A0 > this translation could/should happen centrally;

I think that each device may well observe the Intent, and may well ask thei= r
oracle if they are compliant.

--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-




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




--
regards,
John
--001a1135ea063a4382052ffbf0a8-- From nobody Fri Apr 8 13:34:50 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F27E12D738 for ; Fri, 8 Apr 2016 13:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 duo8Me6yuSs9 for ; Fri, 8 Apr 2016 13:34:46 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AB1612D6C4 for ; Fri, 8 Apr 2016 13:34:46 -0700 (PDT) Received: by mail-pa0-x233.google.com with SMTP id td3so80704588pab.2 for ; Fri, 08 Apr 2016 13:34:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=OzXuTYtoMuieorH3SlsXQiacN6KHPilqM5sis4feSW4=; b=r59HyVrTnIYNHLyiuRAYMcZ02oqgkMzAlmUhnHDirSpURJ4dHMAeb0YbwiUIwP0VnV ysX1f2ABlM0X9+Gc/QjCVvIStDCe3086Q1GV7uJawnqqEmZeyj9ro2LTXKrhDsaNRuFc 75hkoxgXAwL91fTTQ8AIhQb2VJGYqijlUbHKmof6NSKZ9a+ulxobEubRZ20QOkB3xhq9 1lTsCrmWFiPf6iaSaA/WtuUSdY09uoStmQTKXO+vAZNhYhVD5j6dnQLddWIYzQ+9hWYw QUvQInD5qNj4pKDWpTZDtCBfqw9TNRQcqH4kkl6AIHANx4qDWFeRCaj5gHSelWunNMvk 4LqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=OzXuTYtoMuieorH3SlsXQiacN6KHPilqM5sis4feSW4=; b=ZOBAHxv1BkBzfYos8DLEy02srigKWsiFGS8dpLIQmkYbxpnFxJ/dMZYmqr/VKsdMNL 9+Eb+IIIwqIWawyMFRzyysKbrJuXVLW69Kh/z/wJQWqYpWQLp1vngDYkH9C6wjs++4t4 /ltOPlTHIlP+bHE0j+69CqMGOH/LbY9lvfnOjA6xE7iP3ooyoygmd/4Jzxv34P21TA+W aSfUrhW24UkWRgRJOlCJXArDGtdUyMHXufIaRgHdwKdM3SsdxSa+8DcYGpyA7bgwYWtQ Xln70txWJxfU4yjWQshcsn7opiZLSCh/k1BD8v1lkQ9wHJSH8Fs5WsssUaLrdoBXPOEo WpFg== X-Gm-Message-State: AD7BkJJUzLf6YbldRpqla0r5ergBjdCyNcqdlorXmm5322h7zXCLEhoATUGfJ6P/NiawgA== X-Received: by 10.66.193.161 with SMTP id hp1mr15310537pac.9.1460147685488; Fri, 08 Apr 2016 13:34:45 -0700 (PDT) Received: from ?IPv6:2406:e007:7c81:1:28cc:dc4c:9703:6781? ([2406:e007:7c81:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 3sm20555661pfn.59.2016.04.08.13.34.41 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Apr 2016 13:34:44 -0700 (PDT) To: "Toerless Eckert (eckert)" , Laurent Ciavaglia , "jmh.direct" , "Liubing (Leo)" , "Joel M. Halpern" , Anima WG References: <57070C20.9070408@gmail.com> <57076BAE.2070807@alcatel-lucent.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <570815E9.5090101@gmail.com> Date: Sat, 9 Apr 2016 08:34:49 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] GRASP, discovery, and roles X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 08 Apr 2016 20:34:48 -0000 Firstly I fully agree with Laurent; we need a lifecycle model to understa= nd how an ASA fits into the ecosystem. I think we aren't ready to write down the= details yet, though. (For example, it's obvious we need an ASA registration of so= me sort, but I'm not yet convinced that all ASAs need to present a manifest.) On 09/04/2016 00:45, Toerless Eckert (eckert) wrote: > Forblifecycle, i would like to see us define the "lame" model of "magic= ally present on device" (classic router model of big blob software with e= verything you maybe need), and "good" where asa is an independent app tha= t autonomic functions can download and install when and where needed. Yes, I think both cases are needed. > One interesting question is how portable we would like good ASA to be. Good question, indeed. I assume we want the infrastructure ASAs (the ones= that are really part of the ANI) to be fully portable. But for example can the draft-ietf-anima-prefix-management ASA be identical on routers from different vendors? And surely there will be some that really are vendor-specific. Brian >=20 > Sent from my Samsung Captivate Glide on AT&T >=20 > Laurent Ciavaglia wrote: > Hello, >=20 > I think it should be explicit in the specification of the ASA life-cycl= e what it does when it boots (and in other phases as well): > e.g. discover / register to (entities playing) special roles such a= s registrar, coordination, intent, knowledge index... >=20 > This set of "roles" and life-cycle must be fixed and specified by the s= tandard, not left open to ASA developers' creativity because these are sp= ecial roles/objectives that must be supported / understood by all ASAs / = or ANodes (proxy) agents. >=20 > What seems not fully defined yet is precisely a complete ASA life-cycle= (cf discussion and drafts on the topic) and the minimal set of roles to = deploy and have an autonomic networks ready for operation / operating. >=20 > Shall we upgrade the reference model document section on theory of oper= ations with these aspects or should it be another doc? >=20 > FYI, draft-peloso-anima-autonomic-function attempts to describe such a = life-cycle. >=20 > Best regards, Laurent. >=20 > On 08/04/2016 03:40, EXT Brian E Carpenter wrote: >=20 > On 08/04/2016 11:52, jmh.direct wrote: >=20 >=20 > As I understand it, if an entity has at least one cached answer, it wil= l send me that and stop propagating mybrequedt. >=20 >=20 >=20 > Actually I don't think that's how I coded it but that hardly matters; w= e can > review the spec to be unambiguous on that point. >=20 > But there's another point here which may need to be made a formal requi= rement > with some better terminology. >=20 > You can discover an objective without supporting it yourself. For examp= le, > we want exactly one node to support the AN_Registrar objective but any = other > node may need to discover it. That was kind of intuitive when coding my= > prototype but we need to make it explicit. >=20 > Brian >=20 >=20 >=20 > And it can't tell if the answer is insufficient.Yours,Joel >=20 >=20 > Sent via the Samsung Galaxy S=C2=AE 6, an AT&T 4G LTE smartphone-------= - Original message --------From: "Liubing (Leo)" = Date: 4/7/2016 7:38 PM (GMT-03:00) To: = "Joel M. Halpern" , Anim= a WG Subject: RE: [Anima] GRASP, = discovery, and roles >=20 >=20 > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Thursday, April 07, 2016 7:25 PM > To: Liubing (Leo); Anima WG > Subject: Re: [Anima] GRASP, discovery, and roles >=20 > If I could just ignore some responses, and be sure I would get the othe= r > responses, that would be a way to solve the problem. But as far as I > understand GRASP< that isn't what happens. My discovery might prompt > several answers, but along any given branch it stops when it hits any r= esponder, > even if they are just another participant. >=20 >=20 >=20 > [Bing] This is the "multiple responses" open issue we used to discuss. > GRASP will not stop receiving other responses, (actually it just can't)= , according to discussion in last ietf, people tended to handle the multi= ple responses to ASA, who will decide to use which discovered result. I t= hink we'll need to clearly specify the behavior in the API document. >=20 > B.R. > Bing >=20 >=20 >=20 >=20 > Yours, > Joel >=20 > On 4/7/16 6:16 PM, Liubing (Leo) wrote: >=20 >=20 > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Thursday, April 07, 2016 6:57 PM > To: Liubing (Leo); Anima WG > Cc: Brian E Carpenter > Subject: Re: [Anima] GRASP, discovery, and roles >=20 > Given that I register in order to participate in teh discovery, it > seems that I could just as easily end up "discovering" another > participant when what I need is the coordinator. >=20 >=20 >=20 > [Bing] In terms of GRASP terminology, what you need is the "coordinatio= n >=20 >=20 > function/service", and the one who response you, implies it is a "coord= inator" > or whatever role which could provide identical coordination function/se= rvice as > the "coordinator". So, just don't worry about the one who response you = is > "another" guy who is not qualified to serve you. >=20 >=20 >=20 > Did I capture your concern correctly? >=20 > B.R. > Bing >=20 >=20 >=20 > Am I mis-reading it? >=20 > Yours, > Joel >=20 > On 4/7/16 5:48 PM, Liubing (L >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 >=20 > -- > Laurent Ciavaglia > Senior Research Manager > Bell Labs, Nokia >=20 > +33 160 402 636 > Route de Villejust | 91620 Nozay | France > LinkedIn: laurentciavaglia= >=20 >=20 >=20 From nobody Fri Apr 8 15:45:44 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 986CE12D14D for ; Fri, 8 Apr 2016 15:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6ONIOMlrbdTJ for ; Fri, 8 Apr 2016 15:45:39 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BB8312D11F for ; Fri, 8 Apr 2016 15:45:39 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id g184so93835077lfb.3 for ; Fri, 08 Apr 2016 15:45:39 -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; bh=4k+oAou8g8JqE3m1RWp+NaY5l+w+kPBf2u06gchVBzc=; b=xrS41Dk/vdfEqmuhSh6mmVqOVZlya6ZVONIs32hyIyWZIAgvpQDAipN1eJZxk69mdi DARPUpnxQ1Xyua5MRnYwR1ypWaJ2F1n/0St5e0GINSrBCixjg6uFsM+IcbIKO1JW9Hiv rxCOalP9varZfaVT/2Xe+FOV9zTeseXdlYXTJ+Tg1/bDPz/mVe5CHPFOWw2TLrClTV31 N6yG1Tu+lLfRv2O3qcfTXmyRNmdRmm/EFSbSzI1Wlhu1CY6gov0xsB7MA5iK6cGMsKiO 7TQSDfM1nhq8IW1MqfiMyXRVUq2AtmXdqu0BtOEc8RD4oIeFcx0DAg9GcDdJTIQR3kMB x8vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=4k+oAou8g8JqE3m1RWp+NaY5l+w+kPBf2u06gchVBzc=; b=aqp0LIkvlIKgCJBNhH9//Bgf8AoYSPo7wW1hWju4z1mFfC9VmSVucDxjoVtBFLK76T k6rdVgcvILcIgBoh8Z38u3K/SAJSkt9rCANf4nd7YrOmfiJHwEug9QCCOiLeKo4g3cHQ fpxVvl1R2yEViwzPehyUN4Ru4D2owzmAEmcZo4Dp8qWG7qz3ALNkvEK06772wgy1rA15 UUIkmgyqcQU7xlWA5m3VRTHTTlMeRNvWg63KdTGDhNx5RfNSwnIKcKSVy2TL+8ZNmkt8 6UURXV+R/OlraLDIlFk7vEe/DW1Xs+UieO3cVJxZJtixGkaQQhgtEj3MjpUY8CGK/xf4 z0WQ== X-Gm-Message-State: AD7BkJLWOcBTPtfUc7ZWJFKID1aqFLU2h8EWBWJBYEk0ZNBLzzFMujY8YNmO5HOZ1hrBDS4nYRFYJVehdOri+Q== MIME-Version: 1.0 X-Received: by 10.112.137.104 with SMTP id qh8mr1700575lbb.144.1460155537415; Fri, 08 Apr 2016 15:45:37 -0700 (PDT) Received: by 10.25.22.19 with HTTP; Fri, 8 Apr 2016 15:45:37 -0700 (PDT) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C2D64869@nkgeml514-mbx.china.huawei.com> References: <5706C848.10607@alcatel-lucent.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2D64869@nkgeml514-mbx.china.huawei.com> Date: Fri, 8 Apr 2016 15:45:37 -0700 Message-ID: From: John Strassner To: "Liubing (Leo)" , John Strassner Content-Type: multipart/alternative; boundary=089e0117716d1fe7fa053000f420 Archived-At: Cc: Laurent Ciavaglia , =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= , Michael Behringer , anima Subject: Re: [Anima] Questions during ANIMA II session X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 08 Apr 2016 22:45:42 -0000 --089e0117716d1fe7fa053000f420 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Bing, > When we wrote the distribution draft, we also expected the GRASP could > not only distribute Intent, but as well as other valuable information. I think we need to be careful here. Just as Michael warned that we are starting to call everything intent (and shouldn't), I'm a bit scared that we are starting to view GRASP as a generic communications mechanism. I also think we need to differentiate between intent (as an input to the autonomic network), traffic resulting from said intent, and other traffic that gathers observations and produces results. It is not clear to me that we want to use the same network these three types of information, as their associated data structures and properties are likely **very** different. regards, John On Thu, Apr 7, 2016 at 2:11 PM, Liubing (Leo) wrote: > Hi Laurent, > > > > Thanks for the summary. You captured my point. > > I think the knowledge exchange is a valuable topic. When we wrote the > distribution draft, we also expected the GRASP could not only distribute > Intent, but as well as other valuable information. So I=E2=80=99m happy t= o see you > call it out. > > But I don=E2=80=99t know how sophisticate the knowledge exchange would be= , so it > will be great if you can sort out the specific requirements. Then let=E2= =80=99s > check whether it could be covered by the distribution function (probably > with extensions to current design). > > > > Best regards, > > Bing > > > > *From:* Laurent Ciavaglia [mailto:laurent.ciavaglia@nokia.com] > *Sent:* Thursday, April 07, 2016 5:51 PM > *To:* anima; Liubing (Leo); J=C3=A9ferson Campos Nobre; Michael Behringer > *Subject:* Questions during ANIMA II session > > > > Hello, > > Thanks for your patience re. the issues faced for the remote presentation= s. > I hope you still managed to understand our messages ;) > > There have been comments on the coordination and knowledge presentations. > Michael, J=C3=A9ferson and Bing: could you repeat your comment on the lis= t? > I caught the following: > > Q. Michael: examples of coordination, what a (minimal) policy engine coul= d > look like? start small. > > Q. Jeferson: implications on data models / measurement/monitoring... ? > > Q. Bing: use GRASP or other mechanisms. Clarify requirements for GRASP. > > Thanks, Laurent. > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > > --=20 regards, John --089e0117716d1fe7fa053000f420 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Bing,

>=C2=A0When we wrote the distribution d= raft, we also expected the GRASP could
> not only distribute Intent, but as= well as other valuable information.

I thin= k we need to be careful here. Just as Michael warned that we are starting t= o
call everything intent (and shouldn't), I'm a bit scare= d that we are starting to
view GRASP as a generic communications = mechanism.

I also think we need to differentiate b= etween intent (as an input to the autonomic
network), traffic res= ulting from said intent, and other traffic that gathers observations
<= div>and produces results. It is not clear to me that we want to use the sam= e network
these three types of information, as their associated d= ata structures and properties
are likely **very** different.

regards,
John

On Thu, Apr 7, 2016 at 2:11 PM, Liub= ing (Leo) <leo.liubing@huawei.com> wrote:

Hi = Laurent,

= =C2=A0

Tha= nks for the summary. You captured my point.

=C2= =A0I think the knowledge exchange is a valuable topic. When we wrote the di= stribution draft, we also expected the GRASP could not only distribute Intent, but as well as other valuable information. So I=E2=80=99m happy to= see you call it out.

But= I don=E2=80=99t know how sophisticate the knowledge exchange would be, so = it will be great if you can sort out the specific requirements. Then let=E2= =80=99s check whether it could be covered by the distribution function (probably w= ith extensions to current design).

= =C2=A0

Bes= t regards,

Bin= g

= =C2=A0

From: Laurent Ciavaglia [mail= to:laurent= .ciavaglia@nokia.com]
Sent: Thursday, April 07, 2016 5:51 PM
To: anima; Liubing (Leo); J=C3=A9ferson Campos Nobre; Michael Behrin= ger
Subject: Questions during ANIMA II session

=C2=A0

Hello,

Thanks for your patience re. the issues faced for the remote presentations.=
I hope you still managed to understand our messages ;)

There have been comments on the coordination and knowledge presentations. Michael, J=C3=A9ferson and Bing: could you repeat your comment on the list?=
I caught the following:

Q. Michael: examples of coordination, what a (minimal) policy engine could = look like? start small.

Q. Jeferson: implications on data models / measurement/monitoring... ?

Q. Bing: use GRASP or other mechanisms. Clarify requirements for GRASP.

Thanks, Laurent.


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




--
regards,
John
--089e0117716d1fe7fa053000f420-- From nobody Fri Apr 8 15:55:34 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1EE12D5E7 for ; Fri, 8 Apr 2016 15:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 M0qoU_spqPSF for ; Fri, 8 Apr 2016 15:55:31 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EFCA12D0E1 for ; Fri, 8 Apr 2016 15:55:30 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id g184so94013721lfb.3 for ; Fri, 08 Apr 2016 15:55:30 -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; bh=ErGyGhBbNJA3i9ZkQLQIQ4EcteKMh4Lwc+QfAlhv8PQ=; b=knmRBt7YBNbj57TD+Jrqz2CcgJHUTC5+m5s09kbK57tCNz6TA3OhtCCUHrnX3pa8oA skdKNJVD7ddIppXx+c6FK+WlTvcDAuuFXX4Ej7uR9fxzYdp5pSN3myhOCZf9yu8N5zsS ckkZGVOZEv1SiAEcs9LT6ermdEYdSWuLHV9YJkCWE50XcllVZVVzdcC/GqwPx25nZPVn oTLHCVqKAjp3pIqqdx1gyVEJklfg1YvhmN7/Phu3H+gSp4v4fTan4+NBpS/WIopArCFx kDs+mVY6NGXN8UzhfJG8faFnQeIJW441P21PPNI+1saTk+474vo4jtptVTBn6EsQ39HK C1Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ErGyGhBbNJA3i9ZkQLQIQ4EcteKMh4Lwc+QfAlhv8PQ=; b=T0o7Hl7cOXEV0v8pNARD76I6VJ+TOD80E+AZIZSFSmuz/pQg/TgmjEcFdJIn5tkffs eHjNhV86tPJTb7xGg/E1tBcJCoy5LuR+l9CP9lRXcuYYO35RF1ldxFZSxtdBU8aye8An mQtFRP3Td2D/8Ii1CuvMrkTtPn3kjQS7a8Y/jf0FdrS82mz8cU0yRMrNvKIKiamWeXP2 Q7UaD3C6LyvKdzb3iYPx/0yPp+7F2C6SfekHkxR+WWtPGtpekQyLvMmnfiAoZNh9koh7 f+Xc/kXnoLyso2HjcJp8S3jgmfZ2p4gzrg4a04hOCJivvR2+QOHdOa9ZUzFSBRlKa3sr +Hvw== X-Gm-Message-State: AD7BkJL6sEhHgAanwzRRMg7rajInYhXWGT7nDxMEEKgtU3EuLVHUa66arAWoQG2MekuDIojiu/1rfb5hWO1hvQ== MIME-Version: 1.0 X-Received: by 10.112.198.166 with SMTP id jd6mr4446573lbc.12.1460156129123; Fri, 08 Apr 2016 15:55:29 -0700 (PDT) Received: by 10.25.22.19 with HTTP; Fri, 8 Apr 2016 15:55:29 -0700 (PDT) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C2D648F6@nkgeml514-mbx.china.huawei.com> References: <5706CA26.6030203@joelhalpern.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2D648F6@nkgeml514-mbx.china.huawei.com> Date: Fri, 8 Apr 2016 15:55:29 -0700 Message-ID: From: John Strassner To: "Liubing (Leo)" , John Strassner Content-Type: multipart/alternative; boundary=001a11c2ac9064a514053001173d Archived-At: Cc: "Joel M. Halpern" , Anima WG Subject: Re: [Anima] GRASP, discovery, and roles X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 08 Apr 2016 22:55:34 -0000 --001a11c2ac9064a514053001173d Content-Type: text/plain; charset=UTF-8 Two points. First, a "role" is **just** a fancy name for a responsibility. It abstracts the entity performing the role from the role itself. This way, we can keep information about the entity separate from the functions that the entity performs, and better scale the system. That being said, I don't understand how this will work. Clearly, defining a rigid classification system is bad. I could imagine a metadata-driven system, wherein "interests" are advertised by nodes, and a semantic network, based on some formal type of logic, could be used to reason about which interests are useful for a given node. I've done this before, love researching this, but this is NOT easy. regards, John On Thu, Apr 7, 2016 at 2:48 PM, Liubing (Leo) wrote: > Hi Joel, > > > -----Original Message----- > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Joel M. Halpern > > Sent: Thursday, April 07, 2016 5:59 PM > > To: Anima WG > > Subject: [Anima] GRASP, discovery, and roles > > > > I appear to have missed something in the descriptions. > > > > On the one hand, it is very clear that ASAs need to discover certain > kinds of > > special entities. Registrars are one example. Prefix delegators or > usage > > coordinators are others. > > > > On the other hand, when I look at the GRASP discovery mechanisms, what I > see > > is text that ASAs discover peer ASAs who support a given objective. > > > > So how does this work if what I (as an ASA) need to discover is a > resource > > coordinator. That is not an objective I offer. So how do I extablish > > communication with the right entity/ > > [Bing] My understanding: we could discover "resource coordination" as an > objective. If some entity is right the "coordinator", then it will response > to that discovery. GRASP discovery only cares about whether some entities > could provide "resource coordination" function, and doesn't care about the > entity's role. > > In my mind, "objective" is more regarding to function; and "role" more > regarding to the device's character. So, they are two different dimensions. > But the "objective" might have a finer-granularity than "Role", which > means, one entity of a specific Role, might support multiple objectives. > > Brian: please shout out if I'm not sync with you:) > > Best regards, > Bing > > > Or am I completely misreading the specs? > > > > Yours, > > Joel > > > > _______________________________________________ > > 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 > -- regards, John --001a11c2ac9064a514053001173d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Two points.

First, a "r= ole" is **just** a fancy name for a responsibility. It abstracts
=
the entity performing the role from the role itself. This way, we can<= /div>
keep information about the entity separate from the functions tha= t the
entity performs, and better scale the system.
That being said, I don't understand how this will work. Cle= arly, defining
a rigid classification system is bad. I could imag= ine a metadata-driven
system, wherein "interests" are a= dvertised by nodes, and a semantic
network, based on some formal = type of logic, could be used to reason
about which interests are = useful for a given node.

I've done this before= , love researching this, but=C2=A0this is NOT easy.


regards,
John

On Thu, Apr 7, 2016 at 2:48 PM, Liubing = (Leo) <leo.liubing@huawei.com> wrote:
Hi Joel,

> -----Original Message-----
> From: Anima [mailto:anima-bo= unces@ietf.org] On Behalf Of Joel M. Halpern
> Sent: Thursday, April 07, 2016 5:59 PM
> To: Anima WG
> Subject: [Anima] GRASP, discovery, and roles
>
> I appear to have missed something in the descriptions.
>
> On the one hand, it is very clear that ASAs need to discover certain k= inds of
> special entities.=C2=A0 Registrars are one example.=C2=A0 Prefix deleg= ators or usage
> coordinators are others.
>
> On the other hand, when I look at the GRASP discovery mechanisms, what= I see
> is text that ASAs discover peer ASAs who support a given objective. >
> So how does this work if what I (as an ASA) need to discover is a reso= urce
> coordinator.=C2=A0 That is not an objective I offer.=C2=A0 So how do I= extablish
> communication with the right entity/

[Bing] My understanding: we could discover "resource coordination"= ; as an objective. If some entity is right the "coordinator", the= n it will response to that discovery. GRASP discovery only cares about whet= her some entities could provide "resource coordination" function,= and doesn't care about the entity's role.

In my mind, "objective" is more regarding to function; and "= role" more regarding to the device's character. So, they are two d= ifferent dimensions. But the "objective" might have a finer-granu= larity than "Role", which means, one entity of a specific Role, m= ight support multiple objectives.

Brian: please shout out if I'm not sync with you:)

Best regards,
Bing

> Or am I completely misreading the specs?
>
> Yours,
> Joel
>
> _______________________________________________
> 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



--
regards,
John
--001a11c2ac9064a514053001173d-- From nobody Fri Apr 8 16:45:01 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC26D12D52F for ; Fri, 8 Apr 2016 16:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 AuO0CEKbHW4g for ; Fri, 8 Apr 2016 16:44:57 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4347412D52C for ; Fri, 8 Apr 2016 16:44:57 -0700 (PDT) Received: by mail-pa0-x22f.google.com with SMTP id td3so83031023pab.2 for ; Fri, 08 Apr 2016 16:44:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=YgMLZwjjuZOyU8fb8sKiQpA3+v1VqGq0nyIbD/IXeXw=; b=s3HFdW4OvlvthcN1BrxvtxtIqvEBveP90h2uddE0vPbAIxXh4+35jLaGX+uaEDf6tB ocbThHKNusRDV/TinHWc8di3VJthfFqMlNxSlIdj4Rtk27+QxMU3c5Y1w5DH19fde3DX GXC+tYTLPv6wuHieknoLL+u5tuvXnhDyYoHNSS1LK3Fcd11IH8Jx+54z+ksNCnpPai/M rOm7bB4u6AAfS9G0wqX5+drtgFnm0RAtiJrPxuvk8ldI2YaSv5J6ZBzDmOL0RFipkcgZ pS4Wd3rUJuB5OBiGUAuUpMcMwUXJZgOIXV88ST1WDQyC4o8KlLgASeyZ0kQKKDOImhi6 rPCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=YgMLZwjjuZOyU8fb8sKiQpA3+v1VqGq0nyIbD/IXeXw=; b=HZzYfTkw+TlZbpgnhYli+siGGVxjXgcVXB2cpoQA1IXq5gSeT68xCEZzpan1p8ycMn zQYaDkh9liNMcrCj/Bg4JsQDKxUQPRzBaFC8Yf+upePwheanGU45Er3ow9z+gaSAykZN UQZTM28q9p22D+IAzf6J6IZRJGDupRxGChFp0hW9z4/Q2kZ/u407SOFtQWh3mEOi8W4K DYNMSOtn6BGVlImnIvCWPiljHJeM6pitfMk7U84dqQG920OX564xjWcfQWHKXcM4BRiY wBis2zkVbEqbEQNOCiCCC9IDXN+MGnmpehn2Lvt9puWZkRneh2xWiayJ/ArsyA0g1CF7 +e8g== X-Gm-Message-State: AD7BkJKnblF1XZ2mTBssYWFhqdS32iqO2K5BbfzK+EksJWEB3sBsjt0oT0vJjCdCGMcuRg== X-Received: by 10.66.150.163 with SMTP id uj3mr16163991pab.23.1460159096840; Fri, 08 Apr 2016 16:44:56 -0700 (PDT) Received: from ?IPv6:2406:e007:7c81:1:28cc:dc4c:9703:6781? ([2406:e007:7c81:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id r88sm21001268pfi.9.2016.04.08.16.44.53 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Apr 2016 16:44:55 -0700 (PDT) To: John Strassner , "Liubing (Leo)" References: <5706CA26.6030203@joelhalpern.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2D648F6@nkgeml514-mbx.china.huawei.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5708427F.9050306@gmail.com> Date: Sat, 9 Apr 2016 11:45:03 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "Joel M. Halpern" , Anima WG Subject: Re: [Anima] GRASP, discovery, and roles X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 08 Apr 2016 23:44:59 -0000 > this is NOT easy Indeed. That's why I think this discussion comes later... Regards Brian On 09/04/2016 10:55, John Strassner wrote: > Two points. > > First, a "role" is **just** a fancy name for a responsibility. It abstracts > the entity performing the role from the role itself. This way, we can > keep information about the entity separate from the functions that the > entity performs, and better scale the system. > > That being said, I don't understand how this will work. Clearly, defining > a rigid classification system is bad. I could imagine a metadata-driven > system, wherein "interests" are advertised by nodes, and a semantic > network, based on some formal type of logic, could be used to reason > about which interests are useful for a given node. > > I've done this before, love researching this, but this is NOT easy. > > > regards, > John > > On Thu, Apr 7, 2016 at 2:48 PM, Liubing (Leo) > wrote: > >> Hi Joel, >> >>> -----Original Message----- >>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Joel M. Halpern >>> Sent: Thursday, April 07, 2016 5:59 PM >>> To: Anima WG >>> Subject: [Anima] GRASP, discovery, and roles >>> >>> I appear to have missed something in the descriptions. >>> >>> On the one hand, it is very clear that ASAs need to discover certain >> kinds of >>> special entities. Registrars are one example. Prefix delegators or >> usage >>> coordinators are others. >>> >>> On the other hand, when I look at the GRASP discovery mechanisms, what I >> see >>> is text that ASAs discover peer ASAs who support a given objective. >>> >>> So how does this work if what I (as an ASA) need to discover is a >> resource >>> coordinator. That is not an objective I offer. So how do I extablish >>> communication with the right entity/ >> >> [Bing] My understanding: we could discover "resource coordination" as an >> objective. If some entity is right the "coordinator", then it will response >> to that discovery. GRASP discovery only cares about whether some entities >> could provide "resource coordination" function, and doesn't care about the >> entity's role. >> >> In my mind, "objective" is more regarding to function; and "role" more >> regarding to the device's character. So, they are two different dimensions. >> But the "objective" might have a finer-granularity than "Role", which >> means, one entity of a specific Role, might support multiple objectives. >> >> Brian: please shout out if I'm not sync with you:) >> >> Best regards, >> Bing >> >>> Or am I completely misreading the specs? >>> >>> Yours, >>> Joel >>> >>> _______________________________________________ >>> 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 >> > > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Fri Apr 8 17:16:06 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5683D12D0BD for ; Fri, 8 Apr 2016 17:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Be1S6Lq-L4UQ for ; Fri, 8 Apr 2016 17:16:02 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5195812D0B1 for ; Fri, 8 Apr 2016 17:16:02 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id e190so93509547lfe.0 for ; Fri, 08 Apr 2016 17:16:02 -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; bh=UI9s66LbRL2SdUGp/qWTL6nrWI5oEv8x9jqSW3HproY=; b=gj1jdYNezMCnH1AYgfBhfvqG3+jg/3WK7hrC+zCPXdMLg1AOBVzAbgiRa4QjQ6S3FP 1sfRm6idxt3nu5pj9R0YDRZIaIys9DXHjvWiUCFBJfTaZwCDOC7eQCW0p3fcnrfGOkxa zwuxblso4A3sTlJLNcPVuDVdbj47qTeHZeX4oKPFrzTOSqBcLQ69wsjNxM+eBDZTwsPW 0kg3fywJyWVOVtOeBjf/vyXuUXlC8kONXF4DD/wltg6Btokj12yEXHV07Y+FtL833sSA nCmhXjaxE77GG4t+YXQGkPZVPeqs2AblFdstJJg9sjjJZ2jEE+63PI2ZvYf7THmKkBJZ SlmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=UI9s66LbRL2SdUGp/qWTL6nrWI5oEv8x9jqSW3HproY=; b=EOG21wEzGWfkPgR27IEryOa/LR23EJyJBHgnsMqboG2tyDraBmoEPfiRn2fhjOIvf4 KLhL2zpWvM2s6/jyvG0d5ntZHTujg8Yr9zxDZiOzOSG5nqTDbbmsKm7NMFX/xPjNvuFf F/KKT/+TRiq1/FiSiufSEQuQkiTc+7OatstJGYeRLpUye3+Mdu1foy7zP/oKtIgn8a10 wIt1sj4kQWId11ROvmRIhYgNucwoW6Pm3Z11yhjanUe9NybiLkTiEQIIrPYqGIQo96nf N9jqKAWQx6NFh3fFjcePsz6GW5/v+huzpQJvsWZWwaeNI/xxs12t1czZj8kATVBKdMWv LZug== X-Gm-Message-State: AD7BkJK5UXUdEkzUtnEOHqLL+fLN4nVfzPTVUTsy3Dcp4KHR4ZIVk0dW9nKzCxfORk1nrYuZxOz8uN8MLFNZ4g== MIME-Version: 1.0 X-Received: by 10.112.147.101 with SMTP id tj5mr3757778lbb.119.1460160960458; Fri, 08 Apr 2016 17:16:00 -0700 (PDT) Received: by 10.25.22.19 with HTTP; Fri, 8 Apr 2016 17:16:00 -0700 (PDT) In-Reply-To: <5708427F.9050306@gmail.com> References: <5706CA26.6030203@joelhalpern.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2D648F6@nkgeml514-mbx.china.huawei.com> <5708427F.9050306@gmail.com> Date: Fri, 8 Apr 2016 17:16:00 -0700 Message-ID: From: John Strassner To: Brian E Carpenter Content-Type: multipart/alternative; boundary=047d7b3a8bd25cfbe405300237c6 Archived-At: Cc: "Joel M. Halpern" , Anima WG , "Liubing \(Leo\)" Subject: Re: [Anima] GRASP, discovery, and roles X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 09 Apr 2016 00:16:05 -0000 --047d7b3a8bd25cfbe405300237c6 Content-Type: text/plain; charset=UTF-8 Fair enough; I just want to know if my guess at how this operates is correct. :-) regards, John On Fri, Apr 8, 2016 at 4:45 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > this is NOT easy > > Indeed. That's why I think this discussion comes later... > > Regards > Brian > > On 09/04/2016 10:55, John Strassner wrote: > > Two points. > > > > First, a "role" is **just** a fancy name for a responsibility. It > abstracts > > the entity performing the role from the role itself. This way, we can > > keep information about the entity separate from the functions that the > > entity performs, and better scale the system. > > > > That being said, I don't understand how this will work. Clearly, defining > > a rigid classification system is bad. I could imagine a metadata-driven > > system, wherein "interests" are advertised by nodes, and a semantic > > network, based on some formal type of logic, could be used to reason > > about which interests are useful for a given node. > > > > I've done this before, love researching this, but this is NOT easy. > > > > > > regards, > > John > > > > On Thu, Apr 7, 2016 at 2:48 PM, Liubing (Leo) > > wrote: > > > >> Hi Joel, > >> > >>> -----Original Message----- > >>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Joel M. > Halpern > >>> Sent: Thursday, April 07, 2016 5:59 PM > >>> To: Anima WG > >>> Subject: [Anima] GRASP, discovery, and roles > >>> > >>> I appear to have missed something in the descriptions. > >>> > >>> On the one hand, it is very clear that ASAs need to discover certain > >> kinds of > >>> special entities. Registrars are one example. Prefix delegators or > >> usage > >>> coordinators are others. > >>> > >>> On the other hand, when I look at the GRASP discovery mechanisms, what > I > >> see > >>> is text that ASAs discover peer ASAs who support a given objective. > >>> > >>> So how does this work if what I (as an ASA) need to discover is a > >> resource > >>> coordinator. That is not an objective I offer. So how do I extablish > >>> communication with the right entity/ > >> > >> [Bing] My understanding: we could discover "resource coordination" as an > >> objective. If some entity is right the "coordinator", then it will > response > >> to that discovery. GRASP discovery only cares about whether some > entities > >> could provide "resource coordination" function, and doesn't care about > the > >> entity's role. > >> > >> In my mind, "objective" is more regarding to function; and "role" more > >> regarding to the device's character. So, they are two different > dimensions. > >> But the "objective" might have a finer-granularity than "Role", which > >> means, one entity of a specific Role, might support multiple objectives. > >> > >> Brian: please shout out if I'm not sync with you:) > >> > >> Best regards, > >> Bing > >> > >>> Or am I completely misreading the specs? > >>> > >>> Yours, > >>> Joel > >>> > >>> _______________________________________________ > >>> 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 > >> > > > > > > > > > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > > -- regards, John --047d7b3a8bd25cfbe405300237c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Fair enough; I just want to know if my guess at how t= his operates is correct. :-)

regards,
Jo= hn

On = Fri, Apr 8, 2016 at 4:45 PM, Brian E Carpenter <brian.e.carpente= r@gmail.com> wrote:
> th= is is NOT easy

Indeed. That's why I think this discussion comes later...

Regards
=C2=A0 =C2=A0Brian

On 09/04/2016 10:55, John Strassner wrote:
> Two points.
>
> First, a "role" is **just** a fancy name for a responsibilit= y. It abstracts
> the entity performing the role from the role itself. This way, we can<= br> > keep information about the entity separate from the functions that the=
> entity performs, and better scale the system.
>
> That being said, I don't understand how this will work. Clearly, d= efining
> a rigid classification system is bad. I could imagine a metadata-drive= n
> system, wherein "interests" are advertised by nodes, and a s= emantic
> network, based on some formal type of logic, could be used to reason > about which interests are useful for a given node.
>
> I've done this before, love researching this, but this is NOT easy= .
>
>
> regards,
> John
>
> On Thu, Apr 7, 2016 at 2:48 PM, Liubing (Leo) <leo.liubing@huawei.com>
> wrote:
>
>> Hi Joel,
>>
>>> -----Original Message-----
>>> From: Anima [mailto:= anima-bounces@ietf.org] On Behalf Of Joel M. Halpern
>>> Sent: Thursday, April 07, 2016 5:59 PM
>>> To: Anima WG
>>> Subject: [Anima] GRASP, discovery, and roles
>>>
>>> I appear to have missed something in the descriptions.
>>>
>>> On the one hand, it is very clear that ASAs need to discover c= ertain
>> kinds of
>>> special entities.=C2=A0 Registrars are one example.=C2=A0 Pref= ix delegators or
>> usage
>>> coordinators are others.
>>>
>>> On the other hand, when I look at the GRASP discovery mechanis= ms, what I
>> see
>>> is text that ASAs discover peer ASAs who support a given objec= tive.
>>>
>>> So how does this work if what I (as an ASA) need to discover i= s a
>> resource
>>> coordinator.=C2=A0 That is not an objective I offer.=C2=A0 So = how do I extablish
>>> communication with the right entity/
>>
>> [Bing] My understanding: we could discover "resource coordina= tion" as an
>> objective. If some entity is right the "coordinator", th= en it will response
>> to that discovery. GRASP discovery only cares about whether some e= ntities
>> could provide "resource coordination" function, and does= n't care about the
>> entity's role.
>>
>> In my mind, "objective" is more regarding to function; a= nd "role" more
>> regarding to the device's character. So, they are two differen= t dimensions.
>> But the "objective" might have a finer-granularity than = "Role", which
>> means, one entity of a specific Role, might support multiple objec= tives.
>>
>> Brian: please shout out if I'm not sync with you:)
>>
>> Best regards,
>> Bing
>>
>>> Or am I completely misreading the specs?
>>>
>>> Yours,
>>> Joel
>>>
>>> _______________________________________________
>>> Anima mailing list
>>> Anima@ietf.org
>>> https://www.ietf.org/mailman/listinfo/anima<= /a>
>>
>> _______________________________________________
>> Anima mailing list
>> Anima@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima<= br> >>
>
>
>
>
>
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
>



--
regards,
John
--047d7b3a8bd25cfbe405300237c6-- From nobody Fri Apr 8 17:58:36 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039FC12D533 for ; Fri, 8 Apr 2016 17:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 zOkmcp1FbITL for ; Fri, 8 Apr 2016 17:58:32 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D93F312D173 for ; Fri, 8 Apr 2016 17:58:32 -0700 (PDT) Received: by mail-pa0-x22a.google.com with SMTP id bx7so67627470pad.3 for ; Fri, 08 Apr 2016 17:58:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ykO6at1LNfHj4AG+MHewD1geCOPRFZ+Ja1eind7eC8U=; b=aRMWuuNgGBeAx5jL+l6OsYDaOE5elmdHt8o0ofttouA6zXvP9e4xlEXst/Q+O0s1JA wc1GwxF4Rs0LOJI3dMiNnDHhaHe4qO3la0L1YQRqKlt0Zm9BziIHTD0X9SnB1lZwUSbI x7OB/MrICQ1nP9DbxSFQmJ95vzhW0NyAHPy6O2FcRoGxAvUtiDLrnds0EZ3ZEl5XAJnH lrQtPJOtS3vwVtnq0ssnJgEtz/HTjqr5uvoZNupBk8HL3ZPwaeRoNuSrlrNzl/HLBvMf 70mQuuv08jxCWgIhWa1bE/FPlGjHdqTnR5M+WYdZeMi9RvoUZzqLsrcS9s7/pk051M44 qHyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=ykO6at1LNfHj4AG+MHewD1geCOPRFZ+Ja1eind7eC8U=; b=DwKzzLT8szRghOkT/iA/4k02hnjPTNkFqeFd5MB0VoOADNbE5QpqwNzNeSvzi744xt fIT8in7UO84xXFUuq5k4rdMmi0om12kZBICGg/uIwbLw7QLiG8fTNT/yu6KnKjwo0xlF nHTL7FkeJmWHSUEvggpCUj7jg/GDRbTjbzy7ZSvno/xd80eX1DcRr8sq3yvZRt+O8S71 buuyUUaX4m/LClM3DLdoEvFmga4nV3m42lSlbPYdlktz/sujfhRgh4yA/tULgydUlomB UtY/IFQbzhzYPA2VvBjD2clsqIC0VDwrI9H7F8aeDA4D6rfeYBhhke7uYr3YgRasu4wx fwyg== X-Gm-Message-State: AD7BkJJQR+M5dPrmEumuqkul/qFKfYJ0tllbiRx4bnby078UysmBdoTVde+IcnBGBo5alg== X-Received: by 10.67.21.231 with SMTP id hn7mr16605313pad.150.1460163512463; Fri, 08 Apr 2016 17:58:32 -0700 (PDT) Received: from ?IPv6:2406:e007:7c81:1:28cc:dc4c:9703:6781? ([2406:e007:7c81:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id d12sm21108760pfj.85.2016.04.08.17.58.28 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Apr 2016 17:58:31 -0700 (PDT) To: John Strassner , "Liubing (Leo)" References: <5706C848.10607@alcatel-lucent.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2D64869@nkgeml514-mbx.china.huawei.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <570853BD.8090900@gmail.com> Date: Sat, 9 Apr 2016 12:58:37 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Laurent Ciavaglia , =?UTF-8?Q?J=c3=a9ferson_Campos_Nobre?= , anima , Michael Behringer Subject: Re: [Anima] Questions during ANIMA II session X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 09 Apr 2016 00:58:35 -0000 > I'm a bit scared that we are > starting to > view GRASP as a generic communications mechanism. Agreed, but as a matter of principle, I don't want GRASP to be restrictiv= e, since it will be present in every autonomic node. But we've always said that ASAs can use any communication method they want in addition, as long as they do whatever we specify as the minimum with GRASP. What I have noticed, however, is that because of the way we've defined GRASP objectives, they do actually function as a generic PDU when used in a GRASP negotiation session. That wasn't a goal, but it's emerged as a feature. Regards Brian On 09/04/2016 10:45, John Strassner wrote: > Hi Bing, >=20 >> When we wrote the distribution draft, we also expected the GRASP could= >> not only distribute Intent, but as well as other valuable information.= >=20 > I think we need to be careful here. Just as Michael warned that we are > starting to > call everything intent (and shouldn't), I'm a bit scared that we are > starting to > view GRASP as a generic communications mechanism. >=20 > I also think we need to differentiate between intent (as an input to th= e > autonomic > network), traffic resulting from said intent, and other traffic that > gathers observations > and produces results. It is not clear to me that we want to use the sam= e > network > these three types of information, as their associated data structures a= nd > properties > are likely **very** different. >=20 > regards, > John >=20 > On Thu, Apr 7, 2016 at 2:11 PM, Liubing (Leo) > wrote: >=20 >> Hi Laurent, >> >> >> >> Thanks for the summary. You captured my point. >> >> I think the knowledge exchange is a valuable topic. When we wrote the= >> distribution draft, we also expected the GRASP could not only distribu= te >> Intent, but as well as other valuable information. So I=E2=80=99m happ= y to see you >> call it out. >> >> But I don=E2=80=99t know how sophisticate the knowledge exchange would= be, so it >> will be great if you can sort out the specific requirements. Then let=E2= =80=99s >> check whether it could be covered by the distribution function (probab= ly >> with extensions to current design). >> >> >> >> Best regards, >> >> Bing >> >> >> >> *From:* Laurent Ciavaglia [mailto:laurent.ciavaglia@nokia.com] >> *Sent:* Thursday, April 07, 2016 5:51 PM >> *To:* anima; Liubing (Leo); J=C3=A9ferson Campos Nobre; Michael Behrin= ger >> *Subject:* Questions during ANIMA II session >> >> >> >> Hello, >> >> Thanks for your patience re. the issues faced for the remote presentat= ions. >> I hope you still managed to understand our messages ;) >> >> There have been comments on the coordination and knowledge presentatio= ns. >> Michael, J=C3=A9ferson and Bing: could you repeat your comment on the = list? >> I caught the following: >> >> Q. Michael: examples of coordination, what a (minimal) policy engine c= ould >> look like? start small. >> >> Q. Jeferson: implications on data models / measurement/monitoring... ?= >> >> Q. Bing: use GRASP or other mechanisms. Clarify requirements for GRASP= =2E >> >> Thanks, Laurent. >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> >> >=20 >=20 >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Fri Apr 8 19:50:45 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B0F12D54D for ; Fri, 8 Apr 2016 19:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 dL-wstA0JtFr for ; Fri, 8 Apr 2016 19:50:39 -0700 (PDT) Received: from mail-io0-f180.google.com (mail-io0-f180.google.com [209.85.223.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CAD812D0A6 for ; Fri, 8 Apr 2016 19:50:39 -0700 (PDT) Received: by mail-io0-f180.google.com with SMTP id o126so130082877iod.0 for ; Fri, 08 Apr 2016 19:50:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hCLF7fjaH6pY9jti2cg2KzPUKAONlXwV2o33+J+/QdU=; b=FCgr6rSZ86m4+eFU3NiPTgjbTAskDu5lqi/dJgBiJzMM3LNNLKIVBsHb5l302kAYTB Oli8T9hC0kUrHKaOJ63eXpNbNRJAuDIZAWiM7qd81xiJHU4X5g6EeH02D3uVE2wltoT7 umYt4o1YJpc2R7nJcroaXH3nKtFaqnGEi1G/jy9kU48pmJ/bnbAyd/TohEW+mbjwp8xB rrWsHsKqQOOYkv1/HvQEX5F4B7V0WFI+/AaCr6gHUq9V51YK+LrwhWLO6mJrSz0pPYkd e8kAJU2Rf+ZR/buABM5xQ3wnEuR5hQeGhBBbwz0tv+gMH0k5f9fQ0ikgRkxPNY6fq9Mv CbQg== X-Gm-Message-State: AD7BkJINyyrTByuZjfQ7LBf6vIDNsJA+gR+nKxJDT55TTPAcWeFzYe7al9JUY9S4+OMqpInoZchFuJOQe3Sx1g== X-Received: by 10.107.10.144 with SMTP id 16mr13827909iok.48.1460170238948; Fri, 08 Apr 2016 19:50:38 -0700 (PDT) MIME-Version: 1.0 References: <23644a1e52c44a8b900100f1a120a5f6@XCH-RCD-006.cisco.com> In-Reply-To: <23644a1e52c44a8b900100f1a120a5f6@XCH-RCD-006.cisco.com> From: =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= Date: Sat, 09 Apr 2016 02:50:28 +0000 Message-ID: To: "Michael Behringer (mbehring)" , "Ciavaglia, Laurent (Nokia - FR)" Content-Type: multipart/alternative; boundary=001a113f940e677e340530046064 Archived-At: Cc: anima Subject: Re: [Anima] Comment to your presentation on draft-ciavaglia-anima-knowledge-00 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 09 Apr 2016 02:50:42 -0000 --001a113f940e677e340530046064 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Laurent. Just to add up the question I was asking when you became offline... It is more a clarification: are you proposing to use different data models/protocols in ANIMA than the ones used in other WGs? Or you are describing the requirements for the data models/protocols to be used in ANIMA? I got confused. Thanks. J=C3=A9ferson Em qui, 7 de abr de 2016 =C3=A0s 17:22, Michael Behringer (mbehring) < mbehring@cisco.com> escreveu: > Laurent, > > Since we couldn't finish the discussion online, here my comment on the > list: > > You won't be surprised to hear that I'm asking also here for the smallest= , > simplest possible first step. To get us all on the same page, and > understand the requirement better. > > So I was thinking, we actually have a good use case for this: > draft-ietf-anima-prefix-management could probably do with a small knowled= ge > plane; in its simplest case, an operator wants to know the current status > of assignments across the entire network; before a node requests more > address space from another node, it could ask a knowledge plane where the > biggest free pools are. > > Disassembling this a bit: questions to the knowledge plane could be: > - "which node has the biggest free address pool?" > - "what's the average / max / min usage of local pools across the network= ?" > - "how much address space is still available?" (not quite the same as > above, I think) > - etc. > > Would that make a nice use case to understand the knowledge plane better? > > Michael > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > --001a113f940e677e340530046064 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Laurent.
Just to add up the question I was asking w= hen you became offline...
It is more a clarification: are you pro= posing to use different data models/protocols in ANIMA than the ones used i= n other WGs? Or you are describing the requirements for the data models/pro= tocols to be used in ANIMA? I got confused.
Thanks.
J= =C3=A9ferson

Em q= ui, 7 de abr de 2016 =C3=A0s 17:22, Michael Behringer (mbehring) <mbehring@cisco.com> escreveu:
Laurent,

Since we couldn't finish the discussion online, here my comment on the = list:

You won't be surprised to hear that I'm asking also here for the sm= allest, simplest possible first step. To get us all on the same page, and u= nderstand the requirement better.

So I was thinking, we actually have a good use case for this: draft-ietf-an= ima-prefix-management could probably do with a small knowledge plane; in it= s simplest case, an operator wants to know the current status of assignment= s across the entire network; before a node requests more address space from= another node, it could ask a knowledge plane where the biggest free pools = are.

Disassembling this a bit: questions to the knowledge plane could be:
- "which node has the biggest free address pool?"
- "what's the average / max / min usage of local pools across the = network?"
- "how much address space is still available?" (not quite the sam= e as above, I think)
- etc.

Would that make a nice use case to understand the knowledge plane better?
Michael

_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
--001a113f940e677e340530046064-- From nobody Mon Apr 11 21:58:36 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B034612E341 for ; Mon, 11 Apr 2016 21:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 i1X_5S5BiADl for ; Mon, 11 Apr 2016 21:58:32 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97B0912E340 for ; Mon, 11 Apr 2016 21:58:32 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id n1so6334310pfn.2 for ; Mon, 11 Apr 2016 21:58:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=XyHONfJYsYnzp9W0kyJ1agGOlvDYBSw+JbCY8lgTqQA=; b=EXauzwq5j07fv6vFnXX5baG6apYsLen0QnX3vRZvvgR4lfB+xPmKMAfGsV2NH2KRTI 2G9O8PYKRque5rY/3qLE2TRDzma8wURqjcv5FPBoQKwoOdw4k0MUBJDw1NfUpMhiSPH5 38V8vQb/HkBUaMlAT5+hW/4QSjbArX/ZwxOzocifGeS3l/7QRku8vVfixm4Dr+kJd0h4 JYAV7p77JbBE3PdM93Zr8lH8qPOKut5VpWbWlKVVMefjIjDyxnxj/zG7lf9P31PZYNJy XUhPz9RA7ERM8dyWzco46xkGNL6RASagOFe6BNelY6Pun4mpkZEyyqo30+FhWbu+bVkE +Dpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=XyHONfJYsYnzp9W0kyJ1agGOlvDYBSw+JbCY8lgTqQA=; b=WGlunAcHwcVxlXxPefkxV1ezDwQB7zLfxo8vaOVHvSgO9E8SAMWlsi6+VG8HsgmDCY vogMwmcNfajoN4jQVVxZMg/jTFGhoBTfETCdUDL83QCVTI/XoImLGYettcKaF/ayovw/ xwMgWtVy+6esWb9m4rpe+dlJTJxd6WgfUt/TryK8lTQW3J2opEo/MZZDbCRHlJRqj/iY NRorxD/D5luG8gzimlVGmvKg5u+k4nECBkE5WGVCcHiUr+JFc97LAuHnEzrKpI2XnB9C qIn58jCXSJs7mhm8zSclso6af19c5qvMoFfeFrjF/4qN4tEw05WkT5HNpmUBevlKtmfN q8Dw== X-Gm-Message-State: AOPr4FXTkIJQfhLP+oGNEshx5F8DqjSFm3mh8sSimgpsm0ZKyGRTXJej1mw80mJ78TWFiw== X-Received: by 10.98.42.207 with SMTP id q198mr1795045pfq.103.1460437112234; Mon, 11 Apr 2016 21:58:32 -0700 (PDT) Received: from ?IPv6:2406:e007:4a67:1:28cc:dc4c:9703:6781? ([2406:e007:4a67:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id yj1sm39849399pac.16.2016.04.11.21.58.28 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Apr 2016 21:58:30 -0700 (PDT) To: "Michael Behringer (mbehring)" , anima References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <570C8076.8030308@gmail.com> Date: Tue, 12 Apr 2016 16:58:30 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Intent Discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 12 Apr 2016 04:58:34 -0000 On 07/04/2016 23:14, Michael Behringer (mbehring) wrote: ... > Fragmenting Intent > - however we express Intent, we don't want to require that Intent MUST be > able to be de-composed into its atomic bits with a fixed size limit > --> we must not require that atomic bit MUST fit into a packet. I understand that, but we should note that this significantly complicates flooding of Intent to all nodes. ... > Flooded? > - good enough for now to flood. The only straightforward flooding mechanism we have now *does* assume that the atomic bits fit in a packet. > BUT: as long as we have a more granular way to "upgrade to" later. Actually the granular mechanism is there too but *doesn't* assume that the atomic bits fit in a packet. I think we need to think about draft-liu-anima-grasp-distribution as a potential requirements document in this area. Brian From nobody Tue Apr 12 00:44:04 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B98012E4A4 for ; Tue, 12 Apr 2016 00:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 fkWngRLHhRJw for ; Tue, 12 Apr 2016 00:44:01 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1418912E3F1 for ; Tue, 12 Apr 2016 00:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2410; q=dns/txt; s=iport; t=1460447041; x=1461656641; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=LCUm2RMczJbBtKrJMcfQEZ3cq/W8mbrk6gt9yf9Hd3E=; b=FV5PpSZ0Py/45YmG4MOYKckN3JHKkayp+GLCnIfKRFlnqvfzrdMVTsee T+GV/VGj0lOUzk6yx9EeJ2HcCc2jyCLxeasN0vpU1PXtG2JytTV+nNo0n G4wwm2orqjatmdSxTCmlIpAl6gaJZPetTAstSPJodJqFgupe66vVTcYOj o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQBapgxX/4sNJK1dgzeBUAavBYtYA?= =?us-ascii?q?Q2BcoYNAhyBETgUAQEBAQEBAWUnhEEBAQEEIwQNUQQCAQgRBAEBAQICIwMCAgI?= =?us-ascii?q?fERQBCAgBAQQBCQkIiAoDEq4PjQINhR8BAQEBAQEBAQEBAQEBAQEBAQEBAQEVf?= =?us-ascii?q?IUlhEuCQYFZO4JqglYFknaEYTEBiGmDLoFujxeHS4dbAR4BAUKDZ2wBiEg+fgE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.24,472,1454976000"; d="scan'208";a="90779577" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Apr 2016 07:44:00 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u3C7i0xR015045 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Apr 2016 07:44:00 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 12 Apr 2016 02:43:59 -0500 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.009; Tue, 12 Apr 2016 02:43:59 -0500 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , anima Thread-Topic: [Anima] Intent Discussion Thread-Index: AdGQvf+xeVbNHCZJTzaTRxDR/JZAHgD4934AAATXaxA= Date: Tue, 12 Apr 2016 07:43:59 +0000 Message-ID: References: <570C8076.8030308@gmail.com> In-Reply-To: <570C8076.8030308@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.238.142] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Intent Discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 12 Apr 2016 07:44:02 -0000 SW4gbXkgbWluZCwgd2UnZCB1c2UgR1JBU1AgdG8gc2lnbmFsIGFtb25nc3Qgbm9kZXMganVzdCB0 aGUgY3VycmVudCB2ZXJzaW9uIG9mIEludGVudCAob3IgaWYgaXQgY29tZXMgcGFja2FnZWQgZm9y IGV4YW1wbGUgZm9yIGEgc2V0IG9mIGF1dG9ub21pYyBmdW5jdGlvbnMsIHRoYXQgSW50ZW50IHNl dCkuIA0KDQpUaGVuLCB1c2UgVEZUUCAoZm9yIGV4YW1wbGUpIHRvIGFjdHVhbGx5IHRyYW5zbWl0 IHRoZSBmaWxlLiBUaGlzIHdheSB3ZSBnZXQgcmVsaWFiaWxpdHksIHJlLXRyYW5zbWlzc2lvbiwg ZnJhZ21lbnRpbmcsIGV0YywgYWxsIGZvciBmcmVlLCBhbmQgZG9uJ3QgaGF2ZSB0byB3b3JyeSBh Ym91dCB0aGF0IGluIEdSQVNQLiANCg0KTm90aW5nIHRoYXQsIGlmIEludGVudCBpcyByZWFsbHkg cmVsYXRpdmVseSBsb25nIGxpdmVkLCB0aGUgc2lnbmFsbGluZyBoYXBwZW5zIGFsbCB0aGUgdGlt ZSwgYWN0dWFsIHRyYW5zZmVyIG9ubHkgaWYgdGhlcmUgaXMgYSBuZXcgdmVyc2lvbi4gVG8gbWU6 IE9yZGVyIG9mIG9uY2UgYSBtb250aCEgDQoNCk1pY2hhZWwNCg0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IEJyaWFuIEUgQ2FycGVudGVyIFttYWlsdG86YnJpYW4uZS5j YXJwZW50ZXJAZ21haWwuY29tXQ0KPiBTZW50OiAxMiBBcHJpbCAyMDE2IDA2OjU5DQo+IFRvOiBN aWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpIDxtYmVocmluZ0BjaXNjby5jb20+OyBhbmltYQ0K PiA8YW5pbWFAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbQW5pbWFdIEludGVudCBEaXNjdXNz aW9uDQo+IA0KPiBPbiAwNy8wNC8yMDE2IDIzOjE0LCBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJp bmcpIHdyb3RlOg0KPiAuLi4NCj4gPiBGcmFnbWVudGluZyBJbnRlbnQNCj4gPiAtIGhvd2V2ZXIg d2UgZXhwcmVzcyBJbnRlbnQsIHdlIGRvbid0IHdhbnQgdG8gcmVxdWlyZSB0aGF0IEludGVudCBN VVNUDQo+IGJlDQo+ID4gICBhYmxlIHRvIGJlIGRlLWNvbXBvc2VkIGludG8gaXRzIGF0b21pYyBi aXRzIHdpdGggYSBmaXhlZCBzaXplIGxpbWl0DQo+ID4gICAtLT4gd2UgbXVzdCBub3QgcmVxdWly ZSB0aGF0IGF0b21pYyBiaXQgTVVTVCBmaXQgaW50byBhIHBhY2tldC4NCj4gDQo+IEkgdW5kZXJz dGFuZCB0aGF0LCBidXQgd2Ugc2hvdWxkIG5vdGUgdGhhdCB0aGlzIHNpZ25pZmljYW50bHkgY29t cGxpY2F0ZXMNCj4gZmxvb2Rpbmcgb2YgSW50ZW50IHRvIGFsbCBub2Rlcy4NCj4gDQo+IC4uLg0K PiA+IEZsb29kZWQ/DQo+ID4gLSBnb29kIGVub3VnaCBmb3Igbm93IHRvIGZsb29kLg0KPiANCj4g VGhlIG9ubHkgc3RyYWlnaHRmb3J3YXJkIGZsb29kaW5nIG1lY2hhbmlzbSB3ZSBoYXZlIG5vdyAq ZG9lcyogYXNzdW1lDQo+IHRoYXQgdGhlIGF0b21pYyBiaXRzIGZpdCBpbiBhIHBhY2tldC4NCj4g DQo+ID4gICBCVVQ6IGFzIGxvbmcgYXMgd2UgaGF2ZSBhIG1vcmUgZ3JhbnVsYXIgd2F5IHRvICJ1 cGdyYWRlIHRvIiBsYXRlci4NCj4gDQo+IEFjdHVhbGx5IHRoZSBncmFudWxhciBtZWNoYW5pc20g aXMgdGhlcmUgdG9vIGJ1dCAqZG9lc24ndCogYXNzdW1lIHRoYXQgdGhlDQo+IGF0b21pYyBiaXRz IGZpdCBpbiBhIHBhY2tldC4NCj4gDQo+IEkgdGhpbmsgd2UgbmVlZCB0byB0aGluayBhYm91dCBk cmFmdC1saXUtYW5pbWEtZ3Jhc3AtZGlzdHJpYnV0aW9uDQo+IGFzIGEgcG90ZW50aWFsIHJlcXVp cmVtZW50cyBkb2N1bWVudCBpbiB0aGlzIGFyZWEuDQo+IA0KPiAgICAgQnJpYW4NCg== From nobody Tue Apr 12 01:49:39 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE86212E858 for ; Tue, 12 Apr 2016 01:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 IMlx-8njyOUc for ; Tue, 12 Apr 2016 01:49:37 -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 DA9C712E856 for ; Tue, 12 Apr 2016 01:49:36 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id EAE0DBD397378; Tue, 12 Apr 2016 08:49:32 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u3C8nYlm009895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Apr 2016 08:49:35 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u3C8nSbO029156 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Apr 2016 10:49:34 +0200 Received: from [172.27.205.128] (135.239.27.41) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 12 Apr 2016 10:49:33 +0200 To: "EXT Michael Behringer (mbehring)" , Brian E Carpenter , anima References: <570C8076.8030308@gmail.com> From: Laurent Ciavaglia Organization: Bell Labs Message-ID: <570CB69D.40605@alcatel-lucent.com> Date: Tue, 12 Apr 2016 10:49:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------090404000802070203030704" X-Originating-IP: [135.239.27.41] Archived-At: Subject: Re: [Anima] Intent Discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 12 Apr 2016 08:49:38 -0000 --------------090404000802070203030704 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Hello, On 12/04/2016 09:43, EXT Michael Behringer (mbehring) wrote: > Noting that, if Intent is really relatively long lived, the signalling happens all the time, actual transfer only if there is a new version. To me: Order of once a month! It's not so much the intent's lifetime that matters, than the frequency at which the user (or the policy management system) creates/updates/deletes intents. Laurent. --------------090404000802070203030704 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 7bit Hello,

On 12/04/2016 09:43, EXT Michael Behringer (mbehring) wrote:
Noting that, if Intent is really relatively long lived, the signalling happens all the time, actual transfer only if there is a new version. To me: Order of once a month!
It's not so much the intent's lifetime that matters, than the frequency at which the user (or the policy management system) creates/updates/deletes intents.

Laurent.
--------------090404000802070203030704-- From nobody Tue Apr 12 02:15:51 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E6612D612 for ; Tue, 12 Apr 2016 02:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.506 X-Spam-Level: X-Spam-Status: No, score=-15.506 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 DieNXqRXHiIn for ; Tue, 12 Apr 2016 02:15:49 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A781C12D585 for ; Tue, 12 Apr 2016 02:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7805; q=dns/txt; s=iport; t=1460452547; x=1461662147; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ZKKBSbjDRaeLu3Dh6j40TkgFSPzuh3bJn0ZsKobWi2Y=; b=dDDw2Rbm9oTlorlGQIUNF2ByjahKJn4TReujqqDqx9uZhfJCsX1lCvN8 7tw1Ar30SHB7aXaf5ds5NXivT+hGDn1o3ed8lMlRuD38eP9iiuvoOup4z Kn2o/ItvKLdmNP0Vt6OeiPyjzkpzsIMsOfqUQnV/RieH1McJwXshw9ROh 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQBQD0uwxX/51dJa1dgmtMU30GrwaLZ?= =?us-ascii?q?oFyhg0CgS45EwEBAQEBAQFlJ4RBAQEBBC1cAgEIEQQBASgHIREUCQgBAQQBCQk?= =?us-ascii?q?IiAoDErseDYUfAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYhhEuCQYI0hSAFkxuEP?= =?us-ascii?q?DEBiGmDLoFujxeHS4dbASICPoNnbAGJBn4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,473,1454976000"; d="scan'208,217";a="260446835" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Apr 2016 09:15:46 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u3C9FkVI002481 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Apr 2016 09:15:46 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 12 Apr 2016 04:15:46 -0500 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.009; Tue, 12 Apr 2016 04:15:45 -0500 From: "Michael Behringer (mbehring)" To: Laurent Ciavaglia , Brian E Carpenter , anima Thread-Topic: [Anima] Intent Discussion Thread-Index: AdGQvf+xeVbNHCZJTzaTRxDR/JZAHgD4934AAATXaxAAAzpUgAAJnYZg Date: Tue, 12 Apr 2016 09:15:45 +0000 Message-ID: References: <570C8076.8030308@gmail.com> <570CB69D.40605@alcatel-lucent.com> In-Reply-To: <570CB69D.40605@alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.238.142] Content-Type: multipart/alternative; boundary="_000_edc3820c24d6484ca33b8ed5e5052158XCHRCD006ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Intent Discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 12 Apr 2016 09:15:50 -0000 --_000_edc3820c24d6484ca33b8ed5e5052158XCHRCD006ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agree. Also that, in my mind, is long lived; again, to me Intent is "high l= evel policy". That doesn't change frequently. I still suspect at the bottom of this discussion is a different understandi= ng of what Intent actually is.... Michael From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Laurent Ciavaglia Sent: 12 April 2016 10:50 To: Michael Behringer (mbehring) ; Brian E Carpenter ; anima Subject: Re: [Anima] Intent Discussion Hello, On 12/04/2016 09:43, EXT Michael Behringer (mbehring) wrote: Noting that, if Intent is really relatively long lived, the signalling happ= ens all the time, actual transfer only if there is a new version. To me: Or= der of once a month! It's not so much the intent's lifetime that matters, than the frequency at = which the user (or the policy management system) creates/updates/deletes in= tents. Laurent. --_000_edc3820c24d6484ca33b8ed5e5052158XCHRCD006ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Agree. Also that, in my mind, is = long lived; again, to me Intent is “high level policy”. That doesn’t change frequently.

=  

= I still suspect at the bottom of = this discussion is a different understanding of what Intent actually is....

=  

= Michael<= /p>

=  

=  

From:<= font size=3D"2" color=3D"black" face=3D"Calibri"> Anima [mailto:anima-bounces@ietf.org] = On Behalf Of Laurent Ciavaglia
Sent: 12 April 2016 10:50 To: Michael Behringer (mbehr= ing) <mbehring@cisco.com>; Brian E Carpenter <brian.e.carpenter@gm= ail.com>; anima <anima@ietf.org>
Subject: Re: [Anima] Intent = Discussion

 

Hello,

On 12/04/2016 09:43, EXT Michael B= ehringer (mbehring) wrote:

Noting that, if Intent is really relatively long lived, =
the signalling happens all the time, actual transfer only if there is a new=
 version. To me: Order of once a month!

It's not so much the intent's life= time that matters, than the frequency at which the user (or the policy mana= gement system) creates/updates/deletes intents.

Laurent.

--_000_edc3820c24d6484ca33b8ed5e5052158XCHRCD006ciscocom_-- From nobody Tue Apr 12 02:33:52 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2EAF12E998 for ; Tue, 12 Apr 2016 02:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 TGOwGTE3UbqF for ; Tue, 12 Apr 2016 02:33:44 -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 AC72712E994 for ; Tue, 12 Apr 2016 02:33:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHE80923; Tue, 12 Apr 2016 09:33:40 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 12 Apr 2016 10:33:39 +0100 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Tue, 12 Apr 2016 17:33:31 +0800 From: "Liubing (Leo)" To: John Strassner Thread-Topic: [Anima] Questions during ANIMA II session Thread-Index: AQHRkQ9GRToqrTWMZUaywg36mKpr859+/SuAgAErVoCABddlwA== Date: Tue, 12 Apr 2016 09:33:30 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2D66807@nkgeml514-mbx.china.huawei.com> References: <5706C848.10607@alcatel-lucent.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2D64869@nkgeml514-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.117] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2D66807nkgeml514mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.570CC0F5.000B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e8141567fc84b8bdcf141f1480314e53 Archived-At: Cc: Laurent Ciavaglia , =?utf-8?B?SsOpZmVyc29uIENhbXBvcyBOb2JyZQ==?= , Michael Behringer , anima Subject: Re: [Anima] Questions during ANIMA II session X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 12 Apr 2016 09:33:48 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2D66807nkgeml514mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9obiwNCg0KUGxlYXNlIHNlZSByZXBsaWVzIGlubGluZS4NCg0KRnJvbTogSm9obiBTdHJh c3NuZXIgW21haWx0bzpzdHJhenBkakBnbWFpbC5jb21dDQpTZW50OiBTYXR1cmRheSwgQXByaWwg MDksIDIwMTYgNjo0NiBBTQ0KVG86IExpdWJpbmcgKExlbyk7IEpvaG4gU3RyYXNzbmVyDQpDYzog TGF1cmVudCBDaWF2YWdsaWE7IGFuaW1hOyBKw6lmZXJzb24gQ2FtcG9zIE5vYnJlOyBNaWNoYWVs IEJlaHJpbmdlcg0KU3ViamVjdDogUmU6IFtBbmltYV0gUXVlc3Rpb25zIGR1cmluZyBBTklNQSBJ SSBzZXNzaW9uDQoNCkhpIEJpbmcsDQoNCj4gV2hlbiB3ZSB3cm90ZSB0aGUgZGlzdHJpYnV0aW9u IGRyYWZ0LCB3ZSBhbHNvIGV4cGVjdGVkIHRoZSBHUkFTUCBjb3VsZA0KPiBub3Qgb25seSBkaXN0 cmlidXRlIEludGVudCwgYnV0IGFzIHdlbGwgYXMgb3RoZXIgdmFsdWFibGUgaW5mb3JtYXRpb24u DQoNCkkgdGhpbmsgd2UgbmVlZCB0byBiZSBjYXJlZnVsIGhlcmUuIEp1c3QgYXMgTWljaGFlbCB3 YXJuZWQgdGhhdCB3ZSBhcmUgc3RhcnRpbmcgdG8NCmNhbGwgZXZlcnl0aGluZyBpbnRlbnQgKGFu ZCBzaG91bGRuJ3QpLA0KW0JpbmddIEkgYWdyZWUgd2Ugc2hvdWxkIE5PVCBjb25zaWRlciBJbnRl bnQgYXMgYSBnZW5lcmljIGNvbnRhaW5lciBmb3IgdmFyaW91cyBraW5kcyBvZiBtYW5hZ2VtZW50 IGluZm9ybWF0aW9uIG9yIGNvbW1hbmQuDQoNCkknbSBhIGJpdCBzY2FyZWQgdGhhdCB3ZSBhcmUg c3RhcnRpbmcgdG8NCnZpZXcgR1JBU1AgYXMgYSBnZW5lcmljIGNvbW11bmljYXRpb25zIG1lY2hh bmlzbS4NCltCaW5nXSBUaGlzIGlzIGEgcmVhc29uYWJsZSBjYXV0aW9uLCB0aGFua3MuIFdlIGRl ZmluaXRlbHkgc2hvdWxkIE5PVCBhYnVzZSBpdC4NCg0KT24gdGhlIG90aGVyIGhhbmQsIGluIG15 IG1pbmQgR1JBU1AgbmF0dXJhbGx5IGhhcyBzb21lIG1vcmUgb3IgbGVzcyDigJxnZW5lcmlj4oCd IGNvbW11bmljYXRpb24gY2FwYWJpbGl0aWVzIGJ5IGl0cyBkZWZpbml0aW9uLiBIZXJlIGlzIHNv bWUgYW5hbHlzaXM6DQoNCi0gICAgICAgIEFOIGRvbWFpbiBmbG9vZGluZy4gTm90IG9ubHkgSW50 ZW50LCBidXQgYW55dGhpbmcgdGhhdCBuZWVkIHRvIGJlIGZsb29kZWQgdG8gdGhlIGRvbWFpbi4N Cg0KKmxldmVyYWdpbmcgR1JBU1AtRmxvb2QNCg0KKmJ1aWx0LWluIGxvb3AgYXZvaWRhbmNlIGNh cGFiaWxpdHkNCg0KLSAgICAgICAgUHVsbGluZyBhIHNldCBvZiBpbmZvcm1hdGlvbiBmcm9tIGEg c3BlY2lmaWMgQU4gbm9kZToNCg0KKiBsZXZlcmFnaW5nIEdSQVNQLVN5bmMNCg0KLSAgICAgICAg TXVsdGktcm91bmQgcG9pbnQtdG8tcG9pbnQgaW5mb3JtYXRpb24gZXhjaGFuZ2U6DQoqaW1wbHlp bmcgdGhlcmUgaXMgY29udGV4dC9zdGF0ZSBkdXJpbmcgdGhlIGV4Y2hhbmdlLCBub3QgcHVyZWx5 IHRyYW5zcG9ydGluZw0KKmxldmVyYWdpbmcgR1JBU1AtTmVnb3RpYXRpb24NCg0KSG93ZXZlciwg dGhlcmUgc2hvdWxkIGJlIGxpbWl0YXRpb25zIG9uIGFib3ZlIG1lbnRpb25lZCBjb21tdW5pY2F0 aW9uOg0KDQotICAgICAgICBlaXRoZXIgZm9yIGZsb29kIG9yIHBvaW50LXRvLXBvaW50IGNvbW11 bmljYXRpb24sIHRoZSBjb252ZXllZCBpbmZvcm1hdGlvbiBzaG91bGQgYmUgc21hbGwgZW5vdWdo IHRvIGF2b2lkIHRyYW5zcG9ydC1zcGVjaWZpYyBmZWF0dXJlcyBzdWNoIGFzIGZyYWdtZW50YXRp b24sIHN0cmVhbWluZywgcmUtdHJhbnNtaXR0aW5nIGV0Yy4NCg0KLSAgICAgICAgRm9yIGFueSDi gJxnZW5lcmlj4oCdIGNvbW11bmljYXRpb24sIHRoZSBBU0FzIG5lZWQgYW4g4oCcb2JqZWN0aXZl 4oCdIGRlZmluaXRpb24gdG8gaW5kaWNhdGUgd2hhdCBpbmZvcm1hdGlvbiB0aGV54oCZcmUgZXhj aGFuZ2luZywgYW5kIGFsc28gZm9ybXVsaXppbmcgdGhlIGluZm9ybWF0aW9uIGRhdGEgc3RydWN0 dXJlLiBUaGUgb2JqZWN0aXZlIGNvdWxkIGJlIHN0YW5kYXJkLCBvciBwcml2YXRlIGFtb25nIGEg c2V0IG9mIEFTQXMuDQoNCg0KSSBhbHNvIHRoaW5rIHdlIG5lZWQgdG8gZGlmZmVyZW50aWF0ZSBi ZXR3ZWVuIGludGVudCAoYXMgYW4gaW5wdXQgdG8gdGhlIGF1dG9ub21pYw0KbmV0d29yayksIHRy YWZmaWMgcmVzdWx0aW5nIGZyb20gc2FpZCBpbnRlbnQsIGFuZCBvdGhlciB0cmFmZmljIHRoYXQg Z2F0aGVycyBvYnNlcnZhdGlvbnMNCmFuZCBwcm9kdWNlcyByZXN1bHRzLiBJdCBpcyBub3QgY2xl YXIgdG8gbWUgdGhhdCB3ZSB3YW50IHRvIHVzZSB0aGUgc2FtZSBuZXR3b3JrDQp0aGVzZSB0aHJl ZSB0eXBlcyBvZiBpbmZvcm1hdGlvbiwgYXMgdGhlaXIgYXNzb2NpYXRlZCBkYXRhIHN0cnVjdHVy ZXMgYW5kIHByb3BlcnRpZXMNCmFyZSBsaWtlbHkgKip2ZXJ5KiogZGlmZmVyZW50Lg0KW0Jpbmdd IEkgYWdyZWUgdGhlIGFib3ZlIHNhaWQgdGhyZWUgdHlwZXMgb2YgaW5mb3JtYXRpb24gc2hvdWxk IGJlIG5hdHVyYWxseSBkaXN0aW5jdCBhdCB0aGUgY29udGVudCBsZXZlbC4gQnV0IEkgZ3Vlc3Mg YWxsIHRoZSB0aHJlZSB0eXBlcyBvZiBpbmZvcm1hdGlvbiBkb2VzbuKAmXQgbmVjZXNzYXJpbHkg bWVhbiBpdCBhbGwgQU4gcmVsZXZhbnQgY29tbXVuaWNhdGlvbj8NCg0KUmVnYXJkaW5nIHRvIEFO IGNvbW11bmljYXRpb24sIGFzIEkgdW5kZXJzdGFuZCwgdGhlIHNjb3BlIGlzIHRoZSBjb21tdW5p Y2F0aW9ucyBiZXR3ZWVuIEFTQXMuIEFTQSBjb21tdW5pY2F0aW9uIG1pZ2h0IG5vdCBvbmx5IGlu Y2x1ZGUgSW50ZW50LiBJIHRoaW5rIExhdXJlbnQgYW5kIFBlbG9zb+KAmXMgIHByb3Bvc2FscyAo Q29vcmRpbmF0aW9uLCBBU0EgTGlmZS1DeWNsZSBtYW5hZ2VtZW50LCBLbm93bGVkZ2UgZXhjaGFu Z2UpIGFyZSBnaXZpbmcgc29tZSBnb29kIGNsdWVzIGZvciBkaXNjdXNzaW9uLg0KDQpCZXN0IHJl Z2FyZHMsDQpCaW5nDQoNCnJlZ2FyZHMsDQpKb2huDQoNCk9uIFRodSwgQXByIDcsIDIwMTYgYXQg MjoxMSBQTSwgTGl1YmluZyAoTGVvKSA8bGVvLmxpdWJpbmdAaHVhd2VpLmNvbTxtYWlsdG86bGVv LmxpdWJpbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KSGkgTGF1cmVudCwNCg0KVGhhbmtzIGZvciB0 aGUgc3VtbWFyeS4gWW91IGNhcHR1cmVkIG15IHBvaW50Lg0KIEkgdGhpbmsgdGhlIGtub3dsZWRn ZSBleGNoYW5nZSBpcyBhIHZhbHVhYmxlIHRvcGljLiBXaGVuIHdlIHdyb3RlIHRoZSBkaXN0cmli dXRpb24gZHJhZnQsIHdlIGFsc28gZXhwZWN0ZWQgdGhlIEdSQVNQIGNvdWxkIG5vdCBvbmx5IGRp c3RyaWJ1dGUgSW50ZW50LCBidXQgYXMgd2VsbCBhcyBvdGhlciB2YWx1YWJsZSBpbmZvcm1hdGlv bi4gU28gSeKAmW0gaGFwcHkgdG8gc2VlIHlvdSBjYWxsIGl0IG91dC4NCkJ1dCBJIGRvbuKAmXQg a25vdyBob3cgc29waGlzdGljYXRlIHRoZSBrbm93bGVkZ2UgZXhjaGFuZ2Ugd291bGQgYmUsIHNv IGl0IHdpbGwgYmUgZ3JlYXQgaWYgeW91IGNhbiBzb3J0IG91dCB0aGUgc3BlY2lmaWMgcmVxdWly ZW1lbnRzLiBUaGVuIGxldOKAmXMgY2hlY2sgd2hldGhlciBpdCBjb3VsZCBiZSBjb3ZlcmVkIGJ5 IHRoZSBkaXN0cmlidXRpb24gZnVuY3Rpb24gKHByb2JhYmx5IHdpdGggZXh0ZW5zaW9ucyB0byBj dXJyZW50IGRlc2lnbikuDQoNCkJlc3QgcmVnYXJkcywNCkJpbmcNCg0KRnJvbTogTGF1cmVudCBD aWF2YWdsaWEgW21haWx0bzpsYXVyZW50LmNpYXZhZ2xpYUBub2tpYS5jb208bWFpbHRvOmxhdXJl bnQuY2lhdmFnbGlhQG5va2lhLmNvbT5dDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMDcsIDIwMTYg NTo1MSBQTQ0KVG86IGFuaW1hOyBMaXViaW5nIChMZW8pOyBKw6lmZXJzb24gQ2FtcG9zIE5vYnJl OyBNaWNoYWVsIEJlaHJpbmdlcg0KU3ViamVjdDogUXVlc3Rpb25zIGR1cmluZyBBTklNQSBJSSBz ZXNzaW9uDQoNCkhlbGxvLA0KDQpUaGFua3MgZm9yIHlvdXIgcGF0aWVuY2UgcmUuIHRoZSBpc3N1 ZXMgZmFjZWQgZm9yIHRoZSByZW1vdGUgcHJlc2VudGF0aW9ucy4NCkkgaG9wZSB5b3Ugc3RpbGwg bWFuYWdlZCB0byB1bmRlcnN0YW5kIG91ciBtZXNzYWdlcyA7KQ0KDQpUaGVyZSBoYXZlIGJlZW4g Y29tbWVudHMgb24gdGhlIGNvb3JkaW5hdGlvbiBhbmQga25vd2xlZGdlIHByZXNlbnRhdGlvbnMu DQpNaWNoYWVsLCBKw6lmZXJzb24gYW5kIEJpbmc6IGNvdWxkIHlvdSByZXBlYXQgeW91ciBjb21t ZW50IG9uIHRoZSBsaXN0Pw0KSSBjYXVnaHQgdGhlIGZvbGxvd2luZzoNCg0KUS4gTWljaGFlbDog ZXhhbXBsZXMgb2YgY29vcmRpbmF0aW9uLCB3aGF0IGEgKG1pbmltYWwpIHBvbGljeSBlbmdpbmUg Y291bGQgbG9vayBsaWtlPyBzdGFydCBzbWFsbC4NCg0KUS4gSmVmZXJzb246IGltcGxpY2F0aW9u cyBvbiBkYXRhIG1vZGVscyAvIG1lYXN1cmVtZW50L21vbml0b3JpbmcuLi4gPw0KDQpRLiBCaW5n OiB1c2UgR1JBU1Agb3Igb3RoZXIgbWVjaGFuaXNtcy4gQ2xhcmlmeSByZXF1aXJlbWVudHMgZm9y IEdSQVNQLg0KDQpUaGFua3MsIExhdXJlbnQuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpBbmltYSBtYWlsaW5nIGxpc3QNCkFuaW1hQGlldGYub3Jn PG1haWx0bzpBbmltYUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vYW5pbWENCg0KDQoNCi0tDQpyZWdhcmRzLA0KSm9obg0K --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2D66807nkgeml514mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRh dGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiLmibnms6jmoYbm lofmnKwgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjkuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgs IGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1w cmlvcml0eTozNDsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0 LWluZGVudDoyMS4wcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7 fQ0Kc3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLmibnms6jmoYbmlofmnKwgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOuaJueazqOahhuaWh+acrDsN Cglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7 bXNvLWxpc3QtaWQ6NDczNjM5MzMzOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0 LXRlbXBsYXRlLWlkczo0NzM5NjY1MDggLTI4Nzk1MDYzOCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5 ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlz dCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjE4LjBw dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk65a6L5L2TOw0KCW1zby1iaWRpLWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjY2MzE2 NzY0ODsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTIx MzY3MDA1NjQgMjg2NzEzMDYwIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3 Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwxOmxldmVsMQ0KCXtt c28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674GsOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo0OC4xNXB0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OuWui+S9kzsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9 DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoxODQ4NzA5NDA5Ow0KCW1zby1saXN0LXR5cGU6aHli cmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMDA2MjYzOTIwIDM0MTQ1Mjk2OCA2NzY5ODY5 MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2 NzY5ODY5Mzt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+BrDsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ bWFyZ2luLWxlZnQ6NDYuMDVwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTrlrovkvZM7DQoJbXNvLWJpZGkt Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207 fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgt Q04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgSm9obiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+UGxlYXNlIHNlZSByZXBsaWVzIGlubGluZS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gSm9obiBTdHJhc3NuZXIgW21haWx0bzpzdHJhenBkakBnbWFpbC5jb21dDQo8YnI+ DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIEFwcmlsIDA5LCAyMDE2IDY6NDYgQU08YnI+DQo8Yj5U bzo8L2I+IExpdWJpbmcgKExlbyk7IEpvaG4gU3RyYXNzbmVyPGJyPg0KPGI+Q2M6PC9iPiBMYXVy ZW50IENpYXZhZ2xpYTsgYW5pbWE7IErDqWZlcnNvbiBDYW1wb3MgTm9icmU7IE1pY2hhZWwgQmVo cmluZ2VyPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbQW5pbWFdIFF1ZXN0aW9ucyBkdXJpbmcg QU5JTUEgSUkgc2Vzc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+SGkgQmluZyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZndDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+V2hlbiB3ZSB3cm90ZSB0aGUgZGlzdHJpYnV0aW9uIGRyYWZ0LCB3ZSBhbHNvIGV4 cGVjdGVkIHRoZSBHUkFTUCBjb3VsZA0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+Jmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+bm90IG9ubHkgZGlzdHJpYnV0ZSBJbnRlbnQsIGJ1dCBhcyB3ZWxsIGFzIG90aGVy IHZhbHVhYmxlIGluZm9ybWF0aW9uLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIHRoaW5rIHdlIG5lZWQg dG8gYmUgY2FyZWZ1bCBoZXJlLiBKdXN0IGFzIE1pY2hhZWwgd2FybmVkIHRoYXQgd2UgYXJlIHN0 YXJ0aW5nIHRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmNhbGwgZXZlcnl0aGluZyBpbnRlbnQgKGFu ZCBzaG91bGRuJ3QpLCA8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+DQo8bzpwPjwvbzpwPjwv c3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bQmluZ10gSSBhZ3JlZSB3ZSBz aG91bGQgTk9UIGNvbnNpZGVyIEludGVudCBhcyBhIGdlbmVyaWMgY29udGFpbmVyIGZvciB2YXJp b3VzIGtpbmRzIG9mIG1hbmFnZW1lbnQgaW5mb3JtYXRpb24gb3IgY29tbWFuZC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JJ20gYSBiaXQg c2NhcmVkIHRoYXQgd2UgYXJlIHN0YXJ0aW5nIHRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPnZpZXcg R1JBU1AgYXMgYSBnZW5lcmljIGNvbW11bmljYXRpb25zIG1lY2hhbmlzbS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltCaW5nXSBUaGlzIGlzIGEgcmVhc29uYWJs ZSBjYXV0aW9uLCB0aGFua3MuIFdlIGRlZmluaXRlbHkgc2hvdWxkIE5PVCBhYnVzZSBpdC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T24gdGhlIG90aGVyIGhhbmQsIGluIG15 IG1pbmQgR1JBU1AgbmF0dXJhbGx5IGhhcyBzb21lIG1vcmUgb3IgbGVzcyDigJxnZW5lcmlj4oCd IGNvbW11bmljYXRpb24gY2FwYWJpbGl0aWVzIGJ5IGl0cyBkZWZpbml0aW9uLiBIZXJlIGlzIHNv bWUgYW5hbHlzaXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28t bGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QU4gZG9tYWluIGZsb29kaW5nLiBOb3Qgb25s eSBJbnRlbnQsIGJ1dCBhbnl0aGluZyB0aGF0IG5lZWQgdG8gYmUgZmxvb2RlZCB0byB0aGUgZG9t YWluLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MjIuOHB0O3RleHQtaW5kZW50OjUuMjVwdCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4qbGV2ZXJhZ2luZyBH UkFTUC1GbG9vZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjIuOHB0O3RleHQtaW5kZW50OjUuMjVwdCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4qYnVpbHQt aW4gbG9vcCBhdm9pZGFuY2UgY2FwYWJpbGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0O3RleHQtaW5k ZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0 c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlB1bGxpbmcgYSBz ZXQgb2YgaW5mb3JtYXRpb24gZnJvbSBhIHNwZWNpZmljIEFOIG5vZGU6DQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjI3LjZwdDt0ZXh0LWluZGVudDowY20iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+KiBsZXZlcmFnaW5nIEdSQVNQLVN5bmM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4N CjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5NdWx0aS1yb3VuZCBwb2ludC10by1wb2ludCBpbmZvcm1hdGlvbiBleGNoYW5nZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MTQuNHB0O3RleHQtaW5kZW50OjE1Ljc1cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+KmltcGx5aW5nIHRoZXJlIGlzIGNvbnRl eHQvc3RhdGUgZHVyaW5nIHRoZSBleGNoYW5nZSwgbm90IHB1cmVseSB0cmFuc3BvcnRpbmc8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MTQuNHB0O3RleHQtaW5kZW50OjE1Ljc1cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+KmxldmVyYWdpbmcgR1JBU1AtTmVnb3RpYXRp b248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SG93ZXZlciwgdGhlcmUgc2hv dWxkIGJlIGxpbWl0YXRpb25zIG9uIGFib3ZlIG1lbnRpb25lZCBjb21tdW5pY2F0aW9uOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MTguMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4t PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9z cGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPmVpdGhlciBmb3IgZmxvb2Qgb3IgcG9pbnQtdG8tcG9pbnQgY29tbXVuaWNh dGlvbiwgdGhlIGNvbnZleWVkIGluZm9ybWF0aW9uIHNob3VsZCBiZSBzbWFsbCBlbm91Z2ggdG8g YXZvaWQgdHJhbnNwb3J0LXNwZWNpZmljIGZlYXR1cmVzDQogc3VjaCBhcyBmcmFnbWVudGF0aW9u LCBzdHJlYW1pbmcsIHJlLXRyYW5zbWl0dGluZyBldGMuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQ7dGV4 dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Rm9yIGFu eSDigJxnZW5lcmlj4oCdIGNvbW11bmljYXRpb24sIHRoZSBBU0FzIG5lZWQgYW4g4oCcb2JqZWN0 aXZl4oCdIGRlZmluaXRpb24gdG8gaW5kaWNhdGUgd2hhdCBpbmZvcm1hdGlvbiB0aGV54oCZcmUg ZXhjaGFuZ2luZywgYW5kIGFsc28gZm9ybXVsaXppbmcNCiB0aGUgaW5mb3JtYXRpb24gZGF0YSBz dHJ1Y3R1cmUuIFRoZSBvYmplY3RpdmUgY291bGQgYmUgc3RhbmRhcmQsIG9yIHByaXZhdGUgYW1v bmcgYSBzZXQgb2YgQVNBcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgYWxzbyB0aGluayB3ZSBuZWVkIHRvIGRpZmZlcmVu dGlhdGUgYmV0d2VlbiBpbnRlbnQgKGFzIGFuIGlucHV0IHRvIHRoZSBhdXRvbm9taWM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+bmV0d29yayksIHRyYWZmaWMgcmVzdWx0aW5nIGZyb20gc2FpZCBpbnRl bnQsIGFuZCBvdGhlciB0cmFmZmljIHRoYXQgZ2F0aGVycyBvYnNlcnZhdGlvbnM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+YW5kIHByb2R1Y2VzIHJlc3VsdHMuIEl0IGlzIG5vdCBjbGVhciB0byBtZSB0 aGF0IHdlIHdhbnQgdG8gdXNlIHRoZSBzYW1lIG5ldHdvcms8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ dGhlc2UgdGhyZWUgdHlwZXMgb2YgaW5mb3JtYXRpb24sIGFzIHRoZWlyIGFzc29jaWF0ZWQgZGF0 YSBzdHJ1Y3R1cmVzIGFuZCBwcm9wZXJ0aWVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmFyZSBsaWtl bHkgKip2ZXJ5KiogZGlmZmVyZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+W0JpbmddIEkgYWdyZWUgdGhlIGFib3ZlIHNhaWQgdGhyZWUgdHlwZXMgb2YgaW5m b3JtYXRpb24gc2hvdWxkIGJlIG5hdHVyYWxseSBkaXN0aW5jdCBhdCB0aGUgY29udGVudCBsZXZl bC4gQnV0IEkgZ3Vlc3MgYWxsIHRoZSB0aHJlZSB0eXBlcyBvZg0KIGluZm9ybWF0aW9uIGRvZXNu 4oCZdCBuZWNlc3NhcmlseSBtZWFuIGl0IGFsbCBBTiByZWxldmFudCBjb21tdW5pY2F0aW9uPzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRpbmcgdG8gQU4gY29tbXVu aWNhdGlvbiwgYXMgSSB1bmRlcnN0YW5kLCB0aGUgc2NvcGUgaXMgdGhlIGNvbW11bmljYXRpb25z IGJldHdlZW4gQVNBcy4gQVNBIGNvbW11bmljYXRpb24gbWlnaHQgbm90IG9ubHkgaW5jbHVkZSBJ bnRlbnQuDQogSSB0aGluayBMYXVyZW50IGFuZCBQZWxvc2/igJlzICZuYnNwO3Byb3Bvc2FscyAo Q29vcmRpbmF0aW9uLCBBU0EgTGlmZS1DeWNsZSBtYW5hZ2VtZW50LCBLbm93bGVkZ2UgZXhjaGFu Z2UpIGFyZSBnaXZpbmcgc29tZSBnb29kIGNsdWVzIGZvciBkaXNjdXNzaW9uLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5yZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Kb2hu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBUaHUs IEFwciA3LCAyMDE2IGF0IDI6MTEgUE0sIExpdWJpbmcgKExlbykgJmx0OzxhIGhyZWY9Im1haWx0 bzpsZW8ubGl1YmluZ0BodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+bGVvLmxpdWJpbmdAaHVh d2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIExhdXJlbnQsPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciB0aGUgc3VtbWFyeS4gWW91IGNhcHR1cmVkIG15IHBv aW50Lg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7SSB0aGluayB0aGUga25vd2xlZGdlIGV4Y2hhbmdl IGlzIGEgdmFsdWFibGUgdG9waWMuIFdoZW4gd2Ugd3JvdGUgdGhlIGRpc3RyaWJ1dGlvbg0KIGRy YWZ0LCB3ZSBhbHNvIGV4cGVjdGVkIHRoZSBHUkFTUCBjb3VsZCBub3Qgb25seSBkaXN0cmlidXRl IEludGVudCwgYnV0IGFzIHdlbGwgYXMgb3RoZXIgdmFsdWFibGUgaW5mb3JtYXRpb24uIFNvIEni gJltIGhhcHB5IHRvIHNlZSB5b3UgY2FsbCBpdCBvdXQuDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CdXQgSSBk b27igJl0IGtub3cgaG93IHNvcGhpc3RpY2F0ZSB0aGUga25vd2xlZGdlIGV4Y2hhbmdlIHdvdWxk IGJlLCBzbyBpdCB3aWxsIGJlIGdyZWF0DQogaWYgeW91IGNhbiBzb3J0IG91dCB0aGUgc3BlY2lm aWMgcmVxdWlyZW1lbnRzLiBUaGVuIGxldOKAmXMgY2hlY2sgd2hldGhlciBpdCBjb3VsZCBiZSBj b3ZlcmVkIGJ5IHRoZSBkaXN0cmlidXRpb24gZnVuY3Rpb24gKHByb2JhYmx5IHdpdGggZXh0ZW5z aW9ucyB0byBjdXJyZW50IGRlc2lnbikuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+QmVzdCByZWdhcmRzLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJpbmc8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS41cHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA0LjBwdDtib3JkZXItY29sb3I6Y3VycmVudENvbG9yIGN1cnJlbnRDb2xv ciBjdXJyZW50Q29sb3IgYmx1ZSI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY207 Ym9yZGVyLWNvbG9yOmN1cnJlbnRDb2xvciBjdXJyZW50Q29sb3IiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBMYXVy ZW50DQogQ2lhdmFnbGlhIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmxhdXJlbnQuY2lhdmFnbGlh QG5va2lhLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmxhdXJlbnQuY2lhdmFnbGlhQG5va2lhLmNvbTwv YT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEFwcmlsIDA3LCAyMDE2IDU6NTEgUE08 YnI+DQo8Yj5Ubzo8L2I+IGFuaW1hOyBMaXViaW5nIChMZW8pOyBKw6lmZXJzb24gQ2FtcG9zIE5v YnJlOyBNaWNoYWVsIEJlaHJpbmdlcjxicj4NCjxiPlN1YmplY3Q6PC9iPiBRdWVzdGlvbnMgZHVy aW5nIEFOSU1BIElJIHNlc3Npb248L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPkhlbGxvLDxicj4NCjxicj4NClRoYW5rcyBmb3IgeW91ciBwYXRpZW5j ZSByZS4gdGhlIGlzc3VlcyBmYWNlZCBmb3IgdGhlIHJlbW90ZSBwcmVzZW50YXRpb25zLjxicj4N CkkgaG9wZSB5b3Ugc3RpbGwgbWFuYWdlZCB0byB1bmRlcnN0YW5kIG91ciBtZXNzYWdlcyA7KTxi cj4NCjxicj4NClRoZXJlIGhhdmUgYmVlbiBjb21tZW50cyBvbiB0aGUgY29vcmRpbmF0aW9uIGFu ZCBrbm93bGVkZ2UgcHJlc2VudGF0aW9ucy48YnI+DQpNaWNoYWVsLCBKw6lmZXJzb24gYW5kIEJp bmc6IGNvdWxkIHlvdSByZXBlYXQgeW91ciBjb21tZW50IG9uIHRoZSBsaXN0Pzxicj4NCkkgY2F1 Z2h0IHRoZSBmb2xsb3dpbmc6PGJyPg0KPGJyPg0KUS4gTWljaGFlbDogZXhhbXBsZXMgb2YgY29v cmRpbmF0aW9uLCB3aGF0IGEgKG1pbmltYWwpIHBvbGljeSBlbmdpbmUgY291bGQgbG9vayBsaWtl PyBzdGFydCBzbWFsbC48YnI+DQo8YnI+DQpRLiBKZWZlcnNvbjogaW1wbGljYXRpb25zIG9uIGRh dGEgbW9kZWxzIC8gbWVhc3VyZW1lbnQvbW9uaXRvcmluZy4uLiA/PGJyPg0KPGJyPg0KUS4gQmlu ZzogdXNlIEdSQVNQIG9yIG90aGVyIG1lY2hhbmlzbXMuIENsYXJpZnkgcmVxdWlyZW1lbnRzIGZv ciBHUkFTUC48YnI+DQo8YnI+DQpUaGFua3MsIExhdXJlbnQuPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5n PSJFTi1VUyI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpBbmltYSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86QW5pbWFA aWV0Zi5vcmciPkFuaW1hQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWEiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4N CjxiciBjbGVhcj0iYWxsIj4NCjxicj4NCi0tIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPnJlZ2FyZHMs PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPkpvaG48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2D66807nkgeml514mbxchi_-- From nobody Tue Apr 12 06:38:14 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F27412E511 for ; Tue, 12 Apr 2016 06:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 0Bskxh__pP8s for ; Tue, 12 Apr 2016 06:38:11 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1E1212E22E for ; Tue, 12 Apr 2016 06:38:10 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 81A3F20183; Tue, 12 Apr 2016 09:42:02 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9228363755; Tue, 12 Apr 2016 09:38:09 -0400 (EDT) From: Michael Richardson To: "Michael Behringer \(mbehring\)" In-Reply-To: References: <570C8076.8030308@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: anima Subject: Re: [Anima] Intent Discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 12 Apr 2016 13:38:12 -0000 --=-=-= Content-Type: text/plain Michael Behringer (mbehring) wrote: > In my mind, we'd use GRASP to signal amongst nodes just the current > version of Intent (or if it comes packaged for example for a set of > autonomic functions, that Intent set). Yes, what I've been saying. > Then, use TFTP (for example) to actually transmit the file. This way we > get reliability, re-transmission, fragmenting, etc, all for free, and > don't have to worry about that in GRASP. Well, not TFTP, it has horrible congestion properties. If HTTP is too heavy for some reason, use CoAP. > Noting that, if Intent is really relatively long lived, the signalling > happens all the time, actual transfer only if there is a new > version. To me: Order of once a month! Agreed. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVwz6PoCLcPvd0N1lAQKMnwgApZ+PYQPU6kc6/DIcHOIc0hsP7/8WyJQ/ ddvTFvvR7u+fkXza/g8IosA6HHsqUY5ejE9xeSssgY1Imy0pDjsg3IdQT3yESt6r XTgdAkL9Sh/3ORRnGDedry6qV8thQJsSS80+3UFkXXYA6NJlm33JlFQiJpKlE5PQ MQlUkNbKUJH/m/tqkq4pe3JoDRBHX1H5ttXQ6N6cB43TdQfj0HGNNlQ/ljeKsg0o CjihFLhWdthv3Xys/STLibOZfj75ATpskpAHoyxbWKFamay2P8QhFyfC0Pdg7kPJ FX4iNBOSSjn0Qm+fgkMiL7/Ayuz31ESNFPPb8sms0rwGeXdLhDmCGA== =9kqg -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Apr 12 06:47:18 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8767C12D814 for ; Tue, 12 Apr 2016 06:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 A7wVCz6vBsq0 for ; Tue, 12 Apr 2016 06:47:15 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 741AD12D56F for ; Tue, 12 Apr 2016 06:47:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1067; q=dns/txt; s=iport; t=1460468835; x=1461678435; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NUfOWUj2QK/0WU97oPHymxPgGVALxL6ztUlL1EKL72I=; b=PvkzYaPVeRVLAuoercow3jl9qrtRdaRDVv3uw7NN6n2DlCZLF5Xh3LGF L9DrJR51qZDXGkVI7S/qPRLypdjdIcSsv1BmOC4snFRilKyvQpVU9q2or ZXC00kWYtUf6xud5iqD7aTFF3sxiXHtDWVgaKxtp11jRbZBC9vIUYqoV5 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAgC4+wxX/4UNJK1egzdTfQavCItYA?= =?us-ascii?q?Q2BdIYNAoEzOBQBAQEBAQEBZSeEQQEBAQQ6PwwEAgEIEQQBAQEeCQchERQJCAE?= =?us-ascii?q?BBA4FCIgKAxK7WQ2FHwEBAQEBAQEBAQEBAQEBAQEBAQEBARWGIYRLgkGHVAWXV?= =?us-ascii?q?zEBjBeBbo8Xh0uHWwEeAQFCg2dsAYkGfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,474,1454976000"; d="scan'208";a="260392846" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Apr 2016 13:47:14 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u3CDlEEU004210 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Apr 2016 13:47:14 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 12 Apr 2016 08:47:13 -0500 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.009; Tue, 12 Apr 2016 08:47:12 -0500 From: "Michael Behringer (mbehring)" To: Michael Richardson Thread-Topic: [Anima] Intent Discussion Thread-Index: AdGQvf+xeVbNHCZJTzaTRxDR/JZAHgD4934AAATXaxAADU6dgAAKOELA Date: Tue, 12 Apr 2016 13:47:12 +0000 Message-ID: References: <570C8076.8030308@gmail.com> <31908.1460468289@obiwan.sandelman.ca> In-Reply-To: <31908.1460468289@obiwan.sandelman.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.238.142] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: anima Subject: Re: [Anima] Intent Discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 12 Apr 2016 13:47:16 -0000 > -----Original Message----- > From: Michael Richardson [mailto:mcr+ietf@sandelman.ca] > Sent: 12 April 2016 15:38 > To: Michael Behringer (mbehring) > Cc: Brian E Carpenter ; anima > > Subject: Re: [Anima] Intent Discussion >=20 >=20 > Michael Behringer (mbehring) wrote: > > In my mind, we'd use GRASP to signal amongst nodes just the current > > version of Intent (or if it comes packaged for example for a set of > > autonomic functions, that Intent set). >=20 > Yes, what I've been saying. >=20 > > Then, use TFTP (for example) to actually transmit the file. This wa= y we > > get reliability, re-transmission, fragmenting, etc, all for free, a= nd > > don't have to worry about that in GRASP. >=20 > Well, not TFTP, it has horrible congestion properties. > If HTTP is too heavy for some reason, use CoAP. replace TFTP with "a protocol that has reliability, fragmentation, etc". No= strong views from my side. Michael From nobody Tue Apr 12 08:33:12 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 461E712F007 for ; Tue, 12 Apr 2016 08:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 DCejKoxCo_75 for ; Tue, 12 Apr 2016 08:33:09 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 DF19212EFE9 for ; Tue, 12 Apr 2016 08:33:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 531DE540025; Tue, 12 Apr 2016 08:33:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1460475188; bh=ZyDhW2Uj2VYAsPWA1X4uwd1UhDnqZZMKLlRpC/rEXNs=; h=Subject:To:References:From:Date:In-Reply-To:From; b=ZSEKkUMv8oecjY+ViQyiSwCfewcWEQnQljvO514hEoGLJ/jMzWPNMJhYIvD5XxQfl aRAxs/vSxeZ0PfiLaPJBvcnyqpkq2ZGMVkoSr8i1aMqofZD5NzgNcJDVbzUWCOSfcC ePT7jjVoHvryABX7/uIM0XncSkvcgPP8E6SLhJxE= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 9F5C41C04A6; Tue, 12 Apr 2016 08:33:07 -0700 (PDT) To: "Michael Behringer (mbehring)" , Laurent Ciavaglia , Brian E Carpenter , anima References: <570C8076.8030308@gmail.com> <570CB69D.40605@alcatel-lucent.com> From: "Joel M. Halpern" Message-ID: <570D152F.50802@joelhalpern.com> Date: Tue, 12 Apr 2016 11:33:03 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Anima] Intent Discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 12 Apr 2016 15:33:11 -0000 One of the points that was discussed off-line in BA was that some folks in this discussion treat all the information exchanged by Anima as intent, and other folks treat Intent as one subset of the several varieties of information exchanged by Anima. It is pretty clear that for many of the policy control goals, there has to be frequent exchange of information. That information is not the human generated intents, but it is important information. Another aspect that makes me nervous is this assumption of stability. In one sense, it seems to follow naturally (human's don't change their busienss goals all that often). However, as the scope of an Anima system becomes larger, and as people realize they can change the system goals more frequently, I expect that the policy aspects will change more frequently. I even expect to see automated systems producing new policy goals. (Whether those systems are within Anima or above it is irrelevant.) Yours, Joel On 4/12/16 5:15 AM, Michael Behringer (mbehring) wrote: > Agree. Also that, in my mind, is long lived; again, to me Intent is > “high level policy”. That doesn’t change frequently. > > I still suspect at the bottom of this discussion is a different > understanding of what Intent actually is.... > > Michael > > *From:*Anima [mailto:anima-bounces@ietf.org] *On Behalf Of *Laurent > Ciavaglia > *Sent:* 12 April 2016 10:50 > *To:* Michael Behringer (mbehring) ; Brian E > Carpenter ; anima > *Subject:* Re: [Anima] Intent Discussion > > Hello, > > On 12/04/2016 09:43, EXT Michael Behringer (mbehring) wrote: > > Noting that, if Intent is really relatively long lived, the > signalling happens all the time, actual transfer only if there is a > new version. To me: Order of once a month! > > It's not so much the intent's lifetime that matters, than the frequency > at which the user (or the policy management system) > creates/updates/deletes intents. > > Laurent. > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Tue Apr 12 10:54:48 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C772E12D128 for ; Tue, 12 Apr 2016 10:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 uEv9pdWfiR2e for ; Tue, 12 Apr 2016 10:54:46 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19E9F12D0E0 for ; Tue, 12 Apr 2016 10:54:46 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 77A77200A7; Tue, 12 Apr 2016 13:58:38 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E738B63755; Tue, 12 Apr 2016 13:54:44 -0400 (EDT) From: Michael Richardson To: "Joel M. Halpern" In-Reply-To: <570D152F.50802@joelhalpern.com> References: <570C8076.8030308@gmail.com> <570CB69D.40605@alcatel-lucent.com> <570D152F.50802@joelhalpern.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: Laurent Ciavaglia , anima , "Michael Behringer \(mbehring\)" Subject: Re: [Anima] Intent Discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 12 Apr 2016 17:54:48 -0000 --=-=-= Content-Type: text/plain Joel M. Halpern wrote: > One of the points that was discussed off-line in BA was that some folks > in this discussion treat all the information exchanged by Anima as > intent, and other folks treat Intent as one subset of the several > varieties of information exchanged by Anima. I think that you are observing a real discord, and I think that we need some terminology to get a handle on things, but I also think it's premature. My impression is that we are very much in bootstrap/bottom-up mode here, and I think it's okay to remain in that mode for awhile longer. > change their busienss goals all that often). However, as the scope of > an Anima system becomes larger, and as people realize they can change > the system goals more frequently, I expect that the policy aspects will > change more frequently. I even expect to see automated systems > producing new policy goals. (Whether those systems are within Anima or > above it is irrelevant.) One could argue that the automated system is producing new policy statements (We both avoid using the word Intent here) for the network based upon some higher-level Intent. But, for other networks, these "policy statements" are produced by humans. (mcr licks the 15-year old wounds from the "policy WG"...) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVw02YoCLcPvd0N1lAQKdewf/b4QfyT8XO6hdLFMuWUhOT4pV5z1I0btb flA2wRnS6vuZLQnCIxxguxVjfIPcpNiNAKRrPL6FlNsgXZ1dFYntI3p4v5KgIvX5 k0fgllTegqOAJqBYPNGUI5xWk66ff4tu+AMUm5IOD30re1D+32Zn5JioV/v1qpls yxWZbSd1hqyq5Kyq/Ok1RVsTHJmaj6OEWKvxUYgj+zXB5NdYXtXj84Y7d3eHzsFW R7iVbmwf1h6YCR0FdWTT5mAsvgHExFLfm9GarHeuusc5CPmtHQeZ3idRFOIHy4Qb kf9iN3pK95R1DnCEgicD7V0egaiyj7ybZASLat9oRPapKXDFWKWdBQ== =/mMp -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Apr 12 13:12:50 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3ECE12EA8C for ; Tue, 12 Apr 2016 13:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 z6uxJ7S0zUJz for ; Tue, 12 Apr 2016 13:12:47 -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 7AE2F12EA6F for ; Tue, 12 Apr 2016 13:12:46 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 0D713B58DA4F1; Tue, 12 Apr 2016 20:12:40 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u3CKChsB013541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Apr 2016 20:12:43 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u3CKCg2B007619 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Apr 2016 22:12:42 +0200 Received: from [135.224.195.23] (135.239.27.38) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 12 Apr 2016 22:12:42 +0200 To: EXT Michael Richardson , "Joel M. Halpern" References: <570C8076.8030308@gmail.com> <570CB69D.40605@alcatel-lucent.com> <570D152F.50802@joelhalpern.com> <28569.1460483684@obiwan.sandelman.ca> From: Laurent Ciavaglia Organization: Bell Labs Message-ID: <570D56B9.3080908@alcatel-lucent.com> Date: Tue, 12 Apr 2016 22:12:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <28569.1460483684@obiwan.sandelman.ca> Content-Type: multipart/alternative; boundary="------------030706070108010408040302" X-Originating-IP: [135.239.27.38] Archived-At: Cc: Laurent Ciavaglia , anima , "Michael Behringer \(mbehring\)" Subject: Re: [Anima] Intent Discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 12 Apr 2016 20:12:49 -0000 --------------030706070108010408040302 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit On 12/04/2016 19:54, EXT Michael Richardson wrote: > Joel M. Halpern wrote: > > One of the points that was discussed off-line in BA was that some folks > > in this discussion treat all the information exchanged by Anima as > > intent, and other folks treat Intent as one subset of the several > > varieties of information exchanged by Anima. > > I think that you are observing a real discord, and I think that we need some > terminology to get a handle on things, but I also think it's premature. > > My impression is that we are very much in bootstrap/bottom-up mode here, and > I think it's okay to remain in that mode for awhile longer. Yes... maybe... (for the "premature" / "that mode thing"). I think it is worth/instructive to have those discussions on "intent" / other "non-chartered" items now and to continue them. Maybe not only (or not at all) in the ANIMA mailing list... NMRG would be glad to host such discussions and interactions. There has been a series of NMRG meetings on autonomic networking prior to the UCAN BoF and ANIMA WG creation. We could easily re-activate them. (see my upcoming post on the NMRG list). Another perspective is that ANIMA charter "ends" in Q4-2016, so it's seems timely to engage into future ((potential) items discussions and orientations. It doesn't mean that the chartered items/WG documents will not progress (and such discussions should not hinder their development), I see these activities complementary to each other. Best regards, Laurent. > > > change their busienss goals all that often). However, as the scope of > > an Anima system becomes larger, and as people realize they can change > > the system goals more frequently, I expect that the policy aspects will > > change more frequently. I even expect to see automated systems > > producing new policy goals. (Whether those systems are within Anima or > > above it is irrelevant.) > > One could argue that the automated system is producing new policy statements > (We both avoid using the word Intent here) for the network based upon some > higher-level Intent. > > But, for other networks, these "policy statements" are produced by humans. > > (mcr licks the 15-year old wounds from the "policy WG"...) > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > -- Laurent Ciavaglia Senior Research Manager Bell Labs, Nokia +33 160 402 636 Route de Villejust | 91620 Nozay | France LinkedIn: laurentciavaglia --------------030706070108010408040302 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit
On 12/04/2016 19:54, EXT Michael Richardson wrote:
Joel M. Halpern <jmh@joelhalpern.com> wrote:
    > One of the points that was discussed off-line in BA was that some folks
    > in this discussion treat all the information exchanged by Anima as
    > intent, and other folks treat Intent as one subset of the several
    > varieties of information exchanged by Anima.

I think that you are observing a real discord, and I think that we need some
terminology to get a handle on things, but I also think it's premature.

My impression is that we are very much in bootstrap/bottom-up mode here, and
I think it's okay to remain in that mode for awhile longer.

Yes... maybe... (for the "premature" / "that mode thing").
I think it is worth/instructive to have those discussions on "intent" / other "non-chartered" items now and to continue them. Maybe not only (or not at all) in the ANIMA mailing list...
NMRG would be glad to host such discussions and interactions. There has been a series of NMRG meetings on autonomic networking prior to the UCAN BoF and ANIMA WG creation. We could easily re-activate them. (see my upcoming post on the NMRG list).
Another perspective is that ANIMA charter "ends" in Q4-2016, so it's seems timely to engage into future ((potential) items discussions and orientations.
It doesn't mean that the chartered items/WG documents will not progress (and such discussions should not hinder their development), I see these activities complementary to each other.

Best regards, Laurent.


    > change their busienss goals all that often).  However, as the scope of
    > an Anima system becomes larger, and as people realize they can change
    > the system goals more frequently, I expect that the policy aspects will
    > change more frequently.  I even expect to see automated systems
    > producing new policy goals.  (Whether those systems are within Anima or
    > above it is irrelevant.)

One could argue that the automated system is producing new policy statements
(We both avoid using the word Intent here) for the network based upon some
higher-level Intent.

But, for other networks, these "policy statements" are produced by humans.

(mcr licks the 15-year old wounds from the "policy WG"...)

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

--

Laurent Ciavaglia

Senior Research Manager

Bell Labs, Nokia

 

+33 160 402 636

Route de Villejust | 91620 Nozay | France

LinkedIn: laurentciavaglia

 

--------------030706070108010408040302-- From nobody Tue Apr 12 16:45:59 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B5212D1B4 for ; Tue, 12 Apr 2016 16:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 2iPsCPOIY3vu for ; Tue, 12 Apr 2016 16:45:55 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAF1F12D1B3 for ; Tue, 12 Apr 2016 16:45:54 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id g184so46976868lfb.3 for ; Tue, 12 Apr 2016 16:45:54 -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; bh=LZPZSlzQwqQuKVjTbpNrr55n3y+xa/ulysAV/XEL730=; b=eStmtIsL0/2Ev/8fiNmD5rfpscg5Ml2njqXAAW8GaMgTDBwohc1Oszi2KHRO+h0N2p gx8L9Xzp2Vuj0fOuF/VjS2PtsCmT4pW7+RCa88LO3YyRZRCcj2KEXtPt5r0gJIWJ75pW UnMa2uCztvAOxCtV0CV/oJEJv+d5fARDQSssvry2wDOz1QoVNYlO7ky+tBo2d+WEbzk5 jrIl9IokpVndFp8TTw6dyFROX6FA+8yFFxCTToKVOxwdcA66+GE+LM6irc3S86OkEYFk dqaErtLvMCLzd2z9EBU90rtAC0FbUKfy6/PfdT0JdXceCIlJcv3hZGsbA5EPXU6XX7uC R6rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=LZPZSlzQwqQuKVjTbpNrr55n3y+xa/ulysAV/XEL730=; b=TLGkTtrHPACZzEA0Mtvg6zXIMFBJr1BMEV4wBL0I5t+EYk1AvpDnCuswT2k3ZMOioO 3ch9w85WYW/zXcbveNqRm1x90PhPPeMhsupLzWtBb1SqwS8Zpp7LmlAySeXorDX98/YA /yu1hmjEgleNiQ0O812RktNC82uqtX5M04S+aHJh3Mq//31kMcDrN+gKG+4Q/t0b2Qwm z1XxiaPRWThXx44LkdRozCoK1arWn9lE4bX+o7MFUFEv695uV+d/AC0QYCDTsBMTzJmd fhmEJEr8N7LBXlDwHl2DbY2SswRUAGCrmnFzvDcUojrisLPd/8NFVAHRghTWZ44U2BSx +q3A== X-Gm-Message-State: AOPr4FUcBM7fWCmNBWKId4ozAwdANC+yM5RcSLtemzAQeafYBqT2vqEy7pkycjIoIWTrEAnrLSpl1UGAP7d/uQ== MIME-Version: 1.0 X-Received: by 10.25.165.140 with SMTP id o134mr2796939lfe.35.1460504753084; Tue, 12 Apr 2016 16:45:53 -0700 (PDT) Received: by 10.25.22.19 with HTTP; Tue, 12 Apr 2016 16:45:52 -0700 (PDT) In-Reply-To: <57076BAE.2070807@alcatel-lucent.com> References: <57070C20.9070408@gmail.com> <57076BAE.2070807@alcatel-lucent.com> Date: Tue, 12 Apr 2016 16:45:52 -0700 Message-ID: From: John Strassner To: Laurent Ciavaglia , John Strassner Content-Type: multipart/alternative; boundary=001a11410a0e001eaa05305243f6 Archived-At: Cc: "jmh.direct" , Anima WG , "Joel M. Halpern" , "Liubing \(Leo\)" Subject: Re: [Anima] GRASP, discovery, and roles X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 12 Apr 2016 23:45:58 -0000 --001a11410a0e001eaa05305243f6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Laurent, > I think it should be explicit in the specification of the ASA > life-cycle what it does... > > This set of "roles" and life-cycle must be fixed and specified > by the standard...because these are special roles/objectives > that must be supported / understood by all ASAs / or ANodes... Agreed! > What seems not fully defined yet is precisely a complete ASA > life-cycle (cf discussion and drafts on the topic) and the > minimal set of roles to deploy and have an autonomic networks > ready for operation / operating. I think that we need at least two things here: 1) specification of the lifecycle of Autonomic Functions, and 2) specification of the management of those Autonomic Functions > Shall we upgrade the reference model document section on theory > of operations with these aspects or should it be another doc? > > FYI, draft-peloso-anima-autonomic-function attempts to describe such a life-cycle. I think that the reference model needs updating; once that is updated, then I think that the above draft (day in the life) needs to update and expand on the that. I'd like to help in both. However, there is another additional issue. Draft-peloso talks about the power of installing autonomic functions beyond a simple known set that are "pre-installed". This makes me think of emergent behavior. It is one thing to support desired known behavior that is pre-defined; it is quite another to support new services that were not known when the autonomic network was originally installed. The latter is much more difficult, and perhaps beyond our current scope, but it would be nice if we could at least anticipate and start to understand its needs so that we do not box ourselves into a corner regards, John On Fri, Apr 8, 2016 at 1:28 AM, Laurent Ciavaglia < laurent.ciavaglia@nokia.com> wrote: > Hello, > > I think it should be explicit in the specification of the ASA life-cycle > what it does when it boots (and in other phases as well): > e.g. discover / register to (entities playing) special roles such as > registrar, coordination, intent, knowledge index... > > This set of "roles" and life-cycle must be fixed and specified by the > standard, not left open to ASA developers' creativity because these are > special roles/objectives that must be supported / understood by all ASAs = / > or ANodes (proxy) agents. > > What seems not fully defined yet is precisely a complete ASA life-cycle > (cf discussion and drafts on the topic) and the minimal set of roles to > deploy and have an autonomic networks ready for operation / operating. > > Shall we upgrade the reference model document section on theory of > operations with these aspects or should it be another doc? > > FYI, draft-peloso-anima-autonomic-function attempts to describe such a > life-cycle. > > Best regards, Laurent. > > On 08/04/2016 03:40, EXT Brian E Carpenter wrote: > > On 08/04/2016 11:52, jmh.direct wrote: > > As I understand it, if an entity has at least one cached answer, it will = send me that and stop propagating mybrequedt. > > Actually I don't think that's how I coded it but that hardly matters; we = can > review the spec to be unambiguous on that point. > > But there's another point here which may need to be made a formal require= ment > with some better terminology. > > You can discover an objective without supporting it yourself. For example= , > we want exactly one node to support the AN_Registrar objective but any ot= her > node may need to discover it. That was kind of intuitive when coding my > prototype but we need to make it explicit. > > Brian > > > And it can't tell if the answer is insufficient.Yours,Joel > > > Sent via the Samsung Galaxy S=C2=AE 6, an AT&T 4G LTE smartphone-------- = Original message --------From: "Liubing (Leo)" Date: 4/7/2016 7:38 PM (GMT-03:00) To: "Joel M. Hal= pern" , Anima WG Subject: RE: [Anima] GRASP, discovery, and roles > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com ] > Sent: Thursday, April 07, 2016 7:25 PM > To: Liubing (Leo); Anima WG > Subject: Re: [Anima] GRASP, discovery, and roles > > If I could just ignore some responses, and be sure I would get the other > responses, that would be a way to solve the problem. But as far as I > understand GRASP< that isn't what happens. My discovery might prompt > several answers, but along any given branch it stops when it hits any res= ponder, > even if they are just another participant. > > [Bing] This is the "multiple responses" open issue we used to discuss. > GRASP will not stop receiving other responses, (actually it just can't), = according to discussion in last ietf, people tended to handle the multiple = responses to ASA, who will decide to use which discovered result. I think w= e'll need to clearly specify the behavior in the API document. > > B.R. > Bing > > > Yours, > Joel > > On 4/7/16 6:16 PM, Liubing (Leo) wrote: > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com ] > Sent: Thursday, April 07, 2016 6:57 PM > To: Liubing (Leo); Anima WG > Cc: Brian E Carpenter > Subject: Re: [Anima] GRASP, discovery, and roles > > Given that I register in order to participate in teh discovery, it > seems that I could just as easily end up "discovering" another > participant when what I need is the coordinator. > > [Bing] In terms of GRASP terminology, what you need is the "coordination > > function/service", and the one who response you, implies it is a "coordin= ator" > or whatever role which could provide identical coordination function/serv= ice as > the "coordinator". So, just don't worry about the one who response you is > "another" guy who is not qualified to serve you. > > Did I capture your concern correctly? > > B.R. > Bing > > > Am I mis-reading it? > > Yours, > Joel > > On 4/7/16 5:48 PM, Liubing (L > > > _______________________________________________ > Anima mailing listAnima@ietf.orghttps://www.ietf.org/mailman/listinfo/ani= ma > > _______________________________________________ > Anima mailing listAnima@ietf.orghttps://www.ietf.org/mailman/listinfo/ani= ma > > > -- > > Laurent Ciavaglia > > Senior Research Manager > > Bell Labs, Nokia > > > > +33 160 402 636 > > Route de Villejust | 91620 Nozay | France > > LinkedIn: laurentciavaglia > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > > --=20 regards, John --001a11410a0e001eaa05305243f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Laurent,

> I=C2=A0think it should be explicit in the specificati= on of the ASA
> life-cycle w= hat it does...
>
> This set of "roles" and life-cycle= must be fixed and specified
&g= t;=C2=A0by the standard...because these are special roles/objecti= ves
> that must be supported= / understood by all ASAs / or ANodes...

Agreed!

>=C2=A0What seems not fully defined yet is= precisely a complete ASA
> = life-cycle (cf discussion and drafts on the topic) and the
>=C2=A0minimal set of roles to deploy a= nd have an autonomic networks
&= gt;=C2=A0ready for operation / operating.

<= div>I think that we need at least two things here:

=C2=A0=C2=A0 1) specification of the lifecycle of Autonomic Functions, and=
=C2=A0=C2=A0 2) specification of the management of those Autonom= ic Functions

> = Shall we upgrade the reference model document section on theory
>=C2=A0of operations with these as= pects or should it be another doc?
>
> FYI, draft-peloso-anima-= autonomic-function attempts to describe such a life-cycle.

I think that the reference model needs updating;= once that is updated, then I think that the
above draft (day in = the life) needs to update and expand on the that.

= I'd like to help in both.

However, there is an= other additional issue. Draft-peloso talks about the power of installing
autonomic functions beyond a simple known set that are "pre-in= stalled". This makes me think
of emergent behavior. It is on= e thing to support desired known behavior that is pre-defined;
it= is quite another to support new services that were not known when the auto= nomic network
was originally installed. The latter is much more d= ifficult, and perhaps beyond our current
scope, but it would be n= ice if we could at least anticipate and start to understand its needs
=
so that we do not box ourselves into a corner


=
regards,
John

On Fri, Apr 8, 2016 at 1:28 AM, Laurent Ciavaglia <laurent.ciavaglia@nokia.com> wrote:
=20 =20 =20
Hello,

I think it should be explicit in the specification of the ASA life-cycle what it does when it boots (and in other phases as well):
=C2=A0=C2=A0=C2=A0 e.g. discover / register to (entities playing) spe= cial roles such as registrar, coordination, intent, knowledge index...

This set of "roles" and life-cycle must be fixed and specif= ied by the standard, not left open to ASA developers' creativity because these are special roles/objectives that must be supported / understood by all ASAs / or ANodes (proxy) agents.

What seems not fully defined yet is precisely a complete ASA life-cycle (cf discussion and drafts on the topic) and the minimal set of roles to deploy and have an autonomic networks ready for operation / operating.

Shall we upgrade the reference model document section on theory of operations with these aspects or should it be another doc?

FYI, draft-peloso-anima-autonomic-function attempts to describe such a life-cycle.

Best regards, Laurent.

On 08/04/2016 03:40, EXT Brian E Carpenter wrote:
On 08/04/2016 11:52, jmh.direct wrote:

As I understand it, if an entity has at least one cached answe=
r, it will send me that and stop propagating mybrequedt.

Actually I don't think that's how I coded it but that ha=
rdly matters; we can
review the spec to be unambiguous on that point.

But there's another point here which may need to be made a formal requi=
rement
with some better terminology.

You can discover an objective without supporting it yourself. For example,
we want exactly one node to support the AN_Registrar objective but any othe=
r
node may need to discover it. That was kind of intuitive when coding my
prototype but we need to make it explicit.

    Brian


And it can't tell if the answer is insufficient.Yours,Joel


Sent via the Samsung Galaxy S=C2=AE 6, an AT&T 4G LTE smartphone-------=
- Original message --------From: "Liubing (Leo)" <leo.liubing@huawei.com><=
/a> Date: 4/7/2016  7:38 PM  (GMT-03:00) To: "Joel M. Halpern" <jmh@joelhalpern.=
com>, Anima WG &=
lt;anima@ietf.org> Subject: RE: [Anima] GRASP, discovery, and roles=
=20

-----Original Message-----
From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
Sent: Thursday, April 07, 2016 7:25 PM
To: Liubing (Leo); Anima WG
Subject: Re: [Anima] GRASP, discovery, and roles

If I could just ignore some responses, and be sure I would get the other
responses, that would be a way to solve the problem.  But as far as I
understand GRASP< that isn't what happens.  My discovery might promp=
t
several answers, but along any given branch it stops when it hits any respo=
nder,
even if they are just another participant.

[Bing] This is the "multiple responses" open issue w=
e used to discuss.=20
GRASP will not stop receiving other responses, (actually it just can't)=
, according to discussion in last ietf, people tended to handle the multipl=
e responses to ASA, who will decide to use which discovered result. I think=
 we'll need to clearly specify the behavior in the API document.

B.R.
Bing


Yours,
Joel

On 4/7/16 6:16 PM, Liubing (Leo) wrote:

-----Original Message-----
From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
Sent: Thursday, April 07, 2016 6:57 PM
To: Liubing (Leo); Anima WG
Cc: Brian E Carpenter
Subject: Re: [Anima] GRASP, discovery, and roles

Given that I register in order to participate in teh discovery, it
seems that I could just as easily end up "discovering" another
participant when what I need is the coordinator.

[Bing] In terms of GRASP terminology, what you need is the=
 "coordination

function/service", and the one who response you, implie=
s it is a "coordinator"
or whatever role which could provide identical coordination function/servic=
e as
the "coordinator". So, just don't worry about the one who res=
ponse you is
"another" guy who is not qualified to serve you.

Did I capture your concern correctly?

B.R.
Bing


Am I mis-reading it?

Yours,
Joel

On 4/7/16 5:48 PM, Liubing (L


_______________________________________________
Anima mailing list
Anima@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/anima

_______________________________________________
Anima mailing list
Anima@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/anima

--
=20 =20 =20 =20 =20 =20 =20 =20 =20 =20

Laurent Ciavaglia

Senior Research Manager

Bell Labs, Nokia

=C2=A0

+33=C2=A0160 402=C2=A0636

Route de Villejust | 91620 Nozay | France

LinkedIn: laurentciavaglia=

=C2= =A0


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




--
regards,
John
--001a11410a0e001eaa05305243f6-- From nobody Tue Apr 12 18:27:20 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3417112D96A for ; Tue, 12 Apr 2016 18:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 8N7aM_k7EuUG for ; Tue, 12 Apr 2016 18:27:16 -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 312BA12D968 for ; Tue, 12 Apr 2016 18:27:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHF60988; Wed, 13 Apr 2016 01:27:13 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 13 Apr 2016 02:27:12 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Wed, 13 Apr 2016 09:27:08 +0800 From: Sheng Jiang To: "anima@ietf.org" Thread-Topic: Cross-RG activity coordination on Intent Based Networking (IBN) Thread-Index: AQHRlRE+DxxgetbJuEq+1FV65r3/tp+HHG+w Date: Wed, 13 Apr 2016 01:27:08 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927C6534CB@NKGEML515-MBX.china.huawei.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.99.197] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B927C6534CBNKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.570DA072.0047, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 44b502473a1bdc278efcd5e73bfa2f3e Archived-At: Subject: [Anima] FW: Cross-RG activity coordination on Intent Based Networking (IBN) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 13 Apr 2016 01:27:19 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B927C6534CBNKGEML515MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEFOSU1BLA0KV2UgaGF2ZSBhIGxvdCBkaXNjdXNzaW9uIHJlZ2FyZGluZyB0byB0aGUgSW50 ZW50LiBTbyB5b3UgZ3V5cyBtYXkgYWxzbyBiZSBpbnRlcmVzdGVkICBpbiB0aGUgYmVsb3cgZXZl bnRzLg0KUmVnYXJkcywNClNoZW5nDQpTdWJqZWN0Og0KDQpDcm9zcy1SRyBhY3Rpdml0eSBjb29y ZGluYXRpb24gb24gSW50ZW50IEJhc2VkIE5ldHdvcmtpbmcgKElCTikNCg0KRGF0ZToNCg0KV2Vk LCAxMyBBcHIgMjAxNiAwMDo1NzoyMSArMDIwMA0KDQpGcm9tOg0KDQpMYXVyZW50IENpYXZhZ2xp YSA8TGF1cmVudC5DaWF2YWdsaWFAYWxjYXRlbC1sdWNlbnQuY29tPjxtYWlsdG86TGF1cmVudC5D aWF2YWdsaWFAYWxjYXRlbC1sdWNlbnQuY29tPg0KDQpPcmdhbml6YXRpb246DQoNCkJlbGwgTGFi cw0KDQpUbzoNCg0Kbm1yZ0BpcnRmLm9yZzxtYWlsdG86bm1yZ0BpcnRmLm9yZz4gPG5tcmdAaXJ0 Zi5vcmc+PG1haWx0bzpubXJnQGlydGYub3JnPg0KDQpDQzoNCg0KS29oZWkgU2hpb21vdG8gPHNo aW9tb3RvLmtvaGVpQGxhYi5udHQuY28uanA+PG1haWx0bzpzaGlvbW90by5rb2hlaUBsYWIubnR0 LmNvLmpwPiwgS2luZywgRGFuaWVsIDxkLmtpbmdAbGFuY2FzdGVyLmFjLnVrPjxtYWlsdG86ZC5r aW5nQGxhbmNhc3Rlci5hYy51az4sIExpc2FuZHJvIFphbWJlbmVkZXR0aSBHcmFudmlsbGUgPGdy YW52aWxsZUBpbmYudWZyZ3MuYnI+PG1haWx0bzpncmFudmlsbGVAaW5mLnVmcmdzLmJyPiwgTGF1 cmVudCBDaWF2YWdsaWEgPExhdXJlbnQuQ2lhdmFnbGlhQG5va2lhLmNvbT48bWFpbHRvOkxhdXJl bnQuQ2lhdmFnbGlhQG5va2lhLmNvbT4NCg0KDQoNCkRlYXIgTk1SRywNCg0KSW50ZW50IEJhc2Vk IE5ldHdvcmtpbmcgYXNwaXJlcyBhdCByaXNpbmcgbmV0d29yayBtYW5hZ2VhYmlsaXR5IHRvIGEg aGlnaGVyIGxldmVsLg0KQXMgc3VjaCwgdGhlIHZhcmlvdXMgZm9ybXMgb2YgSUJOIGNvbnRpbnVl IHRvIGJlIGEgY29tcGVsbGluZyBhcmVhIG9mIHJlc2VhcmNoIGFuZCB0ZWNobm9sb2d5IGRldmVs b3BtZW50Lg0KWWV0LCB0aGUgSUJOIHRlcm0gbWF5IGNvbnZleSBkaWZmZXJlbnQgbWVhbmluZ3Mg YW5kIHJlZmVyIHRvIGRpZmZlcmVudCBjb25jZXB0cyBvciBhcHByb2FjaGVzLCBlLmcuIGFzIGlu IEFOSU1BIFdHLCBTVVBBIChCb0YpLCBJQk5FTU8sIG9yIFNETiBSRy4uLg0KVGh1cywgd2UgYmVs aWV2ZSBzb21lIGNvb3JkaW5hdGlvbiBhbW9uZyBSRy9XRyBjYW4gZGVsaXZlciBhZGRpdGlvbmFs IHZhbHVlIHRvIHRoZSBjb21tdW5pdHkuDQpKb2ludGx5IHdpdGggdGhlIFNETiBSRywgd2Ugd291 bGQgbGlrZSB0byBpbXB1bHNlIGFuIGFjdGl2aXR5IG9uIElCTiB0byBkaXNjdXNzIHRoZSBvYmpl Y3RpdmVzLCBzY29wZSBhbmQga2ljayBzdGFydCB0aGlzIGVmZm9ydC4NCg0KVGhlIGl0ZW1zIGxp c3RlZCBiZWxvdyBjYW4gaGVscCB0byBnZXQgdGhpbmdzIHN0YXJ0ZWQ6DQogICAgLVdoYXQgYXJl IHRoZSBkZWZpbml0aW9ucyBvZiBJbnRlbnQvSUJOPyBlLmcuIGluIFNVUEEsIEFOSU1BLCBTRE4s IE5GViwgSW9UIHNwYWNlcy4uLg0KICAgIC1XaGF0IGFyZSB0aGUgYWxpZ25tZW50L2NvbW1vbmFs aXRpZXMgYW5kIGRpZmZlcmVuY2VzIGFtb25nIHRoZW0sIGFuZCB0aGUgaW1wbGljYXRpb25zIGZy b20gdGVjaG5vbG9neSwgc3RhbmRhcmQgYW5kIGJ1c2luZXNzIHBlcnNwZWN0aXZlcz8NCiAgICAt V2hhdCBhcmUgdGhlIGZ1bmN0aW9uYWxpdHkgLyBjb21wb25lbnRzIG9mIGFuIGludGVudCBiYXNl ZCBzeXN0ZW0/DQogICAgLUlzIGFuIGVuZC10by1lbmQsIGNvbXByZWhlbnNpdmUgaW50ZW50IGJh c2VkIHN5c3RlbSBmZWFzaWJsZT8gRG9lcyBpdCBtYWtlIHNlbnNlPw0KICAgIC1Ib3cgY2FuIGRp ZmZlcmVudCB0ZWNobm8tc3BlY2lmaWMgLyBoZXRlcm9nZW5lb3VzIHNvdXJjZXMgb2YgaW50ZW50 IChkZWZpbml0aW9ucyAvIGJsb2NrcykgaW50ZXItb3BlcmF0ZSwgaW4gaW50cmEtIGFuZCBpbnRl ci1kb21haW5zPw0KICAgIC1XaGF0IGFyZSB0aGUgKGtleSkgYXJlYXMgb2YgcmVzZWFyY2g/IGxh bmd1YWdlcywgc2VtYW50aWNzL29udG9sb2dpZXMsIGh1bWFuIGZhY3RvcnMvSE5JLCBtb2RlbC1k cml2ZW4tZGV2ZWxvcG1lbnQsIHBvbGljeSByZWZpbmVtZW50Li4uDQogICAgLVdoYXQgYXJlIGV4 YW1wbGVzIG9mIGFwcGxpY2F0aW9uOiBlLmcuIHRlY2hub2xvZ3kgc3BlY2lmaWMgb3IgZ2VuZXJp YzogZS5nLiBpbiBORlYsIFNETiwgYXV0b25vbWljcywgSW9ULi4uDQogICAgLVdoYXQgcmVsYXRp b25zaGlwcy9jb25zaXN0ZW5jeSBhbW9uZyB0aG9zZSBhcHBsaWNhdGlvbnM/IGkuZS4gdG93YXJk cyBhIGNvbXByZWhlbnNpdmUgdmlldyBvZiBhICJHZW5lcmFsaXplZCBJQk4iDQogICAgLUxpc3Qg b2YgcmVwcmVzZW50YXRpdmUgdXNlIGNhc2VzIG9mIElCTi4NCiAgICAtUHJhY3RpY2FsIGV4cGVy aWVuY2VzLCBkZXZlbG9wbWVudHMsIHRvb2xzIG9uIElCTi4NCg0KVGhlIG5ldHdvcmsgbWFuYWdl bWVudCBjb21tdW5pdHkgaGFzIGV4dGVuc2l2ZSBrbm93bGVkZ2UgYW5kIGV4cGVydGlzZSBpbiB0 aGUgYXJlYSAodGhpbmsgcG9saWN5IGJhc2VkIG1hbmFnZW1lbnQpIHRoYXQgY2FuIHByb3ZlIHZl cnkgdXNlZnVsIGluIHRoZSBmb3Jlc2VlbiBpbnZlc3RpZ2F0aW9ucy4NCk5ldHdvcmsgbWFuYWdl bWVudCBpcyBhbHNvIHRyYW5zdmVyc2UgdG8gdGVjaG5vbG9naWVzIChlLmcuIFNETiwgTkZWLCBh dXRvbm9taWNzLi4uKSwgcHJvdmlkaW5nIGEgZGlmZmVyZW50IHBlcnNwZWN0aXZlIHRvIHRoZSBw cm9ibGVtIGF0IGhhbmQuDQoNCi0tLQ0KVGhlIGZpcnN0IG91dGNvbWUgb2YgdGhpcyBhY3Rpdml0 eSB3aWxsIGJlIGRpc2N1c3NlZCBpbiB0aGUgam9pbnQgbWVldGluZyBiZXR3ZWVuIFNETiwgTkZW IGFuZCBOTSByZXNlYXJjaCBncm91cHMgdG8gYmUgaGVsZCBhdCBJRVRGOTYvQmVybGluIChUQkMp Lg0KDQpUaGlzIHRvcGljIGlzIHBhcnQgb2YgdGhlIE5NUkcgbWVldGluZyBhdCBOT01TIDIwMTYg KGh0dHA6Ly9ub21zMjAxNi5pZWVlLW5vbXMub3JnLCAyNS0yOSBBcHJpbCAyMDE2LCBJc3RhbmJ1 bCkuDQoNCk90aGVyIGV2ZW50cyBhcmUgaW4gdGhlIHBpcGUsIHNvIHN0YXkgdHVuZWQhDQoNCg0K QmVzdCByZWdhcmRzLA0KTGlzYW5kcm8gYW5kIExhdXJlbnQgKE5NUkcgY2hhaXJzKSwgdG9nZXRo ZXIgd2l0aCBLb2hlaSBhbmQgRGFuIChTRE4gUkcgY2hhaXJzKS4NCi0tLQ0KDQotLQ0KDQpMYXVy ZW50IENpYXZhZ2xpYQ0KU2VuaW9yIFJlc2VhcmNoIE1hbmFnZXINCkJlbGwgTGFicywgTm9raWEN Cg0KKzMzIDE2MCA0MDIgNjM2DQpSb3V0ZSBkZSBWaWxsZWp1c3QgfCA5MTYyMCBOb3pheSB8IEZy YW5jZQ0KTGlua2VkSW46IGxhdXJlbnRjaWF2YWdsaWE8aHR0cDovL2ZyLmxpbmtlZGluLmNvbS9p bi9sYXVyZW50Y2lhdmFnbGlhLz4NCg0KDQoNCg0K --_000_5D36713D8A4E7348A7E10DF7437A4B927C6534CBNKGEML515MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW4tdG9wOjBj bTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MTAuMHB0Ow0KCW1hcmdpbi1s ZWZ0OjBjbTsNCglsaW5lLWhlaWdodDoxMTUlOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMzMzMzMzO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjU5NS4zcHQgODQxLjlwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAu ODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2xpbmUtaGVpZ2h0 OjExNSU7Y29sb3I6IzFGNDk3RCI+SGksIEFOSU1BLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtsaW5lLWhlaWdodDoxMTUlO2NvbG9yOiMxRjQ5N0QiPldlIGhhdmUgYSBsb3QgZGlzY3Vz c2lvbiByZWdhcmRpbmcgdG8gdGhlIEludGVudC4gU28geW91IGd1eXMgbWF5IGFsc28gYmUgaW50 ZXJlc3RlZCZuYnNwOyBpbiB0aGUgYmVsb3cgZXZlbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtsaW5lLWhlaWdodDoxMTUlO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2xpbmUtaGVpZ2h0OjExNSU7Y29sb3I6IzFGNDk3RCI+U2hl bmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4N Cjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAi IGNlbGxwYWRkaW5nPSIwIiBzdHlsZT0ibWFyZ2luLWxlZnQ6OS42cHQiPg0KPHRib2R5Pg0KPHRy Pg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxp Z246cmlnaHQiPjxiPjxzcGFuIGxhbmc9IkVOLUdCIj5TdWJqZWN0Og0KPC9zcGFuPjwvYj48Yj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bGluZS1oZWlnaHQ6MTE1 JTtmb250LWZhbWlseTrlrovkvZMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8L3RkPg0K PHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiI+Q3Jvc3MtUkcgYWN0aXZpdHkgY29vcmRpbmF0aW9uIG9uIElu dGVudCBCYXNlZCBOZXR3b3JraW5nIChJQk4pPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtsaW5lLWhlaWdodDoxMTUlO2ZvbnQtZmFtaWx5OuWui+S9kyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgbm93cmFwPSIi IHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+PHNw YW4gbGFuZz0iRU4tR0IiPkRhdGU6DQo8L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtsaW5lLWhlaWdodDoxMTUlO2ZvbnQtZmFtaWx5OuWui+S9 kyI+PG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6 MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC Ij5XZWQsIDEzIEFwciAyMDE2IDAwOjU3OjIxICYjNDM7MDIwMDwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bGluZS1oZWlnaHQ6MTE1JTtmb250LWZhbWls eTrlrovkvZMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRk IG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmln aHQiPjxiPjxzcGFuIGxhbmc9IkVOLUdCIj5Gcm9tOg0KPC9zcGFuPjwvYj48Yj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bGluZS1oZWlnaHQ6MTE1JTtmb250LWZh bWlseTrlrovkvZMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8L3RkPg0KPHRkIHN0eWxl PSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiI+TGF1cmVudCBDaWF2YWdsaWEgPGEgaHJlZj0ibWFpbHRvOkxhdXJlbnQuQ2lh dmFnbGlhQGFsY2F0ZWwtbHVjZW50LmNvbSI+DQombHQ7TGF1cmVudC5DaWF2YWdsaWFAYWxjYXRl bC1sdWNlbnQuY29tJmd0OzwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2xpbmUtaGVpZ2h0OjExNSU7Zm9udC1mYW1pbHk65a6L5L2TIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWdu PSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj48c3BhbiBsYW5n PSJFTi1HQiI+T3JnYW5pemF0aW9uOg0KPC9zcGFuPjwvYj48Yj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bGluZS1oZWlnaHQ6MTE1JTtmb250LWZhbWlseTrlrovk vZMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5n OjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiI+QmVsbCBMYWJzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtsaW5lLWhlaWdodDoxMTUlO2ZvbnQtZmFtaWx5OuWui+S9kyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgbm93cmFwPSIiIHZhbGlnbj0idG9wIiBz dHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxp Z249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+PHNwYW4gbGFuZz0iRU4tR0Ii PlRvOg0KPC9zcGFuPjwvYj48Yj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7bGluZS1oZWlnaHQ6MTE1JTtmb250LWZhbWlseTrlrovkvZMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvYj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PGEgaHJlZj0ibWFpbHRv Om5tcmdAaXJ0Zi5vcmciPm5tcmdAaXJ0Zi5vcmc8L2E+DQo8YSBocmVmPSJtYWlsdG86bm1yZ0Bp cnRmLm9yZyI+Jmx0O25tcmdAaXJ0Zi5vcmcmZ3Q7PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bGluZS1oZWlnaHQ6MTE1JTtmb250LWZhbWlseTrl rovkvZMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIG5v d3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQi PjxiPjxzcGFuIGxhbmc9IkVOLUdCIj5DQzoNCjwvc3Bhbj48L2I+PGI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2xpbmUtaGVpZ2h0OjExNSU7Zm9udC1mYW1pbHk6 5a6L5L2TIj48bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFk ZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiPktvaGVpIFNoaW9tb3RvIDxhIGhyZWY9Im1haWx0bzpzaGlvbW90by5rb2hlaUBsYWIu bnR0LmNvLmpwIj4NCiZsdDtzaGlvbW90by5rb2hlaUBsYWIubnR0LmNvLmpwJmd0OzwvYT4sIEtp bmcsIERhbmllbCA8YSBocmVmPSJtYWlsdG86ZC5raW5nQGxhbmNhc3Rlci5hYy51ayI+DQombHQ7 ZC5raW5nQGxhbmNhc3Rlci5hYy51ayZndDs8L2E+LCBMaXNhbmRybyBaYW1iZW5lZGV0dGkgR3Jh bnZpbGxlIDxhIGhyZWY9Im1haWx0bzpncmFudmlsbGVAaW5mLnVmcmdzLmJyIj4NCiZsdDtncmFu dmlsbGVAaW5mLnVmcmdzLmJyJmd0OzwvYT4sIExhdXJlbnQgQ2lhdmFnbGlhIDxhIGhyZWY9Im1h aWx0bzpMYXVyZW50LkNpYXZhZ2xpYUBub2tpYS5jb20iPg0KJmx0O0xhdXJlbnQuQ2lhdmFnbGlh QG5va2lhLmNvbSZndDs8L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtsaW5lLWhlaWdodDoxMTUlO2ZvbnQtZmFtaWx5OuWui+S9kyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4t R0IiPjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5EZWFyIE5NUkcsPGJyPg0KPGJyPg0KSW50ZW50 IEJhc2VkIE5ldHdvcmtpbmcgYXNwaXJlcyBhdCByaXNpbmcgbmV0d29yayBtYW5hZ2VhYmlsaXR5 IHRvIGEgaGlnaGVyIGxldmVsLjxicj4NCkFzIHN1Y2gsIHRoZSB2YXJpb3VzIGZvcm1zIG9mIElC TiBjb250aW51ZSB0byBiZSBhIGNvbXBlbGxpbmcgYXJlYSBvZiByZXNlYXJjaCBhbmQgdGVjaG5v bG9neSBkZXZlbG9wbWVudC48YnI+DQpZZXQsIHRoZSBJQk4gdGVybSBtYXkgY29udmV5IGRpZmZl cmVudCBtZWFuaW5ncyBhbmQgcmVmZXIgdG8gZGlmZmVyZW50IGNvbmNlcHRzIG9yIGFwcHJvYWNo ZXMsIGUuZy4gYXMgaW4gQU5JTUEgV0csIFNVUEEgKEJvRiksIElCTkVNTywgb3IgU0ROIFJHLi4u PGJyPg0KVGh1cywgd2UgYmVsaWV2ZSBzb21lIGNvb3JkaW5hdGlvbiBhbW9uZyBSRy9XRyBjYW4g ZGVsaXZlciBhZGRpdGlvbmFsIHZhbHVlIHRvIHRoZSBjb21tdW5pdHkuPGJyPg0KSm9pbnRseSB3 aXRoIHRoZSBTRE4gUkcsIHdlIHdvdWxkIGxpa2UgdG8gaW1wdWxzZSBhbiBhY3Rpdml0eSBvbiBJ Qk4gdG8gZGlzY3VzcyB0aGUgb2JqZWN0aXZlcywgc2NvcGUgYW5kIGtpY2sgc3RhcnQgdGhpcyBl ZmZvcnQuPGJyPg0KPGJyPg0KVGhlIGl0ZW1zIGxpc3RlZCBiZWxvdyBjYW4gaGVscCB0byBnZXQg dGhpbmdzIHN0YXJ0ZWQ6PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IC1XaGF0IGFyZSB0aGUgZGVm aW5pdGlvbnMgb2YgSW50ZW50L0lCTj8gZS5nLiBpbiBTVVBBLCBBTklNQSwgU0ROLCBORlYsIElv VCBzcGFjZXMuLi48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgLVdoYXQgYXJlIHRoZSBhbGlnbm1l bnQvY29tbW9uYWxpdGllcyBhbmQgZGlmZmVyZW5jZXMgYW1vbmcgdGhlbSwgYW5kIHRoZSBpbXBs aWNhdGlvbnMgZnJvbSB0ZWNobm9sb2d5LCBzdGFuZGFyZCBhbmQgYnVzaW5lc3MgcGVyc3BlY3Rp dmVzPzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAtV2hhdCBhcmUgdGhlIGZ1bmN0aW9uYWxpdHkg LyBjb21wb25lbnRzIG9mIGFuIGludGVudCBiYXNlZCBzeXN0ZW0/PGJyPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7IC1JcyBhbiBlbmQtdG8tZW5kLCBjb21wcmVoZW5zaXZlIGludGVudCBiYXNlZCBzeXN0 ZW0gZmVhc2libGU/IERvZXMgaXQgbWFrZSBzZW5zZT88YnI+DQombmJzcDsmbmJzcDsmbmJzcDsg LUhvdyBjYW4gZGlmZmVyZW50IHRlY2huby1zcGVjaWZpYyAvIGhldGVyb2dlbmVvdXMgc291cmNl cyBvZiBpbnRlbnQgKGRlZmluaXRpb25zIC8gYmxvY2tzKSBpbnRlci1vcGVyYXRlLCBpbiBpbnRy YS0gYW5kIGludGVyLWRvbWFpbnM/PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IC1XaGF0IGFyZSB0 aGUgKGtleSkgYXJlYXMgb2YgcmVzZWFyY2g/IGxhbmd1YWdlcywgc2VtYW50aWNzL29udG9sb2dp ZXMsIGh1bWFuIGZhY3RvcnMvSE5JLCBtb2RlbC1kcml2ZW4tZGV2ZWxvcG1lbnQsIHBvbGljeSBy ZWZpbmVtZW50Li4uPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IC1XaGF0IGFyZSBleGFtcGxlcyBv ZiBhcHBsaWNhdGlvbjogZS5nLiB0ZWNobm9sb2d5IHNwZWNpZmljIG9yIGdlbmVyaWM6IGUuZy4g aW4gTkZWLCBTRE4sIGF1dG9ub21pY3MsIElvVC4uLjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAt V2hhdCByZWxhdGlvbnNoaXBzL2NvbnNpc3RlbmN5IGFtb25nIHRob3NlIGFwcGxpY2F0aW9ucz8g aS5lLiB0b3dhcmRzIGEgY29tcHJlaGVuc2l2ZSB2aWV3IG9mIGEgJnF1b3Q7R2VuZXJhbGl6ZWQg SUJOJnF1b3Q7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IC1MaXN0IG9mIHJlcHJlc2VudGF0aXZl IHVzZSBjYXNlcyBvZiBJQk4uPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IC1QcmFjdGljYWwgZXhw ZXJpZW5jZXMsIGRldmVsb3BtZW50cywgdG9vbHMgb24gSUJOLjxicj4NCjxicj4NClRoZSBuZXR3 b3JrIG1hbmFnZW1lbnQgY29tbXVuaXR5IGhhcyBleHRlbnNpdmUga25vd2xlZGdlIGFuZCBleHBl cnRpc2UgaW4gdGhlIGFyZWEgKHRoaW5rIHBvbGljeSBiYXNlZCBtYW5hZ2VtZW50KSB0aGF0IGNh biBwcm92ZSB2ZXJ5IHVzZWZ1bCBpbiB0aGUgZm9yZXNlZW4gaW52ZXN0aWdhdGlvbnMuPGJyPg0K TmV0d29yayBtYW5hZ2VtZW50IGlzIGFsc28gdHJhbnN2ZXJzZSB0byB0ZWNobm9sb2dpZXMgKGUu Zy4gU0ROLCBORlYsIGF1dG9ub21pY3MuLi4pLCBwcm92aWRpbmcgYSBkaWZmZXJlbnQgcGVyc3Bl Y3RpdmUgdG8gdGhlIHByb2JsZW0gYXQgaGFuZC48YnI+DQo8YnI+DQotLS08YnI+DQpUaGUgZmly c3Qgb3V0Y29tZSBvZiB0aGlzIGFjdGl2aXR5IHdpbGwgYmUgZGlzY3Vzc2VkIGluIHRoZSBqb2lu dCBtZWV0aW5nIGJldHdlZW4gU0ROLCBORlYgYW5kIE5NIHJlc2VhcmNoIGdyb3VwcyB0byBiZSBo ZWxkIGF0IElFVEY5Ni9CZXJsaW4gKFRCQykuPGJyPg0KPGJyPg0KVGhpcyB0b3BpYyBpcyBwYXJ0 IG9mIHRoZSBOTVJHIG1lZXRpbmcgYXQgTk9NUyAyMDE2ICg8YSBocmVmPSJodHRwOi8vbm9tczIw MTYuaWVlZS1ub21zLm9yZyI+aHR0cDovL25vbXMyMDE2LmllZWUtbm9tcy5vcmc8L2E+LCAyNS0y OSBBcHJpbCAyMDE2LCBJc3RhbmJ1bCkuPGJyPg0KPGJyPg0KT3RoZXIgZXZlbnRzIGFyZSBpbiB0 aGUgcGlwZSwgc28gc3RheSB0dW5lZCE8YnI+DQo8YnI+DQo8YnI+DQpCZXN0IHJlZ2FyZHMsPGJy Pg0KTGlzYW5kcm8gYW5kIExhdXJlbnQgKE5NUkcgY2hhaXJzKSwgdG9nZXRoZXIgd2l0aCBLb2hl aSBhbmQgRGFuIChTRE4gUkcgY2hhaXJzKS48YnI+DQotLS08YnI+DQo8YnI+DQo8L3NwYW4+PHNw YW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0 O2xpbmUtaGVpZ2h0Om5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1HQiI+LS0gPGJyPg0KPGJyPg0K PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseTrlrovkvZMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQ7bGluZS1oZWln aHQ6bm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ TGF1cmVudCBDaWF2YWdsaWE8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjBjbTtt YXJnaW4tYm90dG9tOi4wMDAxcHQ7bGluZS1oZWlnaHQ6bm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ij5TZW5pb3IgUmVzZWFyY2ggTWFuYWdlcjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdDts aW5lLWhlaWdodDpub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 OS4wcHQiPkJlbGwgTGFicywgTm9raWE8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQ7bGluZS1oZWlnaHQ6bm9ybWFsIj4NCjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQ7bGluZS1oZWlnaHQ6 bm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ij4mIzQz OzMzJm5ic3A7MTYwIDQwMiZuYnNwOzYzNiA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQ7bGluZS1oZWlnaHQ6bm9ybWFsIj4NCjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ij5Sb3V0ZSBkZSBWaWxsZWp1c3Qg fCA5MTYyMCBOb3pheSB8IEZyYW5jZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdDtsaW5lLWhlaWdodDpub3JtYWwiPg0KPHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OS4wcHQiPkxpbmtlZEluOiA8L3NwYW4+PHNwYW4g bGFuZz0iRU4tR0IiPjxhIGhyZWY9Imh0dHA6Ly9mci5saW5rZWRpbi5jb20vaW4vbGF1cmVudGNp YXZhZ2xpYS8iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJs YWNrO3RleHQtZGVjb3JhdGlvbjpub25lIj5sYXVyZW50Y2lhdmFnbGlhPC9zcGFuPjwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsQ3hTcE1pZGRsZSIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdDtsaW5lLWhlaWdodDpub3Jt YWwiPg0KPHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OS4wcHQiPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowY207bWFyZ2luLWJvdHRv bTouMDAwMXB0O2xpbmUtaGVpZ2h0Om5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQ7bGluZS1oZWlnaHQ6bm9ybWFsIj4NCjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTrlrovkvZMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_5D36713D8A4E7348A7E10DF7437A4B927C6534CBNKGEML515MBXchi_-- From nobody Tue Apr 12 19:41:21 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0633512DD5B for ; Tue, 12 Apr 2016 19:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Ih9K74XqRCPH for ; Tue, 12 Apr 2016 19:41:19 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AE8112DD3F for ; Tue, 12 Apr 2016 19:41:19 -0700 (PDT) Received: by mail-pa0-x235.google.com with SMTP id bx7so24619318pad.3 for ; Tue, 12 Apr 2016 19:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=97vrc6d0hNUAy04QwycL5RttlsESGklOf7RTeOAECAg=; b=Wfvvbw/zdoObiyh/KQJkWKm5nTYmknyngPo7ir1YOw9+Envf+pr1lz+T3XjDT6vacy G986fb9lHjipueyvZt8TSUvJiVhWJHI/uaYHoZKCyEI50Ypac1F8rgM96CuVVurj53Zi 00p0XQxtzY9tLxEhQ/54jClmiVCOlRMBd33sXy1IysBi1p5OSof6Spy5DJI2uD1SHFfI 7fMapKjOhBbJxLXi5q10w0clMwczwgycY+XVYUQe1tZpk1SyCkLE3/oCYnLxh2ItZ5xr IoXyQvEMqv901oPPvEFVN56Fr7eXF+t2IcT9v0dM/czE+M+iTr6zn773rH1hbCt/KBiB ASJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=97vrc6d0hNUAy04QwycL5RttlsESGklOf7RTeOAECAg=; b=c9C1aqTTdImE7Qr0Py+omGn4+ZGASnlKG2EoZPTmwhbplgdG8Gvnho8UECZklIOSAd 0gV7h+5loKyWql8WiME+Mfp3ZPSx9r+w9kCKzItT4QZn31v4QCA4Fl7B5DjrX5kG2E13 kDcJPEyr0/FJC7SJauDey82stKRL2+6givEy7PEMDOWi5J2hd91yWamFi0ig731m98M/ iNIvnywb4UQIB89D6gsEqqJ3zjmbi1GO18jxcmiGfKQMhIIoO2zF7zaH+3nEQC7nstz4 cYCyA3FpcD/JqJyzAyhLdFmYc1uVV3NBr8JU2iNFE2AVA1cxlKf1kIedYoEFk1KQzECE 9djQ== X-Gm-Message-State: AOPr4FUfLHPkIXmHLC9us1oovx4bYV3bHGBDhklKaxq9evZaviKkLT/SeLoAIUt3yCdkwA== X-Received: by 10.66.255.39 with SMTP id an7mr9449401pad.2.1460515279064; Tue, 12 Apr 2016 19:41:19 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id vv8sm46772544pab.22.2016.04.12.19.41.16 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Apr 2016 19:41:18 -0700 (PDT) To: "Michael Behringer (mbehring)" , anima References: <570C8076.8030308@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <570DB1D1.9000202@gmail.com> Date: Wed, 13 Apr 2016 14:41:21 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Intent Discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 13 Apr 2016 02:41:21 -0000 On 12/04/2016 19:43, Michael Behringer (mbehring) wrote: > In my mind, we'd use GRASP to signal amongst nodes just the current version of Intent (or if it comes packaged for example for a set of autonomic functions, that Intent set). So you'd flood the version info and unicast the content? Well, it's certainly simpler than worrying about reliable multicast. > Then, use TFTP (for example) to actually transmit the file. This way we get reliability, re-transmission, fragmenting, etc, all for free, and don't have to worry about that in GRASP. Actually, GRASP Synchronize over TCP should work fine. There's no arbitrary size limit. Brian > > Noting that, if Intent is really relatively long lived, the signalling happens all the time, actual transfer only if there is a new version. To me: Order of once a month! > > Michael > > >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: 12 April 2016 06:59 >> To: Michael Behringer (mbehring) ; anima >> >> Subject: Re: [Anima] Intent Discussion >> >> On 07/04/2016 23:14, Michael Behringer (mbehring) wrote: >> ... >>> Fragmenting Intent >>> - however we express Intent, we don't want to require that Intent MUST >> be >>> able to be de-composed into its atomic bits with a fixed size limit >>> --> we must not require that atomic bit MUST fit into a packet. >> >> I understand that, but we should note that this significantly complicates >> flooding of Intent to all nodes. >> >> ... >>> Flooded? >>> - good enough for now to flood. >> >> The only straightforward flooding mechanism we have now *does* assume >> that the atomic bits fit in a packet. >> >>> BUT: as long as we have a more granular way to "upgrade to" later. >> >> Actually the granular mechanism is there too but *doesn't* assume that the >> atomic bits fit in a packet. >> >> I think we need to think about draft-liu-anima-grasp-distribution >> as a potential requirements document in this area. >> >> Brian From nobody Wed Apr 13 08:43:44 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FECE12D0D8 for ; Wed, 13 Apr 2016 08:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 k9e_xNjVq9pn for ; Wed, 13 Apr 2016 08:43:41 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE1D212D96E for ; Wed, 13 Apr 2016 08:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1290; q=dns/txt; s=iport; t=1460562221; x=1461771821; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Q1Pq19tL4b+NOrNauvaRHG8oP1P6s2EGGLGTwRDf4xA=; b=Xyl9zWc6qIZjS/HdczW3hagygIKYNp6OLPLZkA/F5RQOaJMZe/QfXx8Q CHLbgU7/Mo+qBp8Gzk4IFEHhtVmffpo38BAOQw8clAQP/deDDTd8PLoSf svzTTfhMNQ88nuVMm1COMq29TYd2YpacZbv0OZI7gcpO+PR48HbvZBhD1 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAgDBaA5X/5xdJa1egzdTgQO6RgENg?= =?us-ascii?q?XQihWwCHIElOBQBAQEBAQEBZSeEQQEBAQMBIxFKCwIBCBgCAiYCAgIwFRABAQQ?= =?us-ascii?q?BGogYCA4DsFeSPAEBAQEBAQEBAQEBAQEBAQEBAQEBAREEfIUlhEuEGjuCaoJWB?= =?us-ascii?q?ZJ2hRIBhXaID48XjyYBHgEBQoNniSo+fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,480,1454976000"; d="scan'208";a="260930205" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Apr 2016 15:43:40 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u3DFhekZ027200 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Apr 2016 15:43:40 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 13 Apr 2016 10:43:39 -0500 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.009; Wed, 13 Apr 2016 10:43:39 -0500 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , anima Thread-Topic: [Anima] Intent Discussion Thread-Index: AdGQvf+xeVbNHCZJTzaTRxDR/JZAHgD4934AAATXaxAAKKj4gAAQpfUQ Date: Wed, 13 Apr 2016 15:43:39 +0000 Message-ID: <0a3f76007a324ad6a74a492955ac7f02@XCH-RCD-006.cisco.com> References: <570C8076.8030308@gmail.com> <570DB1D1.9000202@gmail.com> In-Reply-To: <570DB1D1.9000202@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.238.142] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Intent Discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 13 Apr 2016 15:43:44 -0000 PiBPbiAxMi8wNC8yMDE2IDE5OjQzLCBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpIHdyb3Rl Og0KPiA+IEluIG15IG1pbmQsIHdlJ2QgdXNlIEdSQVNQIHRvIHNpZ25hbCBhbW9uZ3N0IG5vZGVz IGp1c3QgdGhlIGN1cnJlbnQNCj4gdmVyc2lvbiBvZiBJbnRlbnQgKG9yIGlmIGl0IGNvbWVzIHBh Y2thZ2VkIGZvciBleGFtcGxlIGZvciBhIHNldCBvZiBhdXRvbm9taWMNCj4gZnVuY3Rpb25zLCB0 aGF0IEludGVudCBzZXQpLg0KPiANCj4gU28geW91J2QgZmxvb2QgdGhlIHZlcnNpb24gaW5mbyBh bmQgdW5pY2FzdCB0aGUgY29udGVudD8gV2VsbCwgaXQncyBjZXJ0YWlubHkNCj4gc2ltcGxlciB0 aGFuIHdvcnJ5aW5nIGFib3V0IHJlbGlhYmxlIG11bHRpY2FzdC4NCg0KWWVzLiBTZWUgaHR0cHM6 Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9hbmltYS9LTklnbHg5YWJETUVlandFWnU5 aEU0bkRBMDggZm9yIG15IG9yaWdpbmFsIHByb3Bvc2FsLiANCiANCj4gPiBUaGVuLCB1c2UgVEZU UCAoZm9yIGV4YW1wbGUpIHRvIGFjdHVhbGx5IHRyYW5zbWl0IHRoZSBmaWxlLiBUaGlzIHdheSB3 ZSBnZXQNCj4gcmVsaWFiaWxpdHksIHJlLXRyYW5zbWlzc2lvbiwgZnJhZ21lbnRpbmcsIGV0Yywg YWxsIGZvciBmcmVlLCBhbmQgZG9uJ3QgaGF2ZSB0bw0KPiB3b3JyeSBhYm91dCB0aGF0IGluIEdS QVNQLg0KPiANCj4gQWN0dWFsbHksIEdSQVNQIFN5bmNocm9uaXplIG92ZXIgVENQIHNob3VsZCB3 b3JrIGZpbmUuIFRoZXJlJ3Mgbm8gYXJiaXRyYXJ5DQo+IHNpemUgbGltaXQuDQoNCkFnYWluLCBu byBzdHJvbmcgdmlldyBvbiBwcm90b2NvbDsgd2Ugc2hvdWxkIHBpY2sgdGhlIGVhc2llc3Qgb25l IHRoYXQgZ2l2ZXMgdXMgcmVsaWFiaWxpdHkuIChBbHdheXMgdGhpbmtpbmcgYWxzbyBjb25zdHJh aW5lZCBkZXZpY2VzKQ0KDQpNaWNoYWVsDQoNCg== From nobody Wed Apr 13 13:48:11 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2539512E519 for ; Wed, 13 Apr 2016 13:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 bim_qjDTtir6 for ; Wed, 13 Apr 2016 13:47:52 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C512612E515 for ; Wed, 13 Apr 2016 13:47:49 -0700 (PDT) Received: by mail-pa0-x22d.google.com with SMTP id er2so9144381pad.3 for ; Wed, 13 Apr 2016 13:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=ZQqMoz2bUmFESQHaalGLyt2pkRE7oF1T4+AHvrxa7RM=; b=TBf3lbDJdgrsyeiP5y2wKWqr06E8grUtqvRKCjlavH2KJ8MkZCdPOHAODDzjK6QbNV BrM8vwFxfMZ3o5/guwTDqSQgGIS5k3KDVAN/uFY7DM0ozhtq2FiMbbsUbjpOxBIo6Yht fH8LvUkRTO9KLhCowhyUjB5uzkFzQa1NF8VSFdegawxSd6kkZAkVMBIg8soQ8fmBxnBq sACAE2PFrG1hc6HREtDTIThyVqE+eCYO0iGA6t3Omqxq02M/0CMDrbyjfBB2DrAbHorL 6O3/DnlHmlti/PAfMFSC/UNYxXElcWMkQXtrYC+XzgcoMQgIho1kgfr3v6gVhCLnlVkp HJAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=ZQqMoz2bUmFESQHaalGLyt2pkRE7oF1T4+AHvrxa7RM=; b=E9RNXOLhdfxwTWNSfrjix6RjrAk0/1WH1soxsLzIohNYei9Xp2WZu9KrmBi04Ty6sb ZRNW73mpmNmwm1w2bs7gFqaJ4aYatJusA/xAUfOu8bEKDUAjOCwxKuEgnbITVwQhGwPn 4U85VUWfIXc0yTERIyyMedhq2jF0TxPxwhAEf719vKdSoayEfeIYLV8RtWopDl9zTQuP 6nAp1uiIrdY2ygPdbbg+ErL6bgMf80acRSeY3W7r4WgVLzL9+PVgf1zyh9fVGOacH1ps IoehxZrFbKgs41d5nGoMNushVn2c1OA/JhFt7kDlS/HUK46wTA5+SKrGCZvqdrcrYZCA xzbQ== X-Gm-Message-State: AOPr4FUsjgfon4DH0uJjChMzlKoLF4QXpKPUbm3kkUUsEUTLyucFwW8cMYvjrq3ttcYaWw== X-Received: by 10.66.169.109 with SMTP id ad13mr15749211pac.20.1460580469443; Wed, 13 Apr 2016 13:47:49 -0700 (PDT) Received: from ?IPv6:2406:e007:5576:1:28cc:dc4c:9703:6781? ([2406:e007:5576:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q4sm53017335pfi.94.2016.04.13.13.47.45 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Apr 2016 13:47:47 -0700 (PDT) To: "Joel M. Halpern" , "Michael Behringer (mbehring)" , Laurent Ciavaglia , anima References: <570C8076.8030308@gmail.com> <570CB69D.40605@alcatel-lucent.com> <570D152F.50802@joelhalpern.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <570EB077.4040605@gmail.com> Date: Thu, 14 Apr 2016 08:47:51 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <570D152F.50802@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Anima] Info distribution [was Intent Discussion] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 13 Apr 2016 20:47:55 -0000 X-List-Received-Date: Wed, 13 Apr 2016 20:47:55 -0000 On 13/04/2016 03:33, Joel M. Halpern wrote: > One of the points that was discussed off-line in BA was that some folks= in this discussion treat all the information exchanged > by Anima as intent, and other folks treat Intent as one subset of the s= everal varieties of information exchanged by Anima. Yes. That's why we really to need to address the question posed by draft-liu-anima-grasp-distribution - do we need a general infrastructure mechanism for information distribution? (Then there's a second question whether it is anima-specific such as a GRASP extension, or an existing mechanism running over the ACP.) That is really a separate discussion from Intent. Brian >=20 > It is pretty clear that for many of the policy control goals, there has= to be frequent exchange of information. That > information is not the human generated intents, but it is important inf= ormation. >=20 > Another aspect that makes me nervous is this assumption of stability. I= n one sense, it seems to follow naturally (human's don't > change their busienss goals all that often). However, as the scope of = an Anima system becomes larger, and as people realize > they can change the system goals more frequently, I expect that the pol= icy aspects will change more frequently. I even expect > to see automated systems producing new policy goals. (Whether those sy= stems are within Anima or above it is irrelevant.) >=20 > Yours, > Joel >=20 > On 4/12/16 5:15 AM, Michael Behringer (mbehring) wrote: >> Agree. Also that, in my mind, is long lived; again, to me Intent is >> =E2=80=9Chigh level policy=E2=80=9D. That doesn=E2=80=99t change frequ= ently. >> >> I still suspect at the bottom of this discussion is a different >> understanding of what Intent actually is.... >> >> Michael >> >> *From:*Anima [mailto:anima-bounces@ietf.org] *On Behalf Of *Laurent >> Ciavaglia >> *Sent:* 12 April 2016 10:50 >> *To:* Michael Behringer (mbehring) ; Brian E >> Carpenter ; anima >> *Subject:* Re: [Anima] Intent Discussion >> >> Hello, >> >> On 12/04/2016 09:43, EXT Michael Behringer (mbehring) wrote: >> >> Noting that, if Intent is really relatively long lived, the >> signalling happens all the time, actual transfer only if there is = a >> new version. To me: Order of once a month! >> >> It's not so much the intent's lifetime that matters, than the frequenc= y >> at which the user (or the policy management system) >> creates/updates/deletes intents. >> >> Laurent. >> >> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> >=20 From nobody Thu Apr 14 12:45:09 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5434D12D81A for ; Thu, 14 Apr 2016 12:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 yLbleU9EM-2C for ; Thu, 14 Apr 2016 12:45:04 -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 CDE1D12D665 for ; Thu, 14 Apr 2016 12:45:03 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 2659AB8A1495D; Thu, 14 Apr 2016 19:44:58 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u3EJj0oJ005523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Apr 2016 19:45:00 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 u3EJj0Ot019614 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Apr 2016 21:45:00 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.143]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 14 Apr 2016 21:45:00 +0200 From: "Peloso, Pierre (Nokia - FR)" To: John Strassner , "Ciavaglia, Laurent (Nokia - FR)" Thread-Topic: [Anima] GRASP, discovery, and roles Thread-Index: AQHRlRV60dpE3FJ22k6eG1TYzufb4J+J34HQ Date: Thu, 14 Apr 2016 19:44:59 +0000 Message-ID: References: <57070C20.9070408@gmail.com> <57076BAE.2070807@alcatel-lucent.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_CCC5C4E24279804E8525F189C60FFABCB0B79362FR712WXCHMBA12z_" MIME-Version: 1.0 Archived-At: Cc: "jmh.direct" , "Joel M. Halpern" , "Liubing \(Leo\)" , Anima WG Subject: Re: [Anima] GRASP, discovery, and roles X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 14 Apr 2016 19:45:07 -0000 --_000_CCC5C4E24279804E8525F189C60FFABCB0B79362FR712WXCHMBA12z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9obiwNCg0KSSBzaGFyZSB5b3VyIHZpZXdzIG9uIHRoZSBhY3Rpb25zIHRvIGJlIHRha2Vu IGFuZCB0aGUgZGlyZWN0aW9ucyB0byBmb2xsb3cuDQpXZeKAmWxsIHNldCBvdXJzZWx2ZXMgYXQg d29yayBvbiB0aGVzZSBpdGVtcyBwcmV0dHkgc29vbiB3aXRoIHRoZSBpbnRlbnRpb24gdG8gdGFr ZSBpbnRvIGFjY291bnQgdGhlIGZlZWQtYmFjayB3ZSBoYWQgZHVyaW5nIHRoZSBtZWV0aW5nIGFu ZCB0aGUgY29tbWVudHMgb24gdGhlIG1haWxpbmcgbGlzdC4NCllvdXIgc3VwcG9ydCB3aWxsIGJl IG11Y2ggYXBwcmVjaWF0ZWQgdGhlbi4uLg0KDQpDaGVlcnMsDQoNClBpZXJyZQ0KDQpQUzogQWdy ZWVkIG9uIHRoZSBhcHByb2FjaCBvZiBmdXR1cmUgYmVoYXZpb3JzIChvciBmdXR1cmUgdHlwZSBv ZiBhdXRvbm9taWMgZnVuY3Rpb25zIHdoaWNoIHJlYWNoIGZhcnRoZXIgdGhhbiBhIHB1cmUgQU5J KS4gV2UgbmVlZCBhdCBsZWFzdCB0byBzZXQgYSBzb2x1dGlvbiB0aGF0IHdvdWxkIG5vdCBiZSBi bG9ja2luZyB1cyB3aGVuIHdl4oCZbGwgd2FudCB0byBleHRlbmQgaXQgdG8gdGhvc2UuDQoNCkRl IDogQW5pbWEgW21haWx0bzphbmltYS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEpv aG4gU3RyYXNzbmVyDQpFbnZvecOpIDogbWVyY3JlZGkgMTMgYXZyaWwgMjAxNiAwMTo0Ng0Kw4Ag OiBDaWF2YWdsaWEsIExhdXJlbnQgKE5va2lhIC0gRlIpOyBKb2huIFN0cmFzc25lcg0KQ2MgOiBq bWguZGlyZWN0OyBBbmltYSBXRzsgSm9lbCBNLiBIYWxwZXJuOyBMaXViaW5nIChMZW8pDQpPYmpl dCA6IFJlOiBbQW5pbWFdIEdSQVNQLCBkaXNjb3ZlcnksIGFuZCByb2xlcw0KDQpIaSBMYXVyZW50 LA0KDQo+IEkgdGhpbmsgaXQgc2hvdWxkIGJlIGV4cGxpY2l0IGluIHRoZSBzcGVjaWZpY2F0aW9u IG9mIHRoZSBBU0ENCj4gbGlmZS1jeWNsZSB3aGF0IGl0IGRvZXMuLi4NCj4NCj4gVGhpcyBzZXQg b2YgInJvbGVzIiBhbmQgbGlmZS1jeWNsZSBtdXN0IGJlIGZpeGVkIGFuZCBzcGVjaWZpZWQNCj4g YnkgdGhlIHN0YW5kYXJkLi4uYmVjYXVzZSB0aGVzZSBhcmUgc3BlY2lhbCByb2xlcy9vYmplY3Rp dmVzDQo+IHRoYXQgbXVzdCBiZSBzdXBwb3J0ZWQgLyB1bmRlcnN0b29kIGJ5IGFsbCBBU0FzIC8g b3IgQU5vZGVzLi4uDQoNCkFncmVlZCENCg0KPiBXaGF0IHNlZW1zIG5vdCBmdWxseSBkZWZpbmVk IHlldCBpcyBwcmVjaXNlbHkgYSBjb21wbGV0ZSBBU0ENCj4gbGlmZS1jeWNsZSAoY2YgZGlzY3Vz c2lvbiBhbmQgZHJhZnRzIG9uIHRoZSB0b3BpYykgYW5kIHRoZQ0KPiBtaW5pbWFsIHNldCBvZiBy b2xlcyB0byBkZXBsb3kgYW5kIGhhdmUgYW4gYXV0b25vbWljIG5ldHdvcmtzDQo+IHJlYWR5IGZv ciBvcGVyYXRpb24gLyBvcGVyYXRpbmcuDQoNCkkgdGhpbmsgdGhhdCB3ZSBuZWVkIGF0IGxlYXN0 IHR3byB0aGluZ3MgaGVyZToNCg0KICAgMSkgc3BlY2lmaWNhdGlvbiBvZiB0aGUgbGlmZWN5Y2xl IG9mIEF1dG9ub21pYyBGdW5jdGlvbnMsIGFuZA0KICAgMikgc3BlY2lmaWNhdGlvbiBvZiB0aGUg bWFuYWdlbWVudCBvZiB0aG9zZSBBdXRvbm9taWMgRnVuY3Rpb25zDQoNCj4gU2hhbGwgd2UgdXBn cmFkZSB0aGUgcmVmZXJlbmNlIG1vZGVsIGRvY3VtZW50IHNlY3Rpb24gb24gdGhlb3J5DQo+IG9m IG9wZXJhdGlvbnMgd2l0aCB0aGVzZSBhc3BlY3RzIG9yIHNob3VsZCBpdCBiZSBhbm90aGVyIGRv Yz8NCj4NCj4gRllJLCBkcmFmdC1wZWxvc28tYW5pbWEtYXV0b25vbWljLWZ1bmN0aW9uIGF0dGVt cHRzIHRvIGRlc2NyaWJlIHN1Y2ggYSBsaWZlLWN5Y2xlLg0KDQpJIHRoaW5rIHRoYXQgdGhlIHJl ZmVyZW5jZSBtb2RlbCBuZWVkcyB1cGRhdGluZzsgb25jZSB0aGF0IGlzIHVwZGF0ZWQsIHRoZW4g SSB0aGluayB0aGF0IHRoZQ0KYWJvdmUgZHJhZnQgKGRheSBpbiB0aGUgbGlmZSkgbmVlZHMgdG8g dXBkYXRlIGFuZCBleHBhbmQgb24gdGhlIHRoYXQuDQoNCkknZCBsaWtlIHRvIGhlbHAgaW4gYm90 aC4NCg0KSG93ZXZlciwgdGhlcmUgaXMgYW5vdGhlciBhZGRpdGlvbmFsIGlzc3VlLiBEcmFmdC1w ZWxvc28gdGFsa3MgYWJvdXQgdGhlIHBvd2VyIG9mIGluc3RhbGxpbmcNCmF1dG9ub21pYyBmdW5j dGlvbnMgYmV5b25kIGEgc2ltcGxlIGtub3duIHNldCB0aGF0IGFyZSAicHJlLWluc3RhbGxlZCIu IFRoaXMgbWFrZXMgbWUgdGhpbmsNCm9mIGVtZXJnZW50IGJlaGF2aW9yLiBJdCBpcyBvbmUgdGhp bmcgdG8gc3VwcG9ydCBkZXNpcmVkIGtub3duIGJlaGF2aW9yIHRoYXQgaXMgcHJlLWRlZmluZWQ7 DQppdCBpcyBxdWl0ZSBhbm90aGVyIHRvIHN1cHBvcnQgbmV3IHNlcnZpY2VzIHRoYXQgd2VyZSBu b3Qga25vd24gd2hlbiB0aGUgYXV0b25vbWljIG5ldHdvcmsNCndhcyBvcmlnaW5hbGx5IGluc3Rh bGxlZC4gVGhlIGxhdHRlciBpcyBtdWNoIG1vcmUgZGlmZmljdWx0LCBhbmQgcGVyaGFwcyBiZXlv bmQgb3VyIGN1cnJlbnQNCnNjb3BlLCBidXQgaXQgd291bGQgYmUgbmljZSBpZiB3ZSBjb3VsZCBh dCBsZWFzdCBhbnRpY2lwYXRlIGFuZCBzdGFydCB0byB1bmRlcnN0YW5kIGl0cyBuZWVkcw0Kc28g dGhhdCB3ZSBkbyBub3QgYm94IG91cnNlbHZlcyBpbnRvIGEgY29ybmVyDQoNCg0KcmVnYXJkcywN CkpvaG4NCg0KT24gRnJpLCBBcHIgOCwgMjAxNiBhdCAxOjI4IEFNLCBMYXVyZW50IENpYXZhZ2xp YSA8bGF1cmVudC5jaWF2YWdsaWFAbm9raWEuY29tPG1haWx0bzpsYXVyZW50LmNpYXZhZ2xpYUBu b2tpYS5jb20+PiB3cm90ZToNCkhlbGxvLA0KDQpJIHRoaW5rIGl0IHNob3VsZCBiZSBleHBsaWNp dCBpbiB0aGUgc3BlY2lmaWNhdGlvbiBvZiB0aGUgQVNBIGxpZmUtY3ljbGUgd2hhdCBpdCBkb2Vz IHdoZW4gaXQgYm9vdHMgKGFuZCBpbiBvdGhlciBwaGFzZXMgYXMgd2VsbCk6DQogICAgZS5nLiBk aXNjb3ZlciAvIHJlZ2lzdGVyIHRvIChlbnRpdGllcyBwbGF5aW5nKSBzcGVjaWFsIHJvbGVzIHN1 Y2ggYXMgcmVnaXN0cmFyLCBjb29yZGluYXRpb24sIGludGVudCwga25vd2xlZGdlIGluZGV4Li4u DQoNClRoaXMgc2V0IG9mICJyb2xlcyIgYW5kIGxpZmUtY3ljbGUgbXVzdCBiZSBmaXhlZCBhbmQg c3BlY2lmaWVkIGJ5IHRoZSBzdGFuZGFyZCwgbm90IGxlZnQgb3BlbiB0byBBU0EgZGV2ZWxvcGVy cycgY3JlYXRpdml0eSBiZWNhdXNlIHRoZXNlIGFyZSBzcGVjaWFsIHJvbGVzL29iamVjdGl2ZXMg dGhhdCBtdXN0IGJlIHN1cHBvcnRlZCAvIHVuZGVyc3Rvb2QgYnkgYWxsIEFTQXMgLyBvciBBTm9k ZXMgKHByb3h5KSBhZ2VudHMuDQoNCldoYXQgc2VlbXMgbm90IGZ1bGx5IGRlZmluZWQgeWV0IGlz IHByZWNpc2VseSBhIGNvbXBsZXRlIEFTQSBsaWZlLWN5Y2xlIChjZiBkaXNjdXNzaW9uIGFuZCBk cmFmdHMgb24gdGhlIHRvcGljKSBhbmQgdGhlIG1pbmltYWwgc2V0IG9mIHJvbGVzIHRvIGRlcGxv eSBhbmQgaGF2ZSBhbiBhdXRvbm9taWMgbmV0d29ya3MgcmVhZHkgZm9yIG9wZXJhdGlvbiAvIG9w ZXJhdGluZy4NCg0KU2hhbGwgd2UgdXBncmFkZSB0aGUgcmVmZXJlbmNlIG1vZGVsIGRvY3VtZW50 IHNlY3Rpb24gb24gdGhlb3J5IG9mIG9wZXJhdGlvbnMgd2l0aCB0aGVzZSBhc3BlY3RzIG9yIHNo b3VsZCBpdCBiZSBhbm90aGVyIGRvYz8NCg0KRllJLCBkcmFmdC1wZWxvc28tYW5pbWEtYXV0b25v bWljLWZ1bmN0aW9uIGF0dGVtcHRzIHRvIGRlc2NyaWJlIHN1Y2ggYSBsaWZlLWN5Y2xlLg0KDQpC ZXN0IHJlZ2FyZHMsIExhdXJlbnQuDQpPbiAwOC8wNC8yMDE2IDAzOjQwLCBFWFQgQnJpYW4gRSBD YXJwZW50ZXIgd3JvdGU6DQoNCk9uIDA4LzA0LzIwMTYgMTE6NTIsIGptaC5kaXJlY3Qgd3JvdGU6 DQoNCkFzIEkgdW5kZXJzdGFuZCBpdCwgaWYgYW4gZW50aXR5IGhhcyBhdCBsZWFzdCBvbmUgY2Fj aGVkIGFuc3dlciwgaXQgd2lsbCBzZW5kIG1lIHRoYXQgYW5kIHN0b3AgcHJvcGFnYXRpbmcgbXli cmVxdWVkdC4NCg0KQWN0dWFsbHkgSSBkb24ndCB0aGluayB0aGF0J3MgaG93IEkgY29kZWQgaXQg YnV0IHRoYXQgaGFyZGx5IG1hdHRlcnM7IHdlIGNhbg0KDQpyZXZpZXcgdGhlIHNwZWMgdG8gYmUg dW5hbWJpZ3VvdXMgb24gdGhhdCBwb2ludC4NCg0KDQoNCkJ1dCB0aGVyZSdzIGFub3RoZXIgcG9p bnQgaGVyZSB3aGljaCBtYXkgbmVlZCB0byBiZSBtYWRlIGEgZm9ybWFsIHJlcXVpcmVtZW50DQoN CndpdGggc29tZSBiZXR0ZXIgdGVybWlub2xvZ3kuDQoNCg0KDQpZb3UgY2FuIGRpc2NvdmVyIGFu IG9iamVjdGl2ZSB3aXRob3V0IHN1cHBvcnRpbmcgaXQgeW91cnNlbGYuIEZvciBleGFtcGxlLA0K DQp3ZSB3YW50IGV4YWN0bHkgb25lIG5vZGUgdG8gc3VwcG9ydCB0aGUgQU5fUmVnaXN0cmFyIG9i amVjdGl2ZSBidXQgYW55IG90aGVyDQoNCm5vZGUgbWF5IG5lZWQgdG8gZGlzY292ZXIgaXQuIFRo YXQgd2FzIGtpbmQgb2YgaW50dWl0aXZlIHdoZW4gY29kaW5nIG15DQoNCnByb3RvdHlwZSBidXQg d2UgbmVlZCB0byBtYWtlIGl0IGV4cGxpY2l0Lg0KDQoNCg0KICAgIEJyaWFuDQoNCg0KDQpBbmQg aXQgY2FuJ3QgdGVsbCBpZiB0aGUgYW5zd2VyIGlzIGluc3VmZmljaWVudC5Zb3VycyxKb2VsDQoN Cg0KDQoNCg0KU2VudCB2aWEgdGhlIFNhbXN1bmcgR2FsYXh5IFPCriA2LCBhbiBBVCZUIDRHIExU RSBzbWFydHBob25lLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLUZyb206ICJMaXVi aW5nIChMZW8pIiA8bGVvLmxpdWJpbmdAaHVhd2VpLmNvbT48bWFpbHRvOmxlby5saXViaW5nQGh1 YXdlaS5jb20+IERhdGU6IDQvNy8yMDE2ICA3OjM4IFBNICAoR01ULTAzOjAwKSBUbzogIkpvZWwg TS4gSGFscGVybiIgPGptaEBqb2VsaGFscGVybi5jb20+PG1haWx0bzpqbWhAam9lbGhhbHBlcm4u Y29tPiwgQW5pbWEgV0cgPGFuaW1hQGlldGYub3JnPjxtYWlsdG86YW5pbWFAaWV0Zi5vcmc+IFN1 YmplY3Q6IFJFOiBbQW5pbWFdIEdSQVNQLCBkaXNjb3ZlcnksIGFuZCByb2xlcw0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBKb2VsIE0uIEhhbHBlcm4gW21haWx0bzpqbWhA am9lbGhhbHBlcm4uY29tXQ0KDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMDcsIDIwMTYgNzoyNSBQ TQ0KDQpUbzogTGl1YmluZyAoTGVvKTsgQW5pbWEgV0cNCg0KU3ViamVjdDogUmU6IFtBbmltYV0g R1JBU1AsIGRpc2NvdmVyeSwgYW5kIHJvbGVzDQoNCg0KDQpJZiBJIGNvdWxkIGp1c3QgaWdub3Jl IHNvbWUgcmVzcG9uc2VzLCBhbmQgYmUgc3VyZSBJIHdvdWxkIGdldCB0aGUgb3RoZXINCg0KcmVz cG9uc2VzLCB0aGF0IHdvdWxkIGJlIGEgd2F5IHRvIHNvbHZlIHRoZSBwcm9ibGVtLiAgQnV0IGFz IGZhciBhcyBJDQoNCnVuZGVyc3RhbmQgR1JBU1A8IHRoYXQgaXNuJ3Qgd2hhdCBoYXBwZW5zLiAg TXkgZGlzY292ZXJ5IG1pZ2h0IHByb21wdA0KDQpzZXZlcmFsIGFuc3dlcnMsIGJ1dCBhbG9uZyBh bnkgZ2l2ZW4gYnJhbmNoIGl0IHN0b3BzIHdoZW4gaXQgaGl0cyBhbnkgcmVzcG9uZGVyLA0KDQpl dmVuIGlmIHRoZXkgYXJlIGp1c3QgYW5vdGhlciBwYXJ0aWNpcGFudC4NCg0KW0JpbmddIFRoaXMg aXMgdGhlICJtdWx0aXBsZSByZXNwb25zZXMiIG9wZW4gaXNzdWUgd2UgdXNlZCB0byBkaXNjdXNz Lg0KDQpHUkFTUCB3aWxsIG5vdCBzdG9wIHJlY2VpdmluZyBvdGhlciByZXNwb25zZXMsIChhY3R1 YWxseSBpdCBqdXN0IGNhbid0KSwgYWNjb3JkaW5nIHRvIGRpc2N1c3Npb24gaW4gbGFzdCBpZXRm LCBwZW9wbGUgdGVuZGVkIHRvIGhhbmRsZSB0aGUgbXVsdGlwbGUgcmVzcG9uc2VzIHRvIEFTQSwg d2hvIHdpbGwgZGVjaWRlIHRvIHVzZSB3aGljaCBkaXNjb3ZlcmVkIHJlc3VsdC4gSSB0aGluayB3 ZSdsbCBuZWVkIHRvIGNsZWFybHkgc3BlY2lmeSB0aGUgYmVoYXZpb3IgaW4gdGhlIEFQSSBkb2N1 bWVudC4NCg0KDQoNCkIuUi4NCg0KQmluZw0KDQoNCg0KWW91cnMsDQoNCkpvZWwNCg0KDQoNCk9u IDQvNy8xNiA2OjE2IFBNLCBMaXViaW5nIChMZW8pIHdyb3RlOg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KDQpGcm9tOiBKb2VsIE0uIEhhbHBlcm4gW21haWx0bzpqbWhAam9lbGhhbHBl cm4uY29tXQ0KDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMDcsIDIwMTYgNjo1NyBQTQ0KDQpUbzog TGl1YmluZyAoTGVvKTsgQW5pbWEgV0cNCg0KQ2M6IEJyaWFuIEUgQ2FycGVudGVyDQoNClN1Ympl Y3Q6IFJlOiBbQW5pbWFdIEdSQVNQLCBkaXNjb3ZlcnksIGFuZCByb2xlcw0KDQoNCg0KR2l2ZW4g dGhhdCBJIHJlZ2lzdGVyIGluIG9yZGVyIHRvIHBhcnRpY2lwYXRlIGluIHRlaCBkaXNjb3Zlcnks IGl0DQoNCnNlZW1zIHRoYXQgSSBjb3VsZCBqdXN0IGFzIGVhc2lseSBlbmQgdXAgImRpc2NvdmVy aW5nIiBhbm90aGVyDQoNCnBhcnRpY2lwYW50IHdoZW4gd2hhdCBJIG5lZWQgaXMgdGhlIGNvb3Jk aW5hdG9yLg0KDQpbQmluZ10gSW4gdGVybXMgb2YgR1JBU1AgdGVybWlub2xvZ3ksIHdoYXQgeW91 IG5lZWQgaXMgdGhlICJjb29yZGluYXRpb24NCg0KZnVuY3Rpb24vc2VydmljZSIsIGFuZCB0aGUg b25lIHdobyByZXNwb25zZSB5b3UsIGltcGxpZXMgaXQgaXMgYSAiY29vcmRpbmF0b3IiDQoNCm9y IHdoYXRldmVyIHJvbGUgd2hpY2ggY291bGQgcHJvdmlkZSBpZGVudGljYWwgY29vcmRpbmF0aW9u IGZ1bmN0aW9uL3NlcnZpY2UgYXMNCg0KdGhlICJjb29yZGluYXRvciIuIFNvLCBqdXN0IGRvbid0 IHdvcnJ5IGFib3V0IHRoZSBvbmUgd2hvIHJlc3BvbnNlIHlvdSBpcw0KDQoiYW5vdGhlciIgZ3V5 IHdobyBpcyBub3QgcXVhbGlmaWVkIHRvIHNlcnZlIHlvdS4NCg0KRGlkIEkgY2FwdHVyZSB5b3Vy IGNvbmNlcm4gY29ycmVjdGx5Pw0KDQoNCg0KQi5SLg0KDQpCaW5nDQoNCg0KDQpBbSBJIG1pcy1y ZWFkaW5nIGl0Pw0KDQoNCg0KWW91cnMsDQoNCkpvZWwNCg0KDQoNCk9uIDQvNy8xNiA1OjQ4IFBN LCBMaXViaW5nIChMDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCg0KQW5pbWEgbWFpbGluZyBsaXN0DQoNCkFuaW1hQGlldGYub3JnPG1h aWx0bzpBbmltYUBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9hbmltYQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KDQpBbmltYSBtYWlsaW5nIGxpc3QNCg0KQW5pbWFAaWV0Zi5vcmc8bWFpbHRvOkFuaW1h QGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1h DQoNCi0tDQpMYXVyZW50IENpYXZhZ2xpYQ0KU2VuaW9yIFJlc2VhcmNoIE1hbmFnZXINCkJlbGwg TGFicywgTm9raWENCg0KKzMzIDE2MCA0MDIgNjM2DQpSb3V0ZSBkZSBWaWxsZWp1c3QgfCA5MTYy MCBOb3pheSB8IEZyYW5jZQ0KTGlua2VkSW46IGxhdXJlbnRjaWF2YWdsaWE8aHR0cDovL2ZyLmxp bmtlZGluLmNvbS9pbi9sYXVyZW50Y2lhdmFnbGlhLz4NCg0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBbmltYSBtYWlsaW5nIGxpc3QNCkFuaW1h QGlldGYub3JnPG1haWx0bzpBbmltYUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vYW5pbWENCg0KDQoNCi0tDQpyZWdhcmRzLA0KSm9obg0K --_000_CCC5C4E24279804E8525F189C60FFABCB0B79362FR712WXCHMBA12z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJbWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRh dGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBi dWxsZXMgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4u UHJmb3JtYXRIVE1MQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOp IEhUTUwiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLlRleHRlZGVidWxsZXNDYXINCgl7bXNv LXN0eWxlLW5hbWU6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIjsNCglmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkhpIEpvaG4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHNoYXJlIHlvdXIgdmlld3Mgb24gdGhlIGFjdGlvbnMg dG8gYmUgdGFrZW4gYW5kIHRoZSBkaXJlY3Rpb25zIHRvIGZvbGxvdy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+V2XigJlsbCBzZXQgb3Vyc2VsdmVzIGF0IHdvcmsgb24gdGhlc2UgaXRl bXMgcHJldHR5IHNvb24gd2l0aCB0aGUgaW50ZW50aW9uIHRvIHRha2UgaW50byBhY2NvdW50IHRo ZSBmZWVkLWJhY2sgd2UgaGFkIGR1cmluZyB0aGUgbWVldGluZyBhbmQgdGhlIGNvbW1lbnRzIG9u IHRoZQ0KIG1haWxpbmcgbGlzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WW91ciBz dXBwb3J0IHdpbGwgYmUgbXVjaCBhcHByZWNpYXRlZCB0aGVuLi4uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaGVlcnMs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5QaWVycmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBTOiBBZ3JlZWQgb24gdGhlIGFwcHJvYWNoIG9m IGZ1dHVyZSBiZWhhdmlvcnMgKG9yIGZ1dHVyZSB0eXBlIG9mIGF1dG9ub21pYyBmdW5jdGlvbnMg d2hpY2ggcmVhY2ggZmFydGhlciB0aGFuIGEgcHVyZSBBTkkpLiBXZSBuZWVkIGF0IGxlYXN0IHRv IHNldCBhIHNvbHV0aW9uDQogdGhhdCB3b3VsZCBub3QgYmUgYmxvY2tpbmcgdXMgd2hlbiB3ZeKA mWxsIHdhbnQgdG8gZXh0ZW5kIGl0IHRvIHRob3NlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQW5pbWEgW21haWx0bzphbmltYS1ib3VuY2VzQGlldGYu b3JnXQ0KPGI+RGUgbGEgcGFydCBkZTwvYj4gSm9obiBTdHJhc3NuZXI8YnI+DQo8Yj5FbnZvecOp Jm5ic3A7OjwvYj4gbWVyY3JlZGkgMTMgYXZyaWwgMjAxNiAwMTo0Njxicj4NCjxiPsOAJm5ic3A7 OjwvYj4gQ2lhdmFnbGlhLCBMYXVyZW50IChOb2tpYSAtIEZSKTsgSm9obiBTdHJhc3NuZXI8YnI+ DQo8Yj5DYyZuYnNwOzo8L2I+IGptaC5kaXJlY3Q7IEFuaW1hIFdHOyBKb2VsIE0uIEhhbHBlcm47 IExpdWJpbmcgKExlbyk8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbQW5pbWFdIEdSQVNQ LCBkaXNjb3ZlcnksIGFuZCByb2xlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgTGF1cmVudCw8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0OyBJJm5ic3A7dGhpbmsgaXQg c2hvdWxkIGJlIGV4cGxpY2l0IGluIHRoZSBzcGVjaWZpY2F0aW9uIG9mIHRoZSBBU0E8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDsgbGlmZS1j eWNsZSB3aGF0IGl0IGRvZXMuLi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGlzIHNldCBvZiAmcXVv dDtyb2xlcyZxdW90OyBhbmQgbGlmZS1jeWNsZSBtdXN0IGJlIGZpeGVkIGFuZCBzcGVjaWZpZWQ8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDsm bmJzcDtieSB0aGUgc3RhbmRhcmQuLi5iZWNhdXNlIHRoZXNlIGFyZSBzcGVjaWFsIHJvbGVzL29i amVjdGl2ZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZndDsgdGhhdCBtdXN0IGJlIHN1cHBvcnRlZCAvIHVuZGVyc3Rvb2QgYnkgYWxsIEFTQXMg LyBvciBBTm9kZXMuLi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWdyZWVkITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDsmbmJzcDtXaGF0IHNlZW1zIG5vdCBmdWxseSBk ZWZpbmVkIHlldCBpcyBwcmVjaXNlbHkgYSBjb21wbGV0ZSBBU0E8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDsgbGlmZS1jeWNsZSAoY2YgZGlz Y3Vzc2lvbiBhbmQgZHJhZnRzIG9uIHRoZSB0b3BpYykgYW5kIHRoZTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0OyZuYnNwO21pbmltYWwgc2V0 IG9mIHJvbGVzIHRvIGRlcGxveSBhbmQgaGF2ZSBhbiBhdXRvbm9taWMgbmV0d29ya3M8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDsmbmJzcDty ZWFkeSBmb3Igb3BlcmF0aW9uIC8gb3BlcmF0aW5nLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGF0IHdlIG5lZWQg YXQgbGVhc3QgdHdvIHRoaW5ncyBoZXJlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgMSkgc3BlY2lmaWNhdGlvbiBvZiB0 aGUgbGlmZWN5Y2xlIG9mIEF1dG9ub21pYyBGdW5jdGlvbnMsIGFuZDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IDIpIHNwZWNp ZmljYXRpb24gb2YgdGhlIG1hbmFnZW1lbnQgb2YgdGhvc2UgQXV0b25vbWljIEZ1bmN0aW9uczxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mZ3Q7 IFNoYWxsIHdlIHVwZ3JhZGUgdGhlIHJlZmVyZW5jZSBtb2RlbCBkb2N1bWVudCBzZWN0aW9uIG9u IHRoZW9yeTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jmd0OyZuYnNwO29mIG9wZXJhdGlvbnMgd2l0aCB0aGVzZSBhc3BlY3RzIG9yIHNob3VsZCBp dCBiZSBhbm90aGVyIGRvYz88YnI+DQomZ3Q7PGJyPg0KJmd0OyBGWUksIGRyYWZ0LXBlbG9zby1h bmltYS1hdXRvbm9taWMtPC9zcGFuPmZ1bmN0aW9uIGF0dGVtcHRzIHRvIGRlc2NyaWJlIHN1Y2gg YSBsaWZlLWN5Y2xlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhhdCB0aGUgcmVmZXJlbmNlIG1vZGVsIG5lZWRz IHVwZGF0aW5nOyBvbmNlIHRoYXQgaXMgdXBkYXRlZCwgdGhlbiBJIHRoaW5rIHRoYXQgdGhlPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hYm92ZSBk cmFmdCAoZGF5IGluIHRoZSBsaWZlKSBuZWVkcyB0byB1cGRhdGUgYW5kIGV4cGFuZCBvbiB0aGUg dGhhdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSdkIGxpa2UgdG8gaGVscCBpbiBib3RoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3dldmVyLCB0aGVyZSBpcyBhbm90aGVyIGFkZGl0 aW9uYWwgaXNzdWUuIERyYWZ0LXBlbG9zbyB0YWxrcyBhYm91dCB0aGUgcG93ZXIgb2YgaW5zdGFs bGluZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ YXV0b25vbWljIGZ1bmN0aW9ucyBiZXlvbmQgYSBzaW1wbGUga25vd24gc2V0IHRoYXQgYXJlICZx dW90O3ByZS1pbnN0YWxsZWQmcXVvdDsuIFRoaXMgbWFrZXMgbWUgdGhpbms8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm9mIGVtZXJnZW50IGJlaGF2 aW9yLiBJdCBpcyBvbmUgdGhpbmcgdG8gc3VwcG9ydCBkZXNpcmVkIGtub3duIGJlaGF2aW9yIHRo YXQgaXMgcHJlLWRlZmluZWQ7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5pdCBpcyBxdWl0ZSBhbm90aGVyIHRvIHN1cHBvcnQgbmV3IHNlcnZpY2Vz IHRoYXQgd2VyZSBub3Qga25vd24gd2hlbiB0aGUgYXV0b25vbWljIG5ldHdvcms8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndhcyBvcmlnaW5hbGx5 IGluc3RhbGxlZC4gVGhlIGxhdHRlciBpcyBtdWNoIG1vcmUgZGlmZmljdWx0LCBhbmQgcGVyaGFw cyBiZXlvbmQgb3VyIGN1cnJlbnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPnNjb3BlLCBidXQgaXQgd291bGQgYmUgbmljZSBpZiB3ZSBjb3VsZCBh dCBsZWFzdCBhbnRpY2lwYXRlIGFuZCBzdGFydCB0byB1bmRlcnN0YW5kIGl0cyBuZWVkczxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c28gdGhhdCB3 ZSBkbyBub3QgYm94IG91cnNlbHZlcyBpbnRvIGEgY29ybmVyPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+cmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvaG48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBBcHIgOCwgMjAxNiBhdCAxOjI4IEFN LCBMYXVyZW50IENpYXZhZ2xpYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxhdXJlbnQuY2lhdmFnbGlh QG5va2lhLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmxhdXJlbnQuY2lhdmFnbGlhQG5va2lhLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5IZWxsbyw8YnI+DQo8YnI+DQpJIHRoaW5rIGl0IHNob3Vs ZCBiZSBleHBsaWNpdCBpbiB0aGUgc3BlY2lmaWNhdGlvbiBvZiB0aGUgQVNBIGxpZmUtY3ljbGUg d2hhdCBpdCBkb2VzIHdoZW4gaXQgYm9vdHMgKGFuZCBpbiBvdGhlciBwaGFzZXMgYXMgd2VsbCk6 PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IGUuZy4gZGlzY292ZXIgLyByZWdpc3RlciB0byAoZW50 aXRpZXMgcGxheWluZykgc3BlY2lhbCByb2xlcyBzdWNoIGFzIHJlZ2lzdHJhciwgY29vcmRpbmF0 aW9uLCBpbnRlbnQsIGtub3dsZWRnZSBpbmRleC4uLjxicj4NCjxicj4NClRoaXMgc2V0IG9mICZx dW90O3JvbGVzJnF1b3Q7IGFuZCBsaWZlLWN5Y2xlIG11c3QgYmUgZml4ZWQgYW5kIHNwZWNpZmll ZCBieSB0aGUgc3RhbmRhcmQsIG5vdCBsZWZ0IG9wZW4gdG8gQVNBIGRldmVsb3BlcnMnIGNyZWF0 aXZpdHkgYmVjYXVzZSB0aGVzZSBhcmUgc3BlY2lhbCByb2xlcy9vYmplY3RpdmVzIHRoYXQgbXVz dCBiZSBzdXBwb3J0ZWQgLyB1bmRlcnN0b29kIGJ5IGFsbCBBU0FzIC8gb3IgQU5vZGVzIChwcm94 eSkgYWdlbnRzLjxicj4NCjxicj4NCldoYXQgc2VlbXMgbm90IGZ1bGx5IGRlZmluZWQgeWV0IGlz IHByZWNpc2VseSBhIGNvbXBsZXRlIEFTQSBsaWZlLWN5Y2xlIChjZiBkaXNjdXNzaW9uIGFuZCBk cmFmdHMgb24gdGhlIHRvcGljKSBhbmQgdGhlIG1pbmltYWwgc2V0IG9mIHJvbGVzIHRvIGRlcGxv eSBhbmQgaGF2ZSBhbiBhdXRvbm9taWMgbmV0d29ya3MgcmVhZHkgZm9yIG9wZXJhdGlvbiAvIG9w ZXJhdGluZy48YnI+DQo8YnI+DQpTaGFsbCB3ZSB1cGdyYWRlIHRoZSByZWZlcmVuY2UgbW9kZWwg ZG9jdW1lbnQgc2VjdGlvbiBvbiB0aGVvcnkgb2Ygb3BlcmF0aW9ucyB3aXRoIHRoZXNlIGFzcGVj dHMgb3Igc2hvdWxkIGl0IGJlIGFub3RoZXIgZG9jPzxicj4NCjxicj4NCkZZSSwgZHJhZnQtcGVs b3NvLWFuaW1hLWF1dG9ub21pYy1mdW5jdGlvbiBhdHRlbXB0cyB0byBkZXNjcmliZSBzdWNoIGEg bGlmZS1jeWNsZS48YnI+DQo8YnI+DQpCZXN0IHJlZ2FyZHMsIExhdXJlbnQuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDA4LzA0LzIwMTYgMDM6 NDAsIEVYVCBCcmlhbiBFIENhcnBlbnRlciB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cHJlPk9uIDA4LzA0LzIwMTYgMTE6NTIsIGptaC5kaXJlY3Qgd3JvdGU6PG86cD48L286cD48 L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHByZT5BcyBJIHVuZGVyc3RhbmQgaXQsIGlmIGFuIGVudGl0eSBoYXMgYXQgbGVh c3Qgb25lIGNhY2hlZCBhbnN3ZXIsIGl0IHdpbGwgc2VuZCBtZSB0aGF0IGFuZCBzdG9wIHByb3Bh Z2F0aW5nIG15YnJlcXVlZHQuPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+ QWN0dWFsbHkgSSBkb24ndCB0aGluayB0aGF0J3MgaG93IEkgY29kZWQgaXQgYnV0IHRoYXQgaGFy ZGx5IG1hdHRlcnM7IHdlIGNhbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnJldmlldyB0aGUgc3Bl YyB0byBiZSB1bmFtYmlndW91cyBvbiB0aGF0IHBvaW50LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkJ1dCB0aGVyZSdzIGFub3RoZXIgcG9pbnQg aGVyZSB3aGljaCBtYXkgbmVlZCB0byBiZSBtYWRlIGEgZm9ybWFsIHJlcXVpcmVtZW50PG86cD48 L286cD48L3ByZT4NCjxwcmU+d2l0aCBzb21lIGJldHRlciB0ZXJtaW5vbG9neS48bzpwPjwvbzpw PjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5Zb3UgY2FuIGRpc2Nv dmVyIGFuIG9iamVjdGl2ZSB3aXRob3V0IHN1cHBvcnRpbmcgaXQgeW91cnNlbGYuIEZvciBleGFt cGxlLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPndlIHdhbnQgZXhhY3RseSBvbmUgbm9kZSB0byBz dXBwb3J0IHRoZSBBTl9SZWdpc3RyYXIgb2JqZWN0aXZlIGJ1dCBhbnkgb3RoZXI8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT5ub2RlIG1heSBuZWVkIHRvIGRpc2NvdmVyIGl0LiBUaGF0IHdhcyBraW5k IG9mIGludHVpdGl2ZSB3aGVuIGNvZGluZyBteTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnByb3Rv dHlwZSBidXQgd2UgbmVlZCB0byBtYWtlIGl0IGV4cGxpY2l0LjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyBCcmlh bjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+ QW5kIGl0IGNhbid0IHRlbGwgaWYgdGhlIGFuc3dlciBpcyBpbnN1ZmZpY2llbnQuWW91cnMsSm9l bDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxv OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlNlbnQgdmlhIHRoZSBTYW1zdW5nIEdhbGF4eSBT wq4gNiwgYW4gQVQmYW1wO1QgNEcgTFRFIHNtYXJ0cGhvbmUtLS0tLS0tLSBPcmlnaW5hbCBtZXNz YWdlIC0tLS0tLS0tRnJvbTogJnF1b3Q7TGl1YmluZyAoTGVvKSZxdW90OyA8YSBocmVmPSJtYWls dG86bGVvLmxpdWJpbmdAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPiZsdDtsZW8ubGl1Ymlu Z0BodWF3ZWkuY29tJmd0OzwvYT4gRGF0ZTogNC83LzIwMTYmbmJzcDsgNzozOCBQTSZuYnNwOyAo R01ULTAzOjAwKSBUbzogJnF1b3Q7Sm9lbCBNLiBIYWxwZXJuJnF1b3Q7IDxhIGhyZWY9Im1haWx0 bzpqbWhAam9lbGhhbHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+Jmx0O2ptaEBqb2VsaGFscGVy bi5jb20mZ3Q7PC9hPiwgQW5pbWEgV0cgPGEgaHJlZj0ibWFpbHRvOmFuaW1hQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+Jmx0O2FuaW1hQGlldGYub3JnJmd0OzwvYT4gU3ViamVjdDogUkU6IFtB bmltYV0gR1JBU1AsIGRpc2NvdmVyeSwgYW5kIHJvbGVzIDxvOnA+PC9vOnA+PC9wcmU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw cmU+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Gcm9t OiBKb2VsIE0uIEhhbHBlcm4gWzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIiB0 YXJnZXQ9Il9ibGFuayI+bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb208L2E+XTxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPlNlbnQ6IFRodXJzZGF5LCBBcHJpbCAwNywgMjAxNiA3OjI1IFBNPG86cD48 L286cD48L3ByZT4NCjxwcmU+VG86IExpdWJpbmcgKExlbyk7IEFuaW1hIFdHPG86cD48L286cD48 L3ByZT4NCjxwcmU+U3ViamVjdDogUmU6IFtBbmltYV0gR1JBU1AsIGRpc2NvdmVyeSwgYW5kIHJv bGVzPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+ SWYgSSBjb3VsZCBqdXN0IGlnbm9yZSBzb21lIHJlc3BvbnNlcywgYW5kIGJlIHN1cmUgSSB3b3Vs ZCBnZXQgdGhlIG90aGVyPG86cD48L286cD48L3ByZT4NCjxwcmU+cmVzcG9uc2VzLCB0aGF0IHdv dWxkIGJlIGEgd2F5IHRvIHNvbHZlIHRoZSBwcm9ibGVtLiZuYnNwOyBCdXQgYXMgZmFyIGFzIEk8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT51bmRlcnN0YW5kIEdSQVNQJmx0OyB0aGF0IGlzbid0IHdo YXQgaGFwcGVucy4mbmJzcDsgTXkgZGlzY292ZXJ5IG1pZ2h0IHByb21wdDxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPnNldmVyYWwgYW5zd2VycywgYnV0IGFsb25nIGFueSBnaXZlbiBicmFuY2ggaXQg c3RvcHMgd2hlbiBpdCBoaXRzIGFueSByZXNwb25kZXIsPG86cD48L286cD48L3ByZT4NCjxwcmU+ ZXZlbiBpZiB0aGV5IGFyZSBqdXN0IGFub3RoZXIgcGFydGljaXBhbnQuPG86cD48L286cD48L3By ZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+W0JpbmddIFRoaXMgaXMgdGhlICZxdW90O211bHRpcGxl IHJlc3BvbnNlcyZxdW90OyBvcGVuIGlzc3VlIHdlIHVzZWQgdG8gZGlzY3Vzcy4gPG86cD48L286 cD48L3ByZT4NCjxwcmU+R1JBU1Agd2lsbCBub3Qgc3RvcCByZWNlaXZpbmcgb3RoZXIgcmVzcG9u c2VzLCAoYWN0dWFsbHkgaXQganVzdCBjYW4ndCksIGFjY29yZGluZyB0byBkaXNjdXNzaW9uIGlu IGxhc3QgaWV0ZiwgcGVvcGxlIHRlbmRlZCB0byBoYW5kbGUgdGhlIG11bHRpcGxlIHJlc3BvbnNl cyB0byBBU0EsIHdobyB3aWxsIGRlY2lkZSB0byB1c2Ugd2hpY2ggZGlzY292ZXJlZCByZXN1bHQu IEkgdGhpbmsgd2UnbGwgbmVlZCB0byBjbGVhcmx5IHNwZWNpZnkgdGhlIGJlaGF2aW9yIGluIHRo ZSBBUEkgZG9jdW1lbnQuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48 L3ByZT4NCjxwcmU+Qi5SLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkJpbmc8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPllvdXJzLDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPkpvZWw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPg0KPHByZT5PbiA0LzcvMTYgNjoxNiBQTSwgTGl1YmluZyAoTGVvKSB3cm90ZTo8 bzpwPjwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpw PjwvbzpwPjwvcHJlPg0KPHByZT5Gcm9tOiBKb2VsIE0uIEhhbHBlcm4gWzxhIGhyZWY9Im1haWx0 bzpqbWhAam9lbGhhbHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOmptaEBqb2VsaGFs cGVybi5jb208L2E+XTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlNlbnQ6IFRodXJzZGF5LCBBcHJp bCAwNywgMjAxNiA2OjU3IFBNPG86cD48L286cD48L3ByZT4NCjxwcmU+VG86IExpdWJpbmcgKExl byk7IEFuaW1hIFdHPG86cD48L286cD48L3ByZT4NCjxwcmU+Q2M6IEJyaWFuIEUgQ2FycGVudGVy PG86cD48L286cD48L3ByZT4NCjxwcmU+U3ViamVjdDogUmU6IFtBbmltYV0gR1JBU1AsIGRpc2Nv dmVyeSwgYW5kIHJvbGVzPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48 L3ByZT4NCjxwcmU+R2l2ZW4gdGhhdCBJIHJlZ2lzdGVyIGluIG9yZGVyIHRvIHBhcnRpY2lwYXRl IGluIHRlaCBkaXNjb3ZlcnksIGl0PG86cD48L286cD48L3ByZT4NCjxwcmU+c2VlbXMgdGhhdCBJ IGNvdWxkIGp1c3QgYXMgZWFzaWx5IGVuZCB1cCAmcXVvdDtkaXNjb3ZlcmluZyZxdW90OyBhbm90 aGVyPG86cD48L286cD48L3ByZT4NCjxwcmU+cGFydGljaXBhbnQgd2hlbiB3aGF0IEkgbmVlZCBp cyB0aGUgY29vcmRpbmF0b3IuPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+ W0JpbmddIEluIHRlcm1zIG9mIEdSQVNQIHRlcm1pbm9sb2d5LCB3aGF0IHlvdSBuZWVkIGlzIHRo ZSAmcXVvdDtjb29yZGluYXRpb248bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHBy ZT5mdW5jdGlvbi9zZXJ2aWNlJnF1b3Q7LCBhbmQgdGhlIG9uZSB3aG8gcmVzcG9uc2UgeW91LCBp bXBsaWVzIGl0IGlzIGEgJnF1b3Q7Y29vcmRpbmF0b3ImcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT5vciB3aGF0ZXZlciByb2xlIHdoaWNoIGNvdWxkIHByb3ZpZGUgaWRlbnRpY2FsIGNvb3Jk aW5hdGlvbiBmdW5jdGlvbi9zZXJ2aWNlIGFzPG86cD48L286cD48L3ByZT4NCjxwcmU+dGhlICZx dW90O2Nvb3JkaW5hdG9yJnF1b3Q7LiBTbywganVzdCBkb24ndCB3b3JyeSBhYm91dCB0aGUgb25l IHdobyByZXNwb25zZSB5b3UgaXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mcXVvdDthbm90aGVy JnF1b3Q7IGd1eSB3aG8gaXMgbm90IHF1YWxpZmllZCB0byBzZXJ2ZSB5b3UuPG86cD48L286cD48 L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHByZT5EaWQgSSBjYXB0dXJlIHlvdXIgY29uY2VybiBjb3JyZWN0bHk/PG86cD48 L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Qi5SLjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPkJpbmc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cHJlPkFtIEkgbWlzLXJlYWRpbmcgaXQ/PG86cD48L286cD48L3By ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+WW91cnMsPG86cD48L286cD48 L3ByZT4NCjxwcmU+Sm9lbDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wcmU+DQo8cHJlPk9uIDQvNy8xNiA1OjQ4IFBNLCBMaXViaW5nIChMPG86cD48L286cD48L3By ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48 L3ByZT4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5BbmltYSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86QW5pbWFAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5BbmltYUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYTwvYT48bzpwPjwvbzpw PjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkFuaW1hIG1haWxpbmcgbGlzdDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpBbmltYUBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPkFuaW1hQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWEiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hPC9hPjxvOnA+ PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5MYXVyZW50IENpYXZhZ2xpYTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPlNlbmlvciBSZXNlYXJjaCBNYW5hZ2VyPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+QmVsbCBMYWJzLCBOb2tpYTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG8iPiYjNDM7MzMmbmJzcDsxNjAgNDAyJm5ic3A7 NjM2IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvIj5Sb3V0ZSBkZSBWaWxsZWp1c3QgfCA5MTYyMCBOb3pheSB8IEZyYW5j ZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvIj5MaW5rZWRJbjogPHNwYW4gbGFuZz0iRU4tR0IiPg0KPGEgaHJlZj0iaHR0 cDovL2ZyLmxpbmtlZGluLmNvbS9pbi9sYXVyZW50Y2lhdmFnbGlhLyIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIGxhbmc9IkZSIj5sYXVyZW50Y2lhdmFnbGlhPC9zcGFuPjwvYT48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWJvdHRvbTowY207bWFyZ2luLWJvdHRvbTouMDAw MXB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpBbmltYSBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86QW5pbWFAaWV0Zi5vcmciPkFuaW1hQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vYW5pbWEiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2FuaW1hPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8YnI+DQotLSA8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvaG48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_CCC5C4E24279804E8525F189C60FFABCB0B79362FR712WXCHMBA12z_-- From nobody Fri Apr 15 02:01:29 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3105812E4D1 for ; Fri, 15 Apr 2016 02:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 2aB6WkcnQXzD for ; Fri, 15 Apr 2016 02:01:26 -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 7697912E4A2 for ; Fri, 15 Apr 2016 02:01:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CME64718; Fri, 15 Apr 2016 09:01:22 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 15 Apr 2016 10:01:21 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Fri, 15 Apr 2016 17:01:16 +0800 From: Sheng Jiang To: "anima@ietf.org" Thread-Topic: Autonomic work in ETSI NGP Thread-Index: AdGW9Ud/tCUOkEfPTrO4bHxlJpFnPQ== Date: Fri, 15 Apr 2016 09:01:16 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927C655899@NKGEML515-MBX.china.huawei.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.99.197] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.5710ADE2.021A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 29ad765e5e54191de1c917e39efd6ae2 Archived-At: Subject: [Anima] Autonomic work in ETSI NGP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 15 Apr 2016 09:01:28 -0000 U2VuZGluZyB0aGlzIGFzIGFuIGluZGl2aWR1YWwuDQoNCkVUU0kgaGFzIGZvcm1lZCBhIG5ldyBJ bmR1c3RyeSBTcGVjaWZpY2F0aW9uIEdyb3VwOiBOR1AgKE5leHQgR2VuZXJhdGlvbiBQcm90b2Nv bCkgZWFybHkgdGhpcyB5ZWFyLiBPbmUgb2YgdGhlIHdvcmsgc3RhcnRzIHRoZXJlIGlzIFNlbGYt b3JnYW5pemluZyBDb250cm9sICYgTWFuYWdlbWVudCBQbGFuZXMgKHdvcmsgaXRlbSAjMikuIEl0 IGlzIGNhbGxpbmcgaW5kaXZpZHVhbCBjb250cmlidXRpb24vcGFydGljaXBhdGlvbiBvbiBhdXRv bm9taWMgd29yay4gSXQgYWxzbyBpbnRyb2R1Y2luZyBtYWNoaW5lIGxlYXJuaW5nIGFzIG1lY2hh bmlzbSBmb3IgYXV0b25vbWljIGRlY2lzaW9uLiBUaGUgbmV4dCBtZWV0aW5nIHdpbGwgYmUgSnVs eSAyNi0yNyBpbiBTb3BoaWEgQW50aXBvbGlzLCBGcmFuY2UsIGp1c3QgYWZ0ZXIgSUVURiA5NiBC ZXJsaW4gbWVldGluZy4gVGhlcmUgd2lsbCBhbHNvIGJlIGEgY291cGxlIG9mIGNvbmYgY2FsbHMg YmVmb3JlIGl0IGZvY3VzaW5nIG9uIFdJMiBzZWxmLW9yZ2FuaXppbmcuDQoNCmh0dHBzOi8vcG9y dGFsLmV0c2kub3JnL3RiLmFzcHg/dGJpZD04NDQmU3ViVEI9ODQ0DQoNCkJlc3QgcmVnYXJkcywN Cg0KU2hlbmcNCg== From nobody Fri Apr 15 21:55:43 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A1712DF69 for ; Fri, 15 Apr 2016 21:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 TLM6ST4NB2jW for ; Fri, 15 Apr 2016 21:55:39 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9FA212DE6B for ; Fri, 15 Apr 2016 21:55:38 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id j11so166067417lfb.1 for ; Fri, 15 Apr 2016 21:55:38 -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; bh=2g5t0vNWHP7/ELiywchdMBDSlhAQBQix5VYBijZgquI=; b=DgWn0jFpNv/rr9VE5WMDJVrq62oD1ypjDJXnQln1b8Z8/UhrXZl/3bNV6GgSvIVgNZ ReKk10wlN6ROM/xPnx8xjaYgrXMiI+CRkMeGTw1MKvbqBikr3kCZ+H4Z/FWp2ZhFsdie 9JATywAPI/MD+RXMGOQcovvk1ap1IULmFAeBlEPzGUyH+utlKwLzh5ZRhNUjI2H28m0o M5Rd1STbr2SuYLQvFUIm0IYK1ctChmAxSErXNsblfzSjYpLsBBHAenud5Z32bMNWc4nz jvRpgE4klvGcSED+Gwrqol5X9kZzkd0cg7nNCLrhBBDUVVG5PAn/q21sOl6UqxR3ki1m U/LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=2g5t0vNWHP7/ELiywchdMBDSlhAQBQix5VYBijZgquI=; b=gU5KUp4H33wVv5CgqH8YztGGkhBXPtJ+ztO2Ex2bHQEDauf7F07Y5K4YW3ZY8zYXG2 /WMbRCUZXh/XqGBSHvwqwudoHpuiuIEO055eeXko7GA5pDByhnDWkHqV9bW6XtIEG3gH nedRropwkyqrg4migGLX2OZShMWzDCV68qiDvkG0PLJ2DXdMreKGrxzjZ4nptPQL3l+s RBD+kmp7N0tc4mvpXz2wTUzrzgrp88D14sPkwuXYPt1/SP9gRM3x8s00Zcbj+vzWr+N+ rzBuE5hTctonQCm5Bc1ORfDkioPAWqC1xG/UXkBIBj3UlJPfSuMj+j65Kn//JmpmAE6W /xeQ== X-Gm-Message-State: AOPr4FVuwXorxbAesqpU+oJX7YsKZ5zwEbMIk4rZqlJ5jlM2mRHOio/HV4WOse8o2hIp3wUolGDss/50ZG55Fw== MIME-Version: 1.0 X-Received: by 10.25.87.71 with SMTP id l68mr2254783lfb.35.1460782536968; Fri, 15 Apr 2016 21:55:36 -0700 (PDT) Received: by 10.25.22.19 with HTTP; Fri, 15 Apr 2016 21:55:36 -0700 (PDT) In-Reply-To: References: <57070C20.9070408@gmail.com> <57076BAE.2070807@alcatel-lucent.com> Date: Fri, 15 Apr 2016 21:55:36 -0700 Message-ID: From: John Strassner To: "Peloso, Pierre (Nokia - FR)" , John Strassner Content-Type: multipart/alternative; boundary=001a11424c1c35d1db053092f053 Archived-At: Cc: "Ciavaglia, Laurent \(Nokia - FR\)" , "jmh.direct" , "Joel M. Halpern" , "Liubing \(Leo\)" , Anima WG Subject: Re: [Anima] GRASP, discovery, and roles X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 16 Apr 2016 04:55:42 -0000 --001a11424c1c35d1db053092f053 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Pierre, thanks for your note; you can count on my support. best regards, John On Thu, Apr 14, 2016 at 12:44 PM, Peloso, Pierre (Nokia - FR) < pierre.peloso@nokia.com> wrote: > Hi John, > > > > I share your views on the actions to be taken and the directions to follo= w. > > We=E2=80=99ll set ourselves at work on these items pretty soon with the i= ntention > to take into account the feed-back we had during the meeting and the > comments on the mailing list. > > Your support will be much appreciated then... > > > > Cheers, > > > > Pierre > > > > PS: Agreed on the approach of future behaviors (or future type of > autonomic functions which reach farther than a pure ANI). We need at leas= t > to set a solution that would not be blocking us when we=E2=80=99ll want t= o extend > it to those. > > > > *De :* Anima [mailto:anima-bounces@ietf.org] *De la part de* John > Strassner > *Envoy=C3=A9 :* mercredi 13 avril 2016 01:46 > *=C3=80 :* Ciavaglia, Laurent (Nokia - FR); John Strassner > *Cc :* jmh.direct; Anima WG; Joel M. Halpern; Liubing (Leo) > *Objet :* Re: [Anima] GRASP, discovery, and roles > > > > Hi Laurent, > > > > > I think it should be explicit in the specification of the ASA > > > life-cycle what it does... > > > > This set of "roles" and life-cycle must be fixed and specified > > > by the standard...because these are special roles/objectives > > > that must be supported / understood by all ASAs / or ANodes... > > > > Agreed! > > > > > What seems not fully defined yet is precisely a complete ASA > > > life-cycle (cf discussion and drafts on the topic) and the > > > minimal set of roles to deploy and have an autonomic networks > > > ready for operation / operating. > > > > I think that we need at least two things here: > > > > 1) specification of the lifecycle of Autonomic Functions, and > > 2) specification of the management of those Autonomic Functions > > > > > Shall we upgrade the reference model document section on theory > > > of operations with these aspects or should it be another doc? > > > > FYI, draft-peloso-anima-autonomic-function attempts to describe such a > life-cycle. > > > > I think that the reference model needs updating; once that is updated, > then I think that the > > above draft (day in the life) needs to update and expand on the that. > > > > I'd like to help in both. > > > > However, there is another additional issue. Draft-peloso talks about the > power of installing > > autonomic functions beyond a simple known set that are "pre-installed". > This makes me think > > of emergent behavior. It is one thing to support desired known behavior > that is pre-defined; > > it is quite another to support new services that were not known when the > autonomic network > > was originally installed. The latter is much more difficult, and perhaps > beyond our current > > scope, but it would be nice if we could at least anticipate and start to > understand its needs > > so that we do not box ourselves into a corner > > > > > > regards, > > John > > > > On Fri, Apr 8, 2016 at 1:28 AM, Laurent Ciavaglia < > laurent.ciavaglia@nokia.com> wrote: > > Hello, > > I think it should be explicit in the specification of the ASA life-cycle > what it does when it boots (and in other phases as well): > e.g. discover / register to (entities playing) special roles such as > registrar, coordination, intent, knowledge index... > > This set of "roles" and life-cycle must be fixed and specified by the > standard, not left open to ASA developers' creativity because these are > special roles/objectives that must be supported / understood by all ASAs = / > or ANodes (proxy) agents. > > What seems not fully defined yet is precisely a complete ASA life-cycle > (cf discussion and drafts on the topic) and the minimal set of roles to > deploy and have an autonomic networks ready for operation / operating. > > Shall we upgrade the reference model document section on theory of > operations with these aspects or should it be another doc? > > FYI, draft-peloso-anima-autonomic-function attempts to describe such a > life-cycle. > > Best regards, Laurent. > > On 08/04/2016 03:40, EXT Brian E Carpenter wrote: > > On 08/04/2016 11:52, jmh.direct wrote: > > As I understand it, if an entity has at least one cached answer, it will = send me that and stop propagating mybrequedt. > > Actually I don't think that's how I coded it but that hardly matters; we = can > > review the spec to be unambiguous on that point. > > > > But there's another point here which may need to be made a formal require= ment > > with some better terminology. > > > > You can discover an objective without supporting it yourself. For example= , > > we want exactly one node to support the AN_Registrar objective but any ot= her > > node may need to discover it. That was kind of intuitive when coding my > > prototype but we need to make it explicit. > > > > Brian > > > > And it can't tell if the answer is insufficient.Yours,Joel > > > > > > Sent via the Samsung Galaxy S=C2=AE 6, an AT&T 4G LTE smartphone-------- = Original message --------From: "Liubing (Leo)" Date: 4/7/2016 7:38 PM (GMT-03:00) To: "Joel M. Hal= pern" , Anima WG Subject: RE: [Anima] GRASP, discovery, and roles > > -----Original Message----- > > From: Joel M. Halpern [mailto:jmh@joelhalpern.com ] > > Sent: Thursday, April 07, 2016 7:25 PM > > To: Liubing (Leo); Anima WG > > Subject: Re: [Anima] GRASP, discovery, and roles > > > > If I could just ignore some responses, and be sure I would get the other > > responses, that would be a way to solve the problem. But as far as I > > understand GRASP< that isn't what happens. My discovery might prompt > > several answers, but along any given branch it stops when it hits any res= ponder, > > even if they are just another participant. > > [Bing] This is the "multiple responses" open issue we used to discuss. > > GRASP will not stop receiving other responses, (actually it just can't), = according to discussion in last ietf, people tended to handle the multiple = responses to ASA, who will decide to use which discovered result. I think w= e'll need to clearly specify the behavior in the API document. > > > > B.R. > > Bing > > > > Yours, > > Joel > > > > On 4/7/16 6:16 PM, Liubing (Leo) wrote: > > -----Original Message----- > > From: Joel M. Halpern [mailto:jmh@joelhalpern.com ] > > Sent: Thursday, April 07, 2016 6:57 PM > > To: Liubing (Leo); Anima WG > > Cc: Brian E Carpenter > > Subject: Re: [Anima] GRASP, discovery, and roles > > > > Given that I register in order to participate in teh discovery, it > > seems that I could just as easily end up "discovering" another > > participant when what I need is the coordinator. > > [Bing] In terms of GRASP terminology, what you need is the "coordination > > function/service", and the one who response you, implies it is a "coordin= ator" > > or whatever role which could provide identical coordination function/serv= ice as > > the "coordinator". So, just don't worry about the one who response you is > > "another" guy who is not qualified to serve you. > > Did I capture your concern correctly? > > > > B.R. > > Bing > > > > Am I mis-reading it? > > > > Yours, > > Joel > > > > On 4/7/16 5:48 PM, Liubing (L > > > > > > _______________________________________________ > > 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 > > > > -- > > Laurent Ciavaglia > > Senior Research Manager > > Bell Labs, Nokia > > > > +33 160 402 636 > > Route de Villejust | 91620 Nozay | France > > LinkedIn: laurentciavaglia > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > > > > > -- > > regards, > > John > --=20 regards, John --001a11424c1c35d1db053092f053 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Pierre,

thanks for your n= ote; you can count on my support.

best regards,
John

On Thu, Apr 14, 2016 at 12:44 PM, Peloso, Pierre (Nokia - FR) <pierre.peloso@nokia.com> wrote:

Hi John,

=C2=A0=

I share your views o= n the actions to be taken and the directions to follow.

We=E2=80=99ll set ou= rselves at work on these items pretty soon with the intention to take into = account the feed-back we had during the meeting and the comments on the mailing list.

Your support will be= much appreciated then...

=C2=A0=

Cheers,

=C2=A0=

Pierre=

=C2=A0=

PS: Agreed on the ap= proach of future behaviors (or future type of autonomic functions which rea= ch farther than a pure ANI). We need at least to set a solution that would not be blocking us when we=E2=80=99ll want to extend it to thos= e.

=C2=A0=

De=C2=A0: Anima [m= ailto:anima-bou= nces@ietf.org] De la part de John Strassner
Envoy=C3=A9=C2=A0: mercredi 13 avril 2016 01:46
=C3=80=C2=A0: Ciavaglia, Laurent (Nokia - FR); John Strassner
Cc=C2=A0: jmh.direct; Anima WG; Joel M. Halpern; Liubing (Leo)
Objet=C2=A0: Re: [Anima] GRASP, discovery, and roles

=C2=A0

Hi Laurent,

=C2=A0

= > I=C2=A0think it should be explicit in the specification of the ASA

= > life-cycle what it does...
>
> This set of "roles" and life-cycle must be fixed and specifi= ed

= >=C2=A0by the standard...because these are special roles/objectives

= > that must be supported / understood by all ASAs / or ANodes...<= u>

=C2=A0

Agreed!

=C2=A0

= >=C2=A0What seems not fully defined yet is precisely a complete ASA

= > life-cycle (cf discussion and drafts on the topic) and the

= >=C2=A0minimal set of roles to deploy and have an autonomic networks

= >=C2=A0ready for operation / operating.

=C2=A0

I think that we need at least two things here:

=C2=A0

=C2=A0=C2=A0 1) specification of the lifecycle of Au= tonomic Functions, and

=C2=A0=C2=A0 2) specification of the management of t= hose Autonomic Functions

=C2=A0

= > Shall we upgrade the reference model document section on theory=

= >=C2=A0of operations with these aspects or should it be another doc?
>
> FYI, draft-peloso-anima-autonomic-function attempts to describe= such a life-cycle.

=C2=A0

I think that the reference model needs updating; onc= e that is updated, then I think that the

above draft (day in the life) needs to update and ex= pand on the that.

=C2=A0

I'd like to help in both.

=C2=A0

However, there is another additional issue. Draft-pe= loso talks about the power of installing

autonomic functions beyond a simple known set that a= re "pre-installed". This makes me think

of emergent behavior. It is one thing to support des= ired known behavior that is pre-defined;

it is quite another to support new services that wer= e not known when the autonomic network

was originally installed. The latter is much more di= fficult, and perhaps beyond our current

scope, but it would be nice if we could at least ant= icipate and start to understand its needs

so that we do not box ourselves into a corner=

=C2=A0

=C2=A0

regards,

John

=C2=A0

On Fri, Apr 8, 2016 at 1:28 AM, Laurent Ciavaglia &l= t;laurent.= ciavaglia@nokia.com> wrote:

Hello,

I think it should be explicit in the specification of the ASA life-cycle wh= at it does when it boots (and in other phases as well):
=C2=A0=C2=A0=C2=A0 e.g. discover / register to (entities playing) special r= oles such as registrar, coordination, intent, knowledge index...

This set of "roles" and life-cycle must be fixed and specified by= the standard, not left open to ASA developers' creativity because thes= e are special roles/objectives that must be supported / understood by all A= SAs / or ANodes (proxy) agents.

What seems not fully defined yet is precisely a complete ASA life-cycle (cf= discussion and drafts on the topic) and the minimal set of roles to deploy= and have an autonomic networks ready for operation / operating.

Shall we upgrade the reference model document section on theory of operatio= ns with these aspects or should it be another doc?

FYI, draft-peloso-anima-autonomic-function attempts to describe such a life= -cycle.

Best regards, Laurent.

On 08/04/2016 03:40, EXT Brian E Carpenter wrote:= 

On 08/04/2016 11:52, jmh.direct wrote:
As I understand it, if an entity has at least one cached answer, it wi=
ll send me that and stop propagating mybrequedt.
Actually I don't think that's how I coded it but that hardly m=
atters; we can
review the spec to be unambiguous on that point.
=C2=A0
But there's another point here which may need to be made a formal =
requirement
with some better terminology.
=C2=A0
You can discover an objective without supporting it yourself. For exam=
ple,
we want exactly one node to support the AN_Registrar objective but any=
 other
node may need to discover it. That was kind of intuitive when coding m=
y
prototype but we need to make it explicit.
=C2=A0
=C2=A0=C2=A0=C2=A0 Brian
=C2=A0
And it can't tell if the answer is insufficient.Yours,Joel<=
u>
=C2=A0
=C2=A0
Sent via the Samsung Galaxy S=C2=AE 6, an AT&T 4G LTE smartphone--=
------ Original message --------From: "Liubing (Leo)" <leo.liubing@huawei.com=
> Date: 4/7/2016=C2=A0 7:38 PM=C2=A0 (GMT-03:00) To: "Joel M. H=
alpern" <j=
mh@joelhalpern.com>, Anima WG <anima@ietf.org> Subject: RE: [Anima] GRASP, discov=
ery, and roles 
-----Original Message-----
From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
Sent: Thursday, April 07, 2016 7:25 PM
To: Liubing (Leo); Anima WG
Subject: Re: [Anima] GRASP, discovery, and roles
=C2=A0
If I could just ignore some responses, and be sure I would get the oth=
er
responses, that would be a way to solve the problem.=C2=A0 But as far =
as I
understand GRASP< that isn't what happens.=C2=A0 My discovery m=
ight prompt
several answers, but along any given branch it stops when it hits any =
responder,
even if they are just another participant.
[Bing] This is the "multiple responses" open issue we used t=
o discuss. 
GRASP will not stop receiving other responses, (actually it just can&#=
39;t), according to discussion in last ietf, people tended to handle the mu=
ltiple responses to ASA, who will decide to use which discovered result. I =
think we'll need to clearly specify the behavior in the API document.
=C2=A0
B.R.
Bing
=C2=A0
Yours,
Joel
=C2=A0
On 4/7/16 6:16 PM, Liubing (Leo) wrote:
-----Original Message-----
From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
Sent: Thursday, April 07, 2016 6:57 PM
To: Liubing (Leo); Anima WG
Cc: Brian E Carpenter
Subject: Re: [Anima] GRASP, discovery, and roles
=C2=A0
Given that I register in order to participate in teh discovery, it<=
/u>
seems that I could just as easily end up "discovering" anoth=
er
participant when what I need is the coordinator.
[Bing] In terms of GRASP terminology, what you need is the "coord=
ination
function/service", and the one who response you, implies it is a =
"coordinator"
or whatever role which could provide identical coordination function/s=
ervice as
the "coordinator". So, just don't worry about the one wh=
o response you is
"another" guy who is not qualified to serve you.
Did I capture your concern correctly?
=C2=A0
B.R.
Bing
=C2=A0
Am I mis-reading it?
=C2=A0
Yours,
Joel
=C2=A0
On 4/7/16 5:48 PM, Liubing (L
=C2=A0
=C2=A0
_______________________________________________
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

=C2=A0

--

Laurent Ciavaglia=

Senior Research Manager<= u>

Bell Labs, Nokia<= u>

=C2=A0

+33=C2=A0160 402=C2=A0636

Route de Villejust | 91620 Nozay | France<= /u>

LinkedIn: <= span lang=3D"FR">laurentciavaglia

=C2=A0


_______________________________________________
Anima mailing list
Anima@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/anima




--

regards,

John




--
regards,
John
--001a11424c1c35d1db053092f053-- From nobody Sat Apr 16 18:29:45 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F0B12DA5F for ; Sat, 16 Apr 2016 18:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 EYsDuaxE9UH8 for ; Sat, 16 Apr 2016 18:29:40 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BD7412D9C3 for ; Sat, 16 Apr 2016 18:29:40 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id e128so68607722pfe.3 for ; Sat, 16 Apr 2016 18:29:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:organization:cc:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=/1en9tzSC4RjM0iVMpsiIT2TvnW1X3xMg9+P+9bHSDM=; b=Pyv1Cy6UQEl6fsVAz6Ep91/Ho4AVJkojw6LrsTBhnR6oyZkZxLBI/NS4MA+pEs9eox vpkz9yJaRmVBIgqFlMTX1yUXXYcUrRqn9j1s3IwgbacnBgAuPWa7jWABwIiGV/nDFeVB 79gzANAjSuqFDkRtSGgg8qgt7H7kij0OS+jcWZQL2N4ypO2DkzWwi/zYxQq/8acEPLVf s4aLf20tEm5u6YxLZuCEIrG836LS+Goprlm2MkK3W4EGpk8hBOM8qoxrc2XZQsjoH3aq rZXdGpUN0dJEy5+YBhBlIUypdzWO2zgvnLleYbXHYoiGCd9dOqokZzeveqnx4pfk8hrO V6VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:organization:cc:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=/1en9tzSC4RjM0iVMpsiIT2TvnW1X3xMg9+P+9bHSDM=; b=eq5jB/ku4BCS3D8Qg5Cq1dAPc3bwB0wyLrgXBR+SQ6fL13Jvw6OoHyVVDywZGlYZac NYBT561rnrd5I3y9z/9JYDZ9760MRFO6qcP4Nad3rrKypTQ2+iurFUX7cFvzLog2ZKm2 v0wuoJwfM/hdlMzsn6a8iQDON9m+l6WxoQjT2bR1VXWnOzBIzGrkOnPTSAggGhczuLBV 4w7nf/+bl5nFj735xyc4qCzxGfevOie+9FDVxTCCHyCPXZ2+LTW/JC3vQkSBziPjCk+s XmK7wx7AUtHkNbKtU6+Z5G9m8lOz1kxMRwFe3TmZ6yPIUU68c3UZ3yRVILYMMZRJ/Gj7 4nag== X-Gm-Message-State: AOPr4FXgt41iKm54BhNxgIT8LjRU337mpSzfbgXmpimCblPfplsPHXjUdBdIPJGwsFBm6g== X-Received: by 10.98.34.207 with SMTP id p76mr9275050pfj.1.1460856579732; Sat, 16 Apr 2016 18:29:39 -0700 (PDT) Received: from ?IPv6:2406:e007:416f:1:28cc:dc4c:9703:6781? ([2406:e007:416f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id h5sm74171934pat.0.2016.04.16.18.29.36 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 16 Apr 2016 18:29:38 -0700 (PDT) To: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: <5712E6FF.5070305@gmail.com> Date: Sun, 17 Apr 2016 13:29:35 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Nancy Cam-Winget Subject: [Anima] GTSM in draft-ietf-anima-autonomic-control-plane-02 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2016 01:29:42 -0000 Hi, A bit of advice on a security matter, please! I was thinking about how I would add the following requirement to the GRASP prototype code: > o GRASP link-local multicast discovery messages MUST use GTSM > [RFC5082]. With GTSM, discovery packets are sent with a TTL of > 255 and packets received with a TTL smaller than 255 are ignored > upon receipt. I hit a problem. The advice I gathered from various on-line sources was to set IPV6_MULTICAST_HOPS to 1 for link-local multicasts. Since they are by definition link-local, a hop limit of 1 makes sense. In any case the packets can never be forwarded to another link by a layer 3 action, whatever the hop limit. (Experimentally, it doesn't seem to matter what hop limit is set in LL multicasts, which is logical enough since they are never forwarded. But 1 makes more sense than 255.) GTSM seems to have been designed to protect against forged off-link unicast packets. AFAIK, link-local multicast packets can't be forged by an off-link attacker. An on-link attacker can do whatever it wants, including implementing GTSM. So I don't see what threat GTSM mitigates in our case. Brian From nobody Sun Apr 17 21:57:31 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6606512DE9F for ; Sun, 17 Apr 2016 21:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 yhFX6jYwf0VO for ; Sun, 17 Apr 2016 21:57:26 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E465112DE60 for ; Sun, 17 Apr 2016 21:57:25 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id g184so203141597lfb.3 for ; Sun, 17 Apr 2016 21:57:25 -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; bh=wgpJ4h+xg4AiUt5mhmkE7DyxUzmVtlQ3Mr4aNPr6l3E=; b=PjtOs8d4HIovfXiX7Hin2DyZHVj0TVN9nw/QQCzIRSnt+4jPk1DmBaSmOaYu3CvvPG cNh9PGhbmqjHICtD5VXldb7qyqEPDI7Ck+pR2E55KTBCzihq+zJFQDDXgSD5RyFo9b4F pqmjpSS/Sa81g9XFvWsoVzwe2iAUM9BzEBWBcpzVywX1mS3My6S+bPxpuEs0/Yj1Bzn8 BTNtwlXypOiRUFYjdGulnbQ6bV0EUsg32LMHbE4cT1dkcII+rDV/ktam/cobFpqfWiKw V2HMin0JHfDR1cpNOYCCwKycrxlfILagGb7hPJAZvMrPn81nJhxAPfQg4rO7x4FeQw3p HyTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=wgpJ4h+xg4AiUt5mhmkE7DyxUzmVtlQ3Mr4aNPr6l3E=; b=WaZz35ziI6GbD+FtRYXD6EoNjk73wTb1KLL+jSIyv8L5ljnJ7x+q4EIFxq1slwSksT Q35HD4hhpHEIbztMXng5oRdhc3SswBKizdLhOyojJDq/y+EaB9mxB3HMsir9R5xVH/zt 8njUy52XZdZ/+kwlZ661D6VD8UgffuBIZu24D4jKLn7TtMOYi4rHOeqrH73qei0RrBZ2 VJ6dLDqcWJ0+krksMHCUPQJ1tnOlMmivbqUD7X9JIReddGxZMiY5UFjaZeF+cyqn6FiL 7r047eK+JRzZC7wIlAaqHn/FGUsduI6P6FRHO4Y9upBDyAvkmpvbS6MD7SMG6Y6I3a5H aaWA== X-Gm-Message-State: AOPr4FXt/5emWQ4CnkGJ36qivhyPOCXRoj5RDdLh7+vvj0I7PIWwsl6oZNBX2BPhZxgDWmT5oepXn9PtQNsr0A== MIME-Version: 1.0 X-Received: by 10.112.167.197 with SMTP id zq5mr7074290lbb.75.1460955444078; Sun, 17 Apr 2016 21:57:24 -0700 (PDT) Received: by 10.25.22.19 with HTTP; Sun, 17 Apr 2016 21:57:23 -0700 (PDT) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C2D66807@nkgeml514-mbx.china.huawei.com> References: <5706C848.10607@alcatel-lucent.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2D64869@nkgeml514-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2D66807@nkgeml514-mbx.china.huawei.com> Date: Sun, 17 Apr 2016 21:57:23 -0700 Message-ID: From: John Strassner To: "Liubing (Leo)" , John Strassner Content-Type: multipart/alternative; boundary=001a11c258c846f3c80530bb32fe Archived-At: Cc: Laurent Ciavaglia , =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= , Michael Behringer , anima Subject: Re: [Anima] Questions during ANIMA II session X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 04:57:29 -0000 --001a11c258c846f3c80530bb32fe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Bing, sorry for the delay; snipped answers below (see ..). On the other hand, in my mind GRASP naturally has some more or less =E2=80=9Cgeneric=E2=80=9D communication capabilities by its definition. Her= e is some analysis: - AN domain flooding. Not only Intent, but anything that need to be flooded to the domain. I understand that this is how GRASP has been designed. However, this incurs a certain amount of risk, including a larger attack surface and the danger of autonomic communications being swamped by other types of communications. I'm not saying that this is wrong, just that we need to be careful. *built-in loop avoidance capability For non-autonomic communications, cool. However, I'm not sure that autonomic communications needs this. - Pulling a set of information from a specific AN node: At some point, I'd really like to understand why this is preferred to a more generic pub-sub mechanism. This seems counter-intuitive to using a flooding approach, especially one that is non-constrained. I guess I'm old-fashioned, but symmetry is usually a good thing... However, there should be limitations on above mentioned communication: - either for flood or point-to-point communication, the conveyed information should be small enough to avoid transport-specific features such as fragmentation, streaming, re-transmitting etc. Agreed. However, one of the prototypical communication types in autonomic communication is the exchange of models, as well as theories, hypotheses, and supporting information. These can be quite large, which is why I think Michael originally suggested TFTP. CoAP is fine for me as well - the point is that early on, as we build up the reference model and related work (control loops, autonomic functions, etc) we need to consider what to do to exchange such types of information. - For any =E2=80=9Cgeneric=E2=80=9D communication, the ASAs need an = =E2=80=9Cobjective=E2=80=9D definition to indicate what information they=E2=80=99re exchanging, and als= o formulizing the information data structure. The objective could be standard, or private among a set of ASAs. We will need context and metadata for autonomics; I suggest that these two would serve well here. I also think we should concentrate on what you are calling "standard objectives". > I also think we need to differentiate between intent (as an input to the autonomic > network), traffic resulting from said intent, and other traffic that gathers observations > and produces results. It is not clear to me that we want to use the same network > these three types of information, as their associated data structures and properties > are likely **very** different. [Bing] I agree the above said three types of information should be naturally distinct at the content level. But I guess all the three types of information doesn=E2=80=99t necessarily mean it all AN relevant communicati= on? Correct. I said **differentiate between** intent and the other 2 types. regards, John On Tue, Apr 12, 2016 at 2:33 AM, Liubing (Leo) wrote: > Hi John, > > > > Please see replies inline. > > > > *From:* John Strassner [mailto:strazpdj@gmail.com] > *Sent:* Saturday, April 09, 2016 6:46 AM > *To:* Liubing (Leo); John Strassner > *Cc:* Laurent Ciavaglia; anima; J=C3=A9ferson Campos Nobre; Michael Behri= nger > *Subject:* Re: [Anima] Questions during ANIMA II session > > > > Hi Bing, > > > > > When we wrote the distribution draft, we also expected the GRASP could > > > not only distribute Intent, but as well as other valuable information. > > > > I think we need to be careful here. Just as Michael warned that we are > starting to > > call everything intent (and shouldn't), > > [Bing] I agree we should NOT consider Intent as a generic container for > various kinds of management information or command. > > > > I'm a bit scared that we are starting to > > view GRASP as a generic communications mechanism. > > [Bing] This is a reasonable caution, thanks. We definitely should NOT > abuse it. > > > > On the other hand, in my mind GRASP naturally has some more or less > =E2=80=9Cgeneric=E2=80=9D communication capabilities by its definition. H= ere is some > analysis: > > - AN domain flooding. Not only Intent, but anything that need to > be flooded to the domain. > > *leveraging GRASP-Flood > > *built-in loop avoidance capability > > - Pulling a set of information from a specific AN node: > > * leveraging GRASP-Sync > > - Multi-round point-to-point information exchange: > > *implying there is context/state during the exchange, not purely > transporting > > *leveraging GRASP-Negotiation > > > > However, there should be limitations on above mentioned communication: > > - either for flood or point-to-point communication, the conveyed > information should be small enough to avoid transport-specific features > such as fragmentation, streaming, re-transmitting etc. > > - For any =E2=80=9Cgeneric=E2=80=9D communication, the ASAs need a= n =E2=80=9Cobjective=E2=80=9D > definition to indicate what information they=E2=80=99re exchanging, and a= lso > formulizing the information data structure. The objective could be > standard, or private among a set of ASAs. > > > > > > I also think we need to differentiate between intent (as an input to the > autonomic > > network), traffic resulting from said intent, and other traffic that > gathers observations > > and produces results. It is not clear to me that we want to use the same > network > > these three types of information, as their associated data structures and > properties > > are likely **very** different. > > [Bing] I agree the above said three types of information should be > naturally distinct at the content level. But I guess all the three types = of > information doesn=E2=80=99t necessarily mean it all AN relevant communica= tion? > > > > Regarding to AN communication, as I understand, the scope is the > communications between ASAs. ASA communication might not only include > Intent. I think Laurent and Peloso=E2=80=99s proposals (Coordination, AS= A > Life-Cycle management, Knowledge exchange) are giving some good clues for > discussion. > > > > Best regards, > > Bing > > > > regards, > > John > > > > On Thu, Apr 7, 2016 at 2:11 PM, Liubing (Leo) > wrote: > > Hi Laurent, > > > > Thanks for the summary. You captured my point. > > I think the knowledge exchange is a valuable topic. When we wrote the > distribution draft, we also expected the GRASP could not only distribute > Intent, but as well as other valuable information. So I=E2=80=99m happy t= o see you > call it out. > > But I don=E2=80=99t know how sophisticate the knowledge exchange would be= , so it > will be great if you can sort out the specific requirements. Then let=E2= =80=99s > check whether it could be covered by the distribution function (probably > with extensions to current design). > > > > Best regards, > > Bing > > > > *From:* Laurent Ciavaglia [mailto:laurent.ciavaglia@nokia.com] > *Sent:* Thursday, April 07, 2016 5:51 PM > *To:* anima; Liubing (Leo); J=C3=A9ferson Campos Nobre; Michael Behringer > *Subject:* Questions during ANIMA II session > > > > Hello, > > Thanks for your patience re. the issues faced for the remote presentation= s. > I hope you still managed to understand our messages ;) > > There have been comments on the coordination and knowledge presentations. > Michael, J=C3=A9ferson and Bing: could you repeat your comment on the lis= t? > I caught the following: > > Q. Michael: examples of coordination, what a (minimal) policy engine coul= d > look like? start small. > > Q. Jeferson: implications on data models / measurement/monitoring... ? > > Q. Bing: use GRASP or other mechanisms. Clarify requirements for GRASP. > > Thanks, Laurent. > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > > > > > -- > > regards, > > John > --=20 regards, John --001a11c258c846f3c80530bb32fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Bing,

sorry for the delay= ; snipped answers below (see <jcs>..</jcs>).

On the other hand, in my mind GRASP naturally has some more or less =E2= =80=9Cgeneric=E2=80=9D communication capabilities by its definition. Here i= s some analysis:
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 AN domain flooding. Not only Intent, but anything that need to be flo= oded to the domain.


<jcs&= gt;
I understand that this is how GRASP has been designed. Howeve= r, this
incurs a certain amount of risk, including a larger attac= k surface and the
danger of autonomic communications being swampe= d by other types of
communications.

I= 9;m not saying that this is wrong, just that we need to be careful.
</jcs>

*built-in= loop avoidance capability

<jcs>
For non-autonomic communications, cool. However, I'm not sure = that
autonomic communications needs this.
</jcs><= /div>

-=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Pulling a set of information from= a specific AN node:

<jcs>
At some point, I'd really like to understand why this is prefe= rred to a
more generic pub-sub mechanism. This seems counter-intu= itive to
using a flooding approach, especially one that is non-co= nstrained. I
guess I'm old-fashioned, but symmetry is usually= a good thing...
</jcs>


However, there should be limitations on above mentioned communication= :

-= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 either for flood or point-to-p= oint communication, the conveyed information should be small enough to avoi= d transport-specific features such as fragmentation, streaming, re-transmit= ting etc.

<jcs>
Agreed. However, one of the prototypical communication types in
= autonomic communication is the exchange of models, as well as
the= ories, hypotheses, and supporting information. These can be
quite= large, which is why I think Michael originally suggested TFTP.
C= oAP is fine for me as well - the point is that early on, as we build
<= div>up the reference model and related work (control loops, autonomic
=
functions, etc) we need to consider what to do to exchange such
<= div>types of information.
</jcs>

-=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 For any =E2=80=9Cgeneric=E2=80=9D communication, the ASAs= need an =E2=80=9Cobjective=E2=80=9D definition to indicate what informatio= n they=E2=80=99re exchanging, and also formulizing the information data str= ucture. The objective could be standard, or private among a set of ASAs.

<jcs>
We will need context and metad= ata for autonomics; I suggest that
these two would serve well her= e. I also think we should concentrate
on what you are calling &qu= ot;standard objectives".
</jcs>

> I also think = we need to differentiate between intent (as an input to the autonomic

> ne= twork), traffic resulting from said intent, and other traffic that gathers = observations

> and produces results. It is not clear to me that we w= ant to use the same network

>=C2=A0these three types of information,= as their associated data structures and properties

> are likely **v= ery** different.


[Bing] I agree the above= said three types of information should be naturally distinct at the conten= t level. But I guess all the three types of information doesn=E2=80=99t nec= essarily mean it all AN relevant communication?

=C2=A0=

<jcs>
Correct. = I said **differentiate between** intent and the other 2 types.
</jcs>


regards,=
John


<= /u>


On Tue, Apr 12, 2016 at 2:33 AM, Liubing (Leo) <le= o.liubing@huawei.com> wrote:

Hi = John,

= =C2=A0

Ple= ase see replies inline.

= =C2=A0

From: John Strassner [mailto:strazpdj@gmail.com]
Sent: Saturday, April 09, 2016 6:46 AM
To: Liubing (Leo); John Strassner
Cc: Laurent Ciavaglia; anima; J=C3=A9ferson Campos Nobre; Michael Be= hringer
Subject: Re: [Anima] Questions during ANIMA II session=

=C2=A0

Hi Bing,

=C2=A0

>=C2=A0When we wrote the distribution draft, we also expected th= e GRASP could

> not only distribute Intent, but as well as other valuable info= rmation.

=C2=A0

I think we need to be careful h= ere. Just as Michael warned that we are starting to

call everything intent (and sho= uldn't),

[Bi= ng] I agree we should NOT consider Intent as a generic container for variou= s kinds of management information or command.

= =C2=A0

I'm a bit scared that we ar= e starting to

view GRASP as a generic communi= cations mechanism.

[Bi= ng] This is a reasonable caution, thanks. We definitely should NOT abuse it= .

= =C2=A0

On = the other hand, in my mind GRASP naturally has some more or less =E2=80=9Cg= eneric=E2=80=9D communication capabilities by its definition. Here is some = analysis:

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *leveraging GRASP-Flood

*built-in loop avoidance capability<= /span>

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * leveraging GRASP-Sync

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *implying there is context/st= ate during the exchange, not purely transporting

*leveraging GRASP-Negotiation=

= =C2=A0

How= ever, there should be limitations on above mentioned communication:<= u>

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =C2=A0

= =C2=A0

I also think we need to differe= ntiate between intent (as an input to the autonomic

network), traffic resulting fro= m said intent, and other traffic that gathers observations

and produces results. It is not= clear to me that we want to use the same network

these three types of informatio= n, as their associated data structures and properties<= /p>

are likely **very** different.<= u>

[Bi= ng] I agree the above said three types of information should be naturally d= istinct at the content level. But I guess all the three types of information doesn=E2=80=99t necessarily mean it all AN relevant communicat= ion?

= =C2=A0

Reg= arding to AN communication, as I understand, the scope is the communication= s between ASAs. ASA communication might not only include Intent. I think Laurent and Peloso=E2=80=99s =C2=A0proposals (Coordination, ASA Li= fe-Cycle management, Knowledge exchange) are giving some good clues for dis= cussion.

= =C2=A0

Bes= t regards,

Bin= g

=C2=A0

regards,

John

=C2=A0

On Thu, Apr 7, 2016 at 2:11 PM,= Liubing (Leo) <leo.liubing@huawei.com> wrote:

Hi = Laurent,

=C2= =A0

Tha= nks for the summary. You captured my point.

=C2= =A0I think the knowledge exchange is a valuable topic. When we wrote the di= stribution draft, we also expected the GRASP could not only distribute Intent, but as= well as other valuable information. So I=E2=80=99m happy to see you call i= t out.

But= I don=E2=80=99t know how sophisticate the knowledge exchange would be, so = it will be great if you can sort out the specific requirements. Then let=E2=80=99s check wh= ether it could be covered by the distribution function (probably with exten= sions to current design).<= /p>

=C2= =A0

Bes= t regards,

Bin= g

=C2= =A0

From: Laurent Ciavaglia [mailto:laurent.ciavaglia@nokia.com]
Sent: Thursday, April 07, 2016 5:51 PM
To: anima; Liubing (Leo); J=C3=A9ferson Campos Nobre; Michael Behrin= ger
Subject: Questions during ANIMA II session

=C2=A0

Hello,

Thanks for your patience re. the issues faced for the remote presentations.=
I hope you still managed to understand our messages ;)

There have been comments on the coordination and knowledge presentations. Michael, J=C3=A9ferson and Bing: could you repeat your comment on the list?=
I caught the following:

Q. Michael: examples of coordination, what a (minimal) policy engine could = look like? start small.

Q. Jeferson: implications on data models / measurement/monitoring... ?

Q. Bing: use GRASP or other mechanisms. Clarify requirements for GRASP.

Thanks, Laurent.

_______________________________________________
Anima mailing list
Anima@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/anima




--

regards,

John




--
regards,
John
--001a11c258c846f3c80530bb32fe-- From nobody Mon Apr 18 06:58:09 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A63A12DE93 for ; Mon, 18 Apr 2016 06:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 vLHIoM0Yc7jR for ; Mon, 18 Apr 2016 06:58:05 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CC6412DE83 for ; Mon, 18 Apr 2016 06:58:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2213; q=dns/txt; s=iport; t=1460987885; x=1462197485; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hDlOHzIanZujaIpfuey9PlQl+thy50RKv5SUZanacU4=; b=KMbtfYjUCECVbA+9U3L5+KiCZzW2z4ncubHXzdliVzQ6v5vsdD3NAU0/ 3WfH2NskMJ+LAm6GgU5bRKbTOf54Vhv8fOveyJX+CxfqxSvtbqJCqJA4U NQ1cFcPszunKQ+QUT9Ly1Wr+dCX4fdfpjRVrpCQaLbEdW79mM1+brKqrX 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BAAgB85xRX/5pdJa1dgzhTfQa6HwENg?= =?us-ascii?q?XEXC4VsAoEuOBQBAQEBAQEBZSeEQQEBAQQBAQE3NAsMBAIBCBEEAQEfCQcnCxQ?= =?us-ascii?q?JCAIEAQ0FCIghDrptAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSGIYRLhBqFewWYD?= =?us-ascii?q?gGOBoFuhE6IXI8qAR4BAUKDaGyHfj5+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,502,1454976000"; d="scan'208";a="262129098" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Apr 2016 13:58:04 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u3IDw4L4031491 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 18 Apr 2016 13:58:04 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 18 Apr 2016 08:58:03 -0500 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.009; Mon, 18 Apr 2016 08:58:02 -0500 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , Anima WG Thread-Topic: [Anima] GTSM in draft-ietf-anima-autonomic-control-plane-02 Thread-Index: AQHRmEih+E8UIeUrh0e7nvM2kKM3oJ+Pwyvg Date: Mon, 18 Apr 2016 13:58:02 +0000 Message-ID: <4dc6499048d14f748d80d0f9e1d31427@XCH-RCD-006.cisco.com> References: <5712E6FF.5070305@gmail.com> In-Reply-To: <5712E6FF.5070305@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.49.80.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Nancy Cam-Winget \(ncamwing\)" Subject: Re: [Anima] GTSM in draft-ietf-anima-autonomic-control-plane-02 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 13:58:06 -0000 I believe GTSM doesn't make sense for link local packets, since, as you poi= nt out, they can't be forwarded beyond the link anyway.=20 So I think we should write:=20 - if link local: GTSM not needed - if unicast to direct neighbour (do we ever do that?): GTSM is a strong SH= OULD (if not MUST) - if unicast to further away nodes: More complicated, only makes sense if w= e can predict the maximum path length in all conditions, which tends to be = hard.=20 Michael > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E > Carpenter > Sent: 17 April 2016 03:30 > To: Anima WG > Cc: Nancy Cam-Winget (ncamwing) > Subject: [Anima] GTSM in draft-ietf-anima-autonomic-control-plane-02 >=20 > Hi, >=20 > A bit of advice on a security matter, please! >=20 > I was thinking about how I would add the following requirement to the > GRASP prototype code: >=20 > > o GRASP link-local multicast discovery messages MUST use GTSM > > [RFC5082]. With GTSM, discovery packets are sent with a TTL of > > 255 and packets received with a TTL smaller than 255 are ignored > > upon receipt. >=20 > I hit a problem. The advice I gathered from various on-line sources was t= o set > IPV6_MULTICAST_HOPS to 1 for link-local multicasts. Since they are by > definition link-local, a hop limit of 1 makes sense. In any case the pack= ets can > never be forwarded to another link by a layer 3 action, whatever the hop > limit. >=20 > (Experimentally, it doesn't seem to matter what hop limit is set in LL > multicasts, which is logical enough since they are never forwarded. > But 1 makes more sense than 255.) >=20 > GTSM seems to have been designed to protect against forged off-link unica= st > packets. AFAIK, link-local multicast packets can't be forged by an off-li= nk > attacker. An on-link attacker can do whatever it wants, including > implementing GTSM. So I don't see what threat GTSM mitigates in our case. >=20 > Brian >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Mon Apr 18 13:08:39 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49CC712DDBF for ; Mon, 18 Apr 2016 13:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 H92YEwLaLo4B for ; Mon, 18 Apr 2016 13:08:35 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60DFC12D722 for ; Mon, 18 Apr 2016 13:08:35 -0700 (PDT) Received: by mail-pa0-x234.google.com with SMTP id er2so53533024pad.3 for ; Mon, 18 Apr 2016 13:08:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=L1LypRiO52DojLIgAhi+XqEHaUJ6Zq2nxNDPocAyhvM=; b=htx0F0SYR45GjFnQ6SHUjnLLZu6P6WXlvFpkgM3bDe9Qwxr0rLRh95S0F3yk4KeBUZ dmPfNuCb7QRBQ6aEfkmT/Un1Hp7q+MYYe7awJgKtLNpP2JmYs3pE1hramWRiW/Zi+PVV VJX2jMYd6OqcqjWPUYLonnmcJ2d7dTtKMHKYS15JSDphEfnjNCqE/UfCgBp0+7TBtDOy D+xmtX6z5UCVl+xPN5Vrs+mUP2ZG7GZcp+BRmTIsSEYhyv7yTU870AxOooFPUAlFpAub vsLl86CUrKxj8VIsdvZnMBhNzuZcfr1KLnGXusPqb91rpVTPS5IGo1yuavRtKt/h/na5 U70w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=L1LypRiO52DojLIgAhi+XqEHaUJ6Zq2nxNDPocAyhvM=; b=LyPdnW7tLDV4fHFc1nMxfm+bLhRCHaHwWdbuTAelPTTm1y2MWisrW3xxHp3lfW6UWw 6x/jvpIwpNF/LbbdiZfLrx8GgWkQfKWrDv6WhyTL4cfhx/xwLcwNgvnk0nC4rgI3+7S5 0bzdVhHV50kyr+1I/ENezIEY+HxrzafR66AFTfEKPWMRBD+9g7kFYs0MSgAJ3i5tu+CA hwEwtUwA3NTaGFdrDGqZYdBMzVblf9C7awhGbkhSokok3uHMYG38zSNQ1bvaZoVet9+3 gD426bIfJVpBhDCd3ojLShWR5+Pvz6PFxVPGMF4zXSl5CIR+JiZV+5t3yheqW3kAoxjD 3Ijg== X-Gm-Message-State: AOPr4FUKIIjCx7j+JUZP4FU3dODW0JCJfEf7TXtVxbB9CgDc2dlStnpyKraiN4lDNsqhkA== X-Received: by 10.66.72.198 with SMTP id f6mr34221621pav.60.1461010114977; Mon, 18 Apr 2016 13:08:34 -0700 (PDT) Received: from ?IPv6:2406:e007:679a:1:28cc:dc4c:9703:6781? ([2406:e007:679a:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id n10sm20023633pax.18.2016.04.18.13.08.30 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Apr 2016 13:08:33 -0700 (PDT) To: John Strassner , "Liubing (Leo)" References: <5706C848.10607@alcatel-lucent.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2D64869@nkgeml514-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2D66807@nkgeml514-mbx.china.huawei.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <57153EBE.3010301@gmail.com> Date: Tue, 19 Apr 2016 08:08:30 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Laurent Ciavaglia , =?UTF-8?Q?J=c3=a9ferson_Campos_Nobre?= , anima , Michael Behringer Subject: Re: [Anima] Questions during ANIMA II session X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 20:08:37 -0000 Comments in line... On 18/04/2016 16:57, John Strassner wrote: > Hi Bing, >=20 > sorry for the delay; snipped answers below (see ..). >=20 > On the other hand, in my mind GRASP naturally has some more or less > =E2=80=9Cgeneric=E2=80=9D communication capabilities by its definition.= Here is some > analysis: > - AN domain flooding. Not only Intent, but anything that need to= be > flooded to the domain. >=20 >=20 > > I understand that this is how GRASP has been designed. However, this > incurs a certain amount of risk, including a larger attack surface and = the > danger of autonomic communications being swamped by other types of > communications. >=20 > I'm not saying that this is wrong, just that we need to be careful. > This is why I keep banging on about LL multicast inside the ACP. When we are not protected by the ACP, we are speaking & listening in public. > *built-in loop avoidance capability > > For non-autonomic communications, cool. However, I'm not sure that > autonomic communications needs this. > It has at least three aspects: 1. Backstop against discovery messages radiating out too far, in case there are any issues with the AN domain boundary. 2. Ditto for flood messages. 3. Backstop against incompetent ASA code with a non-terminating negotiation algorithm. This is important because we might see very large numbers of ASAs written by a large variety of people. These are the apps of AN. > - Pulling a set of information from a specific AN node: > > At some point, I'd really like to understand why this is preferred to a= > more generic pub-sub mechanism. This seems counter-intuitive to > using a flooding approach, especially one that is non-constrained. I > guess I'm old-fashioned, but symmetry is usually a good thing... > I think it's because we tend to see each ASA as an independent actor, and potentially an independent source of information. I think we can construct pub/sub on top of that if we want to, but indeed we don't have a message bus or message hub. (Sorry, I was infected by MQ Series when I worked for IBM :-) > However, there should be limitations on above mentioned communication: >=20 > - either for flood or point-to-point communication, the conveyed= > information should be small enough to avoid transport-specific features= > such as fragmentation, streaming, re-transmitting etc. > > Agreed. However, one of the prototypical communication types in > autonomic communication is the exchange of models, as well as > theories, hypotheses, and supporting information. These can be > quite large, which is why I think Michael originally suggested TFTP. > CoAP is fine for me as well - the point is that early on, as we build > up the reference model and related work (control loops, autonomic > functions, etc) we need to consider what to do to exchange such > types of information. > I'm not sure I agree with either of you on this yet. Simply put, there's no reason that we can't use TCP between any two points in the ACP. So I'm not sure why we need anything else when a message exceeds one packet.= > - For any =E2=80=9Cgeneric=E2=80=9D communication, the ASAs need= an =E2=80=9Cobjective=E2=80=9D > definition to indicate what information they=E2=80=99re exchanging, and= also > formulizing the information data structure. The objective could be > standard, or private among a set of ASAs. > > We will need context and metadata for autonomics; I suggest that > these two would serve well here. I also think we should concentrate > on what you are calling "standard objectives". > That's clearly what *we* (the Anima WG) should concentrate on. But again,= ASAs are apps, and if this stuff works at all, there will be all sorts of privately defined objectives. (Which is why I care about the API and about the ability to support GRASP in high-level languages.) >> I also think we need to differentiate between intent (as an input to t= he autonomic >> network), traffic resulting from said intent, and other traffic that g= athers observations >> and produces results. It is not clear to me that we want to use the sa= me network >> these three types of information, as their associated data structures = and properties=20 >> are likely **very** different. >=20 > [Bing] I agree the above said three types of information should be > naturally distinct at the content level. But I guess all the three type= s of > information doesn=E2=80=99t necessarily mean it all AN relevant communi= cation? >=20 > > Correct. I said **differentiate between** intent and the other 2 types.= > Agreed. This is also why we've said that ASAs can use whatever communicat= ion method they like, once they've established contact using GRASP. Regards Brian > regards, > John >=20 >=20 >=20 > On Tue, Apr 12, 2016 at 2:33 AM, Liubing (Leo) = > wrote: >=20 >> Hi John, >> >> >> >> Please see replies inline. >> >> >> >> *From:* John Strassner [mailto:strazpdj@gmail.com] >> *Sent:* Saturday, April 09, 2016 6:46 AM >> *To:* Liubing (Leo); John Strassner >> *Cc:* Laurent Ciavaglia; anima; J=C3=A9ferson Campos Nobre; Michael Be= hringer >> *Subject:* Re: [Anima] Questions during ANIMA II session >> >> >> >> Hi Bing, >> >> >> >>> When we wrote the distribution draft, we also expected the GRASP coul= d >> >>> not only distribute Intent, but as well as other valuable information= =2E >> >> >> >> I think we need to be careful here. Just as Michael warned that we are= >> starting to >> >> call everything intent (and shouldn't), >> >> [Bing] I agree we should NOT consider Intent as a generic container fo= r >> various kinds of management information or command. >> >> >> >> I'm a bit scared that we are starting to >> >> view GRASP as a generic communications mechanism. >> >> [Bing] This is a reasonable caution, thanks. We definitely should NOT >> abuse it. >> >> >> >> On the other hand, in my mind GRASP naturally has some more or less >> =E2=80=9Cgeneric=E2=80=9D communication capabilities by its definition= =2E Here is some >> analysis: >> >> - AN domain flooding. Not only Intent, but anything that need t= o >> be flooded to the domain. >> >> *leveraging GRASP-Flood >> >> *built-in loop avoidance capability >> >> - Pulling a set of information from a specific AN node: >> >> * leveraging GRASP-Sync >> >> - Multi-round point-to-point information exchange: >> >> *implying there is context/state during the exchange, not purely >> transporting >> >> *leveraging GRASP-Negotiation >> >> >> >> However, there should be limitations on above mentioned communication:= >> >> - either for flood or point-to-point communication, the conveye= d >> information should be small enough to avoid transport-specific feature= s >> such as fragmentation, streaming, re-transmitting etc. >> >> - For any =E2=80=9Cgeneric=E2=80=9D communication, the ASAs nee= d an =E2=80=9Cobjective=E2=80=9D >> definition to indicate what information they=E2=80=99re exchanging, an= d also >> formulizing the information data structure. The objective could be >> standard, or private among a set of ASAs. >> >> >> >> >> >> I also think we need to differentiate between intent (as an input to t= he >> autonomic >> >> network), traffic resulting from said intent, and other traffic that >> gathers observations >> >> and produces results. It is not clear to me that we want to use the sa= me >> network >> >> these three types of information, as their associated data structures = and >> properties >> >> are likely **very** different. >> >> [Bing] I agree the above said three types of information should be >> naturally distinct at the content level. But I guess all the three typ= es of >> information doesn=E2=80=99t necessarily mean it all AN relevant commun= ication? >> >> >> >> Regarding to AN communication, as I understand, the scope is the >> communications between ASAs. ASA communication might not only include >> Intent. I think Laurent and Peloso=E2=80=99s proposals (Coordination,= ASA >> Life-Cycle management, Knowledge exchange) are giving some good clues = for >> discussion. >> >> >> >> Best regards, >> >> Bing >> >> >> >> regards, >> >> John >> >> >> >> On Thu, Apr 7, 2016 at 2:11 PM, Liubing (Leo) = >> wrote: >> >> Hi Laurent, >> >> >> >> Thanks for the summary. You captured my point. >> >> I think the knowledge exchange is a valuable topic. When we wrote the= >> distribution draft, we also expected the GRASP could not only distribu= te >> Intent, but as well as other valuable information. So I=E2=80=99m happ= y to see you >> call it out. >> >> But I don=E2=80=99t know how sophisticate the knowledge exchange would= be, so it >> will be great if you can sort out the specific requirements. Then let=E2= =80=99s >> check whether it could be covered by the distribution function (probab= ly >> with extensions to current design). >> >> >> >> Best regards, >> >> Bing >> >> >> >> *From:* Laurent Ciavaglia [mailto:laurent.ciavaglia@nokia.com] >> *Sent:* Thursday, April 07, 2016 5:51 PM >> *To:* anima; Liubing (Leo); J=C3=A9ferson Campos Nobre; Michael Behrin= ger >> *Subject:* Questions during ANIMA II session >> >> >> >> Hello, >> >> Thanks for your patience re. the issues faced for the remote presentat= ions. >> I hope you still managed to understand our messages ;) >> >> There have been comments on the coordination and knowledge presentatio= ns. >> Michael, J=C3=A9ferson and Bing: could you repeat your comment on the = list? >> I caught the following: >> >> Q. Michael: examples of coordination, what a (minimal) policy engine c= ould >> look like? start small. >> >> Q. Jeferson: implications on data models / measurement/monitoring... ?= >> >> Q. Bing: use GRASP or other mechanisms. Clarify requirements for GRASP= =2E >> >> Thanks, Laurent. >> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> >> >> >> >> -- >> >> regards, >> >> John >> >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Wed Apr 20 05:49:34 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971C912D0D8 for ; Wed, 20 Apr 2016 05:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 lpPMKicV2Tgv for ; Wed, 20 Apr 2016 05:49:30 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45AF212DCE5 for ; Wed, 20 Apr 2016 05:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4414; q=dns/txt; s=iport; t=1461156563; x=1462366163; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=BKR0FJEbwN2JKEdwmH8esyC5f+zNOQSP9Di9gWUTcgQ=; b=aAUXGNVDwL6PEfxWvtpR17qEV7vuIR0ksnFJzL98WRRKuHCJkI41P81q PtNFlmxfPeoMrCVxUISjNd4vwW1H4Afgw/PrVJUeUo1lisTvfwD9b8foj MIPbHgTwTIhUHClRaOJo2tOyqArDYOslbZrO2xbu3j2NJMov9j1Limz2L E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BGAgDeeRdX/4UNJK1egziBVrllAQ2Bc?= =?us-ascii?q?YdPOBQBAQEBAQEBZSeESCcTUQE1CUImAQQbiCGdD6EbAQEIAgEdhiGJSYUXBZg?= =?us-ascii?q?PAY4MgW2ETYhdjywBHgEBQoNoiDV+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,509,1454976000"; d="scan'208";a="263656770" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Apr 2016 12:49:22 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u3KCnMw3019042 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 20 Apr 2016 12:49:22 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 20 Apr 2016 07:49:20 -0500 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.009; Wed, 20 Apr 2016 07:49:20 -0500 From: "Michael Behringer (mbehring)" To: Anima WG Thread-Topic: Intent "beginning to end" Thread-Index: AdGbAEYKborLOcNBR7qt3zbaOPev0g== Date: Wed, 20 Apr 2016 12:49:20 +0000 Message-ID: <74b2701c9b10416cbd2c8043e33596f1@XCH-RCD-006.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.238.131] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Anima] Intent "beginning to end" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 20 Apr 2016 12:49:31 -0000 After the IETF discussions it is clear that we still don't have the same mo= del in our head when we're discussing how Intent is handled. Let's see whet= her we can get some naming agreement.=20 draft-du-anima-an-intent describes some of the content below (e.g., distrib= ution, interpretation), but there is no "beginning to end" flow on how Inte= nt "flows" through the network. It would help the discussion I think if we = formalised the entire flow. For example, in the below flow it is clear that= parameters you exchange as a result of interpreting Intent are not called = Intent. (I think this was one point we don't have agreement on).=20 Let me try to write down this "flow", as I see it, as a starting point for = discussion.=20 1. Business goals: The network owner wants the network to follow some busin= ess goals. (These goals are initially not formalised, in a computer science sense. = ) - these goals are formalised in a language -->=20 2. Intent: is the formalisation of business goals so that computer can deal= with them.=20 (encoded as a file; or several files) - this file must be "given to the network" --> 3. Ingestion: The Intent file(s) get instantiated on an autonomic node On a particular node, an intent file is "ingested".=20 - Now it needs to be distributed -->=20 4. Intent Distribution: Intent is flooded to all nodes in a network; Every node has a copy of the original "Intent" file(s), without modifica= tion.=20 Each node re-distributes the original Intent files, without modification= .=20 Therefore, Intent is optional and transitive in nature.=20 - the Intent files must now be interpreted by each node -->=20 5. Intent splitting (on each node):=20 Intent is split into sections, one for the ANI itself, others for specif= ic Autonomic Functions ASAs are notified if there is new Intent for them.=20 Some intent sections may not apply to a particular node Now each component of a node (ANI, all ASAs) know their respective Inten= t.=20 6. Intent Interpretation (on each node, by each function): The ANI as well as all ASAs on a node interpret their respective Intent. It gets translated into a "target configuration", taking into account lo= cal state. For this translation, it may be necessary for ASAs to communicate with A= SAs on other nodes,=20 to pass on resources (IP addresses), to negotiate, etc.=20 All such communications may be triggered by Intent, but the communicatio= ns themselves are NOT Intent. =20 (NB: This interpretation could also be done centrally, and the resulting= configs distributed; This is of course an option, but for that we don't need ANIMA. Therefor= e I suggest for the ANIMA work to focus on interpreting Intent locally on each node) Result: target configlet (not applied yet!!). 7. Conflict Resolution with non-autonomic management (on each node):=20 The target configlet resulting from Intent has the lowest prio; any othe= r management=20 method (CLI, NETCONF, etc) overrides Intent.=20 8. Conflict Resolution between autonomic components (on each node):=20 Each autonomic function needs to register with a "conflict resolution fu= nction"=20 which parameters it modifies; in case of conflict the conflict resolutio= n function takes a decision and feeds that back to the autonomic functions. This ma= y modify=20 the target configlet.=20 9. Applying the target configlet A type of "commit" of the configlet.=20 10. Feedback loops to NOC: The NOC needs to know about certain conditions:= =20 Conflicts with non-autonomic management (FYI) Not all conflicts can be resolved automatically. (may require NOC action= s) Undesirable states (deviations from expected default behaviour) may have= to be communicated;=20 To some extent, Intent itself can specify which conditions should trigge= r feedback=20 loops to the NOC. =20 Feedback loops may happen at other phases as well (ex: 8) I'm conscious that there are different views in the team; like I believe in= point 6 we're not yet aligned. Please take this list just as a basis for d= iscussion, nothing more. When we have consensus, I believe such a flow should be documented in draft= -du-anima-an-intent in its entirety, to give a full picture.=20 Feedback?=20 Michael From nobody Wed Apr 20 07:17:08 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 191B312DE5F for ; Wed, 20 Apr 2016 07:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 YZ2KvbX9E5OE for ; Wed, 20 Apr 2016 07:17:04 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 77C9312E4EA for ; Wed, 20 Apr 2016 07:17:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 2740B2642B5; Wed, 20 Apr 2016 07:17:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1461161824; bh=Z65oaOU6gnQ8+7pFNJbBAKyJufoO3CvMI4WtUbCbG24=; h=Subject:To:References:From:Date:In-Reply-To:From; b=GOREZw1AFA8Ezp7+fpQkyfMzHNiI2K95ZoAa45WyJGTNTB/vziIG+03oq4KDuXw7Y y0SmypZtvAfV1n3rSqsp/WP/YJVhpGlrNGybm19ZhR+XvMvb3xeeBIUlPWGfuS1cj3 Qdm3gdUhK9bVYJDdL+Xm7PcBlmoBy34tefgrTfRE= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (50-193-35-17-static.hfc.comcastbusiness.net [50.193.35.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id CFDAF263F41; Wed, 20 Apr 2016 07:17:03 -0700 (PDT) To: "Michael Behringer (mbehring)" , Anima WG References: <74b2701c9b10416cbd2c8043e33596f1@XCH-RCD-006.cisco.com> From: "Joel M. Halpern" Message-ID: <57178F54.5030406@joelhalpern.com> Date: Wed, 20 Apr 2016 10:16:52 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <74b2701c9b10416cbd2c8043e33596f1@XCH-RCD-006.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Intent "beginning to end" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 20 Apr 2016 14:17:06 -0000 It seems to me that for many kinds of business intentions, as translated into "intents", there will need to be an intelligent processing step that determines how this intent relates to the network state, and how the network needs to respond to this. While there are cases where this can be done at each AN, there are also many cases where this needs intermediate work. As I understand it, those intermediaries are AN, which produce results usable by other AN. While they will produce parameters for the AN, they will also, I expect produce refined intents. Yours, Joel On 4/20/16 8:49 AM, Michael Behringer (mbehring) wrote: > After the IETF discussions it is clear that we still don't have the same model in our head when we're discussing how Intent is handled. Let's see whether we can get some naming agreement. > > draft-du-anima-an-intent describes some of the content below (e.g., distribution, interpretation), but there is no "beginning to end" flow on how Intent "flows" through the network. It would help the discussion I think if we formalised the entire flow. For example, in the below flow it is clear that parameters you exchange as a result of interpreting Intent are not called Intent. (I think this was one point we don't have agreement on). > > Let me try to write down this "flow", as I see it, as a starting point for discussion. > > 1. Business goals: The network owner wants the network to follow some business goals. > (These goals are initially not formalised, in a computer science sense. ) > - these goals are formalised in a language --> > 2. Intent: is the formalisation of business goals so that computer can deal with them. > (encoded as a file; or several files) > - this file must be "given to the network" --> > 3. Ingestion: The Intent file(s) get instantiated on an autonomic node > On a particular node, an intent file is "ingested". > - Now it needs to be distributed --> > 4. Intent Distribution: Intent is flooded to all nodes in a network; > Every node has a copy of the original "Intent" file(s), without modification. > Each node re-distributes the original Intent files, without modification. > Therefore, Intent is optional and transitive in nature. > - the Intent files must now be interpreted by each node --> > 5. Intent splitting (on each node): > Intent is split into sections, one for the ANI itself, others for specific Autonomic Functions > ASAs are notified if there is new Intent for them. > Some intent sections may not apply to a particular node > Now each component of a node (ANI, all ASAs) know their respective Intent. > 6. Intent Interpretation (on each node, by each function): > The ANI as well as all ASAs on a node interpret their respective Intent. > It gets translated into a "target configuration", taking into account local state. > For this translation, it may be necessary for ASAs to communicate with ASAs on other nodes, > to pass on resources (IP addresses), to negotiate, etc. > All such communications may be triggered by Intent, but the communications themselves > are NOT Intent. > (NB: This interpretation could also be done centrally, and the resulting configs distributed; > This is of course an option, but for that we don't need ANIMA. Therefore I suggest for the > ANIMA work to focus on interpreting Intent locally on each node) > Result: target configlet (not applied yet!!). > 7. Conflict Resolution with non-autonomic management (on each node): > The target configlet resulting from Intent has the lowest prio; any other management > method (CLI, NETCONF, etc) overrides Intent. > 8. Conflict Resolution between autonomic components (on each node): > Each autonomic function needs to register with a "conflict resolution function" > which parameters it modifies; in case of conflict the conflict resolution function > takes a decision and feeds that back to the autonomic functions. This may modify > the target configlet. > 9. Applying the target configlet > A type of "commit" of the configlet. > 10. Feedback loops to NOC: The NOC needs to know about certain conditions: > Conflicts with non-autonomic management (FYI) > Not all conflicts can be resolved automatically. (may require NOC actions) > Undesirable states (deviations from expected default behaviour) may have to be communicated; > To some extent, Intent itself can specify which conditions should trigger feedback > loops to the NOC. > Feedback loops may happen at other phases as well (ex: 8) > > I'm conscious that there are different views in the team; like I believe in point 6 we're not yet aligned. Please take this list just as a basis for discussion, nothing more. > > When we have consensus, I believe such a flow should be documented in draft-du-anima-an-intent in its entirety, to give a full picture. > > Feedback? > Michael > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Wed Apr 20 13:25:54 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEA412E634 for ; Wed, 20 Apr 2016 13:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 BzG19uOxc-GR for ; Wed, 20 Apr 2016 13:25:50 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE96612E5F8 for ; Wed, 20 Apr 2016 13:25:49 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 937072002A; Wed, 20 Apr 2016 16:30:09 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DF8056375A; Wed, 20 Apr 2016 16:25:47 -0400 (EDT) From: Michael Richardson To: Anima WG In-Reply-To: <74b2701c9b10416cbd2c8043e33596f1@XCH-RCD-006.cisco.com> References: <74b2701c9b10416cbd2c8043e33596f1@XCH-RCD-006.cisco.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: "Michael Behringer \(mbehring\)" Subject: Re: [Anima] Intent "beginning to end" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 20 Apr 2016 20:25:52 -0000 --=-=-= Content-Type: text/plain Michael Behringer (mbehring) wrote: > 5. Intent splitting (on each node): > Intent is split into sections, one for the ANI itself, others for specific Autonomic Functions I didn't get this part. > 6. Intent Interpretation (on each node, by each function): > The ANI as well as all ASAs on a node interpret their respective Intent. > It gets translated into a "target configuration", taking into account local state. > For this translation, it may be necessary for ASAs to communicate with ASAs on other nodes, > to pass on resources (IP addresses), to negotiate, etc. > All such communications may be triggered by Intent, but the communications themselves > are NOT Intent. > (NB: This interpretation could also be done centrally, and the resulting configs distributed; > This is of course an option, but for that we don't need ANIMA. Therefore I suggest for the > ANIMA work to focus on interpreting Intent locally on each node) > Result: target configlet (not applied yet!!). I disagree with the NB for two reasons. First, "centrally" might mean "by vendor specific central system", and so we would need ANIMA so that different vendors can communicate. Secondly, we might need to discover the central system that can do the interpretation,accounting,or arithmetic. Consider Intent's relating to bandwidth allocation throughout a network might need a central place to put all the numbers so that they can be added, and then the resulting allocations ("configs") can be distributed back to the nodes. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVxflyYCLcPvd0N1lAQJKmAf8DaOadiLQQCLQvQY1NUc4OWfAgjn8FLq6 NFg5ZqLPkdROYniKQGHMuGYrTEh5u9F2l6oDCXCW6ekZfdshjYHBIp5O2tf/52hF IOLlICeLzrCj9VppDNWQoyDzoMaVjlWAmvjDMwD/wS8t3+TNdYyA6c2gi9idDFU4 Rhm2Bi/4+AJRSQGNLcTZ0xBekYxGhs1V/qTjpd2ggJl3x+jKUw9wEYFyoHG/gT5m s80pa+Rkkrei49jTEHZcAdoLSqoM1V83ibKw8kXOakrazNE+b70TND/bP/8vdeiK DJsa++7S3jxHrsky9dUXJ7cM3mQd3dCNqbmTATVYr7fHsw6qgLDTmQ== =85Wa -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 20 23:48:17 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0DF912D663 for ; Wed, 20 Apr 2016 23:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 jbMQ5JLH9rSr for ; Wed, 20 Apr 2016 23:48:13 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C74E212D58A for ; Wed, 20 Apr 2016 23:48:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2326; q=dns/txt; s=iport; t=1461221293; x=1462430893; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=VVAXFO39+cCgYoKMWkrRM4WQLUj4m7y53EJWVRMzdiQ=; b=E/eNjZxVrTrWT+6xmjFs/Okk0SN6KHwXgLh7ObHv/kcvrMJSSR2o3T24 StsziqJA6vo21VMe95CkZ0T0lkWWlNz+JNMN4UXLZ23jB8lfdkgh9s/sA 8y8eZ43hvRCXOrU8q23i3kFi7th3pEJP6/NxiQfNjHBvfdCmzLuTcz/qq k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQDEdhhX/5JdJa1egziBUAa5aAENg?= =?us-ascii?q?XKGDgKBQTgUAQEBAQEBAWUnhEEBAQEDATpECwIBCBgVCRAyJQEBBAESCIgaCL5?= =?us-ascii?q?1AQEBAQEBAQMBAQEBAQEBARiGIYRLhH6FFwWYDwGODI8XjywBHgEBQoNobIdJf?= =?us-ascii?q?gEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,512,1454976000"; d="scan'208";a="263341360" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Apr 2016 06:48:13 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u3L6mC0d010402 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Apr 2016 06:48:13 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 21 Apr 2016 01:48:12 -0500 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.009; Thu, 21 Apr 2016 01:48:11 -0500 From: "Michael Behringer (mbehring)" To: Michael Richardson , Anima WG Thread-Topic: [Anima] Intent "beginning to end" Thread-Index: AdGbAEYKborLOcNBR7qt3zbaOPev0gAbHUqAAAsNpUA= Date: Thu, 21 Apr 2016 06:48:11 +0000 Message-ID: References: <74b2701c9b10416cbd2c8043e33596f1@XCH-RCD-006.cisco.com> <13678.1461183947@obiwan.sandelman.ca> In-Reply-To: <13678.1461183947@obiwan.sandelman.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.238.131] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Intent "beginning to end" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 21 Apr 2016 06:48:15 -0000 > Michael Behringer (mbehring) wrote: > > 5. Intent splitting (on each node): > > Intent is split into sections, one for the ANI itself, others for s= pecific > Autonomic Functions >=20 > I didn't get this part. This is multiplexing (well, de-multiplexing). Intent contains sections whic= h pertain to a certain ASA. So the way I see it either an ASA polls for Int= ent for itself, or there is a notification to an ASA.=20 How could we phrase that better?=20 =20 > > 6. Intent Interpretation (on each node, by each function): > > The ANI as well as all ASAs on a node interpret their respective In= tent. > > It gets translated into a "target configuration", taking into accou= nt local > state. > > For this translation, it may be necessary for ASAs to communicate w= ith > ASAs on other nodes, > > to pass on resources (IP addresses), to negotiate, etc. > > All such communications may be triggered by Intent, but the > communications themselves > > are NOT Intent. > > (NB: This interpretation could also be done centrally, and the resu= lting > configs distributed; > > This is of course an option, but for that we don't need ANIMA. Ther= efore > I suggest for the > > ANIMA work to focus on interpreting Intent locally on each node) > > Result: target configlet (not applied yet!!). >=20 > I disagree with the NB for two reasons. > First, "centrally" might mean "by vendor specific central system", and so= we > would > need ANIMA so that different vendors can communicate. >=20 > Secondly, we might need to discover the central system that can do the > interpretation,accounting,or arithmetic. I agree with you. But I'm not sure we're on the same page here in the group= . Thus calling it out.=20 To me, ANIMA should distribute Intent to nodes, and *nodes* interpret it an= d "translate" it locally to a config notation that makes sense to that devi= ce.=20 > Consider Intent's relating to bandwidth allocation throughout a network > might need a central place to put all the numbers so that they can be add= ed, > and then the resulting allocations ("configs") can be distributed back to= the > nodes. I'm not sure which point you're making here?=20 Michael From nobody Wed Apr 20 23:52:18 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7F212E84D for ; Wed, 20 Apr 2016 23:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 SMndUjEUFMCT for ; Wed, 20 Apr 2016 23:52:15 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFF1512E85F for ; Wed, 20 Apr 2016 23:52:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6307; q=dns/txt; s=iport; t=1461221534; x=1462431134; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=PrsgAdlqQ22REzCkUVAgwiEdKt1grZpfysfqZGnq3uM=; b=EKibEB8eghbgzGLVfodRM60eRRXRrYdP76s7FvWhRtxCfkv7ZjWW6xLJ g/EHjH0T1jrdbOZj6XsR1l7icIkkighF7SQYtrdbdecVC0PKOrPltr+Y/ uI/ORSLHGcTZ76UMVoj5R2cPc0XZk3K+ATj4Dy1kyWrzuz7iYgDKYG9VP M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQBUdxhX/4YNJK1egzhTfQa5aAENg?= =?us-ascii?q?XIXC4VsAoFBOBQBAQEBAQEBZSeEQQEBAQMBAQEBJBM0EAcEAgEIEQQBAQEVCQk?= =?us-ascii?q?HJwsUCQgBAQQBEgiIGggOvmkBAQEBAQEBAQEBAQEBAQEBAQEBAQERBIYhhEuEf?= =?us-ascii?q?oUXBZgPAY4MgW2ETYhdjywBHgEBQoNobIdJfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,512,1454976000"; d="scan'208";a="263457109" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Apr 2016 06:52:13 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u3L6qDDw028491 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Apr 2016 06:52:13 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 21 Apr 2016 01:52:12 -0500 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.009; Thu, 21 Apr 2016 01:52:12 -0500 From: "Michael Behringer (mbehring)" To: "Joel M. Halpern" , Anima WG Thread-Topic: [Anima] Intent "beginning to end" Thread-Index: AdGbAEYKborLOcNBR7qt3zbaOPev0gAOOusAABgp4bA= Date: Thu, 21 Apr 2016 06:52:12 +0000 Message-ID: <46860e16d59549b6a8da05a0e46b1892@XCH-RCD-006.cisco.com> References: <74b2701c9b10416cbd2c8043e33596f1@XCH-RCD-006.cisco.com> <57178F54.5030406@joelhalpern.com> In-Reply-To: <57178F54.5030406@joelhalpern.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.238.131] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Intent "beginning to end" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 21 Apr 2016 06:52:17 -0000 > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: 20 April 2016 16:17 > To: Michael Behringer (mbehring) ; Anima WG > > Subject: Re: [Anima] Intent "beginning to end" >=20 > It seems to me that for many kinds of business intentions, as translated = into > "intents", there will need to be an intelligent processing step that > determines how this intent relates to the network state, and how the > network needs to respond to this. While there are cases where this can b= e > done at each AN, there are also many cases where this needs intermediate > work. Can you give an example? I think the model I've noted down below is reasona= bly simple, and having intermediate steps might make it a lot more complica= ted. Not saying we shouldn't consider that, but only if we have to :-)=20 > As I understand it, those intermediaries are AN, which produce results us= able > by other AN. While they will produce parameters for the AN, they will al= so, I > expect produce refined intents. This is where I have a hard time. If "Intent" is a business policy, how can= a node modify it?!? To me that seems impossible. I would really like to ke= ep Intent exactly the thing a human throws into the network; everything els= e is, well, something else.=20 Again, maybe an example would make this clearer?=20 Michael =20 > Yours, > Joel >=20 > On 4/20/16 8:49 AM, Michael Behringer (mbehring) wrote: > > After the IETF discussions it is clear that we still don't have the sam= e model > in our head when we're discussing how Intent is handled. Let's see whethe= r > we can get some naming agreement. > > > > draft-du-anima-an-intent describes some of the content below (e.g., > distribution, interpretation), but there is no "beginning to end" flow on= how > Intent "flows" through the network. It would help the discussion I think = if we > formalised the entire flow. For example, in the below flow it is clear th= at > parameters you exchange as a result of interpreting Intent are not called > Intent. (I think this was one point we don't have agreement on). > > > > Let me try to write down this "flow", as I see it, as a starting point = for > discussion. > > > > 1. Business goals: The network owner wants the network to follow some > business goals. > > (These goals are initially not formalised, in a computer science se= nse. ) > > - these goals are formalised in a language --> 2. Intent: is the > > formalisation of business goals so that computer can deal with them. > > (encoded as a file; or several files) > > - this file must be "given to the network" --> 3. Ingestion: The > > Intent file(s) get instantiated on an autonomic node > > On a particular node, an intent file is "ingested". > > - Now it needs to be distributed --> 4. Intent Distribution: > > Intent is flooded to all nodes in a network; > > Every node has a copy of the original "Intent" file(s), without > modification. > > Each node re-distributes the original Intent files, without modific= ation. > > Therefore, Intent is optional and transitive in nature. > > - the Intent files must now be interpreted by each node --> 5. > > Intent splitting (on each node): > > Intent is split into sections, one for the ANI itself, others for s= pecific > Autonomic Functions > > ASAs are notified if there is new Intent for them. > > Some intent sections may not apply to a particular node > > Now each component of a node (ANI, all ASAs) know their respective > Intent. > > 6. Intent Interpretation (on each node, by each function): > > The ANI as well as all ASAs on a node interpret their respective In= tent. > > It gets translated into a "target configuration", taking into accou= nt local > state. > > For this translation, it may be necessary for ASAs to communicate w= ith > ASAs on other nodes, > > to pass on resources (IP addresses), to negotiate, etc. > > All such communications may be triggered by Intent, but the > communications themselves > > are NOT Intent. > > (NB: This interpretation could also be done centrally, and the resu= lting > configs distributed; > > This is of course an option, but for that we don't need ANIMA. The= refore > I suggest for the > > ANIMA work to focus on interpreting Intent locally on each node) > > Result: target configlet (not applied yet!!). > > 7. Conflict Resolution with non-autonomic management (on each node): > > The target configlet resulting from Intent has the lowest prio; any= other > management > > method (CLI, NETCONF, etc) overrides Intent. > > 8. Conflict Resolution between autonomic components (on each node): > > Each autonomic function needs to register with a "conflict resoluti= on > function" > > which parameters it modifies; in case of conflict the conflict reso= lution > function > > takes a decision and feeds that back to the autonomic functions. Th= is may > modify > > the target configlet. > > 9. Applying the target configlet > > A type of "commit" of the configlet. > > 10. Feedback loops to NOC: The NOC needs to know about certain > conditions: > > Conflicts with non-autonomic management (FYI) > > Not all conflicts can be resolved automatically. (may require NOC a= ctions) > > Undesirable states (deviations from expected default behaviour) may > have to be communicated; > > To some extent, Intent itself can specify which conditions should t= rigger > feedback > > loops to the NOC. > > Feedback loops may happen at other phases as well (ex: 8) > > > > I'm conscious that there are different views in the team; like I believ= e in > point 6 we're not yet aligned. Please take this list just as a basis for > discussion, nothing more. > > > > When we have consensus, I believe such a flow should be documented in > draft-du-anima-an-intent in its entirety, to give a full picture. > > > > Feedback? > > Michael > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > From nobody Thu Apr 21 05:34:28 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAAD12E889 for ; Thu, 21 Apr 2016 05:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 SJw3UIXJvg88 for ; Thu, 21 Apr 2016 05:34:25 -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 1EC1412D652 for ; Thu, 21 Apr 2016 05:34:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CIC48130; Thu, 21 Apr 2016 12:34:22 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 21 Apr 2016 13:34:21 +0100 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Thu, 21 Apr 2016 20:34:14 +0800 From: Duzongpeng To: Michael Richardson Thread-Topic: [Anima] Intent "beginning to end" Thread-Index: AdGbAEYKborLOcNBR7qt3zbaOPev0v///vyA//5ux3A= Date: Thu, 21 Apr 2016 12:34:14 +0000 Message-ID: References: <74b2701c9b10416cbd2c8043e33596f1@XCH-RCD-006.cisco.com> <13678.1461183947@obiwan.sandelman.ca> In-Reply-To: <13678.1461183947@obiwan.sandelman.ca> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.149.226] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.5718C8CF.0068, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6efe51a54adb710ab01075694d61b710 Archived-At: Cc: Anima WG , "Michael Behringer \(mbehring\)" Subject: Re: [Anima] Intent "beginning to end" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 21 Apr 2016 12:34:27 -0000 Hi, Michael Richardson About the "centrally" and "distributed", I want to suggest that it depends= . Some simple ones perhaps is easy to handle, and every node can understand = and interpret the intent.=20 I think Michael Behringer has suggested to start with some simple function= s in the beginning. On the other side, I do not think ANIMA means every node make their own de= cisions for everything.=20 Some central node (maybe elected) may also exist in the ANIMA network for = some functions, such as making some high level decision after collecting en= ough network information. Best Regards Zongpeng Du -----Original Message----- From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael Richardson Sent: Thursday, April 21, 2016 4:26 AM To: Anima WG Cc: Michael Behringer (mbehring) Subject: Re: [Anima] Intent "beginning to end" Michael Behringer (mbehring) wrote: > 5. Intent splitting (on each node): > Intent is split into sections, one for the ANI itself, others for spe= cific Autonomic Functions I didn't get this part. > 6. Intent Interpretation (on each node, by each function): > The ANI as well as all ASAs on a node interpret their respective Inte= nt. > It gets translated into a "target configuration", taking into account= local state. > For this translation, it may be necessary for ASAs to communicate wit= h ASAs on other nodes, > to pass on resources (IP addresses), to negotiate, etc. > All such communications may be triggered by Intent, but the communica= tions themselves > are NOT Intent. > (NB: This interpretation could also be done centrally, and the result= ing configs distributed; > This is of course an option, but for that we don't need ANIMA. Theref= ore I suggest for the > ANIMA work to focus on interpreting Intent locally on each node) > Result: target configlet (not applied yet!!). I disagree with the NB for two reasons. First, "centrally" might mean "by vendor specific central system", and so w= e would need ANIMA so that different vendors can communicate. Secondly, we might need to discover the central system that can do the interpretation,accounting,or arithmetic. Consider Intent's relating to bandwidth allocation throughout a network mig= ht need a central place to put all the numbers so that they can be added, a= nd then the resulting allocations ("configs") can be distributed back to th= e nodes. -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Thu Apr 21 05:58:15 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA5412DE84 for ; Thu, 21 Apr 2016 05:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 eQ00Y7rPTzK4 for ; Thu, 21 Apr 2016 05:58:13 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD8DE12D617 for ; Thu, 21 Apr 2016 05:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4624; q=dns/txt; s=iport; t=1461243492; x=1462453092; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9ZzPXf5V7pNiSt21aNZ0/IR7a0zGDxCxLVxsVFSYysM=; b=EiN24f/dw/Fh80X1D55V5Wsrw2yt/4nGew7r7kD84C+cPUY509AKqp23 Y4nT/pzBd1m+XZd2DfYV/9AqcY2uSYuyX+dQ0b5WAgUH294Q6a/IPKY+P w+npbTuMNXH0qk2lJw5g21XPcrzE5TWJ85y8VBdNYW3Jnxs+jEdgzv21W M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgDrzRhX/4kNJK1egziBUAa5aQENg?= =?us-ascii?q?XKCXoMsAgICgS44FAEBAQEBAQFlJ4RBAQEBAwEnEz8FBwQCAQgRBAEBARUJCQc?= =?us-ascii?q?yFAkIAQEEAQ0FCIgaCL9DAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYhhEuEfoUXA?= =?us-ascii?q?QSYDwGODI8XjywBHgEBQoNobIdJfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,512,1454976000"; d="scan'208";a="264405914" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Apr 2016 12:58:11 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u3LCwBRG013519 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Apr 2016 12:58:11 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 21 Apr 2016 07:58:11 -0500 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.009; Thu, 21 Apr 2016 07:58:10 -0500 From: "Michael Behringer (mbehring)" To: Duzongpeng , Michael Richardson Thread-Topic: [Anima] Intent "beginning to end" Thread-Index: AdGbAEYKborLOcNBR7qt3zbaOPev0gAbHUqAACHSngAACiLr0A== Date: Thu, 21 Apr 2016 12:58:10 +0000 Message-ID: References: <74b2701c9b10416cbd2c8043e33596f1@XCH-RCD-006.cisco.com> <13678.1461183947@obiwan.sandelman.ca> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.238.131] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Anima WG Subject: Re: [Anima] Intent "beginning to end" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 21 Apr 2016 12:58:14 -0000 > -----Original Message----- > From: Duzongpeng [mailto:duzongpeng@huawei.com] > Sent: 21 April 2016 14:34 > To: Michael Richardson > Cc: Michael Behringer (mbehring) ; Anima WG > > Subject: RE: [Anima] Intent "beginning to end" >=20 > Hi, Michael Richardson >=20 > About the "centrally" and "distributed", I want to suggest that it > depends. >=20 > Some simple ones perhaps is easy to handle, and every node can > understand and interpret the intent. >=20 > I think Michael Behringer has suggested to start with some simple > functions in the beginning. >=20 > On the other side, I do not think ANIMA means every node make > their own decisions for everything. >=20 > Some central node (maybe elected) may also exist in the ANIMA > network for some functions, such as making some high level decision after > collecting enough network information. Absolutely! However, there are two ways of doing that, and neither involves= Intent:=20 1 - NMS/controller gets feedback; sees that it needs to make some adjustmen= ts in some places: In this case it would use a standard NETCONF call (for e= xample) to set corresponding parameters on specific nodes --> outside ANIMA= scope; we simply state "every other configuration type overrides Intent". = It's clear and easy.=20 2 - NMS/controller gets feedback; sees that it needs to make some adjustmen= ts, and uses ANIMA signalling to signal directly via GRASP what needs to be= done: That *is* in scope, but I think it is "after" Intent, and as such ou= tside scope for the Intent draft. To me, an autonomic function has various = ASAs, one of which could be in the NOC. They use GRASP / whatever to commun= icate. So this is really nothing to do with Intent. We just must make sure = in ANIMA that autonomic functions with all related ASAs have the tools they= need.=20 (Someone might argue here that as a result of the feedback loop Intent shou= ld be changed; I would argue: Maybe; but since Intent is on business level,= this would should involve some human intervention, thus a manual change of= Intent, and the same flow applies again. I think dynamic changes to Intent= are NOT a good idea. Put differently, I think Intent should not be touched= by the network.) These are good discussions! Do you agree with this view? If not, where not?= =20 Michael =20 > Best Regards > Zongpeng Du >=20 > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael > Richardson > Sent: Thursday, April 21, 2016 4:26 AM > To: Anima WG > Cc: Michael Behringer (mbehring) > Subject: Re: [Anima] Intent "beginning to end" >=20 >=20 > Michael Behringer (mbehring) wrote: > > 5. Intent splitting (on each node): > > Intent is split into sections, one for the ANI itself, others for s= pecific > Autonomic Functions >=20 > I didn't get this part. >=20 > > 6. Intent Interpretation (on each node, by each function): > > The ANI as well as all ASAs on a node interpret their respective In= tent. > > It gets translated into a "target configuration", taking into accou= nt local > state. > > For this translation, it may be necessary for ASAs to communicate w= ith > ASAs on other nodes, > > to pass on resources (IP addresses), to negotiate, etc. > > All such communications may be triggered by Intent, but the > communications themselves > > are NOT Intent. > > (NB: This interpretation could also be done centrally, and the resu= lting > configs distributed; > > This is of course an option, but for that we don't need ANIMA. Ther= efore > I suggest for the > > ANIMA work to focus on interpreting Intent locally on each node) > > Result: target configlet (not applied yet!!). >=20 > I disagree with the NB for two reasons. > First, "centrally" might mean "by vendor specific central system", and so= we > would > need ANIMA so that different vendors can communicate. >=20 > Secondly, we might need to discover the central system that can do the > interpretation,accounting,or arithmetic. >=20 > Consider Intent's relating to bandwidth allocation throughout a network > might need a central place to put all the numbers so that they can be add= ed, > and then the resulting allocations ("configs") can be distributed back to= the > nodes. >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 From nobody Thu Apr 21 07:08:57 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9EAA12E39C for ; Thu, 21 Apr 2016 07:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 hByt5cNNwyMt for ; Thu, 21 Apr 2016 07:08:55 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 1761F12E324 for ; Thu, 21 Apr 2016 07:08:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id CDB4D1C0B3D; Thu, 21 Apr 2016 07:08:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1461247734; bh=MRa2h4tgFcfxz6u9iNvi7zLZjeDe4aK53X6AzAiofLM=; h=Subject:To:References:From:Date:In-Reply-To:From; b=BnMa1oXwdWpxix/LHLcX48K7DwSmrARlcmHDX3pFEoH76qhkoLbn3fTZLVEH92oDp Yw40dpi3axBqLym+dagkeMJR1KzmRC2EU1JGa3LM/+u0yHJUf9TfaOSTpJzX9IC8+j lArFLX+4Ro/bbazhcutPrxuocv7fhtJYOOghIwc4= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (50-193-35-17-static.hfc.comcastbusiness.net [50.193.35.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 77F611C043C; Thu, 21 Apr 2016 07:08:54 -0700 (PDT) To: "Michael Behringer (mbehring)" , Anima WG References: <74b2701c9b10416cbd2c8043e33596f1@XCH-RCD-006.cisco.com> <57178F54.5030406@joelhalpern.com> <46860e16d59549b6a8da05a0e46b1892@XCH-RCD-006.cisco.com> From: "Joel M. Halpern" Message-ID: <5718DEE8.20709@joelhalpern.com> Date: Thu, 21 Apr 2016 10:08:40 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <46860e16d59549b6a8da05a0e46b1892@XCH-RCD-006.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Intent "beginning to end" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 21 Apr 2016 14:08:57 -0000 It would be nice if the problem is simpler than I think it is. An example that occurs to me is the usual set of traffic prioritization policies: Ensure that high quality traffic from Platinum customers gets priority, + ... other traffic selection policies + Policies that identify traffic + Ensure that no link is more than 70% utilized. Someone is going to have to decide which traffic goes where. I do not believe each network node independently, no matter how much AN intelligence it has, can act on these policies themselves. Yes, nodes can detect violations, but I can not see how they can remediate independently. Yours, Joel PS: Note that the number of clauses needed to define the intent heere is why I don't think about intent as being a single thing, but rather a collection of policy descriptions. On 4/21/16 2:52 AM, Michael Behringer (mbehring) wrote: >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: 20 April 2016 16:17 >> To: Michael Behringer (mbehring) ; Anima WG >> >> Subject: Re: [Anima] Intent "beginning to end" >> >> It seems to me that for many kinds of business intentions, as translated into >> "intents", there will need to be an intelligent processing step that >> determines how this intent relates to the network state, and how the >> network needs to respond to this. While there are cases where this can be >> done at each AN, there are also many cases where this needs intermediate >> work. > > Can you give an example? I think the model I've noted down below is reasonably simple, and having intermediate steps might make it a lot more complicated. Not saying we shouldn't consider that, but only if we have to :-) > >> As I understand it, those intermediaries are AN, which produce results usable >> by other AN. While they will produce parameters for the AN, they will also, I >> expect produce refined intents. > > This is where I have a hard time. If "Intent" is a business policy, how can a node modify it?!? To me that seems impossible. I would really like to keep Intent exactly the thing a human throws into the network; everything else is, well, something else. > > Again, maybe an example would make this clearer? > > Michael > >> Yours, >> Joel >> >> On 4/20/16 8:49 AM, Michael Behringer (mbehring) wrote: >>> After the IETF discussions it is clear that we still don't have the same model >> in our head when we're discussing how Intent is handled. Let's see whether >> we can get some naming agreement. >>> >>> draft-du-anima-an-intent describes some of the content below (e.g., >> distribution, interpretation), but there is no "beginning to end" flow on how >> Intent "flows" through the network. It would help the discussion I think if we >> formalised the entire flow. For example, in the below flow it is clear that >> parameters you exchange as a result of interpreting Intent are not called >> Intent. (I think this was one point we don't have agreement on). >>> >>> Let me try to write down this "flow", as I see it, as a starting point for >> discussion. >>> >>> 1. Business goals: The network owner wants the network to follow some >> business goals. >>> (These goals are initially not formalised, in a computer science sense. ) >>> - these goals are formalised in a language --> 2. Intent: is the >>> formalisation of business goals so that computer can deal with them. >>> (encoded as a file; or several files) >>> - this file must be "given to the network" --> 3. Ingestion: The >>> Intent file(s) get instantiated on an autonomic node >>> On a particular node, an intent file is "ingested". >>> - Now it needs to be distributed --> 4. Intent Distribution: >>> Intent is flooded to all nodes in a network; >>> Every node has a copy of the original "Intent" file(s), without >> modification. >>> Each node re-distributes the original Intent files, without modification. >>> Therefore, Intent is optional and transitive in nature. >>> - the Intent files must now be interpreted by each node --> 5. >>> Intent splitting (on each node): >>> Intent is split into sections, one for the ANI itself, others for specific >> Autonomic Functions >>> ASAs are notified if there is new Intent for them. >>> Some intent sections may not apply to a particular node >>> Now each component of a node (ANI, all ASAs) know their respective >> Intent. >>> 6. Intent Interpretation (on each node, by each function): >>> The ANI as well as all ASAs on a node interpret their respective Intent. >>> It gets translated into a "target configuration", taking into account local >> state. >>> For this translation, it may be necessary for ASAs to communicate with >> ASAs on other nodes, >>> to pass on resources (IP addresses), to negotiate, etc. >>> All such communications may be triggered by Intent, but the >> communications themselves >>> are NOT Intent. >>> (NB: This interpretation could also be done centrally, and the resulting >> configs distributed; >>> This is of course an option, but for that we don't need ANIMA. Therefore >> I suggest for the >>> ANIMA work to focus on interpreting Intent locally on each node) >>> Result: target configlet (not applied yet!!). >>> 7. Conflict Resolution with non-autonomic management (on each node): >>> The target configlet resulting from Intent has the lowest prio; any other >> management >>> method (CLI, NETCONF, etc) overrides Intent. >>> 8. Conflict Resolution between autonomic components (on each node): >>> Each autonomic function needs to register with a "conflict resolution >> function" >>> which parameters it modifies; in case of conflict the conflict resolution >> function >>> takes a decision and feeds that back to the autonomic functions. This may >> modify >>> the target configlet. >>> 9. Applying the target configlet >>> A type of "commit" of the configlet. >>> 10. Feedback loops to NOC: The NOC needs to know about certain >> conditions: >>> Conflicts with non-autonomic management (FYI) >>> Not all conflicts can be resolved automatically. (may require NOC actions) >>> Undesirable states (deviations from expected default behaviour) may >> have to be communicated; >>> To some extent, Intent itself can specify which conditions should trigger >> feedback >>> loops to the NOC. >>> Feedback loops may happen at other phases as well (ex: 8) >>> >>> I'm conscious that there are different views in the team; like I believe in >> point 6 we're not yet aligned. Please take this list just as a basis for >> discussion, nothing more. >>> >>> When we have consensus, I believe such a flow should be documented in >> draft-du-anima-an-intent in its entirety, to give a full picture. >>> >>> Feedback? >>> Michael >>> >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >>> From nobody Thu Apr 21 07:28:39 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07EFB12DE91 for ; Thu, 21 Apr 2016 07:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 6LRrEofqml-X for ; Thu, 21 Apr 2016 07:28:36 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E89C12B068 for ; Thu, 21 Apr 2016 07:28:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18916; q=dns/txt; s=iport; t=1461248916; x=1462458516; h=from:to:subject:date:message-id:mime-version; bh=+QgRIdyDpwLfKOt2hsJXlgtys4HhkW72wimTudP3OFQ=; b=W0NfRpENrnhwigphO6eaH4jAnNy8kSXRm0VX5EY8tuZtQj33aPu0FIG6 yhLD0BNMGoz/xXfBk262MWCH93DAipVZmqoFV0mz1IFCg5xSoeGM7JIbC AEDmQfkH4A5UgfxQ2aYz9hiGA3VzJoUJMPrg5gUpMFe6eSZ/ZbdJkC8VV s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A+AgDo4hhX/4YNJK1egmxMU30GhB+wW?= =?us-ascii?q?IRyAQ2BcxcBCoVsHoEVOBQBAQEBAQEBZSeEQgEBBAEBASAERx0BCC0SAwIEJQs?= =?us-ascii?q?UEwQBEogqDq45kRcBAQEBAQEBAQIBAQEBAQEBAQEBAREEiBYIgk6EbBKCQSuCK?= =?us-ascii?q?wWTHoRxAY4TgWaETYhdjywBHgEBQoNobId4fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,513,1454976000"; d="scan'208,217";a="262821897" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Apr 2016 14:28:35 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u3LESYeI030159 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 21 Apr 2016 14:28:34 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 21 Apr 2016 10:28:34 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Thu, 21 Apr 2016 10:28:33 -0400 From: "Jason Coleman (colemaj)" To: "Michael Behringer (mbehring)" , Anima WG Thread-Topic: [Anima] Intent "beginning to end" Thread-Index: AQHRm9oVborLOcNBR7qt3zbaOPev0g== Date: Thu, 21 Apr 2016 14:28:33 +0000 Message-ID: <7953A291-A567-4E38-8553-923F37CBB451@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.70.116] Content-Type: multipart/alternative; boundary="_000_7953A291A5674E388553923F37CBB451ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Intent "beginning to end" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 21 Apr 2016 14:28:38 -0000 --_000_7953A291A5674E388553923F37CBB451ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T25lIG9mIHRoZSB0aGluZ3MgdGhhdCBJIHdvdWxkIGxpa2UgdG8gc2VlIHVzIGFsbCBhZ3JlZSB1 cG9uIGlzIHRoZSB1bmRlcnN0YW5kaW5nIG9mIHdoYXQgd2UgYXJlIGF0dGVtcHRpbmcgdG8gZGVm aW5lIHdpdGggcmVzcGVjdCB0byBJbnRlbnQuICBXaGVuIHdlIHRhbGsgYWJvdXQgSW50ZW50IGlu IHRoaXMgbWFpbGVyIGFyZSB3ZSB0YWxraW5nIGFib3V0IOKAmEF1dG9ub21pYyBJbnRlbnTigJkg b3IgaG93IGFuIEF1dG9ub21pYyBOZXR3b3JrIGRlYWxzIHdpdGgg4oCYSW50ZW504oCZLg0KDQpU byBtZSB0aGUgZGlmZmVyZW5jZSBpcyB0aGF0IEF1dG9ub21pYyBJbnRlbnQgaXMgc29tZXRoaW5n IHRoYXQgaXMgd2hvbGx5IGRlZmluZWQgYW5kIHVzZWQgaW5zaWRlIG9mIGFuIEF1dG9ub21pYyBu ZXR3b3JrLCBhbmQgYW4gQXV0b25vbWljIG5ldHdvcmsgdGhhdCBpcyBkZWFsaW5nIHdpdGggSW50 ZW50IGlzIGFjY2VwdGluZyBJbnRlbnQgZnJvbSBhbiBvdXRzaWRlIHNvdXJjZSwgcGVyaGFwcyBB dXRvbm9taWMvcGVyaGFwcyBub3QsIGFuZCB0aGVuIGRpc3RyaWJ1dGluZyBpdCB0aHJvdWdoIHRo ZSBBTiB2aWEgQU4gcHJpbmNpcGxlcywgZmxvd3MsIGFuZCBkZWZpbml0aW9ucy4NCg0KSWYgd2Ug YXJlIGRpc2N1c3NpbmcgQXV0b25vbWljIEludGVudCB0aGVuIEkgYXNzdW1lIHRoYXQgd2UgYXJl IG5vdCB3b3JyaWVkIG9yIGNvbmNlcm5lZCBhYm91dCBvdGhlciBkZWZpbml0aW9ucyBvZiBJbnRl bnQgdGhhdCBhcmUgY3JlYXRlZCBvdXRzaWRlIG9mIEFOLiAgVGhlbiB3ZSBjYW4gZm9jdXMgZGlz Y3Vzc2lvbnMgYWJvdXQgQU4gSW50ZW50IGFzIG9ubHkgbGl2aW5nIG9uIEFOIGVuYWJsZWQgYW5k IGNvbm5lY3RlZCBkZXZpY2VzIGFuZCB0aGUgaW1wbGljYXRpb25zIG9mIHRoYXQuICBJZiB3ZSBh cmUgdGFsa2luZyBhYm91dCBhIG1vcmUgZ2VuZXJhbCBpZGVhIG9mIEludGVudCwgdGhlbiB3ZSBk byBuZWVkIHRvIHRoaW5rIGFib3V0IG90aGVyIGRlZmluaXRpb25zLCBhbmQgYWxzbyBob3cgYW4g QU4gbmV0d29yayB3aWxsIHdvcmsgd2l0aCBJbnRlbnQgdGhhdCBjb21lcyBmcm9tIG9yIG1vdmVz IHRvIG5vbi1BTiBuZXR3b3JrIGVsZW1lbnRzLg0KLS0NCkphc29uIENvbGVtYW4NCg0KT24gNC8y MC8xNiwgNzo0OSBBTSwgIkFuaW1hIG9uIGJlaGFsZiBvZiBNaWNoYWVsIEJlaHJpbmdlciAobWJl aHJpbmcpIiA8YW5pbWEtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86YW5pbWEtYm91bmNlc0BpZXRm Lm9yZz4gb24gYmVoYWxmIG9mIG1iZWhyaW5nQGNpc2NvLmNvbTxtYWlsdG86bWJlaHJpbmdAY2lz Y28uY29tPj4gd3JvdGU6DQoNCkFmdGVyIHRoZSBJRVRGIGRpc2N1c3Npb25zIGl0IGlzIGNsZWFy IHRoYXQgd2Ugc3RpbGwgZG9uJ3QgaGF2ZSB0aGUgc2FtZSBtb2RlbCBpbiBvdXIgaGVhZCB3aGVu IHdlJ3JlIGRpc2N1c3NpbmcgaG93IEludGVudCBpcyBoYW5kbGVkLiBMZXQncyBzZWUgd2hldGhl ciB3ZSBjYW4gZ2V0IHNvbWUgbmFtaW5nIGFncmVlbWVudC4NCg0KZHJhZnQtZHUtYW5pbWEtYW4t aW50ZW50IGRlc2NyaWJlcyBzb21lIG9mIHRoZSBjb250ZW50IGJlbG93IChlLmcuLCBkaXN0cmli dXRpb24sIGludGVycHJldGF0aW9uKSwgYnV0IHRoZXJlIGlzIG5vICJiZWdpbm5pbmcgdG8gZW5k IiBmbG93IG9uIGhvdyBJbnRlbnQgImZsb3dzIiB0aHJvdWdoIHRoZSBuZXR3b3JrLiBJdCB3b3Vs ZCBoZWxwIHRoZSBkaXNjdXNzaW9uIEkgdGhpbmsgaWYgd2UgZm9ybWFsaXNlZCB0aGUgZW50aXJl IGZsb3cuIEZvciBleGFtcGxlLCBpbiB0aGUgYmVsb3cgZmxvdyBpdCBpcyBjbGVhciB0aGF0IHBh cmFtZXRlcnMgeW91IGV4Y2hhbmdlIGFzIGEgcmVzdWx0IG9mIGludGVycHJldGluZyBJbnRlbnQg YXJlIG5vdCBjYWxsZWQgSW50ZW50LiAoSSB0aGluayB0aGlzIHdhcyBvbmUgcG9pbnQgd2UgZG9u J3QgaGF2ZSBhZ3JlZW1lbnQgb24pLg0KDQpMZXQgbWUgdHJ5IHRvIHdyaXRlIGRvd24gdGhpcyAi ZmxvdyIsIGFzIEkgc2VlIGl0LCBhcyBhIHN0YXJ0aW5nIHBvaW50IGZvciBkaXNjdXNzaW9uLg0K DQoxLiBCdXNpbmVzcyBnb2FsczogVGhlIG5ldHdvcmsgb3duZXIgd2FudHMgdGhlIG5ldHdvcmsg dG8gZm9sbG93IHNvbWUgYnVzaW5lc3MgZ29hbHMuDQogICAoVGhlc2UgZ29hbHMgYXJlIGluaXRp YWxseSBub3QgZm9ybWFsaXNlZCwgaW4gYSBjb21wdXRlciBzY2llbmNlIHNlbnNlLiApDQogICAt IHRoZXNlIGdvYWxzIGFyZSBmb3JtYWxpc2VkIGluIGEgbGFuZ3VhZ2UgLS0+DQoyLiBJbnRlbnQ6 IGlzIHRoZSBmb3JtYWxpc2F0aW9uIG9mIGJ1c2luZXNzIGdvYWxzIHNvIHRoYXQgY29tcHV0ZXIg Y2FuIGRlYWwgd2l0aCB0aGVtLg0KICAgKGVuY29kZWQgYXMgYSBmaWxlOyBvciBzZXZlcmFsIGZp bGVzKQ0KICAgLSB0aGlzIGZpbGUgbXVzdCBiZSAiZ2l2ZW4gdG8gdGhlIG5ldHdvcmsiIC0tPg0K My4gSW5nZXN0aW9uOiBUaGUgSW50ZW50IGZpbGUocykgZ2V0IGluc3RhbnRpYXRlZCBvbiBhbiBh dXRvbm9taWMgbm9kZQ0KICAgT24gYSBwYXJ0aWN1bGFyIG5vZGUsIGFuIGludGVudCBmaWxlIGlz ICJpbmdlc3RlZCIuDQogICAtIE5vdyBpdCBuZWVkcyB0byBiZSBkaXN0cmlidXRlZCAtLT4NCjQu IEludGVudCBEaXN0cmlidXRpb246IEludGVudCBpcyBmbG9vZGVkIHRvIGFsbCBub2RlcyBpbiBh IG5ldHdvcms7DQogICBFdmVyeSBub2RlIGhhcyBhIGNvcHkgb2YgdGhlIG9yaWdpbmFsICJJbnRl bnQiIGZpbGUocyksIHdpdGhvdXQgbW9kaWZpY2F0aW9uLg0KICAgRWFjaCBub2RlIHJlLWRpc3Ry aWJ1dGVzIHRoZSBvcmlnaW5hbCBJbnRlbnQgZmlsZXMsIHdpdGhvdXQgbW9kaWZpY2F0aW9uLg0K ICAgVGhlcmVmb3JlLCBJbnRlbnQgaXMgb3B0aW9uYWwgYW5kIHRyYW5zaXRpdmUgaW4gbmF0dXJl Lg0KICAgLSB0aGUgSW50ZW50IGZpbGVzIG11c3Qgbm93IGJlIGludGVycHJldGVkIGJ5IGVhY2gg bm9kZSAtLT4NCjUuIEludGVudCBzcGxpdHRpbmcgKG9uIGVhY2ggbm9kZSk6DQogICBJbnRlbnQg aXMgc3BsaXQgaW50byBzZWN0aW9ucywgb25lIGZvciB0aGUgQU5JIGl0c2VsZiwgb3RoZXJzIGZv ciBzcGVjaWZpYyBBdXRvbm9taWMgRnVuY3Rpb25zDQogICBBU0FzIGFyZSBub3RpZmllZCBpZiB0 aGVyZSBpcyBuZXcgSW50ZW50IGZvciB0aGVtLg0KICAgU29tZSBpbnRlbnQgc2VjdGlvbnMgbWF5 IG5vdCBhcHBseSB0byBhIHBhcnRpY3VsYXIgIG5vZGUNCiAgIE5vdyBlYWNoIGNvbXBvbmVudCBv ZiBhIG5vZGUgKEFOSSwgYWxsIEFTQXMpIGtub3cgdGhlaXIgcmVzcGVjdGl2ZSBJbnRlbnQuDQo2 LiBJbnRlbnQgSW50ZXJwcmV0YXRpb24gKG9uIGVhY2ggbm9kZSwgYnkgZWFjaCBmdW5jdGlvbik6 DQogICBUaGUgQU5JIGFzIHdlbGwgYXMgYWxsIEFTQXMgb24gYSBub2RlIGludGVycHJldCB0aGVp ciByZXNwZWN0aXZlIEludGVudC4NCiAgIEl0IGdldHMgdHJhbnNsYXRlZCBpbnRvIGEgInRhcmdl dCBjb25maWd1cmF0aW9uIiwgdGFraW5nIGludG8gYWNjb3VudCBsb2NhbCBzdGF0ZS4NCiAgIEZv ciB0aGlzIHRyYW5zbGF0aW9uLCBpdCBtYXkgYmUgbmVjZXNzYXJ5IGZvciBBU0FzIHRvIGNvbW11 bmljYXRlIHdpdGggQVNBcyBvbiBvdGhlciBub2RlcywNCiAgIHRvIHBhc3Mgb24gcmVzb3VyY2Vz IChJUCBhZGRyZXNzZXMpLCB0byBuZWdvdGlhdGUsIGV0Yy4NCiAgIEFsbCBzdWNoIGNvbW11bmlj YXRpb25zIG1heSBiZSB0cmlnZ2VyZWQgYnkgSW50ZW50LCBidXQgdGhlIGNvbW11bmljYXRpb25z IHRoZW1zZWx2ZXMNCiAgIGFyZSBOT1QgSW50ZW50Lg0KICAgKE5COiBUaGlzIGludGVycHJldGF0 aW9uIGNvdWxkIGFsc28gYmUgZG9uZSBjZW50cmFsbHksIGFuZCB0aGUgcmVzdWx0aW5nIGNvbmZp Z3MgZGlzdHJpYnV0ZWQ7DQogICAgVGhpcyBpcyBvZiBjb3Vyc2UgYW4gb3B0aW9uLCBidXQgZm9y IHRoYXQgd2UgZG9uJ3QgbmVlZCBBTklNQS4gVGhlcmVmb3JlIEkgc3VnZ2VzdCBmb3IgdGhlDQog ICAgQU5JTUEgd29yayB0byBmb2N1cyBvbiBpbnRlcnByZXRpbmcgSW50ZW50IGxvY2FsbHkgb24g ZWFjaCBub2RlKQ0KICAgUmVzdWx0OiB0YXJnZXQgY29uZmlnbGV0IChub3QgYXBwbGllZCB5ZXQh ISkuDQo3LiBDb25mbGljdCBSZXNvbHV0aW9uIHdpdGggbm9uLWF1dG9ub21pYyBtYW5hZ2VtZW50 IChvbiBlYWNoIG5vZGUpOg0KICAgVGhlIHRhcmdldCBjb25maWdsZXQgcmVzdWx0aW5nIGZyb20g SW50ZW50IGhhcyB0aGUgbG93ZXN0IHByaW87IGFueSBvdGhlciBtYW5hZ2VtZW50DQogICBtZXRo b2QgKENMSSwgTkVUQ09ORiwgZXRjKSBvdmVycmlkZXMgSW50ZW50Lg0KOC4gQ29uZmxpY3QgUmVz b2x1dGlvbiBiZXR3ZWVuIGF1dG9ub21pYyBjb21wb25lbnRzIChvbiBlYWNoIG5vZGUpOg0KICAg RWFjaCBhdXRvbm9taWMgZnVuY3Rpb24gbmVlZHMgdG8gcmVnaXN0ZXIgd2l0aCBhICJjb25mbGlj dCByZXNvbHV0aW9uIGZ1bmN0aW9uIg0KICAgd2hpY2ggcGFyYW1ldGVycyBpdCBtb2RpZmllczsg aW4gY2FzZSBvZiBjb25mbGljdCB0aGUgY29uZmxpY3QgcmVzb2x1dGlvbiBmdW5jdGlvbg0KICAg dGFrZXMgYSBkZWNpc2lvbiBhbmQgZmVlZHMgdGhhdCBiYWNrIHRvIHRoZSBhdXRvbm9taWMgZnVu Y3Rpb25zLiBUaGlzIG1heSBtb2RpZnkNCiAgIHRoZSB0YXJnZXQgY29uZmlnbGV0Lg0KOS4gQXBw bHlpbmcgdGhlIHRhcmdldCBjb25maWdsZXQNCiAgIEEgdHlwZSBvZiAiY29tbWl0IiBvZiB0aGUg Y29uZmlnbGV0Lg0KMTAuIEZlZWRiYWNrIGxvb3BzIHRvIE5PQzogVGhlIE5PQyBuZWVkcyB0byBr bm93IGFib3V0IGNlcnRhaW4gY29uZGl0aW9uczoNCiAgIENvbmZsaWN0cyB3aXRoIG5vbi1hdXRv bm9taWMgbWFuYWdlbWVudCAoRllJKQ0KICAgTm90IGFsbCBjb25mbGljdHMgY2FuIGJlIHJlc29s dmVkIGF1dG9tYXRpY2FsbHkuIChtYXkgcmVxdWlyZSBOT0MgYWN0aW9ucykNCiAgIFVuZGVzaXJh YmxlIHN0YXRlcyAoZGV2aWF0aW9ucyBmcm9tIGV4cGVjdGVkIGRlZmF1bHQgYmVoYXZpb3VyKSBt YXkgaGF2ZSB0byBiZSBjb21tdW5pY2F0ZWQ7DQogICBUbyBzb21lIGV4dGVudCwgSW50ZW50IGl0 c2VsZiBjYW4gc3BlY2lmeSB3aGljaCBjb25kaXRpb25zIHNob3VsZCB0cmlnZ2VyIGZlZWRiYWNr DQogICBsb29wcyB0byB0aGUgTk9DLg0KICAgRmVlZGJhY2sgbG9vcHMgbWF5IGhhcHBlbiBhdCBv dGhlciBwaGFzZXMgYXMgd2VsbCAoZXg6IDgpDQoNCkknbSBjb25zY2lvdXMgdGhhdCB0aGVyZSBh cmUgZGlmZmVyZW50IHZpZXdzIGluIHRoZSB0ZWFtOyBsaWtlIEkgYmVsaWV2ZSBpbiBwb2ludCA2 IHdlJ3JlIG5vdCB5ZXQgYWxpZ25lZC4gUGxlYXNlIHRha2UgdGhpcyBsaXN0IGp1c3QgYXMgYSBi YXNpcyBmb3IgZGlzY3Vzc2lvbiwgbm90aGluZyBtb3JlLg0KDQpXaGVuIHdlIGhhdmUgY29uc2Vu c3VzLCBJIGJlbGlldmUgc3VjaCBhIGZsb3cgc2hvdWxkIGJlIGRvY3VtZW50ZWQgaW4gZHJhZnQt ZHUtYW5pbWEtYW4taW50ZW50IGluIGl0cyBlbnRpcmV0eSwgdG8gZ2l2ZSBhIGZ1bGwgcGljdHVy ZS4NCg0KRmVlZGJhY2s/DQpNaWNoYWVsDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpBbmltYSBtYWlsaW5nIGxpc3QNCkFuaW1hQGlldGYub3JnPG1h aWx0bzpBbmltYUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vYW5pbWENCg0K --_000_7953A291A5674E388553923F37CBB451ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <9D5CF08357A857439D22249663C6A12E@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZTogMTRweDsgY29sb3I6IHJnYigwLCAwLCAwKTsiPg0KPGRpdj4NCjxkaXY+T25l IG9mIHRoZSB0aGluZ3MgdGhhdCBJIHdvdWxkIGxpa2UgdG8gc2VlIHVzIGFsbCBhZ3JlZSB1cG9u IGlzIHRoZSB1bmRlcnN0YW5kaW5nIG9mIHdoYXQgd2UgYXJlIGF0dGVtcHRpbmcgdG8gZGVmaW5l IHdpdGggcmVzcGVjdCB0byBJbnRlbnQuICZuYnNwO1doZW4gd2UgdGFsayBhYm91dCBJbnRlbnQg aW4gdGhpcyBtYWlsZXIgYXJlIHdlIHRhbGtpbmcgYWJvdXQg4oCYQXV0b25vbWljIEludGVudOKA mSBvciBob3cgYW4gQXV0b25vbWljIE5ldHdvcmsNCiBkZWFscyB3aXRoIOKAmEludGVudOKAmS48 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRvIG1lIHRoZSBkaWZmZXJlbmNlIGlzIHRo YXQgQXV0b25vbWljIEludGVudCBpcyBzb21ldGhpbmcgdGhhdCBpcyB3aG9sbHkgZGVmaW5lZCBh bmQgdXNlZCBpbnNpZGUgb2YgYW4gQXV0b25vbWljIG5ldHdvcmssIGFuZCBhbiBBdXRvbm9taWMg bmV0d29yayB0aGF0IGlzIGRlYWxpbmcgd2l0aCBJbnRlbnQgaXMgYWNjZXB0aW5nIEludGVudCBm cm9tIGFuIG91dHNpZGUgc291cmNlLCBwZXJoYXBzIEF1dG9ub21pYy9wZXJoYXBzIG5vdCwgYW5k DQogdGhlbiBkaXN0cmlidXRpbmcgaXQgdGhyb3VnaCB0aGUgQU4gdmlhIEFOIHByaW5jaXBsZXMs IGZsb3dzLCBhbmQgZGVmaW5pdGlvbnMuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5J ZiB3ZSBhcmUgZGlzY3Vzc2luZyBBdXRvbm9taWMgSW50ZW50IHRoZW4gSSBhc3N1bWUgdGhhdCB3 ZSBhcmUgbm90IHdvcnJpZWQgb3IgY29uY2VybmVkIGFib3V0IG90aGVyIGRlZmluaXRpb25zIG9m IEludGVudCB0aGF0IGFyZSBjcmVhdGVkIG91dHNpZGUgb2YgQU4uICZuYnNwO1RoZW4gd2UgY2Fu IGZvY3VzIGRpc2N1c3Npb25zIGFib3V0IEFOIEludGVudCBhcyBvbmx5IGxpdmluZyBvbiBBTiBl bmFibGVkIGFuZCBjb25uZWN0ZWQgZGV2aWNlcw0KIGFuZCB0aGUgaW1wbGljYXRpb25zIG9mIHRo YXQuICZuYnNwO0lmIHdlIGFyZSB0YWxraW5nIGFib3V0IGEgbW9yZSBnZW5lcmFsIGlkZWEgb2Yg SW50ZW50LCB0aGVuIHdlIGRvIG5lZWQgdG8gdGhpbmsgYWJvdXQgb3RoZXIgZGVmaW5pdGlvbnMs IGFuZCBhbHNvIGhvdyBhbiBBTiBuZXR3b3JrIHdpbGwgd29yayB3aXRoIEludGVudCB0aGF0IGNv bWVzIGZyb20gb3IgbW92ZXMgdG8gbm9uLUFOIG5ldHdvcmsgZWxlbWVudHMuPC9kaXY+DQo8ZGl2 Pi0tPC9kaXY+DQo8ZGl2Pg0KPGRpdiBpZD0iTUFDX09VVExPT0tfU0lHTkFUVVJFIj4NCjxkaXY+ SmFzb24gQ29sZW1hbiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+T24gNC8yMC8xNiwgNzo0OSBBTSwgJnF1b3Q7QW5pbWEgb24gYmVo YWxmIG9mIE1pY2hhZWwgQmVocmluZ2VyIChtYmVocmluZykmcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzphbmltYS1ib3VuY2VzQGlldGYub3JnIj5hbmltYS1ib3VuY2VzQGlldGYub3JnPC9hPiBv biBiZWhhbGYgb2YNCjxhIGhyZWY9Im1haWx0bzptYmVocmluZ0BjaXNjby5jb20iPm1iZWhyaW5n QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9S REVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAg NTsiPg0KPGRpdj5BZnRlciB0aGUgSUVURiBkaXNjdXNzaW9ucyBpdCBpcyBjbGVhciB0aGF0IHdl IHN0aWxsIGRvbid0IGhhdmUgdGhlIHNhbWUgbW9kZWwgaW4gb3VyIGhlYWQgd2hlbiB3ZSdyZSBk aXNjdXNzaW5nIGhvdyBJbnRlbnQgaXMgaGFuZGxlZC4gTGV0J3Mgc2VlIHdoZXRoZXIgd2UgY2Fu IGdldCBzb21lIG5hbWluZyBhZ3JlZW1lbnQuDQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2PmRyYWZ0LWR1LWFuaW1hLWFuLWludGVudCBkZXNjcmliZXMgc29tZSBvZiB0aGUgY29udGVu dCBiZWxvdyAoZS5nLiwgZGlzdHJpYnV0aW9uLCBpbnRlcnByZXRhdGlvbiksIGJ1dCB0aGVyZSBp cyBubyAmcXVvdDtiZWdpbm5pbmcgdG8gZW5kJnF1b3Q7IGZsb3cgb24gaG93IEludGVudCAmcXVv dDtmbG93cyZxdW90OyB0aHJvdWdoIHRoZSBuZXR3b3JrLiBJdCB3b3VsZCBoZWxwIHRoZSBkaXNj dXNzaW9uIEkgdGhpbmsgaWYgd2UgZm9ybWFsaXNlZCB0aGUgZW50aXJlIGZsb3cuDQogRm9yIGV4 YW1wbGUsIGluIHRoZSBiZWxvdyBmbG93IGl0IGlzIGNsZWFyIHRoYXQgcGFyYW1ldGVycyB5b3Ug ZXhjaGFuZ2UgYXMgYSByZXN1bHQgb2YgaW50ZXJwcmV0aW5nIEludGVudCBhcmUgbm90IGNhbGxl ZCBJbnRlbnQuIChJIHRoaW5rIHRoaXMgd2FzIG9uZSBwb2ludCB3ZSBkb24ndCBoYXZlIGFncmVl bWVudCBvbikuDQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkxldCBtZSB0cnkgdG8g d3JpdGUgZG93biB0aGlzICZxdW90O2Zsb3cmcXVvdDssIGFzIEkgc2VlIGl0LCBhcyBhIHN0YXJ0 aW5nIHBvaW50IGZvciBkaXNjdXNzaW9uLg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj4xLiBCdXNpbmVzcyBnb2FsczogVGhlIG5ldHdvcmsgb3duZXIgd2FudHMgdGhlIG5ldHdvcmsg dG8gZm9sbG93IHNvbWUgYnVzaW5lc3MgZ29hbHMuPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyAo VGhlc2UgZ29hbHMgYXJlIGluaXRpYWxseSBub3QgZm9ybWFsaXNlZCwgaW4gYSBjb21wdXRlciBz Y2llbmNlIHNlbnNlLiApPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyAtIHRoZXNlIGdvYWxzIGFy ZSBmb3JtYWxpc2VkIGluIGEgbGFuZ3VhZ2UgLS0mZ3Q7IDwvZGl2Pg0KPGRpdj4yLiBJbnRlbnQ6 IGlzIHRoZSBmb3JtYWxpc2F0aW9uIG9mIGJ1c2luZXNzIGdvYWxzIHNvIHRoYXQgY29tcHV0ZXIg Y2FuIGRlYWwgd2l0aCB0aGVtLg0KPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyAoZW5jb2RlZCBh cyBhIGZpbGU7IG9yIHNldmVyYWwgZmlsZXMpPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyAtIHRo aXMgZmlsZSBtdXN0IGJlICZxdW90O2dpdmVuIHRvIHRoZSBuZXR3b3JrJnF1b3Q7IC0tJmd0Ozwv ZGl2Pg0KPGRpdj4zLiBJbmdlc3Rpb246IFRoZSBJbnRlbnQgZmlsZShzKSBnZXQgaW5zdGFudGlh dGVkIG9uIGFuIGF1dG9ub21pYyBub2RlPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyBPbiBhIHBh cnRpY3VsYXIgbm9kZSwgYW4gaW50ZW50IGZpbGUgaXMgJnF1b3Q7aW5nZXN0ZWQmcXVvdDsuIDwv ZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsgLSBOb3cgaXQgbmVlZHMgdG8gYmUgZGlzdHJpYnV0ZWQg LS0mZ3Q7IDwvZGl2Pg0KPGRpdj40LiBJbnRlbnQgRGlzdHJpYnV0aW9uOiBJbnRlbnQgaXMgZmxv b2RlZCB0byBhbGwgbm9kZXMgaW4gYSBuZXR3b3JrOzwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsg RXZlcnkgbm9kZSBoYXMgYSBjb3B5IG9mIHRoZSBvcmlnaW5hbCAmcXVvdDtJbnRlbnQmcXVvdDsg ZmlsZShzKSwgd2l0aG91dCBtb2RpZmljYXRpb24uDQo8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7 IEVhY2ggbm9kZSByZS1kaXN0cmlidXRlcyB0aGUgb3JpZ2luYWwgSW50ZW50IGZpbGVzLCB3aXRo b3V0IG1vZGlmaWNhdGlvbi4NCjwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsgVGhlcmVmb3JlLCBJ bnRlbnQgaXMgb3B0aW9uYWwgYW5kIHRyYW5zaXRpdmUgaW4gbmF0dXJlLiA8L2Rpdj4NCjxkaXY+ Jm5ic3A7Jm5ic3A7IC0gdGhlIEludGVudCBmaWxlcyBtdXN0IG5vdyBiZSBpbnRlcnByZXRlZCBi eSBlYWNoIG5vZGUgLS0mZ3Q7IDwvZGl2Pg0KPGRpdj41LiBJbnRlbnQgc3BsaXR0aW5nIChvbiBl YWNoIG5vZGUpOiA8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7IEludGVudCBpcyBzcGxpdCBpbnRv IHNlY3Rpb25zLCBvbmUgZm9yIHRoZSBBTkkgaXRzZWxmLCBvdGhlcnMgZm9yIHNwZWNpZmljIEF1 dG9ub21pYyBGdW5jdGlvbnM8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7IEFTQXMgYXJlIG5vdGlm aWVkIGlmIHRoZXJlIGlzIG5ldyBJbnRlbnQgZm9yIHRoZW0uIDwvZGl2Pg0KPGRpdj4mbmJzcDsm bmJzcDsgU29tZSBpbnRlbnQgc2VjdGlvbnMgbWF5IG5vdCBhcHBseSB0byBhIHBhcnRpY3VsYXIm bmJzcDsmbmJzcDtub2RlPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyBOb3cgZWFjaCBjb21wb25l bnQgb2YgYSBub2RlIChBTkksIGFsbCBBU0FzKSBrbm93IHRoZWlyIHJlc3BlY3RpdmUgSW50ZW50 Lg0KPC9kaXY+DQo8ZGl2PjYuIEludGVudCBJbnRlcnByZXRhdGlvbiAob24gZWFjaCBub2RlLCBi eSBlYWNoIGZ1bmN0aW9uKTo8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7IFRoZSBBTkkgYXMgd2Vs bCBhcyBhbGwgQVNBcyBvbiBhIG5vZGUgaW50ZXJwcmV0IHRoZWlyIHJlc3BlY3RpdmUgSW50ZW50 LjwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsgSXQgZ2V0cyB0cmFuc2xhdGVkIGludG8gYSAmcXVv dDt0YXJnZXQgY29uZmlndXJhdGlvbiZxdW90OywgdGFraW5nIGludG8gYWNjb3VudCBsb2NhbCBz dGF0ZS48L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7IEZvciB0aGlzIHRyYW5zbGF0aW9uLCBpdCBt YXkgYmUgbmVjZXNzYXJ5IGZvciBBU0FzIHRvIGNvbW11bmljYXRlIHdpdGggQVNBcyBvbiBvdGhl ciBub2RlcywNCjwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsgdG8gcGFzcyBvbiByZXNvdXJjZXMg KElQIGFkZHJlc3NlcyksIHRvIG5lZ290aWF0ZSwgZXRjLiA8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5i c3A7IEFsbCBzdWNoIGNvbW11bmljYXRpb25zIG1heSBiZSB0cmlnZ2VyZWQgYnkgSW50ZW50LCBi dXQgdGhlIGNvbW11bmljYXRpb25zIHRoZW1zZWx2ZXM8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7 IGFyZSBOT1QgSW50ZW50LiZuYnNwOyZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsgKE5C OiBUaGlzIGludGVycHJldGF0aW9uIGNvdWxkIGFsc28gYmUgZG9uZSBjZW50cmFsbHksIGFuZCB0 aGUgcmVzdWx0aW5nIGNvbmZpZ3MgZGlzdHJpYnV0ZWQ7PC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO1RoaXMgaXMgb2YgY291cnNlIGFuIG9wdGlvbiwgYnV0IGZvciB0aGF0IHdl IGRvbid0IG5lZWQgQU5JTUEuIFRoZXJlZm9yZSBJIHN1Z2dlc3QgZm9yIHRoZTwvZGl2Pg0KPGRp dj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtBTklNQSB3b3JrIHRvIGZvY3VzIG9uIGludGVycHJl dGluZyBJbnRlbnQgbG9jYWxseSBvbiBlYWNoIG5vZGUpPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNw OyBSZXN1bHQ6IHRhcmdldCBjb25maWdsZXQgKG5vdCBhcHBsaWVkIHlldCEhKS48L2Rpdj4NCjxk aXY+Ny4gQ29uZmxpY3QgUmVzb2x1dGlvbiB3aXRoIG5vbi1hdXRvbm9taWMgbWFuYWdlbWVudCAo b24gZWFjaCBub2RlKTogPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyBUaGUgdGFyZ2V0IGNvbmZp Z2xldCByZXN1bHRpbmcgZnJvbSBJbnRlbnQgaGFzIHRoZSBsb3dlc3QgcHJpbzsgYW55IG90aGVy IG1hbmFnZW1lbnQNCjwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsgbWV0aG9kIChDTEksIE5FVENP TkYsIGV0Yykgb3ZlcnJpZGVzIEludGVudC4gPC9kaXY+DQo8ZGl2PjguIENvbmZsaWN0IFJlc29s dXRpb24gYmV0d2VlbiBhdXRvbm9taWMgY29tcG9uZW50cyAob24gZWFjaCBub2RlKTogPC9kaXY+ DQo8ZGl2PiZuYnNwOyZuYnNwOyBFYWNoIGF1dG9ub21pYyBmdW5jdGlvbiBuZWVkcyB0byByZWdp c3RlciB3aXRoIGEgJnF1b3Q7Y29uZmxpY3QgcmVzb2x1dGlvbiBmdW5jdGlvbiZxdW90Ow0KPC9k aXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyB3aGljaCBwYXJhbWV0ZXJzIGl0IG1vZGlmaWVzOyBpbiBj YXNlIG9mIGNvbmZsaWN0IHRoZSBjb25mbGljdCByZXNvbHV0aW9uIGZ1bmN0aW9uPC9kaXY+DQo8 ZGl2PiZuYnNwOyZuYnNwOyB0YWtlcyBhIGRlY2lzaW9uIGFuZCBmZWVkcyB0aGF0IGJhY2sgdG8g dGhlIGF1dG9ub21pYyBmdW5jdGlvbnMuIFRoaXMgbWF5IG1vZGlmeQ0KPC9kaXY+DQo8ZGl2PiZu YnNwOyZuYnNwOyB0aGUgdGFyZ2V0IGNvbmZpZ2xldC4gPC9kaXY+DQo8ZGl2PjkuIEFwcGx5aW5n IHRoZSB0YXJnZXQgY29uZmlnbGV0PC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyBBIHR5cGUgb2Yg JnF1b3Q7Y29tbWl0JnF1b3Q7IG9mIHRoZSBjb25maWdsZXQuIDwvZGl2Pg0KPGRpdj4xMC4gRmVl ZGJhY2sgbG9vcHMgdG8gTk9DOiBUaGUgTk9DIG5lZWRzIHRvIGtub3cgYWJvdXQgY2VydGFpbiBj b25kaXRpb25zOiA8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7IENvbmZsaWN0cyB3aXRoIG5vbi1h dXRvbm9taWMgbWFuYWdlbWVudCAoRllJKTwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsgTm90IGFs bCBjb25mbGljdHMgY2FuIGJlIHJlc29sdmVkIGF1dG9tYXRpY2FsbHkuIChtYXkgcmVxdWlyZSBO T0MgYWN0aW9ucyk8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7IFVuZGVzaXJhYmxlIHN0YXRlcyAo ZGV2aWF0aW9ucyBmcm9tIGV4cGVjdGVkIGRlZmF1bHQgYmVoYXZpb3VyKSBtYXkgaGF2ZSB0byBi ZSBjb21tdW5pY2F0ZWQ7DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7IFRvIHNvbWUgZXh0ZW50 LCBJbnRlbnQgaXRzZWxmIGNhbiBzcGVjaWZ5IHdoaWNoIGNvbmRpdGlvbnMgc2hvdWxkIHRyaWdn ZXIgZmVlZGJhY2sNCjwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsgbG9vcHMgdG8gdGhlIE5PQy4m bmJzcDsmbmJzcDsgPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyBGZWVkYmFjayBsb29wcyBtYXkg aGFwcGVuIGF0IG90aGVyIHBoYXNlcyBhcyB3ZWxsIChleDogOCk8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PkknbSBjb25zY2lvdXMgdGhhdCB0aGVyZSBhcmUgZGlmZmVyZW50IHZpZXdz IGluIHRoZSB0ZWFtOyBsaWtlIEkgYmVsaWV2ZSBpbiBwb2ludCA2IHdlJ3JlIG5vdCB5ZXQgYWxp Z25lZC4gUGxlYXNlIHRha2UgdGhpcyBsaXN0IGp1c3QgYXMgYSBiYXNpcyBmb3IgZGlzY3Vzc2lv biwgbm90aGluZyBtb3JlLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V2hlbiB3ZSBo YXZlIGNvbnNlbnN1cywgSSBiZWxpZXZlIHN1Y2ggYSBmbG93IHNob3VsZCBiZSBkb2N1bWVudGVk IGluIGRyYWZ0LWR1LWFuaW1hLWFuLWludGVudCBpbiBpdHMgZW50aXJldHksIHRvIGdpdmUgYSBm dWxsIHBpY3R1cmUuDQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkZlZWRiYWNrPyA8 L2Rpdj4NCjxkaXY+TWljaGFlbDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L2Rpdj4NCjxkaXY+QW5p bWEgbWFpbGluZyBsaXN0PC9kaXY+DQo8ZGl2PjxhIGhyZWY9Im1haWx0bzpBbmltYUBpZXRmLm9y ZyI+QW5pbWFAaWV0Zi5vcmc8L2E+PC9kaXY+DQo8ZGl2PjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWEiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vYW5pbWE8L2E+PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7953A291A5674E388553923F37CBB451ciscocom_-- From nobody Thu Apr 21 09:53:37 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F17E12E18E for ; Thu, 21 Apr 2016 09:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 L_SqiUzFofkT for ; Thu, 21 Apr 2016 09:53:35 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29B5912DE82 for ; Thu, 21 Apr 2016 09:53:27 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9BA282002A; Thu, 21 Apr 2016 12:57:50 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0797963755; Thu, 21 Apr 2016 12:53:26 -0400 (EDT) From: Michael Richardson To: "Michael Behringer \(mbehring\)" In-Reply-To: References: <74b2701c9b10416cbd2c8043e33596f1@XCH-RCD-006.cisco.com> <13678.1461183947@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: Anima WG Subject: Re: [Anima] Intent "beginning to end" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 21 Apr 2016 16:53:36 -0000 --=-=-= Content-Type: text/plain Michael Behringer (mbehring) wrote: >> Consider Intent's relating to bandwidth allocation throughout a network >> might need a central place to put all the numbers so that they can be >> added and then the resulting allocations ("configs") can be >> distributed back to the nodes. > I'm not sure which point you're making here? I'm saying that even when there is no need for a central system to interpret Intent->Config, the set of nodes may still need (to elect) a central system in order to coordinate the totals for some configuration. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVxkFgoCLcPvd0N1lAQJa0ggAhiKwRE7rVXoECGhXf6ULNKODV89bpXqh ZX9rXugeJXIXVFNh2mTlK0Utr21SQ2ebQydCbxBIAoL8MibQvebO5ohYjGWG8YUR kaSgxmAo9AgcY6rVPP/tU1kuLPyK/Y4o+7C6dRbUG0vTROdlog3PxaMg5EyxOCZF Nt5jhMtx8HIVlEHveI7Zpd/j+CVGhITC0HolbtYYii22v13vcHCLZYYd6gxvFibV 1ZkTEhh4qMG281Frc9BwY/ZdzMy8FfXlryLOGesGhEYsEidHfwunWPOg1zZkLxLD 7mJCqNZ0MeTCJmlRAZOCyvSS0HSEH8SHa+QoxTXH7JGOevh8MY3d6Q== =dCBH -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 21 09:57:14 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B88412DD19 for ; Thu, 21 Apr 2016 09:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 0CPpT_UOx3Xg for ; Thu, 21 Apr 2016 09:57:12 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AED212DCA0 for ; Thu, 21 Apr 2016 09:57:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1168; q=dns/txt; s=iport; t=1461257832; x=1462467432; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ptYUd5c0XQ6HqW+HRv7tlYl7ln9IWjmBRa/aAm0oEH4=; b=jhexkEqBgds2zhIfYFvdmvZRYYZIRQbynbfiXIDPfJoae+o1DSyQHF/B tYAGKl4qSw5cNSaINylbfutE34nX9fhsbThBbFVr3wSJeOcm0342WfFuX /Y88SUwnn+0VMGLz8D7sKJUvji3TfNo9vow2q91eGiALiFrb3ETrHrQLI 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQA8BRlX/4cNJK1egziBUAa5bgENg?= =?us-ascii?q?XOGDgKBMzgUAQEBAQEBAWUnhEEBAQEEJxM/DAQCAQgRBAEBAR4JBzIUCQgBAQQ?= =?us-ascii?q?OBQiIIsAvAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYhhEuKFQWYDwGIb4UdjxePL?= =?us-ascii?q?AEeAQFCg2hsh3h+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,513,1454976000"; d="scan'208";a="263694304" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Apr 2016 16:57:11 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u3LGvB3k007104 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Apr 2016 16:57:11 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 21 Apr 2016 11:57:10 -0500 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.009; Thu, 21 Apr 2016 11:57:10 -0500 From: "Michael Behringer (mbehring)" To: Michael Richardson Thread-Topic: [Anima] Intent "beginning to end" Thread-Index: AdGbAEYKborLOcNBR7qt3zbaOPev0gAbHUqAAAsNpUAAH9JBgAAKadww Date: Thu, 21 Apr 2016 16:57:10 +0000 Message-ID: References: <74b2701c9b10416cbd2c8043e33596f1@XCH-RCD-006.cisco.com> <13678.1461183947@obiwan.sandelman.ca> <22819.1461257605@obiwan.sandelman.ca> In-Reply-To: <22819.1461257605@obiwan.sandelman.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.238.131] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Anima WG Subject: Re: [Anima] Intent "beginning to end" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 21 Apr 2016 16:57:13 -0000 > -----Original Message----- > From: Michael Richardson [mailto:mcr+ietf@sandelman.ca] > Sent: 21 April 2016 18:53 > To: Michael Behringer (mbehring) > Cc: Anima WG > Subject: Re: [Anima] Intent "beginning to end" >=20 >=20 > Michael Behringer (mbehring) wrote: > >> Consider Intent's relating to bandwidth allocation throughout a ne= twork > >> might need a central place to put all the numbers so that they can= be > >> added and then the resulting allocations ("configs") can be > >> distributed back to the nodes. >=20 > > I'm not sure which point you're making here? >=20 > I'm saying that even when there is no need for a central system to interp= ret > Intent->Config, the set of nodes may still need (to elect) a central > Intent->system > in order to coordinate the totals for some configuration. Thanks for clarifying - yes, we agree! But, see my mail to Duzongpeng ear= lier today, IMO this is outside scope of the Intent discussion, as I see it= . The transactions you describe would be part of an Autonomic Function. Agr= ee?=20 Michael From nobody Thu Apr 21 10:01:35 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F7F12E1D4 for ; Thu, 21 Apr 2016 10:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 tNCWbsHYrFrE for ; Thu, 21 Apr 2016 10:01:29 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCF4C12E15F for ; Thu, 21 Apr 2016 10:01:29 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 919D42002A for ; Thu, 21 Apr 2016 13:05:53 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D7A6763755 for ; Thu, 21 Apr 2016 13:01:28 -0400 (EDT) From: Michael Richardson To: Anima WG In-Reply-To: <5718DEE8.20709@joelhalpern.com> References: <74b2701c9b10416cbd2c8043e33596f1@XCH-RCD-006.cisco.com> <57178F54.5030406@joelhalpern.com> <46860e16d59549b6a8da05a0e46b1892@XCH-RCD-006.cisco.com> <5718DEE8.20709@joelhalpern.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Intent "beginning to end" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 21 Apr 2016 17:01:32 -0000 --=-=-= Content-Type: text/plain Joel M. Halpern wrote: > Someone is going to have to decide which traffic goes where. I do not > believe each network node independently, no matter how much AN > intelligence > it has, can act on these policies themselves. Yes, nodes can detect > violations, but I can not see how they can remediate independently. Yes, this is a good example of the why we might need to elect a central (bandwidth) manager, even though each AN can comprehend the Intent directly itself. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEUAwUBVxkHZYCLcPvd0N1lAQK9vwf4rpmhCLPla4MXMNBAJELqI4W/dEcfeG1A kJnoqmXG68aRWXO3gY9VSfYxPCr3KTzSdxl/mKyvdTpApUmqIGtxoBlXQvN1X8Ng RCyzpTvFVK9wdYfatt2tCQAah35zpnD6ju059MPhPgD95ta6xO2/MMNce4AA6Ofq dOW7mbog14xZTzmMNFneO1IvuurzvpRbHe8Bbko8RKjhdkhYzpwcZZsUqfqTSMzw KK8bVb4o2CWVpJkvlGBYn+Yj1YzqEb9gVkzmPTaFL1/SKUPYNFfwOySD1p8+Hmd0 vYxttKPbVF/i40d4ijs6MbY/2gOh9cK+kpTDmx1JGayXq7uxf9MK =FST/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 21 10:02:04 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A8612E1BE for ; Thu, 21 Apr 2016 10:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 Ita_twug_1bX for ; Thu, 21 Apr 2016 10:02:02 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E88912E166 for ; Thu, 21 Apr 2016 10:02:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1538; q=dns/txt; s=iport; t=1461258121; x=1462467721; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=CBah7k5Qs5APHzkHzeBn70eUA9Cw5S51Xyj9rEysEeA=; b=hvkbm1sZ6ZLAwMojDNwEif9TcqJCohdlNqzlVYRwZLvR8Zsycb+7Yw2s SLahTPrEJZgijsiO1ClRQpYeQfNYg+/nTGUZKfBcenbIhlDrRI3VgUN7A FEycsqKiYhhi///hMjq5bcxkYOIBw4ILC05KeWpp1sJOz1EHW6boOb3S/ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQBwBhlX/5NdJa1UCoM4gVAGuW4BD?= =?us-ascii?q?YFzhg4CgTM4FAEBAQEBAQFlJ4RBAQEBBDpLBAIBCBEEAQEfCQcyFAkIAQEEARI?= =?us-ascii?q?IiCLAGgEBAQEBAQEBAQEBAQEBAQEBAQEXhiGES4QVhgAFmA8BjgyPF48sAR4BA?= =?us-ascii?q?UKDaGyHeH4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,513,1454976000"; d="scan'208";a="263696846" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Apr 2016 17:02:00 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u3LH20jl032319 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Apr 2016 17:02:00 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 21 Apr 2016 12:01:59 -0500 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.009; Thu, 21 Apr 2016 12:01:59 -0500 From: "Michael Behringer (mbehring)" To: "Joel M. Halpern" , Anima WG Thread-Topic: [Anima] Intent "beginning to end" Thread-Index: AdGbAEYKborLOcNBR7qt3zbaOPev0gAOOusAABgp4bAAGddpAAAEi1Pw Date: Thu, 21 Apr 2016 17:01:59 +0000 Message-ID: References: <74b2701c9b10416cbd2c8043e33596f1@XCH-RCD-006.cisco.com> <57178F54.5030406@joelhalpern.com> <46860e16d59549b6a8da05a0e46b1892@XCH-RCD-006.cisco.com> <5718DEE8.20709@joelhalpern.com> In-Reply-To: <5718DEE8.20709@joelhalpern.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.238.131] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Intent "beginning to end" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 21 Apr 2016 17:02:03 -0000 > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: 21 April 2016 16:09 > To: Michael Behringer (mbehring) ; Anima WG > > Subject: Re: [Anima] Intent "beginning to end" >=20 > It would be nice if the problem is simpler than I think it is. >=20 > An example that occurs to me is the usual set of traffic prioritization > policies: >=20 > Ensure that high quality traffic from Platinum customers gets priority, > + > ... other traffic selection policies > + > Policies that identify traffic > + > Ensure that no link is more than 70% utilized. >=20 > Someone is going to have to decide which traffic goes where. I do not > believe each network node independently, no matter how much AN > intelligence it has, can act on these policies themselves. Yes, nodes ca= n > detect violations, but I can not see how they can remediate independently= . Now I understand, thanks for clarifying. That, to me, this should be covere= d in point=20 8. Conflict Resolution between autonomic components (on each node): Since, these are different autonomic functions that produce results that ne= ed a conflict resolution.=20 In other words, also here, I think this is outside Intent and Intent distri= bution.=20 Laurent is the specialist for conflict resolution - would be good to get hi= s perspective (but he's offline this week, afaik) Does that make sense, Joel, or am I over-simplifying?=20 Michael From nobody Thu Apr 21 10:04:38 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 491E612D8C4 for ; Thu, 21 Apr 2016 10:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 TY8ZkpM8BGwI for ; Thu, 21 Apr 2016 10:04:36 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E9B812D6E8 for ; Thu, 21 Apr 2016 10:04:36 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id EAA3A2002A for ; Thu, 21 Apr 2016 13:08:59 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4E8FB63755 for ; Thu, 21 Apr 2016 13:04:35 -0400 (EDT) From: Michael Richardson To: Anima WG In-Reply-To: References: <74b2701c9b10416cbd2c8043e33596f1@XCH-RCD-006.cisco.com> <13678.1461183947@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Intent "beginning to end" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 21 Apr 2016 17:04:37 -0000 --=-=-= Content-Type: text/plain Michael Behringer (mbehring) wrote: > (Someone might argue here that as a result of the feedback loop Intent > should be changed; I would argue: Maybe; but since Intent is on I agree that the Intent should be immutable. Maybe the NMS might tell the business person that the Intent is unreasonable after trying to implement it, but that would result in a New Intent. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVxkIIICLcPvd0N1lAQJDUQf8DkfRwk9/JrHtKn83QA8stwVm5Tmvv89p wAhHJRszum15pUTlIGva9Kb5Cup97KCbtOAjD8gBneWc1fpsJmR1IVZnALEzAt44 AB6FK0XtGGzb3uxGk5vezDYAzQY2829uXhR+p/H+p1Uqq5JvKOk375/HE0dXDXhm CdqX0OD1CKacaNbSWHMa5KI3s/Js6LBNOiIsTT8NOXCYba3NuD08/OyZobipea4F 0TK57Ff5vWG00yZeUpo4+qP8w7NPmj5Z68nqamhuQi13YMHhuzC5fp55gIHD5OFY TfGPvBO4dK3AxryLCjdvp3twMQ0MyGqjmX/MPXD/OMf8kpZk1VE8HA== =Mija -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 21 10:42:07 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A2912E839 for ; Thu, 21 Apr 2016 10:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 UZOofCxwCT9y for ; Thu, 21 Apr 2016 10:42:03 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 E616212E7F0 for ; Thu, 21 Apr 2016 10:42:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id A50E31C013E; Thu, 21 Apr 2016 10:42:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1461260523; bh=cegqfMgCHCKDBeFDrTqc/p/0ybqKlwDXJ7IpIMkPSEo=; h=Date:Subject:From:To:From; b=fSX4YSgrUuVAKDuum8qrhsfDWfh8pMjzEhahtxWWTx4+meVnLjfusWAc6nsmrAq/F bo8XapQzqKWTer7USVt/uW2eFzf4Y+tRzkv5VdPCS6fYxdw6Ip1piVTBBgclHC9YHp 3ojaBd2aIEjSw5N5ptVpyQryafb0xUyWLOpt/I5A= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.237.74.181] (unknown [166.170.43.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 08F23880671; Thu, 21 Apr 2016 10:42:02 -0700 (PDT) Date: Thu, 21 Apr 2016 10:41:58 -0700 Message-ID: Importance: normal From: "jmh.direct" To: "Michael Behringer (mbehring)" , "Joel M. Halpern" , Anima WG MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_1697086130739110" Archived-At: Subject: Re: [Anima] Intent "beginning to end" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 21 Apr 2016 17:42:05 -0000 ----_com.samsung.android.email_1697086130739110 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SSBhbSB1c2VkIHRvIGNvbmZsaWN0IHJlc29sdXRpIE9LIG5vdyBiZWluZyB1c2VkIGZvciB0aGUg aXNzdWUgb2YgYWN0dWFsIGNvbmZsaWN0cyBiZXR3ZWVuIHBvbGljaWVzLCByYXRoZXIgdGhhbiBm b3IgdGhlIHF1YXNpLWNlbnRyYWx1emVkIHJlc291cmNlIGFsbG9jYXRpb24gaXNzdWVzLiDCoEkg d2lsbCB3YWl0IGZvciBMYXVyZW4ncyByZXR1cm4uCllvdXJzLEpvZWwKCgpTZW50IHZpYSB0aGUg U2Ftc3VuZyBHYWxheHkgU8KuIDYsIGFuIEFUJlQgNEcgTFRFIHNtYXJ0cGhvbmUtLS0tLS0tLSBP cmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tRnJvbTogIk1pY2hhZWwgQmVocmluZ2VyIChtYmVocmlu ZykiIDxtYmVocmluZ0BjaXNjby5jb20+IERhdGU6IDQvMjEvMjAxNiAgMTA6MDEgQU0gIChHTVQt MDg6MDApIFRvOiAiSm9lbCBNLiBIYWxwZXJuIiA8am1oQGpvZWxoYWxwZXJuLmNvbT4sIEFuaW1h IFdHIDxhbmltYUBpZXRmLm9yZz4gU3ViamVjdDogUkU6IFtBbmltYV0gSW50ZW50ICJiZWdpbm5p bmcgdG8gZW5kIiAKPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+IEZyb206IEFuaW1hIFtt YWlsdG86YW5pbWEtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvZWwgTS4gSGFscGVy bgo+IFNlbnQ6IDIxIEFwcmlsIDIwMTYgMTY6MDkKPiBUbzogTWljaGFlbCBCZWhyaW5nZXIgKG1i ZWhyaW5nKSA8bWJlaHJpbmdAY2lzY28uY29tPjsgQW5pbWEgV0cKPiA8YW5pbWFAaWV0Zi5vcmc+ Cj4gU3ViamVjdDogUmU6IFtBbmltYV0gSW50ZW50ICJiZWdpbm5pbmcgdG8gZW5kIgo+IAo+IEl0 IHdvdWxkIGJlIG5pY2UgaWYgdGhlIHByb2JsZW0gaXMgc2ltcGxlciB0aGFuIEkgdGhpbmsgaXQg aXMuCj4gCj4gQW4gZXhhbXBsZSB0aGF0IG9jY3VycyB0byBtZSBpcyB0aGUgdXN1YWwgc2V0IG9m IHRyYWZmaWMgcHJpb3JpdGl6YXRpb24KPiBwb2xpY2llczoKPiAKPiBFbnN1cmUgdGhhdCBoaWdo IHF1YWxpdHkgdHJhZmZpYyBmcm9tIFBsYXRpbnVtIGN1c3RvbWVycyBnZXRzIHByaW9yaXR5LAo+ wqDCoCArCj4gLi4uIG90aGVyIHRyYWZmaWMgc2VsZWN0aW9uIHBvbGljaWVzCj7CoMKgICsKPiBQ b2xpY2llcyB0aGF0IGlkZW50aWZ5IHRyYWZmaWMKPsKgwqAgKwo+IEVuc3VyZSB0aGF0IG5vIGxp bmsgaXMgbW9yZSB0aGFuIDcwJSB1dGlsaXplZC4KPiAKPiBTb21lb25lIGlzIGdvaW5nIHRvIGhh dmUgdG8gZGVjaWRlIHdoaWNoIHRyYWZmaWMgZ29lcyB3aGVyZS7CoCBJIGRvIG5vdAo+IGJlbGll dmUgZWFjaCBuZXR3b3JrIG5vZGUgaW5kZXBlbmRlbnRseSwgbm8gbWF0dGVyIGhvdyBtdWNoIEFO Cj4gaW50ZWxsaWdlbmNlIGl0IGhhcywgY2FuIGFjdCBvbiB0aGVzZSBwb2xpY2llcyB0aGVtc2Vs dmVzLsKgIFllcywgbm9kZXMgY2FuCj4gZGV0ZWN0IHZpb2xhdGlvbnMsIGJ1dCBJIGNhbiBub3Qg c2VlIGhvdyB0aGV5IGNhbiByZW1lZGlhdGUgaW5kZXBlbmRlbnRseS4KCk5vdyBJIHVuZGVyc3Rh bmQsIHRoYW5rcyBmb3IgY2xhcmlmeWluZy4gVGhhdCwgdG8gbWUsIHRoaXMgc2hvdWxkIGJlIGNv dmVyZWQgaW4gcG9pbnQgCjguIENvbmZsaWN0IFJlc29sdXRpb24gYmV0d2VlbiBhdXRvbm9taWMg Y29tcG9uZW50cyAob24gZWFjaCBub2RlKToKClNpbmNlLCB0aGVzZSBhcmUgZGlmZmVyZW50IGF1 dG9ub21pYyBmdW5jdGlvbnMgdGhhdCBwcm9kdWNlIHJlc3VsdHMgdGhhdCBuZWVkIGEgY29uZmxp Y3QgcmVzb2x1dGlvbi4gCgpJbiBvdGhlciB3b3JkcywgYWxzbyBoZXJlLCBJIHRoaW5rIHRoaXMg aXMgb3V0c2lkZSBJbnRlbnQgYW5kIEludGVudCBkaXN0cmlidXRpb24uIAoKTGF1cmVudCBpcyB0 aGUgc3BlY2lhbGlzdCBmb3IgY29uZmxpY3QgcmVzb2x1dGlvbiAtIHdvdWxkIGJlIGdvb2QgdG8g Z2V0IGhpcyBwZXJzcGVjdGl2ZSAoYnV0IGhlJ3Mgb2ZmbGluZSB0aGlzIHdlZWssIGFmYWlrKQoK RG9lcyB0aGF0IG1ha2Ugc2Vuc2UsIEpvZWwsIG9yIGFtIEkgb3Zlci1zaW1wbGlmeWluZz8gCk1p Y2hhZWwK ----_com.samsung.android.email_1697086130739110 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PkkgYW0gdXNlZCB0byBjb25m bGljdCByZXNvbHV0aSBPSyBub3cgYmVpbmcgdXNlZCBmb3IgdGhlIGlzc3VlIG9mIGFjdHVhbCBj b25mbGljdHMgYmV0d2VlbiBwb2xpY2llcywgcmF0aGVyIHRoYW4gZm9yIHRoZSBxdWFzaS1jZW50 cmFsdXplZCByZXNvdXJjZSBhbGxvY2F0aW9uIGlzc3Vlcy4gJm5ic3A7SSB3aWxsIHdhaXQgZm9y IExhdXJlbidzIHJldHVybi48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PllvdXJzLDwvZGl2Pjxk aXY+Sm9lbDwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2 PjxkaXYgaWQ9ImNvbXBvc2VyX3NpZ25hdHVyZSI+PGRpdiBzdHlsZT0iZm9udC1zaXplOjg1JTtj b2xvcjojNTc1NzU3Ij5TZW50IHZpYSB0aGUgU2Ftc3VuZyBHYWxheHkgU8KuIDYsIGFuIEFUJmFt cDtUIDRHIExURSBzbWFydHBob25lPC9kaXY+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1zaXplOjEw MCU7Y29sb3I6IzAwMDAwMCI+PCEtLSBvcmlnaW5hbE1lc3NhZ2UgLS0+PGRpdj4tLS0tLS0tLSBP cmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tPC9kaXY+PGRpdj5Gcm9tOiAiTWljaGFlbCBCZWhyaW5n ZXIgKG1iZWhyaW5nKSIgJmx0O21iZWhyaW5nQGNpc2NvLmNvbSZndDsgPC9kaXY+PGRpdj5EYXRl OiA0LzIxLzIwMTYgIDEwOjAxIEFNICAoR01ULTA4OjAwKSA8L2Rpdj48ZGl2PlRvOiAiSm9lbCBN LiBIYWxwZXJuIiAmbHQ7am1oQGpvZWxoYWxwZXJuLmNvbSZndDssIEFuaW1hIFdHICZsdDthbmlt YUBpZXRmLm9yZyZndDsgPC9kaXY+PGRpdj5TdWJqZWN0OiBSRTogW0FuaW1hXSBJbnRlbnQgImJl Z2lubmluZyB0byBlbmQiIDwvZGl2PjxkaXY+PGJyPjwvZGl2PjwvZGl2PiZndDsgLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS08YnI+Jmd0OyBGcm9tOiBBbmltYSBbbWFpbHRvOmFuaW1hLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb2VsIE0uIEhhbHBlcm48YnI+Jmd0OyBTZW50OiAy MSBBcHJpbCAyMDE2IDE2OjA5PGJyPiZndDsgVG86IE1pY2hhZWwgQmVocmluZ2VyIChtYmVocmlu ZykgJmx0O21iZWhyaW5nQGNpc2NvLmNvbSZndDs7IEFuaW1hIFdHPGJyPiZndDsgJmx0O2FuaW1h QGlldGYub3JnJmd0Ozxicj4mZ3Q7IFN1YmplY3Q6IFJlOiBbQW5pbWFdIEludGVudCAiYmVnaW5u aW5nIHRvIGVuZCI8YnI+Jmd0OyA8YnI+Jmd0OyBJdCB3b3VsZCBiZSBuaWNlIGlmIHRoZSBwcm9i bGVtIGlzIHNpbXBsZXIgdGhhbiBJIHRoaW5rIGl0IGlzLjxicj4mZ3Q7IDxicj4mZ3Q7IEFuIGV4 YW1wbGUgdGhhdCBvY2N1cnMgdG8gbWUgaXMgdGhlIHVzdWFsIHNldCBvZiB0cmFmZmljIHByaW9y aXRpemF0aW9uPGJyPiZndDsgcG9saWNpZXM6PGJyPiZndDsgPGJyPiZndDsgRW5zdXJlIHRoYXQg aGlnaCBxdWFsaXR5IHRyYWZmaWMgZnJvbSBQbGF0aW51bSBjdXN0b21lcnMgZ2V0cyBwcmlvcml0 eSw8YnI+Jmd0OyZuYnNwOyZuYnNwOyArPGJyPiZndDsgLi4uIG90aGVyIHRyYWZmaWMgc2VsZWN0 aW9uIHBvbGljaWVzPGJyPiZndDsmbmJzcDsmbmJzcDsgKzxicj4mZ3Q7IFBvbGljaWVzIHRoYXQg aWRlbnRpZnkgdHJhZmZpYzxicj4mZ3Q7Jm5ic3A7Jm5ic3A7ICs8YnI+Jmd0OyBFbnN1cmUgdGhh dCBubyBsaW5rIGlzIG1vcmUgdGhhbiA3MCUgdXRpbGl6ZWQuPGJyPiZndDsgPGJyPiZndDsgU29t ZW9uZSBpcyBnb2luZyB0byBoYXZlIHRvIGRlY2lkZSB3aGljaCB0cmFmZmljIGdvZXMgd2hlcmUu Jm5ic3A7IEkgZG8gbm90PGJyPiZndDsgYmVsaWV2ZSBlYWNoIG5ldHdvcmsgbm9kZSBpbmRlcGVu ZGVudGx5LCBubyBtYXR0ZXIgaG93IG11Y2ggQU48YnI+Jmd0OyBpbnRlbGxpZ2VuY2UgaXQgaGFz LCBjYW4gYWN0IG9uIHRoZXNlIHBvbGljaWVzIHRoZW1zZWx2ZXMuJm5ic3A7IFllcywgbm9kZXMg Y2FuPGJyPiZndDsgZGV0ZWN0IHZpb2xhdGlvbnMsIGJ1dCBJIGNhbiBub3Qgc2VlIGhvdyB0aGV5 IGNhbiByZW1lZGlhdGUgaW5kZXBlbmRlbnRseS48YnI+PGJyPk5vdyBJIHVuZGVyc3RhbmQsIHRo YW5rcyBmb3IgY2xhcmlmeWluZy4gVGhhdCwgdG8gbWUsIHRoaXMgc2hvdWxkIGJlIGNvdmVyZWQg aW4gcG9pbnQgPGJyPjguIENvbmZsaWN0IFJlc29sdXRpb24gYmV0d2VlbiBhdXRvbm9taWMgY29t cG9uZW50cyAob24gZWFjaCBub2RlKTo8YnI+PGJyPlNpbmNlLCB0aGVzZSBhcmUgZGlmZmVyZW50 IGF1dG9ub21pYyBmdW5jdGlvbnMgdGhhdCBwcm9kdWNlIHJlc3VsdHMgdGhhdCBuZWVkIGEgY29u ZmxpY3QgcmVzb2x1dGlvbi4gPGJyPjxicj5JbiBvdGhlciB3b3JkcywgYWxzbyBoZXJlLCBJIHRo aW5rIHRoaXMgaXMgb3V0c2lkZSBJbnRlbnQgYW5kIEludGVudCBkaXN0cmlidXRpb24uIDxicj48 YnI+TGF1cmVudCBpcyB0aGUgc3BlY2lhbGlzdCBmb3IgY29uZmxpY3QgcmVzb2x1dGlvbiAtIHdv dWxkIGJlIGdvb2QgdG8gZ2V0IGhpcyBwZXJzcGVjdGl2ZSAoYnV0IGhlJ3Mgb2ZmbGluZSB0aGlz IHdlZWssIGFmYWlrKTxicj48YnI+RG9lcyB0aGF0IG1ha2Ugc2Vuc2UsIEpvZWwsIG9yIGFtIEkg b3Zlci1zaW1wbGlmeWluZz8gPGJyPk1pY2hhZWw8YnI+PC9ib2R5PjwvaHRtbD4= ----_com.samsung.android.email_1697086130739110-- From nobody Thu Apr 21 13:34:54 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1641F12D13A for ; Thu, 21 Apr 2016 13:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 7KcZU2T0Cd9P for ; Thu, 21 Apr 2016 13:34:50 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8928412D4FE for ; Thu, 21 Apr 2016 13:34:49 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id g184so67801305lfb.3 for ; Thu, 21 Apr 2016 13:34:49 -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; bh=HcYFwJYUx4fKs4mTV3YrNowrV3jcHzIpo+fq3aIm2UU=; b=OHDxMy9wmiwPwy0dPEF6MRC2rNXe2zCGyE1cn3BF0DmaKw5bf3FaflSiTOwdWD4Z8D N/AmGECf+zmCRUMg8I5zICCbooXOMwio5rDQ8GgO6712424XyoNDdGBjYdGNwJjqwkGP rS5hHkhy0q0HIUqPU5hWTvHOt29krYob5k3I82rts2vGNGdPLnj8TrhFBxVCDa5J4MaW bWo4bhyfcRSQWeImgFIRG2gY3IOjM5HZF2giYek8vWCGxsOwVsMIpSFGjnPKcQhmNKyW xFwG+ZCUrnpCOWwB6EVNeyTSQAlsHeaVMw3O9Jxswc8zEWnEDGzWoaRWQlRr8BVukFDp TwiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=HcYFwJYUx4fKs4mTV3YrNowrV3jcHzIpo+fq3aIm2UU=; b=RZ2VJsujn4FUVEVkIG0oN0t4Qrp2QTChTRDPZ3tn4BhNqZ9yp7JfCLLf4mutTSMcWf hBWMZIjCMFIVrff15nMVb2L+O9//55R9orE3ap20Hea865YrrCX58j8cE14JpLPSuqEK ReRt7GT3FZ/BGkKUeXr7qcm6YjNwcx5vXQjbKe5+7YjQuJBcTEJ6Y4IQJ8l5gts6Y2az BNp+cxmD5MMUyK/w+2IHYFScCSNyVh0ll2VEARphhkT8Ru2B3n8lLYC8XadL4OVHH6lI r+TXJ8QC6HpDdw5T2kXCjhlbwMFJHv3iKRBzCBzlzkIt49PFL2LEUEtC/mHALeNu2Ikh 9g0w== X-Gm-Message-State: AOPr4FXMKS4FPIitdFWl4GcHPSENoiNmo0VeuTPrMBesd/PAbVEx8WOa6bGsoih/0GgFOU6MWz7DuI9WwUbBLA== MIME-Version: 1.0 X-Received: by 10.25.142.201 with SMTP id q192mr7239816lfd.70.1461270887686; Thu, 21 Apr 2016 13:34:47 -0700 (PDT) Received: by 10.25.21.105 with HTTP; Thu, 21 Apr 2016 13:34:47 -0700 (PDT) In-Reply-To: <74b2701c9b10416cbd2c8043e33596f1@XCH-RCD-006.cisco.com> References: <74b2701c9b10416cbd2c8043e33596f1@XCH-RCD-006.cisco.com> Date: Thu, 21 Apr 2016 13:34:47 -0700 Message-ID: From: John Strassner To: "Michael Behringer (mbehring)" , John Strassner Content-Type: multipart/alternative; boundary=001a11401dcc2e6c7d053104a4eb Archived-At: Cc: Anima WG Subject: Re: [Anima] Intent "beginning to end" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 21 Apr 2016 20:34:53 -0000 --001a11401dcc2e6c7d053104a4eb Content-Type: text/plain; charset=UTF-8 Hi Michael, well, now you've done it. :-) This is an interesting and much needed stake in the ground; please see my replies inline. ... > It would help the discussion I think if we formalised the entire flow. Agreed! > For example, in the below flow it is clear that parameters you > exchange as a result of interpreting Intent are not called Intent. > (I think this was one point we don't have agreement on). I don't understand the term "parameters", but if you mean information resulting from the intent interpretation/compilation process, I agree. Note: I also agree that the exchange of such information is NOT intent. ... > 1. Business goals: The network owner wants the network to follow > some business goals. > (These goals are initially not formalised, in a computer science sense. > - these goals are formalised in a language --> Strongly agree. Since intent is by definition high-level, its primary users will be people that are not technical network admins (the *CIEs). Furthermore, another important user is the App Developer, most of which don't have a clue how to configure a network element. So especially for the latter, a **declarative** (NOT imperative) language is critical. However, since intent is abstract by definition, it will need specialized functions to interpret or compile it, and likely other specialized functions (I've used a multi-agent approach in the past) to understand intent. This applies to the rest of my comments below. ... > 4. Intent Distribution: Intent is flooded to all nodes in a network; > Every node has a copy of the original "Intent" file(s), without modification. > Each node re-distributes the original Intent files, without modification. > Therefore, Intent is optional and transitive in nature. > - the Intent files must now be interpreted by each node --> While I am happy for this behavior to be documented, and even defined as a default alternative, I want other behaviors to be possible. For example, if intent really is business-oriented, I posit that the average autonomic node will have NO IDEA what to do with it, or how to interpret it. Furthermore, why should it? In systems that I have seen and have built, this is a very specialized task. I would strongly prefer to see intent received by any node, but then sent to a set of specific nodes for interpretation or compilation. AFTER that, flood the results to all nodes. But flooding the results before it is established what intent is introduces too many variables into the mix. > 5. Intent splitting (on each node): > Intent is split into sections, one for the ANI itself, others for specific Autonomic Functions > ASAs are notified if there is new Intent for them. > Some intent sections may not apply to a particular node > Now each component of a node (ANI, all ASAs) know their respective Intent. You lost me. What is the purpose of splitting intent? This means that EVERY autonomic node now must have the ability to interpret or compile intent (perhaps without fully understanding it) AND must be a "traffic cop" to send the "intentlets" (sorry, low on coffee) to their proper destination. This means that each autonomic node either understands both the topology and the autonomic functions that each node supports (not likely!) or that there is metadata, or bits in the intent, or something to say where the destination is. Remember my earlier analogy with phones. Good luck selling an "intelligent" phone - the consumer will take higher resolution cameras, or better codecs, or anything other than something nebulous! > 6. Intent Interpretation (on each node, by each function): > The ANI as well as all ASAs on a node interpret their respective Intent. ... See above. ... > (NB: This interpretation could also be done centrally, and the resulting configs distributed; > This is of course an option, but for that we don't need ANIMA. Therefore I suggest for the > ANIMA work to focus on interpreting Intent locally on each node) > Result: target configlet (not applied yet!!). Sorry, I disagree. Why do we no longer need ANIMA? For example, let's say we replace GRASP with a pub-sub message queue (I'm NOT advocating this - just making an example). We still need ANIMA, because a pub-sub message queue does not understand how to facilitate autonomic behavior - it just delivers bits. > 7. Conflict Resolution with non-autonomic management (on each node): > The target configlet resulting from Intent has the lowest prio; any other management > method (CLI, NETCONF, etc) overrides Intent. This seems very difficult to me. Case 1: fully autonomic node How does it understand all of the legacy methods and translate those to an autonomic equivalent? This is an n^2 problem, and you need a normalized form so that the node doesn't have to understand the differences between CLI, private MIBs, etc. Case 2: fully dumb rock It won't have a clue what to do with autonomic intent. So again, we need a translation from the intent to a form that the dumb rock can understand. Case 3: node that has a clue about autonomics Even if we assume that it understands all of the legacy methods, how does it integrate those methods with intent? We could, for example, dedicate a set of ASAs to serve as translators. However, as I've stated in earlier posts, this is a very difficult task. I contend that we will need both models and ontologies (or some other form of logic) to do this, which is why I get scared when all nodes are assumed to be able to understand intent. > 8. Conflict Resolution between autonomic components (on each node): > Each autonomic function needs to register with a "conflict resolution function" > which parameters it modifies; in case of conflict the conflict resolution function > takes a decision and feeds that back to the autonomic functions. This may modify > the target configlet. I admire the effort you're putting into this to avoid building a centralized "God-Box". My problem is not with this step, but with how we got here. Let's table this. ... 10. Feedback loops to NOC: The NOC needs to know about certain conditions: ... Agreed! We have a draft explaining control loops, but we need to develop the reference architecture and "day in the life" further to gain better insight into how this is done. regards, John On Wed, Apr 20, 2016 at 5:49 AM, Michael Behringer (mbehring) < mbehring@cisco.com> wrote: > After the IETF discussions it is clear that we still don't have the same > model in our head when we're discussing how Intent is handled. Let's see > whether we can get some naming agreement. > > draft-du-anima-an-intent describes some of the content below (e.g., > distribution, interpretation), but there is no "beginning to end" flow on > how Intent "flows" through the network. It would help the discussion I > think if we formalised the entire flow. For example, in the below flow it > is clear that parameters you exchange as a result of interpreting Intent > are not called Intent. (I think this was one point we don't have agreement > on). > > Let me try to write down this "flow", as I see it, as a starting point for > discussion. > > 1. Business goals: The network owner wants the network to follow some > business goals. > (These goals are initially not formalised, in a computer science sense. > ) > - these goals are formalised in a language --> > 2. Intent: is the formalisation of business goals so that computer can > deal with them. > (encoded as a file; or several files) > - this file must be "given to the network" --> > 3. Ingestion: The Intent file(s) get instantiated on an autonomic node > On a particular node, an intent file is "ingested". > - Now it needs to be distributed --> > 4. Intent Distribution: Intent is flooded to all nodes in a network; > Every node has a copy of the original "Intent" file(s), without > modification. > Each node re-distributes the original Intent files, without > modification. > Therefore, Intent is optional and transitive in nature. > - the Intent files must now be interpreted by each node --> > 5. Intent splitting (on each node): > Intent is split into sections, one for the ANI itself, others for > specific Autonomic Functions > ASAs are notified if there is new Intent for them. > Some intent sections may not apply to a particular node > Now each component of a node (ANI, all ASAs) know their respective > Intent. > 6. Intent Interpretation (on each node, by each function): > The ANI as well as all ASAs on a node interpret their respective Intent. > It gets translated into a "target configuration", taking into account > local state. > For this translation, it may be necessary for ASAs to communicate with > ASAs on other nodes, > to pass on resources (IP addresses), to negotiate, etc. > All such communications may be triggered by Intent, but the > communications themselves > are NOT Intent. > (NB: This interpretation could also be done centrally, and the > resulting configs distributed; > This is of course an option, but for that we don't need ANIMA. > Therefore I suggest for the > ANIMA work to focus on interpreting Intent locally on each node) > Result: target configlet (not applied yet!!). > 7. Conflict Resolution with non-autonomic management (on each node): > The target configlet resulting from Intent has the lowest prio; any > other management > method (CLI, NETCONF, etc) overrides Intent. > 8. Conflict Resolution between autonomic components (on each node): > Each autonomic function needs to register with a "conflict resolution > function" > which parameters it modifies; in case of conflict the conflict > resolution function > takes a decision and feeds that back to the autonomic functions. This > may modify > the target configlet. > 9. Applying the target configlet > A type of "commit" of the configlet. > 10. Feedback loops to NOC: The NOC needs to know about certain conditions: > Conflicts with non-autonomic management (FYI) > Not all conflicts can be resolved automatically. (may require NOC > actions) > Undesirable states (deviations from expected default behaviour) may > have to be communicated; > To some extent, Intent itself can specify which conditions should > trigger feedback > loops to the NOC. > Feedback loops may happen at other phases as well (ex: 8) > > I'm conscious that there are different views in the team; like I believe > in point 6 we're not yet aligned. Please take this list just as a basis for > discussion, nothing more. > > When we have consensus, I believe such a flow should be documented in > draft-du-anima-an-intent in its entirety, to give a full picture. > > Feedback? > Michael > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > -- regards, John --001a11401dcc2e6c7d053104a4eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Michael,

well, now you= 9;ve done it. :-)
This is an interesting and much needed stake in= the ground; please see my replies inline.

...

>=C2=A0It would help the discussion I think if we = formalised the entire flow.

Agreed!

=
> For example, in the below flow it is clear that parameters = you
> exchange as a result of interpreting Intent are not call= ed Intent.
> (I think this was one point we don't have agr= eement on).

I=C2=A0don't understand the term &= quot;parameters", but if you mean information
resulting from= the intent interpretation/compilation process, I=C2=A0agree.
Note: I also agree that the exchange of such information is NOT= intent.

...

>=C2=A01. Business goals: The n= etwork owner wants the network to follow
> some business goals= .
> (These goals are initially not formalised, in a computer science = sense.=C2=A0
>=C2=A0 - these goals are formalised in a languag= e -->

Strongly agree. Since intent is by defini= tion high-level, its primary users
will be people that are not te= chnical network admins (the *CIEs).
Furthermore, another importan= t user is the App Developer, most of which
don't have a clue = how to configure a network element. So especially for
the latter,= a **declarative** (NOT imperative) language is critical.

However, since intent is abstract by definition, it will need speci= alized
functions to interpret or compile it, and likely other spe= cialized functions
(I've used a multi-agent approach in the p= ast) to understand intent.
This applies to the rest of my comment= s below.

...

> 4. Intent Distribu= tion: Intent is flooded to all nodes in a network;
>=C2=A0=C2=A0 Ever= y node has a copy of the original "Intent" file(s), without modif= ication.
>=C2=A0=C2=A0=C2=A0Each node re-distributes the original Int= ent files, without modification.
>=C2=A0 =C2=A0Therefore, Intent is = optional and transitive in nature.
>=C2=A0 =C2=A0- the Intent files = must now be interpreted by each node -->

While = I am happy for this behavior to be documented, and even defined
a= s a default alternative, I want other behaviors to be possible.
<= br>
For example, if intent really is business-oriented, I posit t= hat the average
autonomic node will have NO IDEA what to do with = it, or how to interpret
it. Furthermore, why should it? In system= s that I have seen and have
built, this is a very specialized tas= k.

I would strongly prefer to see intent received = by any node, but then sent
to a set of specific nodes for interpr= etation or compilation. AFTER that,
flood the results to all node= s. But flooding the results before it is
established what intent = is introduces too many variables into the mix.

> 5. Intent splitting (on each node):
>=C2=A0 =C2=A0Intent is sp= lit into sections, one for the ANI itself, others for specific Autonomic Fu= nctions
>=C2=A0 =C2=A0ASAs are notified if there is new Intent for t= hem.
>=C2=A0 =C2=A0Some intent sections may not apply to a particula= r=C2=A0 node
>=C2=A0=C2=A0=C2=A0=C2=A0Now each component of a node (A= NI, all ASAs) know their respective Intent.

You lo= st me. What is the purpose of splitting intent?=C2=A0This means that
<= div>EVERY autonomic node now must have the ability to interpret=C2=A0or
compile intent (perhaps without fully understanding it) AND must be<= /div>
a "traffic cop" to send the "intentlets" (sor= ry, low on coffee) to their
proper destination. This means that e= ach autonomic node either
understands both the topology and the a= utonomic functions that
each node supports (not likely!) or that = there is metadata, or bits
in the=C2=A0intent, or something to=C2= =A0say where the destination is.

Remember my earli= er analogy with phones. Good luck selling
an "intelligent&qu= ot; phone - the consumer will take higher=C2=A0resolution
cameras= , or better codecs, or anything other than something
nebulous!


> =C2=A06. Intent Interpretation (on each nod= e, by each function):
>=C2=A0 =C2=A0The ANI as well as all ASAs on a= node interpret their respective Intent.
...
See above.
=
...
>=C2=A0=C2=A0=C2=A0=C2=A0(NB: This interpretation cou= ld also be done centrally, and the resulting configs distributed;
>= =C2=A0=C2=A0=C2=A0 This is of course an option, but for that we don't n= eed ANIMA. Therefore I suggest for the
>=C2=A0=C2=A0 ANIMA work to fo= cus on interpreting Intent locally on each node)
>=C2=A0 =C2=A0Resul= t: target configlet (not applied yet!!).

Sorry, I = disagree.=C2=A0Why do we no longer need ANIMA? For example,
let&#= 39;s say we replace GRASP with a pub-sub message queue (I'm NOT
advocating this - just making an example). We still need ANIMA,
because a pub-sub message=C2=A0queue does not understand how to
facilitate autonomic behavior - it just delivers=C2=A0bits.

=

>=C2=A07. Conflict Resolution with non-autonomic manageme= nt (on each node):
>=C2=A0 =C2=A0The target configlet resulting from= Intent has the lowest prio; any other management
>=C2=A0 =C2=A0meth= od (CLI, NETCONF, etc) overrides Intent.

This seem= s=C2=A0very difficult to me.
Case 1: fully autonomic node
How does it understand all of the legacy methods and translate those
to an autonomic equivalent? This is an n^2 problem, and you need a
normalized form=C2=A0so that the node doesn't have to understa= nd the=C2=A0
differences between CLI, private MIBs, etc.

Case 2: fully dumb rock
It won't have a clue= what to do with autonomic intent. So again, we
need=C2=A0a trans= lation from the intent to a form that the dumb rock can
understan= d.

Case=C2=A03:=C2=A0node that has a clue about au= tonomics
Even if we assume that it understands=C2=A0all of the le= gacy methods,
how does it integrate those methods with intent? We= could, for
example, dedicate a set of ASAs to serve as translato= rs.
However, as I've stated in earlier posts, this is a very = difficult=C2=A0task.
I contend that=C2=A0we will need both models= and ontologies (or some
other form of logic) to do this, which i= s why I get scared when
all=C2=A0 nodes are assumed to be able to= =C2=A0understand intent.


>=C2=A08. Conflict= Resolution between autonomic components (on each node):
>=C2=A0 =C2= =A0Each autonomic function needs to register with a "conflict resoluti= on function"
>=C2=A0 =C2=A0which parameters it modifies; in cas= e of conflict the conflict resolution function
>=C2=A0 =C2=A0takes a= decision and feeds that back to the autonomic functions. This may modify >=C2=A0 =C2=A0the target configlet.

I admire= the effort you're putting into this to avoid building a
cent= ralized "God-Box". My problem is not with this step, but with
how we got here. Let's table this.


= ...

10. Feedback loops to NOC: The NOC needs to kn= ow about certain conditions:
=C2=A0...
Agreed! We have a=C2=A0= draft explaining control loops,=C2=A0but we need to develop
the r= eference architecture and "day in the life" further to gain bette= r insight
into=C2=A0how this is done.

re= gards,
John

On Wed, Apr 20, 2016 at 5:49 AM, Michael Behringer (mbehri= ng) <mbehring@cisco.com> wrote:
After the IETF discussions it is clear that we still don't have = the same model in our head when we're discussing how Intent is handled.= Let's see whether we can get some naming agreement.

draft-du-anima-an-intent describes some of the content below (e.g., distrib= ution, interpretation), but there is no "beginning to end" flow o= n how Intent "flows" through the network. It would help the discu= ssion I think if we formalised the entire flow. For example, in the below f= low it is clear that parameters you exchange as a result of interpreting In= tent are not called Intent. (I think this was one point we don't have a= greement on).

Let me try to write down this "flow", as I see it, as a starting = point for discussion.

1. Business goals: The network owner wants the network to follow some busin= ess goals.
=C2=A0 =C2=A0(These goals are initially not formalised, in a computer scien= ce sense. )
=C2=A0 =C2=A0- these goals are formalised in a language -->
2. Intent: is the formalisation of business goals so that computer can deal= with them.
=C2=A0 =C2=A0(encoded as a file; or several files)
=C2=A0 =C2=A0- this file must be "given to the network" --> 3. Ingestion: The Intent file(s) get instantiated on an autonomic node
=C2=A0 =C2=A0On a particular node, an intent file is "ingested".<= br> =C2=A0 =C2=A0- Now it needs to be distributed -->
4. Intent Distribution: Intent is flooded to all nodes in a network;
=C2=A0 =C2=A0Every node has a copy of the original "Intent" file(= s), without modification.
=C2=A0 =C2=A0Each node re-distributes the original Intent files, without mo= dification.
=C2=A0 =C2=A0Therefore, Intent is optional and transitive in nature.
=C2=A0 =C2=A0- the Intent files must now be interpreted by each node -->=
5. Intent splitting (on each node):
=C2=A0 =C2=A0Intent is split into sections, one for the ANI itself, others = for specific Autonomic Functions
=C2=A0 =C2=A0ASAs are notified if there is new Intent for them.
=C2=A0 =C2=A0Some intent sections may not apply to a particular=C2=A0 node<= br> =C2=A0 =C2=A0Now each component of a node (ANI, all ASAs) know their respec= tive Intent.
6. Intent Interpretation (on each node, by each function):
=C2=A0 =C2=A0The ANI as well as all ASAs on a node interpret their respecti= ve Intent.
=C2=A0 =C2=A0It gets translated into a "target configuration", ta= king into account local state.
=C2=A0 =C2=A0For this translation, it may be necessary for ASAs to communic= ate with ASAs on other nodes,
=C2=A0 =C2=A0to pass on resources (IP addresses), to negotiate, etc.
=C2=A0 =C2=A0All such communications may be triggered by Intent, but the co= mmunications themselves
=C2=A0 =C2=A0are NOT Intent.
=C2=A0 =C2=A0(NB: This interpretation could also be done centrally, and the= resulting configs distributed;
=C2=A0 =C2=A0 This is of course an option, but for that we don't need A= NIMA. Therefore I suggest for the
=C2=A0 =C2=A0 ANIMA work to focus on interpreting Intent locally on each no= de)
=C2=A0 =C2=A0Result: target configlet (not applied yet!!).
7. Conflict Resolution with non-autonomic management (on each node):
=C2=A0 =C2=A0The target configlet resulting from Intent has the lowest prio= ; any other management
=C2=A0 =C2=A0method (CLI, NETCONF, etc) overrides Intent.
8. Conflict Resolution between autonomic components (on each node):
=C2=A0 =C2=A0Each autonomic function needs to register with a "conflic= t resolution function"
=C2=A0 =C2=A0which parameters it modifies; in case of conflict the conflict= resolution function
=C2=A0 =C2=A0takes a decision and feeds that back to the autonomic function= s. This may modify
=C2=A0 =C2=A0the target configlet.
9. Applying the target configlet
=C2=A0 =C2=A0A type of "commit" of the configlet.
10. Feedback loops to NOC: The NOC needs to know about certain conditions:<= br> =C2=A0 =C2=A0Conflicts with non-autonomic management (FYI)
=C2=A0 =C2=A0Not all conflicts can be resolved automatically. (may require = NOC actions)
=C2=A0 =C2=A0Undesirable states (deviations from expected default behaviour= ) may have to be communicated;
=C2=A0 =C2=A0To some extent, Intent itself can specify which conditions sho= uld trigger feedback
=C2=A0 =C2=A0loops to the NOC.
=C2=A0 =C2=A0Feedback loops may happen at other phases as well (ex: 8)

I'm conscious that there are different views in the team; like I believ= e in point 6 we're not yet aligned. Please take this list just as a bas= is for discussion, nothing more.

When we have consensus, I believe such a flow should be documented in draft= -du-anima-an-intent in its entirety, to give a full picture.

Feedback?
Michael

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



--
regards,
John
--001a11401dcc2e6c7d053104a4eb-- From nobody Thu Apr 21 13:46:56 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82FF512E4A7 for ; Thu, 21 Apr 2016 13:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 OMHM-7Bno_Q0 for ; Thu, 21 Apr 2016 13:46:43 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DDF212E45D for ; Thu, 21 Apr 2016 13:46:42 -0700 (PDT) Received: by mail-lb0-x22a.google.com with SMTP id ys16so33602848lbb.3 for ; Thu, 21 Apr 2016 13:46:41 -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; bh=VaPat9Lc1bRekRz7pfctcqWxSWcCjJlq3pJCajWjEZs=; b=jc7JWNVwYuS1OmIBiFq8dsHx43KyHkWgERet/Bn3yil9cRywNkRxXi16tWgeOiCTy6 AnUWzzLporjFjRw5z7EoTKay06u1zI3Z1WmxVAxUKZTnu1HlCETcVCim6SRvywaVWkIW CUGjuR0Zo4nnbe9LaXkWj8pCM1deNjJIl/eilk8LPL8tKW0iRKcIkfOYoW8j1+HIIbNu S2B4yEqfo8SCes0+P9Wx/eSZBpqtboPh88gvj5txQ/Ymx8DpjgXZifjPj78YC/9xR/AG EHHwph9hGO9fmNLouWRw0vyu9lmp3PJ2b3avy+aR6IhO+CFJ0Z5EDHj5vc/lVvsACV3e qiyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=VaPat9Lc1bRekRz7pfctcqWxSWcCjJlq3pJCajWjEZs=; b=XVvNQQF6zcnpsMIxrFRaWqA37U5lPXN5jgHbAfqjwSZjxbbc0+EhZVpsDOQWAiikdW fw/HON3wS4jpSpw1S3jcH3k7ByFh5ocQebVQw3TSz3i9svpzI1t1AKlnf9NXKL2u2x0o /Y8qgLV1wxZ4Qr1xaRH1sPbexlN4QBTu0M5EIUemnSOtlK7ZRIIR0NJTrkvvn6RBo0G0 W5VEbjTarfSwx4RHqaFDnsfdp88W0TztvzqhWzc88InNPvowGItBFNh7dx4KZU1D9ACM ShbHnoyHUx2SUIO/O1wBcuN83yHxKv5EP0xL06EbXEAWrwBApLQkQq1JJD8qAEeT0vGx 5z3g== X-Gm-Message-State: AOPr4FUJGDPkZkCaE3927+Mz2lrWbNgLfdoCJ5/Iurn8xPkn8Zi2QO3vn3Cu7n7gPi/qlz4vh/nV0QwobVRpDw== MIME-Version: 1.0 X-Received: by 10.112.84.202 with SMTP id b10mr7052886lbz.41.1461271600204; Thu, 21 Apr 2016 13:46:40 -0700 (PDT) Received: by 10.25.21.105 with HTTP; Thu, 21 Apr 2016 13:46:40 -0700 (PDT) In-Reply-To: <57178F54.5030406@joelhalpern.com> References: <74b2701c9b10416cbd2c8043e33596f1@XCH-RCD-006.cisco.com> <57178F54.5030406@joelhalpern.com> Date: Thu, 21 Apr 2016 13:46:40 -0700 Message-ID: From: John Strassner To: "Joel M. Halpern" , John Strassner Content-Type: multipart/alternative; boundary=001a1135ea06a6906d053104ce93 Archived-At: Cc: Anima WG , "Michael Behringer \(mbehring\)" Subject: Re: [Anima] Intent "beginning to end" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 21 Apr 2016 20:46:45 -0000 --001a1135ea06a6906d053104ce93 Content-Type: text/plain; charset=UTF-8 +1. In particular, doing this has a number of advantages: 1) The Policy Continuum was built to mimic the flow of abstract policies being translated into different forms that were applicable to each user. Business intent will need several such translations from experience. 2) Context can be taken into account in a uniform way (as opposed to having each individual node report context) 3) I believe that interpreting/compiling intent will be HARD, and that understanding intent will be MUCH HARDER. Why does every autonomic node need to do that? I do think that ASAs should be used to do the interpreting/compiling and understanding tasks. regards, John On Wed, Apr 20, 2016 at 7:16 AM, Joel M. Halpern wrote: > It seems to me that for many kinds of business intentions, as translated > into "intents", there will need to be an intelligent processing step that > determines how this intent relates to the network state, and how the > network needs to respond to this. While there are cases where this can be > done at each AN, there are also many cases where this needs intermediate > work. > > As I understand it, those intermediaries are AN, which produce results > usable by other AN. While they will produce parameters for the AN, they > will also, I expect produce refined intents. > > Yours, > Joel > > On 4/20/16 8:49 AM, Michael Behringer (mbehring) wrote: > >> After the IETF discussions it is clear that we still don't have the same >> model in our head when we're discussing how Intent is handled. Let's see >> whether we can get some naming agreement. >> >> draft-du-anima-an-intent describes some of the content below (e.g., >> distribution, interpretation), but there is no "beginning to end" flow on >> how Intent "flows" through the network. It would help the discussion I >> think if we formalised the entire flow. For example, in the below flow it >> is clear that parameters you exchange as a result of interpreting Intent >> are not called Intent. (I think this was one point we don't have agreement >> on). >> >> Let me try to write down this "flow", as I see it, as a starting point >> for discussion. >> >> 1. Business goals: The network owner wants the network to follow some >> business goals. >> (These goals are initially not formalised, in a computer science >> sense. ) >> - these goals are formalised in a language --> >> 2. Intent: is the formalisation of business goals so that computer can >> deal with them. >> (encoded as a file; or several files) >> - this file must be "given to the network" --> >> 3. Ingestion: The Intent file(s) get instantiated on an autonomic node >> On a particular node, an intent file is "ingested". >> - Now it needs to be distributed --> >> 4. Intent Distribution: Intent is flooded to all nodes in a network; >> Every node has a copy of the original "Intent" file(s), without >> modification. >> Each node re-distributes the original Intent files, without >> modification. >> Therefore, Intent is optional and transitive in nature. >> - the Intent files must now be interpreted by each node --> >> 5. Intent splitting (on each node): >> Intent is split into sections, one for the ANI itself, others for >> specific Autonomic Functions >> ASAs are notified if there is new Intent for them. >> Some intent sections may not apply to a particular node >> Now each component of a node (ANI, all ASAs) know their respective >> Intent. >> 6. Intent Interpretation (on each node, by each function): >> The ANI as well as all ASAs on a node interpret their respective >> Intent. >> It gets translated into a "target configuration", taking into account >> local state. >> For this translation, it may be necessary for ASAs to communicate >> with ASAs on other nodes, >> to pass on resources (IP addresses), to negotiate, etc. >> All such communications may be triggered by Intent, but the >> communications themselves >> are NOT Intent. >> (NB: This interpretation could also be done centrally, and the >> resulting configs distributed; >> This is of course an option, but for that we don't need ANIMA. >> Therefore I suggest for the >> ANIMA work to focus on interpreting Intent locally on each node) >> Result: target configlet (not applied yet!!). >> 7. Conflict Resolution with non-autonomic management (on each node): >> The target configlet resulting from Intent has the lowest prio; any >> other management >> method (CLI, NETCONF, etc) overrides Intent. >> 8. Conflict Resolution between autonomic components (on each node): >> Each autonomic function needs to register with a "conflict resolution >> function" >> which parameters it modifies; in case of conflict the conflict >> resolution function >> takes a decision and feeds that back to the autonomic functions. This >> may modify >> the target configlet. >> 9. Applying the target configlet >> A type of "commit" of the configlet. >> 10. Feedback loops to NOC: The NOC needs to know about certain conditions: >> Conflicts with non-autonomic management (FYI) >> Not all conflicts can be resolved automatically. (may require NOC >> actions) >> Undesirable states (deviations from expected default behaviour) may >> have to be communicated; >> To some extent, Intent itself can specify which conditions should >> trigger feedback >> loops to the NOC. >> Feedback loops may happen at other phases as well (ex: 8) >> >> I'm conscious that there are different views in the team; like I believe >> in point 6 we're not yet aligned. Please take this list just as a basis for >> discussion, nothing more. >> >> When we have consensus, I believe such a flow should be documented in >> draft-du-anima-an-intent in its entirety, to give a full picture. >> >> Feedback? >> Michael >> >> _______________________________________________ >> 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 > -- regards, John --001a1135ea06a6906d053104ce93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1.

In particular, doing th= is has a number of advantages:

=C2=A0=C2=A0 1) The= Policy Continuum was built to mimic the flow of abstract
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0policies being translated into differen= t forms that were
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 applicable= to each user. Business intent will need several
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 such translations from experience.
=C2=A0= =C2=A0 2) Context can be taken into account in a uniform way (as opposed
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to having each individual node= report context)
=C2=A0=C2=A0 3) I believe that interpreting/comp= iling intent will be HARD, and
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 that understanding intent will be MUCH HARDER. Why does
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 every autonomic node need to do that?

I do think that ASAs should be used to do the interpr= eting/compiling
and understanding tasks.


regards,
John

On Wed, Apr 20, 2016 at 7:16 AM, Joel M. = Halpern <jmh@joelhalpern.com> wrote:
It seems to me that for many kinds of business intentions, as= translated into "intents", there will need to be an intelligent = processing step that determines how this intent relates to the network stat= e, and how the network needs to respond to this.=C2=A0 While there are case= s where this can be done at each AN, there are also many cases where this n= eeds intermediate work.

As I understand it, those intermediaries are AN, which produce results usab= le by other AN.=C2=A0 While they will produce parameters for the AN, they w= ill also, I expect produce refined intents.

Yours,
Joel

On 4/20/16 8:49 AM, Michael Behringer (mbehring) wrote:
After the IETF discussions it is clear that we still don't have the sam= e model in our head when we're discussing how Intent is handled. Let= 9;s see whether we can get some naming agreement.

draft-du-anima-an-intent describes some of the content below (e.g., distrib= ution, interpretation), but there is no "beginning to end" flow o= n how Intent "flows" through the network. It would help the discu= ssion I think if we formalised the entire flow. For example, in the below f= low it is clear that parameters you exchange as a result of interpreting In= tent are not called Intent. (I think this was one point we don't have a= greement on).

Let me try to write down this "flow", as I see it, as a starting = point for discussion.

1. Business goals: The network owner wants the network to follow some busin= ess goals.
=C2=A0 =C2=A0 (These goals are initially not formalised, in a computer scie= nce sense. )
=C2=A0 =C2=A0 - these goals are formalised in a language -->
2. Intent: is the formalisation of business goals so that computer can deal= with them.
=C2=A0 =C2=A0 (encoded as a file; or several files)
=C2=A0 =C2=A0 - this file must be "given to the network" --> 3. Ingestion: The Intent file(s) get instantiated on an autonomic node
=C2=A0 =C2=A0 On a particular node, an intent file is "ingested".=
=C2=A0 =C2=A0 - Now it needs to be distributed -->
4. Intent Distribution: Intent is flooded to all nodes in a network;
=C2=A0 =C2=A0 Every node has a copy of the original "Intent" file= (s), without modification.
=C2=A0 =C2=A0 Each node re-distributes the original Intent files, without m= odification.
=C2=A0 =C2=A0 Therefore, Intent is optional and transitive in nature.
=C2=A0 =C2=A0 - the Intent files must now be interpreted by each node -->= ;
5. Intent splitting (on each node):
=C2=A0 =C2=A0 Intent is split into sections, one for the ANI itself, others= for specific Autonomic Functions
=C2=A0 =C2=A0 ASAs are notified if there is new Intent for them.
=C2=A0 =C2=A0 Some intent sections may not apply to a particular=C2=A0 node=
=C2=A0 =C2=A0 Now each component of a node (ANI, all ASAs) know their respe= ctive Intent.
6. Intent Interpretation (on each node, by each function):
=C2=A0 =C2=A0 The ANI as well as all ASAs on a node interpret their respect= ive Intent.
=C2=A0 =C2=A0 It gets translated into a "target configuration", t= aking into account local state.
=C2=A0 =C2=A0 For this translation, it may be necessary for ASAs to communi= cate with ASAs on other nodes,
=C2=A0 =C2=A0 to pass on resources (IP addresses), to negotiate, etc.
=C2=A0 =C2=A0 All such communications may be triggered by Intent, but the c= ommunications themselves
=C2=A0 =C2=A0 are NOT Intent.
=C2=A0 =C2=A0 (NB: This interpretation could also be done centrally, and th= e resulting configs distributed;
=C2=A0 =C2=A0 =C2=A0This is of course an option, but for that we don't = need ANIMA. Therefore I suggest for the
=C2=A0 =C2=A0 =C2=A0ANIMA work to focus on interpreting Intent locally on e= ach node)
=C2=A0 =C2=A0 Result: target configlet (not applied yet!!).
7. Conflict Resolution with non-autonomic management (on each node):
=C2=A0 =C2=A0 The target configlet resulting from Intent has the lowest pri= o; any other management
=C2=A0 =C2=A0 method (CLI, NETCONF, etc) overrides Intent.
8. Conflict Resolution between autonomic components (on each node):
=C2=A0 =C2=A0 Each autonomic function needs to register with a "confli= ct resolution function"
=C2=A0 =C2=A0 which parameters it modifies; in case of conflict the conflic= t resolution function
=C2=A0 =C2=A0 takes a decision and feeds that back to the autonomic functio= ns. This may modify
=C2=A0 =C2=A0 the target configlet.
9. Applying the target configlet
=C2=A0 =C2=A0 A type of "commit" of the configlet.
10. Feedback loops to NOC: The NOC needs to know about certain conditions:<= br> =C2=A0 =C2=A0 Conflicts with non-autonomic management (FYI)
=C2=A0 =C2=A0 Not all conflicts can be resolved automatically. (may require= NOC actions)
=C2=A0 =C2=A0 Undesirable states (deviations from expected default behaviou= r) may have to be communicated;
=C2=A0 =C2=A0 To some extent, Intent itself can specify which conditions sh= ould trigger feedback
=C2=A0 =C2=A0 loops to the NOC.
=C2=A0 =C2=A0 Feedback loops may happen at other phases as well (ex: 8)

I'm conscious that there are different views in the team; like I believ= e in point 6 we're not yet aligned. Please take this list just as a bas= is for discussion, nothing more.

When we have consensus, I believe such a flow should be documented in draft= -du-anima-an-intent in its entirety, to give a full picture.

Feedback?
Michael

_______________________________________________
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



--
regards,
John
--001a1135ea06a6906d053104ce93-- From nobody Thu Apr 21 13:53:54 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C4E12E2E5 for ; Thu, 21 Apr 2016 13:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.195 X-Spam-Level: X-Spam-Status: No, score=-5.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mitre.onmicrosoft.com 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 pbGZF-yOP-PH for ; Thu, 21 Apr 2016 13:53:48 -0700 (PDT) Received: from smtpvmsrv1.mitre.org (smtpvmsrv1.mitre.org [192.52.194.136]) by ietfa.amsl.com (Postfix) with ESMTP id 9527F12E2AF for ; Thu, 21 Apr 2016 13:53:48 -0700 (PDT) Received: from smtpvmsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E49BC6C04E4; Thu, 21 Apr 2016 16:53:47 -0400 (EDT) Received: from imshyb01.MITRE.ORG (imshyb01.mitre.org [129.83.29.2]) by smtpvmsrv1.mitre.org (Postfix) with ESMTP id CE5C06C04AE; Thu, 21 Apr 2016 16:53:47 -0400 (EDT) Received: from imshyb01.MITRE.ORG (129.83.29.2) by imshyb01.MITRE.ORG (129.83.29.2) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 21 Apr 2016 16:53:47 -0400 Received: from gcc01-CY1-obe.outbound.protection.outlook.com (10.140.19.249) by imshyb01.MITRE.ORG (129.83.29.2) with Microsoft SMTP Server (TLS) id 15.0.1130.7 via Frontend Transport; Thu, 21 Apr 2016 16:53:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mitre.onmicrosoft.com; s=selector1-mitre-org; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=u84TAqEUjuGSr8bPEYbKgYTLj7jUJfP13Zk+gKTYSXE=; b=NyMPosJ2JxPzXEeW6dOCqWw+xuykGInW8MLgnGWSfPgW3XSAlapeNxvzx3lnMrsU8/6DFwbFrvp7VgE/MUGBFfrttffnhfuz83737VTkZhm9/+coGy7wUy8L4KPEeWqkKdAAGGTJEeKyEIaymQVfpEJOCHwpmQ7yV2BqQqvdsik= Received: from CY1PR09MB0922.namprd09.prod.outlook.com (10.163.89.140) by CY1PR09MB0924.namprd09.prod.outlook.com (10.163.89.142) with Microsoft SMTP Server (TLS) id 15.1.466.19; Thu, 21 Apr 2016 20:53:46 +0000 Received: from CY1PR09MB0922.namprd09.prod.outlook.com ([10.163.89.140]) by CY1PR09MB0922.namprd09.prod.outlook.com ([10.163.89.140]) with mapi id 15.01.0466.023; Thu, 21 Apr 2016 20:53:46 +0000 From: "Natale, Bob" To: John Strassner , "Joel M. Halpern" Thread-Topic: [Anima] Intent "beginning to end" Thread-Index: AdGbAEYKborLOcNBR7qt3zbaOPev0gBDr0LpAAAc86A= Date: Thu, 21 Apr 2016 20:53:46 +0000 Message-ID: References: <74b2701c9b10416cbd2c8043e33596f1@XCH-RCD-006.cisco.com> <57178F54.5030406@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=mitre.org; x-originating-ip: [128.29.234.229] x-ms-office365-filtering-correlation-id: 7452430f-6afe-40ec-6a43-08d36a270832 x-microsoft-exchange-diagnostics: 1; CY1PR09MB0924; 5:KxUrt+hkjGw0+XYN1FvbqJt+I8oAdvTlHH0IWGrcmryAARfeAALSYHcPvSw7P+jOhoWkmxAQRIcgMLhlU3TW62hsMjLgmeTADnrSucXK67bLpjaGfAS+7U/TjOSu5ucssq/UHcTGN9blrwc3Jr3HtKSHG8NBnjnBt9isi/fK4zN7p/Fz+5Js7sEJlTgU0Ay5; 24:5MXNUqePX8VnwrWaQKEp0ENW3OGpQMJ5sfavRs7eR/+aO036iYnAuKenHGLQm2hd9H6U/psUP4+LbFt4g6wz/HrxdZtQg0n77o/UI41gVsU=; 7:vkLVKLjlqIQJxyaeKLaKFnqKYOxW+5peFvFvg68L6GkwHDbRyLIlAOMIXJcz/t9tdtOWXfO8VgUjYip8mH5T53aicQXP3+4kNFf/XcRj14JbO2av+5IpYu/dFP3GCM87uUPvijjF3TIumcQRf46RMPDVUv9BAaM81JwWqZWn+g/Cx1S1fEoqpPK4NI1NBx7wwY8aEUdttmYWy51w21yJTfO0F7wC4cBzqbVi3R6Dg6U= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0924; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:CY1PR09MB0924; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0924; x-forefront-prvs: 091949432C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377454003)(69234005)(24454002)(6116002)(790700001)(189998001)(31430400001)(86362001)(19609705001)(19617315012)(586003)(102836003)(87936001)(5004730100002)(3660700001)(15975445007)(33656002)(3280700002)(76176999)(54356999)(50986999)(5001770100001)(76576001)(77096005)(81166005)(19625215002)(10400500002)(11100500001)(99286002)(2950100001)(9686002)(122556002)(66066001)(5008740100001)(4326007)(16236675004)(19300405004)(19580405001)(5003600100002)(74316001)(5002640100001)(19580395003)(92566002)(2900100001)(1220700001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR09MB0924; H:CY1PR09MB0922.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0922439B22444A6B0304EEC8A86E0CY1PR09MB0922namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2016 20:53:46.0193 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0924 X-OriginatorOrg: mitre.org Archived-At: Cc: "Michael Behringer \(mbehring\)" , Anima WG Subject: Re: [Anima] Intent "beginning to end" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 21 Apr 2016 20:53:52 -0000 --_000_CY1PR09MB0922439B22444A6B0304EEC8A86E0CY1PR09MB0922namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWFrZSB0aGF0ICsyLg0KDQooQXMgZmFyIGFzIEkgY2FuIHRlbGwgYW5kIGZyb20gYW4gb3BlcmF0 aW9ucyBwZXJzcGVjdGl2ZSwgeW91IGNhbm5vdCBkbyBJbnRlbnQtYmFzZWQgcG9saWN5IG1hbmFn ZW1lbnQgd2l0aG91dCB0aGUgUG9saWN5IENvbnRpbnV1bSwgb3IgYW4gZXF1aXZhbGVudCBjb25j ZXB0dWFsIGNvbnN0cnVjdCkuDQoNCkF2YW50aSwNCkJvYk4NCg0KRnJvbTogQW5pbWEgW21haWx0 bzphbmltYS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm9obiBTdHJhc3NuZXINClNl bnQ6IFRodXJzZGF5LCBBcHJpbCAyMSwgMjAxNiA0OjQ3IFBNDQpUbzogSm9lbCBNLiBIYWxwZXJu IDxqbWhAam9lbGhhbHBlcm4uY29tPjsgSm9obiBTdHJhc3NuZXIgPHN0cmF6cGRqQGdtYWlsLmNv bT4NCkNjOiBBbmltYSBXRyA8YW5pbWFAaWV0Zi5vcmc+OyBNaWNoYWVsIEJlaHJpbmdlciAobWJl aHJpbmcpIDxtYmVocmluZ0BjaXNjby5jb20+DQpTdWJqZWN0OiBSZTogW0FuaW1hXSBJbnRlbnQg ImJlZ2lubmluZyB0byBlbmQiDQoNCisxLg0KDQpJbiBwYXJ0aWN1bGFyLCBkb2luZyB0aGlzIGhh cyBhIG51bWJlciBvZiBhZHZhbnRhZ2VzOg0KDQogICAxKSBUaGUgUG9saWN5IENvbnRpbnV1bSB3 YXMgYnVpbHQgdG8gbWltaWMgdGhlIGZsb3cgb2YgYWJzdHJhY3QNCiAgICAgICBwb2xpY2llcyBi ZWluZyB0cmFuc2xhdGVkIGludG8gZGlmZmVyZW50IGZvcm1zIHRoYXQgd2VyZQ0KICAgICAgIGFw cGxpY2FibGUgdG8gZWFjaCB1c2VyLiBCdXNpbmVzcyBpbnRlbnQgd2lsbCBuZWVkIHNldmVyYWwN CiAgICAgICBzdWNoIHRyYW5zbGF0aW9ucyBmcm9tIGV4cGVyaWVuY2UuDQogICAyKSBDb250ZXh0 IGNhbiBiZSB0YWtlbiBpbnRvIGFjY291bnQgaW4gYSB1bmlmb3JtIHdheSAoYXMgb3Bwb3NlZA0K ICAgICAgIHRvIGhhdmluZyBlYWNoIGluZGl2aWR1YWwgbm9kZSByZXBvcnQgY29udGV4dCkNCiAg IDMpIEkgYmVsaWV2ZSB0aGF0IGludGVycHJldGluZy9jb21waWxpbmcgaW50ZW50IHdpbGwgYmUg SEFSRCwgYW5kDQogICAgICAgdGhhdCB1bmRlcnN0YW5kaW5nIGludGVudCB3aWxsIGJlIE1VQ0gg SEFSREVSLiBXaHkgZG9lcw0KICAgICAgIGV2ZXJ5IGF1dG9ub21pYyBub2RlIG5lZWQgdG8gZG8g dGhhdD8NCg0KSSBkbyB0aGluayB0aGF0IEFTQXMgc2hvdWxkIGJlIHVzZWQgdG8gZG8gdGhlIGlu dGVycHJldGluZy9jb21waWxpbmcNCmFuZCB1bmRlcnN0YW5kaW5nIHRhc2tzLg0KDQoNCnJlZ2Fy ZHMsDQpKb2huDQoNCk9uIFdlZCwgQXByIDIwLCAyMDE2IGF0IDc6MTYgQU0sIEpvZWwgTS4gSGFs cGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+IHdy b3RlOg0KSXQgc2VlbXMgdG8gbWUgdGhhdCBmb3IgbWFueSBraW5kcyBvZiBidXNpbmVzcyBpbnRl bnRpb25zLCBhcyB0cmFuc2xhdGVkIGludG8gImludGVudHMiLCB0aGVyZSB3aWxsIG5lZWQgdG8g YmUgYW4gaW50ZWxsaWdlbnQgcHJvY2Vzc2luZyBzdGVwIHRoYXQgZGV0ZXJtaW5lcyBob3cgdGhp cyBpbnRlbnQgcmVsYXRlcyB0byB0aGUgbmV0d29yayBzdGF0ZSwgYW5kIGhvdyB0aGUgbmV0d29y ayBuZWVkcyB0byByZXNwb25kIHRvIHRoaXMuICBXaGlsZSB0aGVyZSBhcmUgY2FzZXMgd2hlcmUg dGhpcyBjYW4gYmUgZG9uZSBhdCBlYWNoIEFOLCB0aGVyZSBhcmUgYWxzbyBtYW55IGNhc2VzIHdo ZXJlIHRoaXMgbmVlZHMgaW50ZXJtZWRpYXRlIHdvcmsuDQoNCkFzIEkgdW5kZXJzdGFuZCBpdCwg dGhvc2UgaW50ZXJtZWRpYXJpZXMgYXJlIEFOLCB3aGljaCBwcm9kdWNlIHJlc3VsdHMgdXNhYmxl IGJ5IG90aGVyIEFOLiAgV2hpbGUgdGhleSB3aWxsIHByb2R1Y2UgcGFyYW1ldGVycyBmb3IgdGhl IEFOLCB0aGV5IHdpbGwgYWxzbywgSSBleHBlY3QgcHJvZHVjZSByZWZpbmVkIGludGVudHMuDQoN CllvdXJzLA0KSm9lbA0KDQpPbiA0LzIwLzE2IDg6NDkgQU0sIE1pY2hhZWwgQmVocmluZ2VyICht YmVocmluZykgd3JvdGU6DQpBZnRlciB0aGUgSUVURiBkaXNjdXNzaW9ucyBpdCBpcyBjbGVhciB0 aGF0IHdlIHN0aWxsIGRvbid0IGhhdmUgdGhlIHNhbWUgbW9kZWwgaW4gb3VyIGhlYWQgd2hlbiB3 ZSdyZSBkaXNjdXNzaW5nIGhvdyBJbnRlbnQgaXMgaGFuZGxlZC4gTGV0J3Mgc2VlIHdoZXRoZXIg d2UgY2FuIGdldCBzb21lIG5hbWluZyBhZ3JlZW1lbnQuDQoNCmRyYWZ0LWR1LWFuaW1hLWFuLWlu dGVudCBkZXNjcmliZXMgc29tZSBvZiB0aGUgY29udGVudCBiZWxvdyAoZS5nLiwgZGlzdHJpYnV0 aW9uLCBpbnRlcnByZXRhdGlvbiksIGJ1dCB0aGVyZSBpcyBubyAiYmVnaW5uaW5nIHRvIGVuZCIg ZmxvdyBvbiBob3cgSW50ZW50ICJmbG93cyIgdGhyb3VnaCB0aGUgbmV0d29yay4gSXQgd291bGQg aGVscCB0aGUgZGlzY3Vzc2lvbiBJIHRoaW5rIGlmIHdlIGZvcm1hbGlzZWQgdGhlIGVudGlyZSBm bG93LiBGb3IgZXhhbXBsZSwgaW4gdGhlIGJlbG93IGZsb3cgaXQgaXMgY2xlYXIgdGhhdCBwYXJh bWV0ZXJzIHlvdSBleGNoYW5nZSBhcyBhIHJlc3VsdCBvZiBpbnRlcnByZXRpbmcgSW50ZW50IGFy ZSBub3QgY2FsbGVkIEludGVudC4gKEkgdGhpbmsgdGhpcyB3YXMgb25lIHBvaW50IHdlIGRvbid0 IGhhdmUgYWdyZWVtZW50IG9uKS4NCg0KTGV0IG1lIHRyeSB0byB3cml0ZSBkb3duIHRoaXMgImZs b3ciLCBhcyBJIHNlZSBpdCwgYXMgYSBzdGFydGluZyBwb2ludCBmb3IgZGlzY3Vzc2lvbi4NCg0K MS4gQnVzaW5lc3MgZ29hbHM6IFRoZSBuZXR3b3JrIG93bmVyIHdhbnRzIHRoZSBuZXR3b3JrIHRv IGZvbGxvdyBzb21lIGJ1c2luZXNzIGdvYWxzLg0KICAgIChUaGVzZSBnb2FscyBhcmUgaW5pdGlh bGx5IG5vdCBmb3JtYWxpc2VkLCBpbiBhIGNvbXB1dGVyIHNjaWVuY2Ugc2Vuc2UuICkNCiAgICAt IHRoZXNlIGdvYWxzIGFyZSBmb3JtYWxpc2VkIGluIGEgbGFuZ3VhZ2UgLS0+DQoyLiBJbnRlbnQ6 IGlzIHRoZSBmb3JtYWxpc2F0aW9uIG9mIGJ1c2luZXNzIGdvYWxzIHNvIHRoYXQgY29tcHV0ZXIg Y2FuIGRlYWwgd2l0aCB0aGVtLg0KICAgIChlbmNvZGVkIGFzIGEgZmlsZTsgb3Igc2V2ZXJhbCBm aWxlcykNCiAgICAtIHRoaXMgZmlsZSBtdXN0IGJlICJnaXZlbiB0byB0aGUgbmV0d29yayIgLS0+ DQozLiBJbmdlc3Rpb246IFRoZSBJbnRlbnQgZmlsZShzKSBnZXQgaW5zdGFudGlhdGVkIG9uIGFu IGF1dG9ub21pYyBub2RlDQogICAgT24gYSBwYXJ0aWN1bGFyIG5vZGUsIGFuIGludGVudCBmaWxl IGlzICJpbmdlc3RlZCIuDQogICAgLSBOb3cgaXQgbmVlZHMgdG8gYmUgZGlzdHJpYnV0ZWQgLS0+ DQo0LiBJbnRlbnQgRGlzdHJpYnV0aW9uOiBJbnRlbnQgaXMgZmxvb2RlZCB0byBhbGwgbm9kZXMg aW4gYSBuZXR3b3JrOw0KICAgIEV2ZXJ5IG5vZGUgaGFzIGEgY29weSBvZiB0aGUgb3JpZ2luYWwg IkludGVudCIgZmlsZShzKSwgd2l0aG91dCBtb2RpZmljYXRpb24uDQogICAgRWFjaCBub2RlIHJl LWRpc3RyaWJ1dGVzIHRoZSBvcmlnaW5hbCBJbnRlbnQgZmlsZXMsIHdpdGhvdXQgbW9kaWZpY2F0 aW9uLg0KICAgIFRoZXJlZm9yZSwgSW50ZW50IGlzIG9wdGlvbmFsIGFuZCB0cmFuc2l0aXZlIGlu IG5hdHVyZS4NCiAgICAtIHRoZSBJbnRlbnQgZmlsZXMgbXVzdCBub3cgYmUgaW50ZXJwcmV0ZWQg YnkgZWFjaCBub2RlIC0tPg0KNS4gSW50ZW50IHNwbGl0dGluZyAob24gZWFjaCBub2RlKToNCiAg ICBJbnRlbnQgaXMgc3BsaXQgaW50byBzZWN0aW9ucywgb25lIGZvciB0aGUgQU5JIGl0c2VsZiwg b3RoZXJzIGZvciBzcGVjaWZpYyBBdXRvbm9taWMgRnVuY3Rpb25zDQogICAgQVNBcyBhcmUgbm90 aWZpZWQgaWYgdGhlcmUgaXMgbmV3IEludGVudCBmb3IgdGhlbS4NCiAgICBTb21lIGludGVudCBz ZWN0aW9ucyBtYXkgbm90IGFwcGx5IHRvIGEgcGFydGljdWxhciAgbm9kZQ0KICAgIE5vdyBlYWNo IGNvbXBvbmVudCBvZiBhIG5vZGUgKEFOSSwgYWxsIEFTQXMpIGtub3cgdGhlaXIgcmVzcGVjdGl2 ZSBJbnRlbnQuDQo2LiBJbnRlbnQgSW50ZXJwcmV0YXRpb24gKG9uIGVhY2ggbm9kZSwgYnkgZWFj aCBmdW5jdGlvbik6DQogICAgVGhlIEFOSSBhcyB3ZWxsIGFzIGFsbCBBU0FzIG9uIGEgbm9kZSBp bnRlcnByZXQgdGhlaXIgcmVzcGVjdGl2ZSBJbnRlbnQuDQogICAgSXQgZ2V0cyB0cmFuc2xhdGVk IGludG8gYSAidGFyZ2V0IGNvbmZpZ3VyYXRpb24iLCB0YWtpbmcgaW50byBhY2NvdW50IGxvY2Fs IHN0YXRlLg0KICAgIEZvciB0aGlzIHRyYW5zbGF0aW9uLCBpdCBtYXkgYmUgbmVjZXNzYXJ5IGZv ciBBU0FzIHRvIGNvbW11bmljYXRlIHdpdGggQVNBcyBvbiBvdGhlciBub2RlcywNCiAgICB0byBw YXNzIG9uIHJlc291cmNlcyAoSVAgYWRkcmVzc2VzKSwgdG8gbmVnb3RpYXRlLCBldGMuDQogICAg QWxsIHN1Y2ggY29tbXVuaWNhdGlvbnMgbWF5IGJlIHRyaWdnZXJlZCBieSBJbnRlbnQsIGJ1dCB0 aGUgY29tbXVuaWNhdGlvbnMgdGhlbXNlbHZlcw0KICAgIGFyZSBOT1QgSW50ZW50Lg0KICAgIChO QjogVGhpcyBpbnRlcnByZXRhdGlvbiBjb3VsZCBhbHNvIGJlIGRvbmUgY2VudHJhbGx5LCBhbmQg dGhlIHJlc3VsdGluZyBjb25maWdzIGRpc3RyaWJ1dGVkOw0KICAgICBUaGlzIGlzIG9mIGNvdXJz ZSBhbiBvcHRpb24sIGJ1dCBmb3IgdGhhdCB3ZSBkb24ndCBuZWVkIEFOSU1BLiBUaGVyZWZvcmUg SSBzdWdnZXN0IGZvciB0aGUNCiAgICAgQU5JTUEgd29yayB0byBmb2N1cyBvbiBpbnRlcnByZXRp bmcgSW50ZW50IGxvY2FsbHkgb24gZWFjaCBub2RlKQ0KICAgIFJlc3VsdDogdGFyZ2V0IGNvbmZp Z2xldCAobm90IGFwcGxpZWQgeWV0ISEpLg0KNy4gQ29uZmxpY3QgUmVzb2x1dGlvbiB3aXRoIG5v bi1hdXRvbm9taWMgbWFuYWdlbWVudCAob24gZWFjaCBub2RlKToNCiAgICBUaGUgdGFyZ2V0IGNv bmZpZ2xldCByZXN1bHRpbmcgZnJvbSBJbnRlbnQgaGFzIHRoZSBsb3dlc3QgcHJpbzsgYW55IG90 aGVyIG1hbmFnZW1lbnQNCiAgICBtZXRob2QgKENMSSwgTkVUQ09ORiwgZXRjKSBvdmVycmlkZXMg SW50ZW50Lg0KOC4gQ29uZmxpY3QgUmVzb2x1dGlvbiBiZXR3ZWVuIGF1dG9ub21pYyBjb21wb25l bnRzIChvbiBlYWNoIG5vZGUpOg0KICAgIEVhY2ggYXV0b25vbWljIGZ1bmN0aW9uIG5lZWRzIHRv IHJlZ2lzdGVyIHdpdGggYSAiY29uZmxpY3QgcmVzb2x1dGlvbiBmdW5jdGlvbiINCiAgICB3aGlj aCBwYXJhbWV0ZXJzIGl0IG1vZGlmaWVzOyBpbiBjYXNlIG9mIGNvbmZsaWN0IHRoZSBjb25mbGlj dCByZXNvbHV0aW9uIGZ1bmN0aW9uDQogICAgdGFrZXMgYSBkZWNpc2lvbiBhbmQgZmVlZHMgdGhh dCBiYWNrIHRvIHRoZSBhdXRvbm9taWMgZnVuY3Rpb25zLiBUaGlzIG1heSBtb2RpZnkNCiAgICB0 aGUgdGFyZ2V0IGNvbmZpZ2xldC4NCjkuIEFwcGx5aW5nIHRoZSB0YXJnZXQgY29uZmlnbGV0DQog ICAgQSB0eXBlIG9mICJjb21taXQiIG9mIHRoZSBjb25maWdsZXQuDQoxMC4gRmVlZGJhY2sgbG9v cHMgdG8gTk9DOiBUaGUgTk9DIG5lZWRzIHRvIGtub3cgYWJvdXQgY2VydGFpbiBjb25kaXRpb25z Og0KICAgIENvbmZsaWN0cyB3aXRoIG5vbi1hdXRvbm9taWMgbWFuYWdlbWVudCAoRllJKQ0KICAg IE5vdCBhbGwgY29uZmxpY3RzIGNhbiBiZSByZXNvbHZlZCBhdXRvbWF0aWNhbGx5LiAobWF5IHJl cXVpcmUgTk9DIGFjdGlvbnMpDQogICAgVW5kZXNpcmFibGUgc3RhdGVzIChkZXZpYXRpb25zIGZy b20gZXhwZWN0ZWQgZGVmYXVsdCBiZWhhdmlvdXIpIG1heSBoYXZlIHRvIGJlIGNvbW11bmljYXRl ZDsNCiAgICBUbyBzb21lIGV4dGVudCwgSW50ZW50IGl0c2VsZiBjYW4gc3BlY2lmeSB3aGljaCBj b25kaXRpb25zIHNob3VsZCB0cmlnZ2VyIGZlZWRiYWNrDQogICAgbG9vcHMgdG8gdGhlIE5PQy4N CiAgICBGZWVkYmFjayBsb29wcyBtYXkgaGFwcGVuIGF0IG90aGVyIHBoYXNlcyBhcyB3ZWxsIChl eDogOCkNCg0KSSdtIGNvbnNjaW91cyB0aGF0IHRoZXJlIGFyZSBkaWZmZXJlbnQgdmlld3MgaW4g dGhlIHRlYW07IGxpa2UgSSBiZWxpZXZlIGluIHBvaW50IDYgd2UncmUgbm90IHlldCBhbGlnbmVk LiBQbGVhc2UgdGFrZSB0aGlzIGxpc3QganVzdCBhcyBhIGJhc2lzIGZvciBkaXNjdXNzaW9uLCBu b3RoaW5nIG1vcmUuDQoNCldoZW4gd2UgaGF2ZSBjb25zZW5zdXMsIEkgYmVsaWV2ZSBzdWNoIGEg ZmxvdyBzaG91bGQgYmUgZG9jdW1lbnRlZCBpbiBkcmFmdC1kdS1hbmltYS1hbi1pbnRlbnQgaW4g aXRzIGVudGlyZXR5LCB0byBnaXZlIGEgZnVsbCBwaWN0dXJlLg0KDQpGZWVkYmFjaz8NCk1pY2hh ZWwNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkFu aW1hIG1haWxpbmcgbGlzdA0KQW5pbWFAaWV0Zi5vcmc8bWFpbHRvOkFuaW1hQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQW5pbWEgbWFpbGluZyBsaXN0 DQpBbmltYUBpZXRmLm9yZzxtYWlsdG86QW5pbWFAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hDQoNCg0KDQotLQ0KcmVnYXJkcywNCkpvaG4NCg== --_000_CY1PR09MB0922439B22444A6B0304EEC8A86E0CY1PR09MB0922namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25v cm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDph dXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ bWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6Izk5MzMwMDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJ dGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6Izk5MzMwMCI+TWFrZSB0aGF0ICYjNDM7Mi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5OTMzMDAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk5MzMwMCI+KEFzIGZhciBhcyBJIGNhbiB0 ZWxsIGFuZCBmcm9tIGFuIG9wZXJhdGlvbnMgcGVyc3BlY3RpdmUsIHlvdSBjYW5ub3QgZG8gSW50 ZW50LWJhc2VkIHBvbGljeSBtYW5hZ2VtZW50IHdpdGhvdXQgdGhlIFBvbGljeSBDb250aW51dW0s IG9yIGFuIGVxdWl2YWxlbnQgY29uY2VwdHVhbCBjb25zdHJ1Y3QpLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk5MzMwMCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOTkzMzAwIj5BdmFudGks PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOTkzMzAw Ij5Cb2JOPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj OTkzMzAwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBB bmltYSBbbWFpbHRvOmFuaW1hLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9i PkpvaG4gU3RyYXNzbmVyPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBcHJpbCAyMSwgMjAx NiA0OjQ3IFBNPGJyPg0KPGI+VG86PC9iPiBKb2VsIE0uIEhhbHBlcm4gJmx0O2ptaEBqb2VsaGFs cGVybi5jb20mZ3Q7OyBKb2huIFN0cmFzc25lciAmbHQ7c3RyYXpwZGpAZ21haWwuY29tJmd0Ozxi cj4NCjxiPkNjOjwvYj4gQW5pbWEgV0cgJmx0O2FuaW1hQGlldGYub3JnJmd0OzsgTWljaGFlbCBC ZWhyaW5nZXIgKG1iZWhyaW5nKSAmbHQ7bWJlaHJpbmdAY2lzY28uY29tJmd0Ozxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW0FuaW1hXSBJbnRlbnQgJnF1b3Q7YmVnaW5uaW5nIHRvIGVuZCZxdW90 OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOzEuIDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBw YXJ0aWN1bGFyLCBkb2luZyB0aGlzIGhhcyBhIG51bWJlciBvZiBhZHZhbnRhZ2VzOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJz cDsgMSkgVGhlIFBvbGljeSBDb250aW51dW0gd2FzIGJ1aWx0IHRvIG1pbWljIHRoZSBmbG93IG9m IGFic3RyYWN0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwb2xpY2llcyBi ZWluZyB0cmFuc2xhdGVkIGludG8gZGlmZmVyZW50IGZvcm1zIHRoYXQgd2VyZTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFwcGxpY2FibGUgdG8gZWFjaCB1c2VyLiBCdXNpbmVzcyBp bnRlbnQgd2lsbCBuZWVkIHNldmVyYWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBz dWNoIHRyYW5zbGF0aW9ucyBmcm9tIGV4cGVyaWVuY2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgMikgQ29udGV4dCBjYW4g YmUgdGFrZW4gaW50byBhY2NvdW50IGluIGEgdW5pZm9ybSB3YXkgKGFzIG9wcG9zZWQ8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0byBoYXZpbmcgZWFjaCBpbmRpdmlkdWFsIG5vZGUg cmVwb3J0IGNvbnRleHQpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgMykgSSBiZWxpZXZlIHRoYXQgaW50ZXJwcmV0aW5nL2Nv bXBpbGluZyBpbnRlbnQgd2lsbCBiZSBIQVJELCBhbmQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB0aGF0IHVuZGVyc3RhbmRpbmcgaW50ZW50IHdpbGwgYmUgTVVDSCBIQVJERVIuIFdo eSBkb2VzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZXZlcnkgYXV0b25vbWljIG5v ZGUgbmVlZCB0byBkbyB0aGF0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIGRvIHRoaW5rIHRoYXQgQVNBcyBzaG91bGQgYmUgdXNlZCB0byBk byB0aGUgaW50ZXJwcmV0aW5nL2NvbXBpbGluZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YW5kIHVuZGVyc3RhbmRpbmcgdGFza3MuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cmVnYXJkcyw8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvaG48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g V2VkLCBBcHIgMjAsIDIwMTYgYXQgNzoxNiBBTSwgSm9lbCBNLiBIYWxwZXJuICZsdDs8YSBocmVm PSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmptaEBqb2VsaGFs cGVybi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JdCBzZWVtcyB0byBtZSB0aGF0IGZvciBtYW55IGtpbmRzIG9mIGJ1 c2luZXNzIGludGVudGlvbnMsIGFzIHRyYW5zbGF0ZWQgaW50byAmcXVvdDtpbnRlbnRzJnF1b3Q7 LCB0aGVyZSB3aWxsIG5lZWQgdG8gYmUgYW4gaW50ZWxsaWdlbnQgcHJvY2Vzc2luZyBzdGVwIHRo YXQgZGV0ZXJtaW5lcyBob3cgdGhpcyBpbnRlbnQgcmVsYXRlcyB0byB0aGUgbmV0d29yayBzdGF0 ZSwgYW5kIGhvdyB0aGUgbmV0d29yayBuZWVkcyB0byByZXNwb25kDQogdG8gdGhpcy4mbmJzcDsg V2hpbGUgdGhlcmUgYXJlIGNhc2VzIHdoZXJlIHRoaXMgY2FuIGJlIGRvbmUgYXQgZWFjaCBBTiwg dGhlcmUgYXJlIGFsc28gbWFueSBjYXNlcyB3aGVyZSB0aGlzIG5lZWRzIGludGVybWVkaWF0ZSB3 b3JrLjxicj4NCjxicj4NCkFzIEkgdW5kZXJzdGFuZCBpdCwgdGhvc2UgaW50ZXJtZWRpYXJpZXMg YXJlIEFOLCB3aGljaCBwcm9kdWNlIHJlc3VsdHMgdXNhYmxlIGJ5IG90aGVyIEFOLiZuYnNwOyBX aGlsZSB0aGV5IHdpbGwgcHJvZHVjZSBwYXJhbWV0ZXJzIGZvciB0aGUgQU4sIHRoZXkgd2lsbCBh bHNvLCBJIGV4cGVjdCBwcm9kdWNlIHJlZmluZWQgaW50ZW50cy48YnI+DQo8YnI+DQpZb3Vycyw8 YnI+DQpKb2VsPGJyPg0KPGJyPg0KT24gNC8yMC8xNiA4OjQ5IEFNLCBNaWNoYWVsIEJlaHJpbmdl ciAobWJlaHJpbmcpIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+QWZ0ZXIgdGhlIElFVEYg ZGlzY3Vzc2lvbnMgaXQgaXMgY2xlYXIgdGhhdCB3ZSBzdGlsbCBkb24ndCBoYXZlIHRoZSBzYW1l IG1vZGVsIGluIG91ciBoZWFkIHdoZW4gd2UncmUgZGlzY3Vzc2luZyBob3cgSW50ZW50IGlzIGhh bmRsZWQuIExldCdzIHNlZSB3aGV0aGVyIHdlIGNhbiBnZXQgc29tZSBuYW1pbmcgYWdyZWVtZW50 Ljxicj4NCjxicj4NCmRyYWZ0LWR1LWFuaW1hLWFuLWludGVudCBkZXNjcmliZXMgc29tZSBvZiB0 aGUgY29udGVudCBiZWxvdyAoZS5nLiwgZGlzdHJpYnV0aW9uLCBpbnRlcnByZXRhdGlvbiksIGJ1 dCB0aGVyZSBpcyBubyAmcXVvdDtiZWdpbm5pbmcgdG8gZW5kJnF1b3Q7IGZsb3cgb24gaG93IElu dGVudCAmcXVvdDtmbG93cyZxdW90OyB0aHJvdWdoIHRoZSBuZXR3b3JrLiBJdCB3b3VsZCBoZWxw IHRoZSBkaXNjdXNzaW9uIEkgdGhpbmsgaWYgd2UgZm9ybWFsaXNlZCB0aGUgZW50aXJlIGZsb3cu IEZvcg0KIGV4YW1wbGUsIGluIHRoZSBiZWxvdyBmbG93IGl0IGlzIGNsZWFyIHRoYXQgcGFyYW1l dGVycyB5b3UgZXhjaGFuZ2UgYXMgYSByZXN1bHQgb2YgaW50ZXJwcmV0aW5nIEludGVudCBhcmUg bm90IGNhbGxlZCBJbnRlbnQuIChJIHRoaW5rIHRoaXMgd2FzIG9uZSBwb2ludCB3ZSBkb24ndCBo YXZlIGFncmVlbWVudCBvbikuPGJyPg0KPGJyPg0KTGV0IG1lIHRyeSB0byB3cml0ZSBkb3duIHRo aXMgJnF1b3Q7ZmxvdyZxdW90OywgYXMgSSBzZWUgaXQsIGFzIGEgc3RhcnRpbmcgcG9pbnQgZm9y IGRpc2N1c3Npb24uPGJyPg0KPGJyPg0KMS4gQnVzaW5lc3MgZ29hbHM6IFRoZSBuZXR3b3JrIG93 bmVyIHdhbnRzIHRoZSBuZXR3b3JrIHRvIGZvbGxvdyBzb21lIGJ1c2luZXNzIGdvYWxzLjxicj4N CiZuYnNwOyAmbmJzcDsgKFRoZXNlIGdvYWxzIGFyZSBpbml0aWFsbHkgbm90IGZvcm1hbGlzZWQs IGluIGEgY29tcHV0ZXIgc2NpZW5jZSBzZW5zZS4gKTxicj4NCiZuYnNwOyAmbmJzcDsgLSB0aGVz ZSBnb2FscyBhcmUgZm9ybWFsaXNlZCBpbiBhIGxhbmd1YWdlIC0tJmd0Ozxicj4NCjIuIEludGVu dDogaXMgdGhlIGZvcm1hbGlzYXRpb24gb2YgYnVzaW5lc3MgZ29hbHMgc28gdGhhdCBjb21wdXRl ciBjYW4gZGVhbCB3aXRoIHRoZW0uPGJyPg0KJm5ic3A7ICZuYnNwOyAoZW5jb2RlZCBhcyBhIGZp bGU7IG9yIHNldmVyYWwgZmlsZXMpPGJyPg0KJm5ic3A7ICZuYnNwOyAtIHRoaXMgZmlsZSBtdXN0 IGJlICZxdW90O2dpdmVuIHRvIHRoZSBuZXR3b3JrJnF1b3Q7IC0tJmd0Ozxicj4NCjMuIEluZ2Vz dGlvbjogVGhlIEludGVudCBmaWxlKHMpIGdldCBpbnN0YW50aWF0ZWQgb24gYW4gYXV0b25vbWlj IG5vZGU8YnI+DQombmJzcDsgJm5ic3A7IE9uIGEgcGFydGljdWxhciBub2RlLCBhbiBpbnRlbnQg ZmlsZSBpcyAmcXVvdDtpbmdlc3RlZCZxdW90Oy48YnI+DQombmJzcDsgJm5ic3A7IC0gTm93IGl0 IG5lZWRzIHRvIGJlIGRpc3RyaWJ1dGVkIC0tJmd0Ozxicj4NCjQuIEludGVudCBEaXN0cmlidXRp b246IEludGVudCBpcyBmbG9vZGVkIHRvIGFsbCBub2RlcyBpbiBhIG5ldHdvcms7PGJyPg0KJm5i c3A7ICZuYnNwOyBFdmVyeSBub2RlIGhhcyBhIGNvcHkgb2YgdGhlIG9yaWdpbmFsICZxdW90O0lu dGVudCZxdW90OyBmaWxlKHMpLCB3aXRob3V0IG1vZGlmaWNhdGlvbi48YnI+DQombmJzcDsgJm5i c3A7IEVhY2ggbm9kZSByZS1kaXN0cmlidXRlcyB0aGUgb3JpZ2luYWwgSW50ZW50IGZpbGVzLCB3 aXRob3V0IG1vZGlmaWNhdGlvbi48YnI+DQombmJzcDsgJm5ic3A7IFRoZXJlZm9yZSwgSW50ZW50 IGlzIG9wdGlvbmFsIGFuZCB0cmFuc2l0aXZlIGluIG5hdHVyZS48YnI+DQombmJzcDsgJm5ic3A7 IC0gdGhlIEludGVudCBmaWxlcyBtdXN0IG5vdyBiZSBpbnRlcnByZXRlZCBieSBlYWNoIG5vZGUg LS0mZ3Q7PGJyPg0KNS4gSW50ZW50IHNwbGl0dGluZyAob24gZWFjaCBub2RlKTo8YnI+DQombmJz cDsgJm5ic3A7IEludGVudCBpcyBzcGxpdCBpbnRvIHNlY3Rpb25zLCBvbmUgZm9yIHRoZSBBTkkg aXRzZWxmLCBvdGhlcnMgZm9yIHNwZWNpZmljIEF1dG9ub21pYyBGdW5jdGlvbnM8YnI+DQombmJz cDsgJm5ic3A7IEFTQXMgYXJlIG5vdGlmaWVkIGlmIHRoZXJlIGlzIG5ldyBJbnRlbnQgZm9yIHRo ZW0uPGJyPg0KJm5ic3A7ICZuYnNwOyBTb21lIGludGVudCBzZWN0aW9ucyBtYXkgbm90IGFwcGx5 IHRvIGEgcGFydGljdWxhciZuYnNwOyBub2RlPGJyPg0KJm5ic3A7ICZuYnNwOyBOb3cgZWFjaCBj b21wb25lbnQgb2YgYSBub2RlIChBTkksIGFsbCBBU0FzKSBrbm93IHRoZWlyIHJlc3BlY3RpdmUg SW50ZW50Ljxicj4NCjYuIEludGVudCBJbnRlcnByZXRhdGlvbiAob24gZWFjaCBub2RlLCBieSBl YWNoIGZ1bmN0aW9uKTo8YnI+DQombmJzcDsgJm5ic3A7IFRoZSBBTkkgYXMgd2VsbCBhcyBhbGwg QVNBcyBvbiBhIG5vZGUgaW50ZXJwcmV0IHRoZWlyIHJlc3BlY3RpdmUgSW50ZW50Ljxicj4NCiZu YnNwOyAmbmJzcDsgSXQgZ2V0cyB0cmFuc2xhdGVkIGludG8gYSAmcXVvdDt0YXJnZXQgY29uZmln dXJhdGlvbiZxdW90OywgdGFraW5nIGludG8gYWNjb3VudCBsb2NhbCBzdGF0ZS48YnI+DQombmJz cDsgJm5ic3A7IEZvciB0aGlzIHRyYW5zbGF0aW9uLCBpdCBtYXkgYmUgbmVjZXNzYXJ5IGZvciBB U0FzIHRvIGNvbW11bmljYXRlIHdpdGggQVNBcyBvbiBvdGhlciBub2Rlcyw8YnI+DQombmJzcDsg Jm5ic3A7IHRvIHBhc3Mgb24gcmVzb3VyY2VzIChJUCBhZGRyZXNzZXMpLCB0byBuZWdvdGlhdGUs IGV0Yy48YnI+DQombmJzcDsgJm5ic3A7IEFsbCBzdWNoIGNvbW11bmljYXRpb25zIG1heSBiZSB0 cmlnZ2VyZWQgYnkgSW50ZW50LCBidXQgdGhlIGNvbW11bmljYXRpb25zIHRoZW1zZWx2ZXM8YnI+ DQombmJzcDsgJm5ic3A7IGFyZSBOT1QgSW50ZW50Ljxicj4NCiZuYnNwOyAmbmJzcDsgKE5COiBU aGlzIGludGVycHJldGF0aW9uIGNvdWxkIGFsc28gYmUgZG9uZSBjZW50cmFsbHksIGFuZCB0aGUg cmVzdWx0aW5nIGNvbmZpZ3MgZGlzdHJpYnV0ZWQ7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtU aGlzIGlzIG9mIGNvdXJzZSBhbiBvcHRpb24sIGJ1dCBmb3IgdGhhdCB3ZSBkb24ndCBuZWVkIEFO SU1BLiBUaGVyZWZvcmUgSSBzdWdnZXN0IGZvciB0aGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw O0FOSU1BIHdvcmsgdG8gZm9jdXMgb24gaW50ZXJwcmV0aW5nIEludGVudCBsb2NhbGx5IG9uIGVh Y2ggbm9kZSk8YnI+DQombmJzcDsgJm5ic3A7IFJlc3VsdDogdGFyZ2V0IGNvbmZpZ2xldCAobm90 IGFwcGxpZWQgeWV0ISEpLjxicj4NCjcuIENvbmZsaWN0IFJlc29sdXRpb24gd2l0aCBub24tYXV0 b25vbWljIG1hbmFnZW1lbnQgKG9uIGVhY2ggbm9kZSk6PGJyPg0KJm5ic3A7ICZuYnNwOyBUaGUg dGFyZ2V0IGNvbmZpZ2xldCByZXN1bHRpbmcgZnJvbSBJbnRlbnQgaGFzIHRoZSBsb3dlc3QgcHJp bzsgYW55IG90aGVyIG1hbmFnZW1lbnQ8YnI+DQombmJzcDsgJm5ic3A7IG1ldGhvZCAoQ0xJLCBO RVRDT05GLCBldGMpIG92ZXJyaWRlcyBJbnRlbnQuPGJyPg0KOC4gQ29uZmxpY3QgUmVzb2x1dGlv biBiZXR3ZWVuIGF1dG9ub21pYyBjb21wb25lbnRzIChvbiBlYWNoIG5vZGUpOjxicj4NCiZuYnNw OyAmbmJzcDsgRWFjaCBhdXRvbm9taWMgZnVuY3Rpb24gbmVlZHMgdG8gcmVnaXN0ZXIgd2l0aCBh ICZxdW90O2NvbmZsaWN0IHJlc29sdXRpb24gZnVuY3Rpb24mcXVvdDs8YnI+DQombmJzcDsgJm5i c3A7IHdoaWNoIHBhcmFtZXRlcnMgaXQgbW9kaWZpZXM7IGluIGNhc2Ugb2YgY29uZmxpY3QgdGhl IGNvbmZsaWN0IHJlc29sdXRpb24gZnVuY3Rpb248YnI+DQombmJzcDsgJm5ic3A7IHRha2VzIGEg ZGVjaXNpb24gYW5kIGZlZWRzIHRoYXQgYmFjayB0byB0aGUgYXV0b25vbWljIGZ1bmN0aW9ucy4g VGhpcyBtYXkgbW9kaWZ5PGJyPg0KJm5ic3A7ICZuYnNwOyB0aGUgdGFyZ2V0IGNvbmZpZ2xldC48 YnI+DQo5LiBBcHBseWluZyB0aGUgdGFyZ2V0IGNvbmZpZ2xldDxicj4NCiZuYnNwOyAmbmJzcDsg QSB0eXBlIG9mICZxdW90O2NvbW1pdCZxdW90OyBvZiB0aGUgY29uZmlnbGV0Ljxicj4NCjEwLiBG ZWVkYmFjayBsb29wcyB0byBOT0M6IFRoZSBOT0MgbmVlZHMgdG8ga25vdyBhYm91dCBjZXJ0YWlu IGNvbmRpdGlvbnM6PGJyPg0KJm5ic3A7ICZuYnNwOyBDb25mbGljdHMgd2l0aCBub24tYXV0b25v bWljIG1hbmFnZW1lbnQgKEZZSSk8YnI+DQombmJzcDsgJm5ic3A7IE5vdCBhbGwgY29uZmxpY3Rz IGNhbiBiZSByZXNvbHZlZCBhdXRvbWF0aWNhbGx5LiAobWF5IHJlcXVpcmUgTk9DIGFjdGlvbnMp PGJyPg0KJm5ic3A7ICZuYnNwOyBVbmRlc2lyYWJsZSBzdGF0ZXMgKGRldmlhdGlvbnMgZnJvbSBl eHBlY3RlZCBkZWZhdWx0IGJlaGF2aW91cikgbWF5IGhhdmUgdG8gYmUgY29tbXVuaWNhdGVkOzxi cj4NCiZuYnNwOyAmbmJzcDsgVG8gc29tZSBleHRlbnQsIEludGVudCBpdHNlbGYgY2FuIHNwZWNp Znkgd2hpY2ggY29uZGl0aW9ucyBzaG91bGQgdHJpZ2dlciBmZWVkYmFjazxicj4NCiZuYnNwOyAm bmJzcDsgbG9vcHMgdG8gdGhlIE5PQy48YnI+DQombmJzcDsgJm5ic3A7IEZlZWRiYWNrIGxvb3Bz IG1heSBoYXBwZW4gYXQgb3RoZXIgcGhhc2VzIGFzIHdlbGwgKGV4OiA4KTxicj4NCjxicj4NCkkn bSBjb25zY2lvdXMgdGhhdCB0aGVyZSBhcmUgZGlmZmVyZW50IHZpZXdzIGluIHRoZSB0ZWFtOyBs aWtlIEkgYmVsaWV2ZSBpbiBwb2ludCA2IHdlJ3JlIG5vdCB5ZXQgYWxpZ25lZC4gUGxlYXNlIHRh a2UgdGhpcyBsaXN0IGp1c3QgYXMgYSBiYXNpcyBmb3IgZGlzY3Vzc2lvbiwgbm90aGluZyBtb3Jl Ljxicj4NCjxicj4NCldoZW4gd2UgaGF2ZSBjb25zZW5zdXMsIEkgYmVsaWV2ZSBzdWNoIGEgZmxv dyBzaG91bGQgYmUgZG9jdW1lbnRlZCBpbiBkcmFmdC1kdS1hbmltYS1hbi1pbnRlbnQgaW4gaXRz IGVudGlyZXR5LCB0byBnaXZlIGEgZnVsbCBwaWN0dXJlLjxicj4NCjxicj4NCkZlZWRiYWNrPzxi cj4NCk1pY2hhZWw8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCkFuaW1hIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpBbmltYUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPkFuaW1hQGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWEiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1h PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpBbmltYSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86QW5pbWFAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5BbmltYUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYTwvYT48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJy IGNsZWFyPSJhbGwiPg0KPGJyPg0KLS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPnJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Kb2huPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY1PR09MB0922439B22444A6B0304EEC8A86E0CY1PR09MB0922namp_-- From nobody Thu Apr 21 14:02:06 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5151712E67D for ; Thu, 21 Apr 2016 14:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 i5HOyrVwRIr9 for ; Thu, 21 Apr 2016 14:02:05 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35B3212E60D for ; Thu, 21 Apr 2016 14:02:05 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id 184so33908175pff.0 for ; Thu, 21 Apr 2016 14:02:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=hZJqaF7dLkTXASFG2WAuu588KppHuxaHXXrN7sdYgxo=; b=JdXPrNx4LGFKmBY12kxIsopYsd8bA88lxu3I/PnpUnEagsgWwukoBSd55CQUNpm6f4 QAdPXcg3F7tS4+JgR9CatqTBv+x0YbFta15xeFxOLA53T2rRBUJ70qaH5h4eO4pgebEz zzHYQCIh8YAE2UisJWo3IBHySkcL6RL3Ef1eqvYv9RlULJ1c4HMmgOWjoXzk42ZDXC0w 4HquVeiH4kdz8BCetJpy1hnBlGJTgK8KQIt97Xbc48wToh9Buroqv6WqAXkLltc7khrs 3Y5D1OGJY+NC1u+rb7hFyTn3LMRqMv1pr2UIJsoJfkZYtV2c67nyisQAfP5H3aS+Emjr ltkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=hZJqaF7dLkTXASFG2WAuu588KppHuxaHXXrN7sdYgxo=; b=XsI3bMUeh+DcwRDwDILBfqSR2gfi8MH+ZychPCBuhQyF8aspe/9KG7GeC0jWg1ydbb 5TgWCBvm8611N4RR9JC/8cDofq2mDghl21WqoZIfW4D5lZhPauK0QdY0og46Nm0huDFd itp1sXe+GCamyEi/HEgisFO9xWGbHNmM2frYq9bUOyJYKzG1tC+EUrPJhkwhIhDuP/go uoPqEIK8rqSVtHia+PLHzGoyPAr1Le1q2QJJICT+wWPIDhVU6GXu5oVzkK26/j9EBSQ1 WD6aJmNpfZ4KlmMC3GTw7Dx3RkFQz6ClZf55oYejtWfi0QCC9eTXC9Ec1eV8K2qe74CE HuKg== X-Gm-Message-State: AOPr4FWZSKExC3DK7PJ5gaxsKoSwaMk+FfMAk1FIPTG0VGzkqf8/5Ddxw7M8f6JwzvohcQ== X-Received: by 10.98.43.7 with SMTP id r7mr23462644pfr.24.1461272524821; Thu, 21 Apr 2016 14:02:04 -0700 (PDT) Received: from ?IPv6:2406:e007:5124:1:28cc:dc4c:9703:6781? ([2406:e007:5124:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id ee5sm4238924pac.35.2016.04.21.14.02.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Apr 2016 14:02:03 -0700 (PDT) To: John Strassner , "Joel M. Halpern" References: <74b2701c9b10416cbd2c8043e33596f1@XCH-RCD-006.cisco.com> <57178F54.5030406@joelhalpern.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <57193FCF.4000400@gmail.com> Date: Fri, 22 Apr 2016 09:02:07 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "Michael Behringer \(mbehring\)" , Anima WG Subject: Re: [Anima] Intent "beginning to end" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 21 Apr 2016 21:02:06 -0000 On 22/04/2016 08:46, John Strassner wrote: ... > 3) I believe that interpreting/compiling intent will be HARD, and > that understanding intent will be MUCH HARDER. Why does > every autonomic node need to do that? Surely that depends on the detailed design of Intent syntax and semantics, by which I mean the Intent that is distributed to all autonomic nodes and hence to all ASAs. Given that we know it needs to be interpreted by individual ASAs, shouldn't we design it to be readily interpreted? (If there is some more abstract format of Intent that is *not* distributed everywhere, that's fine, but it's not our concern for designing Anima. We have to worry about the concrete Intent that's sent to all AN nodes.) An ASA that manages resource X, which involves negotiation with other ASAs also managing resource X, and setting configuration for itself and perhaps for subsidiary non-autonomic devices using resource X, will need to interpret statements about settings the affect resource X, as well as statements about generic settings. So they need to be readily interpretable. Brian From nobody Thu Apr 21 14:10:24 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6033A12E3DC for ; Thu, 21 Apr 2016 14:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Zu3Si-BBCC8y for ; Thu, 21 Apr 2016 14:10:21 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2F0E12E192 for ; Thu, 21 Apr 2016 14:10:20 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id j11so68240121lfb.1 for ; Thu, 21 Apr 2016 14:10:20 -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; bh=nFpi3GQobcNlaVQj2YcgwIZF25hOhK26o/VXJdzd314=; b=SFmB5ByoUHW80tFk1qbgHO6V02T3sRgKJJlnOO+XLr349n+aBzF2dBA9+69FHk/QCJ nlpwBkc2SAN2sZW4jlKq4Vm3jRRc1Vorwx1WbKBMFPzuyfy1jIHsTY8dRIHr82NG5LlR nNdhaptjArfQzsVLmtPnF23eOxZlw5MI7teipeQvYSQTkQyjHYm/ypvppEW7s947o2FJ vO2hpWK+AVNI3UzuMo9t26UvWV5hK4sZU1k5MF5oUX+hesTmx6UQjiwYpXvxEPeO7lWc fhKl51J4U6H5PEUHD2NvL2nbBR74cYHtBqcuEWpLtRSAmuTsGB6OhjzCtDnLVnCYSk/B A51A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=nFpi3GQobcNlaVQj2YcgwIZF25hOhK26o/VXJdzd314=; b=bVkw5Tvsa7VoqaVA6EEmnc+lJg+v7tAzJBpT26lsS+O95mOg4eWAcX2CX5DswN9U/n IUg5Bf1cz5cqEDBQzhkxHBVBp01oAoszTS2RDvjix1rkpr3SPTnLLtxLVwlxYdZkE0dZ bz08w4JtJ076eUZ6FOhPxkKHc8wfi5ktbAvmaZAJ89paPwFp5NG/xOw4aNpfUfbH4Ja3 6z1bc53o7/SBOFS0aQZE4fK7qDJ17XALacEYEu/HekCYmx+hrk5ZeCH0wsluIbhtnJ8W SlnIHkBGeEfstHiougCVZjt86ojIu2mgRymETtuM3BXW+UAB1I1A1iHuWhi1z0GVxIiZ N2Fw== X-Gm-Message-State: AOPr4FWCE4Ih7v0NChq8c7FPFbL9WpgiXyWgrr4WDJr6jhjPCuEMU7AKit9IP0s1Ktb1eaqzTPsA/Rox4K2pRw== MIME-Version: 1.0 X-Received: by 10.25.142.201 with SMTP id q192mr7296368lfd.70.1461273019082; Thu, 21 Apr 2016 14:10:19 -0700 (PDT) Received: by 10.25.21.105 with HTTP; Thu, 21 Apr 2016 14:10:18 -0700 (PDT) In-Reply-To: References: <74b2701c9b10416cbd2c8043e33596f1@XCH-RCD-006.cisco.com> <13678.1461183947@obiwan.sandelman.ca> Date: Thu, 21 Apr 2016 14:10:18 -0700 Message-ID: From: John Strassner To: "Michael Behringer (mbehring)" , John Strassner Content-Type: multipart/alternative; boundary=001a11401dcc38f0fe0531052344 Archived-At: Cc: Michael Richardson , Anima WG Subject: Re: [Anima] Intent "beginning to end" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 21 Apr 2016 21:10:23 -0000 --001a11401dcc38f0fe0531052344 Content-Type: text/plain; charset=UTF-8 >> Michael Behringer (mbehring) wrote: >> 5. Intent splitting (on each node): >> Intent is split into sections, one for the ANI itself, others for specific >> Autonomic Functions >> >> I didn't get this part. > This is multiplexing (well, de-multiplexing). Intent contains sections > which pertain to a certain ASA. So the way I see it either an ASA > polls for Intent for itself, or there is a notification to an ASA. > > How could we phrase that better? Sorry, I'm lost. If we have a generic, abstract intent (e.g., ensure that no node exceeds 70% processor utilization, or ensure that Gold and Platinum Service always get the best possible service for a set of particular applications), then how does the node know that it is the target? A higher-level management entity must decide that this particular node is indeed involved, and this can change dynamically. Since we don't necessarily want intent policies of the form "Ethernet 1/1/2 gets AF31" :-) then we need something (an ASA?) to select the set of target nodes (hopefully based on context). This is part of my argument for post-processing the (raw) intent that is received by the first autonomic node in the network, and then try to understand intent. regards, John On Wed, Apr 20, 2016 at 11:48 PM, Michael Behringer (mbehring) < mbehring@cisco.com> wrote: > > Michael Behringer (mbehring) wrote: > > > 5. Intent splitting (on each node): > > > Intent is split into sections, one for the ANI itself, others for > specific > > Autonomic Functions > > > > I didn't get this part. > > This is multiplexing (well, de-multiplexing). Intent contains sections > which pertain to a certain ASA. So the way I see it either an ASA polls for > Intent for itself, or there is a notification to an ASA. > > How could we phrase that better? > > > > 6. Intent Interpretation (on each node, by each function): > > > The ANI as well as all ASAs on a node interpret their respective > Intent. > > > It gets translated into a "target configuration", taking into > account local > > state. > > > For this translation, it may be necessary for ASAs to communicate > with > > ASAs on other nodes, > > > to pass on resources (IP addresses), to negotiate, etc. > > > All such communications may be triggered by Intent, but the > > communications themselves > > > are NOT Intent. > > > (NB: This interpretation could also be done centrally, and the > resulting > > configs distributed; > > > This is of course an option, but for that we don't need ANIMA. > Therefore > > I suggest for the > > > ANIMA work to focus on interpreting Intent locally on each node) > > > Result: target configlet (not applied yet!!). > > > > I disagree with the NB for two reasons. > > First, "centrally" might mean "by vendor specific central system", and > so we > > would > > need ANIMA so that different vendors can communicate. > > > > Secondly, we might need to discover the central system that can do the > > interpretation,accounting,or arithmetic. > > I agree with you. But I'm not sure we're on the same page here in the > group. Thus calling it out. > > To me, ANIMA should distribute Intent to nodes, and *nodes* interpret it > and "translate" it locally to a config notation that makes sense to that > device. > > > Consider Intent's relating to bandwidth allocation throughout a network > > might need a central place to put all the numbers so that they can be > added, > > and then the resulting allocations ("configs") can be distributed back > to the > > nodes. > > I'm not sure which point you're making here? > > Michael > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > -- regards, John --001a11401dcc38f0fe0531052344 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>> Michael Behringer (mbehring) <mbehring@cisco.com> wro= te:
>> 5. Intent splitting (on each node):
>> Intent is s= plit into sections, one for the ANI itself, others for specific
>>= Autonomic Functions
>>
>> I didn't get this part.
> This is multiplexing (well, de-multiplexing). Intent contains s= ections
> which pertain to a certain ASA. So the way I see it = either an ASA
>=C2=A0polls for Intent for itself, or there is = a notification to an ASA.
>
> How could we phrase that better?=

Sorry, I'm lost.

If we have a generic, abstract intent (e.g., ensure that no node exceeds
70% processor utilization, or ensure that Gold and Platinum Servic= e
always get the best possible service for a set of particular ap= plications),
then how does the node know that it is the target? A= higher-level
management entity must decide that this particular = node is indeed
involved, and this can change dynamically.

Since we don't necessarily want intent policies of th= e form
=C2=A0=C2=A0 "Ethernet 1/1/2 gets AF31" :-)
then we need something (an ASA?) to select the set of target nodes
(hopefully based on context). This is part of my argument for
=
post-processing the (raw) intent that is received by the first
autonomic node in the network, and then try to understand intent.
<= div>

regards,
John=C2=A0

On Wed, Apr 20, 2016 at= 11:48 PM, Michael Behringer (mbehring) <mbehring@cisco.com> wrote:
> Michael Behringer (mbehring) <mbehring@cisco.com>= wrote:
>=C2=A0 =C2=A0 =C2=A0> 5. Intent splitting (on each node):
>=C2=A0 =C2=A0 =C2=A0> Intent is split into sections, one for the ANI= itself, others for specific
> Autonomic Functions
>
> I didn't get this part.

This is multiplexing (well, de-multiplexing). Intent contains sections whic= h pertain to a certain ASA. So the way I see it either an ASA polls for Int= ent for itself, or there is a notification to an ASA.

How could we phrase that better?

>=C2=A0 =C2=A0 =C2=A0> 6. Intent Interpretation (on each node, by eac= h function):
>=C2=A0 =C2=A0 =C2=A0> The ANI as well as all ASAs on a node interpre= t their respective Intent.
>=C2=A0 =C2=A0 =C2=A0> It gets translated into a "target configu= ration", taking into account local
> state.
>=C2=A0 =C2=A0 =C2=A0> For this translation, it may be necessary for = ASAs to communicate with
> ASAs on other nodes,
>=C2=A0 =C2=A0 =C2=A0> to pass on resources (IP addresses), to negoti= ate, etc.
>=C2=A0 =C2=A0 =C2=A0> All such communications may be triggered by In= tent, but the
> communications themselves
>=C2=A0 =C2=A0 =C2=A0> are NOT Intent.
>=C2=A0 =C2=A0 =C2=A0> (NB: This interpretation could also be done ce= ntrally, and the resulting
> configs distributed;
>=C2=A0 =C2=A0 =C2=A0> This is of course an option, but for that we d= on't need ANIMA. Therefore
> I suggest for the
>=C2=A0 =C2=A0 =C2=A0> ANIMA work to focus on interpreting Intent loc= ally on each node)
>=C2=A0 =C2=A0 =C2=A0> Result: target configlet (not applied yet!!).<= br> >
> I disagree with the NB for two reasons.
> First, "centrally" might mean "by vendor specific centr= al system", and so we
> would
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 need ANIMA so that different vendors can co= mmunicate.
>
> Secondly, we might need to discover the central system that can do the=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interpretation,accounting,or a= rithmetic.

I agree with you. But I'm not sure we're on the same page here in t= he group. Thus calling it out.

To me, ANIMA should distribute Intent to nodes, and *nodes* interpret it an= d "translate" it locally to a config notation that makes sense to= that device.

> Consider Intent's relating to bandwidth allocation throughout a ne= twork
> might need a central place to put all the numbers so that they can be = added,
> and then the resulting allocations ("configs") can be distri= buted back to the
> nodes.

I'm not sure which point you're making here?

Michael

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



--
regards,
John
--001a11401dcc38f0fe0531052344-- From nobody Thu Apr 21 17:23:46 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5692512E445 for ; Thu, 21 Apr 2016 17:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 yPSh3dzXJWgo for ; Thu, 21 Apr 2016 17:23:44 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 036E912E3BC for ; Thu, 21 Apr 2016 17:23:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id B87072464D2; Thu, 21 Apr 2016 17:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1461284623; bh=Y9WHExaGDrsg1kdoN4PAILQdUBln/TntslvP1VWQTQg=; h=Date:Subject:From:To:Cc:From; b=a5nhFmgeEQ0hT2iw0jhTGW2mbPIJWltCM/7fBBcElzy9SlQRr6eeq9w1geXBerpmc SbrapJx31UeaNdH+S/yl9GQ7d13SZWKprSkKWxj+U+XelZquma6Ofh0LRI+ACkDNnr n0Hra9Hafex/jqV+L/J3b8Yfj7Kpj6v+ORCu1Nrc= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [10.23.39.47] (unknown [166.170.28.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id C6C5C2400D0; Thu, 21 Apr 2016 17:23:42 -0700 (PDT) Date: Thu, 21 Apr 2016 20:23:38 -0400 Message-ID: Importance: normal From: "jmh.direct" To: Brian E Carpenter , John Strassner , "Joel M. Halpern" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_30491850834500" Archived-At: Cc: "Michael Behringer \(mbehring\)" , Anima WG Subject: Re: [Anima] Intent "beginning to end" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 22 Apr 2016 00:23:45 -0000 ----_com.samsung.android.email_30491850834500 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 RnJvbSB3aGF0IEkgaGF2ZSBzZWVuLCBhdCB0aGUgYnVzaW5lc3MgbGV2ZWwgdGhlIG5lZWRlZCBp bmZvcm1hdGlvbiBpcyBzcHJlYWQgYWNyb3NzIG11bHRpcGxlIHNvdXJjZXMuIMKgU28gaWYsIGFz IGRpYWdyYW1tZWQsIEludGVudCBzdGFydHMgYXQgdGhlIGh1bWFuLCB0aGVuIHNvbWV0aGluZyBu ZWVkcyB0byBjb21waWxlIGl0IHRvZ2V0aGVyLgpZb3VycyxKb2VsCgoKU2VudCB2aWEgdGhlIFNh bXN1bmcgR2FsYXh5IFPCriA2LCBhbiBBVCZUIDRHIExURSBzbWFydHBob25lLS0tLS0tLS0gT3Jp Z2luYWwgbWVzc2FnZSAtLS0tLS0tLUZyb206IEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNh cnBlbnRlckBnbWFpbC5jb20+IERhdGU6IDQvMjEvMjAxNiAgNTowMiBQTSAgKEdNVC0wNTowMCkg VG86IEpvaG4gU3RyYXNzbmVyIDxzdHJhenBkakBnbWFpbC5jb20+LCAiSm9lbCBNLiBIYWxwZXJu IiA8am1oQGpvZWxoYWxwZXJuLmNvbT4gQ2M6IEFuaW1hIFdHIDxhbmltYUBpZXRmLm9yZz4sICJN aWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpIiA8bWJlaHJpbmdAY2lzY28uY29tPiBTdWJqZWN0 OiBSZTogW0FuaW1hXSBJbnRlbnQgImJlZ2lubmluZyB0byBlbmQiIApPbiAyMi8wNC8yMDE2IDA4 OjQ2LCBKb2huIFN0cmFzc25lciB3cm90ZToKLi4uCj7CoMKgwqAgMykgSSBiZWxpZXZlIHRoYXQg aW50ZXJwcmV0aW5nL2NvbXBpbGluZyBpbnRlbnQgd2lsbCBiZSBIQVJELCBhbmQKPsKgwqDCoMKg wqDCoMKgIHRoYXQgdW5kZXJzdGFuZGluZyBpbnRlbnQgd2lsbCBiZSBNVUNIIEhBUkRFUi4gV2h5 IGRvZXMKPsKgwqDCoMKgwqDCoMKgIGV2ZXJ5IGF1dG9ub21pYyBub2RlIG5lZWQgdG8gZG8gdGhh dD8KClN1cmVseSB0aGF0IGRlcGVuZHMgb24gdGhlIGRldGFpbGVkIGRlc2lnbiBvZiBJbnRlbnQg c3ludGF4IGFuZCBzZW1hbnRpY3MsCmJ5IHdoaWNoIEkgbWVhbiB0aGUgSW50ZW50IHRoYXQgaXMg ZGlzdHJpYnV0ZWQgdG8gYWxsIGF1dG9ub21pYyBub2RlcwphbmQgaGVuY2UgdG8gYWxsIEFTQXMu IEdpdmVuIHRoYXQgd2Uga25vdyBpdCBuZWVkcyB0byBiZSBpbnRlcnByZXRlZCBieQppbmRpdmlk dWFsIEFTQXMsIHNob3VsZG4ndCB3ZSBkZXNpZ24gaXQgdG8gYmUgcmVhZGlseSBpbnRlcnByZXRl ZD8KKElmIHRoZXJlIGlzIHNvbWUgbW9yZSBhYnN0cmFjdCBmb3JtYXQgb2YgSW50ZW50IHRoYXQg aXMgKm5vdCogZGlzdHJpYnV0ZWQKZXZlcnl3aGVyZSwgdGhhdCdzIGZpbmUsIGJ1dCBpdCdzIG5v dCBvdXIgY29uY2VybiBmb3IgZGVzaWduaW5nIEFuaW1hLgpXZSBoYXZlIHRvIHdvcnJ5IGFib3V0 IHRoZSBjb25jcmV0ZSBJbnRlbnQgdGhhdCdzIHNlbnQgdG8gYWxsIEFOIG5vZGVzLikKCkFuIEFT QSB0aGF0IG1hbmFnZXMgcmVzb3VyY2UgWCwgd2hpY2ggaW52b2x2ZXMgbmVnb3RpYXRpb24gd2l0 aCBvdGhlcgpBU0FzIGFsc28gbWFuYWdpbmcgcmVzb3VyY2UgWCwgYW5kIHNldHRpbmcgY29uZmln dXJhdGlvbiBmb3IgaXRzZWxmIGFuZApwZXJoYXBzIGZvciBzdWJzaWRpYXJ5IG5vbi1hdXRvbm9t aWMgZGV2aWNlcyB1c2luZyByZXNvdXJjZSBYLCB3aWxsIG5lZWQKdG8gaW50ZXJwcmV0IHN0YXRl bWVudHMgYWJvdXQgc2V0dGluZ3MgdGhlIGFmZmVjdCByZXNvdXJjZSBYLCBhcyB3ZWxsIGFzCnN0 YXRlbWVudHMgYWJvdXQgZ2VuZXJpYyBzZXR0aW5ncy4gU28gdGhleSBuZWVkIHRvIGJlIHJlYWRp bHkgaW50ZXJwcmV0YWJsZS4KCsKgwqDCoCBCcmlhbgo= ----_com.samsung.android.email_30491850834500 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PkZyb20gd2hhdCBJIGhhdmUg c2VlbiwgYXQgdGhlIGJ1c2luZXNzIGxldmVsIHRoZSBuZWVkZWQgaW5mb3JtYXRpb24gaXMgc3By ZWFkIGFjcm9zcyBtdWx0aXBsZSBzb3VyY2VzLiAmbmJzcDtTbyBpZiwgYXMgZGlhZ3JhbW1lZCwg SW50ZW50IHN0YXJ0cyBhdCB0aGUgaHVtYW4sIHRoZW4gc29tZXRoaW5nIG5lZWRzIHRvIGNvbXBp bGUgaXQgdG9nZXRoZXIuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5Zb3Vycyw8L2Rpdj48ZGl2 PkpvZWw8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48 ZGl2IGlkPSJjb21wb3Nlcl9zaWduYXR1cmUiPjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTo4NSU7Y29s b3I6IzU3NTc1NyI+U2VudCB2aWEgdGhlIFNhbXN1bmcgR2FsYXh5IFPCriA2LCBhbiBBVCZhbXA7 VCA0RyBMVEUgc21hcnRwaG9uZTwvZGl2PjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtc2l6ZToxMDAl O2NvbG9yOiMwMDAwMDAiPjwhLS0gb3JpZ2luYWxNZXNzYWdlIC0tPjxkaXY+LS0tLS0tLS0gT3Jp Z2luYWwgbWVzc2FnZSAtLS0tLS0tLTwvZGl2PjxkaXY+RnJvbTogQnJpYW4gRSBDYXJwZW50ZXIg Jmx0O2JyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbSZndDsgPC9kaXY+PGRpdj5EYXRlOiA0LzIx LzIwMTYgIDU6MDIgUE0gIChHTVQtMDU6MDApIDwvZGl2PjxkaXY+VG86IEpvaG4gU3RyYXNzbmVy ICZsdDtzdHJhenBkakBnbWFpbC5jb20mZ3Q7LCAiSm9lbCBNLiBIYWxwZXJuIiAmbHQ7am1oQGpv ZWxoYWxwZXJuLmNvbSZndDsgPC9kaXY+PGRpdj5DYzogQW5pbWEgV0cgJmx0O2FuaW1hQGlldGYu b3JnJmd0OywgIk1pY2hhZWwgQmVocmluZ2VyIChtYmVocmluZykiICZsdDttYmVocmluZ0BjaXNj by5jb20mZ3Q7IDwvZGl2PjxkaXY+U3ViamVjdDogUmU6IFtBbmltYV0gSW50ZW50ICJiZWdpbm5p bmcgdG8gZW5kIiA8L2Rpdj48ZGl2Pjxicj48L2Rpdj48L2Rpdj5PbiAyMi8wNC8yMDE2IDA4OjQ2 LCBKb2huIFN0cmFzc25lciB3cm90ZTo8YnI+Li4uPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsg MykgSSBiZWxpZXZlIHRoYXQgaW50ZXJwcmV0aW5nL2NvbXBpbGluZyBpbnRlbnQgd2lsbCBiZSBI QVJELCBhbmQ8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB0aGF0IHVuZGVyc3RhbmRpbmcgaW50ZW50IHdpbGwgYmUgTVVDSCBIQVJERVIuIFdoeSBkb2Vz PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZXZlcnkg YXV0b25vbWljIG5vZGUgbmVlZCB0byBkbyB0aGF0Pzxicj48YnI+U3VyZWx5IHRoYXQgZGVwZW5k cyBvbiB0aGUgZGV0YWlsZWQgZGVzaWduIG9mIEludGVudCBzeW50YXggYW5kIHNlbWFudGljcyw8 YnI+Ynkgd2hpY2ggSSBtZWFuIHRoZSBJbnRlbnQgdGhhdCBpcyBkaXN0cmlidXRlZCB0byBhbGwg YXV0b25vbWljIG5vZGVzPGJyPmFuZCBoZW5jZSB0byBhbGwgQVNBcy4gR2l2ZW4gdGhhdCB3ZSBr bm93IGl0IG5lZWRzIHRvIGJlIGludGVycHJldGVkIGJ5PGJyPmluZGl2aWR1YWwgQVNBcywgc2hv dWxkbid0IHdlIGRlc2lnbiBpdCB0byBiZSByZWFkaWx5IGludGVycHJldGVkPzxicj4oSWYgdGhl cmUgaXMgc29tZSBtb3JlIGFic3RyYWN0IGZvcm1hdCBvZiBJbnRlbnQgdGhhdCBpcyAqbm90KiBk aXN0cmlidXRlZDxicj5ldmVyeXdoZXJlLCB0aGF0J3MgZmluZSwgYnV0IGl0J3Mgbm90IG91ciBj b25jZXJuIGZvciBkZXNpZ25pbmcgQW5pbWEuPGJyPldlIGhhdmUgdG8gd29ycnkgYWJvdXQgdGhl IGNvbmNyZXRlIEludGVudCB0aGF0J3Mgc2VudCB0byBhbGwgQU4gbm9kZXMuKTxicj48YnI+QW4g QVNBIHRoYXQgbWFuYWdlcyByZXNvdXJjZSBYLCB3aGljaCBpbnZvbHZlcyBuZWdvdGlhdGlvbiB3 aXRoIG90aGVyPGJyPkFTQXMgYWxzbyBtYW5hZ2luZyByZXNvdXJjZSBYLCBhbmQgc2V0dGluZyBj b25maWd1cmF0aW9uIGZvciBpdHNlbGYgYW5kPGJyPnBlcmhhcHMgZm9yIHN1YnNpZGlhcnkgbm9u LWF1dG9ub21pYyBkZXZpY2VzIHVzaW5nIHJlc291cmNlIFgsIHdpbGwgbmVlZDxicj50byBpbnRl cnByZXQgc3RhdGVtZW50cyBhYm91dCBzZXR0aW5ncyB0aGUgYWZmZWN0IHJlc291cmNlIFgsIGFz IHdlbGwgYXM8YnI+c3RhdGVtZW50cyBhYm91dCBnZW5lcmljIHNldHRpbmdzLiBTbyB0aGV5IG5l ZWQgdG8gYmUgcmVhZGlseSBpbnRlcnByZXRhYmxlLjxicj48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IEJyaWFuPGJyPjwvYm9keT48L2h0bWw+ ----_com.samsung.android.email_30491850834500-- From nobody Thu Apr 21 17:26:02 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9988412EB66 for ; Thu, 21 Apr 2016 17:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 tjtXkY41eytm for ; Thu, 21 Apr 2016 17:25:58 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4359912EB06 for ; Thu, 21 Apr 2016 17:25:58 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id g184so70290917lfb.3 for ; Thu, 21 Apr 2016 17:25:58 -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; bh=eWon+EEYl2k6pZPmbEahHnZdytSIMToosDpDhvx4QGE=; b=xQr/SH6O88okuB9+9UNhjb809M5ReFNiwhvRvmxlrx4M5vicb3WUuLOvNPXWCkYPFT 3haKcW2ayIPnu+6yQg1tOBDdgaa6RL8cGeugHsyNkMr+RPkXSCpXf8mdZydCIUVXItx6 LEI4eZTMS5O4De0He71JNXmjsvy9movRq7gVch82OOy/DYBxlVAUjT/iEVPx1+CETkd7 eL4BTCXN1w2KBtm0hoht6/o2xp7+u4KJw4t3rfxTVvv6UVcFWH8agMd7IlCoK1jn671R uQG4wcJ6Q8p9rutL0R5w87ak4kPC8D439bVj+NjfROK+exF1kWVmI069BhlieYG2XP05 Tlng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=eWon+EEYl2k6pZPmbEahHnZdytSIMToosDpDhvx4QGE=; b=gQ8zbFNXE+VpCDy+wPlYiQnUP/H8qlwR+hakFNyNlM8AUlHzuxdguqB9AlnGL7LlRI XDiS8U/Z0PRqpO/uDc1XWTu48H7FhXg/qihNxuWFuTgKNYIPRnvGbMA94WEMtJ9m+ud1 a4rz6WghBfYiUQVJuH7F8wlfadeDocglvJ8zlYhuAQIg9yJBtQaUVgpfA/8VkeaNHlsp rQlG8oiSTUFu3oQmYKf07hs6irK5TLflz4cKOMWHBV0E5MqU7EPfFwUMBNIQGFI8vjYV wKuiR/vWbPeR4vaRT8XjsS+Cc/ZtyGBgN+seHf9fc3DbGiOAh3qgAZj4+vnn+5VCwnu+ YkIQ== X-Gm-Message-State: AOPr4FVAy/nipxJzJg6nO0X5LHdui+rtec/A8f3UkahW7V/rwuOTAPshE5H4E596AcxWIaUfY+cBINftpdmQcg== MIME-Version: 1.0 X-Received: by 10.25.142.201 with SMTP id q192mr7571133lfd.70.1461284756455; Thu, 21 Apr 2016 17:25:56 -0700 (PDT) Received: by 10.25.21.105 with HTTP; Thu, 21 Apr 2016 17:25:56 -0700 (PDT) In-Reply-To: <46860e16d59549b6a8da05a0e46b1892@XCH-RCD-006.cisco.com> References: <74b2701c9b10416cbd2c8043e33596f1@XCH-RCD-006.cisco.com> <57178F54.5030406@joelhalpern.com> <46860e16d59549b6a8da05a0e46b1892@XCH-RCD-006.cisco.com> Date: Thu, 21 Apr 2016 17:25:56 -0700 Message-ID: From: John Strassner To: "Michael Behringer (mbehring)" , John Strassner Content-Type: multipart/alternative; boundary=001a11401dccd308ac053107de87 Archived-At: Cc: "Joel M. Halpern" , Anima WG Subject: Re: [Anima] Intent "beginning to end" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 22 Apr 2016 00:26:01 -0000 --001a11401dccd308ac053107de87 Content-Type: text/plain; charset=UTF-8 Hi Michael, >> As I understand it, those intermediaries are AN, which produce >> results usable by other AN. While they will produce parameters >> for the AN, they will also, I expect produce refined intents. > > This is where I have a hard time. If "Intent" is a business policy, > how can a node modify it?!? To me that seems impossible. I > would really like to keep Intent exactly the thing a human throws > into the network; everything else is, well, something else. Why does a node have to modify intent? I think of intent as coming from a business person or an app developer; neither of these typically knows how to configure a network service. The purpose of intent is to enable them to express what services they would like to use, and then have something else do the hard work. This is why other systems I know of put a compiling/interpreting step between the ingestion of the intent and the delivery of the **translated** intent to other autonomic nodes. regards, John On Wed, Apr 20, 2016 at 11:52 PM, Michael Behringer (mbehring) < mbehring@cisco.com> wrote: > > -----Original Message----- > > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > > Sent: 20 April 2016 16:17 > > To: Michael Behringer (mbehring) ; Anima WG > > > > Subject: Re: [Anima] Intent "beginning to end" > > > > It seems to me that for many kinds of business intentions, as translated > into > > "intents", there will need to be an intelligent processing step that > > determines how this intent relates to the network state, and how the > > network needs to respond to this. While there are cases where this can > be > > done at each AN, there are also many cases where this needs intermediate > > work. > > Can you give an example? I think the model I've noted down below is > reasonably simple, and having intermediate steps might make it a lot more > complicated. Not saying we shouldn't consider that, but only if we have to > :-) > > > As I understand it, those intermediaries are AN, which produce results > usable > > by other AN. While they will produce parameters for the AN, they will > also, I > > expect produce refined intents. > > This is where I have a hard time. If "Intent" is a business policy, how > can a node modify it?!? To me that seems impossible. I would really like to > keep Intent exactly the thing a human throws into the network; everything > else is, well, something else. > > Again, maybe an example would make this clearer? > > Michael > > > Yours, > > Joel > > > > On 4/20/16 8:49 AM, Michael Behringer (mbehring) wrote: > > > After the IETF discussions it is clear that we still don't have the > same model > > in our head when we're discussing how Intent is handled. Let's see > whether > > we can get some naming agreement. > > > > > > draft-du-anima-an-intent describes some of the content below (e.g., > > distribution, interpretation), but there is no "beginning to end" flow > on how > > Intent "flows" through the network. It would help the discussion I think > if we > > formalised the entire flow. For example, in the below flow it is clear > that > > parameters you exchange as a result of interpreting Intent are not called > > Intent. (I think this was one point we don't have agreement on). > > > > > > Let me try to write down this "flow", as I see it, as a starting point > for > > discussion. > > > > > > 1. Business goals: The network owner wants the network to follow some > > business goals. > > > (These goals are initially not formalised, in a computer science > sense. ) > > > - these goals are formalised in a language --> 2. Intent: is the > > > formalisation of business goals so that computer can deal with them. > > > (encoded as a file; or several files) > > > - this file must be "given to the network" --> 3. Ingestion: The > > > Intent file(s) get instantiated on an autonomic node > > > On a particular node, an intent file is "ingested". > > > - Now it needs to be distributed --> 4. Intent Distribution: > > > Intent is flooded to all nodes in a network; > > > Every node has a copy of the original "Intent" file(s), without > > modification. > > > Each node re-distributes the original Intent files, without > modification. > > > Therefore, Intent is optional and transitive in nature. > > > - the Intent files must now be interpreted by each node --> 5. > > > Intent splitting (on each node): > > > Intent is split into sections, one for the ANI itself, others for > specific > > Autonomic Functions > > > ASAs are notified if there is new Intent for them. > > > Some intent sections may not apply to a particular node > > > Now each component of a node (ANI, all ASAs) know their respective > > Intent. > > > 6. Intent Interpretation (on each node, by each function): > > > The ANI as well as all ASAs on a node interpret their respective > Intent. > > > It gets translated into a "target configuration", taking into > account local > > state. > > > For this translation, it may be necessary for ASAs to communicate > with > > ASAs on other nodes, > > > to pass on resources (IP addresses), to negotiate, etc. > > > All such communications may be triggered by Intent, but the > > communications themselves > > > are NOT Intent. > > > (NB: This interpretation could also be done centrally, and the > resulting > > configs distributed; > > > This is of course an option, but for that we don't need ANIMA. > Therefore > > I suggest for the > > > ANIMA work to focus on interpreting Intent locally on each node) > > > Result: target configlet (not applied yet!!). > > > 7. Conflict Resolution with non-autonomic management (on each node): > > > The target configlet resulting from Intent has the lowest prio; > any other > > management > > > method (CLI, NETCONF, etc) overrides Intent. > > > 8. Conflict Resolution between autonomic components (on each node): > > > Each autonomic function needs to register with a "conflict > resolution > > function" > > > which parameters it modifies; in case of conflict the conflict > resolution > > function > > > takes a decision and feeds that back to the autonomic functions. > This may > > modify > > > the target configlet. > > > 9. Applying the target configlet > > > A type of "commit" of the configlet. > > > 10. Feedback loops to NOC: The NOC needs to know about certain > > conditions: > > > Conflicts with non-autonomic management (FYI) > > > Not all conflicts can be resolved automatically. (may require NOC > actions) > > > Undesirable states (deviations from expected default behaviour) may > > have to be communicated; > > > To some extent, Intent itself can specify which conditions should > trigger > > feedback > > > loops to the NOC. > > > Feedback loops may happen at other phases as well (ex: 8) > > > > > > I'm conscious that there are different views in the team; like I > believe in > > point 6 we're not yet aligned. Please take this list just as a basis for > > discussion, nothing more. > > > > > > When we have consensus, I believe such a flow should be documented in > > draft-du-anima-an-intent in its entirety, to give a full picture. > > > > > > Feedback? > > > Michael > > > > > > _______________________________________________ > > > 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 > -- regards, John --001a11401dccd308ac053107de87 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Michael,

>> As I un= derstand it, those intermediaries are AN, which produce
>>= =C2=A0results usable by other AN.=C2=A0 While they will produce parameters<= /div>
>>=C2=A0for the AN, they will also, I expect produce refine= d intents.
>
> This is where I have a hard time. If "Inte= nt" is a business policy,
>=C2=A0how can a node modify it= ?!? To me that seems impossible. I
>=C2=A0would really like to= keep Intent exactly the thing a human throws
>=C2=A0into the = network; everything else is, well, something else.

=
Why does a node have to modify intent? I think of intent as coming
from a business person or an app developer; neither of these
typically knows how to configure a network service. The purpose
of intent is to enable them to express what services they would
like to use, and then have something else do the hard work.

=
This is why other systems I know of put a compiling/interpreting=
step between the ingestion of the intent and the delivery of the=
**translated** intent to other autonomic nodes.

regards,
John

=
On Wed, Apr 20, 2016 at 11:52 PM, Michael Behrin= ger (mbehring) <mbehring@cisco.com> wrote:
> -----Original Message-----
> From: Joel M. Halpern [mailto:j= mh@joelhalpern.com]
> Sent: 20 April 2016 16:17
> To: Michael Behringer (mbehring) <mbehring@cisco.com>; Anima WG
> <anima@ietf.org>
> Subject: Re: [Anima] Intent "beginning to end"
>
> It seems to me that for many kinds of business intentions, as translat= ed into
> "intents", there will need to be an intelligent processing s= tep that
> determines how this intent relates to the network state, and how the > network needs to respond to this.=C2=A0 While there are cases where th= is can be
> done at each AN, there are also many cases where this needs intermedia= te
> work.

Can you give an example? I think the model I've noted down below is rea= sonably simple, and having intermediate steps might make it a lot more comp= licated. Not saying we shouldn't consider that, but only if we have to = :-)

> As I understand it, those intermediaries are AN, which produce results= usable
> by other AN.=C2=A0 While they will produce parameters for the AN, they= will also, I
> expect produce refined intents.

This is where I have a hard time. If "Intent" is a business polic= y, how can a node modify it?!? To me that seems impossible. I would really = like to keep Intent exactly the thing a human throws into the network; ever= ything else is, well, something else.

Again, maybe an example would make this clearer?

Michael

> Yours,
> Joel
>
> On 4/20/16 8:49 AM, Michael Behringer (mbehring) wrote:
> > After the IETF discussions it is clear that we still don't ha= ve the same model
> in our head when we're discussing how Intent is handled. Let's= see whether
> we can get some naming agreement.
> >
> > draft-du-anima-an-intent describes some of the content below (e.g= .,
> distribution, interpretation), but there is no "beginning to end&= quot; flow on how
> Intent "flows" through the network. It would help the discus= sion I think if we
> formalised the entire flow. For example, in the below flow it is clear= that
> parameters you exchange as a result of interpreting Intent are not cal= led
> Intent. (I think this was one point we don't have agreement on). > >
> > Let me try to write down this "flow", as I see it, as a= starting point for
> discussion.
> >
> > 1. Business goals: The network owner wants the network to follow = some
> business goals.
> >=C2=A0 =C2=A0 =C2=A0(These goals are initially not formalised, in = a computer science sense. )
> >=C2=A0 =C2=A0 =C2=A0- these goals are formalised in a language --&= gt; 2. Intent: is the
> > formalisation of business goals so that computer can deal with th= em.
> >=C2=A0 =C2=A0 =C2=A0(encoded as a file; or several files)
> >=C2=A0 =C2=A0 =C2=A0- this file must be "given to the network= " --> 3. Ingestion: The
> > Intent file(s) get instantiated on an autonomic node
> >=C2=A0 =C2=A0 =C2=A0On a particular node, an intent file is "= ingested".
> >=C2=A0 =C2=A0 =C2=A0- Now it needs to be distributed --> 4. Int= ent Distribution:
> > Intent is flooded to all nodes in a network;
> >=C2=A0 =C2=A0 =C2=A0Every node has a copy of the original "In= tent" file(s), without
> modification.
> >=C2=A0 =C2=A0 =C2=A0Each node re-distributes the original Intent f= iles, without modification.
> >=C2=A0 =C2=A0 =C2=A0Therefore, Intent is optional and transitive i= n nature.
> >=C2=A0 =C2=A0 =C2=A0- the Intent files must now be interpreted by = each node --> 5.
> > Intent splitting (on each node):
> >=C2=A0 =C2=A0 =C2=A0Intent is split into sections, one for the ANI= itself, others for specific
> Autonomic Functions
> >=C2=A0 =C2=A0 =C2=A0ASAs are notified if there is new Intent for t= hem.
> >=C2=A0 =C2=A0 =C2=A0Some intent sections may not apply to a partic= ular=C2=A0 node
> >=C2=A0 =C2=A0 =C2=A0Now each component of a node (ANI, all ASAs) k= now their respective
> Intent.
> > 6. Intent Interpretation (on each node, by each function):
> >=C2=A0 =C2=A0 =C2=A0The ANI as well as all ASAs on a node interpre= t their respective Intent.
> >=C2=A0 =C2=A0 =C2=A0It gets translated into a "target configu= ration", taking into account local
> state.
> >=C2=A0 =C2=A0 =C2=A0For this translation, it may be necessary for = ASAs to communicate with
> ASAs on other nodes,
> >=C2=A0 =C2=A0 =C2=A0to pass on resources (IP addresses), to negoti= ate, etc.
> >=C2=A0 =C2=A0 =C2=A0All such communications may be triggered by In= tent, but the
> communications themselves
> >=C2=A0 =C2=A0 =C2=A0are NOT Intent.
> >=C2=A0 =C2=A0 =C2=A0(NB: This interpretation could also be done ce= ntrally, and the resulting
> configs distributed;
> >=C2=A0 =C2=A0 =C2=A0 This is of course an option, but for that we = don't need ANIMA. Therefore
> I suggest for the
> >=C2=A0 =C2=A0 =C2=A0 ANIMA work to focus on interpreting Intent lo= cally on each node)
> >=C2=A0 =C2=A0 =C2=A0Result: target configlet (not applied yet!!).<= br> > > 7. Conflict Resolution with non-autonomic management (on each nod= e):
> >=C2=A0 =C2=A0 =C2=A0The target configlet resulting from Intent has= the lowest prio; any other
> management
> >=C2=A0 =C2=A0 =C2=A0method (CLI, NETCONF, etc) overrides Intent. > > 8. Conflict Resolution between autonomic components (on each node= ):
> >=C2=A0 =C2=A0 =C2=A0Each autonomic function needs to register with= a "conflict resolution
> function"
> >=C2=A0 =C2=A0 =C2=A0which parameters it modifies; in case of confl= ict the conflict resolution
> function
> >=C2=A0 =C2=A0 =C2=A0takes a decision and feeds that back to the au= tonomic functions. This may
> modify
> >=C2=A0 =C2=A0 =C2=A0the target configlet.
> > 9. Applying the target configlet
> >=C2=A0 =C2=A0 =C2=A0A type of "commit" of the configlet.=
> > 10. Feedback loops to NOC: The NOC needs to know about certain > conditions:
> >=C2=A0 =C2=A0 =C2=A0Conflicts with non-autonomic management (FYI)<= br> > >=C2=A0 =C2=A0 =C2=A0Not all conflicts can be resolved automaticall= y. (may require NOC actions)
> >=C2=A0 =C2=A0 =C2=A0Undesirable states (deviations from expected d= efault behaviour) may
> have to be communicated;
> >=C2=A0 =C2=A0 =C2=A0To some extent, Intent itself can specify whic= h conditions should trigger
> feedback
> >=C2=A0 =C2=A0 =C2=A0loops to the NOC.
> >=C2=A0 =C2=A0 =C2=A0Feedback loops may happen at other phases as w= ell (ex: 8)
> >
> > I'm conscious that there are different views in the team; lik= e I believe in
> point 6 we're not yet aligned. Please take this list just as a bas= is for
> discussion, nothing more.
> >
> > When we have consensus, I believe such a flow should be documente= d in
> draft-du-anima-an-intent in its entirety, to give a full picture.
> >
> > Feedback?
> > Michael
> >
> > _______________________________________________
> > 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



--
regards,
John
--001a11401dccd308ac053107de87-- From nobody Thu Apr 21 17:36:42 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9FB12E5E9 for ; Thu, 21 Apr 2016 17:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 KOYBhmDGd6p1 for ; Thu, 21 Apr 2016 17:36:37 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 341B712EB90 for ; Thu, 21 Apr 2016 17:36:37 -0700 (PDT) Received: by mail-lb0-x22b.google.com with SMTP id ys16so35797623lbb.3 for ; Thu, 21 Apr 2016 17: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; bh=/WTM2SL/am2fECaOO7TvKbbz3shjlf+U83LFCN0/tHs=; b=twn6BtmiziQW+0z6bjm3JuN6XbT6sPesE35Mv9AHIIcP/p5j/1scC4kplc0q9TohPj cidJaNg6NgnwySPA3GGEr2fPOwoy5mSQWa+00dOfoGRFWcpPr457j2KtQp/9nUV2VMEG JkVwhRhCkOw6EfJmfIUU4uMMJ7d8/v0kBSP1xnIO2AT8rjWnZCEaSuTxRKvCH1G1ZXdl /1tdiCdVF9YmJAgJvCFY98AUyuOdaq055s7B42ZouADV75rjB7X2fLRoawrExW5Em4g3 fiGEJLWGgnAyFSM3WbIxKetqUp4KQxm32o1XglcHv07AyjNKcq8jU9eSNYh15JdCVI73 FL0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=/WTM2SL/am2fECaOO7TvKbbz3shjlf+U83LFCN0/tHs=; b=m37kJse9SWkLw1ax//7hqmnoEbrEv0fk5KKwvE6evwfAvNGcX+cGG24icsFhbbPOQZ 1M7mXCfc584O8jJhLPy01HvipIu4ekUFn35zxWZCgsvHwiP1apMD7Nv1Hju99nU69sNC TKbALZ9+Aim9V6IBDXJlrTfnOjBwIL8UhVp3sOjoQdNUqd5Z+UnE6cSDdbyF7yPetWuV 5fTDuvBy371DvuZ0xJ8xt2Mzaomuy9fWa6cpcdxEXq6F9KStDmZcO3GOY2cpxOyrGjkR 80nf/bJrV9a8GmUA2jDMOQP+umug7mcS3xzaPLdf+76Wqj8Cmfy5kBP+yd2XkkIBIB4v 9xdw== X-Gm-Message-State: AOPr4FUiCi/BDQ/cf/VZHUTr6AUZ3f7gPP8VABjqXfdYI1cyZsSQqAaYiEP+9QRgyKiNKLvD4aAYWuFzP+5nHg== MIME-Version: 1.0 X-Received: by 10.112.198.166 with SMTP id jd6mr7496944lbc.12.1461285395428; Thu, 21 Apr 2016 17:36:35 -0700 (PDT) Received: by 10.25.21.105 with HTTP; Thu, 21 Apr 2016 17:36:35 -0700 (PDT) In-Reply-To: References: <74b2701c9b10416cbd2c8043e33596f1@XCH-RCD-006.cisco.com> <13678.1461183947@obiwan.sandelman.ca> Date: Thu, 21 Apr 2016 17:36:35 -0700 Message-ID: From: John Strassner To: "Michael Behringer (mbehring)" , John Strassner Content-Type: multipart/alternative; boundary=001a11c2ac90e8f9b8053108044c Archived-At: Cc: Duzongpeng , Michael Richardson , Anima WG Subject: Re: [Anima] Intent "beginning to end" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 22 Apr 2016 00:36:40 -0000 --001a11c2ac90e8f9b8053108044c Content-Type: text/plain; charset=UTF-8 > (Someone might argue here that as a result of the feedback loop > Intent should be changed; I would argue: Maybe; but since Intent > is on business level, this would should involve some human > intervention, thus a manual change of Intent, and the same flow > applies again. It depends. I think that ANIMA SHOULD (in the IETF sense) work on what you describe above, and decouple intent from the control loops. However, we need to be careful of the edge cases. For example, if intent is to give a customer Platinum Service, and that cannot be done, hopefully the system realizes that Gold is the best we can do and proceeds (as opposed to giving the customer nothing). > I think dynamic changes to Intent are NOT a good idea. Put > differently, I think Intent should not be touched by the network.) Now I'm confused. If intent in its raw form is flooded to every node in the network, clearly some node is going to have to touch it and/or transform it into a form that other nodes can understand. Joel and I have given some examples of when this is needed. This is why I objected to the overhead of all nodes having to be able to parse intent, let alone understand and act on it. I think (and hope) that what you are saying is that the network SHOULD NOT alter the "intent of the intent" (sorry!). This means that transformation (without changing meaning) is perfectly fine, but changing the semantics would, for example, not be allowed. Is this correct? regards, John On Thu, Apr 21, 2016 at 5:58 AM, Michael Behringer (mbehring) < mbehring@cisco.com> wrote: > > -----Original Message----- > > From: Duzongpeng [mailto:duzongpeng@huawei.com] > > Sent: 21 April 2016 14:34 > > To: Michael Richardson > > Cc: Michael Behringer (mbehring) ; Anima WG > > > > Subject: RE: [Anima] Intent "beginning to end" > > > > Hi, Michael Richardson > > > > About the "centrally" and "distributed", I want to suggest that it > > depends. > > > > Some simple ones perhaps is easy to handle, and every node can > > understand and interpret the intent. > > > > I think Michael Behringer has suggested to start with some simple > > functions in the beginning. > > > > On the other side, I do not think ANIMA means every node make > > their own decisions for everything. > > > > Some central node (maybe elected) may also exist in the ANIMA > > network for some functions, such as making some high level decision after > > collecting enough network information. > > Absolutely! However, there are two ways of doing that, and neither > involves Intent: > > 1 - NMS/controller gets feedback; sees that it needs to make some > adjustments in some places: In this case it would use a standard NETCONF > call (for example) to set corresponding parameters on specific nodes --> > outside ANIMA scope; we simply state "every other configuration type > overrides Intent". It's clear and easy. > > 2 - NMS/controller gets feedback; sees that it needs to make some > adjustments, and uses ANIMA signalling to signal directly via GRASP what > needs to be done: That *is* in scope, but I think it is "after" Intent, and > as such outside scope for the Intent draft. To me, an autonomic function > has various ASAs, one of which could be in the NOC. They use GRASP / > whatever to communicate. So this is really nothing to do with Intent. We > just must make sure in ANIMA that autonomic functions with all related ASAs > have the tools they need. > > (Someone might argue here that as a result of the feedback loop Intent > should be changed; I would argue: Maybe; but since Intent is on business > level, this would should involve some human intervention, thus a manual > change of Intent, and the same flow applies again. I think dynamic changes > to Intent are NOT a good idea. Put differently, I think Intent should not > be touched by the network.) > > These are good discussions! Do you agree with this view? If not, where not? > > Michael > > > Best Regards > > Zongpeng Du > > > > -----Original Message----- > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael > > Richardson > > Sent: Thursday, April 21, 2016 4:26 AM > > To: Anima WG > > Cc: Michael Behringer (mbehring) > > Subject: Re: [Anima] Intent "beginning to end" > > > > > > Michael Behringer (mbehring) wrote: > > > 5. Intent splitting (on each node): > > > Intent is split into sections, one for the ANI itself, others for > specific > > Autonomic Functions > > > > I didn't get this part. > > > > > 6. Intent Interpretation (on each node, by each function): > > > The ANI as well as all ASAs on a node interpret their respective > Intent. > > > It gets translated into a "target configuration", taking into > account local > > state. > > > For this translation, it may be necessary for ASAs to communicate > with > > ASAs on other nodes, > > > to pass on resources (IP addresses), to negotiate, etc. > > > All such communications may be triggered by Intent, but the > > communications themselves > > > are NOT Intent. > > > (NB: This interpretation could also be done centrally, and the > resulting > > configs distributed; > > > This is of course an option, but for that we don't need ANIMA. > Therefore > > I suggest for the > > > ANIMA work to focus on interpreting Intent locally on each node) > > > Result: target configlet (not applied yet!!). > > > > I disagree with the NB for two reasons. > > First, "centrally" might mean "by vendor specific central system", and > so we > > would > > need ANIMA so that different vendors can communicate. > > > > Secondly, we might need to discover the central system that can do the > > interpretation,accounting,or arithmetic. > > > > Consider Intent's relating to bandwidth allocation throughout a network > > might need a central place to put all the numbers so that they can be > added, > > and then the resulting allocations ("configs") can be distributed back > to the > > nodes. > > > > > > -- > > Michael Richardson , Sandelman Software Works > > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > -- regards, John --001a11c2ac90e8f9b8053108044c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> (Someone might argue here that as a result of th= e feedback loop
>=C2=A0Intent should be changed; I would argue= : Maybe; but since Intent
>=C2=A0is on business level, this wo= uld should involve some human
>=C2=A0intervention, thus a manu= al change of Intent, and the same flow
>=C2=A0applies again.

It depends. I think that ANIMA SHOULD (in the IETF = sense) work
on what you describe above, and decouple intent from = the control
loops. However, we need to be careful of the edge cas= es. For
example, if intent is to give a customer Platinum Service= , and that
cannot be done, hopefully the system realizes that Gol= d is the best
we can do and proceeds (as opposed to giving the cu= stomer
nothing).

> I think dynamic ch= anges to Intent are NOT a good=C2=A0idea. Put
> differently, I= think Intent should not be touched by the network.)

Now I'm confused. If intent in its raw form is flooded to every node=
in the network, clearly some node is going to have to touch it a= nd/or
transform it into a form that other nodes can understand. J= oel and I
have given some examples of when this is needed. This i= s why I
objected to the overhead of all nodes having to be able t= o parse
intent, let alone understand and act on it.
I think (and hope) that what you are saying is that the network=
SHOULD NOT alter the "intent of the intent" (sorry!). = This means
that transformation (without changing meaning) is perf= ectly fine,
but changing the semantics would, for example, not be= allowed.
Is this correct?

regards,
John

On Thu, Apr 21, 2016 at 5:58 AM, Michael Behringer (mbehring) <m= behring@cisco.com> wrote:
&= gt; -----Original Message-----
> From: Duzongpeng [mailto:duzo= ngpeng@huawei.com]
> Sent: 21 April 2016 14:34
> To: Michael Richardson <= mcr+ietf@sandelman.ca>
> Cc: Michael Behringer (mbehring) <mbehring@cisco.com>; Anima WG
> <anima@ietf.org>
> Subject: RE: [Anima] Intent "beginning to end"
>
> Hi, Michael Richardson
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0About the "centrally" and "di= stributed", I want to suggest that it
> depends.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Some simple ones perhaps is easy to handle, = and every node can
> understand and interpret the intent.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I think Michael Behringer has suggested to s= tart with some simple
> functions in the beginning.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0On the other side, I do not think ANIMA mean= s every node make
> their own decisions for everything.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Some central node (maybe elected) may also e= xist in the ANIMA
> network for some functions, such as making some high level decision af= ter
> collecting enough network information.

Absolutely! However, there are two ways of doing that, and neither involves= Intent:

1 - NMS/controller gets feedback; sees that it needs to make some adjustmen= ts in some places: In this case it would use a standard NETCONF call (for e= xample) to set corresponding parameters on specific nodes --> outside AN= IMA scope; we simply state "every other configuration type overrides I= ntent". It's clear and easy.

2 - NMS/controller gets feedback; sees that it needs to make some adjustmen= ts, and uses ANIMA signalling to signal directly via GRASP what needs to be= done: That *is* in scope, but I think it is "after" Intent, and = as such outside scope for the Intent draft. To me, an autonomic function ha= s various ASAs, one of which could be in the NOC. They use GRASP / whatever= to communicate. So this is really nothing to do with Intent. We just must = make sure in ANIMA that autonomic functions with all related ASAs have the = tools they need.

(Someone might argue here that as a result of the feedback loop Intent shou= ld be changed; I would argue: Maybe; but since Intent is on business level,= this would should involve some human intervention, thus a manual change of= Intent, and the same flow applies again. I think dynamic changes to Intent= are NOT a good idea. Put differently, I think Intent should not be touched= by the network.)

These are good discussions! Do you agree with this view? If not, where not?=

Michael

> Best Regards
> Zongpeng Du
>
> -----Original Message-----
> From: Anima [mailto:anima-bo= unces@ietf.org] On Behalf Of Michael
> Richardson
> Sent: Thursday, April 21, 2016 4:26 AM
> To: Anima WG
> Cc: Michael Behringer (mbehring)
> Subject: Re: [Anima] Intent "beginning to end"
>
>
> Michael Behringer (mbehring) <mbehring@cisco.com> wrote:
>=C2=A0 =C2=A0 =C2=A0> 5. Intent splitting (on each node):
>=C2=A0 =C2=A0 =C2=A0> Intent is split into sections, one for the ANI= itself, others for specific
> Autonomic Functions
>
> I didn't get this part.
>
>=C2=A0 =C2=A0 =C2=A0> 6. Intent Interpretation (on each node, by eac= h function):
>=C2=A0 =C2=A0 =C2=A0> The ANI as well as all ASAs on a node interpre= t their respective Intent.
>=C2=A0 =C2=A0 =C2=A0> It gets translated into a "target configu= ration", taking into account local
> state.
>=C2=A0 =C2=A0 =C2=A0> For this translation, it may be necessary for = ASAs to communicate with
> ASAs on other nodes,
>=C2=A0 =C2=A0 =C2=A0> to pass on resources (IP addresses), to negoti= ate, etc.
>=C2=A0 =C2=A0 =C2=A0> All such communications may be triggered by In= tent, but the
> communications themselves
>=C2=A0 =C2=A0 =C2=A0> are NOT Intent.
>=C2=A0 =C2=A0 =C2=A0> (NB: This interpretation could also be done ce= ntrally, and the resulting
> configs distributed;
>=C2=A0 =C2=A0 =C2=A0> This is of course an option, but for that we d= on't need ANIMA. Therefore
> I suggest for the
>=C2=A0 =C2=A0 =C2=A0> ANIMA work to focus on interpreting Intent loc= ally on each node)
>=C2=A0 =C2=A0 =C2=A0> Result: target configlet (not applied yet!!).<= br> >
> I disagree with the NB for two reasons.
> First, "centrally" might mean "by vendor specific centr= al system", and so we
> would
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 need ANIMA so that different vendors can co= mmunicate.
>
> Secondly, we might need to discover the central system that can do the=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interpretation,accounting,or a= rithmetic.
>
> Consider Intent's relating to bandwidth allocation throughout a ne= twork
> might need a central place to put all the numbers so that they can be = added,
> and then the resulting allocations ("configs") can be distri= buted back to the
> nodes.
>
>
> --
> Michael Richardson <mcr+= IETF@sandelman.ca>, Sandelman Software Works
> -=3D IPv6 IoT consulting =3D-
>
>

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



--
regards,
John
--001a11c2ac90e8f9b8053108044c-- From nobody Thu Apr 21 17:53:03 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC9212DCA4 for ; Thu, 21 Apr 2016 17:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 wzDLbhWz8eyh for ; Thu, 21 Apr 2016 17:52:59 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24F2312D562 for ; Thu, 21 Apr 2016 17:52:57 -0700 (PDT) Received: by mail-lb0-x232.google.com with SMTP id u8so35892120lbk.0 for ; Thu, 21 Apr 2016 17:52:57 -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; bh=Gfeklx3/6HupZypYt6V5XKfvDi5nqkorKL4bRKlkcEg=; b=g3kP+Ln5HAzfA7XVmNYesCDSXFV8izzCtSt45kd4PrKCApYXYGjPpAdqL/ON3475nd eOHeFq+d06oMF9T3qp5LgO02LOy/Q+vc5kwV0O9zKGF0zG8NvabBL1RArFZIZvt9Q17I XjcgJ7hvEoPpdu6JGSPBxWZc8lD/qoMIllXhoxfNhYJ4uo/OWC7G9BxfXPWLn6S2ThF5 etfssKBhtGOOsDMdDj0auWz4plTVjulcCx0Gwaj02zJE09tdqCnlCKfF213fX1x62zkD i7UMM0nQwdWZJBP5m/5Bm5gas199WWFPTN60O/a/LlVPbXVywX+VPlLPI8XFt7EuM6S+ CmTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Gfeklx3/6HupZypYt6V5XKfvDi5nqkorKL4bRKlkcEg=; b=FSFm9E7O34fRD4EAeN4UWwgOWh5Qx31xyE1OpbKyhSvVx8EsjrAy4jmZnG9dVLEhYw JeM6DzVFsnNhL1ytrtGosILgAPEz/hRXvqEVtiG5Gl4IjSDL/Ejyh2DOgWmR1VppLMH/ vPnqwELrwjQk05phg6O3WJoDhwOvrJxKtTwU9s7sF9IHzrrZ4nXueqk8BCIXShqN4+q6 GbQ6CIpWWWa422ytm12PS0rxmA50rlHy+7C/25aCRKaIYN5YArdesR5IYi4yCvfR59zW svDmbp3Z4JYmNwE+GuAHXsd1cSMFf96UMZfr13AGIB9CNOD1KAf8ZIUQtAFHgAxamDSU cLsg== X-Gm-Message-State: AOPr4FVzZWALhURViKVocaJyufSYB50DQLTRaMq0QlqYaEWGM5iKxapDOlXJjVQnlk9+yhJx1kepx+D2LLdGtg== MIME-Version: 1.0 X-Received: by 10.112.84.202 with SMTP id b10mr7393149lbz.41.1461286376203; Thu, 21 Apr 2016 17:52:56 -0700 (PDT) Received: by 10.25.21.105 with HTTP; Thu, 21 Apr 2016 17:52:56 -0700 (PDT) In-Reply-To: References: <74b2701c9b10416cbd2c8043e33596f1@XCH-RCD-006.cisco.com> <57178F54.5030406@joelhalpern.com> <46860e16d59549b6a8da05a0e46b1892@XCH-RCD-006.cisco.com> <5718DEE8.20709@joelhalpern.com> Date: Thu, 21 Apr 2016 17:52:56 -0700 Message-ID: From: John Strassner To: "Michael Behringer (mbehring)" , John Strassner Content-Type: multipart/alternative; boundary=001a1135ea065e6c4a0531083fce Archived-At: Cc: "Joel M. Halpern" , Anima WG Subject: Re: [Anima] Intent "beginning to end" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 22 Apr 2016 00:53:02 -0000 --001a1135ea065e6c4a0531083fce Content-Type: text/plain; charset=UTF-8 While waiting for Laurent to return, I'd like to offer my view (I've graduated a couple of Ph.D. students in this subject, btw). I don't see this as conflict resolution IFF this is a declarative intent. (If it is procedural or imperative, then possibly, but even then, I'm not convinced). This is because a set of traffic selection and action policies could be defined that have no conflicts at all. Furthermore, just because different functions are involved does not mean that they conflict - they only have the potential to conflict. For example, a service chain has different functions, and they better not conflict... As yet another example, if I implemented this using a declarative logic program, then by definition there would not be any conflicts. I would instead call this "service compatibility checking" (a horrible name, sorry, but the problem is that "conflict resolution" has very defined semantics in the policy world). All this being said, if there is a conflict, then: 1) some type of sanity checking SHOULD be done, but I'm assuming that this is done BEFORE the intent is sent to the network 2) if an actual conflict does occur, then I do agree that this is NOT an intent or intent distribution problem. regards, John On Thu, Apr 21, 2016 at 10:01 AM, Michael Behringer (mbehring) < mbehring@cisco.com> wrote: > > -----Original Message----- > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Joel M. Halpern > > Sent: 21 April 2016 16:09 > > To: Michael Behringer (mbehring) ; Anima WG > > > > Subject: Re: [Anima] Intent "beginning to end" > > > > It would be nice if the problem is simpler than I think it is. > > > > An example that occurs to me is the usual set of traffic prioritization > > policies: > > > > Ensure that high quality traffic from Platinum customers gets priority, > > + > > ... other traffic selection policies > > + > > Policies that identify traffic > > + > > Ensure that no link is more than 70% utilized. > > > > Someone is going to have to decide which traffic goes where. I do not > > believe each network node independently, no matter how much AN > > intelligence it has, can act on these policies themselves. Yes, nodes > can > > detect violations, but I can not see how they can remediate > independently. > > Now I understand, thanks for clarifying. That, to me, this should be > covered in point > 8. Conflict Resolution between autonomic components (on each node): > > Since, these are different autonomic functions that produce results that > need a conflict resolution. > > In other words, also here, I think this is outside Intent and Intent > distribution. > > Laurent is the specialist for conflict resolution - would be good to get > his perspective (but he's offline this week, afaik) > > Does that make sense, Joel, or am I over-simplifying? > Michael > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > -- regards, John --001a1135ea065e6c4a0531083fce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
While waiting for Laurent to return, I'd like to = offer my view
(I've graduated a couple of Ph.D. students in this sub= ject, btw).

I don't see this as conflict resol= ution IFF this is a declarative
intent. (If it is procedural or imperati= ve, then possibly, but even
then, I'm not convinced). This is becaus= e a set of traffic selection
and action policies could be defined that h= ave no conflicts at all.
Furthermore, just because different functions a= re involved does not
mean that they conflict - they only have the potent= ial to conflict.
For example, a service chain has different functions, a= nd they better
not conflict...

As yet another e= xample, if I implemented this using a declarative
logic program, then by= definition there would not be any conflicts.
I would instead cal= l this "service compatibility checking" (a horrible
name, sorr= y, but the problem is that "conflict resolution" has very
defi= ned semantics in the policy world).

All this being= said, if there is a conflict, then:

=C2=A0=C2=A0 = 1) some type of sanity checking SHOULD be done, but I'm assuming
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 that this is done BEFORE the intent is sent to = the network
=C2=A0=C2=A0 2) if an actual conflict does occur, then I do = agree that this is
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 NOT an intent or inten= t distribution problem.


regards,John


On Thu, Apr 21, 2016 at 10:01 AM, Michael Behringer (mbehr= ing) <mbehring@cisco.com> wrote:
> -----Original Message-----
> From: Anima [mailto:anima-bo= unces@ietf.org] On Behalf Of Joel M. Halpern
> Sent: 21 April 2016 16:09
> To: Michael Behringer (mbehring) <mbehring@cisco.com>; Anima WG
> <anima@ietf.org>
> Subject: Re: [Anima] Intent "beginning to end"
>
> It would be nice if the problem is simpler than I think it is.
>
> An example that occurs to me is the usual set of traffic prioritizatio= n
> policies:
>
> Ensure that high quality traffic from Platinum customers gets priority= ,
>=C2=A0 =C2=A0+
> ... other traffic selection policies
>=C2=A0 =C2=A0+
> Policies that identify traffic
>=C2=A0 =C2=A0+
> Ensure that no link is more than 70% utilized.
>
> Someone is going to have to decide which traffic goes where.=C2=A0 I d= o not
> believe each network node independently, no matter how much AN
> intelligence it has, can act on these policies themselves.=C2=A0 Yes, = nodes can
> detect violations, but I can not see how they can remediate independen= tly.

Now I understand, thanks for clarifying. That, to me, this should be covere= d in point
8. Conflict Resolution between autonomic components (on each node):

Since, these are different autonomic functions that produce results that ne= ed a conflict resolution.

In other words, also here, I think this is outside Intent and Intent distri= bution.

Laurent is the specialist for conflict resolution - would be good to get hi= s perspective (but he's offline this week, afaik)

Does that make sense, Joel, or am I over-simplifying?
Michael

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



--
regards,
John
--001a1135ea065e6c4a0531083fce-- From nobody Thu Apr 21 18:12:44 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E86512EBAF for ; Thu, 21 Apr 2016 18:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 YBNosifxRMtk for ; Thu, 21 Apr 2016 18:12:42 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1B0312EBBB for ; Thu, 21 Apr 2016 18:12:41 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id e128so35303865pfe.3 for ; Thu, 21 Apr 2016 18:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=VbPUFCu+EV147N0AnxggN3uHZ6wQHwbTkrGWJ47vTb4=; b=ajL3ER12N156tsDqUmljqk5wyQ46vVhauVpVj8GhNr/GviRvEVOMzPVHE+C489a/Af iA1xantT/zSPpRiKMo5wRhalzGjVS4r9R99rS/91/iwaqf4vfBnPaaY86VAk2BYG3E8x Lt9UE1oHAxyCq613mdJSjGsZTDjWHld/YzSEAKC4N6p0zFUt9oFVZQhDVKTBCLv1yhG5 M7EKYjQuTZ9BJLd57eBCYrE0JIjJ9O/rZrTEYMFIK03x6zxgOGukbBg82g28fOruoNqS zQZTeZoKrtkf8nnvV+vU27S46KZsNSygSHW/gNCGhrcL5D2TtxA37caU6DYeQnRIgpMc PKOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=VbPUFCu+EV147N0AnxggN3uHZ6wQHwbTkrGWJ47vTb4=; b=L4SQyJIKG50Uzqfrn9a0CCPrZ1s225CGYa+Dn0IBQi9jLmTjZkK5MiOIyEzZ1VbIIS 5/BCFn0SOCpXcNSN9D+lYiAINMunbg9QRHnSkcSIgcWnv43B6FQbHevEAOsQJxq7dU09 a3+YS5JYnxmfAUKpUHGXYgoAJVbP2EQmyLNAtoZTQ90P4bs7vfhWy4xdIQNatYl3sb01 lwc0PWSLqjeCB3ZGocDxuu3mlJJW0hZACpsqOW6eMmN4MITxQefAcjaykRd8ijIp2kHo g/jAAhdr54WIDUPjtZO5t9CX47D3Zo15sPhyfcmdhvRzavzJr5uVwPFMLwDHVc8d8KDk Ib4w== X-Gm-Message-State: AOPr4FUR8fcVoNE2solj93+eOEKKgn/6RpVYshCQi7Qp/MN8H3GAosxtSlNejN/olqu/qg== X-Received: by 10.98.85.131 with SMTP id j125mr24911189pfb.22.1461287561512; Thu, 21 Apr 2016 18:12:41 -0700 (PDT) Received: from ?IPv6:2406:e007:5124:1:28cc:dc4c:9703:6781? ([2406:e007:5124:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id o65sm3792827pfb.24.2016.04.21.18.12.37 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Apr 2016 18:12:39 -0700 (PDT) To: "jmh.direct" , John Strassner , "Joel M. Halpern" References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <57197A8D.1000306@gmail.com> Date: Fri, 22 Apr 2016 13:12:45 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Michael Behringer \(mbehring\)" , Anima WG Subject: Re: [Anima] Intent "beginning to end" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 22 Apr 2016 01:12:43 -0000 On 22/04/2016 12:23, jmh.direct wrote: > From what I have seen, at the business level the needed information is = spread across multiple sources. So if, as diagrammed, Intent starts at t= he human, then something needs to compile it together. Certainly. So in fact we are talking about two different things. Intent (H): what humans generate, that must be sanity checked, reconciled= , and compiled into Intent (A): a consistent form of Intent that can be interpreted by an alg= orithm in any autonomic node. I believe that Anima should focus on Intent (A). Brian > Yours,Joel >=20 >=20 > Sent via the Samsung Galaxy S=C2=AE 6, an AT&T 4G LTE smartphone-------= - Original message --------From: Brian E Carpenter Date: 4/21/2016 5:02 PM (GMT-05:00) To: John Strassner , "Joel M. Halpern" Cc: Anima WG , "Michael Behringer (mbehring)" Subject: = Re: [Anima] Intent "beginning to end"=20 > On 22/04/2016 08:46, John Strassner wrote: > ... >> 3) I believe that interpreting/compiling intent will be HARD, and >> that understanding intent will be MUCH HARDER. Why does >> every autonomic node need to do that? >=20 > Surely that depends on the detailed design of Intent syntax and semanti= cs, > by which I mean the Intent that is distributed to all autonomic nodes > and hence to all ASAs. Given that we know it needs to be interpreted by= > individual ASAs, shouldn't we design it to be readily interpreted? > (If there is some more abstract format of Intent that is *not* distribu= ted > everywhere, that's fine, but it's not our concern for designing Anima. > We have to worry about the concrete Intent that's sent to all AN nodes.= ) >=20 > An ASA that manages resource X, which involves negotiation with other > ASAs also managing resource X, and setting configuration for itself and= > perhaps for subsidiary non-autonomic devices using resource X, will nee= d > to interpret statements about settings the affect resource X, as well a= s > statements about generic settings. So they need to be readily interpret= able. >=20 > Brian >=20 From nobody Thu Apr 21 18:15:34 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0CD12EB82 for ; Thu, 21 Apr 2016 18:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 1yLIKjTjB37l for ; Thu, 21 Apr 2016 18:15:31 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2551212E46B for ; Thu, 21 Apr 2016 18:15:31 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id e190so70778980lfe.0 for ; Thu, 21 Apr 2016 18:15:31 -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; bh=2eRTMYUMBwWA803b+lvFUIc+zm7P574jYY9E1685xOQ=; b=GBAVP0kXCqOgFjhIEc2X4ZRU9LVYOxwS6nmLqe+DsaCfPV3kMYKA3h5qfpwgGqRGtV s0n5VlKAA5eGcEsVstSJl8hn4eC1q1TUXs6emzdm8MCl2YXa1oLbAK3VNhZk73OXXzjZ rO2eGtUKj1nG6TYnR4EzPNud8ZOXkkdYWe9Uh+0Z3RIDt+aMbg7W75Q8VMtw2RHgHRnD q04s3oE7VVJMMek6+QCK7wGTDyYuEzEINEikeVw2u8CtZbRcWwT8Nd2Ij5vv3XTE8BwM iExNUA7MCoOfvwvZuiq9cE+7eovx0WiQyGwclKfO7YwKM31lwwwrLvP95CrEb9xpLfmi iUwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=2eRTMYUMBwWA803b+lvFUIc+zm7P574jYY9E1685xOQ=; b=Ic2+zQ3aKXWFvpLD8HJbU6BPZLF52ITvfmWsIp014MyTYASQOeVAzQIwKcKspRRrPj UEoePSNKO9WxdjHV8R1EunUTjpedDHU4JhwexbfunIRF+BSWDQeoYT4819V1d+g+s7HN /iFCOHsR/n1bV8b5TBc1zjsssYqeFFKNPY51N60BgJpQCrZ/JuXgZWho7fZnahYOiyEf G4Z+CG631Tptv483sFFEL2C+AdibQBjrQWMiXNxQmB/zaCl5b4ZcYN+sXXk6kWo0GHqx NI7jNOF2Ap2nmGAZ2Srk8vl0WIS/gyf3/CwuUWKY3FoTrVRj7t1J3jpsGWtNTUSMAzVt Gdrw== X-Gm-Message-State: AOPr4FXxV3aYgiVeXSlaPiD4D/aWhtelj3+HfVe4JrSw+5FqVg7U+ayQctx1uZCbLuU4pO+T9sLiz/MwtKvbKg== MIME-Version: 1.0 X-Received: by 10.25.19.157 with SMTP id 29mr7542306lft.100.1461287729330; Thu, 21 Apr 2016 18:15:29 -0700 (PDT) Received: by 10.25.21.105 with HTTP; Thu, 21 Apr 2016 18:15:29 -0700 (PDT) In-Reply-To: <57193FCF.4000400@gmail.com> References: <74b2701c9b10416cbd2c8043e33596f1@XCH-RCD-006.cisco.com> <57178F54.5030406@joelhalpern.com> <57193FCF.4000400@gmail.com> Date: Thu, 21 Apr 2016 18:15:29 -0700 Message-ID: From: John Strassner To: Brian E Carpenter , John Strassner Content-Type: multipart/alternative; boundary=001a113a9bba05829005310890a6 Archived-At: Cc: "Joel M. Halpern" , "Michael Behringer \(mbehring\)" , Anima WG Subject: Re: [Anima] Intent "beginning to end" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 22 Apr 2016 01:15:33 -0000 --001a113a9bba05829005310890a6 Content-Type: text/plain; charset=UTF-8 ... >> 3) I believe that interpreting/compiling intent will be HARD, and >> that understanding intent will be MUCH HARDER. Why does >> every autonomic node need to do that? > Surely that depends on the detailed design of Intent syntax and > semantics, by which I mean the Intent that is distributed to all > autonomic nodes and hence to all ASAs. I disagree. Look at the programming world. Visual Basic is much more used and popular than other languages that are more * (insert whatever you'd like - elegant, concise, extensible, performant, ...). Even for my personal favorite (Prolog), there are differences between ISO and Edinburgh Prolog as well as differences in implementations. The fact that we are defining this to address the business user (at least in part) makes it that much harder. We could never agree on CLI - and we knew what we were doing in CLI. MIBs were worse. Sorry, but based on this, I have no confidence whatsoever we will agree on a standard high-level language that is declarative in nature. Furthermore, even if we could accomplish a miracle and do this, I still don't understand why EVERY node has to have this function. Look at DiffServ - one Carrier uses AF4x, another uses AF3x, a third might use CS4 or CS5. Nodes don't know how to do this mapping - something else (typically a human) does. > Given that we know it needs to be interpreted by individual > ASAs, shouldn't we design it to be readily interpreted? Of course. The problem is, no such proposal, or even spec, exists. I've spent over a year in the ONF discussing a white paper that still is having problems defining precisely what intent is. Same in the TMF. The only working examples that one could argue are declarative (OpenStack Congress and ODL GBP) that I am familiar with are nowhere close to being able to be consumed by a business user. Even good application developers have trouble with them. ... > An ASA that manages resource X, which involves negotiation with > other ASAs also managing resource X, and setting configuration for > itself and perhaps for subsidiary non-autonomic devices using > resource X, will need to interpret statements about settings the > affect resource X, as well as statements about generic settings. > So they need to be readily interpretable. Not necessarily. Take any of Joel's or my examples - how does an ASA know what Platinum Service is for ONE Carrier, let alone many? Wouldn't it be (much) simpler to offload this to a specialized ASA that had the processing power, as well as access to other resources (e.g., ontologies, FOL processing, computational linguistics) to do the transformation? Then, once the intent is translated to a form that the ASA can understand, it can proceed while needing much less resources and processing power. regards, John On Thu, Apr 21, 2016 at 2:02 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 22/04/2016 08:46, John Strassner wrote: > ... > > 3) I believe that interpreting/compiling intent will be HARD, and > > that understanding intent will be MUCH HARDER. Why does > > every autonomic node need to do that? > > Surely that depends on the detailed design of Intent syntax and semantics, > by which I mean the Intent that is distributed to all autonomic nodes > and hence to all ASAs. Given that we know it needs to be interpreted by > individual ASAs, shouldn't we design it to be readily interpreted? > (If there is some more abstract format of Intent that is *not* distributed > everywhere, that's fine, but it's not our concern for designing Anima. > We have to worry about the concrete Intent that's sent to all AN nodes.) > > An ASA that manages resource X, which involves negotiation with other > ASAs also managing resource X, and setting configuration for itself and > perhaps for subsidiary non-autonomic devices using resource X, will need > to interpret statements about settings the affect resource X, as well as > statements about generic settings. So they need to be readily > interpretable. > > Brian > -- regards, John --001a113a9bba05829005310890a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

...
>>=C2=A0 3) I believe that interpreting/co= mpiling intent will be HARD, and
>>=C2=A0=C2=A0=C2=A0=C2=A0 that u= nderstanding intent will be MUCH HARDER. Why does
>>=C2=A0=C2=A0= =C2=A0=C2=A0 every autonomic node need to do that?

> Surely that d= epends on the detailed design of Intent syntax and
> semantics, by wh= ich I mean the Intent that is distributed to all
> autonomic nodes an= d hence to all ASAs.

I disagree. Look at the programming world. Vis= ual Basic is much
more used and popular than other languages that are mo= re * (insert
whatever you'd like - elegant, concise, extensible, per= formant, ...).
Even for my personal favorite (Prolog), there are differe= nces
between ISO and Edinburgh Prolog as well as differences in
implementations.

The fact that we are defining this to add= ress the business user (at
least in part) makes it that much harder. We = could never agree on
CLI - and we knew what we were doing in CLI. MIBs w= ere worse. Sorry,
but based on this, I have no confidence whatsoever we = will agree on a
standard high-level language that is declarative in natu= re.

Furthermore, even if we could accomplish a miracle and do this,= I
still don't understand why EVERY node has to have this function.<= br>Look at DiffServ - one Carrier uses AF4x, another uses AF3x, a
third = might use CS4 or CS5. Nodes don't know how to do this
mapping= - something else (typically a human) does.

> Given that we know= it needs to be interpreted by individual
> ASAs, shouldn't we de= sign it to be readily interpreted?

Of course. The problem is, no such= proposal, or even spec, exists.
I've spent over a year in the ONF d= iscussing a white paper that
still is having problems defining precisely= what intent is. Same
in the TMF. The only working examples that one cou= ld argue are
declarative (OpenStack Congress and ODL GBP) that I am fami= liar
with are nowhere close to being able to be consumed by a businessuser. Even good application developers have trouble with them.

...<= /p>

> An ASA that manages resource X, which involves negotiation with<= br>> other ASAs also managing resource X, and setting configuration for<= br>> itself and perhaps for subsidiary non-autonomic devices using
&g= t; resource X, will need to interpret statements about settings the
>= affect resource X, as well as statements about generic settings.
> S= o they need to be readily interpretable.

Not necessarily. Take any of= Joel's or my examples - how does an
ASA know what Platinum Service = is for ONE Carrier, let alone many?
Wouldn't it be (much) simpler to= offload this to a specialized ASA
that had the processing power, as wel= l as access to other resources
(e.g., ontologies, FOL processing, comput= ational linguistics) to
do the transformation? Then, once the intent is = translated to a form
that the ASA can understand, it can proceed while n= eeding much less
resources and processing power.


regards,
J= ohn


On T= hu, Apr 21, 2016 at 2:02 PM, Brian E Carpenter <brian.e.carpente= r@gmail.com> wrote:
On 22/0= 4/2016 08:46, John Strassner wrote:
...
>=C2=A0 =C2=A0 3) I believe that interpreting/compiling intent will be H= ARD, and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 that understanding intent will be MUCH HARD= ER. Why does
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 every autonomic node need to do that?

Surely that depends on the detailed design of Intent syntax and semantics,<= br> by which I mean the Intent that is distributed to all autonomic nodes
and hence to all ASAs. Given that we know it needs to be interpreted by
individual ASAs, shouldn't we design it to be readily interpreted?
(If there is some more abstract format of Intent that is *not* distributed<= br> everywhere, that's fine, but it's not our concern for designing Ani= ma.
We have to worry about the concrete Intent that's sent to all AN nodes.= )

An ASA that manages resource X, which involves negotiation with other
ASAs also managing resource X, and setting configuration for itself and
perhaps for subsidiary non-autonomic devices using resource X, will need to interpret statements about settings the affect resource X, as well as statements about generic settings. So they need to be readily interpretable= .

=C2=A0 =C2=A0 Brian



--
regards,
John
--001a113a9bba05829005310890a6-- From nobody Thu Apr 21 18:20:10 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C3012D81B for ; Thu, 21 Apr 2016 18:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 1IzTt9T7r7IE for ; Thu, 21 Apr 2016 18:20:06 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 4097612DB11 for ; Thu, 21 Apr 2016 18:20:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 0511C1C043C; Thu, 21 Apr 2016 18:20:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1461288006; bh=Lk21C8SmqBNfKHfHlri67CcsTAOsqkMvlqC44ndbmQA=; h=Date:Subject:From:To:Cc:From; b=cSq6T6hyfVKxQ0CmQb3Tyd61yAbqHjrN/FOWmSVwG7szYtogL04kJU6yVw/zJCvMx 5diDQQBgX9B7dEL0Cb0q+cKWYDk8Oblwng+SltBK/kYi5VwAvkJM7HMyx/63TT5fe+ zXyFtbgZo68ixHboaZK/k6G2krdOhP/dxTrcoc2I= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.23.39.47] (unknown [166.170.28.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 17AD01C0252; Thu, 21 Apr 2016 18:20:04 -0700 (PDT) Date: Thu, 21 Apr 2016 21:20:01 -0400 Message-ID: Importance: normal From: "jmh.direct" To: Brian E Carpenter , John Strassner , "Joel M. Halpern" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_41558931178530" Archived-At: Cc: "Michael Behringer \(mbehring\)" , Anima WG Subject: Re: [Anima] Intent "beginning to end" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 22 Apr 2016 01:20:07 -0000 ----_com.samsung.android.email_41558931178530 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 UmVhc29uYWJsZSwgYnV0IEkgd2FzIHJlc3BvbmRpbmcgdG8gTWljaGFlbCBCLnMgdGFibGUsIHdo aWNoIHN0YXJ0ZWQgZnJvbSBodW1hbnMgYW5kIGhhZCBubyB0cmFuc2xhdGlvbi4KWW91cnMsSm9l bAoKClNlbnQgdmlhIHRoZSBTYW1zdW5nIEdhbGF4eSBTwq4gNiwgYW4gQVQmVCA0RyBMVEUgc21h cnRwaG9uZS0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS1Gcm9tOiBCcmlhbiBFIENh cnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPiBEYXRlOiA0LzIxLzIwMTYgIDk6 MTIgUE0gIChHTVQtMDU6MDApIFRvOiAiam1oLmRpcmVjdCIgPGptaC5kaXJlY3RAam9lbGhhbHBl cm4uY29tPiwgSm9obiBTdHJhc3NuZXIgPHN0cmF6cGRqQGdtYWlsLmNvbT4sICJKb2VsIE0uIEhh bHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPiBDYzogQW5pbWEgV0cgPGFuaW1hQGlldGYub3Jn PiwgIk1pY2hhZWwgQmVocmluZ2VyIChtYmVocmluZykiIDxtYmVocmluZ0BjaXNjby5jb20+IFN1 YmplY3Q6IFJlOiBbQW5pbWFdIEludGVudCAiYmVnaW5uaW5nIHRvIGVuZCIgCk9uIDIyLzA0LzIw MTYgMTI6MjMsIGptaC5kaXJlY3Qgd3JvdGU6Cj4gRnJvbSB3aGF0IEkgaGF2ZSBzZWVuLCBhdCB0 aGUgYnVzaW5lc3MgbGV2ZWwgdGhlIG5lZWRlZCBpbmZvcm1hdGlvbiBpcyBzcHJlYWQgYWNyb3Nz IG11bHRpcGxlIHNvdXJjZXMuwqAgU28gaWYsIGFzIGRpYWdyYW1tZWQsIEludGVudCBzdGFydHMg YXQgdGhlIGh1bWFuLCB0aGVuIHNvbWV0aGluZyBuZWVkcyB0byBjb21waWxlIGl0IHRvZ2V0aGVy LgoKQ2VydGFpbmx5LiBTbyBpbiBmYWN0IHdlIGFyZSB0YWxraW5nIGFib3V0IHR3byBkaWZmZXJl bnQgdGhpbmdzLgoKSW50ZW50IChIKTogd2hhdCBodW1hbnMgZ2VuZXJhdGUsIHRoYXQgbXVzdCBi ZSBzYW5pdHkgY2hlY2tlZCwgcmVjb25jaWxlZCwgYW5kIGNvbXBpbGVkIGludG8KSW50ZW50IChB KTogYSBjb25zaXN0ZW50IGZvcm0gb2YgSW50ZW50IHRoYXQgY2FuIGJlIGludGVycHJldGVkIGJ5 IGFuIGFsZ29yaXRobSBpbiBhbnkgYXV0b25vbWljIG5vZGUuCgpJIGJlbGlldmUgdGhhdCBBbmlt YSBzaG91bGQgZm9jdXMgb24gSW50ZW50IChBKS4KCsKgwqAgQnJpYW4KCj4gWW91cnMsSm9lbAo+ IAo+IAo+IFNlbnQgdmlhIHRoZSBTYW1zdW5nIEdhbGF4eSBTwq4gNiwgYW4gQVQmVCA0RyBMVEUg c21hcnRwaG9uZS0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS1Gcm9tOiBCcmlhbiBF IENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPiBEYXRlOiA0LzIxLzIwMTbC oCA1OjAyIFBNwqAgKEdNVC0wNTowMCkgVG86IEpvaG4gU3RyYXNzbmVyIDxzdHJhenBkakBnbWFp bC5jb20+LCAiSm9lbCBNLiBIYWxwZXJuIiA8am1oQGpvZWxoYWxwZXJuLmNvbT4gQ2M6IEFuaW1h IFdHIDxhbmltYUBpZXRmLm9yZz4sICJNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpIiA8bWJl aHJpbmdAY2lzY28uY29tPiBTdWJqZWN0OiBSZTogW0FuaW1hXSBJbnRlbnQgImJlZ2lubmluZyB0 byBlbmQiIAo+IE9uIDIyLzA0LzIwMTYgMDg6NDYsIEpvaG4gU3RyYXNzbmVyIHdyb3RlOgo+IC4u Lgo+PsKgwqDCoMKgIDMpIEkgYmVsaWV2ZSB0aGF0IGludGVycHJldGluZy9jb21waWxpbmcgaW50 ZW50IHdpbGwgYmUgSEFSRCwgYW5kCj4+wqDCoMKgwqDCoMKgwqDCoCB0aGF0IHVuZGVyc3RhbmRp bmcgaW50ZW50IHdpbGwgYmUgTVVDSCBIQVJERVIuIFdoeSBkb2VzCj4+wqDCoMKgwqDCoMKgwqDC oCBldmVyeSBhdXRvbm9taWMgbm9kZSBuZWVkIHRvIGRvIHRoYXQ/Cj4gCj4gU3VyZWx5IHRoYXQg ZGVwZW5kcyBvbiB0aGUgZGV0YWlsZWQgZGVzaWduIG9mIEludGVudCBzeW50YXggYW5kIHNlbWFu dGljcywKPiBieSB3aGljaCBJIG1lYW4gdGhlIEludGVudCB0aGF0IGlzIGRpc3RyaWJ1dGVkIHRv IGFsbCBhdXRvbm9taWMgbm9kZXMKPiBhbmQgaGVuY2UgdG8gYWxsIEFTQXMuIEdpdmVuIHRoYXQg d2Uga25vdyBpdCBuZWVkcyB0byBiZSBpbnRlcnByZXRlZCBieQo+IGluZGl2aWR1YWwgQVNBcywg c2hvdWxkbid0IHdlIGRlc2lnbiBpdCB0byBiZSByZWFkaWx5IGludGVycHJldGVkPwo+IChJZiB0 aGVyZSBpcyBzb21lIG1vcmUgYWJzdHJhY3QgZm9ybWF0IG9mIEludGVudCB0aGF0IGlzICpub3Qq IGRpc3RyaWJ1dGVkCj4gZXZlcnl3aGVyZSwgdGhhdCdzIGZpbmUsIGJ1dCBpdCdzIG5vdCBvdXIg Y29uY2VybiBmb3IgZGVzaWduaW5nIEFuaW1hLgo+IFdlIGhhdmUgdG8gd29ycnkgYWJvdXQgdGhl IGNvbmNyZXRlIEludGVudCB0aGF0J3Mgc2VudCB0byBhbGwgQU4gbm9kZXMuKQo+IAo+IEFuIEFT QSB0aGF0IG1hbmFnZXMgcmVzb3VyY2UgWCwgd2hpY2ggaW52b2x2ZXMgbmVnb3RpYXRpb24gd2l0 aCBvdGhlcgo+IEFTQXMgYWxzbyBtYW5hZ2luZyByZXNvdXJjZSBYLCBhbmQgc2V0dGluZyBjb25m aWd1cmF0aW9uIGZvciBpdHNlbGYgYW5kCj4gcGVyaGFwcyBmb3Igc3Vic2lkaWFyeSBub24tYXV0 b25vbWljIGRldmljZXMgdXNpbmcgcmVzb3VyY2UgWCwgd2lsbCBuZWVkCj4gdG8gaW50ZXJwcmV0 IHN0YXRlbWVudHMgYWJvdXQgc2V0dGluZ3MgdGhlIGFmZmVjdCByZXNvdXJjZSBYLCBhcyB3ZWxs IGFzCj4gc3RhdGVtZW50cyBhYm91dCBnZW5lcmljIHNldHRpbmdzLiBTbyB0aGV5IG5lZWQgdG8g YmUgcmVhZGlseSBpbnRlcnByZXRhYmxlLgo+IAo+wqDCoMKgwqAgQnJpYW4KPiAKCg== ----_com.samsung.android.email_41558931178530 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PlJlYXNvbmFibGUsIGJ1dCBJ IHdhcyByZXNwb25kaW5nIHRvIE1pY2hhZWwgQi5zIHRhYmxlLCB3aGljaCBzdGFydGVkIGZyb20g aHVtYW5zIGFuZCBoYWQgbm8gdHJhbnNsYXRpb24uPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5Z b3Vycyw8L2Rpdj48ZGl2PkpvZWw8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48 ZGl2Pjxicj48L2Rpdj48ZGl2IGlkPSJjb21wb3Nlcl9zaWduYXR1cmUiPjxkaXYgc3R5bGU9ImZv bnQtc2l6ZTo4NSU7Y29sb3I6IzU3NTc1NyI+U2VudCB2aWEgdGhlIFNhbXN1bmcgR2FsYXh5IFPC riA2LCBhbiBBVCZhbXA7VCA0RyBMVEUgc21hcnRwaG9uZTwvZGl2PjwvZGl2PjxkaXYgc3R5bGU9 ImZvbnQtc2l6ZToxMDAlO2NvbG9yOiMwMDAwMDAiPjwhLS0gb3JpZ2luYWxNZXNzYWdlIC0tPjxk aXY+LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLTwvZGl2PjxkaXY+RnJvbTogQnJp YW4gRSBDYXJwZW50ZXIgJmx0O2JyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbSZndDsgPC9kaXY+ PGRpdj5EYXRlOiA0LzIxLzIwMTYgIDk6MTIgUE0gIChHTVQtMDU6MDApIDwvZGl2PjxkaXY+VG86 ICJqbWguZGlyZWN0IiAmbHQ7am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb20mZ3Q7LCBKb2huIFN0 cmFzc25lciAmbHQ7c3RyYXpwZGpAZ21haWwuY29tJmd0OywgIkpvZWwgTS4gSGFscGVybiIgJmx0 O2ptaEBqb2VsaGFscGVybi5jb20mZ3Q7IDwvZGl2PjxkaXY+Q2M6IEFuaW1hIFdHICZsdDthbmlt YUBpZXRmLm9yZyZndDssICJNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpIiAmbHQ7bWJlaHJp bmdAY2lzY28uY29tJmd0OyA8L2Rpdj48ZGl2PlN1YmplY3Q6IFJlOiBbQW5pbWFdIEludGVudCAi YmVnaW5uaW5nIHRvIGVuZCIgPC9kaXY+PGRpdj48YnI+PC9kaXY+PC9kaXY+T24gMjIvMDQvMjAx NiAxMjoyMywgam1oLmRpcmVjdCB3cm90ZTo8YnI+Jmd0OyBGcm9tIHdoYXQgSSBoYXZlIHNlZW4s IGF0IHRoZSBidXNpbmVzcyBsZXZlbCB0aGUgbmVlZGVkIGluZm9ybWF0aW9uIGlzIHNwcmVhZCBh Y3Jvc3MgbXVsdGlwbGUgc291cmNlcy4mbmJzcDsgU28gaWYsIGFzIGRpYWdyYW1tZWQsIEludGVu dCBzdGFydHMgYXQgdGhlIGh1bWFuLCB0aGVuIHNvbWV0aGluZyBuZWVkcyB0byBjb21waWxlIGl0 IHRvZ2V0aGVyLjxicj48YnI+Q2VydGFpbmx5LiBTbyBpbiBmYWN0IHdlIGFyZSB0YWxraW5nIGFi b3V0IHR3byBkaWZmZXJlbnQgdGhpbmdzLjxicj48YnI+SW50ZW50IChIKTogd2hhdCBodW1hbnMg Z2VuZXJhdGUsIHRoYXQgbXVzdCBiZSBzYW5pdHkgY2hlY2tlZCwgcmVjb25jaWxlZCwgYW5kIGNv bXBpbGVkIGludG88YnI+SW50ZW50IChBKTogYSBjb25zaXN0ZW50IGZvcm0gb2YgSW50ZW50IHRo YXQgY2FuIGJlIGludGVycHJldGVkIGJ5IGFuIGFsZ29yaXRobSBpbiBhbnkgYXV0b25vbWljIG5v ZGUuPGJyPjxicj5JIGJlbGlldmUgdGhhdCBBbmltYSBzaG91bGQgZm9jdXMgb24gSW50ZW50IChB KS48YnI+PGJyPiZuYnNwOyZuYnNwOyBCcmlhbjxicj48YnI+Jmd0OyBZb3VycyxKb2VsPGJyPiZn dDsgPGJyPiZndDsgPGJyPiZndDsgU2VudCB2aWEgdGhlIFNhbXN1bmcgR2FsYXh5IFPCriA2LCBh biBBVCZhbXA7VCA0RyBMVEUgc21hcnRwaG9uZS0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0t LS0tLS1Gcm9tOiBCcmlhbiBFIENhcnBlbnRlciAmbHQ7YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwu Y29tJmd0OyBEYXRlOiA0LzIxLzIwMTYmbmJzcDsgNTowMiBQTSZuYnNwOyAoR01ULTA1OjAwKSBU bzogSm9obiBTdHJhc3NuZXIgJmx0O3N0cmF6cGRqQGdtYWlsLmNvbSZndDssICJKb2VsIE0uIEhh bHBlcm4iICZsdDtqbWhAam9lbGhhbHBlcm4uY29tJmd0OyBDYzogQW5pbWEgV0cgJmx0O2FuaW1h QGlldGYub3JnJmd0OywgIk1pY2hhZWwgQmVocmluZ2VyIChtYmVocmluZykiICZsdDttYmVocmlu Z0BjaXNjby5jb20mZ3Q7IFN1YmplY3Q6IFJlOiBbQW5pbWFdIEludGVudCAiYmVnaW5uaW5nIHRv IGVuZCIgPGJyPiZndDsgT24gMjIvMDQvMjAxNiAwODo0NiwgSm9obiBTdHJhc3NuZXIgd3JvdGU6 PGJyPiZndDsgLi4uPGJyPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDMpIEkgYmVs aWV2ZSB0aGF0IGludGVycHJldGluZy9jb21waWxpbmcgaW50ZW50IHdpbGwgYmUgSEFSRCwgYW5k PGJyPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHRoYXQgdW5kZXJzdGFuZGluZyBpbnRlbnQgd2lsbCBiZSBNVUNIIEhBUkRFUi4gV2h5IGRv ZXM8YnI+Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgZXZlcnkgYXV0b25vbWljIG5vZGUgbmVlZCB0byBkbyB0aGF0Pzxicj4mZ3Q7IDxicj4m Z3Q7IFN1cmVseSB0aGF0IGRlcGVuZHMgb24gdGhlIGRldGFpbGVkIGRlc2lnbiBvZiBJbnRlbnQg c3ludGF4IGFuZCBzZW1hbnRpY3MsPGJyPiZndDsgYnkgd2hpY2ggSSBtZWFuIHRoZSBJbnRlbnQg dGhhdCBpcyBkaXN0cmlidXRlZCB0byBhbGwgYXV0b25vbWljIG5vZGVzPGJyPiZndDsgYW5kIGhl bmNlIHRvIGFsbCBBU0FzLiBHaXZlbiB0aGF0IHdlIGtub3cgaXQgbmVlZHMgdG8gYmUgaW50ZXJw cmV0ZWQgYnk8YnI+Jmd0OyBpbmRpdmlkdWFsIEFTQXMsIHNob3VsZG4ndCB3ZSBkZXNpZ24gaXQg dG8gYmUgcmVhZGlseSBpbnRlcnByZXRlZD88YnI+Jmd0OyAoSWYgdGhlcmUgaXMgc29tZSBtb3Jl IGFic3RyYWN0IGZvcm1hdCBvZiBJbnRlbnQgdGhhdCBpcyAqbm90KiBkaXN0cmlidXRlZDxicj4m Z3Q7IGV2ZXJ5d2hlcmUsIHRoYXQncyBmaW5lLCBidXQgaXQncyBub3Qgb3VyIGNvbmNlcm4gZm9y IGRlc2lnbmluZyBBbmltYS48YnI+Jmd0OyBXZSBoYXZlIHRvIHdvcnJ5IGFib3V0IHRoZSBjb25j cmV0ZSBJbnRlbnQgdGhhdCdzIHNlbnQgdG8gYWxsIEFOIG5vZGVzLik8YnI+Jmd0OyA8YnI+Jmd0 OyBBbiBBU0EgdGhhdCBtYW5hZ2VzIHJlc291cmNlIFgsIHdoaWNoIGludm9sdmVzIG5lZ290aWF0 aW9uIHdpdGggb3RoZXI8YnI+Jmd0OyBBU0FzIGFsc28gbWFuYWdpbmcgcmVzb3VyY2UgWCwgYW5k IHNldHRpbmcgY29uZmlndXJhdGlvbiBmb3IgaXRzZWxmIGFuZDxicj4mZ3Q7IHBlcmhhcHMgZm9y IHN1YnNpZGlhcnkgbm9uLWF1dG9ub21pYyBkZXZpY2VzIHVzaW5nIHJlc291cmNlIFgsIHdpbGwg bmVlZDxicj4mZ3Q7IHRvIGludGVycHJldCBzdGF0ZW1lbnRzIGFib3V0IHNldHRpbmdzIHRoZSBh ZmZlY3QgcmVzb3VyY2UgWCwgYXMgd2VsbCBhczxicj4mZ3Q7IHN0YXRlbWVudHMgYWJvdXQgZ2Vu ZXJpYyBzZXR0aW5ncy4gU28gdGhleSBuZWVkIHRvIGJlIHJlYWRpbHkgaW50ZXJwcmV0YWJsZS48 YnI+Jmd0OyA8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBCcmlhbjxicj4mZ3Q7IDxi cj48YnI+PC9ib2R5PjwvaHRtbD4= ----_com.samsung.android.email_41558931178530-- From nobody Thu Apr 21 18:25:39 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E922812EC0B for ; Thu, 21 Apr 2016 18:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 TUsqx6U-XvS5 for ; Thu, 21 Apr 2016 18:25:36 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2524812EC18 for ; Thu, 21 Apr 2016 18:25:35 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id c126so70886368lfb.2 for ; Thu, 21 Apr 2016 18:25:35 -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; bh=KnlVsfJh2hRUYUdn8U+J61R+D6iggAp4ncr6ral8snA=; b=XWgIdm03Ib3+xDfIr6s4aaTc4Ne7oAQfto+2clWGbheMqyCjMpAHUkpnywnmyyyIpy NhCgVLl8bO9Gd2jzqoMKrpSl9U9oPBTcK2Sd9SG3YpiuKxXoMx3M/J5RHZiTCCKMAjUn VWxGgQHQGoEQkQWcQ8OYM9QJX3tHikwN8IdlVAj28GNww1+34zfhFZ5qH6XyU/Sf7nmD Tpr+x+qrNbtSz8mtAJXykpuYnbvwvBPLA9LbtPncBq7vhUZ5ivo6ehVWi5OtW124FIkK n2dlCvYnJAuTFPhLmLcdjYVLvR29NDmSp0gbxK1O8jIV0TpDdD6ZdDrxq+yj+BG4mhfP 1/Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=KnlVsfJh2hRUYUdn8U+J61R+D6iggAp4ncr6ral8snA=; b=VYMJNmVus5raG9vr3xnosFslmjPcwtMtBPO96d2xNZOqEpi1ZymWaEUZ6STukB8nyB 0dVIJJkFC2xyyWP5vMhpz5XKxPjTtDz5/nRQifoA7JAeEkBo7wf14nlbHoNK/T/k4oth +nEn5uKbt/F+DGBpdjMVuW1JdjtnzhkRa6Agm0KUWdeCS4/+4Rps1ZBe3cmcM3L2xshf p+MUo/q7NRDOUG1Ww1ufh2E01cxjmwnjwuCQ8nFLULiPQdG4FyLItP8O36/xmBU08IDw mzjM8E4ep1TjX2egqekDz0gCS+qXlB7m/CPzgbYqzdrUMaeB2/u76rUKvqviSmsp07S1 dDKQ== X-Gm-Message-State: AOPr4FUxkvZie0YY//ONg2M91TgDUNTANP1QK80Pa67bkt56JXZRi6pXxNeZtpemZpcGPWZbw2WLg5nr/r6BjA== MIME-Version: 1.0 X-Received: by 10.25.216.106 with SMTP id p103mr946883lfg.16.1461288333376; Thu, 21 Apr 2016 18:25:33 -0700 (PDT) Received: by 10.25.21.105 with HTTP; Thu, 21 Apr 2016 18:25:33 -0700 (PDT) In-Reply-To: <57197A8D.1000306@gmail.com> References: <57197A8D.1000306@gmail.com> Date: Thu, 21 Apr 2016 18:25:33 -0700 Message-ID: From: John Strassner To: Brian E Carpenter , John Strassner Content-Type: multipart/alternative; boundary=001a1140d0ca0684cd053108b4ad Archived-At: Cc: "jmh.direct" , "Joel M. Halpern" , "Michael Behringer \(mbehring\)" , Anima WG Subject: Re: [Anima] Intent "beginning to end" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 22 Apr 2016 01:25:38 -0000 --001a1140d0ca0684cd053108b4ad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > Intent (H): what humans generate, that must be sanity checked, > reconciled, and compiled into > Intent (A): a consistent form of Intent that can be interpreted > by an algorithm in any autonomic node. When I read draft draft-du-anima-an-intent-03, I got the impression that both Intent (H) and Intent (A) were worked on in the policy system. Even if this is not the case, clearly nodes that are not fully autonomic will not be interested in adding additional resources to understand and act on intent. My problem is that I do not believe that we can define a mechanism to specify Intent (A) in a vendor-independent, interoperable manner. Hence, I see no reason why **every** mode MUST be able to ingest and act on intent. regards, John On Thu, Apr 21, 2016 at 6:12 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 22/04/2016 12:23, jmh.direct wrote: > > From what I have seen, at the business level the needed information is > spread across multiple sources. So if, as diagrammed, Intent starts at t= he > human, then something needs to compile it together. > > Certainly. So in fact we are talking about two different things. > > Intent (H): what humans generate, that must be sanity checked, reconciled= , > and compiled into > Intent (A): a consistent form of Intent that can be interpreted by an > algorithm in any autonomic node. > > I believe that Anima should focus on Intent (A). > > Brian > > > Yours,Joel > > > > > > Sent via the Samsung Galaxy S=C2=AE 6, an AT&T 4G LTE smartphone-------= - > Original message --------From: Brian E Carpenter < > brian.e.carpenter@gmail.com> Date: 4/21/2016 5:02 PM (GMT-05:00) To: > John Strassner , "Joel M. Halpern" < > jmh@joelhalpern.com> Cc: Anima WG , "Michael Behringer > (mbehring)" Subject: Re: [Anima] Intent "beginning > to end" > > On 22/04/2016 08:46, John Strassner wrote: > > ... > >> 3) I believe that interpreting/compiling intent will be HARD, and > >> that understanding intent will be MUCH HARDER. Why does > >> every autonomic node need to do that? > > > > Surely that depends on the detailed design of Intent syntax and > semantics, > > by which I mean the Intent that is distributed to all autonomic nodes > > and hence to all ASAs. Given that we know it needs to be interpreted by > > individual ASAs, shouldn't we design it to be readily interpreted? > > (If there is some more abstract format of Intent that is *not* > distributed > > everywhere, that's fine, but it's not our concern for designing Anima. > > We have to worry about the concrete Intent that's sent to all AN nodes.= ) > > > > An ASA that manages resource X, which involves negotiation with other > > ASAs also managing resource X, and setting configuration for itself and > > perhaps for subsidiary non-autonomic devices using resource X, will nee= d > > to interpret statements about settings the affect resource X, as well a= s > > statements about generic settings. So they need to be readily > interpretable. > > > > Brian > > > > --=20 regards, John --001a1140d0ca0684cd053108b4ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

> Intent (H): what humans generate, that must be san= ity checked,
> reconciled, and compiled into
> Intent (A): a co= nsistent form of Intent that can be interpreted
> by an algorithm in = any autonomic node.

When I read draft draft-du-anima-an-intent-03, I = got the impression
that both Intent (H) and Intent (A) were worked on in= the policy
system. Even if this is not the case, clearly nodes that are= not
fully autonomic will not be interested in adding additional
reso= urces to understand and act on intent.

My problem is that I do not be= lieve that we can define a mechanism
to specify Intent (A) in a vendor-i= ndependent, interoperable manner.
Hence, I see no reason why **every** m= ode MUST be able to ingest
and act on intent.

regards,
John

=

On Thu, Apr= 21, 2016 at 6:12 PM, Brian E Carpenter <brian.e.carpenter@gmail= .com> wrote:
On 22/04/2016 = 12:23, jmh.direct wrote:
> From what I have seen, at the business level the needed information is= spread across multiple sources.=C2=A0 So if, as diagrammed, Intent starts = at the human, then something needs to compile it together.

Certainly. So in fact we are talking about two different things.

Intent (H): what humans generate, that must be sanity checked, reconciled, = and compiled into
Intent (A): a consistent form of Intent that can be interpreted by an algor= ithm in any autonomic node.

I believe that Anima should focus on Intent (A).

=C2=A0 =C2=A0Brian

> Yours,Joel
>
>
> Sent via the Samsung Galaxy S=C2=AE 6, an AT&T 4G LTE smartphone--= ------ Original message --------From: Brian E Carpenter <brian.e.carpenter@gmail.com> Date: 4= /21/2016=C2=A0 5:02 PM=C2=A0 (GMT-05:00) To: John Strassner <strazpdj@gmail.com>, "Joel M. Halper= n" <jmh@joelhalpern.com&= gt; Cc: Anima WG <anima@ietf.org&g= t;, "Michael Behringer (mbehring)" <mbehring@cisco.com> Subject: Re: [Anima] Intent "be= ginning to end"
> On 22/04/2016 08:46, John Strassner wrote:
> ...
>>=C2=A0 =C2=A0 =C2=A03) I believe that interpreting/compiling intent= will be HARD, and
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that understanding intent will be= MUCH HARDER. Why does
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0every autonomic node need to do t= hat?
>
> Surely that depends on the detailed design of Intent syntax and semant= ics,
> by which I mean the Intent that is distributed to all autonomic nodes<= br> > and hence to all ASAs. Given that we know it needs to be interpreted b= y
> individual ASAs, shouldn't we design it to be readily interpreted?=
> (If there is some more abstract format of Intent that is *not* distrib= uted
> everywhere, that's fine, but it's not our concern for designin= g Anima.
> We have to worry about the concrete Intent that's sent to all AN n= odes.)
>
> An ASA that manages resource X, which involves negotiation with other<= br> > ASAs also managing resource X, and setting configuration for itself an= d
> perhaps for subsidiary non-autonomic devices using resource X, will ne= ed
> to interpret statements about settings the affect resource X, as well = as
> statements about generic settings. So they need to be readily interpre= table.
>
>=C2=A0 =C2=A0 =C2=A0Brian
>




--
regards,
John
--001a1140d0ca0684cd053108b4ad-- From nobody Sat Apr 23 01:35:10 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F205612D7C3; Sat, 23 Apr 2016 01:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 wSAEMt9l-0_p; Sat, 23 Apr 2016 01:35:07 -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 48D4212D0C1; Sat, 23 Apr 2016 01:35:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CIF96956; Sat, 23 Apr 2016 08:35:03 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 23 Apr 2016 09:35:02 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Sat, 23 Apr 2016 16:34:55 +0800 From: Sheng Jiang To: "anima@ietf.org" Thread-Topic: ANIMA minutes - IETF 95 Thread-Index: AdGdOv/1IJYgGb8XQ3KebQRWDTC2+A== Date: Sat, 23 Apr 2016 08:34:54 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927C6596AD@NKGEML515-MBX.china.huawei.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.99.197] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B927C6596ADNKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.571B33B8.00BE, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7f4c0cf1f6d9199f57d656aef76800af Archived-At: Cc: "anima-chairs@ietf.org" Subject: [Anima] ANIMA minutes - IETF 95 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 23 Apr 2016 08:35:09 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B927C6596ADNKGEML515MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIGFsbCwNCg0KDQoNClRoZSBtaW51dGVzIGZvciB0aGUgQU5JTUEgc2Vzc2lvbnMgYXQgSUVU Rjk1IGluIEJ1ZW5vcyBBaXJlcyBjYW4gYmUgZm91bmQgYXQ6DQoNCg0KDQpodHRwczovL3d3dy5p ZXRmLm9yZy9wcm9jZWVkaW5ncy85NS9taW51dGVzL21pbnV0ZXMtOTUtYW5pbWENCg0KDQoNCk1h bnkgdGhhbmtzIHRvIEJpbmcgTGl1IGZvciB0YWtpbmcgbWludXRlcy4NCg0KDQoNClBsZWFzZSBz ZW5kIGFueSBjb3JyZWN0aW9ucyB0byB0aGUgY2hhaXJzLg0KDQoNCg0KQmVzdCByZWdhcmRzLA0K DQoNCg0KU2hlbmcgKyBUb2VybGVzcw0KDQo= --_000_5D36713D8A4E7348A7E10DF7437A4B927C6596ADNKGEML515MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAz IDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5v c2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7 DQoJdGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaDsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KaDENCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6Iuagh+mimCAxIENoYXIiOw0KCW1zby1tYXJnaW4tdG9w LWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToyNC4wcHQ7DQoJZm9udC1mYW1pbHk6 5a6L5L2TO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIENo YXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uMUNoYXINCgl7bXNvLXN0eWxlLW5h bWU6Iuagh+mimCAxIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1s aW5rOiLmoIfpopggMSI7DQoJZm9udC1mYW1pbHk65a6L5L2TOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7 fQ0KcC5kYXJrZ3JheSwgbGkuZGFya2dyYXksIGRpdi5kYXJrZ3JheQ0KCXttc28tc3R5bGUtbmFt ZTpkYXJrZ3JheTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNt Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLnBpcGUNCgl7bXNvLXN0 eWxlLW5hbWU6cGlwZTt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUt bmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5IVE1MQ2hhcg0KCXttc28tc3R5bGUt bmFtZToiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyI7DQoJZm9udC1mYW1pbHk65a6L5L2T O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCi8qIFBh Z2UgRGVmaW5pdGlvbnMgKi8NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgt Q04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ0ZXh0LWp1c3RpZnktdHJpbTpw dW5jdHVhdGlvbiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHByZSBzdHlsZT0ibXNv LWxpbmUtaGVpZ2h0LWFsdDoxMC44cHQ7YmFja2dyb3VuZDp3aGl0ZTt2ZXJ0aWNhbC1hbGlnbjpi YXNlbGluZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyO2Nv bG9yOmJsYWNrIj5IaSwgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0i bXNvLWxpbmUtaGVpZ2h0LWFsdDoxMC44cHQ7YmFja2dyb3VuZDp3aGl0ZTt2ZXJ0aWNhbC1hbGln bjpiYXNlbGluZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVy O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9 Im1zby1saW5lLWhlaWdodC1hbHQ6MTAuOHB0O2JhY2tncm91bmQ6d2hpdGU7dmVydGljYWwtYWxp Z246YmFzZWxpbmUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmll cjtjb2xvcjpibGFjayI+VGhlIG1pbnV0ZXMgZm9yIHRoZSBBTklNQSBzZXNzaW9ucyBhdCBJRVRG OTUgaW4gQnVlbm9zIEFpcmVzIGNhbiBiZSBmb3VuZCBhdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmUgc3R5bGU9Im1zby1saW5lLWhlaWdodC1hbHQ6MTAuOHB0O2JhY2tncm91bmQ6d2hp dGU7dmVydGljYWwtYWxpZ246YmFzZWxpbmUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w cmU+DQo8cHJlIHN0eWxlPSJtc28tbGluZS1oZWlnaHQtYWx0OjEwLjhwdDtiYWNrZ3JvdW5kOndo aXRlO3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5lIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPmh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2Nl ZWRpbmdzLzk1L21pbnV0ZXMvbWludXRlcy05NS1hbmltYTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZSBzdHlsZT0ibXNvLWxpbmUtaGVpZ2h0LWFsdDoxMC44cHQ7YmFja2dyb3VuZDp3aGl0 ZTt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmUgc3R5bGU9Im1zby1saW5lLWhlaWdodC1hbHQ6MTAuOHB0O2JhY2tncm91bmQ6d2hp dGU7dmVydGljYWwtYWxpZ246YmFzZWxpbmUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+TWFueSB0aGFua3MgdG8gQmluZyBMaXUgZm9y IHRha2luZyBtaW51dGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibXNv LWxpbmUtaGVpZ2h0LWFsdDoxMC44cHQ7YmFja2dyb3VuZDp3aGl0ZTt2ZXJ0aWNhbC1hbGlnbjpi YXNlbGluZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyO2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1z by1saW5lLWhlaWdodC1hbHQ6MTAuOHB0O2JhY2tncm91bmQ6d2hpdGU7dmVydGljYWwtYWxpZ246 YmFzZWxpbmUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllcjtj b2xvcjpibGFjayI+UGxlYXNlIHNlbmQgYW55IGNvcnJlY3Rpb25zIHRvIHRoZSBjaGFpcnMuPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtc28tbGluZS1oZWlnaHQtYWx0OjEw LjhwdDtiYWNrZ3JvdW5kOndoaXRlO3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5lIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibXNvLWxpbmUtaGVpZ2h0LWFsdDox MC44cHQ7YmFja2dyb3VuZDp3aGl0ZTt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZSI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj5CZXN0IHJl Z2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtc28tbGluZS1oZWln aHQtYWx0OjEwLjhwdDtiYWNrZ3JvdW5kOndoaXRlO3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5lIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibXNvLWxpbmUtaGVp Z2h0LWFsdDoxMC44cHQ7YmFja2dyb3VuZDp3aGl0ZTt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZSI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNr Ij5TaGVuZyAmIzQzOyBUb2VybGVzczxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5D36713D8A4E7348A7E10DF7437A4B927C6596ADNKGEML515MBXchi_-- From nobody Fri Apr 29 13:26:06 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF2012D510 for ; Fri, 29 Apr 2016 13:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 mmjP--JeoOjb for ; Fri, 29 Apr 2016 13:26:03 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0F7D12D1BF for ; Fri, 29 Apr 2016 13:26:03 -0700 (PDT) Received: by mail-pa0-x232.google.com with SMTP id zm5so55330010pac.0 for ; Fri, 29 Apr 2016 13:26:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:organization:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=LycViTIx5neerOb16VM5+twS1FpunROdRAWpFRyikjg=; b=RxFrPVdHPbrsPg4/hn6Hg1uuy+55PDSbdDuGiMR5BVtuURc9gUjw4nTyUVHsw7oaqu zbmsGnzPV5jBsdvKycgzZZffxFGCpzs5IxEIQS7D+kh8rVJBlX4es3Z7atg8WyBc8Ie0 TCt2x4K+yJAv8R5mW9+4Z6P994B4u/ME3KrQLHSsY0k+4EhttPB0kYLmtqJvDrT6Nc2V qY4iKgH7gBtuIkxFP85eGX1nK0FkvtqG5ry5Hut/zV3uXEgvMm8pxUnO862NkXFMgFwe +jgtGW9yM2sP6klze1dtO0j5tjpygHwO09WlCCZ7XUkiJf8TxAvxK2OJwN14l/s212Ic 0HUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:organization:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=LycViTIx5neerOb16VM5+twS1FpunROdRAWpFRyikjg=; b=R4VI0DxIBBmWIa3svYN0exRt4pjvaW+SsonxDu+ZzzLMrPNwiQlFaVZ+Iju7/mmDw7 xEg7yD6QvwjdMO6/TVaH9IJbRPBzWgdVg/OPuMY5hWiH7N2YUoOapiL283Tupx0wZRxC xbW3+atSH5da3vQsgA92dfGL5EDYJvvkl0Y4zamvPBWYgD+OG5HmgvaXXl+QOtOtlB/M vtiemxrLg+h/jdzgCF6DqGxYfrTA3qDteZGCGQ0XorFIM2aOCnEcesq11O7jSVUHh1xy Yt8XokkmVDsiZ/4UA7YKHukOP++OLPlH4QFwrJTNEWhH0lZxUzOq58jsYWJ6QMU8Gz+u f4Tw== X-Gm-Message-State: AOPr4FVHxRiwYrVKkFQJHVQptgZQCsy3QhY+3Hk0D9nP1UksI65rfmznzkj+5AbQa4+nJg== X-Received: by 10.66.241.73 with SMTP id wg9mr3718327pac.91.1461961563318; Fri, 29 Apr 2016 13:26:03 -0700 (PDT) Received: from ?IPv6:2406:e007:5f53:1:28cc:dc4c:9703:6781? ([2406:e007:5f53:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id d13sm25582799pfd.80.2016.04.29.13.26.01 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Apr 2016 13:26:02 -0700 (PDT) From: Brian E Carpenter To: Anima WG Organization: University of Auckland Message-ID: Date: Sat, 30 Apr 2016 08:26:13 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Proposed change to GRASP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 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, 29 Apr 2016 20:26:05 -0000 Hi, Short version: We propose that when an ASA listens for negotiation or synchronization requests, it should do so on its own transport port number rather than sharing the generic GRASP port number as currently defined. The consequence for the protocol is that discovery responses must include a complete transport address (locator+protocol+port) instead of just the locator. Long version: We want ASAs to be able to run as separate modules in user address space, as applications, rather than being bundled with the GRASP engine in kernel space. To achieve this with all ASAs listening on the same port number would require quite complicated inter-process communication between the GRASP kernel and the indvidual ASAs. The details of this would be different in each operating system. If we allow each ASA to have its own port this can be avoided, and each ASA can have its own copy of the GRASP API library if required. This will make the systems engineering of portable ASAs much easier, and will make the adaptation of the GRASP API library and the GRASP kernel to various operating systems easier too. In practice we need to indicate the protocol (TCP or UDP) as well, since dynamic ports are assigned for a specific socket and protocol. We propose to redefine the locator returned by GRASP discovery accordingly. For the IPv6 case that would give the following CDDL: locator-option /= [O_IPv6_LOCATOR, ipv6-address, transport-proto, port-number] ipv6-address = bytes .size 16 transport-proto = IPPROTO_TCP / IPPROTO_UDP IPPROTO_TCP = 6 IPPROTO_UDP = 17 port-number = 0..65535 We did consider making this optional, but that would raise interoperability issues. If an implementation does choose to use the GRASP_LISTEN_PORT for all ASAs, that could simply be returned as the port-number. Implementation note: If someone implements multiple ASAs in a common address space, they can share a unicast port and demultiplex incoming messages using other fields (the Session ID and the Objective name). This change allows them to be in separate spaces, without requiring it. When it starts up, an ASA can obtain an ephemeral port number for each transport protocol that it supports, and that will be used in discovery responses. This change has already been tested out in the prototype Python code. Comments? Note: Toerless Eckert brought up this problem and outlined the proposed solution. Joel Halpern made very helpful comments. Brian + co-authors