From nobody Tue Jul 1 00:59:53 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA9B61B27D7 for ; Tue, 1 Jul 2014 00:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.552 X-Spam-Level: X-Spam-Status: No, score=-104.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jv5Ni_EDEQ2v for ; Tue, 1 Jul 2014 00:59: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 270A61A0199 for ; Tue, 1 Jul 2014 00:59:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJL22982; Tue, 01 Jul 2014 07:59:48 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 1 Jul 2014 08:59:47 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Tue, 1 Jul 2014 15:59:40 +0800 From: Zongning To: "vnfpool@ietf.org" Thread-Topic: New Version Notification for draft-zong-vnfpool-problem-statement-06.txt Thread-Index: AQHPlQGrQpRPQUz06EagaxCLAZTnr5uK2Wng Date: Tue, 1 Jul 2014 07:59:40 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.54] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/hbNFbyZfIZo2D8BgP2gs4Z2pR5M Subject: [vnfpool] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g?= =?utf-8?q?for_draft-zong-vnfpool-problem-statement-06=2Etxt?= X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 07:59:52 -0000 SGksIGFsbCwNCg0KQSBuZXcgcmV2aXNpb24gb2YgVk5GIFBvb2wgUHJvYmxlbSBTdGF0ZW1lbnQg SS1EIGhhcyBiZWVuIHN1Ym1pdHRlZDoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LXpvbmctdm5mcG9vbC1wcm9ibGVtLXN0YXRlbWVudC0wNi50eHQNCg0KV2UganVz dCBkaWQgb25seSBhIGZldyB1cGRhdGVzIHRvIGFsaWduZWQgaXQgd2l0aCB0aGUgY2hhbmdlcyBz dWdnZXN0ZWQgZHVyaW5nIG91ciBjaGFydGVyIGRpc2N1c3Npb24uDQoNCkZ1cnRoZXIgY29tbWVu dHMgJiBzdWdnZXN0aW9ucyBhcmUgYWx3YXlzIHdlbGNvbWUhDQoNClRoYW5rcy4NCg0KLU5pbmcN Cg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0K5Y+R6YCB5pe26Ze0OiAy MDE05bm0N+aciDHml6UgMTU6NTQNCuaUtuS7tuS6ujogR2Vvcmdpb3MgS2FyYWdpYW5uaXM7IFpv bmduaW5nOyBMaW5kYSBEdW5iYXI7IE1lbGluZGEgU2hvcmU7IExpbmRhIER1bmJhcjsgTWVsaW5k YSBTaG9yZTsgRGllZ28gTG9wZXo7IERpZWdvIFIuIExvcGV6OyBab25nbmluZzsgR2Vvcmdpb3Mg S2FyYWdpYW5uaXMNCuS4u+mimDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC16 b25nLXZuZnBvb2wtcHJvYmxlbS1zdGF0ZW1lbnQtMDYudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LXpvbmctdm5mcG9vbC1wcm9ibGVtLXN0YXRlbWVudC0wNi50eHQNCmhhcyBi ZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTmluZyBab25nIGFuZCBwb3N0ZWQgdG8gdGhl IElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LXpvbmctdm5mcG9vbC1wcm9ibGVtLXN0 YXRlbWVudA0KUmV2aXNpb246CTA2DQpUaXRsZToJCVZpcnR1YWxpemVkIE5ldHdvcmsgRnVuY3Rp b24gKFZORikgUG9vbCBQcm9ibGVtIFN0YXRlbWVudA0KRG9jdW1lbnQgZGF0ZToJMjAxNC0wNy0w MQ0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMTMNClVSTDogICAgICAg ICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC16b25nLXZuZnBv b2wtcHJvYmxlbS1zdGF0ZW1lbnQtMDYudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtem9uZy12bmZwb29sLXByb2JsZW0tc3RhdGVtZW50 Lw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpvbmct dm5mcG9vbC1wcm9ibGVtLXN0YXRlbWVudC0wNg0KRGlmZjogICAgICAgICAgIGh0dHA6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXpvbmctdm5mcG9vbC1wcm9ibGVtLXN0YXRlbWVu dC0wNg0KDQpBYnN0cmFjdDoNCiAgIE5ldHdvcmsgZnVuY3Rpb25zIGFyZSB0cmFkaXRpb25hbGx5 IGltcGxlbWVudGVkIG9uIHNwZWNpYWxpemVkDQogICBoYXJkd2FyZSByYXRoZXIgdGhhbiBvbiBn ZW5lcmFsIHB1cnBvc2Ugc2VydmVycywgYnV0IHRoZXJlIGlzIGEgY2xlYXINCiAgIHRyZW5kIHRv IGltcGxlbWVudCBhIG51bWJlciBvZiBuZXR3b3JrIGZ1bmN0aW9ucywgc3VjaCBhcyBmaXJld2Fs bCBvcg0KICAgbG9hZCBiYWxhbmNlciwgYXMgc29mdHdhcmUgb24gdmlydHVhbGl6ZWQgY29tcHV0 aW5nIHBsYXRmb3Jtcy4gIFRoZXNlDQogICB2aXJ0dWFsaXplZCBmdW5jdGlvbnMgYXJlIGNhbGxl ZCBWaXJ0dWFsaXplZCBOZXR3b3JrIEZ1bmN0aW9ucw0KICAgKFZORnMpLCB3aGljaCBjYW4gYmUg dXNlZCB0byBidWlsZCBuZXR3b3JrIHNlcnZpY2VzLiAgVGhlIHVzZSBvZiBWTkZzDQogICB0byBi dWlsZCBuZXR3b3JrIHNlcnZpY2VzIGludHJvZHVjZXMgYWRkaXRpb25hbCBjaGFsbGVuZ2VzIG9u DQogICByZWxpYWJpbGl0eSwgc3VjaCBhcyBhZGRpdGlvbmFsIHBvaW50cyBvZiBmYWlsdXJlIGFu ZCB0aGUgbmVlZCB0bw0KICAgY29vcmRpbmF0ZSB2YXJpb3VzIFZORnMuDQoNCiAgIFRoaXMgZG9j dW1lbnQgaW50cm9kdWNlcyBhIGdlbmVyYWwgaWRlYSBvZiBWTkYgUG9vbCB0byBzdXBwb3J0DQog ICByZWxpYWJsZSBmdW5jdGlvbiBwcm92aXNpb24gYnkgdGhlIFZORnMuICBXZSB0aGVuIGhpZ2hs aWdodCB0aGUNCiAgIHJlbGlhYmlsaXR5IGNoYWxsZW5nZXMgYW5kIGlzc3VlcyB3aGVuIHVzaW5n IHRoZSBWTkZzIHRvIGJ1aWxkDQogICBzZXJ2aWNlcy4gIFJlbGF0ZWQgSUVURiB3b3JrcyBhcmUg YWxzbyBicmllZmx5IGRlc2NyaWJlZC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoN ClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo ZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQN Cg0K From nobody Tue Jul 1 17:23:34 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269A41A0ADA for ; Tue, 1 Jul 2014 17:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.851 X-Spam-Level: X-Spam-Status: No, score=-104.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aP7Bjsk-qeOt for ; Tue, 1 Jul 2014 17:23: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 DD1541A0AFF for ; Tue, 1 Jul 2014 17:23:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJL93937; Wed, 02 Jul 2014 00:23:29 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 2 Jul 2014 01:23:27 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Wed, 2 Jul 2014 08:23:24 +0800 From: Zongning To: "vnfpool@ietf.org" Thread-Topic: IETF final agenda posted Thread-Index: Ac+Vi9Vjka0hfV7LS/ek6HSeDJbl0w== Date: Wed, 2 Jul 2014 00:23:23 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.54] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC6667796616C323nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/BtrUNCTG0FaZoJVetFU4DrOl_gM Subject: [vnfpool] IETF final agenda posted X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 00:23:33 -0000 --_000_B0D29E0424F2DE47A0B36779EC6667796616C323nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Please see below IETF 90th final agenda. VNFPool BoF is still scheduled on = Tuesday afternoon 14:20-16:20. https://datatracker.ietf.org/meeting/90/agenda.html I (for sure :)) hope that you can join VNFPool BoF, even if there is potent= ial conflict for you... Thanks. -Ning --_000_B0D29E0424F2DE47A0B36779EC6667796616C323nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Please see below IETF 90th= final agenda. VNFPool BoF is still scheduled on Tuesday afternoon 14= :20-16:20.

https://datatracker.ietf.org/meeting/90/ag= enda.html

 

I (for sure J) h= ope that you can join VNFPool BoF, even if there is potential conflict for = you…

 

Thanks.

 

-Ning

 

--_000_B0D29E0424F2DE47A0B36779EC6667796616C323nkgeml501mbschi_-- From nobody Wed Jul 2 01:05:46 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0EF1B27C5 for ; Wed, 2 Jul 2014 01:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.551 X-Spam-Level: X-Spam-Status: No, score=-104.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u_OEKHAuXMh7 for ; Wed, 2 Jul 2014 01:05:40 -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 A70E71B27C0 for ; Wed, 2 Jul 2014 01:05:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGS01757; Wed, 02 Jul 2014 08:05:37 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 2 Jul 2014 09:05:35 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Wed, 2 Jul 2014 16:05:23 +0800 From: Zongning To: Linda Dunbar , LAC Chidung Thread-Topic: =?utf-8?B?W3ZuZnBvb2xdIOetlOWkjTog562U5aSNOiAg562U5aSNOiBVcGRhdGVkIFZO?= =?utf-8?Q?FPool_Charter?= Thread-Index: AQHPlLmMoovlimQrt0qIovtCAilhLZuMarlQ Date: Wed, 2 Jul 2014 08:05:22 +0000 Message-ID: References: <53A1C0E0.1090301@orange.com> <53AC33C8.9060700@orange.com> <53AD382A.5050009@orange.com> <4A95BA014132FF49AE685FAB4B9F17F645D6F39C@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D6F39C@dfweml701-chm.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.54] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC6667796616C55Fnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/Dka4FA97m0jEKitqiSFwDXlIbWw Cc: "vnfpool@ietf.org" Subject: [vnfpool] =?utf-8?b?562U5aSNOiAg562U5aSNOiDnrZTlpI06ICDnrZTlpI06?= =?utf-8?q?_Updated_VNFPool_Charter?= X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 08:05:44 -0000 --_000_B0D29E0424F2DE47A0B36779EC6667796616C55Fnkgeml501mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIExpbmRhIGFuZCBDaGlkdW5nLA0KSeKAmWQgdGhpbmsgdGhhdCB1c3VhbGx5IGEgcG9vbCB3 b3VsZCBoYXZlIGEgY29udHJvbCBwb2ludCBpbiB0aGUgZGF0YSBwYXRoIHRvIGFsbG9jYXRlIGlu Y29taW5nIHRyYWZmaWMgdG8gZGlmZmVyZW50IHBvb2wgbWVtYmVycyB0aGF0IGJlbG9uZ3MgdG8g YSB0ZW5hbnQuIEnigJlkIGNhbGwgc3VjaCBhIGNvbnRyb2wgcG9pbnQgYSB0cmFmZmljIG1hbmFn ZXIgaW4gYSBwb29sLiBOb3RlIHRoYXQgdGhpcyB0cmFmZmljIG1hbmFnZXIgaXMgcGFydCBvZiB0 aGUgcG9vbGluZyBtZWNoYW5pc20gaXRzZWxmLCB0aHVzIGlzIG5vdCBoYW5kbGVkIGJ5IHRoZSBj b250cm9sIGVudGl0eSBvdXRzaWRlIG9mIHRoZSBwb29sLiBNb3Jlb3ZlciwgYmFzZWQgb24gb3Vy IGNoYXJ0ZXIsIHdlIGN1cnJlbnRseSBmb2N1cyBvbiB0aGUgcG9vbCBtYW5hZ2VtZW50LCBzdWNo IGFzIGluc3RhbmNlIHJlZ2lzdHJhdGlvbiwgYWN0aXZlL3N0YW5kYnkgaW5zdGFuY2Ugc2VsZWN0 aW9uLiBTbyBzdWNoIGEgdHJhZmZpYyBtYW5hZ2VyIGlzIG5vdCBvdXIgZm9jdXMgZm9yIHRoaXMg cGhhc2UuDQpUaG91Z2h0cz8NCg0KLU5pbmcNCg0K5Y+R5Lu25Lq6OiBMaW5kYSBEdW5iYXINCuWP kemAgeaXtumXtDogMjAxNOW5tDfmnIgx5pelIDc6MTgNCuaUtuS7tuS6ujogTEFDIENoaWR1bmc7 IFpvbmduaW5nDQrmioTpgIE6IHZuZnBvb2xAaWV0Zi5vcmcNCuS4u+mimDogUkU6IFt2bmZwb29s XSDnrZTlpI06IOetlOWkjTog562U5aSNOiBVcGRhdGVkIFZORlBvb2wgQ2hhcnRlcg0KDQpDaGlk dW5nLA0KQSBmZXcgcXVlc3Rpb25zIHRvIHlvdXIgYXR0YWNoZWQgZmlsZToNCg0KLSAgICAgICAg ICBBbGwgdGhlIG1vZGVscyBhc3N1bWUgdGhhdCB0aGVyZSBpcyBhIGNlbnRyYWwgTEJNIHRoYXQg dHJhZmZpYyB0cmF2ZXJzZSB0aHJvdWdoLiBJIHdvdWxkIHRoaW5rIHRoYXQgVk5GcG9vbCBkb2Vz buKAmXQgcmVxdWlyZSB0aGUgdHJhZmZpYyB0byBnbyB0aHJvdWdoIGEgc2luZ2xlIHBvaW50IG9m IExCLiBDb3JyZWN0Pw0KDQotICAgICAgICAgIDErMSBwcm90ZWN0aW9uIGNhbiBiZSB2ZXJ5IGV4 cGVuc2l2ZS4gSSB3b3VsZCB0aGluayBvbmx5IHRoZSBzdGF0ZWZ1bCBWTkYgbWlnaHQgbmVlZCAx KzEgb3IgTitLIHByb3RlY3Rpb24uIEZvciBzdGF0ZWxlc3MgVk5GLCB0aGUgTW9kZWwgMSBzaG91 bGQgYmUgdXNlZC4NCk15IHR3byBjZW50cywNCkxpbmRhDQoNCkZyb206IHZuZnBvb2wgW21haWx0 bzp2bmZwb29sLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMQUMgQ2hpZHVuZw0KU2Vu dDogRnJpZGF5LCBKdW5lIDI3LCAyMDE0IDQ6MjQgQU0NClRvOiBab25nbmluZw0KQ2M6IHZuZnBv b2xAaWV0Zi5vcmc8bWFpbHRvOnZuZnBvb2xAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3ZuZnBv b2xdIOetlOWkjTog562U5aSNOiDnrZTlpI06IFVwZGF0ZWQgVk5GUG9vbCBDaGFydGVyDQoNCkhp IE5pbmcsDQoxLSBPbiBmdXJ0aGVyIGNvbnNpZGVyYXRpb24sIG15IHJlbWFyayAoaSkgaW4gdGhl IHByZXZpb3VzIGUtbWFpbCAoIm5vIHJlZHVuZGFuY3kgYXQgYWxsIC4uLi4uIikgc2hvdWxkIG5v dCBiZSBhcHBsaWVkIGluIHRoZSBWTkYgY29udGV4dCBpZiB0aGUgaW50ZW50aW9uIGlzIHRvIHVz ZSBhIHBvb2wgZm9yIHJlZHVuZGFuY3kgcHVycG9zZXMgd2hpbGUgbWluaW1pemluZyB0aGUgbmVl ZGVkIHJlc291cmNlcy4gQXMgc2hvd24gaW4gdGhlIGZpZ3VyZSBlbmNsb3NlZCwgdGhpcyBQTkYg c2NoZW1lIChubyByZWR1bmRhbmN5IGF0IGFsbCwgaS5lLiwgYWxsIGluc3RhbmNlcyBvZiB0aGUg cG9vbCBwYXJ0aWNpcGF0ZSBhY3RpdmVseSkgaXMgbm90IGFwcGxpY2FibGUgaW4gdGhlIFZORiBm cmFtZXdvcmsgd2hlcmUgYWRkaXRpb25hbCBpbnN0YW5jZXMgYXJlIGNyZWF0ZWQgb25seSBpZiBu ZWVkZWQuDQoyLSBCYWNrIHRvIHlvdXIgZS1tYWlsIG9mIEp1bmUgMTl0aCAidGhlIFZORiBpbnN0 YW5jZSBzY2FsaW5nIHdpdGhpbiBhIFZORiBwb29sIGlzIGluY2x1ZGVkIGluIHRoZSBjaGFydGVy IjogSSBkb24ndCB0aGluayAic2NhbGluZyIsICJzY2FsYWJpbGl0eSIgYXBwZWFyaW5nIGluIHRo ZSBjaGFydGVyIC0gaXQgd291bGQgYmUgbmljZSB0byBpbnRyb2R1Y2UgYSBzZW50ZW5jZSAoc29t ZXdoZXJlKSB3aXRoIG9uZSBvZiB0aGVzZSB0d28gd29yZHMgdG8gYXZvaWQgdGhpcyBhbWJpZ3Vp dHkuIEFnYWluLCBzY2FsaW5nIGluL291dCBpcyBvbmUgbWFpbiBjaGFyYWN0ZXJpc3RpYyBvZiBW TkYuDQpCZXN0LA0KQ2hpZHVuZw0KTGUgMjcvMDYvMjAxNCAwMzozNiwgWm9uZ25pbmcgYSDDqWNy aXQgOg0KSGksIENoaWR1bmcsDQpUaGFua3MgZm9yIHlvdXIgc3VnZ2VzdGlvbnMuIEkgd2lsbCBt YWtlIHRoZSB0ZXh0IGNsZWFyIGZvciBjb21tZW50IFoyLiBCdXQgZm9yIGNvbW1lbnQgWjksIEni gJlkIHByZWZlciB0byBrZWVwIOKAnFZORiBQb29s4oCdLCBhcyB3ZSBkb27igJl0IHByb3Bvc2Uv ZGlzY3VzcyBhIGNvbmNyZXRlIFZORiBQb29sIGFyY2hpdGVjdHVyZSBpbiB0aGUgY2hhcnRlciwg YnV0IGp1c3QgaW50cm9kdWNlIGEgZ2VuZXJhbCBjb25jZXB0Lg0KTG9vayBmb3J3YXJkIHRvIHlv dXIgZnVydGhlciBjb21tZW50cy4NCi1OaW5nDQrlj5Eg5Lu25Lq6OiBMQUMgQ2hpZHVuZyBbbWFp bHRvOmNoaWR1bmcubGFjQG9yYW5nZS5jb21dDQrlj5Eg6YCB5pe26Ze0OiAyMDE05bm0NuaciDI2 5pelIDIyOjUzDQrmlLbku7bkuro6IFpvbmduaW5nDQrmioTpgIE6IHZuZnBvb2xAaWV0Zi5vcmc8 bWFpbHRvOnZuZnBvb2xAaWV0Zi5vcmc+DQrkuLvpopg6IFJlOiDnrZTlpI06IFt2bmZwb29sXSDn rZTlpI06IFVwZGF0ZWQgVk5GUG9vbCBDaGFydGVyDQoNCkhpIE5pbmcsDQpUaGFuayB5b3UgZm9y IHRoZSByZXBseS4gU29tZSBjb21tZW50cy9zdWdnZXN0aW9ucyB0byB5b3VyOg0KKiBjb21tZW50 IFoyOiBJIGtuZXcgdGhhdCB0aGUgwqsgZWxlbWVudGFyeSDCuyBORnMgYXJlIHBhcnQgb2YgdGhl IGpvYiwgYnV0IHdhbnRlZCB0byBzdWdnZXN0IHRvIGFkZCBzb21ldGhpbmcgaW4gdGhpcyBzZWN0 aW9uIHRvIGF2b2lkIHJlYWRlcnMgdG8gcGVyY2VpdmUgIHRoZSB3cm9uZyBmZWVsaW5nIG1lbnRp b25lZCBpbiBteSBjb21tZW50ICMxDQoqIGNvbW1lbnQgWjc6IFRoYW5rIHlvdSBmb3IgdGhpcyBj bGFyaWZpY2F0aW9uLiBJIHRodXMgdW5kZXJzdGFuZCB0aGF0IHRocmVlIHR5cGVzIG9mIHBvb2xz IChhbmQgbm90IG1vcmUgdGhhbiB0aHJlZSkgbWF5IGV4aXN0Og0KICAgICAtIChpKSBubyByZWR1 bmRhbmN5IGF0IGFsbCwgaS5lLiwgYWxsIGluc3RhbmNlcyBvZiB0aGUgcG9vbCBwYXJ0aWNpcGF0 ZSBhY3RpdmVseSAtIGFuIHVwc3RyZWFtIGxvYWQgYmFsYW5jaW5nIG1lY2hhbmlzbSBzaGFyZXMg dGhlIGluY29taW5nIGxvYWQgYW1vbmcgdGhlc2UgaW5zdGFuY2VzOw0KICAgICAtIChpaSkgMTox IChhY3RpdmUtYWN0aXZlKSByZWR1bmRhbmN5IC0gZm9yIGV4YW1wbGUsIDUgImltYWdlcyIgKHRv IGF2b2lkIHRoZSB3b3JkICdpbnN0YW5jZScpIG9mIHRoZSBWTkYsIGFuZCBlYWNoIG9mIHRoZW0g aXMgcmVkdW5kYW50IC0+IGluIHRoaXMgY2FzZSwgdGhlcmUgYXJlIDEwIGluc3RhbmNlcyBydW5u aW5nIGluIHBhcmFsbGVsIGluIHRoZSBwb29sOw0KICAgICAtIChpaWkpIE4rSyAoYWN0aXZlLXN0 YW5kYnkpIHJlZHVuZGFuY3kgd2hlcmUgc29tZSBpbnN0YW5jZXMgcnVuIGFjdGl2ZWx5LCB3aGls ZSBvdGhlcnMgYXJlIGluIGEgZG9ybWFudCBzdGF0ZS4NCiogY29tbWVudCBaOTogSG93IGFib3V0 IHRoaXMgYWRkLW9uIHRoZW4gPyAiLi4uIGFjaGlldmVkIGJ5IHRoZSBWTkYgUG9vbCBhcmNoaXRl Y3R1cmUgdXRpbGl6ZWQvYWRvcHRlZCBieSB0aGUgVk5GIC4uLiINCkJlc3QsDQpDaGlkdW5nDQoN CkxlIDE5LzA2LzIwMTQgMDU6MTQsIFpvbmduaW5nIGEgw6ljcml0IDoNCkhpLCBDaGlkdW5nLA0K UGxlYXNlIHNlZSBteSByZXBseSBlbmNsb3NlZCBpbiB0aGUgYXR0YWNobWVudC4gUmVnYXJkaW5n IGNvbW1lbnQjNiwgSeKAmWQgbGlrZSB0byBleHBsYWluIHRoYXQgd2UgZG9u4oCZdCByZXN0cmlj dCB0byB0aGUgY2FzZSB0aGF0IGluIGEgcG9vbCwgYXQgYSBnaXZlbiB0aW1lLCB0aGVyZSBpcyBv bmx5IG9uZSBydW5uaW5nIGluc3RhbmNlIGFuZCBhbGwgb3RoZXJzIGFyZSBzbGVlcGluZy4gQSBw b29sIHNob3VsZCBiZSBmbGV4aWJsZSB0byBoYW5kbGUgbW9yZSBjYXNlcywgaW5jbHVkaW5nIG11 bHRpcGxlIHJ1bm5pbmcgaW5zdGFuY2VzIGFuZCBtdWx0aXBsZSBzdGFuZGJ5IGluc3RhbmNlcy4N Ckxvb2sgZm9yd2FyZCB0byB5b3VyIGZ1cnRoZXIgY29tbWVudHMgJiBzdWdnZXN0aW9ucy4NCi1O aW5nDQoNCuWPkSDku7bkuro6IExBQyBDaGlkdW5nIFttYWlsdG86Y2hpZHVuZy5sYWNAb3Jhbmdl LmNvbV0NCuWPkSDpgIHml7bpl7Q6IDIwMTTlubQ25pyIMTnml6UgMDo0MA0K5pS25Lu25Lq6OiBa b25nbmluZw0K5oqE6YCBOiB2bmZwb29sQGlldGYub3JnPG1haWx0bzp2bmZwb29sQGlldGYub3Jn Pg0K5Li76aKYOiBSZTogW3ZuZnBvb2xdIOetlOWkjTogVXBkYXRlZCBWTkZQb29sIENoYXJ0ZXIN Cg0KSGkgTmluZywNCjEpIElzIGl0IGV4YWN0IHRoYXQgc2NhbGluZyBvdXQvaW4sIG9uZSBtYWlu IGNoYXJhY3RlcmlzdGljIG9mIFZORnMgKGNvbXBhcmVkIHRvIFBORnMpLCBpcyBub3QgaW5jbHVk ZWQgPw0KMikgU29tZSBjb21tZW50cy9zdWdnZXN0aW9ucyBhcmUgZW5jbG9zZWQuDQpCZXN0LA0K Q2hpZHVuZw0KTGUgMTIvMDYvMjAxNCAwNTozOCwgWm9uZ25pbmcgYSDDqWNyaXQgOg0KRGVhciBh bGwsDQpQbGVhc2UgcmV2aWV3IHRoZSBjaGFydGVyIHRleHQgaW5jbHVkZWQgaW4gdGhlIGxhc3Qg ZW1haWwuIFdlIGFyZSBob3BpbmcgdGhhdCBhIGdlbmVyYWwgY29uc2Vuc3VzIG9uIHRoZSBjaGFy dGVyIGNvdWxkIGJlIGFjaGlldmVkIG9uIHRoZSBsaXN0LCB0aGVuIGEgc3RhYmxlIGNoYXJ0ZXIg aXMgcmVhZHkgZm9yIHRoZSBWTkZQb29sIHNlc3Npb24gaW4gVG9yb250by4NClRoYW5rcy4NCi1O aW5nDQrlj5Hku7bkuro6IHZuZnBvb2wgW21haWx0bzp2bmZwb29sLWJvdW5jZXNAaWV0Zi5vcmdd IOS7oyDooaggWm9uZ25pbmcNCuWPkSDpgIHml7bpl7Q6IDIwMTTlubQ25pyIMTLml6UgMTE6MjAN CuaUtuS7tuS6ujogdm5mcG9vbEBpZXRmLm9yZzxtYWlsdG86dm5mcG9vbEBpZXRmLm9yZz4NCuS4 u+mimDogW3ZuZnBvb2xdIFVwZGF0ZWQgVk5GUG9vbCBDaGFydGVyDQoNCkRlYXIgYWxsLA0KQmFz ZWQgb24gdGhlIGxpc3QgZGlzY3Vzc2lvbiBzaW5jZSB3ZSBwb3N0ZWQgdGhlIGxhc3QgdmVyc2lv biwgSSBoYXZlIG1hZGUgc29tZSAobWlub3IpIHJldmlzaW9uIG9mIHRoZSBjaGFydGVyLiBUaGUg bWFpbiBjaGFuZ2VzIGFyZToNCg0KMSkgICAgICAgU3RhdGUgdGhhdCBzZXJ2aWNlIHN0YXRlIHN5 bmNocm9uaXphdGlvbiBpcyBvdXQgb2Ygc2NvcGUg4oCcaW4gdGhpcyBwaGFzZeKAnTsNCg0KMikg ICAgICAgSW5jbHVkZSBWTkYgUG9vbCB3aXRoIGJvdGggdmlydHVhbGl6ZWQgYW5kIG5vbi12aXJ0 dWFsaXplZCBuZXR3b3JrIGZ1bmN0aW9uIGZvciBmdXJ0aGVyIHN0dWR5Ow0KDQozKSAgICAgICBF eHBsaWNpdGx5IHN0YXRlIHRoYXQgdGhlIHJlZmVyZW5jZSBzb2x1dGlvbiAmIGdhcCBhbmFseXNp cyBpcyBub3QgbGltaXRlZCB0byBSU2VyUG9vbCwgYnV0IG9wZW4gdG8gYW55IG90aGVyIHNvbHV0 aW9ucywgYWx0aG91Z2ggbm8gZGVjaXNpb24gb24gcHJvdG9jb2xzIHdpbGwgYmUgbWFkZSBpbiB0 aGlzIHBoYXNlOw0KDQo0KSAgICAgICBTdGF0ZSB0aGF0IHRoZSBsaW5rYWdlIGJldHdlZW4gU0ZD IGFuZCBWTkYgUG9vbCBpcyBqdXN0IGxpa2UgYSBwb29sIHVzZXIgYW5kIGEgcG9vbCDigJMgbm90 aGluZyBzcGVjaWZpZWQgKHlldCk7DQoNCjUpICAgICAgIFVwZGF0ZSBidWxsZXQgIzQgdW5kZXIg 4oCcUXVlc3Rpb25zIHRoYXQgYXJlIHJhaXNlZOKApuKAnSwgdG8ga2VlcCBpdCBjb25zaXN0ZW50 IHdpdGggdGhlIGlkZWEgdGhhdCBwb29saW5nIGlzIG5vdCB2aXNpYmxlIHRvIHRoZSBzZXJ2aWNl IGNvbnRyb2wgZW50aXR5Lg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCk5ldHdvcmsgZnVuY3Rpb25zIHN1 Y2ggYXMgZmlyZXdhbGxzLCBsb2FkIGJhbGFuY2VycywgYW5kIFdBTiBvcHRpbWl6ZXJzIGFyZSBj b252ZW50aW9uYWxseSBkZXBsb3llZCBhcyBzcGVjaWFsaXplZCBoYXJkd2FyZSBzZXJ2ZXJzIGlu IGJvdGggbmV0d29yayBvcGVyYXRvcnMnIG5ldHdvcmtzIGFuZCBkYXRhIGNlbnRlciBuZXR3b3Jr cyBhcyB0aGUgYnVpbGRpbmcgYmxvY2tzIG9mIHRoZSBuZXR3b3JrIHNlcnZpY2VzLiBUaGVyZSBp cyBhIHRyZW5kIHRvIGltcGxlbWVudCBzdWNoIG5ldHdvcmsgZnVuY3Rpb25zIGFzIHNvZnR3YXJl IGluc3RhbmNlcyBydW5uaW5nIG9uIGdlbmVyYWwgcHVycG9zZSBzZXJ2ZXJzLCB2aWEgYSB2aXJ0 dWFsaXphdGlvbiBsYXllciAoaS5lLiwgaHlwZXJ2aXNvcnMpLiBUaGVzZSB2aXJ0dWFsaXplZCBm dW5jdGlvbnMgYXJlIGNhbGxlZCBWaXJ0dWFsaXplZCBOZXR3b3JrIEZ1bmN0aW9ucyAoVk5Gcyks IHdoaWNoIGNhbiBiZSB1c2VkIHRvIGJ1aWxkIG5ldHdvcmsgc2VydmljZXMuDQpUaGUgdXNlIG9m IFZORnMgaW50cm9kdWNlcyBhZGRpdGlvbmFsIGNoYWxsZW5nZXMgdG8gdGhlIHJlbGlhYmlsaXR5 IG9mIHRoZSBwcm92aWRlZCBuZXR3b3JrIHNlcnZpY2VzLiBBIHNpbmdsZSBWTkYgaW5zdGFuY2Ug d291bGQgdHlwaWNhbGx5IG5vdCBoYXZlIGJ1aWx0LWluIHJlbGlhYmlsaXR5IG1lY2hhbmlzbXMg b24gaXRzIGhvc3QgKGkuZS4sIGEgZ2VuZXJhbCBwdXJwb3NlIHNlcnZlcikuIEluc3RlYWQsIHRo ZXJlIGFyZSBtb3JlIGZhY3RvcnMgb2YgcmlzayBzdWNoIGFzIHNvZnR3YXJlIGZhaWx1cmUgYXQg dmFyaW91cyBsZXZlbHMgaW5jbHVkaW5nIGh5cGVydmlzb3JzIGFuZCB2aXJ0dWFsIG1hY2hpbmVz LCBoYXJkd2FyZSBmYWlsdXJlLCBhbmQgaW5zdGFuY2UgbWlncmF0aW9uIHRoYXQgY2FuIG1ha2Ug YSBWTkYgaW5zdGFuY2UgdW5yZWxpYWJsZS4NCkluIG9yZGVyIHRvIGFjaGlldmUgaGlnaGVyIHJl bGlhYmlsaXR5LCBhIFZORiBtYXkgYWRvcHQgYSBwb29saW5nIG1lY2hhbmlzbSwgd2hlcmUgYSBu dW1iZXIgb2YgVk5GIGluc3RhbmNlcyB3aXRoIHRoZSBzYW1lIGZ1bmN0aW9uIGNhbiBiZSBncm91 cGVkIGFzIGEgcG9vbCB0byBwcm92aWRlIHRoZSBmdW5jdGlvbi4gV2UgY2FsbCBzdWNoIGEgcG9v bCBhIFZORiBQb29sLkNvbmNlcHR1YWxseSwgYSBQb29sIE1hbmFnZXIgaXMgdXNlZCB0byBtYW5h Z2UgYSBWTkYgUG9vbCwgZS5nLiwgc2VsZWN0cyBhY3RpdmUvc3RhbmRieSBWTkYgaW5zdGFuY2Vz LCBhbmQgcG90ZW50aWFsbHkgaW50ZXJhY3RzIHdpdGggYSBzZXJ2aWNlIGNvbnRyb2wgZW50aXR5 LiBTdWNoIGEgc2VydmljZSBjb250cm9sIGVudGl0eSBpcyBhbiBlbnRpdHkgdGhhdCBvcmNoZXN0 cmF0ZXMgYSBzZXQgb2YgbmV0d29yayBmdW5jdGlvbnMgdG8gYnVpbGQgbmV0d29yayBzZXJ2aWNl cy4gVGhlIG1ham9yIGJlbmVmaXQgb2YgdXNpbmcgVk5GIFBvb2wgaXMgdGhhdCByZWxpYWJpbGl0 eSBtZWNoYW5pc21zIHN1Y2ggYXMgcmVkdW5kYW5jeSBtb2RlbCBhcmUgYWNoaWV2ZWQgYnkgdGhl IFZORiBQb29sIGluc2lkZSB0aGUgVk5GIGFuZCB0aHVzIG5vdCB2aXNpYmxlIHRvIHRoZSBzZXJ2 aWNlIGNvbnRyb2wgZW50aXR5LiBBIFZORiBQb29sLWVuYWJsZWQgVk5GIHN0aWxsIGFwcGVhcnMg YXMgYSBub3JtYWwgVk5GIHdoZW4gb3JjaGVzdHJhdGVkIGJ5IGEgc2VydmljZSBjb250cm9sIGVu dGl0eS4NClF1ZXN0aW9ucyB0aGF0IGFyZSByYWlzZWQgYnkgdGhlIGFkZGl0aW9uIG9mIGEgcG9v bGluZyBtZWNoYW5pc20gdG8gVk5GIGluY2x1ZGU6DQoNCsK3ICAgICAgICAgSG93IHRvIG1hbmFn ZSB0aGUgcmVkdW5kYW5jeSBtb2RlbCwgZS5nLiwgc2VsZWN0IGFjdGl2ZS9zdGFuZGJ5IFZORiBp bnN0YW5jZXMgaW4gYSBWTkYgUG9vbD8NCg0KwrcgICAgICAgICBXaGF0IHBvb2wgc3RhdGVzIG5l ZWQgdG8gYmUgbWFpbnRhaW5lZCB0byBzdXBwb3J0IHRoZSBwb29saW5nIG1lY2hhbmlzbSBpdHNl bGYsIGFuZCBob3cgYXJlIHN1Y2ggc3RhdGVzIG1haW50YWluZWQ/DQoNCsK3ICAgICAgICAgV2hh dCBpbmZvcm1hdGlvbiBpcyBleGNoYW5nZWQgYmV0d2VlbiBhIFZORiBhbmQgYSBzZXJ2aWNlIGNv bnRyb2wgZW50aXR5PyBGb3IgZXhhbXBsZSwgaG93IGNhbiBhIFZORiBQb29sIGJlIGFkZHJlc3Nl ZCBieSB0aGUgc2VydmljZSBjb250cm9sIGVudGl0eT8NCg0KwrcgICAgICAgICBBZnRlciBhIFZO RiBpbnN0YW5jZSBmYWlsb3ZlciwgaG93IGRvZXMgdGhlIFBvb2wgTWFuYWdlciBub3RpZnkgdGhl IHNlcnZpY2UgY29udHJvbCBlbnRpdHkgc29tZSBjaGFyYWN0ZXJpc3RpYyBjaGFuZ2VzIG9mIHRo ZSBWTkYsIGUuZy4sIGNhcGFjaXR5IGNoYW5nZSwgYnV0IHdpdGhvdXQgZGlzY2xvc3VyZSBvZiB0 aGUgcG9vbGluZyBwcm9jZWR1cmU/DQpUaGUgV0cgaW5pdGlhbGx5IGZvY3VzZXMgb24gc2V2ZXJh bCByZWxpYWJpbGl0eSBtZWNoYW5pc21zIHRoYXQgYXJlIG1haW5seSBhc3NvY2lhdGVkIHdpdGgg YSByZWR1bmRhbmN5IG1vZGVsIGJhc2VkIG9uIGEgVk5GIFBvb2wuIEFkZGl0aW9uYWwgbWVjaGFu aXNtcyBtYXkgaW5jbHVkZSBwb29sIHN0YXRlIG1haW50ZW5hbmNlIG9ubHkgZm9yIHBvb2xpbmcg cHVycG9zZS4gU2VydmljZSBzdGF0ZSBzeW5jaHJvbml6YXRpb24gaXMgb3V0IG9mIHNjb3BlIGZv ciB0aGlzIHBoYXNlLiBUaGUgV0cgYXNzdW1lcyB0aGF0IGEgVk5GIFBvb2wgY29udGFpbnMgcmVk dW5kYW50IFZORiBpbnN0YW5jZXMgb2Ygc2FtZSBmdW5jdGlvbmFsIHR5cGUuIERpZmZlcmVudCB0 eXBlcyBvZiBWTkZzIGFyZSBlbnZpc2lvbmVkIHRvIGJlIGhlbGQgaW4gc2VwYXJhdGUgVk5GIFBv b2xzLiBWTkYgUG9vbCBjb21wb3NlZCBieSBib3RoIHZpcnR1YWxpemVkIGFuZCBub24tdmlydHVh bGl6ZWQgZnVuY3Rpb25hbCBpbnN0YW5jZXMgbWF5IGJlIGluY2x1ZGVkIGFmdGVyIGZ1cnRoZXIg dXNlIGNhc2UgYW5kIHJlcXVpcmVtZW50cyBzdHVkeS4gVGhlIFdHIHdpbGwgYWRkcmVzcyB0aGUg cmVsaWFiaWxpdHkgb2YgYW4gaW5kaXZpZHVhbCBWTkYsIGJ1dCBub3QgdGhlIHJlbGlhYmlsaXR5 IHJlbGF0ZWQgdG8gdGhlIGNvbnRyb2wgb3IgdGhlIHJvdXRpbmcgYmV0d2VlbiBhZGphY2VudCBW TkZzIHRoYXQgY2FuIGZvcm0gYSBuZXR3b3JrIHNlcnZpY2UuDQpTcGVjaWZpY2FsbHksIHRoZSBX RyB3aWxsIHdvcmsgb24gdGhlIGZvbGxvd2luZyB0ZWNobmljYWwgYXNwZWN0czoNCg0KwrcgICAg ICAgICAgIFJlZHVuZGFuY3kgbWFuYWdlbWVudCB3aXRoaW4gYSBWTkYgUG9vbCwgc3VjaCBhcyB0 aGUgc2lnbmFsaW5nIGJldHdlZW4gdGhlIFBvb2wgTWFuYWdlciBhbmQgdGhlIGluc3RhbmNlcyBp biB0aGUgcG9vbCBmb3IgaW5zdGFuY2UgcmVnaXN0cmF0aW9uLCBiYWNrdXAgaW5zdGFuY2VzIHNl bGVjdGlvbiwgYW5kIHN3aXRjaGluZyBiZXR3ZWVuIGFjdGl2ZSBhbmQgc3RhbmRieSBpbnN0YW5j ZXMuDQoNCsK3ICAgICAgICAgICBUaGUgcHJvdG9jb2wgYmV0d2VlbiB0aGUgUG9vbCBNYW5hZ2Vy IGFuZCB0aGUgdW5kZXJseWluZyBuZXR3b3JrIHRvIGNvbGxlY3QgdGhlIG5ldHdvcmsgaW5mb3Jt YXRpb24gcmVxdWlyZWQgZm9yIGFwcHJvcHJpYXRlIHBsYWNlbWVudC9zZWxlY3Rpb24gb2YgYmFj a3VwIGluc3RhbmNlcy4NCg0KwrcgICAgICAgICAgIFRoZSBwcm90b2NvbCBiZXR3ZWVuIGEgVk5G IGFuZCB0aGUgc2VydmljZSBjb250cm9sIGVudGl0eSB0byBleGNoYW5nZSBvcGVyYXRpb25hbCBp bmZvcm1hdGlvbiBiZXR3ZWVuIGEgVk5GIFBvb2wgYW5kIHRoZSBzZXJ2aWNlIGNvbnRyb2wgZW50 aXR5Lg0KDQrCtyAgICAgICAgICAgSWRlbnRpZnkgYW5kIGFuYWx5emUgcmVsaWFibGUgaW50ZXJm YWNlcywgc3VjaCBhcyB0cmFuc3BvcnQgcHJvdG9jb2wgbGlrZSBNUFRDUCBhbmQgU0NUUCBmb3Ig cmVsaWFibGUgZGVsaXZlcnkgb2YgdGhlIG1lc3NhZ2VzIGFzc29jaWF0ZWQgd2l0aCB0aGUgcmVk dW5kYW5jeSBtYW5hZ2VtZW50IHdpdGhpbiBhIFZORiBQb29sLg0KDQrCtyAgICAgICAgICAgQW5h bHlzaXMgb2YgcG9vbGluZyBzZWN1cml0eSBjaGFyYWN0ZXJpc3RpY3MgYW5kIHJlcXVpcmVtZW50 cyB0byBpZGVudGlmeSBhbmQgbWl0aWdhdGUgdGhyZWF0cyBhZ2FpbnN0IHRoZSBwb29saW5nIG1l Y2hhbmlzbS4gSWRlbnRpZmljYXRpb24gb2YgYW4gYXBwcm9wcmlhdGUgdHJ1c3QgbW9kZWwgYmV0 d2VlbiBwb29sIG1lbWJlcnMsIGFuZCBiZXR3ZWVuIHBvb2wgbWVtYmVycyBhbmQgdGhlIFBvb2wg TWFuYWdlci4NClRoZSBXRyBwbGFucyB0byBkZWxpdmVyIGEgcHJvYmxlbSBzdGF0ZW1lbnQsIGEg c2V0IG9mIHVzZSBjYXNlcywgcmVxdWlyZW1lbnRzIGFuZCBhbiBhcmNoaXRlY3R1cmUgY292ZXJp bmcgdGhlIGFmb3JlbWVudGlvbmVkIHRlY2huaWNhbCBhc3BlY3RzLCBhbmQgYXBwbGljYWJpbGl0 eSBhbmQgZ2FwIGFuYWx5c2lzIG9mIGV4aXN0aW5nIHRlY2hub2xvZ2llcyBpbmNsdWRpbmcgYnV0 IG5vdCBsaW1pdGVkIHRvIFJTZXJQb29sLiBXZSB3aWxsIHJlbHkgaGVhdmlseSBvbiBleGlzdGlu ZyBJRVRGIHRlY2hub2xvZ2llcywgYnV0IHRoYXQgZ2FwcyB3aWxsIGJlIGZvdW5kIGFyb3VuZCBw cm9ibGVtcyBsaWtlIHJlZHVuZGFuY3kgbWVjaGFuaXNtcywgc3RhdGUgbWFpbnRlbmFuY2Ugc29s ZWx5IGZvciBwb29saW5nIHB1cnBvc2VzLCByZWxpYWJsZSB0cmFuc3BvcnQsIGFuZCB0cnVzdC9z ZWN1cml0eSwgYWxsIG9mIHdoaWNoIHdpbGwgbmVlZCB0byBiZSBjb25zaWRlcmVkIGFuZCBhZGRy ZXNzZWQuIEFsdGhvdWdoIG5vIGRlY2lzaW9uIG9uIHByb3RvY29scyB3aWxsIGJlIG1hZGUgaW4g dGhpcyBwaGFzZSwgd2Ugd2lsbCBrZWVwIG9wZW4gZm9yIGNhbmRpZGF0ZSBwcm90b2NvbHMgZm9y IFZORiBQb29sLiBUaGUgV0cgd2lsbCBzZWVrIHJlLWNoYXJ0ZXJpbmcgYmVmb3JlIGFkb3B0aW5n IGFueSB3b3JrIHRvIGRldmVsb3AgbmV3LCBvciBleHRlbmQgZXhpc3RpbmcsIHByb3RvY29scy4N CkluIHBhcnRpY3VsYXIsIHdlIHdpbGwgd29yayBjbG9zZWx5IHdpdGggdGhlIFNGQyBXRywgYXMg d2UgYmVsaWV2ZSB0aGF0IFNGQyBhbmQgVk5GIFBvb2wgYXJlIGluZGVwZW5kZW50IGJ1dCBjb21w bGVtZW50YXJ5LiBTRkMgd291bGQgZXNzZW50aWFsbHkgc2VlIGEgVk5GIFBvb2wtZW5hYmxlZCBW TkYgYXMgYSBub3JtYWwgc2VydmljZSBmdW5jdGlvbiBhbmQgdGhlcmVmb3JlIGJlIGFibGUgdG8g bWVyZ2UgaXQgaW50byBhbiBTRkMganVzdCBsaWtlIGFueSBvdGhlciBzZXJ2aWNlIGZ1bmN0aW9u cy4gSnVzdCBsaWtlIHRoZSBjb21tdW5pY2F0aW9uIGJldHdlZW4gYW55IHBvb2wgdXNlcnMgYW5k IFZORiBQb29sLCB0aGUgaW5mb3JtYXRpb24gZXhjaGFuZ2VkIGJldHdlZW4gdGhlIFZORiBQb29s IGFuZCB0aGUgU0ZDIG1heSBpbmNsdWRlIHNvbWUgb3BlcmF0aW9uYWwgaW5mb3JtYXRpb24gb2Yg dGhlIFZORiBQb29sLg0KR29hbHMgYW5kIE1pbGVzdG9uZXM6DQpEZWNlbWJlciAyMDE0IC0gU3Vi bWl0IFZORlBvb2wgUHJvYmxlbSBTdGF0ZW1lbnQgdG8gSUVTRyBmb3IgcHVibGljYXRpb24gYXMg YW4gSW5mb3JtYXRpb25hbCBkb2N1bWVudC4NCkFwcmlsIDIwMTUgLSBTdWJtaXQgVk5GUG9vbCBV c2UgQ2FzZXMgdG8gSUVTRyBmb3IgcHVibGljYXRpb24gYXMgYW4gSW5mb3JtYXRpb25hbCBkb2N1 bWVudC4NCkF1Z3VzdCAyMDE1IC0gU3VibWl0IFZORlBvb2wgUmVxdWlyZW1lbnRzLCBpbmNsdWRp bmcgdGhlIG1hbmFnZWFiaWxpdHkgb2YgVk5GIFBvb2wgdG8gSUVTRyBmb3IgcHVibGljYXRpb24g YXMgYW4gSW5mb3JtYXRpb25hbCBkb2N1bWVudC4NCkF1Z3VzdCAyMDE1IC0gU3VibWl0IFZORlBv b2wgQXJjaGl0ZWN0dXJlIHRvIElFU0cgZm9yIHB1YmxpY2F0aW9uIGFzIGFuIEluZm9ybWF0aW9u YWwgZG9jdW1lbnQuDQpEZWNlbWJlciAyMDE1IC0gU3VibWl0IG9uZSBvciBtb3JlIEFwcGxpY2Fi aWxpdHkgYW5kIEdhcCBBbmFseXNpcyBvZiBleGlzdGluZyBwcm90b2NvbHMgdG8gVk5GUG9vbCB0 byBJRVNHIGZvciBwdWJsaWNhdGlvbiBhcyBJbmZvcm1hdGlvbmFsIGRvY3VtZW50KHMpLg0KPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0NCllvdXIgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIHRvIHRoZSBjaGFy dGVyIGFyZSBBTFdBWVMgaGlnaGx5IGFwcHJlY2lhdGVkIQ0KVGhhbmtzLg0KLU5pbmcNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0Kdm5mcG9vbCBt YWlsaW5nIGxpc3QNCg0Kdm5mcG9vbEBpZXRmLm9yZzxtYWlsdG86dm5mcG9vbEBpZXRmLm9yZz4N Cg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92bmZwb29sDQo= --_000_B0D29E0424F2DE47A0B36779EC6667796616C55Fnkgeml501mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNv bnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk65b6u6L2v6ZuF6buROw0KCXBhbm9zZS0xOjIgMTEg NSAzIDIgMiA0IDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5b6u6L2v6ZuF 6buRIjsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjE3Ljg1cHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5 Ow0KCXRleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGg7DQoJbGluZS1oZWlnaHQ6MTUwJTsNCglm b250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6YmxhY2s7fQ0KcC5Nc29Db21tZW50VGV4dCwgbGkuTXNvQ29tbWVudFRleHQsIGRpdi5N c29Db21tZW50VGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IuaJueazqOaWh+WtlyBDaGFyIjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4t cmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjE3 Ljg1cHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCXRleHQtanVzdGlmeTppbnRlci1pZGVvZ3Jh cGg7DQoJbGluZS1oZWlnaHQ6MTUwJTsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDoxNy44NXB0Ow0KCXRleHQtYWxpZ246anVzdGlmeTsNCgl0ZXh0LWp1c3Rp Znk6aW50ZXItaWRlb2dyYXBoOw0KCWxpbmUtaGVpZ2h0OjE1MCU7DQoJZm9udC1zaXplOjEwLjVw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30N CnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiLmibnms6jmoYbmlofmnKwgQ2hhciI7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDoxNy44NXB0Ow0KCXRleHQtYWxpZ246anVz dGlmeTsNCgl0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoOw0KCWxpbmUtaGVpZ2h0OjE1MCU7 DQoJZm9udC1zaXplOjEwLjVwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOmJsYWNrO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFw aCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1zby1t YXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCXRleHQtYWxpZ246anVzdGlmeTsN Cgl0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoOw0KCWxpbmUtaGVpZ2h0OjE1MCU7DQoJZm9u dC1zaXplOjEwLjVwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOmJsYWNrO30NCnNwYW4uSFRNTENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg6aKE6K6+ 5qC85byPIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCDpooTorr7moLzlvI8iOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6 YmxhY2s7fQ0Kc3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLmibnms6jmloflrZcgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOuaJueazqOaWh+WtlzsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNw YW4uQ2hhcjANCgl7bXNvLXN0eWxlLW5hbWU6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms65om55rOo5qGG5paH5pysOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5D b21tZW50YWlyZUNhcg0KCXttc28tc3R5bGUtbmFtZToiQ29tbWVudGFpcmUgQ2FyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6Q29tbWVudGFpcmU7fQ0KcC5Db21t ZW50YWlyZSwgbGkuQ29tbWVudGFpcmUsIGRpdi5Db21tZW50YWlyZQ0KCXttc28tc3R5bGUtbmFt ZTpDb21tZW50YWlyZTsNCgltc28tc3R5bGUtbGluazoiQ29tbWVudGFpcmUgQ2FyIjsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjE3Ljg1cHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5 Ow0KCXRleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGg7DQoJbGluZS1oZWlnaHQ6MTUwJTsNCglm b250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6YmxhY2s7fQ0KcC5IVE1MUHJlZm9ybWF0dGVkLCBsaS5IVE1MUHJlZm9ybWF0dGVkLCBk aXYuSFRNTFByZWZvcm1hdHRlZA0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQi Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjE3Ljg1cHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCXRl eHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGg7DQoJbGluZS1oZWlnaHQ6MTUwJTsNCglmb250LXNp emU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29s b3I6YmxhY2s7fQ0KcC5Db21tZW50VGV4dCwgbGkuQ29tbWVudFRleHQsIGRpdi5Db21tZW50VGV4 dA0KCXttc28tc3R5bGUtbmFtZToiQ29tbWVudCBUZXh0IjsNCgltc28tc3R5bGUtbGluazoiQ29t bWVudCBUZXh0IENoYXIiOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MTcuODVw dDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJdGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaDsN CglsaW5lLWhlaWdodDoxNTAlOw0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkNvbW1lbnRUZXh0Q2hh cg0KCXttc28tc3R5bGUtbmFtZToiQ29tbWVudCBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQ29tbWVudCBUZXh0IjsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnAuQmFsbG9vblRleHQsIGxp LkJhbGxvb25UZXh0LCBkaXYuQmFsbG9vblRleHQNCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24g VGV4dCI7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjE3Ljg1cHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCXRl eHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGg7DQoJbGluZS1oZWlnaHQ6MTUwJTsNCglmb250LXNp emU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 YmxhY2s7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24g VGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJh bGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTMyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9 DQpzcGFuLkVtYWlsU3R5bGUzMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp bFN0eWxlMzQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTM1DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzNg0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpA bGlzdCBsMA0KCXttc28tbGlzdC1pZDoyMzkwMjczMTU7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7 DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yMTE3NDM0Njk2IDU4MjY1MzU4MCA2NzY5ODY5MSA2 NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5 ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjUzNDA7DQoJbXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgltc28tZmFyZWFzdC1mb250LWZhbWlseTrlrovkvZM7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC10YWItc3Rv cDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC10YWItc3RvcDoxMDguMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlz dCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2 ZWw2DQoJe21zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXtt c28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVs LXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC10YWItc3Rv cDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0O30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjI1NTk4NTEyOTsNCgltc28tbGlz dC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTg1MzIzMTM4NiAtMTk3ODM0 OTc2NiA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcw MyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXRleHQ6 IiUxXCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDozNS44NXB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJbXNvLWFuc2ktZm9udC13ZWlnaHQ6bm9ybWFsO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28t bGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtdGFi LXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjE0 NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30N CkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBs MTpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw4 DQoJe21zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28t bGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDo4NTQxNDg1 Nzk7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMTEx OTY3NDA2IDE3NTgxMDg4MjggNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2 OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CW1hcmdpbi1sZWZ0OjM4Ljg1cHQ7DQoJdGV4dC1pbmRlbnQ6LTIxLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0 IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZl bDUNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21z by1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwt dGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDgNCgl7bXNvLWxldmVsLXRhYi1zdG9w OjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC10YWItc3RvcDozMjQuMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 O30NCkBsaXN0IGwzDQoJe21zby1saXN0LWlkOjExMTk4MzU3OTg7DQoJbXNvLWxpc3QtdHlwZTpo eWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjY1NTEzMDc2NiAxNzU4MTA4ODI4IDY3Njk4 NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4Njkx IDY3Njk4NjkzO30NCkBsaXN0IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjQuNnB0Ow0K CXRleHQtaW5kZW50Oi0zLjZwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2 ZWwyDQoJe21zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDM6bGV2ZWwzDQoJe21z by1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwt dGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNvLWxldmVsLXRhYi1zdG9w OjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7fQ0KQGxpc3QgbDM6bGV2ZWw2DQoJe21zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 O30NCkBsaXN0IGwzOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlz dCBsMzpsZXZlbDgNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDM6bGV2 ZWw5DQoJe21zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJn Y29sb3I9IndoaXRlIiBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJsaW5lLWhlaWdodDoxNTAlO2NvbG9yOiMxRjQ5N0QiPkhpLCBMaW5k YSBhbmQgQ2hpZHVuZyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1MCU7Y29sb3I6IzFGNDk3 RCI+SeKAmWQgdGhpbmsgdGhhdCB1c3VhbGx5IGEgcG9vbCB3b3VsZCBoYXZlIGEgY29udHJvbCBw b2ludCBpbiB0aGUgZGF0YSBwYXRoIHRvIGFsbG9jYXRlIGluY29taW5nIHRyYWZmaWMgdG8gZGlm ZmVyZW50IHBvb2wgbWVtYmVycyB0aGF0IGJlbG9uZ3MgdG8gYSB0ZW5hbnQuIEnigJlkIGNhbGwg c3VjaCBhIGNvbnRyb2wNCiBwb2ludCBhIHRyYWZmaWMgbWFuYWdlciBpbiBhIHBvb2wuIE5vdGUg dGhhdCB0aGlzIHRyYWZmaWMgbWFuYWdlciBpcyBwYXJ0IG9mIHRoZSBwb29saW5nIG1lY2hhbmlz bSBpdHNlbGYsIHRodXMgaXMgbm90IGhhbmRsZWQgYnkgdGhlIGNvbnRyb2wgZW50aXR5IG91dHNp ZGUgb2YgdGhlIHBvb2wuIE1vcmVvdmVyLCBiYXNlZCBvbiBvdXIgY2hhcnRlciwgd2UgY3VycmVu dGx5IGZvY3VzIG9uIHRoZSBwb29sIG1hbmFnZW1lbnQsIHN1Y2ggYXMgaW5zdGFuY2UNCiByZWdp c3RyYXRpb24sIGFjdGl2ZS9zdGFuZGJ5IGluc3RhbmNlIHNlbGVjdGlvbi4gU28gc3VjaCBhIHRy YWZmaWMgbWFuYWdlciBpcyBub3Qgb3VyIGZvY3VzIGZvciB0aGlzIHBoYXNlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0ibGluZS1oZWlnaHQ6MTUwJTtjb2xvcjojMUY0OTdEIj5UaG91Z2h0cz88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImxpbmUtaGVpZ2h0OjE1MCU7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJsaW5l LWhlaWdodDoxNTAlO2NvbG9yOiMxRjQ5N0QiPi1OaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJsaW5lLWhlaWdo dDoxNTAlO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i bGVmdCIgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0O3RleHQtYWxpZ246 bGVmdDtsaW5lLWhlaWdodDpub3JtYWwiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOndpbmRvd3RleHQiPuWPkeS7tuS6ujxzcGFuIGxh bmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjp3aW5kb3d0ZXh0Ij4gTGlu ZGEgRHVuYmFyDQo8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOndpbmRvd3RleHQiPuWPkemAgeaXtumXtDxzcGFuIGxh bmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjp3aW5kb3d0ZXh0Ij4gMjAx NDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZM7 Y29sb3I6d2luZG93dGV4dCI+5bm0PHNwYW4gbGFuZz0iRU4tVVMiPjc8L3NwYW4+5pyIPHNwYW4g bGFuZz0iRU4tVVMiPjE8L3NwYW4+5pelPHNwYW4gbGFuZz0iRU4tVVMiPg0KIDc6MTg8YnI+DQo8 L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIj4gTEFDIENoaWR1bmc7IFpvbmduaW5nPGJyPg0KPC9zcGFuPjxiPuaKhOmAgTxz cGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IHZuZnBvb2xA aWV0Zi5vcmc8YnI+DQo8L3NwYW4+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUkU6IFt2bmZwb29sXSA8L3NwYW4+DQrnrZTlpI08c3Bh biBsYW5nPSJFTi1VUyI+OiA8L3NwYW4+562U5aSNPHNwYW4gbGFuZz0iRU4tVVMiPjogPC9zcGFu PuetlOWkjTxzcGFuIGxhbmc9IkVOLVVTIj46IFVwZGF0ZWQgVk5GUG9vbCBDaGFydGVyPG86cD48 L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtsaW5lLWhlaWdodDoxNTAl O2NvbG9yOiMxRjQ5N0QiPkNoaWR1bmcsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7bGluZS1oZWlnaHQ6MTUwJTtjb2xvcjojMUY0OTdEIj5B IGZldyBxdWVzdGlvbnMgdG8geW91ciBhdHRhY2hlZCBmaWxlOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBw dDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2xpbmUtaGVpZ2h0OjE1MCU7Y29sb3I6 IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250 OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2xpbmUt aGVpZ2h0OjE1MCU7Y29sb3I6IzFGNDk3RCI+QWxsIHRoZSBtb2RlbHMgYXNzdW1lIHRoYXQgdGhl cmUgaXMgYSBjZW50cmFsIExCTSB0aGF0IHRyYWZmaWMgdHJhdmVyc2UgdGhyb3VnaC4gSSB3b3Vs ZCB0aGluayB0aGF0IFZORnBvb2wgZG9lc27igJl0IHJlcXVpcmUgdGhlIHRyYWZmaWMgdG8gZ28g dGhyb3VnaCBhDQogc2luZ2xlIHBvaW50IG9mIExCLiBDb3JyZWN0PzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4 LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2xpbmUtaGVpZ2h0OjE1MCU7Y29s b3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2xp bmUtaGVpZ2h0OjE1MCU7Y29sb3I6IzFGNDk3RCI+MSYjNDM7MSBwcm90ZWN0aW9uIGNhbiBiZSB2 ZXJ5IGV4cGVuc2l2ZS4gSSB3b3VsZCB0aGluayBvbmx5IHRoZSBzdGF0ZWZ1bCBWTkYgbWlnaHQg bmVlZCAxJiM0MzsxIG9yIE4mIzQzO0sgcHJvdGVjdGlvbi4gRm9yIHN0YXRlbGVzcyBWTkYsIHRo ZSBNb2RlbCAxIHNob3VsZCBiZSB1c2VkLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbSI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2xpbmUtaGVpZ2h0OjE1MCU7Y29sb3I6IzFGNDk3RCI+ TXkgdHdvIGNlbnRzLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2xpbmUtaGVpZ2h0OjE1MCU7Y29sb3I6IzFGNDk3RCI+TGluZGE8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7bGluZS1oZWlnaHQ6MTUwJTtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJtYXJnaW46MGNt O21hcmdpbi1ib3R0b206LjAwMDFwdDt0ZXh0LWFsaWduOmxlZnQ7bGluZS1oZWlnaHQ6bm9ybWFs Ij4NCjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5k b3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiB2bmZwb29sIFs8YSBocmVmPSJtYWlsdG86dm5mcG9v bC1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86dm5mcG9vbC1ib3VuY2VzQGlldGYub3JnPC9hPl0N CjxiPk9uIEJlaGFsZiBPZiA8L2I+TEFDIENoaWR1bmc8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5 LCBKdW5lIDI3LCAyMDE0IDQ6MjQgQU08YnI+DQo8Yj5Ubzo8L2I+IFpvbmduaW5nPGJyPg0KPGI+ Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86dm5mcG9vbEBpZXRmLm9yZyI+dm5mcG9vbEBpZXRmLm9y ZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2bmZwb29sXSA8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+562U5aSNPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij46 DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 5b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4 dCI+562U5aSNPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjp3aW5kb3d0ZXh0Ij46DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6d2luZG93dGV4dCI+562U5aSNPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij46IFVwZGF0ZWQgVk5GUG9vbCBDaGFy dGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2xpbmUtaGVpZ2h0OjE1 MCUiPkhpIE5pbmcsPGJyPg0KMS0gT24gZnVydGhlciBjb25zaWRlcmF0aW9uLCBteSByZW1hcmsg KGkpIGluIHRoZSBwcmV2aW91cyBlLW1haWwgKCZxdW90OzxpPm5vIHJlZHVuZGFuY3kgYXQgYWxs IC4uLi4uPC9pPiZxdW90Oykgc2hvdWxkIG5vdCBiZSBhcHBsaWVkIGluIHRoZSBWTkYgY29udGV4 dCBpZiB0aGUgaW50ZW50aW9uIGlzIHRvIHVzZSBhIHBvb2wgZm9yIHJlZHVuZGFuY3kgcHVycG9z ZXMNCjxiPndoaWxlIG1pbmltaXppbmcgdGhlIG5lZWRlZCByZXNvdXJjZXM8L2I+LiBBcyBzaG93 biBpbiB0aGUgZmlndXJlIGVuY2xvc2VkLCB0aGlzIFBORiBzY2hlbWUgKG5vIHJlZHVuZGFuY3kg YXQgYWxsLCBpLmUuLCBhbGwgaW5zdGFuY2VzIG9mIHRoZSBwb29sIHBhcnRpY2lwYXRlIGFjdGl2 ZWx5KSBpcyBub3QgYXBwbGljYWJsZSBpbiB0aGUgVk5GIGZyYW1ld29yayB3aGVyZSBhZGRpdGlv bmFsIGluc3RhbmNlcyBhcmUgY3JlYXRlZA0KPGI+b25seTwvYj4gaWYgbmVlZGVkLjxicj4NCjIt IEJhY2sgdG8geW91ciBlLW1haWwgb2YgSnVuZSAxOXRoICZxdW90OzxpPnRoZSBWTkYgaW5zdGFu Y2Ugc2NhbGluZyB3aXRoaW4gYSBWTkYgcG9vbCBpcyBpbmNsdWRlZCBpbiB0aGUgY2hhcnRlcjwv aT4mcXVvdDs6IEkgZG9uJ3QgdGhpbmsgJnF1b3Q7c2NhbGluZyZxdW90OywgJnF1b3Q7c2NhbGFi aWxpdHkmcXVvdDsgYXBwZWFyaW5nIGluIHRoZSBjaGFydGVyIC0gaXQgd291bGQgYmUgbmljZSB0 byBpbnRyb2R1Y2UgYSBzZW50ZW5jZSAoc29tZXdoZXJlKSB3aXRoIG9uZSBvZiB0aGVzZSB0d28N CiB3b3JkcyB0byBhdm9pZCB0aGlzIGFtYmlndWl0eS4gQWdhaW4sIHNjYWxpbmcgaW4vb3V0IGlz IG9uZSBtYWluIGNoYXJhY3RlcmlzdGljIG9mIFZORi48YnI+DQpCZXN0LDxicj4NCkNoaWR1bmc8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7bGluZS1oZWlnaHQ6MTUwJSI+TGUgMjcvMDYvMjAxNCAwMzozNiwgWm9uZ25pbmcgYSDD qWNyaXQmbmJzcDs6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5IaSwgQ2hpZHVuZyw8YnI+DQpUaGFua3MgZm9yIHlvdXIgc3Vn Z2VzdGlvbnMuIEkgd2lsbCBtYWtlIHRoZSB0ZXh0IGNsZWFyIGZvciBjb21tZW50IFoyLiBCdXQg Zm9yIGNvbW1lbnQgWjksIEnigJlkIHByZWZlciB0byBrZWVwIOKAnFZORiBQb29s4oCdLCBhcyB3 ZSBkb27igJl0IHByb3Bvc2UvZGlzY3VzcyBhIGNvbmNyZXRlIFZORiBQb29sIGFyY2hpdGVjdHVy ZSBpbiB0aGUgY2hhcnRlciwgYnV0IGp1c3QgaW50cm9kdWNlIGEgZ2VuZXJhbCBjb25jZXB0Ljxi cj4NCkxvb2sgZm9yd2FyZCB0byB5b3VyIGZ1cnRoZXIgY29tbWVudHMuPGJyPg0KLU5pbmc8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIg c3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0O3RleHQtYWxpZ246bGVmdDts aW5lLWhlaWdodDpub3JtYWwiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk65a6L5L2TO2NvbG9yOndpbmRvd3RleHQiPuWPkSDku7bkuro8c3BhbiBsYW5nPSJF Ti1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZM7Y29sb3I6d2luZG93dGV4dCI+IExBQyBDaGlk dW5nIFs8YSBocmVmPSJtYWlsdG86Y2hpZHVuZy5sYWNAb3JhbmdlLmNvbSI+bWFpbHRvOmNoaWR1 bmcubGFjQG9yYW5nZS5jb208L2E+XQ0KPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjp3aW5kb3d0ZXh0Ij7lj5Eg6YCB 5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOndp bmRvd3RleHQiPiAyMDE0PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OuWui+S9kztjb2xvcjp3aW5kb3d0ZXh0Ij7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+Njwv c3Bhbj7mnIg8c3BhbiBsYW5nPSJFTi1VUyI+MjY8L3NwYW4+5pelPHNwYW4gbGFuZz0iRU4tVVMi Pg0KIDIyOjUzPGJyPg0KPC9zcGFuPjxiPuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFpvbmduaW5nPGJyPg0KPC9zcGFuPjxiPuaKhOmA gTxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IDxhIGhy ZWY9Im1haWx0bzp2bmZwb29sQGlldGYub3JnIj4NCnZuZnBvb2xAaWV0Zi5vcmc8L2E+PGJyPg0K PC9zcGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyI+IFJlOiA8L3NwYW4+562U5aSNPHNwYW4gbGFuZz0iRU4tVVMiPjogW3ZuZnBvb2xd DQo8L3NwYW4+562U5aSNPHNwYW4gbGFuZz0iRU4tVVMiPjogVXBkYXRlZCBWTkZQb29sIENoYXJ0 ZXI8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxl PSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6bm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkhpIE5pbmcsPGJy Pg0KVGhhbmsgeW91IGZvciB0aGUgcmVwbHkuIFNvbWUgY29tbWVudHMvc3VnZ2VzdGlvbnMgdG8g eW91cjo8YnI+DQoqIGNvbW1lbnQgWjI6IEkga25ldyB0aGF0IHRoZSDCqyZuYnNwO2VsZW1lbnRh cnkmbmJzcDvCuyBORnMgYXJlIHBhcnQgb2YgdGhlIGpvYiwgYnV0IHdhbnRlZCB0byBzdWdnZXN0 IHRvIGFkZCBzb21ldGhpbmcgaW4gdGhpcyBzZWN0aW9uIHRvIGF2b2lkIHJlYWRlcnMgdG8gcGVy Y2VpdmUmbmJzcDsgdGhlIHdyb25nIGZlZWxpbmcgbWVudGlvbmVkIGluIG15IGNvbW1lbnQgIzE8 YnI+DQoqIGNvbW1lbnQgWjc6IFRoYW5rIHlvdSBmb3IgdGhpcyBjbGFyaWZpY2F0aW9uLiBJIHRo dXMgdW5kZXJzdGFuZCB0aGF0IHRocmVlIHR5cGVzIG9mIHBvb2xzIChhbmQgbm90IG1vcmUgdGhh biB0aHJlZSkgbWF5IGV4aXN0Ojxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIChpKSBu byByZWR1bmRhbmN5IGF0IGFsbCwgaS5lLiwgYWxsIGluc3RhbmNlcyBvZiB0aGUgcG9vbCBwYXJ0 aWNpcGF0ZSBhY3RpdmVseSAtIGFuIHVwc3RyZWFtIGxvYWQgYmFsYW5jaW5nIG1lY2hhbmlzbSBz aGFyZXMgdGhlIGluY29taW5nIGxvYWQgYW1vbmcgdGhlc2UgaW5zdGFuY2VzOzxicj4NCiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAtIChpaSkgMToxIChhY3RpdmUtYWN0aXZlKSByZWR1bmRhbmN5 IC0gZm9yIGV4YW1wbGUsIDUgJnF1b3Q7aW1hZ2VzJnF1b3Q7ICh0byBhdm9pZCB0aGUgd29yZCAn aW5zdGFuY2UnKSBvZiB0aGUgVk5GLCBhbmQgZWFjaCBvZiB0aGVtIGlzIHJlZHVuZGFudCAtJmd0 OyBpbiB0aGlzIGNhc2UsIHRoZXJlIGFyZSAxMCBpbnN0YW5jZXMgcnVubmluZyBpbiBwYXJhbGxl bCBpbiB0aGUgcG9vbDs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSAoaWlpKSBOJiM0 MztLIChhY3RpdmUtc3RhbmRieSkgcmVkdW5kYW5jeSB3aGVyZSBzb21lIGluc3RhbmNlcyBydW4g YWN0aXZlbHksIHdoaWxlIG90aGVycyBhcmUgaW4gYSBkb3JtYW50IHN0YXRlLjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDpub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZMiPiogY29tbWVudCBaOTog SG93IGFib3V0IHRoaXMgYWRkLW9uIHRoZW4gPyAmcXVvdDsuLi4gYWNoaWV2ZWQgYnkgdGhlIFZO RiBQb29sDQo8Yj5hcmNoaXRlY3R1cmU8L2I+IHV0aWxpemVkL2Fkb3B0ZWQgYnkgdGhlIFZORiAu Li4mcXVvdDsgPGJyPg0KQmVzdCw8YnI+DQpDaGlkdW5nPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTrlrovkvZMiPiA8YnI+DQo8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OuWui+S9kyI+PGJyPg0KTGUgMTkvMDYvMjAxNCAwNToxNCwgWm9uZ25pbmcgYSA8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj7DqTxzcGFuIGxh bmc9IkVOLVVTIj5jcml0Jm5ic3A7Ojwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkhpLCBDaGlkdW5nLDxicj4NClBs ZWFzZSBzZWUgbXkgcmVwbHkgZW5jbG9zZWQgaW4gdGhlIGF0dGFjaG1lbnQuIFJlZ2FyZGluZyBj b21tZW50IzYsIEnigJlkIGxpa2UgdG8gZXhwbGFpbiB0aGF0IHdlIGRvbuKAmXQgcmVzdHJpY3Qg dG8gdGhlIGNhc2UgdGhhdCBpbiBhIHBvb2wsIGF0IGEgZ2l2ZW4gdGltZSwgdGhlcmUgaXMgb25s eSBvbmUgcnVubmluZyBpbnN0YW5jZSBhbmQgYWxsIG90aGVycyBhcmUgc2xlZXBpbmcuIEEgcG9v bCBzaG91bGQgYmUgZmxleGlibGUgdG8gaGFuZGxlDQogbW9yZSBjYXNlcywgaW5jbHVkaW5nIG11 bHRpcGxlIHJ1bm5pbmcgaW5zdGFuY2VzIGFuZCBtdWx0aXBsZSBzdGFuZGJ5IGluc3RhbmNlcy48 YnI+DQpMb29rIGZvcndhcmQgdG8geW91ciBmdXJ0aGVyIGNvbW1lbnRzICZhbXA7IHN1Z2dlc3Rp b25zLjxicj4NCi1OaW5nPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4w MDAxcHQ7dGV4dC1hbGlnbjpsZWZ0O2xpbmUtaGVpZ2h0Om5vcm1hbCI+DQo8Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZM7Y29sb3I6d2luZG93dGV4dCI+ 5Y+RIOS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xv cjp3aW5kb3d0ZXh0Ij4gTEFDIENoaWR1bmcgWzxhIGhyZWY9Im1haWx0bzpjaGlkdW5nLmxhY0Bv cmFuZ2UuY29tIj5tYWlsdG86Y2hpZHVuZy5sYWNAb3JhbmdlLmNvbTwvYT5dDQo8YnI+DQo8L3Nw YW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TO2Nv bG9yOndpbmRvd3RleHQiPuWPkSDpgIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTrlrovkvZM7Y29sb3I6d2luZG93dGV4dCI+IDIwMTQ8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOndpbmRvd3RleHQiPuW5 tDxzcGFuIGxhbmc9IkVOLVVTIj42PC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj4xOTwvc3Bh bj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+DQogMDo0MDxicj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8 c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBab25nbmlu Zzxicj4NCjwvc3Bhbj48Yj7mioTpgIE8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiPiA8YSBocmVmPSJtYWlsdG86dm5mcG9vbEBpZXRmLm9yZyI+DQp2bmZw b29sQGlldGYub3JnPC9hPjxicj4NCjwvc3Bhbj48Yj7kuLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+ Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBSZTogW3ZuZnBvb2xdIDwvc3Bhbj4NCuet lOWkjTxzcGFuIGxhbmc9IkVOLVVTIj46IFVwZGF0ZWQgVk5GUG9vbCBDaGFydGVyPC9zcGFuPjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGln bjpsZWZ0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIE5pbmcsPGJyPg0KMSkg SXMgaXQgZXhhY3QgdGhhdCBzY2FsaW5nIG91dC9pbiwgb25lIG1haW4gY2hhcmFjdGVyaXN0aWMg b2YgVk5GcyAoY29tcGFyZWQgdG8gUE5GcyksIGlzIG5vdCBpbmNsdWRlZCA/PGJyPg0KMikgU29t ZSBjb21tZW50cy9zdWdnZXN0aW9ucyBhcmUgZW5jbG9zZWQuPGJyPg0KQmVzdCw8YnI+DQpDaGlk dW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5MZSAxMi8wNi8yMDE0IDA1OjM4LCBab25nbmluZyBhIMOpY3JpdCZu YnNwOzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5EZWFyIGFsbCw8YnI+ DQpQbGVhc2UgcmV2aWV3IHRoZSBjaGFydGVyIHRleHQgaW5jbHVkZWQgaW4gdGhlIGxhc3QgZW1h aWwuIFdlIGFyZSBob3BpbmcgdGhhdCBhIGdlbmVyYWwgY29uc2Vuc3VzIG9uIHRoZSBjaGFydGVy IGNvdWxkIGJlIGFjaGlldmVkIG9uIHRoZSBsaXN0LCB0aGVuIGEgc3RhYmxlIGNoYXJ0ZXIgaXMg cmVhZHkgZm9yIHRoZSBWTkZQb29sIHNlc3Npb24gaW4gVG9yb250by48YnI+DQpUaGFua3MuPGJy Pg0KLU5pbmc8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBh bGlnbj0ibGVmdCIgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0O3RleHQt YWxpZ246bGVmdDtsaW5lLWhlaWdodDpub3JtYWwiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+ Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTrlrovkvZMiPiB2bmZwb29sIFs8YSBocmVmPSJtYWlsdG86dm5mcG9v bC1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86dm5mcG9vbC1ib3VuY2VzQGlldGYub3JnPC9hPl0N Cjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovk vZMiPuS7oyDooaggPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj5ab25nbmluZzxicj4NCjwvc3Bhbj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZMiPuWPkSDpgIHml7bp l7Q8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZMiPiAyMDE0PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+5bm0PHNw YW4gbGFuZz0iRU4tVVMiPjY8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjEyPC9zcGFuPuaX pTxzcGFuIGxhbmc9IkVOLVVTIj4NCiAxMToyMDxicj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8c3Bh biBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiA8YSBocmVmPSJt YWlsdG86dm5mcG9vbEBpZXRmLm9yZyI+DQp2bmZwb29sQGlldGYub3JnPC9hPjxicj4NCjwvc3Bh bj48Yj7kuLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiPiBbdm5mcG9vbF0gVXBkYXRlZCBWTkZQb29sIENoYXJ0ZXI8L3NwYW4+PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6bm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ RGVhciBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImxpbmUtaGVpZ2h0Om5vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJhc2VkIG9uIHRoZSBs aXN0IGRpc2N1c3Npb24gc2luY2Ugd2UgcG9zdGVkIHRoZSBsYXN0IHZlcnNpb24sIEkgaGF2ZSBt YWRlIHNvbWUgKG1pbm9yKSByZXZpc2lvbiBvZiB0aGUgY2hhcnRlci4gVGhlIG1haW4gY2hhbmdl cyBhcmU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDozNS44NXB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bGluZS1oZWln aHQ6bm9ybWFsO21zby1saXN0OmwxIGxldmVsMSBsZm80Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xKTxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+PHNwYW4gbGFuZz0iRU4tVVMiPlN0YXRlIHRoYXQgc2VydmljZSBzdGF0ZSBzeW5jaHJvbml6 YXRpb24gaXMgb3V0IG9mIHNjb3BlIOKAnGluIHRoaXMgcGhhc2XigJ07PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoz NS44NXB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bGluZS1oZWlnaHQ6bm9ybWFsO21zby1saXN0Omwx IGxldmVsMSBsZm80Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIj48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMi PkluY2x1ZGUgVk5GIFBvb2wgd2l0aCBib3RoIHZpcnR1YWxpemVkIGFuZCBub24tdmlydHVhbGl6 ZWQgbmV0d29yayBmdW5jdGlvbiBmb3IgZnVydGhlciBzdHVkeTs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1Ljg1 cHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDtsaW5lLWhlaWdodDpub3JtYWw7bXNvLWxpc3Q6bDEgbGV2 ZWwxIGxmbzQiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjMpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyI+RXhw bGljaXRseSBzdGF0ZSB0aGF0IHRoZSByZWZlcmVuY2Ugc29sdXRpb24gJmFtcDsgZ2FwIGFuYWx5 c2lzIGlzIG5vdCBsaW1pdGVkIHRvIFJTZXJQb29sLCBidXQgb3BlbiB0byBhbnkgb3RoZXIgc29s dXRpb25zLCBhbHRob3VnaCBubyBkZWNpc2lvbiBvbiBwcm90b2NvbHMgd2lsbCBiZSBtYWRlIGlu IHRoaXMgcGhhc2U7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS44NXB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bGlu ZS1oZWlnaHQ6bm9ybWFsO21zby1saXN0OmwxIGxldmVsMSBsZm80Ij4NCjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj40 KTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiPlN0YXRlIHRoYXQgdGhlIGxpbmthZ2UgYmV0d2Vl biBTRkMgYW5kIFZORiBQb29sIGlzIGp1c3QgbGlrZSBhIHBvb2wgdXNlciBhbmQgYSBwb29sIOKA kyBub3RoaW5nIHNwZWNpZmllZCAoeWV0KTs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1Ljg1cHQ7dGV4dC1pbmRl bnQ6LTE4LjBwdDtsaW5lLWhlaWdodDpub3JtYWw7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzQiPg0K PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPjUpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyI+VXBkYXRlIGJ1bGxldCAj NCB1bmRlciDigJxRdWVzdGlvbnMgdGhhdCBhcmUgcmFpc2Vk4oCm4oCdLCB0byBrZWVwIGl0IGNv bnNpc3RlbnQgd2l0aCB0aGUgaWRlYSB0aGF0IHBvb2xpbmcgaXMgbm90IHZpc2libGUgdG8gdGhl IHNlcnZpY2UgY29udHJvbCBlbnRpdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0Om5vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi Pj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0Om5vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk5ldHdv cmsgZnVuY3Rpb25zIHN1Y2ggYXMgZmlyZXdhbGxzLCBsb2FkIGJhbGFuY2VycywgYW5kIFdBTiBv cHRpbWl6ZXJzIGFyZSBjb252ZW50aW9uYWxseSBkZXBsb3llZCBhcyBzcGVjaWFsaXplZCBoYXJk d2FyZSBzZXJ2ZXJzIGluIGJvdGggbmV0d29yayBvcGVyYXRvcnMnIG5ldHdvcmtzIGFuZCBkYXRh IGNlbnRlciBuZXR3b3Jrcw0KIGFzIHRoZSBidWlsZGluZyBibG9ja3Mgb2YgdGhlIG5ldHdvcmsg c2VydmljZXMuIFRoZXJlIGlzIGEgdHJlbmQgdG8gaW1wbGVtZW50IHN1Y2ggbmV0d29yayBmdW5j dGlvbnMgYXMgc29mdHdhcmUgaW5zdGFuY2VzIHJ1bm5pbmcgb24gZ2VuZXJhbCBwdXJwb3NlIHNl cnZlcnMsIHZpYSBhIHZpcnR1YWxpemF0aW9uIGxheWVyIChpLmUuLCBoeXBlcnZpc29ycykuIFRo ZXNlIHZpcnR1YWxpemVkIGZ1bmN0aW9ucyBhcmUgY2FsbGVkIFZpcnR1YWxpemVkDQogTmV0d29y ayBGdW5jdGlvbnMgKFZORnMpLCB3aGljaCBjYW4gYmUgdXNlZCB0byBidWlsZCBuZXR3b3JrIHNl cnZpY2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJsaW5lLWhlaWdodDpub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgdXNlIG9mIFZORnMg aW50cm9kdWNlcyBhZGRpdGlvbmFsIGNoYWxsZW5nZXMgdG8gdGhlIHJlbGlhYmlsaXR5IG9mIHRo ZSBwcm92aWRlZCBuZXR3b3JrIHNlcnZpY2VzLiBBIHNpbmdsZSBWTkYgaW5zdGFuY2Ugd291bGQg dHlwaWNhbGx5IG5vdCBoYXZlIGJ1aWx0LWluIHJlbGlhYmlsaXR5IG1lY2hhbmlzbXMgb24gaXRz IGhvc3QNCiAoaS5lLiwgYSBnZW5lcmFsIHB1cnBvc2Ugc2VydmVyKS4gSW5zdGVhZCwgdGhlcmUg YXJlIG1vcmUgZmFjdG9ycyBvZiByaXNrIHN1Y2ggYXMgc29mdHdhcmUgZmFpbHVyZSBhdCB2YXJp b3VzIGxldmVscyBpbmNsdWRpbmcgaHlwZXJ2aXNvcnMgYW5kIHZpcnR1YWwgbWFjaGluZXMsIGhh cmR3YXJlIGZhaWx1cmUsIGFuZCBpbnN0YW5jZSBtaWdyYXRpb24gdGhhdCBjYW4gbWFrZSBhIFZO RiBpbnN0YW5jZSB1bnJlbGlhYmxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDpub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5J biBvcmRlciB0byBhY2hpZXZlIGhpZ2hlciByZWxpYWJpbGl0eSwgYSBWTkYgbWF5IGFkb3B0IGEg cG9vbGluZyBtZWNoYW5pc20sIHdoZXJlIGEgbnVtYmVyIG9mIFZORiBpbnN0YW5jZXMgd2l0aCB0 aGUgc2FtZSBmdW5jdGlvbiBjYW4gYmUgZ3JvdXBlZCBhcyBhIHBvb2wgdG8gcHJvdmlkZSB0aGUg ZnVuY3Rpb24uIFdlIGNhbGwNCiBzdWNoIGEgcG9vbCBhIFZORiBQb29sLjwvc3Bhbj48c3BhbiBs YW5nPSJERSI+Q29uY2VwdHVhbGx5LCBhIDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+UG9vbCBN YW5hZ2VyIGlzIHVzZWQgdG8gbWFuYWdlIGEgVk5GIFBvb2wsIGUuZy4sIHNlbGVjdHMgYWN0aXZl L3N0YW5kYnkgVk5GIGluc3RhbmNlcywgYW5kIHBvdGVudGlhbGx5IGludGVyYWN0cyB3aXRoIGEg c2VydmljZSBjb250cm9sIGVudGl0eS4NCjwvc3Bhbj48c3BhbiBsYW5nPSJERSI+U3VjaCBhIDwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+c2VydmljZSBjb250cm9sIGVudGl0eSBpcyBhbiBlbnRp dHkgdGhhdCBvcmNoZXN0cmF0ZXMgYSBzZXQgb2YgbmV0d29yayBmdW5jdGlvbnMgdG8gYnVpbGQg bmV0d29yayBzZXJ2aWNlcy4gVGhlIG1ham9yIGJlbmVmaXQgb2YgdXNpbmcgVk5GIFBvb2wgaXMg dGhhdCByZWxpYWJpbGl0eSBtZWNoYW5pc21zIHN1Y2ggYXMgcmVkdW5kYW5jeSBtb2RlbCBhcmUN CiBhY2hpZXZlZCBieSB0aGUgVk5GIFBvb2wgaW5zaWRlIHRoZSBWTkYgYW5kIHRodXMgbm90IHZp c2libGUgdG8gdGhlIHNlcnZpY2UgY29udHJvbCBlbnRpdHkuIEEgVk5GIFBvb2wtZW5hYmxlZCBW TkYgc3RpbGwgYXBwZWFycyBhcyBhIG5vcm1hbCBWTkYgd2hlbiBvcmNoZXN0cmF0ZWQgYnkNCjwv c3Bhbj48c3BhbiBsYW5nPSJERSI+YSA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPnNlcnZpY2Ug Y29udHJvbCBlbnRpdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImxpbmUtaGVpZ2h0Om5vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlF1ZXN0aW9u cyB0aGF0IGFyZSByYWlzZWQgYnkgdGhlIGFkZGl0aW9uIG9mIGEgcG9vbGluZyBtZWNoYW5pc20g dG8gVk5GIGluY2x1ZGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoyNC42cHQ7dGV4dC1pbmRlbnQ6LTMuNnB0O2xp bmUtaGVpZ2h0Om5vcm1hbDttc28tbGlzdDpsMyBsZXZlbDEgbGZvNiI+DQo8IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxh bmc9IkVOLVVTIj5Ib3cgdG8gbWFuYWdlIHRoZSByZWR1bmRhbmN5IG1vZGVsLCBlLmcuLCBzZWxl Y3QgYWN0aXZlL3N0YW5kYnkgVk5GIGluc3RhbmNlcyBpbiBhIFZORiBQb29sPzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MjQuNnB0O3RleHQtaW5kZW50Oi0zLjZwdDtsaW5lLWhlaWdodDpub3JtYWw7bXNvLWxpc3Q6 bDMgbGV2ZWwxIGxmbzYiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi PsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyI+V2hhdCBwb29sIHN0YXRl cyBuZWVkIHRvIGJlIG1haW50YWluZWQgdG8gc3VwcG9ydCB0aGUgcG9vbGluZyBtZWNoYW5pc20g aXRzZWxmLCBhbmQgaG93IGFyZSBzdWNoIHN0YXRlcyBtYWludGFpbmVkPzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MjQuNnB0O3RleHQtaW5kZW50Oi0zLjZwdDtsaW5lLWhlaWdodDpub3JtYWw7bXNvLWxpc3Q6bDMg bGV2ZWwxIGxmbzYiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3 PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyI+V2hhdCBpbmZvcm1hdGlvbiBp cyBleGNoYW5nZWQgYmV0d2VlbiBhIFZORiBhbmQgYSBzZXJ2aWNlIGNvbnRyb2wgZW50aXR5PyBG b3IgZXhhbXBsZSwgaG93IGNhbiBhIFZORiBQb29sIGJlIGFkZHJlc3NlZCBieSB0aGUgc2Vydmlj ZSBjb250cm9sIGVudGl0eT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjI0LjZwdDt0ZXh0LWluZGVudDotMy42cHQ7 bGluZS1oZWlnaHQ6bm9ybWFsO21zby1saXN0OmwzIGxldmVsMSBsZm82Ij4NCjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4g bGFuZz0iRU4tQ0EiPkFmdGVyIGEgVk5GIGluc3RhbmNlIGZhaWxvdmVyLCBob3cgZG9lcyB0aGUg UG9vbCBNYW5hZ2VyIG5vdGlmeSB0aGUgc2VydmljZSBjb250cm9sIGVudGl0eSBzb21lIGNoYXJh Y3RlcmlzdGljIGNoYW5nZXMgb2YgdGhlIFZORiwgZS5nLiwgY2FwYWNpdHkgY2hhbmdlLCBidXQg d2l0aG91dCBkaXNjbG9zdXJlIG9mIHRoZSBwb29saW5nIHByb2NlZHVyZT88L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJsaW5lLWhlaWdodDpub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgV0cgaW5p dGlhbGx5IGZvY3VzZXMgb24gc2V2ZXJhbCByZWxpYWJpbGl0eSBtZWNoYW5pc21zIHRoYXQgYXJl IG1haW5seSBhc3NvY2lhdGVkIHdpdGggYSByZWR1bmRhbmN5IG1vZGVsIGJhc2VkIG9uIGEgVk5G IFBvb2wuIEFkZGl0aW9uYWwgbWVjaGFuaXNtcyBtYXkgaW5jbHVkZSBwb29sIHN0YXRlIG1haW50 ZW5hbmNlDQo8L3NwYW4+PHNwYW4gbGFuZz0iREUiPm9ubHkgZm9yIHBvb2xpbmcgcHVycG9zZS4g U2VydmljZSBzdGF0ZSBzeW5jaHJvbml6YXRpb24gaXMgb3V0IG9mIHNjb3BlIGZvciB0aGlzIHBo YXNlLiBUaGUgV0c8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiBhc3N1bWU8L3NwYW4+PHNwYW4g bGFuZz0iREUiPnM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiB0aGF0IGEgVk5GIFBvb2wgY29u dGFpbnMgcmVkdW5kYW50IFZORiBpbnN0YW5jZXMgb2Ygc2FtZQ0KIGZ1bmN0aW9uYWwgdHlwZS4g PC9zcGFuPjxzcGFuIGxhbmc9IkRFIj5EaWZmZXJlbnQgdHlwZXMgb2YgVk5GcyBhcmUgZW52aXNp b25lZCB0byBiZSBoZWxkIGluIHNlcGFyYXRlIFZORiBQb29scy4gVk5GIFBvb2wgY29tcG9zZWQg YnkgYm90aCB2aXJ0dWFsaXplZCBhbmQgbm9uLXZpcnR1YWxpemVkIGZ1bmN0aW9uYWwgaW5zdGFu Y2VzIG1heSBiZSBpbmNsdWRlZCBhZnRlciBmdXJ0aGVyIHVzZSBjYXNlIGFuZCByZXF1aXJlbWVu dHMgc3R1ZHkuIFRoZQ0KIFdHIHdpbGwgYWRkcmVzcyB0aGUgcmVsaWFiaWxpdHkgb2YgYW4gaW5k aXZpZHVhbCBWTkYsIGJ1dCBub3QgdGhlIHJlbGlhYmlsaXR5IHJlbGF0ZWQNCjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+dG8gdGhlIGNvbnRyb2wgb3IgdGhlIHJvdXRpbmcgYmV0d2VlbiBhZGph Y2VudCBWTkZzIDwvc3Bhbj4NCjxzcGFuIGxhbmc9IkRFIj50aGF0IGNhbiBmb3JtIGEgbmV0d29y ayBzZXJ2aWNlPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0Om5vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPlNwZWNpZmljYWxseSwgdGhlIFdHIHdpbGwgd29yayBvbiB0aGUgZm9sbG93 aW5nIHRlY2huaWNhbCBhc3BlY3RzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzguODVwdDt0ZXh0LWluZGVudDot MjEuMHB0O2xpbmUtaGVpZ2h0Om5vcm1hbDttc28tbGlzdDpsMiBsZXZlbDEgbGZvOCI+DQo8IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OlN5 bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWR1bmRhbmN5IG1hbmFnZW1lbnQgd2l0 aGluIGEgVk5GIFBvb2wsIHN1Y2ggYXMgdGhlIHNpZ25hbGluZyBiZXR3ZWVuIHRoZSBQb29sIE1h bmFnZXIgYW5kIHRoZSBpbnN0YW5jZXMgaW4gdGhlIHBvb2wgZm9yIGluc3RhbmNlIHJlZ2lzdHJh dGlvbiwgYmFja3VwIGluc3RhbmNlcyBzZWxlY3Rpb24sIGFuZCBzd2l0Y2hpbmcgYmV0d2VlbiBh Y3RpdmUgYW5kIHN0YW5kYnkNCiBpbnN0YW5jZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDozOC44NXB0O3RleHQt aW5kZW50Oi0yMS4wcHQ7bGluZS1oZWlnaHQ6bm9ybWFsO21zby1saXN0OmwyIGxldmVsMSBsZm84 Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBwcm90b2NvbCBiZXR3 ZWVuIHRoZSBQb29sIE1hbmFnZXIgYW5kIHRoZSB1bmRlcmx5aW5nIG5ldHdvcmsgdG8gY29sbGVj dCB0aGUgbmV0d29yayBpbmZvcm1hdGlvbiByZXF1aXJlZCBmb3IgYXBwcm9wcmlhdGUgcGxhY2Vt ZW50L3NlbGVjdGlvbiBvZiBiYWNrdXAgaW5zdGFuY2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzguODVwdDt0 ZXh0LWluZGVudDotMjEuMHB0O2xpbmUtaGVpZ2h0Om5vcm1hbDttc28tbGlzdDpsMiBsZXZlbDEg bGZvOCI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBz dHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu Pjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgcHJvdG9jb2wg YmV0d2VlbiBhIFZORiBhbmQgdGhlIHNlcnZpY2UgY29udHJvbCBlbnRpdHkgdG8gZXhjaGFuZ2Ug b3BlcmF0aW9uYWwgaW5mb3JtYXRpb24gYmV0d2VlbiBhIFZORiBQb29sPC9zcGFuPjxzcGFuIGxh bmc9IkRFIj4gYW5kIHRoZSBzZXJ2aWNlIGNvbnRyb2wgZW50aXR5Ljwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJtYXJnaW4tbGVmdDozOC44NXB0O3RleHQtaW5kZW50Oi0yMS4wcHQ7bGluZS1o ZWlnaHQ6bm9ybWFsO21zby1saXN0OmwyIGxldmVsMSBsZm84Ij4NCjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ PHNwYW4gbGFuZz0iRU4tVVMiPklkZW50aWZ5IGFuZCBhbmFseXplIHJlbGlhYmxlIGludGVyZmFj ZXMsIHN1Y2ggYXMgdHJhbnNwb3J0IHByb3RvY29sIGxpa2UgTVBUQ1AgYW5kIFNDVFAgZm9yIHJl bGlhYmxlIGRlbGl2ZXJ5IG9mIHRoZSBtZXNzYWdlcyBhc3NvY2lhdGVkIHdpdGggdGhlIHJlZHVu ZGFuY3kgbWFuYWdlbWVudCB3aXRoaW4gYSBWTkYgUG9vbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM4Ljg1cHQ7 dGV4dC1pbmRlbnQ6LTIxLjBwdDtsaW5lLWhlaWdodDpub3JtYWw7bXNvLWxpc3Q6bDIgbGV2ZWwx IGxmbzgiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyI+QW5hbHlzaXMgb2Yg cG9vbGluZyBzZWN1cml0eSBjaGFyYWN0ZXJpc3RpY3MgYW5kIHJlcXVpcmVtZW50cyB0byBpZGVu dGlmeSBhbmQgbWl0aWdhdGUgdGhyZWF0cyBhZ2FpbnN0IHRoZSBwb29saW5nIG1lY2hhbmlzbS4g SWRlbnRpZmljYXRpb24gb2YgYW4gYXBwcm9wcmlhdGUgdHJ1c3QgbW9kZWwgYmV0d2VlbiBwb29s IG1lbWJlcnMsIGFuZCBiZXR3ZWVuIHBvb2wNCiBtZW1iZXJzIGFuZCB0aGUgUG9vbCBNYW5hZ2Vy LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5l LWhlaWdodDpub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgV0cgcGxhbnMgdG8gZGVsaXZl ciBhIHByb2JsZW0gc3RhdGVtZW50LCBhIHNldCBvZiB1c2UgY2FzZXMsIHJlcXVpcmVtZW50cyBh bmQgYW4gYXJjaGl0ZWN0dXJlIGNvdmVyaW5nIHRoZSBhZm9yZW1lbnRpb25lZCB0ZWNobmljYWwg YXNwZWN0cywgYW5kIGFwcGxpY2FiaWxpdHkgYW5kIGdhcCBhbmFseXNpcyBvZiBleGlzdGluZw0K IHRlY2hub2xvZ2llcyBpbmNsdWRpbmcgYnV0IG5vdCBsaW1pdGVkIHRvIFJTZXJQb29sLiBXZSB3 aWxsIHJlbHkgaGVhdmlseSBvbiBleGlzdGluZyBJRVRGIHRlY2hub2xvZ2llcywgYnV0IHRoYXQg Z2FwcyB3aWxsIGJlIGZvdW5kIGFyb3VuZCBwcm9ibGVtcyBsaWtlIHJlZHVuZGFuY3kgbWVjaGFu aXNtcywgc3RhdGUgbWFpbnRlbmFuY2U8L3NwYW4+PHNwYW4gbGFuZz0iREUiPiBzb2xlbHkgZm9y IHBvb2xpbmcgcHVycG9zZXM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiwNCiByZWxpYWJsZSB0 cmFuc3BvcnQsIGFuZCB0cnVzdC9zZWN1cml0eSwgYWxsIG9mIHdoaWNoIHdpbGwgbmVlZCB0byBi ZSBjb25zaWRlcmVkIGFuZCBhZGRyZXNzZWQuIEFsdGhvdWdoIG5vIGRlY2lzaW9uIG9uIHByb3Rv Y29scyB3aWxsIGJlIG1hZGUgaW4gdGhpcyBwaGFzZSwgd2Ugd2lsbCBrZWVwIG9wZW4gZm9yIGNh bmRpZGF0ZSBwcm90b2NvbHMgZm9yIFZORiBQb29sLiBUaGUgV0cgd2lsbCBzZWVrIHJlLWNoYXJ0 ZXJpbmcgYmVmb3JlIGFkb3B0aW5nDQogYW55IHdvcmsgdG8gZGV2ZWxvcCBuZXcsIG9yIGV4dGVu ZCBleGlzdGluZywgcHJvdG9jb2xzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDpub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5J biBwYXJ0aWN1bGFyLCB3ZSB3aWxsIHdvcmsgY2xvc2VseSB3aXRoIHRoZSBTRkMgV0csIGFzIHdl IGJlbGlldmUgdGhhdCBTRkMgYW5kIFZORiBQb29sIGFyZSBpbmRlcGVuZGVudCBidXQgY29tcGxl bWVudGFyeS4gU0ZDIHdvdWxkIGVzc2VudGlhbGx5IHNlZSBhIFZORiBQb29sLWVuYWJsZWQgVk5G IGFzIGEgbm9ybWFsIHNlcnZpY2UNCiBmdW5jdGlvbiBhbmQgdGhlcmVmb3JlIGJlIGFibGUgdG8g bWVyZ2UgaXQgaW50byBhbiBTRkMganVzdCBsaWtlIGFueSBvdGhlciBzZXJ2aWNlIGZ1bmN0aW9u cy4gSnVzdCBsaWtlIHRoZSBjb21tdW5pY2F0aW9uIGJldHdlZW4gYW55IHBvb2wgdXNlcnMgYW5k IFZORiBQb29sLCB0aGUgaW5mb3JtYXRpb24gZXhjaGFuZ2VkIGJldHdlZW4gdGhlIFZORiBQb29s IGFuZCB0aGUgU0ZDIG1heSBpbmNsdWRlIHNvbWUgb3BlcmF0aW9uYWwgaW5mb3JtYXRpb24NCiBv ZiB0aGUgVk5GIFBvb2wuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImxpbmUtaGVpZ2h0Om5vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkdvYWxzIGFu ZCBNaWxlc3RvbmVzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJsaW5lLWhlaWdodDpub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5EZWNlbWJlciAy MDE0IC0gU3VibWl0IFZORlBvb2wgUHJvYmxlbSBTdGF0ZW1lbnQgdG8gSUVTRyBmb3IgcHVibGlj YXRpb24gYXMgYW4gSW5mb3JtYXRpb25hbCBkb2N1bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6bm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+QXByaWwgMjAxNSAtIFN1Ym1pdCBWTkZQb29sIFVzZSBDYXNlcyB0byBJRVNH IGZvciBwdWJsaWNhdGlvbiBhcyBhbiBJbmZvcm1hdGlvbmFsIGRvY3VtZW50LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDpub3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BdWd1c3QgMjAxNSAtIFN1Ym1pdCBWTkZQb29sIFJlcXVp cmVtZW50cywgaW5jbHVkaW5nIHRoZSBtYW5hZ2VhYmlsaXR5IG9mIFZORiBQb29sIHRvIElFU0cg Zm9yIHB1YmxpY2F0aW9uIGFzIGFuIEluZm9ybWF0aW9uYWwgZG9jdW1lbnQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0Om5vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPkF1Z3VzdCAyMDE1IC0gU3VibWl0IFZORlBvb2wgQXJjaGl0 ZWN0dXJlIHRvIElFU0cgZm9yIHB1YmxpY2F0aW9uIGFzIGFuIEluZm9ybWF0aW9uYWwgZG9jdW1l bnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Imxp bmUtaGVpZ2h0Om5vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkRlY2VtYmVyIDIwMTUgLSBTdWJt aXQgb25lIG9yIG1vcmUgQXBwbGljYWJpbGl0eSBhbmQgR2FwIEFuYWx5c2lzIG9mIGV4aXN0aW5n IHByb3RvY29scyB0byBWTkZQb29sIHRvIElFU0cgZm9yIHB1YmxpY2F0aW9uIGFzIEluZm9ybWF0 aW9uYWwgZG9jdW1lbnQocykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0Om5vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImxpbmUtaGVpZ2h0Om5vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPllvdXIgY29tbWVu dHMgYW5kIHN1Z2dlc3Rpb25zIHRvIHRoZSBjaGFydGVyIGFyZSBBTFdBWVMgaGlnaGx5IGFwcHJl Y2lhdGVkITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJsaW5lLWhlaWdodDpub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFua3MuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0Om5v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPi1OaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHBy ZSBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtsaW5lLWhlaWdodDoxNTAlO2ZvbnQtZmFtaWx5 OuWui+S9kyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJv dHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 bGluZS1oZWlnaHQ6MTUwJTtmb250LWZhbWlseTrlrovkvZMiPnZuZnBvb2wgbWFpbGluZyBsaXN0 PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1i b3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2xpbmUtaGVpZ2h0OjE1MCU7Zm9udC1mYW1pbHk65a6L5L2TIj48YSBocmVmPSJtYWlsdG86dm5m cG9vbEBpZXRmLm9yZyI+dm5mcG9vbEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bGluZS1oZWlnaHQ6MTUwJTtmb250 LWZhbWlseTrlrovkvZMiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdm5mcG9vbCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92bmZw b29sPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_B0D29E0424F2DE47A0B36779EC6667796616C55Fnkgeml501mbschi_-- From nobody Wed Jul 2 01:41:18 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A36651A00F2 for ; Wed, 2 Jul 2014 01:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHnQOSQZ7X2t for ; Wed, 2 Jul 2014 01:41:13 -0700 (PDT) Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 7371E1A019D for ; Wed, 2 Jul 2014 01:41:12 -0700 (PDT) Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7664E1074003; Wed, 2 Jul 2014 10:41:11 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.orange.com (Postfix) with ESMTP id 23A8D1074002; Wed, 2 Jul 2014 10:41:11 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Jul 2014 10:41:11 +0200 Received: from [10.193.5.40] ([10.193.5.40]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Jul 2014 10:41:10 +0200 Message-ID: <53B3C5A6.2000408@orange.com> Date: Wed, 02 Jul 2014 10:41:10 +0200 From: LAC Chidung User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Linda Dunbar References: <53A1C0E0.1090301@orange.com> <53AC33C8.9060700@orange.com> <53AD382A.5050009@orange.com> <4A95BA014132FF49AE685FAB4B9F17F645D6F39C@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D6F39C@dfweml701-chm.china.huawei.com> Content-Type: multipart/alternative; boundary="------------070803020106060903060606" X-OriginalArrivalTime: 02 Jul 2014 08:41:10.0384 (UTC) FILETIME=[5FBB2F00:01CF95D1] Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/16jT9SHof_eVmpIl9iAx6QKDOYc Cc: "vnfpool@ietf.org" , Zongning Subject: Re: [vnfpool] =?utf-8?b?562U5aSNOiDnrZTlpI06ICDnrZTlpI06IFVwZGF0ZWQg?= =?utf-8?q?VNFPool_Charter?= X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 08:41:16 -0000 This is a multi-part message in MIME format. --------------070803020106060903060606 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Linda, 1) IMHO, the difficulty is to marry the pool and the NFV scaling in/out concepts. Actually, the lower part of the picture (called "VNF") should be appropriate to the NFV environment, but using the expression "pool" for it is not necessary, i.e., what means "pool" in the case where a single VNF instance is sufficient to treat the load ? We definitively need to comprehend "pool" differently (compared to the PNF context) ... If scaling in/out is used, it is hard to imagine how to exempt the architecture from including a mechanism to distribute the load among the different instances. Furthermore, as Ning wrote to Adrian on June 27th "/You are right that a VNF pool appears as a single instance to outside entity such as service control entity/": as the pool is hidden, the load sent to the pool's elements (VNF instances in the NFV context) goes necessarily to a single address (which could be redundant for HA purposes), leaving to this entity the job to distribute the load. 2) If "/the Model 1/" = no redundancy, IMO, stateful/stateless and no_redundancy/redundancy are independent. If there is a need for (high) availability, stateless VNF redundancy should be carried out (and is usually much more easy than stateful redundancy). Best, Chidung Le 01/07/2014 01:17, Linda Dunbar a écrit : > > Chidung, > A few questions to your attached file: > -All the models assume that there is a central LBM that traffic > traverse through. I would think that VNFpool doesn’t require the > traffic to go through a single point of LB. Correct? > -1+1 protection can be very expensive. I would think only the stateful > VNF might need 1+1 or N+K protection. For stateless VNF, the Model 1 > should be used. > My two cents, > Linda > > *From:*vnfpool [mailto:vnfpool-bounces@ietf.org] *On Behalf Of *LAC > Chidung > *Sent:* Friday, June 27, 2014 4:24 AM > *To:* Zongning > *Cc:* vnfpool@ietf.org > *Subject:* Re: [vnfpool] 答复: 答复: 答复: Updated VNFPool Charter > > Hi Ning, > 1- On further consideration, my remark (i) in the previous e-mail > ("/no redundancy at all ...../") should not be applied in the VNF > context if the intention is to use a pool for redundancy purposes > *while minimizing the needed resources*. As shown in the figure > enclosed, this PNF scheme (no redundancy at all, i.e., all instances > of the pool participate actively) is not applicable in the VNF > framework where additional instances are created *only* if needed. > 2- Back to your e-mail of June 19th "/the VNF instance scaling within > a VNF pool is included in the charter/": I don't think "scaling", > "scalability" appearing in the charter - it would be nice to introduce > a sentence (somewhere) with one of these two words to avoid this > ambiguity. Again, scaling in/out is one main characteristic of VNF. > Best, > Chidung > > Le 27/06/2014 03:36, Zongning a écrit : > > Hi, Chidung, > Thanks for your suggestions. I will make the text clear for > comment Z2. But for comment Z9, I’d prefer to keep “VNF Pool”, as > we don’t propose/discuss a concrete VNF Pool architecture in the > charter, but just introduce a general concept. > Look forward to your further comments. > -Ning > > *发****件人**:*LAC Chidung [mailto:chidung.lac@orange.com] > *发****送时间**:*2014年6月26日22:53 > *收件人**:*Zongning > *抄送**:*vnfpool@ietf.org > *主题**:*Re: 答复: [vnfpool] 答复: Updated VNFPool Charter > > Hi Ning, > Thank you for the reply. Some comments/suggestions to your: > * comment Z2: I knew that the « elementary » NFs are part of the > job, but wanted to suggest to add something in this section to > avoid readers to perceive the wrong feeling mentioned in my > comment #1 > * comment Z7: Thank you for this clarification. I thus understand > that three types of pools (and not more than three) may exist: > - (i) no redundancy at all, i.e., all instances of the pool > participate actively - an upstream load balancing mechanism shares > the incoming load among these instances; > - (ii) 1:1 (active-active) redundancy - for example, 5 > "images" (to avoid the word 'instance') of the VNF, and each of > them is redundant -> in this case, there are 10 instances running > in parallel in the pool; > - (iii) N+K (active-standby) redundancy where some instances > run actively, while others are in a dormant state. > > * comment Z9: How about this add-on then ? "... achieved by the > VNF Pool *architecture* utilized/adopted by the VNF ..." > Best, > Chidung > > Le 19/06/2014 05:14, Zongning a écrit : > > Hi, Chidung, > Please see my reply enclosed in the attachment. Regarding > comment#6, I’d like to explain that we don’t restrict to the > case that in a pool, at a given time, there is only one > running instance and all others are sleeping. A pool should be > flexible to handle more cases, including multiple running > instances and multiple standby instances. > Look forward to your further comments & suggestions. > -Ning > > *发****件人**:*LAC Chidung [mailto:chidung.lac@orange.com] > *发****送时间**:*2014年6月19日0:40 > *收件人**:*Zongning > *抄送**:*vnfpool@ietf.org > *主题**:*Re: [vnfpool] 答复: Updated VNFPool Charter > > Hi Ning, > 1) Is it exact that scaling out/in, one main characteristic of > VNFs (compared to PNFs), is not included ? > 2) Some comments/suggestions are enclosed. > Best, > Chidung > > Le 12/06/2014 05:38, Zongning a écrit : > > Dear all, > Please review the charter text included in the last email. > We are hoping that a general consensus on the charter > could be achieved on the list, then a stable charter is > ready for the VNFPool session in Toronto. > Thanks. > -Ning > > *发件人**:*vnfpool [mailto:vnfpool-bounces@ietf.org] * > 代****表***Zongning > *发****送时间**:*2014年6月12日11:20 > *收件人**:*vnfpool@ietf.org > *主题**:*[vnfpool] Updated VNFPool Charter > > Dear all, > > Based on the list discussion since we posted the last > version, I have made some (minor) revision of the charter. > The main changes are: > > 1)State that service state synchronization is out of scope > “in this phase”; > > 2)Include VNF Pool with both virtualized and > non-virtualized network function for further study; > > 3)Explicitly state that the reference solution & gap > analysis is not limited to RSerPool, but open to any other > solutions, although no decision on protocols will be made > in this phase; > > 4)State that the linkage between SFC and VNF Pool is just > like a pool user and a pool – nothing specified (yet); > > 5)Update bullet #4 under “Questions that are raised…”, to > keep it consistent with the idea that pooling is not > visible to the service control entity. > > ========================================================================== > > Network functions such as firewalls, load balancers, and > WAN optimizers are conventionally deployed as specialized > hardware servers in both network operators' networks and > data center networks as the building blocks of the network > services. There is a trend to implement such network > functions as software instances running on general purpose > servers, via a virtualization layer (i.e., hypervisors). > These virtualized functions are called Virtualized Network > Functions (VNFs), which can be used to build network services. > > The use of VNFs introduces additional challenges to the > reliability of the provided network services. A single VNF > instance would typically not have built-in reliability > mechanisms on its host (i.e., a general purpose server). > Instead, there are more factors of risk such as software > failure at various levels including hypervisors and > virtual machines, hardware failure, and instance migration > that can make a VNF instance unreliable. > > In order to achieve higher reliability, a VNF may adopt a > pooling mechanism, where a number of VNF instances with > the same function can be grouped as a pool to provide the > function. We call such a pool a VNF Pool.Conceptually, a > Pool Manager is used to manage a VNF Pool, e.g., selects > active/standby VNF instances, and potentially interacts > with a service control entity. Such a service control > entity is an entity that orchestrates a set of network > functions to build network services. The major benefit of > using VNF Pool is that reliability mechanisms such as > redundancy model are achieved by the VNF Pool inside the > VNF and thus not visible to the service control entity. A > VNF Pool-enabled VNF still appears as a normal VNF when > orchestrated by a service control entity. > > Questions that are raised by the addition of a pooling > mechanism to VNF include: > > ·How to manage the redundancy model, e.g., select > active/standby VNF instances in a VNF Pool? > > ·What pool states need to be maintained to support the > pooling mechanism itself, and how are such states maintained? > > ·What information is exchanged between a VNF and a service > control entity? For example, how can a VNF Pool be > addressed by the service control entity? > > ·After a VNF instance failover, how does the Pool Manager > notify the service control entity some characteristic > changes of the VNF, e.g., capacity change, but without > disclosure of the pooling procedure? > > The WG initially focuses on several reliability mechanisms > that are mainly associated with a redundancy model based > on a VNF Pool. Additional mechanisms may include pool > state maintenance only for pooling purpose. Service state > synchronization is out of scope for this phase. The WG > assumes that a VNF Pool contains redundant VNF instances > of same functional type. Different types of VNFs are > envisioned to be held in separate VNF Pools. VNF Pool > composed by both virtualized and non-virtualized > functional instances may be included after further use > case and requirements study. The WG will address the > reliability of an individual VNF, but not the reliability > related to the control or the routing between adjacent > VNFs that can form a network service. > > Specifically, the WG will work on the following technical > aspects: > > ·Redundancy management within a VNF Pool, such as the > signaling between the Pool Manager and the instances in > the pool for instance registration, backup instances > selection, and switching between active and standby instances. > > ·The protocol between the Pool Manager and the underlying > network to collect the network information required for > appropriate placement/selection of backup instances. > > ·The protocol between a VNF and the service control entity > to exchange operational information between a VNF Pooland > the service control entity. > > ·Identify and analyze reliable interfaces, such as > transport protocol like MPTCP and SCTP for reliable > delivery of the messages associated with the redundancy > management within a VNF Pool. > > ·Analysis of pooling security characteristics and > requirements to identify and mitigate threats against the > pooling mechanism. Identification of an appropriate trust > model between pool members, and between pool members and > the Pool Manager. > > The WG plans to deliver a problem statement, a set of use > cases, requirements and an architecture covering the > aforementioned technical aspects, and applicability and > gap analysis of existing technologies including but not > limited to RSerPool. We will rely heavily on existing IETF > technologies, but that gaps will be found around problems > like redundancy mechanisms, state maintenancesolely for > pooling purposes, reliable transport, and trust/security, > all of which will need to be considered and addressed. > Although no decision on protocols will be made in this > phase, we will keep open for candidate protocols for VNF > Pool. The WG will seek re-chartering before adopting any > work to develop new, or extend existing, protocols. > > In particular, we will work closely with the SFC WG, as we > believe that SFC and VNF Pool are independent but > complementary. SFC would essentially see a VNF > Pool-enabled VNF as a normal service function and > therefore be able to merge it into an SFC just like any > other service functions. Just like the communication > between any pool users and VNF Pool, the information > exchanged between the VNF Pool and the SFC may include > some operational information of the VNF Pool. > > Goals and Milestones: > > December 2014 - Submit VNFPool Problem Statement to IESG > for publication as an Informational document. > > April 2015 - Submit VNFPool Use Cases to IESG for > publication as an Informational document. > > August 2015 - Submit VNFPool Requirements, including the > manageability of VNF Pool to IESG for publication as an > Informational document. > > August 2015 - Submit VNFPool Architecture to IESG for > publication as an Informational document. > > December 2015 - Submit one or more Applicability and Gap > Analysis of existing protocols to VNFPool to IESG for > publication as Informational document(s). > > ========================================================================== > > Your comments and suggestions to the charter are ALWAYS > highly appreciated! > > Thanks. > > -Ning > > _______________________________________________ > > vnfpool mailing list > > vnfpool@ietf.org > > https://www.ietf.org/mailman/listinfo/vnfpool > --------------070803020106060903060606 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Linda,
1) IMHO, the difficulty is to marry the pool and the NFV scaling in/out concepts. Actually, the lower part of the picture (called "VNF") should be appropriate to the NFV environment, but using the expression "pool" for it is not necessary, i.e., what means "pool" in the case where a single VNF instance is sufficient to treat the load ? We definitively need to comprehend "pool" differently (compared to the PNF context) ...
If scaling in/out is used, it is hard to imagine how to exempt the architecture from including a mechanism to distribute the load among the different instances.
Furthermore, as Ning wrote to Adrian on June 27th "You are right that a VNF pool appears as a single instance to outside entity such as service control entity": as the pool is hidden, the load sent to the pool's elements (VNF instances in the NFV context) goes necessarily to a single address (which could be redundant for HA purposes), leaving to this entity the job to distribute the load.
2) If "the Model 1" = no redundancy, IMO, stateful/stateless and no_redundancy/redundancy are independent. If there is a need for (high) availability, stateless VNF redundancy should be carried out (and is usually much more easy than stateful redundancy).
Best,
Chidung
Le 01/07/2014 01:17, Linda Dunbar a écrit :

Chidung,
A few questions to your attached file:
-          All the models assume that there is a central LBM that traffic traverse through. I would think that VNFpool doesn’t require the traffic to go through a single point of LB. Correct?
-          1+1 protection can be very expensive. I would think only the stateful VNF might need 1+1 or N+K protection. For stateless VNF, the Model 1 should be used.
My two cents,
Linda

From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of LAC Chidung
Sent: Friday, June 27, 2014 4:24 AM
To: Zongning
Cc: vnfpool@ietf.org
Subject: Re: [vnfpool] 答复: 答复: 答复: Updated VNFPool Charter

 

Hi Ning,
1- On further consideration, my remark (i) in the previous e-mail ("no redundancy at all .....") should not be applied in the VNF context if the intention is to use a pool for redundancy purposes while minimizing the needed resources. As shown in the figure enclosed, this PNF scheme (no redundancy at all, i.e., all instances of the pool participate actively) is not applicable in the VNF framework where additional instances are created only if needed.
2- Back to your e-mail of June 19th "the VNF instance scaling within a VNF pool is included in the charter": I don't think "scaling", "scalability" appearing in the charter - it would be nice to introduce a sentence (somewhere) with one of these two words to avoid this ambiguity. Again, scaling in/out is one main characteristic of VNF.
Best,
Chidung

Le 27/06/2014 03:36, Zongning a écrit :

Hi, Chidung,
Thanks for your suggestions. I will make the text clear for comment Z2. But for comment Z9, I’d prefer to keep “VNF Pool”, as we don’t propose/discuss a concrete VNF Pool architecture in the charter, but just introduce a general concept.
Look forward to your further comments.
-Ning

发 件人: LAC Chidung [mailto:chidung.lac@orange.com]
发 送时间: 2014年6月26日 22:53
收件人: Zongning
抄送: vnfpool@ietf.org
主题: Re: 答复: [vnfpool] 答复: Updated VNFPool Charter

 

Hi Ning,
Thank you for the reply. Some comments/suggestions to your:
* comment Z2: I knew that the « elementary » NFs are part of the job, but wanted to suggest to add something in this section to avoid readers to perceive  the wrong feeling mentioned in my comment #1
* comment Z7: Thank you for this clarification. I thus understand that three types of pools (and not more than three) may exist:
     - (i) no redundancy at all, i.e., all instances of the pool participate actively - an upstream load balancing mechanism shares the incoming load among these instances;
     - (ii) 1:1 (active-active) redundancy - for example, 5 "images" (to avoid the word 'instance') of the VNF, and each of them is redundant -> in this case, there are 10 instances running in parallel in the pool;
     - (iii) N+K (active-standby) redundancy where some instances run actively, while others are in a dormant state.

* comment Z9: How about this add-on then ? "... achieved by the VNF Pool architecture utilized/adopted by the VNF ..."
Best,
Chidung

Le 19/06/2014 05:14, Zongning a écrit :

Hi, Chidung,
Please see my reply enclosed in the attachment. Regarding comment#6, I’d like to explain that we don’t restrict to the case that in a pool, at a given time, there is only one running instance and all others are sleeping. A pool should be flexible to handle more cases, including multiple running instances and multiple standby instances.
Look forward to your further comments & suggestions.
-Ning

 

发 件人: LAC Chidung [mailto:chidung.lac@orange.com]
发 送时间: 2014年6月19日 0:40
收件人: Zongning
抄送: vnfpool@ietf.org
主题: Re: [vnfpool] 答复: Updated VNFPool Charter

 

Hi Ning,
1) Is it exact that scaling out/in, one main characteristic of VNFs (compared to PNFs), is not included ?
2) Some comments/suggestions are enclosed.
Best,
Chidung

Le 12/06/2014 05:38, Zongning a écrit :

Dear all,
Please review the charter text included in the last email. We are hoping that a general consensus on the charter could be achieved on the list, then a stable charter is ready for the VNFPool session in Toronto.
Thanks.
-Ning

发件人: vnfpool [mailto:vnfpool-bounces@ietf.org] 代 表 Zongning
发 送时间: 2014年6月12日 11:20
收件人: vnfpool@ietf.org
主题: [vnfpool] Updated VNFPool Charter

 

Dear all,

Based on the list discussion since we posted the last version, I have made some (minor) revision of the charter. The main changes are:

1)       State that service state synchronization is out of scope “in this phase”;

2)       Include VNF Pool with both virtualized and non-virtualized network function for further study;

3)       Explicitly state that the reference solution & gap analysis is not limited to RSerPool, but open to any other solutions, although no decision on protocols will be made in this phase;

4)       State that the linkage between SFC and VNF Pool is just like a pool user and a pool – nothing specified (yet);

5)       Update bullet #4 under “Questions that are raised…”, to keep it consistent with the idea that pooling is not visible to the service control entity.

==========================================================================

Network functions such as firewalls, load balancers, and WAN optimizers are conventionally deployed as specialized hardware servers in both network operators' networks and data center networks as the building blocks of the network services. There is a trend to implement such network functions as software instances running on general purpose servers, via a virtualization layer (i.e., hypervisors). These virtualized functions are called Virtualized Network Functions (VNFs), which can be used to build network services.

The use of VNFs introduces additional challenges to the reliability of the provided network services. A single VNF instance would typically not have built-in reliability mechanisms on its host (i.e., a general purpose server). Instead, there are more factors of risk such as software failure at various levels including hypervisors and virtual machines, hardware failure, and instance migration that can make a VNF instance unreliable.

In order to achieve higher reliability, a VNF may adopt a pooling mechanism, where a number of VNF instances with the same function can be grouped as a pool to provide the function. We call such a pool a VNF Pool.Conceptually, a Pool Manager is used to manage a VNF Pool, e.g., selects active/standby VNF instances, and potentially interacts with a service control entity. Such a service control entity is an entity that orchestrates a set of network functions to build network services. The major benefit of using VNF Pool is that reliability mechanisms such as redundancy model are achieved by the VNF Pool inside the VNF and thus not visible to the service control entity. A VNF Pool-enabled VNF still appears as a normal VNF when orchestrated by a service control entity.

Questions that are raised by the addition of a pooling mechanism to VNF include:

·     How to manage the redundancy model, e.g., select active/standby VNF instances in a VNF Pool?

·     What pool states need to be maintained to support the pooling mechanism itself, and how are such states maintained?

·     What information is exchanged between a VNF and a service control entity? For example, how can a VNF Pool be addressed by the service control entity?

·     After a VNF instance failover, how does the Pool Manager notify the service control entity some characteristic changes of the VNF, e.g., capacity change, but without disclosure of the pooling procedure?

The WG initially focuses on several reliability mechanisms that are mainly associated with a redundancy model based on a VNF Pool. Additional mechanisms may include pool state maintenance only for pooling purpose. Service state synchronization is out of scope for this phase. The WG assumes that a VNF Pool contains redundant VNF instances of same functional type. Different types of VNFs are envisioned to be held in separate VNF Pools. VNF Pool composed by both virtualized and non-virtualized functional instances may be included after further use case and requirements study. The WG will address the reliability of an individual VNF, but not the reliability related to the control or the routing between adjacent VNFs that can form a network service.

Specifically, the WG will work on the following technical aspects:

·        Redundancy management within a VNF Pool, such as the signaling between the Pool Manager and the instances in the pool for instance registration, backup instances selection, and switching between active and standby instances.

·        The protocol between the Pool Manager and the underlying network to collect the network information required for appropriate placement/selection of backup instances.

·        The protocol between a VNF and the service control entity to exchange operational information between a VNF Pool and the service control entity.

·        Identify and analyze reliable interfaces, such as transport protocol like MPTCP and SCTP for reliable delivery of the messages associated with the redundancy management within a VNF Pool.

·        Analysis of pooling security characteristics and requirements to identify and mitigate threats against the pooling mechanism. Identification of an appropriate trust model between pool members, and between pool members and the Pool Manager.

The WG plans to deliver a problem statement, a set of use cases, requirements and an architecture covering the aforementioned technical aspects, and applicability and gap analysis of existing technologies including but not limited to RSerPool. We will rely heavily on existing IETF technologies, but that gaps will be found around problems like redundancy mechanisms, state maintenance solely for pooling purposes, reliable transport, and trust/security, all of which will need to be considered and addressed. Although no decision on protocols will be made in this phase, we will keep open for candidate protocols for VNF Pool. The WG will seek re-chartering before adopting any work to develop new, or extend existing, protocols.

In particular, we will work closely with the SFC WG, as we believe that SFC and VNF Pool are independent but complementary. SFC would essentially see a VNF Pool-enabled VNF as a normal service function and therefore be able to merge it into an SFC just like any other service functions. Just like the communication between any pool users and VNF Pool, the information exchanged between the VNF Pool and the SFC may include some operational information of the VNF Pool.

Goals and Milestones:

December 2014 - Submit VNFPool Problem Statement to IESG for publication as an Informational document.

April 2015 - Submit VNFPool Use Cases to IESG for publication as an Informational document.

August 2015 - Submit VNFPool Requirements, including the manageability of VNF Pool to IESG for publication as an Informational document.

August 2015 - Submit VNFPool Architecture to IESG for publication as an Informational document.

December 2015 - Submit one or more Applicability and Gap Analysis of existing protocols to VNFPool to IESG for publication as Informational document(s).

==========================================================================

Your comments and suggestions to the charter are ALWAYS highly appreciated!

Thanks.

-Ning

_______________________________________________
vnfpool mailing list
vnfpool@ietf.org
https://www.ietf.org/mailman/listinfo/vnfpool
--------------070803020106060903060606-- From nobody Thu Jul 3 18:37:11 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8821B289A for ; Thu, 3 Jul 2014 18:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.851 X-Spam-Level: X-Spam-Status: No, score=-104.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EO6HSMGcubpd for ; Thu, 3 Jul 2014 18:37:04 -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 8E2731A045D for ; Thu, 3 Jul 2014 18:37:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJP57394; Fri, 04 Jul 2014 01:37:02 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 4 Jul 2014 02:37:01 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Fri, 4 Jul 2014 09:36:57 +0800 From: Zongning To: "vnfpool@ietf.org" Thread-Topic: New Charter for Toronto Thread-Index: Ac+XKHD4e3Tyhku3QbmwqloaWSCkww== Date: Fri, 4 Jul 2014 01:36:56 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.54] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC6667796616CDC0nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/L3MQxDBGXBSnizjBUe2LU_t1Pqc Subject: [vnfpool] New Charter for Toronto X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 01:37:07 -0000 --_000_B0D29E0424F2DE47A0B36779EC6667796616CDC0nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all, Please find below the new VNFPool Charter, by which I'd like to keep entert= aining you. :) This new version is based on the list discussion and feedback mainly from L= AC Chidung, Hidetoshi, Sood, and Adrian. Thank you guys for improving our c= harter. Although I'd regard this version as a stable charter that reflects = a rough agreement on the list and is ready for Toronto, further comments an= d suggestions are *always* welcome. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Network functions such as firewalls, load balancers, and WAN optimizers are= conventionally deployed as specialized hardware servers in both network op= erators' networks and data center networks as the building blocks of networ= k services. There is a trend to implement such network functions as softwar= e instances running on general purpose servers, via a virtualization layer = (i.e., hypervisors). These virtualized functions are called Virtualized Net= work Functions (VNFs), which can be used to build network services. The use of VNFs introduces additional challenges to the reliability of the = provided network services. A single VNF instance would typically not have b= uilt-in reliability mechanisms on its host (i.e., a general purpose server)= . Instead, there are more risk factors such as software failure at various = levels including hypervisors and virtual machines, hardware failure, and in= stance migration that can make a VNF instance unreliable. In order to achieve higher reliability, a VNF implementation may adopt a po= oling mechanism, where a number of VNF instances with the same function can= be grouped as a pool to provide the function. We call such a pool a VNF Po= ol. Conceptually, a Pool Manager is used to manage a VNF Pool, e.g., select= s active/standby VNF instances, and potentially interacts with a service co= ntrol entity. Such a service control entity is an entity that orchestrates = a set of network functions to build network services. The major benefit of = using VNF Pool is that reliability mechanisms such as redundancy model are = achieved by the VNF Pool adopted by the VNF and thus not visible to the ser= vice control entity. A VNF Pool-enabled VNF still appears as a normal VNF w= hen orchestrated by a service control entity. Questions that are raised by the addition of a pooling mechanism to VNF inc= lude: * How to manage the redundancy model, e.g., select active/standby= VNF instances in a VNF Pool considering the infrastructure conditions, and= scale a VNF instance in a VNF Pool? * What pool states need to be maintained to support the pooling m= echanism itself, and how are such states maintained? * What information is exchanged between a VNF and a service contr= ol entity? For example, how can a VNF Pool be addressed by the service cont= rol entity? * After a VNF instance failover, how does the Pool Manager notify= the service control entity of some characteristic changes of the VNF, e.g.= , capacity change, but without disclosure of the pooling procedure? The WG initially focuses on several reliability mechanisms that are mainly = associated with a redundancy model based on a VNF Pool. Additional mechanis= ms may include pool state maintenance only for pooling purpose. Service sta= te synchronization is out of scope for this phase. The WG assumes that a VN= F Pool contains redundant VNF instances of a same functional type. Differen= t types of VNFs are envisioned to be held in separate VNF Pools. VNF Pool c= omposed of both virtualized and non-virtualized functional instances may be= included after further use case and requirements study. The WG will addres= s the reliability of an individual VNF, but not the reliability related to = the control or the routing between adjacent VNFs that can form a network se= rvice. Specifically, the WG will study the following technical aspects: * Redundancy management within a VNF Pool, such as the signaling = between the Pool Manager and the instances in the pool for instance registr= ation, backup instances selection, and switching between active and standby= instances. * Protocol between the Pool Manager and the underlying network to= collect the network information required for appropriate placement/selecti= on of backup instances. * Protocol between a VNF and the service control entity to exchan= ge operational information between a VNF Pool and the service control entit= y. * Identification and analysis of reliable interfaces, such as tra= nsport protocol like MPTCP and SCTP for reliable delivery of the messages a= ssociated with the redundancy management within a VNF Pool. * Analysis of pooling security characteristics and requirements t= o identify and mitigate threats against the pooling mechanism. Identificati= on of an appropriate trust model between pool members, and between pool mem= bers and the Pool Manager. The WG plans to deliver a problem statement, a set of use cases, requiremen= ts and an architecture covering the aforementioned technical aspects, and g= ap analysis of existing technologies including but not limited to RSerPool.= We will rely heavily on existing IETF technologies, but that gaps will be = found around problems like redundancy mechanisms, state maintenance solely = for pooling purposes, reliable transport, and trust/security, all of which = will need to be considered and addressed. Although no decision on protocols= will be made in this phase, we will keep open for candidate protocols for = VNF Pool. The WG will seek re-chartering before adopting any work to develo= p new, or extend existing, protocols. We will work closely with the SFC WG, as we believe that SFC and VNF Pool a= re complementary. SFC would essentially see a VNF Pool-enabled VNF as a nor= mal service function and therefore be able to merge it into an SFC just lik= e any other service functions. Just like the communication between any pool= users and VNF Pool, the information exchanged between the VNF Pool and the= SFC may include some operational information of the VNF Pool. Goals and Milestones: December 2014 - Submit VNFPool Problem Statement to IESG for publication as= an Informational document. April 2015 - Submit VNFPool Use Cases to IESG for publication as an Informa= tional document. August 2015 - Submit VNFPool Requirements, including the manageability of V= NF Pool to IESG for publication as an Informational document. August 2015 - Submit VNFPool Architecture to IESG for publication as an Inf= ormational document. December 2015 - Submit one or more Applicability and Gap Analysis of existi= ng protocols to VNFPool to IESG for publication as Informational document(s= ). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Thanks. -Ning --_000_B0D29E0424F2DE47A0B36779EC6667796616CDC0nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi= , all,

Pl= ease find below the new VNFPool Charter, by which I’d like to keep en= tertaining you. J

Th= is new version is based on the list discussion and feedback mainly from LAC= Chidung, Hidetoshi, Sood, and Adrian. Thank you guys for improving our cha= rter. Although I’d regard this version as a stable charter that reflects a rough agreement on the list and is rea= dy for Toronto, further comments and suggestions are *always* welcom= e.

= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /span>

Ne= twork functions such as firewalls, load balancers, and WAN optimizers are c= onventionally deployed as specialized hardware servers in both network oper= ators' networks and data center networks as the building blocks of network services. There is a trend to implement = such network functions as software instances running on general purpose ser= vers, via a virtualization layer (i.e., hypervisors). These virtualized fun= ctions are called Virtualized Network Functions (VNFs), which can be used to build network services.<= /span>

Th= e use of VNFs introduces additional challenges to the reliability of the pr= ovided network services. A single VNF instance would typically not have bui= lt-in reliability mechanisms on its host (i.e., a general purpose server). Instead, there are more risk factors suc= h as software failure at various levels including hypervisors and virtual m= achines, hardware failure, and instance migration that can make a VNF insta= nce unreliable.

In= order to achieve higher reliability, a VNF implementation may adopt a pool= ing mechanism, where a number of VNF instances with the same function can b= e grouped as a pool to provide the function. We call such a pool a VNF Pool. Conceptually, a <= /span>Pool Manager is used to manage a VNF Pool, e.g.,= selects active/standby VNF instances, and potentially interacts with a ser= vice control entity. Such a service control= entity is an entity that orchestrates a set of network functions to build = network services. The major benefit of using VNF Pool is that reliability m= echanisms such as redundancy model are achieved by the VNF Pool adopted by the VNF and thus not visible to the se= rvice control entity. A VNF Pool-enabled VNF still appears as a normal VNF = when orchestrated by a service control enti= ty.

Qu= estions that are raised by the addition of a pooling mechanism to VNF inclu= de:

·          = ; How to manage the redun= dancy model, e.g., select active/standby VNF instances in a VNF Pool consid= ering the infrastructure conditions, and scale a VNF instance in a VNF Pool= ?

·          = ; What pool states need t= o be maintained to support the pooling mechanism itself, and how are such s= tates maintained?

·          = ; What information is exc= hanged between a VNF and a service control entity? For example, how can a V= NF Pool be addressed by the service control entity?

·          = ; After a VNF instance fa= ilover, how does the Pool Manager notify the service control entity of some= characteristic changes of the VNF, e.g., capacity change, but without disc= losure of the pooling procedure?

Th= e WG initially focuses on several reliability mechanisms that are mainly as= sociated with a redundancy model based on a VNF Pool. Additional mechanisms= may include pool state maintenance only for pooling purpose. Service state synchroniz= ation is out of scope for this phase. The WG as= sumes that a VNF Pool = contains redundant VNF instances of a same functional type. Different types of VNFs are envi= sioned to be held in separate VNF Pools. VNF Pool composed of both virtuali= zed and non-virtualized functional instances may be included after further = use case and requirements study. The WG will address the reliability of an individual VNF, but not the reliabil= ity related to the control or the routing between adjacent = VNFs that can form a network service.

Sp= ecifically, the WG will study the following technical aspects:

·          = ; Redundancy management w= ithin a VNF Pool, such as the signaling between the Pool Manager and the in= stances in the pool for instance registration, backup instances selection, = and switching between active and standby instances.

·          = ; Protocol between the Po= ol Manager and the underlying network to collect the network information re= quired for appropriate placement/selection of backup instances.<= /span>

·          = ; Protocol between a VNF = and the service control entity to exchange operational information between = a VNF Pool and the service control entity.<= span lang=3D"EN-US">

·          = ; Identification and anal= ysis of reliable interfaces, such as transport protocol like MPTCP and SCTP= for reliable delivery of the messages associated with the redundancy manag= ement within a VNF Pool.

·          = ; Analysis of pooling sec= urity characteristics and requirements to identify and mitigate threats aga= inst the pooling mechanism. Identification of an appropriate trust model be= tween pool members, and between pool members and the Pool Manager.

Th= e WG plans to deliver a problem statement, a set of use cases, requirements= and an architecture covering the aforementioned technical aspects, and gap= analysis of existing technologies including but not limited to RSerPool. We will rely heavily on existing IETF technol= ogies, but that gaps will be found around problems like redundancy mechanis= ms, state maintenance solely for pooling purposes<= /span>, reliable transport, and trust/security, all of which will need to be considered and= addressed. Although no decision on protocols will be made in this phase, w= e will keep open for candidate protocols for VNF Pool. The WG will seek re-= chartering before adopting any work to develop new, or extend existing, protocols.

We= will work closely with the SFC WG, as we believe that SFC and VNF Pool are= complementary. SFC would essentially see= a VNF Pool-enabled VNF as a normal service function and therefore be able to = merge it into an SFC just like any other service functions. Just like the communication between any pool users and VNF Pool, the information exc= hanged between the VNF Pool and the SFC may include some operational inform= ation of the VNF Pool.

Go= als and Milestones:

De= cember 2014 - Submit VNFPool Problem Statement to IESG for publication as a= n Informational document.

Ap= ril 2015 - Submit VNFPool Use Cases to IESG for publication as an Informati= onal document.

Au= gust 2015 - Submit VNFPool Requirements, including the manageability of VNF= Pool to IESG for publication as an Informational document.

Au= gust 2015 - Submit VNFPool Architecture to IESG for publication as an Infor= mational document.

De= cember 2015 - Submit one or more Applicability and Gap Analysis of existing= protocols to VNFPool to IESG for publication as Informational document(s).=

= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /span>

Th= anks.

-N= ing

--_000_B0D29E0424F2DE47A0B36779EC6667796616CDC0nkgeml501mbschi_-- From nobody Thu Jul 3 19:40:51 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74EE81A01C8 for ; Thu, 3 Jul 2014 19:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.851 X-Spam-Level: X-Spam-Status: No, score=-104.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPtRMT8Hu9nM for ; Thu, 3 Jul 2014 19:40:45 -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 881B41A0A97 for ; Thu, 3 Jul 2014 19:40:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGT87028; Fri, 04 Jul 2014 02:40:42 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 4 Jul 2014 03:40:41 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Fri, 4 Jul 2014 10:40:39 +0800 From: Zongning To: "vnfpool@ietf.org" Thread-Topic: Tentative VNFPool BoF Agenda Thread-Index: Ac+XMVb29Wi62js2QSCwvSf1NZSSCQ== Date: Fri, 4 Jul 2014 02:40:38 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.54] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC6667796616CE26nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/PJwq7ndBm4ZyeukvrX3Ip7-XBHg Subject: [vnfpool] Tentative VNFPool BoF Agenda X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 02:40:47 -0000 --_000_B0D29E0424F2DE47A0B36779EC6667796616CE26nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all, We uploaded a tentative agenda for VNFPool BoF in Toronto. It is available = at http://www.ietf.org/proceedings/90/agenda/agenda-90-vnfpool. Please let = us know if you want to change this agenda. Note that we will dedicate most of the agenda time to charter discussion. A= lso, we've temporarily reserved a 10~20 minutes slot for an initial discuss= ion of straw-man solutions. We'd like to call for your input to this topic. Thanks. -Melinda & Ning --_000_B0D29E0424F2DE47A0B36779EC6667796616CE26nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, all,

 

We uploaded a tentative agenda = for VNFPool BoF in Toronto. It is available at htt= p://www.ietf.org/proceedings/90/agenda/agenda-90-vnfpool. Please let us= know if you want to change this agenda.

Note that we will dedicate most= of the agenda time to charter discussion. Also, we’ve temporarily re= served a 10~20 minutes slot for an initial discussion of straw-man solution= s. We’d like to call for your input to this topic.

 

Thanks.

 

-Melinda & Ning<= /span>

--_000_B0D29E0424F2DE47A0B36779EC6667796616CE26nkgeml501mbschi_-- From nobody Fri Jul 4 09:19:37 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82E601B2C37 for ; Fri, 4 Jul 2014 09:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.414 X-Spam-Level: X-Spam-Status: No, score=-0.414 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RgEht41f-6M for ; Fri, 4 Jul 2014 09:19:31 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0901B2A6E for ; Fri, 4 Jul 2014 09:19:31 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id s64GJMRh021048; Fri, 4 Jul 2014 10:19:22 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Fri, 04 Jul 2014 10:19:21 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([::1]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0174.001; Fri, 4 Jul 2014 10:19:21 -0600 From: Don Clarke To: Zongning , "vnfpool@ietf.org" Thread-Topic: New Charter for Toronto Thread-Index: Ac+XKHD4e3Tyhku3QbmwqloaWSCkwwAeKS/w Date: Fri, 4 Jul 2014 16:19:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.5.0.27] Content-Type: multipart/alternative; boundary="_000_F67D8AE3B3893148B7E3EF3977D554E5402168EXCHANGEcablelabs_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/gctLh7KecKlLP3g27-cj8o_gmI8 Cc: "WRIGHT, STEVEN A" , "naseem.a.khan@verizon.com" , "tetsuya.nakamura.cu@nttdocomo.com" , "diego@tid.es" , "raquel.morera@verizon.com" Subject: Re: [vnfpool] New Charter for Toronto X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 16:19:34 -0000 --_000_F67D8AE3B3893148B7E3EF3977D554E5402168EXCHANGEcablelabs_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ning and All, I welcome this work as I have a strong belief that such mechanisms if prope= rly implemented will enable NFV-based network topologies to provide many mo= re options for delivering scalable high reliability networks than tradition= al point-hardware bounded topologies. I have highlighted this message in pu= blic statements whenever I get an opportunity and I have encouraged efforts= in the ETSI NFV ISG towards this goal. I would like to see a reference in this charter to related work in the ETSI= NFV ISG for example in the REL Working Group (Naseem Khan copied) and the = INF Working Group (Steve Wright copied). Also MANO (Raquel Morera copied). = I know that you and no doubt many others on this list are involved in both = places, but could we at least see some words in this charter that acknowled= ge relevant requirements coming from the NFV ISG? Suggested text in line below. Regards, Don Clarke. Chair, NFV ISG Network Operator Council From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Zongning Sent: Thursday, July 03, 2014 8:37 PM To: vnfpool@ietf.org Subject: [vnfpool] New Charter for Toronto Hi, all, Please find below the new VNFPool Charter, by which I'd like to keep entert= aining you. :) This new version is based on the list discussion and feedback mainly from L= AC Chidung, Hidetoshi, Sood, and Adrian. Thank you guys for improving our c= harter. Although I'd regard this version as a stable charter that reflects = a rough agreement on the list and is ready for Toronto, further comments an= d suggestions are *always* welcome. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Network functions such as firewalls, load balancers, and WAN optimizers are= conventionally deployed as specialized hardware servers in both network op= erators' networks and data center networks as the building blocks of networ= k services. There is a trend to implement such network functions as softwar= e instances running on general purpose servers, via a virtualization layer = (i.e., hypervisors). These virtualized functions are called Virtualized Net= work Functions (VNFs), which can be used to build network services. The use of VNFs introduces additional challenges to the reliability of the = provided network services. A single VNF instance would typically not have b= uilt-in reliability mechanisms on its host (i.e., a general purpose server)= . Instead, there are more risk factors such as software failure at various = levels including hypervisors and virtual machines, hardware failure, and in= stance migration that can make a VNF instance unreliable. In order to achieve higher reliability, a VNF implementation may adopt a po= oling mechanism, where a number of VNF instances with the same function can= be grouped as a pool to provide the function. We call such a pool a VNF Po= ol. Conceptually, a Pool Manager is used to manage a VNF Pool, e.g., select= s active/standby VNF instances, and potentially interacts with a service co= ntrol entity. Such a service control entity is an entity that orchestrates = a set of network functions to build network services. The major benefit of = using VNF Pool is that reliability mechanisms such as redundancy model are = achieved by the VNF Pool adopted by the VNF and thus not visible to the ser= vice control entity. A VNF Pool-enabled VNF still appears as a normal VNF w= hen orchestrated by a service control entity. Questions that are raised by the addition of a pooling mechanism to VNF inc= lude: * How to manage the redundancy model, e.g., select active/standby VNF= instances in a VNF Pool considering the infrastructure conditions, and sca= le a VNF instance in a VNF Pool? * What pool states need to be maintained to support the pooling mecha= nism itself, and how are such states maintained? * What information is exchanged between a VNF and a service control e= ntity? For example, how can a VNF Pool be addressed by the service control = entity? * After a VNF instance failover, how does the Pool Manager notify the= service control entity of some characteristic changes of the VNF, e.g., ca= pacity change, but without disclosure of the pooling procedure? The WG will refer to published ETSI NFV ISG documents relevant to this work= , notably (but not limited to) the outputs of the REL, MANO and INF Working= Groups to ensure that VNF Pooling mechanisms are compatible with the requi= rements published by the ETSI NFV ISG. The WG initially focuses on several reliability mechanisms that are mainly = associated with a redundancy model based on a VNF Pool. Additional mechanis= ms may include pool state maintenance only for pooling purpose. Service sta= te synchronization is out of scope for this phase. The WG assumes that a VN= F Pool contains redundant VNF instances of a same functional type. Differen= t types of VNFs are envisioned to be held in separate VNF Pools. VNF Pool c= omposed of both virtualized and non-virtualized functional instances may be= included after further use case and requirements study. The WG will addres= s the reliability of an individual VNF, but not the reliability related to = the control or the routing between adjacent VNFs that can form a network se= rvice. Specifically, the WG will study the following technical aspects: * Redundancy management within a VNF Pool, such as the signaling = between the Pool Manager and the instances in the pool for instance registr= ation, backup instances selection, and switching between active and standby= instances. * Protocol between the Pool Manager and the underlying network to= collect the network information required for appropriate placement/selecti= on of backup instances. * Protocol between a VNF and the service control entity to exchan= ge operational information between a VNF Pool and the service control entit= y. * Identification and analysis of reliable interfaces, such as tra= nsport protocol like MPTCP and SCTP for reliable delivery of the messages a= ssociated with the redundancy management within a VNF Pool. * Analysis of pooling security characteristics and requirements t= o identify and mitigate threats against the pooling mechanism. Identificati= on of an appropriate trust model between pool members, and between pool mem= bers and the Pool Manager. The WG plans to deliver a problem statement, a set of use cases, requiremen= ts and an architecture covering the aforementioned technical aspects, and g= ap analysis of existing technologies including but not limited to RSerPool.= We will rely heavily on existing IETF technologies, but that gaps will be = found around problems like redundancy mechanisms, state maintenance solely = for pooling purposes, reliable transport, and trust/security, all of which = will need to be considered and addressed. Although no decision on protocols= will be made in this phase, we will keep open for candidate protocols for = VNF Pool. The WG will seek re-chartering before adopting any work to develo= p new, or extend existing, protocols. We will work closely with the SFC WG, as we believe that SFC and VNF Pool a= re complementary. SFC would essentially see a VNF Pool-enabled VNF as a nor= mal service function and therefore be able to merge it into an SFC just lik= e any other service functions. Just like the communication between any pool= users and VNF Pool, the information exchanged between the VNF Pool and the= SFC may include some operational information of the VNF Pool. Goals and Milestones: December 2014 - Submit VNFPool Problem Statement to IESG for publication as= an Informational document. April 2015 - Submit VNFPool Use Cases to IESG for publication as an Informa= tional document. August 2015 - Submit VNFPool Requirements, including the manageability of V= NF Pool to IESG for publication as an Informational document. August 2015 - Submit VNFPool Architecture to IESG for publication as an Inf= ormational document. December 2015 - Submit one or more Applicability and Gap Analysis of existi= ng protocols to VNFPool to IESG for publication as Informational document(s= ). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Thanks. -Ning --_000_F67D8AE3B3893148B7E3EF3977D554E5402168EXCHANGEcablelabs_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ning and All,

 

I welcome this work as I hav= e a strong belief that such mechanisms if properly implemented will enable = NFV-based network topologies to provide many more options for delivering sc= alable high reliability networks than traditional point-hardware bounded topologies. I have highlighted this mes= sage in public statements whenever I get an opportunity and I have encourag= ed efforts in the ETSI NFV ISG towards this goal.

 

I would like to see a refere= nce in this charter to related work in the ETSI NFV ISG for example in the = REL Working Group (Naseem Khan copied) and the INF Working Group (Steve Wri= ght copied). Also MANO (Raquel Morera copied). I know that you and no doubt many others on this list are involve= d in both places, but could we at least see some words in this charter that= acknowledge relevant requirements coming from the NFV ISG?

 

Suggested text in line below= .

 

Regards,

Don Clarke.

 

Chair, NFV ISG Network Opera= tor Council

 

From: vnfpool [mailto:vnfpool-bounces= @ietf.org] On Behalf Of Zongning
Sent: Thursday, July 03, 2014 8:37 PM
To: vnfpool@ietf.org
Subject: [vnfpool] New Charter for Toronto

 =

Hi, all,

Please find below the new VNFPool Charter, by which I&#= 8217;d like to keep entertaining you. J

This new version is based on the list discussion and fe= edback mainly from LAC Chidung, Hidetoshi, Sood, and Adrian. Thank you guys= for improving our charter. Although I’d regard this version as a stable charter that reflects a rough agreement on= the list and is ready for Toronto, further comments and suggestions are *<= b>always* welcome.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

Network functions such as firewalls, load balancers, an= d WAN optimizers are conventionally deployed as specialized hardware server= s in both network operators' networks and data center networks as the building blocks of network services. There= is a trend to implement such network functions as software instances runni= ng on general purpose servers, via a virtualization layer (i.e., hypervisor= s). These virtualized functions are called Virtualized Network Functions (VNFs), which can be used to buil= d network services.

The use of VNFs introduces additional challenges to the= reliability of the provided network services. A single VNF instance would = typically not have built-in reliability mechanisms on its host (i.e., a general purpose server). Instead, there ar= e more risk factors such as software failure at various levels including hy= pervisors and virtual machines, hardware failure, and instance migration th= at can make a VNF instance unreliable.

In order to achieve higher reliability, a VNF implement= ation may adopt a pooling mechanism, where a number of VNF instances with t= he same function can be grouped as a pool to provide the function. We call such a pool a VNF Pool. Conceptually, a Pool Manager is used to m= anage a VNF Pool, e.g., selects active/standby VNF instances, and potential= ly interacts with a service control entity. Such a service control entity is an en= tity that orchestrates a set of network functions to build network services= . The major benefit of using VNF Pool is that reliability mechanisms such as redundancy model are achieved by th= e VNF Pool adopted by the VNF and thus not visible to the service control e= ntity. A VNF Pool-enabled VNF still appears as a normal VNF when orchestrat= ed by a service control entity.

Questions that are raised by the addition of a pooling = mechanism to VNF include:

·       H= ow to manage the redundancy model, e.g., select active/standby VNF instance= s in a VNF Pool considering the infrastructure conditions, and scale a VNF = instance in a VNF Pool?

·       W= hat pool states need to be maintained to support the pooling mechanism itse= lf, and how are such states maintained?

·       W= hat information is exchanged between a VNF and a service control entity? Fo= r example, how can a VNF Pool be addressed by the service control entity?

·       After a VNF instance failover, how does the Pool Manager noti= fy the service control entity of some characteristic changes of the VNF, e.= g., capacity change, but without disclosure of the pooling procedure?

Th= e WG will refer to published ETSI NFV ISG documents relevant to this work, = notably (but not limited to) the outputs of the REL, MANO and INF Working Groups to ensure that VNF Pooling mechani= sms are compatible with the requirements published by the ETSI NFV ISG.

The WG initially focuses on several reliability mechani= sms that are mainly associated with a redundancy model based on a VNF Pool.= Additional mechanisms may include pool state maintenance only for pooling purpose. Service state synchronization is out of sco= pe for this phase. The WG= assumes that a VNF Pool contains redundant VNF instances of a same functional type= . Different types of V= NFs are envisioned to be held in separate VNF Pools. VNF Pool composed of b= oth virtualized and non-virtualized functional instances may be included af= ter further use case and requirements study. The WG will address the reliability of an individual VNF, but not t= he reliability related to the control or the rou= ting between adjacent VNFs that can form= a network service.<= /o:p>

Specifically, the WG will study the following technical= aspects:

·        = ;   R= edundancy management within a VNF Pool, such as the signaling between the P= ool Manager and the instances in the pool for instance registration, backup= instances selection, and switching between active and standby instances.

·        = ;   P= rotocol between the Pool Manager and the underlying network to collect the = network information required for appropriate placement/selection of backup = instances.

·        = ;   P= rotocol between a VNF and the service control entity to exchange operationa= l information between a VNF Pool and the service control entity.

·        = ;   I= dentification and analysis of reliable interfaces, such as transport protoc= ol like MPTCP and SCTP for reliable delivery of the messages associated wit= h the redundancy management within a VNF Pool.

·        = ;   A= nalysis of pooling security characteristics and requirements to identify an= d mitigate threats against the pooling mechanism. Identification of an appr= opriate trust model between pool members, and between pool members and the Pool Manager.

The WG plans to deliver a problem statement, a set of u= se cases, requirements and an architecture covering the aforementioned tech= nical aspects, and gap analysis of existing technologies including but not limited to RSerPool. We will rely heavily o= n existing IETF technologies, but that gaps will be found around problems l= ike redundancy mechanisms, state maintenance solely for pooling purposes, re= liable transport, and trust/security, all of which will need to be consider= ed and addressed. Although no decision on protocols will be made in this ph= ase, we will keep open for candidate protocols for VNF Pool. The WG will seek re-chartering before adopting any= work to develop new, or extend existing, protocols.

We will work closely with the SFC WG, as we believe tha= t SFC and VNF Pool are complementary. SFC would essentially see a VNF Pool-enabled VN= F as a normal service function and therefore be able to merge it into an SF= C just like any other service functions. Just like the communication betwee= n any pool users and VNF Pool, the information exchanged between the VNF Pool and the SFC may include some op= erational information of the VNF Pool.

Goals and Milestones:

December 2014 - Submit VNFPool Problem Statement to IES= G for publication as an Informational document.

April 2015 - Submit VNFPool Use Cases to IESG for publi= cation as an Informational document.

August 2015 - Submit VNFPool Requirements, including th= e manageability of VNF Pool to IESG for publication as an Informational doc= ument.

August 2015 - Submit VNFPool Architecture to IESG for p= ublication as an Informational document.

December 2015 - Submit one or more Applicability and Ga= p Analysis of existing protocols to VNFPool to IESG for publication as Info= rmational document(s).

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

Thanks.

-Ning

--_000_F67D8AE3B3893148B7E3EF3977D554E5402168EXCHANGEcablelabs_-- From nobody Fri Jul 4 11:32:26 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4311B2E63 for ; Fri, 4 Jul 2014 11:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovuLHBhfaeR1 for ; Fri, 4 Jul 2014 11:32:17 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 309911B2E5C for ; Fri, 4 Jul 2014 11:32:16 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s64IW01H003121; Fri, 4 Jul 2014 19:32:00 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s64IVw8w003094 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 4 Jul 2014 19:31:59 +0100 From: "Adrian Farrel" To: "'Don Clarke'" , "'Zongning'" , References: In-Reply-To: Date: Fri, 4 Jul 2014 19:31:52 +0100 Message-ID: <0ec801cf97b6$3a660400$af320c00$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0EC9_01CF97BE.9C2E63A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL1TVX33y6XDgqr0E62DMj7iKcISgLrSoyrmS11ulA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20798.001 X-TM-AS-Result: No--27.051-10.0-31-10 X-imss-scan-details: No--27.051-10.0-31-10 X-TMASE-MatchedRID: yebcs53SkkDRhEyb9f1sjghWgIsZuXlPGSqdEmeD/nUC5WKtSs0Iv8hg wglSjPsLGEK7I4zsfn9e1AFSKjFQ8yYffDhK8sjJV9LwT29+rzap7eIcybi6oSQ37TuGigkb27S CZTa2t0qOLEVJNiQKgnylQ2at2EtqvHmmKJkwZOS4jAucHcCqna8WUNN9WehaZM25ZAWwDYYIZJ R7eWK/XDqjyFfqBLqlZyPbixOGVCBp71qAvI563k3suC/LuKpdQPCPzycuBFMOkJQR4QWbsDcuo 3EoNtwLTXzie8nJX6IuDKaWBhg8NnXOLnYa1mG+T7jCYv2QJPELBTNIdp+7bha6DRt6Sf/fRTg4 JSdU5fz4l1LNAW7cUOtKJ5X3SmTJfPmUQQG69pzmXEF3MwNZbjoSfZud5+Gg87rPiCP1jeCd8Y6 4luJmv9nLzK9o1xRISR1MtKFnpBMERznX5Usjmvv+//lqU1h645oDENe4eesJQDk2+4484PB8ks kKxiHuPXwdv4QPT6DTAK4/jiVfb+XGeJTjN8iqk3rl+MaNgxAjo8c0NkYYIp1uGX2i4E0OH7eMB QFeFwvXerHp2eyhCWJVHm/j9yxpb4veVDHQ5AEtrWjCN9l/FuOQ2i6l6A6yaxKBbTWINAvy67HG lbS8BKNPLsRUE6Gk5j2YUuVMMdRl+YLqdHPX1UdAWPMBu8kQx3lyq2zCKQBL4P/1QuCcTNrKbeL V7rdXogSQgg+Gc50z2vVoE43Gu/BRRUamfheMiFoorQjboWnzWqWqi0pBAQ4AepdqPBUYupNsDJ huPOukBywKohVqXrYIuy18hqhUVCFefQRV3M6eAiCmPx4NwGmRqNBHmBvevqq8s2MNhPB9j2Gwz TE3vXkguuQorcgMlHnCBbIfm9UyoCYNPZhPp0PG9YWU5R/mvMsVZWB7qxd+3BndfXUhXQ== Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/u5c0JCZqu3YA7GlTnTi3vesqFxQ Cc: "'WRIGHT, STEVEN A'" , naseem.a.khan@verizon.com, raquel.morera@verizon.com, diego@tid.es, tetsuya.nakamura.cu@nttdocomo.com Subject: Re: [vnfpool] New Charter for Toronto X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 18:32:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0EC9_01CF97BE.9C2E63A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Don, Just chipping in from the side lines.... I think this group of people working on VNFpool and those in the SFC working group take the work done by ETSI on NFV very seriously. They coordinate closely with Diego Lopez and consider the ETSI work as input. However, your proposed text might be a little unusual in an IETF working group charter. More likely would be to add to the final paragraph as: OLD We will work closely with the SFC WG, as we believe that SFC and VNF Pool are complementary. SFC would essentially see a VNF Pool-enabled VNF as a normal service function and therefore be able to merge it into an SFC just like any other service functions. Just like the communication between any pool users and VNF Pool, the information exchanged between the VNF Pool and the SFC may include some operational information of the VNF Pool. NEW The VNFpool working group will work closely with the SFC WG, as SFC and VNF Pool are complementary: SFC would essentially see a VNF Pool-enabled VNF as a normal service function and therefore be able to merge it into an SFC just like any other service functions. Just like the communication between any pool users and VNF Pool, the information exchanged between the VNF Pool and the SFC may include some operational information of the VNF Pool. Furthermore, the VNFpool working group will exchange information with ETSI to ensure that the work done by that body is taken into account and to share the progress of the working group as it produces documents. Cheers, Adrian (hating HTML emails) From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Don Clarke Sent: 04 July 2014 17:19 To: Zongning; vnfpool@ietf.org Cc: WRIGHT, STEVEN A; naseem.a.khan@verizon.com; tetsuya.nakamura.cu@nttdocomo.com; diego@tid.es; raquel.morera@verizon.com Subject: Re: [vnfpool] New Charter for Toronto Ning and All, I welcome this work as I have a strong belief that such mechanisms if properly implemented will enable NFV-based network topologies to provide many more options for delivering scalable high reliability networks than traditional point-hardware bounded topologies. I have highlighted this message in public statements whenever I get an opportunity and I have encouraged efforts in the ETSI NFV ISG towards this goal. I would like to see a reference in this charter to related work in the ETSI NFV ISG for example in the REL Working Group (Naseem Khan copied) and the INF Working Group (Steve Wright copied). Also MANO (Raquel Morera copied). I know that you and no doubt many others on this list are involved in both places, but could we at least see some words in this charter that acknowledge relevant requirements coming from the NFV ISG? Suggested text in line below. Regards, Don Clarke. Chair, NFV ISG Network Operator Council From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Zongning Sent: Thursday, July 03, 2014 8:37 PM To: vnfpool@ietf.org Subject: [vnfpool] New Charter for Toronto Hi, all, Please find below the new VNFPool Charter, by which I'd like to keep entertaining you. J This new version is based on the list discussion and feedback mainly from LAC Chidung, Hidetoshi, Sood, and Adrian. Thank you guys for improving our charter. Although I'd regard this version as a stable charter that reflects a rough agreement on the list and is ready for Toronto, further comments and suggestions are *always* welcome. ======================================================================= Network functions such as firewalls, load balancers, and WAN optimizers are conventionally deployed as specialized hardware servers in both network operators' networks and data center networks as the building blocks of network services. There is a trend to implement such network functions as software instances running on general purpose servers, via a virtualization layer (i.e., hypervisors). These virtualized functions are called Virtualized Network Functions (VNFs), which can be used to build network services. The use of VNFs introduces additional challenges to the reliability of the provided network services. A single VNF instance would typically not have built-in reliability mechanisms on its host (i.e., a general purpose server). Instead, there are more risk factors such as software failure at various levels including hypervisors and virtual machines, hardware failure, and instance migration that can make a VNF instance unreliable. In order to achieve higher reliability, a VNF implementation may adopt a pooling mechanism, where a number of VNF instances with the same function can be grouped as a pool to provide the function. We call such a pool a VNF Pool. Conceptually, a Pool Manager is used to manage a VNF Pool, e.g., selects active/standby VNF instances, and potentially interacts with a service control entity. Such a service control entity is an entity that orchestrates a set of network functions to build network services. The major benefit of using VNF Pool is that reliability mechanisms such as redundancy model are achieved by the VNF Pool adopted by the VNF and thus not visible to the service control entity. A VNF Pool-enabled VNF still appears as a normal VNF when orchestrated by a service control entity. Questions that are raised by the addition of a pooling mechanism to VNF include: . How to manage the redundancy model, e.g., select active/standby VNF instances in a VNF Pool considering the infrastructure conditions, and scale a VNF instance in a VNF Pool? . What pool states need to be maintained to support the pooling mechanism itself, and how are such states maintained? . What information is exchanged between a VNF and a service control entity? For example, how can a VNF Pool be addressed by the service control entity? . After a VNF instance failover, how does the Pool Manager notify the service control entity of some characteristic changes of the VNF, e.g., capacity change, but without disclosure of the pooling procedure? The WG will refer to published ETSI NFV ISG documents relevant to this work, notably (but not limited to) the outputs of the REL, MANO and INF Working Groups to ensure that VNF Pooling mechanisms are compatible with the requirements published by the ETSI NFV ISG. The WG initially focuses on several reliability mechanisms that are mainly associated with a redundancy model based on a VNF Pool. Additional mechanisms may include pool state maintenance only for pooling purpose. Service state synchronization is out of scope for this phase. The WG assumes that a VNF Pool contains redundant VNF instances of a same functional type. Different types of VNFs are envisioned to be held in separate VNF Pools. VNF Pool composed of both virtualized and non-virtualized functional instances may be included after further use case and requirements study. The WG will address the reliability of an individual VNF, but not the reliability related to the control or the routing between adjacent VNFs that can form a network service. Specifically, the WG will study the following technical aspects: . Redundancy management within a VNF Pool, such as the signaling between the Pool Manager and the instances in the pool for instance registration, backup instances selection, and switching between active and standby instances. . Protocol between the Pool Manager and the underlying network to collect the network information required for appropriate placement/selection of backup instances. . Protocol between a VNF and the service control entity to exchange operational information between a VNF Pool and the service control entity. . Identification and analysis of reliable interfaces, such as transport protocol like MPTCP and SCTP for reliable delivery of the messages associated with the redundancy management within a VNF Pool. . Analysis of pooling security characteristics and requirements to identify and mitigate threats against the pooling mechanism. Identification of an appropriate trust model between pool members, and between pool members and the Pool Manager. The WG plans to deliver a problem statement, a set of use cases, requirements and an architecture covering the aforementioned technical aspects, and gap analysis of existing technologies including but not limited to RSerPool. We will rely heavily on existing IETF technologies, but that gaps will be found around problems like redundancy mechanisms, state maintenance solely for pooling purposes, reliable transport, and trust/security, all of which will need to be considered and addressed. Although no decision on protocols will be made in this phase, we will keep open for candidate protocols for VNF Pool. The WG will seek re-chartering before adopting any work to develop new, or extend existing, protocols. We will work closely with the SFC WG, as we believe that SFC and VNF Pool are complementary. SFC would essentially see a VNF Pool-enabled VNF as a normal service function and therefore be able to merge it into an SFC just like any other service functions. Just like the communication between any pool users and VNF Pool, the information exchanged between the VNF Pool and the SFC may include some operational information of the VNF Pool. Goals and Milestones: December 2014 - Submit VNFPool Problem Statement to IESG for publication as an Informational document. April 2015 - Submit VNFPool Use Cases to IESG for publication as an Informational document. August 2015 - Submit VNFPool Requirements, including the manageability of VNF Pool to IESG for publication as an Informational document. August 2015 - Submit VNFPool Architecture to IESG for publication as an Informational document. December 2015 - Submit one or more Applicability and Gap Analysis of existing protocols to VNFPool to IESG for publication as Informational document(s). ======================================================================= Thanks. -Ning ------=_NextPart_000_0EC9_01CF97BE.9C2E63A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Don,

Just chipping in from the side = lines....

I think this group of people working on VNFpool = and those in the SFC working group take the work done by ETSI on NFV = very seriously. They coordinate closely with Diego Lopez and consider = the ETSI work as input.

However, your proposed text might be a little = unusual in an IETF working group charter. More likely would be to add to = the final paragraph as:

OLD

We will work closely with the SFC WG, as we = believe that SFC and VNF Pool are complementary. SFC would essentially = see a VNF Pool-enabled VNF as a normal service function and therefore be = able to merge it into an SFC just like any other service functions. Just = like the communication between any pool users and VNF Pool, the = information exchanged between the VNF Pool and the SFC may include some = operational information of the VNF Pool.

NEW

The VNFpool working group will work closely with = the SFC WG, as SFC and VNF Pool are complementary: SFC would essentially = see a VNF Pool-enabled VNF as a normal service function and therefore be = able to merge it into an SFC just like any other service functions. Just = like the communication between any pool users and VNF Pool, the = information exchanged between the VNF Pool and the SFC may include some = operational information of the VNF Pool. Furthermore, the VNFpool = working group will exchange information with ETSI to ensure that the = work done by that body is taken into account and to share the progress = of the working group as it produces documents.

 

Cheers,

Adrian (hating HTML = emails)

From: vnfpool = [mailto:vnfpool-bounces@ietf.org] On Behalf Of Don = Clarke
Sent: 04 July 2014 17:19
To: Zongning; = vnfpool@ietf.org
Cc: WRIGHT, STEVEN A; = naseem.a.khan@verizon.com; tetsuya.nakamura.cu@nttdocomo.com; = diego@tid.es; raquel.morera@verizon.com
Subject: Re: [vnfpool] = New Charter for Toronto

 

Ning = and All,

&nb= sp;

I = welcome this work as I have a strong belief that such mechanisms if = properly implemented will enable NFV-based network topologies to provide = many more options for delivering scalable high reliability networks than = traditional point-hardware bounded topologies. I have highlighted this = message in public statements whenever I get an opportunity and I have = encouraged efforts in the ETSI NFV ISG towards this = goal.

&nb= sp;

I would = like to see a reference in this charter to related work in the ETSI NFV = ISG for example in the REL Working Group (Naseem Khan copied) and the = INF Working Group (Steve Wright copied). Also MANO (Raquel Morera = copied). I know that you and no doubt many others on this list are = involved in both places, but could we at least see some words in this = charter that acknowledge relevant requirements coming from the NFV = ISG?

&nb= sp;

Suggeste= d text in line below.

&nb= sp;

Regards,=

Don = Clarke.

&nb= sp;

Chair, = NFV ISG Network Operator Council

&nb= sp;

From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of = Zongning
Sent: Thursday, July 03, 2014 8:37 = PM
To: vnfpool@ietf.org
Subject: [vnfpool] New = Charter for Toronto

 

Hi, = all,

Please find = below the new VNFPool Charter, by which I’d like to keep = entertaining you. J<= /span>

This new = version is based on the list discussion and feedback mainly from LAC = Chidung, Hidetoshi, Sood, and Adrian. Thank you guys for improving our = charter. Although I’d regard this version as a stable charter that = reflects a rough agreement on the list and is ready for Toronto, further = comments and suggestions are *always* = welcome.

=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=

Network = functions such as firewalls, load balancers, and WAN optimizers are = conventionally deployed as specialized hardware servers in both network = operators' networks and data center networks as the building blocks of = network services. There is a trend to implement such network functions = as software instances running on general purpose servers, via a = virtualization layer (i.e., hypervisors). These virtualized functions = are called Virtualized Network Functions (VNFs), which can be used to = build network services.

The use of = VNFs introduces additional challenges to the reliability of the provided = network services. A single VNF instance would typically not have = built-in reliability mechanisms on its host (i.e., a general purpose = server). Instead, there are more risk factors such as software failure = at various levels including hypervisors and virtual machines, hardware = failure, and instance migration that can make a VNF instance = unreliable.

In order to = achieve higher reliability, a VNF implementation may adopt a pooling = mechanism, where a number of VNF instances with the same function can be = grouped as a pool to provide the function. We call such a pool a VNF = Pool. Conceptually, = a Pool = Manager is used to manage a VNF Pool, e.g., selects active/standby VNF = instances, and potentially interacts with a service control entity. = Such a = service = control entity is an entity that orchestrates a set of network functions = to build network services. The major benefit of using VNF Pool is that = reliability mechanisms such as redundancy model are achieved by the VNF = Pool adopted by the VNF and thus not visible to the service control = entity. A VNF Pool-enabled VNF still appears as a normal VNF when = orchestrated by a service = control entity.

Questions = that are raised by the addition of a pooling mechanism to VNF = include:

·    How to = manage the redundancy model, e.g., select active/standby VNF instances = in a VNF Pool considering the infrastructure conditions, and scale a VNF = instance in a VNF Pool?

·    What pool = states need to be maintained to support the pooling mechanism itself, = and how are such states maintained?

·    What = information is exchanged between a VNF and a service control entity? For = example, how can a VNF Pool be addressed by the service control = entity?

·    After a VNF = instance failover, how does the Pool Manager notify the service control = entity of some characteristic changes of the VNF, e.g., capacity change, = but without disclosure of the pooling procedure?<= /span>

The WG will refer to published = ETSI NFV ISG documents relevant to this work, notably (but not limited = to) the outputs of the REL, MANO and INF Working Groups to ensure that = VNF Pooling mechanisms are compatible with the requirements published by = the ETSI NFV ISG.

The WG = initially focuses on several reliability mechanisms that are mainly = associated with a redundancy model based on a VNF Pool. Additional = mechanisms may include pool state maintenance only for = pooling purpose. Service state synchronization is out of scope for this = phase. The WG = assumes that a VNF = Pool contains redundant VNF instances of a same functional type. = Different = types of VNFs are envisioned to be held in separate VNF Pools. VNF Pool = composed of both virtualized and non-virtualized functional instances = may be included after further use case and requirements study. The WG = will address the reliability of an individual VNF, but not the = reliability related to the = control or the routing between adjacent VNFs that can form = a network service.=

Specifically= , the WG will study the following technical = aspects:

·           = Redundancy = management within a VNF Pool, such as the signaling between the Pool = Manager and the instances in the pool for instance registration, backup = instances selection, and switching between active and standby = instances.

·           = Protocol = between the Pool Manager and the underlying network to collect the = network information required for appropriate placement/selection of = backup instances.

·           = Protocol = between a VNF and the service control entity to exchange operational = information between a VNF Pool and the = service control entity.<= /span>

·           = Identificati= on and analysis of reliable interfaces, such as transport protocol like = MPTCP and SCTP for reliable delivery of the messages associated with the = redundancy management within a VNF Pool.

·           = Analysis of = pooling security characteristics and requirements to identify and = mitigate threats against the pooling mechanism. Identification of an = appropriate trust model between pool members, and between pool members = and the Pool Manager.

The WG = plans to deliver a problem statement, a set of use cases, requirements = and an architecture covering the aforementioned technical aspects, and = gap analysis of existing technologies including but not limited to = RSerPool. We will rely heavily on existing IETF technologies, but that = gaps will be found around problems like redundancy mechanisms, state = maintenance solely for = pooling purposes, reliable = transport, and trust/security, all of which will need to be considered = and addressed. Although no decision on protocols will be made in this = phase, we will keep open for candidate protocols for VNF Pool. The WG = will seek re-chartering before adopting any work to develop new, or = extend existing, protocols.

We will = work closely with the SFC WG, as we believe that SFC and VNF Pool are = complementary. SFC would essentially see a = VNF Pool-enabled VNF as a normal service function and therefore be able = to merge it into an SFC just like any other service functions. Just like = the communication between any pool users and VNF Pool, the information = exchanged between the VNF Pool and the SFC may include some operational = information of the VNF Pool.

Goals and = Milestones:

December = 2014 - Submit VNFPool Problem Statement to IESG for publication as an = Informational document.

April 2015 = - Submit VNFPool Use Cases to IESG for publication as an Informational = document.

August 2015 = - Submit VNFPool Requirements, including the manageability of VNF Pool = to IESG for publication as an Informational = document.

August 2015 = - Submit VNFPool Architecture to IESG for publication as an = Informational document.

December = 2015 - Submit one or more Applicability and Gap Analysis of existing = protocols to VNFPool to IESG for publication as Informational = document(s).

=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=

Thanks.=

-Ning

------=_NextPart_000_0EC9_01CF97BE.9C2E63A0-- From nobody Fri Jul 4 13:25:33 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BFF11B2F5D for ; Fri, 4 Jul 2014 13:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSmpxV-W3fDj for ; Fri, 4 Jul 2014 13:25:27 -0700 (PDT) Received: from sideburn.lancs.ac.uk (sideburn.lancs.ac.uk [148.88.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 54CF81B2F59 for ; Fri, 4 Jul 2014 13:25:27 -0700 (PDT) Received: from ex-0-ht0.lancs.ac.uk ([10.42.18.47] helo=EX-0-HT0.lancs.local) by sideburn.lancs.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1X3A2m-0006od-Fe; Fri, 04 Jul 2014 21:25:16 +0100 Received: from EX-0-MB2.lancs.local ([fe80::9d98:936b:54d1:c531]) by EX-0-HT0.lancs.local ([fe80::7d10:114a:53b0:7f2f%12]) with mapi id 14.03.0174.001; Fri, 4 Jul 2014 21:25:14 +0100 From: "King, Daniel" To: "adrian@olddog.co.uk" , 'Don Clarke' , 'Zongning' , "vnfpool@ietf.org" Thread-Topic: [vnfpool] New Charter for Toronto Thread-Index: Ac+XKHD4e3Tyhku3QbmwqloaWSCkwwAeKS/wAAMwewAABZH2oA== Date: Fri, 4 Jul 2014 20:25:14 +0000 Message-ID: <65174429B5AF4C45BD0798810EC48E0A323544AF@EX-0-MB2.lancs.local> References: <0ec801cf97b6$3a660400$af320c00$@olddog.co.uk> In-Reply-To: <0ec801cf97b6$3a660400$af320c00$@olddog.co.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [88.97.23.122] x-iss-local-domain: 1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/ubu0UWSv0z6Imp4PEyfECNwbqtY Cc: "'WRIGHT, STEVEN A'" , "naseem.a.khan@verizon.com" , "tetsuya.nakamura.cu@nttdocomo.com" , "diego@tid.es" , "raquel.morera@verizon.com" Subject: Re: [vnfpool] New Charter for Toronto X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 20:25:31 -0000 SGkgRG9uLCANCg0KSnVzdCBhbiBvYnNlcnZhdGlvbmFsIGNvbW1lbnQsIGFuZCBmb2xsb3dpbmcg b24gZnJvbSBBZHJpYW4sIGJ1dCBub3QgZGlyZWN0bHkgcmVsYXRlZCB0byB0aGUgQ2hhcnRlciB0 ZXh0IHByb3Bvc2FsLg0KDQpXZSAoYXMgYXV0aG9ycykgb2YgSW50ZXJuZXQgRHJhZnRzIChJLURz KSBjaXRlIGRvY3VtZW50cyB3aGVyZSByZXF1aXJlbWVudHMgYW5kIGlucHV0IGlzIHNvdXJjZWQs IGFuZCB3aXRoaW4gdGhlIGNvbnRleHQgb2YgVk5GIFBvb2wgIHdlIGhhdmUgYmVlbiByZWZlcmVu Y2luZyBhcHBsaWNhYmxlIChhbmQgZXNwZWNpYWxseSBvcGVubHkgYXZhaWxhYmxlKSBFVFNJIGRv Y3VtZW50YXRpb24uIEFzIHlvdSBtZW50aW9uIFZORiBQb29sIGRpc2N1c3Npb25zIGhhdmUgdGFr ZW4gcGxhY2Ugd2l0aGluIHRoZSB2YXJpb3VzIEVUU0kgTkZWIElTRyBXRyBzZXNzaW9ucyAoZXNw ZWNpYWxseSBSRUwsIElORiBhbmQgTUFOTyksIHNvIHdoZXJlIHJlbGV2YW50IHdlIGNhbiBsb29r IHRvIGFkZCBzcGVjaWZpYyByZWZlcmVuY2VzIGluIEktRCBBY2tub3dsZWRnbWVudCBzZWN0aW9u cyBhcyB3ZWxsLiANCg0KQnIsIERhbi4gDQoNCkZyb206IHZuZnBvb2wgW21haWx0bzp2bmZwb29s LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBZHJpYW4gRmFycmVsDQpTZW50OiAwNCBK dWx5IDIwMTQgMTk6MzINClRvOiAnRG9uIENsYXJrZSc7ICdab25nbmluZyc7IHZuZnBvb2xAaWV0 Zi5vcmcNCkNjOiAnV1JJR0hULCBTVEVWRU4gQSc7IG5hc2VlbS5hLmtoYW5AdmVyaXpvbi5jb207 IHJhcXVlbC5tb3JlcmFAdmVyaXpvbi5jb207IGRpZWdvQHRpZC5lczsgdGV0c3V5YS5uYWthbXVy YS5jdUBudHRkb2NvbW8uY29tDQpTdWJqZWN0OiBSZTogW3ZuZnBvb2xdIE5ldyBDaGFydGVyIGZv ciBUb3JvbnRvDQoNCkhpIERvbiwNCkp1c3QgY2hpcHBpbmcgaW4gZnJvbSB0aGUgc2lkZSBsaW5l cy4uLi4NCkkgdGhpbmsgdGhpcyBncm91cCBvZiBwZW9wbGUgd29ya2luZyBvbiBWTkZwb29sIGFu ZCB0aG9zZSBpbiB0aGUgU0ZDIHdvcmtpbmcgZ3JvdXAgdGFrZSB0aGUgd29yayBkb25lIGJ5IEVU U0kgb24gTkZWIHZlcnkgc2VyaW91c2x5LiBUaGV5IGNvb3JkaW5hdGUgY2xvc2VseSB3aXRoIERp ZWdvIExvcGV6IGFuZCBjb25zaWRlciB0aGUgRVRTSSB3b3JrIGFzIGlucHV0Lg0KSG93ZXZlciwg eW91ciBwcm9wb3NlZCB0ZXh0IG1pZ2h0IGJlIGEgbGl0dGxlIHVudXN1YWwgaW4gYW4gSUVURiB3 b3JraW5nIGdyb3VwIGNoYXJ0ZXIuIE1vcmUgbGlrZWx5IHdvdWxkIGJlIHRvIGFkZCB0byB0aGUg ZmluYWwgcGFyYWdyYXBoIGFzOg0KT0xEDQpXZSB3aWxsIHdvcmsgY2xvc2VseSB3aXRoIHRoZSBT RkMgV0csIGFzIHdlIGJlbGlldmUgdGhhdCBTRkMgYW5kIFZORiBQb29sIGFyZSBjb21wbGVtZW50 YXJ5LiBTRkMgd291bGQgZXNzZW50aWFsbHkgc2VlIGEgVk5GIFBvb2wtZW5hYmxlZCBWTkYgYXMg YSBub3JtYWwgc2VydmljZSBmdW5jdGlvbiBhbmQgdGhlcmVmb3JlIGJlIGFibGUgdG8gbWVyZ2Ug aXQgaW50byBhbiBTRkMganVzdCBsaWtlIGFueSBvdGhlciBzZXJ2aWNlIGZ1bmN0aW9ucy4gSnVz dCBsaWtlIHRoZSBjb21tdW5pY2F0aW9uIGJldHdlZW4gYW55IHBvb2wgdXNlcnMgYW5kIFZORiBQ b29sLCB0aGUgaW5mb3JtYXRpb24gZXhjaGFuZ2VkIGJldHdlZW4gdGhlIFZORiBQb29sIGFuZCB0 aGUgU0ZDIG1heSBpbmNsdWRlIHNvbWUgb3BlcmF0aW9uYWwgaW5mb3JtYXRpb24gb2YgdGhlIFZO RiBQb29sLg0KTkVXDQpUaGUgVk5GcG9vbCB3b3JraW5nIGdyb3VwIHdpbGwgd29yayBjbG9zZWx5 IHdpdGggdGhlIFNGQyBXRywgYXMgU0ZDIGFuZCBWTkYgUG9vbCBhcmUgY29tcGxlbWVudGFyeTog U0ZDIHdvdWxkIGVzc2VudGlhbGx5IHNlZSBhIFZORiBQb29sLWVuYWJsZWQgVk5GIGFzIGEgbm9y bWFsIHNlcnZpY2UgZnVuY3Rpb24gYW5kIHRoZXJlZm9yZSBiZSBhYmxlIHRvIG1lcmdlIGl0IGlu dG8gYW4gU0ZDIGp1c3QgbGlrZSBhbnkgb3RoZXIgc2VydmljZSBmdW5jdGlvbnMuIEp1c3QgbGlr ZSB0aGUgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIGFueSBwb29sIHVzZXJzIGFuZCBWTkYgUG9vbCwg dGhlIGluZm9ybWF0aW9uIGV4Y2hhbmdlZCBiZXR3ZWVuIHRoZSBWTkYgUG9vbCBhbmQgdGhlIFNG QyBtYXkgaW5jbHVkZSBzb21lIG9wZXJhdGlvbmFsIGluZm9ybWF0aW9uIG9mIHRoZSBWTkYgUG9v bC4gRnVydGhlcm1vcmUsIHRoZSBWTkZwb29sIHdvcmtpbmcgZ3JvdXAgd2lsbCBleGNoYW5nZSBp bmZvcm1hdGlvbiB3aXRoIEVUU0kgdG8gZW5zdXJlIHRoYXQgdGhlIHdvcmsgZG9uZSBieSB0aGF0 IGJvZHkgaXMgdGFrZW4gaW50byBhY2NvdW50IGFuZCB0byBzaGFyZSB0aGUgcHJvZ3Jlc3Mgb2Yg dGhlIHdvcmtpbmcgZ3JvdXAgYXMgaXQgcHJvZHVjZXMgZG9jdW1lbnRzLg0KDQpDaGVlcnMsDQpB ZHJpYW4gKGhhdGluZyBIVE1MIGVtYWlscykNCkZyb206IHZuZnBvb2wgW21haWx0bzp2bmZwb29s LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEb24gQ2xhcmtlDQpTZW50OiAwNCBKdWx5 IDIwMTQgMTc6MTkNClRvOiBab25nbmluZzsgdm5mcG9vbEBpZXRmLm9yZw0KQ2M6IFdSSUdIVCwg U1RFVkVOIEE7IG5hc2VlbS5hLmtoYW5AdmVyaXpvbi5jb207IHRldHN1eWEubmFrYW11cmEuY3VA bnR0ZG9jb21vLmNvbTsgZGllZ29AdGlkLmVzOyByYXF1ZWwubW9yZXJhQHZlcml6b24uY29tDQpT dWJqZWN0OiBSZTogW3ZuZnBvb2xdIE5ldyBDaGFydGVyIGZvciBUb3JvbnRvDQoNCk5pbmcgYW5k IEFsbCwNCg0KSSB3ZWxjb21lIHRoaXMgd29yayBhcyBJIGhhdmUgYSBzdHJvbmcgYmVsaWVmIHRo YXQgc3VjaCBtZWNoYW5pc21zIGlmIHByb3Blcmx5IGltcGxlbWVudGVkIHdpbGwgZW5hYmxlIE5G Vi1iYXNlZCBuZXR3b3JrIHRvcG9sb2dpZXMgdG8gcHJvdmlkZSBtYW55IG1vcmUgb3B0aW9ucyBm b3IgZGVsaXZlcmluZyBzY2FsYWJsZSBoaWdoIHJlbGlhYmlsaXR5IG5ldHdvcmtzIHRoYW4gdHJh ZGl0aW9uYWwgcG9pbnQtaGFyZHdhcmUgYm91bmRlZCB0b3BvbG9naWVzLiBJIGhhdmUgaGlnaGxp Z2h0ZWQgdGhpcyBtZXNzYWdlIGluIHB1YmxpYyBzdGF0ZW1lbnRzIHdoZW5ldmVyIEkgZ2V0IGFu IG9wcG9ydHVuaXR5IGFuZCBJIGhhdmUgZW5jb3VyYWdlZCBlZmZvcnRzIGluIHRoZSBFVFNJIE5G ViBJU0cgdG93YXJkcyB0aGlzIGdvYWwuDQoNCkkgd291bGQgbGlrZSB0byBzZWUgYSByZWZlcmVu Y2UgaW4gdGhpcyBjaGFydGVyIHRvIHJlbGF0ZWQgd29yayBpbiB0aGUgRVRTSSBORlYgSVNHIGZv ciBleGFtcGxlIGluIHRoZSBSRUwgV29ya2luZyBHcm91cCAoTmFzZWVtIEtoYW4gY29waWVkKSBh bmQgdGhlIElORiBXb3JraW5nIEdyb3VwIChTdGV2ZSBXcmlnaHQgY29waWVkKS4gQWxzbyBNQU5P IChSYXF1ZWwgTW9yZXJhIGNvcGllZCkuIEkga25vdyB0aGF0IHlvdSBhbmQgbm8gZG91YnQgbWFu eSBvdGhlcnMgb24gdGhpcyBsaXN0IGFyZSBpbnZvbHZlZCBpbiBib3RoIHBsYWNlcywgYnV0IGNv dWxkIHdlIGF0IGxlYXN0IHNlZSBzb21lIHdvcmRzIGluIHRoaXMgY2hhcnRlciB0aGF0IGFja25v d2xlZGdlIHJlbGV2YW50IHJlcXVpcmVtZW50cyBjb21pbmcgZnJvbSB0aGUgTkZWIElTRz8NCg0K U3VnZ2VzdGVkIHRleHQgaW4gbGluZSBiZWxvdy4NCg0KUmVnYXJkcywNCkRvbiBDbGFya2UuDQoN CkNoYWlyLCBORlYgSVNHIE5ldHdvcmsgT3BlcmF0b3IgQ291bmNpbA0KDQpGcm9tOiB2bmZwb29s IFttYWlsdG86dm5mcG9vbC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWm9uZ25pbmcN ClNlbnQ6IFRodXJzZGF5LCBKdWx5IDAzLCAyMDE0IDg6MzcgUE0NClRvOiB2bmZwb29sQGlldGYu b3JnDQpTdWJqZWN0OiBbdm5mcG9vbF0gTmV3IENoYXJ0ZXIgZm9yIFRvcm9udG8NCg0KSGksIGFs bCwNClBsZWFzZSBmaW5kIGJlbG93IHRoZSBuZXcgVk5GUG9vbCBDaGFydGVyLCBieSB3aGljaCBJ 4oCZZCBsaWtlIHRvIGtlZXAgZW50ZXJ0YWluaW5nIHlvdS4g4pi6DQpUaGlzIG5ldyB2ZXJzaW9u IGlzIGJhc2VkIG9uIHRoZSBsaXN0IGRpc2N1c3Npb24gYW5kIGZlZWRiYWNrIG1haW5seSBmcm9t IExBQyBDaGlkdW5nLCBIaWRldG9zaGksIFNvb2QsIGFuZCBBZHJpYW4uIFRoYW5rIHlvdSBndXlz IGZvciBpbXByb3Zpbmcgb3VyIGNoYXJ0ZXIuIEFsdGhvdWdoIEnigJlkIHJlZ2FyZCB0aGlzIHZl cnNpb24gYXMgYSBzdGFibGUgY2hhcnRlciB0aGF0IHJlZmxlY3RzIGEgcm91Z2ggYWdyZWVtZW50 IG9uIHRoZSBsaXN0IGFuZCBpcyByZWFkeSBmb3IgVG9yb250bywgZnVydGhlciBjb21tZW50cyBh bmQgc3VnZ2VzdGlvbnMgYXJlICphbHdheXMqIHdlbGNvbWUuDQo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KTmV0 d29yayBmdW5jdGlvbnMgc3VjaCBhcyBmaXJld2FsbHMsIGxvYWQgYmFsYW5jZXJzLCBhbmQgV0FO IG9wdGltaXplcnMgYXJlIGNvbnZlbnRpb25hbGx5IGRlcGxveWVkIGFzIHNwZWNpYWxpemVkIGhh cmR3YXJlIHNlcnZlcnMgaW4gYm90aCBuZXR3b3JrIG9wZXJhdG9ycycgbmV0d29ya3MgYW5kIGRh dGEgY2VudGVyIG5ldHdvcmtzIGFzIHRoZSBidWlsZGluZyBibG9ja3Mgb2YgbmV0d29yayBzZXJ2 aWNlcy4gVGhlcmUgaXMgYSB0cmVuZCB0byBpbXBsZW1lbnQgc3VjaCBuZXR3b3JrIGZ1bmN0aW9u cyBhcyBzb2Z0d2FyZSBpbnN0YW5jZXMgcnVubmluZyBvbiBnZW5lcmFsIHB1cnBvc2Ugc2VydmVy cywgdmlhIGEgdmlydHVhbGl6YXRpb24gbGF5ZXIgKGkuZS4sIGh5cGVydmlzb3JzKS4gVGhlc2Ug dmlydHVhbGl6ZWQgZnVuY3Rpb25zIGFyZSBjYWxsZWQgVmlydHVhbGl6ZWQgTmV0d29yayBGdW5j dGlvbnMgKFZORnMpLCB3aGljaCBjYW4gYmUgdXNlZCB0byBidWlsZCBuZXR3b3JrIHNlcnZpY2Vz Lg0KVGhlIHVzZSBvZiBWTkZzIGludHJvZHVjZXMgYWRkaXRpb25hbCBjaGFsbGVuZ2VzIHRvIHRo ZSByZWxpYWJpbGl0eSBvZiB0aGUgcHJvdmlkZWQgbmV0d29yayBzZXJ2aWNlcy4gQSBzaW5nbGUg Vk5GIGluc3RhbmNlIHdvdWxkIHR5cGljYWxseSBub3QgaGF2ZSBidWlsdC1pbiByZWxpYWJpbGl0 eSBtZWNoYW5pc21zIG9uIGl0cyBob3N0IChpLmUuLCBhIGdlbmVyYWwgcHVycG9zZSBzZXJ2ZXIp LiBJbnN0ZWFkLCB0aGVyZSBhcmUgbW9yZSByaXNrIGZhY3RvcnMgc3VjaCBhcyBzb2Z0d2FyZSBm YWlsdXJlIGF0IHZhcmlvdXMgbGV2ZWxzIGluY2x1ZGluZyBoeXBlcnZpc29ycyBhbmQgdmlydHVh bCBtYWNoaW5lcywgaGFyZHdhcmUgZmFpbHVyZSwgYW5kIGluc3RhbmNlIG1pZ3JhdGlvbiB0aGF0 IGNhbiBtYWtlIGEgVk5GIGluc3RhbmNlIHVucmVsaWFibGUuDQpJbiBvcmRlciB0byBhY2hpZXZl IGhpZ2hlciByZWxpYWJpbGl0eSwgYSBWTkYgaW1wbGVtZW50YXRpb24gbWF5IGFkb3B0IGEgcG9v bGluZyBtZWNoYW5pc20sIHdoZXJlIGEgbnVtYmVyIG9mIFZORiBpbnN0YW5jZXMgd2l0aCB0aGUg c2FtZSBmdW5jdGlvbiBjYW4gYmUgZ3JvdXBlZCBhcyBhIHBvb2wgdG8gcHJvdmlkZSB0aGUgZnVu Y3Rpb24uIFdlIGNhbGwgc3VjaCBhIHBvb2wgYSBWTkYgUG9vbC4gQ29uY2VwdHVhbGx5LCBhIFBv b2wgTWFuYWdlciBpcyB1c2VkIHRvIG1hbmFnZSBhIFZORiBQb29sLCBlLmcuLCBzZWxlY3RzIGFj dGl2ZS9zdGFuZGJ5IFZORiBpbnN0YW5jZXMsIGFuZCBwb3RlbnRpYWxseSBpbnRlcmFjdHMgd2l0 aCBhIHNlcnZpY2UgY29udHJvbCBlbnRpdHkuIFN1Y2ggYSBzZXJ2aWNlIGNvbnRyb2wgZW50aXR5 IGlzIGFuIGVudGl0eSB0aGF0IG9yY2hlc3RyYXRlcyBhIHNldCBvZiBuZXR3b3JrIGZ1bmN0aW9u cyB0byBidWlsZCBuZXR3b3JrIHNlcnZpY2VzLiBUaGUgbWFqb3IgYmVuZWZpdCBvZiB1c2luZyBW TkYgUG9vbCBpcyB0aGF0IHJlbGlhYmlsaXR5IG1lY2hhbmlzbXMgc3VjaCBhcyByZWR1bmRhbmN5 IG1vZGVsIGFyZSBhY2hpZXZlZCBieSB0aGUgVk5GIFBvb2wgYWRvcHRlZCBieSB0aGUgVk5GIGFu ZCB0aHVzIG5vdCB2aXNpYmxlIHRvIHRoZSBzZXJ2aWNlIGNvbnRyb2wgZW50aXR5LiBBIFZORiBQ b29sLWVuYWJsZWQgVk5GIHN0aWxsIGFwcGVhcnMgYXMgYSBub3JtYWwgVk5GIHdoZW4gb3JjaGVz dHJhdGVkIGJ5IGEgc2VydmljZSBjb250cm9sIGVudGl0eS4NClF1ZXN0aW9ucyB0aGF0IGFyZSBy YWlzZWQgYnkgdGhlIGFkZGl0aW9uIG9mIGEgcG9vbGluZyBtZWNoYW5pc20gdG8gVk5GIGluY2x1 ZGU6DQrigKIgSG93IHRvIG1hbmFnZSB0aGUgcmVkdW5kYW5jeSBtb2RlbCwgZS5nLiwgc2VsZWN0 IGFjdGl2ZS9zdGFuZGJ5IFZORiBpbnN0YW5jZXMgaW4gYSBWTkYgUG9vbCBjb25zaWRlcmluZyB0 aGUgaW5mcmFzdHJ1Y3R1cmUgY29uZGl0aW9ucywgYW5kIHNjYWxlIGEgVk5GIGluc3RhbmNlIGlu IGEgVk5GIFBvb2w/DQrigKIgV2hhdCBwb29sIHN0YXRlcyBuZWVkIHRvIGJlIG1haW50YWluZWQg dG8gc3VwcG9ydCB0aGUgcG9vbGluZyBtZWNoYW5pc20gaXRzZWxmLCBhbmQgaG93IGFyZSBzdWNo IHN0YXRlcyBtYWludGFpbmVkPw0K4oCiIFdoYXQgaW5mb3JtYXRpb24gaXMgZXhjaGFuZ2VkIGJl dHdlZW4gYSBWTkYgYW5kIGEgc2VydmljZSBjb250cm9sIGVudGl0eT8gRm9yIGV4YW1wbGUsIGhv dyBjYW4gYSBWTkYgUG9vbCBiZSBhZGRyZXNzZWQgYnkgdGhlIHNlcnZpY2UgY29udHJvbCBlbnRp dHk/DQrigKIgQWZ0ZXIgYSBWTkYgaW5zdGFuY2UgZmFpbG92ZXIsIGhvdyBkb2VzIHRoZSBQb29s IE1hbmFnZXIgbm90aWZ5IHRoZSBzZXJ2aWNlIGNvbnRyb2wgZW50aXR5IG9mIHNvbWUgY2hhcmFj dGVyaXN0aWMgY2hhbmdlcyBvZiB0aGUgVk5GLCBlLmcuLCBjYXBhY2l0eSBjaGFuZ2UsIGJ1dCB3 aXRob3V0IGRpc2Nsb3N1cmUgb2YgdGhlIHBvb2xpbmcgcHJvY2VkdXJlPw0KVGhlIFdHIHdpbGwg cmVmZXIgdG8gcHVibGlzaGVkIEVUU0kgTkZWIElTRyBkb2N1bWVudHMgcmVsZXZhbnQgdG8gdGhp cyB3b3JrLCBub3RhYmx5IChidXQgbm90IGxpbWl0ZWQgdG8pIHRoZSBvdXRwdXRzIG9mIHRoZSBS RUwsIE1BTk8gYW5kIElORiBXb3JraW5nIEdyb3VwcyB0byBlbnN1cmUgdGhhdCBWTkYgUG9vbGlu ZyBtZWNoYW5pc21zIGFyZSBjb21wYXRpYmxlIHdpdGggdGhlIHJlcXVpcmVtZW50cyBwdWJsaXNo ZWQgYnkgdGhlIEVUU0kgTkZWIElTRy4NClRoZSBXRyBpbml0aWFsbHkgZm9jdXNlcyBvbiBzZXZl cmFsIHJlbGlhYmlsaXR5IG1lY2hhbmlzbXMgdGhhdCBhcmUgbWFpbmx5IGFzc29jaWF0ZWQgd2l0 aCBhIHJlZHVuZGFuY3kgbW9kZWwgYmFzZWQgb24gYSBWTkYgUG9vbC4gQWRkaXRpb25hbCBtZWNo YW5pc21zIG1heSBpbmNsdWRlIHBvb2wgc3RhdGUgbWFpbnRlbmFuY2Ugb25seSBmb3IgcG9vbGlu ZyBwdXJwb3NlLiBTZXJ2aWNlIHN0YXRlIHN5bmNocm9uaXphdGlvbiBpcyBvdXQgb2Ygc2NvcGUg Zm9yIHRoaXMgcGhhc2UuIFRoZSBXRyBhc3N1bWVzIHRoYXQgYSBWTkYgUG9vbCBjb250YWlucyBy ZWR1bmRhbnQgVk5GIGluc3RhbmNlcyBvZiBhIHNhbWUgZnVuY3Rpb25hbCB0eXBlLiBEaWZmZXJl bnQgdHlwZXMgb2YgVk5GcyBhcmUgZW52aXNpb25lZCB0byBiZSBoZWxkIGluIHNlcGFyYXRlIFZO RiBQb29scy4gVk5GIFBvb2wgY29tcG9zZWQgb2YgYm90aCB2aXJ0dWFsaXplZCBhbmQgbm9uLXZp cnR1YWxpemVkIGZ1bmN0aW9uYWwgaW5zdGFuY2VzIG1heSBiZSBpbmNsdWRlZCBhZnRlciBmdXJ0 aGVyIHVzZSBjYXNlIGFuZCByZXF1aXJlbWVudHMgc3R1ZHkuIFRoZSBXRyB3aWxsIGFkZHJlc3Mg dGhlIHJlbGlhYmlsaXR5IG9mIGFuIGluZGl2aWR1YWwgVk5GLCBidXQgbm90IHRoZSByZWxpYWJp bGl0eSByZWxhdGVkIHRvIHRoZSBjb250cm9sIG9yIHRoZSByb3V0aW5nIGJldHdlZW4gYWRqYWNl bnQgVk5GcyB0aGF0IGNhbiBmb3JtIGEgbmV0d29yayBzZXJ2aWNlLg0KU3BlY2lmaWNhbGx5LCB0 aGUgV0cgd2lsbCBzdHVkeSB0aGUgZm9sbG93aW5nIHRlY2huaWNhbCBhc3BlY3RzOg0K4oCiIFJl ZHVuZGFuY3kgbWFuYWdlbWVudCB3aXRoaW4gYSBWTkYgUG9vbCwgc3VjaCBhcyB0aGUgc2lnbmFs aW5nIGJldHdlZW4gdGhlIFBvb2wgTWFuYWdlciBhbmQgdGhlIGluc3RhbmNlcyBpbiB0aGUgcG9v bCBmb3IgaW5zdGFuY2UgcmVnaXN0cmF0aW9uLCBiYWNrdXAgaW5zdGFuY2VzIHNlbGVjdGlvbiwg YW5kIHN3aXRjaGluZyBiZXR3ZWVuIGFjdGl2ZSBhbmQgc3RhbmRieSBpbnN0YW5jZXMuDQrigKIg UHJvdG9jb2wgYmV0d2VlbiB0aGUgUG9vbCBNYW5hZ2VyIGFuZCB0aGUgdW5kZXJseWluZyBuZXR3 b3JrIHRvIGNvbGxlY3QgdGhlIG5ldHdvcmsgaW5mb3JtYXRpb24gcmVxdWlyZWQgZm9yIGFwcHJv cHJpYXRlIHBsYWNlbWVudC9zZWxlY3Rpb24gb2YgYmFja3VwIGluc3RhbmNlcy4NCuKAoiBQcm90 b2NvbCBiZXR3ZWVuIGEgVk5GIGFuZCB0aGUgc2VydmljZSBjb250cm9sIGVudGl0eSB0byBleGNo YW5nZSBvcGVyYXRpb25hbCBpbmZvcm1hdGlvbiBiZXR3ZWVuIGEgVk5GIFBvb2wgYW5kIHRoZSBz ZXJ2aWNlIGNvbnRyb2wgZW50aXR5Lg0K4oCiIElkZW50aWZpY2F0aW9uIGFuZCBhbmFseXNpcyBv ZiByZWxpYWJsZSBpbnRlcmZhY2VzLCBzdWNoIGFzIHRyYW5zcG9ydCBwcm90b2NvbCBsaWtlIE1Q VENQIGFuZCBTQ1RQIGZvciByZWxpYWJsZSBkZWxpdmVyeSBvZiB0aGUgbWVzc2FnZXMgYXNzb2Np YXRlZCB3aXRoIHRoZSByZWR1bmRhbmN5IG1hbmFnZW1lbnQgd2l0aGluIGEgVk5GIFBvb2wuDQri gKIgQW5hbHlzaXMgb2YgcG9vbGluZyBzZWN1cml0eSBjaGFyYWN0ZXJpc3RpY3MgYW5kIHJlcXVp cmVtZW50cyB0byBpZGVudGlmeSBhbmQgbWl0aWdhdGUgdGhyZWF0cyBhZ2FpbnN0IHRoZSBwb29s aW5nIG1lY2hhbmlzbS4gSWRlbnRpZmljYXRpb24gb2YgYW4gYXBwcm9wcmlhdGUgdHJ1c3QgbW9k ZWwgYmV0d2VlbiBwb29sIG1lbWJlcnMsIGFuZCBiZXR3ZWVuIHBvb2wgbWVtYmVycyBhbmQgdGhl IFBvb2wgTWFuYWdlci4NClRoZSBXRyBwbGFucyB0byBkZWxpdmVyIGEgcHJvYmxlbSBzdGF0ZW1l bnQsIGEgc2V0IG9mIHVzZSBjYXNlcywgcmVxdWlyZW1lbnRzIGFuZCBhbiBhcmNoaXRlY3R1cmUg Y292ZXJpbmcgdGhlIGFmb3JlbWVudGlvbmVkIHRlY2huaWNhbCBhc3BlY3RzLCBhbmQgZ2FwIGFu YWx5c2lzIG9mIGV4aXN0aW5nIHRlY2hub2xvZ2llcyBpbmNsdWRpbmcgYnV0IG5vdCBsaW1pdGVk IHRvIFJTZXJQb29sLiBXZSB3aWxsIHJlbHkgaGVhdmlseSBvbiBleGlzdGluZyBJRVRGIHRlY2hu b2xvZ2llcywgYnV0IHRoYXQgZ2FwcyB3aWxsIGJlIGZvdW5kIGFyb3VuZCBwcm9ibGVtcyBsaWtl IHJlZHVuZGFuY3kgbWVjaGFuaXNtcywgc3RhdGUgbWFpbnRlbmFuY2Ugc29sZWx5IGZvciBwb29s aW5nIHB1cnBvc2VzLCByZWxpYWJsZSB0cmFuc3BvcnQsIGFuZCB0cnVzdC9zZWN1cml0eSwgYWxs IG9mIHdoaWNoIHdpbGwgbmVlZCB0byBiZSBjb25zaWRlcmVkIGFuZCBhZGRyZXNzZWQuIEFsdGhv dWdoIG5vIGRlY2lzaW9uIG9uIHByb3RvY29scyB3aWxsIGJlIG1hZGUgaW4gdGhpcyBwaGFzZSwg d2Ugd2lsbCBrZWVwIG9wZW4gZm9yIGNhbmRpZGF0ZSBwcm90b2NvbHMgZm9yIFZORiBQb29sLiBU aGUgV0cgd2lsbCBzZWVrIHJlLWNoYXJ0ZXJpbmcgYmVmb3JlIGFkb3B0aW5nIGFueSB3b3JrIHRv IGRldmVsb3AgbmV3LCBvciBleHRlbmQgZXhpc3RpbmcsIHByb3RvY29scy4NCldlIHdpbGwgd29y ayBjbG9zZWx5IHdpdGggdGhlIFNGQyBXRywgYXMgd2UgYmVsaWV2ZSB0aGF0IFNGQyBhbmQgVk5G IFBvb2wgYXJlIGNvbXBsZW1lbnRhcnkuIFNGQyB3b3VsZCBlc3NlbnRpYWxseSBzZWUgYSBWTkYg UG9vbC1lbmFibGVkIFZORiBhcyBhIG5vcm1hbCBzZXJ2aWNlIGZ1bmN0aW9uIGFuZCB0aGVyZWZv cmUgYmUgYWJsZSB0byBtZXJnZSBpdCBpbnRvIGFuIFNGQyBqdXN0IGxpa2UgYW55IG90aGVyIHNl cnZpY2UgZnVuY3Rpb25zLiBKdXN0IGxpa2UgdGhlIGNvbW11bmljYXRpb24gYmV0d2VlbiBhbnkg cG9vbCB1c2VycyBhbmQgVk5GIFBvb2wsIHRoZSBpbmZvcm1hdGlvbiBleGNoYW5nZWQgYmV0d2Vl biB0aGUgVk5GIFBvb2wgYW5kIHRoZSBTRkMgbWF5IGluY2x1ZGUgc29tZSBvcGVyYXRpb25hbCBp bmZvcm1hdGlvbiBvZiB0aGUgVk5GIFBvb2wuDQpHb2FscyBhbmQgTWlsZXN0b25lczoNCkRlY2Vt YmVyIDIwMTQgLSBTdWJtaXQgVk5GUG9vbCBQcm9ibGVtIFN0YXRlbWVudCB0byBJRVNHIGZvciBw dWJsaWNhdGlvbiBhcyBhbiBJbmZvcm1hdGlvbmFsIGRvY3VtZW50Lg0KQXByaWwgMjAxNSAtIFN1 Ym1pdCBWTkZQb29sIFVzZSBDYXNlcyB0byBJRVNHIGZvciBwdWJsaWNhdGlvbiBhcyBhbiBJbmZv cm1hdGlvbmFsIGRvY3VtZW50Lg0KQXVndXN0IDIwMTUgLSBTdWJtaXQgVk5GUG9vbCBSZXF1aXJl bWVudHMsIGluY2x1ZGluZyB0aGUgbWFuYWdlYWJpbGl0eSBvZiBWTkYgUG9vbCB0byBJRVNHIGZv ciBwdWJsaWNhdGlvbiBhcyBhbiBJbmZvcm1hdGlvbmFsIGRvY3VtZW50Lg0KQXVndXN0IDIwMTUg LSBTdWJtaXQgVk5GUG9vbCBBcmNoaXRlY3R1cmUgdG8gSUVTRyBmb3IgcHVibGljYXRpb24gYXMg YW4gSW5mb3JtYXRpb25hbCBkb2N1bWVudC4NCkRlY2VtYmVyIDIwMTUgLSBTdWJtaXQgb25lIG9y IG1vcmUgQXBwbGljYWJpbGl0eSBhbmQgR2FwIEFuYWx5c2lzIG9mIGV4aXN0aW5nIHByb3RvY29s cyB0byBWTkZQb29sIHRvIElFU0cgZm9yIHB1YmxpY2F0aW9uIGFzIEluZm9ybWF0aW9uYWwgZG9j dW1lbnQocykuDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQ0KVGhhbmtzLg0KLU5pbmcNCg== From nobody Fri Jul 4 15:32:30 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83131A0027 for ; Fri, 4 Jul 2014 15:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gnb9ExFW8i0J for ; Fri, 4 Jul 2014 15:32:23 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E8171A012D for ; Fri, 4 Jul 2014 15:32:22 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s64MW8hO004439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 4 Jul 2014 22:32:08 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s64MW6k0004921 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 5 Jul 2014 00:32:06 +0200 Received: from DEMUHTC012.nsn-intra.net (10.159.42.43) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sat, 5 Jul 2014 00:32:05 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.136]) by DEMUHTC012.nsn-intra.net ([10.159.42.43]) with mapi id 14.03.0181.006; Sat, 5 Jul 2014 00:32:05 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "adrian@olddog.co.uk" , "'Don Clarke'" , "'Zongning'" , "vnfpool@ietf.org" Thread-Topic: [vnfpool] New Charter for Toronto Thread-Index: AQL1TVX33y6XDgqr0E62DMj7iKcISgLrSoyrmS11ulCAAC40UA== Date: Fri, 4 Jul 2014 22:32:05 +0000 Message-ID: References: <0ec801cf97b6$3a660400$af320c00$@olddog.co.uk> In-Reply-To: <0ec801cf97b6$3a660400$af320c00$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.156] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F838E553DEMUMBX005nsnintr_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 36716 X-purgate-ID: 151667::1404513129-000005B1-C75C0043/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/bqBzz2b99KXfyV6rkXnkCgrPKBc Cc: "'WRIGHT, STEVEN A'" , "naseem.a.khan@verizon.com" , "tetsuya.nakamura.cu@nttdocomo.com" , "diego@tid.es" , "raquel.morera@verizon.com" Subject: Re: [vnfpool] New Charter for Toronto X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 22:32:28 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F838E553DEMUMBX005nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Adrian, I understand why you want to avoid introducing a dependency between SDOs in= the charter. Some of the first drafts for VNFPOOL requirements and use cases have been w= ritten by people from and discussed in ETSI NFV REL WG. I think there is already a natural cooperation between VNFPOOL BoF and NFV = REL WG. That said ETSI is a big organization and saying "will exchange information = with ETSI" appears to be insufficient. I would suggest to write "will exchange information with relevant WGs in ET= SI NFV". Cheers, Mehmet From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of ext Adrian Far= rel Sent: Friday, July 04, 2014 8:32 PM To: 'Don Clarke'; 'Zongning'; vnfpool@ietf.org Cc: 'WRIGHT, STEVEN A'; naseem.a.khan@verizon.com; raquel.morera@verizon.co= m; diego@tid.es; tetsuya.nakamura.cu@nttdocomo.com Subject: Re: [vnfpool] New Charter for Toronto Hi Don, Just chipping in from the side lines.... I think this group of people working on VNFpool and those in the SFC work= ing group take the work done by ETSI on NFV very seriously. They coordinate= closely with Diego Lopez and consider the ETSI work as input. However, your proposed text might be a little unusual in an IETF working = group charter. More likely would be to add to the final paragraph as: OLD We will work closely with the SFC WG, as we believe that SFC and VNF Pool= are complementary. SFC would essentially see a VNF Pool-enabled VNF as a n= ormal service function and therefore be able to merge it into an SFC just l= ike any other service functions. Just like the communication between any po= ol users and VNF Pool, the information exchanged between the VNF Pool and t= he SFC may include some operational information of the VNF Pool. NEW The VNFpool working group will work closely with the SFC WG, as SFC and V= NF Pool are complementary: SFC would essentially see a VNF Pool-enabled VNF= as a normal service function and therefore be able to merge it into an SFC= just like any other service functions. Just like the communication between= any pool users and VNF Pool, the information exchanged between the VNF Poo= l and the SFC may include some operational information of the VNF Pool. Fur= thermore, the VNFpool working group will exchange information with ETSI to = ensure that the work done by that body is taken into account and to share t= he progress of the working group as it produces documents. Cheers, Adrian (hating HTML emails) From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Don Clarke Sent: 04 July 2014 17:19 To: Zongning; vnfpool@ietf.org Cc: WRIGHT, STEVEN A; naseem.a.khan@verizon.com; tetsuya.nakamura.cu@nttdocomo.com; diego@tid.es; raquel.morera@verizon.com Subject: Re: [vnfpool] New Charter for Toronto Ning and All, I welcome this work as I have a strong belief that such mechanisms if prope= rly implemented will enable NFV-based network topologies to provide many mo= re options for delivering scalable high reliability networks than tradition= al point-hardware bounded topologies. I have highlighted this message in pu= blic statements whenever I get an opportunity and I have encouraged efforts= in the ETSI NFV ISG towards this goal. I would like to see a reference in this charter to related work in the ETSI= NFV ISG for example in the REL Working Group (Naseem Khan copied) and the = INF Working Group (Steve Wright copied). Also MANO (Raquel Morera copied). = I know that you and no doubt many others on this list are involved in both = places, but could we at least see some words in this charter that acknowled= ge relevant requirements coming from the NFV ISG? Suggested text in line below. Regards, Don Clarke. Chair, NFV ISG Network Operator Council From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Zongning Sent: Thursday, July 03, 2014 8:37 PM To: vnfpool@ietf.org Subject: [vnfpool] New Charter for Toronto Hi, all, Please find below the new VNFPool Charter, by which I'd like to keep ente= rtaining you. :) This new version is based on the list discussion and feedback mainly from= LAC Chidung, Hidetoshi, Sood, and Adrian. Thank you guys for improving our= charter. Although I'd regard this version as a stable charter that reflect= s a rough agreement on the list and is ready for Toronto, further comments = and suggestions are *always* welcome. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Network functions such as firewalls, load balancers, and WAN optimizers a= re conventionally deployed as specialized hardware servers in both network = operators' networks and data center networks as the building blocks of netw= ork services. There is a trend to implement such network functions as softw= are instances running on general purpose servers, via a virtualization laye= r (i.e., hypervisors). These virtualized functions are called Virtualized N= etwork Functions (VNFs), which can be used to build network services. The use of VNFs introduces additional challenges to the reliability of th= e provided network services. A single VNF instance would typically not have= built-in reliability mechanisms on its host (i.e., a general purpose serve= r). Instead, there are more risk factors such as software failure at variou= s levels including hypervisors and virtual machines, hardware failure, and = instance migration that can make a VNF instance unreliable. In order to achieve higher reliability, a VNF implementation may adopt a = pooling mechanism, where a number of VNF instances with the same function c= an be grouped as a pool to provide the function. We call such a pool a VNF = Pool. Conceptually, a Pool Manager is used to manage a VNF Pool, e.g., sele= cts active/standby VNF instances, and potentially interacts with a service = control entity. Such a service control entity is an entity that orchestrate= s a set of network functions to build network services. The major benefit o= f using VNF Pool is that reliability mechanisms such as redundancy model ar= e achieved by the VNF Pool adopted by the VNF and thus not visible to the s= ervice control entity. A VNF Pool-enabled VNF still appears as a normal VNF= when orchestrated by a service control entity. Questions that are raised by the addition of a pooling mechanism to VNF i= nclude: * How to manage the redundancy model, e.g., select active/standby VNF= instances in a VNF Pool considering the infrastructure conditions, and sca= le a VNF instance in a VNF Pool? * What pool states need to be maintained to support the pooling mecha= nism itself, and how are such states maintained? * What information is exchanged between a VNF and a service control e= ntity? For example, how can a VNF Pool be addressed by the service control = entity? * After a VNF instance failover, how does the Pool Manager notify the= service control entity of some characteristic changes of the VNF, e.g., ca= pacity change, but without disclosure of the pooling procedure? The WG will refer to published ETSI NFV ISG documents relevant to this wo= rk, notably (but not limited to) the outputs of the REL, MANO and INF Worki= ng Groups to ensure that VNF Pooling mechanisms are compatible with the req= uirements published by the ETSI NFV ISG. The WG initially focuses on several reliability mechanisms that are mainl= y associated with a redundancy model based on a VNF Pool. Additional mechan= isms may include pool state maintenance only for pooling purpose. Service s= tate synchronization is out of scope for this phase. The WG assumes that a = VNF Pool contains redundant VNF instances of a same functional type. Differ= ent types of VNFs are envisioned to be held in separate VNF Pools. VNF Pool= composed of both virtualized and non-virtualized functional instances may = be included after further use case and requirements study. The WG will addr= ess the reliability of an individual VNF, but not the reliability related t= o the control or the routing between adjacent VNFs that can form a network = service. Specifically, the WG will study the following technical aspects: * Redundancy management within a VNF Pool, such as the signaling betw= een the Pool Manager and the instances in the pool for instance registratio= n, backup instances selection, and switching between active and standby ins= tances. * Protocol between the Pool Manager and the underlying network to col= lect the network information required for appropriate placement/selection o= f backup instances. * Protocol between a VNF and the service control entity to exchange o= perational information between a VNF Pool and the service control entity. * Identification and analysis of reliable interfaces, such as transpo= rt protocol like MPTCP and SCTP for reliable delivery of the messages assoc= iated with the redundancy management within a VNF Pool. * Analysis of pooling security characteristics and requirements to id= entify and mitigate threats against the pooling mechanism. Identification o= f an appropriate trust model between pool members, and between pool members= and the Pool Manager. The WG plans to deliver a problem statement, a set of use cases, requirem= ents and an architecture covering the aforementioned technical aspects, and= gap analysis of existing technologies including but not limited to RSerPoo= l. We will rely heavily on existing IETF technologies, but that gaps will b= e found around problems like redundancy mechanisms, state maintenance solel= y for pooling purposes, reliable transport, and trust/security, all of whic= h will need to be considered and addressed. Although no decision on protoco= ls will be made in this phase, we will keep open for candidate protocols fo= r VNF Pool. The WG will seek re-chartering before adopting any work to deve= lop new, or extend existing, protocols. We will work closely with the SFC WG, as we believe that SFC and VNF Pool= are complementary. SFC would essentially see a VNF Pool-enabled VNF as a n= ormal service function and therefore be able to merge it into an SFC just l= ike any other service functions. Just like the communication between any po= ol users and VNF Pool, the information exchanged between the VNF Pool and t= he SFC may include some operational information of the VNF Pool. Goals and Milestones: December 2014 - Submit VNFPool Problem Statement to IESG for publication = as an Informational document. April 2015 - Submit VNFPool Use Cases to IESG for publication as an Infor= mational document. August 2015 - Submit VNFPool Requirements, including the manageability of= VNF Pool to IESG for publication as an Informational document. August 2015 - Submit VNFPool Architecture to IESG for publication as an I= nformational document. December 2015 - Submit one or more Applicability and Gap Analysis of exis= ting protocols to VNFPool to IESG for publication as Informational document= (s). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Thanks. -Ning --_000_E4DE949E6CE3E34993A2FF8AE79131F838E553DEMUMBX005nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Adrian,
I understand why you want to avoid introduc= ing a dependency between SDOs in the charter.
Some of the first drafts for VNFPOOL requir= ements and use cases have been written by people from and discussed in ETSI= NFV REL WG.
I think there is already a natural cooperation between VNFPOOL BoF and NFV = REL WG.
That said ETSI is a big organization and sa= ying “will exchange information with ETSI” appears to be insufficient.
I would suggest to write R= 20;will exchange information with relevant WGs in ETSI NFV”.
Cheers,
Mehmet
 
From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of = ext Adrian Farrel
Sent: Friday, July 04, 2014 8:32 PM
To: 'Don Clarke'; 'Zongning'; vnfpool@ietf.org
Cc: 'WRIGHT, STEVEN A'; naseem.a.khan@verizon.com; raquel.morera@ver= izon.com; diego@tid.es; tetsuya.nakamura.cu@nttdocomo.com
Subject: Re: [vnfpool] New Charter for Toronto
&nbs= p;
Hi Don,
Just chipping in from the side lines....
I think this group of people working on VNFpool and those in the S= FC working group take the work done by ETSI on NFV very seriously. They coo= rdinate closely with Diego Lopez and consider the ETSI work as input.
However, your proposed text might be a little unusual in an IETF w= orking group charter. More likely would be to add to the final paragraph as= :
OLD
We will work closely with the SFC WG, as we believe that SFC and V= NF Pool are complementary. SFC would essentially see a VNF Pool-enabled VNF= as a normal service function and therefore be able to merge it into an SFC just like any other service functions. Just= like the communication between any pool users and VNF Pool, the informatio= n exchanged between the VNF Pool and the SFC may include some operational i= nformation of the VNF Pool.
NEW
The VNFpool working group will work closely with the SFC WG, as SF= C and VNF Pool are complementary: SFC would essentially see a VNF Pool-enab= led VNF as a normal service function and therefore be able to merge it into an SFC just like any other service funct= ions. Just like the communication between any pool users and VNF Pool, the = information exchanged between the VNF Pool and the SFC may include some ope= rational information of the VNF Pool. Furthermore, the VNFpool working group will exchange information with= ETSI to ensure that the work done by that body is taken into account and t= o share the progress of the working group as it produces documents.<= /font>
 
Cheers,
Adrian (hating HTML emails)
From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Don Clarke
Sent: 04 July 2014 17:19
To: Zongning; vnfpool@ietf.org
Cc: WRIGHT, STEVEN A; <= font color=3D"blue">naseem.a.khan@verizon.com; tetsuya.= nakamura.cu@nttdocomo.com; diego@tid.es; raquel.morera@verizon.com
Subject: Re: [vnfpool] New Charter for Toronto
&nbs= p;
Ning and All,
 
I welcome this work as I have a strong belief that such mecha= nisms if properly implemented will enable NFV-based network topologies to p= rovide many more options for delivering scalable high reliability networks than traditional point-hardware bounded = topologies. I have highlighted this message in public statements whenever I= get an opportunity and I have encouraged efforts in the ETSI NFV ISG towar= ds this goal.
 
I would like to see a reference in this charter to related wo= rk in the ETSI NFV ISG for example in the REL Working Group (Naseem Khan co= pied) and the INF Working Group (Steve Wright copied). Also MANO (Raquel Morera copied). I know that you and no doubt man= y others on this list are involved in both places, but could we at least se= e some words in this charter that acknowledge relevant requirements coming = from the NFV ISG?
 
Suggested text in line below.
 
Regards,
Don Clarke.
 
Chair, NFV ISG Network Operator Council
 
From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Zongning
Sent: Thursday, July 03, 2014 8:37 PM
To: vnfp= ool@ietf.org
Subject: [vnfpool] New Charter for Toronto
&nbs= p;
Hi, all= ,
Please = find below the new VNFPool Charter, by which I’d like to keep enterta= ining you. J
This ne= w version is based on the list discussion and feedback mainly from LAC Chid= ung, Hidetoshi, Sood, and Adrian. Thank you guys for improving our charter.= Although I’d regard this version as a stable charter that reflects a rough agreement on the list and is ready for= Toronto, further comments and suggestions are *always* welcome.
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Network= functions such as firewalls, load balancers, and WAN optimizers are conven= tionally deployed as specialized hardware servers in both network operators= ' networks and data center networks as the building blocks of network services. There is a trend to implement such= network functions as software instances running on general purpose servers= , via a virtualization layer (i.e., hypervisors). These virtualized functio= ns are called Virtualized Network Functions (VNFs), which can be used to build network services.
The use= of VNFs introduces additional challenges to the reliability of the provide= d network services. A single VNF instance would typically not have built-in= reliability mechanisms on its host (i.e., a general purpose server). Instead, there are more risk factors such as sof= tware failure at various levels including hypervisors and virtual machines,= hardware failure, and instance migration that can make a VNF instance unre= liable.
In orde= r to achieve higher reliability, a VNF implementation may adopt a pooling m= echanism, where a number of VNF instances with the same function can be gro= uped as a pool to provide the function. We call such a pool a VNF Pool. Conceptually, a Pool Manager is used to man= age a VNF Pool, e.g., selects active/standby VNF instances, and potentially= interacts with a service control entity. Such a service control entity is = an entity that orchestrates a set of network functions to build network services. The major benefit of using = VNF Pool is that reliability mechanisms such as redundancy model are achiev= ed by the VNF Pool adopted by the VNF and thus not visible to the service c= ontrol entity. A VNF Pool-enabled VNF still appears as a normal VNF when orchestrated by a service control en= tity.
Questio= ns that are raised by the addition of a pooling mechanism to VNF include:
  • How to manage the redundanc= y model, e.g., select active/standby VNF instances in a VNF Pool considerin= g the infrastructure conditions, and scale a VNF instance in a VNF Pool?
  • What pool states need to = be maintained to support the pooling mechanism itself, and how are such sta= tes maintained?
  • What in= formation is exchanged between a VNF and a service control entity? For exam= ple, how can a VNF Pool be addressed by the service control entity?
    • After a VNF instance failover,= how does the Pool Manager notify the service control entity of some charac= teristic changes of the VNF, e.g., capacity change, but without disclosure = of the pooling procedure?
The WG will refer to pu= blished ETSI NFV ISG documents relevant to this work, notably (but not limi= ted to) the outputs of the REL, MANO and INF Working Groups to ensure that VNF Pooling mechanisms are compatible with th= e requirements published by the ETSI NFV ISG.
The WG = initially focuses on several reliability mechanisms that are mainly associa= ted with a redundancy model based on a VNF Pool. Additional mechanisms may = include pool state maintenance only for pooling purpose. Service state synchronization is out of scope for this pha= se. The WG assumes that a VNF Pool contains redundant VNF instances of a sa= me functional type. Different types of VNFs are envisioned to be held in se= parate VNF Pools. VNF Pool composed of both virtualized and non-virtualized functional instances may be include= d after further use case and requirements study. The WG will address the re= liability of an individual VNF, but not the reliability related to the cont= rol or the routing between adjacent VNFs that can form a network service.
Specifi= cally, the WG will study the following technical aspects:
  • Redundancy management withi= n a VNF Pool, such as the signaling between the Pool Manager and the instan= ces in the pool for instance registration, backup instances selection, and = switching between active and standby instances.
  • Protocol bet= ween the Pool Manager and the underlying network to collect the network inf= ormation required for appropriate placement/selection of backup instances.<= /li>
  • Protocol between a VNF = and the service control entity to exchange operational information between = a VNF Pool and the service control entity.
  • Identification and analysis of reliable interfaces, suc= h as transport protocol like MPTCP and SCTP for reliable delivery of the me= ssages associated with the redundancy management within a VNF Pool.
    • Analysis of pooling security c= haracteristics and requirements to identify and mitigate threats against th= e pooling mechanism. Identification of an appropriate trust model between p= ool members, and between pool members and the Pool Manager.
The WG = plans to deliver a problem statement, a set of use cases, requirements and = an architecture covering the aforementioned technical aspects, and gap anal= ysis of existing technologies including but not limited to RSerPool. We will rely heavily on existing IETF technolo= gies, but that gaps will be found around problems like redundancy mechanism= s, state maintenance solely for pooling purposes, reliable transport, and t= rust/security, all of which will need to be considered and addressed. Although no decision on protocols will= be made in this phase, we will keep open for candidate protocols for VNF P= ool. The WG will seek re-chartering before adopting any work to develop new= , or extend existing, protocols.
We will= work closely with the SFC WG, as we believe that SFC and VNF Pool are comp= lementary. SFC would essentially see a VNF Pool-enabled VNF as a normal ser= vice function and therefore be able to merge it into an SFC just like any other service functions. Just like the c= ommunication between any pool users and VNF Pool, the information exchanged= between the VNF Pool and the SFC may include some operational information = of the VNF Pool.
Goals a= nd Milestones:
Decembe= r 2014 - Submit VNFPool Problem Statement to IESG for publication as an Inf= ormational document.
April 2= 015 - Submit VNFPool Use Cases to IESG for publication as an Informational = document.
August = 2015 - Submit VNFPool Requirements, including the manageability of VNF Pool= to IESG for publication as an Informational document.
August = 2015 - Submit VNFPool Architecture to IESG for publication as an Informatio= nal document.
Decembe= r 2015 - Submit one or more Applicability and Gap Analysis of existing prot= ocols to VNFPool to IESG for publication as Informational document(s).
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Thanks.=
-Ning
 
 --_000_E4DE949E6CE3E34993A2FF8AE79131F838E553DEMUMBX005nsnintr_-- From nobody Fri Jul 4 17:30:40 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 123FF1A0092 for ; Fri, 4 Jul 2014 17:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYHSafdwx5WT for ; Fri, 4 Jul 2014 17:30:37 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB311A002A for ; Fri, 4 Jul 2014 17:30:37 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 65D051DE05D; Fri, 4 Jul 2014 17:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=nomountain.net; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s= nomountain.net; bh=zFw9jmIr+ml7XJL2FciHaRn1iT0=; b=mH/wrGhyOrzZy X+u0UXdgwm3MuTiInERtRazZiqpjkuuYgXUkKFW6UZQx1LH+kDuMKn73qMHR/tmJ mV6HNYLpBUpZmNEYoVBZ9bhG8YG6P57WQ6iSKDirHVDAFNMJojcbcZwv0wqgc8uM Gf+DgVFrOO4JiJhCOl6mJZgoon6hS0= Received: from spandex.local (unknown [216.67.57.220]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: melinda.shore@nomountain.net) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id 9CAA71DE059; Fri, 4 Jul 2014 17:30:36 -0700 (PDT) Message-ID: <53B7472B.7070004@nomountain.net> Date: Fri, 04 Jul 2014 16:30:35 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: vnfpool@ietf.org, "Ersue, Mehmet (NSN - DE/Munich)" References: <0ec801cf97b6$3a660400$af320c00$@olddog.co.uk> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/pn_hv6SLXQgIhkDNhSuY8vBNQUA Subject: Re: [vnfpool] New Charter for Toronto X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 00:30:38 -0000 On 7/4/14 2:32 PM, Ersue, Mehmet (NSN - DE/Munich) wrote: > That said ETSI is a big organization and saying =93will exchange > information with ETSI=94 appears to be insufficient. > I would suggest to write=93will exchange information with relevant WGs = in > ETSI NFV=94. Are you anticipating a liaison, or keeping it informal? I agree about being specific about which ETSI body will be engaged. Melinda --=20 Melinda Shore No Mountain Software melinda.shore@nomountain.net "Software longa, hardware brevis." From nobody Fri Jul 4 23:31:03 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8371A0354 for ; Fri, 4 Jul 2014 23:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxIcrJ9D_r1F for ; Fri, 4 Jul 2014 23:30:59 -0700 (PDT) Received: from out26-ams.mf.surf.net (out26-ams.mf.surf.net [145.0.1.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE3B01A0350 for ; Fri, 4 Jul 2014 23:30:57 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by outgoing1-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s656UtQA003272; Sat, 5 Jul 2014 08:30:55 +0200 Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sat, 5 Jul 2014 08:30:59 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.31]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.03.0181.006; Sat, 5 Jul 2014 08:30:55 +0200 From: To: , , Thread-Topic: [vnfpool] New Charter for Toronto Thread-Index: Ac+XKHD4e3Tyhku3QbmwqloaWSCkwwAeKS/wAAEYCgAACGO1gAAEI3mAABBPG5s= Date: Sat, 5 Jul 2014 06:30:54 +0000 Message-ID: References: <0ec801cf97b6$3a660400$af320c00$@olddog.co.uk> , <53B7472B.7070004@nomountain.net> In-Reply-To: <53B7472B.7070004@nomountain.net> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.91.134.3] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Bayes-Prob: 0.0001 (Score 0, tokens from: utwente-out:default, base:default, @@RPTN) X-CanIt-Geo: ip=130.89.5.48; country=NL; region=Provincie Overijssel; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default) X-Canit-Stats-ID: 0uMmuuTOe - b3095e1cdcc3 - 20140705 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/bK4ysfP8Z8ivUx3sCbZRUKZCtsA Subject: Re: [vnfpool] New Charter for Toronto X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 06:31:01 -0000 Hi all, If possible a liaison will be IMHO better! This will probably increase the= =20 certainty of specifying solutions that will be beneficiary for both SDOs. In addition to that I would also like to mention that the 3GPP SA WG5=20 approved a new Study Item on Network Management of Virtualized Networks.=20 The objective of this activity is to provide recommendations for the=20 standardization of the network management of fully virtualized mobile netwo= rks=20 and mixed networks.=20 I think that a possible cooperation between IETF and this new 3GPP SA WG5 w= ill also be beneficiary! Best regards, Georgios ________________________________________ Van: vnfpool [vnfpool-bounces@ietf.org] namens Melinda Shore [melinda.shore= @nomountain.net] Verzonden: zaterdag 5 juli 2014 2:30 Aan: vnfpool@ietf.org; Ersue, Mehmet (NSN - DE/Munich) Onderwerp: Re: [vnfpool] New Charter for Toronto On 7/4/14 2:32 PM, Ersue, Mehmet (NSN - DE/Munich) wrote: > That said ETSI is a big organization and saying =93will exchange > information with ETSI=94 appears to be insufficient. > I would suggest to write=93will exchange information with relevant WGs in > ETSI NFV=94. Are you anticipating a liaison, or keeping it informal? I agree about being specific about which ETSI body will be engaged. Melinda -- Melinda Shore No Mountain Software melinda.shore@nomountain.net "Software longa, hardware brevis." _______________________________________________ vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool= From nobody Sun Jul 6 17:07:51 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B261B27CE for ; Sat, 5 Jul 2014 12:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.301 X-Spam-Level: X-Spam-Status: No, score=-6.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PSFUR_rIkUf for ; Sat, 5 Jul 2014 12:34:55 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 528DD1B27C8 for ; Sat, 5 Jul 2014 12:34:55 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s65JYfSx015096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 5 Jul 2014 19:34:41 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s65JYbT7001135 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 5 Jul 2014 21:34:37 +0200 Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sat, 5 Jul 2014 21:34:37 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.136]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0181.006; Sat, 5 Jul 2014 21:34:37 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: ext Melinda Shore , "adrian@olddog.co.uk" , "'Don Clarke'" , "'Zongning'" , "vnfpool@ietf.org" Thread-Topic: [vnfpool] New Charter for Toronto Thread-Index: AQL1TVX33y6XDgqr0E62DMj7iKcISgLrSoyrmS11ulCAAC40UIAAE2KAgAD0CkA= Date: Sat, 5 Jul 2014 19:34:37 +0000 Message-ID: References: <0ec801cf97b6$3a660400$af320c00$@olddog.co.uk> <53B744CB.9000404@nomountain.net> In-Reply-To: <53B744CB.9000404@nomountain.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.156] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1282 X-purgate-ID: 151667::1404588882-000005B1-F1C47088/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/zTuTQ_WBH3ZlL4kIoi0IFt-uX1Y X-Mailman-Approved-At: Sun, 06 Jul 2014 17:07:46 -0700 Cc: "'WRIGHT, STEVEN A'" , "naseem.a.khan@verizon.com" , "raquel.morera@verizon.com" , "diego@tid.es" , "tetsuya.nakamura.cu@nttdocomo.com" Subject: Re: [vnfpool] New Charter for Toronto X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 19:34:57 -0000 > On 7/4/14 2:32 PM, Ersue, Mehmet (NSN - DE/Munich) wrote: > > That said ETSI is a big organization and saying "will exchange > > information with ETSI" appears to be insufficient. > > I would suggest to write"will exchange information with relevant WGs > in > > ETSI NFV". >=20 > Are you anticipating a liaison, or keeping it informal? I think a liaison between VNFPOOL and NFV REL WGs would be valuable,=20 which I assume will happen sooner or later. =20 > I agree about being specific about which ETSI body will be > engaged. You can express what is already happening in many ways, also e.g. "..will exchange information with relevant WGs in ETSI NFV, e.g. REL WG.." = or=20 "..will exchange information with ETSI NFV REL, MANO and INF WGs..". Let me know which one you prefer. There is one point though, which I would like to underline. Being active in two organizations I know that compared to some other SDOs, = ETSI NFV people are not trying to declare a technology as their ownership. = It is just the aim to contribute and cooperate in the interest of reliable = VNF pools. Cheers, Mehmet > Melinda >=20 >=20 > -- > Melinda Shore > No Mountain Software > melinda.shore@nomountain.net >=20 > "Software longa, hardware brevis." From nobody Sun Jul 6 17:07:55 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D9B1A0AA3 for ; Sun, 6 Jul 2014 13:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.285 X-Spam-Level: ** X-Spam-Status: No, score=2.285 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HT9R1l--m7qP for ; Sun, 6 Jul 2014 13:53:11 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 11AD01A0AA2 for ; Sun, 6 Jul 2014 13:53:10 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id s66Kr1fP028607; Sun, 6 Jul 2014 14:53:01 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Sun, 06 Jul 2014 14:53:00 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([::1]) by EXCHANGE.cablelabs.com ([::1]) with mapi id 14.03.0195.001; Sun, 6 Jul 2014 14:53:00 -0600 From: Don Clarke To: DIEGO LOPEZ GARCIA , ext Melinda Shore , "Ersue, Mehmet (NSN - DE/Munich)" Thread-Topic: [vnfpool] New Charter for Toronto Thread-Index: Ac+XKHD4e3Tyhku3QbmwqloaWSCkwwAeKS/wABHbkwAACGO0gAADyOCAAChPDoAACILZgAAfiVBb Date: Sun, 6 Jul 2014 20:52:59 +0000 Message-ID: References: <0ec801cf97b6$3a660400$af320c00$@olddog.co.uk> <53B744CB.9000404@nomountain.net> , <1527F33A-81DD-4672-9B57-AE2BD3D80BF9@telefonica.com> In-Reply-To: <1527F33A-81DD-4672-9B57-AE2BD3D80BF9@telefonica.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.5.0.27] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/-QaJP2hszB8M9n9KhP5MN921EDo X-Mailman-Approved-At: Sun, 06 Jul 2014 17:07:47 -0700 Cc: "vnfpool@ietf.org" , "WRIGHT, STEVEN A" , Raquel Morera , "tetsuya.nakamura.cu@nttdocomo.com" , Zongning , "naseem.a.khan@verizon.com" , "adrian@olddog.co.uk" Subject: Re: [vnfpool] New Charter for Toronto X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 20:53:12 -0000 Sorry for triggering such a big discussion. I think Mehmet captured my conc= ern exactly. I only wanted to be sure that the IETF vnfpool folks take acco= unt of the excellent ground work already documented. I also recognize that = the best way to achieve that is by active contribution. On the other hand = it does no harm to be explicit in the charter and through ongoing formal li= aison to help "institutionalize" the relationship. Especially for folks in = the IETF who might not understand the significance of the ISG work. I also agree there is no rush to put in a liaison as we have high profile i= ndividuals active in both places at the moment and hopefully ongoing.=20 Regards, Don.=20 ________________________________________ From: DIEGO LOPEZ GARCIA [diego.r.lopez@telefonica.com] Sent: Saturday, July 05, 2014 18:38 To: ext Melinda Shore; Ersue, Mehmet (NSN - DE/Munich) Cc: adrian@olddog.co.uk; Don Clarke; Zongning; vnfpool@ietf.org; WRIGHT, ST= EVEN A; naseem.a.khan@verizon.com; tetsuya.nakamura.cu@nttdocomo.com; DIEGO= LOPEZ GARCIA; Raquel Morera Subject: Re: [vnfpool] New Charter for Toronto Hi, On 5 Jul 2014, at 21:34 , Ersue, Mehmet (NSN - DE/Munich) > wrote: I agree about being specific about which ETSI body will be engaged. You can express what is already happening in many ways, also e.g. "..will exchange information with relevant WGs in ETSI NFV, e.g. REL WG.." = or "..will exchange information with ETSI NFV REL, MANO and INF WGs..". Let me know which one you prefer. Just let me note that I think the first one, as it is more open to future e= volution in the ETSI NFV. There is one point though, which I would like to underline. Being active in two organizations I know that compared to some other SDOs, = ETSI NFV people are not trying to declare a technology as their ownership. = It is just the aim to contribute and cooperate in the interest of reliable = VNF pools. Being in the same position as Mehmet is, let me support his view on this as= well. Be goode, -- PLEASE NOTE MY NEW EMAIL ADDRESS "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o From nobody Sun Jul 6 19:28:33 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B1A1A00C3 for ; Sun, 6 Jul 2014 19:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.552 X-Spam-Level: X-Spam-Status: No, score=-104.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7OP4Ma0PHu7 for ; Sun, 6 Jul 2014 19:28:27 -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 58E881A00C2 for ; Sun, 6 Jul 2014 19:28:26 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJR64319; Mon, 07 Jul 2014 02:28:24 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 7 Jul 2014 03:28:23 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Mon, 7 Jul 2014 10:26:31 +0800 From: Zongning To: Don Clarke Thread-Topic: [vnfpool] New Charter for Toronto Thread-Index: Ac+XKHD4e3Tyhku3QbmwqloaWSCkwwAeKS/w//+kKwCAAEMdgIAAHkeAgAFCeYCAAEQWgIABZCSA//8ms0A= Date: Mon, 7 Jul 2014 02:26:30 +0000 Message-ID: References: <0ec801cf97b6$3a660400$af320c00$@olddog.co.uk> <53B744CB.9000404@nomountain.net> , <1527F33A-81DD-4672-9B57-AE2BD3D80BF9@telefonica.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.138.41.54] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/dWnqcchPTPUHiaQONwrhScQxPYU Cc: "vnfpool@ietf.org" , "WRIGHT, STEVEN A" , Raquel Morera , "tetsuya.nakamura.cu@nttdocomo.com" Subject: [vnfpool] =?utf-8?b?562U5aSNOiAgTmV3IENoYXJ0ZXIgZm9yIFRvcm9udG8=?= X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 02:28:29 -0000 SGksIERvbiBhbmQgQWxsLA0KDQooZGVsZXRlZCBzb21lIHJlY2lwaWVudHMgYXMgdGhleSBhcmUg YWxyZWFkeSB0aGUgbWVtYmVycyBvZiB2bmZwb29sIGxpc3QgLi4uKQ0KDQpGaXJzdGx5LCB0aGFu ayB5b3Ugc28gbXVjaCBmb3IgYWNrbm93bGVkZ2luZyBvdXIgd29yayBvZiBWTkZQb29sIGluIElF VEYuIDotKQ0KSSBhYnNvbHV0ZWx5IGFncmVlIHRoYXQgVk5GUG9vbCBmb2xrcyBzaG91bGQgcHJv cGVybHkgdGFrZSB0aGUgZXhjZWxsZW50IHdvcmsgZG9uZSBieSBORlYgSVNHIGludG8gYWNjb3Vu dCB3aGVuZXZlciBhcHByb3ByaWF0ZS4gQWN0dWFsbHksIGFzIG1lbnRpb25lZCBieSBEYW5pZWws IHRoZSBjby1hdXRob3JzIG9mIGV4aXN0aW5nIFZORlBvb2wgZHJhZnRzIGhhdmUgYmVlbiBraW5k bHkgcmVnYXJkaW5nIElTRyBhcyBrZXkgaW5mb3JtYXRpb25hbCByZXNvdXJjZSwgYW5kIHdpbGwg Y29udGludWUgbWFraW5nIGFwcHJvcHJpYXRlIHJlZmVyZW5jZXMgd2hlbiBtb3JlIElTRyBkb2N1 bWVudHMgYXJlIHB1YmxpY2x5IGF2YWlsYWJsZS4NCkkgYW0gYWxzbyBnbGFkIHRvIGxldCB5b3Ug a25vdyB0aGF0IGZyb20gdGhlIGRheSBvbmUgb2YgVk5GUG9vbCBpbml0aWF0aXZlLCB0aGUgYWN0 aXZlIGNvbnRyaWJ1dG9ycyBhcmUgKHJlYWxseSkgYWN0aXZlIGluIGJvdGggY29tbXVuaXRpZXMu IEZvciBpbnN0YW5jZSwgSSB3YXMgbGVhZGluZyBHYXAgQW5hbHlzaXMgc2VjdGlvbiBpbiBSRUwg R1MsIGFuZCBoYWQgY29tbXVuaWNhdGlvbnMgd2l0aCBSRUwgZm9sa3MgYWJvdXQgVk5GUG9vbC4g T24gdGhlIFZORlBvb2wgbGlzdCwgZnJvbSB0aW1lIHRvIHRpbWUgdGhlcmUgYXJlIGZvbGtzIHRh bGtpbmcgYWJvdXQgdGhlIHJlcXVpcmVtZW50cyBmcm9tIFJFTCBXRy4gU28gYm90aCBjb21tdW5p dGllcyBoYXZlIGJlZW4gaW4gYSBnb29kIGFsaWdubWVudCBpbiBhIG5hdHVyZSAoZGUgZmFjdG8p IHdheS4gQnV0IEkgZG8gYWdyZWUgd2l0aCB5b3UgdGhhdCBpdCBkb2VzIG5vIGhhcm0gdG8gYmUg ZXhwbGljaXQgaW4gVk5GUG9vbCBjaGFydGVyIGFuZCB0aHJvdWdoIExTIHRvIGZvcm1hbGl6ZWQg c3VjaCBjb29yZGluYXRpb24uDQpJIHdpbGwgdHJ5IHRvIHN1Z2dlc3Qgc29tZSB3b3JkcyBpbnRv IHRoZSBjaGFydGVyIGFuZCBhbHNvIGhlbHAgb24gdGhlIExTLCB3aGVuIGFwcHJvcHJpYXRlLg0K DQpUaGFua3MuDQoNCi1OaW5nDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujog RG9uIENsYXJrZSBbbWFpbHRvOkQuQ2xhcmtlQGNhYmxlbGFicy5jb21dIA0K5Y+R6YCB5pe26Ze0 OiAyMDE05bm0N+aciDfml6UgNDo1Mw0K5pS25Lu25Lq6OiBESUVHTyBMT1BFWiBHQVJDSUE7IGV4 dCBNZWxpbmRhIFNob3JlOyBFcnN1ZSwgTWVobWV0IChOU04gLSBERS9NdW5pY2gpDQrmioTpgIE6 IGFkcmlhbkBvbGRkb2cuY28udWs7IFpvbmduaW5nOyB2bmZwb29sQGlldGYub3JnOyBXUklHSFQs IFNURVZFTiBBOyBuYXNlZW0uYS5raGFuQHZlcml6b24uY29tOyB0ZXRzdXlhLm5ha2FtdXJhLmN1 QG50dGRvY29tby5jb207IFJhcXVlbCBNb3JlcmENCuS4u+mimDogUkU6IFt2bmZwb29sXSBOZXcg Q2hhcnRlciBmb3IgVG9yb250bw0KDQpTb3JyeSBmb3IgdHJpZ2dlcmluZyBzdWNoIGEgYmlnIGRp c2N1c3Npb24uIEkgdGhpbmsgTWVobWV0IGNhcHR1cmVkIG15IGNvbmNlcm4gZXhhY3RseS4gSSBv bmx5IHdhbnRlZCB0byBiZSBzdXJlIHRoYXQgdGhlIElFVEYgdm5mcG9vbCBmb2xrcyB0YWtlIGFj Y291bnQgb2YgdGhlIGV4Y2VsbGVudCBncm91bmQgd29yayBhbHJlYWR5IGRvY3VtZW50ZWQuIEkg YWxzbyByZWNvZ25pemUgdGhhdCB0aGUgYmVzdCB3YXkgdG8gYWNoaWV2ZSB0aGF0IGlzIGJ5IGFj dGl2ZSBjb250cmlidXRpb24uICBPbiB0aGUgb3RoZXIgaGFuZCBpdCBkb2VzIG5vIGhhcm0gdG8g YmUgZXhwbGljaXQgaW4gdGhlIGNoYXJ0ZXIgYW5kIHRocm91Z2ggb25nb2luZyBmb3JtYWwgbGlh aXNvbiB0byBoZWxwICJpbnN0aXR1dGlvbmFsaXplIiB0aGUgcmVsYXRpb25zaGlwLiBFc3BlY2lh bGx5IGZvciBmb2xrcyBpbiB0aGUgSUVURiB3aG8gbWlnaHQgbm90IHVuZGVyc3RhbmQgdGhlIHNp Z25pZmljYW5jZSBvZiB0aGUgSVNHIHdvcmsuDQoNCkkgYWxzbyBhZ3JlZSB0aGVyZSBpcyBubyBy dXNoIHRvIHB1dCBpbiBhIGxpYWlzb24gYXMgd2UgaGF2ZSBoaWdoIHByb2ZpbGUgaW5kaXZpZHVh bHMgYWN0aXZlIGluIGJvdGggcGxhY2VzIGF0IHRoZSBtb21lbnQgYW5kIGhvcGVmdWxseSBvbmdv aW5nLiANCg0KUmVnYXJkcywNCkRvbi4gDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpGcm9tOiBESUVHTyBMT1BFWiBHQVJDSUEgW2RpZWdvLnIubG9wZXpAdGVsZWZv bmljYS5jb21dDQpTZW50OiBTYXR1cmRheSwgSnVseSAwNSwgMjAxNCAxODozOA0KVG86IGV4dCBN ZWxpbmRhIFNob3JlOyBFcnN1ZSwgTWVobWV0IChOU04gLSBERS9NdW5pY2gpDQpDYzogYWRyaWFu QG9sZGRvZy5jby51azsgRG9uIENsYXJrZTsgWm9uZ25pbmc7IHZuZnBvb2xAaWV0Zi5vcmc7IFdS SUdIVCwgU1RFVkVOIEE7IG5hc2VlbS5hLmtoYW5AdmVyaXpvbi5jb207IHRldHN1eWEubmFrYW11 cmEuY3VAbnR0ZG9jb21vLmNvbTsgRElFR08gTE9QRVogR0FSQ0lBOyBSYXF1ZWwgTW9yZXJhDQpT dWJqZWN0OiBSZTogW3ZuZnBvb2xdIE5ldyBDaGFydGVyIGZvciBUb3JvbnRvDQoNCkhpLA0KDQpP biA1IEp1bCAyMDE0LCBhdCAyMTozNCAsIEVyc3VlLCBNZWhtZXQgKE5TTiAtIERFL011bmljaCkg PG1laG1ldC5lcnN1ZUBuc24uY29tPG1haWx0bzptZWhtZXQuZXJzdWVAbnNuLmNvbT4+IHdyb3Rl Og0KDQpJIGFncmVlIGFib3V0IGJlaW5nIHNwZWNpZmljIGFib3V0IHdoaWNoIEVUU0kgYm9keSB3 aWxsIGJlIGVuZ2FnZWQuDQoNCllvdSBjYW4gZXhwcmVzcyB3aGF0IGlzIGFscmVhZHkgaGFwcGVu aW5nIGluIG1hbnkgd2F5cywgYWxzbyBlLmcuDQoiLi53aWxsIGV4Y2hhbmdlIGluZm9ybWF0aW9u IHdpdGggcmVsZXZhbnQgV0dzIGluIEVUU0kgTkZWLCBlLmcuIFJFTCBXRy4uIiBvciAiLi53aWxs IGV4Y2hhbmdlIGluZm9ybWF0aW9uIHdpdGggRVRTSSBORlYgUkVMLCBNQU5PIGFuZCBJTkYgV0dz Li4iLg0KDQpMZXQgbWUga25vdyB3aGljaCBvbmUgeW91IHByZWZlci4NCg0KSnVzdCBsZXQgbWUg bm90ZSB0aGF0IEkgdGhpbmsgdGhlIGZpcnN0IG9uZSwgYXMgaXQgaXMgbW9yZSBvcGVuIHRvIGZ1 dHVyZSBldm9sdXRpb24gaW4gdGhlIEVUU0kgTkZWLg0KDQpUaGVyZSBpcyBvbmUgcG9pbnQgdGhv dWdoLCB3aGljaCBJIHdvdWxkIGxpa2UgdG8gdW5kZXJsaW5lLg0KQmVpbmcgYWN0aXZlIGluIHR3 byBvcmdhbml6YXRpb25zIEkga25vdyB0aGF0IGNvbXBhcmVkIHRvIHNvbWUgb3RoZXIgU0RPcywg RVRTSSBORlYgcGVvcGxlIGFyZSBub3QgdHJ5aW5nIHRvIGRlY2xhcmUgYSB0ZWNobm9sb2d5IGFz IHRoZWlyIG93bmVyc2hpcC4gSXQgaXMganVzdCB0aGUgYWltIHRvIGNvbnRyaWJ1dGUgYW5kIGNv b3BlcmF0ZSBpbiB0aGUgaW50ZXJlc3Qgb2YgcmVsaWFibGUgVk5GIHBvb2xzLg0KDQpCZWluZyBp biB0aGUgc2FtZSBwb3NpdGlvbiBhcyBNZWhtZXQgaXMsIGxldCBtZSBzdXBwb3J0IGhpcyB2aWV3 IG9uIHRoaXMgYXMgd2VsbC4NCg0KQmUgZ29vZGUsDQoNCi0tDQpQTEVBU0UgTk9URSBNWSBORVcg RU1BSUwgQUREUkVTUw0KIkVzdGEgdmV6IG5vIGZhbGxhcmVtb3MsIERvY3RvciBJbmZpZXJubyIN Cg0KRHIgRGllZ28gUi4gTG9wZXoNClRlbGVmb25pY2EgSStEDQpodHRwOi8vcGVvcGxlLnRpZC5l cy9kaWVnby5sb3Blei8NCg0KZS1tYWlsOiBkaWVnby5yLmxvcGV6QHRlbGVmb25pY2EuY29tDQpU ZWw6ICAgICszNCA5MTMgMTI5IDA0MQ0KTW9iaWxlOiArMzQgNjgyIDA1MSAwOTENCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KDQpFc3RlIG1lbnNhamUgeSBzdXMgYWRqdW50b3Mgc2UgZGlyaWdlbiBleGNsdXNp dmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpbywgcHVlZGUgY29udGVuZXIgaW5mb3JtYWNpw7NuIHBy aXZpbGVnaWFkYSBvIGNvbmZpZGVuY2lhbCB5IGVzIHBhcmEgdXNvIGV4Y2x1c2l2byBkZSBsYSBw ZXJzb25hIG8gZW50aWRhZCBkZSBkZXN0aW5vLiBTaSBubyBlcyB1c3RlZC4gZWwgZGVzdGluYXRh cmlvIGluZGljYWRvLCBxdWVkYSBub3RpZmljYWRvIGRlIHF1ZSBsYSBsZWN0dXJhLCB1dGlsaXph Y2nDs24sIGRpdnVsZ2FjacOzbiB5L28gY29waWEgc2luIGF1dG9yaXphY2nDs24gcHVlZGUgZXN0 YXIgcHJvaGliaWRhIGVuIHZpcnR1ZCBkZSBsYSBsZWdpc2xhY2nDs24gdmlnZW50ZS4gU2kgaGEg cmVjaWJpZG8gZXN0ZSBtZW5zYWplIHBvciBlcnJvciwgbGUgcm9nYW1vcyBxdWUgbm9zIGxvIGNv bXVuaXF1ZSBpbm1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtaXNtYSB2w61hIHkgcHJvY2VkYSBhIHN1 IGRlc3RydWNjacOzbi4NCg0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIHRyYW5z bWlzc2lvbiBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gaW50ZW5k ZWQgb25seSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgbmFtZWQgYWJv dmUuIElmIHRoZSByZWFkZXIgb2YgdGhpcyBtZXNzYWdlIGlzIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBk aXN0cmlidXRpb24gb3IgY29weWluZyBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3RyaWN0bHkg cHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJy b3IsIGRvIG5vdCByZWFkIGl0LiBQbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRl ciB0aGF0IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciBhbmQg dGhlbiBkZWxldGUgaXQuDQoNCkVzdGEgbWVuc2FnZW0gZSBzZXVzIGFuZXhvcyBzZSBkaXJpZ2Vt IGV4Y2x1c2l2YW1lbnRlIGFvIHNldSBkZXN0aW5hdMOhcmlvLCBwb2RlIGNvbnRlciBpbmZvcm1h w6fDo28gcHJpdmlsZWdpYWRhIG91IGNvbmZpZGVuY2lhbCBlIMOpIHBhcmEgdXNvIGV4Y2x1c2l2 byBkYSBwZXNzb2Egb3UgZW50aWRhZGUgZGUgZGVzdGluby4gU2UgbsOjbyDDqSB2b3NzYSBzZW5o b3JpYSBvIGRlc3RpbmF0w6FyaW8gaW5kaWNhZG8sIGZpY2Egbm90aWZpY2FkbyBkZSBxdWUgYSBs ZWl0dXJhLCB1dGlsaXphw6fDo28sIGRpdnVsZ2HDp8OjbyBlL291IGPDs3BpYSBzZW0gYXV0b3Jp emHDp8OjbyBwb2RlIGVzdGFyIHByb2liaWRhIGVtIHZpcnR1ZGUgZGEgbGVnaXNsYcOnw6NvIHZp Z2VudGUuIFNlIHJlY2ViZXUgZXN0YSBtZW5zYWdlbSBwb3IgZXJybywgcm9nYW1vcy1saGUgcXVl IG5vcyBvIGNvbXVuaXF1ZSBpbWVkaWF0YW1lbnRlIHBvciBlc3RhIG1lc21hIHZpYSBlIHByb2Nl ZGEgYSBzdWEgZGVzdHJ1acOnw6NvDQo= From nobody Sun Jul 6 19:48:12 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8BBF1A00C9 for ; Sun, 6 Jul 2014 19:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.551 X-Spam-Level: X-Spam-Status: No, score=-104.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIHT2_rKkdM7 for ; Sun, 6 Jul 2014 19:48:08 -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 755871A00E9 for ; Sun, 6 Jul 2014 19:48:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJR65455; Mon, 07 Jul 2014 02:48:05 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 7 Jul 2014 03:48:04 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Mon, 7 Jul 2014 10:47:59 +0800 From: Zongning To: DIEGO LOPEZ GARCIA , "Ersue, Mehmet (NSN - DE/Munich)" Thread-Topic: [vnfpool] New Charter for Toronto Thread-Index: Ac+XKHD4e3Tyhku3QbmwqloaWSCkwwAeKS/w//+kKwCAAEMdgIAAHkeAgAFCeYCAAEQWgP/9tjmQ Date: Mon, 7 Jul 2014 02:47:57 +0000 Message-ID: References: <0ec801cf97b6$3a660400$af320c00$@olddog.co.uk> <53B744CB.9000404@nomountain.net> <1527F33A-81DD-4672-9B57-AE2BD3D80BF9@telefonica.com> In-Reply-To: <1527F33A-81DD-4672-9B57-AE2BD3D80BF9@telefonica.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.54] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC6667796616D823nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/1AnTnA0RSSDDAtrarRSpAlCp6j4 Cc: "vnfpool@ietf.org" , "WRIGHT, STEVEN A" , Raquel Morera , Don Clarke , "tetsuya.nakamura.cu@nttdocomo.com" Subject: [vnfpool] =?utf-8?b?562U5aSNOiAgTmV3IENoYXJ0ZXIgZm9yIFRvcm9udG8=?= X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 02:48:10 -0000 --_000_B0D29E0424F2DE47A0B36779EC6667796616D823nkgeml501mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIERpZWdvIGFuZCBNZWhtZXQsDQoNCkkgcHJlZmVyIHRoZSBmaXJzdCBvbmUgYXMgd2VsbC4g 4pi6DQoNClRoYW5rcy4NCg0KLU5pbmcNCg0K5Y+R5Lu25Lq6OiBESUVHTyBMT1BFWiBHQVJDSUEg W21haWx0bzpkaWVnby5yLmxvcGV6QHRlbGVmb25pY2EuY29tXQ0K5Y+R6YCB5pe26Ze0OiAyMDE0 5bm0N+aciDbml6UgNzozOA0K5pS25Lu25Lq6OiBleHQgTWVsaW5kYSBTaG9yZTsgRXJzdWUsIE1l aG1ldCAoTlNOIC0gREUvTXVuaWNoKQ0K5oqE6YCBOiBhZHJpYW5Ab2xkZG9nLmNvLnVrOyBEb24g Q2xhcmtlOyBab25nbmluZzsgdm5mcG9vbEBpZXRmLm9yZzsgV1JJR0hULCBTVEVWRU4gQTsgbmFz ZWVtLmEua2hhbkB2ZXJpem9uLmNvbTsgdGV0c3V5YS5uYWthbXVyYS5jdUBudHRkb2NvbW8uY29t OyBESUVHTyBMT1BFWiBHQVJDSUE7IFJhcXVlbCBNb3JlcmENCuS4u+mimDogUmU6IFt2bmZwb29s XSBOZXcgQ2hhcnRlciBmb3IgVG9yb250bw0KDQpIaSwNCg0KT24gNSBKdWwgMjAxNCwgYXQgMjE6 MzQgLCBFcnN1ZSwgTWVobWV0IChOU04gLSBERS9NdW5pY2gpIDxtZWhtZXQuZXJzdWVAbnNuLmNv bTxtYWlsdG86bWVobWV0LmVyc3VlQG5zbi5jb20+PiB3cm90ZToNCg0KDQpJIGFncmVlIGFib3V0 IGJlaW5nIHNwZWNpZmljIGFib3V0IHdoaWNoIEVUU0kgYm9keSB3aWxsIGJlDQplbmdhZ2VkLg0K DQpZb3UgY2FuIGV4cHJlc3Mgd2hhdCBpcyBhbHJlYWR5IGhhcHBlbmluZyBpbiBtYW55IHdheXMs IGFsc28gZS5nLg0KIi4ud2lsbCBleGNoYW5nZSBpbmZvcm1hdGlvbiB3aXRoIHJlbGV2YW50IFdH cyBpbiBFVFNJIE5GViwgZS5nLiBSRUwgV0cuLiIgb3INCiIuLndpbGwgZXhjaGFuZ2UgaW5mb3Jt YXRpb24gd2l0aCBFVFNJIE5GViBSRUwsIE1BTk8gYW5kIElORiBXR3MuLiIuDQoNCkxldCBtZSBr bm93IHdoaWNoIG9uZSB5b3UgcHJlZmVyLg0KDQpKdXN0IGxldCBtZSBub3RlIHRoYXQgSSB0aGlu ayB0aGUgZmlyc3Qgb25lLCBhcyBpdCBpcyBtb3JlIG9wZW4gdG8gZnV0dXJlIGV2b2x1dGlvbiBp biB0aGUgRVRTSSBORlYuDQoNCg0KVGhlcmUgaXMgb25lIHBvaW50IHRob3VnaCwgd2hpY2ggSSB3 b3VsZCBsaWtlIHRvIHVuZGVybGluZS4NCkJlaW5nIGFjdGl2ZSBpbiB0d28gb3JnYW5pemF0aW9u cyBJIGtub3cgdGhhdCBjb21wYXJlZCB0byBzb21lIG90aGVyIFNET3MsIEVUU0kgTkZWIHBlb3Bs ZSBhcmUgbm90IHRyeWluZyB0byBkZWNsYXJlIGEgdGVjaG5vbG9neSBhcyB0aGVpciBvd25lcnNo aXAuIEl0IGlzIGp1c3QgdGhlIGFpbSB0byBjb250cmlidXRlIGFuZCBjb29wZXJhdGUgaW4gdGhl IGludGVyZXN0IG9mIHJlbGlhYmxlIFZORiBwb29scy4NCg0KQmVpbmcgaW4gdGhlIHNhbWUgcG9z aXRpb24gYXMgTWVobWV0IGlzLCBsZXQgbWUgc3VwcG9ydCBoaXMgdmlldyBvbiB0aGlzIGFzIHdl bGwuDQoNCkJlIGdvb2RlLA0KDQotLQ0KUExFQVNFIE5PVEUgTVkgTkVXIEVNQUlMIEFERFJFU1MN CiJFc3RhIHZleiBubyBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVybm8iDQoNCkRyIERpZWdvIFIu IExvcGV6DQpUZWxlZm9uaWNhIEkrRA0KaHR0cDovL3Blb3BsZS50aWQuZXMvZGllZ28ubG9wZXov DQoNCmUtbWFpbDogZGllZ28uci5sb3BlekB0ZWxlZm9uaWNhLmNvbTxtYWlsdG86ZGllZ28uci5s b3BlekB0ZWxlZm9uaWNhLmNvbT4NClRlbDogICAgKzM0IDkxMyAxMjkgMDQxDQpNb2JpbGU6ICsz NCA2ODIgMDUxIDA5MQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkVzdGUgbWVuc2FqZSB5IHN1cyBhZGp1 bnRvcyBzZSBkaXJpZ2VuIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLCBwdWVkZSBj b250ZW5lciBpbmZvcm1hY2nDs24gcHJpdmlsZWdpYWRhIG8gY29uZmlkZW5jaWFsIHkgZXMgcGFy YSB1c28gZXhjbHVzaXZvIGRlIGxhIHBlcnNvbmEgbyBlbnRpZGFkIGRlIGRlc3Rpbm8uIFNpIG5v IGVzIHVzdGVkLiBlbCBkZXN0aW5hdGFyaW8gaW5kaWNhZG8sIHF1ZWRhIG5vdGlmaWNhZG8gZGUg cXVlIGxhIGxlY3R1cmEsIHV0aWxpemFjacOzbiwgZGl2dWxnYWNpw7NuIHkvbyBjb3BpYSBzaW4g YXV0b3JpemFjacOzbiBwdWVkZSBlc3RhciBwcm9oaWJpZGEgZW4gdmlydHVkIGRlIGxhIGxlZ2lz bGFjacOzbiB2aWdlbnRlLiBTaSBoYSByZWNpYmlkbyBlc3RlIG1lbnNhamUgcG9yIGVycm9yLCBs ZSByb2dhbW9zIHF1ZSBub3MgbG8gY29tdW5pcXVlIGlubWVkaWF0YW1lbnRlIHBvciBlc3RhIG1p c21hIHbDrWEgeSBwcm9jZWRhIGEgc3UgZGVzdHJ1Y2Npw7NuLg0KDQpUaGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGluIHRoaXMgdHJhbnNtaXNzaW9uIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVu dGlhbCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBvbmx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlk dWFsIG9yIGVudGl0eSBuYW1lZCBhYm92ZS4gSWYgdGhlIHJlYWRlciBvZiB0aGlzIG1lc3NhZ2Ug aXMgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRo YXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMgY29t bXVuaWNhdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgZG8gbm90IHJlYWQgaXQuIFBsZWFzZSBpbW1lZGlh dGVseSByZXBseSB0byB0aGUgc2VuZGVyIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21t dW5pY2F0aW9uIGluIGVycm9yIGFuZCB0aGVuIGRlbGV0ZSBpdC4NCg0KRXN0YSBtZW5zYWdlbSBl IHNldXMgYW5leG9zIHNlIGRpcmlnZW0gZXhjbHVzaXZhbWVudGUgYW8gc2V1IGRlc3RpbmF0w6Fy aW8sIHBvZGUgY29udGVyIGluZm9ybWHDp8OjbyBwcml2aWxlZ2lhZGEgb3UgY29uZmlkZW5jaWFs IGUgw6kgcGFyYSB1c28gZXhjbHVzaXZvIGRhIHBlc3NvYSBvdSBlbnRpZGFkZSBkZSBkZXN0aW5v LiBTZSBuw6NvIMOpIHZvc3NhIHNlbmhvcmlhIG8gZGVzdGluYXTDoXJpbyBpbmRpY2FkbywgZmlj YSBub3RpZmljYWRvIGRlIHF1ZSBhIGxlaXR1cmEsIHV0aWxpemHDp8OjbywgZGl2dWxnYcOnw6Nv IGUvb3UgY8OzcGlhIHNlbSBhdXRvcml6YcOnw6NvIHBvZGUgZXN0YXIgcHJvaWJpZGEgZW0gdmly dHVkZSBkYSBsZWdpc2xhw6fDo28gdmlnZW50ZS4gU2UgcmVjZWJldSBlc3RhIG1lbnNhZ2VtIHBv ciBlcnJvLCByb2dhbW9zLWxoZSBxdWUgbm9zIG8gY29tdW5pcXVlIGltZWRpYXRhbWVudGUgcG9y IGVzdGEgbWVzbWEgdmlhIGUgcHJvY2VkYSBhIHN1YSBkZXN0cnVpw6fDo28NCg== --_000_B0D29E0424F2DE47A0B36779EC6667796616D823nkgeml501mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAg MyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsN CglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEg MTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg ZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLCBEaWVnbyBhbmQgTWVobWV0LDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHByZWZlciB0aGUgZmlyc3Qgb25lIGFz IHdlbGwuDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj5KPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+LU5pbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiBESUVHTyBMT1BFWiBH QVJDSUEgW21haWx0bzpkaWVnby5yLmxvcGV6QHRlbGVmb25pY2EuY29tXQ0KPGJyPg0KPC9zcGFu PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lj5HpgIHml7bpl7Q8c3BhbiBsYW5n PSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+IDIwMTQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi PuW5tDxzcGFuIGxhbmc9IkVOLVVTIj43PC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj42PC9z cGFuPuaXpTxzcGFuIGxhbmc9IkVOLVVTIj4gNzozODxicj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8 c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBleHQgTWVs aW5kYSBTaG9yZTsgRXJzdWUsIE1laG1ldCAoTlNOIC0gREUvTXVuaWNoKTxicj4NCjwvc3Bhbj48 Yj7mioTpgIE8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi PiBhZHJpYW5Ab2xkZG9nLmNvLnVrOyBEb24gQ2xhcmtlOyBab25nbmluZzsgdm5mcG9vbEBpZXRm Lm9yZzsgV1JJR0hULCBTVEVWRU4gQTsgbmFzZWVtLmEua2hhbkB2ZXJpem9uLmNvbTsgdGV0c3V5 YS5uYWthbXVyYS5jdUBudHRkb2NvbW8uY29tOyBESUVHTyBMT1BFWiBHQVJDSUE7IFJhcXVlbCBN b3JlcmE8YnI+DQo8L3NwYW4+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIj4gUmU6IFt2bmZwb29sXSBOZXcgQ2hhcnRlciBmb3IgVG9yb250 bzxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSwgPG86cD48L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiA1IEp1bCAy MDE0LCBhdCAyMTozNCAsIEVyc3VlLCBNZWhtZXQgKE5TTiAtIERFL011bmljaCkgJmx0OzxhIGhy ZWY9Im1haWx0bzptZWhtZXQuZXJzdWVAbnNuLmNvbSI+bWVobWV0LmVyc3VlQG5zbi5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGFncmVlIGFi b3V0IGJlaW5nIHNwZWNpZmljIGFib3V0IHdoaWNoIEVUU0kgYm9keSB3aWxsIGJlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+ZW5nYWdlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KWW91IGNh biBleHByZXNzIHdoYXQgaXMgYWxyZWFkeSBoYXBwZW5pbmcgaW4gbWFueSB3YXlzLCBhbHNvIGUu Zy48YnI+DQomcXVvdDsuLndpbGwgZXhjaGFuZ2UgaW5mb3JtYXRpb24gd2l0aCByZWxldmFudCBX R3MgaW4gRVRTSSBORlYsIGUuZy4gUkVMIFdHLi4mcXVvdDsgb3IgPGJyPg0KJnF1b3Q7Li53aWxs IGV4Y2hhbmdlIGluZm9ybWF0aW9uIHdpdGggRVRTSSBORlYgUkVMLCBNQU5PIGFuZCBJTkYgV0dz Li4mcXVvdDsuPGJyPg0KPGJyPg0KTGV0IG1lIGtub3cgd2hpY2ggb25lIHlvdSBwcmVmZXIuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SnVzdCBsZXQgbWUgbm90ZSB0 aGF0IEkgdGhpbmsgdGhlIGZpcnN0IG9uZSwgYXMgaXQgaXMgbW9yZSBvcGVuIHRvIGZ1dHVyZSBl dm9sdXRpb24gaW4gdGhlIEVUU0kgTkZWLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5UaGVyZSBpcyBvbmUgcG9pbnQgdGhvdWdoLCB3aGljaCBJIHdvdWxkIGxpa2UgdG8gdW5kZXJs aW5lLjxicj4NCkJlaW5nIGFjdGl2ZSBpbiB0d28gb3JnYW5pemF0aW9ucyBJIGtub3cgdGhhdCBj b21wYXJlZCB0byBzb21lIG90aGVyIFNET3MsIEVUU0kgTkZWIHBlb3BsZSBhcmUgbm90IHRyeWlu ZyB0byBkZWNsYXJlIGEgdGVjaG5vbG9neSBhcyB0aGVpciBvd25lcnNoaXAuIEl0IGlzIGp1c3Qg dGhlIGFpbSB0byBjb250cmlidXRlIGFuZCBjb29wZXJhdGUgaW4gdGhlIGludGVyZXN0IG9mIHJl bGlhYmxlIFZORiBwb29scy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5CZWluZyBpbiB0aGUgc2FtZSBwb3NpdGlvbiBhcyBNZWhtZXQgaXMsIGxldCBtZSBzdXBwb3J0 IGhpcyB2aWV3IG9uIHRoaXMgYXMgd2VsbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPkJlIGdvb2RlLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4t LTxicj4NClBMRUFTRSBOT1RFIE1ZIE5FVyBFTUFJTCBBRERSRVNTPGJyPg0KJnF1b3Q7RXN0YSB2 ZXogbm8gZmFsbGFyZW1vcywgRG9jdG9yIEluZmllcm5vJnF1b3Q7PGJyPg0KPGJyPg0KRHIgRGll Z28gUi4gTG9wZXo8YnI+DQpUZWxlZm9uaWNhIEkmIzQzO0Q8YnI+DQo8YSBocmVmPSJodHRwOi8v cGVvcGxlLnRpZC5lcy9kaWVnby5sb3Blei8iPmh0dHA6Ly9wZW9wbGUudGlkLmVzL2RpZWdvLmxv cGV6LzwvYT48YnI+DQo8YnI+DQplLW1haWw6IDxhIGhyZWY9Im1haWx0bzpkaWVnby5yLmxvcGV6 QHRlbGVmb25pY2EuY29tIj5kaWVnby5yLmxvcGV6QHRlbGVmb25pY2EuY29tPC9hPjxicj4NClRl bDogJm5ic3A7ICZuYnNwOyYjNDM7MzQgOTEzIDEyOSAwNDE8YnI+DQpNb2JpbGU6ICYjNDM7MzQg NjgyIDA1MSAwOTE8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0 ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4gbGFuZz0iRU4tVVMiPg0KPGhyIHNpemU9IjIiIHdpZHRo PSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Z3JheSI+PGJy Pg0KRXN0ZSBtZW5zYWplIHkgc3VzIGFkanVudG9zIHNlIGRpcmlnZW4gZXhjbHVzaXZhbWVudGUg YSBzdSBkZXN0aW5hdGFyaW8sIHB1ZWRlIGNvbnRlbmVyIGluZm9ybWFjacOzbiBwcml2aWxlZ2lh ZGEgbyBjb25maWRlbmNpYWwgeSBlcyBwYXJhIHVzbyBleGNsdXNpdm8gZGUgbGEgcGVyc29uYSBv IGVudGlkYWQgZGUgZGVzdGluby4gU2kgbm8gZXMgdXN0ZWQuIGVsIGRlc3RpbmF0YXJpbyBpbmRp Y2FkbywgcXVlZGEgbm90aWZpY2FkbyBkZSBxdWUgbGENCiBsZWN0dXJhLCB1dGlsaXphY2nDs24s IGRpdnVsZ2FjacOzbiB5L28gY29waWEgc2luIGF1dG9yaXphY2nDs24gcHVlZGUgZXN0YXIgcHJv aGliaWRhIGVuIHZpcnR1ZCBkZSBsYSBsZWdpc2xhY2nDs24gdmlnZW50ZS4gU2kgaGEgcmVjaWJp ZG8gZXN0ZSBtZW5zYWplIHBvciBlcnJvciwgbGUgcm9nYW1vcyBxdWUgbm9zIGxvIGNvbXVuaXF1 ZSBpbm1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtaXNtYSB2w61hIHkgcHJvY2VkYSBhIHN1IGRlc3Ry dWNjacOzbi48YnI+DQo8YnI+DQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgdHJh bnNtaXNzaW9uIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBpbnRl bmRlZCBvbmx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSBuYW1lZCBh Ym92ZS4gSWYgdGhlIHJlYWRlciBvZiB0aGlzIG1lc3NhZ2UgaXMgbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24s DQogZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcgb2YgdGhpcyBjb21tdW5pY2F0aW9uIGlzIHN0cmlj dGx5IHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGlu IGVycm9yLCBkbyBub3QgcmVhZCBpdC4gUGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBz ZW5kZXIgdGhhdCB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3Ig YW5kIHRoZW4gZGVsZXRlIGl0Ljxicj4NCjxicj4NCkVzdGEgbWVuc2FnZW0gZSBzZXVzIGFuZXhv cyBzZSBkaXJpZ2VtIGV4Y2x1c2l2YW1lbnRlIGFvIHNldSBkZXN0aW5hdMOhcmlvLCBwb2RlIGNv bnRlciBpbmZvcm1hw6fDo28gcHJpdmlsZWdpYWRhIG91IGNvbmZpZGVuY2lhbCBlIMOpIHBhcmEg dXNvIGV4Y2x1c2l2byBkYSBwZXNzb2Egb3UgZW50aWRhZGUgZGUgZGVzdGluby4gU2UgbsOjbyDD qSB2b3NzYSBzZW5ob3JpYSBvIGRlc3RpbmF0w6FyaW8gaW5kaWNhZG8sIGZpY2Egbm90aWZpY2Fk byBkZSBxdWUgYQ0KIGxlaXR1cmEsIHV0aWxpemHDp8OjbywgZGl2dWxnYcOnw6NvIGUvb3UgY8Oz cGlhIHNlbSBhdXRvcml6YcOnw6NvIHBvZGUgZXN0YXIgcHJvaWJpZGEgZW0gdmlydHVkZSBkYSBs ZWdpc2xhw6fDo28gdmlnZW50ZS4gU2UgcmVjZWJldSBlc3RhIG1lbnNhZ2VtIHBvciBlcnJvLCBy b2dhbW9zLWxoZSBxdWUgbm9zIG8gY29tdW5pcXVlIGltZWRpYXRhbWVudGUgcG9yIGVzdGEgbWVz bWEgdmlhIGUgcHJvY2VkYSBhIHN1YSBkZXN0cnVpw6fDo288L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B0D29E0424F2DE47A0B36779EC6667796616D823nkgeml501mbschi_-- From nobody Thu Jul 10 18:12:14 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6FD1B2816 for ; Thu, 10 Jul 2014 18:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.851 X-Spam-Level: X-Spam-Status: No, score=-104.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AuFCxSTOji8 for ; Thu, 10 Jul 2014 18:12:10 -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 4E4381B283D for ; Thu, 10 Jul 2014 18:12:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGZ76812; Fri, 11 Jul 2014 01:12:03 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 11 Jul 2014 02:12:02 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Fri, 11 Jul 2014 09:11:56 +0800 From: Zongning To: "vnfpool@ietf.org" Thread-Topic: More updates on BoF agenda? Thread-Index: Ac+cpRsDHvg7RChcRAC7VHs1JoXVWw== Date: Fri, 11 Jul 2014 01:11:55 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.54] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC6667796616F05Fnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/WGEp-H6jrjzj8-DKPFlECY-luF4 Subject: [vnfpool] More updates on BoF agenda? X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 01:12:12 -0000 --_000_B0D29E0424F2DE47A0B36779EC6667796616F05Fnkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all, We are going to fix our BoF agenda by next Monday. So please let us know if= you have any more updates. Especially, I'd welcome additional topics on Re= quirements, or Architecture, as both are intended milestones. Thanks, -Ning --_000_B0D29E0424F2DE47A0B36779EC6667796616F05Fnkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, all,

 

We are going to fix our BoF age= nda by next Monday. So please let us know if you have any more updates. Esp= ecially, I’d welcome additional topics on Requirements, or Architectu= re, as both are intended milestones.

 

Thanks,

 

-Ning

--_000_B0D29E0424F2DE47A0B36779EC6667796616F05Fnkgeml501mbschi_-- From nobody Sun Jul 13 23:47:12 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F61A1A031B for ; Sun, 13 Jul 2014 23:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.851 X-Spam-Level: X-Spam-Status: No, score=-104.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qfy6LTihIFc0 for ; Sun, 13 Jul 2014 23:47:08 -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 715061A0319 for ; Sun, 13 Jul 2014 23:47:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHD85806; Mon, 14 Jul 2014 06:47:07 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 14 Jul 2014 07:47:06 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Mon, 14 Jul 2014 14:47:02 +0800 From: Zongning To: "vnfpool@ietf.org" Thread-Topic: Final VNFPool BoF Agenda Thread-Index: Ac+fL2rOfeffARBfQEStxZWlBKR08A== Date: Mon, 14 Jul 2014 06:47:02 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.54] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC6667796616FA41nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/TKyUJocTaUwtvG9DXhRJEYenx_c Subject: [vnfpool] Final VNFPool BoF Agenda X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 06:47:10 -0000 --_000_B0D29E0424F2DE47A0B36779EC6667796616FA41nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all, The final VNFPool BoF agenda is available at http://www.ietf.org/proceeding= s/90/agenda/agenda-90-vnfpool. Please the presenters send your slides to Melinda and me, ideally by this F= riday. Thanks. -Melinda & Ning --_000_B0D29E0424F2DE47A0B36779EC6667796616FA41nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, all,

 

The final VNFPool BoF agenda is= available at htt= p://www.ietf.org/proceedings/90/agenda/agenda-90-vnfpool.

Please the presenters send your= slides to Melinda and me, ideally by this Friday.

 

Thanks.

 

-Melinda & Ning

--_000_B0D29E0424F2DE47A0B36779EC6667796616FA41nkgeml501mbschi_-- From nobody Wed Jul 16 19:08:53 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250E91A03F4 for ; Wed, 16 Jul 2014 19:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.901 X-Spam-Level: X-Spam-Status: No, score=-98.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4eXacQa2dmGA for ; Wed, 16 Jul 2014 19:08:48 -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 E8CB81A03CA for ; Wed, 16 Jul 2014 19:08:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHG73407; Thu, 17 Jul 2014 02:08:46 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 17 Jul 2014 03:08:45 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Thu, 17 Jul 2014 10:08:41 +0800 From: Zongning To: "vnfpool@ietf.org" Thread-Topic: Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto Thread-Index: Ac+glo0SWV5Tpf8ORV2qBe787uS76gAzVD6w Date: Thu, 17 Jul 2014 02:08:40 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.54] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC66677966171B6Enkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/r2fJ_SY1i7rEetZrm0L82qd3ftM Subject: [vnfpool] =?gb2312?b?16q3ojogUHJvcG9zZWQgSVJURiBOZXR3b3JrIEZ1bmN0?= =?gb2312?b?aW9ucyBWaXJ0dWFsaXphdGlvbiBSZXNlYXJjaCBHcm91cCAoTkZWUkcpIC0g?= =?gb2312?b?Zmlyc3QgZmFjZS10by1mYWNlIG1lZXRpbmcgYXQgVG9yb250bw==?= X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 02:08:51 -0000 --_000_B0D29E0424F2DE47A0B36779EC66677966171B6Enkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RllJLg0KDQoNCreivP7Iyzogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddILT6se0g cmFta2kgS3Jpc2huYW4NCreiy83KsbzkOiAyMDE0xOo31MIxNsjVIDk6NDINCsrVvP7IyzogbmZ2 cmdAaWVmdC5vcmc7IHNkbkBpcnRmLm9yZzsgbm1yZ0BpcnRmLm9yZzsgJ3NmY0BpZXRmLm9yZyc7 IG52bzNAaWV0Zi5vcmc7IGkycnNAaWV0Zi5vcmc7IGZvcmNlc0BpZXRmLm9yZzsgcGNlQGlldGYu b3JnOyBibXdnQGlldGYub3JnDQqzrcvNOiBESUVHTyBMT1BFWiBHQVJDSUEgKGRpZWdvLnIubG9w ZXpAdGVsZWZvbmljYS5jb20pOyBkaWxpa3Jpc0Bpbi5pYm0uY29tDQrW98ziOiBbc2ZjXSBQcm9w b3NlZCBJUlRGIE5ldHdvcmsgRnVuY3Rpb25zIFZpcnR1YWxpemF0aW9uIFJlc2VhcmNoIEdyb3Vw IChORlZSRykgLSBmaXJzdCBmYWNlLXRvLWZhY2UgbWVldGluZyBhdCBUb3JvbnRvDQoNClBsZWFz ZSBmaW5kIG1vcmUgaW5mb3JtYXRpb24gb24gTkZWUkcgaW5jbHVkaW5nIGNoYXJ0ZXIgYXQgLSBo dHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9ncm91cC9pcnRmL3RyYWMvd2lraS9uZnZyZw0KDQpQ bGVhc2UgZmluZCBtZWV0aW5nIGxvY2F0aW9uIGFuZCBhZ2VuZGEgYXQgLSBodHRwOi8vdHJhYy50 b29scy5pZXRmLm9yZy9ncm91cC9pcnRmL3RyYWMvd2lraS9uZnZyZy1pZXRmLTkwDQoNClRoYW5r cywNClJhbWtpIG9uIGJlaGFsZiBvZiB0aGUgY28tY2hhaXJzDQo= --_000_B0D29E0424F2DE47A0B36779EC66677966171B6Enkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

FYI.

 

 

=B7=A2=BC=FE=C8=CB: sfc [mailto:sfc-bounc= es@ietf.org] =B4=FA=B1=ED = ramki Krishnan
=B7=A2=CB=CD= =CA=B1=BC=E4: 2014=C4=EA7=D4=C2<= span lang=3D"EN-US">16=C8=D5 9:42
=CA=D5=BC=FE=C8=CB: nfvrg@ieft.org; sdn@irtf.org; nmrg@irtf.org; 'sfc@ietf.org'; nvo3@i= etf.org; i2rs@ietf.org; forces@ietf.org; pce@ietf.org; bmwg@ietf.org
=B3=AD=CB=CD: DIEGO LOPEZ GARCIA (diego.r.lopez@telefonica.com); dilikris@in.ibm.com =D6=F7=CC=E2: [sfc] Proposed IRTF Network Functions Virtualization Research Group (NFVR= G) - first face-to-face meeting at Toronto

 

Please find more information on= NFVRG including charter at - http://tr= ac.tools.ietf.org/group/irtf/trac/wiki/nfvrg

 

Please find meeting location an= d agenda at - h= ttp://trac.tools.ietf.org/group/irtf/trac/wiki/nfvrg-ietf-90=

 

Thanks,

Ramki on behalf of the co-chair= s

--_000_B0D29E0424F2DE47A0B36779EC66677966171B6Enkgeml501mbschi_-- From nobody Thu Jul 17 17:05:50 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 516361B2870 for ; Thu, 17 Jul 2014 17:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.902 X-Spam-Level: X-Spam-Status: No, score=-103.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFN50SOSigoK for ; Thu, 17 Jul 2014 17:05:46 -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 763041B2852 for ; Thu, 17 Jul 2014 17:05:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHH66466; Fri, 18 Jul 2014 00:05:44 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 18 Jul 2014 01:05:42 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Fri, 18 Jul 2014 08:05:38 +0800 From: Zongning To: "vnfpool@ietf.org" Thread-Topic: IETF 90 - Remote Participation Thread-Index: AQHPofHOSqDCJnyWO02tN/HNqnFZkZuk8ysg Date: Fri, 18 Jul 2014 00:05:38 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.54] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/LQBmdmhRXic6QD5wBOGAjF6Z5NQ Subject: [vnfpool] =?utf-8?b?6L2s5Y+ROiBJRVRGIDkwIC0gUmVtb3RlIFBhcnRpY2lw?= =?utf-8?q?ation?= X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 00:05:48 -0000 SGksDQoNCkZvciB0aG9zZSB3aG8gYXJlIG5vdCBhYmxlIHRvIGF0dGVuZCBWTkZQb29sIEJvRiBp biBUb3JvbnRvIElFVEYsIHBsZWFzZSBzZWUgYmVsb3cgaW5mb3JtYXRpb24gZm9yIHJlbW90ZSBw YXJ0aWNpcGF0aW9uLiBJTU8sIGEgcG9wdWxhciB3YXkgaXMgdG8gdXNlIEphYmJlciByb29tLg0K DQpUaGFua3MuDQoNCi1OaW5nDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujog V0dDaGFpcnMgW21haWx0bzp3Z2NoYWlycy1ib3VuY2VzQGlldGYub3JnXSDku6PooaggSUVURiBT ZWNyZXRhcmlhdA0K5Y+R6YCB5pe26Ze0OiAyMDE05bm0N+aciDE45pelIDM6MDANCuaUtuS7tuS6 ujogd2djaGFpcnNAaWV0Zi5vcmcNCuS4u+mimDogSUVURiA5MCAtIFJlbW90ZSBQYXJ0aWNpcGF0 aW9uDQoNCkNhbuKAmXQgbWFrZSBpdCB0byBUb3JvbnRvPyBQYXJ0aWNpcGF0ZSByZW1vdGVseSEg VGhlIElFVEYgb2ZmZXJzIGEgbnVtYmVyIG9mIHdheXMgZm9yIHJlbW90ZSBhdHRlbmRlZXMgdG8g YXVkaXQgb3IgZXZlbiBjb250cmlidXRlIHRvIElFVEYgc2Vzc2lvbnMgdGhyb3VnaG91dCB0aGUg bWVldGluZyB3ZWVrLg0KDQpGaXJzdCwgcmVnaXN0ZXIgZm9yIHRoZSBtZWV0aW5nLiBUaGVyZSBp cyBubyBjb3N0IHRvIHJlZ2lzdGVyIGFzIGEgcmVtb3RlIGF0dGVuZGVlIGFuZCBieSByZWdpc3Rl cmluZyB5b3Ugd2lsbCBpbnN1cmUgdGhhdCB5b3UgcmVjZWl2ZSBpbXBvcnRhbnQgdXBkYXRlcyBv biBhZ2VuZGEgY2hhbmdlcyBhbmQgb3RoZXIgdGhpbmdzIG9mIGludGVyZXN0IHRvIG1lZXRpbmcg YXR0ZW5kZWVzLiBQbGVhc2UgcmVnaXN0ZXIgaGVyZTogaHR0cDovL3d3dy5pZXRmLm9yZy9tZWV0 aW5nL3JlZ2lzdGVyLmh0bWwgYW5kIHNlbGVjdCDigJxyZW1vdGUgcGFydGljaXBhbnTigJ0gYXMg eW91ciByZWdpc3RyYXRpb24gdHlwZS4gDQoNCkdlbmVyYWwgcmVtb3RlIHBhcnRpY2lwYXRpb24g aW5mb3JtYXRpb24gY2FuIGJlIGZvdW5kIGhlcmU6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWVldGlu Zy85MC9yZW1vdGUtcGFydGljaXBhdGlvbi5odG1sLiBCZWxvdyBpcyBhIGJyZWFrZG93biBvZiBz b21lIG9mIHRoZSBtYWluIHNlcnZpY2VzIGF2YWlsYWJsZS4gDQoNCjEpIE1lZXRlY2hvIA0KVGhl IE1lZXRlY2hvIHBsYXRmb3JtIHByb3ZpZGVzIGEgc3luY2hyb25pemVkIHZpZXcgb2YgdGhlIGF1 ZGlvL3ZpZGVvIHN0cmVhbSBmcm9tIHRoZSBtZWV0aW5nIHJvb20sIHdoaWNoIGluY2x1ZGVzIHNs aWRlcyBiZWluZyBwcmVzZW50ZWQgYW5kIHRoZSBwcmVzZW50ZXIsIGFzIHdlbGwgYXMgb2ZmaWNp YWwgSUVURiBKYWJiZXIgcm9vbS4gTWVldGVjaG8gd2lsbCBiZSBzdXBwb3J0aW5nIHNpeCBvZiB0 aGUgZWlnaHQgY29uY3VycmVudCB3b3JraW5nIHNlc3Npb24gdHJhY2tzLCBhbG9uZyB3aXRoIGJv dGggdGhlIEFkbWluaXN0cmF0aXZlIGFuZCBUZWNobmljYWwgcGxlbmFyaWVzLiBJZiB5b3UgaGF2 ZSBhIGNvbW1lbnQgb3IgYSBxdWVzdGlvbiwgTWVldGVjaG8gZW5hYmxlcyB5b3UgdG8gYXNrIGl0 IGV2ZW4gaWYgeW91IGFyZSBub3QgaW4gdGhlIHJvb20uIEluIGFkZGl0aW9uLCBNZWV0ZWNobyB3 aWxsIGJlIHN0cmVhbWluZyBtYW55IG9mIHRoZSBTdW5kYXkgdHV0b3JpYWxzIHNlc3Npb25zLiBG b3IgbW9yZSBpbmZvcm1hdGlvbiBvbiBob3cgdG8gam9pbiBhIE1lZXRlY2hvIHNlc3Npb24sIG9y IHRvIHdhdGNoIGEgcmVjb3JkaW5nIGFmdGVyIHRoZSBzZXNzaW9uIGhhcyBjb25jbHVkZWQsIHNl ZSBoZXJlOmh0dHA6Ly9pZXRmOTAuY29uZi5tZWV0ZWNoby5jb20vLg0KDQoyKSBBdWRpbyBTdHJl YW0NCklmIHlvdSBvbmx5IHdhbnQgdG8gbGlzdGVuIHRvIHRoZSBzZXNzaW9ucyAob3IgaWYgdGhl IHNlc3Npb24geW91IGFyZSBpbnRlcmVzdGVkIGluIGlzbuKAmXQgc3VwcG9ydGVkIGJ5IE1lZXRl Y2hvKSwgdGhlIGF1ZGlvIHN0cmVhbSBpcyBhIGdvb2QgY2hvaWNlLiBBbGwgd29ya2luZyBzZXNz aW9ucyBhcmUgc3RyZWFtZWQ7IHNlZSBoZXJlIGZvciBtb3JlIGNoYW5uZWwtdG8tcm9vbSBhc3Np Z25tZW50czogaHR0cDovL3d3dy5pZXRmLm9yZy9tZWV0aW5nLzkwL3JlbW90ZS1wYXJ0aWNpcGF0 aW9uLmh0bWwjYXVkaW8uDQoNCjMpIEphYmJlciBSb29tcw0KQWxsIElFVEYgbWVldGluZyBzZXNz aW9ucyBoYXZlIGEgY29ycmVzcG9uZGluZyBKYWJiZXIgcm9vbS4gU2VlIGhlcmUgZm9yIGxpbmsg dG8gdGhlIG1lZXRpbmcgYWdlbmRhIHdpdGggY29ycmVzcG9uZGluZyBKYWJiZXIgcm9vbXM6IGh0 dHA6Ly90b29scy5pZXRmLm9yZy9hZ2VuZGEvOTAvLiBXaGVuZXZlciBwb3NzaWJsZSwgYW4gaW4t cm9vbSB2b2x1bnRlZXIgbW9uaXRvcnMgdGhlIEphYmJlciByb29tOyB0aGlzIHZvbHVudGVlciB3 aWxsIHN0YW5kIGF0IHRoZSBtaWNyb3Bob25lIGZvciByZW1vdGUgYXR0ZW5kZWVzIGFuZCByZWxh eSB0aGVpciBxdWVzdGlvbnMgaW50byB0aGUgbWVldGluZyByb29tIG1pY3JvcGhvbmUgc28gdGhh dCBwZW9wbGUgaW4gdGhlIHJvb20gY2FuIHJlc3BvbmQuIE1vcmUgaW5mb3JtYXRpb24gb24gdGhl IElFVEYgSmFiYmVyIHNlcnZpY2UgaXMgYXZhaWxhYmxlIGhlcmU6IGh0dHA6Ly93d3cuaWV0Zi5v cmcvamFiYmVyLy4NCg0KNCkgTWFpbGluZyBMaXN0cw0KVGhlIDkwYXR0ZW5kZWVzQGlldGYub3Jn IGlzIGZvciBnZW5lcmFsIGRpc2N1c3Npb24gb2YgdGhpbmdzIGhhcHBlbmluZyBhdCB0aGUgbWVl dGluZzsgam9pbiB0aGUgbGlzdCBpZiB5b3Ugd2FudCB0byBoZWFyIGFib3V0IFRvcm9udG8gcmVz dGF1cmFudHMsIG1lZXRpbmcgcm9vbSB0ZW1wZXJhdHVyZXMgYW5kIG90aGVyIHRvcGljcyBvZiBp bnRlcmVzdCB0byB0aG9zZSB3aG8gYXJlIHBoeXNpY2FsbHkgcHJlc2VudCBhdCB0aGUgbWVldGlu Zy4gU3Vic2NyaWJlIHRvIDkwYXR0ZW5kZWVzIGhlcmU6IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vOTBhdHRlbmRlZXMuIA0KDQpUaGUgOTBhbGxAaWV0Zi5vcmcgbGlzdCBp cyBmb3IgaW1wb3J0YW50IGFubm91bmNlbWVudHMgb25seSBhbmQgaXMgbm90IGEgZGlzY3Vzc2lv biBsaXN0LiBZb3UgYXV0b21hdGljYWxseSBzdWJzY3JpYmVkIHdoZW4geW91IHJlZ2lzdGVyIGFz IGEgcmVtb3RlIHBhcnRpY2lwYW50LiBCZWluZyBvbiA5MGFsbCBpcyBlc3NlbnRpYWwgaWYgeW91 IHdhbnQgdG8gaGVhciBhYm91dCBjaGFuZ2VzIHRvIG1lZXRpbmcgYWdlbmRhIG9yIG90aGVyIGlt cG9ydGFudCBhbm5vdW5jZW1lbnRzLiBTdWJzY3JpYmUgdG8gOTBhbGwgaGVyZTogaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby85MGFsbC4NCg0KNSkgTGl2ZSBWaWRlbyBhbmQg VGV4dCBTdHJlYW1pbmcgb2YgdGhlIFRlY2huaWNhbCBQbGVuYXJ5IG9uIE1vbmRheSwgSnVseSAy MXN0LiBUaGUgdGVjaG5pY2FsIHRvcGljIGlzIG5ldHdvcmsgdG9wb2xvZ3kgYW5kIGdlb2dyYXBo eS4gU2VlIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbGl2ZS8gZm9yIG1vcmUgaW5mb3JtYXRpb24uDQoN CkFmdGVyIHRoZSBtZWV0aW5nIHdlIHdpbGwgYmUgc2VuZGluZyBhIHN1cnZleSB0byBhbGwgcmVt b3RlIHBhcnRpY2lwYW50cyB0byBnZXQgZmVlZGJhY2sgb24gdGhlaXIgZXhwZXJpZW5jZTsgaWYg eW91IHBhcnRpY2lwYXRlIHJlbW90ZWx5LCB3ZeKAmWQgbG92ZSB0byBoZWFyIGZyb20geW91ISBB bmQgZG9u4oCZdCBmb3JnZXQgdG8gZm9sbG93IEBpZXRmIG9uIFR3aXR0ZXIhDQoNCk9ubHkgMyBk YXlzIHVudGlsIHRoZSBUb3JvbnRvIElFVEYhDQoNCg== From nobody Fri Jul 18 10:00:30 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8057F1B27A6 for ; Fri, 18 Jul 2014 10:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkQ4sgBosIpZ for ; Fri, 18 Jul 2014 10:00:15 -0700 (PDT) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C18861B280F for ; Fri, 18 Jul 2014 10:00:12 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id hy4so7663004vcb.22 for ; Fri, 18 Jul 2014 10:00:10 -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:from:date:message-id:subject:to :content-type; bh=GAUm7u5KXtbVG2kOGPrFLmfCQiLto7Go2sRohYl1PgA=; b=S4ja5nAc6Wlw95AxUgUAlL2eRMmo9fkAdtUgLXKA9pj3Op0Yw7jOx/EsUf5iih2R93 QwE2aPwOjmxLDUuaEMz3LxYEYMUDHr6aoO29fDWzqeu7OeZ1zbbVEF+LgSmW1ol2tKQ5 4yb/Zn7I8A4UjEO9v8Mq7b4WR+enTT9Jw/9HIokfCfXlXogQcvVKoPaKyt9z+hXC71tk gI/vxEGySvQElYAs7Yt/Lvi460whl+StmgVkUaL1NB3+qO47uCqPeC3YY1Y0HlPmLozo ufjTiCcJPLrddZCt/z7Ut7g3mrT5l2HmgIuKyjIJQg+EE2P+VfeYDBti23GtVBKgZIGQ x4Cw== X-Gm-Message-State: ALoCoQncRzlHXzpFf0DnvAdZEApm7Xi/LZkA+sx2wefZv5dR/8VV9hMhD8xyARlEoAhxb2uaBbll X-Received: by 10.221.56.5 with SMTP id wa5mr4225748vcb.25.1405702810658; Fri, 18 Jul 2014 10:00:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.235.65 with HTTP; Fri, 18 Jul 2014 09:59:50 -0700 (PDT) From: Jamal Hadi Salim Date: Fri, 18 Jul 2014 12:59:50 -0400 Message-ID: To: "forces@ietf.org" , "sdn@irtf.org" , nfvrg@irtf.org, vnfpool@ietf.org, nvo3@ietf.org, "i2rs@ietf.org" , sfc Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/6rAu2Zh1_U06RBnu-e53LHC1JoE Subject: [vnfpool] BitsnBites ForCES PoC X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 17:00:16 -0000 Folks, I am sorry for spamming all these lists. You are being spammed because you are a cousin of ForCES. We are planning to have a ForCES based NFV/SDN PoC demonstration at the Bits and Bites event on Thursday night (1845-2100 at the Concert Hall). Given it is very hard to give a lot of details in the demo, Evangelos Haleplidis will present more details at the ForCES meeting Monday 15:20 at the Manitoba room. The official blurb is as follows: ------ SANA will demonstrate the proof-of-concept of the applicability of IETF's ForCES framework for both NFV management and SDN control. The ForCES data model will be utilized to describe VNFs, services and the infrastructure definition in a clear, formal and concise approach. The protocol will illustrate SDN control and NFV management of all modelled elements. The setup includes various NFV/SDN entities controlled and managed by the ForCES architecture execute under a singular simple programmatic API regardless of whether they are virtual or physical. The separation of hardware and software is illustrated by the same NF LFB data models implemented in: a)KVM virtual machines, b) Linux containers, c) linux kernel proper and d) ASIC based L2/3 (Broadcom chipset) in white box switches all working in unison. Infrastructure orchestration includes instantiating VMs, containers, applications and setup of basic network connectivity using appropriate ForCES LFBs. Service orchestration is again modelled by ForCES LFBs and both control and management activities for the services are driven by the ForCES protocol. We will illustrate 3GPP S/PGW simple connectivity (NAT-based) service and the advantages gained from (SDN) separating the datapath components of S/PGW from the control as well as (NFV) separation of hardware from software. This PoC is further illustrated in: http://nfvwiki.etsi.org/index.php?title=ForCES_Applicability_for_NFV_and_integrated_SDN -------- Apologies again for the mass email. cheers, jamal From nobody Fri Jul 18 18:18:51 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17481A00EC; Fri, 18 Jul 2014 11:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJ3nMPABJmSY; Fri, 18 Jul 2014 11:21:09 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 806F61A0091; Fri, 18 Jul 2014 11:21:09 -0700 (PDT) Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB563.namprd05.prod.outlook.com (10.141.202.144) with Microsoft SMTP Server (TLS) id 15.0.990.7; Fri, 18 Jul 2014 18:21:07 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.0990.007; Fri, 18 Jul 2014 18:21:07 +0000 From: John E Drake To: Jamal Hadi Salim Thread-Topic: [sfc] BitsnBites ForCES PoC Thread-Index: AQHPoqnB/0IwhlC/pky+GbkxV4TKYpumJMEQ Date: Fri, 18 Jul 2014 18:21:06 +0000 Message-ID: <5B1198B1-1EBF-40D6-BDE7-31A2AD498636@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.147.100.47] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02760F0D1C x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377454003)(189002)(199002)(51704005)(24454002)(92726001)(83322001)(106116001)(74502001)(80022001)(79102001)(36756003)(101416001)(77982001)(110136001)(106356001)(19580395003)(19580405001)(16799955002)(81342001)(99396002)(82746002)(46102001)(15202345003)(87936001)(81542001)(50986999)(64706001)(76176999)(95666004)(54356999)(85852003)(99286002)(86362001)(15188155005)(83716003)(21056001)(74662001)(92566001)(76482001)(33656002)(31966008)(2656002)(15975445006)(4396001)(20776003)(83072002)(85306003)(105586002)(66066001)(107046002)(104396001)(19623215001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB563; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/80uEw8Z94kAjJ1BrkQHxLy6REfw X-Mailman-Approved-At: Fri, 18 Jul 2014 18:18:48 -0700 Cc: "vnfpool@ietf.org" , "i2rs@ietf.org" , "sdn@irtf.org" , sfc , "nvo3@ietf.org" , "nfvrg@irtf.org" , "forces@ietf.org" Subject: Re: [vnfpool] [sfc] BitsnBites ForCES PoC X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 18:21:11 -0000 Shameless self-aggrandizement=20 Sent from my iPhone > On Jul 18, 2014, at 1:00 PM, "Jamal Hadi Salim" wrote= : >=20 > Folks, >=20 > I am sorry for spamming all these lists. You are being spammed because > you are a cousin of ForCES. >=20 > We are planning to have a ForCES based NFV/SDN PoC demonstration at the > Bits and Bites event on Thursday night (1845-2100 at the Concert Hall). > Given it is very hard to give a lot of details in the demo, Evangelos Hal= eplidis > will present more details at the ForCES meeting Monday 15:20 at the > Manitoba room. >=20 > The official blurb is as follows: > ------ > SANA will demonstrate the proof-of-concept of the applicability of > IETF's ForCES framework for both NFV management and SDN control. > The ForCES data model will be utilized to describe VNFs, services and the > infrastructure definition in a clear, formal and concise approach. > The protocol will illustrate SDN control and NFV management of all > modelled elements. >=20 > The setup includes various NFV/SDN entities controlled and managed by the > ForCES architecture execute under a singular simple programmatic API > regardless of whether they are virtual or physical. The > separation of hardware and software is illustrated by the same NF > LFB data models implemented in: > a)KVM virtual machines, b) Linux containers, c) linux kernel proper > and d) ASIC based L2/3 (Broadcom chipset) in white box switches > all working in unison. >=20 > Infrastructure orchestration includes instantiating VMs, containers, > applications and setup of basic network connectivity using appropriate > ForCES LFBs. > Service orchestration is again modelled by ForCES LFBs and > both control and management activities for the services are driven by > the ForCES protocol. >=20 > We will illustrate 3GPP S/PGW simple connectivity (NAT-based) service > and the advantages > gained from (SDN) separating the datapath components of S/PGW from the co= ntrol > as well as (NFV) separation of hardware from software. >=20 > This PoC is further illustrated in: > http://nfvwiki.etsi.org/index.php?title=3DForCES_Applicability_for_NFV_an= d_integrated_SDN > -------- >=20 > Apologies again for the mass email. >=20 > cheers, > jamal >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Jul 22 10:13:26 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6513A1B2A97 for ; Tue, 22 Jul 2014 10:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPAslYeheROL for ; Tue, 22 Jul 2014 10:13:24 -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 451111B2A99 for ; Tue, 22 Jul 2014 10:13:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHM45101; Tue, 22 Jul 2014 17:13:19 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 22 Jul 2014 18:13:17 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Wed, 23 Jul 2014 01:13:14 +0800 From: Zongning To: "vnfpool@ietf.org" Thread-Topic: Meeting slides uploaded Thread-Index: Ac+l0Dqlr1Pp/mNTSxiRAjotwSLnfw== Date: Tue, 22 Jul 2014 17:13:13 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.130.22] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC666779661742BDnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/wBmMZ7eCUivW0DUW0uhZDNlBeSg Subject: [vnfpool] Meeting slides uploaded X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 17:13:25 -0000 --_000_B0D29E0424F2DE47A0B36779EC666779661742BDnkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, folks, All meeting slides have been uploaded. Just open the link https://datatrack= er.ietf.org/meeting/90/materials.html and search for "vnfpool". See you in the BoF! Thanks. -Ning --_000_B0D29E0424F2DE47A0B36779EC666779661742BDnkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, folks,

 

All meeting slides have been up= loaded. Just open the link https://= datatracker.ietf.org/meeting/90/materials.html and search for “vn= fpool”.

 

See you in the BoF!<= /span>

 

Thanks.

 

-Ning

--_000_B0D29E0424F2DE47A0B36779EC666779661742BDnkgeml501mbschi_-- From nobody Tue Jul 22 13:14:26 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA6521B28B2 for ; Tue, 22 Jul 2014 13:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuVukkaaHK4M for ; Tue, 22 Jul 2014 13:14:23 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ECA01A035B for ; Tue, 22 Jul 2014 13:14:23 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id k48so168071wev.27 for ; Tue, 22 Jul 2014 13:14:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=zbAba67fuwNCZn47jBNN1PuG4wQrKwqp4U407pYfbn8=; b=tyyZVa8B6sw/S5eudJBek9ERqyib+o8+SgA90hfkldtSHjLpV6LWDfaHnNeTfgD4Bo w1qYRdl1u86fC4oH7Wah1NU6INaQFmsQo2UqVyXidCOR8lV7nL/ZEuLZxNifAsIC5pSl NZiNZlDtjPrqzSW1K/1HeGNkftpzeIjLL26HehTSHW8z2FtDwWcM3A4HWk6WxBT6HjMd fCACH6rA7p8Mb2vAfZ8abGgI0wXIsDooMM6In1M20BMrONwXkBQk3eUBb5Fq2XsvjbtN qPSEO9886UEhfj469GYhTDE5kvyOUXOBHapxk+AKVP8FrItSwkUzZs5FGmIqPUW9ENmi axXw== X-Received: by 10.180.74.11 with SMTP id p11mr17933684wiv.68.1406060061927; Tue, 22 Jul 2014 13:14:21 -0700 (PDT) Received: from dhcp-9b6b.meeting.ietf.org ([2001:67c:370:152:98c:d86c:ae9a:cca7]) by mx.google.com with ESMTPSA id d12sm299028wjx.0.2014.07.22.13.14.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Jul 2014 13:14:21 -0700 (PDT) Message-ID: <53CEC61A.9010104@gmail.com> Date: Tue, 22 Jul 2014 16:14:18 -0400 From: Martin Stiemerling User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: vnfpool@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/6I8x86hbbo7novgj_2LcOG5EHfY Subject: [vnfpool] Follow-up question from the BOF X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 20:14:24 -0000 Dear all, This is a follow-up question from your responsible AD about the first hum we did take in the BOF @ IETF-90. The questions asked was if the technical problem to be worked on is clear? A majority on the session did hum against that the technical problem to be solved is clear. However, from the discussion during the BOF session it is not clear to me that the technical problem isn't understood. So now the question: Why do people are not convinced that the technical problem is solveable? So, enlight me :) Thanks, Martin From nobody Tue Jul 22 14:34:55 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF311B2C77 for ; Tue, 22 Jul 2014 14:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIET9jmV88ui for ; Tue, 22 Jul 2014 14:34:43 -0700 (PDT) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28FE71B2C73 for ; Tue, 22 Jul 2014 14:34:42 -0700 (PDT) Received: by mail-vc0-f178.google.com with SMTP id la4so551248vcb.23 for ; Tue, 22 Jul 2014 14:34:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3A/dpz0dCUgcFjdibgmKNi0b2PSyuJ4TTmEDxdJ4EiE=; b=YhCBJ93riKgfGvJXTzk1HKTeppjhib8ZQIEUa3mtEk4rszGtgqafK5F2O/0mdip5Pe Ryrb7RJ2Ajg5ShBlp/UU1GGsPSANO7BsSaNmXr/sOMgwbQbV85CiPF/ysxSScEfqHcqq OLtU6ubdtxFeT9KC2MBMP+oRe7Vue/Smw9TS4XgNyIy5m5DtEKY/hTAkGdPDLCK1U0Jp eRI1Na9IgcIe4JFfi0MJQBUwp4hgB1t1ulPXelGyTyMfoQe+6ve7vFX15z7YOyFHZs2z bdN6P3FA4VEkR88XUNpmoY4ZhsdDQSRGDgx3MqDYqxcc9D4PE7Gv4arBrSrE3zXCAGxo pi7Q== MIME-Version: 1.0 X-Received: by 10.220.166.9 with SMTP id k9mr44809499vcy.20.1406064880705; Tue, 22 Jul 2014 14:34:40 -0700 (PDT) Sender: yang.r.yang@gmail.com Received: by 10.58.133.11 with HTTP; Tue, 22 Jul 2014 14:34:40 -0700 (PDT) In-Reply-To: <53CEC61A.9010104@gmail.com> References: <53CEC61A.9010104@gmail.com> Date: Tue, 22 Jul 2014 17:34:40 -0400 X-Google-Sender-Auth: rmvUw2DQN-QGazDI4xw8WTNojCo Message-ID: From: "Y. Richard Yang" To: Martin Stiemerling Content-Type: multipart/alternative; boundary=047d7b3a8ae6bee7f604fecefdd7 Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/MVnCmEfMaIRdx2f-gej-N4TF4LM Cc: "vnfpool@ietf.org" Subject: Re: [vnfpool] Follow-up question from the BOF X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 21:34:45 -0000 --047d7b3a8ae6bee7f604fecefdd7 Content-Type: text/plain; charset=UTF-8 Hi Martin, Here is one point. One constraint of the proposed work, in my view, is that the scope does not consider state management. Most useful NFs are stateful. Hence, removing state management from the scope is not ideal, and hence is a limit. There is interesting recent progress in generic, reusable NF state management, such as Merge/Split ( https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final205.pdf). If this is included, I believe that the group can develop a lot more more solutions. Richard On Tue, Jul 22, 2014 at 4:14 PM, Martin Stiemerling wrote: > Dear all, > > This is a follow-up question from your responsible AD about the first hum > we did take in the BOF @ IETF-90. > > The questions asked was if the technical problem to be worked on is clear? > A majority on the session did hum against that the technical problem to be > solved is clear. > > However, from the discussion during the BOF session it is not clear to me > that the technical problem isn't understood. > > So now the question: > Why do people are not convinced that the technical problem is solveable? > > So, enlight me :) > > Thanks, > > Martin > > _______________________________________________ > vnfpool mailing list > vnfpool@ietf.org > https://www.ietf.org/mailman/listinfo/vnfpool > -- -- ===================================== | Y. Richard Yang | | Professor of Computer Science | | http://www.cs.yale.edu/~yry/ | ===================================== --047d7b3a8ae6bee7f604fecefdd7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Martin,

Here is one point. One const= raint of the proposed work, in my view, is that the scope does not consider= state management. Most useful NFs are stateful. Hence, removing state mana= gement from the scope is not ideal, and hence is a limit. There is interest= ing recent progress in generic, reusable NF state management, such as Merge= /Split (https://www.usenix.org/system/files/conference/nsdi13/ns= di13-final205.pdf). If this is included, I believe that the group can d= evelop a lot more more solutions.

Richard


<= div class=3D"gmail_quote">On Tue, Jul 22, 2014 at 4:14 PM, Martin Stiemerli= ng <mls.ietf@gmail.com> wrote:
Dear all,

This is a follow-up question from your responsible AD about the first hum w= e did take in the BOF @ IETF-90.

The questions asked was if the technical problem to be worked on is clear?<= br> A majority on the session did hum against that the technical problem to be = solved is clear.

However, from the discussion during the BOF session it is not clear to me t= hat the technical problem isn't understood.

So now the question:
Why do people are not convinced that the technical problem is solveable?
So, enlight me :)

Thanks,

=C2=A0 Martin

_______________________________________________
vnfpool mailing list
vnfpool@ietf.org<= br> https://www.ietf.org/mailman/listinfo/vnfpool



--
--=C2=A0
<= font face=3D"courier new, monospace">=C2=A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
| Y. Richard Yang <yry@cs.yale.edu> =C2=A0 |=
| Professor of Comp= uter Science =C2=A0 =C2=A0 =C2=A0 |
| http://www.cs.yale.edu/~yry/ =C2=A0 =C2=A0= =C2=A0 =C2=A0|
=C2= =A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--047d7b3a8ae6bee7f604fecefdd7-- From nobody Wed Jul 23 12:49:17 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2CD1A0204 for ; Wed, 23 Jul 2014 12:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMVsC4t359Mo for ; Wed, 23 Jul 2014 12:49:14 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EBEA1A063F for ; Wed, 23 Jul 2014 12:49:14 -0700 (PDT) Received: by mail-ig0-f170.google.com with SMTP id h3so5733030igd.1 for ; Wed, 23 Jul 2014 12:49:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=MDaOPLW7WYElcGu5kfi9mR4lq5/lW3iWikX5rMiXlHE=; b=wEqO/xm9rofxf/7Zp1RkQOmVQ69G+4ynf9wk2kaUbIc3pz5utUYWg4ISGdoYG0aPSb 3hERWqQ/UIiQwYHSPJL5LNKJj+tfL1oZHAOkMOqqYk7Iv3hDBnvaMGwOjHyj9EeUhdCK KO1iCjnrxQQuJM3V3Nvf/VsqomrGwM+rMwt2iEUltIB/Mgw8rOxqKYFgKuFjgQkf3qcM ESFyCOcGlSn2hq4J656IneetIMHLntkDSvUMN+aIld4ObdQrTLJzTg2b0A5ghMaF+XVK tCZcNThiEQFCkcoevjd92wppAn2/6d0TMtvNKeYZv89kF1ceHCz2LISFXbWeLow5BqJ9 POyw== X-Received: by 10.42.85.81 with SMTP id p17mr5653476icl.33.1406144952684; Wed, 23 Jul 2014 12:49:12 -0700 (PDT) Received: from dhcp-9055.meeting.ietf.org (dhcp-9055.meeting.ietf.org. [31.133.144.85]) by mx.google.com with ESMTPSA id kw1sm15641008igb.2.2014.07.23.12.49.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 12:49:12 -0700 (PDT) Message-ID: <53D011B6.3040708@gmail.com> Date: Wed, 23 Jul 2014 15:49:10 -0400 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: vnfpool@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/JoMZtXqjGMfD7aUVJ3bmW6liQa4 Subject: [vnfpool] vnfpool and rserpool X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 19:49:16 -0000 I found yesterday's BOF to be very useful, in terms of clarifying the scope of the charter proposal and of identifying applicability considerations in several scenarios. We plan to get the next iteration of the charter out next week, with some additional text about policy. Many thanks to everybody who participated. This seems like a good time to post a reminder that we do have a draft on the applicability of rserpool to the vnfpool problem. This draft is not intended as a full gap analysis but it does identify problems that must be addressed by a redundancy model for VNF reliability, and looks at what is (and is not) provided by rserpool. In particular, section 4 says: The following features of RSerPool can be used for VNFPOOL: o Pool management. o PE selection with pool policies. o Session management with help of ASAP_BUSINESS_CARD. The following features have to be added to RSerPool itself: o Support of TCP including MPTCP as additional/alternative transport protocols. o Possibly add some special pool policies? The following features have to be provided outside of RSerPool: o State synchronisation for VNFPOOL. o Pool Manager functionality as an RSerPool-based service. Details are provided by the draft, which is available at: http://tools.ietf.org/html/draft-dreibholz-vnfpool-rserpool-applic-01. Please note that the question of which technology to use for vnfpool is open and will not be resolved until we have a full set of agreed-upon requirements, and that the rserpool draft was written as a demonstration of what might be possible with existing IETF protocols. We'd love to see similar drafts describing the applicability of other protocols or technologies. Thanks, Melinda From nobody Thu Jul 24 03:54:53 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38701A01DD for ; Thu, 24 Jul 2014 03:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adVZQOVcNvP5 for ; Thu, 24 Jul 2014 03:54:49 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C41381A01C5 for ; Thu, 24 Jul 2014 03:54:48 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w62so2502484wes.29 for ; Thu, 24 Jul 2014 03:54:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=XbY3A/Ik/k82rrIdZ0aOVDLvElbcRwVa76fH+ns+Cz8=; b=cDTtgs+90WiESQ0Nr6sYMhwR7vLDouXWIfuVQq8llHNDRMARJHbn5Z348ufBh3aYWI uDKHdTZdakryLEt5TiprA7I6eMpkpYwB5B9qeA2uYBUSxXyFZWqeqBqKnL1i76eYOjtx mbAsxMzaJxCvZEWnuSzFdO8qm9bsjc28yRoB3yrNMykD8fFeQ3BIHCSBDRXjbghMjRKe ahK1B1q9tFuHGmrEIMcJwl0NXHkJ3m1tCPooRZ5YyID8GkWT+e1RqmBCqtLblr34NQDe Ce/huQ5KQ+2LVqTWJktPBwftOsthW71o8k4VZ8cGb5pHyd0d8bV5+nz/J16hqpIwNhI0 iamw== X-Received: by 10.180.38.14 with SMTP id c14mr8141028wik.43.1406199284767; Thu, 24 Jul 2014 03:54:44 -0700 (PDT) Received: from dhcp-8cea.meeting.ietf.org (dhcp-8cea.meeting.ietf.org. [31.133.140.234]) by mx.google.com with ESMTPSA id cz4sm21547476wib.23.2014.07.24.03.54.43 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Jul 2014 03:54:44 -0700 (PDT) Message-ID: <53D0E5F1.9060503@gmail.com> Date: Thu, 24 Jul 2014 06:54:41 -0400 From: Martin Stiemerling User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Y. Richard Yang" References: <53CEC61A.9010104@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/mR2Eh4hgX9TuSWamKgGVZPMogaY Cc: "vnfpool@ietf.org" Subject: Re: [vnfpool] Follow-up question from the BOF X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 10:54:51 -0000 Hi Richard, Am 22.07.14 um 17:34 schrieb Y. Richard Yang: > Hi Martin, > > Here is one point. One constraint of the proposed work, in my view, is > that the scope does not consider state management. Most useful NFs are > stateful. Hence, removing state management from the scope is not ideal, > and hence is a limit. There is interesting recent progress in generic, > reusable NF state management, such as Merge/Split > (https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final205.pdf). > If this is included, I believe that the group can develop a lot more > more solutions. state management is an interesting topic, but there has been explicit community feedback during the first bof that this is not something the potential wg should be working on, as this is very vendor specific. Martin From nobody Thu Jul 24 04:09:55 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4567B1A01FF for ; Thu, 24 Jul 2014 04:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.552 X-Spam-Level: X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgNMuCQFFo7F for ; Thu, 24 Jul 2014 04:09:47 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E98F1A01EB for ; Thu, 24 Jul 2014 04:09:47 -0700 (PDT) Received: from dhcp-8cb4.meeting.ietf.org (dhcp-8cb4.meeting.ietf.org [31.133.140.180]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 1124E1C104E6A; Thu, 24 Jul 2014 13:09:43 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <53D0E5F1.9060503@gmail.com> Date: Thu, 24 Jul 2014 07:09:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53CEC61A.9010104@gmail.com> <53D0E5F1.9060503@gmail.com> To: Martin Stiemerling X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/jmeJVfQb6O1UtAs-KcVolqJdF4Q Cc: "vnfpool@ietf.org" , "Y. Richard Yang" Subject: Re: [vnfpool] Follow-up question from the BOF X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 11:09:52 -0000 On 24 Jul 2014, at 06:54, Martin Stiemerling wrote: > Hi Richard, >=20 > Am 22.07.14 um 17:34 schrieb Y. Richard Yang: >> Hi Martin, >>=20 >> Here is one point. One constraint of the proposed work, in my view, = is >> that the scope does not consider state management. Most useful NFs = are >> stateful. Hence, removing state management from the scope is not = ideal, >> and hence is a limit. There is interesting recent progress in = generic, >> reusable NF state management, such as Merge/Split >> = (https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final205.pdf= ). >> If this is included, I believe that the group can develop a lot more >> more solutions. >=20 > state management is an interesting topic, but there has been explicit = community feedback during the first bof that this is not something the = potential wg should be working on, as this is very vendor specific. ... and there are most likely a lot IPRs... That was one of the reasons state sharing was excluded from the scope of RSerPool... Best regards Michael >=20 > Martin >=20 > _______________________________________________ > vnfpool mailing list > vnfpool@ietf.org > https://www.ietf.org/mailman/listinfo/vnfpool >=20 From nobody Thu Jul 24 04:47:45 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D2E1A01CA for ; Thu, 24 Jul 2014 04:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oS6ZY6torKaS for ; Thu, 24 Jul 2014 04:47:42 -0700 (PDT) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3122D1A017E for ; Thu, 24 Jul 2014 04:47:42 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id hq11so4626634vcb.30 for ; Thu, 24 Jul 2014 04:47:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=NzKJdig3zU4XSW6pAsI3B27K+1DI2+nzYkJp+l0+Ehk=; b=Xq5s1I1q19drZDzWgwLHruy1LuI5lphEBAEEXvAoDUPfizjvWuegJkOyuh96oqIe5P 8UI4RHCCtm12LlFs4dPD7GvmEQsmbSSH4dnN4DPYba1RlqGzhCEi4ruAsA8HWhcbT2ar /4L3fE+2VFK1xGP3oerpwJROxsTQMNGi4dywvDnorcTUOMRXnH6i1kChc7WDAifgp386 69eKSriyZP5qmX7NDWcEgCHsRwRf6W0cq03B4/LFoZfPEf6Qe4emX7rsPVOiOcNRju+Z NTaCtePy3OPYRF9/GWfTCKJ39cjpAaDZDeDqXyJRQcJDGSmFE4a3raU+bEX1nxoyWfNC AD5w== MIME-Version: 1.0 X-Received: by 10.220.73.137 with SMTP id q9mr11277163vcj.64.1406202461255; Thu, 24 Jul 2014 04:47:41 -0700 (PDT) Sender: yang.r.yang@gmail.com Received: by 10.58.133.11 with HTTP; Thu, 24 Jul 2014 04:47:41 -0700 (PDT) Received: by 10.58.133.11 with HTTP; Thu, 24 Jul 2014 04:47:41 -0700 (PDT) In-Reply-To: References: <53CEC61A.9010104@gmail.com> <53D0E5F1.9060503@gmail.com> Date: Thu, 24 Jul 2014 07:47:41 -0400 X-Google-Sender-Auth: AYbk8-VfYHGCmf8bm55wrR4x6zI Message-ID: From: "Y. Richard Yang" To: Michael Tuexen Content-Type: multipart/alternative; boundary=001a11c2ab4e2f7f2604feef06db Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/zx21aMg13cm53NsyYksS8Zx_HiA Cc: vnfpool@ietf.org, mls.ietf@gmail.com Subject: Re: [vnfpool] Follow-up question from the BOF X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 11:47:43 -0000 --001a11c2ab4e2f7f2604feef06db Content-Type: text/plain; charset=UTF-8 Martin, Michael, IPR concerns are valid, but if they are crucial to solve the problem, and the solution provides higher benefit, they could be addressed, right? Regarding vendor specific solution, this is a very good point! Please take a look at approaches such as merge/split. They allow vendor specific packaging of NF state. Hence, transfers of state can be only among NFs of the same vendor. The advance, however, is that at least the controller can be different from the NF vendors. This is a good progress, in my view. Make sense? Richard On Jul 24, 2014 7:09 AM, "Michael Tuexen" wrote: > > On 24 Jul 2014, at 06:54, Martin Stiemerling wrote: > > > Hi Richard, > > > > Am 22.07.14 um 17:34 schrieb Y. Richard Yang: > >> Hi Martin, > >> > >> Here is one point. One constraint of the proposed work, in my view, is > >> that the scope does not consider state management. Most useful NFs are > >> stateful. Hence, removing state management from the scope is not ideal, > >> and hence is a limit. There is interesting recent progress in generic, > >> reusable NF state management, such as Merge/Split > >> ( > https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final205.pdf > ). > >> If this is included, I believe that the group can develop a lot more > >> more solutions. > > > > state management is an interesting topic, but there has been explicit > community feedback during the first bof that this is not something the > potential wg should be working on, as this is very vendor specific. > ... and there are most likely a lot IPRs... That was one of the reasons > state sharing was excluded from the scope of RSerPool... > > Best regards > Michael > > > > Martin > > > > _______________________________________________ > > vnfpool mailing list > > vnfpool@ietf.org > > https://www.ietf.org/mailman/listinfo/vnfpool > > > > --001a11c2ab4e2f7f2604feef06db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Martin, Michael,

IPR concerns are valid, but if they are crucial to solve the= problem, and the solution provides higher benefit, they could be addressed= , right?

Regarding vendor specific solution, this is a very good poin= t! Please take a look at approaches such as merge/split. They allow vendor = specific packaging of NF state. Hence, transfers of state can be only among= NFs of the same vendor. The advance, however, is that at least the control= ler can be different from the NF vendors. This is a good progress, in my vi= ew. Make sense?

Richard

On Jul 24, 2014 7:09 AM, "Michael Tuexen&qu= ot; <Michael.Tuexen@= lurchi.franken.de> wrote:

On 24 Jul 2014, at 06:54, Martin Stiemerling <mls.ietf@gmail.com> wrote:

> Hi Richard,
>
> Am 22.07.14 um 17:34 schrieb Y. Richard Yang:
>> Hi Martin,
>>
>> Here is one point. One constraint of the proposed work, in my view= , is
>> that the scope does not consider state management. Most useful NFs= are
>> stateful. Hence, removing state management from the scope is not i= deal,
>> and hence is a limit. There is interesting recent progress in gene= ric,
>> reusable NF state management, such as Merge/Split
>> (https://www.usenix.org/system/files/= conference/nsdi13/nsdi13-final205.pdf).
>> If this is included, I believe that the group can develop a lot mo= re
>> more solutions.
>
> state management is an interesting topic, but there has been explicit = community feedback during the first bof that this is not something the pote= ntial wg should be working on, as this is very vendor specific.
... and there are most likely a lot IPRs... That was one of the reasons
state sharing was excluded from the scope of RSerPool...

Best regards
Michael
>
> =C2=A0Martin
>
> _______________________________________________
> vnfpool mailing list
> vnfpool@ietf.org
> https://www.ietf.org/mailman/listinfo/vnfpool
>

--001a11c2ab4e2f7f2604feef06db-- From nobody Thu Jul 24 07:06:25 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026161A035B for ; Thu, 24 Jul 2014 07:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpzjW8NurnKS for ; Thu, 24 Jul 2014 07:06:09 -0700 (PDT) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E7001A0350 for ; Thu, 24 Jul 2014 07:06:02 -0700 (PDT) Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8ACEC88138; Thu, 24 Jul 2014 16:05:59 +0200 (CEST) Received: from ESTGVMSP101.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtptc.telefonica.com (Postfix) with ESMTPS id 695D08813B; Thu, 24 Jul 2014 16:05:59 +0200 (CEST) Received: from emea01-db3-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.49) with Microsoft SMTP Server (TLS) id 14.3.146.2; Thu, 24 Jul 2014 16:05:58 +0200 Received: from DB3PR06MB252.eurprd06.prod.outlook.com (10.141.5.153) by DB3PR06MB251.eurprd06.prod.outlook.com (10.141.5.146) with Microsoft SMTP Server (TLS) id 15.0.990.7; Thu, 24 Jul 2014 14:05:57 +0000 Received: from DB3PR06MB252.eurprd06.prod.outlook.com ([10.141.5.153]) by DB3PR06MB252.eurprd06.prod.outlook.com ([10.141.5.153]) with mapi id 15.00.0990.007; Thu, 24 Jul 2014 14:05:57 +0000 From: DIEGO LOPEZ GARCIA To: "Y. Richard Yang" Thread-Topic: [vnfpool] Follow-up question from the BOF Thread-Index: AQHPpemjVlcpgUSIKESa236wz9XhvZusnakAgAJx2oCAAAQyAIAACp2AgAAmoQA= Date: Thu, 24 Jul 2014 14:05:57 +0000 Message-ID: <0850FF93-99BD-4206-AB0B-86021BBEF960@telefonica.com> References: <53CEC61A.9010104@gmail.com> <53D0E5F1.9060503@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.161.176] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(252514010)(199002)(24454002)(51704005)(377454003)(110136001)(92726001)(2656002)(19617315012)(31966008)(83716003)(46102001)(81542001)(2171001)(20776003)(4396001)(74662001)(106116001)(92566001)(74502001)(87936001)(15202345003)(15975445006)(82746002)(76482001)(85852003)(21056001)(95666004)(66066001)(105586002)(77982001)(19580405001)(561944003)(99396002)(83072002)(64706001)(81342001)(93886003)(86362001)(101416001)(33656002)(36756003)(16236675004)(107046002)(83322001)(50986999)(19580395003)(106356001)(85306003)(80022001)(79102001)(54356999)(76176999)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR06MB251; H:DB3PR06MB252.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_0850FF9399BD4206AB0B86021BBEF960telefonicacom_" MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/TGbsCOpMiODMCcn0nIBM6T4oBgI Cc: "vnfpool@ietf.org" , Michael Tuexen , "mls.ietf@gmail.com" Subject: Re: [vnfpool] Follow-up question from the BOF X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 14:06:22 -0000 --_000_0850FF9399BD4206AB0B86021BBEF960telefonicacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, As one of the supporters of the idea of not leaving state management out of= scope, I am glad to see Richard's proposal and happy to support the idea o= f exploring a solution able to encompass vendor specific approaches. Be goode, On 24 Jul 2014, at 07:47 , Y. Richard Yang > wrote: Martin, Michael, IPR concerns are valid, but if they are crucial to solve the problem, and t= he solution provides higher benefit, they could be addressed, right? Regarding vendor specific solution, this is a very good point! Please take = a look at approaches such as merge/split. They allow vendor specific packag= ing of NF state. Hence, transfers of state can be only among NFs of the sam= e vendor. The advance, however, is that at least the controller can be diff= erent from the NF vendors. This is a good progress, in my view. Make sense? Richard On Jul 24, 2014 7:09 AM, "Michael Tuexen" > wrote: On 24 Jul 2014, at 06:54, Martin Stiemerling > wrote: > Hi Richard, > > Am 22.07.14 um 17:34 schrieb Y. Richard Yang: >> Hi Martin, >> >> Here is one point. One constraint of the proposed work, in my view, is >> that the scope does not consider state management. Most useful NFs are >> stateful. Hence, removing state management from the scope is not ideal, >> and hence is a limit. There is interesting recent progress in generic, >> reusable NF state management, such as Merge/Split >> (https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final205.p= df). >> If this is included, I believe that the group can develop a lot more >> more solutions. > > state management is an interesting topic, but there has been explicit com= munity feedback during the first bof that this is not something the potenti= al wg should be working on, as this is very vendor specific. ... and there are most likely a lot IPRs... That was one of the reasons state sharing was excluded from the scope of RSerPool... Best regards Michael > > Martin > > _______________________________________________ > vnfpool mailing list > vnfpool@ietf.org > https://www.ietf.org/mailman/listinfo/vnfpool > _______________________________________________ vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool -- PLEASE NOTE MY NEW EMAIL ADDRESS "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci= =C3=B3n y/o copia sin autorizaci=C3=B3n puede estar prohibida en virtud de = la legislaci=C3=B3n vigente. Si ha recibido este mensaje por error, le roga= mos que nos lo comunique inmediatamente por esta misma v=C3=ADa y proceda a= su destrucci=C3=B3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura= , utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza= =C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o vigent= e. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imedi= atamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o --_000_0850FF9399BD4206AB0B86021BBEF960telefonicacom_ Content-Type: text/html; charset="utf-8" Content-ID: <61B70A1790FEE54AA0588E75673FEF35@eurprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi,

As one of the supporters of the idea of not leaving state management o= ut of scope, I am glad to see Richard's proposal and happy to support the i= dea of exploring a solution able to encompass vendor specific approaches.

Be goode,

On 24 Jul 2014, at 07:47 , Y. Richard Yang <yry@cs.yale.edu> wrote:

Martin, Michael,

IPR concerns are valid, but if they are crucial to solve the= problem, and the solution provides higher benefit, they could be addressed= , right?

Regarding vendor specific solution, this is a very good poin= t! Please take a look at approaches such as merge/split. They allow vendor = specific packaging of NF state. Hence, transfers of state can be only among= NFs of the same vendor. The advance, however, is that at least the controller can be different from the NF vend= ors. This is a good progress, in my view. Make sense?

Richard

On Jul 24, 2014 7:09 AM, "Michael Tuexen&qu= ot; <Michael.Tuexen@= lurchi.franken.de> wrote:

On 24 Jul 2014, at 06:54, Martin Stiemerling <mls.ietf@gmail.com> wrote:

> Hi Richard,
>
> Am 22.07.14 um 17:34 schrieb Y. Richard Yang:
>> Hi Martin,
>>
>> Here is one point. One constraint of the proposed work, in my view= , is
>> that the scope does not consider state management. Most useful NFs= are
>> stateful. Hence, removing state management from the scope is not i= deal,
>> and hence is a limit. There is interesting recent progress in gene= ric,
>> reusable NF state management, such as Merge/Split
>> (https://www.usenix.org/system/files/= conference/nsdi13/nsdi13-final205.pdf).
>> If this is included, I believe that the group can develop a lot mo= re
>> more solutions.
>
> state management is an interesting topic, but there has been explicit = community feedback during the first bof that this is not something the pote= ntial wg should be working on, as this is very vendor specific.
... and there are most likely a lot IPRs... That was one of the reasons
state sharing was excluded from the scope of RSerPool...

Best regards
Michael
>
>  Martin
>
> _______________________________________________
> vnfpool mailing list
> vnfpool@ietf.org
> https://www.ietf.org/mailman/listinfo/vnfpool
>

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

--
PLEASE NOTE MY NEW EMAIL ADDRESS
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lo= pez/

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3= n puede estar prohibida en virtud de la legislaci=C3=B3n vigente. Si ha rec= ibido este mensaje por error, le rogamos que nos lo comunique inmediatament= e por esta misma v=C3=ADa y proceda a su destrucci=C3=B3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have received this communication in error= and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem au= toriza=C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o = vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique= imediatamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o
 --_000_0850FF9399BD4206AB0B86021BBEF960telefonicacom_-- From nobody Thu Jul 24 07:09:25 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 200661A02C1 for ; Thu, 24 Jul 2014 07:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8TaTGwDfhE6 for ; Thu, 24 Jul 2014 07:09:21 -0700 (PDT) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1DBB1A02EB for ; Thu, 24 Jul 2014 07:09:20 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id lf12so4962020vcb.26 for ; Thu, 24 Jul 2014 07:09:19 -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:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=lTtcdOYbMF2Bn6JOmNL+wQ7zK3IAFJUeTS5qsx04CPU=; b=SaFJc1Wa6iQohxVDGqRJwDNTtzeb7JEx5GLYQVO0kHK4CcFyfpbJcGL6MMo5NzEiLj IPz/UFRH+bvf5HfXEmHryL2/ED94XS48ym/tujgYz66yPE4kTR8GFs0rrkkZy0UjGQUT qVBbZ6hraiZ5QaCIvZtBDX8EyfF0sKiczcsY4AXenycS+oEJUg3MrfsiMnoozyLXx5cb KI/hv9tOc0pJLuT6SadMHMkz4Qri6tl2IZ2MdLvVDTG0Y48Trr8cA8Mx0WpmXYtdUd72 J13m9ceGgGyBoL4+N06EjfYEfhoKRNSNNxF6+qHeA9P6zsbHGYQGdb2TGYIO73eAciLW 2T+A== X-Gm-Message-State: ALoCoQmBHMxkWTqgC5CbHQ8K53NRtxv2SFUkFGTd7ZUaqRAhXEPIhNzUW7qCHlRipWg6d1SkBxRv X-Received: by 10.220.199.193 with SMTP id et1mr12682218vcb.58.1406210959636; Thu, 24 Jul 2014 07:09:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.115.4 with HTTP; Thu, 24 Jul 2014 07:08:59 -0700 (PDT) In-Reply-To: <0850FF93-99BD-4206-AB0B-86021BBEF960@telefonica.com> References: <53CEC61A.9010104@gmail.com> <53D0E5F1.9060503@gmail.com> <0850FF93-99BD-4206-AB0B-86021BBEF960@telefonica.com> From: Jamal Hadi Salim Date: Thu, 24 Jul 2014 10:08:59 -0400 Message-ID: To: DIEGO LOPEZ GARCIA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/yyCx5uN599c-XjEb12zYJM_qWoM Cc: "vnfpool@ietf.org" , Michael Tuexen , "Y. Richard Yang" , "mls.ietf@gmail.com" Subject: Re: [vnfpool] Follow-up question from the BOF X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 14:09:23 -0000 I am not big on high-five, but i would like to add my +1. I will find vnfpool appealing if it does state. cheers, jamal On Thu, Jul 24, 2014 at 10:05 AM, DIEGO LOPEZ GARCIA wrote: > Hi, > > As one of the supporters of the idea of not leaving state management out = of > scope, I am glad to see Richard's proposal and happy to support the idea = of > exploring a solution able to encompass vendor specific approaches. > > Be goode, > > On 24 Jul 2014, at 07:47 , Y. Richard Yang wrote: > > Martin, Michael, > > IPR concerns are valid, but if they are crucial to solve the problem, and > the solution provides higher benefit, they could be addressed, right? > > Regarding vendor specific solution, this is a very good point! Please tak= e a > look at approaches such as merge/split. They allow vendor specific packag= ing > of NF state. Hence, transfers of state can be only among NFs of the same > vendor. The advance, however, is that at least the controller can be > different from the NF vendors. This is a good progress, in my view. Make > sense? > > Richard > > On Jul 24, 2014 7:09 AM, "Michael Tuexen" > wrote: >> >> >> On 24 Jul 2014, at 06:54, Martin Stiemerling wrote: >> >> > Hi Richard, >> > >> > Am 22.07.14 um 17:34 schrieb Y. Richard Yang: >> >> Hi Martin, >> >> >> >> Here is one point. One constraint of the proposed work, in my view, i= s >> >> that the scope does not consider state management. Most useful NFs ar= e >> >> stateful. Hence, removing state management from the scope is not idea= l, >> >> and hence is a limit. There is interesting recent progress in generic= , >> >> reusable NF state management, such as Merge/Split >> >> >> >> (https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final20= 5.pdf). >> >> If this is included, I believe that the group can develop a lot more >> >> more solutions. >> > >> > state management is an interesting topic, but there has been explicit >> > community feedback during the first bof that this is not something the >> > potential wg should be working on, as this is very vendor specific. >> ... and there are most likely a lot IPRs... That was one of the reasons >> state sharing was excluded from the scope of RSerPool... >> >> Best regards >> Michael >> > >> > Martin >> > >> > _______________________________________________ >> > vnfpool mailing list >> > vnfpool@ietf.org >> > https://www.ietf.org/mailman/listinfo/vnfpool >> > >> > _______________________________________________ > vnfpool mailing list > vnfpool@ietf.org > https://www.ietf.org/mailman/listinfo/vnfpool > > > -- > PLEASE NOTE MY NEW EMAIL ADDRESS > "Esta vez no fallaremos, Doctor Infierno" > > Dr Diego R. Lopez > Telefonica I+D > http://people.tid.es/diego.lopez/ > > e-mail: diego.r.lopez@telefonica.com > Tel: +34 913 129 041 > Mobile: +34 682 051 091 > ---------------------------------- > > > ________________________________ > > Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, > puede contener informaci=C3=B3n privilegiada o confidencial y es para uso > exclusivo de la persona o entidad de destino. Si no es usted. el > destinatario indicado, queda notificado de que la lectura, utilizaci=C3= =B3n, > divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3n puede estar prohibida en= virtud de la > legislaci=C3=B3n vigente. Si ha recibido este mensaje por error, le rogam= os que > nos lo comunique inmediatamente por esta misma v=C3=ADa y proceda a su > destrucci=C3=B3n. > > The information contained in this transmission is privileged and > confidential information intended only for the use of the individual or > entity named above. If the reader of this message is not the intended > recipient, you are hereby notified that any dissemination, distribution o= r > copying of this communication is strictly prohibited. If you have receive= d > this transmission in error, do not read it. Please immediately reply to t= he > sender that you have received this communication in error and then delete > it. > > Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3= =A1rio, > pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9 pa= ra uso exclusivo > da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vossa senhoria o des= tinat=C3=A1rio > indicado, fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, divulga= =C3=A7=C3=A3o e/ou > c=C3=B3pia sem autoriza=C3=A7=C3=A3o pode estar proibida em virtude da le= gisla=C3=A7=C3=A3o vigente. > Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique > imediatamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o > > _______________________________________________ > vnfpool mailing list > vnfpool@ietf.org > https://www.ietf.org/mailman/listinfo/vnfpool > From nobody Thu Jul 24 07:15:20 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF0B1A0343 for ; Thu, 24 Jul 2014 07:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kH3Ex6cP6i1e for ; Thu, 24 Jul 2014 07:15:17 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2C11A035B for ; Thu, 24 Jul 2014 07:15:15 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.162.238; From: "Susan Hares" To: "'DIEGO LOPEZ GARCIA'" , "'Y. Richard Yang'" References: <53CEC61A.9010104@gmail.com> <53D0E5F1.9060503@gmail.com> <0850FF93-99BD-4206-AB0B-86021BBEF960@telefonica.com> In-Reply-To: <0850FF93-99BD-4206-AB0B-86021BBEF960@telefonica.com> Date: Thu, 24 Jul 2014 10:15:11 -0400 Message-ID: <010501cfa749$ae746ab0$0b5d4010$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0106_01CFA728.2765B0E0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQHW3qJ/Qxoju7WZpU2Z62WJkt0QZQGeKOhuAvy2AJgCDYYXVwGii+dFAi00kmObTRQmUA== X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/RxrNx9Y9o9SRfR9eG_mVQ-gdio8 Cc: vnfpool@ietf.org, 'Michael Tuexen' , mls.ietf@gmail.com Subject: Re: [vnfpool] Follow-up question from the BOF X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 14:15:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0106_01CFA728.2765B0E0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Diego and Richard: =20 As another supporter of including state management in scope, I support = Richard=E2=80=99s proposal.=20 =20 Sue=20 =20 From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of DIEGO LOPEZ = GARCIA Sent: Thursday, July 24, 2014 10:06 AM To: Y. Richard Yang Cc: vnfpool@ietf.org; Michael Tuexen; mls.ietf@gmail.com Subject: Re: [vnfpool] Follow-up question from the BOF =20 Hi,=20 =20 As one of the supporters of the idea of not leaving state management out = of scope, I am glad to see Richard's proposal and happy to support the = idea of exploring a solution able to encompass vendor specific = approaches. =20 Be goode, =20 On 24 Jul 2014, at 07:47 , Y. Richard Yang wrote: Martin, Michael, IPR concerns are valid, but if they are crucial to solve the problem, = and the solution provides higher benefit, they could be addressed, = right? Regarding vendor specific solution, this is a very good point! Please = take a look at approaches such as merge/split. They allow vendor = specific packaging of NF state. Hence, transfers of state can be only = among NFs of the same vendor. The advance, however, is that at least the = controller can be different from the NF vendors. This is a good = progress, in my view. Make sense? Richard On Jul 24, 2014 7:09 AM, "Michael Tuexen" = wrote: On 24 Jul 2014, at 06:54, Martin Stiemerling wrote: > Hi Richard, > > Am 22.07.14 um 17:34 schrieb Y. Richard Yang: >> Hi Martin, >> >> Here is one point. One constraint of the proposed work, in my view, = is >> that the scope does not consider state management. Most useful NFs = are >> stateful. Hence, removing state management from the scope is not = ideal, >> and hence is a limit. There is interesting recent progress in = generic, >> reusable NF state management, such as Merge/Split >> = (https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final205.pd= f). >> If this is included, I believe that the group can develop a lot more >> more solutions. > > state management is an interesting topic, but there has been explicit = community feedback during the first bof that this is not something the = potential wg should be working on, as this is very vendor specific. ... and there are most likely a lot IPRs... That was one of the reasons state sharing was excluded from the scope of RSerPool... Best regards Michael > > Martin > > _______________________________________________ > vnfpool mailing list > vnfpool@ietf.org > https://www.ietf.org/mailman/listinfo/vnfpool > _______________________________________________ vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool =20 -- PLEASE NOTE MY NEW EMAIL ADDRESS "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- =20 =20 _____ =20 Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, = puede contener informaci=C3=B3n privilegiada o confidencial y es para = uso exclusivo de la persona o entidad de destino. Si no es usted. el = destinatario indicado, queda notificado de que la lectura, = utilizaci=C3=B3n, divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3n puede = estar prohibida en virtud de la legislaci=C3=B3n vigente. Si ha recibido = este mensaje por error, le rogamos que nos lo comunique inmediatamente = por esta misma v=C3=ADa y proceda a su destrucci=C3=B3n. The information contained in this transmission is privileged and = confidential information intended only for the use of the individual or = entity named above. If the reader of this message is not the intended = recipient, you are hereby notified that any dissemination, distribution = or copying of this communication is strictly prohibited. If you have = received this transmission in error, do not read it. Please immediately = reply to the sender that you have received this communication in error = and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu = destinat=C3=A1rio, pode conter informa=C3=A7=C3=A3o privilegiada ou = confidencial e =C3=A9 para uso exclusivo da pessoa ou entidade de = destino. Se n=C3=A3o =C3=A9 vossa senhoria o destinat=C3=A1rio indicado, = fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, = divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza=C3=A7=C3=A3o pode = estar proibida em virtude da legisla=C3=A7=C3=A3o vigente. Se recebeu = esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente = por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o ------=_NextPart_000_0106_01CFA728.2765B0E0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Diego and Richard:

 

As another supporter of including state management in scope, I = support Richard=E2=80=99s proposal.

 

Sue

 

From:= = vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of DIEGO = LOPEZ GARCIA
Sent: Thursday, July 24, 2014 10:06 = AM
To: Y. Richard Yang
Cc: vnfpool@ietf.org; Michael = Tuexen; mls.ietf@gmail.com
Subject: Re: [vnfpool] Follow-up = question from the BOF

 

Hi, =

 

As one of the supporters of the idea of not leaving = state management out of scope, I am glad to see Richard's proposal and = happy to support the idea of exploring a solution able to encompass = vendor specific approaches.

 

Be goode,

 

On = 24 Jul 2014, at 07:47 , Y. Richard Yang <yry@cs.yale.edu> = wrote:



Martin, = Michael,

IPR concerns are valid, but if they are = crucial to solve the problem, and the solution provides higher benefit, = they could be addressed, right?

Regarding vendor = specific solution, this is a very good point! Please take a look at = approaches such as merge/split. They allow vendor specific packaging of = NF state. Hence, transfers of state can be only among NFs of the same = vendor. The advance, however, is that at least the controller can be = different from the NF vendors. This is a good progress, in my view. Make = sense?

Richard

On Jul 24, 2014 7:09 AM, "Michael Tuexen" = <Michael.Tuexen@lurchi.fr= anken.de> wrote:


On 24 Jul 2014, at 06:54, Martin = Stiemerling <mls.ietf@gmail.com> = wrote:

> Hi Richard,
>
> Am 22.07.14 um 17:34 = schrieb Y. Richard Yang:
>> Hi Martin,
>>
>> = Here is one point. One constraint of the proposed work, in my view, = is
>> that the scope does not consider state management. Most = useful NFs are
>> stateful. Hence, removing state management = from the scope is not ideal,
>> and hence is a limit. There is = interesting recent progress in generic,
>> reusable NF state = management, such as Merge/Split
>> (https://www.usenix.org/system/files/conference/nsdi13/n= sdi13-final205.pdf).
>> If this is included, I believe that = the group can develop a lot more
>> more = solutions.
>
> state management is an interesting topic, but = there has been explicit community feedback during the first bof that = this is not something the potential wg should be working on, as this is = very vendor specific.
... and there are most likely a lot IPRs... = That was one of the reasons
state sharing was excluded from the scope = of RSerPool...

Best regards
Michael
>
> =  Martin
>
> = _______________________________________________
> vnfpool mailing = list
> vnfpool@ietf.org
> https://www.ietf.org/mailman/listinfo/vnfpool
&g= t;

_______________________________________________
vnfp= ool mailing list
vnfpool@ietf.org
https://www.ietf.o= rg/mailman/listinfo/vnfpool

 

--
PLEASE NOTE MY NEW EMAIL ADDRESS
"Esta = vez no fallaremos, Doctor Infierno"

Dr Diego R. = Lopez
Telefonica I+D
http://people.tid.es/diego.lop= ez/

e-mail: diego.r.lopez@telefonica.com=
Tel:    +34 913 129 041
Mobile: +34 682 051 = 091
----------------------------------

 

 

Este mensaje y sus adjuntos se dirigen exclusivamente a su = destinatario, puede contener informaci=C3=B3n privilegiada o = confidencial y es para uso exclusivo de la persona o entidad de destino. = Si no es usted. el destinatario indicado, queda notificado de que la = lectura, utilizaci=C3=B3n, divulgaci=C3=B3n y/o copia sin = autorizaci=C3=B3n puede estar prohibida en virtud de la legislaci=C3=B3n = vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=C3=ADa y proceda a su = destrucci=C3=B3n.

The information contained in this transmission = is privileged and confidential information intended only for the use of = the individual or entity named above. If the reader of this message is = not the intended recipient, you are hereby notified that any = dissemination, distribution or copying of this communication is strictly = prohibited. If you have received this transmission in error, do not read = it. Please immediately reply to the sender that you have received this = communication in error and then delete it.

Esta mensagem e seus = anexos se dirigem exclusivamente ao seu destinat=C3=A1rio, pode conter = informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9 para uso = exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vossa = senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura, = utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem = autoriza=C3=A7=C3=A3o pode estar proibida em virtude da = legisla=C3=A7=C3=A3o vigente. Se recebeu esta mensagem por erro, = rogamos-lhe que nos o comunique imediatamente por esta mesma via e = proceda a sua = destrui=C3=A7=C3=A3o

------=_NextPart_000_0106_01CFA728.2765B0E0-- From nobody Thu Jul 24 07:45:22 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085A91A03B7 for ; Thu, 24 Jul 2014 07:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Qn0-Bveor2n for ; Thu, 24 Jul 2014 07:45:14 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C18A71A03B1 for ; Thu, 24 Jul 2014 07:45:14 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id lx4so2379001iec.3 for ; Thu, 24 Jul 2014 07:45:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=50YO7mYsUDJG5NSCZ17yJpXrPI9yZM+2nHs8BZngrTY=; b=P+YdjBNIBaD/lTuQoR2/GqYGH//LL2u0udHbBvuzqzULq74iRCNazbACYA/9XJ0JWL SNpxZ9B3/1OaPvf2xQIJdKncUKPUyDDModSCKBipD6pIhPu9kbd3vyii5aohn0R8+bpg +bZn1uYeLWgYX+f/R7MDM8+m+e9+VnhRIQPBXAs9a6HCrS5A5Hz0SMPNoBkQ56DtvTWa 22sLPf/Xwd9D777827vs69MmkSl+BUj1aYMI4fQzWAJ09WIGnAu92mIlokDegBlSezBQ 4awoZpgYXYGRCF/EHDFp0sEp4EZVV/xhgjUTi6ctvk8Qgd/4/WvelgNHy6PhsSBhsOTe KqWw== X-Received: by 10.50.57.68 with SMTP id g4mr40066451igq.48.1406213114045; Thu, 24 Jul 2014 07:45:14 -0700 (PDT) Received: from dhcp-9055.meeting.ietf.org (dhcp-9055.meeting.ietf.org. [31.133.144.85]) by mx.google.com with ESMTPSA id i8sm49420987igt.17.2014.07.24.07.45.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 07:45:13 -0700 (PDT) Message-ID: <53D11BF6.2080901@gmail.com> Date: Thu, 24 Jul 2014 10:45:10 -0400 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Y. Richard Yang" References: <53CEC61A.9010104@gmail.com> <53D0E5F1.9060503@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/cSIZiwTjJvpeXk-kSlBg8LCvKfo Cc: vnfpool@ietf.org, mls.ietf@gmail.com Subject: Re: [vnfpool] Follow-up question from the BOF X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 14:45:21 -0000 Hi, folks: We're in complete agreement about interoperability between pool managers and pool elements from different vendors, and that's already implicit in the charter (it's why we're talking about standardizing a pooling protocol). So, on that front I think we're good. It's probably premature to be talking about protocol specifics but if we assume that the data being transported between the pool manager and pool elements are tagged (whether they're TLVs, JSON, ASN.1 - whatever!) it allows for future extensibility related to state conveyance, should the need arise. That is to say, I think we're in good shape in terms of not closing off the possibility of future work. Melinda From nobody Thu Jul 24 08:14:16 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634151A0456 for ; Thu, 24 Jul 2014 08:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.913 X-Spam-Level: X-Spam-Status: No, score=-97.913 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82oosv_Dpw02 for ; Thu, 24 Jul 2014 08:14:06 -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 BF8841A02D5 for ; Thu, 24 Jul 2014 08:11:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKM38944; Thu, 24 Jul 2014 15:11:06 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Jul 2014 16:11:05 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Thu, 24 Jul 2014 23:11:01 +0800 From: Zongning To: Melinda Shore , "Y. Richard Yang" Thread-Topic: [vnfpool] Follow-up question from the BOF Thread-Index: AQHPpemOJU2UUYr3UESfh3q1MomqwpusF40AgAJx2oCAAAQyAIAACp2AgAAxlwCAAIoRYA== Date: Thu, 24 Jul 2014 15:11:00 +0000 Message-ID: References: <53CEC61A.9010104@gmail.com> <53D0E5F1.9060503@gmail.com> <53D11BF6.2080901@gmail.com> In-Reply-To: <53D11BF6.2080901@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.145.140] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/Wz4k_UasSPGXMJBQ5XMhqbXHwtQ Cc: "vnfpool@ietf.org" , "mls.ietf@gmail.com" Subject: [vnfpool] =?gb2312?b?tPC4tDogIEZvbGxvdy11cCBxdWVzdGlvbiBmcm9tIHRo?= =?gb2312?b?ZSBCT0Y=?= X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 15:14:12 -0000 SnVzdCBjb25jdXIgdG8gTWVsaW5kYSAtIHdlIGFncmVlIHRvIGhhdmUgc3RhdGUgbWFuYWdlbWVu dCByZWxhdGVkIGluZm9ybWF0aW9uIHRvIGJlIHRyYW5zcG9ydGVkIGJldHdlZW4gcG9vbCBtYW5h Z2VyIGFuZCBtZW1iZXJzIGluIGEgc3RhbmRhcmQgd2F5LiBXZSBoYXZlIHNwYWNlL29wdGlvbnMg aW4gdGhlIHByb3RvY29scywgYnV0IHdlIG5lZWQgZnVydGhlciBJLURzIHRvIHRhbGsgYWJvdXQg c3BlY2lmaWNhdGlvbiBvbiBwcm90b2NvbC4NCldlIGNvdWxkIHB1dCBqdXN0IGEgZmV3IHdvcmRz IGluIG91ciBjaGFydGVyIHRvIHJlZmxlY3QgdGhpcywgaWYgcGVvcGxlIGZlZWwgbW9yZSBjb21m b3J0YWJsZS4gQXMgc2FpZCwgd2UgYWxyZWFkeSBoYXZlIGltcGxpY2l0IHdvcmRpbmcsIHNvIG1h eWJlIGp1c3QgYSB0cml2aWFsIGlzc3VlLg0KDQpUaGFua3MuDQoNCi1OaW5nDQoNCi0tLS0t08q8 /tStvP4tLS0tLQ0Kt6K8/sjLOiB2bmZwb29sIFttYWlsdG86dm5mcG9vbC1ib3VuY2VzQGlldGYu b3JnXSC0+rHtIE1lbGluZGEgU2hvcmUNCreiy83KsbzkOiAyMDE0xOo31MIyNMjVIDEwOjQ1DQrK 1bz+yMs6IFkuIFJpY2hhcmQgWWFuZw0Ks63LzTogdm5mcG9vbEBpZXRmLm9yZzsgbWxzLmlldGZA Z21haWwuY29tDQrW98ziOiBSZTogW3ZuZnBvb2xdIEZvbGxvdy11cCBxdWVzdGlvbiBmcm9tIHRo ZSBCT0YNCg0KSGksIGZvbGtzOg0KDQpXZSdyZSBpbiBjb21wbGV0ZSBhZ3JlZW1lbnQgYWJvdXQg aW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuIHBvb2wgbWFuYWdlcnMgYW5kIHBvb2wgZWxlbWVudHMg ZnJvbSBkaWZmZXJlbnQgdmVuZG9ycywgYW5kIHRoYXQncyBhbHJlYWR5IGltcGxpY2l0IGluIHRo ZSBjaGFydGVyIChpdCdzIHdoeSB3ZSdyZSB0YWxraW5nIGFib3V0IHN0YW5kYXJkaXppbmcgYSBw b29saW5nIHByb3RvY29sKS4gIFNvLCBvbiB0aGF0IGZyb250IEkgdGhpbmsgd2UncmUgZ29vZC4g IEl0J3MgcHJvYmFibHkgcHJlbWF0dXJlIHRvIGJlIHRhbGtpbmcgYWJvdXQgcHJvdG9jb2wgc3Bl Y2lmaWNzIGJ1dCBpZiB3ZSBhc3N1bWUgdGhhdCB0aGUgZGF0YSBiZWluZyB0cmFuc3BvcnRlZCBi ZXR3ZWVuIHRoZSBwb29sIG1hbmFnZXIgYW5kIHBvb2wgZWxlbWVudHMgYXJlIHRhZ2dlZCAod2hl dGhlciB0aGV5J3JlIFRMVnMsIEpTT04sIEFTTi4xIC0NCndoYXRldmVyISkgaXQgYWxsb3dzIGZv ciBmdXR1cmUgZXh0ZW5zaWJpbGl0eSByZWxhdGVkIHRvIHN0YXRlIGNvbnZleWFuY2UsIHNob3Vs ZCB0aGUgbmVlZCBhcmlzZS4gIFRoYXQgaXMgdG8gc2F5LCBJIHRoaW5rIHdlJ3JlIGluIGdvb2Qg c2hhcGUgaW4gdGVybXMgb2Ygbm90IGNsb3Npbmcgb2ZmIHRoZSBwb3NzaWJpbGl0eSBvZiBmdXR1 cmUgd29yay4NCg0KTWVsaW5kYQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0Kdm5mcG9vbCBtYWlsaW5nIGxpc3QNCnZuZnBvb2xAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdm5mcG9vbA0K From nobody Thu Jul 24 10:11:15 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4971A0444 for ; Thu, 24 Jul 2014 10:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRkTaJOyCzgs for ; Thu, 24 Jul 2014 10:11:11 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D5151A0503 for ; Thu, 24 Jul 2014 10:11:09 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id la4so5425803vcb.33 for ; Thu, 24 Jul 2014 10:11:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=QE0LgR6gqKG1T1gFU56FS3+MGUHCvIr+pTHBGh8plIQ=; b=e8HJtn+xavUxXo+hdCsiERRW71/EN/kHOGafgAIkfYBwf8U2B+tgiEBmvIb2d7Cpfc TKhDItk0SoQJp3Fjt1AxnBZ1hv+K4d/ImjI+2iu90kzvICUlUR6nUF4B7zkiOppbE2Mq MrVsLw93OfKnSFYN/u8VEoemSgF1WtlpCYyXC7n9xxUmxYbyEfUpZiFpu5czDA/Sptj/ Zo9fTi37hXPHjq51WWDnzoXpV2pPqSiP1EOowWF+NJ+Dzj1tHsudk/vb9j7luYAW28uC B94E7v+LRlYh/k6Ld4mo9A1tZDd6q3KMv/Ocok5X+lPvU/7WKAx7eQGk36Fr59NXfBaX ME1w== MIME-Version: 1.0 X-Received: by 10.220.1.198 with SMTP id 6mr14226638vcg.31.1406221868121; Thu, 24 Jul 2014 10:11:08 -0700 (PDT) Sender: yang.r.yang@gmail.com Received: by 10.58.133.11 with HTTP; Thu, 24 Jul 2014 10:11:08 -0700 (PDT) In-Reply-To: <53D11BF6.2080901@gmail.com> References: <53CEC61A.9010104@gmail.com> <53D0E5F1.9060503@gmail.com> <53D11BF6.2080901@gmail.com> Date: Thu, 24 Jul 2014 13:11:08 -0400 X-Google-Sender-Auth: 0qHmzEt_cvieaaOfnI9-9GymTJI Message-ID: From: "Y. Richard Yang" To: Melinda Shore Content-Type: multipart/alternative; boundary=001a11c3cef2ecc55f04fef38a66 Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/XK2LrZER_0MdSe6l3KdkOwXmrHc Cc: "vnfpool@ietf.org" , "mls.ietf@gmail.com" Subject: Re: [vnfpool] Follow-up question from the BOF X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 17:11:12 -0000 --001a11c3cef2ecc55f04fef38a66 Content-Type: text/plain; charset=UTF-8 Hi Melinda, On Thu, Jul 24, 2014 at 10:45 AM, Melinda Shore wrote: > Hi, folks: > > We're in complete agreement about interoperability between > pool managers and pool elements from different vendors, and > that's already implicit in the charter (it's why we're > talking about standardizing a pooling protocol). So, on that > front I think we're good. It's probably premature to be > talking about protocol specifics but if we assume that the > data being transported between the pool manager and pool > elements are tagged (whether they're TLVs, JSON, ASN.1 - > whatever!) it allows for future extensibility related to > state conveyance, should the need arise. The road map I see is that the initial tagging of state will be (NF, vendor) specific, to allow both vendor innovation and more standard controller-NF interaction. If good progress is made and an agreement/convergence is achieved, for some NFs, it might become only NF. > That is to say, > I think we're in good shape in terms of not closing off the > possibility of future work. > > My personal suggestion is to include generic state management in scope. I see good progress in this space already, and it is time for transfer. This will substantially increase the usability and timeliness of the proposed work. The plenary last night talked about more timeliness of IETF work. This comment is in that spirit. Cheers, Richard > Melinda --001a11c3cef2ecc55f04fef38a66 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Melinda,

On Thu, Jul 24, 2014 at 10:45 AM, Melinda Shore <melinda.= shore@gmail.com> wrote:
Hi, folks:

We're in complete agreement about interoperability between
pool managers and pool elements from different vendors, and
that's already implicit in the charter (it's why we're
talking about standardizing a pooling protocol). =C2=A0So, on that
front I think we're good. =C2=A0It's probably premature to be
talking about protocol specifics but if we assume that the
data being transported between the pool manager and pool
elements are tagged (whether they're TLVs, JSON, ASN.1 -
whatever!) it allows for future extensibility related to
state conveyance, should the need arise. =C2=A0

=
The road map I see is that the initial tagging of state will be (NF, v= endor) specific, to allow both vendor innovation and more standard controll= er-NF interaction. If good progress is made and an agreement/convergence is= achieved, for some NFs, it might become only NF.
=C2=A0
That is to say,
I think we're in good shape in terms of not closing off the
possibility of future work.<= br>

My personal suggestion i= s to include generic state management in scope. I see good progress in this= space already, and it is time for transfer. This will substantially increa= se the usability and timeliness of the proposed work. The plenary last nigh= t talked about more timeliness of IETF work. This comment is in that spirit= .

Cheers,

Richard
=C2= =A0
Melinda
--001a11c3cef2ecc55f04fef38a66-- From nobody Fri Jul 25 15:13:08 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD8E91A03BB for ; Fri, 25 Jul 2014 15:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OW05tdwBpC3X for ; Fri, 25 Jul 2014 15:13:05 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BDE81A037C for ; Fri, 25 Jul 2014 15:13:04 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6PMD2iH008227 for ; Fri, 25 Jul 2014 23:13:02 +0100 Received: from 950129200 ([206.47.221.210]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6PMD0OC008215 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 25 Jul 2014 23:13:02 +0100 From: "Adrian Farrel" To: Date: Fri, 25 Jul 2014 23:13:04 +0100 Message-ID: <06be01cfa855$9bd1acd0$d3750670$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+oVZenuSdQzK7FTsCQOip43tv5ww== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20840.003 X-TM-AS-Result: No--5.685-10.0-31-10 X-imss-scan-details: No--5.685-10.0-31-10 X-TMASE-MatchedRID: jsxUPcGNVV7/TZdFgL/x66/CFdNrq+rVk9atiES99p2jdLyRE42E9mlF 7OhYLlctyKzYuAfVtMKib2Eymq9o7s1ybZtba3mcVtZNMIeE5PGrDPxf3LbqpE+0uGVOF08QIvE 3uA6qAEytWNmeiSi8s030aT0AOD6cbCKCT8RVQPoS7luGt6tlhiH2Y0Xxk8nYi2g8XzxCDfv9z+ z1eRqf0GntCa/pSQHPu9+soTfTMPe68Mln9Nwu0+J28KqpjndpZijLrBI/sgUgUEQTkIWiYllzo 9zSKaiK8Z+lsw1JOq8fZdczzDm/ur9ZdlL8eonaC24oEZ6SpSlsZUSYh+N/e7eO0FxOLtFrEFYy 4g7QN9l7KfldF9zaRuflAoHi2EDKNg3tecCMDvk= Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/9q6dr4RedbzM8CJQ99TYJy3Q_08 Subject: [vnfpool] State management X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 22:13:06 -0000 Hi, I completely understand why people want to work on state management: it = is a hugely interesting and hard problem, and a lot of fun. But... - Learn to walk before you try to run - Not doing state management in the first pass at IETF work on this = topic does not preclude doing the research in your own labs and bring the ideas to the IETF - Draw a distinction between learned/derived state and programmed state. The former is complex to synchronise. The latter is centrally = controlled and easy to synchronise/manage. I would argue the latter is automagically = in scope, but is not really "synchronisation", just parallel = configuration. - Don't assume that you can derive a generic solution for synchronising=20 dynamic state across a whole set of different classes of virtual = functions. And lastly, the question Martin asked interests me: "Why do people are not convinced that the technical problem is = solveable?" The answer so far seems to be to a different question (e.g. "What else = would you like to see in scope to make the problem interesting or more = applicable to your deployment models?"). It is fine to answer that = question and discuss the charter (although in my opinion trying to put = state synchronisation in from day one will completely turn this from a = real problem for rapid deployment into a research topic for many years). = I would *really* like to hear whether there is an answer to Martin's = question, or did the people who hummed also hum to the wrong question? Thanks, Adrian From nobody Fri Jul 25 17:51:21 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8F11A0AEF for ; Fri, 25 Jul 2014 17:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxcG_BVB_Qsw for ; Fri, 25 Jul 2014 17:51:16 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 341011A0AF2 for ; Fri, 25 Jul 2014 17:51:16 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id la4so8280924vcb.5 for ; Fri, 25 Jul 2014 17:51:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=uNbdP5fwzkxPl2ToT1lBHB291wYGoB5LDkBqt6aAnrE=; b=FXs0/K+c+g0camFqfVHzqTSNnj4PIvjzA80mLZ4y6eCTuiC0E88R29KiQ6ttFnQlQS wC14nyOVrgZfaQDF53rfX8IGCIEp/qad5zsIK5lXpZjxUxW4Z73eIKqsoCl6PZ+ggy7A /nxp6zWujaqXJ6GWKxpTkhcgv2BzD/WEd61zuQtPw47azGnBV+vhYIpuXDLVM49aGoag a1JQBHopa1xnq3ZSGA+mGcHR4+ugPGyy6K4ONKhXUMsWRevao+VSkBC2pn5nrrfPulVO KouVcRUOG46bt7RShmLyeUDHvKqXtgW7FEhCDKKmnprogocf4cdlF621wol1z5iguiMr StDA== MIME-Version: 1.0 X-Received: by 10.52.28.231 with SMTP id e7mr5576593vdh.55.1406335875148; Fri, 25 Jul 2014 17:51:15 -0700 (PDT) Sender: yang.r.yang@gmail.com Received: by 10.58.133.11 with HTTP; Fri, 25 Jul 2014 17:51:15 -0700 (PDT) Received: by 10.58.133.11 with HTTP; Fri, 25 Jul 2014 17:51:15 -0700 (PDT) In-Reply-To: <06be01cfa855$9bd1acd0$d3750670$@olddog.co.uk> References: <06be01cfa855$9bd1acd0$d3750670$@olddog.co.uk> Date: Fri, 25 Jul 2014 20:51:15 -0400 X-Google-Sender-Auth: 84BsyKTM5Ky7cyJbJZmfO9YMerM Message-ID: From: "Y. Richard Yang" To: adrian@olddog.co.uk Content-Type: multipart/alternative; boundary=20cf307c9ee645f33504ff0e162b Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/625uBR5cJIHBW69DXP3BwSq8dE4 Cc: vnfpool@ietf.org Subject: Re: [vnfpool] State management X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 00:51:18 -0000 --20cf307c9ee645f33504ff0e162b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Adrian, In my view, without state management, the vnfpool problem is hardly solvable, i.e., reaching a usable goal. Hence, it is my attempt to understand the "puzzle" posted by Martin. IETF prefers real use case droven design. What is a use case with reasonable SLA but no dynamic state? Static Web proxies? Even in this case, the controller has dynamic state. Hence, my view is that we need to consider state management up front, to make sure it is not the case that we are learning walking on the ground, but the goal is swimming in the water :-=EF=BC=89 Regarding considering that state will turn into research. This is a valid convern. My feeling is that both industry and academia have made good progress on generic solutions. I support the formation of the proposed WG so that it checks out solutions such as Zookeeper and merge/split, which provide good examples of generic mechanisms/abstraction, considering state. In other words, I am slightly more optimistic here in that IETF can jump in, adopt the progress already made, and make an impact on a real problem that IETF has more expertise =EF=BC=88i.e., VNF=EF=BC=89. Just my 2 cents. And I am also looking forward to others sharing aspects. Richard Hi, I completely understand why people want to work on state management: it is a hugely interesting and hard problem, and a lot of fun. But... - Learn to walk before you try to run - Not doing state management in the first pass at IETF work on this topic does not preclude doing the research in your own labs and bring the ideas to the IETF - Draw a distinction between learned/derived state and programmed state. The former is complex to synchronise. The latter is centrally controlled and easy to synchronise/manage. I would argue the latter is automagically in scope, but is not really "synchronisation", just parallel configuration. - Don't assume that you can derive a generic solution for synchronising dynamic state across a whole set of different classes of virtual functions. And lastly, the question Martin asked interests me: "Why do people are not convinced that the technical problem is solveable?" The answer so far seems to be to a different question (e.g. "What else would you like to see in scope to make the problem interesting or more applicable to your deployment models?"). It is fine to answer that question and discuss the charter (although in my opinion trying to put state synchronisation in from day one will completely turn this from a real problem for rapid deployment into a research topic for many years). I would *really* like to hear whether there is an answer to Martin's question, or did the people who hummed also hum to the wrong question? Thanks, Adrian _______________________________________________ vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool --20cf307c9ee645f33504ff0e162b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Adrian,

In my view, without state management, the vnfpool problem is= hardly solvable, i.e., reaching a usable goal. Hence, it is my attempt to = understand the "puzzle" posted by Martin. IETF prefers real use c= ase droven design. What is a use case with reasonable SLA but no dynamic st= ate? Static Web proxies? Even in this case, the controller has dynamic stat= e. Hence, my view is that we need to consider state management up front, to= make sure it is not the case that we are learning walking on the ground,= =C2=A0 but the goal is swimming in the water :-=EF=BC=89

Regarding considering that state will turn into research. Th= is is a valid convern. My feeling is that both industry and academia have m= ade good progress on generic solutions. I support the formation of the prop= osed WG so that it checks out solutions such as Zookeeper and merge/split, = which provide good examples of generic mechanisms/abstraction, considering = state. In other words, I am slightly more optimistic here in that IETF can = jump in, adopt the progress already made, and make an impact on a real prob= lem that IETF has more expertise =EF=BC=88i.e., VNF=EF=BC=89.

Just my 2 cents. And I am also looking forward to others sha= ring aspects.

Richard

Hi,

I completely understand why people want to work on state management: it is = a hugely interesting and hard problem, and a lot of fun. But...

- Learn to walk before you try to run
- Not doing state management in the first pass at IETF work on this topic =C2=A0 =C2=A0does not preclude doing the research in your own labs and brin= g the
=C2=A0 =C2=A0ideas to the IETF
- Draw a distinction between learned/derived state and programmed state. =C2=A0 =C2=A0The former is complex to synchronise. The latter is centrally = controlled and
=C2=A0 =C2=A0easy to synchronise/manage. I would argue the latter is automa= gically in
=C2=A0 =C2=A0scope, but is not really "synchronisation", just par= allel configuration.
- Don't assume that you can derive a generic solution for synchronising=
=C2=A0 =C2=A0dynamic state across a whole set of different classes of virtu= al functions.

And lastly, the question Martin asked interests me:

"Why do people are not convinced that the technical problem is solveab= le?"

The answer so far seems to be to a different question (e.g. "What else= would you like to see in scope to make the problem interesting or more app= licable to your deployment models?"). It is fine to answer that questi= on and discuss the charter (although in my opinion trying to put state sync= hronisation in from day one will completely turn this from a real problem f= or rapid deployment into a research topic for many years). I would *really*= like to hear whether there is an answer to Martin's question, or did t= he people who hummed also hum to the wrong question?

Thanks,
Adrian


_______________________________________________
vnfpool mailing list
vnfpool@ietf.org
https://www.ietf.org/mailman/listinfo/vnfpool
--20cf307c9ee645f33504ff0e162b-- From nobody Fri Jul 25 18:26:18 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8931AD6B0 for ; Fri, 25 Jul 2014 18:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kl4fFLUGb6p for ; Fri, 25 Jul 2014 18:26:15 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D6DB1AC0D2 for ; Fri, 25 Jul 2014 18:26:15 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id x48so4944211wes.19 for ; Fri, 25 Jul 2014 18:26:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=2xvEFpfTs2+ZGI1VM8pdQ+RRSFzSzYN7Q2B1upR3IeY=; b=h/ciw9Fi7+FGeMfpO6abV94tM5gadqi6g4hPDSJbvxiLUbsYLtmVj93ivn4VRDNy5N CjHSvMForVk85d+qHRGMokQ3OHT48Lwqs7NKjCuJMya7Vg0YlHlrIlUP8qTsdmDGjuGi E7E5yONa7ycX9GDYTlhSGNkQ5Z8cXmFbSRGxUvVhMmJzwtPHF7Gl59za2M/bPW8PPxw7 pj0LHywP7RcuWRt7VJo33PEhYYpEV4WUrLyggbFGaDOlUYghXZBKsbV+lvGhC+CNXSsF pFsOKUN3ICr9z8TCdQTtZyh0RQMQfXoeKtt29AL8tTZ7+kWM+EhoFieSHuZPQDrEA376 0rsw== X-Received: by 10.180.39.73 with SMTP id n9mr9872377wik.70.1406337973781; Fri, 25 Jul 2014 18:26:13 -0700 (PDT) Received: from Melindas-MacBook-Pro.local ([206.47.221.210]) by mx.google.com with ESMTPSA id nc19sm1726456wic.4.2014.07.25.18.26.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jul 2014 18:26:13 -0700 (PDT) Message-ID: <53D303B3.4030205@gmail.com> Date: Fri, 25 Jul 2014 21:26:11 -0400 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Y. Richard Yang" , adrian@olddog.co.uk References: <06be01cfa855$9bd1acd0$d3750670$@olddog.co.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/jSHB4fo9gofvEEJPxOgpIP7oTts Cc: vnfpool@ietf.org Subject: Re: [vnfpool] State management X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 01:26:17 -0000 On 7/25/14, 8:51 PM, Y. Richard Yang wrote: > In my view, without state management, the vnfpool problem is hardly > solvable, i.e., reaching a usable goal. Hence, it is my attempt to > understand the "puzzle" posted by Martin. IETF prefers real use case > droven design. I'd argue that while it may be the case, the piece that's missing here, I think, is that the IETF prefers problems to be broken down into solvable chunks. State management is necessarily application-specific, while what we've been trying to work on is a common substrate that can be used to carry application-specific state. So, for the time being, the substrate would be in-scope and the application state would be out-of-scope, whether it would be handled by a rechartered vnfpool or a separate working group (or working groups). There's certainly precedent for this sort of approach - for example nsis, MPLS, and others. One of the things that concerns me, as someone who'd like to see the work progress, is that those who are insisting that this is an atomic problem seem also to effectively be arguing against a modular approach to designing a solution. And frankly I'm somewhat dismayed by that. Melinda From nobody Fri Jul 25 18:49:20 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D63E1A0049 for ; Fri, 25 Jul 2014 18:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGW71m-6wyqV for ; Fri, 25 Jul 2014 18:49:16 -0700 (PDT) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA77B1A0048 for ; Fri, 25 Jul 2014 18:49:15 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id hu12so8430938vcb.20 for ; Fri, 25 Jul 2014 18:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=mtVX+W6q1NgfJEgmtu2XkOUmAYO0saMziTdFrxZeA3c=; b=ojPzEujuEEK0Wmx55WczIo4M9UmcKWyBp4Fb/SI7H8xGsZgDy2rM81O4H3StikTni/ oxn/xtuXJmTm7sNaUlRu7/D+TBTR05CxuNEeToNCcbRyaQbf3KIx6r0a3XUvIIULUivQ QA2SgvVHjFmKHvexa5jb2eLJH3kR+X/Pxa2ZTQKbJmWmVsSrcEHZD/2QcHzZCHpQCdf7 BEIE2PSzpV2CJh1zKwrVGFy9DbOI2tms5fsODRlFGSjPILJvOeyNzHlrsBUtHneQqbYs vF7PQwpcFhegKDyYOioKn+cNyeYziFnhWFqvYfQUEaPnCh+GGgjtRnlw6aUTXGI+V8DE H1dw== MIME-Version: 1.0 X-Received: by 10.53.13.200 with SMTP id fa8mr5878752vdd.57.1406339355043; Fri, 25 Jul 2014 18:49:15 -0700 (PDT) Sender: yang.r.yang@gmail.com Received: by 10.58.133.11 with HTTP; Fri, 25 Jul 2014 18:49:14 -0700 (PDT) Received: by 10.58.133.11 with HTTP; Fri, 25 Jul 2014 18:49:14 -0700 (PDT) In-Reply-To: <53D303B3.4030205@gmail.com> References: <06be01cfa855$9bd1acd0$d3750670$@olddog.co.uk> <53D303B3.4030205@gmail.com> Date: Fri, 25 Jul 2014 21:49:14 -0400 X-Google-Sender-Auth: IFwGUzXZKR9fJKl2TztDFENWyi4 Message-ID: From: "Y. Richard Yang" To: Melinda Shore Content-Type: multipart/alternative; boundary=001a1134a1dab0ef4c04ff0ee519 Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/C2C8oDOX1RVkcY7odBns7vzA-as Cc: vnfpool@ietf.org, adrian@olddog.co.uk Subject: Re: [vnfpool] State management X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 01:49:17 -0000 --001a1134a1dab0ef4c04ff0ee519 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Melinda, Not sure why you got the impression of these people arguing against a modular. I do not. I strongly support. Go back to industry practice. Zookeeper (Google) uses a single unifying mechanism =EF=BC=88its special file system abstraction=EF=BC=89to handle in= stance registration, instance keep alive, state sync, etc. A great design! Given that the initial purpose of the WG appears to be gap analysis, according to my understanding, I feel that leaving state sync, arguably a key piece, out of scope, is not ideal. If the concern is that design is hard, gap analysis may be not. This will make your WG work more valuable. Make sense? I am taking off now, and may be quiet for a while. I certainly hope the proposed work (and adding one more item: state gap analysis) be approved. Cheers, Richard On Jul 25, 2014 9:26 PM, "Melinda Shore" wrote: > On 7/25/14, 8:51 PM, Y. Richard Yang wrote: > >> In my view, without state management, the vnfpool problem is hardly >> solvable, i.e., reaching a usable goal. Hence, it is my attempt to >> understand the "puzzle" posted by Martin. IETF prefers real use case >> droven design. >> > > I'd argue that while it may be the case, the piece that's > missing here, I think, is that the IETF prefers problems > to be broken down into solvable chunks. State management > is necessarily application-specific, while what we've been > trying to work on is a common substrate that can be used > to carry application-specific state. So, for the time being, > the substrate would be in-scope and the application state > would be out-of-scope, whether it would be handled by a > rechartered vnfpool or a separate working group (or > working groups). There's certainly precedent for this > sort of approach - for example nsis, MPLS, and others. > One of the things that concerns me, as someone who'd like > to see the work progress, is that those who are insisting > that this is an atomic problem seem also to effectively be > arguing against a modular approach to designing a solution. > And frankly I'm somewhat dismayed by that. > > Melinda > > _______________________________________________ > vnfpool mailing list > vnfpool@ietf.org > https://www.ietf.org/mailman/listinfo/vnfpool > --001a1134a1dab0ef4c04ff0ee519 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Melinda,

Not sure why you got the impression of these people arguing = against a modular. I do not. I strongly support.

Go back to industry practice. Zookeeper (Google) uses a sing= le unifying mechanism =EF=BC=88its special file system abstraction=EF=BC=89= to handle instance registration, instance keep alive, state sync, etc. A gr= eat design!

Given that the initial purpose of the WG appears to be gap a= nalysis, according to my understanding, I feel that leaving state sync, arg= uably a key piece, out of scope, is not ideal.=C2=A0 If the concern is that= design is hard, gap analysis may be not. This will make your WG work more = valuable. Make sense?

I am taking off now, and may be quiet for a while. I certain= ly hope the proposed work (and adding one more item: state gap analysis) be= approved.

Cheers,

Richard

On Jul 25, 2014 9:26 PM, "Melinda Shore&quo= t; <melinda.shore@gmail.com> wrote:
On 7/25/14, 8:51 PM, Y. Richard Yang wrote:
In my view, without state management, the vnfpool problem is hardly
solvable, i.e., reaching a usable goal. Hence, it is my attempt to
understand the "puzzle" posted by Martin. IETF prefers real use c= ase
droven design.

I'd argue that while it may be the case, the piece that's
missing here, I think, is that the IETF prefers problems
to be broken down into solvable chunks. =C2=A0State management
is necessarily application-specific, while what we've been
trying to work on is a common substrate that can be used
to carry application-specific state. =C2=A0So, for the time being,
the substrate would be in-scope and the application state
would be out-of-scope, whether it would be handled by a
rechartered vnfpool or a separate working group (or
working groups). =C2=A0There's certainly precedent for this
sort of approach - for example nsis, MPLS, and others.
One of the things that concerns me, as someone who'd like
to see the work progress, is that those who are insisting
that this is an atomic problem seem also to effectively be
arguing against a modular approach to designing a solution.
And frankly I'm somewhat dismayed by that.

Melinda

_______________________________________________
vnfpool mailing list
vnfpool@ietf.org<= br> https://www.ietf.org/mailman/listinfo/vnfpool
--001a1134a1dab0ef4c04ff0ee519-- From nobody Sat Jul 26 05:03:43 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E181ABB34 for ; Sat, 26 Jul 2014 05:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NP4f96IQWvtQ for ; Sat, 26 Jul 2014 05:03:39 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id C8EAA1ABB31 for ; Sat, 26 Jul 2014 05:03:38 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Melinda Shore'" , "'Y. Richard Yang'" , References: <06be01cfa855$9bd1acd0$d3750670$@olddog.co.uk> <53D303B3.4030205@gmail.com> In-Reply-To: <53D303B3.4030205@gmail.com> Date: Sat, 26 Jul 2014 08:03:34 -0400 Message-ID: <002101cfa8c9$a07be240$e173a6c0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQGHQjPlgyd5Ecxjxu96RYI796ioAQJLDE0NAWzhk3ucJU890A== X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/Nxizm0hVZ1Ya6afDbH0lWS5TTEE Cc: vnfpool@ietf.org Subject: Re: [vnfpool] State management X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 12:03:40 -0000 Melinda: A modular solution is key to the success of the VNF Pool work. Thank you for reminding us of this fact. Sue -----Original Message----- From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Melinda Shore Sent: Friday, July 25, 2014 9:26 PM To: Y. Richard Yang; adrian@olddog.co.uk Cc: vnfpool@ietf.org Subject: Re: [vnfpool] State management On 7/25/14, 8:51 PM, Y. Richard Yang wrote: > In my view, without state management, the vnfpool problem is hardly > solvable, i.e., reaching a usable goal. Hence, it is my attempt to > understand the "puzzle" posted by Martin. IETF prefers real use case > droven design. I'd argue that while it may be the case, the piece that's missing here, I think, is that the IETF prefers problems to be broken down into solvable chunks. State management is necessarily application-specific, while what we've been trying to work on is a common substrate that can be used to carry application-specific state. So, for the time being, the substrate would be in-scope and the application state would be out-of-scope, whether it would be handled by a rechartered vnfpool or a separate working group (or working groups). There's certainly precedent for this sort of approach - for example nsis, MPLS, and others. One of the things that concerns me, as someone who'd like to see the work progress, is that those who are insisting that this is an atomic problem seem also to effectively be arguing against a modular approach to designing a solution. And frankly I'm somewhat dismayed by that. Melinda _______________________________________________ vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool From nobody Sun Jul 27 23:01:41 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2791A005C for ; Sun, 27 Jul 2014 23:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8qCPYsRWwrG for ; Sun, 27 Jul 2014 23:01:25 -0700 (PDT) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0ECE1A0233 for ; Sun, 27 Jul 2014 23:01:22 -0700 (PDT) Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2CB41370093 for ; Mon, 28 Jul 2014 08:01:19 +0200 (CEST) Received: from ESTGVMSP106.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtptc.telefonica.com (Postfix) with ESMTPS id 0F51837008F for ; Mon, 28 Jul 2014 08:01:19 +0200 (CEST) Received: from ESTGVMSP209.EUROPE.telefonica.corp ([fe80::b818:3976:1351:7896]) by ESTGVMSP106.EUROPE.telefonica.corp ([fe80::18d2:792c:5932:894c%16]) with mapi id 14.03.0146.002; Mon, 28 Jul 2014 08:01:18 +0200 From: PEDRO ANDRES ARANDA GUTIERREZ To: "vnfpool@ietf.org" Thread-Topic: [vnfpool] State management Thread-Index: Ac+oVZenuSdQzK7FTsCQOip43tv5wwB07heA Date: Mon, 28 Jul 2014 06:01:17 +0000 Message-ID: References: <06be01cfa855$9bd1acd0$d3750670$@olddog.co.uk> In-Reply-To: <06be01cfa855$9bd1acd0$d3750670$@olddog.co.uk> Accept-Language: es-ES, es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.92.4.9] Content-Type: text/plain; charset="utf-8" Content-ID: <46C7EF03FDA0EA44A771A98A4C1D9290@telefonica.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/Hw6D7xqaQxJNQnvvuWG8obRTRSk Subject: Re: [vnfpool] State management X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 06:01:37 -0000 KzENClBTOiBwbGVhc2Ugbm90ZSBteSBuZXcgZW1haWwgYWRkcmVzcyBiZWxvdy4gTWFpbHMgdG8g bXkgb2xkIGVtYWlscyBAdGlkLmVzDQp3aWxsIG9ubHkgYmUgZm9yd2FyZGVkIGZvciBhIGxpbWl0 ZWQgcGVyaW9kIG9mIHRpbWUNCi0tLQ0KRHIuIFBlZHJvIEEuIEFyYW5kYSBHdXRpw6lycmV6DQoN ClRlY2hub2xvZ3kgRXhwbG9yYXRpb24gLQ0KTmV0d29yayBJbm5vdmF0aW9uICYgVmlydHVhbGlz YXRpb24NCg0KbWFpbHRvOnBlZHJvYS5hcmFuZGFAdCA8bWFpbHRvOnBhYWdAdGlkLmVzPmVsZWZv bmljYS5jb20NClRlbGVmw7NuaWNhLCBJbnZlc3RpZ2FjacOzbiB5IERlc2Fycm9sbG8NCkMvIEQu IFJhbcOzbiBkZSBsYSBDcnV6LDg0DQoyODAwNiBNYWRyaWQsIFNwYWluDQoNCkZyYWdlbiBzaW5k IG5pY2h0IGRhLCB1bSBiZWFudHdvcnRldCB6dSB3ZXJkZW4uDQpGcmFnZW4gc2luZCBkYSwgdW0g Z2VzdGVsbHQgenUgd2VyZGVuLg0KR2VvcmcgS3JlaXNsZXINCg0KDQoNCg0KDQpFbCAyNi8wNy8x NCAwMDoxMywgIkFkcmlhbiBGYXJyZWwiIDxhZHJpYW5Ab2xkZG9nLmNvLnVrPiBlc2NyaWJpw7M6 DQoNCj5IaSwNCj4NCj5JIGNvbXBsZXRlbHkgdW5kZXJzdGFuZCB3aHkgcGVvcGxlIHdhbnQgdG8g d29yayBvbiBzdGF0ZSBtYW5hZ2VtZW50OiBpdA0KPmlzIGEgaHVnZWx5IGludGVyZXN0aW5nIGFu ZCBoYXJkIHByb2JsZW0sIGFuZCBhIGxvdCBvZiBmdW4uIEJ1dC4uLg0KPg0KPi0gTGVhcm4gdG8g d2FsayBiZWZvcmUgeW91IHRyeSB0byBydW4NCj4tIE5vdCBkb2luZyBzdGF0ZSBtYW5hZ2VtZW50 IGluIHRoZSBmaXJzdCBwYXNzIGF0IElFVEYgd29yayBvbiB0aGlzIHRvcGljDQo+ICAgZG9lcyBu b3QgcHJlY2x1ZGUgZG9pbmcgdGhlIHJlc2VhcmNoIGluIHlvdXIgb3duIGxhYnMgYW5kIGJyaW5n IHRoZQ0KPiAgIGlkZWFzIHRvIHRoZSBJRVRGDQo+LSBEcmF3IGEgZGlzdGluY3Rpb24gYmV0d2Vl biBsZWFybmVkL2Rlcml2ZWQgc3RhdGUgYW5kIHByb2dyYW1tZWQgc3RhdGUuDQo+ICAgVGhlIGZv cm1lciBpcyBjb21wbGV4IHRvIHN5bmNocm9uaXNlLiBUaGUgbGF0dGVyIGlzIGNlbnRyYWxseQ0K PmNvbnRyb2xsZWQgYW5kDQo+ICAgZWFzeSB0byBzeW5jaHJvbmlzZS9tYW5hZ2UuIEkgd291bGQg YXJndWUgdGhlIGxhdHRlciBpcyBhdXRvbWFnaWNhbGx5DQo+aW4NCj4gICBzY29wZSwgYnV0IGlz IG5vdCByZWFsbHkgInN5bmNocm9uaXNhdGlvbiIsIGp1c3QgcGFyYWxsZWwNCj5jb25maWd1cmF0 aW9uLg0KPi0gRG9uJ3QgYXNzdW1lIHRoYXQgeW91IGNhbiBkZXJpdmUgYSBnZW5lcmljIHNvbHV0 aW9uIGZvciBzeW5jaHJvbmlzaW5nDQo+ICAgZHluYW1pYyBzdGF0ZSBhY3Jvc3MgYSB3aG9sZSBz ZXQgb2YgZGlmZmVyZW50IGNsYXNzZXMgb2YgdmlydHVhbA0KPmZ1bmN0aW9ucy4NCj4NCj5BbmQg bGFzdGx5LCB0aGUgcXVlc3Rpb24gTWFydGluIGFza2VkIGludGVyZXN0cyBtZToNCj4NCj4iV2h5 IGRvIHBlb3BsZSBhcmUgbm90IGNvbnZpbmNlZCB0aGF0IHRoZSB0ZWNobmljYWwgcHJvYmxlbSBp cyBzb2x2ZWFibGU/Ig0KPg0KPlRoZSBhbnN3ZXIgc28gZmFyIHNlZW1zIHRvIGJlIHRvIGEgZGlm ZmVyZW50IHF1ZXN0aW9uIChlLmcuICJXaGF0IGVsc2UNCj53b3VsZCB5b3UgbGlrZSB0byBzZWUg aW4gc2NvcGUgdG8gbWFrZSB0aGUgcHJvYmxlbSBpbnRlcmVzdGluZyBvciBtb3JlDQo+YXBwbGlj YWJsZSB0byB5b3VyIGRlcGxveW1lbnQgbW9kZWxzPyIpLiBJdCBpcyBmaW5lIHRvIGFuc3dlciB0 aGF0DQo+cXVlc3Rpb24gYW5kIGRpc2N1c3MgdGhlIGNoYXJ0ZXIgKGFsdGhvdWdoIGluIG15IG9w aW5pb24gdHJ5aW5nIHRvIHB1dA0KPnN0YXRlIHN5bmNocm9uaXNhdGlvbiBpbiBmcm9tIGRheSBv bmUgd2lsbCBjb21wbGV0ZWx5IHR1cm4gdGhpcyBmcm9tIGENCj5yZWFsIHByb2JsZW0gZm9yIHJh cGlkIGRlcGxveW1lbnQgaW50byBhIHJlc2VhcmNoIHRvcGljIGZvciBtYW55IHllYXJzKS4NCj5J IHdvdWxkICpyZWFsbHkqIGxpa2UgdG8gaGVhciB3aGV0aGVyIHRoZXJlIGlzIGFuIGFuc3dlciB0 byBNYXJ0aW4ncw0KPnF1ZXN0aW9uLCBvciBkaWQgdGhlIHBlb3BsZSB3aG8gaHVtbWVkIGFsc28g aHVtIHRvIHRoZSB3cm9uZyBxdWVzdGlvbj8NCj4NCj5UaGFua3MsDQo+QWRyaWFuDQo+DQo+DQo+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj52bmZwb29s IG1haWxpbmcgbGlzdA0KPnZuZnBvb2xAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3ZuZnBvb2wNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KDQpFc3RlIG1lbnNhamUgeSBzdXMgYWRqdW50b3Mgc2UgZGlyaWdlbiBleGNsdXNpdmFt ZW50ZSBhIHN1IGRlc3RpbmF0YXJpbywgcHVlZGUgY29udGVuZXIgaW5mb3JtYWNpw7NuIHByaXZp bGVnaWFkYSBvIGNvbmZpZGVuY2lhbCB5IGVzIHBhcmEgdXNvIGV4Y2x1c2l2byBkZSBsYSBwZXJz b25hIG8gZW50aWRhZCBkZSBkZXN0aW5vLiBTaSBubyBlcyB1c3RlZC4gZWwgZGVzdGluYXRhcmlv IGluZGljYWRvLCBxdWVkYSBub3RpZmljYWRvIGRlIHF1ZSBsYSBsZWN0dXJhLCB1dGlsaXphY2nD s24sIGRpdnVsZ2FjacOzbiB5L28gY29waWEgc2luIGF1dG9yaXphY2nDs24gcHVlZGUgZXN0YXIg cHJvaGliaWRhIGVuIHZpcnR1ZCBkZSBsYSBsZWdpc2xhY2nDs24gdmlnZW50ZS4gU2kgaGEgcmVj aWJpZG8gZXN0ZSBtZW5zYWplIHBvciBlcnJvciwgbGUgcm9nYW1vcyBxdWUgbm9zIGxvIGNvbXVu aXF1ZSBpbm1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtaXNtYSB2w61hIHkgcHJvY2VkYSBhIHN1IGRl c3RydWNjacOzbi4NCg0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIHRyYW5zbWlz c2lvbiBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gaW50ZW5kZWQg b25seSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgbmFtZWQgYWJvdmUu IElmIHRoZSByZWFkZXIgb2YgdGhpcyBtZXNzYWdlIGlzIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0 cmlidXRpb24gb3IgY29weWluZyBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3RyaWN0bHkgcHJv aGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3Is IGRvIG5vdCByZWFkIGl0LiBQbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciB0 aGF0IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciBhbmQgdGhl biBkZWxldGUgaXQuDQoNCkVzdGEgbWVuc2FnZW0gZSBzZXVzIGFuZXhvcyBzZSBkaXJpZ2VtIGV4 Y2x1c2l2YW1lbnRlIGFvIHNldSBkZXN0aW5hdMOhcmlvLCBwb2RlIGNvbnRlciBpbmZvcm1hw6fD o28gcHJpdmlsZWdpYWRhIG91IGNvbmZpZGVuY2lhbCBlIMOpIHBhcmEgdXNvIGV4Y2x1c2l2byBk YSBwZXNzb2Egb3UgZW50aWRhZGUgZGUgZGVzdGluby4gU2UgbsOjbyDDqSB2b3NzYSBzZW5ob3Jp YSBvIGRlc3RpbmF0w6FyaW8gaW5kaWNhZG8sIGZpY2Egbm90aWZpY2FkbyBkZSBxdWUgYSBsZWl0 dXJhLCB1dGlsaXphw6fDo28sIGRpdnVsZ2HDp8OjbyBlL291IGPDs3BpYSBzZW0gYXV0b3JpemHD p8OjbyBwb2RlIGVzdGFyIHByb2liaWRhIGVtIHZpcnR1ZGUgZGEgbGVnaXNsYcOnw6NvIHZpZ2Vu dGUuIFNlIHJlY2ViZXUgZXN0YSBtZW5zYWdlbSBwb3IgZXJybywgcm9nYW1vcy1saGUgcXVlIG5v cyBvIGNvbXVuaXF1ZSBpbWVkaWF0YW1lbnRlIHBvciBlc3RhIG1lc21hIHZpYSBlIHByb2NlZGEg YSBzdWEgZGVzdHJ1acOnw6NvDQo= From nobody Tue Jul 29 01:31:23 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F210B1A0086 for ; Tue, 29 Jul 2014 01:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.901 X-Spam-Level: X-Spam-Status: No, score=-103.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id In_UAeUrg4At for ; Tue, 29 Jul 2014 01:31:13 -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 627921A00FA for ; Tue, 29 Jul 2014 01:31:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKQ43210; Tue, 29 Jul 2014 08:31:11 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 29 Jul 2014 09:31:08 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Tue, 29 Jul 2014 16:31:05 +0800 From: Zongning To: "Y. Richard Yang" , Melinda Shore Thread-Topic: [vnfpool] State management Thread-Index: Ac+oVZenuSdQzK7FTsCQOip43tv5w///phyAgAAJwoCAAAZxAP/6Xx7Q Date: Tue, 29 Jul 2014 08:31:04 +0000 Message-ID: References: <06be01cfa855$9bd1acd0$d3750670$@olddog.co.uk> <53D303B3.4030205@gmail.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.138.41.54] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC66677966176DEAnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/zyIy9VAATEhGPGmnCriuNkdJEc4 Cc: "vnfpool@ietf.org" , "adrian@olddog.co.uk" Subject: [vnfpool] =?utf-8?b?562U5aSNOiAgU3RhdGUgbWFuYWdlbWVudA==?= X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 08:31:21 -0000 --_000_B0D29E0424F2DE47A0B36779EC66677966176DEAnkgeml501mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIFJpY2hhcmQsIGFuZCBhbGwsDQoNCkkgZG9u4oCZdCBzZWUgYSBiaWcgZGlzcHV0ZSBpbiB5 b3VyIGNvbnZlcnNhdGlvbi4gV2UgZG9u4oCZdCBleGNsdWRlIHN0YXRlIG1hbmFnZW1lbnQgYXMg YSB3aG9sZS4gSWYgd2UgYWdyZWUgb24gYSBtb2R1bGFyIGFwcHJvYWNoLCB3ZSBjYW4gY2Fycnkg b24gb3VyIHdvcmsgc3RlcCBieSBzdGVwLg0KRmlyc3RseSBJIGFncmVlIHdpdGggQWRyaWFuIHRo YXQgd2Ugc2hvdWxkIGRyYXcgYSBkaXN0aW5jdGlvbiBiZXR3ZWVuIHRoZSBpbnRlcmZhY2UgYmV0 d2VlbiBwb29sIG1lbWJlcnMgZm9yIHN0YXRlIGRhdGEgdHJhbnNmZXIsIGFuZCB0aGUgaW50ZXJm YWNlIGJldHdlZW4gcG9vbCBtYW5hZ2VyIGFuZCBwb29sIG1lbWJlciBmb3Igc3RhdGUgbWFuYWdl bWVudC4gQWx0aG91Z2ggYm90aCB0aGVzZSB0d28gaW50ZXJmYWNlcyBhcmUgY2FsbGVkIOKAnHN0 YXRlIG1hbmFnZW1lbnTigJ0gaW4gZ2VuZXJhbCAtIGZyb20gbWFueSBwZW9wbGXigJlzIHBlcnNw ZWN0aXZlLCB0aGV5IGFyZSBxdWl0ZSBkaWZmZXJlbnQgaW4gbmF0dXJlLg0KVGhlIGZvcm1lciBp cyB2ZW5kb3Igc3BlY2lmaWMgYW5kIG9idmlvdXNseSBuZWVkcyBhZ3JlZW1lbnQgYW1vbmcgbXVs dGlwbGUgdmVuZG9ycyBpbiB0ZXJtcyBvZiBmYWlsb3ZlciAoYW5kIHN0YXRlIGRhdGEgdHJhbnNm ZXIpIGJldHdlZW4gVk5GcyBmcm9tIGRpZmZlcmVudCB2ZW5kb3JzLiBXZSBhcmUgbm90IGluIHN1 Y2ggc2l0dWF0aW9uIHlldCwgYnV0IHdpbGwgZW5jb3VyYWdlIHZlbmRvcnMgdG8gZGlzY3VzcyBh bmQgYnJpbmcgZ2FwIGFuYWx5c2lzIHRvIHNob3cgdGhlaXIgc3VwcG9ydCBvbiBpbnRlcm9wZXJh YmlsaXR5LiBTbyB5b3VyIHByb3Bvc2VkIHdvcmsgb2YgZ2FwIGFuYWx5c2lzIG9uIHN0YXRlIG1h bmFnZW1lbnQgaXMgYSBnb29kIGlkZWEuDQpUaGUgbGF0dGVyIGlzIGFjdHVhbGx5IGltcGxpY2l0 bHkgaW5jbHVkZWQgaW4gdGhlIGNoYXJ0ZXIsIHNlcnZpbmcgYXMgYSBjb21tb24gc3Vic3RyYXRl IGZvciBzdGF0ZSBtYW5hZ2VtZW50LiBXZSBhZ3JlZSB0aGF0IHN1Y2ggc3RhbmRhcmQgaW50ZXJm YWNlIGJldHdlZW4gcG9vbCBtYW5hZ2VyIGFuZCBwb29sIG1lbWJlcnMgYXJlIGltcG9ydGFudCBm b3IgZGVjb3VwbGVkIGlubm92YXRpb24gb2YgZGlmZmVyZW50IFZORiBhbmQgY29udHJvbGxlciBp bXBsZW1lbnRhdGlvbnMuIFRoaXMgaXNzdWUgaGFzIGJlZW4gY2xhcmlmaWVkIGluIGVhcmx5IGVt YWlsIGZyb20gTWVsaW5kYS4NCklNTywgdGhlIFZORiBwb29sIGlzIHVzYWJsZSBhbmQgdmFsdWFi bGUsIHByb3ZpZGVkIHRoZSBzdGFuZGFyZCBpbnRlcmZhY2UgYmV0d2VlbiBwb29sIG1hbmFnZXIg YW5kIHBvb2wgbWVtYmVycyBhcmUgd2VsbCBkZXNpZ25lZCwgdG8gYWxsb3cgZm9yIGludGVyb3Bl cmFiaWxpdHkgYmV0d2VlbiBwb29sIG1hbmFnZXIsIGFuZCBwb29sIG1lbWJlcnMgZnJvbSBkaWZm ZXJlbnQgdmVuZG9ycy4gVGhpcyBpcyBxdWl0ZSBkaWZmZXJlbnQgd2l0aCBhbnkgcHJvcHJpZXRh cnkgcG9vbGluZyBzb2x1dGlvbiBiYXNlZCBvbiBzaW5nbGUgdmVuZG9yIGltcGxlbWVudGF0aW9u LCBhbmQgaXMgdGhlIGtleSB2YWx1ZSB3ZSB3YW50IGJyaW5nIHZpYSBJRVRGLg0KDQpUaGUgcmVh bCBjb25jZXJuIGluIG15IG1pbmQgaXMgdGhhdCBzb21lb25lIG1heSBzdGlsbCB0aGluayB0aGF0 IHRoZSB3aG9sZSBWTkYgcG9vbCB3b27igJl0IHN1Y2NlZWQgd2l0aG91dCBvcGVuaW5nIHRoZSBp bnRlcmZhY2UgYmV0d2VlbiBwb29sIG1lbWJlcnMgZm9yIHN0YXRlIGRhdGEgdHJhbnNmZXIg4oCT IHdoaWNoIEkgc3Ryb25nbHkgZGlzYWdyZWUuDQoNClRoYW5rcy4NCg0KLU5pbmcNCg0K5Y+R5Lu2 5Lq6OiB2bmZwb29sIFttYWlsdG86dm5mcG9vbC1ib3VuY2VzQGlldGYub3JnXSDku6PooaggWS4g UmljaGFyZCBZYW5nDQrlj5HpgIHml7bpl7Q6IDIwMTTlubQ35pyIMjbml6UgOTo0OQ0K5pS25Lu2 5Lq6OiBNZWxpbmRhIFNob3JlDQrmioTpgIE6IHZuZnBvb2xAaWV0Zi5vcmc7IGFkcmlhbkBvbGRk b2cuY28udWsNCuS4u+mimDogUmU6IFt2bmZwb29sXSBTdGF0ZSBtYW5hZ2VtZW50DQoNCg0KSGkg TWVsaW5kYSwNCg0KTm90IHN1cmUgd2h5IHlvdSBnb3QgdGhlIGltcHJlc3Npb24gb2YgdGhlc2Ug cGVvcGxlIGFyZ3VpbmcgYWdhaW5zdCBhIG1vZHVsYXIuIEkgZG8gbm90LiBJIHN0cm9uZ2x5IHN1 cHBvcnQuDQoNCkdvIGJhY2sgdG8gaW5kdXN0cnkgcHJhY3RpY2UuIFpvb2tlZXBlciAoR29vZ2xl KSB1c2VzIGEgc2luZ2xlIHVuaWZ5aW5nIG1lY2hhbmlzbSDvvIhpdHMgc3BlY2lhbCBmaWxlIHN5 c3RlbSBhYnN0cmFjdGlvbu+8iXRvIGhhbmRsZSBpbnN0YW5jZSByZWdpc3RyYXRpb24sIGluc3Rh bmNlIGtlZXAgYWxpdmUsIHN0YXRlIHN5bmMsIGV0Yy4gQSBncmVhdCBkZXNpZ24hDQoNCkdpdmVu IHRoYXQgdGhlIGluaXRpYWwgcHVycG9zZSBvZiB0aGUgV0cgYXBwZWFycyB0byBiZSBnYXAgYW5h bHlzaXMsIGFjY29yZGluZyB0byBteSB1bmRlcnN0YW5kaW5nLCBJIGZlZWwgdGhhdCBsZWF2aW5n IHN0YXRlIHN5bmMsIGFyZ3VhYmx5IGEga2V5IHBpZWNlLCBvdXQgb2Ygc2NvcGUsIGlzIG5vdCBp ZGVhbC4gIElmIHRoZSBjb25jZXJuIGlzIHRoYXQgZGVzaWduIGlzIGhhcmQsIGdhcCBhbmFseXNp cyBtYXkgYmUgbm90LiBUaGlzIHdpbGwgbWFrZSB5b3VyIFdHIHdvcmsgbW9yZSB2YWx1YWJsZS4g TWFrZSBzZW5zZT8NCg0KSSBhbSB0YWtpbmcgb2ZmIG5vdywgYW5kIG1heSBiZSBxdWlldCBmb3Ig YSB3aGlsZS4gSSBjZXJ0YWlubHkgaG9wZSB0aGUgcHJvcG9zZWQgd29yayAoYW5kIGFkZGluZyBv bmUgbW9yZSBpdGVtOiBzdGF0ZSBnYXAgYW5hbHlzaXMpIGJlIGFwcHJvdmVkLg0KDQpDaGVlcnMs DQoNClJpY2hhcmQNCk9uIEp1bCAyNSwgMjAxNCA5OjI2IFBNLCAiTWVsaW5kYSBTaG9yZSIgPG1l bGluZGEuc2hvcmVAZ21haWwuY29tPG1haWx0bzptZWxpbmRhLnNob3JlQGdtYWlsLmNvbT4+IHdy b3RlOg0KT24gNy8yNS8xNCwgODo1MSBQTSwgWS4gUmljaGFyZCBZYW5nIHdyb3RlOg0KSW4gbXkg dmlldywgd2l0aG91dCBzdGF0ZSBtYW5hZ2VtZW50LCB0aGUgdm5mcG9vbCBwcm9ibGVtIGlzIGhh cmRseQ0Kc29sdmFibGUsIGkuZS4sIHJlYWNoaW5nIGEgdXNhYmxlIGdvYWwuIEhlbmNlLCBpdCBp cyBteSBhdHRlbXB0IHRvDQp1bmRlcnN0YW5kIHRoZSAicHV6emxlIiBwb3N0ZWQgYnkgTWFydGlu LiBJRVRGIHByZWZlcnMgcmVhbCB1c2UgY2FzZQ0KZHJvdmVuIGRlc2lnbi4NCg0KSSdkIGFyZ3Vl IHRoYXQgd2hpbGUgaXQgbWF5IGJlIHRoZSBjYXNlLCB0aGUgcGllY2UgdGhhdCdzDQptaXNzaW5n IGhlcmUsIEkgdGhpbmssIGlzIHRoYXQgdGhlIElFVEYgcHJlZmVycyBwcm9ibGVtcw0KdG8gYmUg YnJva2VuIGRvd24gaW50byBzb2x2YWJsZSBjaHVua3MuICBTdGF0ZSBtYW5hZ2VtZW50DQppcyBu ZWNlc3NhcmlseSBhcHBsaWNhdGlvbi1zcGVjaWZpYywgd2hpbGUgd2hhdCB3ZSd2ZSBiZWVuDQp0 cnlpbmcgdG8gd29yayBvbiBpcyBhIGNvbW1vbiBzdWJzdHJhdGUgdGhhdCBjYW4gYmUgdXNlZA0K dG8gY2FycnkgYXBwbGljYXRpb24tc3BlY2lmaWMgc3RhdGUuICBTbywgZm9yIHRoZSB0aW1lIGJl aW5nLA0KdGhlIHN1YnN0cmF0ZSB3b3VsZCBiZSBpbi1zY29wZSBhbmQgdGhlIGFwcGxpY2F0aW9u IHN0YXRlDQp3b3VsZCBiZSBvdXQtb2Ytc2NvcGUsIHdoZXRoZXIgaXQgd291bGQgYmUgaGFuZGxl ZCBieSBhDQpyZWNoYXJ0ZXJlZCB2bmZwb29sIG9yIGEgc2VwYXJhdGUgd29ya2luZyBncm91cCAo b3INCndvcmtpbmcgZ3JvdXBzKS4gIFRoZXJlJ3MgY2VydGFpbmx5IHByZWNlZGVudCBmb3IgdGhp cw0Kc29ydCBvZiBhcHByb2FjaCAtIGZvciBleGFtcGxlIG5zaXMsIE1QTFMsIGFuZCBvdGhlcnMu DQpPbmUgb2YgdGhlIHRoaW5ncyB0aGF0IGNvbmNlcm5zIG1lLCBhcyBzb21lb25lIHdobydkIGxp a2UNCnRvIHNlZSB0aGUgd29yayBwcm9ncmVzcywgaXMgdGhhdCB0aG9zZSB3aG8gYXJlIGluc2lz dGluZw0KdGhhdCB0aGlzIGlzIGFuIGF0b21pYyBwcm9ibGVtIHNlZW0gYWxzbyB0byBlZmZlY3Rp dmVseSBiZQ0KYXJndWluZyBhZ2FpbnN0IGEgbW9kdWxhciBhcHByb2FjaCB0byBkZXNpZ25pbmcg YSBzb2x1dGlvbi4NCkFuZCBmcmFua2x5IEknbSBzb21ld2hhdCBkaXNtYXllZCBieSB0aGF0Lg0K DQpNZWxpbmRhDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQp2bmZwb29sIG1haWxpbmcgbGlzdA0Kdm5mcG9vbEBpZXRmLm9yZzxtYWlsdG86dm5mcG9v bEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdm5mcG9v bA0K --_000_B0D29E0424F2DE47A0B36779EC66677966176DEAnkgeml501mbschi_ 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 cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLkVtYWlsU3R5 bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSwgUmljaGFyZCwgYW5kIGFsbCw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBkb27igJl0IHNlZSBhIGJpZyBk aXNwdXRlIGluIHlvdXIgY29udmVyc2F0aW9uLiBXZSBkb27igJl0IGV4Y2x1ZGUgc3RhdGUgbWFu YWdlbWVudCBhcyBhIHdob2xlLiBJZiB3ZSBhZ3JlZSBvbiBhIG1vZHVsYXIgYXBwcm9hY2gsIHdl IGNhbiBjYXJyeSBvbg0KIG91ciB3b3JrIHN0ZXAgYnkgc3RlcC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZpcnN0bHkgSSBhZ3JlZSB3aXRoIEFkcmlhbiB0aGF0 IHdlIHNob3VsZCBkcmF3IGEgZGlzdGluY3Rpb24gYmV0d2VlbiB0aGUgaW50ZXJmYWNlIGJldHdl ZW4gcG9vbCBtZW1iZXJzIGZvciBzdGF0ZSBkYXRhIHRyYW5zZmVyLCBhbmQgdGhlIGludGVyZmFj ZQ0KIGJldHdlZW4gcG9vbCBtYW5hZ2VyIGFuZCBwb29sIG1lbWJlciBmb3Igc3RhdGUgbWFuYWdl bWVudC4gQWx0aG91Z2ggYm90aCB0aGVzZSB0d28gaW50ZXJmYWNlcyBhcmUgY2FsbGVkIOKAnHN0 YXRlIG1hbmFnZW1lbnTigJ0gaW4gZ2VuZXJhbCAtIGZyb20gbWFueSBwZW9wbGXigJlzIHBlcnNw ZWN0aXZlLCB0aGV5IGFyZSBxdWl0ZSBkaWZmZXJlbnQgaW4gbmF0dXJlLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIGZvcm1lciBpcyB2ZW5kb3Igc3BlY2lm aWMgYW5kIG9idmlvdXNseSBuZWVkcyBhZ3JlZW1lbnQgYW1vbmcgbXVsdGlwbGUgdmVuZG9ycyBp biB0ZXJtcyBvZiBmYWlsb3ZlciAoYW5kIHN0YXRlIGRhdGEgdHJhbnNmZXIpIGJldHdlZW4gVk5G cw0KIGZyb20gZGlmZmVyZW50IHZlbmRvcnMuIFdlIGFyZSBub3QgaW4gc3VjaCBzaXR1YXRpb24g eWV0LCBidXQgd2lsbCBlbmNvdXJhZ2UgdmVuZG9ycyB0byBkaXNjdXNzIGFuZCBicmluZyBnYXAg YW5hbHlzaXMgdG8gc2hvdyB0aGVpciBzdXBwb3J0IG9uIGludGVyb3BlcmFiaWxpdHkuIFNvIHlv dXIgcHJvcG9zZWQgd29yayBvZiBnYXAgYW5hbHlzaXMgb24gc3RhdGUgbWFuYWdlbWVudCBpcyBh IGdvb2QgaWRlYS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRo ZSBsYXR0ZXIgaXMgYWN0dWFsbHkgaW1wbGljaXRseSBpbmNsdWRlZCBpbiB0aGUgY2hhcnRlciwg c2VydmluZyBhcyBhIGNvbW1vbiBzdWJzdHJhdGUgZm9yIHN0YXRlIG1hbmFnZW1lbnQuIFdlIGFn cmVlIHRoYXQgc3VjaCBzdGFuZGFyZCBpbnRlcmZhY2UNCiBiZXR3ZWVuIHBvb2wgbWFuYWdlciBh bmQgcG9vbCBtZW1iZXJzIGFyZSBpbXBvcnRhbnQgZm9yIGRlY291cGxlZCBpbm5vdmF0aW9uIG9m IGRpZmZlcmVudCBWTkYgYW5kIGNvbnRyb2xsZXIgaW1wbGVtZW50YXRpb25zLiBUaGlzIGlzc3Vl IGhhcyBiZWVuIGNsYXJpZmllZCBpbiBlYXJseSBlbWFpbCBmcm9tIE1lbGluZGEuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JTU8sIHRoZSBWTkYgcG9vbCBpcyB1 c2FibGUgYW5kIHZhbHVhYmxlLCBwcm92aWRlZCB0aGUgc3RhbmRhcmQgaW50ZXJmYWNlIGJldHdl ZW4gcG9vbCBtYW5hZ2VyIGFuZCBwb29sIG1lbWJlcnMgYXJlIHdlbGwgZGVzaWduZWQsIHRvIGFs bG93IGZvcg0KIGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiBwb29sIG1hbmFnZXIsIGFuZCBwb29s IG1lbWJlcnMgZnJvbSBkaWZmZXJlbnQgdmVuZG9ycy4gVGhpcyBpcyBxdWl0ZSBkaWZmZXJlbnQg d2l0aCBhbnkgcHJvcHJpZXRhcnkgcG9vbGluZyBzb2x1dGlvbiBiYXNlZCBvbiBzaW5nbGUgdmVu ZG9yIGltcGxlbWVudGF0aW9uLCBhbmQgaXMgdGhlIGtleSB2YWx1ZSB3ZSB3YW50IGJyaW5nIHZp YSBJRVRGLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgcmVhbCBjb25j ZXJuIGluIG15IG1pbmQgaXMgdGhhdCBzb21lb25lIG1heSBzdGlsbCB0aGluayB0aGF0IHRoZSB3 aG9sZSBWTkYgcG9vbCB3b27igJl0IHN1Y2NlZWQgd2l0aG91dCBvcGVuaW5nIHRoZSBpbnRlcmZh Y2UgYmV0d2VlbiBwb29sIG1lbWJlcnMNCiBmb3Igc3RhdGUgZGF0YSB0cmFuc2ZlciDigJMgd2hp Y2ggSSBzdHJvbmdseSBkaXNhZ3JlZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+VGhhbmtzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tTmluZzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuWPkeS7tuS6ujxzcGFuIGxhbmc9 IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij4gdm5mcG9vbCBbbWFpbHRvOnZuZnBvb2wtYm91bmNlc0BpZXRmLm9yZ10N Cjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Luj6KGoIDwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5ZLiBSaWNoYXJk IFlhbmc8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuWPkemA geaXtumXtDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4gMjAxNDwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+5bm0PHNwYW4gbGFuZz0iRU4tVVMiPjc8L3NwYW4+5pyIPHNwYW4g bGFuZz0iRU4tVVMiPjI2PC9zcGFuPuaXpTxzcGFuIGxhbmc9IkVOLVVTIj4gOTo0OTxicj4NCjwv c3Bhbj48Yj7mlLbku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiPiBNZWxpbmRhIFNob3JlPGJyPg0KPC9zcGFuPjxiPuaKhOmAgTxzcGFuIGxhbmc9 IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IHZuZnBvb2xAaWV0Zi5vcmc7 IGFkcmlhbkBvbGRkb2cuY28udWs8YnI+DQo8L3NwYW4+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4t VVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUmU6IFt2bmZwb29sXSBTdGF0ZSBt YW5hZ2VtZW50PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBNZWxpbmRhLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5Ob3Qgc3VyZSB3aHkgeW91IGdvdCB0aGUgaW1wcmVz c2lvbiBvZiB0aGVzZSBwZW9wbGUgYXJndWluZyBhZ2FpbnN0IGEgbW9kdWxhci4gSSBkbyBub3Qu IEkgc3Ryb25nbHkgc3VwcG9ydC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5n PSJFTi1VUyI+R28gYmFjayB0byBpbmR1c3RyeSBwcmFjdGljZS4gWm9va2VlcGVyIChHb29nbGUp IHVzZXMgYSBzaW5nbGUgdW5pZnlpbmcgbWVjaGFuaXNtDQo8L3NwYW4+77yIPHNwYW4gbGFuZz0i RU4tVVMiPml0cyBzcGVjaWFsIGZpbGUgc3lzdGVtIGFic3RyYWN0aW9uPC9zcGFuPu+8iTxzcGFu IGxhbmc9IkVOLVVTIj50byBoYW5kbGUgaW5zdGFuY2UgcmVnaXN0cmF0aW9uLCBpbnN0YW5jZSBr ZWVwIGFsaXZlLCBzdGF0ZSBzeW5jLCBldGMuIEEgZ3JlYXQgZGVzaWduITxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5HaXZlbiB0aGF0IHRoZSBpbml0aWFsIHB1 cnBvc2Ugb2YgdGhlIFdHIGFwcGVhcnMgdG8gYmUgZ2FwIGFuYWx5c2lzLCBhY2NvcmRpbmcgdG8g bXkgdW5kZXJzdGFuZGluZywgSSBmZWVsIHRoYXQgbGVhdmluZyBzdGF0ZSBzeW5jLCBhcmd1YWJs eSBhIGtleSBwaWVjZSwgb3V0IG9mIHNjb3BlLCBpcyBub3QgaWRlYWwuJm5ic3A7IElmIHRoZSBj b25jZXJuIGlzIHRoYXQgZGVzaWduIGlzIGhhcmQsIGdhcCBhbmFseXNpcw0KIG1heSBiZSBub3Qu IFRoaXMgd2lsbCBtYWtlIHlvdXIgV0cgd29yayBtb3JlIHZhbHVhYmxlLiBNYWtlIHNlbnNlPzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGFtIHRha2luZyBv ZmYgbm93LCBhbmQgbWF5IGJlIHF1aWV0IGZvciBhIHdoaWxlLiBJIGNlcnRhaW5seSBob3BlIHRo ZSBwcm9wb3NlZCB3b3JrIChhbmQgYWRkaW5nIG9uZSBtb3JlIGl0ZW06IHN0YXRlIGdhcCBhbmFs eXNpcykgYmUgYXBwcm92ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0i RU4tVVMiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1V UyI+UmljaGFyZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gSnVsIDI1LCAyMDE0IDk6MjYgUE0sICZxdW90O01l bGluZGEgU2hvcmUmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzptZWxpbmRhLnNob3JlQGdtYWls LmNvbSI+bWVsaW5kYS5zaG9yZUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gNy8y NS8xNCwgODo1MSBQTSwgWS4gUmljaGFyZCBZYW5nIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JbiBteSB2aWV3LCB3 aXRob3V0IHN0YXRlIG1hbmFnZW1lbnQsIHRoZSB2bmZwb29sIHByb2JsZW0gaXMgaGFyZGx5PGJy Pg0Kc29sdmFibGUsIGkuZS4sIHJlYWNoaW5nIGEgdXNhYmxlIGdvYWwuIEhlbmNlLCBpdCBpcyBt eSBhdHRlbXB0IHRvPGJyPg0KdW5kZXJzdGFuZCB0aGUgJnF1b3Q7cHV6emxlJnF1b3Q7IHBvc3Rl ZCBieSBNYXJ0aW4uIElFVEYgcHJlZmVycyByZWFsIHVzZSBjYXNlPGJyPg0KZHJvdmVuIGRlc2ln bi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PGJyPg0KSSdkIGFyZ3VlIHRoYXQgd2hpbGUgaXQgbWF5IGJlIHRoZSBjYXNlLCB0 aGUgcGllY2UgdGhhdCdzPGJyPg0KbWlzc2luZyBoZXJlLCBJIHRoaW5rLCBpcyB0aGF0IHRoZSBJ RVRGIHByZWZlcnMgcHJvYmxlbXM8YnI+DQp0byBiZSBicm9rZW4gZG93biBpbnRvIHNvbHZhYmxl IGNodW5rcy4gJm5ic3A7U3RhdGUgbWFuYWdlbWVudDxicj4NCmlzIG5lY2Vzc2FyaWx5IGFwcGxp Y2F0aW9uLXNwZWNpZmljLCB3aGlsZSB3aGF0IHdlJ3ZlIGJlZW48YnI+DQp0cnlpbmcgdG8gd29y ayBvbiBpcyBhIGNvbW1vbiBzdWJzdHJhdGUgdGhhdCBjYW4gYmUgdXNlZDxicj4NCnRvIGNhcnJ5 IGFwcGxpY2F0aW9uLXNwZWNpZmljIHN0YXRlLiAmbmJzcDtTbywgZm9yIHRoZSB0aW1lIGJlaW5n LDxicj4NCnRoZSBzdWJzdHJhdGUgd291bGQgYmUgaW4tc2NvcGUgYW5kIHRoZSBhcHBsaWNhdGlv biBzdGF0ZTxicj4NCndvdWxkIGJlIG91dC1vZi1zY29wZSwgd2hldGhlciBpdCB3b3VsZCBiZSBo YW5kbGVkIGJ5IGE8YnI+DQpyZWNoYXJ0ZXJlZCB2bmZwb29sIG9yIGEgc2VwYXJhdGUgd29ya2lu ZyBncm91cCAob3I8YnI+DQp3b3JraW5nIGdyb3VwcykuICZuYnNwO1RoZXJlJ3MgY2VydGFpbmx5 IHByZWNlZGVudCBmb3IgdGhpczxicj4NCnNvcnQgb2YgYXBwcm9hY2ggLSBmb3IgZXhhbXBsZSBu c2lzLCBNUExTLCBhbmQgb3RoZXJzLjxicj4NCk9uZSBvZiB0aGUgdGhpbmdzIHRoYXQgY29uY2Vy bnMgbWUsIGFzIHNvbWVvbmUgd2hvJ2QgbGlrZTxicj4NCnRvIHNlZSB0aGUgd29yayBwcm9ncmVz cywgaXMgdGhhdCB0aG9zZSB3aG8gYXJlIGluc2lzdGluZzxicj4NCnRoYXQgdGhpcyBpcyBhbiBh dG9taWMgcHJvYmxlbSBzZWVtIGFsc28gdG8gZWZmZWN0aXZlbHkgYmU8YnI+DQphcmd1aW5nIGFn YWluc3QgYSBtb2R1bGFyIGFwcHJvYWNoIHRvIGRlc2lnbmluZyBhIHNvbHV0aW9uLjxicj4NCkFu ZCBmcmFua2x5IEknbSBzb21ld2hhdCBkaXNtYXllZCBieSB0aGF0Ljxicj4NCjxicj4NCk1lbGlu ZGE8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCnZuZnBvb2wgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnZuZnBv b2xAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52bmZwb29sQGlldGYub3JnPC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdm5mcG9vbCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdm5mcG9v bDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_B0D29E0424F2DE47A0B36779EC66677966176DEAnkgeml501mbschi_--