From nobody Wed Aug 1 08:22:26 2018 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A0A130FE8; Wed, 1 Aug 2018 08:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcoWoZy_3_7A; Wed, 1 Aug 2018 08:22:14 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C299130E37; Wed, 1 Aug 2018 08:22:14 -0700 (PDT) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 5D607C042B058; Wed, 1 Aug 2018 16:22:08 +0100 (IST) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 1 Aug 2018 16:22:09 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.206]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0399.000; Wed, 1 Aug 2018 23:22:02 +0800 From: "Dongjie (Jimmy)" To: "Joel M. Halpern" CC: "TEAS WG (teas@ietf.org)" , "rtgwg@ietf.org" Thread-Topic: VPN security vs SD-WAN security Thread-Index: AQHUI/wIJ6g4duQ3X0aNCgBtJqhDKKSfLQmAgAAYIgCAABGYAIAE6NWA///YuoCAAG2tgIAAK5GAgAJ2aLCAADdCAIADlRmw Date: Wed, 1 Aug 2018 15:22:01 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927A72B1EF7@NKGEML515-MBS.china.huawei.com> References: <0cb8f15b-7538-500c-dda3-915bf9814f94@gmail.com> <5D10C0C4-B93D-463F-A071-EEA6F35506CD@cisco.com> <76CD132C3ADEF848BD84D028D243C927A71506F6@NKGEML515-MBS.china.huawei.com> <76CD132C3ADEF848BD84D028D243C927A72042AB@NKGEML515-MBS.china.huawei.com> <89653c55-90e0-c52d-bdef-38b312b7feda@joelhalpern.com> In-Reply-To: <89653c55-90e0-c52d-bdef-38b312b7feda@joelhalpern.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.189.142] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Teas] =?utf-8?b?562U5aSNOiBWUE4gc2VjdXJpdHkgdnMgU0QtV0FOIHNl?= =?utf-8?q?curity?= X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 15:22:24 -0000 VGhpcyBzdGF0ZW1lbnQgaXMgYmFzZWQgb24gdGhlIGNvbXBhcmlzb24gYmV0d2VlbiBvdmVybGF5 IFZQTnMgYW5kIG5ldHdvcmsgc2xpY2VzLiBUaGUgcmVzb3VyY2UgaGVyZSByZWZlcnMgdG8gdmFy aW91cyBkYXRhIHBsYW5lIHJlc291cmNlcyB0aGF0IGNhbiBiZSBhbGxvY2F0ZWQgdG8gYSBwYXJ0 aWN1bGFyIHNsaWNlIChxdWV1ZXMsIGJ1ZmZlciwgZXRjLikuIFNvbWUgbGV2ZWwgb2YgcmVzb3Vy Y2UgaXNvbGF0aW9uIGlzIG5lY2Vzc2FyeSB0byBlbnN1cmUgdGhhdCBzZXJ2aWNlIGluIG9uZSBz bGljZSBuZXZlciBpbnRlcmZlcmVzIHdpdGggc2VydmljZSBpbiBhbm90aGVyIHNsaWNlLiANCg0K TWF5IEkga25vdyB3aGF0IGFyZSB0aGUgcmVxdWlyZW1lbnRzIHlvdSd2ZSBnb3Q/IA0KDQpCZXN0 IHJlZ2FyZHMsIA0KSmllDQoNCj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6 IEpvZWwgTS4gSGFscGVybiBbbWFpbHRvOmptaEBqb2VsaGFscGVybi5jb21dDQo+IOWPkemAgeaX tumXtDogMjAxOOW5tDfmnIgzMOaXpSAyMzowNQ0KPiDmlLbku7bkuro6IERvbmdqaWUgKEppbW15 KSA8amllLmRvbmdAaHVhd2VpLmNvbT4NCj4g5oqE6YCBOiBURUFTIFdHICh0ZWFzQGlldGYub3Jn KSA8dGVhc0BpZXRmLm9yZz47IHJ0Z3dnQGlldGYub3JnDQo+IOS4u+mimDogUmU6IFZQTiBzZWN1 cml0eSB2cyBTRC1XQU4gc2VjdXJpdHkNCj4gDQo+IEFjdHVhbGx5LCBhc3N1bWluZyBJIHVuZGVy c3RhbmQgdGhlIHN0YXRlbWVudCBwcm9wZXJseSwgImRlZXAgaW50ZWdyYXRpb24NCj4gd2l0aCB0 aGUgdW5kZXJsYXkgcmVzb3VyY2Ugd291bGQgYmUgbmVjZXNzYXJ5IiBkb2VzIG5vdCBhcHBlYXIg dG8gYmUgYW4NCj4gYWNjdXJhdGUgc3RhdGVtZW50IGRlcml2YWJsZSBmcm9tIHRoZSByZXF1aXJl bWVudHMgdGhhdCBJIGhhdmUgc2Vlbi4NCj4gDQo+IFlvdXJzLA0KPiBKb2VsDQo+IA0KPiBPbiA3 LzMwLzE4IDg6MjMgQU0sIERvbmdqaWUgKEppbW15KSB3cm90ZToNCj4gPiAoQWRkaW5nIFRFQVMg YXMgaXQgaXMgd2hlcmUgdGhlIFZQTisgZnJhbWV3b3JrIGRyYWZ0IGlzIGRpc2N1c3NlZCkNCj4g Pg0KPiA+IEhpIFJvYmVydCBhbmQgR3JlZywNCj4gPg0KPiA+IEFzIGRpc2N1c3NlZCBkdXJpbmcg dGhlIFZQTisgcHJlc2VudGF0aW9uIGluIFRFQVMgYXQgSUVURiAxMDIsIHRoZQ0KPiA+IHNjb3Bl IGlzIG5vdCB0aGUgaW50ZXJuZXQsIGFzIHdlIGtub3cgaXQgd291bGQgcXVpdGUgZGlmZmljdWx0 IG9yIGV2ZW4NCj4gPiBpbXBvc3NpYmxlIHRvIGFjaGlldmUgdGhlIHJlcXVpcmVkIGd1YXJhbnRl ZSBhdCB0aGUgc2NvcGUgb2YgaW50ZXJuZXQuDQo+ID4NCj4gPiBBbmQgY2xlYXJseSB0aGUgVlBO IG92ZXJsYXlzIGNhbm5vdCBwcm92aWRlIHRoZSByZXF1aXJlZCBndWFyYW50ZWUsDQo+ID4gZGVl cCBpbnRlZ3JhdGlvbiB3aXRoIHRoZSB1bmRlcmxheSByZXNvdXJjZSB3b3VsZCBiZSBuZWNlc3Nh cnkuDQo+ID4NCj4gPiBBbm90aGVyIGFzcGVjdCB3ZSBtYXkgdGFrZSBpbnRvIGNvbnNpZGVyYXRp b24gaXMgdGhlIGZhY3RvciBvZg0KPiA+IG92ZXJwcm92aXNpb25pbmcuIFRoZSBjdXJyZW50IG5l dHdvcmsgb25seSBoYXMgb25lIG92ZXJwcm92aXNpb25pbmcNCj4gPiBmYWN0b3IsIHdoaWNoIG1h eSBub3QgbWVldCB0aGUgcmVxdWlyZW1lbnQgb2YgZGlmZmVyZW50DQo+ID4gc2VydmljZXMvY3Vz dG9tZXJzLiBXaXRoIG5ldHdvcmsgc2xpY2luZywgaXQgaXMgcG9zc2libGUgdG8gaGF2ZQ0KPiA+ IGRpZmZlcmVudCBvdmVycHJvdmlzaW9uaW5nIHBvbGljeSBhbmQgZmFjdG9yIGluIGRpZmZlcmVu dCBzbGljZXMuDQo+ID4NCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4NCj4gPiBKaWUNCj4gPg0KPiA+ ICpGcm9tOipycmFzenVrQGdtYWlsLmNvbSBbbWFpbHRvOnJyYXN6dWtAZ21haWwuY29tXSAqT24g QmVoYWxmIE9mDQo+ID4gKlJvYmVydCBSYXN6dWsNCj4gPiAqU2VudDoqIFN1bmRheSwgSnVseSAy OSwgMjAxOCA2OjExIEFNDQo+ID4gKlRvOiogR3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5QGdtYWls LmNvbT4NCj4gPiAqQ2M6KiBEb25namllIChKaW1teSkgPGppZS5kb25nQGh1YXdlaS5jb20+OyBy dGd3Z0BpZXRmLm9yZw0KPiA+ICpTdWJqZWN0OiogUmU6IFZQTiBzZWN1cml0eSB2cyBTRC1XQU4g c2VjdXJpdHkNCj4gPg0KPiA+IEhleSBHcmVnLA0KPiA+DQo+ID4+DQo+ID4NCj4gPiB3b3VsZCBu b3QgcmVxdWlyZSBnbG9iYWwgdHJhbnNpdCBhbmQgbGlrZWx5IGJlIGNvbnRhaW5lZCB3aXRoaW4g YWNjZXNzDQo+ID4gb3IsIGF0IG1vc3QsIG1ldHJvIGRvbWFpbnMuDQo+ID4NCj4gPiBUaGF0J3Mg bmV3cyB0byBtZSwgYnV0IHBlcmhhcHMgb24gdGhlIHBvc2l0aXZlIHNpZGUgOikgSSBhbHdheXMg dGhpbmsNCj4gPiBXQU4gLi4gcmVhbGx5IHdpZGUgb25lICENCj4gPg0KPiA+IFRoZSBzZXBhcmF0 aW9uIG9uICJzb2Z0IiB2cyAiaGFyZCIgZ3VhcmFudGVlcyBpcyBldmVudHVhbGx5IGFsbCBhYm91 dA0KPiA+IGFtb3VudCBvZiBuZXR3b3JrIHJvYnVzdG5lc3MgYW5kIGxldmVsIG9mIG92ZXIgcHJv dmlzaW9uaW5nLsKgIEkNCj4gPiBzaW5jZXJlbHkgaG9wZSBpdCB3aWxsIG5vdCBiZSB5ZXQgYW5v dGhlciBFVlBOIG92ZXJsYXkgb3ZlciBJUCBuZXR3b3JrDQo+ID4ganVzdCBwYWludGVkIHdpdGgg ZGlmZmVyZW50IG1hcmtldGluZyBjb2xvcnMuDQo+ID4NCj4gPiBCZXNpZGVzIGlmIGFueSBjdXN0 b21lciBpcyBzZXJpb3VzIGFuZCBhY3R1YWxseSBjb3VudHMgb24gdGhvc2UNCj4gPiBndWFyYW50 ZWVzIGhlIGJldHRlciBwdXJjaGFzZSB0d28gb2Ygc3VjaCBzZXJ2aWNlcyBjb21pbmcgZnJvbQ0K PiA+IGluZGVwZW5kZW50IG9wZXJhdG9ycy4gVGhhdCBtZWFucyB0aGF0IHRvIGJlIGF0dHJhY3Rp dmUgZmluYW5jaWFsbHkNCj4gPiBjb3N0IG9mIHN1Y2ggcHJlbWl1bSBzZXJ2aWNlIG11c3Qgbm90 IGJlIGhpZ2hlciB0aGVuIGhhbGYgb2YgdGhlIHAycA0KPiA+IGxvY2FsIGZpYmVyIG9yIGNvc3Qg b2YgbG9jYWwgYWNjZXNzIHRvIGNsb3Nlc3QgSVggcG9ydHMgKyBwb3J0DQo+ID4gc3Vic2NyaXB0 aW9uIGluIGEgZ2l2ZW4gTUFOIHdoZXJlIG5vbiBibG9ja2luZyBJWCBmYWJyaWMgc3BhbnMgZ2l2 ZW4NCj4gZ2VvZ3JhcGh5Lg0KPiA+DQo+ID4gSXQgc2VlbXMgdG8gbWUgdGhhdCBhdCB0aGUgZW5k IG9mIHRoZSBkYXkgdGhlIHNwYWNlIGZvciB0aG9zZQ0KPiA+IG9wZXJhdG9ycyB3aXNoaW5nIHRv IG9mZmVyIGhhcmQgbmV0d29yayBzbGljaW5nIGlzIGFjdHVhbGx5IHByZXR0eQ0KPiA+IG5hcnJv dywgYnV0IHRpbWUgd2lsbCB0ZWxsIC4uLg0KPiA+DQo+ID4gUmdzLA0KPiA+DQo+ID4gci4NCj4g Pg0KPiA+IE9uIFNhdCwgSnVsIDI4LCAyMDE4IGF0IDk6MzQgUE0sIEdyZWcgTWlyc2t5IDxncmVn aW1pcnNreUBnbWFpbC5jb20NCj4gPiA8bWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbT4+IHdy b3RlOg0KPiA+DQo+ID4gICAgIEhpIFJvYmVydCwNCj4gPg0KPiA+ICAgICB2ZXJ5IG11Y2ggYWdy ZWUgd2l0aCBhbGwgeW91J3JlIHNheWluZyBhbmQgZmluZCB1cyBpbiB2aW9sZW50DQo+ID4gICAg IGFncmVlbWVudCBvbiAiQyIuIFByb2FjdGl2ZSBwZXJmb3JtYW5jZSBtb25pdG9yaW5nLCBpbiBt eSB2aWV3IGFzDQo+ID4gICAgIHdlbGwsIGlzIHRoZSByZWFzb25hYmxlIHBhdGggdG8gcHJvdmlk ZSAic29mdCIgU0xBIGFuZCwgdG8gYSBkZWdyZWUsDQo+ID4gICAgIHByZXZlbnQgb3ZlcnN1YnNj cmlwdGlvbiBvZiB0aGUgbmV0d29yay4gQW5kIHRoYXQsIGFzIHlvdSd2ZSBzYWlkLA0KPiA+ICAg ICBpcyBvbmUgd2F5IHRvICJhc3N1cmVkL2d1YXJhbnRlZWQgZ2xvYmFsIElQIHRyYW5zaXQiLg0K PiA+DQo+ID4gICAgIEJ1dCBJIHRoaW5rIHRoYXQgdGhlcmUgd2lsbCBiZSBkZW1hbmQgZm9yICJo YXJkIiBndWFyYW50ZWVzIGZvcg0KPiA+ICAgICBVUkxMQ8KgYXBwbGljYXRpb25zLiBCdXQgdGhl c2UsIGluIG15IHZpZXcsDQo+ID4NCj4gPiAgICAgd291bGQgbm90IHJlcXVpcmUgZ2xvYmFsIHRy YW5zaXQgYW5kIGxpa2VseSBiZSBjb250YWluZWQgd2l0aGluDQo+ID4gICAgIGFjY2Vzc8Kgb3Is IGF0IG1vc3QsIG1ldHJvIGRvbWFpbnMuIEJlY2F1c2Ugb2YgdGhlIGxpbWl0ZWQgc2l6ZSBvZg0K PiA+ICAgICB0aGUgZG9tYWluLCBJbnRTZXJ2IG1heSB3b3JrLCB0aG91Z2ggdGhhdCBtYXkgYmUg bm90IHRoZSBtb3N0DQo+ID4gICAgIGVmZmljaWVudCB0ZWNobmlxdWUuIFdlIHNoYWxsIGZpbmQg b3V0Lg0KPiA+DQo+ID4gICAgIEhlbmNlIG15IHZpZXcgb24gc2xpY2luZzoNCj4gPg0KPiA+ICAg ICAgICogZGlmZmVyZW50IGFwcGxpY2F0aW9ucyB3aWxsIGhhdmUgZGlmZmVyZW50IHJlcXVpcmVt ZW50cyBhbmQgdXNlDQo+ID4gICAgICAgICBkaWZmZXJlbnQgZGVncmVlcyBvZiBpc29sYXRpb24g YW5kIGd1YXJhbnRlZXM7DQo+ID4gICAgICAgKiAic29mdCIgc2xpY2VzIG1heSBub3QgbmVlZCBt dWNoIG9mIGFkZGl0aW9uYWwgc3RhbmRhcmRpemF0aW9uDQo+ID4gICAgICAgICBhbmQgdXNlIGF2 YWlsYWJsZSBWUE4gdGVjaG5vbG9naWVzIGluIGNvbWJpbmF0aW9uIHdpdGggUE0gT0FNDQo+ID4g ICAgICAgICBmb3IgU0xBIG1vbml0b3JpbmcgYW5kIGFzc3VyYW5jZTsNCj4gPiAgICAgICAqICJo YXJkIiBzbGljZXMgd291bGQgc3BhbiB3aXRoaW4gYSBzaW5nbGUgYWNjZXNzIGFuZC9vciBtZXRy bw0KPiA+ICAgICAgICAgZG9tYWluLiBOZXR3b3JraW5nIHNvbHV0aW9ucyBsaWtlbHkgd2lsbCBi ZSBjb3VwbGVkIHdpdGgNCj4gPiAgICAgICAgIGFyY2hpdGVjdHVyZSBhbmQgaW50ZXJmYWNlcyBk ZXZlbG9wZWQgaW4gTXVsdGktYWNjZXNzIEVkZ2UNCj4gPiAgICAgICAgIENvbXB1dGluZyAoTUVD KS4NCj4gPg0KPiA+ICAgICBSZWdhcmRzLA0KPiA+DQo+ID4gICAgIEdyZWcNCj4gPg0KPiA+ICAg ICBPbiBTYXQsIEp1bCAyOCwgMjAxOCBhdCA2OjAyIEFNLCBSb2JlcnQgUmFzenVrIDxyb2JlcnRA cmFzenVrLm5ldA0KPiA+ICAgICA8bWFpbHRvOnJvYmVydEByYXN6dWsubmV0Pj4gd3JvdGU6DQo+ ID4NCj4gPiAgICAgICAgIEhpIEppZSwNCj4gPg0KPiA+ICAgICAgICAgPiAobmV0d29yayBzbGlj aW5nKSBpcyB0byBwcm92aWRlIHRoZSBkZW1hbmRpbmcgc2VydmljZXMgd2l0aA0KPiA+IGd1YXJh bnRlZWQgcGVyZm9ybWFuY2UgaW4gYSBjb252ZXJnZWQgbmV0d29yaywNCj4gPg0KPiA+ICAgICAg ICAgRm91bmRhdGlvbiBvZiBjb252ZXJnZWQgSVAgbmV0d29yayBpcyBiYXNlZCBvbiBzdGF0aXN0 aWNhbA0KPiA+ICAgICAgICAgbXVsdGlwbGV4aW5nIG9mIHRyYWZmaWMgZGVtYW5kcy4gQXMgc3Vj aCBpdCBpcyBpbiBpdHMgcHJpbmNpcGxlDQo+ID4gICAgICAgICBxdWl0ZSBjb250cmFkaWN0b3J5 IHRvICJndWFyYW50ZWVkIiBjaGFyYWN0ZXJpc3RpY3MNCj4gPiAgICAgICAgIChwZXJmb3JtYW5j ZSwgZGVsYXlzLCBqaXR0ZXIsIGRyb3BzIC0tIHlvdSBuYW1lIGl0KS4NCj4gPg0KPiA+ICAgICAg ICAgQXBwbGljYXRpb24gbGF5ZXJzIHVzdWFsbHkgZGVhbCB2ZXJ5IHdlbGwgd2l0aCBhbGwgb2Yg dGhlIGFib3ZlDQo+ID4gICAgICAgICBJIHdvdWxkIHN0YXRlIC0gbm9ybWFsIGNoYXJhY3Rlcmlz dGljcyBvZiBJUCBuZXR3b3Jrcy4uDQo+ID4NCj4gPiAgICAgICAgIE5vIGRvdWJ0IHRoZXJlIHdp bGwgYmUgdGhvc2UgdHJ5aW5nIHRvIG9mZmVyIHNvbWUgbmV0d29yaw0KPiA+ICAgICAgICAgc2xp Y2luZyB3aXRoIGd1YXJhbnRlZXMgYW5kIGV2ZW4gdGhvc2Ugd2hvIHdpbGwgYnV5IGl0LiBKdXN0 DQo+ID4gICAgICAgICBsaWtlIHRvZGF5IHRoZXJlIGFyZSB0aG9zZSB3aG8gb2ZmZXIgeW91IEwy IGNpcmN1aXQgYmV0d2Vlbg0KPiA+ICAgICAgICAgZW5kcG9pbnRzIGV4Y2VwdCBzdWNoIEwyIGNp cmN1aXQgaXMgYW4gZW11bGF0ZWQgb25lIHdpdGggemVybw0KPiA+ICAgICAgICAgT0VNIHZpc2li aWxpdHkgdG8gdGhlIElQIGluZnJhc3RydWN0dXJlIHVuZGVybmVhdGguDQo+ID4NCj4gPiAgICAg ICAgIE5vdyB0aGUgbmV0d29yayBzbGljaW5nIGlzIGNsZWFybHkgYWltaW5nIGZvciBldmVuIG1v cmUNCj4gPiAgICAgICAgIGNvbXBsZXhpdHkgdW5kZXIgdGhlIGhvb2QuIEFuZCB0aGF0IGlzIG5v dCB0aGUgb25seSBwcm9ibGVtLiBUaGUNCj4gPiAgICAgICAgIGlzc3VlIGlzIGNvc3QuIFdoZW4g U1AgaXMgYnVpbGRpbmcgdGhlIElQIG5ldHdvcmsgdGhlIGdvYWwgaXMgdG8NCj4gPiAgICAgICAg IG11eCBhcyBtYW55IHNlcnZpY2VzIG9uIGl0IGFzIGl0IHNpbXBseSByZXN1bHRzIGluIGdpdmVu J3MgU1ANCj4gPiAgICAgICAgIHJldmVudWUuIE5ldHdvcmsgc2xpY2luZyBpcyBwcm9taXNpbmcg YXMgcG90ZW50aWFsbHkganVzdCBieQ0KPiA+ICAgICAgICAgY29uZmlndXJhdGlvbiBvZiBmZXcg a25vYnMgdGhleSB3aWxsIGJlIGNsYWltaW5nIGd1YXJhbnRlZXMgYXMNCj4gPiAgICAgICAgIFJG QyBzYXlzIC0gZXhjZXB0IFJGQyB3aWxsIG5vdCBsaWtlbHkgdGVsbCB5b3UgdG8gc3RvcA0KPiA+ ICAgICAgICAgb3Zlci1wcm92aXNpb25pbmcuDQo+ID4NCj4gPiAgICAgICAgIFVubGVzcyB0aGUg aWRlYSBpcyB0byB1c2Ugc3RyaWN0IHBvbGljaW5nIHdpdGggZGVkaWNhdGVkIHF1ZXVpbmcNCj4g PiAgICAgICAgIG9uIGFjdGl2ZSBhbmQgYmFjayBwYXRocyBvciBkbyBzb21ldGhpbmcgbGlrZSBS U1ZQIEludFNlcnYgYWxzbw0KPiA+ICAgICAgICAgb24gYWN0aXZlIGFuZCBiYWNrdXAgcGF0aHMg cGVyIGN1c3RvbWVyIC0gSSByZWFsbHkgZG9uJ3QgdGhpbmsNCj4gPiAgICAgICAgIHlvdSBjYW4g cmVhbGx5IGd1YXJhbnRlZSBtdWNoLiBBbmQgaWYgeW91IGRvIHRoYXQgdGhlIGNvc3Qgd291bGQN Cj4gPiAgICAgICAgIGxpa2VseSBncm93IHJlYWxseSBzdGVlcC4NCj4gPg0KPiA+ICAgICAgICAg U28gd2hhdCBpcyBJTU8gdGhlIHNvbHV0aW9uIGZvciBhc3N1cmVkL2d1YXJhbnRlZWQgZ2xvYmFs IElQDQo+ID4gICAgICAgICB0cmFuc2l0Og0KPiA+DQo+ID4gICAgICAgICAqQSrCoCBnZXQgZGl2 ZXJzZWx5IHJvdXRlZMKgIGRhcmsgZmliZXIgcGF0aHMgYmV0d2VlbiB5b3VyIFBPUHMNCj4gPiAg ICAgICAgIChjYW4gYmUgdW5wcm90ZWN0ZWQpIHdoaWNoIGJ0dyB0b2RheSBkbyBub3QgY29zdCB0 aGF0IG11Y2gNCj4gPiBhbnltb3JlDQo+ID4NCj4gPiAgICAgICAgICpCKiBnZXQgZGl2ZXJzZWx5 IHJvdXRlZMKgIG9wdGljYWwgY2hhbm5lbHMgYWxzb2wgYmV0d2VlbiB5b3VyDQo+ID4gICAgICAg ICBQT1BzIChjYW4gYmUgdW5wcm90ZWN0ZWQpDQo+ID4NCj4gPiAgICAgICAgICpDKsKgIHVzZSBO IGRpc2pvaW5lZCBieSBkZXNpZ24gKHNpbmdsZSBBUyBJbnRlcm5ldCBwcm92aWRlcnMNCj4gPiAg ICAgICAgIGJldHdlZW4geW91ciBlbmQtcG9pbnRzKSArIHByb3BlciBTRC1XQU4gd2l0aCBhY3Rp dmUgU0xBDQo+ID4gbW9uaXRvcmluZw0KPiA+DQo+ID4gICAgICAgICBDbGVhcmx5IEkgYW0gYmln IHN1cHBvcnRlciBvZiAqQyogbW9kZWwgZm9yIHJlYXNvbnMgZGlzY3Vzc2VkIG9uDQo+ID4gICAg ICAgICB0aGlzIGFuZCBmZXcgb3RoZXIgcmVjZW50IHRocmVhZHMuDQo+ID4NCj4gPiAgICAgICAg IEkgYXNzdW1lIG5ldHdvcmsgc2xpY2luZyB3aWxsIHRyeSB0byBnZXQgaW50byBiZSBzb21ldGhp bmcNCj4gPiAgICAgICAgIGJldHdlZW4gQS9CICYgQyBidXQgaXQgaXMgYm91bmRlZCB1cCBmcm9u dCB3aXRoIHRoZSBjb3N0IG9mIHRoZQ0KPiA+ICAgICAgICAgdHdvLg0KPiA+DQo+ID4gICAgICAg ICBNYW55IHRoeCwNCj4gPg0KPiA+ICAgICAgICAgUm9iZXJ0Lg0KPiA+DQo+ID4gICAgICAgICBP biBTYXQsIEp1bCAyOCwgMjAxOCBhdCA5OjUxIEFNLCBEb25namllIChKaW1teSkNCj4gPiAgICAg ICAgIDxqaWUuZG9uZ0BodWF3ZWkuY29tIDxtYWlsdG86amllLmRvbmdAaHVhd2VpLmNvbT4+IHdy b3RlOg0KPiA+DQo+ID4gICAgICAgICAgICAgSGkgUm9iZXJ0LA0KPiA+DQo+ID4gICAgICAgICAg ICAgSU1PIHRoZSB0d28gYXBwcm9hY2hlcyBhcmUgdGFyZ2V0aW5nIGF0IGRpZmZlcmVudCB1c2Ug Y2FzZXMNCj4gPiAgICAgICAgICAgICBhbmQgY3VzdG9tZXJzLg0KPiA+DQo+ID4gICAgICAgICAg ICAgVGhlIGZvcm1lciAobmV0d29yayBzbGljaW5nKSBpcyB0byBwcm92aWRlIHRoZSBkZW1hbmRp bmcNCj4gPiAgICAgICAgICAgICBzZXJ2aWNlcyB3aXRoIGd1YXJhbnRlZWQgcGVyZm9ybWFuY2Ug aW4gYSBjb252ZXJnZWQNCj4gbmV0d29yaywNCj4gPiAgICAgICAgICAgICB3aGlsZSB0aGUgbGF0 dGVyIChzd2l0Y2hpbmcgYmV0d2VlbiBtdWx0aXBsZSBwYXJhbGxlbGVkDQo+ID4gICAgICAgICAg ICAgbmV0d29ya3MpIHByb3ZpZGVzIHRoZSBjdXN0b21lciB3aXRoIHRoZSBiZXN0IHBlcmZvcm1h bmNlDQo+ID4gICAgICAgICAgICAgdGhhdCBpcyBhdmFpbGFibGUgYW1vbmcgdGhvc2UgY2FuZGlk YXRlcy4gVG8gbWUgdGhlIGxhdHRlcg0KPiA+ICAgICAgICAgICAgIGlzIHN0aWxsIHNvbWUga2lu ZCBvZiBiZXN0IGVmZm9ydCwgYW5kIGFzIFRvZXJsZXNzIHNhaWQsIGl0DQo+ID4gICAgICAgICAg ICAgZGVwZW5kcyBvbiB0aGUgZGl2ZXJzaXR5IHlvdSBjYW4gaGF2ZSBpbiB0aGUgbXVsdGlwbGUN Cj4gbmV0d29ya3MuDQo+ID4NCj4gPiAgICAgICAgICAgICBBbmQgSSBhZ3JlZSB3aXRoIFN0ZXdh cnQgb24g4oCceW91IGFsd2F5cyBwYXkgYSBwcmljZSBmb3INCj4gPiAgICAgICAgICAgICBiZXR0 ZXIgdGhhbiBiZXN0IGVmZm9ydC7igJ0NCj4gPg0KPiA+ICAgICAgICAgICAgIEJlc3QgcmVnYXJk cywNCj4gPg0KPiA+ICAgICAgICAgICAgIEppZQ0KPiA+DQo+ID4gICAgICAgICAgICAgKkZyb206 KnJ0Z3dnIFttYWlsdG86cnRnd2ctYm91bmNlc0BpZXRmLm9yZw0KPiA+ICAgICAgICAgICAgIDxt YWlsdG86cnRnd2ctYm91bmNlc0BpZXRmLm9yZz5dICpPbiBCZWhhbGYgT2YgKlJvYmVydA0KPiBS YXN6dWsNCj4gPiAgICAgICAgICAgICAqU2VudDoqIFdlZG5lc2RheSwgSnVseSAyNSwgMjAxOCA4 OjI0IFBNDQo+ID4gICAgICAgICAgICAgKlRvOiogQWNlZSBMaW5kZW0gKGFjZWUpIDxhY2VlQGNp c2NvLmNvbQ0KPiA+ICAgICAgICAgICAgIDxtYWlsdG86YWNlZUBjaXNjby5jb20+Pg0KPiA+ICAg ICAgICAgICAgICpDYzoqIHJ0Z3dnQGlldGYub3JnIDxtYWlsdG86cnRnd2dAaWV0Zi5vcmc+DQo+ ID4NCj4gPg0KPiA+ICAgICAgICAgICAgICpTdWJqZWN0OiogUmU6IFZQTiBzZWN1cml0eSB2cyBT RC1XQU4gc2VjdXJpdHkNCj4gPg0KPiA+ICAgICAgICAgICAgIFRydWUgbmV0d29yayBzbGljaW5n IGZvciBJUCBuZXR3b3JrcyBtZWFucyBlaXRoZXIgd2Fpc3Qgb2YNCj4gPiAgICAgICAgICAgICBy ZXNvdXJjZXMgb3IgdmVyeSBzdHJpY3QgbXVsdGktbGV2ZWwgcXVldWluZyBhdCBlYWNoIGhvcCBh bmQNCj4gPiAgICAgICAgICAgICAxMDAlIGluZ3Jlc3MgdHJhZmZpYyBwb2xpY2luZy4gWWV0IHdo aWxlIHRoaXMgaGFzIGEgY2hhbmNlDQo+ID4gICAgICAgICAgICAgdG8gd29yayBkdXJpbmcgbm9y bWFsIG9wZXJhdGlvbiBhdCB0aGUgdGltZSBvZiBldmVuIHJlZ3VsYXINCj4gPiAgICAgICAgICAg ICBmYWlsdXJlcyB0aGlzIGFsbCBwcmV0dHkgbXVjaCBtZWx0cyBsaWtlIGNoZWVzZSBvbiBhIGdv b2QNCj4gPiAgICAgICAgICAgICBzYW5kd2ljaC4NCj4gPg0KPiA+ICAgICAgICAgICAgIEl0IGlz IGdvaW5nIHRvIGJlIHZlcnkgaW50ZXJlc3RpbmcgdG8gY29tcGFyZSBob3cgc2luZ2xlDQo+ID4g ICAgICAgICAgICAgY29tcGxleCBzbGljZWQgbmV0d29yayBjb21wYXJlcyBmb3IgYW55IGVuZCB0 byBlbmQgcm9idXN0DQo+ID4gICAgICAgICAgICAgdHJhbnNwb3J0IGZyb20gTiBub3JtYWwgc2lt cGxlIElQIGJhY2tib25lcyBhbmQgZW5kIHRvDQo+IGVuZA0KPiA+ICAgICAgICAgICAgIFNMQSBi YXNlZCBtaWxsaXNlY29uZCBzd2l0Y2ggb3ZlciBiZXR3ZWVuIG9uZSBhbmQgYW5vdGhlcg0KPiBv bg0KPiA+ICAgICAgICAgICAgIGEgcGVyIGZsb3cgYmFzaXMuIEFsc28gbGV0J3Mgbm90ZSB0aGVu IHdoaWxlIHRoZSBmb3JtZXIgaXMNCj4gPiAgICAgICAgICAgICBzdGlsbCB0byB0aGUgYmVzdCBv ZiBteSBrbm93bGVkZ2UgYSBkcmFmdCB0aGUgbGF0dGVyIGlzDQo+ID4gICAgICAgICAgICAgYWxy ZWFkeSBkZXBsb3llZCBnbG9iYWxseSBpbiAxMDBzIG9mIG5ldHdvcmtzLg0KPiA+DQo+ID4gICAg ICAgICAgICAgQmVzdCwNCj4gPiAgICAgICAgICAgICBSLg0KPiA+DQo+ID4gICAgICAgICAgICAg T24gV2VkLCBKdWwgMjUsIDIwMTggYXQgMToyMSBQTSwgQWNlZSBMaW5kZW0gKGFjZWUpDQo+ID4g ICAgICAgICAgICAgPGFjZWVAY2lzY28uY29tIDxtYWlsdG86YWNlZUBjaXNjby5jb20+PiB3cm90 ZToNCj4gPg0KPiA+ICAgICAgICAgICAgICAgICAqRnJvbTogKnJ0Z3dnIDxydGd3Zy1ib3VuY2Vz QGlldGYub3JnDQo+ID4gICAgICAgICAgICAgICAgIDxtYWlsdG86cnRnd2ctYm91bmNlc0BpZXRm Lm9yZz4+IG9uIGJlaGFsZiBvZiBTdGV3YXJ0DQo+ID4gICAgICAgICAgICAgICAgIEJyeWFudCA8 c3Rld2FydC5icnlhbnRAZ21haWwuY29tDQo+ID4gICAgICAgICAgICAgICAgIDxtYWlsdG86c3Rl d2FydC5icnlhbnRAZ21haWwuY29tPj4NCj4gPiAgICAgICAgICAgICAgICAgKkRhdGU6ICpXZWRu ZXNkYXksIEp1bHkgMjUsIDIwMTggYXQgNTo1NSBBTQ0KPiA+ICAgICAgICAgICAgICAgICAqVG86 ICpSb2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldA0KPiA+ICAgICAgICAgICAgICAgICA8 bWFpbHRvOnJvYmVydEByYXN6dWsubmV0Pj4NCj4gPiAgICAgICAgICAgICAgICAgKkNjOiAqUm91 dGluZyBXRyA8cnRnd2dAaWV0Zi5vcmcNCj4gPG1haWx0bzpydGd3Z0BpZXRmLm9yZz4+DQo+ID4g ICAgICAgICAgICAgICAgICpTdWJqZWN0OiAqUmU6IFZQTiBzZWN1cml0eSB2cyBTRC1XQU4gc2Vj dXJpdHkNCj4gPg0KPiA+ICAgICAgICAgICAgICAgICBPbiAyNS8wNy8yMDE4IDEwOjQwLCBSb2Jl cnQgUmFzenVrIHdyb3RlOg0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICAgICAvKiBBZGp1c3Rp bmcgdGhlIHN1YmplY3QgLi4uICovDQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgIEhlbGxv DQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgIFN0ZXdhcnQsDQo+ID4NCj4gPiAgICAgICAg ICAgICAgICAgICAgIFlvdSBoYXZlIG1hZGUgdGhlIGJlbG93IGNvbW1lbnQgaW4gdGhlIG90aGVy DQo+IHRocmVhZA0KPiA+ICAgICAgICAgICAgICAgICAgICAgd2UgYXJlIGhhdmluZzoNCj4gPg0K PiA+ICAgICAgICAgICAgICAgICAgICAgICAgIEluZGVlZCwgSSB3b3VsZCBoYXZlIGV4cGVjdGVk IHRoaXMgdG8gYmUgb24gYQ0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgIHNlY3VyZSBuZXR3 b3JrIG9mIHNvbWUgc29ydCBlaXRoZXIgcHVyZWx5DQo+ID4gICAgICAgICAgICAgICAgICAgICAg ICAgcHJpdmF0ZSBvciBzb21lIGZvcm0gb2YgVlBOLiBIb3dldmVyLCBJIGFtDQo+IHN1cmUNCj4g PiAgICAgICAgICAgICAgICAgICAgICAgICBJIHJlYWQgaW4geW91ciB0ZXh0IHRoYXQgeW91IHdl cmUNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICBjb25zaWRlcmluZyB1c2luZyB0aGUgUHVi bGljIEludGVybmV0IG11Y2ggaW4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgd2F5 IG9mIFNELVdBTi4NCj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICAgV291bGQgeW91IG1pbmQg YXMgZXh0ZW5zaXZlbHkgYXMgeW91IGNhbiBleHBhbmQNCj4gb24NCj4gPiAgICAgICAgICAgICAg ICAgICAgIHRoZSBhYm92ZSBzdGF0ZW1lbnQgPw0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICAg ICBTcGVjaWZpY2FsbHkgb24gd2hhdCBiYXNpcyBkbyB5b3UgdHJlYXQgc2F5IEwyVlBODQo+IG9y DQo+ID4gICAgICAgICAgICAgICAgICAgICBMM1ZQTiBvZiBuYWtlZCB1bmVuY3J5cHRlZCBwYWNr ZXRzIG9mdGVuDQo+IHRyYXZlbGluZw0KPiA+ICAgICAgICAgICAgICAgICAgICAgb24gdGhlIHZl cnkgc2FtZSBsaW5rcyBhcyB0aGlzICJiYWQiIEludGVybmV0DQo+ID4gICAgICAgICAgICAgICAg ICAgICB0cmFmZmljIHRvIGJlIGV2ZW4gc2xpZ2h0bHkgbW9yZSBzZWN1cmUgdGhlbiBJUFNFQw0K PiA+ICAgICAgICAgICAgICAgICAgICAgb3IgRFRMUyBlbmNyeXB0ZWQgU0QtV0FOIGNhcnJpZWQg ZGF0YSB3aXRoDQo+IGVuZHBvaW50cw0KPiA+ICAgICAgICAgICAgICAgICAgICAgYmVpbmcgdGVy bWluYXRlZCBpbiBwcml2YXRlIHN5c3RlbXMgPw0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICAg ICBUaHgsDQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgIFJvYmVydA0KPiA+DQo+ID4NCj4g PiAgICAgICAgICAgICAgICAgUm9iZXJ0LCBJIHRoaW5rIHRoYXQgeW91IGhhdmUgdG8gdGFrZSBp dCBhcyByZWFkIHRoYXQgYW4NCj4gPiAgICAgICAgICAgICAgICAgYWlyIHRyYWZmaWMgY29udHJv bCBTb0Ygc3lzdGVtIGlzIGVuY3J5cHRpbmcgaXRzDQo+ID4gICAgICAgICAgICAgICAgIHBhY2tl dHMuIElmIGl0IGlzIG5vdCwgdGhlbiBpdCBpcyBjbGVhcmx5IG5vdCBmaXQgZm9yDQo+ID4gICAg ICAgICAgICAgICAgIHB1cnBvc2UuDQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgV2hhdCBjb25j ZXJucyBtZSBpcyB0aGF0IGFuIGFpciB0cmFmZmljIHN5c3RlbSBpcyBvbmUgb2YNCj4gPiAgICAg ICAgICAgICAgICAgdGhlIG1vc3QsIGlmIG5vdCB0aGUgbW9zdCwgaGlnaCBwcm9maWxlIHRhcmdl dHMgaW4gY2l2aWwNCj4gPiAgICAgICAgICAgICAgICAgc29jaWV0eS4gWW91IGdldCByZW1pbmRl ZCBvZiB0aGlzIGVhY2ggdGltZSB5b3UgdHJhdmVsDQo+ID4gICAgICAgICAgICAgICAgIHRvIElF VEYuDQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgVGhlIHRoaW5nIGFib3V0IHNhZmV0eSBvZiBm bGlnaHQgdHJhZmZpYyBpcyB0aGF0IGENCj4gPiAgICAgICAgICAgICAgICAgc3VzdGFpbmVkIGFu ZCBlZmZlY3RpdmUgRERvUyBhdHRhY2sgaGFzIGdsb2JhbCBpbXBhY3QgaW4NCj4gPiAgICAgICAg ICAgICAgICAgYSB3YXkgdGhhdCBmZXcgb3RoZXIgc3VjaCBhdHRhY2tzIGhhdmUuDQo+ID4NCj4g PiAgICAgICAgICAgICAgICAgQSBWUE4gc3lzdGVtIG91Z2h0IHRvIHN1c3RhaW4gcmVzaXN0YW5j ZSB0byBzdWNoIGFuDQo+ID4gICAgICAgICAgICAgICAgIGF0dGFjayBiZXR0ZXIgdGhhbiB0aGUg cHJvcG9zZWQgc3lzdGVtIHdoaWNoIHRyZWF0cw0KPiB0aGUNCj4gPiAgICAgICAgICAgICAgICAg U29GIHRyYWZmaWMgdGhlIHNhbWUgYXMgcmVndWxhciB0cmFmZmljLg0KPiA+DQo+ID4gICAgICAg ICAgICAgICAgIEkgZ3Vlc3MgeW91IGFyZSBtYWtpbmcgYSBjYXNlIGZvciB5b3VyIG5ldHdvcmsg c2xpY2luZw0KPiA+ICAgICAgICAgICAgICAgICB3b3JrIPCfmIkNCj4gPg0KPiA+ICAgICAgICAg ICAgICAgICBBY2VlDQo+ID4NCj4gPg0KPiA+DQo+ID4gICAgICAgICAgICAgICAgIC0gU3Rld2Fy dA0KPiA+DQo+ID4gICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiA+ICAgICAgICAgcnRnd2cgbWFpbGluZyBsaXN0DQo+ID4gICAgICAgICBy dGd3Z0BpZXRmLm9yZyA8bWFpbHRvOnJ0Z3dnQGlldGYub3JnPg0KPiA+ICAgICAgICAgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGd3Zw0KPiA+DQo+ID4NCj4gPg0KPiA+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gcnRn d2cgbWFpbGluZyBsaXN0DQo+ID4gcnRnd2dAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Z3dnDQo+ID4NCg== From nobody Wed Aug 1 08:26:10 2018 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3C3130E37; Wed, 1 Aug 2018 08:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vjkd3ZyMJLHU; Wed, 1 Aug 2018 08:26:04 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7993E1274D0; Wed, 1 Aug 2018 08:26:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 5D3126219EA; Wed, 1 Aug 2018 08:26:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1533137164; bh=e3+1nBOKcfnI960SNKvnidkip6hOESohVmRTsugQ894=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=FZpjiH4eL+dSoD/8XDEga9eF8w4Ywxcc4s47CN8xAJpE7WibDlgEDqamiB0lFHkGL t8SjvuQXBWzwCbBgw9Tx3UHqFmb1znx9GabAxIDVdqRMxTFB2jMcZTCXBpi11RtQqr Dy/fM5bo6Y6UkJv9q8gdsD4CPuPHOBu9QyRWb/SA= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 749ED6219DF; Wed, 1 Aug 2018 08:26:03 -0700 (PDT) To: "Dongjie (Jimmy)" Cc: "TEAS WG (teas@ietf.org)" , "rtgwg@ietf.org" References: <0cb8f15b-7538-500c-dda3-915bf9814f94@gmail.com> <5D10C0C4-B93D-463F-A071-EEA6F35506CD@cisco.com> <76CD132C3ADEF848BD84D028D243C927A71506F6@NKGEML515-MBS.china.huawei.com> <76CD132C3ADEF848BD84D028D243C927A72042AB@NKGEML515-MBS.china.huawei.com> <89653c55-90e0-c52d-bdef-38b312b7feda@joelhalpern.com> <76CD132C3ADEF848BD84D028D243C927A72B1EF7@NKGEML515-MBS.china.huawei.com> From: "Joel M. Halpern" Message-ID: <5c72cc37-c1e0-e806-701d-40a4cf756eee@joelhalpern.com> Date: Wed, 1 Aug 2018 11:26:02 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <76CD132C3ADEF848BD84D028D243C927A72B1EF7@NKGEML515-MBS.china.huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Teas] =?utf-8?b?562U5aSNOiBWUE4gc2VjdXJpdHkgdnMgU0QtV0FOIHNl?= =?utf-8?q?curity?= X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 15:26:08 -0000 I am not disagreeing with a view that network resource allocation requires some visibility to those resources. It is the assertion of a "deep integration" that seems to lack grounding. We know that one can use our existing VPN technologies and tools like diffserv, with suitable admission control and path computation, to provide strong service guarantees to meet SLAs. As others have noted in other presentations, when it comes to the data plane this seems to meet the articulated needs from various fora. Yours, Joel On 8/1/18 11:22 AM, Dongjie (Jimmy) wrote: > This statement is based on the comparison between overlay VPNs and network slices. The resource here refers to various data plane resources that can be allocated to a particular slice (queues, buffer, etc.). Some level of resource isolation is necessary to ensure that service in one slice never interferes with service in another slice. > > May I know what are the requirements you've got? > > Best regards, > Jie > >> -----邮件原件----- >> 发件人: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> 发送时间: 2018年7月30日 23:05 >> 收件人: Dongjie (Jimmy) >> 抄送: TEAS WG (teas@ietf.org) ; rtgwg@ietf.org >> 主题: Re: VPN security vs SD-WAN security >> >> Actually, assuming I understand the statement properly, "deep integration >> with the underlay resource would be necessary" does not appear to be an >> accurate statement derivable from the requirements that I have seen. >> >> Yours, >> Joel >> >> On 7/30/18 8:23 AM, Dongjie (Jimmy) wrote: >>> (Adding TEAS as it is where the VPN+ framework draft is discussed) >>> >>> Hi Robert and Greg, >>> >>> As discussed during the VPN+ presentation in TEAS at IETF 102, the >>> scope is not the internet, as we know it would quite difficult or even >>> impossible to achieve the required guarantee at the scope of internet. >>> >>> And clearly the VPN overlays cannot provide the required guarantee, >>> deep integration with the underlay resource would be necessary. >>> >>> Another aspect we may take into consideration is the factor of >>> overprovisioning. The current network only has one overprovisioning >>> factor, which may not meet the requirement of different >>> services/customers. With network slicing, it is possible to have >>> different overprovisioning policy and factor in different slices. >>> >>> Best regards, >>> >>> Jie >>> >>> *From:*rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of >>> *Robert Raszuk >>> *Sent:* Sunday, July 29, 2018 6:11 AM >>> *To:* Greg Mirsky >>> *Cc:* Dongjie (Jimmy) ; rtgwg@ietf.org >>> *Subject:* Re: VPN security vs SD-WAN security >>> >>> Hey Greg, >>> >>>> >>> >>> would not require global transit and likely be contained within access >>> or, at most, metro domains. >>> >>> That's news to me, but perhaps on the positive side :) I always think >>> WAN .. really wide one ! >>> >>> The separation on "soft" vs "hard" guarantees is eventually all about >>> amount of network robustness and level of over provisioning.  I >>> sincerely hope it will not be yet another EVPN overlay over IP network >>> just painted with different marketing colors. >>> >>> Besides if any customer is serious and actually counts on those >>> guarantees he better purchase two of such services coming from >>> independent operators. That means that to be attractive financially >>> cost of such premium service must not be higher then half of the p2p >>> local fiber or cost of local access to closest IX ports + port >>> subscription in a given MAN where non blocking IX fabric spans given >> geography. >>> >>> It seems to me that at the end of the day the space for those >>> operators wishing to offer hard network slicing is actually pretty >>> narrow, but time will tell ... >>> >>> Rgs, >>> >>> r. >>> >>> On Sat, Jul 28, 2018 at 9:34 PM, Greg Mirsky >> > wrote: >>> >>> Hi Robert, >>> >>> very much agree with all you're saying and find us in violent >>> agreement on "C". Proactive performance monitoring, in my view as >>> well, is the reasonable path to provide "soft" SLA and, to a degree, >>> prevent oversubscription of the network. And that, as you've said, >>> is one way to "assured/guaranteed global IP transit". >>> >>> But I think that there will be demand for "hard" guarantees for >>> URLLC applications. But these, in my view, >>> >>> would not require global transit and likely be contained within >>> access or, at most, metro domains. Because of the limited size of >>> the domain, IntServ may work, though that may be not the most >>> efficient technique. We shall find out. >>> >>> Hence my view on slicing: >>> >>> * different applications will have different requirements and use >>> different degrees of isolation and guarantees; >>> * "soft" slices may not need much of additional standardization >>> and use available VPN technologies in combination with PM OAM >>> for SLA monitoring and assurance; >>> * "hard" slices would span within a single access and/or metro >>> domain. Networking solutions likely will be coupled with >>> architecture and interfaces developed in Multi-access Edge >>> Computing (MEC). >>> >>> Regards, >>> >>> Greg >>> >>> On Sat, Jul 28, 2018 at 6:02 AM, Robert Raszuk >> > wrote: >>> >>> Hi Jie, >>> >>> > (network slicing) is to provide the demanding services with >>> guaranteed performance in a converged network, >>> >>> Foundation of converged IP network is based on statistical >>> multiplexing of traffic demands. As such it is in its principle >>> quite contradictory to "guaranteed" characteristics >>> (performance, delays, jitter, drops -- you name it). >>> >>> Application layers usually deal very well with all of the above >>> I would state - normal characteristics of IP networks.. >>> >>> No doubt there will be those trying to offer some network >>> slicing with guarantees and even those who will buy it. Just >>> like today there are those who offer you L2 circuit between >>> endpoints except such L2 circuit is an emulated one with zero >>> OEM visibility to the IP infrastructure underneath. >>> >>> Now the network slicing is clearly aiming for even more >>> complexity under the hood. And that is not the only problem. The >>> issue is cost. When SP is building the IP network the goal is to >>> mux as many services on it as it simply results in given's SP >>> revenue. Network slicing is promising as potentially just by >>> configuration of few knobs they will be claiming guarantees as >>> RFC says - except RFC will not likely tell you to stop >>> over-provisioning. >>> >>> Unless the idea is to use strict policing with dedicated queuing >>> on active and back paths or do something like RSVP IntServ also >>> on active and backup paths per customer - I really don't think >>> you can really guarantee much. And if you do that the cost would >>> likely grow really steep. >>> >>> So what is IMO the solution for assured/guaranteed global IP >>> transit: >>> >>> *A*  get diversely routed  dark fiber paths between your POPs >>> (can be unprotected) which btw today do not cost that much >>> anymore >>> >>> *B* get diversely routed  optical channels alsol between your >>> POPs (can be unprotected) >>> >>> *C*  use N disjoined by design (single AS Internet providers >>> between your end-points) + proper SD-WAN with active SLA >>> monitoring >>> >>> Clearly I am big supporter of *C* model for reasons discussed on >>> this and few other recent threads. >>> >>> I assume network slicing will try to get into be something >>> between A/B & C but it is bounded up front with the cost of the >>> two. >>> >>> Many thx, >>> >>> Robert. >>> >>> On Sat, Jul 28, 2018 at 9:51 AM, Dongjie (Jimmy) >>> > wrote: >>> >>> Hi Robert, >>> >>> IMO the two approaches are targeting at different use cases >>> and customers. >>> >>> The former (network slicing) is to provide the demanding >>> services with guaranteed performance in a converged >> network, >>> while the latter (switching between multiple paralleled >>> networks) provides the customer with the best performance >>> that is available among those candidates. To me the latter >>> is still some kind of best effort, and as Toerless said, it >>> depends on the diversity you can have in the multiple >> networks. >>> >>> And I agree with Stewart on “you always pay a price for >>> better than best effort.” >>> >>> Best regards, >>> >>> Jie >>> >>> *From:*rtgwg [mailto:rtgwg-bounces@ietf.org >>> ] *On Behalf Of *Robert >> Raszuk >>> *Sent:* Wednesday, July 25, 2018 8:24 PM >>> *To:* Acee Lindem (acee) >> > >>> *Cc:* rtgwg@ietf.org >>> >>> >>> *Subject:* Re: VPN security vs SD-WAN security >>> >>> True network slicing for IP networks means either waist of >>> resources or very strict multi-level queuing at each hop and >>> 100% ingress traffic policing. Yet while this has a chance >>> to work during normal operation at the time of even regular >>> failures this all pretty much melts like cheese on a good >>> sandwich. >>> >>> It is going to be very interesting to compare how single >>> complex sliced network compares for any end to end robust >>> transport from N normal simple IP backbones and end to >> end >>> SLA based millisecond switch over between one and another >> on >>> a per flow basis. Also let's note then while the former is >>> still to the best of my knowledge a draft the latter is >>> already deployed globally in 100s of networks. >>> >>> Best, >>> R. >>> >>> On Wed, Jul 25, 2018 at 1:21 PM, Acee Lindem (acee) >>> > wrote: >>> >>> *From: *rtgwg >> > on behalf of Stewart >>> Bryant >> > >>> *Date: *Wednesday, July 25, 2018 at 5:55 AM >>> *To: *Robert Raszuk >> > >>> *Cc: *Routing WG > > >>> *Subject: *Re: VPN security vs SD-WAN security >>> >>> On 25/07/2018 10:40, Robert Raszuk wrote: >>> >>> /* Adjusting the subject ... */ >>> >>> Hello >>> >>> Stewart, >>> >>> You have made the below comment in the other >> thread >>> we are having: >>> >>> Indeed, I would have expected this to be on a >>> secure network of some sort either purely >>> private or some form of VPN. However, I am >> sure >>> I read in your text that you were >>> considering using the Public Internet much in >>> the way of SD-WAN. >>> >>> Would you mind as extensively as you can expand >> on >>> the above statement ? >>> >>> Specifically on what basis do you treat say L2VPN >> or >>> L3VPN of naked unencrypted packets often >> traveling >>> on the very same links as this "bad" Internet >>> traffic to be even slightly more secure then IPSEC >>> or DTLS encrypted SD-WAN carried data with >> endpoints >>> being terminated in private systems ? >>> >>> Thx, >>> >>> Robert >>> >>> >>> Robert, I think that you have to take it as read that an >>> air traffic control SoF system is encrypting its >>> packets. If it is not, then it is clearly not fit for >>> purpose. >>> >>> What concerns me is that an air traffic system is one of >>> the most, if not the most, high profile targets in civil >>> society. You get reminded of this each time you travel >>> to IETF. >>> >>> The thing about safety of flight traffic is that a >>> sustained and effective DDoS attack has global impact in >>> a way that few other such attacks have. >>> >>> A VPN system ought to sustain resistance to such an >>> attack better than the proposed system which treats >> the >>> SoF traffic the same as regular traffic. >>> >>> I guess you are making a case for your network slicing >>> work 😉 >>> >>> Acee >>> >>> >>> >>> - Stewart >>> >>> _______________________________________________ >>> rtgwg mailing list >>> rtgwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtgwg >>> >>> >>> >>> _______________________________________________ >>> rtgwg mailing list >>> rtgwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtgwg >>> From nobody Thu Aug 2 04:18:59 2018 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03B5130DE6; Thu, 2 Aug 2018 04:18: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSLQaZ0yVW8M; Thu, 2 Aug 2018 04:18:49 -0700 (PDT) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C82C2127333; Thu, 2 Aug 2018 04:18:48 -0700 (PDT) Received: by mail-wm0-x241.google.com with SMTP id s9-v6so2054571wmh.3; Thu, 02 Aug 2018 04:18:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=JWoxgnUkdPG0udLnOMFlRh6MwQHyF2oCo682vuANm/I=; b=qi166f8lFZTkbbqJql+Hby3FQey19WygSMYvWpPfR847rVnAwZ9XtZEvEgPfLe8eWZ 6MqE5XcaMuB6BavOYrStfBC0Sk+rvEqKDn3Si+F222ETzmqAUjXZYD+mcbBYHWCs2Pnx Iu7PNpUTjoZcT5J6YGJb8UeTPCof2ICvD7cpsMIPbEerUSetYw5nS5n+b5rZFu5adaaZ qEIr8HNgM/LDm1FtXyY7p2zCv+M19TiKTra0/kTRtE3dIYYpPw1oT4sc1cgkPD6HM9Bo dO4AmC76FgvK3ttaqJPPCWZq0EdLaIfoKz9f/USw5eRZ9qls2ddfURUQzdjK6RyxLVwV 1ZTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=JWoxgnUkdPG0udLnOMFlRh6MwQHyF2oCo682vuANm/I=; b=Nv39jZWN5rug9NiQkH/60iFh34lADF8uw0lXb8m4T3J1bVr8LgQa8QXq9IqK2X5OJ9 WI8XeK9abL28Pz7WYqBX94tN1knHPb9o1lb0bnNAAozC7rS9s7ByV/sBIPruy+Qb+9Hx NiyVk9upV7SAIaldsO2HZP3TCGuWjZtM81kEn9G5S52LLuchwayMfiU/OM7yTbD2k7EU rjen1++TogLK5OSrROamfNvNMSEEimVZv99ZRF7ciFc0Irl4e7RrUzDM66ZV/xg4eej9 fz5hoq2SJxPD3bZBejrIx+K721f0o7JzkU6sAb9I17AMxvlCpztzlhoLm0AyIygkMmsc hewg== X-Gm-Message-State: AOUpUlFi4tQd5kGv6BEjwZMjSJv1edpeO8mrm4A8in1TC20MVk1+HWmH lOVypL+GUhz01WGYuOG2m67wBFUiHFI= X-Google-Smtp-Source: AAOMgpcyjctunN3WPi8PoBBEgOAv0InjAz/IrQzZX//SMlqRFASoj2XEksB53phCaj4ggHrgAFNnRA== X-Received: by 2002:a1c:1bc2:: with SMTP id b185-v6mr1906896wmb.160.1533208726853; Thu, 02 Aug 2018 04:18:46 -0700 (PDT) Received: from [192.168.2.105] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id e12-v6sm1346848wru.89.2018.08.02.04.18.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Aug 2018 04:18:46 -0700 (PDT) To: "Joel M. Halpern" , "Dongjie (Jimmy)" Cc: "TEAS WG (teas@ietf.org)" , "rtgwg@ietf.org" References: <0cb8f15b-7538-500c-dda3-915bf9814f94@gmail.com> <5D10C0C4-B93D-463F-A071-EEA6F35506CD@cisco.com> <76CD132C3ADEF848BD84D028D243C927A71506F6@NKGEML515-MBS.china.huawei.com> <76CD132C3ADEF848BD84D028D243C927A72042AB@NKGEML515-MBS.china.huawei.com> <89653c55-90e0-c52d-bdef-38b312b7feda@joelhalpern.com> <76CD132C3ADEF848BD84D028D243C927A72B1EF7@NKGEML515-MBS.china.huawei.com> <5c72cc37-c1e0-e806-701d-40a4cf756eee@joelhalpern.com> From: Stewart Bryant Message-ID: <644649c7-a5b5-9e78-8749-4a2109566cf9@gmail.com> Date: Thu, 2 Aug 2018 12:18:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <5c72cc37-c1e0-e806-701d-40a4cf756eee@joelhalpern.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [Teas] =?utf-8?b?562U5aSNOiBWUE4gc2VjdXJpdHkgdnMgU0QtV0FOIHNl?= =?utf-8?q?curity?= X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 11:18:52 -0000 On 01/08/2018 16:26, Joel M. Halpern wrote: > I am not disagreeing with a view that network resource allocation > requires some visibility to those resources. > It is the assertion of a "deep integration" that seems to lack grounding. > > We know that one can use our existing VPN technologies and tools like > diffserv, with suitable admission control and path computation, to > provide strong service guarantees to meet SLAs. As others have noted > in other presentations, when it comes to the data plane this seems to > meet the articulated needs from various fora. > Hi Joel, We can certainly get a long way with those tools for "conventional" applications. However, as we support the sort of applications that look for a deterministic networking class of SLA, then I am concerned that we need to map the traffic to dedicated resources in more detail than we currently do through the diffserv mechanism. What we do at the moment with diffserv is a mapping of packets to resources, but in practise we limit those resources to ingress and egress queues with the queue management algorithm out of scope. I am not convinced this is adequate for the future, and think that we need to start to consider CPU/NPU cores, queue algorithms, and maybe other resources. I am also concerned that the number of diffserv code points available in MPLS is going to be insufficient. Of course what we know today from experience is based on the applications that can run on the network infrastructure that we have today. That is a self limiting situation. We are designing DETNET because this model is inadequate for some classes of application that would like to run over a more general network. What we are doing with VPN+ is to integrate DETNET into a VPN structure alongside classic VPNs. - Stewart > Yours, > Joel > > On 8/1/18 11:22 AM, Dongjie (Jimmy) wrote: >> This statement is based on the comparison between overlay VPNs and >> network slices. The resource here refers to various data plane >> resources that can be allocated to a particular slice (queues, >> buffer, etc.). Some level of resource isolation is necessary to >> ensure that service in one slice never interferes with service in >> another slice. >> >> May I know what are the requirements you've got? >> >> Best regards, >> Jie >> >>> -----邮件原件----- >>> 发件人: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>> 发送时间: 2018年7月30日 23:05 >>> 收件人: Dongjie (Jimmy) >>> 抄送: TEAS WG (teas@ietf.org) ; rtgwg@ietf.org >>> 主题: Re: VPN security vs SD-WAN security >>> >>> Actually, assuming I understand the statement properly, "deep >>> integration >>> with the underlay resource would be necessary" does not appear to be an >>> accurate statement derivable from the requirements that I have seen. >>> >>> Yours, >>> Joel >>> >>> On 7/30/18 8:23 AM, Dongjie (Jimmy) wrote: >>>> (Adding TEAS as it is where the VPN+ framework draft is discussed) >>>> >>>> Hi Robert and Greg, >>>> >>>> As discussed during the VPN+ presentation in TEAS at IETF 102, the >>>> scope is not the internet, as we know it would quite difficult or even >>>> impossible to achieve the required guarantee at the scope of internet. >>>> >>>> And clearly the VPN overlays cannot provide the required guarantee, >>>> deep integration with the underlay resource would be necessary. >>>> >>>> Another aspect we may take into consideration is the factor of >>>> overprovisioning. The current network only has one overprovisioning >>>> factor, which may not meet the requirement of different >>>> services/customers. With network slicing, it is possible to have >>>> different overprovisioning policy and factor in different slices. >>>> >>>> Best regards, >>>> >>>> Jie >>>> >>>> *From:*rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of >>>> *Robert Raszuk >>>> *Sent:* Sunday, July 29, 2018 6:11 AM >>>> *To:* Greg Mirsky >>>> *Cc:* Dongjie (Jimmy) ; rtgwg@ietf.org >>>> *Subject:* Re: VPN security vs SD-WAN security >>>> >>>> Hey Greg, >>>> >>>>> >>>> >>>> would not require global transit and likely be contained within access >>>> or, at most, metro domains. >>>> >>>> That's news to me, but perhaps on the positive side :) I always think >>>> WAN .. really wide one ! >>>> >>>> The separation on "soft" vs "hard" guarantees is eventually all about >>>> amount of network robustness and level of over provisioning.  I >>>> sincerely hope it will not be yet another EVPN overlay over IP network >>>> just painted with different marketing colors. >>>> >>>> Besides if any customer is serious and actually counts on those >>>> guarantees he better purchase two of such services coming from >>>> independent operators. That means that to be attractive financially >>>> cost of such premium service must not be higher then half of the p2p >>>> local fiber or cost of local access to closest IX ports + port >>>> subscription in a given MAN where non blocking IX fabric spans given >>> geography. >>>> >>>> It seems to me that at the end of the day the space for those >>>> operators wishing to offer hard network slicing is actually pretty >>>> narrow, but time will tell ... >>>> >>>> Rgs, >>>> >>>> r. >>>> >>>> On Sat, Jul 28, 2018 at 9:34 PM, Greg Mirsky >>> > wrote: >>>> >>>>      Hi Robert, >>>> >>>>      very much agree with all you're saying and find us in violent >>>>      agreement on "C". Proactive performance monitoring, in my view as >>>>      well, is the reasonable path to provide "soft" SLA and, to a >>>> degree, >>>>      prevent oversubscription of the network. And that, as you've >>>> said, >>>>      is one way to "assured/guaranteed global IP transit". >>>> >>>>      But I think that there will be demand for "hard" guarantees for >>>>      URLLC applications. But these, in my view, >>>> >>>>      would not require global transit and likely be contained within >>>>      access or, at most, metro domains. Because of the limited size of >>>>      the domain, IntServ may work, though that may be not the most >>>>      efficient technique. We shall find out. >>>> >>>>      Hence my view on slicing: >>>> >>>>        * different applications will have different requirements >>>> and use >>>>          different degrees of isolation and guarantees; >>>>        * "soft" slices may not need much of additional standardization >>>>          and use available VPN technologies in combination with PM OAM >>>>          for SLA monitoring and assurance; >>>>        * "hard" slices would span within a single access and/or metro >>>>          domain. Networking solutions likely will be coupled with >>>>          architecture and interfaces developed in Multi-access Edge >>>>          Computing (MEC). >>>> >>>>      Regards, >>>> >>>>      Greg >>>> >>>>      On Sat, Jul 28, 2018 at 6:02 AM, Robert Raszuk >>>      > wrote: >>>> >>>>          Hi Jie, >>>> >>>>          > (network slicing) is to provide the demanding services with >>>> guaranteed performance in a converged network, >>>> >>>>          Foundation of converged IP network is based on statistical >>>>          multiplexing of traffic demands. As such it is in its >>>> principle >>>>          quite contradictory to "guaranteed" characteristics >>>>          (performance, delays, jitter, drops -- you name it). >>>> >>>>          Application layers usually deal very well with all of the >>>> above >>>>          I would state - normal characteristics of IP networks.. >>>> >>>>          No doubt there will be those trying to offer some network >>>>          slicing with guarantees and even those who will buy it. Just >>>>          like today there are those who offer you L2 circuit between >>>>          endpoints except such L2 circuit is an emulated one with zero >>>>          OEM visibility to the IP infrastructure underneath. >>>> >>>>          Now the network slicing is clearly aiming for even more >>>>          complexity under the hood. And that is not the only >>>> problem. The >>>>          issue is cost. When SP is building the IP network the goal >>>> is to >>>>          mux as many services on it as it simply results in given's SP >>>>          revenue. Network slicing is promising as potentially just by >>>>          configuration of few knobs they will be claiming >>>> guarantees as >>>>          RFC says - except RFC will not likely tell you to stop >>>>          over-provisioning. >>>> >>>>          Unless the idea is to use strict policing with dedicated >>>> queuing >>>>          on active and back paths or do something like RSVP IntServ >>>> also >>>>          on active and backup paths per customer - I really don't >>>> think >>>>          you can really guarantee much. And if you do that the cost >>>> would >>>>          likely grow really steep. >>>> >>>>          So what is IMO the solution for assured/guaranteed global IP >>>>          transit: >>>> >>>>          *A*  get diversely routed  dark fiber paths between your POPs >>>>          (can be unprotected) which btw today do not cost that much >>>> anymore >>>> >>>>          *B* get diversely routed  optical channels alsol between your >>>>          POPs (can be unprotected) >>>> >>>>          *C*  use N disjoined by design (single AS Internet providers >>>>          between your end-points) + proper SD-WAN with active SLA >>>> monitoring >>>> >>>>          Clearly I am big supporter of *C* model for reasons >>>> discussed on >>>>          this and few other recent threads. >>>> >>>>          I assume network slicing will try to get into be something >>>>          between A/B & C but it is bounded up front with the cost >>>> of the >>>>          two. >>>> >>>>          Many thx, >>>> >>>>          Robert. >>>> >>>>          On Sat, Jul 28, 2018 at 9:51 AM, Dongjie (Jimmy) >>>>          > wrote: >>>> >>>>              Hi Robert, >>>> >>>>              IMO the two approaches are targeting at different use >>>> cases >>>>              and customers. >>>> >>>>              The former (network slicing) is to provide the demanding >>>>              services with guaranteed performance in a converged >>> network, >>>>              while the latter (switching between multiple paralleled >>>>              networks) provides the customer with the best performance >>>>              that is available among those candidates. To me the >>>> latter >>>>              is still some kind of best effort, and as Toerless >>>> said, it >>>>              depends on the diversity you can have in the multiple >>> networks. >>>> >>>>              And I agree with Stewart on “you always pay a price for >>>>              better than best effort.” >>>> >>>>              Best regards, >>>> >>>>              Jie >>>> >>>>              *From:*rtgwg [mailto:rtgwg-bounces@ietf.org >>>>              ] *On Behalf Of *Robert >>> Raszuk >>>>              *Sent:* Wednesday, July 25, 2018 8:24 PM >>>>              *To:* Acee Lindem (acee) >>>              > >>>>              *Cc:* rtgwg@ietf.org >>>> >>>> >>>>              *Subject:* Re: VPN security vs SD-WAN security >>>> >>>>              True network slicing for IP networks means either >>>> waist of >>>>              resources or very strict multi-level queuing at each >>>> hop and >>>>              100% ingress traffic policing. Yet while this has a >>>> chance >>>>              to work during normal operation at the time of even >>>> regular >>>>              failures this all pretty much melts like cheese on a good >>>>              sandwich. >>>> >>>>              It is going to be very interesting to compare how single >>>>              complex sliced network compares for any end to end robust >>>>              transport from N normal simple IP backbones and end to >>> end >>>>              SLA based millisecond switch over between one and another >>> on >>>>              a per flow basis. Also let's note then while the >>>> former is >>>>              still to the best of my knowledge a draft the latter is >>>>              already deployed globally in 100s of networks. >>>> >>>>              Best, >>>>              R. >>>> >>>>              On Wed, Jul 25, 2018 at 1:21 PM, Acee Lindem (acee) >>>>              > wrote: >>>> >>>>                  *From: *rtgwg >>>                  > on behalf of Stewart >>>>                  Bryant >>>                  > >>>>                  *Date: *Wednesday, July 25, 2018 at 5:55 AM >>>>                  *To: *Robert Raszuk >>>                  > >>>>                  *Cc: *Routing WG >> > >>>>                  *Subject: *Re: VPN security vs SD-WAN security >>>> >>>>                  On 25/07/2018 10:40, Robert Raszuk wrote: >>>> >>>>                      /* Adjusting the subject ... */ >>>> >>>>                      Hello >>>> >>>>                      Stewart, >>>> >>>>                      You have made the below comment in the other >>> thread >>>>                      we are having: >>>> >>>>                          Indeed, I would have expected this to be on a >>>>                          secure network of some sort either purely >>>>                          private or some form of VPN. However, I am >>> sure >>>>                          I read in your text that you were >>>>                          considering using the Public Internet much in >>>>                          the way of SD-WAN. >>>> >>>>                      Would you mind as extensively as you can expand >>> on >>>>                      the above statement ? >>>> >>>>                      Specifically on what basis do you treat say L2VPN >>> or >>>>                      L3VPN of naked unencrypted packets often >>> traveling >>>>                      on the very same links as this "bad" Internet >>>>                      traffic to be even slightly more secure then >>>> IPSEC >>>>                      or DTLS encrypted SD-WAN carried data with >>> endpoints >>>>                      being terminated in private systems ? >>>> >>>>                      Thx, >>>> >>>>                      Robert >>>> >>>> >>>>                  Robert, I think that you have to take it as read >>>> that an >>>>                  air traffic control SoF system is encrypting its >>>>                  packets. If it is not, then it is clearly not fit for >>>>                  purpose. >>>> >>>>                  What concerns me is that an air traffic system is >>>> one of >>>>                  the most, if not the most, high profile targets in >>>> civil >>>>                  society. You get reminded of this each time you >>>> travel >>>>                  to IETF. >>>> >>>>                  The thing about safety of flight traffic is that a >>>>                  sustained and effective DDoS attack has global >>>> impact in >>>>                  a way that few other such attacks have. >>>> >>>>                  A VPN system ought to sustain resistance to such an >>>>                  attack better than the proposed system which treats >>> the >>>>                  SoF traffic the same as regular traffic. >>>> >>>>                  I guess you are making a case for your network >>>> slicing >>>>                  work 😉 >>>> >>>>                  Acee >>>> >>>> >>>> >>>>                  - Stewart >>>> >>>>          _______________________________________________ >>>>          rtgwg mailing list >>>>          rtgwg@ietf.org >>>>          https://www.ietf.org/mailman/listinfo/rtgwg >>>> >>>> >>>> >>>> _______________________________________________ >>>> rtgwg mailing list >>>> rtgwg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtgwg >>>> > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Thu Aug 2 05:07:12 2018 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB158124BE5; Thu, 2 Aug 2018 05:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de header.b=tEcnjyEk; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=H9JMOiDv 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 U12OMqD5mwWO; Thu, 2 Aug 2018 05:07:01 -0700 (PDT) Received: from mailout24.telekom.de (MAILOUT24.telekom.de [80.149.113.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF29B12426A; Thu, 2 Aug 2018 05:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1533211621; x=1564747621; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7W5uCj6/uSszSNn5c1sxgO3FsCEDGDXRxhZcAtzx5MM=; b=tEcnjyEk69KUUgHkrOHY7PyWB8sL/n100+wcftJ6gZVad82X3hxNbZxj KBbvwKF/jGkPP5/kJ/E8eLXcZ4cl3A5wmGUflsyjnZayRTwk0SeoDILnW 4Xfm+rf8QBHt8EHPTpL9XUHbelq7T0A7UZZjkBtDus7ZC4Xd4ucrWFPUS 8MYF5ffwzd2NMtLOQLBHjr2gT/g6A5RvXfmgPeW1bEtn4GEkBbRlbkjF9 Vl9qg8RB9MWgObAiJNmbPpeiXR1gD/t80JZSdXBrYvdZ6iAH7e+x4ynOY I1MSpjd3k/CRAImRohlZTGkKluxjc3B/phSV93qEjm9CivA/buVFKRffk g==; Received: from qde9xy.de.t-internal.com ([10.171.254.32]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Aug 2018 14:06:56 +0200 X-IronPort-AV: E=Sophos;i="5.51,435,1526335200"; d="scan'208";a="96714392" Received: from he105647.emea1.cds.t-internal.com ([10.169.119.61]) by QDE9Y1.de.t-internal.com with ESMTP/TLS/AES256-SHA; 02 Aug 2018 14:06:55 +0200 Received: from HE105660.EMEA1.cds.t-internal.com (10.169.119.56) by HE105647.emea1.cds.t-internal.com (10.169.119.61) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 2 Aug 2018 14:06:51 +0200 Received: from HE104163.emea1.cds.t-internal.com (10.171.40.38) by HE105660.EMEA1.cds.t-internal.com (10.169.119.56) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Thu, 2 Aug 2018 14:06:51 +0200 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.16) by O365mail05.telekom.de (172.30.0.230) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 2 Aug 2018 14:06:59 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.onmicrosoft.de; s=selector1-telekom-onmicrosoft-de; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7W5uCj6/uSszSNn5c1sxgO3FsCEDGDXRxhZcAtzx5MM=; b=H9JMOiDvakOdaB+UimcqYIShKmIsKiUhFu82pZw1MaHir+QEx5wcf3/JDoVux3d5f8r9cAe8ehxpWRJXi+Yt8m1kRW1i+FNM+iqYI08hBJVA1TSphhdUkbkRX1+FwQyK6w3tIyI6C+WawnsuRaRqhaEuMqYPYCWRhpWNYn5Lxco= Received: from FRAPR01MB0113.DEUPRD01.PROD.OUTLOOK.DE (10.158.130.143) by FRAPR01MB0113.DEUPRD01.PROD.OUTLOOK.DE (10.158.130.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1017.14; Thu, 2 Aug 2018 12:06:50 +0000 Received: from FRAPR01MB0113.DEUPRD01.PROD.OUTLOOK.DE ([fe80::e8f7:3190:beb6:eee2]) by FRAPR01MB0113.DEUPRD01.PROD.OUTLOOK.DE ([fe80::e8f7:3190:beb6:eee2%5]) with mapi id 15.20.1017.010; Thu, 2 Aug 2018 12:06:50 +0000 From: To: CC: , Thread-Topic: =?utf-8?B?W1RlYXNdIOetlOWkjTogVlBOIHNlY3VyaXR5IHZzIFNELVdBTiBzZWN1cml0?= =?utf-8?Q?y?= Thread-Index: AQHUKlKmQsM4w1IkoEaJjjbC4+zUV6SsUlJg Date: Thu, 2 Aug 2018 12:06:50 +0000 Message-ID: References: <0cb8f15b-7538-500c-dda3-915bf9814f94@gmail.com> <5D10C0C4-B93D-463F-A071-EEA6F35506CD@cisco.com> <76CD132C3ADEF848BD84D028D243C927A71506F6@NKGEML515-MBS.china.huawei.com> <76CD132C3ADEF848BD84D028D243C927A72042AB@NKGEML515-MBS.china.huawei.com> <89653c55-90e0-c52d-bdef-38b312b7feda@joelhalpern.com> <76CD132C3ADEF848BD84D028D243C927A72B1EF7@NKGEML515-MBS.china.huawei.com> <5c72cc37-c1e0-e806-701d-40a4cf756eee@joelhalpern.com> <644649c7-a5b5-9e78-8749-4a2109566cf9@gmail.com> In-Reply-To: <644649c7-a5b5-9e78-8749-4a2109566cf9@gmail.com> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ruediger.Geib@telekom.de; x-originating-ip: [164.19.3.235] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0113; 6:EFHwp7uk0wrE+P293I3nj+3KWuBoFagFeUHnixkjKpIiKxb86h9CGIAw/AW7mjQmsDryFuo6FnJ8NBCJhriudT1S53M+O0YtRJqUS5k3BIxULgFqeKW9BLlyVzw4XDZE+crzOxbyjZ7xDfMSZ9xM7B33wsFC605USaVT8iC47M5MjBdlbHUnvMt2opt/yyw9PyxdROhwWHinyxCONBP6zpdclCP+A1VP9VRFHfNaFqORhR4a0+WbZvPlN9xfgBz7VrSOsacNu86GvUbaAb3q3ci9qqhmoLkF6+IOyFnNJGXD0E4pdYbLDNilr/yODZAfes3cV8xMJV+HYnhOW5JESjpCUyhg8DA0bjmfUIwTkHTb95o/JDQDiy17YUBe20myH9KBhupbH1yxKorXEPDyP3HTzmCTrxo14QtM8k09q+zd9Hs5L4/TYC1EF3u42I0HDvexgssrYQgvnREdwt1HWA==; 5:jEXvPhVsE+vKcIHCdYRPo/4iGMq8p5V37knqEqOuWtgF6PSsqq5k864yGzk9PbA92E21ZxH01s2NsI7mukLJxrLVIu2XmvWeUhd/VAC8WbW0J1TtqJ3cEN73Rg6O4OdgIa0FyoqpZIIJ4HZ2Bkcqjlj0bf9JlRQDmGmHof7miMY=; 7:vWckjXpfjQlr6Yc2FmoaUwQXhqw53opFJpfCyNhj5i3d0PWihWH5E7uLyWssP3TtY2j0PK2jalyEJoHSgj4BmT3b4y5RaBiYzTzRtvEhWe4BISIPOSBTC1YRoc/fuFfOb+vqMnXymrGz/ay31odXwbfHVFQV80aDyOM1LpHZEBMmHYu7Etx8uyt2ll0Eipcf98sxm1m2R+e1WsTBuF/AuSDT3ZufseLRGh3BCw6tPP1Fs56odlVbTg1LCcqBuUHR x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 02ed5ae3-ff70-463b-ae63-08d5f8706ddc x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:FRAPR01MB0113; x-ms-traffictypediagnostic: FRAPR01MB0113: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(72170088055959)(192374486261705)(50582790962513)(85827821059158)(95692535739014)(12901024606220); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3002001)(3231311)(944501410)(52105095)(10201501046)(93006095)(93001095)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:FRAPR01MB0113; BCL:0; PCL:0; RULEID:; SRVR:FRAPR01MB0113; x-forefront-prvs: 07521929C1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(136003)(366004)(396003)(51444003)(37854004)(189003)(199004)(85182001)(2906002)(53936002)(966005)(75402003)(72206003)(478600001)(53946003)(66066001)(15650500001)(9686003)(5250100002)(5660300001)(33656002)(55016002)(14454004)(6306002)(86362001)(6916009)(11346002)(8936002)(85202003)(446003)(305945005)(476003)(6116002)(3846002)(224303003)(2900100001)(53546011)(7736002)(102836004)(486006)(186003)(106356001)(26005)(105586002)(256004)(14444005)(76176011)(52396003)(74482002)(39060400002)(93886005)(7696005)(4326008)(54906003)(97736004)(68736007)(81156014)(81166006)(316002)(777600001); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0113; H:FRAPR01MB0113.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) x-microsoft-antispam-message-info: fCnohrXgNPAOU5VQrSL7WnpiMF6wvxOkPQSn7rXhMNdDz+TiH1C6slZ6QB+oa1vUQiXzyXCNXE0T4cbcBaCpXOER8E5oOPN+4grt09jcDYs1FKVEWY6Po6uTGkkhkMGOFbd6XM+HLPTaVwhgEYMPsiEqeb9MpNuJy6V7bqhhpmcYoXUqtzt3U9Be53IMnb8MH+zrJ8TSNiUscLx9kS0+VBi8V0HkCFM5LyMQqtuHPerm54wlATZob8Ek63AJAtLoxMbRgQ4ucUz3JmG1pyMoV/r+JaR+kXjwCM9D6lHj9aYt9SvyHPWbEu5MEAyKst9Xa5jg4Z+oYJuTEDTwc1JOBawKlv1tzSN0C/mvTri1Kkk= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 02ed5ae3-ff70-463b-ae63-08d5f8706ddc X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2018 12:06:50.5060 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB0113 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [Teas] =?utf-8?b?562U5aSNOiBWUE4gc2VjdXJpdHkgdnMgU0QtV0FOIHNl?= =?utf-8?q?curity?= X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 12:07:06 -0000 U3Rld2FydCwNCg0KSSdkIGFwcHJlY2lhdGUgYSBkaXNjdXNzaW9uIGJhc2VkIG9uIG9wZXJhdGlv bmFsIGV4cGVyaWVuY2UuIEluIHdoaWNoIERpZmZzZXJ2IHN1cHBvcnRlZCBuZXR3b3JrIGRpZCB3 aGljaCBhcHBsaWNhdGlvbiBmYWlsIGR1ZSB0byBhIGxhY2sgb2Ygc3VpdGFibGUgc2NoZWR1bGlu ZyBvciBkdWUgdG8gYSBsYWNrIG9mIGNvZGVwb2ludHMsIHdoaWNoIHdvdWxkIGhhdmUgYmVlbiB3 b3JraW5nIHByb3Blcmx5IG9uIHRoZSBzYW1lIG5ldHdvcmsgd2l0aCBEZXRuZXQgYW5kIG1vcmUg Y29kZXBvaW50cz8gSSdkIGJlIGhhcHB5LCBpZiB5b3Ugd2VyZSBhYmxlIHRvIHByb3ZpZGUgYSBs aW5rIHRvIGEgcHJlc2VudGF0aW9uLg0KDQpJJ3ZlIHN0YXJ0ZWQgbXkgUW9TIGNhcmVlciB3aXRo IEFUTSwgYSB0ZWNobm9sb2d5IG9mZmVyaW5nIGRlZGljYXRlZCBRb1MgbmV0d29yayByZXNvdXJj ZXMuIFNwYXJlIGNhcGFjaXRpZXMgd2l0aCBhIG5ldHdvcmstZnVsbHktYm9va2VkIGluZGljYXRp b24gd2VyZSB0aGUgZmlyc3QgbGVzc29uIEkgbGVhcm5lZCwgYW5kIHRoaXMgY29tYmluYXRpb24g dHVybmVkIG91dCB0byBiZSBiYWQgd2hlbmV2ZXIgSSBlbmNvdW50ZXJlZCBpdCBmcm9tIHRoZW4g b24uIE15IHRha2Ugb24gRGlmZnNlcnYgaXMsIHRoYXQgaXQgaXMgdXNlZnVsIHRvIHByb3RlY3Qg Y2VydGFpbiB0cmFmZmljIGluIHRoZSBjYXNlIG9mIG5vdCBmb3Jlc2VlbiBuZXR3b3JraW5nIGNv bmRpdGlvbnMuIFRoYXQgbWVhbnMsIGluIDk5LC4uLi4lIG9mIHRoZSB0aW1lLCB0b2RheXMgRGlm ZnNlcnYgaXNuJ3QgcmVxdWlyZWQsIGJlY2F1c2UgdGhlcmUncyBubyBjb25nZXN0aW9uLiANCg0K WW91IHNlZW0gdG8gaGVhZCBmb3IgZ2VuZXJpYyBzb2x1dGlvbnMsIGFwcGxpY2FibGUgaW4gYWxs IHBhcnRzIG9mIHRoZSBJbnRlcm5ldC4gSSBkb24ndCB1bmRlcnN0YW5kIHdoYXQgdGhlIGJlbmVm aXQgb2YgZGVkaWNhdGVkIHJlc291cmNlcyB3b3VsZCBiZSwgZ2l2ZW4gdGhleSBhcmUgcmVxdWly ZWQgZW5kLXRvLWVuZC4gSSBleGN1c2UgaWYgSSBtaXNzZWQgYSBzdGF0ZW1lbnQgdGhhdCB0aGUg YXBwcm9hY2ggeW91IHByb3Bvc2UgaXMgbGltaXRlZCB0byBzcGVjaWZpYyBpbnN0YW5jZXMgb3Ig c2VjdGlvbnMgb2YgdGhlIEludGVybmV0Lg0KDQpSZWdhcmRzLA0KDQpSdWVkaWdlcg0KDQoNCi0t LS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0NClZvbjogcnRnd2cgW21haWx0bzpydGd3 Zy1ib3VuY2VzQGlldGYub3JnXSBJbSBBdWZ0cmFnIHZvbiBTdGV3YXJ0IEJyeWFudA0KR2VzZW5k ZXQ6IERvbm5lcnN0YWcsIDIuIEF1Z3VzdCAyMDE4IDEzOjE5DQpBbjogSm9lbCBNLiBIYWxwZXJu IDxqbWhAam9lbGhhbHBlcm4uY29tPjsgRG9uZ2ppZSAoSmltbXkpIDxqaWUuZG9uZ0BodWF3ZWku Y29tPg0KQ2M6IFRFQVMgV0cgKHRlYXNAaWV0Zi5vcmcpIDx0ZWFzQGlldGYub3JnPjsgcnRnd2dA aWV0Zi5vcmcNCkJldHJlZmY6IFJlOiBbVGVhc10g562U5aSNOiBWUE4gc2VjdXJpdHkgdnMgU0Qt V0FOIHNlY3VyaXR5DQoNCg0KDQpPbiAwMS8wOC8yMDE4IDE2OjI2LCBKb2VsIE0uIEhhbHBlcm4g d3JvdGU6DQo+IEkgYW0gbm90IGRpc2FncmVlaW5nIHdpdGggYSB2aWV3IHRoYXQgbmV0d29yayBy ZXNvdXJjZSBhbGxvY2F0aW9uIA0KPiByZXF1aXJlcyBzb21lIHZpc2liaWxpdHkgdG8gdGhvc2Ug cmVzb3VyY2VzLg0KPiBJdCBpcyB0aGUgYXNzZXJ0aW9uIG9mIGEgImRlZXAgaW50ZWdyYXRpb24i IHRoYXQgc2VlbXMgdG8gbGFjayBncm91bmRpbmcuDQo+DQo+IFdlIGtub3cgdGhhdCBvbmUgY2Fu IHVzZSBvdXIgZXhpc3RpbmcgVlBOIHRlY2hub2xvZ2llcyBhbmQgdG9vbHMgbGlrZSANCj4gZGlm ZnNlcnYsIHdpdGggc3VpdGFibGUgYWRtaXNzaW9uIGNvbnRyb2wgYW5kIHBhdGggY29tcHV0YXRp b24sIHRvIA0KPiBwcm92aWRlIHN0cm9uZyBzZXJ2aWNlIGd1YXJhbnRlZXMgdG8gbWVldCBTTEFz LiBBcyBvdGhlcnMgaGF2ZSBub3RlZCANCj4gaW4gb3RoZXIgcHJlc2VudGF0aW9ucywgd2hlbiBp dCBjb21lcyB0byB0aGUgZGF0YSBwbGFuZSB0aGlzIHNlZW1zIHRvIA0KPiBtZWV0IHRoZSBhcnRp Y3VsYXRlZCBuZWVkcyBmcm9tIHZhcmlvdXMgZm9yYS4NCj4NCkhpIEpvZWwsDQoNCldlIGNhbiBj ZXJ0YWlubHkgZ2V0IGEgbG9uZyB3YXkgd2l0aCB0aG9zZSB0b29scyBmb3IgImNvbnZlbnRpb25h bCIgDQphcHBsaWNhdGlvbnMuDQoNCkhvd2V2ZXIsIGFzIHdlIHN1cHBvcnQgdGhlIHNvcnQgb2Yg YXBwbGljYXRpb25zIHRoYXQgbG9vayBmb3IgYSBkZXRlcm1pbmlzdGljIG5ldHdvcmtpbmcgY2xh c3Mgb2YgU0xBLCB0aGVuIEkgYW0gY29uY2VybmVkIHRoYXQgd2UgbmVlZCB0byBtYXAgdGhlIHRy YWZmaWMgdG8gZGVkaWNhdGVkIHJlc291cmNlcyBpbiBtb3JlIGRldGFpbCB0aGFuIHdlIGN1cnJl bnRseSBkbyB0aHJvdWdoIHRoZSBkaWZmc2VydiBtZWNoYW5pc20uDQoNCldoYXQgd2UgZG8gYXQg dGhlIG1vbWVudCB3aXRoIGRpZmZzZXJ2IGlzIGEgbWFwcGluZyBvZiBwYWNrZXRzIHRvIHJlc291 cmNlcywgYnV0IGluIHByYWN0aXNlIHdlIGxpbWl0IHRob3NlIHJlc291cmNlcyB0byBpbmdyZXNz IGFuZCBlZ3Jlc3MgcXVldWVzIHdpdGggdGhlIHF1ZXVlIG1hbmFnZW1lbnQgYWxnb3JpdGhtIG91 dCBvZiBzY29wZS4gSSBhbSBub3QgY29udmluY2VkIHRoaXMgaXMgYWRlcXVhdGUgZm9yIHRoZSBm dXR1cmUsIGFuZCB0aGluayB0aGF0IHdlIG5lZWQgdG8gc3RhcnQgdG8gY29uc2lkZXIgQ1BVL05Q VSBjb3JlcywgcXVldWUgYWxnb3JpdGhtcywgYW5kIG1heWJlIG90aGVyIHJlc291cmNlcy4NCg0K SSBhbSBhbHNvIGNvbmNlcm5lZCB0aGF0IHRoZSBudW1iZXIgb2YgZGlmZnNlcnYgY29kZSBwb2lu dHMgYXZhaWxhYmxlIGluIE1QTFMgaXMgZ29pbmcgdG8gYmUgaW5zdWZmaWNpZW50Lg0KDQpPZiBj b3Vyc2Ugd2hhdCB3ZSBrbm93IHRvZGF5IGZyb20gZXhwZXJpZW5jZSBpcyBiYXNlZCBvbiB0aGUg YXBwbGljYXRpb25zIHRoYXQgY2FuIHJ1biBvbiB0aGUgbmV0d29yayBpbmZyYXN0cnVjdHVyZSB0 aGF0IHdlIGhhdmUgdG9kYXkuIFRoYXQgaXMgYSBzZWxmIGxpbWl0aW5nIHNpdHVhdGlvbi4gV2Ug YXJlIGRlc2lnbmluZyBERVRORVQgYmVjYXVzZSB0aGlzIG1vZGVsIGlzIGluYWRlcXVhdGUgZm9y IHNvbWUgY2xhc3NlcyBvZiBhcHBsaWNhdGlvbiB0aGF0IHdvdWxkIGxpa2UgdG8gcnVuIG92ZXIg YSBtb3JlIGdlbmVyYWwgbmV0d29yay4gV2hhdCB3ZSBhcmUgZG9pbmcgd2l0aCANClZQTisgaXMg dG8gaW50ZWdyYXRlIERFVE5FVCBpbnRvIGEgVlBOIHN0cnVjdHVyZSBhbG9uZ3NpZGUgY2xhc3Np YyBWUE5zLg0KDQotIFN0ZXdhcnQNCg0KDQo+IFlvdXJzLA0KPiBKb2VsDQo+DQo+IE9uIDgvMS8x OCAxMToyMiBBTSwgRG9uZ2ppZSAoSmltbXkpIHdyb3RlOg0KPj4gVGhpcyBzdGF0ZW1lbnQgaXMg YmFzZWQgb24gdGhlIGNvbXBhcmlzb24gYmV0d2VlbiBvdmVybGF5IFZQTnMgYW5kIA0KPj4gbmV0 d29yayBzbGljZXMuIFRoZSByZXNvdXJjZSBoZXJlIHJlZmVycyB0byB2YXJpb3VzIGRhdGEgcGxh bmUgDQo+PiByZXNvdXJjZXMgdGhhdCBjYW4gYmUgYWxsb2NhdGVkIHRvIGEgcGFydGljdWxhciBz bGljZSAocXVldWVzLCANCj4+IGJ1ZmZlciwgZXRjLikuIFNvbWUgbGV2ZWwgb2YgcmVzb3VyY2Ug aXNvbGF0aW9uIGlzIG5lY2Vzc2FyeSB0byANCj4+IGVuc3VyZSB0aGF0IHNlcnZpY2UgaW4gb25l IHNsaWNlIG5ldmVyIGludGVyZmVyZXMgd2l0aCBzZXJ2aWNlIGluIA0KPj4gYW5vdGhlciBzbGlj ZS4NCj4+DQo+PiBNYXkgSSBrbm93IHdoYXQgYXJlIHRoZSByZXF1aXJlbWVudHMgeW91J3ZlIGdv dD8NCj4+DQo+PiBCZXN0IHJlZ2FyZHMsDQo+PiBKaWUNCj4+DQo+Pj4gLS0tLS3pgq7ku7bljp/k u7YtLS0tLQ0KPj4+IOWPkeS7tuS6ujogSm9lbCBNLiBIYWxwZXJuIFttYWlsdG86am1oQGpvZWxo YWxwZXJuLmNvbV0NCj4+PiDlj5HpgIHml7bpl7Q6IDIwMTjlubQ35pyIMzDml6UgMjM6MDUNCj4+ PiDmlLbku7bkuro6IERvbmdqaWUgKEppbW15KSA8amllLmRvbmdAaHVhd2VpLmNvbT4NCj4+PiDm ioTpgIE6IFRFQVMgV0cgKHRlYXNAaWV0Zi5vcmcpIDx0ZWFzQGlldGYub3JnPjsgcnRnd2dAaWV0 Zi5vcmcNCj4+PiDkuLvpopg6IFJlOiBWUE4gc2VjdXJpdHkgdnMgU0QtV0FOIHNlY3VyaXR5DQo+ Pj4NCj4+PiBBY3R1YWxseSwgYXNzdW1pbmcgSSB1bmRlcnN0YW5kIHRoZSBzdGF0ZW1lbnQgcHJv cGVybHksICJkZWVwIA0KPj4+IGludGVncmF0aW9uIHdpdGggdGhlIHVuZGVybGF5IHJlc291cmNl IHdvdWxkIGJlIG5lY2Vzc2FyeSIgZG9lcyBub3QgDQo+Pj4gYXBwZWFyIHRvIGJlIGFuIGFjY3Vy YXRlIHN0YXRlbWVudCBkZXJpdmFibGUgZnJvbSB0aGUgcmVxdWlyZW1lbnRzIA0KPj4+IHRoYXQg SSBoYXZlIHNlZW4uDQo+Pj4NCj4+PiBZb3VycywNCj4+PiBKb2VsDQo+Pj4NCj4+PiBPbiA3LzMw LzE4IDg6MjMgQU0sIERvbmdqaWUgKEppbW15KSB3cm90ZToNCj4+Pj4gKEFkZGluZyBURUFTIGFz IGl0IGlzIHdoZXJlIHRoZSBWUE4rIGZyYW1ld29yayBkcmFmdCBpcyBkaXNjdXNzZWQpDQo+Pj4+ DQo+Pj4+IEhpIFJvYmVydCBhbmQgR3JlZywNCj4+Pj4NCj4+Pj4gQXMgZGlzY3Vzc2VkIGR1cmlu ZyB0aGUgVlBOKyBwcmVzZW50YXRpb24gaW4gVEVBUyBhdCBJRVRGIDEwMiwgdGhlIA0KPj4+PiBz Y29wZSBpcyBub3QgdGhlIGludGVybmV0LCBhcyB3ZSBrbm93IGl0IHdvdWxkIHF1aXRlIGRpZmZp Y3VsdCBvciANCj4+Pj4gZXZlbiBpbXBvc3NpYmxlIHRvIGFjaGlldmUgdGhlIHJlcXVpcmVkIGd1 YXJhbnRlZSBhdCB0aGUgc2NvcGUgb2YgaW50ZXJuZXQuDQo+Pj4+DQo+Pj4+IEFuZCBjbGVhcmx5 IHRoZSBWUE4gb3ZlcmxheXMgY2Fubm90IHByb3ZpZGUgdGhlIHJlcXVpcmVkIGd1YXJhbnRlZSwg DQo+Pj4+IGRlZXAgaW50ZWdyYXRpb24gd2l0aCB0aGUgdW5kZXJsYXkgcmVzb3VyY2Ugd291bGQg YmUgbmVjZXNzYXJ5Lg0KPj4+Pg0KPj4+PiBBbm90aGVyIGFzcGVjdCB3ZSBtYXkgdGFrZSBpbnRv IGNvbnNpZGVyYXRpb24gaXMgdGhlIGZhY3RvciBvZiANCj4+Pj4gb3ZlcnByb3Zpc2lvbmluZy4g VGhlIGN1cnJlbnQgbmV0d29yayBvbmx5IGhhcyBvbmUgb3ZlcnByb3Zpc2lvbmluZyANCj4+Pj4g ZmFjdG9yLCB3aGljaCBtYXkgbm90IG1lZXQgdGhlIHJlcXVpcmVtZW50IG9mIGRpZmZlcmVudCAN Cj4+Pj4gc2VydmljZXMvY3VzdG9tZXJzLiBXaXRoIG5ldHdvcmsgc2xpY2luZywgaXQgaXMgcG9z c2libGUgdG8gaGF2ZSANCj4+Pj4gZGlmZmVyZW50IG92ZXJwcm92aXNpb25pbmcgcG9saWN5IGFu ZCBmYWN0b3IgaW4gZGlmZmVyZW50IHNsaWNlcy4NCj4+Pj4NCj4+Pj4gQmVzdCByZWdhcmRzLA0K Pj4+Pg0KPj4+PiBKaWUNCj4+Pj4NCj4+Pj4gKkZyb206KnJyYXN6dWtAZ21haWwuY29tIFttYWls dG86cnJhc3p1a0BnbWFpbC5jb21dICpPbiBCZWhhbGYgT2YgDQo+Pj4+ICpSb2JlcnQgUmFzenVr DQo+Pj4+ICpTZW50OiogU3VuZGF5LCBKdWx5IDI5LCAyMDE4IDY6MTEgQU0NCj4+Pj4gKlRvOiog R3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbT4NCj4+Pj4gKkNjOiogRG9uZ2ppZSAo SmltbXkpIDxqaWUuZG9uZ0BodWF3ZWkuY29tPjsgcnRnd2dAaWV0Zi5vcmcNCj4+Pj4gKlN1Ympl Y3Q6KiBSZTogVlBOIHNlY3VyaXR5IHZzIFNELVdBTiBzZWN1cml0eQ0KPj4+Pg0KPj4+PiBIZXkg R3JlZywNCj4+Pj4NCj4+Pj4+DQo+Pj4+DQo+Pj4+IHdvdWxkIG5vdCByZXF1aXJlIGdsb2JhbCB0 cmFuc2l0IGFuZCBsaWtlbHkgYmUgY29udGFpbmVkIHdpdGhpbiANCj4+Pj4gYWNjZXNzIG9yLCBh dCBtb3N0LCBtZXRybyBkb21haW5zLg0KPj4+Pg0KPj4+PiBUaGF0J3MgbmV3cyB0byBtZSwgYnV0 IHBlcmhhcHMgb24gdGhlIHBvc2l0aXZlIHNpZGUgOikgSSBhbHdheXMgDQo+Pj4+IHRoaW5rIFdB TiAuLiByZWFsbHkgd2lkZSBvbmUgIQ0KPj4+Pg0KPj4+PiBUaGUgc2VwYXJhdGlvbiBvbiAic29m dCIgdnMgImhhcmQiIGd1YXJhbnRlZXMgaXMgZXZlbnR1YWxseSBhbGwgDQo+Pj4+IGFib3V0IGFt b3VudCBvZiBuZXR3b3JrIHJvYnVzdG5lc3MgYW5kIGxldmVsIG9mIG92ZXIgcHJvdmlzaW9uaW5n LsKgIA0KPj4+PiBJIHNpbmNlcmVseSBob3BlIGl0IHdpbGwgbm90IGJlIHlldCBhbm90aGVyIEVW UE4gb3ZlcmxheSBvdmVyIElQIA0KPj4+PiBuZXR3b3JrIGp1c3QgcGFpbnRlZCB3aXRoIGRpZmZl cmVudCBtYXJrZXRpbmcgY29sb3JzLg0KPj4+Pg0KPj4+PiBCZXNpZGVzIGlmIGFueSBjdXN0b21l ciBpcyBzZXJpb3VzIGFuZCBhY3R1YWxseSBjb3VudHMgb24gdGhvc2UgDQo+Pj4+IGd1YXJhbnRl ZXMgaGUgYmV0dGVyIHB1cmNoYXNlIHR3byBvZiBzdWNoIHNlcnZpY2VzIGNvbWluZyBmcm9tIA0K Pj4+PiBpbmRlcGVuZGVudCBvcGVyYXRvcnMuIFRoYXQgbWVhbnMgdGhhdCB0byBiZSBhdHRyYWN0 aXZlIGZpbmFuY2lhbGx5IA0KPj4+PiBjb3N0IG9mIHN1Y2ggcHJlbWl1bSBzZXJ2aWNlIG11c3Qg bm90IGJlIGhpZ2hlciB0aGVuIGhhbGYgb2YgdGhlIA0KPj4+PiBwMnAgbG9jYWwgZmliZXIgb3Ig Y29zdCBvZiBsb2NhbCBhY2Nlc3MgdG8gY2xvc2VzdCBJWCBwb3J0cyArIHBvcnQgDQo+Pj4+IHN1 YnNjcmlwdGlvbiBpbiBhIGdpdmVuIE1BTiB3aGVyZSBub24gYmxvY2tpbmcgSVggZmFicmljIHNw YW5zIA0KPj4+PiBnaXZlbg0KPj4+IGdlb2dyYXBoeS4NCj4+Pj4NCj4+Pj4gSXQgc2VlbXMgdG8g bWUgdGhhdCBhdCB0aGUgZW5kIG9mIHRoZSBkYXkgdGhlIHNwYWNlIGZvciB0aG9zZSANCj4+Pj4g b3BlcmF0b3JzIHdpc2hpbmcgdG8gb2ZmZXIgaGFyZCBuZXR3b3JrIHNsaWNpbmcgaXMgYWN0dWFs bHkgcHJldHR5IA0KPj4+PiBuYXJyb3csIGJ1dCB0aW1lIHdpbGwgdGVsbCAuLi4NCj4+Pj4NCj4+ Pj4gUmdzLA0KPj4+Pg0KPj4+PiByLg0KPj4+Pg0KPj4+PiBPbiBTYXQsIEp1bCAyOCwgMjAxOCBh dCA5OjM0IFBNLCBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tIA0KPj4+PiA8bWFp bHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbT4+IHdyb3RlOg0KPj4+Pg0KPj4+PiDCoMKgwqDCoCBI aSBSb2JlcnQsDQo+Pj4+DQo+Pj4+IMKgwqDCoMKgIHZlcnkgbXVjaCBhZ3JlZSB3aXRoIGFsbCB5 b3UncmUgc2F5aW5nIGFuZCBmaW5kIHVzIGluIHZpb2xlbnQNCj4+Pj4gwqDCoMKgwqAgYWdyZWVt ZW50IG9uICJDIi4gUHJvYWN0aXZlIHBlcmZvcm1hbmNlIG1vbml0b3JpbmcsIGluIG15IHZpZXcg DQo+Pj4+IGFzDQo+Pj4+IMKgwqDCoMKgIHdlbGwsIGlzIHRoZSByZWFzb25hYmxlIHBhdGggdG8g cHJvdmlkZSAic29mdCIgU0xBIGFuZCwgdG8gYSANCj4+Pj4gZGVncmVlLA0KPj4+PiDCoMKgwqDC oCBwcmV2ZW50IG92ZXJzdWJzY3JpcHRpb24gb2YgdGhlIG5ldHdvcmsuIEFuZCB0aGF0LCBhcyB5 b3UndmUgDQo+Pj4+IHNhaWQsDQo+Pj4+IMKgwqDCoMKgIGlzIG9uZSB3YXkgdG8gImFzc3VyZWQv Z3VhcmFudGVlZCBnbG9iYWwgSVAgdHJhbnNpdCIuDQo+Pj4+DQo+Pj4+IMKgwqDCoMKgIEJ1dCBJ IHRoaW5rIHRoYXQgdGhlcmUgd2lsbCBiZSBkZW1hbmQgZm9yICJoYXJkIiBndWFyYW50ZWVzIA0K Pj4+PiBmb3INCj4+Pj4gwqDCoMKgwqAgVVJMTEPCoGFwcGxpY2F0aW9ucy4gQnV0IHRoZXNlLCBp biBteSB2aWV3LA0KPj4+Pg0KPj4+PiDCoMKgwqDCoCB3b3VsZCBub3QgcmVxdWlyZSBnbG9iYWwg dHJhbnNpdCBhbmQgbGlrZWx5IGJlIGNvbnRhaW5lZCANCj4+Pj4gd2l0aGluDQo+Pj4+IMKgwqDC oMKgIGFjY2Vzc8Kgb3IsIGF0IG1vc3QsIG1ldHJvIGRvbWFpbnMuIEJlY2F1c2Ugb2YgdGhlIGxp bWl0ZWQgc2l6ZSANCj4+Pj4gb2YNCj4+Pj4gwqDCoMKgwqAgdGhlIGRvbWFpbiwgSW50U2VydiBt YXkgd29yaywgdGhvdWdoIHRoYXQgbWF5IGJlIG5vdCB0aGUgbW9zdA0KPj4+PiDCoMKgwqDCoCBl ZmZpY2llbnQgdGVjaG5pcXVlLiBXZSBzaGFsbCBmaW5kIG91dC4NCj4+Pj4NCj4+Pj4gwqDCoMKg wqAgSGVuY2UgbXkgdmlldyBvbiBzbGljaW5nOg0KPj4+Pg0KPj4+PiDCoMKgwqDCoMKgwqAgKiBk aWZmZXJlbnQgYXBwbGljYXRpb25zIHdpbGwgaGF2ZSBkaWZmZXJlbnQgcmVxdWlyZW1lbnRzIA0K Pj4+PiBhbmQgdXNlDQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqAgZGlmZmVyZW50IGRlZ3JlZXMgb2Yg aXNvbGF0aW9uIGFuZCBndWFyYW50ZWVzOw0KPj4+PiDCoMKgwqDCoMKgwqAgKiAic29mdCIgc2xp Y2VzIG1heSBub3QgbmVlZCBtdWNoIG9mIGFkZGl0aW9uYWwgDQo+Pj4+IHN0YW5kYXJkaXphdGlv bg0KPj4+PiDCoMKgwqDCoMKgwqDCoMKgIGFuZCB1c2UgYXZhaWxhYmxlIFZQTiB0ZWNobm9sb2dp ZXMgaW4gY29tYmluYXRpb24gd2l0aCBQTSANCj4+Pj4gT0FNDQo+Pj4+IMKgwqDCoMKgwqDCoMKg wqAgZm9yIFNMQSBtb25pdG9yaW5nIGFuZCBhc3N1cmFuY2U7DQo+Pj4+IMKgwqDCoMKgwqDCoCAq ICJoYXJkIiBzbGljZXMgd291bGQgc3BhbiB3aXRoaW4gYSBzaW5nbGUgYWNjZXNzIGFuZC9vciAN Cj4+Pj4gbWV0cm8NCj4+Pj4gwqDCoMKgwqDCoMKgwqDCoCBkb21haW4uIE5ldHdvcmtpbmcgc29s dXRpb25zIGxpa2VseSB3aWxsIGJlIGNvdXBsZWQgd2l0aA0KPj4+PiDCoMKgwqDCoMKgwqDCoMKg IGFyY2hpdGVjdHVyZSBhbmQgaW50ZXJmYWNlcyBkZXZlbG9wZWQgaW4gTXVsdGktYWNjZXNzIEVk Z2UNCj4+Pj4gwqDCoMKgwqDCoMKgwqDCoCBDb21wdXRpbmcgKE1FQykuDQo+Pj4+DQo+Pj4+IMKg wqDCoMKgIFJlZ2FyZHMsDQo+Pj4+DQo+Pj4+IMKgwqDCoMKgIEdyZWcNCj4+Pj4NCj4+Pj4gwqDC oMKgwqAgT24gU2F0LCBKdWwgMjgsIDIwMTggYXQgNjowMiBBTSwgUm9iZXJ0IFJhc3p1ayANCj4+ Pj4gPHJvYmVydEByYXN6dWsubmV0DQo+Pj4+IMKgwqDCoMKgIDxtYWlsdG86cm9iZXJ0QHJhc3p1 ay5uZXQ+PiB3cm90ZToNCj4+Pj4NCj4+Pj4gwqDCoMKgwqDCoMKgwqDCoCBIaSBKaWUsDQo+Pj4+ DQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqAgPiAobmV0d29yayBzbGljaW5nKSBpcyB0byBwcm92aWRl IHRoZSBkZW1hbmRpbmcgc2VydmljZXMgDQo+Pj4+IHdpdGggZ3VhcmFudGVlZCBwZXJmb3JtYW5j ZSBpbiBhIGNvbnZlcmdlZCBuZXR3b3JrLA0KPj4+Pg0KPj4+PiDCoMKgwqDCoMKgwqDCoMKgIEZv dW5kYXRpb24gb2YgY29udmVyZ2VkIElQIG5ldHdvcmsgaXMgYmFzZWQgb24gc3RhdGlzdGljYWwN Cj4+Pj4gwqDCoMKgwqDCoMKgwqDCoCBtdWx0aXBsZXhpbmcgb2YgdHJhZmZpYyBkZW1hbmRzLiBB cyBzdWNoIGl0IGlzIGluIGl0cyANCj4+Pj4gcHJpbmNpcGxlDQo+Pj4+IMKgwqDCoMKgwqDCoMKg wqAgcXVpdGUgY29udHJhZGljdG9yeSB0byAiZ3VhcmFudGVlZCIgY2hhcmFjdGVyaXN0aWNzDQo+ Pj4+IMKgwqDCoMKgwqDCoMKgwqAgKHBlcmZvcm1hbmNlLCBkZWxheXMsIGppdHRlciwgZHJvcHMg LS0geW91IG5hbWUgaXQpLg0KPj4+Pg0KPj4+PiDCoMKgwqDCoMKgwqDCoMKgIEFwcGxpY2F0aW9u IGxheWVycyB1c3VhbGx5IGRlYWwgdmVyeSB3ZWxsIHdpdGggYWxsIG9mIHRoZSANCj4+Pj4gYWJv dmUNCj4+Pj4gwqDCoMKgwqDCoMKgwqDCoCBJIHdvdWxkIHN0YXRlIC0gbm9ybWFsIGNoYXJhY3Rl cmlzdGljcyBvZiBJUCBuZXR3b3Jrcy4uDQo+Pj4+DQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqAgTm8g ZG91YnQgdGhlcmUgd2lsbCBiZSB0aG9zZSB0cnlpbmcgdG8gb2ZmZXIgc29tZSBuZXR3b3JrDQo+ Pj4+IMKgwqDCoMKgwqDCoMKgwqAgc2xpY2luZyB3aXRoIGd1YXJhbnRlZXMgYW5kIGV2ZW4gdGhv c2Ugd2hvIHdpbGwgYnV5IGl0LiANCj4+Pj4gSnVzdA0KPj4+PiDCoMKgwqDCoMKgwqDCoMKgIGxp a2UgdG9kYXkgdGhlcmUgYXJlIHRob3NlIHdobyBvZmZlciB5b3UgTDIgY2lyY3VpdCANCj4+Pj4g YmV0d2Vlbg0KPj4+PiDCoMKgwqDCoMKgwqDCoMKgIGVuZHBvaW50cyBleGNlcHQgc3VjaCBMMiBj aXJjdWl0IGlzIGFuIGVtdWxhdGVkIG9uZSB3aXRoIA0KPj4+PiB6ZXJvDQo+Pj4+IMKgwqDCoMKg wqDCoMKgwqAgT0VNIHZpc2liaWxpdHkgdG8gdGhlIElQIGluZnJhc3RydWN0dXJlIHVuZGVybmVh dGguDQo+Pj4+DQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqAgTm93IHRoZSBuZXR3b3JrIHNsaWNpbmcg aXMgY2xlYXJseSBhaW1pbmcgZm9yIGV2ZW4gbW9yZQ0KPj4+PiDCoMKgwqDCoMKgwqDCoMKgIGNv bXBsZXhpdHkgdW5kZXIgdGhlIGhvb2QuIEFuZCB0aGF0IGlzIG5vdCB0aGUgb25seSANCj4+Pj4g cHJvYmxlbS4gVGhlDQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqAgaXNzdWUgaXMgY29zdC4gV2hlbiBT UCBpcyBidWlsZGluZyB0aGUgSVAgbmV0d29yayB0aGUgZ29hbCANCj4+Pj4gaXMgdG8NCj4+Pj4g wqDCoMKgwqDCoMKgwqDCoCBtdXggYXMgbWFueSBzZXJ2aWNlcyBvbiBpdCBhcyBpdCBzaW1wbHkg cmVzdWx0cyBpbiBnaXZlbidzIA0KPj4+PiBTUA0KPj4+PiDCoMKgwqDCoMKgwqDCoMKgIHJldmVu dWUuIE5ldHdvcmsgc2xpY2luZyBpcyBwcm9taXNpbmcgYXMgcG90ZW50aWFsbHkganVzdCANCj4+ Pj4gYnkNCj4+Pj4gwqDCoMKgwqDCoMKgwqDCoCBjb25maWd1cmF0aW9uIG9mIGZldyBrbm9icyB0 aGV5IHdpbGwgYmUgY2xhaW1pbmcgDQo+Pj4+IGd1YXJhbnRlZXMgYXMNCj4+Pj4gwqDCoMKgwqDC oMKgwqDCoCBSRkMgc2F5cyAtIGV4Y2VwdCBSRkMgd2lsbCBub3QgbGlrZWx5IHRlbGwgeW91IHRv IHN0b3ANCj4+Pj4gwqDCoMKgwqDCoMKgwqDCoCBvdmVyLXByb3Zpc2lvbmluZy4NCj4+Pj4NCj4+ Pj4gwqDCoMKgwqDCoMKgwqDCoCBVbmxlc3MgdGhlIGlkZWEgaXMgdG8gdXNlIHN0cmljdCBwb2xp Y2luZyB3aXRoIGRlZGljYXRlZCANCj4+Pj4gcXVldWluZw0KPj4+PiDCoMKgwqDCoMKgwqDCoMKg IG9uIGFjdGl2ZSBhbmQgYmFjayBwYXRocyBvciBkbyBzb21ldGhpbmcgbGlrZSBSU1ZQIEludFNl cnYgDQo+Pj4+IGFsc28NCj4+Pj4gwqDCoMKgwqDCoMKgwqDCoCBvbiBhY3RpdmUgYW5kIGJhY2t1 cCBwYXRocyBwZXIgY3VzdG9tZXIgLSBJIHJlYWxseSBkb24ndCANCj4+Pj4gdGhpbmsNCj4+Pj4g wqDCoMKgwqDCoMKgwqDCoCB5b3UgY2FuIHJlYWxseSBndWFyYW50ZWUgbXVjaC4gQW5kIGlmIHlv dSBkbyB0aGF0IHRoZSBjb3N0IA0KPj4+PiB3b3VsZA0KPj4+PiDCoMKgwqDCoMKgwqDCoMKgIGxp a2VseSBncm93IHJlYWxseSBzdGVlcC4NCj4+Pj4NCj4+Pj4gwqDCoMKgwqDCoMKgwqDCoCBTbyB3 aGF0IGlzIElNTyB0aGUgc29sdXRpb24gZm9yIGFzc3VyZWQvZ3VhcmFudGVlZCBnbG9iYWwgDQo+ Pj4+IElQDQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqAgdHJhbnNpdDoNCj4+Pj4NCj4+Pj4gwqDCoMKg wqDCoMKgwqDCoCAqQSrCoCBnZXQgZGl2ZXJzZWx5IHJvdXRlZMKgIGRhcmsgZmliZXIgcGF0aHMg YmV0d2VlbiB5b3VyIA0KPj4+PiBQT1BzDQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqAgKGNhbiBiZSB1 bnByb3RlY3RlZCkgd2hpY2ggYnR3IHRvZGF5IGRvIG5vdCBjb3N0IHRoYXQgbXVjaCANCj4+Pj4g YW55bW9yZQ0KPj4+Pg0KPj4+PiDCoMKgwqDCoMKgwqDCoMKgICpCKiBnZXQgZGl2ZXJzZWx5IHJv dXRlZMKgIG9wdGljYWwgY2hhbm5lbHMgYWxzb2wgYmV0d2VlbiANCj4+Pj4geW91cg0KPj4+PiDC oMKgwqDCoMKgwqDCoMKgIFBPUHMgKGNhbiBiZSB1bnByb3RlY3RlZCkNCj4+Pj4NCj4+Pj4gwqDC oMKgwqDCoMKgwqDCoCAqQyrCoCB1c2UgTiBkaXNqb2luZWQgYnkgZGVzaWduIChzaW5nbGUgQVMg SW50ZXJuZXQgDQo+Pj4+IHByb3ZpZGVycw0KPj4+PiDCoMKgwqDCoMKgwqDCoMKgIGJldHdlZW4g eW91ciBlbmQtcG9pbnRzKSArIHByb3BlciBTRC1XQU4gd2l0aCBhY3RpdmUgU0xBIA0KPj4+PiBt b25pdG9yaW5nDQo+Pj4+DQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqAgQ2xlYXJseSBJIGFtIGJpZyBz dXBwb3J0ZXIgb2YgKkMqIG1vZGVsIGZvciByZWFzb25zIA0KPj4+PiBkaXNjdXNzZWQgb24NCj4+ Pj4gwqDCoMKgwqDCoMKgwqDCoCB0aGlzIGFuZCBmZXcgb3RoZXIgcmVjZW50IHRocmVhZHMuDQo+ Pj4+DQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqAgSSBhc3N1bWUgbmV0d29yayBzbGljaW5nIHdpbGwg dHJ5IHRvIGdldCBpbnRvIGJlIHNvbWV0aGluZw0KPj4+PiDCoMKgwqDCoMKgwqDCoMKgIGJldHdl ZW4gQS9CICYgQyBidXQgaXQgaXMgYm91bmRlZCB1cCBmcm9udCB3aXRoIHRoZSBjb3N0IA0KPj4+ PiBvZiB0aGUNCj4+Pj4gwqDCoMKgwqDCoMKgwqDCoCB0d28uDQo+Pj4+DQo+Pj4+IMKgwqDCoMKg wqDCoMKgwqAgTWFueSB0aHgsDQo+Pj4+DQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqAgUm9iZXJ0Lg0K Pj4+Pg0KPj4+PiDCoMKgwqDCoMKgwqDCoMKgIE9uIFNhdCwgSnVsIDI4LCAyMDE4IGF0IDk6NTEg QU0sIERvbmdqaWUgKEppbW15KQ0KPj4+PiDCoMKgwqDCoMKgwqDCoMKgIDxqaWUuZG9uZ0BodWF3 ZWkuY29tIDxtYWlsdG86amllLmRvbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KPj4+Pg0KPj4+PiDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgSGkgUm9iZXJ0LA0KPj4+Pg0KPj4+PiDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgSU1PIHRoZSB0d28gYXBwcm9hY2hlcyBhcmUgdGFyZ2V0aW5nIGF0IGRp ZmZlcmVudCB1c2UgDQo+Pj4+IGNhc2VzDQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBh bmQgY3VzdG9tZXJzLg0KPj4+Pg0KPj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgVGhlIGZv cm1lciAobmV0d29yayBzbGljaW5nKSBpcyB0byBwcm92aWRlIHRoZSANCj4+Pj4gZGVtYW5kaW5n DQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBzZXJ2aWNlcyB3aXRoIGd1YXJhbnRlZWQg cGVyZm9ybWFuY2UgaW4gYSBjb252ZXJnZWQNCj4+PiBuZXR3b3JrLA0KPj4+PiDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgd2hpbGUgdGhlIGxhdHRlciAoc3dpdGNoaW5nIGJldHdlZW4gbXVsdGlw bGUgDQo+Pj4+IHBhcmFsbGVsZWQNCj4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIG5ldHdv cmtzKSBwcm92aWRlcyB0aGUgY3VzdG9tZXIgd2l0aCB0aGUgYmVzdCANCj4+Pj4gcGVyZm9ybWFu Y2UNCj4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHRoYXQgaXMgYXZhaWxhYmxlIGFtb25n IHRob3NlIGNhbmRpZGF0ZXMuIFRvIG1lIHRoZSANCj4+Pj4gbGF0dGVyDQo+Pj4+IMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCBpcyBzdGlsbCBzb21lIGtpbmQgb2YgYmVzdCBlZmZvcnQsIGFuZCBh cyBUb2VybGVzcyANCj4+Pj4gc2FpZCwgaXQNCj4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IGRlcGVuZHMgb24gdGhlIGRpdmVyc2l0eSB5b3UgY2FuIGhhdmUgaW4gdGhlIG11bHRpcGxlDQo+ Pj4gbmV0d29ya3MuDQo+Pj4+DQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBBbmQgSSBh Z3JlZSB3aXRoIFN0ZXdhcnQgb24g4oCceW91IGFsd2F5cyBwYXkgYSBwcmljZSANCj4+Pj4gZm9y DQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBiZXR0ZXIgdGhhbiBiZXN0IGVmZm9ydC7i gJ0NCj4+Pj4NCj4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIEJlc3QgcmVnYXJkcywNCj4+ Pj4NCj4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIEppZQ0KPj4+Pg0KPj4+PiDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgKkZyb206KnJ0Z3dnIFttYWlsdG86cnRnd2ctYm91bmNlc0BpZXRm Lm9yZw0KPj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPG1haWx0bzpydGd3Zy1ib3VuY2Vz QGlldGYub3JnPl0gKk9uIEJlaGFsZiBPZiAqUm9iZXJ0DQo+Pj4gUmFzenVrDQo+Pj4+IMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCAqU2VudDoqIFdlZG5lc2RheSwgSnVseSAyNSwgMjAxOCA4OjI0 IFBNDQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAqVG86KiBBY2VlIExpbmRlbSAoYWNl ZSkgPGFjZWVAY2lzY28uY29tDQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8bWFpbHRv OmFjZWVAY2lzY28uY29tPj4NCj4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICpDYzoqIHJ0 Z3dnQGlldGYub3JnIDxtYWlsdG86cnRnd2dAaWV0Zi5vcmc+DQo+Pj4+DQo+Pj4+DQo+Pj4+IMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAqU3ViamVjdDoqIFJlOiBWUE4gc2VjdXJpdHkgdnMgU0Qt V0FOIHNlY3VyaXR5DQo+Pj4+DQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBUcnVlIG5l dHdvcmsgc2xpY2luZyBmb3IgSVAgbmV0d29ya3MgbWVhbnMgZWl0aGVyIA0KPj4+PiB3YWlzdCBv Zg0KPj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgcmVzb3VyY2VzIG9yIHZlcnkgc3RyaWN0 IG11bHRpLWxldmVsIHF1ZXVpbmcgYXQgZWFjaCANCj4+Pj4gaG9wIGFuZA0KPj4+PiDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgMTAwJSBpbmdyZXNzIHRyYWZmaWMgcG9saWNpbmcuIFlldCB3aGls ZSB0aGlzIGhhcyBhIA0KPj4+PiBjaGFuY2UNCj4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IHRvIHdvcmsgZHVyaW5nIG5vcm1hbCBvcGVyYXRpb24gYXQgdGhlIHRpbWUgb2YgZXZlbiANCj4+ Pj4gcmVndWxhcg0KPj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgZmFpbHVyZXMgdGhpcyBh bGwgcHJldHR5IG11Y2ggbWVsdHMgbGlrZSBjaGVlc2Ugb24gYSANCj4+Pj4gZ29vZA0KPj4+PiDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgc2FuZHdpY2guDQo+Pj4+DQo+Pj4+IMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCBJdCBpcyBnb2luZyB0byBiZSB2ZXJ5IGludGVyZXN0aW5nIHRvIGNvbXBh cmUgaG93IA0KPj4+PiBzaW5nbGUNCj4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGNvbXBs ZXggc2xpY2VkIG5ldHdvcmsgY29tcGFyZXMgZm9yIGFueSBlbmQgdG8gZW5kIA0KPj4+PiByb2J1 c3QNCj4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHRyYW5zcG9ydCBmcm9tIE4gbm9ybWFs IHNpbXBsZSBJUCBiYWNrYm9uZXMgYW5kIGVuZCB0bw0KPj4+IGVuZA0KPj4+PiDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgU0xBIGJhc2VkIG1pbGxpc2Vjb25kIHN3aXRjaCBvdmVyIGJldHdlZW4g b25lIGFuZCANCj4+Pj4gYW5vdGhlcg0KPj4+IG9uDQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCBhIHBlciBmbG93IGJhc2lzLiBBbHNvIGxldCdzIG5vdGUgdGhlbiB3aGlsZSB0aGUgDQo+ Pj4+IGZvcm1lciBpcw0KPj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgc3RpbGwgdG8gdGhl IGJlc3Qgb2YgbXkga25vd2xlZGdlIGEgZHJhZnQgdGhlIGxhdHRlciANCj4+Pj4gaXMNCj4+Pj4g wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGFscmVhZHkgZGVwbG95ZWQgZ2xvYmFsbHkgaW4gMTAw cyBvZiBuZXR3b3Jrcy4NCj4+Pj4NCj4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIEJlc3Qs DQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBSLg0KPj4+Pg0KPj4+PiDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgT24gV2VkLCBKdWwgMjUsIDIwMTggYXQgMToyMSBQTSwgQWNlZSBMaW5k ZW0gKGFjZWUpDQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YWNlZUBjaXNjby5jb20g PG1haWx0bzphY2VlQGNpc2NvLmNvbT4+IHdyb3RlOg0KPj4+Pg0KPj4+PiDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCAqRnJvbTogKnJ0Z3dnIDxydGd3Zy1ib3VuY2VzQGlldGYub3Jn DQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxtYWlsdG86cnRnd2ctYm91 bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiANCj4+Pj4gU3Rld2FydA0KPj4+PiDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBCcnlhbnQgPHN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNv bQ0KPj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8bWFpbHRvOnN0ZXdhcnQu YnJ5YW50QGdtYWlsLmNvbT4+DQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg ICpEYXRlOiAqV2VkbmVzZGF5LCBKdWx5IDI1LCAyMDE4IGF0IDU6NTUgQU0NCj4+Pj4gwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgKlRvOiAqUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJh c3p1ay5uZXQNCj4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPG1haWx0bzpy b2JlcnRAcmFzenVrLm5ldD4+DQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg ICpDYzogKlJvdXRpbmcgV0cgPHJ0Z3dnQGlldGYub3JnDQo+Pj4gPG1haWx0bzpydGd3Z0BpZXRm Lm9yZz4+DQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICpTdWJqZWN0OiAq UmU6IFZQTiBzZWN1cml0eSB2cyBTRC1XQU4gc2VjdXJpdHkNCj4+Pj4NCj4+Pj4gwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgT24gMjUvMDcvMjAxOCAxMDo0MCwgUm9iZXJ0IFJhc3p1 ayB3cm90ZToNCj4+Pj4NCj4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCAvKiBBZGp1c3RpbmcgdGhlIHN1YmplY3QgLi4uICovDQo+Pj4+DQo+Pj4+IMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgSGVsbG8NCj4+Pj4NCj4+Pj4gwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBTdGV3YXJ0LA0KPj4+Pg0KPj4+PiDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFlvdSBoYXZlIG1hZGUgdGhl IGJlbG93IGNvbW1lbnQgaW4gdGhlIG90aGVyDQo+Pj4gdGhyZWFkDQo+Pj4+IMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgd2UgYXJlIGhhdmluZzoNCj4+Pj4NCj4+Pj4g wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIEluZGVlZCwg SSB3b3VsZCBoYXZlIGV4cGVjdGVkIHRoaXMgdG8gYmUgDQo+Pj4+IG9uIGENCj4+Pj4gwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHNlY3VyZSBuZXR3b3Jr IG9mIHNvbWUgc29ydCBlaXRoZXIgcHVyZWx5DQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBwcml2YXRlIG9yIHNvbWUgZm9ybSBvZiBWUE4uIEhv d2V2ZXIsIEkgYW0NCj4+PiBzdXJlDQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCBJIHJlYWQgaW4geW91ciB0ZXh0IHRoYXQgeW91IHdlcmUNCj4+ Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGNvbnNp ZGVyaW5nIHVzaW5nIHRoZSBQdWJsaWMgSW50ZXJuZXQgbXVjaCANCj4+Pj4gaW4NCj4+Pj4gwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHRoZSB3YXkgb2Yg U0QtV0FOLg0KPj4+Pg0KPj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIFdvdWxkIHlvdSBtaW5kIGFzIGV4dGVuc2l2ZWx5IGFzIHlvdSBjYW4gDQo+Pj4+IGV4cGFu ZA0KPj4+IG9uDQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg dGhlIGFib3ZlIHN0YXRlbWVudCA/DQo+Pj4+DQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgU3BlY2lmaWNhbGx5IG9uIHdoYXQgYmFzaXMgZG8geW91IHRyZWF0 IHNheSANCj4+Pj4gTDJWUE4NCj4+PiBvcg0KPj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIEwzVlBOIG9mIG5ha2VkIHVuZW5jcnlwdGVkIHBhY2tldHMgb2Z0ZW4N Cj4+PiB0cmF2ZWxpbmcNCj4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCBvbiB0aGUgdmVyeSBzYW1lIGxpbmtzIGFzIHRoaXMgImJhZCIgSW50ZXJuZXQNCj4+Pj4g wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB0cmFmZmljIHRvIGJlIGV2 ZW4gc2xpZ2h0bHkgbW9yZSBzZWN1cmUgdGhlbiANCj4+Pj4gSVBTRUMNCj4+Pj4gwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBvciBEVExTIGVuY3J5cHRlZCBTRC1XQU4g Y2FycmllZCBkYXRhIHdpdGgNCj4+PiBlbmRwb2ludHMNCj4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBiZWluZyB0ZXJtaW5hdGVkIGluIHByaXZhdGUgc3lzdGVt cyA/DQo+Pj4+DQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg VGh4LA0KPj4+Pg0KPj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IFJvYmVydA0KPj4+Pg0KPj4+Pg0KPj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCBSb2JlcnQsIEkgdGhpbmsgdGhhdCB5b3UgaGF2ZSB0byB0YWtlIGl0IGFzIHJlYWQgDQo+Pj4+ IHRoYXQgYW4NCj4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgYWlyIHRyYWZm aWMgY29udHJvbCBTb0Ygc3lzdGVtIGlzIGVuY3J5cHRpbmcgaXRzDQo+Pj4+IMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIHBhY2tldHMuIElmIGl0IGlzIG5vdCwgdGhlbiBpdCBpcyBj bGVhcmx5IG5vdCBmaXQgDQo+Pj4+IGZvcg0KPj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCBwdXJwb3NlLg0KPj4+Pg0KPj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCBXaGF0IGNvbmNlcm5zIG1lIGlzIHRoYXQgYW4gYWlyIHRyYWZmaWMgc3lzdGVtIGlzIA0K Pj4+PiBvbmUgb2YNCj4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgdGhlIG1v c3QsIGlmIG5vdCB0aGUgbW9zdCwgaGlnaCBwcm9maWxlIHRhcmdldHMgaW4gDQo+Pj4+IGNpdmls DQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHNvY2lldHkuIFlvdSBnZXQg cmVtaW5kZWQgb2YgdGhpcyBlYWNoIHRpbWUgeW91IA0KPj4+PiB0cmF2ZWwNCj4+Pj4gwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgdG8gSUVURi4NCj4+Pj4NCj4+Pj4gwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgVGhlIHRoaW5nIGFib3V0IHNhZmV0eSBvZiBmbGlnaHQg dHJhZmZpYyBpcyB0aGF0IGENCj4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg c3VzdGFpbmVkIGFuZCBlZmZlY3RpdmUgRERvUyBhdHRhY2sgaGFzIGdsb2JhbCANCj4+Pj4gaW1w YWN0IGluDQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGEgd2F5IHRoYXQg ZmV3IG90aGVyIHN1Y2ggYXR0YWNrcyBoYXZlLg0KPj4+Pg0KPj4+PiDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCBBIFZQTiBzeXN0ZW0gb3VnaHQgdG8gc3VzdGFpbiByZXNpc3RhbmNl IHRvIHN1Y2ggDQo+Pj4+IGFuDQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IGF0dGFjayBiZXR0ZXIgdGhhbiB0aGUgcHJvcG9zZWQgc3lzdGVtIHdoaWNoIA0KPj4+PiB0cmVh dHMNCj4+PiB0aGUNCj4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgU29GIHRy YWZmaWMgdGhlIHNhbWUgYXMgcmVndWxhciB0cmFmZmljLg0KPj4+Pg0KPj4+PiDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBJIGd1ZXNzIHlvdSBhcmUgbWFraW5nIGEgY2FzZSBmb3Ig eW91ciBuZXR3b3JrIA0KPj4+PiBzbGljaW5nDQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgIHdvcmsg8J+YiQ0KPj4+Pg0KPj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCBBY2VlDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIC0gU3Rld2FydA0KPj4+Pg0KPj4+PiDCoMKgwqDCoMKgwqDCoMKgIF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IMKgwqDCoMKg wqDCoMKgwqAgcnRnd2cgbWFpbGluZyBsaXN0DQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqAgcnRnd2dA aWV0Zi5vcmcgPG1haWx0bzpydGd3Z0BpZXRmLm9yZz4NCj4+Pj4gwqDCoMKgwqDCoMKgwqDCoCBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Z3dnDQo+Pj4+DQo+Pj4+DQo+ Pj4+DQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj4+IHJ0Z3dnIG1haWxpbmcgbGlzdA0KPj4+PiBydGd3Z0BpZXRmLm9yZw0KPj4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Z3dnDQo+Pj4+DQo+DQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFRlYXMgbWFpbGlu ZyBsaXN0DQo+IFRlYXNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90ZWFzDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpydGd3ZyBtYWlsaW5nIGxpc3QNCnJ0Z3dnQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Z3dnDQo= From nobody Thu Aug 2 06:19:59 2018 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C228130E7D; Thu, 2 Aug 2018 06:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHuSWxZLqy4F; Thu, 2 Aug 2018 06:19:48 -0700 (PDT) Received: from mail-pl0-x242.google.com (mail-pl0-x242.google.com [IPv6:2607:f8b0:400e:c01::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 783D9130E6D; Thu, 2 Aug 2018 06:19:48 -0700 (PDT) Received: by mail-pl0-x242.google.com with SMTP id f6-v6so1028063plo.1; Thu, 02 Aug 2018 06:19:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=U9bojEE95Zm+Bo6ILTseHxQlSN3dv4sEPldjzgDwgxA=; b=oNsr5qqDQ357D8Gx7PU1k0DJesXJjtLNXxsK9+qoi2bJ/w1GBaqJWZ/SMQw7fKm/tQ 48KSUb8Z7gsSk1kVHqR3R0pfnD9uTo1y/5LSO3G8FI9qREeA55xLBybDg1BfDgUHUVBZ 8O/Ma884GykWRq09yLXZCOtKiwTqNBgO7tmYUgMcN49+c6z6dbMJnnB8ulvHW4fZw/Lv 8HOzzmCy4V9+D2EXJczEwsYKml/QeeYJuEC/zYDvSGrQ6xs+s8DpVIIiB1ezWTBZZgAk w84yhzFkFYmzswY4ClKJqeHi2rea74WNlRSYRZVsqefHvIfj1zUPJyb3+7UBUGGzqYb8 vd/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=U9bojEE95Zm+Bo6ILTseHxQlSN3dv4sEPldjzgDwgxA=; b=eG1jNoBYtu9ToP3pk2x9wP1xEqJMeGl5uT7Wr2QnIJQs0NAHlvu68/6BgcArzzocpz axTS68D92fNMpuysr5sz48Kb3uD/stJGQJK0l42q25UebmhiYnXh14EqGckAzRxYktcH pdwGm8OruTRUFD3N4RnhEWCX9+Sk+DHRyyq+tW1W7G4f74cFWFqK9jVqrmq4Vl31CY3s cP/zuPbes9639k9qaaTp8aVRrTifJ0urDtOUBnvKmTthJ/DOWCNHTxiIGOy39WCzPq0U SrOL2pDTzb/PiG8qjV1q76x9nQUc69vSFgTUHgfuVa9iFdgAw5j6JV1Ehk8wiWQegHyh +4xg== X-Gm-Message-State: AOUpUlG8ZMFUfIpT0wcml4Z9n6aYhHKJlOZL1CiVoCe8aZoFNgeCEPwj u27r3LjD4OF0bu0Xyb+3Pw30czUe0wMKTgjYgGc= X-Google-Smtp-Source: AAOMgpcxFxK/nKD1dkNIPW7tJJEp3bYanAri7Yk4swAIregAdKpkcbmegy36yD2x0+8qVSdfef24z2/UWKjDuDHwd5w= X-Received: by 2002:a17:902:7287:: with SMTP id d7-v6mr2395797pll.54.1533215987641; Thu, 02 Aug 2018 06:19:47 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 2002:a17:90a:1e64:0:0:0:0 with HTTP; Thu, 2 Aug 2018 06:19:46 -0700 (PDT) In-Reply-To: References: <0cb8f15b-7538-500c-dda3-915bf9814f94@gmail.com> <5D10C0C4-B93D-463F-A071-EEA6F35506CD@cisco.com> <76CD132C3ADEF848BD84D028D243C927A71506F6@NKGEML515-MBS.china.huawei.com> <76CD132C3ADEF848BD84D028D243C927A72042AB@NKGEML515-MBS.china.huawei.com> <89653c55-90e0-c52d-bdef-38b312b7feda@joelhalpern.com> <76CD132C3ADEF848BD84D028D243C927A72B1EF7@NKGEML515-MBS.china.huawei.com> <5c72cc37-c1e0-e806-701d-40a4cf756eee@joelhalpern.com> <644649c7-a5b5-9e78-8749-4a2109566cf9@gmail.com> From: Robert Raszuk Date: Thu, 2 Aug 2018 15:19:46 +0200 X-Google-Sender-Auth: 0U2RzaQcdrcpdHpzP4QdtV641mU Message-ID: To: "Ruediger.Geib@telekom.de Geib" Cc: Stewart Bryant , teas@ietf.org, RTGWG Content-Type: multipart/alternative; boundary="0000000000004eb41c057273aa4e" Archived-At: Subject: Re: [Teas] =?utf-8?b?562U5aSNOiBWUE4gc2VjdXJpdHkgdnMgU0QtV0FOIHNl?= =?utf-8?q?curity?= X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 13:19:52 -0000 --0000000000004eb41c057273aa4e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Very well said indeed ! One comment to your last sentence I think the slicing plan is to again lock given customer to single provider - just like it is locked today with L3/L2VPNs. The most interesting trend is however not even network related ... if we move up and observe that more real providers are offering services and those services actually work well all it will be required from any customer is last mile access to closest IX where provider of selected service (not to say on purpose "SP") has its presence. If this model succeeds and all financial reports indicate that it is doing pretty good - all our network slicing and dicing discussions will be moved to Muppet's balcony status. Cheers, r. On Thu, Aug 2, 2018 at 2:06 PM, wrote: > Stewart, > > I'd appreciate a discussion based on operational experience. In which > Diffserv supported network did which application fail due to a lack of > suitable scheduling or due to a lack of codepoints, which would have been > working properly on the same network with Detnet and more codepoints? I'd > be happy, if you were able to provide a link to a presentation. > > I've started my QoS career with ATM, a technology offering dedicated QoS > network resources. Spare capacities with a network-fully-booked indicatio= n > were the first lesson I learned, and this combination turned out to be ba= d > whenever I encountered it from then on. My take on Diffserv is, that it i= s > useful to protect certain traffic in the case of not foreseen networking > conditions. That means, in 99,....% of the time, todays Diffserv isn't > required, because there's no congestion. > > You seem to head for generic solutions, applicable in all parts of the > Internet. I don't understand what the benefit of dedicated resources woul= d > be, given they are required end-to-end. I excuse if I missed a statement > that the approach you propose is limited to specific instances or section= s > of the Internet. > > Regards, > > Ruediger > > > -----Urspr=C3=BCngliche Nachricht----- > Von: rtgwg [mailto:rtgwg-bounces@ietf.org] Im Auftrag von Stewart Bryant > Gesendet: Donnerstag, 2. August 2018 13:19 > An: Joel M. Halpern ; Dongjie (Jimmy) < > jie.dong@huawei.com> > Cc: TEAS WG (teas@ietf.org) ; rtgwg@ietf.org > Betreff: Re: [Teas] =E7=AD=94=E5=A4=8D: VPN security vs SD-WAN security > > > > On 01/08/2018 16:26, Joel M. Halpern wrote: > > I am not disagreeing with a view that network resource allocation > > requires some visibility to those resources. > > It is the assertion of a "deep integration" that seems to lack groundin= g. > > > > We know that one can use our existing VPN technologies and tools like > > diffserv, with suitable admission control and path computation, to > > provide strong service guarantees to meet SLAs. As others have noted > > in other presentations, when it comes to the data plane this seems to > > meet the articulated needs from various fora. > > > Hi Joel, > > We can certainly get a long way with those tools for "conventional" > applications. > > However, as we support the sort of applications that look for a > deterministic networking class of SLA, then I am concerned that we need t= o > map the traffic to dedicated resources in more detail than we currently d= o > through the diffserv mechanism. > > What we do at the moment with diffserv is a mapping of packets to > resources, but in practise we limit those resources to ingress and egress > queues with the queue management algorithm out of scope. I am not convinc= ed > this is adequate for the future, and think that we need to start to > consider CPU/NPU cores, queue algorithms, and maybe other resources. > > I am also concerned that the number of diffserv code points available in > MPLS is going to be insufficient. > > Of course what we know today from experience is based on the applications > that can run on the network infrastructure that we have today. That is a > self limiting situation. We are designing DETNET because this model is > inadequate for some classes of application that would like to run over a > more general network. What we are doing with > VPN+ is to integrate DETNET into a VPN structure alongside classic VPNs. > > - Stewart > > > > Yours, > > Joel > > > > On 8/1/18 11:22 AM, Dongjie (Jimmy) wrote: > >> This statement is based on the comparison between overlay VPNs and > >> network slices. The resource here refers to various data plane > >> resources that can be allocated to a particular slice (queues, > >> buffer, etc.). Some level of resource isolation is necessary to > >> ensure that service in one slice never interferes with service in > >> another slice. > >> > >> May I know what are the requirements you've got? > >> > >> Best regards, > >> Jie > >> > >>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > >>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Joel M. Halpern [mailto:jmh@joelhalpern.= com] > >>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2018=E5=B9=B47=E6=9C=8830=E6=97= =A5 23:05 > >>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Dongjie (Jimmy) > >>> =E6=8A=84=E9=80=81: TEAS WG (teas@ietf.org) ; rtgwg@ie= tf.org > >>> =E4=B8=BB=E9=A2=98: Re: VPN security vs SD-WAN security > >>> > >>> Actually, assuming I understand the statement properly, "deep > >>> integration with the underlay resource would be necessary" does not > >>> appear to be an accurate statement derivable from the requirements > >>> that I have seen. > >>> > >>> Yours, > >>> Joel > >>> > >>> On 7/30/18 8:23 AM, Dongjie (Jimmy) wrote: > >>>> (Adding TEAS as it is where the VPN+ framework draft is discussed) > >>>> > >>>> Hi Robert and Greg, > >>>> > >>>> As discussed during the VPN+ presentation in TEAS at IETF 102, the > >>>> scope is not the internet, as we know it would quite difficult or > >>>> even impossible to achieve the required guarantee at the scope of > internet. > >>>> > >>>> And clearly the VPN overlays cannot provide the required guarantee, > >>>> deep integration with the underlay resource would be necessary. > >>>> > >>>> Another aspect we may take into consideration is the factor of > >>>> overprovisioning. The current network only has one overprovisioning > >>>> factor, which may not meet the requirement of different > >>>> services/customers. With network slicing, it is possible to have > >>>> different overprovisioning policy and factor in different slices. > >>>> > >>>> Best regards, > >>>> > >>>> Jie > >>>> > >>>> *From:*rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of > >>>> *Robert Raszuk > >>>> *Sent:* Sunday, July 29, 2018 6:11 AM > >>>> *To:* Greg Mirsky > >>>> *Cc:* Dongjie (Jimmy) ; rtgwg@ietf.org > >>>> *Subject:* Re: VPN security vs SD-WAN security > >>>> > >>>> Hey Greg, > >>>> > >>>>> > >>>> > >>>> would not require global transit and likely be contained within > >>>> access or, at most, metro domains. > >>>> > >>>> That's news to me, but perhaps on the positive side :) I always > >>>> think WAN .. really wide one ! > >>>> > >>>> The separation on "soft" vs "hard" guarantees is eventually all > >>>> about amount of network robustness and level of over provisioning. > >>>> I sincerely hope it will not be yet another EVPN overlay over IP > >>>> network just painted with different marketing colors. > >>>> > >>>> Besides if any customer is serious and actually counts on those > >>>> guarantees he better purchase two of such services coming from > >>>> independent operators. That means that to be attractive financially > >>>> cost of such premium service must not be higher then half of the > >>>> p2p local fiber or cost of local access to closest IX ports + port > >>>> subscription in a given MAN where non blocking IX fabric spans > >>>> given > >>> geography. > >>>> > >>>> It seems to me that at the end of the day the space for those > >>>> operators wishing to offer hard network slicing is actually pretty > >>>> narrow, but time will tell ... > >>>> > >>>> Rgs, > >>>> > >>>> r. > >>>> > >>>> On Sat, Jul 28, 2018 at 9:34 PM, Greg Mirsky >>>> > wrote: > >>>> > >>>> Hi Robert, > >>>> > >>>> very much agree with all you're saying and find us in violent > >>>> agreement on "C". Proactive performance monitoring, in my view > >>>> as > >>>> well, is the reasonable path to provide "soft" SLA and, to a > >>>> degree, > >>>> prevent oversubscription of the network. And that, as you've > >>>> said, > >>>> is one way to "assured/guaranteed global IP transit". > >>>> > >>>> But I think that there will be demand for "hard" guarantees > >>>> for > >>>> URLLC applications. But these, in my view, > >>>> > >>>> would not require global transit and likely be contained > >>>> within > >>>> access or, at most, metro domains. Because of the limited size > >>>> of > >>>> the domain, IntServ may work, though that may be not the most > >>>> efficient technique. We shall find out. > >>>> > >>>> Hence my view on slicing: > >>>> > >>>> * different applications will have different requirements > >>>> and use > >>>> different degrees of isolation and guarantees; > >>>> * "soft" slices may not need much of additional > >>>> standardization > >>>> and use available VPN technologies in combination with PM > >>>> OAM > >>>> for SLA monitoring and assurance; > >>>> * "hard" slices would span within a single access and/or > >>>> metro > >>>> domain. Networking solutions likely will be coupled with > >>>> architecture and interfaces developed in Multi-access Edge > >>>> Computing (MEC). > >>>> > >>>> Regards, > >>>> > >>>> Greg > >>>> > >>>> On Sat, Jul 28, 2018 at 6:02 AM, Robert Raszuk > >>>> >>>> > wrote: > >>>> > >>>> Hi Jie, > >>>> > >>>> > (network slicing) is to provide the demanding services > >>>> with guaranteed performance in a converged network, > >>>> > >>>> Foundation of converged IP network is based on statistical > >>>> multiplexing of traffic demands. As such it is in its > >>>> principle > >>>> quite contradictory to "guaranteed" characteristics > >>>> (performance, delays, jitter, drops -- you name it). > >>>> > >>>> Application layers usually deal very well with all of the > >>>> above > >>>> I would state - normal characteristics of IP networks.. > >>>> > >>>> No doubt there will be those trying to offer some network > >>>> slicing with guarantees and even those who will buy it. > >>>> Just > >>>> like today there are those who offer you L2 circuit > >>>> between > >>>> endpoints except such L2 circuit is an emulated one with > >>>> zero > >>>> OEM visibility to the IP infrastructure underneath. > >>>> > >>>> Now the network slicing is clearly aiming for even more > >>>> complexity under the hood. And that is not the only > >>>> problem. The > >>>> issue is cost. When SP is building the IP network the goal > >>>> is to > >>>> mux as many services on it as it simply results in given's > >>>> SP > >>>> revenue. Network slicing is promising as potentially just > >>>> by > >>>> configuration of few knobs they will be claiming > >>>> guarantees as > >>>> RFC says - except RFC will not likely tell you to stop > >>>> over-provisioning. > >>>> > >>>> Unless the idea is to use strict policing with dedicated > >>>> queuing > >>>> on active and back paths or do something like RSVP IntServ > >>>> also > >>>> on active and backup paths per customer - I really don't > >>>> think > >>>> you can really guarantee much. And if you do that the cost > >>>> would > >>>> likely grow really steep. > >>>> > >>>> So what is IMO the solution for assured/guaranteed global > >>>> IP > >>>> transit: > >>>> > >>>> *A* get diversely routed dark fiber paths between your > >>>> POPs > >>>> (can be unprotected) which btw today do not cost that much > >>>> anymore > >>>> > >>>> *B* get diversely routed optical channels alsol between > >>>> your > >>>> POPs (can be unprotected) > >>>> > >>>> *C* use N disjoined by design (single AS Internet > >>>> providers > >>>> between your end-points) + proper SD-WAN with active SLA > >>>> monitoring > >>>> > >>>> Clearly I am big supporter of *C* model for reasons > >>>> discussed on > >>>> this and few other recent threads. > >>>> > >>>> I assume network slicing will try to get into be something > >>>> between A/B & C but it is bounded up front with the cost > >>>> of the > >>>> two. > >>>> > >>>> Many thx, > >>>> > >>>> Robert. > >>>> > >>>> On Sat, Jul 28, 2018 at 9:51 AM, Dongjie (Jimmy) > >>>> > wrote: > >>>> > >>>> Hi Robert, > >>>> > >>>> IMO the two approaches are targeting at different use > >>>> cases > >>>> and customers. > >>>> > >>>> The former (network slicing) is to provide the > >>>> demanding > >>>> services with guaranteed performance in a converged > >>> network, > >>>> while the latter (switching between multiple > >>>> paralleled > >>>> networks) provides the customer with the best > >>>> performance > >>>> that is available among those candidates. To me the > >>>> latter > >>>> is still some kind of best effort, and as Toerless > >>>> said, it > >>>> depends on the diversity you can have in the multiple > >>> networks. > >>>> > >>>> And I agree with Stewart on =E2=80=9Cyou always pay a p= rice > >>>> for > >>>> better than best effort.=E2=80=9D > >>>> > >>>> Best regards, > >>>> > >>>> Jie > >>>> > >>>> *From:*rtgwg [mailto:rtgwg-bounces@ietf.org > >>>> ] *On Behalf Of *Robert > >>> Raszuk > >>>> *Sent:* Wednesday, July 25, 2018 8:24 PM > >>>> *To:* Acee Lindem (acee) >>>> > > >>>> *Cc:* rtgwg@ietf.org > >>>> > >>>> > >>>> *Subject:* Re: VPN security vs SD-WAN security > >>>> > >>>> True network slicing for IP networks means either > >>>> waist of > >>>> resources or very strict multi-level queuing at each > >>>> hop and > >>>> 100% ingress traffic policing. Yet while this has a > >>>> chance > >>>> to work during normal operation at the time of even > >>>> regular > >>>> failures this all pretty much melts like cheese on a > >>>> good > >>>> sandwich. > >>>> > >>>> It is going to be very interesting to compare how > >>>> single > >>>> complex sliced network compares for any end to end > >>>> robust > >>>> transport from N normal simple IP backbones and end to > >>> end > >>>> SLA based millisecond switch over between one and > >>>> another > >>> on > >>>> a per flow basis. Also let's note then while the > >>>> former is > >>>> still to the best of my knowledge a draft the latter > >>>> is > >>>> already deployed globally in 100s of networks. > >>>> > >>>> Best, > >>>> R. > >>>> > >>>> On Wed, Jul 25, 2018 at 1:21 PM, Acee Lindem (acee) > >>>> > wrote: > >>>> > >>>> *From: *rtgwg >>>> > on behalf of > >>>> Stewart > >>>> Bryant >>>> > > >>>> *Date: *Wednesday, July 25, 2018 at 5:55 AM > >>>> *To: *Robert Raszuk >>>> > > >>>> *Cc: *Routing WG >>> > > >>>> *Subject: *Re: VPN security vs SD-WAN security > >>>> > >>>> On 25/07/2018 10:40, Robert Raszuk wrote: > >>>> > >>>> /* Adjusting the subject ... */ > >>>> > >>>> Hello > >>>> > >>>> Stewart, > >>>> > >>>> You have made the below comment in the other > >>> thread > >>>> we are having: > >>>> > >>>> Indeed, I would have expected this to be > >>>> on a > >>>> secure network of some sort either purely > >>>> private or some form of VPN. However, I am > >>> sure > >>>> I read in your text that you were > >>>> considering using the Public Internet much > >>>> in > >>>> the way of SD-WAN. > >>>> > >>>> Would you mind as extensively as you can > >>>> expand > >>> on > >>>> the above statement ? > >>>> > >>>> Specifically on what basis do you treat say > >>>> L2VPN > >>> or > >>>> L3VPN of naked unencrypted packets often > >>> traveling > >>>> on the very same links as this "bad" Internet > >>>> traffic to be even slightly more secure then > >>>> IPSEC > >>>> or DTLS encrypted SD-WAN carried data with > >>> endpoints > >>>> being terminated in private systems ? > >>>> > >>>> Thx, > >>>> > >>>> Robert > >>>> > >>>> > >>>> Robert, I think that you have to take it as read > >>>> that an > >>>> air traffic control SoF system is encrypting its > >>>> packets. If it is not, then it is clearly not fit > >>>> for > >>>> purpose. > >>>> > >>>> What concerns me is that an air traffic system is > >>>> one of > >>>> the most, if not the most, high profile targets in > >>>> civil > >>>> society. You get reminded of this each time you > >>>> travel > >>>> to IETF. > >>>> > >>>> The thing about safety of flight traffic is that a > >>>> sustained and effective DDoS attack has global > >>>> impact in > >>>> a way that few other such attacks have. > >>>> > >>>> A VPN system ought to sustain resistance to such > >>>> an > >>>> attack better than the proposed system which > >>>> treats > >>> the > >>>> SoF traffic the same as regular traffic. > >>>> > >>>> I guess you are making a case for your network > >>>> slicing > >>>> work =F0=9F=98=89 > >>>> > >>>> Acee > >>>> > >>>> > >>>> > >>>> - Stewart > >>>> > >>>> _______________________________________________ > >>>> rtgwg mailing list > >>>> rtgwg@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/rtgwg > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> rtgwg mailing list > >>>> rtgwg@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/rtgwg > >>>> > > > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org > > https://www.ietf.org/mailman/listinfo/teas > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > --0000000000004eb41c057273aa4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Very well said indeed !=C2=A0

One comment to your last senten= ce I think the slicing plan is to again lock given customer to single provi= der - just like it is locked today with L3/L2VPNs.=C2=A0

The most interesting trend is however no= t even network related ... if we move up and observe that more real provide= rs are offering services and those services actually work well all it will = be required from any customer is last mile access to closest IX where provi= der of selected service (not to say on purpose "SP") has its pres= ence. If this model succeeds and all financial reports indicate that it is = doing pretty good - all our network slicing and dicing discussions will be = moved to Muppet's balcony status.

Cheers,
r.
=

O= n Thu, Aug 2, 2018 at 2:06 PM, <Ruediger.Geib@telekom.de> wrote:
Stewart,

I'd appreciate a discussion based on operational experience. In which D= iffserv supported network did which application fail due to a lack of suita= ble scheduling or due to a lack of codepoints, which would have been workin= g properly on the same network with Detnet and more codepoints? I'd be = happy, if you were able to provide a link to a presentation.

I've started my QoS career with ATM, a technology offering dedicated Qo= S network resources. Spare capacities with a network-fully-booked indicatio= n were the first lesson I learned, and this combination turned out to be ba= d whenever I encountered it from then on. My take on Diffserv is, that it i= s useful to protect certain traffic in the case of not foreseen networking = conditions. That means, in 99,....% of the time, todays Diffserv isn't = required, because there's no congestion.

You seem to head for generic solutions, applicable in all parts of the Inte= rnet. I don't understand what the benefit of dedicated resources would = be, given they are required end-to-end. I excuse if I missed a statement th= at the approach you propose is limited to specific instances or sections of= the Internet.

Regards,

Ruediger


-----Urspr=C3=BCngliche Nachricht-----
Von: rtgwg [mailto:rtgwg-bounces@ietf.org] Im Auftrag von Stewart Bryant
Gesendet: Donnerstag, 2. August 2018 13:19
An: Joel M. Halpern <jmh@joelhalp= ern.com>; Dongjie (Jimmy) <jie.dong@huawei.com>
Cc: TEAS WG (teas@ietf.org) <teas@ietf.org>; rtgwg@ietf.org
Betreff: Re: [Teas] =E7=AD=94=E5=A4=8D: VPN security vs SD-WAN security



On 01/08/2018 16:26, Joel M. Halpern wrote:
> I am not disagreeing with a view that network resource allocation
> requires some visibility to those resources.
> It is the assertion of a "deep integration" that seems to la= ck grounding.
>
> We know that one can use our existing VPN technologies and tools like =
> diffserv, with suitable admission control and path computation, to > provide strong service guarantees to meet SLAs. As others have noted <= br> > in other presentations, when it comes to the data plane this seems to =
> meet the articulated needs from various fora.
>
Hi Joel,

We can certainly get a long way with those tools for "conventional&quo= t;
applications.

However, as we support the sort of applications that look for a determinist= ic networking class of SLA, then I am concerned that we need to map the tra= ffic to dedicated resources in more detail than we currently do through the= diffserv mechanism.

What we do at the moment with diffserv is a mapping of packets to resources= , but in practise we limit those resources to ingress and egress queues wit= h the queue management algorithm out of scope. I am not convinced this is a= dequate for the future, and think that we need to start to consider CPU/NPU= cores, queue algorithms, and maybe other resources.

I am also concerned that the number of diffserv code points available in MP= LS is going to be insufficient.

Of course what we know today from experience is based on the applications t= hat can run on the network infrastructure that we have today. That is a sel= f limiting situation. We are designing DETNET because this model is inadequ= ate for some classes of application that would like to run over a more gene= ral network. What we are doing with
VPN+ is to integrate DETNET into a VPN structure alongside classic VPNs.
- Stewart


> Yours,
> Joel
>
> On 8/1/18 11:22 AM, Dongjie (Jimmy) wrote:
>> This statement is based on the comparison between overlay VPNs and=
>> network slices. The resource here refers to various data plane >> resources that can be allocated to a particular slice (queues, >> buffer, etc.). Some level of resource isolation is necessary to >> ensure that service in one slice never interferes with service in =
>> another slice.
>>
>> May I know what are the requirements you've got?
>>
>> Best regards,
>> Jie
>>
>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2018=E5=B9=B47=E6=9C=883= 0=E6=97=A5 23:05
>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Dongjie (Jimmy) <jie.dong@huawei.com>
>>> =E6=8A=84=E9=80=81: TEAS WG (= teas@ietf.org) <teas@ietf.org&g= t;; rtgwg@ietf.org
>>> =E4=B8=BB=E9=A2=98: Re: VPN security vs SD-WAN security
>>>
>>> Actually, assuming I understand the statement properly, "= deep
>>> integration with the underlay resource would be necessary"= ; does not
>>> appear to be an accurate statement derivable from the requirem= ents
>>> that I have seen.
>>>
>>> Yours,
>>> Joel
>>>
>>> On 7/30/18 8:23 AM, Dongjie (Jimmy) wrote:
>>>> (Adding TEAS as it is where the VPN+ framework draft is di= scussed)
>>>>
>>>> Hi Robert and Greg,
>>>>
>>>> As discussed during the VPN+ presentation in TEAS at IETF = 102, the
>>>> scope is not the internet, as we know it would quite diffi= cult or
>>>> even impossible to achieve the required guarantee at the s= cope of internet.
>>>>
>>>> And clearly the VPN overlays cannot provide the required g= uarantee,
>>>> deep integration with the underlay resource would be neces= sary.
>>>>
>>>> Another aspect we may take into consideration is the facto= r of
>>>> overprovisioning. The current network only has one overpro= visioning
>>>> factor, which may not meet the requirement of different >>>> services/customers. With network slicing, it is possible t= o have
>>>> different overprovisioning policy and factor in different = slices.
>>>>
>>>> Best regards,
>>>>
>>>> Jie
>>>>
>>>> *From:*rraszuk@gmail.= com [mailto:rraszuk@gmail.com]= *On Behalf Of
>>>> *Robert Raszuk
>>>> *Sent:* Sunday, July 29, 2018 6:11 AM
>>>> *To:* Greg Mirsky <gregimirsky@gmail.com>
>>>> *Cc:* Dongjie (Jimmy) <jie.dong@huawei.com>; rtgwg= @ietf.org
>>>> *Subject:* Re: VPN security vs SD-WAN security
>>>>
>>>> Hey Greg,
>>>>
>>>>>
>>>>
>>>> would not require global transit and likely be contained w= ithin
>>>> access or, at most, metro domains.
>>>>
>>>> That's news to me, but perhaps on the positive side :)= I always
>>>> think WAN .. really wide one !
>>>>
>>>> The separation on "soft" vs "hard" gua= rantees is eventually all
>>>> about amount of network robustness and level of over provi= sioning.=C2=A0
>>>> I sincerely hope it will not be yet another EVPN overlay o= ver IP
>>>> network just painted with different marketing colors.
>>>>
>>>> Besides if any customer is serious and actually counts on = those
>>>> guarantees he better purchase two of such services coming = from
>>>> independent operators. That means that to be attractive fi= nancially
>>>> cost of such premium service must not be higher then half = of the
>>>> p2p local fiber or cost of local access to closest IX port= s + port
>>>> subscription in a given MAN where non blocking IX fabric s= pans
>>>> given
>>> geography.
>>>>
>>>> It seems to me that at the end of the day the space for th= ose
>>>> operators wishing to offer hard network slicing is actuall= y pretty
>>>> narrow, but time will tell ...
>>>>
>>>> Rgs,
>>>>
>>>> r.
>>>>
>>>> On Sat, Jul 28, 2018 at 9:34 PM, Greg Mirsky <gregimirsky@gmail.com
>>>> <mailto:gregim= irsky@gmail.com>> wrote:
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 Hi Robert,
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 very much agree with all you'= re saying and find us in violent
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 agreement on "C". Proac= tive performance monitoring, in my view
>>>> as
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 well, is the reasonable path to p= rovide "soft" SLA and, to a
>>>> degree,
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 prevent oversubscription of the n= etwork. And that, as you've
>>>> said,
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 is one way to "assured/guara= nteed global IP transit".
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 But I think that there will be de= mand for "hard" guarantees
>>>> for
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 URLLC=C2=A0applications. But thes= e, in my view,
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 would not require global transit = and likely be contained
>>>> within
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 access=C2=A0or, at most, metro do= mains. Because of the limited size
>>>> of
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 the domain, IntServ may work, tho= ugh that may be not the most
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 efficient technique. We shall fin= d out.
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 Hence my view on slicing:
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * different applicati= ons will have different requirements
>>>> and use
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 different= degrees of isolation and guarantees;
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * "soft" sl= ices may not need much of additional
>>>> standardization
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and use a= vailable VPN technologies in combination with PM
>>>> OAM
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for SLA m= onitoring and assurance;
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * "hard" sl= ices would span within a single access and/or
>>>> metro
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 domain. N= etworking solutions likely will be coupled with
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 architect= ure and interfaces developed in Multi-access Edge
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Computing= (MEC).
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 Regards,
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 Greg
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 On Sat, Jul 28, 2018 at 6:02 AM, = Robert Raszuk
>>>> <robert@raszuk.net=
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 <mailto:robert@raszuk.net>> wrote:
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Hi Jie, >>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > (net= work slicing) is to provide the demanding services
>>>> with guaranteed performance in a converged network,
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Foundatio= n of converged IP network is based on statistical
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 multiplex= ing of traffic demands. As such it is in its
>>>> principle
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 quite con= tradictory to "guaranteed" characteristics
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (performa= nce, delays, jitter, drops -- you name it).
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Applicati= on layers usually deal very well with all of the
>>>> above
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I would s= tate - normal characteristics of IP networks..
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 No doubt = there will be those trying to offer some network
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 slicing w= ith guarantees and even those who will buy it.
>>>> Just
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 like toda= y there are those who offer you L2 circuit
>>>> between
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 endpoints= except such L2 circuit is an emulated one with
>>>> zero
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OEM visib= ility to the IP infrastructure underneath.
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Now the n= etwork slicing is clearly aiming for even more
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 complexit= y under the hood. And that is not the only
>>>> problem. The
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 issue is = cost. When SP is building the IP network the goal
>>>> is to
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 mux as ma= ny services on it as it simply results in given's
>>>> SP
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 revenue. = Network slicing is promising as potentially just
>>>> by
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 configura= tion of few knobs they will be claiming
>>>> guarantees as
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFC says = - except RFC will not likely tell you to stop
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 over-prov= isioning.
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Unless th= e idea is to use strict policing with dedicated
>>>> queuing
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 on active= and back paths or do something like RSVP IntServ
>>>> also
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 on active= and backup paths per customer - I really don't
>>>> think
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 you can r= eally guarantee much. And if you do that the cost
>>>> would
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 likely gr= ow really steep.
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 So what i= s IMO the solution for assured/guaranteed global
>>>> IP
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 transit:<= br> >>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *A*=C2=A0= get diversely routed=C2=A0 dark fiber paths between your
>>>> POPs
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (can be u= nprotected) which btw today do not cost that much
>>>> anymore
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *B* get d= iversely routed=C2=A0 optical channels alsol between
>>>> your
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 POPs (can= be unprotected)
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *C*=C2=A0= use N disjoined by design (single AS Internet
>>>> providers
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 between y= our end-points) + proper SD-WAN with active SLA
>>>> monitoring
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Clearly I= am big supporter of *C* model for reasons
>>>> discussed on
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 this and = few other recent threads.
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I assume = network slicing will try to get into be something
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 between A= /B & C but it is bounded up front with the cost
>>>> of the
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 two.
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Many thx,=
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Robert. >>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 On Sat, J= ul 28, 2018 at 9:51 AM, Dongjie (Jimmy)
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <jie.dong@huawei.com <mailto:jie.dong@huawei.com>> wrote:
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Hi Robert,
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 IMO the two approaches are targeting at different use
>>>> cases
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 and customers.
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 The former (network slicing) is to provide the
>>>> demanding
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 services with guaranteed performance in a converged
>>> network,
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 while the latter (switching between multiple
>>>> paralleled
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 networks) provides the customer with the best
>>>> performance
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 that is available among those candidates. To me the
>>>> latter
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 is still some kind of best effort, and as Toerless
>>>> said, it
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 depends on the diversity you can have in the multiple
>>> networks.
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 And I agree with Stewart on =E2=80=9Cyou always pay a price=
>>>> for
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 better than best effort.=E2=80=9D
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Best regards,
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Jie
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 *From:*rtgwg [mailto:rtgwg-bounces@ietf.org
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 <mailto:rtgwg-= bounces@ietf.org>] *On Behalf Of *Robert
>>> Raszuk
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 *Sent:* Wednesday, July 25, 2018 8:24 PM
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 *To:* Acee Lindem (acee) <acee@cisco.com
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 <mailto:acee@cisco.com= >>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 *Cc:* rtgwg@ietf.org = <mailto:rtgwg@ietf.org>
>>>>
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 *Subject:* Re: VPN security vs SD-WAN security
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 True network slicing for IP networks means either
>>>> waist of
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 resources or very strict multi-level queuing at each
>>>> hop and
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 100% ingress traffic policing. Yet while this has a
>>>> chance
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 to work during normal operation at the time of even
>>>> regular
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 failures this all pretty much melts like cheese on a
>>>> good
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 sandwich.
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 It is going to be very interesting to compare how
>>>> single
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 complex sliced network compares for any end to end
>>>> robust
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 transport from N normal simple IP backbones and end to
>>> end
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 SLA based millisecond switch over between one and
>>>> another
>>> on
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 a per flow basis. Also let's note then while the
>>>> former is
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 still to the best of my knowledge a draft the latter
>>>> is
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 already deployed globally in 100s of networks.
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Best,
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 R.
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 On Wed, Jul 25, 2018 at 1:21 PM, Acee Lindem (acee)
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 <acee@cisco.com &l= t;mailto:acee@cisco.com>> wrote= :
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *From: *rtgwg <rtgwg-bounces@ietf.org
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:rtgwg-bounces@ietf.org>> on behalf of
>>>> Stewart
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Bryant <stewart.bryant@gmail.com
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:stewart.bryant@gmail.com>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *Date: *Wednesday, July 25, 2018 at= 5:55 AM
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *To: *Robert Raszuk <robert@raszuk.net
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:robert@raszuk.net>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *Cc: *Routing WG <rtgwg@ietf.org
>>> <mailto:rtgwg@ietf.org>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *Subject: *Re: VPN security vs SD-W= AN security
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 On 25/07/2018 10:40, Robert Raszuk = wrote:
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* Adjustin= g the subject ... */
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Hello
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Stewart, >>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 You have ma= de the below comment in the other
>>> thread
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 we are havi= ng:
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Indeed, I would have expected this to be
>>>> on a
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 secure network of some sort either purely
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 private or some form of VPN. However, I am
>>> sure
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 I read in your text that you were
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 considering using the Public Internet much
>>>> in
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 the way of SD-WAN.
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Would you m= ind as extensively as you can
>>>> expand
>>> on
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the above s= tatement ?
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Specificall= y on what basis do you treat say
>>>> L2VPN
>>> or
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 L3VPN of na= ked unencrypted packets often
>>> traveling
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 on the very= same links as this "bad" Internet
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 traffic to = be even slightly more secure then
>>>> IPSEC
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 or DTLS enc= rypted SD-WAN carried data with
>>> endpoints
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 being termi= nated in private systems ?
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thx,
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Robert
>>>>
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Robert, I think that you have to ta= ke it as read
>>>> that an
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 air traffic control SoF system is e= ncrypting its
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 packets. If it is not, then it is c= learly not fit
>>>> for
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 purpose.
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 What concerns me is that an air tra= ffic system is
>>>> one of
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the most, if not the most, high pro= file targets in
>>>> civil
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 society. You get reminded of this e= ach time you
>>>> travel
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to IETF.
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The thing about safety of flight tr= affic is that a
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sustained and effective DDoS attack= has global
>>>> impact in
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a way that few other such attacks h= ave.
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A VPN system ought to sustain resis= tance to such
>>>> an
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 attack better than the proposed sys= tem which
>>>> treats
>>> the
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SoF traffic the same as regular tra= ffic.
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I guess you are making a case for y= our network
>>>> slicing
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 work =F0=9F=98=89
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Acee
>>>>
>>>>
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Stewart
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 _________= ______________________________________
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 rtgwg mai= ling list
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 rtgwg@ietf.org <mailto:rtgwg@ietf.org>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://www.ietf.org/mailman/listinfo/rtgwg
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> rtgwg mailing list
>>>> rtgwg@ietf.org
>>>> https://www.ietf.org/mailman/listin= fo/rtgwg
>>>>
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

--0000000000004eb41c057273aa4e-- From nobody Thu Aug 2 13:41:41 2018 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0B2130E04 for ; Thu, 2 Aug 2018 13:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eewGyodV1MUG for ; Thu, 2 Aug 2018 13:41:37 -0700 (PDT) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51C44130E01 for ; Thu, 2 Aug 2018 13:41:37 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id a26-v6so1978912pfo.4 for ; Thu, 02 Aug 2018 13:41:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=uPpmpCgLoqeDiZJU2hn86Fkhfp9BDLOw+kBsfGAFgtY=; b=RxbGTJhSyfSVRByHD0dlhAE1ERyI9tXuNw6xQS4nTTIk17Ngrnt563bfHfJTofY494 qCB1n4+iNcwCOv0pcWizmQCoscbjxfnm9lhCqIYd7lQr1Vrnx+eSBrnqdbUVR3ZswRPa kYVhrPc6BZ6y5cgPNXTcIa2TRgKbJZ9grDxDqRNsmC79aq+JutUFGFk9Ucu9X34pzXNM 4mHcml+qJ8oRQaedxdOmqmZSE9ZZxEJykcSXlsQ/8P6lh+tBNay7pH7aNoS49sm5nIph jJiyF1tIvrRXRnPKI4Mx39WyGwIeEMKhGLYS01e03JaqhR9bcBwvTbHP/floe0XCau3q byPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=uPpmpCgLoqeDiZJU2hn86Fkhfp9BDLOw+kBsfGAFgtY=; b=G2ryXHQesrUtFLx4cU4uw9CUliHJVKTOGEB6VIPV3q2dXJnE9SH+n9hP89Qx7D4DDw GnzrGNxaYFtvgBuTSuRRv4W11/kyYQSN7dhGxOXSHxGLXUcF4su0DxCYXyC1XDyY4VUH rcZ0x8tgj6nI56rZTz502Y7uFnX5FQqS8WVAWWAMNGQd7qYfFcA3IWI2IHv03Hnnbi4O ciSlEh2hUwraj91O0aNRaa+0XKts/UK05OxW/o7tPuA5rbBn4izLGs6Ux3krL01aYf3M eLSooEL9PxnqQnnpdiXKLHCefn/k27bhTrGXgfFoKGwvzVG3I+zJJZv9M/4nEC7gy0DZ kvYg== X-Gm-Message-State: AOUpUlF3WlqC4OgQ87dsr1JhshyI+T4opLrq6V3A4Ez2LjXSYvBKRYLO z9pbIPyvz6hnC+ajF3ERyNFqzdVBFl0+Pqru0DLdTvkR X-Google-Smtp-Source: AAOMgpepvffOkdfPAVqDMzzfg/R72VSq+G0FhlzoA3ieUKJnz7tFPZMiSZDzf+YFR1piICDVbBZvx87DoyPWfWeGNyc= X-Received: by 2002:a62:a05:: with SMTP id s5-v6mr1057331pfi.147.1533242496902; Thu, 02 Aug 2018 13:41:36 -0700 (PDT) MIME-Version: 1.0 From: Matt Hartley Date: Thu, 2 Aug 2018 16:41:25 -0400 Message-ID: To: teas@ietf.org Content-Type: multipart/alternative; boundary="00000000000061ead8057279d624" Archived-At: Subject: [Teas] Minutes from Montreal X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 20:41:39 -0000 --00000000000061ead8057279d624 Content-Type: text/plain; charset="UTF-8" All, I've made a few edits to the etherpad and uploaded the draft minutes from our meeting in Montreal. Please have a look and let me know if there's any changes that need to be made. http://etherpad.tools.ietf.org:9000/p/notes-ietf-102-teas?useMonospaceFont=true https://datatracker.ietf.org/meeting/102/materials/minutes-102-teas-00.txt Cheers Matt --00000000000061ead8057279d624 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

I've made a few edi= ts to the etherpad and uploaded the draft minutes from our meeting in Montr= eal. Please have a look and let me know if there's any changes that nee= d to be made.

<= div>https://datatracker.ietf.org/meeting/102/materials/minutes-= 102-teas-00.txt

Cheers

Matt
--00000000000061ead8057279d624-- From nobody Thu Aug 2 19:28:07 2018 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E197130F3E for ; Thu, 2 Aug 2018 19:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xF1A0RJntmbk for ; Thu, 2 Aug 2018 19:28:03 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFA94130F3C for ; Thu, 2 Aug 2018 19:28:03 -0700 (PDT) Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 7ED00527D0168 for ; Fri, 3 Aug 2018 03:27:59 +0100 (IST) Received: from DGGEML424-HUB.china.huawei.com (10.1.199.41) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.399.0; Fri, 3 Aug 2018 03:28:00 +0100 Received: from DGGEML511-MBX.china.huawei.com ([169.254.1.109]) by dggeml424-hub.china.huawei.com ([10.1.199.41]) with mapi id 14.03.0382.000; Fri, 3 Aug 2018 10:27:54 +0800 From: "Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept)" To: TEAS WG Thread-Topic: New Version Notification for draft-zheng-teas-gmpls-controller-inter-work-00.txt Thread-Index: AdQq0XX5OlIBZfQAT6uNZQDu5VcW3g== Date: Fri, 3 Aug 2018 02:27:54 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.57.78.212] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Teas] Fw: New Version Notification for draft-zheng-teas-gmpls-controller-inter-work-00.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 02:28:06 -0000 RGVhciBXRyBleHBlcnRzLCANCg0KRHVyaW5nIE1vbnRyZWFsIGNjYW1wIHNlc3Npb24sIHRoZXJl IHdhcyByZXF1ZXN0IG9uIG1vdmluZyAnZHJhZnQtemhlbmctY2NhbXAtZ21wbHMtY29udHJvbGxl ci1pbnRlci13b3JrJyBpbnRvIHRlYXMuIEFmdGVyIGRpc2N1c3Npb24gd2l0aCB0aGUgY2hhaXJz IGluIGNjYW1wICYgdGVhcywgdG9nZXRoZXIgd2l0aCByb3V0aW5nIEFELCB0aGlzIHdvcmsgaXMg c3VnZ2VzdGVkIHRvIGJlIHByb2dyZXNzZWQgaW4gdGVhcy4gDQoNCk5vdyB0aGUgZHJhZnQgaXMg cmUtcHVibGlzaGVkIGFzIGRyYWZ0LXpoZW5nLXRlYXMtZ21wbHMtY29udHJvbGxlci1pbnRlci13 b3JrIGFuZCByZXBsYWNlIHRoZSBjY2FtcCBvbmUuIFBsZWFzZSBmZWVsIGZyZWUgdG8gcmV2aWV3 IGFuZCBwcm92aWRlIHlvdXIgY29tbWVudHMuIFRoYW5rIHlvdS4gDQoNCkJlc3Qgd2lzaGVzLA0K SGFvbWlhbg0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQrlj5HpgIHm l7bpl7Q6IDIwMTjlubQ45pyIM+aXpSAxMDoyMw0K5pS25Lu25Lq6OiBaaGVuZ2hhb21pYW4gKFpo ZW5naGFvbWlhbiwgT3B0aWNhbCAmTWljcm93YXZlIFRlY2hub2xvZ3kgUmVzZWFyY2ggRGVwdCkg PHpoZW5naGFvbWlhbkBodWF3ZWkuY29tPjsgWXVuYmluIFh1IDx4dXl1bmJpbkByaXR0LmNuPjsg THVveGlhbmxvbmcgPGx1b3hpYW5sb25nQGh1YXdlaS5jb20+OyBTZXJnaW8gQmVsb3R0aSA8c2Vy Z2lvLmJlbG90dGlAbm9raWEuY29tPjsgWmhlbmdoYW9taWFuIChaaGVuZ2hhb21pYW4sIE9wdGlj YWwgJk1pY3Jvd2F2ZSBUZWNobm9sb2d5IFJlc2VhcmNoIERlcHQpIDx6aGVuZ2hhb21pYW5AaHVh d2VpLmNvbT47IERpZXRlciBCZWxsZXIgPGRpZXRlci5iZWxsZXJAbm9raWEuY29tPjsgWWFuZyBa aGFvIDx6aGFveWFuZ3lqeUBjaGluYW1vYmlsZS5jb20+DQrkuLvpopg6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtemhlbmctdGVhcy1nbXBscy1jb250cm9sbGVyLWludGVyLXdv cmstMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXpoZW5nLXRlYXMtZ21w bHMtY29udHJvbGxlci1pbnRlci13b3JrLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCBieSBIYW9taWFuIFpoZW5nIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9y eS4NCg0KTmFtZToJCWRyYWZ0LXpoZW5nLXRlYXMtZ21wbHMtY29udHJvbGxlci1pbnRlci13b3Jr DQpSZXZpc2lvbjoJMDANClRpdGxlOgkJSW50ZXJ3b3JraW5nIG9mIEdNUExTIENvbnRyb2wgYW5k IENlbnRyYWxpemVkIENvbnRyb2xsZXIgU3lzdGVtDQpEb2N1bWVudCBkYXRlOgkyMDE4LTA4LTAz DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxNA0KVVJMOiAgICAgICAg ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC16aGVuZy10ZWFz LWdtcGxzLWNvbnRyb2xsZXItaW50ZXItd29yay0wMC50eHQNClN0YXR1czogICAgICAgICBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aGVuZy10ZWFzLWdtcGxzLWNvbnRy b2xsZXItaW50ZXItd29yay8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtemhlbmctdGVhcy1nbXBscy1jb250cm9sbGVyLWludGVyLXdvcmstMDANCkh0 bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0 LXpoZW5nLXRlYXMtZ21wbHMtY29udHJvbGxlci1pbnRlci13b3JrDQoNCg0KQWJzdHJhY3Q6DQog ICBHZW5lcmFsaXplZCBNdWx0aS1Qcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcgKEdNUExTKSBjb250 cm9sIGFsbG93cw0KICAgZWFjaCBuZXR3b3JrIGVsZW1lbnQgKE5FKSB0byBwZXJmb3JtIGxvY2Fs IHJlc291cmNlIGRpc2NvdmVyeSAoZS5nLiwNCiAgIExNUCksIHJvdXRpbmcgKGUuZy4sIE9TUEYt VEUpIGFuZCBzaWduYWxpbmcgKGUuZy4sIFJTVlAtVEUpIGluIGENCiAgIGRpc3RyaWJ1dGVkIG1h bm5lci4NCg0KICAgT24gdGhlIG90aGVyIGhhbmQsIHdpdGggdGhlIGRldmVsb3BtZW50IG9mIHNv ZnR3YXJlLWRlZmluZWQNCiAgIHRyYW5zcG9ydCBuZXR3b3JraW5nIHRlY2hub2xvZ3ksIGEgc2V0 IG9mIE5FcyBjYW4gYmUgY29udHJvbGxlZCB2aWENCiAgIGNlbnRyYWxpemVkIGNvbnRyb2xsZXIg aGllcmFyY2hpZXMgdG8gYWRkcmVzcyB0aGUgaXNzdWUgZnJvbSBtdWx0aS0NCiAgIGRvbWFpbiwg bXVsdGktdmVuZG9yIGFuZCBtdWx0aS10ZWNobm9sb2d5LiBBbiBleGFtcGxlIG9mIHN1Y2gNCiAg IGNlbnRyYWxpemVkIGFyY2hpdGVjdHVyZSBpcyBBQ1ROIGNvbnRyb2xsZXIgaGllcmFyY2h5IFtJ LUQuaWV0Zi0NCiAgIHRlYXMtYWN0bi1mcmFtZXdvcmtdLg0KDQogICBJbnN0ZWFkIG9mIGNvbXBl dGluZyB3aXRoIGVhY2ggb3RoZXIsIGJvdGggdGhlIGRpc3RyaWJ1dGVkIGFuZCB0aGUNCiAgIGNl bnRyYWxpemVkIGNvbnRyb2wgcGxhbmUgaGF2ZSB0aGVpciBvd24gYWR2YW50YWdlLCBhbmQgc2hv dWxkIGJlDQogICBjb21wbGVtZW50YXJ5IGluIHRoZSBzeXN0ZW0uIFRoaXMgZG9jdW1lbnQgZGVz Y3JpYmVzIGhvdyB0aGUgR01QTFMNCiAgIGRpc3RyaWJ1dGVkIGNvbnRyb2wgcGxhbmUgY2FuIGlu dGVyd29yayB3aXRoIGEgY2VudHJhbGl6ZWQNCiAgIGNvbnRyb2xsZXIgc3lzdGVtIGluIGEgdHJh bnNwb3J0IG5ldHdvcmsuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ug bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv ZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFp bGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Mon Aug 6 11:18:42 2018 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A228130ED7; Mon, 6 Aug 2018 11:18:40 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceaSUMZ8-5dX; Mon, 6 Aug 2018 11:18:37 -0700 (PDT) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE02F130EC8; Mon, 6 Aug 2018 11:18:36 -0700 (PDT) Received: by mail-wm0-x244.google.com with SMTP id t25-v6so15257024wmi.3; Mon, 06 Aug 2018 11:18:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=6FqOArE3rdszIIbCkcf5xC42T14j8Dd6DR99YX5Mu6s=; b=EAZ5/Ie2ftl97S0m1D3LngmQgfXaOnd4guyuGBPhhXHnCKmI7AVtHOeqtDle/AIfNV Gf/RWhSkFmm3v5zv+nFLYEvw7yQD68jAdakNrHccIJzjUzjPZYK+z5j4WG3nwfjlE7Sv +HGVFksgyg0KkMUxqh+BIz00fh7RxUbPVdoV39ggwHtwYf3/j50t5hm4tX5FSNV5oT9G RaAnvMXLboU5uvjYD9OGfwjrvpj4wJOh7wtk23OhmJql6JycRJZ3vOzMZBe2L9sKPWRU HnjNau/49zOgHHIeCTg0StJv6JorSSfsW3HqZWDR2C32CSbuznrxmuHEA/dFbH87XDdg XrEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=6FqOArE3rdszIIbCkcf5xC42T14j8Dd6DR99YX5Mu6s=; b=EstoCb/ImQy79NzeWMrkenNglQvVmlvrVFrQ5wUBMZ3QQAkVUOMYyupsHzd/F5CQjt BYe2hxAehrjxBxFPjcJ393f9O833WubXfGZA4zfFMhsTc/g7Kj0PdibBvS/Ud2x21rj/ YdAmUU824oJhaQ/IIzwbnMQnjj9bj3xwwF9YrfrDAttWbcf5KsevLwcXFz9cgb85RsBL KoqxD2+rLGHjF+2247b7m1OJNjhEqfWZ3HXBeunNJrnzxaiQ2NUM+EWRddbXe2XIV/BL IXE2w3YDX8gONlnRs/x4FgUI3vcNeG/UJfCTdHqJiDibfMdJX/64dbEwhd8OJIW++7aM OxWw== X-Gm-Message-State: AOUpUlH4qSiJpsrf/LMKK3WknTAvdPr7c7dQx6KvXRmo87iOYUj/Z0IM uy5PzjBfAj3m8pd3IiGhb6dHojq2 X-Google-Smtp-Source: AAOMgpdzInRCXbWrMkIzAvzVJRmjLyhUSLSsJo7nJMKSEti027FYjDFSHzljtiQhLAtOGiNfnFQh8w== X-Received: by 2002:a1c:168a:: with SMTP id 132-v6mr13557419wmw.13.1533579514850; Mon, 06 Aug 2018 11:18:34 -0700 (PDT) Received: from [192.168.2.105] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id m68-v6sm15424466wmb.10.2018.08.06.11.18.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Aug 2018 11:18:34 -0700 (PDT) To: Ruediger.Geib@telekom.de Cc: teas@ietf.org, rtgwg@ietf.org References: <0cb8f15b-7538-500c-dda3-915bf9814f94@gmail.com> <5D10C0C4-B93D-463F-A071-EEA6F35506CD@cisco.com> <76CD132C3ADEF848BD84D028D243C927A71506F6@NKGEML515-MBS.china.huawei.com> <76CD132C3ADEF848BD84D028D243C927A72042AB@NKGEML515-MBS.china.huawei.com> <89653c55-90e0-c52d-bdef-38b312b7feda@joelhalpern.com> <76CD132C3ADEF848BD84D028D243C927A72B1EF7@NKGEML515-MBS.china.huawei.com> <5c72cc37-c1e0-e806-701d-40a4cf756eee@joelhalpern.com> <644649c7-a5b5-9e78-8749-4a2109566cf9@gmail.com> From: Stewart Bryant Message-ID: <90595ec5-89ff-6289-67a5-7aa32a8fc8a1@gmail.com> Date: Mon, 6 Aug 2018 19:18:26 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [Teas] =?utf-8?b?562U5aSNOiBWUE4gc2VjdXJpdHkgdnMgU0QtV0FOIHNl?= =?utf-8?q?curity?= X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 18:18:40 -0000 Ruediger The work I am doing on VPN+ is not targetted at the big I Internet. It is targetted at mobile edge, access and the core of the mobile provider. These are the customers that are asking for the service, and that in turn is based on the output of SDOs that they are more comfortable associating with (3GPP and ITU-R). However, as we all know, a lot of traffic that users consider to go across the big I internet is between them and the PoP of the CDN provider supporting the service they are accessing. That is the model that the mobile operators want to propagate by pulling compute resources closer to the edge of their network than is currently the case. I am sure there are commercial reasons why they want that to happen but there are also application reasons that drive architecture reasons, and if they align with commercial reasons it is more likely to get deployed. - Stewart On 02/08/2018 13:06, Ruediger.Geib@telekom.de wrote: > Stewart, > > I'd appreciate a discussion based on operational experience. In which Diffserv supported network did which application fail due to a lack of suitable scheduling or due to a lack of codepoints, which would have been working properly on the same network with Detnet and more codepoints? I'd be happy, if you were able to provide a link to a presentation. > > I've started my QoS career with ATM, a technology offering dedicated QoS network resources. Spare capacities with a network-fully-booked indication were the first lesson I learned, and this combination turned out to be bad whenever I encountered it from then on. My take on Diffserv is, that it is useful to protect certain traffic in the case of not foreseen networking conditions. That means, in 99,....% of the time, todays Diffserv isn't required, because there's no congestion. > > You seem to head for generic solutions, applicable in all parts of the Internet. I don't understand what the benefit of dedicated resources would be, given they are required end-to-end. I excuse if I missed a statement that the approach you propose is limited to specific instances or sections of the Internet. > > Regards, > > Ruediger > > > -----Ursprüngliche Nachricht----- > Von: rtgwg [mailto:rtgwg-bounces@ietf.org] Im Auftrag von Stewart Bryant > Gesendet: Donnerstag, 2. August 2018 13:19 > An: Joel M. Halpern ; Dongjie (Jimmy) > Cc: TEAS WG (teas@ietf.org) ; rtgwg@ietf.org > Betreff: Re: [Teas] 答复: VPN security vs SD-WAN security > > > > On 01/08/2018 16:26, Joel M. Halpern wrote: >> I am not disagreeing with a view that network resource allocation >> requires some visibility to those resources. >> It is the assertion of a "deep integration" that seems to lack grounding. >> >> We know that one can use our existing VPN technologies and tools like >> diffserv, with suitable admission control and path computation, to >> provide strong service guarantees to meet SLAs. As others have noted >> in other presentations, when it comes to the data plane this seems to >> meet the articulated needs from various fora. >> > Hi Joel, > > We can certainly get a long way with those tools for "conventional" > applications. > > However, as we support the sort of applications that look for a deterministic networking class of SLA, then I am concerned that we need to map the traffic to dedicated resources in more detail than we currently do through the diffserv mechanism. > > What we do at the moment with diffserv is a mapping of packets to resources, but in practise we limit those resources to ingress and egress queues with the queue management algorithm out of scope. I am not convinced this is adequate for the future, and think that we need to start to consider CPU/NPU cores, queue algorithms, and maybe other resources. > > I am also concerned that the number of diffserv code points available in MPLS is going to be insufficient. > > Of course what we know today from experience is based on the applications that can run on the network infrastructure that we have today. That is a self limiting situation. We are designing DETNET because this model is inadequate for some classes of application that would like to run over a more general network. What we are doing with > VPN+ is to integrate DETNET into a VPN structure alongside classic VPNs. > > - Stewart > > >> Yours, >> Joel >> >> On 8/1/18 11:22 AM, Dongjie (Jimmy) wrote: >>> This statement is based on the comparison between overlay VPNs and >>> network slices. The resource here refers to various data plane >>> resources that can be allocated to a particular slice (queues, >>> buffer, etc.). Some level of resource isolation is necessary to >>> ensure that service in one slice never interferes with service in >>> another slice. >>> >>> May I know what are the requirements you've got? >>> >>> Best regards, >>> Jie >>> >>>> -----邮件原件----- >>>> 发件人: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>> 发送时间: 2018年7月30日 23:05 >>>> 收件人: Dongjie (Jimmy) >>>> 抄送: TEAS WG (teas@ietf.org) ; rtgwg@ietf.org >>>> 主题: Re: VPN security vs SD-WAN security >>>> >>>> Actually, assuming I understand the statement properly, "deep >>>> integration with the underlay resource would be necessary" does not >>>> appear to be an accurate statement derivable from the requirements >>>> that I have seen. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 7/30/18 8:23 AM, Dongjie (Jimmy) wrote: >>>>> (Adding TEAS as it is where the VPN+ framework draft is discussed) >>>>> >>>>> Hi Robert and Greg, >>>>> >>>>> As discussed during the VPN+ presentation in TEAS at IETF 102, the >>>>> scope is not the internet, as we know it would quite difficult or >>>>> even impossible to achieve the required guarantee at the scope of internet. >>>>> >>>>> And clearly the VPN overlays cannot provide the required guarantee, >>>>> deep integration with the underlay resource would be necessary. >>>>> >>>>> Another aspect we may take into consideration is the factor of >>>>> overprovisioning. The current network only has one overprovisioning >>>>> factor, which may not meet the requirement of different >>>>> services/customers. With network slicing, it is possible to have >>>>> different overprovisioning policy and factor in different slices. >>>>> >>>>> Best regards, >>>>> >>>>> Jie >>>>> >>>>> *From:*rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of >>>>> *Robert Raszuk >>>>> *Sent:* Sunday, July 29, 2018 6:11 AM >>>>> *To:* Greg Mirsky >>>>> *Cc:* Dongjie (Jimmy) ; rtgwg@ietf.org >>>>> *Subject:* Re: VPN security vs SD-WAN security >>>>> >>>>> Hey Greg, >>>>> >>>>> would not require global transit and likely be contained within >>>>> access or, at most, metro domains. >>>>> >>>>> That's news to me, but perhaps on the positive side :) I always >>>>> think WAN .. really wide one ! >>>>> >>>>> The separation on "soft" vs "hard" guarantees is eventually all >>>>> about amount of network robustness and level of over provisioning. >>>>> I sincerely hope it will not be yet another EVPN overlay over IP >>>>> network just painted with different marketing colors. >>>>> >>>>> Besides if any customer is serious and actually counts on those >>>>> guarantees he better purchase two of such services coming from >>>>> independent operators. That means that to be attractive financially >>>>> cost of such premium service must not be higher then half of the >>>>> p2p local fiber or cost of local access to closest IX ports + port >>>>> subscription in a given MAN where non blocking IX fabric spans >>>>> given >>>> geography. >>>>> It seems to me that at the end of the day the space for those >>>>> operators wishing to offer hard network slicing is actually pretty >>>>> narrow, but time will tell ... >>>>> >>>>> Rgs, >>>>> >>>>> r. >>>>> >>>>> On Sat, Jul 28, 2018 at 9:34 PM, Greg Mirsky >>>> > wrote: >>>>> >>>>>      Hi Robert, >>>>> >>>>>      very much agree with all you're saying and find us in violent >>>>>      agreement on "C". Proactive performance monitoring, in my view >>>>> as >>>>>      well, is the reasonable path to provide "soft" SLA and, to a >>>>> degree, >>>>>      prevent oversubscription of the network. And that, as you've >>>>> said, >>>>>      is one way to "assured/guaranteed global IP transit". >>>>> >>>>>      But I think that there will be demand for "hard" guarantees >>>>> for >>>>>      URLLC applications. But these, in my view, >>>>> >>>>>      would not require global transit and likely be contained >>>>> within >>>>>      access or, at most, metro domains. Because of the limited size >>>>> of >>>>>      the domain, IntServ may work, though that may be not the most >>>>>      efficient technique. We shall find out. >>>>> >>>>>      Hence my view on slicing: >>>>> >>>>>        * different applications will have different requirements >>>>> and use >>>>>          different degrees of isolation and guarantees; >>>>>        * "soft" slices may not need much of additional >>>>> standardization >>>>>          and use available VPN technologies in combination with PM >>>>> OAM >>>>>          for SLA monitoring and assurance; >>>>>        * "hard" slices would span within a single access and/or >>>>> metro >>>>>          domain. Networking solutions likely will be coupled with >>>>>          architecture and interfaces developed in Multi-access Edge >>>>>          Computing (MEC). >>>>> >>>>>      Regards, >>>>> >>>>>      Greg >>>>> >>>>>      On Sat, Jul 28, 2018 at 6:02 AM, Robert Raszuk >>>>> >>>>      > wrote: >>>>> >>>>>          Hi Jie, >>>>> >>>>>          > (network slicing) is to provide the demanding services >>>>> with guaranteed performance in a converged network, >>>>> >>>>>          Foundation of converged IP network is based on statistical >>>>>          multiplexing of traffic demands. As such it is in its >>>>> principle >>>>>          quite contradictory to "guaranteed" characteristics >>>>>          (performance, delays, jitter, drops -- you name it). >>>>> >>>>>          Application layers usually deal very well with all of the >>>>> above >>>>>          I would state - normal characteristics of IP networks.. >>>>> >>>>>          No doubt there will be those trying to offer some network >>>>>          slicing with guarantees and even those who will buy it. >>>>> Just >>>>>          like today there are those who offer you L2 circuit >>>>> between >>>>>          endpoints except such L2 circuit is an emulated one with >>>>> zero >>>>>          OEM visibility to the IP infrastructure underneath. >>>>> >>>>>          Now the network slicing is clearly aiming for even more >>>>>          complexity under the hood. And that is not the only >>>>> problem. The >>>>>          issue is cost. When SP is building the IP network the goal >>>>> is to >>>>>          mux as many services on it as it simply results in given's >>>>> SP >>>>>          revenue. Network slicing is promising as potentially just >>>>> by >>>>>          configuration of few knobs they will be claiming >>>>> guarantees as >>>>>          RFC says - except RFC will not likely tell you to stop >>>>>          over-provisioning. >>>>> >>>>>          Unless the idea is to use strict policing with dedicated >>>>> queuing >>>>>          on active and back paths or do something like RSVP IntServ >>>>> also >>>>>          on active and backup paths per customer - I really don't >>>>> think >>>>>          you can really guarantee much. And if you do that the cost >>>>> would >>>>>          likely grow really steep. >>>>> >>>>>          So what is IMO the solution for assured/guaranteed global >>>>> IP >>>>>          transit: >>>>> >>>>>          *A*  get diversely routed  dark fiber paths between your >>>>> POPs >>>>>          (can be unprotected) which btw today do not cost that much >>>>> anymore >>>>> >>>>>          *B* get diversely routed  optical channels alsol between >>>>> your >>>>>          POPs (can be unprotected) >>>>> >>>>>          *C*  use N disjoined by design (single AS Internet >>>>> providers >>>>>          between your end-points) + proper SD-WAN with active SLA >>>>> monitoring >>>>> >>>>>          Clearly I am big supporter of *C* model for reasons >>>>> discussed on >>>>>          this and few other recent threads. >>>>> >>>>>          I assume network slicing will try to get into be something >>>>>          between A/B & C but it is bounded up front with the cost >>>>> of the >>>>>          two. >>>>> >>>>>          Many thx, >>>>> >>>>>          Robert. >>>>> >>>>>          On Sat, Jul 28, 2018 at 9:51 AM, Dongjie (Jimmy) >>>>>          > wrote: >>>>> >>>>>              Hi Robert, >>>>> >>>>>              IMO the two approaches are targeting at different use >>>>> cases >>>>>              and customers. >>>>> >>>>>              The former (network slicing) is to provide the >>>>> demanding >>>>>              services with guaranteed performance in a converged >>>> network, >>>>>              while the latter (switching between multiple >>>>> paralleled >>>>>              networks) provides the customer with the best >>>>> performance >>>>>              that is available among those candidates. To me the >>>>> latter >>>>>              is still some kind of best effort, and as Toerless >>>>> said, it >>>>>              depends on the diversity you can have in the multiple >>>> networks. >>>>>              And I agree with Stewart on “you always pay a price >>>>> for >>>>>              better than best effort.” >>>>> >>>>>              Best regards, >>>>> >>>>>              Jie >>>>> >>>>>              *From:*rtgwg [mailto:rtgwg-bounces@ietf.org >>>>>              ] *On Behalf Of *Robert >>>> Raszuk >>>>>              *Sent:* Wednesday, July 25, 2018 8:24 PM >>>>>              *To:* Acee Lindem (acee) >>>>              > >>>>>              *Cc:* rtgwg@ietf.org >>>>> >>>>> >>>>>              *Subject:* Re: VPN security vs SD-WAN security >>>>> >>>>>              True network slicing for IP networks means either >>>>> waist of >>>>>              resources or very strict multi-level queuing at each >>>>> hop and >>>>>              100% ingress traffic policing. Yet while this has a >>>>> chance >>>>>              to work during normal operation at the time of even >>>>> regular >>>>>              failures this all pretty much melts like cheese on a >>>>> good >>>>>              sandwich. >>>>> >>>>>              It is going to be very interesting to compare how >>>>> single >>>>>              complex sliced network compares for any end to end >>>>> robust >>>>>              transport from N normal simple IP backbones and end to >>>> end >>>>>              SLA based millisecond switch over between one and >>>>> another >>>> on >>>>>              a per flow basis. Also let's note then while the >>>>> former is >>>>>              still to the best of my knowledge a draft the latter >>>>> is >>>>>              already deployed globally in 100s of networks. >>>>> >>>>>              Best, >>>>>              R. >>>>> >>>>>              On Wed, Jul 25, 2018 at 1:21 PM, Acee Lindem (acee) >>>>>              > wrote: >>>>> >>>>>                  *From: *rtgwg >>>>                  > on behalf of >>>>> Stewart >>>>>                  Bryant >>>>                  > >>>>>                  *Date: *Wednesday, July 25, 2018 at 5:55 AM >>>>>                  *To: *Robert Raszuk >>>>                  > >>>>>                  *Cc: *Routing WG >>> > >>>>>                  *Subject: *Re: VPN security vs SD-WAN security >>>>> >>>>>                  On 25/07/2018 10:40, Robert Raszuk wrote: >>>>> >>>>>                      /* Adjusting the subject ... */ >>>>> >>>>>                      Hello >>>>> >>>>>                      Stewart, >>>>> >>>>>                      You have made the below comment in the other >>>> thread >>>>>                      we are having: >>>>> >>>>>                          Indeed, I would have expected this to be >>>>> on a >>>>>                          secure network of some sort either purely >>>>>                          private or some form of VPN. However, I am >>>> sure >>>>>                          I read in your text that you were >>>>>                          considering using the Public Internet much >>>>> in >>>>>                          the way of SD-WAN. >>>>> >>>>>                      Would you mind as extensively as you can >>>>> expand >>>> on >>>>>                      the above statement ? >>>>> >>>>>                      Specifically on what basis do you treat say >>>>> L2VPN >>>> or >>>>>                      L3VPN of naked unencrypted packets often >>>> traveling >>>>>                      on the very same links as this "bad" Internet >>>>>                      traffic to be even slightly more secure then >>>>> IPSEC >>>>>                      or DTLS encrypted SD-WAN carried data with >>>> endpoints >>>>>                      being terminated in private systems ? >>>>> >>>>>                      Thx, >>>>> >>>>>                      Robert >>>>> >>>>> >>>>>                  Robert, I think that you have to take it as read >>>>> that an >>>>>                  air traffic control SoF system is encrypting its >>>>>                  packets. If it is not, then it is clearly not fit >>>>> for >>>>>                  purpose. >>>>> >>>>>                  What concerns me is that an air traffic system is >>>>> one of >>>>>                  the most, if not the most, high profile targets in >>>>> civil >>>>>                  society. You get reminded of this each time you >>>>> travel >>>>>                  to IETF. >>>>> >>>>>                  The thing about safety of flight traffic is that a >>>>>                  sustained and effective DDoS attack has global >>>>> impact in >>>>>                  a way that few other such attacks have. >>>>> >>>>>                  A VPN system ought to sustain resistance to such >>>>> an >>>>>                  attack better than the proposed system which >>>>> treats >>>> the >>>>>                  SoF traffic the same as regular traffic. >>>>> >>>>>                  I guess you are making a case for your network >>>>> slicing >>>>>                  work 😉 >>>>> >>>>>                  Acee >>>>> >>>>> >>>>> >>>>>                  - Stewart >>>>> >>>>>          _______________________________________________ >>>>>          rtgwg mailing list >>>>>          rtgwg@ietf.org >>>>>          https://www.ietf.org/mailman/listinfo/rtgwg >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> rtgwg mailing list >>>>> rtgwg@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtgwg >>>>> >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From nobody Mon Aug 6 11:29:51 2018 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF0E130EDF; Mon, 6 Aug 2018 11:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8g4AAp9W4b7; Mon, 6 Aug 2018 11:29:45 -0700 (PDT) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEB81130EE1; Mon, 6 Aug 2018 11:29:44 -0700 (PDT) Received: by mail-wm0-x243.google.com with SMTP id y9-v6so15405352wma.5; Mon, 06 Aug 2018 11:29:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=VcsyK1asrzQKxQWe8W/P2pAX1X6JH94uL+IS0C/+d6Q=; b=lmmtwhyvMZyr8HmR2MXqQCiihrcYGv8Uj5VYuClqC5xxepH8hxi/yelPX0hJe4Scne Ybm1PGDtKaPYmCLnSS5et7jK0l8LC2EkT1Sp5JKaKifoAlMbdPg9FwIGR+xdKHDA2OEp 9BenF2rfdt2pFspm0yz9nFCCKpp78XkkSjtC296zawLh+zNOy0T0NEusR5JjgPxd3RZq /lCO2QeuJfLXiqSI4Hz7lx9Wqh5Xn0O5uC5ifFAJooCBek1N59BQ9Cbkn6DC98WlnL3s IerYCqiLrCJq1cEMEtQ/HACN0bizbOL0JjMI78WlqR5qhUEb5z74ZmwPmmGlEDhUuag2 4HFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=VcsyK1asrzQKxQWe8W/P2pAX1X6JH94uL+IS0C/+d6Q=; b=MFX0gyKqUcF3gKTA0vDNn4tJX495ZuJaF3F472oLsNEoJ06kguL1G5KBR9o7XezT1p qP94p92Ydd9crmiO/qEM14vjDAnjPlCu/MXl4iBEfO2LbTWbAzO18EOe/0jQxK4LcUb8 SDSa1+mB0oq2cZApm0JdUzMlBfs4u3bTKZvjboyeyF7w6tlotKn/WvWhHC4/xxeCLulI HHGrAYVP+uCbzKT/N1f92Uv6OcvFJnvlP8nxtC2hdnNgVgeoChZolyB5He08fXWbrfI7 Q3ocIiBKmQEuDA9IFfhcwTRVPxMaMwUn2FsacEYsLrKJCMGd7QebE5tntaz3jhjPrnlh JE8g== X-Gm-Message-State: AOUpUlEV+VoERZJ7lVOzxOykNUK2ElDaCspiA4tOKtoU5DwagQNT3oQY 0ccwQGkStGwN7Tykkn41I5sQvB7f X-Google-Smtp-Source: AAOMgpd5fCKM6YvjXg3wPGbdGDnohKORF1/jXc8EZL2k6oTAdhj+oJKIYgHZO0lkQ2M5S/otZlPyhw== X-Received: by 2002:a1c:c685:: with SMTP id w127-v6mr13121348wmf.133.1533580183021; Mon, 06 Aug 2018 11:29:43 -0700 (PDT) Received: from [192.168.2.105] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id m2-v6sm10946625wrw.76.2018.08.06.11.29.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Aug 2018 11:29:42 -0700 (PDT) To: Robert Raszuk , "Ruediger.Geib@telekom.de Geib" Cc: teas@ietf.org, RTGWG References: <0cb8f15b-7538-500c-dda3-915bf9814f94@gmail.com> <5D10C0C4-B93D-463F-A071-EEA6F35506CD@cisco.com> <76CD132C3ADEF848BD84D028D243C927A71506F6@NKGEML515-MBS.china.huawei.com> <76CD132C3ADEF848BD84D028D243C927A72042AB@NKGEML515-MBS.china.huawei.com> <89653c55-90e0-c52d-bdef-38b312b7feda@joelhalpern.com> <76CD132C3ADEF848BD84D028D243C927A72B1EF7@NKGEML515-MBS.china.huawei.com> <5c72cc37-c1e0-e806-701d-40a4cf756eee@joelhalpern.com> <644649c7-a5b5-9e78-8749-4a2109566cf9@gmail.com> From: Stewart Bryant Message-ID: <07ac400b-099f-6727-a14d-71d7f91fce5e@gmail.com> Date: Mon, 6 Aug 2018 19:29:34 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0F26A573268B0BA2E58C6F77" Content-Language: en-GB Archived-At: Subject: Re: [Teas] =?utf-8?b?562U5aSNOiBWUE4gc2VjdXJpdHkgdnMgU0QtV0FOIHNl?= =?utf-8?q?curity?= X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 18:29:50 -0000 This is a multi-part message in MIME format. --------------0F26A573268B0BA2E58C6F77 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 02/08/2018 14:19, Robert Raszuk wrote: > Very well said indeed ! > > One comment to your last sentence I think the slicing plan is to again > lock given customer to single provider - just like it is locked today > with L3/L2VPNs. > > The most interesting trend is however not even network related ... if > we move up and observe that more real providers are offering services > and those services actually work well all it will be required from any > customer is last mile access to closest IX where provider of selected > service (not to say on purpose "SP") has its presence. If this model > succeeds and all financial reports indicate that it is doing pretty > good - all our network slicing and dicing discussions will be moved to > Muppet's balcony status. > Remember that a wireless last mile is not the same as a fixed line last mile, and there is a lot of infrastructure in a wireless network that is not present in a fixed network. For example in some cases they need to carry DSP samples to a data center just to demodulate the radio signals, and then there is a whole lot of access control and monitoring that is in itself quite complicated, but needed by the current commercial and operational model. If you really suggest that we can have all of the required computing at every mobile mast which is the edge of the mobile "last mile", then that is a lot of closet space, capital, power and maintenance. At the end of the day the accountants will add up the CAPEX and OPEX numbers and that will determine what is deployed. At this stage both approaches are giving them options to put in their spreadsheets. - Stewart > Cheers, > r. > > > On Thu, Aug 2, 2018 at 2:06 PM, > wrote: > > Stewart, > > I'd appreciate a discussion based on operational experience. In > which Diffserv supported network did which application fail due to > a lack of suitable scheduling or due to a lack of codepoints, > which would have been working properly on the same network with > Detnet and more codepoints? I'd be happy, if you were able to > provide a link to a presentation. > > I've started my QoS career with ATM, a technology offering > dedicated QoS network resources. Spare capacities with a > network-fully-booked indication were the first lesson I learned, > and this combination turned out to be bad whenever I encountered > it from then on. My take on Diffserv is, that it is useful to > protect certain traffic in the case of not foreseen networking > conditions. That means, in 99,....% of the time, todays Diffserv > isn't required, because there's no congestion. > > You seem to head for generic solutions, applicable in all parts of > the Internet. I don't understand what the benefit of dedicated > resources would be, given they are required end-to-end. I excuse > if I missed a statement that the approach you propose is limited > to specific instances or sections of the Internet. > > Regards, > > Ruediger > > > -----Ursprüngliche Nachricht----- > Von: rtgwg [mailto:rtgwg-bounces@ietf.org > ] Im Auftrag von Stewart Bryant > Gesendet: Donnerstag, 2. August 2018 13:19 > An: Joel M. Halpern >; Dongjie (Jimmy) > > > Cc: TEAS WG (teas@ietf.org ) >; rtgwg@ietf.org > Betreff: Re: [Teas] 答复: VPN security vs SD-WAN security > > > > On 01/08/2018 16:26, Joel M. Halpern wrote: > > I am not disagreeing with a view that network resource allocation > > requires some visibility to those resources. > > It is the assertion of a "deep integration" that seems to lack > grounding. > > > > We know that one can use our existing VPN technologies and tools > like > > diffserv, with suitable admission control and path computation, to > > provide strong service guarantees to meet SLAs. As others have > noted > > in other presentations, when it comes to the data plane this > seems to > > meet the articulated needs from various fora. > > > Hi Joel, > > We can certainly get a long way with those tools for "conventional" > applications. > > However, as we support the sort of applications that look for a > deterministic networking class of SLA, then I am concerned that we > need to map the traffic to dedicated resources in more detail than > we currently do through the diffserv mechanism. > > What we do at the moment with diffserv is a mapping of packets to > resources, but in practise we limit those resources to ingress and > egress queues with the queue management algorithm out of scope. I > am not convinced this is adequate for the future, and think that > we need to start to consider CPU/NPU cores, queue algorithms, and > maybe other resources. > > I am also concerned that the number of diffserv code points > available in MPLS is going to be insufficient. > > Of course what we know today from experience is based on the > applications that can run on the network infrastructure that we > have today. That is a self limiting situation. We are designing > DETNET because this model is inadequate for some classes of > application that would like to run over a more general network. > What we are doing with > VPN+ is to integrate DETNET into a VPN structure alongside classic > VPNs. > > - Stewart > > > > Yours, > > Joel > > > > On 8/1/18 11:22 AM, Dongjie (Jimmy) wrote: > >> This statement is based on the comparison between overlay VPNs and > >> network slices. The resource here refers to various data plane > >> resources that can be allocated to a particular slice (queues, > >> buffer, etc.). Some level of resource isolation is necessary to > >> ensure that service in one slice never interferes with service in > >> another slice. > >> > >> May I know what are the requirements you've got? > >> > >> Best regards, > >> Jie > >> > >>> -----邮件原件----- > >>> 发件人: Joel M. Halpern [mailto:jmh@joelhalpern.com > ] > >>> 发送时间: 2018年7月30日 23:05 > >>> 收件人: Dongjie (Jimmy) > > >>> 抄送: TEAS WG (teas@ietf.org ) > >; rtgwg@ietf.org > > >>> 主题: Re: VPN security vs SD-WAN security > >>> > >>> Actually, assuming I understand the statement properly, "deep > >>> integration with the underlay resource would be necessary" > does not > >>> appear to be an accurate statement derivable from the > requirements > >>> that I have seen. > >>> > >>> Yours, > >>> Joel > >>> > >>> On 7/30/18 8:23 AM, Dongjie (Jimmy) wrote: > >>>> (Adding TEAS as it is where the VPN+ framework draft is > discussed) > >>>> > >>>> Hi Robert and Greg, > >>>> > >>>> As discussed during the VPN+ presentation in TEAS at IETF > 102, the > >>>> scope is not the internet, as we know it would quite > difficult or > >>>> even impossible to achieve the required guarantee at the > scope of internet. > >>>> > >>>> And clearly the VPN overlays cannot provide the required > guarantee, > >>>> deep integration with the underlay resource would be necessary. > >>>> > >>>> Another aspect we may take into consideration is the factor of > >>>> overprovisioning. The current network only has one > overprovisioning > >>>> factor, which may not meet the requirement of different > >>>> services/customers. With network slicing, it is possible to have > >>>> different overprovisioning policy and factor in different slices. > >>>> > >>>> Best regards, > >>>> > >>>> Jie > >>>> > >>>> *From:*rraszuk@gmail.com > [mailto:rraszuk@gmail.com ] *On Behalf Of > >>>> *Robert Raszuk > >>>> *Sent:* Sunday, July 29, 2018 6:11 AM > >>>> *To:* Greg Mirsky > > >>>> *Cc:* Dongjie (Jimmy) >; rtgwg@ietf.org > >>>> *Subject:* Re: VPN security vs SD-WAN security > >>>> > >>>> Hey Greg, > >>>> > >>>>> > >>>> > >>>> would not require global transit and likely be contained within > >>>> access or, at most, metro domains. > >>>> > >>>> That's news to me, but perhaps on the positive side :) I always > >>>> think WAN .. really wide one ! > >>>> > >>>> The separation on "soft" vs "hard" guarantees is eventually all > >>>> about amount of network robustness and level of over > provisioning. > >>>> I sincerely hope it will not be yet another EVPN overlay over IP > >>>> network just painted with different marketing colors. > >>>> > >>>> Besides if any customer is serious and actually counts on those > >>>> guarantees he better purchase two of such services coming from > >>>> independent operators. That means that to be attractive > financially > >>>> cost of such premium service must not be higher then half of the > >>>> p2p local fiber or cost of local access to closest IX ports + > port > >>>> subscription in a given MAN where non blocking IX fabric spans > >>>> given > >>> geography. > >>>> > >>>> It seems to me that at the end of the day the space for those > >>>> operators wishing to offer hard network slicing is actually > pretty > >>>> narrow, but time will tell ... > >>>> > >>>> Rgs, > >>>> > >>>> r. > >>>> > >>>> On Sat, Jul 28, 2018 at 9:34 PM, Greg Mirsky > > >>>> >> wrote: > >>>> > >>>>      Hi Robert, > >>>> > >>>>      very much agree with all you're saying and find us in > violent > >>>>      agreement on "C". Proactive performance monitoring, in > my view > >>>> as > >>>>      well, is the reasonable path to provide "soft" SLA and, > to a > >>>> degree, > >>>>      prevent oversubscription of the network. And that, as > you've > >>>> said, > >>>>      is one way to "assured/guaranteed global IP transit". > >>>> > >>>>      But I think that there will be demand for "hard" guarantees > >>>> for > >>>>      URLLC applications. But these, in my view, > >>>> > >>>>      would not require global transit and likely be contained > >>>> within > >>>>      access or, at most, metro domains. Because of the > limited size > >>>> of > >>>>      the domain, IntServ may work, though that may be not the > most > >>>>      efficient technique. We shall find out. > >>>> > >>>>      Hence my view on slicing: > >>>> > >>>>        * different applications will have different requirements > >>>> and use > >>>>          different degrees of isolation and guarantees; > >>>>        * "soft" slices may not need much of additional > >>>> standardization > >>>>          and use available VPN technologies in combination > with PM > >>>> OAM > >>>>          for SLA monitoring and assurance; > >>>>        * "hard" slices would span within a single access and/or > >>>> metro > >>>>          domain. Networking solutions likely will be coupled with > >>>>          architecture and interfaces developed in > Multi-access Edge > >>>>          Computing (MEC). > >>>> > >>>>      Regards, > >>>> > >>>>      Greg > >>>> > >>>>      On Sat, Jul 28, 2018 at 6:02 AM, Robert Raszuk > >>>> > >>>>      >> > wrote: > >>>> > >>>>          Hi Jie, > >>>> > >>>>          > (network slicing) is to provide the demanding > services > >>>> with guaranteed performance in a converged network, > >>>> > >>>>          Foundation of converged IP network is based on > statistical > >>>>          multiplexing of traffic demands. As such it is in its > >>>> principle > >>>>          quite contradictory to "guaranteed" characteristics > >>>>          (performance, delays, jitter, drops -- you name it). > >>>> > >>>>          Application layers usually deal very well with all > of the > >>>> above > >>>>          I would state - normal characteristics of IP networks.. > >>>> > >>>>          No doubt there will be those trying to offer some > network > >>>>          slicing with guarantees and even those who will buy it. > >>>> Just > >>>>          like today there are those who offer you L2 circuit > >>>> between > >>>>          endpoints except such L2 circuit is an emulated one > with > >>>> zero > >>>>          OEM visibility to the IP infrastructure underneath. > >>>> > >>>>          Now the network slicing is clearly aiming for even more > >>>>          complexity under the hood. And that is not the only > >>>> problem. The > >>>>          issue is cost. When SP is building the IP network > the goal > >>>> is to > >>>>          mux as many services on it as it simply results in > given's > >>>> SP > >>>>          revenue. Network slicing is promising as potentially > just > >>>> by > >>>>          configuration of few knobs they will be claiming > >>>> guarantees as > >>>>          RFC says - except RFC will not likely tell you to stop > >>>>          over-provisioning. > >>>> > >>>>          Unless the idea is to use strict policing with > dedicated > >>>> queuing > >>>>          on active and back paths or do something like RSVP > IntServ > >>>> also > >>>>          on active and backup paths per customer - I really > don't > >>>> think > >>>>          you can really guarantee much. And if you do that > the cost > >>>> would > >>>>          likely grow really steep. > >>>> > >>>>          So what is IMO the solution for assured/guaranteed > global > >>>> IP > >>>>          transit: > >>>> > >>>>          *A*  get diversely routed dark fiber paths between your > >>>> POPs > >>>>          (can be unprotected) which btw today do not cost > that much > >>>> anymore > >>>> > >>>>          *B* get diversely routed optical channels alsol between > >>>> your > >>>>          POPs (can be unprotected) > >>>> > >>>>          *C*  use N disjoined by design (single AS Internet > >>>> providers > >>>>          between your end-points) + proper SD-WAN with active > SLA > >>>> monitoring > >>>> > >>>>          Clearly I am big supporter of *C* model for reasons > >>>> discussed on > >>>>          this and few other recent threads. > >>>> > >>>>          I assume network slicing will try to get into be > something > >>>>          between A/B & C but it is bounded up front with the > cost > >>>> of the > >>>>          two. > >>>> > >>>>          Many thx, > >>>> > >>>>          Robert. > >>>> > >>>>          On Sat, Jul 28, 2018 at 9:51 AM, Dongjie (Jimmy) > >>>>          > >> wrote: > >>>> > >>>>              Hi Robert, > >>>> > >>>>              IMO the two approaches are targeting at > different use > >>>> cases > >>>>              and customers. > >>>> > >>>>              The former (network slicing) is to provide the > >>>> demanding > >>>>              services with guaranteed performance in a converged > >>> network, > >>>>              while the latter (switching between multiple > >>>> paralleled > >>>>              networks) provides the customer with the best > >>>> performance > >>>>              that is available among those candidates. To me the > >>>> latter > >>>>              is still some kind of best effort, and as Toerless > >>>> said, it > >>>>              depends on the diversity you can have in the > multiple > >>> networks. > >>>> > >>>>              And I agree with Stewart on “you always pay a price > >>>> for > >>>>              better than best effort.” > >>>> > >>>>              Best regards, > >>>> > >>>>              Jie > >>>> > >>>>              *From:*rtgwg [mailto:rtgwg-bounces@ietf.org > > >>>>              >] *On Behalf Of *Robert > >>> Raszuk > >>>>              *Sent:* Wednesday, July 25, 2018 8:24 PM > >>>>              *To:* Acee Lindem (acee) > >>>>              >> > >>>>              *Cc:* rtgwg@ietf.org > > > >>>> > >>>> > >>>>              *Subject:* Re: VPN security vs SD-WAN security > >>>> > >>>>              True network slicing for IP networks means either > >>>> waist of > >>>>              resources or very strict multi-level queuing at > each > >>>> hop and > >>>>              100% ingress traffic policing. Yet while this has a > >>>> chance > >>>>              to work during normal operation at the time of even > >>>> regular > >>>>              failures this all pretty much melts like cheese > on a > >>>> good > >>>>              sandwich. > >>>> > >>>>              It is going to be very interesting to compare how > >>>> single > >>>>              complex sliced network compares for any end to end > >>>> robust > >>>>              transport from N normal simple IP backbones and > end to > >>> end > >>>>              SLA based millisecond switch over between one and > >>>> another > >>> on > >>>>              a per flow basis. Also let's note then while the > >>>> former is > >>>>              still to the best of my knowledge a draft the > latter > >>>> is > >>>>              already deployed globally in 100s of networks. > >>>> > >>>>              Best, > >>>>              R. > >>>> > >>>>              On Wed, Jul 25, 2018 at 1:21 PM, Acee Lindem (acee) > >>>>              > >> wrote: > >>>> > >>>>                  *From: *rtgwg > >>>>                  >> on behalf of > >>>> Stewart > >>>>                  Bryant > >>>>                  >> > >>>>                  *Date: *Wednesday, July 25, 2018 at 5:55 AM > >>>>                  *To: *Robert Raszuk > >>>>                  >> > >>>>                  *Cc: *Routing WG > >>> >> > >>>>                  *Subject: *Re: VPN security vs SD-WAN security > >>>> > >>>>                  On 25/07/2018 10:40, Robert Raszuk wrote: > >>>> > >>>>                      /* Adjusting the subject ... */ > >>>> > >>>>                      Hello > >>>> > >>>>                      Stewart, > >>>> > >>>>                      You have made the below comment in the other > >>> thread > >>>>                      we are having: > >>>> > >>>>                          Indeed, I would have expected this > to be > >>>> on a > >>>>                          secure network of some sort either > purely > >>>>                          private or some form of VPN. > However, I am > >>> sure > >>>>                          I read in your text that you were > >>>>                          considering using the Public > Internet much > >>>> in > >>>>                          the way of SD-WAN. > >>>> > >>>>                      Would you mind as extensively as you can > >>>> expand > >>> on > >>>>                      the above statement ? > >>>> > >>>>                      Specifically on what basis do you treat say > >>>> L2VPN > >>> or > >>>>                      L3VPN of naked unencrypted packets often > >>> traveling > >>>>                      on the very same links as this "bad" > Internet > >>>>                      traffic to be even slightly more secure > then > >>>> IPSEC > >>>>                      or DTLS encrypted SD-WAN carried data with > >>> endpoints > >>>>                      being terminated in private systems ? > >>>> > >>>>                      Thx, > >>>> > >>>>                      Robert > >>>> > >>>> > >>>>                  Robert, I think that you have to take it as > read > >>>> that an > >>>>                  air traffic control SoF system is encrypting its > >>>>                  packets. If it is not, then it is clearly > not fit > >>>> for > >>>>                  purpose. > >>>> > >>>>                  What concerns me is that an air traffic > system is > >>>> one of > >>>>                  the most, if not the most, high profile > targets in > >>>> civil > >>>>                  society. You get reminded of this each time you > >>>> travel > >>>>                  to IETF. > >>>> > >>>>                  The thing about safety of flight traffic is > that a > >>>>                  sustained and effective DDoS attack has global > >>>> impact in > >>>>                  a way that few other such attacks have. > >>>> > >>>>                  A VPN system ought to sustain resistance to > such > >>>> an > >>>>                  attack better than the proposed system which > >>>> treats > >>> the > >>>>                  SoF traffic the same as regular traffic. > >>>> > >>>>                  I guess you are making a case for your network > >>>> slicing > >>>>                  work 😉 > >>>> > >>>>                  Acee > >>>> > >>>> > >>>> > >>>>                  - Stewart > >>>> > >>>>          _______________________________________________ > >>>>          rtgwg mailing list > >>>> rtgwg@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/rtgwg > > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> rtgwg mailing list > >>>> rtgwg@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/rtgwg > > >>>> > > > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org > > https://www.ietf.org/mailman/listinfo/teas > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > > > --------------0F26A573268B0BA2E58C6F77 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 02/08/2018 14:19, Robert Raszuk wrote:
Very well said indeed ! 

One comment to your last sentence I think the slicing plan is to again lock given customer to single provider - just like it is locked today with L3/L2VPNs. 

The most interesting trend is however not even network related ... if we move up and observe that more real providers are offering services and those services actually work well all it will be required from any customer is last mile access to closest IX where provider of selected service (not to say on purpose "SP") has its presence. If this model succeeds and all financial reports indicate that it is doing pretty good - all our network slicing and dicing discussions will be moved to Muppet's balcony status.

Remember that a wireless last mile is not the same as a fixed line last mile, and there is a lot of infrastructure in a wireless network that is not present in a fixed network. For example in some cases they need to carry DSP samples to a data center just to demodulate the radio signals, and then there is a whole lot of access control and monitoring that is in itself quite complicated, but needed by the current commercial and operational model.

If you really suggest that we can have all of the required computing at every mobile mast which is the edge of the mobile "last mile", then that is a lot of closet space, capital, power and maintenance.

At the end of the day the accountants will add up the CAPEX and OPEX numbers and that will determine what is deployed. At this stage both approaches are giving them options to put in their spreadsheets.

- Stewart


Cheers,
r.


On Thu, Aug 2, 2018 at 2:06 PM, <Ruediger.Geib@telekom.de> wrote:
Stewart,

I'd appreciate a discussion based on operational experience. In which Diffserv supported network did which application fail due to a lack of suitable scheduling or due to a lack of codepoints, which would have been working properly on the same network with Detnet and more codepoints? I'd be happy, if you were able to provide a link to a presentation.

I've started my QoS career with ATM, a technology offering dedicated QoS network resources. Spare capacities with a network-fully-booked indication were the first lesson I learned, and this combination turned out to be bad whenever I encountered it from then on. My take on Diffserv is, that it is useful to protect certain traffic in the case of not foreseen networking conditions. That means, in 99,....% of the time, todays Diffserv isn't required, because there's no congestion.

You seem to head for generic solutions, applicable in all parts of the Internet. I don't understand what the benefit of dedicated resources would be, given they are required end-to-end. I excuse if I missed a statement that the approach you propose is limited to specific instances or sections of the Internet.

Regards,

Ruediger


-----Ursprüngliche Nachricht-----
Von: rtgwg [mailto:rtgwg-bounces@ietf.org] Im Auftrag von Stewart Bryant
Gesendet: Donnerstag, 2. August 2018 13:19
An: Joel M. Halpern <jmh@joelhalpern.com>; Dongjie (Jimmy) <jie.dong@huawei.com>
Cc: TEAS WG (teas@ietf.org) <teas@ietf.org>; rtgwg@ietf.org
Betreff: Re: [Teas] 答复: VPN security vs SD-WAN security



On 01/08/2018 16:26, Joel M. Halpern wrote:
> I am not disagreeing with a view that network resource allocation
> requires some visibility to those resources.
> It is the assertion of a "deep integration" that seems to lack grounding.
>
> We know that one can use our existing VPN technologies and tools like
> diffserv, with suitable admission control and path computation, to
> provide strong service guarantees to meet SLAs. As others have noted
> in other presentations, when it comes to the data plane this seems to
> meet the articulated needs from various fora.
>
Hi Joel,

We can certainly get a long way with those tools for "conventional"
applications.

However, as we support the sort of applications that look for a deterministic networking class of SLA, then I am concerned that we need to map the traffic to dedicated resources in more detail than we currently do through the diffserv mechanism.

What we do at the moment with diffserv is a mapping of packets to resources, but in practise we limit those resources to ingress and egress queues with the queue management algorithm out of scope. I am not convinced this is adequate for the future, and think that we need to start to consider CPU/NPU cores, queue algorithms, and maybe other resources.

I am also concerned that the number of diffserv code points available in MPLS is going to be insufficient.

Of course what we know today from experience is based on the applications that can run on the network infrastructure that we have today. That is a self limiting situation. We are designing DETNET because this model is inadequate for some classes of application that would like to run over a more general network. What we are doing with
VPN+ is to integrate DETNET into a VPN structure alongside classic VPNs.

- Stewart


> Yours,
> Joel
>
> On 8/1/18 11:22 AM, Dongjie (Jimmy) wrote:
>> This statement is based on the comparison between overlay VPNs and
>> network slices. The resource here refers to various data plane
>> resources that can be allocated to a particular slice (queues,
>> buffer, etc.). Some level of resource isolation is necessary to
>> ensure that service in one slice never interferes with service in
>> another slice.
>>
>> May I know what are the requirements you've got?
>>
>> Best regards,
>> Jie
>>
>>> -----邮件原件-----
>>> 发件人: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>>> 发送时间: 2018年7月30日 23:05
>>> 收件人: Dongjie (Jimmy) <jie.dong@huawei.com>
>>> 抄送: TEAS WG (teas@ietf.org) <teas@ietf.org>; rtgwg@ietf.org
>>> 主题: Re: VPN security vs SD-WAN security
>>>
>>> Actually, assuming I understand the statement properly, "deep
>>> integration with the underlay resource would be necessary" does not
>>> appear to be an accurate statement derivable from the requirements
>>> that I have seen.
>>>
>>> Yours,
>>> Joel
>>>
>>> On 7/30/18 8:23 AM, Dongjie (Jimmy) wrote:
>>>> (Adding TEAS as it is where the VPN+ framework draft is discussed)
>>>>
>>>> Hi Robert and Greg,
>>>>
>>>> As discussed during the VPN+ presentation in TEAS at IETF 102, the
>>>> scope is not the internet, as we know it would quite difficult or
>>>> even impossible to achieve the required guarantee at the scope of internet.
>>>>
>>>> And clearly the VPN overlays cannot provide the required guarantee,
>>>> deep integration with the underlay resource would be necessary.
>>>>
>>>> Another aspect we may take into consideration is the factor of
>>>> overprovisioning. The current network only has one overprovisioning
>>>> factor, which may not meet the requirement of different
>>>> services/customers. With network slicing, it is possible to have
>>>> different overprovisioning policy and factor in different slices.
>>>>
>>>> Best regards,
>>>>
>>>> Jie
>>>>
>>>> *From:*rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of
>>>> *Robert Raszuk
>>>> *Sent:* Sunday, July 29, 2018 6:11 AM
>>>> *To:* Greg Mirsky <gregimirsky@gmail.com>
>>>> *Cc:* Dongjie (Jimmy) <jie.dong@huawei.com>; rtgwg@ietf.org
>>>> *Subject:* Re: VPN security vs SD-WAN security
>>>>
>>>> Hey Greg,
>>>>
>>>>>
>>>>
>>>> would not require global transit and likely be contained within
>>>> access or, at most, metro domains.
>>>>
>>>> That's news to me, but perhaps on the positive side :) I always
>>>> think WAN .. really wide one !
>>>>
>>>> The separation on "soft" vs "hard" guarantees is eventually all
>>>> about amount of network robustness and level of over provisioning. 
>>>> I sincerely hope it will not be yet another EVPN overlay over IP
>>>> network just painted with different marketing colors.
>>>>
>>>> Besides if any customer is serious and actually counts on those
>>>> guarantees he better purchase two of such services coming from
>>>> independent operators. That means that to be attractive financially
>>>> cost of such premium service must not be higher then half of the
>>>> p2p local fiber or cost of local access to closest IX ports + port
>>>> subscription in a given MAN where non blocking IX fabric spans
>>>> given
>>> geography.
>>>>
>>>> It seems to me that at the end of the day the space for those
>>>> operators wishing to offer hard network slicing is actually pretty
>>>> narrow, but time will tell ...
>>>>
>>>> Rgs,
>>>>
>>>> r.
>>>>
>>>> On Sat, Jul 28, 2018 at 9:34 PM, Greg Mirsky <gregimirsky@gmail.com
>>>> <mailto:gregimirsky@gmail.com>> wrote:
>>>>
>>>>      Hi Robert,
>>>>
>>>>      very much agree with all you're saying and find us in violent
>>>>      agreement on "C". Proactive performance monitoring, in my view
>>>> as
>>>>      well, is the reasonable path to provide "soft" SLA and, to a
>>>> degree,
>>>>      prevent oversubscription of the network. And that, as you've
>>>> said,
>>>>      is one way to "assured/guaranteed global IP transit".
>>>>
>>>>      But I think that there will be demand for "hard" guarantees
>>>> for
>>>>      URLLC applications. But these, in my view,
>>>>
>>>>      would not require global transit and likely be contained
>>>> within
>>>>      access or, at most, metro domains. Because of the limited size
>>>> of
>>>>      the domain, IntServ may work, though that may be not the most
>>>>      efficient technique. We shall find out.
>>>>
>>>>      Hence my view on slicing:
>>>>
>>>>        * different applications will have different requirements
>>>> and use
>>>>          different degrees of isolation and guarantees;
>>>>        * "soft" slices may not need much of additional
>>>> standardization
>>>>          and use available VPN technologies in combination with PM
>>>> OAM
>>>>          for SLA monitoring and assurance;
>>>>        * "hard" slices would span within a single access and/or
>>>> metro
>>>>          domain. Networking solutions likely will be coupled with
>>>>          architecture and interfaces developed in Multi-access Edge
>>>>          Computing (MEC).
>>>>
>>>>      Regards,
>>>>
>>>>      Greg
>>>>
>>>>      On Sat, Jul 28, 2018 at 6:02 AM, Robert Raszuk
>>>> <robert@raszuk.net
>>>>      <mailto:robert@raszuk.net>> wrote:
>>>>
>>>>          Hi Jie,
>>>>
>>>>          > (network slicing) is to provide the demanding services
>>>> with guaranteed performance in a converged network,
>>>>
>>>>          Foundation of converged IP network is based on statistical
>>>>          multiplexing of traffic demands. As such it is in its
>>>> principle
>>>>          quite contradictory to "guaranteed" characteristics
>>>>          (performance, delays, jitter, drops -- you name it).
>>>>
>>>>          Application layers usually deal very well with all of the
>>>> above
>>>>          I would state - normal characteristics of IP networks..
>>>>
>>>>          No doubt there will be those trying to offer some network
>>>>          slicing with guarantees and even those who will buy it.
>>>> Just
>>>>          like today there are those who offer you L2 circuit
>>>> between
>>>>          endpoints except such L2 circuit is an emulated one with
>>>> zero
>>>>          OEM visibility to the IP infrastructure underneath.
>>>>
>>>>          Now the network slicing is clearly aiming for even more
>>>>          complexity under the hood. And that is not the only
>>>> problem. The
>>>>          issue is cost. When SP is building the IP network the goal
>>>> is to
>>>>          mux as many services on it as it simply results in given's
>>>> SP
>>>>          revenue. Network slicing is promising as potentially just
>>>> by
>>>>          configuration of few knobs they will be claiming
>>>> guarantees as
>>>>          RFC says - except RFC will not likely tell you to stop
>>>>          over-provisioning.
>>>>
>>>>          Unless the idea is to use strict policing with dedicated
>>>> queuing
>>>>          on active and back paths or do something like RSVP IntServ
>>>> also
>>>>          on active and backup paths per customer - I really don't
>>>> think
>>>>          you can really guarantee much. And if you do that the cost
>>>> would
>>>>          likely grow really steep.
>>>>
>>>>          So what is IMO the solution for assured/guaranteed global
>>>> IP
>>>>          transit:
>>>>
>>>>          *A*  get diversely routed  dark fiber paths between your
>>>> POPs
>>>>          (can be unprotected) which btw today do not cost that much
>>>> anymore
>>>>
>>>>          *B* get diversely routed  optical channels alsol between
>>>> your
>>>>          POPs (can be unprotected)
>>>>
>>>>          *C*  use N disjoined by design (single AS Internet
>>>> providers
>>>>          between your end-points) + proper SD-WAN with active SLA
>>>> monitoring
>>>>
>>>>          Clearly I am big supporter of *C* model for reasons
>>>> discussed on
>>>>          this and few other recent threads.
>>>>
>>>>          I assume network slicing will try to get into be something
>>>>          between A/B & C but it is bounded up front with the cost
>>>> of the
>>>>          two.
>>>>
>>>>          Many thx,
>>>>
>>>>          Robert.
>>>>
>>>>          On Sat, Jul 28, 2018 at 9:51 AM, Dongjie (Jimmy)
>>>>          <jie.dong@huawei.com <mailto:jie.dong@huawei.com>> wrote:
>>>>
>>>>              Hi Robert,
>>>>
>>>>              IMO the two approaches are targeting at different use
>>>> cases
>>>>              and customers.
>>>>
>>>>              The former (network slicing) is to provide the
>>>> demanding
>>>>              services with guaranteed performance in a converged
>>> network,
>>>>              while the latter (switching between multiple
>>>> paralleled
>>>>              networks) provides the customer with the best
>>>> performance
>>>>              that is available among those candidates. To me the
>>>> latter
>>>>              is still some kind of best effort, and as Toerless
>>>> said, it
>>>>              depends on the diversity you can have in the multiple
>>> networks.
>>>>
>>>>              And I agree with Stewart on “you always pay a price
>>>> for
>>>>              better than best effort.”
>>>>
>>>>              Best regards,
>>>>
>>>>              Jie
>>>>
>>>>              *From:*rtgwg [mailto:rtgwg-bounces@ietf.org
>>>>              <mailto:rtgwg-bounces@ietf.org>] *On Behalf Of *Robert
>>> Raszuk
>>>>              *Sent:* Wednesday, July 25, 2018 8:24 PM
>>>>              *To:* Acee Lindem (acee) <acee@cisco.com
>>>>              <mailto:acee@cisco.com>>
>>>>              *Cc:* rtgwg@ietf.org <mailto:rtgwg@ietf.org>
>>>>
>>>>
>>>>              *Subject:* Re: VPN security vs SD-WAN security
>>>>
>>>>              True network slicing for IP networks means either
>>>> waist of
>>>>              resources or very strict multi-level queuing at each
>>>> hop and
>>>>              100% ingress traffic policing. Yet while this has a
>>>> chance
>>>>              to work during normal operation at the time of even
>>>> regular
>>>>              failures this all pretty much melts like cheese on a
>>>> good
>>>>              sandwich.
>>>>
>>>>              It is going to be very interesting to compare how
>>>> single
>>>>              complex sliced network compares for any end to end
>>>> robust
>>>>              transport from N normal simple IP backbones and end to
>>> end
>>>>              SLA based millisecond switch over between one and
>>>> another
>>> on
>>>>              a per flow basis. Also let's note then while the
>>>> former is
>>>>              still to the best of my knowledge a draft the latter
>>>> is
>>>>              already deployed globally in 100s of networks.
>>>>
>>>>              Best,
>>>>              R.
>>>>
>>>>              On Wed, Jul 25, 2018 at 1:21 PM, Acee Lindem (acee)
>>>>              <acee@cisco.com <mailto:acee@cisco.com>> wrote:
>>>>
>>>>                  *From: *rtgwg <rtgwg-bounces@ietf.org
>>>>                  <mailto:rtgwg-bounces@ietf.org>> on behalf of
>>>> Stewart
>>>>                  Bryant <stewart.bryant@gmail.com
>>>>                  <mailto:stewart.bryant@gmail.com>>
>>>>                  *Date: *Wednesday, July 25, 2018 at 5:55 AM
>>>>                  *To: *Robert Raszuk <robert@raszuk.net
>>>>                  <mailto:robert@raszuk.net>>
>>>>                  *Cc: *Routing WG <rtgwg@ietf.org
>>> <mailto:rtgwg@ietf.org>>
>>>>                  *Subject: *Re: VPN security vs SD-WAN security
>>>>
>>>>                  On 25/07/2018 10:40, Robert Raszuk wrote:
>>>>
>>>>                      /* Adjusting the subject ... */
>>>>
>>>>                      Hello
>>>>
>>>>                      Stewart,
>>>>
>>>>                      You have made the below comment in the other
>>> thread
>>>>                      we are having:
>>>>
>>>>                          Indeed, I would have expected this to be
>>>> on a
>>>>                          secure network of some sort either purely
>>>>                          private or some form of VPN. However, I am
>>> sure
>>>>                          I read in your text that you were
>>>>                          considering using the Public Internet much
>>>> in
>>>>                          the way of SD-WAN.
>>>>
>>>>                      Would you mind as extensively as you can
>>>> expand
>>> on
>>>>                      the above statement ?
>>>>
>>>>                      Specifically on what basis do you treat say
>>>> L2VPN
>>> or
>>>>                      L3VPN of naked unencrypted packets often
>>> traveling
>>>>                      on the very same links as this "bad" Internet
>>>>                      traffic to be even slightly more secure then
>>>> IPSEC
>>>>                      or DTLS encrypted SD-WAN carried data with
>>> endpoints
>>>>                      being terminated in private systems ?
>>>>
>>>>                      Thx,
>>>>
>>>>                      Robert
>>>>
>>>>
>>>>                  Robert, I think that you have to take it as read
>>>> that an
>>>>                  air traffic control SoF system is encrypting its
>>>>                  packets. If it is not, then it is clearly not fit
>>>> for
>>>>                  purpose.
>>>>
>>>>                  What concerns me is that an air traffic system is
>>>> one of
>>>>                  the most, if not the most, high profile targets in
>>>> civil
>>>>                  society. You get reminded of this each time you
>>>> travel
>>>>                  to IETF.
>>>>
>>>>                  The thing about safety of flight traffic is that a
>>>>                  sustained and effective DDoS attack has global
>>>> impact in
>>>>                  a way that few other such attacks have.
>>>>
>>>>                  A VPN system ought to sustain resistance to such
>>>> an
>>>>                  attack better than the proposed system which
>>>> treats
>>> the
>>>>                  SoF traffic the same as regular traffic.
>>>>
>>>>                  I guess you are making a case for your network
>>>> slicing
>>>>                  work 😉
>>>>
>>>>                  Acee
>>>>
>>>>
>>>>
>>>>                  - Stewart
>>>>
>>>>          _______________________________________________
>>>>          rtgwg mailing list
>>>>          rtgwg@ietf.org <mailto:rtgwg@ietf.org>
>>>>          https://www.ietf.org/mailman/listinfo/rtgwg
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> rtgwg mailing list
>>>> rtgwg@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/rtgwg
>>>>
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas

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


--------------0F26A573268B0BA2E58C6F77-- From nobody Tue Aug 7 00:27:44 2018 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30387130DDE; Tue, 7 Aug 2018 00:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de header.b=8pYtaz1k; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=fiKt+ASa 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 g8IvXXh27yRd; Tue, 7 Aug 2018 00:27:38 -0700 (PDT) Received: from mailout34.telekom.de (MAILOUT34.telekom.de [194.25.225.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF8F3130E02; Tue, 7 Aug 2018 00:27:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1533626858; x=1565162858; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=9z/u7VXgMv0Jb4uzVSkHjZfa/iKBSMmc4ilTMu6SSrI=; b=8pYtaz1ktEFLptd/3FenMB4vV1e/w/d4W8BGFLk0de7tGblIbDNzvBQU zQRjHgUWFAgKTQ/wESKjsYExWsRHElTjA7e8SbengL8NQ29LR4AI0y3Hr E04YSjQgPgPC7oiLAZQz5h9pdRt9rI6Td0h55dfBs8AoQQKWLFPN7AEBH QC5R5UwPVXdAmT6EmDtQlxVShgsRYvYZ1Hr3G3tOLEbdWqunvixI5Pboz H1/I2gnw87EypGvMlg32LMzR+mWz98WoJpiK5l+W1fZH/FPIL0CiELtM6 /4ZOBR0GB7y2BCdcUQ76jVcEa/Y3KfzkexRFcYrkOr273iNqcSi4ZkNPW A==; Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Aug 2018 09:26:26 +0200 X-IronPort-AV: E=Sophos;i="5.51,454,1526335200"; d="scan'208";a="309745088" Received: from he105665.emea1.cds.t-internal.com ([10.169.118.62]) by QDE8PP.de.t-internal.com with ESMTP/TLS/AES256-SHA; 07 Aug 2018 09:26:26 +0200 Received: from HE101949.EMEA1.cds.t-internal.com (10.169.118.76) by HE105665.emea1.cds.t-internal.com (10.169.118.62) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 7 Aug 2018 09:26:13 +0200 Received: from HE106564.emea1.cds.t-internal.com (10.171.40.16) by HE101949.EMEA1.cds.t-internal.com (10.169.118.76) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 7 Aug 2018 09:26:13 +0200 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.22) by O365mail01.telekom.de (172.30.0.234) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 7 Aug 2018 09:25:57 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.onmicrosoft.de; s=selector1-telekom-onmicrosoft-de; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9z/u7VXgMv0Jb4uzVSkHjZfa/iKBSMmc4ilTMu6SSrI=; b=fiKt+ASa+qOr35pWBwDh3zM7viNUixjsm8Ks2gh/yQSF1AIBxfiUAg3OZb3uyTqMsW1Zb0uAOa5jQWd7yBZ9L9zz82rEViFLWQ2BoKk2OxMLpGMeQhrv3+vtspw7VAjT2xxkGIRldhW5bjCykoyQZ1KB/f5zEU/sKFm3hylOqrE= Received: from FRAPR01MB0113.DEUPRD01.PROD.OUTLOOK.DE (10.158.130.143) by FRAPR01MB0114.DEUPRD01.PROD.OUTLOOK.DE (10.158.130.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1017.14; Tue, 7 Aug 2018 07:26:05 +0000 Received: from FRAPR01MB0113.DEUPRD01.PROD.OUTLOOK.DE ([fe80::e8f7:3190:beb6:eee2]) by FRAPR01MB0113.DEUPRD01.PROD.OUTLOOK.DE ([fe80::e8f7:3190:beb6:eee2%5]) with mapi id 15.20.1017.019; Tue, 7 Aug 2018 07:26:05 +0000 From: To: CC: , Thread-Topic: =?utf-8?B?W1RlYXNdIOetlOWkjTogVlBOIHNlY3VyaXR5IHZzIFNELVdBTiBzZWN1cml0?= =?utf-8?Q?y?= Thread-Index: AdQuH+T+7KMuzTAYSJGMSpltp2II8g== Date: Tue, 7 Aug 2018 07:26:05 +0000 Message-ID: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ruediger.Geib@telekom.de; x-originating-ip: [164.19.3.156] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0114; 6:vTKGw4AYzy4qQykJcVy4rpBJA6F28RACbh/49DlCCJJ8ZY6ug0nasix77rJh8nlW35mPn/O/1oAGdK0y55esyLLcHC6ayHhfR6IU9nzRRlCEqJTyUPbVSujl3WPkdnfK7lZuOyAnnSRnO6BOu/9znaqOFTJi3eWrBrVw27Kc8744On7cyxtbFf8a3bPiYc2+r89KAMMjmMe8EiWVifIXUmkCM7sGk2FPKhfRVCWDQCL4tJ7CT+9CNjTSLt5gw/oGl0WUan9qQPnGBIlvKI/ua2AYSDvQwx0Q6j31PxQ6nuEmT2+P/PJlZmIiPmFAONtn3nPF2RNSn8hgb1yOpVPLoMeGDrNBIoctozi0sdR5451ZV5QXAKJEePMAJFzSL4b6z4qFoxxgPjmZFp1xf/4DahvSBl53ACxqR+zio97eCmHaHl736G2cN2eHex4S1lVJXGSzlPPHCyOfdUIML8/VCA==; 5:omJLC8BbzPC4odklKAveJSDOfpFHek+pPtqW3pkeXa9HOLb4cfcORzHGUufQE2Ne/ZKLMuTqrgJvKLKbIGJ400fxCdjvQBQXo1u6/ILcVf6cr5PpduVcY4EIeDmf072udrVypLZgUXS8C/CZEQi7CS6PX5eGWJa6rL2EZuf29mE=; 7:TXGn+4Y9KDf9NFPYr4w/z/m09s3VRarZhMMVIezLtX0OgRzIvHaKcqtvjH6BeymcT5Dk+CHnu1MJoaIHtSlab8D0y/XVPU2EbTLCjn6lPFvHaY3PId4JG5+XaextIWPln5r2ZkMh0eWyE6DvVI1xzpBssAcVzDc0uSharKwjVFyx1HxZ7SeaQoL6ucWOC1G3Sdo/8OoDsp3P22+ZXgGcm1wz6GOEnXLSVWQr1AJ/VRyu3v9g7KzNxggAV2zbuWLB x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: f5457bd8-c07c-4f26-9329-08d5fc370943 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:FRAPR01MB0114; x-ms-traffictypediagnostic: FRAPR01MB0114: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(72170088055959)(192374486261705)(50582790962513)(85827821059158)(260130700054247)(95692535739014)(12901024606220); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231311)(944501410)(52105095)(10201501046)(3002001)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:FRAPR01MB0114; BCL:0; PCL:0; RULEID:; SRVR:FRAPR01MB0114; x-forefront-prvs: 0757EEBDCA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39860400002)(136003)(396003)(366004)(37854004)(199004)(189003)(51444003)(72206003)(81166006)(81156014)(966005)(7696005)(53946003)(52396003)(14454004)(478600001)(75402003)(3846002)(6116002)(7736002)(8936002)(305945005)(33656002)(68736007)(15650500001)(86362001)(2900100001)(54906003)(316002)(55016002)(66066001)(6916009)(6306002)(74482002)(9686003)(97736004)(224303003)(106356001)(85202003)(105586002)(5660300001)(85182001)(53546011)(2906002)(102836004)(486006)(476003)(186003)(256004)(4326008)(39060400002)(14444005)(26005)(53936002)(5250100002)(777600001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0114; H:FRAPR01MB0113.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) x-microsoft-antispam-message-info: b4ppnQ4puafm8ojXbH3H/s0QxMbJXPCfM5qQ+TcYC1Auztpm4lhnMqVxYnrgGUWkFSIONi5bllKTo+M2IAwU8ulcLP8ElAm3U2+0YqfP1P73J4ux0K0T73YHKTENL18QbxbmV9/3KjFPFnHeO2q3SORj5U5wohncCCOKOOXeJuuNDFbyfMJR4mj0wzx2bF5TqYX7tCyu9PvinupdlUTnkZLNjMe/BKpI0Rv3quVnEiXqiBbvzOsyiCHGJWynnaE4Dqcmcrw78z8tdGSdV42ent/XTAu1hKunvfwTa2shNe4jTmVoxjxHoktU2ERg0gOhsAeKIcYCkeoDm3s35NGg/YFn8exegztVttfj9jTRmxQ= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f5457bd8-c07c-4f26-9329-08d5fc370943 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2018 07:26:05.0367 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB0114 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [Teas] =?utf-8?b?562U5aSNOiBWUE4gc2VjdXJpdHkgdnMgU0QtV0FOIHNl?= =?utf-8?q?curity?= X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 07:27:43 -0000 U3Rld2FydCwNCg0KdGhhbmtzLiBNeSByZXBsaWVzIHRvIHlvdXIgbWFpbCBhcmUgbWFya2VkIFtS R10gaW4gbGluZSBiZWxvdy4NCg0KUmVnYXJkcywgUnVlZGlnZXINCg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpGcm9tOiBTdGV3YXJ0IEJyeWFudCBbbWFpbHRvOnN0ZXdhcnQuYnJ5YW50QGdtYWls LmNvbV0gDQouLi4uLg0KUnVlZGlnZXINCg0KVGhlIHdvcmsgSSBhbSBkb2luZyBvbiBWUE4rIGlz IG5vdCB0YXJnZXR0ZWQgYXQgdGhlIGJpZyBJIEludGVybmV0LiBJdCBpcyB0YXJnZXR0ZWQgYXQg bW9iaWxlIGVkZ2UsIGFjY2VzcyBhbmQgdGhlIGNvcmUgb2YgdGhlIG1vYmlsZSBwcm92aWRlci4g VGhlc2UgYXJlIHRoZSBjdXN0b21lcnMgdGhhdCBhcmUgYXNraW5nIGZvciB0aGUgc2VydmljZSwg YW5kIHRoYXQgaW4gdHVybiBpcyBiYXNlZCBvbiB0aGUgb3V0cHV0IG9mIFNET3MgdGhhdCB0aGV5 IGFyZSBtb3JlIGNvbWZvcnRhYmxlIGFzc29jaWF0aW5nIHdpdGggKDNHUFAgYW5kIElUVS1SKS4N Cg0KW1JHXSBUaGF0J3MgZmluZSB3aXRoIG1lLiBBRkFJSywgM0dQUCBhcmNoaXRlY3R1cmVzIGxp a2UgTFRFIGFyZSBjb25uZWN0aW9uIG9yaWVudGVkIGFuZCA1RyB3aWxsIGJlIHRvby4gQXMgbG9u ZyBhcyB0aGVzZSBraW5kIG9mIHNvbHV0aW9ucyBzdGF5IGluIHRoZSBwYXJ0IG9mIG5ldHdvcmsg d2hpY2ggaXMgcGFydCBvZiB0aGUgd2lyZWxlc3MgZG9tYWluLCB0aGF0J3Mgb2sgd2l0aCBtZS4g SSdkIGFwcHJlY2lhdGUgYSBzdGF0ZW1lbnQgaW4gdGhlIHJlbGF0ZWQgZHJhZnRzLiBJIGNhbid0 IHJlY2FsbCBoYXZpbmcgaXQgcGVyY2VpdmVkIGxpa2UgdGhhdCB3aGVuIHlvdSBwcmVzZW50ZWQg aW4gTG9uZG9uIC0gYnV0IEkgYWxzbyBjb3VsZCBoYXZlIG92ZXJoZWFyZCBzb21ldGhpbmcuDQoN Ckhvd2V2ZXIsIGFzIHdlIGFsbCBrbm93LCBhIGxvdCBvZiB0cmFmZmljIHRoYXQgdXNlcnMgY29u c2lkZXIgdG8gZ28gYWNyb3NzIHRoZSBiaWcgSSBpbnRlcm5ldCBpcyBiZXR3ZWVuIHRoZW0gYW5k IHRoZSBQb1Agb2YgdGhlIENETiBwcm92aWRlciBzdXBwb3J0aW5nIHRoZSBzZXJ2aWNlIHRoZXkg YXJlIGFjY2Vzc2luZy4gVGhhdCBpcyB0aGUgbW9kZWwgdGhhdCB0aGUgbW9iaWxlIG9wZXJhdG9y cyB3YW50IHRvIHByb3BhZ2F0ZSBieSBwdWxsaW5nIGNvbXB1dGUgcmVzb3VyY2VzIGNsb3NlciB0 byB0aGUgZWRnZSBvZiB0aGVpciBuZXR3b3JrIHRoYW4gaXMgY3VycmVudGx5IHRoZSBjYXNlLg0K DQpbUkddIE15IGluZm9ybWF0aW9uIG9uIDVHIGlzLCBpZiBvbmUgYWltcyBvbiAicmVtb3RlIiBp bnRlcmFjdGlvbiBiZXR3ZWVuIG1vdmluZyBvYmplY3RzIG9yIGh1bWFucywgbGF0ZW5jaWVzIG11 c3QgYmUgc21hbGwuIFNvIGNvbnRlbnQgb3IgQ1BVIGN5Y2xlcyByZXF1aXJlZCB0byBzdXBwb3J0 IHRoZXNlIGtpbmQgb2Ygc3BlY2lhbGl6ZWQgc2VydmljZXMgbXVzdCBiZSBjbG9zZSB0byBpbnRl cmFjdGluZyBwZXJzb25zIGFuZCBvYmplY3RzLiBJJ20gbm90IHN1cmUgdG8gd2hpY2ggZXh0ZW50 IGNvbnRlbnQgaW4gZ2VuZXJhbCB3aWxsIG1vdmUgZnJvbSBjZW50cmFsIGNpdGllcyB0byB0b3du cy4gDQoNCkkgYW0gc3VyZSB0aGVyZSBhcmUgY29tbWVyY2lhbCByZWFzb25zIHdoeSB0aGV5IHdh bnQgdGhhdCB0byBoYXBwZW4gYnV0IHRoZXJlIGFyZSBhbHNvIGFwcGxpY2F0aW9uIHJlYXNvbnMg dGhhdCBkcml2ZSBhcmNoaXRlY3R1cmUgcmVhc29ucywgYW5kIGlmIHRoZXkgYWxpZ24gd2l0aCBj b21tZXJjaWFsIHJlYXNvbnMgaXQgaXMgbW9yZSBsaWtlbHkgdG8gZ2V0IGRlcGxveWVkLg0KDQpb UkddIEknZCBleHBlY3QgZWNvbm9taWMgY29uc3RyYWludHMgdG8gaW1wYWN0IHRoZSBhcmNoaXRl Y3R1cmUgb2YgdGhlIHNvbHV0aW9uIHRvby4gIA0KDQotIFN0ZXdhcnQNCg0KDQpPbiAwMi8wOC8y MDE4IDEzOjA2LCBSdWVkaWdlci5HZWliQHRlbGVrb20uZGUgd3JvdGU6DQo+IFN0ZXdhcnQsDQo+ DQo+IEknZCBhcHByZWNpYXRlIGEgZGlzY3Vzc2lvbiBiYXNlZCBvbiBvcGVyYXRpb25hbCBleHBl cmllbmNlLiBJbiB3aGljaCBEaWZmc2VydiBzdXBwb3J0ZWQgbmV0d29yayBkaWQgd2hpY2ggYXBw bGljYXRpb24gZmFpbCBkdWUgdG8gYSBsYWNrIG9mIHN1aXRhYmxlIHNjaGVkdWxpbmcgb3IgZHVl IHRvIGEgbGFjayBvZiBjb2RlcG9pbnRzLCB3aGljaCB3b3VsZCBoYXZlIGJlZW4gd29ya2luZyBw cm9wZXJseSBvbiB0aGUgc2FtZSBuZXR3b3JrIHdpdGggRGV0bmV0IGFuZCBtb3JlIGNvZGVwb2lu dHM/IEknZCBiZSBoYXBweSwgaWYgeW91IHdlcmUgYWJsZSB0byBwcm92aWRlIGEgbGluayB0byBh IHByZXNlbnRhdGlvbi4NCj4NCj4gSSd2ZSBzdGFydGVkIG15IFFvUyBjYXJlZXIgd2l0aCBBVE0s IGEgdGVjaG5vbG9neSBvZmZlcmluZyBkZWRpY2F0ZWQgUW9TIG5ldHdvcmsgcmVzb3VyY2VzLiBT cGFyZSBjYXBhY2l0aWVzIHdpdGggYSBuZXR3b3JrLWZ1bGx5LWJvb2tlZCBpbmRpY2F0aW9uIHdl cmUgdGhlIGZpcnN0IGxlc3NvbiBJIGxlYXJuZWQsIGFuZCB0aGlzIGNvbWJpbmF0aW9uIHR1cm5l ZCBvdXQgdG8gYmUgYmFkIHdoZW5ldmVyIEkgZW5jb3VudGVyZWQgaXQgZnJvbSB0aGVuIG9uLiBN eSB0YWtlIG9uIERpZmZzZXJ2IGlzLCB0aGF0IGl0IGlzIHVzZWZ1bCB0byBwcm90ZWN0IGNlcnRh aW4gdHJhZmZpYyBpbiB0aGUgY2FzZSBvZiBub3QgZm9yZXNlZW4gbmV0d29ya2luZyBjb25kaXRp b25zLiBUaGF0IG1lYW5zLCBpbiA5OSwuLi4uJSBvZiB0aGUgdGltZSwgdG9kYXlzIERpZmZzZXJ2 IGlzbid0IHJlcXVpcmVkLCBiZWNhdXNlIHRoZXJlJ3Mgbm8gY29uZ2VzdGlvbi4NCj4NCj4gWW91 IHNlZW0gdG8gaGVhZCBmb3IgZ2VuZXJpYyBzb2x1dGlvbnMsIGFwcGxpY2FibGUgaW4gYWxsIHBh cnRzIG9mIHRoZSBJbnRlcm5ldC4gSSBkb24ndCB1bmRlcnN0YW5kIHdoYXQgdGhlIGJlbmVmaXQg b2YgZGVkaWNhdGVkIHJlc291cmNlcyB3b3VsZCBiZSwgZ2l2ZW4gdGhleSBhcmUgcmVxdWlyZWQg ZW5kLXRvLWVuZC4gSSBleGN1c2UgaWYgSSBtaXNzZWQgYSBzdGF0ZW1lbnQgdGhhdCB0aGUgYXBw cm9hY2ggeW91IHByb3Bvc2UgaXMgbGltaXRlZCB0byBzcGVjaWZpYyBpbnN0YW5jZXMgb3Igc2Vj dGlvbnMgb2YgdGhlIEludGVybmV0Lg0KPg0KPiBSZWdhcmRzLA0KPg0KPiBSdWVkaWdlcg0KPg0K Pg0KPiAtLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tDQo+IFZvbjogcnRnd2cgW21h aWx0bzpydGd3Zy1ib3VuY2VzQGlldGYub3JnXSBJbSBBdWZ0cmFnIHZvbiBTdGV3YXJ0IA0KPiBC cnlhbnQNCj4gR2VzZW5kZXQ6IERvbm5lcnN0YWcsIDIuIEF1Z3VzdCAyMDE4IDEzOjE5DQo+IEFu OiBKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb20+OyBEb25namllIChKaW1teSkg DQo+IDxqaWUuZG9uZ0BodWF3ZWkuY29tPg0KPiBDYzogVEVBUyBXRyAodGVhc0BpZXRmLm9yZykg PHRlYXNAaWV0Zi5vcmc+OyBydGd3Z0BpZXRmLm9yZw0KPiBCZXRyZWZmOiBSZTogW1RlYXNdIOet lOWkjTogVlBOIHNlY3VyaXR5IHZzIFNELVdBTiBzZWN1cml0eQ0KPg0KPg0KPg0KPiBPbiAwMS8w OC8yMDE4IDE2OjI2LCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+PiBJIGFtIG5vdCBkaXNhZ3Jl ZWluZyB3aXRoIGEgdmlldyB0aGF0IG5ldHdvcmsgcmVzb3VyY2UgYWxsb2NhdGlvbiANCj4+IHJl cXVpcmVzIHNvbWUgdmlzaWJpbGl0eSB0byB0aG9zZSByZXNvdXJjZXMuDQo+PiBJdCBpcyB0aGUg YXNzZXJ0aW9uIG9mIGEgImRlZXAgaW50ZWdyYXRpb24iIHRoYXQgc2VlbXMgdG8gbGFjayBncm91 bmRpbmcuDQo+Pg0KPj4gV2Uga25vdyB0aGF0IG9uZSBjYW4gdXNlIG91ciBleGlzdGluZyBWUE4g dGVjaG5vbG9naWVzIGFuZCB0b29scyBsaWtlIA0KPj4gZGlmZnNlcnYsIHdpdGggc3VpdGFibGUg YWRtaXNzaW9uIGNvbnRyb2wgYW5kIHBhdGggY29tcHV0YXRpb24sIHRvIA0KPj4gcHJvdmlkZSBz dHJvbmcgc2VydmljZSBndWFyYW50ZWVzIHRvIG1lZXQgU0xBcy4gQXMgb3RoZXJzIGhhdmUgbm90 ZWQgDQo+PiBpbiBvdGhlciBwcmVzZW50YXRpb25zLCB3aGVuIGl0IGNvbWVzIHRvIHRoZSBkYXRh IHBsYW5lIHRoaXMgc2VlbXMgdG8gDQo+PiBtZWV0IHRoZSBhcnRpY3VsYXRlZCBuZWVkcyBmcm9t IHZhcmlvdXMgZm9yYS4NCj4+DQo+IEhpIEpvZWwsDQo+DQo+IFdlIGNhbiBjZXJ0YWlubHkgZ2V0 IGEgbG9uZyB3YXkgd2l0aCB0aG9zZSB0b29scyBmb3IgImNvbnZlbnRpb25hbCINCj4gYXBwbGlj YXRpb25zLg0KPg0KPiBIb3dldmVyLCBhcyB3ZSBzdXBwb3J0IHRoZSBzb3J0IG9mIGFwcGxpY2F0 aW9ucyB0aGF0IGxvb2sgZm9yIGEgZGV0ZXJtaW5pc3RpYyBuZXR3b3JraW5nIGNsYXNzIG9mIFNM QSwgdGhlbiBJIGFtIGNvbmNlcm5lZCB0aGF0IHdlIG5lZWQgdG8gbWFwIHRoZSB0cmFmZmljIHRv IGRlZGljYXRlZCByZXNvdXJjZXMgaW4gbW9yZSBkZXRhaWwgdGhhbiB3ZSBjdXJyZW50bHkgZG8g dGhyb3VnaCB0aGUgZGlmZnNlcnYgbWVjaGFuaXNtLg0KPg0KPiBXaGF0IHdlIGRvIGF0IHRoZSBt b21lbnQgd2l0aCBkaWZmc2VydiBpcyBhIG1hcHBpbmcgb2YgcGFja2V0cyB0byByZXNvdXJjZXMs IGJ1dCBpbiBwcmFjdGlzZSB3ZSBsaW1pdCB0aG9zZSByZXNvdXJjZXMgdG8gaW5ncmVzcyBhbmQg ZWdyZXNzIHF1ZXVlcyB3aXRoIHRoZSBxdWV1ZSBtYW5hZ2VtZW50IGFsZ29yaXRobSBvdXQgb2Yg c2NvcGUuIEkgYW0gbm90IGNvbnZpbmNlZCB0aGlzIGlzIGFkZXF1YXRlIGZvciB0aGUgZnV0dXJl LCBhbmQgdGhpbmsgdGhhdCB3ZSBuZWVkIHRvIHN0YXJ0IHRvIGNvbnNpZGVyIENQVS9OUFUgY29y ZXMsIHF1ZXVlIGFsZ29yaXRobXMsIGFuZCBtYXliZSBvdGhlciByZXNvdXJjZXMuDQo+DQo+IEkg YW0gYWxzbyBjb25jZXJuZWQgdGhhdCB0aGUgbnVtYmVyIG9mIGRpZmZzZXJ2IGNvZGUgcG9pbnRz IGF2YWlsYWJsZSBpbiBNUExTIGlzIGdvaW5nIHRvIGJlIGluc3VmZmljaWVudC4NCj4NCj4gT2Yg Y291cnNlIHdoYXQgd2Uga25vdyB0b2RheSBmcm9tIGV4cGVyaWVuY2UgaXMgYmFzZWQgb24gdGhl IA0KPiBhcHBsaWNhdGlvbnMgdGhhdCBjYW4gcnVuIG9uIHRoZSBuZXR3b3JrIGluZnJhc3RydWN0 dXJlIHRoYXQgd2UgaGF2ZSANCj4gdG9kYXkuIFRoYXQgaXMgYSBzZWxmIGxpbWl0aW5nIHNpdHVh dGlvbi4gV2UgYXJlIGRlc2lnbmluZyBERVRORVQgDQo+IGJlY2F1c2UgdGhpcyBtb2RlbCBpcyBp bmFkZXF1YXRlIGZvciBzb21lIGNsYXNzZXMgb2YgYXBwbGljYXRpb24gdGhhdCANCj4gd291bGQg bGlrZSB0byBydW4gb3ZlciBhIG1vcmUgZ2VuZXJhbCBuZXR3b3JrLiBXaGF0IHdlIGFyZSBkb2lu ZyB3aXRoDQo+IFZQTisgaXMgdG8gaW50ZWdyYXRlIERFVE5FVCBpbnRvIGEgVlBOIHN0cnVjdHVy ZSBhbG9uZ3NpZGUgY2xhc3NpYyBWUE5zLg0KPg0KPiAtIFN0ZXdhcnQNCj4NCj4NCj4+IFlvdXJz LA0KPj4gSm9lbA0KPj4NCj4+IE9uIDgvMS8xOCAxMToyMiBBTSwgRG9uZ2ppZSAoSmltbXkpIHdy b3RlOg0KPj4+IFRoaXMgc3RhdGVtZW50IGlzIGJhc2VkIG9uIHRoZSBjb21wYXJpc29uIGJldHdl ZW4gb3ZlcmxheSBWUE5zIGFuZCANCj4+PiBuZXR3b3JrIHNsaWNlcy4gVGhlIHJlc291cmNlIGhl cmUgcmVmZXJzIHRvIHZhcmlvdXMgZGF0YSBwbGFuZSANCj4+PiByZXNvdXJjZXMgdGhhdCBjYW4g YmUgYWxsb2NhdGVkIHRvIGEgcGFydGljdWxhciBzbGljZSAocXVldWVzLCANCj4+PiBidWZmZXIs IGV0Yy4pLiBTb21lIGxldmVsIG9mIHJlc291cmNlIGlzb2xhdGlvbiBpcyBuZWNlc3NhcnkgdG8g DQo+Pj4gZW5zdXJlIHRoYXQgc2VydmljZSBpbiBvbmUgc2xpY2UgbmV2ZXIgaW50ZXJmZXJlcyB3 aXRoIHNlcnZpY2UgaW4gDQo+Pj4gYW5vdGhlciBzbGljZS4NCj4+Pg0KPj4+IE1heSBJIGtub3cg d2hhdCBhcmUgdGhlIHJlcXVpcmVtZW50cyB5b3UndmUgZ290Pw0KPj4+DQo+Pj4gQmVzdCByZWdh cmRzLA0KPj4+IEppZQ0KPj4+DQo+Pj4+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4+Pj4g5Y+R 5Lu25Lq6OiBKb2VsIE0uIEhhbHBlcm4gW21haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tXQ0KPj4+ PiDlj5HpgIHml7bpl7Q6IDIwMTjlubQ35pyIMzDml6UgMjM6MDUNCj4+Pj4g5pS25Lu25Lq6OiBE b25namllIChKaW1teSkgPGppZS5kb25nQGh1YXdlaS5jb20+DQo+Pj4+IOaKhOmAgTogVEVBUyBX RyAodGVhc0BpZXRmLm9yZykgPHRlYXNAaWV0Zi5vcmc+OyBydGd3Z0BpZXRmLm9yZw0KPj4+PiDk uLvpopg6IFJlOiBWUE4gc2VjdXJpdHkgdnMgU0QtV0FOIHNlY3VyaXR5DQo+Pj4+DQo+Pj4+IEFj dHVhbGx5LCBhc3N1bWluZyBJIHVuZGVyc3RhbmQgdGhlIHN0YXRlbWVudCBwcm9wZXJseSwgImRl ZXAgDQo+Pj4+IGludGVncmF0aW9uIHdpdGggdGhlIHVuZGVybGF5IHJlc291cmNlIHdvdWxkIGJl IG5lY2Vzc2FyeSIgZG9lcyBub3QgDQo+Pj4+IGFwcGVhciB0byBiZSBhbiBhY2N1cmF0ZSBzdGF0 ZW1lbnQgZGVyaXZhYmxlIGZyb20gdGhlIHJlcXVpcmVtZW50cyANCj4+Pj4gdGhhdCBJIGhhdmUg c2Vlbi4NCj4+Pj4NCj4+Pj4gWW91cnMsDQo+Pj4+IEpvZWwNCj4+Pj4NCj4+Pj4gT24gNy8zMC8x OCA4OjIzIEFNLCBEb25namllIChKaW1teSkgd3JvdGU6DQo+Pj4+PiAoQWRkaW5nIFRFQVMgYXMg aXQgaXMgd2hlcmUgdGhlIFZQTisgZnJhbWV3b3JrIGRyYWZ0IGlzIGRpc2N1c3NlZCkNCj4+Pj4+ DQo+Pj4+PiBIaSBSb2JlcnQgYW5kIEdyZWcsDQo+Pj4+Pg0KPj4+Pj4gQXMgZGlzY3Vzc2VkIGR1 cmluZyB0aGUgVlBOKyBwcmVzZW50YXRpb24gaW4gVEVBUyBhdCBJRVRGIDEwMiwgdGhlIA0KPj4+ Pj4gc2NvcGUgaXMgbm90IHRoZSBpbnRlcm5ldCwgYXMgd2Uga25vdyBpdCB3b3VsZCBxdWl0ZSBk aWZmaWN1bHQgb3IgDQo+Pj4+PiBldmVuIGltcG9zc2libGUgdG8gYWNoaWV2ZSB0aGUgcmVxdWly ZWQgZ3VhcmFudGVlIGF0IHRoZSBzY29wZSBvZiBpbnRlcm5ldC4NCj4+Pj4+DQo+Pj4+PiBBbmQg Y2xlYXJseSB0aGUgVlBOIG92ZXJsYXlzIGNhbm5vdCBwcm92aWRlIHRoZSByZXF1aXJlZCANCj4+ Pj4+IGd1YXJhbnRlZSwgZGVlcCBpbnRlZ3JhdGlvbiB3aXRoIHRoZSB1bmRlcmxheSByZXNvdXJj ZSB3b3VsZCBiZSBuZWNlc3NhcnkuDQo+Pj4+Pg0KPj4+Pj4gQW5vdGhlciBhc3BlY3Qgd2UgbWF5 IHRha2UgaW50byBjb25zaWRlcmF0aW9uIGlzIHRoZSBmYWN0b3Igb2YgDQo+Pj4+PiBvdmVycHJv dmlzaW9uaW5nLiBUaGUgY3VycmVudCBuZXR3b3JrIG9ubHkgaGFzIG9uZSANCj4+Pj4+IG92ZXJw cm92aXNpb25pbmcgZmFjdG9yLCB3aGljaCBtYXkgbm90IG1lZXQgdGhlIHJlcXVpcmVtZW50IG9m IA0KPj4+Pj4gZGlmZmVyZW50IHNlcnZpY2VzL2N1c3RvbWVycy4gV2l0aCBuZXR3b3JrIHNsaWNp bmcsIGl0IGlzIHBvc3NpYmxlIA0KPj4+Pj4gdG8gaGF2ZSBkaWZmZXJlbnQgb3ZlcnByb3Zpc2lv bmluZyBwb2xpY3kgYW5kIGZhY3RvciBpbiBkaWZmZXJlbnQgc2xpY2VzLg0KPj4+Pj4NCj4+Pj4+ IEJlc3QgcmVnYXJkcywNCj4+Pj4+DQo+Pj4+PiBKaWUNCj4+Pj4+DQo+Pj4+PiAqRnJvbToqcnJh c3p1a0BnbWFpbC5jb20gW21haWx0bzpycmFzenVrQGdtYWlsLmNvbV0gKk9uIEJlaGFsZiBPZiAN Cj4+Pj4+ICpSb2JlcnQgUmFzenVrDQo+Pj4+PiAqU2VudDoqIFN1bmRheSwgSnVseSAyOSwgMjAx OCA2OjExIEFNDQo+Pj4+PiAqVG86KiBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29t Pg0KPj4+Pj4gKkNjOiogRG9uZ2ppZSAoSmltbXkpIDxqaWUuZG9uZ0BodWF3ZWkuY29tPjsgcnRn d2dAaWV0Zi5vcmcNCj4+Pj4+ICpTdWJqZWN0OiogUmU6IFZQTiBzZWN1cml0eSB2cyBTRC1XQU4g c2VjdXJpdHkNCj4+Pj4+DQo+Pj4+PiBIZXkgR3JlZywNCj4+Pj4+DQo+Pj4+PiB3b3VsZCBub3Qg cmVxdWlyZSBnbG9iYWwgdHJhbnNpdCBhbmQgbGlrZWx5IGJlIGNvbnRhaW5lZCB3aXRoaW4gDQo+ Pj4+PiBhY2Nlc3Mgb3IsIGF0IG1vc3QsIG1ldHJvIGRvbWFpbnMuDQo+Pj4+Pg0KPj4+Pj4gVGhh dCdzIG5ld3MgdG8gbWUsIGJ1dCBwZXJoYXBzIG9uIHRoZSBwb3NpdGl2ZSBzaWRlIDopIEkgYWx3 YXlzIA0KPj4+Pj4gdGhpbmsgV0FOIC4uIHJlYWxseSB3aWRlIG9uZSAhDQo+Pj4+Pg0KPj4+Pj4g VGhlIHNlcGFyYXRpb24gb24gInNvZnQiIHZzICJoYXJkIiBndWFyYW50ZWVzIGlzIGV2ZW50dWFs bHkgYWxsIA0KPj4+Pj4gYWJvdXQgYW1vdW50IG9mIG5ldHdvcmsgcm9idXN0bmVzcyBhbmQgbGV2 ZWwgb2Ygb3ZlciBwcm92aXNpb25pbmcuDQo+Pj4+PiBJIHNpbmNlcmVseSBob3BlIGl0IHdpbGwg bm90IGJlIHlldCBhbm90aGVyIEVWUE4gb3ZlcmxheSBvdmVyIElQIA0KPj4+Pj4gbmV0d29yayBq dXN0IHBhaW50ZWQgd2l0aCBkaWZmZXJlbnQgbWFya2V0aW5nIGNvbG9ycy4NCj4+Pj4+DQo+Pj4+ PiBCZXNpZGVzIGlmIGFueSBjdXN0b21lciBpcyBzZXJpb3VzIGFuZCBhY3R1YWxseSBjb3VudHMg b24gdGhvc2UgDQo+Pj4+PiBndWFyYW50ZWVzIGhlIGJldHRlciBwdXJjaGFzZSB0d28gb2Ygc3Vj aCBzZXJ2aWNlcyBjb21pbmcgZnJvbSANCj4+Pj4+IGluZGVwZW5kZW50IG9wZXJhdG9ycy4gVGhh dCBtZWFucyB0aGF0IHRvIGJlIGF0dHJhY3RpdmUgDQo+Pj4+PiBmaW5hbmNpYWxseSBjb3N0IG9m IHN1Y2ggcHJlbWl1bSBzZXJ2aWNlIG11c3Qgbm90IGJlIGhpZ2hlciB0aGVuIA0KPj4+Pj4gaGFs ZiBvZiB0aGUgcDJwIGxvY2FsIGZpYmVyIG9yIGNvc3Qgb2YgbG9jYWwgYWNjZXNzIHRvIGNsb3Nl c3QgSVggDQo+Pj4+PiBwb3J0cyArIHBvcnQgc3Vic2NyaXB0aW9uIGluIGEgZ2l2ZW4gTUFOIHdo ZXJlIG5vbiBibG9ja2luZyBJWCANCj4+Pj4+IGZhYnJpYyBzcGFucyBnaXZlbg0KPj4+PiBnZW9n cmFwaHkuDQo+Pj4+PiBJdCBzZWVtcyB0byBtZSB0aGF0IGF0IHRoZSBlbmQgb2YgdGhlIGRheSB0 aGUgc3BhY2UgZm9yIHRob3NlIA0KPj4+Pj4gb3BlcmF0b3JzIHdpc2hpbmcgdG8gb2ZmZXIgaGFy ZCBuZXR3b3JrIHNsaWNpbmcgaXMgYWN0dWFsbHkgcHJldHR5IA0KPj4+Pj4gbmFycm93LCBidXQg dGltZSB3aWxsIHRlbGwgLi4uDQo+Pj4+Pg0KPj4+Pj4gUmdzLA0KPj4+Pj4NCj4+Pj4+IHIuDQo+ Pj4+Pg0KPj4+Pj4gT24gU2F0LCBKdWwgMjgsIDIwMTggYXQgOTozNCBQTSwgR3JlZyBNaXJza3kg DQo+Pj4+PiA8Z3JlZ2ltaXJza3lAZ21haWwuY29tIDxtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwu Y29tPj4gd3JvdGU6DQo+Pj4+Pg0KPj4+Pj4gIMKgwqDCoMKgIEhpIFJvYmVydCwNCj4+Pj4+DQo+ Pj4+PiAgwqDCoMKgwqAgdmVyeSBtdWNoIGFncmVlIHdpdGggYWxsIHlvdSdyZSBzYXlpbmcgYW5k IGZpbmQgdXMgaW4gDQo+Pj4+PiB2aW9sZW50DQo+Pj4+PiAgwqDCoMKgwqAgYWdyZWVtZW50IG9u ICJDIi4gUHJvYWN0aXZlIHBlcmZvcm1hbmNlIG1vbml0b3JpbmcsIGluIG15IA0KPj4+Pj4gdmll dyBhcw0KPj4+Pj4gIMKgwqDCoMKgIHdlbGwsIGlzIHRoZSByZWFzb25hYmxlIHBhdGggdG8gcHJv dmlkZSAic29mdCIgU0xBIGFuZCwgdG8gYSANCj4+Pj4+IGRlZ3JlZSwNCj4+Pj4+ICDCoMKgwqDC oCBwcmV2ZW50IG92ZXJzdWJzY3JpcHRpb24gb2YgdGhlIG5ldHdvcmsuIEFuZCB0aGF0LCBhcyB5 b3UndmUgDQo+Pj4+PiBzYWlkLA0KPj4+Pj4gIMKgwqDCoMKgIGlzIG9uZSB3YXkgdG8gImFzc3Vy ZWQvZ3VhcmFudGVlZCBnbG9iYWwgSVAgdHJhbnNpdCIuDQo+Pj4+Pg0KPj4+Pj4gIMKgwqDCoMKg IEJ1dCBJIHRoaW5rIHRoYXQgdGhlcmUgd2lsbCBiZSBkZW1hbmQgZm9yICJoYXJkIiBndWFyYW50 ZWVzIA0KPj4+Pj4gZm9yDQo+Pj4+PiAgwqDCoMKgwqAgVVJMTEPCoGFwcGxpY2F0aW9ucy4gQnV0 IHRoZXNlLCBpbiBteSB2aWV3LA0KPj4+Pj4NCj4+Pj4+ICDCoMKgwqDCoCB3b3VsZCBub3QgcmVx dWlyZSBnbG9iYWwgdHJhbnNpdCBhbmQgbGlrZWx5IGJlIGNvbnRhaW5lZCANCj4+Pj4+IHdpdGhp bg0KPj4+Pj4gIMKgwqDCoMKgIGFjY2Vzc8Kgb3IsIGF0IG1vc3QsIG1ldHJvIGRvbWFpbnMuIEJl Y2F1c2Ugb2YgdGhlIGxpbWl0ZWQgDQo+Pj4+PiBzaXplIG9mDQo+Pj4+PiAgwqDCoMKgwqAgdGhl IGRvbWFpbiwgSW50U2VydiBtYXkgd29yaywgdGhvdWdoIHRoYXQgbWF5IGJlIG5vdCB0aGUgDQo+ Pj4+PiBtb3N0DQo+Pj4+PiAgwqDCoMKgwqAgZWZmaWNpZW50IHRlY2huaXF1ZS4gV2Ugc2hhbGwg ZmluZCBvdXQuDQo+Pj4+Pg0KPj4+Pj4gIMKgwqDCoMKgIEhlbmNlIG15IHZpZXcgb24gc2xpY2lu ZzoNCj4+Pj4+DQo+Pj4+PiAgwqDCoMKgwqDCoMKgICogZGlmZmVyZW50IGFwcGxpY2F0aW9ucyB3 aWxsIGhhdmUgZGlmZmVyZW50IHJlcXVpcmVtZW50cyANCj4+Pj4+IGFuZCB1c2UNCj4+Pj4+ICDC oMKgwqDCoMKgwqDCoMKgIGRpZmZlcmVudCBkZWdyZWVzIG9mIGlzb2xhdGlvbiBhbmQgZ3VhcmFu dGVlczsNCj4+Pj4+ICDCoMKgwqDCoMKgwqAgKiAic29mdCIgc2xpY2VzIG1heSBub3QgbmVlZCBt dWNoIG9mIGFkZGl0aW9uYWwgDQo+Pj4+PiBzdGFuZGFyZGl6YXRpb24NCj4+Pj4+ICDCoMKgwqDC oMKgwqDCoMKgIGFuZCB1c2UgYXZhaWxhYmxlIFZQTiB0ZWNobm9sb2dpZXMgaW4gY29tYmluYXRp b24gd2l0aCANCj4+Pj4+IFBNIE9BTQ0KPj4+Pj4gIMKgwqDCoMKgwqDCoMKgwqAgZm9yIFNMQSBt b25pdG9yaW5nIGFuZCBhc3N1cmFuY2U7DQo+Pj4+PiAgwqDCoMKgwqDCoMKgICogImhhcmQiIHNs aWNlcyB3b3VsZCBzcGFuIHdpdGhpbiBhIHNpbmdsZSBhY2Nlc3MgYW5kL29yIA0KPj4+Pj4gbWV0 cm8NCj4+Pj4+ICDCoMKgwqDCoMKgwqDCoMKgIGRvbWFpbi4gTmV0d29ya2luZyBzb2x1dGlvbnMg bGlrZWx5IHdpbGwgYmUgY291cGxlZCB3aXRoDQo+Pj4+PiAgwqDCoMKgwqDCoMKgwqDCoCBhcmNo aXRlY3R1cmUgYW5kIGludGVyZmFjZXMgZGV2ZWxvcGVkIGluIE11bHRpLWFjY2VzcyANCj4+Pj4+ IEVkZ2UNCj4+Pj4+ICDCoMKgwqDCoMKgwqDCoMKgIENvbXB1dGluZyAoTUVDKS4NCj4+Pj4+DQo+ Pj4+PiAgwqDCoMKgwqAgUmVnYXJkcywNCj4+Pj4+DQo+Pj4+PiAgwqDCoMKgwqAgR3JlZw0KPj4+ Pj4NCj4+Pj4+ICDCoMKgwqDCoCBPbiBTYXQsIEp1bCAyOCwgMjAxOCBhdCA2OjAyIEFNLCBSb2Jl cnQgUmFzenVrIA0KPj4+Pj4gPHJvYmVydEByYXN6dWsubmV0DQo+Pj4+PiAgwqDCoMKgwqAgPG1h aWx0bzpyb2JlcnRAcmFzenVrLm5ldD4+IHdyb3RlOg0KPj4+Pj4NCj4+Pj4+ICDCoMKgwqDCoMKg wqDCoMKgIEhpIEppZSwNCj4+Pj4+DQo+Pj4+PiAgwqDCoMKgwqDCoMKgwqDCoCA+IChuZXR3b3Jr IHNsaWNpbmcpIGlzIHRvIHByb3ZpZGUgdGhlIGRlbWFuZGluZyBzZXJ2aWNlcyANCj4+Pj4+IHdp dGggZ3VhcmFudGVlZCBwZXJmb3JtYW5jZSBpbiBhIGNvbnZlcmdlZCBuZXR3b3JrLA0KPj4+Pj4N Cj4+Pj4+ICDCoMKgwqDCoMKgwqDCoMKgIEZvdW5kYXRpb24gb2YgY29udmVyZ2VkIElQIG5ldHdv cmsgaXMgYmFzZWQgb24gDQo+Pj4+PiBzdGF0aXN0aWNhbA0KPj4+Pj4gIMKgwqDCoMKgwqDCoMKg wqAgbXVsdGlwbGV4aW5nIG9mIHRyYWZmaWMgZGVtYW5kcy4gQXMgc3VjaCBpdCBpcyBpbiBpdHMg DQo+Pj4+PiBwcmluY2lwbGUNCj4+Pj4+ICDCoMKgwqDCoMKgwqDCoMKgIHF1aXRlIGNvbnRyYWRp Y3RvcnkgdG8gImd1YXJhbnRlZWQiIGNoYXJhY3RlcmlzdGljcw0KPj4+Pj4gIMKgwqDCoMKgwqDC oMKgwqAgKHBlcmZvcm1hbmNlLCBkZWxheXMsIGppdHRlciwgZHJvcHMgLS0geW91IG5hbWUgaXQp Lg0KPj4+Pj4NCj4+Pj4+ICDCoMKgwqDCoMKgwqDCoMKgIEFwcGxpY2F0aW9uIGxheWVycyB1c3Vh bGx5IGRlYWwgdmVyeSB3ZWxsIHdpdGggYWxsIG9mIA0KPj4+Pj4gdGhlIGFib3ZlDQo+Pj4+PiAg wqDCoMKgwqDCoMKgwqDCoCBJIHdvdWxkIHN0YXRlIC0gbm9ybWFsIGNoYXJhY3RlcmlzdGljcyBv ZiBJUCBuZXR3b3Jrcy4uDQo+Pj4+Pg0KPj4+Pj4gIMKgwqDCoMKgwqDCoMKgwqAgTm8gZG91YnQg dGhlcmUgd2lsbCBiZSB0aG9zZSB0cnlpbmcgdG8gb2ZmZXIgc29tZSANCj4+Pj4+IG5ldHdvcmsN Cj4+Pj4+ICDCoMKgwqDCoMKgwqDCoMKgIHNsaWNpbmcgd2l0aCBndWFyYW50ZWVzIGFuZCBldmVu IHRob3NlIHdobyB3aWxsIGJ1eSBpdC4NCj4+Pj4+IEp1c3QNCj4+Pj4+ICDCoMKgwqDCoMKgwqDC oMKgIGxpa2UgdG9kYXkgdGhlcmUgYXJlIHRob3NlIHdobyBvZmZlciB5b3UgTDIgY2lyY3VpdCAN Cj4+Pj4+IGJldHdlZW4NCj4+Pj4+ICDCoMKgwqDCoMKgwqDCoMKgIGVuZHBvaW50cyBleGNlcHQg c3VjaCBMMiBjaXJjdWl0IGlzIGFuIGVtdWxhdGVkIG9uZSB3aXRoIA0KPj4+Pj4gemVybw0KPj4+ Pj4gIMKgwqDCoMKgwqDCoMKgwqAgT0VNIHZpc2liaWxpdHkgdG8gdGhlIElQIGluZnJhc3RydWN0 dXJlIHVuZGVybmVhdGguDQo+Pj4+Pg0KPj4+Pj4gIMKgwqDCoMKgwqDCoMKgwqAgTm93IHRoZSBu ZXR3b3JrIHNsaWNpbmcgaXMgY2xlYXJseSBhaW1pbmcgZm9yIGV2ZW4gbW9yZQ0KPj4+Pj4gIMKg wqDCoMKgwqDCoMKgwqAgY29tcGxleGl0eSB1bmRlciB0aGUgaG9vZC4gQW5kIHRoYXQgaXMgbm90 IHRoZSBvbmx5IA0KPj4+Pj4gcHJvYmxlbS4gVGhlDQo+Pj4+PiAgwqDCoMKgwqDCoMKgwqDCoCBp c3N1ZSBpcyBjb3N0LiBXaGVuIFNQIGlzIGJ1aWxkaW5nIHRoZSBJUCBuZXR3b3JrIHRoZSANCj4+ Pj4+IGdvYWwgaXMgdG8NCj4+Pj4+ICDCoMKgwqDCoMKgwqDCoMKgIG11eCBhcyBtYW55IHNlcnZp Y2VzIG9uIGl0IGFzIGl0IHNpbXBseSByZXN1bHRzIGluIA0KPj4+Pj4gZ2l2ZW4ncyBTUA0KPj4+ Pj4gIMKgwqDCoMKgwqDCoMKgwqAgcmV2ZW51ZS4gTmV0d29yayBzbGljaW5nIGlzIHByb21pc2lu ZyBhcyBwb3RlbnRpYWxseSANCj4+Pj4+IGp1c3QgYnkNCj4+Pj4+ICDCoMKgwqDCoMKgwqDCoMKg IGNvbmZpZ3VyYXRpb24gb2YgZmV3IGtub2JzIHRoZXkgd2lsbCBiZSBjbGFpbWluZyANCj4+Pj4+ IGd1YXJhbnRlZXMgYXMNCj4+Pj4+ICDCoMKgwqDCoMKgwqDCoMKgIFJGQyBzYXlzIC0gZXhjZXB0 IFJGQyB3aWxsIG5vdCBsaWtlbHkgdGVsbCB5b3UgdG8gc3RvcA0KPj4+Pj4gIMKgwqDCoMKgwqDC oMKgwqAgb3Zlci1wcm92aXNpb25pbmcuDQo+Pj4+Pg0KPj4+Pj4gIMKgwqDCoMKgwqDCoMKgwqAg VW5sZXNzIHRoZSBpZGVhIGlzIHRvIHVzZSBzdHJpY3QgcG9saWNpbmcgd2l0aCBkZWRpY2F0ZWQg DQo+Pj4+PiBxdWV1aW5nDQo+Pj4+PiAgwqDCoMKgwqDCoMKgwqDCoCBvbiBhY3RpdmUgYW5kIGJh Y2sgcGF0aHMgb3IgZG8gc29tZXRoaW5nIGxpa2UgUlNWUCANCj4+Pj4+IEludFNlcnYgYWxzbw0K Pj4+Pj4gIMKgwqDCoMKgwqDCoMKgwqAgb24gYWN0aXZlIGFuZCBiYWNrdXAgcGF0aHMgcGVyIGN1 c3RvbWVyIC0gSSByZWFsbHkgZG9uJ3QgDQo+Pj4+PiB0aGluaw0KPj4+Pj4gIMKgwqDCoMKgwqDC oMKgwqAgeW91IGNhbiByZWFsbHkgZ3VhcmFudGVlIG11Y2guIEFuZCBpZiB5b3UgZG8gdGhhdCB0 aGUgDQo+Pj4+PiBjb3N0IHdvdWxkDQo+Pj4+PiAgwqDCoMKgwqDCoMKgwqDCoCBsaWtlbHkgZ3Jv dyByZWFsbHkgc3RlZXAuDQo+Pj4+Pg0KPj4+Pj4gIMKgwqDCoMKgwqDCoMKgwqAgU28gd2hhdCBp cyBJTU8gdGhlIHNvbHV0aW9uIGZvciBhc3N1cmVkL2d1YXJhbnRlZWQgDQo+Pj4+PiBnbG9iYWwg SVANCj4+Pj4+ICDCoMKgwqDCoMKgwqDCoMKgIHRyYW5zaXQ6DQo+Pj4+Pg0KPj4+Pj4gIMKgwqDC oMKgwqDCoMKgwqAgKkEqwqAgZ2V0IGRpdmVyc2VseSByb3V0ZWTCoCBkYXJrIGZpYmVyIHBhdGhz IGJldHdlZW4geW91ciANCj4+Pj4+IFBPUHMNCj4+Pj4+ICDCoMKgwqDCoMKgwqDCoMKgIChjYW4g YmUgdW5wcm90ZWN0ZWQpIHdoaWNoIGJ0dyB0b2RheSBkbyBub3QgY29zdCB0aGF0IA0KPj4+Pj4g bXVjaCBhbnltb3JlDQo+Pj4+Pg0KPj4+Pj4gIMKgwqDCoMKgwqDCoMKgwqAgKkIqIGdldCBkaXZl cnNlbHkgcm91dGVkwqAgb3B0aWNhbCBjaGFubmVscyBhbHNvbCBiZXR3ZWVuIA0KPj4+Pj4geW91 cg0KPj4+Pj4gIMKgwqDCoMKgwqDCoMKgwqAgUE9QcyAoY2FuIGJlIHVucHJvdGVjdGVkKQ0KPj4+ Pj4NCj4+Pj4+ICDCoMKgwqDCoMKgwqDCoMKgICpDKsKgIHVzZSBOIGRpc2pvaW5lZCBieSBkZXNp Z24gKHNpbmdsZSBBUyBJbnRlcm5ldCANCj4+Pj4+IHByb3ZpZGVycw0KPj4+Pj4gIMKgwqDCoMKg wqDCoMKgwqAgYmV0d2VlbiB5b3VyIGVuZC1wb2ludHMpICsgcHJvcGVyIFNELVdBTiB3aXRoIGFj dGl2ZSBTTEEgDQo+Pj4+PiBtb25pdG9yaW5nDQo+Pj4+Pg0KPj4+Pj4gIMKgwqDCoMKgwqDCoMKg wqAgQ2xlYXJseSBJIGFtIGJpZyBzdXBwb3J0ZXIgb2YgKkMqIG1vZGVsIGZvciByZWFzb25zIA0K Pj4+Pj4gZGlzY3Vzc2VkIG9uDQo+Pj4+PiAgwqDCoMKgwqDCoMKgwqDCoCB0aGlzIGFuZCBmZXcg b3RoZXIgcmVjZW50IHRocmVhZHMuDQo+Pj4+Pg0KPj4+Pj4gIMKgwqDCoMKgwqDCoMKgwqAgSSBh c3N1bWUgbmV0d29yayBzbGljaW5nIHdpbGwgdHJ5IHRvIGdldCBpbnRvIGJlIA0KPj4+Pj4gc29t ZXRoaW5nDQo+Pj4+PiAgwqDCoMKgwqDCoMKgwqDCoCBiZXR3ZWVuIEEvQiAmIEMgYnV0IGl0IGlz IGJvdW5kZWQgdXAgZnJvbnQgd2l0aCB0aGUgY29zdCANCj4+Pj4+IG9mIHRoZQ0KPj4+Pj4gIMKg wqDCoMKgwqDCoMKgwqAgdHdvLg0KPj4+Pj4NCj4+Pj4+ICDCoMKgwqDCoMKgwqDCoMKgIE1hbnkg dGh4LA0KPj4+Pj4NCj4+Pj4+ICDCoMKgwqDCoMKgwqDCoMKgIFJvYmVydC4NCj4+Pj4+DQo+Pj4+ PiAgwqDCoMKgwqDCoMKgwqDCoCBPbiBTYXQsIEp1bCAyOCwgMjAxOCBhdCA5OjUxIEFNLCBEb25n amllIChKaW1teSkNCj4+Pj4+ICDCoMKgwqDCoMKgwqDCoMKgIDxqaWUuZG9uZ0BodWF3ZWkuY29t IDxtYWlsdG86amllLmRvbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KPj4+Pj4NCj4+Pj4+ICDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgSGkgUm9iZXJ0LA0KPj4+Pj4NCj4+Pj4+ICDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgSU1PIHRoZSB0d28gYXBwcm9hY2hlcyBhcmUgdGFyZ2V0aW5nIGF0IGRp ZmZlcmVudCANCj4+Pj4+IHVzZSBjYXNlcw0KPj4+Pj4gIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCBhbmQgY3VzdG9tZXJzLg0KPj4+Pj4NCj4+Pj4+ICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg VGhlIGZvcm1lciAobmV0d29yayBzbGljaW5nKSBpcyB0byBwcm92aWRlIHRoZSANCj4+Pj4+IGRl bWFuZGluZw0KPj4+Pj4gIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBzZXJ2aWNlcyB3aXRoIGd1 YXJhbnRlZWQgcGVyZm9ybWFuY2UgaW4gYSBjb252ZXJnZWQNCj4+Pj4gbmV0d29yaywNCj4+Pj4+ ICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgd2hpbGUgdGhlIGxhdHRlciAoc3dpdGNoaW5nIGJl dHdlZW4gbXVsdGlwbGUgDQo+Pj4+PiBwYXJhbGxlbGVkDQo+Pj4+PiAgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgIG5ldHdvcmtzKSBwcm92aWRlcyB0aGUgY3VzdG9tZXIgd2l0aCB0aGUgYmVzdCAN Cj4+Pj4+IHBlcmZvcm1hbmNlDQo+Pj4+PiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHRoYXQg aXMgYXZhaWxhYmxlIGFtb25nIHRob3NlIGNhbmRpZGF0ZXMuIFRvIG1lIHRoZSANCj4+Pj4+IGxh dHRlcg0KPj4+Pj4gIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBpcyBzdGlsbCBzb21lIGtpbmQg b2YgYmVzdCBlZmZvcnQsIGFuZCBhcyBUb2VybGVzcyANCj4+Pj4+IHNhaWQsIGl0DQo+Pj4+PiAg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGRlcGVuZHMgb24gdGhlIGRpdmVyc2l0eSB5b3UgY2Fu IGhhdmUgaW4gdGhlIA0KPj4+Pj4gbXVsdGlwbGUNCj4+Pj4gbmV0d29ya3MuDQo+Pj4+PiAgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIEFuZCBJIGFncmVlIHdpdGggU3Rld2FydCBvbiDigJx5b3Ug YWx3YXlzIHBheSBhIHByaWNlIA0KPj4+Pj4gZm9yDQo+Pj4+PiAgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgIGJldHRlciB0aGFuIGJlc3QgZWZmb3J0LuKAnQ0KPj4+Pj4NCj4+Pj4+ICDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgQmVzdCByZWdhcmRzLA0KPj4+Pj4NCj4+Pj4+ICDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgSmllDQo+Pj4+Pg0KPj4+Pj4gIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCAqRnJvbToqcnRnd2cgW21haWx0bzpydGd3Zy1ib3VuY2VzQGlldGYub3JnDQo+Pj4+PiAgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxtYWlsdG86cnRnd2ctYm91bmNlc0BpZXRmLm9yZz5dICpP biBCZWhhbGYgT2YgDQo+Pj4+PiAqUm9iZXJ0DQo+Pj4+IFJhc3p1aw0KPj4+Pj4gIMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCAqU2VudDoqIFdlZG5lc2RheSwgSnVseSAyNSwgMjAxOCA4OjI0IFBN DQo+Pj4+PiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICpUbzoqIEFjZWUgTGluZGVtIChhY2Vl KSA8YWNlZUBjaXNjby5jb20NCj4+Pj4+ICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPG1haWx0 bzphY2VlQGNpc2NvLmNvbT4+DQo+Pj4+PiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICpDYzoq IHJ0Z3dnQGlldGYub3JnIDxtYWlsdG86cnRnd2dAaWV0Zi5vcmc+DQo+Pj4+Pg0KPj4+Pj4NCj4+ Pj4+ICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgKlN1YmplY3Q6KiBSZTogVlBOIHNlY3VyaXR5 IHZzIFNELVdBTiBzZWN1cml0eQ0KPj4+Pj4NCj4+Pj4+ICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgVHJ1ZSBuZXR3b3JrIHNsaWNpbmcgZm9yIElQIG5ldHdvcmtzIG1lYW5zIGVpdGhlciANCj4+ Pj4+IHdhaXN0IG9mDQo+Pj4+PiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHJlc291cmNlcyBv ciB2ZXJ5IHN0cmljdCBtdWx0aS1sZXZlbCBxdWV1aW5nIGF0IGVhY2ggDQo+Pj4+PiBob3AgYW5k DQo+Pj4+PiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDEwMCUgaW5ncmVzcyB0cmFmZmljIHBv bGljaW5nLiBZZXQgd2hpbGUgdGhpcyBoYXMgYSANCj4+Pj4+IGNoYW5jZQ0KPj4+Pj4gIMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCB0byB3b3JrIGR1cmluZyBub3JtYWwgb3BlcmF0aW9uIGF0IHRo ZSB0aW1lIG9mIGV2ZW4gDQo+Pj4+PiByZWd1bGFyDQo+Pj4+PiAgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgIGZhaWx1cmVzIHRoaXMgYWxsIHByZXR0eSBtdWNoIG1lbHRzIGxpa2UgY2hlZXNlIG9u IGEgDQo+Pj4+PiBnb29kDQo+Pj4+PiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHNhbmR3aWNo Lg0KPj4+Pj4NCj4+Pj4+ICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgSXQgaXMgZ29pbmcgdG8g YmUgdmVyeSBpbnRlcmVzdGluZyB0byBjb21wYXJlIGhvdyANCj4+Pj4+IHNpbmdsZQ0KPj4+Pj4g IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBjb21wbGV4IHNsaWNlZCBuZXR3b3JrIGNvbXBhcmVz IGZvciBhbnkgZW5kIHRvIGVuZCANCj4+Pj4+IHJvYnVzdA0KPj4+Pj4gIMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCB0cmFuc3BvcnQgZnJvbSBOIG5vcm1hbCBzaW1wbGUgSVAgYmFja2JvbmVzIGFu ZCBlbmQgDQo+Pj4+PiB0bw0KPj4+PiBlbmQNCj4+Pj4+ICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgU0xBIGJhc2VkIG1pbGxpc2Vjb25kIHN3aXRjaCBvdmVyIGJldHdlZW4gb25lIGFuZCANCj4+ Pj4+IGFub3RoZXINCj4+Pj4gb24NCj4+Pj4+ICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgYSBw ZXIgZmxvdyBiYXNpcy4gQWxzbyBsZXQncyBub3RlIHRoZW4gd2hpbGUgdGhlIA0KPj4+Pj4gZm9y bWVyIGlzDQo+Pj4+PiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHN0aWxsIHRvIHRoZSBiZXN0 IG9mIG15IGtub3dsZWRnZSBhIGRyYWZ0IHRoZSBsYXR0ZXIgDQo+Pj4+PiBpcw0KPj4+Pj4gIMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBhbHJlYWR5IGRlcGxveWVkIGdsb2JhbGx5IGluIDEwMHMg b2YgbmV0d29ya3MuDQo+Pj4+Pg0KPj4+Pj4gIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBCZXN0 LA0KPj4+Pj4gIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBSLg0KPj4+Pj4NCj4+Pj4+ICDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgT24gV2VkLCBKdWwgMjUsIDIwMTggYXQgMToyMSBQTSwgQWNl ZSBMaW5kZW0gKGFjZWUpDQo+Pj4+PiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxhY2VlQGNp c2NvLmNvbSA8bWFpbHRvOmFjZWVAY2lzY28uY29tPj4gd3JvdGU6DQo+Pj4+Pg0KPj4+Pj4gIMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICpGcm9tOiAqcnRnd2cgPHJ0Z3dnLWJvdW5j ZXNAaWV0Zi5vcmcNCj4+Pj4+ICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8bWFp bHRvOnJ0Z3dnLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgDQo+Pj4+PiBTdGV3YXJ0 DQo+Pj4+PiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgQnJ5YW50IDxzdGV3YXJ0 LmJyeWFudEBnbWFpbC5jb20NCj4+Pj4+ICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCA8bWFpbHRvOnN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbT4+DQo+Pj4+PiAgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgKkRhdGU6ICpXZWRuZXNkYXksIEp1bHkgMjUsIDIwMTggYXQg NTo1NSBBTQ0KPj4+Pj4gIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICpUbzogKlJv YmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0DQo+Pj4+PiAgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgPG1haWx0bzpyb2JlcnRAcmFzenVrLm5ldD4+DQo+Pj4+PiAgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgKkNjOiAqUm91dGluZyBXRyA8cnRnd2dAaWV0Zi5v cmcNCj4+Pj4gPG1haWx0bzpydGd3Z0BpZXRmLm9yZz4+DQo+Pj4+PiAgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgKlN1YmplY3Q6ICpSZTogVlBOIHNlY3VyaXR5IHZzIFNELVdBTiBz ZWN1cml0eQ0KPj4+Pj4NCj4+Pj4+ICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBP biAyNS8wNy8yMDE4IDEwOjQwLCBSb2JlcnQgUmFzenVrIHdyb3RlOg0KPj4+Pj4NCj4+Pj4+ICDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIC8qIEFkanVzdGluZyB0aGUg c3ViamVjdCAuLi4gKi8NCj4+Pj4+DQo+Pj4+PiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCBIZWxsbw0KPj4+Pj4NCj4+Pj4+ICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIFN0ZXdhcnQsDQo+Pj4+Pg0KPj4+Pj4gIMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgWW91IGhhdmUgbWFkZSB0aGUgYmVsb3cgY29tbWVu dCBpbiB0aGUgb3RoZXINCj4+Pj4gdGhyZWFkDQo+Pj4+PiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCB3ZSBhcmUgaGF2aW5nOg0KPj4+Pj4NCj4+Pj4+ICDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgSW5kZWVkLCBJIHdvdWxk IGhhdmUgZXhwZWN0ZWQgdGhpcyB0byBiZSANCj4+Pj4+IG9uIGENCj4+Pj4+ICDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgc2VjdXJlIG5ldHdvcmsgb2Yg c29tZSBzb3J0IGVpdGhlciANCj4+Pj4+IHB1cmVseQ0KPj4+Pj4gIMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBwcml2YXRlIG9yIHNvbWUgZm9ybSBvZiBW UE4uIEhvd2V2ZXIsIEkgDQo+Pj4+PiBhbQ0KPj4+PiBzdXJlDQo+Pj4+PiAgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIEkgcmVhZCBpbiB5b3VyIHRleHQg dGhhdCB5b3Ugd2VyZQ0KPj4+Pj4gIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCBjb25zaWRlcmluZyB1c2luZyB0aGUgUHVibGljIEludGVybmV0IA0KPj4+ Pj4gbXVjaCBpbg0KPj4+Pj4gIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCB0aGUgd2F5IG9mIFNELVdBTi4NCj4+Pj4+DQo+Pj4+PiAgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBXb3VsZCB5b3UgbWluZCBhcyBleHRlbnNpdmVs eSBhcyB5b3UgY2FuIA0KPj4+Pj4gZXhwYW5kDQo+Pj4+IG9uDQo+Pj4+PiAgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB0aGUgYWJvdmUgc3RhdGVtZW50ID8NCj4+Pj4+ DQo+Pj4+PiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBTcGVjaWZp Y2FsbHkgb24gd2hhdCBiYXNpcyBkbyB5b3UgdHJlYXQgc2F5IA0KPj4+Pj4gTDJWUE4NCj4+Pj4g b3INCj4+Pj4+ICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIEwzVlBO IG9mIG5ha2VkIHVuZW5jcnlwdGVkIHBhY2tldHMgb2Z0ZW4NCj4+Pj4gdHJhdmVsaW5nDQo+Pj4+ PiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBvbiB0aGUgdmVyeSBz YW1lIGxpbmtzIGFzIHRoaXMgImJhZCIgDQo+Pj4+PiBJbnRlcm5ldA0KPj4+Pj4gIMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgdHJhZmZpYyB0byBiZSBldmVuIHNsaWdo dGx5IG1vcmUgc2VjdXJlIHRoZW4gDQo+Pj4+PiBJUFNFQw0KPj4+Pj4gIMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgb3IgRFRMUyBlbmNyeXB0ZWQgU0QtV0FOIGNhcnJp ZWQgZGF0YSB3aXRoDQo+Pj4+IGVuZHBvaW50cw0KPj4+Pj4gIMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgYmVpbmcgdGVybWluYXRlZCBpbiBwcml2YXRlIHN5c3RlbXMg Pw0KPj4+Pj4NCj4+Pj4+ICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IFRoeCwNCj4+Pj4+DQo+Pj4+PiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCBSb2JlcnQNCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgIFJvYmVydCwgSSB0aGluayB0aGF0IHlvdSBoYXZlIHRvIHRha2UgaXQgYXMgcmVh ZCANCj4+Pj4+IHRoYXQgYW4NCj4+Pj4+ICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCBhaXIgdHJhZmZpYyBjb250cm9sIFNvRiBzeXN0ZW0gaXMgZW5jcnlwdGluZyBpdHMNCj4+Pj4+ ICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBwYWNrZXRzLiBJZiBpdCBpcyBub3Qs IHRoZW4gaXQgaXMgY2xlYXJseSBub3QgDQo+Pj4+PiBmaXQgZm9yDQo+Pj4+PiAgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgcHVycG9zZS4NCj4+Pj4+DQo+Pj4+PiAgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgV2hhdCBjb25jZXJucyBtZSBpcyB0aGF0IGFuIGFpciB0 cmFmZmljIHN5c3RlbSANCj4+Pj4+IGlzIG9uZSBvZg0KPj4+Pj4gIMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIHRoZSBtb3N0LCBpZiBub3QgdGhlIG1vc3QsIGhpZ2ggcHJvZmlsZSB0 YXJnZXRzIA0KPj4+Pj4gaW4gY2l2aWwNCj4+Pj4+ICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCBzb2NpZXR5LiBZb3UgZ2V0IHJlbWluZGVkIG9mIHRoaXMgZWFjaCB0aW1lIHlvdSAN Cj4+Pj4+IHRyYXZlbA0KPj4+Pj4gIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHRv IElFVEYuDQo+Pj4+Pg0KPj4+Pj4gIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFRo ZSB0aGluZyBhYm91dCBzYWZldHkgb2YgZmxpZ2h0IHRyYWZmaWMgaXMgdGhhdCANCj4+Pj4+IGEN Cj4+Pj4+ICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBzdXN0YWluZWQgYW5kIGVm ZmVjdGl2ZSBERG9TIGF0dGFjayBoYXMgZ2xvYmFsIA0KPj4+Pj4gaW1wYWN0IGluDQo+Pj4+PiAg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgYSB3YXkgdGhhdCBmZXcgb3RoZXIgc3Vj aCBhdHRhY2tzIGhhdmUuDQo+Pj4+Pg0KPj4+Pj4gIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgIEEgVlBOIHN5c3RlbSBvdWdodCB0byBzdXN0YWluIHJlc2lzdGFuY2UgdG8gc3VjaCAN Cj4+Pj4+IGFuDQo+Pj4+PiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgYXR0YWNr IGJldHRlciB0aGFuIHRoZSBwcm9wb3NlZCBzeXN0ZW0gd2hpY2ggDQo+Pj4+PiB0cmVhdHMNCj4+ Pj4gdGhlDQo+Pj4+PiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgU29GIHRyYWZm aWMgdGhlIHNhbWUgYXMgcmVndWxhciB0cmFmZmljLg0KPj4+Pj4NCj4+Pj4+ICDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBJIGd1ZXNzIHlvdSBhcmUgbWFraW5nIGEgY2FzZSBmb3Ig eW91ciBuZXR3b3JrIA0KPj4+Pj4gc2xpY2luZw0KPj4+Pj4gIMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIHdvcmsg8J+YiQ0KPj4+Pj4NCj4+Pj4+ICDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCBBY2VlDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiAgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgLSBTdGV3YXJ0DQo+Pj4+Pg0KPj4+Pj4gIMKgwqDCoMKg wqDCoMKgwqAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+Pj4+ICDCoMKgwqDCoMKgwqDCoMKgIHJ0Z3dnIG1haWxpbmcgbGlzdA0KPj4+Pj4gIMKgwqDC oMKgwqDCoMKgwqAgcnRnd2dAaWV0Zi5vcmcgPG1haWx0bzpydGd3Z0BpZXRmLm9yZz4NCj4+Pj4+ ICDCoMKgwqDCoMKgwqDCoMKgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cnRnd2cNCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+PiBydGd3ZyBtYWlsaW5nIGxpc3QNCj4+Pj4+ IHJ0Z3dnQGlldGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3J0Z3dnDQo+Pj4+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+IFRlYXMgbWFpbGluZyBsaXN0DQo+PiBUZWFzQGlldGYub3JnDQo+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RlYXMNCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gcnRnd2cgbWFpbGluZyBsaXN0 DQo+IHJ0Z3dnQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcnRnd2cNCg0K From nobody Tue Aug 7 01:49:09 2018 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 962B3130EBE for ; Tue, 7 Aug 2018 01:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=KUerxtAT; dkim=pass (1024-bit key) header.d=ericsson.com header.b=C4B/lOsg 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 pNsqTHGnErbv for ; Tue, 7 Aug 2018 01:49:03 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E51DB130DDE for ; Tue, 7 Aug 2018 01:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1533631741; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=7VpI/4N9z/6xWQmkBWQvi9cOnT5boAhitVJWCQzl4gk=; b=KUerxtATavjH/AFf70lYmIMf7OOW9UQhtMvgOAfS6g5xTxoOkDyJMR+CCRu71h25 V5P9q/d5N1iCNQWKOg42H1x0braMwyZDDM7m9WfCoigk0gaeE/uN+yCokXgIvVSY ZkJ2mhsrMlXnLaIqv7zRayBJKfZViAhf7zXJTJc6P64=; X-AuditID: c1b4fb25-ee5789c000006cb9-64-5b695cfc3d1f Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 6B.74.27833.CFC596B5; Tue, 7 Aug 2018 10:49:00 +0200 (CEST) Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 7 Aug 2018 10:49:00 +0200 Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 7 Aug 2018 10:49:00 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JCoEuRFr4fxd4FnTBd0jdp3rkJsq53BjSY8NiUV1EUk=; b=C4B/lOsgrQORO5/2UKLVNDdamortOhH2/UCW+trfHQ5x77nWgcTBetJkbs/UrV5MgVazpya9tmwXr1LoxgPDFbBxBSLfeSHeYe5y1M9800jISMRTCY8r/5jxQFUVNrTt7D0rB41lDoQeoUrH7weWvPl6P2wWkNTmvmDPtK1KLQY= Received: from VI1PR07MB4270.eurprd07.prod.outlook.com (20.176.6.151) by VI1PR07MB4334.eurprd07.prod.outlook.com (20.176.7.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1038.14; Tue, 7 Aug 2018 08:48:58 +0000 Received: from VI1PR07MB4270.eurprd07.prod.outlook.com ([fe80::5a9:39a3:8a0e:778b]) by VI1PR07MB4270.eurprd07.prod.outlook.com ([fe80::5a9:39a3:8a0e:778b%5]) with mapi id 15.20.1038.019; Tue, 7 Aug 2018 08:48:57 +0000 From: Francesco Lazzeri To: Dieter Beller , Daniele Ceccarelli , Igor Bryskin , "sergio.belotti@nokia.com" , "teas@ietf.org" , "teas-chairs@ietf.org" CC: "Karthik.Sethuraman@necam.com" , "michael.scharf@nokia.com" , "vlopez@tid.es" , "oscar.gonzalezdedios@telefonica.com" , Carlo Perocchio , Leeyoung , "ansha@google.com" , "ricard.vilalta@cttc.es" , "shiyan49@chinaunicom.cn" , Italo Busi Thread-Topic: [Teas] draft-ietf-teas-yang-path-computation-02 : path computation stateless RPC attributes Thread-Index: AdQkvNfVJK0UViBSSaelX1MjWeaTXAACJLZwAAqffwAAIJt5cAACfTsAABBT4QAB8kedMA== Date: Tue, 7 Aug 2018 08:48:57 +0000 Message-ID: References: <6855a283-6a83-7278-22ec-ec5c1dd54f48@nokia.com> In-Reply-To: <6855a283-6a83-7278-22ec-ec5c1dd54f48@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesco.lazzeri@ericsson.com; x-originating-ip: [151.0.200.100] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB4334; 6:oVsKMVLUm55NlG4mxFUPkbcLOVFG4wYixS0inub4c3wvFf/COJ4oxeJpjUr/AVb5MvdfkCEArLKD2NQ+xrey2vTgVr1v1Ybg5ZiisC6Xe4X998517/ECEfXPFqLdqfLc2KDG0bBSXnrNK9CfYxqTNFqlmBkyicHbk+6eCIVU1xaMy/VGCg2MhXd5s9f6xKmrfOEWVXJLxDUjyDVxlhA3EFQj5AHEWEgaj1W7OJABTmI89CeRLU1tYMEfQDiNISQbIwc5rbG8R9zRA/Xzv9up3gpgVZW+o5Q9njbz4RqmjxeZq8K6nWEKIwhvOfKZd5LOMbnlLC3onvcPOdtTWtlzzsOZadw8+V0SPcoao+G41NnK+CIaKTrZk43hc7mnuLOTMmUmUslvjG3E8xURFQTwLwtFKlJFEx+ICn8ZkNqadU42veoNUA92Jux4mlMYbYJ7Pyqe7ZRvYP2goreumbPIjw==; 5:7st6CYBYc+lkZxoYe0ekb7wnuJ33CHZ/I2sfg5H6O/bYRG3DZcTClaMygptjKJJ12PgLBtZVvAcs7FIOQ6+ynvk5lCAkRRlY4+FSSqOzk+/Ktm1KfQ+HsDnV1ViZUtq3PWfHlK39LTSEhj7D3wpbJG8xOM9L2IDNxLsat6jyxlY=; 7:wbamcDmFAqOKERsTwZgEY9s/NwxIDe4iA7GCzTBuqDlJ8VX1U58t0rs4mJNYsSPK/G0w+K4djiEna/nfvEkDJjAxDjW21JqQAK1chaRQaJzRrubOMQtLn3qzloNaDjwSMQvx9vAXMavIUBe2NuUAt+M7NkbhREdvDABmDc1cLIoNnjT2saK+O7L5U8SoF+lGsy05uPfzGPU33+y3rx/szD03DKLkTEIDcSlOgA4drOlwzStHtrRwQ0tlXWSF56z8 x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(376002)(346002)(366004)(39860400002)(136003)(396003)(189003)(53754006)(199004)(7416002)(790700001)(3846002)(6116002)(11346002)(966005)(53936002)(14454004)(8676002)(8936002)(81156014)(81166006)(68736007)(106356001)(105586002)(6246003)(2501003)(53946003)(446003)(5660300001)(478600001)(6436002)(4326008)(256004)(25786009)(5250100002)(14444005)(236005)(6506007)(53546011)(93886005)(9686003)(6306002)(54896002)(229853002)(7736002)(55016002)(102836004)(99286004)(486006)(74316002)(2906002)(66066001)(76176011)(476003)(33656002)(7696005)(316002)(296002)(54906003)(110136005)(44832011)(606006)(86362001)(97736004)(26005)(186003)(2900100001)(2201001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB4334; H:VI1PR07MB4270.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-office365-filtering-correlation-id: 742ee17b-78f9-4739-183e-08d5fc429ce2 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:VI1PR07MB4334; x-ms-traffictypediagnostic: VI1PR07MB4334: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(28532068793085)(40392960112811)(158342451672863)(166708455590820)(50582790962513)(82608151540597)(109105607167333)(195916259791689)(211936372134217); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231311)(944501410)(52105095)(3002001)(10201501046)(149027)(150027)(6041310)(20161123564045)(20161123560045)(201703131423095)(201703031522075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:VI1PR07MB4334; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB4334; x-forefront-prvs: 0757EEBDCA received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: NyQy5DTduHbi7ezt3tzB6w23MNUvH+l1r7OWGTDPKq9ePvu64JDyV43hf7pu0wolRovK6Vb+HW79h3VekS3cah30b311uO2Q/xRCnuWam2KKoouQToQPBComPYen9q7eJAFVhho8b4Njvpn+ZRycjlhWJUQyl4JnkkRIutZxtnCVyDYqpCT6YFOv3TLtuHwdvCOWcB9IMI7/B7unOsqCdV8U2EDd2rfDUB3m6DuarL3bSJr0ZEnq7wt07/pAtWPvNzgj4ASHhOlWRdpSp91YvqLTUzf2aOTHqGaKnY91EaCw5CQmtON6MPqgKSD6kvNzT4ME1PINH4/VWr+UJZdOoPtW48cF7psTrME1leyfEf8= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR07MB4270D252C3B586F62D1C91C196270VI1PR07MB4270eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 742ee17b-78f9-4739-183e-08d5fc429ce2 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2018 08:48:57.1726 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4334 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRjG+c45Ozuaq6+l9WZINbLI0DQDT1iZVHj+ESREQoVaedClTtmW ZVSIaJcpTElNLW9zmoqY6UqpTFx2s4ulIbW0vHUxtUzyUsuR21nQf8/zPj+e93vhY0iplnZn FEoNr1LKE2S0M1V0sOWk959oRZRvzeVANnd2XMQ2GPopduGJH7swdUfEtmXmitiC0v3sr1de 7FjZJ8TqrYOIHZ7TUmzx++9iNr3kNsFmzrdSbKF2356lXN5kNuIyH5ynuPKm41xG56SIMxh+ EVxrzgTBDZh7CO6iheRGF4xkmFOk884YPkGRwqu27j7sHDddmk4n97WSJ0sqLVQaqk8jtciJ AbwdisbrKC1yZqT4AYJ3sz0OM4Og6/JzsWAqCZhpGyVshsI5JDRkDyMh0REw3N/kwD4gGOrT 0bZmGrPwu/OKvcwVFxDw9tpD2mZIPEfCvL6FslEr8DG4WDdF2LQrjoeflfcXIWZRR8ALfbht TOEN8KW70V4qwdHwtaLBsbqFBN1Ns73HCe8Cc+a0HUJ4Jcx11ds7SbwKzKNlhHArBsPdbsfd bjA2YhUJvBxuGIodzHp4WfdPe0BPWZZ9GeB7Ypgc0SMh8INHte2kEDyjoe1WtqM1FEqMk7QQ PEJgLW2hhcALyp9miAQdD2VVC2IB6kaQ1tuGcpBv8X/PFXQSXNCbqGL73cvhSdEoJcx94E1+ Hi3oLVBdMU4K2hsKrSbq/3k5EtchNzWvPpIYu83fh1cpjqrVSUofJa9pQos/tMNo8WxFvRPB JoQZJHORtIcooqQieYo6NdGEgCFlrhKJIi5KKomRp57iVUmHVMcTeLUJrWEo2SrJUEBzpBTH yjV8PM8n86p/KcE4uachn+tBQ6F+WuPjmZgu3UbaFP62eYd3aOAmS9+PkLHT1uy5pVcGkpmr ypqq3L2vjY2xIWHrOurzP3qMxDVPWc4yLqKqrCBziebzvc6Cn96X/gQcGDknDSj1d5dXG7NO eKwJli6r2YzPwZIL7/wjChukunDN5tr3nmsHo6rOFE5/W50ko9Rxcj8vUqWW/wVD0SvHnQMA AA== Archived-At: Subject: Re: [Teas] draft-ietf-teas-yang-path-computation-02 : path computation stateless RPC attributes X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 08:49:09 -0000 --_000_VI1PR07MB4270D252C3B586F62D1C91C196270VI1PR07MB4270eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for your response Dieter, and sorry for the late reply. I actually e= xpected to find a lot of additional comments and some responses to the poll= . Instead, it seems that there isn't a great interest behind this issue, as I= haven't seen any other opinion since a while. Maybe summer vacations ? I hope we, as co-authors/contributors , can receive additional feedbacks to= understand how to proceed. BR Francesco From: Dieter Beller Sent: 27 July, 2018 5:22 PM To: Francesco Lazzeri ; Daniele Ceccarelli = ; Igor Bryskin ; = sergio.belotti@nokia.com; teas@ietf.org; teas-chairs@ietf.org Cc: Karthik.Sethuraman@necam.com; michael.scharf@nokia.com; vlopez@tid.es; = oscar.gonzalezdedios@telefonica.com; Carlo Perocchio ; Leeyoung ; ansha@google.com; ricard.vilalta@= cttc.es; shiyan49@chinaunicom.cn; Italo Busi Subject: Re: [Teas] draft-ietf-teas-yang-path-computation-02 : path computa= tion stateless RPC attributes Hi all, I concur with the comments from Francesco and Daniele below as well as with= those from Michael. We discussed this issue at length in Montreal after the CCAMP session and I= would like to emphasize again that I am having reservations about policies= being applied by a path computation engine based on attributes that are provided = as input to path computation, which have absolutely nothing to do with poli= cy rules as they were defined for totally other purposes! We called that hidde= n policies in our discussion. Thanks, Dieter On 27.07.2018 10:16, Francesco Lazzeri wrote: I believe that the main point for deciding whether all the parameters (incl= uding name, description and so on) are needed or not for stateless path com= putation is the adoption of policies. When I think about policies, I go to the definitions present in RFC3060, wh= ere policy information model is described. According to 3060, basically policies are a (set of) rules where each rule = is defined by enabling conditions (boolean expressions that "enable" the po= licy actions as soon as they become true) and policy actions (the behavior = of the policy). If we introduce this concept in path computation we could think for example= to create two policies for a given domain D: * The first one is enabled when the tunnel description contains the str= ing "igor", and the relevant action is avoiding the node X inside the relev= ant domain. * The second one is enabled when the tunnel description con contains th= e string "francesco", and the levant action is avoiding the node Y inside t= he relevant domain. Let suppose we don't want to use stateless path computation (e.g. the domai= n is "white", so we have full topology information about it, or, if domain = is "black" or "gray", we just use its abstract connectivity). We are asking for a new tunnel with description "igor". Assuming the client (MDSC) knows nothing about those policies, it does path= computation end-to-end using the topology information it collected, and f= ind that the best end-to-end path passing through D. This path could well use node X: MDSC doesn't care, as it doesn't know that= there is a policy installed in D the will ask to avoid that node. When the end-to-end path needs to be deployed the tunnel requested on D wil= l be created using a path avoding X, because the path creation is done by t= he controller of the domain D which is aware of and enforces that policy. But, being this path different from the one computed during the end-to-end = path computation, it could have different te-cost, igp-cost, latency and so= on, leading to end-to-end figures possibly not in compliance with the end-= to-end constraints. In my view, this is not acceptable. There are two ways to overcome this issue: * Requesting path computation to the domain D also during end-to-end pa= th computation. This is stateless path computation actually, and means that= abstract topology is useless (as we actully are renouncing to use it). * Exposing information about policies to the MDSC (or the client reques= ting end-to-end path computation). But this is still not enough: abstract t= opology should be also enhanced in order to take into account the possible = policies enforced. In this example we should have one (or more) abstract connectivity informat= ion for ingress-egress of D in case neither "igor" or "francesco" policies = are enforced, "igor" is enforced, "francesco" is enforced, "igor" and "fran= cesco" are enforced at once (e.g. asking a path having name "igor and franc= esco like ietf"). In this case policy information known to MDSC could be limited to the enabl= ing conditions, which should also be referred by the relevant abstract conn= ectivity, of course, so MDSC can select the right connectivity information. In the past we already had discussions about the scalability of the abstrac= t connectivity model, and basically the stateful model was born because thi= s very reason. The presence of policies makes the scalability issue even mo= re evident, multiplying each abstract link times the number of the combinat= ions of the installed policies in the domain. So, now we can: * Renounce at all to use policies (or provide for them a definition dif= ferent from RFC3060, please suggest). In this case not all the attributes p= resent in ietf-te are managed by ietf-te-path-computation are needed. * Use the policies and use only ietf-te-path-computation; this lead to = a deep revision of the entire ietf model of the traffic and topology, becau= se abstract connectivity information is no longer needed. * Go ahead with ietf-te plus these policies and face either wrong resul= ts or the "dragon" of scalability. My 2 cents Francesco From: Daniele Ceccarelli Sent: 27 July, 2018 8:29 AM To: Igor Bryskin ;= sergio.belotti@nokia.com; teas@ietf.org; teas-chairs@ietf.org Cc: Francesco Lazzeri ; Karthik.Sethuraman@necam.com; michael.scharf@nokia.com; vlop= ez@tid.es; oscar.gonzalezdedios@telefonica.com; dieter.beller@nokia.com; Carlo Perocchio ; Leeyoung ; ansha@google.com; ricard.vilalta@c= ttc.es; shiyan49@chinaunicom.cn; Italo Busi Subject: RE: [Teas] draft-ietf-teas-yang-path-computation-02 : path computa= tion stateless RPC attributes Hi Igor, what you are describing is just one of the use cases. * Statefull path computation: I want the request/response to be guarant= eed along the same path returned via path computation response. * Stateless path computation: I don't really care about the path, I jus= t want to know that a path exists with given characteristics between A and = B. Here we're talking about stateless path computation. As I said before if a = H-PCE needs to find the best path across multiple domains and there are dif= ferent links/nodes that allow going from one domain to the other, the numbe= r of iterations between the H-PCE and the various PCE is huge, hence it sho= uld be very simple and in 99% of the cases who cares about an intra domain = path? The only thing that cares is that between two border nodes there are = X Gbps with given TE characteristics. Cheers Daniele From: Igor Bryskin = > Sent: gioved=EC 26 luglio 2018 16:50 To: Daniele Ceccarelli >; sergio.belotti@nokia.com; teas@ietf.org; teas-chairs@ietf.org Cc: Francesco Lazzeri >; Karthik.Sethuraman@necam.com; michael.scharf@nokia.com; vlop= ez@tid.es; oscar.gonzalezdedios@telefonica.com; dieter.beller@nokia.com; Carlo Perocchio >; Leeyoung >; ansha@google.com; ricard.vilalta@c= ttc.es; shiyan49@chinaunicom.cn; Italo Busi > Subject: Re: [Teas] draft-ietf-teas-yang-path-computation-02 : path computa= tion stateless RPC attributes Daniele, What is the point of path computation request / response if it can not be g= uaranteed, generally speaking, that a TE tunnel configured on a given netwo= rk will take the same path as returned via path computation response? The policies installed in the network are not expected to be known to all c= lients, but the policies could significantly influence on tunnel routing. All we are saying is that when the same information is passed for tunnel co= nfiguration and in path computation request for the tunnel in questuon, th= ere will be no reason for a path computation return one path, while the act= ual tunnel, when requested, taking a different one. Note also that all extra parameters we are talking about are optional and c= ould be omitted in path computation RPC if it is known, for example, from e= xperience that they do not affect the actual tunnel routing. Igor From:Daniele Ceccarelli To:Belotti, Sergio (Nokia - IT/Vimercate),TEAS WG,teas-chairs@ietf.org, Cc:Francesco Lazzeri,Sethuraman, Karthik,Scharf, Michael (Nokia - DE/Stuttg= art),Victor Lopez,OSCAR GONZALEZ DE DIOS (oscar.gonzalezdedios@telefonica.c= om),Beller, Dieter (N= okia - DE/Stuttgart),Carlo Perocchio,Leeyoung,Anurag Sharma (ansha@google.c= om),Ricard Vilalta,shiyan49@chinaunicom.= cn,Italo Busi, Date:2018-07-26 05:54:16 Subject:Re: [Teas] draft-ietf-teas-yang-path-computation-02 : path computat= ion stateless RPC attributes Hi, >The question is: are there benefits in including in input of Path Computat= ion Request RPC also te-tunnel attributes without any foreseen recommended = usage by path computation engine? Absolutely no. Main reasons: 1. Policies might not be shared with the MDSC 2. Policies may be different from PNC to PNC 3. A high number of path computation results will be discarded (stateles= s path computation is needed also by the MDSC to understand what are the di= fferent options to get from a node in a domain to another node in a differe= nt domain and possibly through a number of other domains...hence a high num= ber of comination) 4. Last but not least simplification. BR Daniele From: Belotti, Sergio (Nokia - IT/Vimercate) > Sent: gioved=EC 26 luglio 2018 11:00 To: TEAS WG >; teas-chairs@ietf.org Cc: Italo Busi >; Belot= ti, Sergio (Nokia - IT/Vimercate) >; Francesco Lazzeri >; Carlo Perocchio >; Scharf, Michael (Nokia - DE/S= tuttgart) >; Anur= ag Sharma (ansha@google.com) >; ylee@huawei.com; shiyan49@c= hinaunicom.cn; Ricard Vilalta >; OSCAR GONZALEZ DE DIOS (oscar.g= onzalezdedios@telefonica.com) <= oscar.gonzalezdedios@telefonica.com>; Victor Lopez >; Daniele Ceccarel= li = >; Beller, Dieter (Nokia - DE/Stuttgart) >; Sethuraman, Karthik > Subject: draft-ietf-teas-yang-path-computation-02 : path computation statel= ess RPC attributes Hi all, After the discussion held during the last TEAS WG session in IETF102 and so= me offline talks, we are trying to summarize the questions that we need to = answer to resolve the open issue 31 (reference for background https://githu= b.com/rvilalta/ietf-te-path-computation/issues/31) . The question is: are there benefits in including in input of Path Computati= on Request RPC also te-tunnel attributes without any foreseen recommended u= sage by path computation engine? For example this is the case of administra= tion attributes such as 'tunnel description' or of those attributes that ar= e relevant only for the provisioning phase e.g provisioning-state... Please= consider that the question is in the scope of a 'Stateless-Path-Computatio= n' service: no state or data is saved by PCE after RPC output is returned t= o the client. One of the main use case for the Path Computation RPC design is to support = multi domain path computation. In this case the MDSC (the RPC client) addre= sses to a PNC (the RPC server) a request to compute a path within the PNC n= ative/controlled topology during the quest for a multi-domain path at a giv= en time T1; at a later time T2 (once, for example, the e2e path is identifi= ed) MDSC requests southbound to PNC per domain Tunnel setup (the segments o= f the multi-domain tunnel) with either the same or different metrics and co= nstraints (MDSC implementation decision), to guarantee that the PNC would s= etup a path equivalent or better than the one computed at time T1. Example: the MDSC computes a multi-domain end-to-end path between points A = and Z and selects a path having te-metric 100. The path A-Z passes through = the domain controlled by PNC X, entering in B and exiting in C, for which= path computation RPC has returned a B-C path with te-metric 20. When askin= g PNC X to setup the path B-C, a constraint on te-metric must be provided = in order to avoid PNC X finding a suitable path satisfying all the other co= nstraints of the end-to-end path but with te-metric higher than 20. If a di= fferent path is found with a metric < 20, that's fine. So, it's not essenti= al that the same identical path is produced at the second path computation.= The only requirement is on its metrics. Depending on the abstraction level applied by the domain controller the cl= ient may never know the actual computed path: the only important requiremen= t is that the path metrics and constraints are met. Therefore it is not necessary to guaranteed that the path setup at time T2 = is exactly the same as the path computed at time T1 but only that it has th= e same or better metrics. Regarding the policies, it has been said in the ietf meeting (see the relev= ant transcript) that they allow a "private" behavior of the server triggere= d by a condition depending possibly on any attribute of the tunnel request.= This actually prevents a client application to perform autonomously the en= d-to-end path computation (e.g. using detailed connectivity matrix), as it = doesn't know how each domain will behave when recomputing the tunnel for de= ployment (and so applying policies the client doesn't know and which could = be even different for different domains). In order to prevent this, policies should be explicitly shared with the cli= ents, and be included in the detailed connectivity matrix information expos= ed by each domain to take into account not only the possible alternative pa= th computation parameters, but also all the possible combinations of applic= able policies. The client shall then select the suitable detailed connectiv= ity matrix taking into account both the path computation parameters AND the= applicable policies. When such policy attributes are defined, they will be included in the path = computation RPC. Italo and Sergio (on behalf of co-authors/contributors) Sergio Belotti Senior System Engineer and Standardization Architect IP/Optical Networks, Optics BU Nokia M: +39-335761776 Via Energy Park, 20871 Vimercate (MB) , Italy sergio.belotti@nokia.com --_000_VI1PR07MB4270D252C3B586F62D1C91C196270VI1PR07MB4270eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks for your res= ponse Dieter, and sorry for the late reply. I actually expected to find a l= ot of additional comments and some responses to the poll.

Instead, it seems t= hat there isn’t a great interest behind this issue, as I haven’= t seen any other opinion since a while. Maybe summer vacations ?=

 

I hope we, as co-authors/contributors , can receive = additional feedbacks to understand how to proceed.

 

BR

Francesco

 

 

From:= Dieter Beller <Dieter.Beller@nokia.com= >
Sent: 27 July, 2018 5:22 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Daniel= e Ceccarelli <daniele.ceccarelli@ericsson.com>; Igor Bryskin <Igor= .Bryskin@huawei.com>; sergio.belotti@nokia.com; teas@ietf.org; teas-chai= rs@ietf.org
Cc: Karthik.Sethuraman@necam.com; michael.scharf@nokia.com; vlopez@t= id.es; oscar.gonzalezdedios@telefonica.com; Carlo Perocchio <carlo.peroc= chio@ericsson.com>; Leeyoung <leeyoung@huawei.com>; ansha@google.c= om; ricard.vilalta@cttc.es; shiyan49@chinaunicom.cn; Italo Busi <Italo.Busi@huawei.com>
Subject: Re: [Teas] draft-ietf-teas-yang-path-computation-02 : path = computation stateless RPC attributes

 

Hi all,

I concur with the comments from Francesco and Daniele below as well as with= those from Michael.

We discussed this issue at length in Montreal after the CCAMP session and I= would like to emphasize again that I am having reservations about policies= being
applied by a path computation engine based on attributes that are provided = as input to path computation, which have absolutely nothing to do with poli= cy
rules as they were defined for totally other purposes! We called that hidde= n policies in our discussion.


Thanks,
Dieter

On 27.07.2018 10:16, Francesco Lazzeri wrote:

I believe that the main point for deciding whether a= ll the parameters (including name, description and so on) are needed or not= for stateless path computation is the adoption of policies.

When I think about policies, I go to the definitions= present in RFC3060, where policy information model is described.

According to 3060, basically policies are a (set of)= rules where each rule is defined by enabling conditions (boolean expressio= ns that “enable” the policy actions as soon as they become true= ) and policy actions (the behavior of the policy).

If we introduce this concept in path computation we = could think for example to create two policies for a given domain D:

 

  • The first one is enabled when the tunnel description contains the str= ing “igor”, and the relevant action is avoiding the node X insi= de the relevant domain.
  • The second one is enabled when= the tunnel description con contains the string “francesco”, an= d the levant action is avoiding the node Y inside the relevant domain.=

 

Let suppose we don’t want to use stateless pat= h computation (e.g. the domain is “white”, so we have full topo= logy information about it, or, if domain is “black” or “g= ray”,  we just use its abstract connectivity).

We are asking for a new tunnel with description R= 20;igor”.

Assuming the client (MDSC) knows nothing about those= policies, it does path computation end-to-end using the topology informati= on it collected,  and find that the best end-to-end path passing throu= gh D.

This path could well use node X: MDSC doesn’t = care, as it doesn’t know that there is a policy installed in D the wi= ll ask to avoid that node.

When the end-to-end path needs to be deployed the tu= nnel requested on D will be created using a path avoding X, because the pat= h creation is done by the controller of the domain D which is aware of and = enforces that policy.  

But, being this path different from the one computed= during the end-to-end path computation, it could have different te-cost, i= gp-cost, latency and so on, leading to end-to-end figures possibly not in c= ompliance with the end-to-end constraints.

In my view, this is not acceptable.

 

There are two ways to overcome this issue:

 

  • Requesting path computation to the domain D also during end-to-end pa= th computation. This is stateless path computation actually, and means that= abstract topology is useless (as we actully are renouncing to use it).
  • Exposing informati= on about policies to the MDSC (or the client requesting end-to-end path com= putation). But this is still not enough: abstract topology should be also e= nhanced in order to take into account the possible policies enforced.
    In this example we should have one (or more) abstract connectivity informat= ion for ingress-egress of D in case neither “igor” or “fr= ancesco” policies are enforced, “igor” is enforced, ̶= 0;francesco” is enforced, “igor” and “francescoR= 21; are enforced at once (e.g. asking a path having name “igor and francesco like ietf”). In this case policy information known to MDSC could be limited to the enabl= ing conditions, which should also be referred by the relevant abstract conn= ectivity, of course, so MDSC can select the right connectivity information.=

 

In the past we already had discussions about the sca= lability of the abstract connectivity model, and basically the stateful mod= el was born because this very reason. The presence of policies makes the sc= alability issue even more evident, multiplying each abstract link times the number of the combinations of the= installed policies in the domain.

 

So, now we can:

 

  • Renounce at all to use policies (or provide for them a definition dif= ferent from RFC3060, please suggest). In this case not all the attributes p= resent in ietf-te are managed by ietf-te-path-computation are needed.
  • Use the policies and use only ietf-te-pat= h-computation; this lead to a deep revision of the entire ietf model of the= traffic and topology, because abstract connectivity information is no longer needed.
  • Go ahead with ietf-te plus the= se policies and face either wrong results or the “dragon” of sc= alability.

 

My 2 cents

Francesco

 

 

From: Daniele Ceccarelli
Sent: 27 July, 2018 8:29 AM
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; sergio.belotti@nokia.com; <= a href=3D"mailto:teas@ietf.org"> teas@ietf.org; teas-chairs@ietf= .org
Cc: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Karthik.Sethuraman@necam.co= m; michael.scharf@nokia.com; vlopez@tid.e= s; oscar.gonzalezdedios@telefonica.com; dieter.beller@nokia.com; Carlo Perocchio <carlo.perocchio@ericsson.com>; Leeyoung <leeyoung@huawei.com>; ansha@= google.com; ricard.vilalta@cttc.es; shiyan49@chinaunicom.cn; Italo Busi <Italo.Busi@huawei.com>
Subject: RE: [Teas] draft-ietf-teas-yang-path-computation-02 : path = computation stateless RPC attributes

 

Hi Igor,

 

what you are describing is just one of the use cases= .

 

  • Statefull path computation: I want the request/response to be guarant= eed along the same path returned via path computation response.<= /li>
  • Stateless path computation: I don’t really care about the p= ath, I just want to know that a path exists with given characteristics betw= een A and B.

 

Here we’re talking about stateless path comput= ation. As I said before if a H-PCE needs to find the best path across multi= ple domains and there are different links/nodes that allow going from one d= omain to the other, the number of iterations between the H-PCE and the various PCE is huge, hence it should be very sim= ple and in 99% of the cases who cares about an intra domain path? The only = thing that cares is that between two border nodes there are X Gbps with giv= en TE characteristics.

 

Cheers

Daniele 

 

From: Igor Bryskin <Igor.Bryskin@huawei.com>
Sent: gioved=EC 26 luglio 2018 16:50
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; sergio.belotti@nokia.com; <= a href=3D"mailto:teas@ietf.org"> teas@ietf.org; teas-chairs@ietf= .org
Cc: Francesco Lazzeri <francesco.lazzeri@ericsson.com>; Karthik.Sethuraman@necam.co= m; michael.scharf@nokia.com; vlopez@tid.e= s; oscar.gonzalezdedios@telefonica.com; dieter.beller@nokia.com; Carlo Perocchio <carlo.perocchio@ericsson.com>; Leeyoung <leeyoung@huawei.com>; ansha@google.com; ricard.vilalta@cttc.es; shiy= an49@chinaunicom.cn; Italo Busi <Italo.Busi@huawei.com>
Subject: Re: [Teas] draft-ietf-teas-yang-path-computation-02 : path = computation stateless RPC attributes

 

Daniele,
What is the point of path computation request / response if it can not be g= uaranteed, generally speaking, that a TE tunnel configured on a given netwo= rk will take the same path as returned via path computation response?
The policies installed in the network are not expected to be known to all c= lients, but the policies could significantly  influence  on tunne= l routing.
All we are saying is that when the same information is passed for tunnel co= nfiguration and in path computation request for the tunnel  in questuo= n, there will be no reason for a path computation return one path, while th= e actual tunnel, when requested,  taking  a different one.
Note also that all extra parameters we are talking about are optional and c= ould be omitted in path computation RPC if it is known, for example, from e= xperience that they do not affect the actual tunnel routing.

Igor

From:Daniele Ceccarelli=

To:Belotti, Sergio (Nokia - IT/Vimercate),TEAS W= G,teas-chairs@ietf.org,

Cc:Francesco Lazzeri,Sethuraman, Karthik,Scharf,= Michael (Nokia - DE/Stuttgart),Victor Lopez,OSCAR GONZALEZ DE DIOS (oscar.gonzalez= dedios@telefonica.com),Beller, Dieter (Nokia - DE/Stuttgart),Carlo Perocchio,Leeyoung,Anurag Sharma (ansha@google.com)= ,Ricard Vilalta,shiyan49@chinaunicom.cn,Italo Busi,

Date:2018-07-26 05:54:16

Subject:Re: [Teas] draft-ietf-teas-yang-path-computation-02 : path compu= tation stateless RPC attributes

 

Hi,

 

>The question is: are there benefits in including i= n input of Path Computation Request RPC also te-tunnel attributes without a= ny foreseen recommended usage by path computation engine?

 

Absolutely no.

 

Main reasons:

  1. Policies might not be shared with the MDSC
  2. Pol= icies may be different from PNC to PNC
  3. A high number o= f path computation results will be discarded (stateless path computation is= needed also by the MDSC to understand what are the different options to ge= t from a node in a domain to another node in a different domain and possibly through a numb= er of other domains…hence a high number of comination)
  4. Last but not least simplification.

 

BR
Daniele 

 

From: Belotti, Sergio (Nokia - IT/Vimercate) = <sergio.belotti@nokia..com<= /a>>
Sent: gioved=EC 26 luglio 2018 11:00
To: TEAS WG <teas@ietf.org&g= t;; teas-chairs@ietf.org
Cc: Italo Busi <Italo.Bu= si@huawei.com>; Belotti, Sergio (Nokia - IT/Vimercate) <sergio.belotti@nokia.com>; Fran= cesco Lazzeri <frances= co.lazzeri@ericsson.com>; Carlo Perocchio <carlo.= perocchio@ericsson.com>; Scharf, Michael (Nokia - DE/Stuttgart) <= michael.scharf@nokia.com>= ;; Anurag Sharma (ansha@google.com) <ansha@google.com>; ylee@huawei.com; shiyan49@ch= inaunicom.cn; Ricard Vilalta <ricard.vilalta@cttc.es>; OSCAR GONZALEZ DE DIOS (oscar.gonzalezdedios@telefonica.com= ) <oscar.gonzalezd= edios@telefonica.com>; Victor Lopez <vlopez@tid.es>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; Beller, Dieter (Nokia - DE/Stuttgart) <dieter.beller@nokia.com>; Sethuraman, Karthik <Karthik.Sethuraman@necam.com&g= t;
Subject: draft-ietf-teas-yang-path-computation-02 : path computation= stateless RPC attributes

 

Hi all,=

 <= /p>

After the discussion held= during the last TEAS WG session in IETF102 and some offline talks, we are = trying to summarize the questions that we need to answer to resolve the open issue 31 (reference for background https:/= /github.com/rvilalta/ietf-te-path-computation/issues/31) .

 <= /p>

The question is: are ther= e benefits in including in input of Path Computation Request RPC also te-tu= nnel attributes without any foreseen recommended usage by path computation engine? For example this is the case of administ= ration attributes such as 'tunnel description' or of those attributes that = are relevant only for the provisioning phase e.g provisioning-state... Plea= se consider that the question is in the scope of a 'Stateless-Path-Computation' service: no state or data i= s saved by PCE after RPC output is returned to the client. 

 <= /p>

One of the main use case = for the Path Computation RPC design is to support multi domain path computa= tion. In this case the MDSC (the RPC client) addresses to a PNC (the RPC server) a request to compute a path within the PNC nativ= e/controlled topology during the quest for a multi-domain path at a given t= ime T1; at a later time T2 (once, for example, the e2e path is identified) = MDSC requests southbound to PNC per domain Tunnel setup (the segments of the multi-domain tunnel) with eit= her the same or different metrics and constraints (MDSC implementation deci= sion), to guarantee that the PNC would setup a path equivalent or better th= an the one computed at time T1.

 <= /p>

Example: the MDSC compute= s a multi-domain end-to-end path between points A and Z and selects a path = having te-metric 100. The path A-Z passes through the  domain controlled by PNC  X, entering in B and exiting in C= , for which path computation RPC has returned a B-C path with te-metric 20.= When asking  PNC X to setup the path B-C, a constraint on te-metric m= ust be provided in order to avoid PNC X finding a suitable path satisfying all the other constraints of the end-to-end pat= h but with te-metric higher than 20. If a different path is found with a me= tric < 20, that's fine. So, it's not essential that the same identical p= ath is produced at the second path computation. The only requirement is on its metrics.

 <= /p>

 Depending on the ab= straction level applied by the domain controller the client may never know = the actual computed path: the only important requirement is that the path metrics and constraints are met.

Therefore it is not neces= sary to guaranteed that the path setup at time T2 is exactly the same as th= e path computed at time T1 but only that it has the same or better metrics.

 <= /p>

Regarding the policies, i= t has been said in the ietf meeting (see the relevant transcript) that they= allow a "private" behavior of the server triggered by a condition depending possibly on any attribute of the tunnel request. = This actually prevents a client application to perform autonomously the end= -to-end path computation (e.g. using detailed connectivity matrix), as it d= oesn't know how each domain will behave when recomputing the tunnel for deployment (and so applying policie= s the client doesn't know and which could be even different for different d= omains). 

In order to prevent this,= policies should be explicitly shared with the clients, and be included in = the detailed connectivity matrix information exposed by each domain to take into account not only the possible alternative path= computation parameters, but also all the possible combinations of applicab= le policies. The client shall then select the suitable detailed connectivit= y matrix taking into account both the path computation parameters AND the applicable policies. <= o:p>

When such policy attributes are defined, they will be = included in the path computation RPC.

 

Italo and Sergio (on behalf of co-authors/contributo= rs)

 

Sergio Belotti<= o:p>

Senior System Engineer= and Standardization Architect

IP/Optical Networks, O= ptics BU

Nokia

M: +39= -335761776

Via Energy= Park, 20871 Vimercate (MB) , Italy

sergio.belotti@nokia.com

 

 

--_000_VI1PR07MB4270D252C3B586F62D1C91C196270VI1PR07MB4270eurp_-- From nobody Wed Aug 8 12:26:35 2018 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA9C130E77; Wed, 8 Aug 2018 12:26:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: teas@ietf.org Message-ID: <153375639367.6563.10365005582577739932@ietfa.amsl.com> Date: Wed, 08 Aug 2018 12:26:33 -0700 Archived-At: Subject: [Teas] I-D Action: draft-ietf-teas-assoc-corouted-bidir-frr-05.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.27 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 19:26:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling WG of the IETF. Title : Updates to the Fast Reroute Procedures for Co-routed Associated Bidirectional Label Switched Paths (LSPs) Authors : Rakesh Gandhi Himanshu Shah Jeremy Whittaker Filename : draft-ietf-teas-assoc-corouted-bidir-frr-05.txt Pages : 16 Date : 2018-08-08 Abstract: Resource Reservation Protocol (RSVP) association signaling can be used to bind two unidirectional LSPs into an associated bidirectional LSP. When an associated bidirectional LSP is co-routed, the reverse LSP follows the same path as its forward LSP. This document updates the Fast Reroute (FRR) procedures defined in RFC 4090 to support both single-sided and double-sided provisioned associated bidirectional LSPs. This document also updates the procedure for associating two reverse LSPs defined in RFC 7551 to support co-routed bidirectional LSPs. The FRR procedures can ensure that for the co-routed LSPs, traffic flows on co-routed paths in the forward and reverse directions after a failure event. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-assoc-corouted-bidir-frr/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-teas-assoc-corouted-bidir-frr-05 https://datatracker.ietf.org/doc/html/draft-ietf-teas-assoc-corouted-bidir-frr-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-assoc-corouted-bidir-frr-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 8 12:30:26 2018 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A85130ED9; Wed, 8 Aug 2018 12:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_RED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pjgjYjAeKq4; Wed, 8 Aug 2018 12:30:15 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 977B0130E77; Wed, 8 Aug 2018 12:30:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=45494; q=dns/txt; s=iport; t=1533756614; x=1534966214; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5hlGBO8iCUfWKQcuF6EZTInYO/zsIvCAKD6zeRtrKg8=; b=YFhpAOURoVj3Gg6YUfpZgo2PGfmWVBUSGtOgnCAA2xPGonK/YkCIohi5 TMZTNrtaBPL1Usrkn4teGdSd/lDk2EpeDhSakXO3Z3tp6zEI259jlCY17 uMrhlarX1vBNIlcsAG33uTpA81MfkBrARWihrar/2lixNyb3zFcReLoAl E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CdAAC+Q2tb/4QNJK1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJXd2N/KAqDdIgKjDqBaCWIR40qgXoLJYRHAheCfCE0GAE?= =?us-ascii?q?CAQECAQECbRwMhTcBAQEBAyNWEAIBBgIRAwECIQEJAgICHxEdCAEBBAENBYM?= =?us-ascii?q?gAYEcTAMVD49Km0uBLh+HBA2DJYkUF4FBP4ERAScME4JMghFFOgsBAQIBARa?= =?us-ascii?q?BZwYSgkkxgiQCiAOSFysJAoYahh6DD4FPSINegnSFQ4p1V4cCAhEUgSQNEDi?= =?us-ascii?q?BUnAVGksBgj4JiwyFPm8BjRGBGwEB?= X-IronPort-AV: E=Sophos;i="5.53,458,1531785600"; d="scan'208,217";a="435531569" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Aug 2018 19:30:12 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id w78JUCSF014029 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Aug 2018 19:30:12 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 8 Aug 2018 14:30:11 -0500 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1320.000; Wed, 8 Aug 2018 14:30:11 -0500 From: "Rakesh Gandhi (rgandhi)" To: Daniele Ceccarelli , " (rtg-ads@ietf.org)" CC: "rtg-dir@ietf.org" , "TEAS WG (teas@ietf.org)" , "draft-ietf-teas-assoc-corouted-bidir-frr.all@ietf.org" Thread-Topic: RtgDir review: draft-ietf-teas-assoc-corouted-bidir-frr-04 Thread-Index: AdQlm/SWFN83nAOVQmKg2miyrumEwAChYgCAAc1HYgA= Date: Wed, 8 Aug 2018 19:30:11 +0000 Message-ID: References: <5A4119B4-94E1-4AD9-8300-39F27AE195F8@cisco.com> In-Reply-To: <5A4119B4-94E1-4AD9-8300-39F27AE195F8@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.220.55] Content-Type: multipart/alternative; boundary="_000_DE9B26474A474EEE814952A16CEE123Eciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.27, xch-rcd-017.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [Teas] RtgDir review: draft-ietf-teas-assoc-corouted-bidir-frr-04 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 19:30:18 -0000 --_000_DE9B26474A474EEE814952A16CEE123Eciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGFuaWVsZSwNCg0KRllJLCB3ZSBoYXZlIHVwbG9hZGVkIHRoaXMgdmVyc2lvbi4gUGxlYXNl IGxldCB1cyBrbm93IGlmIHlvdSBoYXZlIGFkZGl0aW9uYWwgY29tbWVudHMuDQoNCg0KaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdGVhcy1hc3NvYy1jb3JvdXRlZC1iaWRp ci1mcnItMDUNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1p ZXRmLXRlYXMtYXNzb2MtY29yb3V0ZWQtYmlkaXItZnJyLTA1DQoNCg0KDQpBIGRpZmYgZnJvbSB0 aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQoNCmh0dHBzOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXRlYXMtYXNzb2MtY29yb3V0ZWQtYmlkaXItZnJy LTA1DQoNCg0KDQpUaGFua3MsDQpSYWtlc2ggKGZvciBhdXRob3JzKQ0KDQoNCkZyb206ICI9U01U UDpyZ2FuZGhpQGNpc2NvLiBjb20iIDxyZ2FuZGhpQGNpc2NvLmNvbT4NCkRhdGU6IE1vbmRheSwg SnVseSAzMCwgMjAxOCBhdCAxMToyMiBBTQ0KVG86IERhbmllbGUgQ2VjY2FyZWxsaSA8ZGFuaWVs ZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbT4sICI8cnRnLWFkc0BpZXRmLm9yZz4gKHJ0Zy1hZHNA aWV0Zi5vcmcpIiA8cnRnLWFkc0BpZXRmLm9yZz4NCkNjOiAicnRnLWRpckBpZXRmLm9yZyIgPHJ0 Zy1kaXJAaWV0Zi5vcmc+LCAiVEVBUyBXRyAodGVhc0BpZXRmLm9yZykiIDx0ZWFzQGlldGYub3Jn PiwgImRyYWZ0LWlldGYtdGVhcy1hc3NvYy1jb3JvdXRlZC1iaWRpci1mcnIuYWxsQGlldGYub3Jn IiA8ZHJhZnQtaWV0Zi10ZWFzLWFzc29jLWNvcm91dGVkLWJpZGlyLWZyci5hbGxAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSZTogUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi10ZWFzLWFzc29jLWNvcm91 dGVkLWJpZGlyLWZyci0wNA0KDQpIaSBEYW5pZWxlLA0KDQpNYW55IHRoYW5rcyBmb3IgdGhlIHJl dmlldyBvZiB0aGUgZG9jdW1lbnQgYW5kIHlvdXIgc3VnZ2VzdGlvbnMuDQpEaWZmIGZpbGUgaXMg Zm9yIHRoZSB1cGRhdGVkIGRvY3VtZW50IGlzIGF0dGFjaGVkLg0KUGxlYXNlIHNlZSBpbmxpbmUg PFJHPuKApg0KDQpGcm9tOiBEYW5pZWxlIENlY2NhcmVsbGkgPGRhbmllbGUuY2VjY2FyZWxsaUBl cmljc3Nvbi5jb20+DQpEYXRlOiBTYXR1cmRheSwgSnVseSAyOCwgMjAxOCBhdCAxMDoyOCBBTQ0K VG86ICI8cnRnLWFkc0BpZXRmLm9yZz4gKHJ0Zy1hZHNAaWV0Zi5vcmcpIiA8cnRnLWFkc0BpZXRm Lm9yZz4NCkNjOiAicnRnLWRpckBpZXRmLm9yZyIgPHJ0Zy1kaXJAaWV0Zi5vcmc+LCAiVEVBUyBX RyAodGVhc0BpZXRmLm9yZykiIDx0ZWFzQGlldGYub3JnPiwgImRyYWZ0LWlldGYtdGVhcy1hc3Nv Yy1jb3JvdXRlZC1iaWRpci1mcnIuYWxsQGlldGYub3JnIiA8ZHJhZnQtaWV0Zi10ZWFzLWFzc29j LWNvcm91dGVkLWJpZGlyLWZyci5hbGxAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSdGdEaXIgcmV2aWV3 OiBkcmFmdC1pZXRmLXRlYXMtYXNzb2MtY29yb3V0ZWQtYmlkaXItZnJyLTA0DQpSZXNlbnQtRnJv bTogPGFsaWFzLWJvdW5jZXNAaWV0Zi5vcmc+DQpSZXNlbnQtVG86ICI9U01UUDpyZ2FuZGhpQGNp c2NvLiBjb20iIDxyZ2FuZGhpQGNpc2NvLmNvbT4sIDxoc2hhaEBjaWVuYS5jb20+LCA8amVyZW15 LndoaXR0YWtlckB2ZXJpem9uLmNvbT4sIExvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+LCA8 bWhhcnRsZXkuaWV0ZkBnbWFpbC5jb20+LCA8dmJlZXJhbUBqdW5pcGVyLm5ldD4sIDxtYXJ0aW4u dmlnb3VyZXV4QG5va2lhLmNvbT4sIERFQk9SQUggQlJVTkdBUkQgPGRiMzU0NkBhdHQuY29tPiwg PGFyZXRhbmEuaWV0ZkBnbWFpbC5jb20+LCBWaXNobnUgQmVlcmFtIDx2aXNobnVwYXZhbkBnbWFp bC5jb20+LCA8dmlzaG51cGF2YW5AZ21haWwuY29tPg0KUmVzZW50LURhdGU6IFNhdHVyZGF5LCBK dWx5IDI4LCAyMDE4IGF0IDEwOjI4IEFNDQoNCg0KSGVsbG8sDQoNCkkgaGF2ZSBiZWVuIHNlbGVj dGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBU aGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91 dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBh bmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMgb24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVy cG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGlu ZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl LCBwbGVhc2Ugc2VlIOKAi2h0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMv d2lraS9SdGdEaXI8aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtp L1J0Z0Rpcj4NCg0KQWx0aG91Z2ggdGhlc2UgY29tbWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhl IHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxk IGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBhbnkgb3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVu dHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCBk aXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBkcmFmdC4NCg0KRG9jdW1lbnQ6IGRyYWZ0LWll dGYtdGVhcy1hc3NvYy1jb3JvdXRlZC1iaWRpci1mcnItMDQNClJldmlld2VyOiBEYW5pZWxlIENl Y2NhcmVsbGkNClJldmlldyBEYXRlOiAyNy8wNy8yMDE4DQpJRVRGIExDIEVuZCBEYXRlOiBkYXRl LWlmLWtub3duDQpJbnRlbmRlZCBTdGF0dXM6IFN0YW5kYXJkIHRyYWNrDQoNClN1bW1hcnk6DQoN Cg0KDQoNCiAgKiAgIEkgaGF2ZSBzb21lIG1pbm9yIGNvbmNlcm5zIGFib3V0IHRoaXMgZG9jdW1l bnQgdGhhdCBJIHRoaW5rIHNob3VsZCBiZSByZXNvbHZlZCBiZWZvcmUgcHVibGljYXRpb24uDQoN CkNvbW1lbnRzOg0KDQogICogICBUaGUgZG9jdW1lbnQgaXMgdmVyeSB3ZWxsIHdyaXR0ZW4gYW5k IHRoZSBwcm9ibGVtIGNsZWFybHkgc3RhdGVkIChldmVuIGlmIGNhbGxlZCBvdmVydmlldyDwn5iK ICkuIFRoZSBzZWNvbmQgcGFydCBpcyBhIGJpdCBoYXJkZXIgdG8gZm9sbG93IGJ1dCBJIGRvbuKA mXQgc2VlIGhvdyB0byBtYWtlIHRoZSBwcm9jZWR1cmUgc2VjdGlvbiBlYXNpZXIgdG8gcmVhZC4N CjxSRz4gT2ssIHRoYW5rcy4NCg0KICAqICAgSXQgaXMgbm90IGNsZWFyIHRvIG1lIHdoeSB0aGVy ZSBpcyBhbiDigJxleGFtcGxl4oCdIG9mIEV4dGVuZGVkIEFzc29jaWF0aW9uIElEIGluIHRoZSBh cHBlbmRpeC4gUkZDIDY3ODAganVzdCBzYXlzIGl0IOKAnGNvbnRhaW5zIGRhdGEgdGhhdCBpcyBh ZGRpdGlvbmFsIGluZm9ybWF0aW9uIHRvIHN1cHBvcnQgdW5pcXVlIGlkZW50aWZpY2F0aW9uLuKA nSBCdXQgZG9lc27igJl0IGRlc2NyaWJlIGhvdyBpdCBzaG91bGQgYmUgZmlsbGVkLiBEb2VzIHRo aXMgbWVhbiB0aGVyZSBpcyBubyBzdGFuZGFyZCBmb3JtYXQgZm9yIGl0Pw0KPFJHPiBSaWdodC4g RXhhbXBsZSBzaG93biBpbiB0aGUgQXBwZW5kaXggaXMgb25lIHVuLWFtYmlndW91cyB3YXkgdG8g cG9wdWxhdGUgaXQgZm9yIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1BzLg0KDQpNYWpvciBJ c3N1ZXM6DQoNCk5vbmUNCg0KTWlub3IgSXNzdWVzOg0KDQogICogICBNb3ZpbmcgdGhlIHRlcm1p bm9sb2d5IHNlY3Rpb24gYmVmb3JlIHRoZSBpbnRyb2R1Y3Rpb24gd291bGQgaW1wcm92ZSByZWFk YWJpbGl0eSwgc2luY2UgdGhlIHRlcm1zIGRlZmluZWQgaW4gdGhlIHRlcm1pbm9sb2d5IHNlY3Rp b24gYXJlIGZyZXF1ZW50bHkgdXNlZCBpbiB0aGUgaW50cm9kdWN0aW9uLg0KPFJHPiBJIGFtIG5v dCBmYW1pbGlhciB3aXRoIGFuIFJGQyB3aGVyZSB0ZXJtaW5vbG9neSBpcyB0aGUgZmlyc3Qgc2Vj dGlvbi4gSSBhbSBmaW5lIGVpdGhlciB3YXksIHBsZWFzZSBsZXQgbWUga25vdyBpZiB5b3UgcHJl ZmVyIHRoaXMgd2F5Lg0KDQogICogICBXaGVuIEkgcmVhZCB0aGUgdGl0bGUgb2Ygc2VjdGlvbiAz IChvdmVydmlldyksIEkgdGhvdWdodCDigJx3aHkgYW4gb3ZlcnZpZXcgaXMgbmVlZGVkIGlmIHRo ZXJlIGlzIGFuIGludHJvZHVjdGlvbj/igJ0uIEFjdHVhbGx5IHRoZSB0ZXh0IGluIHRoYXQgc2Vj dGlvbiBpcyB2ZXJ5IHVzZWZ1bCBidXQgbW9yZSB0aGFuIGFuIG92ZXJ2aWV3IEkgd291bGQgY2Fs bCBpdCBhIHByb2JsZW0gc3RhdGVtZW50IChvciBzb21ldGhpbmcgbGlrZSB0aGF0KS4NCjxSRz4g Q29ycmVjdGVkLg0KDQogICogICBUaGUgdXNhZ2Ugb2YgUkZDIDIxMTkgKG9yIHNob3VsZCB3ZSBy ZWZlcmVuY2UgUkZDIDgxNzQgPz8pIGlzIG5vdCBjb25ncnVlbnQgYWxsIG92ZXIgdGhlIGRvY3Vt ZW50LiBFLmcuIHNlY3Rpb24gNC4xDQoNCiAgbyAgVGhlIGRvd25zdHJlYW0gUExSIG5vZGUgYWx3 YXlzIGluaXRpYXRlcyB0aGUgYnlwYXNzIHR1bm5lbA0KDQogICAgICBhc3NpZ25tZW50IGZvciB0 aGUgZm9yd2FyZCBMU1AuICBUaGUgdXBzdHJlYW0gUExSIChmb3J3YXJkDQoNCiAgICAgIGRpcmVj dGlvbiBMU1AgTVApIG5vZGUgc2ltcGx5IHJlZmxlY3RzIHRoZSBhc3NvY2lhdGVkIGJ5cGFzcw0K DQogICAgICB0dW5uZWwgYXNzaWdubWVudCBmb3IgdGhlIHJldmVyc2UgZGlyZWN0aW9uIExTUC4g IFRoZSB1cHN0cmVhbSBQTFINCg0KICAgICAgbm9kZSBNVVNUIE5PVCBpbml0aWF0ZSB0aGUgYnlw YXNzIHR1bm5lbCBhc3NpZ25tZW50Lg0KDQoNCg0KPFJHPiBDb3JyZWN0ZWQuDQoNCk5pdHM6DQoN CiAgKiAgIFNlY3Rpb24xOiDigJwoRylNdWx0aXByb3RvY29sIExhYmVsIFN3aXRjaGluZyAoTVBM UykgVHJhZmZpYyBFbmdpbmVlcmluZyAoVEUpIExhYmVsIFN3aXRjaGVkIFBhdGhzIChMU1BzKeKA nS4gVGhpcyBmb3JtYXR0aW5nIGRvZXNu4oCZdCBtYWtlIG11Y2ggc2Vuc2UuIEluIHRoZSBmaXJz dCBpbnN0YW5jZSB0aGUgYnJhY2tldHMgYXJlIHVzZWQgdG8gc2F5IE1QTFMgb3IgR01QTFMgd2hp bGUgaW4gdGhlIG90aGVyIG9uZXMgdG8gZGVmaW5lIHRoZSBhY3Jvbnltcy4NCjxSRz4gQ29ycmVj dGVkLg0KDQogICogICBTZWN0aW9uIDMuMSB0aGVyZSBpcyBubyBuZWVkIHRvIHJlcGVhdCB0d2lj ZSB0aGF0IEJ5cGFzcyB0dW5uZWwgTiB1c2VzIHBhdGggQi1ILUktQyBhbmQgQnlwYXNzIHR1bm5l bCBTIHBhdGggQi1GLUctQy4gVGhlIHNlY29uZCB0aW1lIHRoZSBicmFja2V0IGNhbiBiZSBkcm9w cGVkLg0KPFJHPiBDb3JyZWN0ZWQuDQoNCiAgKiAgIFNlY3Rpb24gNC4xLjEuIC0gIHMvU0hPVUxE IHRyaWdnZXIgdGhlIHByb2NlZHVyZS8gU0hPVUxEIHRyaWdnZXIgcHJvY2VkdXJlDQo8Ukc+IENv cnJlY3RlZC4NClRoYW5rcywNClJha2VzaCAoZm9yIGF1dGhvcnMpDQoNCg0KQlINCkRhbmllbGUN Cg== --_000_DE9B26474A474EEE814952A16CEE123Eciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <2173202BA4228041BF9F01534B85B4FE@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6QXJpYWw7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAy IDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCXBh bm9zZS0xOjIgNyAzIDkgMiAyIDUgMiA0IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpU aW1lczsNCglwYW5vc2UtMToyIDAgNSAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0 IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFu b3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNh bGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQXBwbGUgQ29sb3IgRW1vamkiOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAg MCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3Jt YWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseTpDYWxpYnJpO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCnByZQ0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xp c3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eToz NDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206 MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseTpDYWxpYnJpO30NCnNwYW4uSFRNTFByZWZvcm1h dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6SVQ7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uaWNvbg0KCXttc28tc3R5 bGUtbmFtZTppY29uO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVt YWlsU3R5bGUyNQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KcC5wMSwgbGkucDEsIGRpdi5wMQ0KCXtt c28tc3R5bGUtbmFtZTpwMTsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6Ny4wcHQ7DQoJZm9udC1mYW1pbHk6VGltZXM7fQ0KcC5wMiwgbGkucDIsIGRp di5wMg0KCXttc28tc3R5bGUtbmFtZTpwMjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6Ny4wcHQ7DQoJZm9udC1mYW1pbHk6VGltZXM7DQoJY29sb3I6 IzA0MkVFRTt9DQpwLnAzLCBsaS5wMywgZGl2LnAzDQoJe21zby1zdHlsZS1uYW1lOnAzOw0KCW1h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo3LjBwdDsNCglm b250LWZhbWlseTpUaW1lczt9DQpzcGFuLnMyDQoJe21zby1zdHlsZS1uYW1lOnMyOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5zMQ0KCXttc28tc3R5bGUtbmFtZTpzMTt9DQpz cGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFt ZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcwLjg1cHQgMi4wY20gMi4wY20gMi4wY207fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlz dC1pZDo5ODcxNzA2MzE7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMzI3MzMyOTIwO30NCkBs aXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21z by1saXN0LWlkOjExMDQyOTkzMTM7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjIwNDYwNDQ1MjQ7 fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZl bDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEw OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI4OC4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDIN Cgl7bXNvLWxpc3QtaWQ6MTc0NzcyMTM0NzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEzNTM4 NDUyNjt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwy OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMw0KCXttc28tbGlzdC1pZDoyMDg5OTYzMjA2Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczot MTcwMjQ1MDU1ODt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwzOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMzpsZXZlbDMNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0 LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MzpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDcNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQot LT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBs aW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkhp IERhbmllbGUsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5GWUks IHdlIGhhdmUgdXBsb2FkZWQgdGhpcyB2ZXJzaW9uLiBQbGVhc2UgbGV0IHVzIGtub3cgaWYgeW91 IGhhdmUgYWRkaXRpb25hbCBjb21tZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9InAyIj48c3BhbiBjbGFzcz0iczIiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi10ZWFzLWFzc29jLWNvcm91dGVkLWJpZGlyLWZyci0wNSI+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdGVhcy1hc3NvYy1jb3JvdXRlZC1iaWRpci1m cnItMDU8L2E+PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9InAyIj48c3BhbiBjbGFzcz0iczIiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtdGVhcy1hc3NvYy1jb3JvdXRlZC1iaWRpci1mcnIt MDUiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi10ZWFz LWFzc29jLWNvcm91dGVkLWJpZGlyLWZyci0wNTwvYT48L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0icDMi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0icDEiPjxzcGFuIGNsYXNzPSJzMSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBh dDo8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0icDIiPjxzcGFuIGNsYXNzPSJzMiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1pZXRmLXRlYXMtYXNzb2MtY29yb3V0ZWQtYmlkaXItZnJyLTA1Ij5odHRwczov L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi10ZWFzLWFzc29jLWNvcm91dGVk LWJpZGlyLWZyci0wNTwvYT48L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0icDMiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+UmFrZXNoIChmb3IgYXV0aG9ycyk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZy b206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mcXVvdDs9U01UUDpyZ2Fu ZGhpQGNpc2NvLiBjb20mcXVvdDsgJmx0O3JnYW5kaGlAY2lzY28uY29tJmd0Ozxicj4NCjxiPkRh dGU6IDwvYj5Nb25kYXksIEp1bHkgMzAsIDIwMTggYXQgMTE6MjIgQU08YnI+DQo8Yj5UbzogPC9i PkRhbmllbGUgQ2VjY2FyZWxsaSAmbHQ7ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbSZn dDssICZxdW90OyZsdDtydGctYWRzQGlldGYub3JnJmd0OyAocnRnLWFkc0BpZXRmLm9yZykmcXVv dDsgJmx0O3J0Zy1hZHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtydGctZGly QGlldGYub3JnJnF1b3Q7ICZsdDtydGctZGlyQGlldGYub3JnJmd0OywgJnF1b3Q7VEVBUyBXRyAo dGVhc0BpZXRmLm9yZykmcXVvdDsgJmx0O3RlYXNAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtkcmFmdC1p ZXRmLXRlYXMtYXNzb2MtY29yb3V0ZWQtYmlkaXItZnJyLmFsbEBpZXRmLm9yZyZxdW90OyAmbHQ7 ZHJhZnQtaWV0Zi10ZWFzLWFzc29jLWNvcm91dGVkLWJpZGlyLWZyci5hbGxAaWV0Zi5vcmcmZ3Q7 PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLXRlYXMt YXNzb2MtY29yb3V0ZWQtYmlkaXItZnJyLTA0PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIERhbmllbGUsPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk1hbnkgdGhhbmtzIGZvciB0aGUgcmV2aWV3IG9mIHRoZSBkb2N1bWVudCBhbmQgeW91ciBzdWdn ZXN0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRpZmYgZmlsZSBp cyBmb3IgdGhlIHVwZGF0ZWQgZG9jdW1lbnQgaXMgYXR0YWNoZWQuIDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNlIHNlZSBpbmxpbmUgJmx0O1JHJmd0O+KApjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj5EYW5pZWxlIENlY2NhcmVsbGkgJmx0O2RhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5j b20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlNhdHVyZGF5LCBKdWx5IDI4LCAyMDE4IGF0IDEwOjI4 IEFNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDsmbHQ7cnRnLWFkc0BpZXRmLm9yZyZndDsgKHJ0Zy1h ZHNAaWV0Zi5vcmcpJnF1b3Q7ICZsdDtydGctYWRzQGlldGYub3JnJmd0Ozxicj4NCjxiPkNjOiA8 L2I+JnF1b3Q7cnRnLWRpckBpZXRmLm9yZyZxdW90OyAmbHQ7cnRnLWRpckBpZXRmLm9yZyZndDss ICZxdW90O1RFQVMgV0cgKHRlYXNAaWV0Zi5vcmcpJnF1b3Q7ICZsdDt0ZWFzQGlldGYub3JnJmd0 OywgJnF1b3Q7ZHJhZnQtaWV0Zi10ZWFzLWFzc29jLWNvcm91dGVkLWJpZGlyLWZyci5hbGxAaWV0 Zi5vcmcmcXVvdDsgJmx0O2RyYWZ0LWlldGYtdGVhcy1hc3NvYy1jb3JvdXRlZC1iaWRpci1mcnIu YWxsQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SdGdEaXIgcmV2aWV3OiBkcmFm dC1pZXRmLXRlYXMtYXNzb2MtY29yb3V0ZWQtYmlkaXItZnJyLTA0PGJyPg0KPGI+UmVzZW50LUZy b206IDwvYj4mbHQ7YWxpYXMtYm91bmNlc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5SZXNlbnQtVG86 IDwvYj4mcXVvdDs9U01UUDpyZ2FuZGhpQGNpc2NvLiBjb20mcXVvdDsgJmx0O3JnYW5kaGlAY2lz Y28uY29tJmd0OywgJmx0O2hzaGFoQGNpZW5hLmNvbSZndDssICZsdDtqZXJlbXkud2hpdHRha2Vy QHZlcml6b24uY29tJmd0OywgTG91IEJlcmdlciAmbHQ7bGJlcmdlckBsYWJuLm5ldCZndDssICZs dDttaGFydGxleS5pZXRmQGdtYWlsLmNvbSZndDssICZsdDt2YmVlcmFtQGp1bmlwZXIubmV0Jmd0 OywgJmx0O21hcnRpbi52aWdvdXJldXhAbm9raWEuY29tJmd0OywgREVCT1JBSCBCUlVOR0FSRCAm bHQ7ZGIzNTQ2QGF0dC5jb20mZ3Q7LA0KICZsdDthcmV0YW5hLmlldGZAZ21haWwuY29tJmd0Oywg VmlzaG51IEJlZXJhbSAmbHQ7dmlzaG51cGF2YW5AZ21haWwuY29tJmd0OywgJmx0O3Zpc2hudXBh dmFuQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5SZXNlbnQtRGF0ZTogPC9iPlNhdHVyZGF5LCBKdWx5 IDI4LCAyMDE4IGF0IDEwOjI4IEFNPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6VmVyZGFuYTtjb2xvcjpibGFjayI+SGVsbG8sPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7Zm9udC12YXJpYW50LWxpZ2F0dXJl czogbm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogMjt0ZXh0LWFsaWdu OnN0YXJ0O3dpZG93czogMjstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7dGV4dC1kZWNv cmF0aW9uLXN0eWxlOiBpbml0aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjogaW5pdGlhbDt3b3Jk LXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OlZlcmRhbmE7Y29sb3I6YmxhY2siPkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5n IERpcmVjdG9yYXRlIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3Rv cmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0 cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRw0KIHJldmlldywg YW5kIHNvbWV0aW1lcyBvbiBzcGVjaWFsIHJlcXVlc3QuIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZp ZXcgaXMgdG8gcHJvdmlkZSBhc3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUg aW5mb3JtYXRpb24gYWJvdXQgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUmbmJz cDs8YSBocmVmPSJodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kv UnRnRGlyIj48c3BhbiBjbGFzcz0iaWNvbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkFyaWFs O2NvbG9yOiNCQjAwMDA7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPuKAizwvc3Bhbj48L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOiNCQjAwMDAiPmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEv cnRnL3RyYWMvd2lraS9SdGdEaXI8L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlO2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDtm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IDI7dGV4dC1hbGlnbjpzdGFydDt3aWRv d3M6IDI7LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3RleHQtZGVjb3JhdGlvbi1zdHls ZTogaW5pdGlhbDt0ZXh0LWRlY29yYXRpb24tY29sb3I6IGluaXRpYWw7d29yZC1zcGFjaW5nOjBw eCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpWZXJkYW5hO2Nv bG9yOmJsYWNrIj5BbHRob3VnaCB0aGVzZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUg dXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQgd291bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQg Y29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhlciBJRVRGIExhc3QgQ2FsbCBjb21tZW50 cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZlIHRvDQogcmVzb2x2ZSB0aGVtIHRocm91Z2gg ZGlzY3Vzc2lvbiBvciBieSB1cGRhdGluZyB0aGUgZHJhZnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7Zm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9y bWFsO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogMjt0ZXh0LWFsaWduOnN0YXJ0 O3dpZG93czogMjstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7dGV4dC1kZWNvcmF0aW9u LXN0eWxlOiBpbml0aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjogaW5pdGlhbDt3b3JkLXNwYWNp bmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlZlcmRh bmE7Y29sb3I6YmxhY2siPkRvY3VtZW50OiBkcmFmdC1pZXRmLXRlYXMtYXNzb2MtY29yb3V0ZWQt YmlkaXItZnJyLTA0PGJyPg0KUmV2aWV3ZXI6IERhbmllbGUgQ2VjY2FyZWxsaTxicj4NClJldmll dyBEYXRlOiAyNy8wNy8yMDE4PGJyPg0KSUVURiBMQyBFbmQgRGF0ZTogZGF0ZS1pZi1rbm93biZu YnNwOzxicj4NCkludGVuZGVkIFN0YXR1czogU3RhbmRhcmQgdHJhY2s8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZTtmb250LXZhcmlhbnQtbGlnYXR1cmVz OiBub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiAyO3RleHQtYWxpZ246 c3RhcnQ7d2lkb3dzOiAyOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt0ZXh0LWRlY29y YXRpb24tc3R5bGU6IGluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOiBpbml0aWFsO3dvcmQt c3BhY2luZzowcHgiPg0KPHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpWZXJkYW5hO2NvbG9yOmJsYWNrIj5TdW1tYXJ5Ojwvc3Bhbj48L3N0cm9uZz48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpWZXJkYW5hO2NvbG9yOmJsYWNr Ij4mbmJzcDs8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8 dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNr O21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1s aXN0OmwxIGxldmVsMSBsZm8xO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OlZlcmRhbmEiPkkgaGF2ZSBzb21lIG1pbm9yIGNvbmNlcm5zIGFib3V0IHRoaXMgZG9j dW1lbnQgdGhhdCBJIHRoaW5rIHNob3VsZCBiZSByZXNvbHZlZCBiZWZvcmUgcHVibGljYXRpb24u PC9zcGFuPjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6VmVyZGFu YTtjb2xvcjpibGFjayI+Q29tbWVudHM6PC9zcGFuPjwvc3Ryb25nPjxvOnA+PC9vOnA+PC9wPg0K PHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFj azttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28t bGlzdDpsMCBsZXZlbDEgbGZvMjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTpWZXJkYW5hIj5UaGUgZG9jdW1lbnQgaXMgdmVyeSB3ZWxsIHdyaXR0ZW4gYW5kIHRo ZSBwcm9ibGVtIGNsZWFybHkgc3RhdGVkIChldmVuIGlmIGNhbGxlZCBvdmVydmlldw0KPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcHBsZSBDb2xvciBFbW9qaSZxdW90OyI+ JiMxMjg1MjI7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpWZXJkYW5hIj4gKS4gVGhl IHNlY29uZCBwYXJ0IGlzIGEgYml0IGhhcmRlciB0byBmb2xsb3cgYnV0IEkgZG9u4oCZdCBzZWUg aG93IHRvIG1ha2UgdGhlIHByb2NlZHVyZSBzZWN0aW9uIGVhc2llciB0byByZWFkLg0KPC9zcGFu PjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6 d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlZlcmRhbmE7Y29sb3I6YmxhY2siPiZs dDtSRyZndDsgT2ssIHRoYW5rcy4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRp c2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZl bDEgbGZvMjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpWZXJk YW5hIj5JdCBpcyBub3QgY2xlYXIgdG8gbWUgd2h5IHRoZXJlIGlzIGFuIOKAnGV4YW1wbGXigJ0g b2YgRXh0ZW5kZWQgQXNzb2NpYXRpb24gSUQgaW4gdGhlIGFwcGVuZGl4LiBSRkMgNjc4MCBqdXN0 IHNheXMgaXQg4oCcY29udGFpbnMgZGF0YSB0aGF0IGlzIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24g dG8gc3VwcG9ydCB1bmlxdWUgaWRlbnRpZmljYXRpb24u4oCdIEJ1dCBkb2VzbuKAmXQgZGVzY3Jp YmUgaG93IGl0DQogc2hvdWxkIGJlIGZpbGxlZC4gRG9lcyB0aGlzIG1lYW4gdGhlcmUgaXMgbm8g c3RhbmRhcmQgZm9ybWF0IGZvciBpdD88L3NwYW4+PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6VmVyZGFuYTtjb2xvcjpibGFjayI+Jmx0O1JHJmd0OyBSaWdodC4gRXhhbXBsZSBzaG93 biBpbiB0aGUgQXBwZW5kaXggaXMgb25lIHVuLWFtYmlndW91cyB3YXkgdG8gcG9wdWxhdGUgaXQg Zm9yIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1BzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OlZlcmRhbmE7Y29sb3I6YmxhY2siPk1ham9yIElzc3Vlczo8 L3NwYW4+PC9zdHJvbmc+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6VmVyZGFuYTtjb2xv cjpibGFjayI+Tm9uZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OlZlcmRhbmE7Y29sb3I6YmxhY2siPk1pbm9yIElzc3Vlczo8L3NwYW4+PC9zdHJvbmc+PG86cD48 L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21zby1saXN0OmwyIGxldmVsMSBsZm8zO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OlZlcmRhbmEiPk1vdmluZyB0aGUgdGVybWlub2xvZ3kgc2VjdGlv biBiZWZvcmUgdGhlIGludHJvZHVjdGlvbiB3b3VsZCBpbXByb3ZlIHJlYWRhYmlsaXR5LCBzaW5j ZSB0aGUgdGVybXMgZGVmaW5lZCBpbiB0aGUgdGVybWlub2xvZ3kgc2VjdGlvbiBhcmUgZnJlcXVl bnRseSB1c2VkIGluIHRoZSBpbnRyb2R1Y3Rpb24uDQo8L3NwYW4+PG86cD48L286cD48L2xpPjwv dWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6VmVyZGFuYTtjb2xvcjpibGFjayI+Jmx0O1JHJmd0OyBJIGFtIG5vdCBm YW1pbGlhciB3aXRoIGFuIFJGQyB3aGVyZSB0ZXJtaW5vbG9neSBpcyB0aGUgZmlyc3Qgc2VjdGlv bi4gSSBhbSBmaW5lIGVpdGhlciB3YXksIHBsZWFzZSBsZXQgbWUga25vdyBpZiB5b3UgcHJlZmVy IHRoaXMgd2F5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzM7YmFj a2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6VmVyZGFuYSI+V2hlbiBJ IHJlYWQgdGhlIHRpdGxlIG9mIHNlY3Rpb24gMyAob3ZlcnZpZXcpLCBJIHRob3VnaHQg4oCcd2h5 IGFuIG92ZXJ2aWV3IGlzIG5lZWRlZCBpZiB0aGVyZSBpcyBhbiBpbnRyb2R1Y3Rpb24/4oCdLiBB Y3R1YWxseSB0aGUgdGV4dCBpbiB0aGF0IHNlY3Rpb24gaXMgdmVyeSB1c2VmdWwgYnV0IG1vcmUg dGhhbiBhbiBvdmVydmlldyBJIHdvdWxkIGNhbGwgaXQgYSBwcm9ibGVtIHN0YXRlbWVudA0KIChv ciBzb21ldGhpbmcgbGlrZSB0aGF0KS48L3NwYW4+PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6VmVyZGFuYTtjb2xvcjpibGFjayI+Jmx0O1JHJmd0OyBDb3JyZWN0ZWQuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDEgbGZvMztiYWNrZ3JvdW5kOndoaXRlIj4NCjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpWZXJkYW5hIj5UaGUgdXNhZ2Ugb2YgUkZDIDIxMTkgKG9y IHNob3VsZCB3ZSByZWZlcmVuY2UgUkZDIDgxNzQgPz8pIGlzIG5vdCBjb25ncnVlbnQgYWxsIG92 ZXIgdGhlIGRvY3VtZW50LiBFLmcuIHNlY3Rpb24gNC4xPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48 L3VsPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJmb250LXZhcmlhbnQtbGln YXR1cmVzOiBub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiAyO3RleHQt YWxpZ246c3RhcnQ7d2lkb3dzOiAyOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt0ZXh0 LWRlY29yYXRpb24tc3R5bGU6IGluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOiBpbml0aWFs O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOklUIj4mbmJzcDsg byZuYnNwOyBUaGUgZG93bnN0cmVhbSBQTFIgbm9kZQ0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6 eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93Ij5hbHdheXMgaW5pdGlhdGVzPC9zcGFuPiB0aGUg YnlwYXNzIHR1bm5lbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6SVQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBhc3NpZ25tZW50IGZvciB0aGUgZm9yd2FyZCBMU1AuJm5ic3A7IFRoZSB1cHN0 cmVhbSBQTFIgKGZvcndhcmQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOklUIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgZGlyZWN0aW9uIExTUCBNUCkgbm9kZQ0KPHNwYW4gc3R5bGU9ImJhY2tn cm91bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93Ij5zaW1wbHkgcmVmbGVjdHM8L3NwYW4+ IHRoZSBhc3NvY2lhdGVkIGJ5cGFzczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6SVQiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB0dW5uZWwgYXNzaWdubWVudCBmb3IgdGhlIHJldmVyc2UgZGly ZWN0aW9uIExTUC4mbmJzcDsgVGhlIHVwc3RyZWFtIFBMUjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6SVQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBub2RlIE1VU1QgTk9UIGluaXRpYXRlIHRo ZSBieXBhc3MgdHVubmVsIGFzc2lnbm1lbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpJVCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW4tbGVmdDowY20iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjazttc28tZmFyZWFzdC1s YW5ndWFnZTpJVCI+Jmx0O1JHJmd0OyBDb3JyZWN0ZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6VmVyZGFuYTtjb2xvcjpibGFjayI+Tml0czo8L3NwYW4+PC9z dHJvbmc+PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwzIGxldmVsMSBsZm80O2JhY2tncm91bmQ6d2hp dGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlZlcmRhbmEiPlNlY3Rpb24xOiDigJwoRylN dWx0aXByb3RvY29sIExhYmVsIFN3aXRjaGluZyAoTVBMUykgVHJhZmZpYyBFbmdpbmVlcmluZyAo VEUpIExhYmVsIFN3aXRjaGVkIFBhdGhzIChMU1BzKeKAnS4gVGhpcyBmb3JtYXR0aW5nIGRvZXNu 4oCZdCBtYWtlIG11Y2ggc2Vuc2UuIEluIHRoZSBmaXJzdCBpbnN0YW5jZSB0aGUgYnJhY2tldHMg YXJlIHVzZWQgdG8gc2F5IE1QTFMgb3IgR01QTFMgd2hpbGUgaW4gdGhlDQogb3RoZXIgb25lcyB0 byBkZWZpbmUgdGhlIGFjcm9ueW1zLjwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpWZXJkYW5hO2NvbG9yOmJsYWNrIj4mbHQ7UkcmZ3Q7IENvcnJlY3RlZC48L3NwYW4+PG86 cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21z by1saXN0OmwzIGxldmVsMSBsZm80O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OlZlcmRhbmE7Y29sb3I6YmxhY2siPlNlY3Rpb24gMy4xIHRoZXJlIGlzIG5vIG5l ZWQgdG8gcmVwZWF0IHR3aWNlIHRoYXQgQnlwYXNzIHR1bm5lbCBOIHVzZXMgcGF0aCBCLUgtSS1D IGFuZCBCeXBhc3MgdHVubmVsIFMgcGF0aCBCLUYtRy1DLiBUaGUgc2Vjb25kIHRpbWUgdGhlIGJy YWNrZXQgY2FuIGJlIGRyb3BwZWQuDQo8L3NwYW4+PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6VmVyZGFuYTtjb2xvcjpibGFjayI+Jmx0O1JHJmd0OyBDb3JyZWN0ZWQuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt c28tbGlzdDpsMyBsZXZlbDEgbGZvNDtiYWNrZ3JvdW5kOndoaXRlIj4NClNlY3Rpb24gNC4xLjEu IC0gJm5ic3A7cy9TSE9VTEQgdHJpZ2dlciB0aGUgcHJvY2VkdXJlLyBTSE9VTEQgdHJpZ2dlciBw cm9jZWR1cmU8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNr Z3JvdW5kOndoaXRlIj4NCiZsdDtSRyZndDsgQ29ycmVjdGVkLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KVGhhbmtzLDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KUmFrZXNoIChm b3IgYXV0aG9ycyk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3Jv dW5kOndoaXRlIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjE4LjBwdDtiYWNrZ3JvdW5kOndoaXRlIj4NCiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjE4LjBwdDtiYWNrZ3JvdW5k OndoaXRlIj4NCkJSPGJyPg0KRGFuaWVsZSZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_DE9B26474A474EEE814952A16CEE123Eciscocom_-- From nobody Thu Aug 9 07:53:25 2018 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955DD130DD9; Thu, 9 Aug 2018 07:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eHiak2A42ot; Thu, 9 Aug 2018 07:53:17 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00093.outbound.protection.outlook.com [40.107.0.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C8B3130DC2; Thu, 9 Aug 2018 07:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J+Yatdxks76DYo0f4GoXlynFqEYnqt0TjK+VvERhqaQ=; b=pk9YlgSY/vl4tbF/dgZMoA6H6fSJ1lm447dLOY4SvS+6Xm0FD/C07TnocllFp2dfSBHVMXwi35eWciWkvzs7HGMo44tz9g6/MdHqNNJB9whbV7RoPzTtwEsvmJjjWDEVoimOXlBJYgOlnl8Ob0v3mreOvBh/QslVBs6ZnBl69mo= Received: from AM5PR0701MB2723.eurprd07.prod.outlook.com (10.173.93.137) by AM5PR0701MB3042.eurprd07.prod.outlook.com (10.168.157.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1059.9; Thu, 9 Aug 2018 14:53:12 +0000 Received: from AM5PR0701MB2723.eurprd07.prod.outlook.com ([fe80::6dd9:2f0c:7ce7:7fb5]) by AM5PR0701MB2723.eurprd07.prod.outlook.com ([fe80::6dd9:2f0c:7ce7:7fb5%8]) with mapi id 15.20.1038.013; Thu, 9 Aug 2018 14:53:12 +0000 From: "Belotti, Sergio (Nokia - IT/Vimercate)" To: Julien Meuric CC: "Scharf, Michael (Nokia - DE/Stuttgart)" , "vlopez@tid.es" , "oscar.gonzalezdedios@telefonica.com" , 'Carlo Perocchio' , Leeyoung , "Karthik.Sethuraman@necam.com" , "ansha@google.com" , "ricard.vilalta@cttc.es" , "shiyan49@chinaunicom.cn" , Italo Busi , Igor Bryskin , "adrian@olddog.co.uk" , "Beller, Dieter (Nokia - DE/Stuttgart)" , 'Francesco Lazzeri' , 'Daniele Ceccarelli' , "teas@ietf.org" , "teas-chairs@ietf.org" , Carlo Perocchio , "Belotti, Sergio (Nokia - IT/Vimercate)" Thread-Topic: [Teas] draft-ietf-teas-yang-path-computation-02 : path computation stateless RPC attributes---> Yang model vs. PCEP alignment Thread-Index: AdQv8BFBXfZhabl0QuO/aQv/t0NqVw== Date: Thu, 9 Aug 2018 14:53:11 +0000 Message-ID: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [93.36.178.236] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB3042; 6:OtmGsPGvHlwXYPVJsa/gsdFmbGi4ihOYfqNi8rQp+BwfcSdlp3Xu6DEPO5eyUM2JZbzpqBdEQ12HECFKaYyqZhqVA8ZK/N1s1+vkMSgJ470+WBD7p4nAA1TdltWYBzj9EqWRPWtJ3LdhrEZkJ6Iuua/oetqBe7Yh3uwyCbBsEzZDtrgohHPOWEb9oTd5KTNUbJIb+bxOp5NzM+bOdlZWRbSKjcVsABnsUMH0RMyEB5msOX1zqENIhyJzaWDPIOyXpLyI7ENpcIZ2jNKNZS/R8OAtqIpUO9YEBhJJ/2wImut12ylFVbdBv78cAxrBLLqwg2gKarpxQTOCARaptya3M007NTO/J/f5+vKWENk1+PLbl0A+gmUgFnRJkpRGL0Pa0+Ze0Cail3jm2wBAStdP8/BoVjbeF0Y51abzFNkxcU0WDN+9pW9sO0hqJoUB6FFB/oFFDcAzEKUgJd1h+vJ7Fg==; 5:73QNnpEOxqHaCGqSTFCnM0TbquTJiOJhdBmed8hNyV5mVvbuZ4bpYcPR//oyGUrZh6rKxcZgFTUExX4KKW6ZQy/QQC0KewF+qfQxWyGLqQ6GE5C+bxjjPuZNne5ZdRm0dk82NdZM23807OAd+y5rseCA1c474i5a7LELaVzwGVg=; 7:txVsIs36OVhISErY/vKrJwIvOxGwny0lcdxTo+VsZ9EjfuYWM5KTv9K30/B4hmo/qaDPqpnDBY4kWR/Lavlz7AZuB7Jk5cGB21k6OufoURYVCAkmOxBcMqVKwyjSMSGBdtpngHLPWA2JzdhZWcMjjJgBtsodpLJfw4PzccwRBVpaI9CPVNQPbjISriuUA4nEJiOYXeP+ECRNPezh+/EU4hy/qXYi0ZIpZW0YhnKmDWsryAYfDhE1vbgbtu9U1JBH x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(396003)(376002)(346002)(366004)(136003)(39860400002)(189003)(199004)(53754006)(478600001)(26005)(790700001)(5024004)(14444005)(256004)(2900100001)(8936002)(55016002)(97736004)(6916009)(3846002)(6116002)(4326008)(236005)(6306002)(54906003)(53936002)(53946003)(54896002)(316002)(486006)(186003)(7696005)(68736007)(966005)(9326002)(6436002)(25786009)(9686003)(99286004)(606006)(14454004)(476003)(5250100002)(74316002)(229853002)(107886003)(6246003)(6506007)(81166006)(81156014)(8676002)(105586002)(7416002)(33656002)(7736002)(5660300001)(86362001)(2906002)(102836004)(66066001)(53546011)(106356001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB3042; H:AM5PR0701MB2723.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-office365-filtering-correlation-id: 8294e703-dfd8-41ad-59fa-08d5fe07d42b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:AM5PR0701MB3042; x-ms-traffictypediagnostic: AM5PR0701MB3042: authentication-results: spf=none (sender IP is ) smtp.mailfrom=sergio.belotti@nokia.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(28532068793085)(40392960112811)(158342451672863)(166708455590820)(50582790962513)(82608151540597)(109105607167333)(195916259791689)(161740460382875); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(823301020)(3002001)(3231311)(11241501184)(806099)(944501410)(52105095)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123560045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:AM5PR0701MB3042; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB3042; x-forefront-prvs: 0759F7A50A received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: CKrnISdV9acAC8+yw8rfoNQPyVShrRR34zTXTyVFpzzbIJJ/jvPPr39uiiPJYJyvd7+9fHuvy8iMTGIg6iVxEljmX+Qx+lA6kFkslTozWhHlzzNouyE739lV0ftGGR/Yn2yO/FSRc+HHMgZY97VGGUaBj0NuxkU6Ugh7Bpu19x6y9bSxHDxdqKalCZkTel4K84mEwSE/PSmn/LnS8thUxKx/4YMwSpdddqYw4GX6S2R3z4YfO8lz03n0E3bTzyKY8RGtnkLm3rMwsVs6vi9Z645FI1MsKB7vsVaVAKYQ6ZyNAO977al1EOFgfa2MHA/L5OVd5fXpWws8wpad8OVXLHQYQEsPpnQZQ8W2GQYXlb6xKyJSB+7SJYMhdbpS5FAtiegbTdIgzVL/sGjyr8YFTg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB272350A8E3646F3CF724844191250AM5PR0701MB2723_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8294e703-dfd8-41ad-59fa-08d5fe07d42b X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2018 14:53:11.9869 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB3042 Archived-At: Subject: Re: [Teas] draft-ietf-teas-yang-path-computation-02 : path computation stateless RPC attributes---> Yang model vs. PCEP alignment X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 14:53:23 -0000 --_000_AM5PR0701MB272350A8E3646F3CF724844191250AM5PR0701MB2723_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Julien, we think your reply, in line with Adrian's desire, is in favor of an alignm= ent between PCEP and Yang models. We have found 4 possible types of differences between YANG models and PCEP: 1. Features defined in PCEP but missing in YANG models 2. Features defined in YANG models but missing in PCEP 3. Features supported by both but in different and incompatible way 4. Features supported by both but with some differences which appear mor= e inherent to protocol characteristics of NETCON/RESTCONF with PCEP which c= an be reconciled from an implementation perspective. We can prepare a detailed list of the differences if you think it is valuab= le. A typical case in which a feature is differently implemented on the YANG mo= del and PCEP is related to the support of mandatory/optional (relaxable) co= nstraints. PCEP offers the possibility to decide whether a constraint (almost any obje= ct actually in PCEP) must be considered by the path computation or may be i= gnored. TE-tunnel model has a different mechanism to provide similar featur= e with an ordered list of paths computed with different constraints and the= n the possibility to choose one or the other depending of optimization purp= ose. Do you think we need to reconcile this difference? Thanks Carlo, Francesco, Sergio From: Julien Meuric Sent: Monday, July 30, 2018 4:39 PM To: Igor Bryskin ; adrian@olddog.co.uk; Beller, Di= eter (Nokia - DE/Stuttgart) ; 'Francesco Lazzeri' = ; 'Daniele Ceccarelli' ; Belotti, Sergio (Nokia - IT/Vimercate) ; teas@ietf.org; teas-chairs@ietf.org Cc: Scharf, Michael (Nokia - DE/Stuttgart) ; vlop= ez@tid.es; oscar.gonzalezdedios@telefonica.com; 'Carlo Perocchio' ; Leeyoung ; Karthik.Sethuraman@n= ecam.com; ansha@google.com; ricard.vilalta@cttc.es; shiyan49@chinaunicom.cn= ; Italo Busi Subject: Re: [Teas] draft-ietf-teas-yang-path-computation-02 : path computa= tion stateless RPC attributes Hi Igor, FWIW, the PCE WG would welcome your contribution to allocate a codepoint fo= r a PCEP Object Functions saying "The order of the attached METRIC and IRO = objects express relative preference". If your implementation doesn't want t= o go through the standard process, there are 32768 values "reserved for pri= vate use". Whatever the feature to address, I really wish that multiplying the number = of technical means to express it would increase the number of implementatio= ns supporting it, unfortunately that is not how it works. Operator's hat on= , if your implementation allows to express your example using a proprietary= interface, I'd be happy to write to piece of code to integrate it into my = favorite communication mean. My 2 cents, Julien Jul. 27, 2018 - Igor.Bryskin@huawei.com: Hi Adrian, To say that we cannot do a stateless path computation better than what coul= d be done using PCEP today is a bit too bold IMUO. Why then we keep working= on PCEP enhancements? ;-) One example: today, using the TE tunnel model, a client can request (and I = know servers that implement) a customized (client controlled) weighted mult= i-criteria optimization for path selection, specifying any subset of model = defined metrics. For example, the client can ask for a best possible compro= mise between, say, TE e2e cost, delay and following as much as possible a s= pecific explicit path, assigning a relative weight/importance to each of th= e three criteria. AFAIK this is not possible to do with PCEP today. Cheers, Igor From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Friday, July 27, 2018 2:30 PM I've had several off-line conversations with a number of you where I have l= earned a lot about the use cases and desires that are driving this work. However, (there he goes spoiling the effect!) I see nothing in the use case= s that could not be addressed using PCEP (if PCEP were implemented in those= scenarios) so it makes me think that we should generalise (as we should do= in many cases, anyway). That is, we should make our YANG model carry exact= ly the same information as a PCEP computation request/response, and for the= same reasons. Some of that information should be part of the base model and some should b= e in augmentations, but I don't suppose we should leave stuff out. The debate about how fields like "tunnel name" are used does not serve us w= ell, I believe. That in some environments there is information encoded in t= hese fields so that the PCC can communicate to the PCE the purpose of the p= ath computation is (of course) a implementation/deployment thing. That it c= an be useful to a PCE, looking at the LSPs installed in the network, to mat= ch them against the computations it performed may be incidental to this dis= cussion. My point is that the parameters are there in PCEP, they may have f= ound various uses, and the YANG model is supposed to model the PCEP request= s. I have yet to be convinced of the desirability of leaving things out. And I= don't see the harm of including stuff. Adrian From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Dieter Beller Sent: 27 July 2018 16:22 Hi all, I concur with the comments from Francesco and Daniele below as well as with= those from Michael. We discussed this issue at length in Montreal after the CCAMP session and I= would like to emphasize again that I am having reservations about policies= being applied by a path computation engine based on attributes that are provided = as input to path computation, which have absolutely nothing to do with poli= cy rules as they were defined for totally other purposes! We called that hidde= n policies in our discussion. Thanks, Dieter On 27.07.2018 10:16, Francesco Lazzeri wrote: I believe that the main point for deciding whether all the parameters (incl= uding name, description and so on) are needed or not for stateless path com= putation is the adoption of policies. When I think about policies, I go to the definitions present in RFC3060, wh= ere policy information model is described. According to 3060, basically policies are a (set of) rules where each rule = is defined by enabling conditions (boolean expressions that "enable" the po= licy actions as soon as they become true) and policy actions (the behavior = of the policy). If we introduce this concept in path computation we could think for example= to create two policies for a given domain D: * The first one is enabled when the tunnel description contains the str= ing "igor", and the relevant action is avoiding the node X inside the relev= ant domain. * The second one is enabled when the tunnel description con contains th= e string "francesco", and the levant action is avoiding the node Y inside t= he relevant domain. Let suppose we don't want to use stateless path computation (e.g. the domai= n is "white", so we have full topology information about it, or, if domain = is "black" or "gray", we just use its abstract connectivity). We are asking for a new tunnel with description "igor". Assuming the client (MDSC) knows nothing about those policies, it does path= computation end-to-end using the topology information it collected, and f= ind that the best end-to-end path passing through D. This path could well use node X: MDSC doesn't care, as it doesn't know that= there is a policy installed in D the will ask to avoid that node. When the end-to-end path needs to be deployed the tunnel requested on D wil= l be created using a path avoding X, because the path creation is done by t= he controller of the domain D which is aware of and enforces that policy. But, being this path different from the one computed during the end-to-end = path computation, it could have different te-cost, igp-cost, latency and so= on, leading to end-to-end figures possibly not in compliance with the end-= to-end constraints. In my view, this is not acceptable. There are two ways to overcome this issue: * Requesting path computation to the domain D also during end-to-end pa= th computation. This is stateless path computation actually, and means that= abstract topology is useless (as we actully are renouncing to use it). * Exposing information about policies to the MDSC (or the client reques= ting end-to-end path computation). But this is still not enough: abstract t= opology should be also enhanced in order to take into account the possible = policies enforced. In this example we should have one (or more) abstract connectivity informat= ion for ingress-egress of D in case neither "igor" or "francesco" policies = are enforced, "igor" is enforced, "francesco" is enforced, "igor" and "fran= cesco" are enforced at once (e.g. asking a path having name "igor and franc= esco like ietf"). In this case policy information known to MDSC could be limited to the enabl= ing conditions, which should also be referred by the relevant abstract conn= ectivity, of course, so MDSC can select the right connectivity information. In the past we already had discussions about the scalability of the abstrac= t connectivity model, and basically the stateful model was born because thi= s very reason. The presence of policies makes the scalability issue even mo= re evident, multiplying each abstract link times the number of the combinat= ions of the installed policies in the domain. So, now we can: * Renounce at all to use policies (or provide for them a definition dif= ferent from RFC3060, please suggest). In this case not all the attributes p= resent in ietf-te are managed by ietf-te-path-computation are needed. * Use the policies and use only ietf-te-path-computation; this lead to = a deep revision of the entire ietf model of the traffic and topology, becau= se abstract connectivity information is no longer needed. * Go ahead with ietf-te plus these policies and face either wrong resul= ts or the "dragon" of scalability. My 2 cents Francesco From: Daniele Ceccarelli Sent: 27 July, 2018 8:29 AM Hi Igor, what you are describing is just one of the use cases. * Statefull path computation: I want the request/response to be guarant= eed along the same path returned via path computation response. * Stateless path computation: I don't really care about the path, I jus= t want to know that a path exists with given characteristics between A and = B. Here we're talking about stateless path computation. As I said before if a = H-PCE needs to find the best path across multiple domains and there are dif= ferent links/nodes that allow going from one domain to the other, the numbe= r of iterations between the H-PCE and the various PCE is huge, hence it sho= uld be very simple and in 99% of the cases who cares about an intra domain = path? The only thing that cares is that between two border nodes there are = X Gbps with given TE characteristics. Cheers Daniele From: Igor Bryskin = > Sent: gioved=EC 26 luglio 2018 16:50 Daniele, What is the point of path computation request / response if it can not be g= uaranteed, generally speaking, that a TE tunnel configured on a given netwo= rk will take the same path as returned via path computation response? The policies installed in the network are not expected to be known to all c= lients, but the policies could significantly influence on tunnel routing. All we are saying is that when the same information is passed for tunnel co= nfiguration and in path computation request for the tunnel in questuon, th= ere will be no reason for a path computation return one path, while the act= ual tunnel, when requested, taking a different one. Note also that all extra parameters we are talking about are optional and c= ould be omitted in path computation RPC if it is known, for example, from e= xperience that they do not affect the actual tunnel routing. Igor From:Daniele Ceccarelli Date:2018-07-26 05:54:16 Hi, >The question is: are there benefits in including in input of Path Computat= ion Request RPC also te-tunnel attributes without any foreseen recommended = usage by path computation engine? Absolutely no. Main reasons: 1. Policies might not be shared with the MDSC 2. Policies may be different from PNC to PNC 3. A high number of path computation results will be discarded (stateles= s path computation is needed also by the MDSC to understand what are the di= fferent options to get from a node in a domain to another node in a differe= nt domain and possibly through a number of other domains...hence a high num= ber of comination) 4. Last but not least simplification. BR Daniele From: Belotti, Sergio (Nokia - IT/Vimercate) > Sent: gioved=EC 26 luglio 2018 11:00 Hi all, After the discussion held during the last TEAS WG session in IETF102 and so= me offline talks, we are trying to summarize the questions that we need to = answer to resolve the open issue 31 (reference for background https://githu= b.com/rvilalta/ietf-te-path-computation/issues/31) . The question is: are there benefits in including in input of Path Computati= on Request RPC also te-tunnel attributes without any foreseen recommended u= sage by path computation engine? For example this is the case of administra= tion attributes such as 'tunnel description' or of those attributes that ar= e relevant only for the provisioning phase e.g provisioning-state... Please= consider that the question is in the scope of a 'Stateless-Path-Computatio= n' service: no state or data is saved by PCE after RPC output is returned t= o the client. One of the main use case for the Path Computation RPC design is to support = multi domain path computation. In this case the MDSC (the RPC client) addre= sses to a PNC (the RPC server) a request to compute a path within the PNC n= ative/controlled topology during the quest for a multi-domain path at a giv= en time T1; at a later time T2 (once, for example, the e2e path is identifi= ed) MDSC requests southbound to PNC per domain Tunnel setup (the segments o= f the multi-domain tunnel) with either the same or different metrics and co= nstraints (MDSC implementation decision), to guarantee that the PNC would s= etup a path equivalent or better than the one computed at time T1. Example: the MDSC computes a multi-domain end-to-end path between points A = and Z and selects a path having te-metric 100. The path A-Z passes through = the domain controlled by PNC X, entering in B and exiting in C, for which= path computation RPC has returned a B-C path with te-metric 20. When askin= g PNC X to setup the path B-C, a constraint on te-metric must be provided = in order to avoid PNC X finding a suitable path satisfying all the other co= nstraints of the end-to-end path but with te-metric higher than 20. If a di= fferent path is found with a metric < 20, that's fine. So, it's not essenti= al that the same identical path is produced at the second path computation.= The only requirement is on its metrics. Depending on the abstraction level applied by the domain controller the cl= ient may never know the actual computed path: the only important requiremen= t is that the path metrics and constraints are met. Therefore it is not necessary to guaranteed that the path setup at time T2 = is exactly the same as the path computed at time T1 but only that it has th= e same or better metrics. Regarding the policies, it has been said in the ietf meeting (see the relev= ant transcript) that they allow a "private" behavior of the server triggere= d by a condition depending possibly on any attribute of the tunnel request.= This actually prevents a client application to perform autonomously the en= d-to-end path computation (e.g. using detailed connectivity matrix), as it = doesn't know how each domain will behave when recomputing the tunnel for de= ployment (and so applying policies the client doesn't know and which could = be even different for different domains). In order to prevent this, policies should be explicitly shared with the cli= ents, and be included in the detailed connectivity matrix information expos= ed by each domain to take into account not only the possible alternative pa= th computation parameters, but also all the possible combinations of applic= able policies. The client shall then select the suitable detailed connectiv= ity matrix taking into account both the path computation parameters AND the= applicable policies. When such policy attributes are defined, they will be included in the path = computation RPC. Italo and Sergio (on behalf of co-authors/contributors) Sergio Belotti Senior System Engineer and Standardization Architect IP/Optical Networks, Optics BU Nokia M: +39-335761776 Via Energy Park, 20871 Vimercate (MB) , Italy sergio.belotti@nokia.com _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas --_000_AM5PR0701MB272350A8E3646F3CF724844191250AM5PR0701MB2723_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Julien,

we think your reply, in line with Adrian’= s desire, is in favor of an alignment between PCEP and Yang models.

We have found 4 possible types of differences b= etween YANG models and PCEP:

  1. Features defined in PCEP but missing in YANG models
  2. Features defined in YANG models but missing in PCEP
  3. Features supported by both but in different and incompatible way=
  4. Features supported by both but with some differences which appear more inhe= rent to protocol characteristics of NETCON/RESTCONF with PCEP which can be = reconciled from an implementation perspective.

We can prepare a detailed list of the differenc= es if you think it is valuable.

A typical case in which a feature is differentl= y implemented on the YANG model and PCEP is related to the support of manda= tory/optional (relaxable) constraints.

PCEP offers the possibility to decide whether a= constraint (almost any object actually in PCEP) must be considered by the = path computation or may be ignored. TE-tunnel model has a different mechanism to provide similar feature with an ordered= list of paths computed with different constraints and then the possibility= to choose one or the other depending of optimization purpose.

Do you think we need to reconcile this differen= ce?

Thanks

Carlo, Francesco, Sergio

 

 

From:= Julien Meuric <julien.meuric@orange.co= m>
Sent: Monday, July 30, 2018 4:39 PM
To: Igor Bryskin <Igor.Bryskin@huawei.com>; adrian@olddog.co.u= k; Beller, Dieter (Nokia - DE/Stuttgart) <dieter.beller@nokia.com>; '= Francesco Lazzeri' <francesco.lazzeri@ericsson.com>; 'Daniele Ceccare= lli' <daniele.ceccarelli@ericsson.com>; Belotti, Sergio (Nokia - IT/Vimercate) <sergio.belotti@nokia.com>; teas@ietf.org; te= as-chairs@ietf.org
Cc: Scharf, Michael (Nokia - DE/Stuttgart) <michael.scharf@nokia.= com>; vlopez@tid.es; oscar.gonzalezdedios@telefonica.com; 'Carlo Perocch= io' <carlo.perocchio@ericsson.com>; Leeyoung <leeyoung@huawei.com&= gt;; Karthik.Sethuraman@necam.com; ansha@google.com; ricard.vilalta@cttc.es; shiyan49@chinaunicom.cn; Italo Busi <Italo.Busi= @huawei.com>
Subject: Re: [Teas] draft-ietf-teas-yang-path-computation-02 : path = computation stateless RPC attributes

 

Hi Igor,

FWIW, the PCE WG would welcome your contribution to allocate a codepoint fo= r a PCEP Object Functions saying "The order of the attached METRIC and= IRO objects express relative preference". If your implementation does= n't want to go through the standard process, there are 32768 values "reserved for private use".

Whatever the feature to address, I really wish that multiplying the number = of technical means to express it would increase the number of implementatio= ns supporting it, unfortunately that is not how it works. Operator's hat on= , if your implementation allows to express your example using a proprietary interface, I'd be happy to wri= te to piece of code to integrate it into my favorite communication mean.
My 2 cents,

Julien

Jul. 27, 2018 - Igor.Bryskin@huawei.com:

Hi Adrian,=

 

To say that we cannot = do a stateless path computation better than what could be done using PCEP t= oday is a bit too bold IMUO. Why then we keep working on PCEP enhancements?= ;-)

 

One example: today, us= ing the TE tunnel model, a client can request (and I know servers that impl= ement) a customized (client controlled) weighted multi-criteria optimizatio= n for path selection, specifying any subset of model defined metrics. For example, the client can ask for a bes= t possible compromise between, say, TE e2e cost, delay and following as muc= h as possible a specific explicit path, assigning a relative weight/importa= nce to each of the three criteria. AFAIK this is not possible to do with PCEP today.

 

Cheers,

Igor   

 

 

From: Adrian Farrel [mailto:adrian@olddo= g.co.uk]
Sent: Friday, July 27, 2018 2:30 PM

 

I've ha= d several off-line conversations with a number of you where I have learned = a lot about the use cases and desires that are driving this work.

 <= /span>

However= , (there he goes spoiling the effect!) I see nothing in the use cases that = could not be addressed using PCEP (if PCEP were implemented in those scenar= ios) so it makes me think that we should generalise (as we should do in many cases, anyway). That is, we should mak= e our YANG model carry exactly the same information as a PCEP computation r= equest/response, and for the same reasons.

 <= /span>

Some of= that information should be part of the base model and some should be in au= gmentations, but I don't suppose we should leave stuff out.

 <= /span>

The deb= ate about how fields like "tunnel name" are used does not serve u= s well, I believe. That in some environments there is information encoded i= n these fields so that the PCC can communicate to the PCE the purpose of the path computation is (of course) a implementatio= n/deployment thing. That it can be useful to a PCE, looking at the LSPs ins= talled in the network, to match them against the computations it performed = may be incidental to this discussion. My point is that the parameters are there in PCEP, they may have found var= ious uses, and the YANG model is supposed to model the PCEP requests.

 <= /span>

I have = yet to be convinced of the desirability of leaving things out. And I don't = see the harm of including stuff.

 <= /span>

Adrian<= /span>

 <= /span>

From: Teas [mailto:teas-bounces@ietf.o= rg] On Behalf Of Dieter Beller
Sent: 27 July 2018 16:22

 

Hi all,

I concur with the comments from Francesco and Daniele below as well as with= those from Michael.

We discussed this issue at length in Montreal after the CCAMP session and I= would like to emphasize again that I am having reservations about policies= being
applied by a path computation engine based on attributes that are provided = as input to path computation, which have absolutely nothing to do with poli= cy
rules as they were defined for totally other purposes! We called that hidde= n policies in our discussion.


Thanks,
Dieter


On 27.07.2018 10:16, Francesco = Lazzeri wrote:

I believe that the main point f= or deciding whether all the parameters (including name, description and so = on) are needed or not for stateless path computation is the adoption of pol= icies.

When I think about policies, I = go to the definitions present in RFC3060, where policy information model is= described.

According to 3060, basically po= licies are a (set of) rules where each rule is defined by enabling conditio= ns (boolean expressions that “enable” the policy actions as soo= n as they become true) and policy actions (the behavior of the policy).

If we introduce this concept in= path computation we could think for example to create two policies for a g= iven domain D:

 

  • The first one is enabled when the tunnel description contains the strin= g “igor”, and the relevant action is avoiding the node X inside= the relevant domain.
  • The second one is enabled= when the tunnel description con contains the string “francesco”= ;, and the levant action is avoiding the node Y inside the relevant domain.=

 

Let suppose we don’t want= to use stateless path computation (e.g. the domain is “white”,= so we have full topology information about it, or, if domain is “bla= ck” or “gray”,  we just use its abstract connectivit= y).

We are asking for a new tunnel = with description “igor”.

Assuming the client (MDSC) know= s nothing about those policies, it does path computation end-to-end using t= he topology information it collected,  and find that the best end-to-e= nd path passing through D.

This path could well use node X= : MDSC doesn’t care, as it doesn’t know that there is a policy = installed in D the will ask to avoid that node.

When the end-to-end path needs = to be deployed the tunnel requested on D will be created using a path avodi= ng X, because the path creation is done by the controller of the domain D w= hich is aware of and enforces that policy.  

But, being this path different = from the one computed during the end-to-end path computation, it could have= different te-cost, igp-cost, latency and so on, leading to end-to-end figu= res possibly not in compliance with the end-to-end constraints.

In my view, this is not accepta= ble.

 

There are two ways to overcome = this issue:

 

  • Requesting path computation to the domain D also during end-to-end path= computation. This is stateless path computation actually, and means that a= bstract topology is useless (as we actully are renouncing to use it).
  • Exposing information = about policies to the MDSC (or the client requesting end-to-end path comput= ation). But this is still not enough: abstract topology should be also enha= nced in order to take into account the possible policies enforced.
    In this example we should have one (or more) abstract connectivity informat= ion for ingress-egress of D in case neither “igor” or “fr= ancesco” policies are enforced, “igor” is enforced, ̶= 0;francesco” is enforced, “igor” and “francescoR= 21; are enforced at once (e.g. asking a path having name “igor and francesco like ietf”). In this case policy information known to MDSC could be limited to the enabl= ing conditions, which should also be referred by the relevant abstract conn= ectivity, of course, so MDSC can select the right connectivity information.=

 =

In the past we already had disc= ussions about the scalability of the abstract connectivity model, and basic= ally the stateful model was born because this very reason. The presence of = policies makes the scalability issue even more evident, multiplying each abstract link times the number of the = combinations of the installed policies in the domain.

 

So, now we can:

 

  • Renounce at all to use policies (or provide for them a definition diffe= rent from RFC3060, please suggest). In this case not all the attributes pre= sent in ietf-te are managed by ietf-te-path-computation are needed.
  • Use the policies and use only ietf-t= e-path-computation; this lead to a deep revision of the entire ietf model o= f the traffic and topology, because abstract connectivity information is no longer needed.
  • Go ahead with ietf-te plus th= ese policies and face either wrong results or the “dragon” of s= calability.

 

My 2 cents

Francesco

 

 

From: Daniele Ceccarelli
Sent: 27 July, 2018 8:29 AM

 

Hi Igor,

 

what you are describing is just= one of the use cases.

 

  • Statefull path computation: I want the request/response to be guarantee= d along the same path returned via path computation response.
  • Stateless path computation: I don’t really care about th= e path, I just want to know that a path exists with given characteristics b= etween A and B.

 

Here we’re talking about = stateless path computation. As I said before if a H-PCE needs to find the b= est path across multiple domains and there are different links/nodes that a= llow going from one domain to the other, the number of iterations between the H-PCE and the various PCE is huge, hence = it should be very simple and in 99% of the cases who cares about an intra d= omain path? The only thing that cares is that between two border nodes ther= e are X Gbps with given TE characteristics.

 

Cheers

Daniele 

 

From: Igor Bryskin <Igo= r.Bryskin@huawei.com>
Sent: gioved=EC 26 luglio 2018 16:50

 

Daniele,
What is the point of path computation request / response if it can not be g= uaranteed, generally speaking, that a TE tunnel configured on a given netwo= rk will take the same path as returned via path computation response?
The policies installed in the network are not expected to be known to all c= lients, but the policies could significantly  influence  on tunne= l routing.
All we are saying is that when the same information is passed for tunnel co= nfiguration and in path computation request for the tunnel  in questuo= n, there will be no reason for a path computation return one path, while th= e actual tunnel, when requested,  taking  a different one.
Note also that all extra parameters we are talking about are optional and c= ould be omitted in path computation RPC if it is known, for example, from e= xperience that they do not affect the actual tunnel routing.

Igor

From:Daniele Ceccarelli

Date:2018-07-26 05:54:16

 

Hi,

 

>The question is: are there benefits= in including in input of Path Computation Request RPC also te-tunnel attri= butes without any foreseen recommended usage by path computation engine?

 

Absolutely no.

 

Main reasons:=

  1. Policies might not be shared with the MDSC
  2. Po= licies may be different from PNC to PNC
  3. A high nu= mber of path computation results will be discarded (stateless path computat= ion is needed also by the MDSC to understand what are the different options= to get from a node in a domain to another node in a different domain and possibly through a number= of other domains…hence a high number of comination)
  4. Last but not least simplification.

 

BR
Daniele 

 

From: Belotti, Sergio (Nokia - IT/Vimercate) <sergio.belotti@nokia..com>
Sent: gioved=EC 26 luglio 2018 11:00

 

Hi all,

 

After the = discussion held during the last TEAS WG session in IETF102 and some offline= talks, we are trying to summarize the questions that we need to answer to resolve the open issue 31 (reference for background <= a href=3D"https://github.com/rvilalta/ietf-te-path-computation/issues/31"> https://github.com/rvilalta/ietf-te-path-computation/issues/31) .

 

The questi= on is: are there benefits in including in input of Path Computation Request= RPC also te-tunnel attributes without any foreseen recommended usage by path computation engine? For example this is the case= of administration attributes such as 'tunnel description' or of those attr= ibutes that are relevant only for the provisioning phase e.g provisioning-s= tate... Please consider that the question is in the scope of a 'Stateless-Path-Computation' service: no sta= te or data is saved by PCE after RPC output is returned to the client. = ;

 

One of the= main use case for the Path Computation RPC design is to support multi doma= in path computation. In this case the MDSC (the RPC client) addresses to a PNC (the RPC server) a request to compute a path wi= thin the PNC native/controlled topology during the quest for a multi-domain= path at a given time T1; at a later time T2 (once, for example, the e2e pa= th is identified) MDSC requests southbound to PNC per domain Tunnel setup (the segments of the multi-domai= n tunnel) with either the same or different metrics and constraints (MDSC i= mplementation decision), to guarantee that the PNC would setup a path equiv= alent or better than the one computed at time T1.

 

Example: t= he MDSC computes a multi-domain end-to-end path between points A and Z and = selects a path having te-metric 100. The path A-Z passes through the  domain controlled by PNC  X, entering in B a= nd exiting in C, for which path computation RPC has returned a B-C path wit= h te-metric 20. When asking  PNC X to setup the path B-C, a constraint= on te-metric must be provided in order to avoid PNC X finding a suitable path satisfying all the other constraints of the = end-to-end path but with te-metric higher than 20. If a different path is f= ound with a metric < 20, that's fine. So, it's not essential that the sa= me identical path is produced at the second path computation. The only requirement is on its metrics.

 

 Depe= nding on the abstraction level applied by the domain controller the client = may never know the actual computed path: the only important requirement is that the path metrics and constraints are met.<= /o:p>

Therefore = it is not necessary to guaranteed that the path setup at time T2 is exactly= the same as the path computed at time T1 but only that it has the same or better metrics.

 

Regarding = the policies, it has been said in the ietf meeting (see the relevant transc= ript) that they allow a "private" behavior of the server triggered by a condition depending possibly on any attribute of the= tunnel request. This actually prevents a client application to perform aut= onomously the end-to-end path computation (e.g. using detailed connectivity= matrix), as it doesn't know how each domain will behave when recomputing the tunnel for deployment (and so= applying policies the client doesn't know and which could be even differen= t for different domains). 

In order t= o prevent this, policies should be explicitly shared with the clients, and = be included in the detailed connectivity matrix information exposed by each domain to take into account not only the possible alternat= ive path computation parameters, but also all the possible combinations of = applicable policies. The client shall then select the suitable detailed con= nectivity matrix taking into account both the path computation parameters AND the applicable policies. 

When such policy attributes are defined= , they will be included in the path computation RPC.

 

Italo and Sergio (on behalf of = co-authors/contributors)

 

Sergio = Belotti

Senior = System Engineer and Standardization Architect

IP/Opti= cal Networks, Optics BU

Nokia <= /span>

M: +39= -335761776

Via Energy= Park, 20871 Vimercate (MB) , Italy

sergio.belotti@nokia.com

 

 <= /p> 




_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.iet=
f.org/mailman/listinfo/teas

 

--_000_AM5PR0701MB272350A8E3646F3CF724844191250AM5PR0701MB2723_-- From nobody Sun Aug 12 14:46:18 2018 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C4F130E48; Sun, 12 Aug 2018 14:46:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: lberger@labn.net, teas-chairs@ietf.org, db3546@att.com, teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153411037639.11801.16155601088469834477.idtracker@ietfa.amsl.com> Date: Sun, 12 Aug 2018 14:46:16 -0700 Archived-At: Subject: [Teas] teas - New Meeting Session Request for IETF 103 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.27 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2018 21:46:16 -0000 A new meeting session request has just been submitted by Lou Berger, a Chair of the teas working group. --------------------------------------------------------- Working Group Name: Traffic Engineering Architecture and Signaling Area Name: Routing Area Session Requester: Lou Berger Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: mpls ccamp pce netmod detnet Second Priority: idr i2rs spring lsr Third Priority: pals bess nvo3 People who must be present: Lou Berger Deborah Brungard Vishnu Pavan Beeram Resources Requested: Special Requests: Other Conflicts: IRTF RRG, RTG BOFs --------------------------------------------------------- From nobody Tue Aug 14 12:16:54 2018 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 409BA124BE5; Tue, 14 Aug 2018 12:16:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liaison Statement Management Tool To: <3GPPLiaison@etsi.org> Cc: TEAS Discussion List , l2sm-chairs@ietf.org, rtg-ads@ietf.org, teas-chairs@ietf.org, Adrian Farrel , DetNet Discussion List , detnet-chairs@ietf.org, ops-ads@ietf.org, Qin Wu , zoulan@huawei.com, L2VPN Service Model Discussion List X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153427420818.27176.13203359648572620433.idtracker@ietfa.amsl.com> Date: Tue, 14 Aug 2018 12:16:48 -0700 Archived-At: Subject: [Teas] New Liaison Statement, "Further Information About IETF Work Relevant to Network Slicing" X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.27 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2018 19:16:48 -0000 Title: Further Information About IETF Work Relevant to Network Slicing Submission Date: 2018-08-14 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1595/ From: Adrian Farrel To: 3GPPLiaison@etsi.org Cc: zoulan@huawei.com,Adrian Farrel ,Qin Wu ,l2sm-chairs@ietf.org ,teas-chairs@ietf.org ,detnet-chairs@ietf.org ,ops-ads@ietf.org ,rtg-ads@ietf.org ,DetNet Discussion List ,L2VPN Service Model Discussion List ,TEAS Discussion List Response Contacts: Adrian Farrel ,Qin Wu Technical Contacts: Adrian Farrel ,Qin Wu Purpose: In response Referenced liaison: Reply LS on IETF work related to the management and orchestration of network slicing (https://datatracker.ietf.org/liaison/1588/) Body: Thank you for your liaison statement "Reply LS on IETF work related to the management and orchestration of network slicing" from 3GPP-TSG-SA-WG5 dated 7/23/18. This has been passed to the chairs of the IETF's L2SM working group to coordinate a response. Our understanding of the 3GPP's definition of a "Transport Network" is that it covers any network that underlies and provides connectivity for 3GPP networks or services. There are, of course, many other definitions of "Transport Network" so it is important that we are clear on this. The IETF works on IP and MPLS dataplane technologies as well as higher layer encapsulations such as UDP, TCP, and HTTP all of which may be applicable to your requirements. Additionally, the IETF works on control and management plane specifications applicable to all technology layers including IP and sub-IP transport networks. You may be interested in the work of the DetNet working group [1] which is collaborating with the IEEE802.1 TSN task group to develop mechanisms to provide deterministic data paths that operate over Layer 2 bridged and Layer 3 routed segments, where such paths can provide bounds on latency, loss, and packet delay variation (jitter), and high reliability. These features may prove to be particularly useful in supporting connectivity (or slices) for 5G services. The DetNet Architecture is largely complete and is described in [2]. DetNet's use of the IP [3] and MPLS [4] date planes is still being defined in the working group. You may also be interested in early work on configuration control in [5]. With regard to your specific enquiry about management interfaces there are several layers of interaction that you should consider: - The L2VPN and L3VPN service models ([6] and [7]) are intended to allow a customer to request a VPN connectivity service from an operator. These models may be used as a 'paper procedure' allowing a common format for service requests, or may facilitate automation so that one software component may make requests to another component responsible for orchestrating the underlying network. The services described by these two models would normally be provided by IP or MPLS networks, but the details of how the service is provided are deliberately out of scope. Thus, direct control of transport resources do not fall within the scope of these service models. What is in scope are the points of attachment (connection end points), the type of attachment circuit, and the quality of connectivity that is required (such as bandwidth and quality of service). The way that service models fit into the management of networks is described in RFC 8309 [8]. - VPN delivery models are being specified in the BESS working group [9]. These models allow an operator to manage a network for the delivery of a VPN connectivity service, and would normally be provided by IP or MPLS networks. These models describe the details of how the service is implemented within the network. Examples include the YANG Data Model for MPLS-based L2VPN [10], the YANG Data Model for BGP/MPLS L3 VPNs [11], and the YANG Data Model for EVPN [12]. - The TEAS working group [13] is developing a YANG model for the configuration and management of Traffic Engineering (TE) interfaces, tunnels and Label Switched Paths (LSPs) [14]. While this is a service delivery model, it closely matches the corresponding service model for 'connectivity as a service'. - The TEAS working group is also working on the Abstraction and Control of Traffic Engineered Networks (ACTN) [15]. This approach allows a network user to request and manipulate 'topology' in the form of a virtual network and is accessed through YANG models such as [16] and [17]. This is applicable to all forms of traffic engineered network from MPLS through Ethernet, TDM, and OTN, to WDM. Virtual network creation and operation may be similar to 'network slicing' that you describe: this is discussed in an individual contribution Internet-Draft [18], while a further individual document [19] describes an architecture for data model driven network management of virtual networks. Further dialogue is needed around the topic of traffic isolation in network slicing in particular with respect to its application to shared packet or frame networks. The IETF has developed techniques to protect against misdelivery of traffic and to secure customer traffic as it is transmitted over the network. Similarly, there are protocol mechanisms to reserve and dedicate network resources to specific traffic flows or to provide statistical accounting that, combined with traffic policing, ensure that network resources are not over-committed. Nevertheless, it has to be understood that packet and frame networks are essentially shared-media networks where separation or isolation of traffic is logical not physical. It is often hard to provide a firm roadmap for delivery of IETF specifications as the work only completes when it is technically sound and has sufficient consensus for publication: it is not tied to any formal schedule. However, we can suggest the following information: - [2] Still needs work: may be an RFC within 12 months - [3] Unknown timing - [4] Unknown timing - [5] Unknown timing - [6] Complete and in RFC Editor processing: likely to be an RFC within two months - [7] Already an RFC - [8] Already an RFC - [10] Still needs work: may be an RFC within 12 months - [11] Still needs work: may be an RFC within 12 months - [12] Still needs work: may be an RFC within 12 months - [14] Still needs work: may be an RFC within 6 months - [15] Complete and in RFC Editor processing: likely to be an RFC within two months - [16] Still needs work: may be an RFC within 6 months - [17] Still needs work: may be an RFC within 6 months - [18] Unknown timing - [19] Unknown timing Best regards, Adrian Farrel and Qin Wu (IETF L2SM Working Group chairs) [1] https://datatracker.ietf.org/wg/detnet/about/ [2] https://tools.ietf.org/html/draft-ietf-detnet-architecture [3] https://tools.ietf.org/html/draft-ietf-detnet-dp-sol-ip [4] https://tools.ietf.org/html/draft-ietf-detnet-dp-sol-mpls [5] https://tools.ietf.org/html/draft-geng-detnet-conf-yang [6] https://www.ietf.org/id/draft-ietf-l2sm-l2vpn-service-model-10.txt [7] https://www.rfc-editor.org/rfc/rfc8299.txt [8] https://www.rfc-editor.org/rfc/rfc8309.txt [9] https://datatracker.ietf.org/wg/bess/about/ [10] https://www.ietf.org/id/draft-ietf-bess-l2vpn-yang-08.txt [11] https://www.ietf.org/id/draft-ietf-bess-l3vpn-yang-03.txt [12] https://www.ietf.org/id/draft-ietf-bess-evpn-yang-05.txt [13] https://datatracker.ietf.org/wg/teas/about/ [14] https://www.ietf.org/id/draft-ietf-teas-yang-te-16.txt [15] https://www.ietf.org/id/draft-ietf-teas-actn-framework-15.txt [16] https://www.ietf.org/id/draft-ietf-teas-actn-yang-01.txt [17] https://www.ietf.org/id/draft-ietf-teas-actn-vn-yang-01.txt [18] https://www.ietf.org/id/draft-king-teas-applicability-actn-slicing-03.txt [19] https://www.ietf.org/id/draft-wu-model-driven-management-virtualization-01.txt Attachments: Microsoft Word version of this LS https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-08-14-l2sm-3gpp-tsg-sa-wg5-further-information-about-ietf-work-relevant-to-network-slicing-attachment-1.doc From nobody Tue Aug 14 19:14:44 2018 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B637130EF7 for ; Tue, 14 Aug 2018 19:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ieee-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCu4Gw27y4MA for ; Tue, 14 Aug 2018 19:14:40 -0700 (PDT) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A931130EF5 for ; Tue, 14 Aug 2018 19:14:40 -0700 (PDT) Received: by mail-pg1-x536.google.com with SMTP id k3-v6so9951918pgq.5 for ; Tue, 14 Aug 2018 19:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=jxm/5OSgfZOmCdAG9XMtHM/voRI0E+YjASJCLxbHrCE=; b=CpO+cva+0rn5OuLVGxyLifW32QOU/nlNBCuxDVdrD8UqeLGifJA0iVUShxcs32piGH VbJvQaebhxX8JCw9727jvxxmtE3NWCpEuYSqrwYhI8ijSZ9/H5KkX0D8cYLZ2A4tpZmC WOMWOboBYeUP1I+9X9Fm4DDvMABHivdQ/4TbEHwXxCsVFVkSZ7gfENmGjSd03Th63T+x P4Np0WbQoPr+ViW+o7peTalGNqNRM0TQJmSKl7Ret+QxGq696ealu6ihEL8jIAwjNdzO rHaiEu00ukDPn4xopQxLcQ2OxYn+ZM+9sCZ+GPR49c4umm0RbEvWaFOV8gA+2w/oEAeH vPVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jxm/5OSgfZOmCdAG9XMtHM/voRI0E+YjASJCLxbHrCE=; b=Cw7qhbSmEAy0h+i0+bzNDfsx6rEGvPbfsBiKqwbTzZFyLwiYHW7q7kgUsW4zushgpH zH2OEvixfdSn6iHwmfDsDxyyiGKpHLilk/MRhtpFnY0LIXx7IJdOX5LT3Eh/kjIszp1z gWO8plOBAWDxPzKuzWoItgWfePFy5FieSvU8wkB/U8V7jMiVryHQoHLNy3r2hi4j9RC9 OQzHcFRUPXYoQoMKmMYq0WlUPKxZSrcK19mJ7LwgJHWUDlByxwJbhjTZy8SwZhew6SzV SJ/nULEHaBEpjy5OWLCWneUN+EzkqlQOCuWYFeJx9keiDQ/npRnqXorjGcGFT0uupmQZ TaXw== X-Gm-Message-State: AOUpUlGDWdpsOCJDNVtX/EVp6Z4R0XUp7YOrfjz39VID5lxT2ZE0+B+T XsZb6meVs/7+R3BiVo+fWSyHVBHntRg= X-Google-Smtp-Source: AA+uWPwC0dj8Q25NhuoLk6zq16HGsAHCbTlOrKU8f9vXQk61K0lMXBY8vXFfZvFhxingM6K7TEu8pQ== X-Received: by 2002:a63:f:: with SMTP id 15-v6mr23376915pga.430.1534299279913; Tue, 14 Aug 2018 19:14:39 -0700 (PDT) Received: from [192.168.1.251] ([131.113.102.193]) by smtp.googlemail.com with ESMTPSA id q140-v6sm33657439pgq.11.2018.08.14.19.14.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Aug 2018 19:14:38 -0700 (PDT) References: To: teas@ietf.org From: Satoru OKAMOTO X-Forwarded-Message-Id: Message-ID: <7e64196c-223a-e728-9284-2527db7f2324@ieee.org> Date: Wed, 15 Aug 2018 11:14:34 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Teas] Call for Presentation - Net-Centric 2018 is extended to Aug. 24. X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 02:14:42 -0000 Presentation proposal deadline of Net-Centric 2018 is extended to Aug. 24. [Apologies, if you receive multiple copies of this CFP] --------------------------------------- Call for Presentation Abstract Proposal is Now up at http://www.isocore.com/2018/cfp.php Submission due date is extended to August 24, 2018! Please submit your abstracts to cfp2018@isocore.com Isocore's 2018 International Conference, the 21st Annual event on new networking technologies will be held October 7-9, 2018, in Washington DC area. Please see at http://www.isocore.com/2018/ This year, the overarching themes of the conference will be on Edge Clouds and Data Center Technologies, Machine Leaning for Network Management & Optimization of Emerging Networks, Open Source Platforms and Technologies, Virtualization and Network Automation Technologies, SDN & NFV for Enterprise Networks, and Advanced Programmable Hardware and Applications. The conference Program Committee is soliciting presentation proposals seeking original and unpublished work to continue the tradition initiated by this conference in 1998 of covering cutting-edge topics. Presentations addressing new technologies and operational experience are solicited from network equipment vendors, service providers, the research community, government agencies, and enterprise users. Please submit your abstracts to cfp2018@isocore.com Satoru Okamoto, Keio University Tom Tofigh, AT&T Net-Centric 2018 TPC Co-chairs From nobody Wed Aug 15 05:07:16 2018 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A292C130DBE for ; Wed, 15 Aug 2018 05:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORP12lNyrlpO for ; Wed, 15 Aug 2018 05:07:13 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BE5F127148 for ; Wed, 15 Aug 2018 05:07:13 -0700 (PDT) Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 6AC09E4F2141B for ; Wed, 15 Aug 2018 13:07:05 +0100 (IST) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 15 Aug 2018 13:07:06 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.206]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0399.000; Wed, 15 Aug 2018 20:07:01 +0800 From: "Dongjie (Jimmy)" To: TEAS Discussion List Thread-Topic: New Version Notification for draft-dong-teas-enhanced-vpn-01.txt Thread-Index: AQHUNI7kQqcww/2Ai0aMiCfTe/rENaTAtM/Q Date: Wed, 15 Aug 2018 12:07:01 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927A776D4A2@NKGEML515-MBS.china.huawei.com> References: <153433413455.14468.3674985423844109755.idtracker@ietfa.amsl.com> In-Reply-To: <153433413455.14468.3674985423844109755.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.151.75] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Teas] FW: New Version Notification for draft-dong-teas-enhanced-vpn-01.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 12:07:15 -0000 SGkgYWxsLCANCg0KQSBuZXcgcmV2aXNpb24gb2YgZHJhZnQtZG9uZy10ZWFzLWVuaGFuY2VkLXZw bi0wMSBpcyBzdWJtaXR0ZWQgdG8gcmVzb2x2ZSB0aGUgY29tbWVudHMgcmVjZWl2ZWQgYm90aCBv biBJRVRGIG1lZXRpbmcgYW5kIG9mZmxpbmUuIA0KDQpUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGEg ZnJhbWV3b3JrIG9mIGVuaGFuY2VkIFZQTiwgd2hpY2ggY291bGQgYmUgdXNlZCBmb3IgbmV0d29y ayBzbGljaW5nLiBUaGUgU1IgYmFzZWQgc29sdXRpb24gYW5kIHByb3RvY29sIGV4dGVuc2lvbnMg YXJlIHNwZWNpZmllZCBpbiBhY2NvbXBhbnlpbmcgZG9jdW1lbnRzIGluIFNQUklORyBhbmQgTFNS IFdHIHJlc3BlY3RpdmVseS4gDQoNCk1vcmUgY29tbWVudHMgYXJlIGFwcHJlY2lhdGVkLiANCg0K QmVzdCByZWdhcmRzLA0KSmllDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmdd IA0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMTUsIDIwMTggNzo1NiBQTQ0KVG86IERvbmdqaWUg KEppbW15KSA8amllLmRvbmdAaHVhd2VpLmNvbT47IFN0ZXdhcnQgQnJ5YW50IDxzdGV3YXJ0LmJy eWFudEBnbWFpbC5jb20+OyBUYWt1eWEgTWl5YXNha2EgPHRhLW1peWFzYWthQGtkZGkuY29tPjsg WmhlbnFpYW5nIExpIDxsaXpoZW5xaWFuZ0BjaGluYW1vYmlsZS5jb20+DQpTdWJqZWN0OiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWRvbmctdGVhcy1lbmhhbmNlZC12cG4tMDEu dHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWRvbmctdGVhcy1lbmhhbmNlZC12 cG4tMDEudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEppZSBEb25nIGFu ZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWRvbmctdGVh cy1lbmhhbmNlZC12cG4NClJldmlzaW9uOgkwMQ0KVGl0bGU6CQlBIEZyYW1ld29yayBmb3IgRW5o YW5jZWQgVmlydHVhbCBQcml2YXRlIE5ldHdvcmtzIChWUE4rKQ0KRG9jdW1lbnQgZGF0ZToJMjAx OC0wOC0xNQ0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMjYNClVSTDog ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZG9u Zy10ZWFzLWVuaGFuY2VkLXZwbi0wMS50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1kb25nLXRlYXMtZW5oYW5jZWQtdnBuLw0KSHRtbGl6 ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kb25nLXRlYXMtZW5o YW5jZWQtdnBuLTAxDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvaHRtbC9kcmFmdC1kb25nLXRlYXMtZW5oYW5jZWQtdnBuDQpEaWZmOiAgICAgICAgICAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWRvbmctdGVhcy1lbmhhbmNl ZC12cG4tMDENCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBhIGZyYW1l d29yayBmb3IgdXNpbmcgZXhpc3RpbmcsIG1vZGlmaWVkIGFuZA0KICAgcG90ZW50aWFsIG5ldyBu ZXR3b3JraW5nIHRlY2hub2xvZ2llcyBhcyBjb21wb25lbnRzIHRvIHByb3ZpZGUgYW4NCiAgIGVu aGFuY2VkIFZQTiAoVlBOKykgc2VydmljZS4gIFRoZSBwdXJwb3NlIGlzIHRvIGVuYWJsZSB2aXJ0 dWFsDQogICBwcml2YXRlIG5ldHdvcmtzIChWUE5zKSB0byBzdXBwb3J0IHRoZSBuZWVkcyBvZiBu ZXcgYXBwbGljYXRpb25zLA0KICAgcGFydGljdWxhcmx5IGFwcGxpY2F0aW9ucyB0aGF0IGFyZSBh c3NvY2lhdGVkIHdpdGggNUcgc2VydmljZXMuICBBDQogICBuZXR3b3JrIGVuaGFuY2VkIHdpdGgg dGhlc2UgcHJvcGVydGllcyBjYW4gZm9ybSB0aGUgdW5kZXJwaW5uaW5nIG9mDQogICBuZXR3b3Jr IHNsaWNpbmcsIGJ1dCB3aWxsIGFsc28gYmUgb2YgdXNlIGluIGl0cyBvd24gcmlnaHQuDQoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRo ZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5v cmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Mon Aug 20 01:56:38 2018 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B26130F25 for ; Mon, 20 Aug 2018 01:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=hjPu3mR7; dkim=pass (1024-bit key) header.d=ericsson.com header.b=XvAZNS2h 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 R-J2yFPhGNiw for ; Mon, 20 Aug 2018 01:56:22 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8601D130F1D for ; Mon, 20 Aug 2018 01:56:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1534755376; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=eKXAHF45eaQnajNE6nUVmz/0RroS7DqqfgqRS88RJ60=; b=hjPu3mR79FLwMzA18DZnuMtbeRd5SsEHAERisEaQQwg7ok2tTxItyOWjZxt6Zyhn 6EtGqQhbClPhjlE5mM8KFQLvQ4JOvAdY3kZ2mLp5Jc6zmAXIxtQOscN/ddWS5GR8 WWKWf4dP1zl+OH3CwloZ5atsAXaCEb6BKWleo+RG1mk=; X-AuditID: c1b4fb3a-baf5f9c00000680b-69-5b7a8230ad76 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id CD.2D.26635.0328A7B5; Mon, 20 Aug 2018 10:56:16 +0200 (CEST) Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 20 Aug 2018 10:56:09 +0200 Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 20 Aug 2018 10:56:09 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eKXAHF45eaQnajNE6nUVmz/0RroS7DqqfgqRS88RJ60=; b=XvAZNS2hafPG3yYCQVOVJ+iqRdH4WtGBjrKmgjb7uYtfKZgFfydP/fL/oxyemt83kJ92nFHN937Ro85r6spD3/TYWkWygoyug7MJiK6eLilNOwhfkuvHCuKHQvf2Yum9WPEeVywsHYRrXZlENhzR0sm/nR8jZNZ+Sf+69BeHclo= Received: from HE1PR07MB1675.eurprd07.prod.outlook.com (10.166.124.141) by HE1PR07MB3467.eurprd07.prod.outlook.com (10.170.247.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1080.11; Mon, 20 Aug 2018 08:56:07 +0000 Received: from HE1PR07MB1675.eurprd07.prod.outlook.com ([fe80::49ef:94ce:7c08:6201]) by HE1PR07MB1675.eurprd07.prod.outlook.com ([fe80::49ef:94ce:7c08:6201%5]) with mapi id 15.20.1080.010; Mon, 20 Aug 2018 08:56:07 +0000 From: Daniele Ceccarelli To: "Rakesh Gandhi (rgandhi)" , " (rtg-ads@ietf.org)" CC: "rtg-dir@ietf.org" , "TEAS WG (teas@ietf.org)" , "draft-ietf-teas-assoc-corouted-bidir-frr.all@ietf.org" Thread-Topic: RtgDir review: draft-ietf-teas-assoc-corouted-bidir-frr-04 Thread-Index: AdQlm/SWFN83nAOVQmKg2miyrumEwAChYgCAAc1HYgACQwcaIA== Date: Mon, 20 Aug 2018 08:56:07 +0000 Message-ID: References: <5A4119B4-94E1-4AD9-8300-39F27AE195F8@cisco.com> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com; x-originating-ip: [93.38.67.165] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB3467; 6:BY18tGBpAxM3hHVpyaSb2TCXXwY07NAHixB1nZvtY1ZOXI3+yDassKfQQMRqvuHnNL20KZ+3kzBP/fMWwQ0P9YzS3L9uzG6Ro55yyhdDqe3dBbuJARV+5ZsnVCx1a1ZPKVijvy/OFY/BY3UIqjfrxiybprWraSXhz6NtwHYYZdt7bWhRjrajHOthZYQtSj1dhd7ydhh3NIdmORmq/GV5QpGWM0zgRx3XSCqY+uBdflaNOpYY0q1FyVgP2dBOaCB15Bzz8kaqUQ6NQX1Wkj87Dy45YVdPJCBu/lZelaGdSmu2zrOQXrKSyUhfxTn2SDNGQBvOLQlSwLqsiHhjOTsdu0DHDxAQSEmRKsFqPwSwZw42EI6SNi25NWOaJ+P2xRzIrddRsOsv7jz+YPfQ2x8iFr8GL2mdc2mRVJW2kvTIht5nBdE9HWkWRmt2eGw4toe6VcjqnHM7fMNZVJdhvOfv2w==; 5:gWT1RjE7zeGF1oK1lOMueJ5DYd3PBLAw/g901EwyD6y+mnuOFOI3WPZwnTHSTJvDCU86gTusrBONUyp6z5HRqNPjZlTB8WS9dWbJTm0B4tcby7t1pgY8BUpgmJXEnWYloPqY6EQyc0Yw3eZoFzgYVdEavXoMSpSwmKG5Nl1woHw=; 7:3ikWIaw97Ex/iOB+17+u2Rnu35QjHn6ZAReGm8fl3EkoqD1e/p9ZjtGTbS+QXIJrqhD4w+qGimnQB0ca1Htn9vYM0G5sYT6jL1TTeS+vIEzSN53NFaTVK0XpbYcsw27k07SZlijp9B6+91XHXUdNvb+IP4fIK5nRXvXCAYtzscQ+CYBoKqcpqe3wPY5d6e8UYT7n93KyugXbsHIxz8ORug07No0gyGA14RAxmwalILGr3ayVl8KnU3YYGRa+vBL6 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 3873e27d-ee48-409a-0a08-08d6067ac483 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3467; x-ms-traffictypediagnostic: HE1PR07MB3467: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(28532068793085)(120809045254105)(138986009662008)(82608151540597)(85827821059158)(109105607167333)(195916259791689)(95692535739014)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231311)(944501410)(52105095)(10201501046)(93006095)(93001095)(3002001)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201708071742011)(7699016); SRVR:HE1PR07MB3467; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB3467; x-forefront-prvs: 0770F75EA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(39860400002)(366004)(346002)(376002)(51914003)(189003)(199004)(69234005)(33656002)(8676002)(81156014)(81166006)(105586002)(106356001)(2900100001)(66066001)(14454004)(966005)(110136005)(54906003)(6246003)(6506007)(53546011)(6116002)(25786009)(4326008)(790700001)(3846002)(316002)(5660300001)(44832011)(446003)(76176011)(11346002)(476003)(486006)(256004)(14444005)(5024004)(186003)(606006)(26005)(236005)(2906002)(7696005)(9686003)(54896002)(6306002)(55016002)(53946003)(229853002)(6436002)(7736002)(74316002)(8936002)(68736007)(53936002)(99286004)(102836004)(97736004)(5250100002)(86362001)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3467; H:HE1PR07MB1675.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: VoQg1Vot7r9dxWHLGN/vONndP0aq3wEAWZNKWIiQIOHgQy/Cfus+KUkBfo7jrTKKZq3acXPl1mcAXIoQGtfy9VZvFbg5Wgz17S3r9TqeZQehJzN138nQeSQ5CoinLHhc8QAI30gEwp9iyzLGi96VjvA8UUJdNG56Eqnq0HXuviCbydk+aB1wWR/2wmj0P1FyXWvQrJXDYM17Sz63YAnKMCyq28eaHLw+GECYIyoce03En6sCOtlz7QvDUq1CZBUEdDlOiCRhrFj+HLgwKTz6nDoBq2vicDnJRybwYkd59ScmWLkbvTxKX+SgtIQqL0dY0hTzZapOETX9FVnBfqT6uxDKBkIMO/8imDmNiHd8S1U= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR07MB1675ADC945508711D6F899CFF0320HE1PR07MB1675eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3873e27d-ee48-409a-0a08-08d6067ac483 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Aug 2018 08:56:07.0952 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3467 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHec85286Gw7ep+GCYOQpS8JIYDNNMP5RgQV9S0UKXHi9Mneyo 5Qqdg6UoopbLNk1NRpQZpijeNWdiCzOzJmKUaZpEX6qV17ScZ4Hffs/z/7/PjZcmJX08Dzoj O5dRZcszpXwRZYjrvuoXqFUnBJa0+8jK1j4QMr22lC+z1K+TsqbWZYFMt95DneZF1Wy186JM pg3iAhEvCk1hMjPyGVXAqSRReum0U45miLxWV/KU1KDODrIMCWnAwTD5YJNXhkS0BI8hqGmY ILhgFYFm0cDnAhMBFdW9pD2gcBUJ8z93HDY9Ae9WhykuWERQPNu6W42m+TgElszn7E1csRJ6 52x7TUhsQTDW9JKwe1zwWVjVhXOeKGiyNhIcR8Kz23/4dqbwUaivtFF2FuNLMDbWsccSbEbw uzzWzkIcBh2Gqb08wp5Q1d+M7Exid5hb4moCxmAaeO1Y2g2+ft7hcf4r0KbrcXgOQ9f0OMWx J0w3liP7zICHBKC9+YLPCX7wXa93FDoPd59vE5xpHME3/YxD8IVP642OBwqw3mnmcaZJBLVD pTxOOAQtFQtUFQo07puWYyXMTrxHxr2tD4DFsEQZdw9GYh9o6wvgLN5QU74g4PgY6OrvCfbn m5CgBbmxDMtmpQUF+TOqjGSWVWb7ZzO5HWj3R410boX0oJGVCDPCNJI6ibsK1QkSnjyfLcja PS1NSl3F1vWCBIk4RV6gZlTKRFVeJsOa0UGakrqLI1Nl8RKcJs9lFAyTw6j+qwQt9NAgfP+v csrZubB4a+S6V9iPooyVKX/oXlFEfJmfsBljRELr2/5HMT0ujyvXrF4B6oCyam/zQ8YnsTby zJuY5O3x2ujLRSmKhvCjoxctt47EpmZpfxk2E2OHnUj16En1iSRL7uSS9lWekIkcHIz2X5bH GRdsOR9TNwbqwoNvPJkJlVJsuvy4L6li5f8AM2HEdk0DAAA= Archived-At: Subject: Re: [Teas] RtgDir review: draft-ietf-teas-assoc-corouted-bidir-frr-04 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 08:56:26 -0000 --_000_HE1PR07MB1675ADC945508711D6F899CFF0320HE1PR07MB1675eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmFrZXNoLA0KDQp0aGFua3MgZm9yIHRoZSB1cGRhdGUuDQoNClRoZSB0ZXJtaW5vbG9neSBz ZWN0aW9uIGlzIGEgdmVyeSBtaW5vciBpc3N1ZXMsIHRoZSBpbXBvcnRhbnQgdGhpbmcgaXMgdGhh dCBpdCBpcyB0aGVyZS4gSSB3b3VsZCBwcmVmZXIgdG8gaGF2ZSBpdCBhdCB0aGUgYmVnaW5uaW5n IGFzIHNvbWV0aW1lcyBJIGZvdW5kIGl0IGhhcmQgdG8gcmVhZCB0aGUgaW50cm8gd2hlcmUgdGVy bXMgbm90IHlldCBkZWZpbmVkIHdlcmUgdXNlZC4NClBsZWFzZSBhbHNvIGFkZHJlc3MgdGhlIGNv bW1lbnQgZnJvbSBEZWJvcmFoIHRvIGFkZCBvbmUgb3IgdHdvIHNlbnRlbmNlcyB0byBzZWN0aW9u IDUgb24gd2hhdCBoYXBwZW5zIGlmIG9uZSBvZiB0aGUgbm9kZXMgZG9lcyBub3Qgc3VwcG9ydCB0 aGUgZmVhdHVyZS4NCg0KV2hlbiB0aGF0IGlzIGRvbmUgSeKAmW0gb2sgd2l0aCB0aGUgZG9jdW1l bnQuDQpUaGFua3MNCkRhbmllbGUNCg0KRnJvbTogUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkgPHJn YW5kaGlAY2lzY28uY29tPg0KU2VudDogbWVyY29sZWTDrCA4IGFnb3N0byAyMDE4IDIxOjMwDQpU bzogRGFuaWVsZSBDZWNjYXJlbGxpIDxkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tPjsg PHJ0Zy1hZHNAaWV0Zi5vcmc+IChydGctYWRzQGlldGYub3JnKSA8cnRnLWFkc0BpZXRmLm9yZz4N CkNjOiBydGctZGlyQGlldGYub3JnOyBURUFTIFdHICh0ZWFzQGlldGYub3JnKSA8dGVhc0BpZXRm Lm9yZz47IGRyYWZ0LWlldGYtdGVhcy1hc3NvYy1jb3JvdXRlZC1iaWRpci1mcnIuYWxsQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi10ZWFzLWFzc29jLWNv cm91dGVkLWJpZGlyLWZyci0wNA0KDQpIaSBEYW5pZWxlLA0KDQpGWUksIHdlIGhhdmUgdXBsb2Fk ZWQgdGhpcyB2ZXJzaW9uLiBQbGVhc2UgbGV0IHVzIGtub3cgaWYgeW91IGhhdmUgYWRkaXRpb25h bCBjb21tZW50cy4NCg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10 ZWFzLWFzc29jLWNvcm91dGVkLWJpZGlyLWZyci0wNQ0KDQpodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtdGVhcy1hc3NvYy1jb3JvdXRlZC1iaWRpci1mcnIt MDUNCg0KDQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBh dDoNCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdGVhcy1h c3NvYy1jb3JvdXRlZC1iaWRpci1mcnItMDUNCg0KDQoNClRoYW5rcywNClJha2VzaCAoZm9yIGF1 dGhvcnMpDQoNCg0KRnJvbTogIj1TTVRQOnJnYW5kaGlAY2lzY28uIGNvbSIgPHJnYW5kaGlAY2lz Y28uY29tPG1haWx0bzpyZ2FuZGhpQGNpc2NvLmNvbT4+DQpEYXRlOiBNb25kYXksIEp1bHkgMzAs IDIwMTggYXQgMTE6MjIgQU0NClRvOiBEYW5pZWxlIENlY2NhcmVsbGkgPGRhbmllbGUuY2VjY2Fy ZWxsaUBlcmljc3Nvbi5jb208bWFpbHRvOmRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb20+ PiwgIjxydGctYWRzQGlldGYub3JnPG1haWx0bzpydGctYWRzQGlldGYub3JnPj4gKHJ0Zy1hZHNA aWV0Zi5vcmc8bWFpbHRvOnJ0Zy1hZHNAaWV0Zi5vcmc+KSIgPHJ0Zy1hZHNAaWV0Zi5vcmc8bWFp bHRvOnJ0Zy1hZHNAaWV0Zi5vcmc+Pg0KQ2M6ICJydGctZGlyQGlldGYub3JnPG1haWx0bzpydGct ZGlyQGlldGYub3JnPiIgPHJ0Zy1kaXJAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1kaXJAaWV0Zi5vcmc+ PiwgIlRFQVMgV0cgKHRlYXNAaWV0Zi5vcmc8bWFpbHRvOnRlYXNAaWV0Zi5vcmc+KSIgPHRlYXNA aWV0Zi5vcmc8bWFpbHRvOnRlYXNAaWV0Zi5vcmc+PiwgImRyYWZ0LWlldGYtdGVhcy1hc3NvYy1j b3JvdXRlZC1iaWRpci1mcnIuYWxsQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLXRlYXMtYXNz b2MtY29yb3V0ZWQtYmlkaXItZnJyLmFsbEBpZXRmLm9yZz4iIDxkcmFmdC1pZXRmLXRlYXMtYXNz b2MtY29yb3V0ZWQtYmlkaXItZnJyLmFsbEBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi10ZWFz LWFzc29jLWNvcm91dGVkLWJpZGlyLWZyci5hbGxAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFJ0 Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtdGVhcy1hc3NvYy1jb3JvdXRlZC1iaWRpci1mcnItMDQN Cg0KSGkgRGFuaWVsZSwNCg0KTWFueSB0aGFua3MgZm9yIHRoZSByZXZpZXcgb2YgdGhlIGRvY3Vt ZW50IGFuZCB5b3VyIHN1Z2dlc3Rpb25zLg0KRGlmZiBmaWxlIGlzIGZvciB0aGUgdXBkYXRlZCBk b2N1bWVudCBpcyBhdHRhY2hlZC4NClBsZWFzZSBzZWUgaW5saW5lIDxSRz7igKYNCg0KRnJvbTog RGFuaWVsZSBDZWNjYXJlbGxpIDxkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tPG1haWx0 bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tPj4NCkRhdGU6IFNhdHVyZGF5LCBKdWx5 IDI4LCAyMDE4IGF0IDEwOjI4IEFNDQpUbzogIjxydGctYWRzQGlldGYub3JnPG1haWx0bzpydGct YWRzQGlldGYub3JnPj4gKHJ0Zy1hZHNAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1hZHNAaWV0Zi5vcmc+ KSIgPHJ0Zy1hZHNAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1hZHNAaWV0Zi5vcmc+Pg0KQ2M6ICJydGct ZGlyQGlldGYub3JnPG1haWx0bzpydGctZGlyQGlldGYub3JnPiIgPHJ0Zy1kaXJAaWV0Zi5vcmc8 bWFpbHRvOnJ0Zy1kaXJAaWV0Zi5vcmc+PiwgIlRFQVMgV0cgKHRlYXNAaWV0Zi5vcmc8bWFpbHRv OnRlYXNAaWV0Zi5vcmc+KSIgPHRlYXNAaWV0Zi5vcmc8bWFpbHRvOnRlYXNAaWV0Zi5vcmc+Piwg ImRyYWZ0LWlldGYtdGVhcy1hc3NvYy1jb3JvdXRlZC1iaWRpci1mcnIuYWxsQGlldGYub3JnPG1h aWx0bzpkcmFmdC1pZXRmLXRlYXMtYXNzb2MtY29yb3V0ZWQtYmlkaXItZnJyLmFsbEBpZXRmLm9y Zz4iIDxkcmFmdC1pZXRmLXRlYXMtYXNzb2MtY29yb3V0ZWQtYmlkaXItZnJyLmFsbEBpZXRmLm9y ZzxtYWlsdG86ZHJhZnQtaWV0Zi10ZWFzLWFzc29jLWNvcm91dGVkLWJpZGlyLWZyci5hbGxAaWV0 Zi5vcmc+Pg0KU3ViamVjdDogUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi10ZWFzLWFzc29jLWNv cm91dGVkLWJpZGlyLWZyci0wNA0KUmVzZW50LUZyb206IDxhbGlhcy1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzphbGlhcy1ib3VuY2VzQGlldGYub3JnPj4NClJlc2VudC1UbzogIj1TTVRQOnJnYW5k aGlAY2lzY28uIGNvbSIgPHJnYW5kaGlAY2lzY28uY29tPG1haWx0bzpyZ2FuZGhpQGNpc2NvLmNv bT4+LCA8aHNoYWhAY2llbmEuY29tPG1haWx0bzpoc2hhaEBjaWVuYS5jb20+PiwgPGplcmVteS53 aGl0dGFrZXJAdmVyaXpvbi5jb208bWFpbHRvOmplcmVteS53aGl0dGFrZXJAdmVyaXpvbi5jb20+ PiwgTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldDxtYWlsdG86bGJlcmdlckBsYWJuLm5ldD4+ LCA8bWhhcnRsZXkuaWV0ZkBnbWFpbC5jb208bWFpbHRvOm1oYXJ0bGV5LmlldGZAZ21haWwuY29t Pj4sIDx2YmVlcmFtQGp1bmlwZXIubmV0PG1haWx0bzp2YmVlcmFtQGp1bmlwZXIubmV0Pj4sIDxt YXJ0aW4udmlnb3VyZXV4QG5va2lhLmNvbTxtYWlsdG86bWFydGluLnZpZ291cmV1eEBub2tpYS5j b20+PiwgREVCT1JBSCBCUlVOR0FSRCA8ZGIzNTQ2QGF0dC5jb208bWFpbHRvOmRiMzU0NkBhdHQu Y29tPj4sIDxhcmV0YW5hLmlldGZAZ21haWwuY29tPG1haWx0bzphcmV0YW5hLmlldGZAZ21haWwu Y29tPj4sIFZpc2hudSBCZWVyYW0gPHZpc2hudXBhdmFuQGdtYWlsLmNvbTxtYWlsdG86dmlzaG51 cGF2YW5AZ21haWwuY29tPj4sIDx2aXNobnVwYXZhbkBnbWFpbC5jb208bWFpbHRvOnZpc2hudXBh dmFuQGdtYWlsLmNvbT4+DQpSZXNlbnQtRGF0ZTogU2F0dXJkYXksIEp1bHkgMjgsIDIwMTggYXQg MTA6MjggQU0NCg0KDQpIZWxsbywNCg0KSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRp bmcgRGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBSb3V0aW5nIERpcmVj dG9yYXRlIHNlZWtzIHRvIHJldmlldyBhbGwgcm91dGluZyBvciByb3V0aW5nLXJlbGF0ZWQgZHJh ZnRzIGFzIHRoZXkgcGFzcyB0aHJvdWdoIElFVEYgbGFzdCBjYWxsIGFuZCBJRVNHIHJldmlldywg YW5kIHNvbWV0aW1lcyBvbiBzcGVjaWFsIHJlcXVlc3QuIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZp ZXcgaXMgdG8gcHJvdmlkZSBhc3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUg aW5mb3JtYXRpb24gYWJvdXQgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUg4oCL aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0RpcjxodHRw Oi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyPg0KDQpBbHRo b3VnaCB0aGVzZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0 aW5nIEFEcywgaXQgd291bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBh bG9uZyB3aXRoIGFueSBvdGhlciBJRVRGIExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNl aXZlLCBhbmQgc3RyaXZlIHRvIHJlc29sdmUgdGhlbSB0aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkg dXBkYXRpbmcgdGhlIGRyYWZ0Lg0KDQpEb2N1bWVudDogZHJhZnQtaWV0Zi10ZWFzLWFzc29jLWNv cm91dGVkLWJpZGlyLWZyci0wNA0KUmV2aWV3ZXI6IERhbmllbGUgQ2VjY2FyZWxsaQ0KUmV2aWV3 IERhdGU6IDI3LzA3LzIwMTgNCklFVEYgTEMgRW5kIERhdGU6IGRhdGUtaWYta25vd24NCkludGVu ZGVkIFN0YXR1czogU3RhbmRhcmQgdHJhY2sNCg0KU3VtbWFyeToNCg0KDQoNCiAgKiAgIEkgaGF2 ZSBzb21lIG1pbm9yIGNvbmNlcm5zIGFib3V0IHRoaXMgZG9jdW1lbnQgdGhhdCBJIHRoaW5rIHNo b3VsZCBiZSByZXNvbHZlZCBiZWZvcmUgcHVibGljYXRpb24uDQoNCkNvbW1lbnRzOg0KDQogICog ICBUaGUgZG9jdW1lbnQgaXMgdmVyeSB3ZWxsIHdyaXR0ZW4gYW5kIHRoZSBwcm9ibGVtIGNsZWFy bHkgc3RhdGVkIChldmVuIGlmIGNhbGxlZCBvdmVydmlldyDwn5iKICkuIFRoZSBzZWNvbmQgcGFy dCBpcyBhIGJpdCBoYXJkZXIgdG8gZm9sbG93IGJ1dCBJIGRvbuKAmXQgc2VlIGhvdyB0byBtYWtl IHRoZSBwcm9jZWR1cmUgc2VjdGlvbiBlYXNpZXIgdG8gcmVhZC4NCjxSRz4gT2ssIHRoYW5rcy4N Cg0KICAqICAgSXQgaXMgbm90IGNsZWFyIHRvIG1lIHdoeSB0aGVyZSBpcyBhbiDigJxleGFtcGxl 4oCdIG9mIEV4dGVuZGVkIEFzc29jaWF0aW9uIElEIGluIHRoZSBhcHBlbmRpeC4gUkZDIDY3ODAg anVzdCBzYXlzIGl0IOKAnGNvbnRhaW5zIGRhdGEgdGhhdCBpcyBhZGRpdGlvbmFsIGluZm9ybWF0 aW9uIHRvIHN1cHBvcnQgdW5pcXVlIGlkZW50aWZpY2F0aW9uLuKAnSBCdXQgZG9lc27igJl0IGRl c2NyaWJlIGhvdyBpdCBzaG91bGQgYmUgZmlsbGVkLiBEb2VzIHRoaXMgbWVhbiB0aGVyZSBpcyBu byBzdGFuZGFyZCBmb3JtYXQgZm9yIGl0Pw0KPFJHPiBSaWdodC4gRXhhbXBsZSBzaG93biBpbiB0 aGUgQXBwZW5kaXggaXMgb25lIHVuLWFtYmlndW91cyB3YXkgdG8gcG9wdWxhdGUgaXQgZm9yIGFz c29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1BzLg0KDQpNYWpvciBJc3N1ZXM6DQoNCk5vbmUNCg0K TWlub3IgSXNzdWVzOg0KDQogICogICBNb3ZpbmcgdGhlIHRlcm1pbm9sb2d5IHNlY3Rpb24gYmVm b3JlIHRoZSBpbnRyb2R1Y3Rpb24gd291bGQgaW1wcm92ZSByZWFkYWJpbGl0eSwgc2luY2UgdGhl IHRlcm1zIGRlZmluZWQgaW4gdGhlIHRlcm1pbm9sb2d5IHNlY3Rpb24gYXJlIGZyZXF1ZW50bHkg dXNlZCBpbiB0aGUgaW50cm9kdWN0aW9uLg0KPFJHPiBJIGFtIG5vdCBmYW1pbGlhciB3aXRoIGFu IFJGQyB3aGVyZSB0ZXJtaW5vbG9neSBpcyB0aGUgZmlyc3Qgc2VjdGlvbi4gSSBhbSBmaW5lIGVp dGhlciB3YXksIHBsZWFzZSBsZXQgbWUga25vdyBpZiB5b3UgcHJlZmVyIHRoaXMgd2F5Lg0KDQog ICogICBXaGVuIEkgcmVhZCB0aGUgdGl0bGUgb2Ygc2VjdGlvbiAzIChvdmVydmlldyksIEkgdGhv dWdodCDigJx3aHkgYW4gb3ZlcnZpZXcgaXMgbmVlZGVkIGlmIHRoZXJlIGlzIGFuIGludHJvZHVj dGlvbj/igJ0uIEFjdHVhbGx5IHRoZSB0ZXh0IGluIHRoYXQgc2VjdGlvbiBpcyB2ZXJ5IHVzZWZ1 bCBidXQgbW9yZSB0aGFuIGFuIG92ZXJ2aWV3IEkgd291bGQgY2FsbCBpdCBhIHByb2JsZW0gc3Rh dGVtZW50IChvciBzb21ldGhpbmcgbGlrZSB0aGF0KS4NCjxSRz4gQ29ycmVjdGVkLg0KDQogICog ICBUaGUgdXNhZ2Ugb2YgUkZDIDIxMTkgKG9yIHNob3VsZCB3ZSByZWZlcmVuY2UgUkZDIDgxNzQg Pz8pIGlzIG5vdCBjb25ncnVlbnQgYWxsIG92ZXIgdGhlIGRvY3VtZW50LiBFLmcuIHNlY3Rpb24g NC4xDQoNCiAgbyAgVGhlIGRvd25zdHJlYW0gUExSIG5vZGUgYWx3YXlzIGluaXRpYXRlcyB0aGUg YnlwYXNzIHR1bm5lbA0KDQogICAgICBhc3NpZ25tZW50IGZvciB0aGUgZm9yd2FyZCBMU1AuICBU aGUgdXBzdHJlYW0gUExSIChmb3J3YXJkDQoNCiAgICAgIGRpcmVjdGlvbiBMU1AgTVApIG5vZGUg c2ltcGx5IHJlZmxlY3RzIHRoZSBhc3NvY2lhdGVkIGJ5cGFzcw0KDQogICAgICB0dW5uZWwgYXNz aWdubWVudCBmb3IgdGhlIHJldmVyc2UgZGlyZWN0aW9uIExTUC4gIFRoZSB1cHN0cmVhbSBQTFIN Cg0KICAgICAgbm9kZSBNVVNUIE5PVCBpbml0aWF0ZSB0aGUgYnlwYXNzIHR1bm5lbCBhc3NpZ25t ZW50Lg0KDQoNCg0KPFJHPiBDb3JyZWN0ZWQuDQoNCk5pdHM6DQoNCiAgKiAgIFNlY3Rpb24xOiDi gJwoRylNdWx0aXByb3RvY29sIExhYmVsIFN3aXRjaGluZyAoTVBMUykgVHJhZmZpYyBFbmdpbmVl cmluZyAoVEUpIExhYmVsIFN3aXRjaGVkIFBhdGhzIChMU1BzKeKAnS4gVGhpcyBmb3JtYXR0aW5n IGRvZXNu4oCZdCBtYWtlIG11Y2ggc2Vuc2UuIEluIHRoZSBmaXJzdCBpbnN0YW5jZSB0aGUgYnJh Y2tldHMgYXJlIHVzZWQgdG8gc2F5IE1QTFMgb3IgR01QTFMgd2hpbGUgaW4gdGhlIG90aGVyIG9u ZXMgdG8gZGVmaW5lIHRoZSBhY3Jvbnltcy4NCjxSRz4gQ29ycmVjdGVkLg0KDQogICogICBTZWN0 aW9uIDMuMSB0aGVyZSBpcyBubyBuZWVkIHRvIHJlcGVhdCB0d2ljZSB0aGF0IEJ5cGFzcyB0dW5u ZWwgTiB1c2VzIHBhdGggQi1ILUktQyBhbmQgQnlwYXNzIHR1bm5lbCBTIHBhdGggQi1GLUctQy4g VGhlIHNlY29uZCB0aW1lIHRoZSBicmFja2V0IGNhbiBiZSBkcm9wcGVkLg0KPFJHPiBDb3JyZWN0 ZWQuDQoNCiAgKiAgIFNlY3Rpb24gNC4xLjEuIC0gIHMvU0hPVUxEIHRyaWdnZXIgdGhlIHByb2Nl ZHVyZS8gU0hPVUxEIHRyaWdnZXIgcHJvY2VkdXJlDQo8Ukc+IENvcnJlY3RlZC4NClRoYW5rcywN ClJha2VzaCAoZm9yIGF1dGhvcnMpDQoNCg0KQlINCkRhbmllbGUNCg== --_000_HE1PR07MB1675ADC945508711D6F899CFF0320HE1PR07MB1675eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiU2Vnb2UgVUkgRW1vamkiO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGltZXM7DQoJ cGFub3NlLTE6MiAyIDYgMyA1IDQgNSAyIDMgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K cC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFn cmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2lu LXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28t c3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3IjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpJVDt9DQpwLm1zb25vcm1hbDAs IGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1h bDsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjt9DQpwLnAxLCBsaS5wMSwgZGl2LnAxDQoJe21zby1zdHlsZS1uYW1lOnAxOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6Ny4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIixzZXJpZjt9DQpw LnAyLCBsaS5wMiwgZGl2LnAyDQoJe21zby1zdHlsZS1uYW1lOnAyOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6Ny4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIixzZXJpZjsNCgljb2xvcjojMDQyRUVFO30N CnAucDMsIGxpLnAzLCBkaXYucDMNCgl7bXNvLXN0eWxlLW5hbWU6cDM7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZTo3LjBwdDsNCglmb250LWZhbWlseToiVGltZXMiLHNlcmlmO30NCnNwYW4uRW1haWxTdHls ZTI1DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5pY29uDQoJe21zby1zdHlsZS1u YW1lOmljb247fQ0Kc3Bhbi5FbWFpbFN0eWxlMjcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9 DQpzcGFuLkVtYWlsU3R5bGUyOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uczIN Cgl7bXNvLXN0eWxlLW5hbWU6czI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LnMxDQoJe21zby1zdHlsZS1uYW1lOnMxO30NCnNwYW4uRW1haWxTdHlsZTMzDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgMi4wY20gMi4wY20gMi4wY207 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo5ODcxNzA2MzE7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOi0xMzI3MzMyOTIwO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0K CW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDox ODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjExMDQyOTkzMTM7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOjIwNDYwNDQ1MjQ7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDE6 bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MTc0NzcyMTM0NzsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEzNTM4NDUyNjt9DQpAbGlzdCBsMjpsZXZlbDENCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlz dCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDQN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2 LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MjpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDoyMDg5OTYz MjA2Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTcwMjQ1MDU1ODt9DQpAbGlzdCBsMzpsZXZl bDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9 DQpAbGlzdCBsMzpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMzpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9 DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3 aGl0ZSIgbGFuZz0iSVQiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIFJha2VzaCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+dGhhbmtzIGZvciB0aGUg dXBkYXRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhlIHRlcm1pbm9sb2d5IHNlY3Rpb24gaXMgYSB2 ZXJ5IG1pbm9yIGlzc3VlcywgdGhlIGltcG9ydGFudCB0aGluZyBpcyB0aGF0IGl0IGlzIHRoZXJl LiBJIHdvdWxkIHByZWZlciB0byBoYXZlIGl0IGF0IHRoZSBiZWdpbm5pbmcgYXMgc29tZXRpbWVz IEkgZm91bmQgaXQgaGFyZCB0byByZWFkIHRoZSBpbnRybyB3aGVyZQ0KIHRlcm1zIG5vdCB5ZXQg ZGVmaW5lZCB3ZXJlIHVzZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+UGxlYXNlIGFsc28gYWRkcmVzcyB0aGUgY29tbWVudCBmcm9tIERlYm9yYWggdG8gYWRkIG9u ZSBvciB0d28gc2VudGVuY2VzIHRvIHNlY3Rpb24gNSBvbiB3aGF0IGhhcHBlbnMgaWYgb25lIG9m IHRoZSBub2RlcyBkb2VzIG5vdCBzdXBwb3J0IHRoZSBmZWF0dXJlLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPldoZW4gdGhhdCBpcyBkb25lIEnigJltIG9rIHdpdGggdGhlIGRvY3Vt ZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5rczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkRhbmllbGUmbmJzcDsNCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZy b206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFJha2VzaCBHYW5kaGkgKHJnYW5kaGkp ICZsdDtyZ2FuZGhpQGNpc2NvLmNvbSZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBtZXJjb2xlZMOs IDggYWdvc3RvIDIwMTggMjE6MzA8YnI+DQo8Yj5Ubzo8L2I+IERhbmllbGUgQ2VjY2FyZWxsaSAm bHQ7ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbSZndDs7ICZsdDtydGctYWRzQGlldGYu b3JnJmd0OyAocnRnLWFkc0BpZXRmLm9yZykgJmx0O3J0Zy1hZHNAaWV0Zi5vcmcmZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBydGctZGlyQGlldGYub3JnOyBURUFTIFdHICh0ZWFzQGlldGYub3JnKSAmbHQ7 dGVhc0BpZXRmLm9yZyZndDs7IGRyYWZ0LWlldGYtdGVhcy1hc3NvYy1jb3JvdXRlZC1iaWRpci1m cnIuYWxsQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBSdGdEaXIgcmV2aWV3OiBk cmFmdC1pZXRmLXRlYXMtYXNzb2MtY29yb3V0ZWQtYmlkaXItZnJyLTA0PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkhpIERhbmllbGUs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPkZZSSwgd2UgaGF2ZSB1cGxvYWRlZCB0aGlzIHZlcnNpb24uIFBsZWFzZSBs ZXQgdXMga25vdyBpZiB5b3UgaGF2ZSBhZGRpdGlvbmFsIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 InAyIj48c3BhbiBjbGFzcz0iczIiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt dGVhcy1hc3NvYy1jb3JvdXRlZC1iaWRpci1mcnItMDUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLXRlYXMtYXNzb2MtY29yb3V0ZWQtYmlkaXItZnJyLTA1PC9hPjwvc3Bh bj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0icDIiPjxzcGFuIGNsYXNzPSJzMiI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48YSBocmVmPSJodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtdGVhcy1hc3NvYy1jb3JvdXRl ZC1iaWRpci1mcnItMDUiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJh ZnQtaWV0Zi10ZWFzLWFzc29jLWNvcm91dGVkLWJpZGlyLWZyci0wNTwvYT48L3NwYW4+PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9InAzIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJwMSI+ PHNwYW4gY2xhc3M9InMxIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDo8L3Nw YW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9InAyIj48c3BhbiBjbGFzcz0iczIiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdGVhcy1hc3NvYy1jb3JvdXRlZC1i aWRpci1mcnItMDUiPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRm LXRlYXMtYXNzb2MtY29yb3V0ZWQtYmlkaXItZnJyLTA1PC9hPjwvc3Bhbj48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0icDMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQiPlJha2VzaCAoZm9yIGF1dGhvcnMpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOmJsYWNrIj4mcXVvdDs9U01UUDpyZ2FuZGhpQGNpc2NvLiBjb20mcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpyZ2FuZGhpQGNpc2NvLmNvbSI+cmdhbmRoaUBjaXNjby5jb208 L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIEp1bHkgMzAsIDIwMTggYXQgMTE6MjIg QU08YnI+DQo8Yj5UbzogPC9iPkRhbmllbGUgQ2VjY2FyZWxsaSAmbHQ7PGEgaHJlZj0ibWFpbHRv OmRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb20iPmRhbmllbGUuY2VjY2FyZWxsaUBlcmlj c3Nvbi5jb208L2E+Jmd0OywgJnF1b3Q7Jmx0OzxhIGhyZWY9Im1haWx0bzpydGctYWRzQGlldGYu b3JnIj5ydGctYWRzQGlldGYub3JnPC9hPiZndDsgKDxhIGhyZWY9Im1haWx0bzpydGctYWRzQGll dGYub3JnIj5ydGctYWRzQGlldGYub3JnPC9hPikmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpy dGctYWRzQGlldGYub3JnIj5ydGctYWRzQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5DYzogPC9i PiZxdW90OzxhIGhyZWY9Im1haWx0bzpydGctZGlyQGlldGYub3JnIj5ydGctZGlyQGlldGYub3Jn PC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Zy1kaXJAaWV0Zi5vcmciPnJ0Zy1kaXJA aWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7VEVBUyBXRyAoPGEgaHJlZj0ibWFpbHRvOnRlYXNAaWV0 Zi5vcmciPnRlYXNAaWV0Zi5vcmc8L2E+KSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRlYXNA aWV0Zi5vcmciPnRlYXNAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmRy YWZ0LWlldGYtdGVhcy1hc3NvYy1jb3JvdXRlZC1iaWRpci1mcnIuYWxsQGlldGYub3JnIj5kcmFm dC1pZXRmLXRlYXMtYXNzb2MtY29yb3V0ZWQtYmlkaXItZnJyLmFsbEBpZXRmLm9yZzwvYT4mcXVv dDsNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtdGVhcy1hc3NvYy1jb3JvdXRlZC1i aWRpci1mcnIuYWxsQGlldGYub3JnIj5kcmFmdC1pZXRmLXRlYXMtYXNzb2MtY29yb3V0ZWQtYmlk aXItZnJyLmFsbEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBSdGdE aXIgcmV2aWV3OiBkcmFmdC1pZXRmLXRlYXMtYXNzb2MtY29yb3V0ZWQtYmlkaXItZnJyLTA0PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIERhbmllbGUsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5NYW55IHRoYW5rcyBmb3IgdGhlIHJldmlldyBvZiB0aGUgZG9jdW1l bnQgYW5kIHlvdXIgc3VnZ2VzdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkRpZmYgZmlsZSBpcyBmb3IgdGhlIHVwZGF0 ZWQgZG9jdW1lbnQgaXMgYXR0YWNoZWQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UGxlYXNlIHNlZSBpbmxpbmUgJmx0O1JH Jmd0O+KApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6YmxhY2siPkRhbmllbGUgQ2VjY2FyZWxsaSAmbHQ7PGEgaHJlZj0ibWFpbHRv OmRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb20iPmRhbmllbGUuY2VjY2FyZWxsaUBlcmlj c3Nvbi5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5TYXR1cmRheSwgSnVseSAyOCwgMjAx OCBhdCAxMDoyOCBBTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7Jmx0OzxhIGhyZWY9Im1haWx0bzpy dGctYWRzQGlldGYub3JnIj5ydGctYWRzQGlldGYub3JnPC9hPiZndDsgKDxhIGhyZWY9Im1haWx0 bzpydGctYWRzQGlldGYub3JnIj5ydGctYWRzQGlldGYub3JnPC9hPikmcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzpydGctYWRzQGlldGYub3JnIj5ydGctYWRzQGlldGYub3JnPC9hPiZndDs8YnI+ DQo8Yj5DYzogPC9iPiZxdW90OzxhIGhyZWY9Im1haWx0bzpydGctZGlyQGlldGYub3JnIj5ydGct ZGlyQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Zy1kaXJAaWV0Zi5v cmciPnJ0Zy1kaXJAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7VEVBUyBXRyAoPGEgaHJlZj0ibWFp bHRvOnRlYXNAaWV0Zi5vcmciPnRlYXNAaWV0Zi5vcmc8L2E+KSZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnRlYXNAaWV0Zi5vcmciPnRlYXNAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJl Zj0ibWFpbHRvOmRyYWZ0LWlldGYtdGVhcy1hc3NvYy1jb3JvdXRlZC1iaWRpci1mcnIuYWxsQGll dGYub3JnIj5kcmFmdC1pZXRmLXRlYXMtYXNzb2MtY29yb3V0ZWQtYmlkaXItZnJyLmFsbEBpZXRm Lm9yZzwvYT4mcXVvdDsNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtdGVhcy1hc3Nv Yy1jb3JvdXRlZC1iaWRpci1mcnIuYWxsQGlldGYub3JnIj5kcmFmdC1pZXRmLXRlYXMtYXNzb2Mt Y29yb3V0ZWQtYmlkaXItZnJyLmFsbEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDog PC9iPlJ0Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtdGVhcy1hc3NvYy1jb3JvdXRlZC1iaWRpci1m cnItMDQ8YnI+DQo8Yj5SZXNlbnQtRnJvbTogPC9iPiZsdDs8YSBocmVmPSJtYWlsdG86YWxpYXMt Ym91bmNlc0BpZXRmLm9yZyI+YWxpYXMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+ UmVzZW50LVRvOiA8L2I+JnF1b3Q7PVNNVFA6cmdhbmRoaUBjaXNjby4gY29tJnF1b3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86cmdhbmRoaUBjaXNjby5jb20iPnJnYW5kaGlAY2lzY28uY29tPC9hPiZn dDssICZsdDs8YSBocmVmPSJtYWlsdG86aHNoYWhAY2llbmEuY29tIj5oc2hhaEBjaWVuYS5jb208 L2E+Jmd0OywgJmx0OzxhIGhyZWY9Im1haWx0bzpqZXJlbXkud2hpdHRha2VyQHZlcml6b24uY29t Ij5qZXJlbXkud2hpdHRha2VyQHZlcml6b24uY29tPC9hPiZndDssIExvdSBCZXJnZXIgJmx0Ozxh IGhyZWY9Im1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0Ij5sYmVyZ2VyQGxhYm4ubmV0PC9hPiZndDss DQogJmx0OzxhIGhyZWY9Im1haWx0bzptaGFydGxleS5pZXRmQGdtYWlsLmNvbSI+bWhhcnRsZXku aWV0ZkBnbWFpbC5jb208L2E+Jmd0OywgJmx0OzxhIGhyZWY9Im1haWx0bzp2YmVlcmFtQGp1bmlw ZXIubmV0Ij52YmVlcmFtQGp1bmlwZXIubmV0PC9hPiZndDssICZsdDs8YSBocmVmPSJtYWlsdG86 bWFydGluLnZpZ291cmV1eEBub2tpYS5jb20iPm1hcnRpbi52aWdvdXJldXhAbm9raWEuY29tPC9h PiZndDssIERFQk9SQUggQlJVTkdBUkQgJmx0OzxhIGhyZWY9Im1haWx0bzpkYjM1NDZAYXR0LmNv bSI+ZGIzNTQ2QGF0dC5jb208L2E+Jmd0OywNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFyZXRhbmEu aWV0ZkBnbWFpbC5jb20iPmFyZXRhbmEuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OywgVmlzaG51IEJl ZXJhbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZpc2hudXBhdmFuQGdtYWlsLmNvbSI+dmlzaG51cGF2 YW5AZ21haWwuY29tPC9hPiZndDssICZsdDs8YSBocmVmPSJtYWlsdG86dmlzaG51cGF2YW5AZ21h aWwuY29tIj52aXNobnVwYXZhbkBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPlJlc2VudC1EYXRl OiA8L2I+U2F0dXJkYXksIEp1bHkgMjgsIDIwMTggYXQgMTA6MjggQU08L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkhlbGxvLDwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGU7Zm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsO2ZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogMjt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogMjst d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOiBpbml0 aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjogaW5pdGlhbDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkkgaGF2ZSBiZWVuIHNlbGVj dGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBU aGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91 dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3VnaA0KIElFVEYgbGFzdCBjYWxs IGFuZCBJRVNHIHJldmlldywgYW5kIHNvbWV0aW1lcyBvbiBzcGVjaWFsIHJlcXVlc3QuIFRoZSBw dXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Npc3RhbmNlIHRvIHRoZSBSb3V0 aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFJvdXRpbmcgRGlyZWN0b3Jh dGUsIHBsZWFzZSBzZWUmbmJzcDs8YSBocmVmPSJodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9h cmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyIj48c3BhbiBjbGFzcz0iaWNvbiI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6I0JCMDAwMDt0 ZXh0LWRlY29yYXRpb246bm9uZSI+4oCLPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 I0JCMDAwMCI+aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0 Z0Rpcjwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZTtmb250LXZhcmlhbnQtbGlnYXR1cmVz OiBub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiAyO3RleHQtYWxpZ246 c3RhcnQ7d2lkb3dzOiAyOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt0ZXh0LWRlY29y YXRpb24tc3R5bGU6IGluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOiBpbml0aWFsO3dvcmQt c3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ QWx0aG91Z2ggdGhlc2UgY29tbWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUg Um91dGluZyBBRHMsIGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRo ZW0gYWxvbmcgd2l0aCBhbnkgb3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UN CiByZWNlaXZlLCBhbmQgc3RyaXZlIHRvIHJlc29sdmUgdGhlbSB0aHJvdWdoIGRpc2N1c3Npb24g b3IgYnkgdXBkYXRpbmcgdGhlIGRyYWZ0Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7Zm9udC12YXJpYW50 LWxpZ2F0dXJlczogbm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogMjt0 ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogMjstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 dGV4dC1kZWNvcmF0aW9uLXN0eWxlOiBpbml0aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjogaW5p dGlhbDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPkRvY3VtZW50OiBkcmFmdC1pZXRmLXRlYXMtYXNzb2MtY29yb3V0ZWQtYmlkaXIt ZnJyLTA0PGJyPg0KUmV2aWV3ZXI6IERhbmllbGUgQ2VjY2FyZWxsaTxicj4NClJldmlldyBEYXRl OiAyNy8wNy8yMDE4PGJyPg0KSUVURiBMQyBFbmQgRGF0ZTogZGF0ZS1pZi1rbm93biZuYnNwOzxi cj4NCkludGVuZGVkIFN0YXR1czogU3RhbmRhcmQgdHJhY2s8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dDtiYWNrZ3JvdW5kOndoaXRlO2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDtmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IDI7dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IDI7 LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3RleHQtZGVjb3JhdGlvbi1zdHlsZTogaW5p dGlhbDt0ZXh0LWRlY29yYXRpb24tY29sb3I6IGluaXRpYWw7d29yZC1zcGFjaW5nOjBweCI+DQo8 c3Ryb25nPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlN1bW1hcnk6 PC9zcGFuPjwvc3Ryb25nPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PiZuYnNwOzxicj4NCjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDEgbGZvMTtiYWNrZ3JvdW5kOndoaXRlIj4N CjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90 OyxzYW5zLXNlcmlmIj5JIGhhdmUgc29tZSBtaW5vciBjb25jZXJucyBhYm91dCB0aGlzIGRvY3Vt ZW50IHRoYXQgSSB0aGluayBzaG91bGQgYmUgcmVzb2x2ZWQgYmVmb3JlIHB1YmxpY2F0aW9uLjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPHAg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzdHJvbmc+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+Q29tbWVudHM6PC9zcGFuPjwvc3Ryb25nPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8yO2JhY2tncm91 bmQ6d2hpdGUiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtW ZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBkb2N1bWVudCBpcyB2ZXJ5IHdlbGwgd3JpdHRl biBhbmQgdGhlIHByb2JsZW0gY2xlYXJseSBzdGF0ZWQgKGV2ZW4gaWYgY2FsbGVkIG92ZXJ2aWV3 DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdv ZSBVSSBFbW9qaSZxdW90OyxzYW5zLXNlcmlmIj4mIzEyODUyMjs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYi PiApLiBUaGUgc2Vjb25kIHBhcnQgaXMgYSBiaXQgaGFyZGVyIHRvIGZvbGxvdyBidXQgSSBkb27i gJl0IHNlZSBob3cgdG8gbWFrZSB0aGUgcHJvY2VkdXJlIHNlY3Rpb24gZWFzaWVyIHRvIHJlYWQu DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mbHQ7UkcmZ3Q7IE9rLCB0aGFua3MuDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzI7YmFja2dyb3Vu ZDp3aGl0ZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Zl cmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+SXQgaXMgbm90IGNsZWFyIHRvIG1lIHdoeSB0aGVyZSBp cyBhbiDigJxleGFtcGxl4oCdIG9mIEV4dGVuZGVkIEFzc29jaWF0aW9uIElEIGluIHRoZSBhcHBl bmRpeC4gUkZDIDY3ODAganVzdCBzYXlzIGl0IOKAnGNvbnRhaW5zIGRhdGEgdGhhdCBpcyBhZGRp dGlvbmFsIGluZm9ybWF0aW9uIHRvIHN1cHBvcnQgdW5pcXVlIGlkZW50aWZpY2F0aW9uLuKAnSBC dXQNCiBkb2VzbuKAmXQgZGVzY3JpYmUgaG93IGl0IHNob3VsZCBiZSBmaWxsZWQuIERvZXMgdGhp cyBtZWFuIHRoZXJlIGlzIG5vIHN0YW5kYXJkIGZvcm1hdCBmb3IgaXQ/PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmx0O1JH Jmd0OyBSaWdodC4gRXhhbXBsZSBzaG93biBpbiB0aGUgQXBwZW5kaXggaXMgb25lIHVuLWFtYmln dW91cyB3YXkgdG8gcG9wdWxhdGUgaXQgZm9yIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1Bz Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzdHJvbmc+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+TWFqb3IgSXNzdWVzOjwvc3Bhbj48L3N0cm9uZz48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk5vbmU8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3Ryb25nPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPk1pbm9yIElzc3Vlczo8L3NwYW4+PC9zdHJvbmc+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzM7YmFja2dyb3VuZDp3aGl0ZSI+ DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVv dDssc2Fucy1zZXJpZiI+TW92aW5nIHRoZSB0ZXJtaW5vbG9neSBzZWN0aW9uIGJlZm9yZSB0aGUg aW50cm9kdWN0aW9uIHdvdWxkIGltcHJvdmUgcmVhZGFiaWxpdHksIHNpbmNlIHRoZSB0ZXJtcyBk ZWZpbmVkIGluIHRoZSB0ZXJtaW5vbG9neSBzZWN0aW9uIGFyZSBmcmVxdWVudGx5IHVzZWQgaW4g dGhlIGludHJvZHVjdGlvbi4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUi Pg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZsdDtSRyZndDsgSSBhbSBub3QgZmFtaWxpYXIg d2l0aCBhbiBSRkMgd2hlcmUgdGVybWlub2xvZ3kgaXMgdGhlIGZpcnN0IHNlY3Rpb24uIEkgYW0g ZmluZSBlaXRoZXIgd2F5LCBwbGVhc2UgbGV0IG1lIGtub3cgaWYgeW91IHByZWZlciB0aGlzIHdh eS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjx1bCB0 eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6 bDIgbGV2ZWwxIGxmbzM7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+V2hlbiBJIHJl YWQgdGhlIHRpdGxlIG9mIHNlY3Rpb24gMyAob3ZlcnZpZXcpLCBJIHRob3VnaHQg4oCcd2h5IGFu IG92ZXJ2aWV3IGlzIG5lZWRlZCBpZiB0aGVyZSBpcyBhbiBpbnRyb2R1Y3Rpb24/4oCdLiBBY3R1 YWxseSB0aGUgdGV4dCBpbiB0aGF0IHNlY3Rpb24gaXMgdmVyeSB1c2VmdWwgYnV0IG1vcmUgdGhh biBhbiBvdmVydmlldyBJIHdvdWxkDQogY2FsbCBpdCBhIHByb2JsZW0gc3RhdGVtZW50IChvciBz b21ldGhpbmcgbGlrZSB0aGF0KS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRl Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbHQ7UkcmZ3Q7IENvcnJlY3RlZC48L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjx1bCB0eXBlPSJkaXNj Ij4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIgbGV2ZWwx IGxmbzM7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+VGhlIHVzYWdlIG9mIFJGQyAy MTE5IChvciBzaG91bGQgd2UgcmVmZXJlbmNlIFJGQyA4MTc0ID8/KSBpcyBub3QgY29uZ3J1ZW50 IGFsbCBvdmVyIHRoZSBkb2N1bWVudC4gRS5nLiBzZWN0aW9uIDQuMTwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7Zm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiAyO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiAyOy13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt0ZXh0LWRlY29yYXRpb24tc3R5bGU6IGluaXRp YWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOiBpbml0aWFsO3dvcmQtc3BhY2luZzowcHgiPg0KPHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7IG8mbmJzcDsgVGhlIGRvd25zdHJlYW0gUExSIG5vZGUNCjxz cGFuIHN0eWxlPSJiYWNrZ3JvdW5kOnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyI+YWx3YXlz IGluaXRpYXRlczwvc3Bhbj4gdGhlIGJ5cGFzcyB0dW5uZWw8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXNzaWdubWVu dCBmb3IgdGhlIGZvcndhcmQgTFNQLiZuYnNwOyBUaGUgdXBzdHJlYW0gUExSIChmb3J3YXJkPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGRpcmVjdGlvbiBMU1AgTVApIG5vZGUNCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5k OnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyI+c2ltcGx5IHJlZmxlY3RzPC9zcGFuPiB0aGUg YXNzb2NpYXRlZCBieXBhc3M8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHVubmVsIGFzc2lnbm1lbnQgZm9yIHRoZSBy ZXZlcnNlIGRpcmVjdGlvbiBMU1AuJm5ic3A7IFRoZSB1cHN0cmVhbSBQTFI8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg bm9kZSBNVVNUIE5PVCBpbml0aWF0ZSB0aGUgYnlwYXNzIHR1bm5lbCBhc3NpZ25tZW50Ljwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY20iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6YmxhY2siPiZsdDtSRyZndDsgQ29ycmVjdGVkLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzdHJv bmc+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Tml0czo8L3NwYW4+ PC9zdHJvbmc+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjx1bCB0 eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6 bDMgbGV2ZWwxIGxmbzQ7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+U2VjdGlvbjE6 IOKAnChHKU11bHRpcHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nIChNUExTKSBUcmFmZmljIEVuZ2lu ZWVyaW5nIChURSkgTGFiZWwgU3dpdGNoZWQgUGF0aHMgKExTUHMp4oCdLiBUaGlzIGZvcm1hdHRp bmcgZG9lc27igJl0IG1ha2UgbXVjaCBzZW5zZS4gSW4gdGhlIGZpcnN0IGluc3RhbmNlIHRoZSBi cmFja2V0cyBhcmUgdXNlZCB0byBzYXkNCiBNUExTIG9yIEdNUExTIHdoaWxlIGluIHRoZSBvdGhl ciBvbmVzIHRvIGRlZmluZSB0aGUgYWNyb255bXMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dy b3VuZDp3aGl0ZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmx0O1JHJmd0OyBDb3JyZWN0 ZWQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8dWwg dHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwzIGxldmVsMSBs Zm80O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlNlY3Rpb24g My4xIHRoZXJlIGlzIG5vIG5lZWQgdG8gcmVwZWF0IHR3aWNlIHRoYXQgQnlwYXNzIHR1bm5lbCBO IHVzZXMgcGF0aCBCLUgtSS1DIGFuZCBCeXBhc3MgdHVubmVsIFMgcGF0aCBCLUYtRy1DLiBUaGUg c2Vjb25kIHRpbWUgdGhlIGJyYWNrZXQgY2FuIGJlIGRyb3BwZWQuDQo8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbHQ7Ukcm Z3Q7IENvcnJlY3RlZC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6 bDMgbGV2ZWwxIGxmbzQ7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+U2Vj dGlvbiA0LjEuMS4gLSAmbmJzcDtzL1NIT1VMRCB0cmlnZ2VyIHRoZSBwcm9jZWR1cmUvIFNIT1VM RCB0cmlnZ2VyIHByb2NlZHVyZTxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj4mbHQ7 UkcmZ3Q7IENvcnJlY3RlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRl Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj5SYWtlc2ggKGZvciBhdXRob3JzKTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6MTguMHB0O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDoxOC4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBsYW5nPSJF Ti1VUyI+QlI8YnI+DQpEYW5pZWxlJm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_HE1PR07MB1675ADC945508711D6F899CFF0320HE1PR07MB1675eurp_-- From nobody Mon Aug 20 16:56:55 2018 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD0E5130E96; Mon, 20 Aug 2018 16:56:39 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5iGrVAa5pKkF; Mon, 20 Aug 2018 16:56:37 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCEE6130E6C; Mon, 20 Aug 2018 16:56:37 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id ED7A2B80500; Mon, 20 Aug 2018 16:56:24 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, teas@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20180820235624.ED7A2B80500@rfc-editor.org> Date: Mon, 20 Aug 2018 16:56:24 -0700 (PDT) Archived-At: Subject: [Teas] =?utf-8?q?RFC_8424_on_Extensions_to_RSVP-TE_for_Label_Swi?= =?utf-8?q?tched_Path_=28LSP=29_Ingress_Fast_Reroute_=28FRR=29_Protection?= X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 23:56:53 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8424 Title: Extensions to RSVP-TE for Label Switched Path (LSP) Ingress Fast Reroute (FRR) Protection Author: H. Chen, Ed., R. Torvi, Ed. Status: Experimental Stream: IETF Date: August 2018 Mailbox: huaimo.chen@huawei.com, rtorvi@juniper.net Pages: 28 Characters: 62022 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-teas-rsvp-ingress-protection-17.txt URL: https://www.rfc-editor.org/info/rfc8424 DOI: 10.17487/RFC8424 This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the ingress node of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP) Traffic Engineered (TE) Label Switched Path (LSP). It extends the Fast Reroute (FRR) protection for transit nodes of an LSP to the ingress node of the LSP. The procedures described in this document are experimental. This document is a product of the Traffic Engineering Architecture and Signaling Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Aug 22 12:22:59 2018 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C120D1292AD; Wed, 22 Aug 2018 12:22:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: teas@ietf.org Message-ID: <153496577776.20968.7208130009012296158@ietfa.amsl.com> Date: Wed, 22 Aug 2018 12:22:57 -0700 Archived-At: Subject: [Teas] I-D Action: draft-ietf-teas-actn-yang-02.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.27 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2018 19:22:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling WG of the IETF. Title : Applicability of YANG models for Abstraction and Control of Traffic Engineered Networks Authors : Young Lee Haomian Zheng Daniele Ceccarelli Bin Yeong Yoon Oscar Gonzalez de Dios Jong Yoon Shin Sergio Belotti Filename : draft-ietf-teas-actn-yang-02.txt Pages : 19 Date : 2018-08-22 Abstract: Abstraction and Control of TE Networks (ACTN) refers to the set of virtual network operations needed to orchestrate, control and manage large-scale multi-domain TE networks, so as to facilitate network programmability, automation, efficient resource sharing, and end-to- end virtual service aware connectivity and network function virtualization services. This document explains how the different types of YANG models defined in the Operations and Management Area and in the Routing Area are applicable to the ACTN framework. This document also shows how the ACTN architecture can be satisfied using classes of data model that have already been defined, and discusses the applicability of specific data models that are under development. It also highlights where new data models may need to be developed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-actn-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-teas-actn-yang-02 https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-yang-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-actn-yang-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 23 15:27:23 2018 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE34130F2B; Thu, 23 Aug 2018 15:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scgHcWASnLQV; Thu, 23 Aug 2018 15:27:20 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27031128CF2; Thu, 23 Aug 2018 15:27:20 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 41D58B80E6B; Thu, 23 Aug 2018 15:27:05 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, teas@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20180823222705.41D58B80E6B@rfc-editor.org> Date: Thu, 23 Aug 2018 15:27:05 -0700 (PDT) Archived-At: Subject: [Teas] =?utf-8?q?RFC_8453_on_Framework_for_Abstraction_and_Contr?= =?utf-8?q?ol_of_TE_Networks_=28ACTN=29?= X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2018 22:27:22 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8453 Title: Framework for Abstraction and Control of TE Networks (ACTN) Author: D. Ceccarelli, Ed., Y. Lee Status: Informational Stream: IETF Date: August 2018 Mailbox: daniele.ceccarelli@ericsson.com, leeyoung@huawei.com Pages: 42 Characters: 90463 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-teas-actn-framework-15.txt URL: https://www.rfc-editor.org/info/rfc8453 DOI: 10.17487/RFC8453 Traffic Engineered (TE) networks have a variety of mechanisms to facilitate the separation of the data plane and control plane. They also have a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. The term "Traffic Engineered network" refers to a network that uses any connection-oriented technology under the control of a distributed or centralized control plane to support dynamic provisioning of end-to- end connectivity. Abstraction of network resources is a technique that can be applied to a single network domain or across multiple domains to create a single virtualized network that is under the control of a network operator or the customer of the operator that actually owns the network resources. This document provides a framework for Abstraction and Control of TE Networks (ACTN) to support virtual network services and connectivity services. This document is a product of the Traffic Engineering Architecture and Signaling Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue Aug 28 07:45:13 2018 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F042B130DD0; Tue, 28 Aug 2018 07:45:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: teas@ietf.org Message-ID: <153546750692.23688.4827384142395263965@ietfa.amsl.com> Date: Tue, 28 Aug 2018 07:45:06 -0700 Archived-At: Subject: [Teas] I-D Action: draft-ietf-teas-assoc-corouted-bidir-frr-06.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.27 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 14:45:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling WG of the IETF. Title : Updates to the Fast Reroute Procedures for Co-routed Associated Bidirectional Label Switched Paths (LSPs) Authors : Rakesh Gandhi Himanshu Shah Jeremy Whittaker Filename : draft-ietf-teas-assoc-corouted-bidir-frr-06.txt Pages : 16 Date : 2018-08-28 Abstract: Resource Reservation Protocol (RSVP) association signaling can be used to bind two unidirectional LSPs into an associated bidirectional LSP. When an associated bidirectional LSP is co-routed, the reverse LSP follows the same path as its forward LSP. This document updates the Fast Reroute (FRR) procedures defined in RFC 4090 to support both single-sided and double-sided provisioned associated bidirectional LSPs. This document also updates the procedure for associating two reverse LSPs defined in RFC 7551 to support co-routed bidirectional LSPs. The FRR procedures can ensure that for the co-routed LSPs, traffic flows on co-routed paths in the forward and reverse directions after a failure event. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-assoc-corouted-bidir-frr/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-teas-assoc-corouted-bidir-frr-06 https://datatracker.ietf.org/doc/html/draft-ietf-teas-assoc-corouted-bidir-frr-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-assoc-corouted-bidir-frr-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 28 07:48:35 2018 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63D8130F24; Tue, 28 Aug 2018 07:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uabF-SFMTxzO; Tue, 28 Aug 2018 07:48:30 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B255130DD0; Tue, 28 Aug 2018 07:48:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=57082; q=dns/txt; s=iport; t=1535467710; x=1536677310; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=IKh6YuvyWigza/EIYYHBE41inIQp5vpKmxw/lh/bNoo=; b=H/XrJine0CoXBU680vVH6Ew7wTMIbtjXRHONBoQmuro74fnUvpBAg7lC WZCycsyTaQwDwTZVnIVrfgcve0XDrKGPvI9G7DuwIccRT/xvLyDxFy+pb XpCaCQH8lau+67AqnQ22GDNUI/ByhgDEx6BimeXNJez0T8Vw9OWgEolzJ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbAABuX4Vb/51dJa1aGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJXeGV/KAqDZ4gRjCmBaCWIVI1SgXoLJQeEQAIXgmwhNBg?= =?us-ascii?q?BAgEBAgEBAm0cDIU3AQEBAQMjVhACAQYCEQMBAQEhAQYDAgICHxEUCQgBAQQ?= =?us-ascii?q?BDQWDIQGBHUwDFQ+HaJtLgS4fhwQNgzGJVheBQT+BEQEnDBOCTIIRRToLAQE?= =?us-ascii?q?CAQEWgWcGEAKCSTGCJgKIFoRzhVKIJisJAoYxhiyDEBEGgT9Ig2qCe4VdiDa?= =?us-ascii?q?CZ2OHIgIRFIEkDRA4gVJwFRpLAYI+CYsMhT5vAYEVimsBgRsBAQ?= X-IronPort-AV: E=Sophos;i="5.53,299,1531785600"; d="scan'208,217";a="441097470" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Aug 2018 14:48:28 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id w7SEmSn8022487 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 Aug 2018 14:48:28 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 28 Aug 2018 09:48:27 -0500 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1367.000; Tue, 28 Aug 2018 09:48:27 -0500 From: "Rakesh Gandhi (rgandhi)" To: Daniele Ceccarelli , " (rtg-ads@ietf.org)" CC: "rtg-dir@ietf.org" , "TEAS WG (teas@ietf.org)" , "draft-ietf-teas-assoc-corouted-bidir-frr.all@ietf.org" Thread-Topic: RtgDir review: draft-ietf-teas-assoc-corouted-bidir-frr-04 Thread-Index: AdQlm/SWFN83nAOVQmKg2miyrumEwAChYgCAAc1HYgACQwcaIAGg9jiA Date: Tue, 28 Aug 2018 14:48:27 +0000 Message-ID: References: <5A4119B4-94E1-4AD9-8300-39F27AE195F8@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.213.39] Content-Type: multipart/alternative; boundary="_000_E51A0C3E660448CAB39B45EB25001012ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.26, xch-rcd-016.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [Teas] RtgDir review: draft-ietf-teas-assoc-corouted-bidir-frr-04 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 14:48:34 -0000 --_000_E51A0C3E660448CAB39B45EB25001012ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGFuaWVsZSwNCg0KVGhhbmsgeW91IGZvciB0aGUgcmV2aWV3IGNvbW1lbnRzIGFuZCBmZWVk YmFja3MuDQoNCldlIGhhdmUgYWRkcmVzc2VkIHRoZSBjb21tZW50cyBpbiB0aGUgbGF0ZXN0IGRy YWZ0IEANCg0KDQogICAgSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLXRlYXMtYXNzb2MtY29yb3V0ZWQtYmlkaXItZnJyLTA2DQoNCiAgICBEaWZm OiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYt dGVhcy1hc3NvYy1jb3JvdXRlZC1iaWRpci1mcnItMDYNCg0KUGxlYXNlIGxldCB1cyBrbm93IGlm IHlvdSBvayB3aXRoIHRoZSBkb2N1bWVudC4NCg0KVGhhbmtzLA0KUmFrZXNoDQoNCkZyb206IERh bmllbGUgQ2VjY2FyZWxsaSA8ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbT4NCkRhdGU6 IE1vbmRheSwgQXVndXN0IDIwLCAyMDE4IGF0IDQ6NTYgQU0NClRvOiAiPVNNVFA6cmdhbmRoaUBj aXNjby4gY29tIiA8cmdhbmRoaUBjaXNjby5jb20+LCAiPHJ0Zy1hZHNAaWV0Zi5vcmc+IChydGct YWRzQGlldGYub3JnKSIgPHJ0Zy1hZHNAaWV0Zi5vcmc+DQpDYzogInJ0Zy1kaXJAaWV0Zi5vcmci IDxydGctZGlyQGlldGYub3JnPiwgIlRFQVMgV0cgKHRlYXNAaWV0Zi5vcmcpIiA8dGVhc0BpZXRm Lm9yZz4sICJkcmFmdC1pZXRmLXRlYXMtYXNzb2MtY29yb3V0ZWQtYmlkaXItZnJyLmFsbEBpZXRm Lm9yZyIgPGRyYWZ0LWlldGYtdGVhcy1hc3NvYy1jb3JvdXRlZC1iaWRpci1mcnIuYWxsQGlldGYu b3JnPg0KU3ViamVjdDogUkU6IFJ0Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtdGVhcy1hc3NvYy1j b3JvdXRlZC1iaWRpci1mcnItMDQNCg0KSGkgUmFrZXNoLA0KDQp0aGFua3MgZm9yIHRoZSB1cGRh dGUuDQoNClRoZSB0ZXJtaW5vbG9neSBzZWN0aW9uIGlzIGEgdmVyeSBtaW5vciBpc3N1ZXMsIHRo ZSBpbXBvcnRhbnQgdGhpbmcgaXMgdGhhdCBpdCBpcyB0aGVyZS4gSSB3b3VsZCBwcmVmZXIgdG8g aGF2ZSBpdCBhdCB0aGUgYmVnaW5uaW5nIGFzIHNvbWV0aW1lcyBJIGZvdW5kIGl0IGhhcmQgdG8g cmVhZCB0aGUgaW50cm8gd2hlcmUgdGVybXMgbm90IHlldCBkZWZpbmVkIHdlcmUgdXNlZC4NClBs ZWFzZSBhbHNvIGFkZHJlc3MgdGhlIGNvbW1lbnQgZnJvbSBEZWJvcmFoIHRvIGFkZCBvbmUgb3Ig dHdvIHNlbnRlbmNlcyB0byBzZWN0aW9uIDUgb24gd2hhdCBoYXBwZW5zIGlmIG9uZSBvZiB0aGUg bm9kZXMgZG9lcyBub3Qgc3VwcG9ydCB0aGUgZmVhdHVyZS4NCg0KV2hlbiB0aGF0IGlzIGRvbmUg SeKAmW0gb2sgd2l0aCB0aGUgZG9jdW1lbnQuDQpUaGFua3MNCkRhbmllbGUNCg0KRnJvbTogUmFr ZXNoIEdhbmRoaSAocmdhbmRoaSkgPHJnYW5kaGlAY2lzY28uY29tPg0KU2VudDogbWVyY29sZWTD rCA4IGFnb3N0byAyMDE4IDIxOjMwDQpUbzogRGFuaWVsZSBDZWNjYXJlbGxpIDxkYW5pZWxlLmNl Y2NhcmVsbGlAZXJpY3Nzb24uY29tPjsgPHJ0Zy1hZHNAaWV0Zi5vcmc+IChydGctYWRzQGlldGYu b3JnKSA8cnRnLWFkc0BpZXRmLm9yZz4NCkNjOiBydGctZGlyQGlldGYub3JnOyBURUFTIFdHICh0 ZWFzQGlldGYub3JnKSA8dGVhc0BpZXRmLm9yZz47IGRyYWZ0LWlldGYtdGVhcy1hc3NvYy1jb3Jv dXRlZC1iaWRpci1mcnIuYWxsQGlldGYub3JnDQpTdWJqZWN0OiBSZTogUnRnRGlyIHJldmlldzog ZHJhZnQtaWV0Zi10ZWFzLWFzc29jLWNvcm91dGVkLWJpZGlyLWZyci0wNA0KDQpIaSBEYW5pZWxl LA0KDQpGWUksIHdlIGhhdmUgdXBsb2FkZWQgdGhpcyB2ZXJzaW9uLiBQbGVhc2UgbGV0IHVzIGtu b3cgaWYgeW91IGhhdmUgYWRkaXRpb25hbCBjb21tZW50cy4NCg0KDQpodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10ZWFzLWFzc29jLWNvcm91dGVkLWJpZGlyLWZyci0wNQ0K DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtdGVhcy1h c3NvYy1jb3JvdXRlZC1iaWRpci1mcnItMDUNCg0KDQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91 cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LWlldGYtdGVhcy1hc3NvYy1jb3JvdXRlZC1iaWRpci1mcnItMDUNCg0KDQoN ClRoYW5rcywNClJha2VzaCAoZm9yIGF1dGhvcnMpDQoNCg0KRnJvbTogIj1TTVRQOnJnYW5kaGlA Y2lzY28uIGNvbSIgPHJnYW5kaGlAY2lzY28uY29tPG1haWx0bzpyZ2FuZGhpQGNpc2NvLmNvbT4+ DQpEYXRlOiBNb25kYXksIEp1bHkgMzAsIDIwMTggYXQgMTE6MjIgQU0NClRvOiBEYW5pZWxlIENl Y2NhcmVsbGkgPGRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb208bWFpbHRvOmRhbmllbGUu Y2VjY2FyZWxsaUBlcmljc3Nvbi5jb20+PiwgIjxydGctYWRzQGlldGYub3JnPG1haWx0bzpydGct YWRzQGlldGYub3JnPj4gKHJ0Zy1hZHNAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1hZHNAaWV0Zi5vcmc+ KSIgPHJ0Zy1hZHNAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1hZHNAaWV0Zi5vcmc+Pg0KQ2M6ICJydGct ZGlyQGlldGYub3JnPG1haWx0bzpydGctZGlyQGlldGYub3JnPiIgPHJ0Zy1kaXJAaWV0Zi5vcmc8 bWFpbHRvOnJ0Zy1kaXJAaWV0Zi5vcmc+PiwgIlRFQVMgV0cgKHRlYXNAaWV0Zi5vcmc8bWFpbHRv OnRlYXNAaWV0Zi5vcmc+KSIgPHRlYXNAaWV0Zi5vcmc8bWFpbHRvOnRlYXNAaWV0Zi5vcmc+Piwg ImRyYWZ0LWlldGYtdGVhcy1hc3NvYy1jb3JvdXRlZC1iaWRpci1mcnIuYWxsQGlldGYub3JnPG1h aWx0bzpkcmFmdC1pZXRmLXRlYXMtYXNzb2MtY29yb3V0ZWQtYmlkaXItZnJyLmFsbEBpZXRmLm9y Zz4iIDxkcmFmdC1pZXRmLXRlYXMtYXNzb2MtY29yb3V0ZWQtYmlkaXItZnJyLmFsbEBpZXRmLm9y ZzxtYWlsdG86ZHJhZnQtaWV0Zi10ZWFzLWFzc29jLWNvcm91dGVkLWJpZGlyLWZyci5hbGxAaWV0 Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFJ0Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtdGVhcy1hc3Nv Yy1jb3JvdXRlZC1iaWRpci1mcnItMDQNCg0KSGkgRGFuaWVsZSwNCg0KTWFueSB0aGFua3MgZm9y IHRoZSByZXZpZXcgb2YgdGhlIGRvY3VtZW50IGFuZCB5b3VyIHN1Z2dlc3Rpb25zLg0KRGlmZiBm aWxlIGlzIGZvciB0aGUgdXBkYXRlZCBkb2N1bWVudCBpcyBhdHRhY2hlZC4NClBsZWFzZSBzZWUg aW5saW5lIDxSRz7igKYNCg0KRnJvbTogRGFuaWVsZSBDZWNjYXJlbGxpIDxkYW5pZWxlLmNlY2Nh cmVsbGlAZXJpY3Nzb24uY29tPG1haWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29t Pj4NCkRhdGU6IFNhdHVyZGF5LCBKdWx5IDI4LCAyMDE4IGF0IDEwOjI4IEFNDQpUbzogIjxydGct YWRzQGlldGYub3JnPG1haWx0bzpydGctYWRzQGlldGYub3JnPj4gKHJ0Zy1hZHNAaWV0Zi5vcmc8 bWFpbHRvOnJ0Zy1hZHNAaWV0Zi5vcmc+KSIgPHJ0Zy1hZHNAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1h ZHNAaWV0Zi5vcmc+Pg0KQ2M6ICJydGctZGlyQGlldGYub3JnPG1haWx0bzpydGctZGlyQGlldGYu b3JnPiIgPHJ0Zy1kaXJAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1kaXJAaWV0Zi5vcmc+PiwgIlRFQVMg V0cgKHRlYXNAaWV0Zi5vcmc8bWFpbHRvOnRlYXNAaWV0Zi5vcmc+KSIgPHRlYXNAaWV0Zi5vcmc8 bWFpbHRvOnRlYXNAaWV0Zi5vcmc+PiwgImRyYWZ0LWlldGYtdGVhcy1hc3NvYy1jb3JvdXRlZC1i aWRpci1mcnIuYWxsQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLXRlYXMtYXNzb2MtY29yb3V0 ZWQtYmlkaXItZnJyLmFsbEBpZXRmLm9yZz4iIDxkcmFmdC1pZXRmLXRlYXMtYXNzb2MtY29yb3V0 ZWQtYmlkaXItZnJyLmFsbEBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi10ZWFzLWFzc29jLWNv cm91dGVkLWJpZGlyLWZyci5hbGxAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUnRnRGlyIHJldmlldzog ZHJhZnQtaWV0Zi10ZWFzLWFzc29jLWNvcm91dGVkLWJpZGlyLWZyci0wNA0KUmVzZW50LUZyb206 IDxhbGlhcy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzphbGlhcy1ib3VuY2VzQGlldGYub3JnPj4N ClJlc2VudC1UbzogIj1TTVRQOnJnYW5kaGlAY2lzY28uIGNvbSIgPHJnYW5kaGlAY2lzY28uY29t PG1haWx0bzpyZ2FuZGhpQGNpc2NvLmNvbT4+LCA8aHNoYWhAY2llbmEuY29tPG1haWx0bzpoc2hh aEBjaWVuYS5jb20+PiwgPGplcmVteS53aGl0dGFrZXJAdmVyaXpvbi5jb208bWFpbHRvOmplcmVt eS53aGl0dGFrZXJAdmVyaXpvbi5jb20+PiwgTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldDxt YWlsdG86bGJlcmdlckBsYWJuLm5ldD4+LCA8bWhhcnRsZXkuaWV0ZkBnbWFpbC5jb208bWFpbHRv Om1oYXJ0bGV5LmlldGZAZ21haWwuY29tPj4sIDx2YmVlcmFtQGp1bmlwZXIubmV0PG1haWx0bzp2 YmVlcmFtQGp1bmlwZXIubmV0Pj4sIDxtYXJ0aW4udmlnb3VyZXV4QG5va2lhLmNvbTxtYWlsdG86 bWFydGluLnZpZ291cmV1eEBub2tpYS5jb20+PiwgREVCT1JBSCBCUlVOR0FSRCA8ZGIzNTQ2QGF0 dC5jb208bWFpbHRvOmRiMzU0NkBhdHQuY29tPj4sIDxhcmV0YW5hLmlldGZAZ21haWwuY29tPG1h aWx0bzphcmV0YW5hLmlldGZAZ21haWwuY29tPj4sIFZpc2hudSBCZWVyYW0gPHZpc2hudXBhdmFu QGdtYWlsLmNvbTxtYWlsdG86dmlzaG51cGF2YW5AZ21haWwuY29tPj4sIDx2aXNobnVwYXZhbkBn bWFpbC5jb208bWFpbHRvOnZpc2hudXBhdmFuQGdtYWlsLmNvbT4+DQpSZXNlbnQtRGF0ZTogU2F0 dXJkYXksIEp1bHkgMjgsIDIwMTggYXQgMTA6MjggQU0NCg0KDQpIZWxsbywNCg0KSSBoYXZlIGJl ZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIHRoaXMg ZHJhZnQuIFRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHNlZWtzIHRvIHJldmlldyBhbGwgcm91dGlu ZyBvciByb3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkgcGFzcyB0aHJvdWdoIElFVEYgbGFz dCBjYWxsIGFuZCBJRVNHIHJldmlldywgYW5kIHNvbWV0aW1lcyBvbiBzcGVjaWFsIHJlcXVlc3Qu IFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Npc3RhbmNlIHRvIHRo ZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFJvdXRpbmcgRGly ZWN0b3JhdGUsIHBsZWFzZSBzZWUg4oCLaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9y dGcvdHJhYy93aWtpL1J0Z0RpcjxodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90 cmFjL3dpa2kvUnRnRGlyPg0KDQpBbHRob3VnaCB0aGVzZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5 IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQgd291bGQgYmUgaGVscGZ1bCBpZiB5 b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhlciBJRVRGIExhc3QgQ2Fs bCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZlIHRvIHJlc29sdmUgdGhlbSB0 aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhlIGRyYWZ0Lg0KDQpEb2N1bWVudDog ZHJhZnQtaWV0Zi10ZWFzLWFzc29jLWNvcm91dGVkLWJpZGlyLWZyci0wNA0KUmV2aWV3ZXI6IERh bmllbGUgQ2VjY2FyZWxsaQ0KUmV2aWV3IERhdGU6IDI3LzA3LzIwMTgNCklFVEYgTEMgRW5kIERh dGU6IGRhdGUtaWYta25vd24NCkludGVuZGVkIFN0YXR1czogU3RhbmRhcmQgdHJhY2sNCg0KU3Vt bWFyeToNCg0KDQoNCg0KICAqICAgSSBoYXZlIHNvbWUgbWlub3IgY29uY2VybnMgYWJvdXQgdGhp cyBkb2N1bWVudCB0aGF0IEkgdGhpbmsgc2hvdWxkIGJlIHJlc29sdmVkIGJlZm9yZSBwdWJsaWNh dGlvbi4NCg0KQ29tbWVudHM6DQoNCiAgKiAgIFRoZSBkb2N1bWVudCBpcyB2ZXJ5IHdlbGwgd3Jp dHRlbiBhbmQgdGhlIHByb2JsZW0gY2xlYXJseSBzdGF0ZWQgKGV2ZW4gaWYgY2FsbGVkIG92ZXJ2 aWV3IPCfmIogKS4gVGhlIHNlY29uZCBwYXJ0IGlzIGEgYml0IGhhcmRlciB0byBmb2xsb3cgYnV0 IEkgZG9u4oCZdCBzZWUgaG93IHRvIG1ha2UgdGhlIHByb2NlZHVyZSBzZWN0aW9uIGVhc2llciB0 byByZWFkLg0KPFJHPiBPaywgdGhhbmtzLg0KDQogICogICBJdCBpcyBub3QgY2xlYXIgdG8gbWUg d2h5IHRoZXJlIGlzIGFuIOKAnGV4YW1wbGXigJ0gb2YgRXh0ZW5kZWQgQXNzb2NpYXRpb24gSUQg aW4gdGhlIGFwcGVuZGl4LiBSRkMgNjc4MCBqdXN0IHNheXMgaXQg4oCcY29udGFpbnMgZGF0YSB0 aGF0IGlzIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gdG8gc3VwcG9ydCB1bmlxdWUgaWRlbnRpZmlj YXRpb24u4oCdIEJ1dCBkb2VzbuKAmXQgZGVzY3JpYmUgaG93IGl0IHNob3VsZCBiZSBmaWxsZWQu IERvZXMgdGhpcyBtZWFuIHRoZXJlIGlzIG5vIHN0YW5kYXJkIGZvcm1hdCBmb3IgaXQ/DQo8Ukc+ IFJpZ2h0LiBFeGFtcGxlIHNob3duIGluIHRoZSBBcHBlbmRpeCBpcyBvbmUgdW4tYW1iaWd1b3Vz IHdheSB0byBwb3B1bGF0ZSBpdCBmb3IgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIExTUHMuDQoN Ck1ham9yIElzc3VlczoNCg0KTm9uZQ0KDQpNaW5vciBJc3N1ZXM6DQoNCiAgKiAgIE1vdmluZyB0 aGUgdGVybWlub2xvZ3kgc2VjdGlvbiBiZWZvcmUgdGhlIGludHJvZHVjdGlvbiB3b3VsZCBpbXBy b3ZlIHJlYWRhYmlsaXR5LCBzaW5jZSB0aGUgdGVybXMgZGVmaW5lZCBpbiB0aGUgdGVybWlub2xv Z3kgc2VjdGlvbiBhcmUgZnJlcXVlbnRseSB1c2VkIGluIHRoZSBpbnRyb2R1Y3Rpb24uDQo8Ukc+ IEkgYW0gbm90IGZhbWlsaWFyIHdpdGggYW4gUkZDIHdoZXJlIHRlcm1pbm9sb2d5IGlzIHRoZSBm aXJzdCBzZWN0aW9uLiBJIGFtIGZpbmUgZWl0aGVyIHdheSwgcGxlYXNlIGxldCBtZSBrbm93IGlm IHlvdSBwcmVmZXIgdGhpcyB3YXkuDQoNCiAgKiAgIFdoZW4gSSByZWFkIHRoZSB0aXRsZSBvZiBz ZWN0aW9uIDMgKG92ZXJ2aWV3KSwgSSB0aG91Z2h0IOKAnHdoeSBhbiBvdmVydmlldyBpcyBuZWVk ZWQgaWYgdGhlcmUgaXMgYW4gaW50cm9kdWN0aW9uP+KAnS4gQWN0dWFsbHkgdGhlIHRleHQgaW4g dGhhdCBzZWN0aW9uIGlzIHZlcnkgdXNlZnVsIGJ1dCBtb3JlIHRoYW4gYW4gb3ZlcnZpZXcgSSB3 b3VsZCBjYWxsIGl0IGEgcHJvYmxlbSBzdGF0ZW1lbnQgKG9yIHNvbWV0aGluZyBsaWtlIHRoYXQp Lg0KPFJHPiBDb3JyZWN0ZWQuDQoNCiAgKiAgIFRoZSB1c2FnZSBvZiBSRkMgMjExOSAob3Igc2hv dWxkIHdlIHJlZmVyZW5jZSBSRkMgODE3NCA/PykgaXMgbm90IGNvbmdydWVudCBhbGwgb3ZlciB0 aGUgZG9jdW1lbnQuIEUuZy4gc2VjdGlvbiA0LjENCg0KICBvICBUaGUgZG93bnN0cmVhbSBQTFIg bm9kZSBhbHdheXMgaW5pdGlhdGVzIHRoZSBieXBhc3MgdHVubmVsDQoNCiAgICAgIGFzc2lnbm1l bnQgZm9yIHRoZSBmb3J3YXJkIExTUC4gIFRoZSB1cHN0cmVhbSBQTFIgKGZvcndhcmQNCg0KICAg ICAgZGlyZWN0aW9uIExTUCBNUCkgbm9kZSBzaW1wbHkgcmVmbGVjdHMgdGhlIGFzc29jaWF0ZWQg YnlwYXNzDQoNCiAgICAgIHR1bm5lbCBhc3NpZ25tZW50IGZvciB0aGUgcmV2ZXJzZSBkaXJlY3Rp b24gTFNQLiAgVGhlIHVwc3RyZWFtIFBMUg0KDQogICAgICBub2RlIE1VU1QgTk9UIGluaXRpYXRl IHRoZSBieXBhc3MgdHVubmVsIGFzc2lnbm1lbnQuDQoNCg0KDQo8Ukc+IENvcnJlY3RlZC4NCg0K Tml0czoNCg0KICAqICAgU2VjdGlvbjE6IOKAnChHKU11bHRpcHJvdG9jb2wgTGFiZWwgU3dpdGNo aW5nIChNUExTKSBUcmFmZmljIEVuZ2luZWVyaW5nIChURSkgTGFiZWwgU3dpdGNoZWQgUGF0aHMg KExTUHMp4oCdLiBUaGlzIGZvcm1hdHRpbmcgZG9lc27igJl0IG1ha2UgbXVjaCBzZW5zZS4gSW4g dGhlIGZpcnN0IGluc3RhbmNlIHRoZSBicmFja2V0cyBhcmUgdXNlZCB0byBzYXkgTVBMUyBvciBH TVBMUyB3aGlsZSBpbiB0aGUgb3RoZXIgb25lcyB0byBkZWZpbmUgdGhlIGFjcm9ueW1zLg0KPFJH PiBDb3JyZWN0ZWQuDQoNCiAgKiAgIFNlY3Rpb24gMy4xIHRoZXJlIGlzIG5vIG5lZWQgdG8gcmVw ZWF0IHR3aWNlIHRoYXQgQnlwYXNzIHR1bm5lbCBOIHVzZXMgcGF0aCBCLUgtSS1DIGFuZCBCeXBh c3MgdHVubmVsIFMgcGF0aCBCLUYtRy1DLiBUaGUgc2Vjb25kIHRpbWUgdGhlIGJyYWNrZXQgY2Fu IGJlIGRyb3BwZWQuDQo8Ukc+IENvcnJlY3RlZC4NCg0KICAqICAgU2VjdGlvbiA0LjEuMS4gLSAg cy9TSE9VTEQgdHJpZ2dlciB0aGUgcHJvY2VkdXJlLyBTSE9VTEQgdHJpZ2dlciBwcm9jZWR1cmUN CjxSRz4gQ29ycmVjdGVkLg0KVGhhbmtzLA0KUmFrZXNoIChmb3IgYXV0aG9ycykNCg0KDQpCUg0K RGFuaWVsZQ0K --_000_E51A0C3E660448CAB39B45EB25001012ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6QXJpYWw7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAy IDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCXBh bm9zZS0xOjIgNyAzIDkgMiAyIDUgMiA0IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpU aW1lczsNCglwYW5vc2UtMToyIDAgNSAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0 IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFu b3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNh bGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQXBwbGUgQ29sb3IgRW1vamkiOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAg MCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3Jt YWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseTpDYWxpYnJpO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5U ZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KcA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Ijt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5N c29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFw aA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJp Z2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6Q2Fs aWJyaTt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0K CW1zby1mYXJlYXN0LWxhbmd1YWdlOklUO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwg ZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNt Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCnAucDEsIGxp LnAxLCBkaXYucDENCgl7bXNvLXN0eWxlLW5hbWU6cDE7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo3LjBw dDsNCglmb250LWZhbWlseTpUaW1lczt9DQpwLnAyLCBsaS5wMiwgZGl2LnAyDQoJe21zby1zdHls ZS1uYW1lOnAyOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltYXJnaW46MGNtOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6Ny4wcHQ7DQoJZm9udC1mYW1pbHk6VGltZXM7 DQoJY29sb3I6IzA0MkVFRTt9DQpwLnAzLCBsaS5wMywgZGl2LnAzDQoJe21zby1zdHlsZS1uYW1l OnAzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6Ny4wcHQ7DQoJZm9udC1mYW1pbHk6VGltZXM7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uaWNvbg0KCXttc28tc3R5bGUtbmFt ZTppY29uO30NCnNwYW4uRW1haWxTdHlsZTI2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5 bGUyNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseTpDYWxpYnJpOw0K CWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5zMg0KCXttc28tc3R5bGUtbmFtZTpzMjsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uczENCgl7bXNvLXN0eWxlLW5hbWU6czE7fQ0K c3Bhbi5FbWFpbFN0eWxlMzANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p bHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTMzDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29s b3I6d2luZG93dGV4dDt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBs YWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseTpDYWxpYnJpO30NCnNwYW4ubXNvSW5zDQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCAyLjBjbSAy LjBjbSAyLjBjbTt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8q IExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjk4NzE3MDYzMTsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEzMjczMzI5MjA7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w OjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxp c3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIx Ni4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTEwNDI5 OTMxMzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MjA0NjA0NDUyNDt9DQpAbGlzdCBsMTpsZXZl bDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9 DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDox NzQ3NzIxMzQ3Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTM1Mzg0NTI2O30NCkBsaXN0IGwy OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyNTIu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwy OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzDQoJe21zby1saXN0 LWlkOjIwODk5NjMyMDY7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNzAyNDUwNTU4O30NCkBs aXN0IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iO30NCkBsaXN0IGwzOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwzOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwzOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1i b3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+DQo8L2hl YWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZs aW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5IaSBEYW5pZWxlLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFuayB5b3UgZm9y IHRoZSByZXZpZXcgY29tbWVudHMgYW5kIGZlZWRiYWNrcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+V2UgaGF2ZSBhZGRyZXNzZWQgdGhlIGNvbW1lbnRzIGluIHRoZSBsYXRlc3QgZHJhZnQgQDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgSHRtbGl6ZWQ6Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLXRlYXMtYXNzb2MtY29yb3V0ZWQtYmlkaXItZnJyLTA2PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgRGlmZjom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdGVhcy1hc3Nv Yy1jb3JvdXRlZC1iaWRpci1mcnItMDY8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNlIGxl dCB1cyBrbm93IGlmIHlvdSBvayB3aXRoIHRoZSBkb2N1bWVudC48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmFrZXNo PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPkRhbmllbGUgQ2VjY2FyZWxsaSAmbHQ7ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNz c29uLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+TW9uZGF5LCBBdWd1c3QgMjAsIDIwMTggYXQg NDo1NiBBTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7PVNNVFA6cmdhbmRoaUBjaXNjby4gY29tJnF1 b3Q7ICZsdDtyZ2FuZGhpQGNpc2NvLmNvbSZndDssICZxdW90OyZsdDtydGctYWRzQGlldGYub3Jn Jmd0OyAocnRnLWFkc0BpZXRmLm9yZykmcXVvdDsgJmx0O3J0Zy1hZHNAaWV0Zi5vcmcmZ3Q7PGJy Pg0KPGI+Q2M6IDwvYj4mcXVvdDtydGctZGlyQGlldGYub3JnJnF1b3Q7ICZsdDtydGctZGlyQGll dGYub3JnJmd0OywgJnF1b3Q7VEVBUyBXRyAodGVhc0BpZXRmLm9yZykmcXVvdDsgJmx0O3RlYXNA aWV0Zi5vcmcmZ3Q7LCAmcXVvdDtkcmFmdC1pZXRmLXRlYXMtYXNzb2MtY29yb3V0ZWQtYmlkaXIt ZnJyLmFsbEBpZXRmLm9yZyZxdW90OyAmbHQ7ZHJhZnQtaWV0Zi10ZWFzLWFzc29jLWNvcm91dGVk LWJpZGlyLWZyci5hbGxAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJFOiBSdGdE aXIgcmV2aWV3OiBkcmFmdC1pZXRmLXRlYXMtYXNzb2MtY29yb3V0ZWQtYmlkaXItZnJyLTA0PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFJha2Vz aCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhhbmtzIGZvciB0aGUgdXBkYXRlLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGUgdGVybWlub2xvZ3kgc2VjdGlvbiBpcyBhIHZlcnkgbWlub3Ig aXNzdWVzLCB0aGUgaW1wb3J0YW50IHRoaW5nIGlzIHRoYXQgaXQgaXMgdGhlcmUuIEkgd291bGQg cHJlZmVyIHRvIGhhdmUgaXQgYXQgdGhlIGJlZ2lubmluZyBhcyBzb21ldGltZXMgSSBmb3VuZCBp dCBoYXJkIHRvIHJlYWQgdGhlIGludHJvIHdoZXJlIHRlcm1zIG5vdCB5ZXQgZGVmaW5lZCB3ZXJl IHVzZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2UgYWxzbyBh ZGRyZXNzIHRoZSBjb21tZW50IGZyb20gRGVib3JhaCB0byBhZGQgb25lIG9yIHR3byBzZW50ZW5j ZXMgdG8gc2VjdGlvbiA1IG9uIHdoYXQgaGFwcGVucyBpZiBvbmUgb2YgdGhlIG5vZGVzIGRvZXMg bm90IHN1cHBvcnQgdGhlIGZlYXR1cmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoZW4gdGhh dCBpcyBkb25lIEnigJltIG9rIHdpdGggdGhlIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5EYW5pZWxlJm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9i PiBSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKSAmbHQ7cmdhbmRoaUBjaXNjby5jb20mZ3Q7IDxicj4N CjxiPlNlbnQ6PC9iPiBtZXJjb2xlZMOsIDggYWdvc3RvIDIwMTggMjE6MzA8YnI+DQo8Yj5Ubzo8 L2I+IERhbmllbGUgQ2VjY2FyZWxsaSAmbHQ7ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNv bSZndDs7ICZsdDtydGctYWRzQGlldGYub3JnJmd0OyAocnRnLWFkc0BpZXRmLm9yZykgJmx0O3J0 Zy1hZHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBydGctZGlyQGlldGYub3JnOyBURUFT IFdHICh0ZWFzQGlldGYub3JnKSAmbHQ7dGVhc0BpZXRmLm9yZyZndDs7IGRyYWZ0LWlldGYtdGVh cy1hc3NvYy1jb3JvdXRlZC1iaWRpci1mcnIuYWxsQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLXRlYXMtYXNzb2MtY29yb3V0ZWQtYmlk aXItZnJyLTA0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SGkgRGFuaWVsZSw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkZZSSwgd2UgaGF2ZSB1cGxvYWRlZCB0aGlzIHZlcnNpb24u IFBsZWFzZSBsZXQgdXMga25vdyBpZiB5b3UgaGF2ZSBhZGRpdGlvbmFsIGNvbW1lbnRzLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0icDIi PjxzcGFuIGNsYXNzPSJzMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRlYXMtYXNzb2MtY29yb3V0 ZWQtYmlkaXItZnJyLTA1Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10 ZWFzLWFzc29jLWNvcm91dGVkLWJpZGlyLWZyci0wNTwvYT48L3NwYW4+PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9InAyIj48c3BhbiBjbGFzcz0iczIiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9o dG1sL2RyYWZ0LWlldGYtdGVhcy1hc3NvYy1jb3JvdXRlZC1iaWRpci1mcnItMDUiPmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi10ZWFzLWFzc29jLWNvcm91 dGVkLWJpZGlyLWZyci0wNTwvYT48L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9InAzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9InAxIj48c3BhbiBjbGFzcz0iczEiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij5BIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFp bGFibGUgYXQ6PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJwMiI+PHNw YW4gY2xhc3M9InMyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdGVhcy1hc3NvYy1jb3Jv dXRlZC1iaWRpci1mcnItMDUiPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1pZXRmLXRlYXMtYXNzb2MtY29yb3V0ZWQtYmlkaXItZnJyLTA1PC9hPjwvc3Bhbj48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0icDMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlRo YW5rcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+UmFrZXNoIChmb3IgYXV0aG9ycyk8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mcXVvdDs9U01UUDpyZ2FuZGhpQGNpc2NvLiBj b20mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyZ2FuZGhpQGNpc2NvLmNvbSI+cmdhbmRoaUBj aXNjby5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIEp1bHkgMzAsIDIwMTgg YXQgMTE6MjIgQU08YnI+DQo8Yj5UbzogPC9iPkRhbmllbGUgQ2VjY2FyZWxsaSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb20iPmRhbmllbGUuY2VjY2Fy ZWxsaUBlcmljc3Nvbi5jb208L2E+Jmd0OywgJnF1b3Q7Jmx0OzxhIGhyZWY9Im1haWx0bzpydGct YWRzQGlldGYub3JnIj5ydGctYWRzQGlldGYub3JnPC9hPiZndDsgKDxhIGhyZWY9Im1haWx0bzpy dGctYWRzQGlldGYub3JnIj5ydGctYWRzQGlldGYub3JnPC9hPikmcXVvdDsgJmx0OzxhIGhyZWY9 Im1haWx0bzpydGctYWRzQGlldGYub3JnIj5ydGctYWRzQGlldGYub3JnPC9hPiZndDs8YnI+DQo8 Yj5DYzogPC9iPiZxdW90OzxhIGhyZWY9Im1haWx0bzpydGctZGlyQGlldGYub3JnIj5ydGctZGly QGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Zy1kaXJAaWV0Zi5vcmci PnJ0Zy1kaXJAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7VEVBUyBXRyAoPGEgaHJlZj0ibWFpbHRv OnRlYXNAaWV0Zi5vcmciPnRlYXNAaWV0Zi5vcmc8L2E+KSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnRlYXNAaWV0Zi5vcmciPnRlYXNAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0i bWFpbHRvOmRyYWZ0LWlldGYtdGVhcy1hc3NvYy1jb3JvdXRlZC1iaWRpci1mcnIuYWxsQGlldGYu b3JnIj5kcmFmdC1pZXRmLXRlYXMtYXNzb2MtY29yb3V0ZWQtYmlkaXItZnJyLmFsbEBpZXRmLm9y ZzwvYT4mcXVvdDsNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtdGVhcy1hc3NvYy1j b3JvdXRlZC1iaWRpci1mcnIuYWxsQGlldGYub3JnIj5kcmFmdC1pZXRmLXRlYXMtYXNzb2MtY29y b3V0ZWQtYmlkaXItZnJyLmFsbEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9i PlJlOiBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLXRlYXMtYXNzb2MtY29yb3V0ZWQtYmlkaXIt ZnJyLTA0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5IaSBEYW5pZWxlLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYW55IHRoYW5rcyBm b3IgdGhlIHJldmlldyBvZiB0aGUgZG9jdW1lbnQgYW5kIHlvdXIgc3VnZ2VzdGlvbnMuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EaWZmIGZpbGUgaXMgZm9yIHRoZSB1cGRh dGVkIGRvY3VtZW50IGlzIGF0dGFjaGVkLiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlBsZWFzZSBzZWUgaW5saW5lICZsdDtSRyZndDvigKY8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RGFuaWVsZSBD ZWNjYXJlbGxpICZsdDs8YSBocmVmPSJtYWlsdG86ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29u LmNvbSI+ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0 ZTogPC9iPlNhdHVyZGF5LCBKdWx5IDI4LCAyMDE4IGF0IDEwOjI4IEFNPGJyPg0KPGI+VG86IDwv Yj4mcXVvdDsmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Zy1hZHNAaWV0Zi5vcmciPnJ0Zy1hZHNAaWV0 Zi5vcmc8L2E+Jmd0OyAoPGEgaHJlZj0ibWFpbHRvOnJ0Zy1hZHNAaWV0Zi5vcmciPnJ0Zy1hZHNA aWV0Zi5vcmc8L2E+KSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Zy1hZHNAaWV0Zi5vcmci PnJ0Zy1hZHNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7PGEgaHJlZj0i bWFpbHRvOnJ0Zy1kaXJAaWV0Zi5vcmciPnJ0Zy1kaXJAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86cnRnLWRpckBpZXRmLm9yZyI+cnRnLWRpckBpZXRmLm9yZzwvYT4mZ3Q7 LCAmcXVvdDtURUFTIFdHICg8YSBocmVmPSJtYWlsdG86dGVhc0BpZXRmLm9yZyI+dGVhc0BpZXRm Lm9yZzwvYT4pJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86dGVhc0BpZXRmLm9yZyI+dGVhc0Bp ZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi10ZWFzLWFz c29jLWNvcm91dGVkLWJpZGlyLWZyci5hbGxAaWV0Zi5vcmciPmRyYWZ0LWlldGYtdGVhcy1hc3Nv Yy1jb3JvdXRlZC1iaWRpci1mcnIuYWxsQGlldGYub3JnPC9hPiZxdW90Ow0KICZsdDs8YSBocmVm PSJtYWlsdG86ZHJhZnQtaWV0Zi10ZWFzLWFzc29jLWNvcm91dGVkLWJpZGlyLWZyci5hbGxAaWV0 Zi5vcmciPmRyYWZ0LWlldGYtdGVhcy1hc3NvYy1jb3JvdXRlZC1iaWRpci1mcnIuYWxsQGlldGYu b3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UnRnRGlyIHJldmlldzogZHJhZnQtaWV0 Zi10ZWFzLWFzc29jLWNvcm91dGVkLWJpZGlyLWZyci0wNDxicj4NCjxiPlJlc2VudC1Gcm9tOiA8 L2I+Jmx0OzxhIGhyZWY9Im1haWx0bzphbGlhcy1ib3VuY2VzQGlldGYub3JnIj5hbGlhcy1ib3Vu Y2VzQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5SZXNlbnQtVG86IDwvYj4mcXVvdDs9U01UUDpy Z2FuZGhpQGNpc2NvLiBjb20mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyZ2FuZGhpQGNpc2Nv LmNvbSI+cmdhbmRoaUBjaXNjby5jb208L2E+Jmd0OywgJmx0OzxhIGhyZWY9Im1haWx0bzpoc2hh aEBjaWVuYS5jb20iPmhzaGFoQGNpZW5hLmNvbTwvYT4mZ3Q7LCAmbHQ7PGEgaHJlZj0ibWFpbHRv OmplcmVteS53aGl0dGFrZXJAdmVyaXpvbi5jb20iPmplcmVteS53aGl0dGFrZXJAdmVyaXpvbi5j b208L2E+Jmd0OywgTG91IEJlcmdlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxiZXJnZXJAbGFibi5u ZXQiPmxiZXJnZXJAbGFibi5uZXQ8L2E+Jmd0OywNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1oYXJ0 bGV5LmlldGZAZ21haWwuY29tIj5taGFydGxleS5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7LCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnZiZWVyYW1AanVuaXBlci5uZXQiPnZiZWVyYW1AanVuaXBlci5uZXQ8 L2E+Jmd0OywgJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4udmlnb3VyZXV4QG5va2lhLmNvbSI+ bWFydGluLnZpZ291cmV1eEBub2tpYS5jb208L2E+Jmd0OywgREVCT1JBSCBCUlVOR0FSRCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmRiMzU0NkBhdHQuY29tIj5kYjM1NDZAYXR0LmNvbTwvYT4mZ3Q7LA0K ICZsdDs8YSBocmVmPSJtYWlsdG86YXJldGFuYS5pZXRmQGdtYWlsLmNvbSI+YXJldGFuYS5pZXRm QGdtYWlsLmNvbTwvYT4mZ3Q7LCBWaXNobnUgQmVlcmFtICZsdDs8YSBocmVmPSJtYWlsdG86dmlz aG51cGF2YW5AZ21haWwuY29tIj52aXNobnVwYXZhbkBnbWFpbC5jb208L2E+Jmd0OywgJmx0Ozxh IGhyZWY9Im1haWx0bzp2aXNobnVwYXZhbkBnbWFpbC5jb20iPnZpc2hudXBhdmFuQGdtYWlsLmNv bTwvYT4mZ3Q7PGJyPg0KPGI+UmVzZW50LURhdGU6IDwvYj5TYXR1cmRheSwgSnVseSAyOCwgMjAx OCBhdCAxMDoyOCBBTTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OlZlcmRhbmE7Y29sb3I6YmxhY2siPkhlbGxvLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlO2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1h bDtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IDI7dGV4dC1hbGlnbjpzdGFydDt3 aWRvd3M6IDI7LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3RleHQtZGVjb3JhdGlvbi1z dHlsZTogaW5pdGlhbDt0ZXh0LWRlY29yYXRpb24tY29sb3I6IGluaXRpYWw7d29yZC1zcGFjaW5n OjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpWZXJkYW5h O2NvbG9yOmJsYWNrIj5JIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3Rv cmF0ZSByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vl a3MgdG8gcmV2aWV3IGFsbCByb3V0aW5nIG9yIHJvdXRpbmctcmVsYXRlZCBkcmFmdHMgYXMgdGhl eSBwYXNzIHRocm91Z2ggSUVURiBsYXN0IGNhbGwgYW5kIElFU0cNCiByZXZpZXcsIGFuZCBzb21l dGltZXMgb24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRv IHByb3ZpZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0 aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlJm5ic3A7PGEgaHJl Zj0iaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0RpciI+ PHNwYW4gY2xhc3M9Imljb24iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpBcmlhbDtjb2xvcjoj QkIwMDAwO3RleHQtZGVjb3JhdGlvbjpub25lIj7igIs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjojQkIwMDAwIj5odHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFj L3dpa2kvUnRnRGlyPC9zcGFuPjwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZTtmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7Zm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiAyO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiAyOy13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt0ZXh0LWRlY29yYXRpb24tc3R5bGU6IGluaXRp YWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOiBpbml0aWFsO3dvcmQtc3BhY2luZzowcHgiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6VmVyZGFuYTtjb2xvcjpibGFj ayI+QWx0aG91Z2ggdGhlc2UgY29tbWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0 aGUgUm91dGluZyBBRHMsIGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVy IHRoZW0gYWxvbmcgd2l0aCBhbnkgb3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5 b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZSB0bw0KIHJlc29sdmUgdGhlbSB0aHJvdWdoIGRpc2N1c3Np b24gb3IgYnkgdXBkYXRpbmcgdGhlIGRyYWZ0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlO2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDtmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IDI7dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6 IDI7LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3RleHQtZGVjb3JhdGlvbi1zdHlsZTog aW5pdGlhbDt0ZXh0LWRlY29yYXRpb24tY29sb3I6IGluaXRpYWw7d29yZC1zcGFjaW5nOjBweCI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpWZXJkYW5hO2NvbG9y OmJsYWNrIj5Eb2N1bWVudDogZHJhZnQtaWV0Zi10ZWFzLWFzc29jLWNvcm91dGVkLWJpZGlyLWZy ci0wNDxicj4NClJldmlld2VyOiBEYW5pZWxlIENlY2NhcmVsbGk8YnI+DQpSZXZpZXcgRGF0ZTog MjcvMDcvMjAxODxicj4NCklFVEYgTEMgRW5kIERhdGU6IGRhdGUtaWYta25vd24mbmJzcDs8YnI+ DQpJbnRlbmRlZCBTdGF0dXM6IFN0YW5kYXJkIHRyYWNrPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGU7Zm9udC12YXJp YW50LWxpZ2F0dXJlczogbm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczog Mjt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogMjstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOiBpbml0aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjog aW5pdGlhbDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6VmVyZGFuYTtjb2xvcjpibGFjayI+U3VtbWFyeTo8L3NwYW4+ PC9zdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6VmVyZGFu YTtjb2xvcjpibGFjayI+Jm5ic3A7PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDEgbGZvMTtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpWZXJkYW5hIj5JIGhhdmUgc29tZSBtaW5vciBjb25jZXJucyBh Ym91dCB0aGlzIGRvY3VtZW50IHRoYXQgSSB0aGluayBzaG91bGQgYmUgcmVzb2x2ZWQgYmVmb3Jl IHB1YmxpY2F0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OlZlcmRhbmE7Y29sb3I6YmxhY2siPkNvbW1lbnRzOjwvc3Bhbj48L3N0cm9uZz48bzpw PjwvbzpwPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6VmVyZGFuYSI+VGhlIGRvY3VtZW50IGlzIHZlcnkgd2VsbCB3 cml0dGVuIGFuZCB0aGUgcHJvYmxlbSBjbGVhcmx5IHN0YXRlZCAoZXZlbiBpZiBjYWxsZWQgb3Zl cnZpZXcNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXBwbGUgQ29sb3Ig RW1vamkmcXVvdDsiPiYjMTI4NTIyOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6VmVy ZGFuYSI+ICkuIFRoZSBzZWNvbmQgcGFydCBpcyBhIGJpdCBoYXJkZXIgdG8gZm9sbG93IGJ1dCBJ IGRvbuKAmXQgc2VlIGhvdyB0byBtYWtlIHRoZSBwcm9jZWR1cmUgc2VjdGlvbiBlYXNpZXIgdG8g cmVhZC4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpWZXJkYW5hO2Nv bG9yOmJsYWNrIj4mbHQ7UkcmZ3Q7IE9rLCB0aGFua3MuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N Cjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6Ymxh Y2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6VmVyZGFuYSI+SXQgaXMgbm90IGNsZWFyIHRvIG1lIHdoeSB0aGVyZSBpcyBhbiDi gJxleGFtcGxl4oCdIG9mIEV4dGVuZGVkIEFzc29jaWF0aW9uIElEIGluIHRoZSBhcHBlbmRpeC4g UkZDIDY3ODAganVzdCBzYXlzIGl0IOKAnGNvbnRhaW5zIGRhdGEgdGhhdCBpcyBhZGRpdGlvbmFs IGluZm9ybWF0aW9uIHRvIHN1cHBvcnQgdW5pcXVlIGlkZW50aWZpY2F0aW9uLuKAnSBCdXQgZG9l c27igJl0IGRlc2NyaWJlIGhvdyBpdA0KIHNob3VsZCBiZSBmaWxsZWQuIERvZXMgdGhpcyBtZWFu IHRoZXJlIGlzIG5vIHN0YW5kYXJkIGZvcm1hdCBmb3IgaXQ/PC9zcGFuPjxvOnA+PC9vOnA+PC9s aT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OlZlcmRhbmE7Y29sb3I6YmxhY2siPiZsdDtSRyZndDsgUmlnaHQu IEV4YW1wbGUgc2hvd24gaW4gdGhlIEFwcGVuZGl4IGlzIG9uZSB1bi1hbWJpZ3VvdXMgd2F5IHRv IHBvcHVsYXRlIGl0IGZvciBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQcy48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHN0cm9uZz48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpWZXJkYW5hO2NvbG9yOmJsYWNrIj5N YWpvciBJc3N1ZXM6PC9zcGFuPjwvc3Ryb25nPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OlZlcmRhbmE7Y29sb3I6YmxhY2siPk5vbmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpWZXJkYW5hO2NvbG9yOmJsYWNrIj5NaW5vciBJc3N1ZXM6PC9zcGFuPjwv c3Ryb25nPjxvOnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDEgbGZvMztiYWNrZ3JvdW5kOndo aXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpWZXJkYW5hIj5Nb3ZpbmcgdGhlIHRlcm1p bm9sb2d5IHNlY3Rpb24gYmVmb3JlIHRoZSBpbnRyb2R1Y3Rpb24gd291bGQgaW1wcm92ZSByZWFk YWJpbGl0eSwgc2luY2UgdGhlIHRlcm1zIGRlZmluZWQgaW4gdGhlIHRlcm1pbm9sb2d5IHNlY3Rp b24gYXJlIGZyZXF1ZW50bHkgdXNlZCBpbiB0aGUgaW50cm9kdWN0aW9uLg0KPC9zcGFuPjxvOnA+ PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlZlcmRhbmE7Y29sb3I6YmxhY2siPiZsdDtSRyZn dDsgSSBhbSBub3QgZmFtaWxpYXIgd2l0aCBhbiBSRkMgd2hlcmUgdGVybWlub2xvZ3kgaXMgdGhl IGZpcnN0IHNlY3Rpb24uIEkgYW0gZmluZSBlaXRoZXIgd2F5LCBwbGVhc2UgbGV0IG1lIGtub3cg aWYgeW91IHByZWZlciB0aGlzIHdheS48L3NwYW4+PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0i ZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwyIGxl dmVsMSBsZm8zO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlZl cmRhbmEiPldoZW4gSSByZWFkIHRoZSB0aXRsZSBvZiBzZWN0aW9uIDMgKG92ZXJ2aWV3KSwgSSB0 aG91Z2h0IOKAnHdoeSBhbiBvdmVydmlldyBpcyBuZWVkZWQgaWYgdGhlcmUgaXMgYW4gaW50cm9k dWN0aW9uP+KAnS4gQWN0dWFsbHkgdGhlIHRleHQgaW4gdGhhdCBzZWN0aW9uIGlzIHZlcnkgdXNl ZnVsIGJ1dCBtb3JlIHRoYW4gYW4gb3ZlcnZpZXcgSSB3b3VsZCBjYWxsIGl0IGEgcHJvYmxlbSBz dGF0ZW1lbnQNCiAob3Igc29tZXRoaW5nIGxpa2UgdGhhdCkuPC9zcGFuPjxvOnA+PC9vOnA+PC9s aT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OlZlcmRhbmE7Y29sb3I6YmxhY2siPiZsdDtSRyZndDsgQ29ycmVj dGVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzM7YmFja2dyb3Vu ZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6VmVyZGFuYSI+VGhlIHVzYWdlIG9m IFJGQyAyMTE5IChvciBzaG91bGQgd2UgcmVmZXJlbmNlIFJGQyA4MTc0ID8/KSBpcyBub3QgY29u Z3J1ZW50IGFsbCBvdmVyIHRoZSBkb2N1bWVudC4gRS5nLiBzZWN0aW9uIDQuMTwvc3Bhbj48bzpw PjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0iZm9u dC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3Jw aGFuczogMjt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogMjstd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOiBpbml0aWFsO3RleHQtZGVjb3JhdGlvbi1j b2xvcjogaW5pdGlhbDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7IG8mbmJzcDsgVGhl IGRvd25zdHJlYW0gUExSIG5vZGUgPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93O21zby1o aWdobGlnaHQ6eWVsbG93Ij4NCmFsd2F5cyBpbml0aWF0ZXM8L3NwYW4+IHRoZSBieXBhc3MgdHVu bmVsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFzc2lnbm1lbnQgZm9yIHRoZSBmb3J3 YXJkIExTUC4mbmJzcDsgVGhlIHVwc3RyZWFtIFBMUiAoZm9yd2FyZDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBkaXJlY3Rpb24gTFNQIE1QKSBub2RlDQo8c3BhbiBzdHlsZT0iYmFja2dy b3VuZDp5ZWxsb3c7bXNvLWhpZ2hsaWdodDp5ZWxsb3ciPnNpbXBseSByZWZsZWN0czwvc3Bhbj4g dGhlIGFzc29jaWF0ZWQgYnlwYXNzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR1bm5l bCBhc3NpZ25tZW50IGZvciB0aGUgcmV2ZXJzZSBkaXJlY3Rpb24gTFNQLiZuYnNwOyBUaGUgdXBz dHJlYW0gUExSPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG5vZGUgTVVTVCBOT1QgaW5p dGlhdGUgdGhlIGJ5cGFzcyB0dW5uZWwgYXNzaWdubWVudC48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBj bSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbHQ7UkcmZ3Q7IENvcnJlY3RlZC48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHN0cm9uZz48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpWZXJkYW5hO2NvbG9yOmJsYWNr Ij5OaXRzOjwvc3Bhbj48L3N0cm9uZz48bzpwPjwvbzpwPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4N CjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDMgbGV2ZWwxIGxm bzQ7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6VmVyZGFuYSI+ U2VjdGlvbjE6IOKAnChHKU11bHRpcHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nIChNUExTKSBUcmFm ZmljIEVuZ2luZWVyaW5nIChURSkgTGFiZWwgU3dpdGNoZWQgUGF0aHMgKExTUHMp4oCdLiBUaGlz IGZvcm1hdHRpbmcgZG9lc27igJl0IG1ha2UgbXVjaCBzZW5zZS4gSW4gdGhlIGZpcnN0IGluc3Rh bmNlIHRoZSBicmFja2V0cyBhcmUgdXNlZCB0byBzYXkgTVBMUyBvciBHTVBMUyB3aGlsZSBpbiB0 aGUNCiBvdGhlciBvbmVzIHRvIGRlZmluZSB0aGUgYWNyb255bXMuPC9zcGFuPjxvOnA+PC9vOnA+ PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OlZlcmRhbmE7Y29sb3I6YmxhY2siPiZsdDtSRyZndDsgQ29y cmVjdGVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzQ7YmFja2dyb3VuZDp3aGl0ZSI+ DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6VmVyZGFuYTtjb2xvcjpibGFjayI+U2VjdGlvbiAz LjEgdGhlcmUgaXMgbm8gbmVlZCB0byByZXBlYXQgdHdpY2UgdGhhdCBCeXBhc3MgdHVubmVsIE4g dXNlcyBwYXRoIEItSC1JLUMgYW5kIEJ5cGFzcyB0dW5uZWwgUyBwYXRoIEItRi1HLUMuIFRoZSBz ZWNvbmQgdGltZSB0aGUgYnJhY2tldCBjYW4gYmUgZHJvcHBlZC4NCjwvc3Bhbj48bzpwPjwvbzpw PjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpWZXJkYW5hO2NvbG9yOmJsYWNrIj4mbHQ7UkcmZ3Q7IENv cnJlY3RlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21zby1saXN0OmwzIGxldmVsMSBsZm80O2JhY2tncm91bmQ6d2hpdGUi Pg0KU2VjdGlvbiA0LjEuMS4gLSAmbmJzcDtzL1NIT1VMRCB0cmlnZ2VyIHRoZSBwcm9jZWR1cmUv IFNIT1VMRCB0cmlnZ2VyIHByb2NlZHVyZTxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KJmx0O1JHJmd0OyBDb3JyZWN0ZWQuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQpU aGFua3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3 aGl0ZSI+DQpSYWtlc2ggKGZvciBhdXRob3JzKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MTguMHB0O2JhY2tncm91bmQ6d2hpdGUiPg0K Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 MTguMHB0O2JhY2tncm91bmQ6d2hpdGUiPg0KQlI8YnI+DQpEYW5pZWxlJm5ic3A7IDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E51A0C3E660448CAB39B45EB25001012ciscocom_-- From nobody Thu Aug 30 02:35:46 2018 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9292130EF8; Thu, 30 Aug 2018 02:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMGVB8t4Qg_n; Thu, 30 Aug 2018 02:35:35 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C944C130EF7; Thu, 30 Aug 2018 02:35:34 -0700 (PDT) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id DF66AE0BFF36B; Thu, 30 Aug 2018 10:35:29 +0100 (IST) Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.399.0; Thu, 30 Aug 2018 10:35:30 +0100 Received: from DGGEML511-MBX.china.huawei.com ([169.254.1.110]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0399.000; Thu, 30 Aug 2018 17:35:23 +0800 From: "Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept)" To: "ccamp@ietf.org" CC: TEAS WG Thread-Topic: New Version Notification for draft-zheng-ccamp-client-signal-yang-02.txt Thread-Index: AdRARHVbIYodabaiQWa2CJbrsbI6Xg== Date: Thu, 30 Aug 2018 09:35:23 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.57.78.212] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Teas] Fw: New Version Notification for draft-zheng-ccamp-client-signal-yang-02.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2018 09:35:37 -0000 RGVhciBXRywgDQoNCldlIHVwZGF0ZWQgdGhpcyB3b3JrIHRvIGZpeCB0aGUgaXNzdWVzIGluIFlB TkcgdmFsaWRhdG9yLiBZb3UgYXJlIGZyZWUgdG8gcmV2aWV3IGFuZCBwcm92aWRlIGNvbW1lbnRz LCB0aGFuayB5b3UuIA0KDQpUaGUgb3RoZXIgdHdvIGNsaWVudCByZWxhdGVkIGRyYWZ0cywgdG9w b2xvZ3kgYW5kIHR1bm5lbCwgd2VyZSBhbHNvIHVwZGF0ZWQgaW4gb25seSB2ZXJzaW9uIGFuZCBk YXRlcy4gVGhlIG1vZGVsIHdpbGwgYmUgdXBkYXRlZCBvbmNlIHRoZSBiYXNpYyBtb2RlbCAodGUt dG9wbyBhbmQgdGUtdHVubmVsKSBpcyBzdGFibGUsIHByb2JhYmx5IGJlZm9yZSBuZXh0IElFVEYu IA0KDQpCZXN0IHdpc2hlcywNCkhhb21pYW4NCg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R 5Lu25Lq6OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmddIA0K5Y+R6YCB5pe26Ze0OiAyMDE45bm0OOaciDMw5pelIDE3OjMzDQrmlLbku7bk uro6IEdpdXNlcHBlIEZpb2Njb2xhIDxnaXVzZXBwZS5maW9jY29sYUB0ZWxlY29taXRhbGlhLml0 PjsgWHVmZW5nIExpdSA8eHVmZW5nLmxpdS5pZXRmQGdtYWlsLmNvbT47IFpoZW5naGFvbWlhbiAo WmhlbmdoYW9taWFuLCBPcHRpY2FsICZNaWNyb3dhdmUgVGVjaG5vbG9neSBSZXNlYXJjaCBEZXB0 KSA8emhlbmdoYW9taWFuQGh1YXdlaS5jb20+OyBZdW5iaW4gWHUgPHh1eXVuYmluQHJpdHQuY24+ OyBBaWh1YWd1byAoQWlodWEgR3VvLCBDUkMpIDxhaWh1YWd1b0BodWF3ZWkuY29tPjsgWmhlbmdo YW9taWFuIChaaGVuZ2hhb21pYW4sIE9wdGljYWwgJk1pY3Jvd2F2ZSBUZWNobm9sb2d5IFJlc2Vh cmNoIERlcHQpIDx6aGVuZ2hhb21pYW5AaHVhd2VpLmNvbT47IEl0YWxvIEJ1c2kgPEl0YWxvLkJ1 c2lAaHVhd2VpLmNvbT47IFlhbmcgWmhhbyA8emhhb3lhbmd5anlAY2hpbmFtb2JpbGUuY29tPg0K 5Li76aKYOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXpoZW5nLWNjYW1wLWNs aWVudC1zaWduYWwteWFuZy0wMi50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQt emhlbmctY2NhbXAtY2xpZW50LXNpZ25hbC15YW5nLTAyLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1 bGx5IHN1Ym1pdHRlZCBieSBIYW9taWFuIFpoZW5nIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVw b3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LXpoZW5nLWNjYW1wLWNsaWVudC1zaWduYWwteWFuZw0K UmV2aXNpb246CTAyDQpUaXRsZToJCUEgWUFORyBEYXRhIE1vZGVsIGZvciBUcmFuc3BvcnQgTmV0 d29yayBDbGllbnQgU2lnbmFscw0KRG9jdW1lbnQgZGF0ZToJMjAxOC0wOC0zMA0KR3JvdXA6CQlJ bmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMzQNClVSTDogICAgICAgICAgICBodHRwczov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtemhlbmctY2NhbXAtY2xpZW50LXNp Z25hbC15YW5nLTAyLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LXpoZW5nLWNjYW1wLWNsaWVudC1zaWduYWwteWFuZy8NCkh0bWxpemVk OiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhlbmctY2NhbXAtY2xp ZW50LXNpZ25hbC15YW5nLTAyDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC16aGVuZy1jY2FtcC1jbGllbnQtc2lnbmFsLXlhbmcNCkRp ZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtemhl bmctY2NhbXAtY2xpZW50LXNpZ25hbC15YW5nLTAyDQoNCkFic3RyYWN0Og0KICAgQSB0cmFuc3Bv cnQgbmV0d29yayBpcyBhIHNlcnZlci1sYXllciBuZXR3b3JrIHRvIHByb3ZpZGUgY29ubmVjdGl2 aXR5DQogICBzZXJ2aWNlcyB0byBpdHMgY2xpZW50LiAgVGhlIHRvcG9sb2d5IGFuZCB0dW5uZWwg aW5mb3JtYXRpb24gaW4gdGhlDQogICB0cmFuc3BvcnQgbGF5ZXIgaGFzIGFscmVhZHkgYmVlbiBk ZWZpbmVkIGJ5IFRyYWZmaWMtZW5naW5lZXJlZCBtb2RlbHMNCiAgIGFuZCBPVE4gbW9kZWxzLCBo b3dldmVyLCB0aGUgYWNjZXNzIHRvIHRoZSBuZXR3b3JrIGhhcyBub3QgYmVlbg0KICAgZGVzY3Jp YmVkLiAgVGhlc2UgaW5mb3JtYXRpb24gaXMgdXNlZnVsIHRvIGJvdGggY2xpZW50IGFuZCBwcm92 aWRlci4NCg0KICAgVGhpcyBkcmFmdCBkZXNjcmliZSBob3cgdGhlIGNsaWVudCBzaWduYWxzIGFy ZSBjYXJyaWVkIG92ZXIgdHJhbnNwb3J0DQogICBuZXR3b3JrIGFuZCBkZWZpbmVkIGNvcnJlc3Bv bmRpbmcgWUFORyBkYXRhIG1vZGVsIHdoaWNoIGlzIHJlcXVpcmVkDQogICBkdXJpbmcgY29uZmln dXJhdGlvbiBwcm9jZWR1cmUuICBNb3JlIHNwZWNpZmljYWxseSwgc2V2ZXJhbCBjbGllbnQNCiAg IHNpZ25hbCAob2YgdHJhbnNwb3J0IG5ldHdvcmspIG1vZGVscyBpbmNsdWRpbmcgRVRILCBTVE0t biwgRkMgYW5kIHNvDQogICBvbiwgYXJlIGRlZmluZWQgaW4gdGhpcyBkcmFmdC4NCg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0 bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4N Cg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K