From nobody Mon May 2 20:13:30 2016 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 23C0112D0B0 for ; Mon, 2 May 2016 20:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TubpqbdJcLz8 for ; Mon, 2 May 2016 20:13:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32BCE12B015 for ; Mon, 2 May 2016 20:13:26 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJA07996; Tue, 03 May 2016 03:13:24 +0000 (GMT) Received: from SZXEMA417-HUB.china.huawei.com (10.82.72.34) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 3 May 2016 04:13:23 +0100 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.211]) by SZXEMA417-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0235.001; Tue, 3 May 2016 11:13:19 +0800 From: "Zhangxian (Xian)" To: Vishnu Pavan Beeram , "teas@ietf.org" Thread-Topic: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-srlg-collect-05 Thread-Index: AQHRoY5hFf7aW4q4tU+wo+eHX2JTR5+mesmQ Date: Tue, 3 May 2016 03:13:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.104.209] Content-Type: multipart/alternative; boundary="_000_C636AF2FA540124E9B9ACB5A6BECCE6B7DEA6AACSZXEMA512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.57281754.00EE, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.211, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 14bd6ad2e43c9b2e145dbaf265c16119 Archived-At: Subject: Re: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-srlg-collect-05 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 03:13:29 -0000 --_000_C636AF2FA540124E9B9ACB5A6BECCE6B7DEA6AACSZXEMA512MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIGFsbCwNCg0KSSd2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFuZCBiZWxpZXZlIGl0IGlz IHJlYWR5IGZvciBwdWJsaWNhdGlvbi4NCg0KSSBoYXZlIG9uZSBzdWdnZXN0aW9uIG9uIHRoZSBl bmNvZGluZyBzZWN0aW9uOiBjb3VsZCB3ZSBhZGQgdGhlIGJpdCBudW1iZXIgZm9yIGVhY2ggZmll bGQgZXhwbGFuYXRpb24/IEl0IG1heSBiZSBhIGJpdCByZWR1bmRhbnQsIGJ1dCBJIGZpbmQgaXQg dXN1YWxseSBjbGVhcmVyIGlmIHdlIGhhdmUgc3VjaCBpbmZvcm1hdGlvbiBpbiB0aGUgdGV4dC4N Cg0KT3RoZXJzIGFyZSBqdXN0IHNvbWUgbml0czoNCjHvvJogcy9Ob3RlIHRoYXQgc3BlY2lmaWNh dGlvbiBvZiB0aGUgdGhlIHVzZSBvZiB0aGUgY29sbGVjdGVkIFNSTEdzIGlzIG91dHNpZGUgdGhl IHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuL05vdGUgdGhhdCBzcGVjaWZpY2F0aW9uIG9mIHRoZSB1 c2Ugb2YgdGhlIGNvbGxlY3RlZCBTUkxHcyBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRv Y3VtZW50Lg0KMu+8mnMvU1JMRyBpbmZvcm1hdGlvbiBpcyBmb3IgZWFjaCBob3AgaXMgYWRkZWQg dG8gdGhlIFBhdGggUlJPIGR1cmluZyBQYXRoIG1lc3NhZ2UgcHJvY2Vzc2luZy4vU1JMRyBpbmZv cm1hdGlvbiBpcyBhZGRlZCBieSBlYWNoIGhvcCB0byB0aGUgUGF0aCBSUk8gZHVyaW5nIFBhdGgg bWVzc2FnZSBwcm9jZXNzaW5nLig/KQ0KMzogY29uc2lkZXIgcmVsb2NhdGluZyB0aGUgZm9sbG93 aW5nIHNlbnRlbmNlIHRvIHRoZSB2ZXJ5IGJlZ2lubmluZyBvZiB0aGlzIHNlY3Rpb24oNS4xKSwg bWF5YmU/DQpBIG5vZGUgU0hPVUxEIE5PVCBhZGQgU1JMRyBpbmZvcm1hdGlvbiB3aXRob3V0IGFu IGV4cGxpY2l0IHJlcXVlc3QgZm9yIGl0IGJlaW5nIG1hZGUgYnkgdGhlIGluZ3Jlc3Mgbm9kZSBp biB0aGUgUGF0aCBtZXNzYWdlLg0KNDogVGhlIHBvaW50cyBsaXN0ZWQgaW4gU2VjdGlvbiA2LjEg c3RhcnRlZCB3aXRoIOKAnG/igJ0gYXJlIHNxdWVlemVkIHRvZ2V0aGVyIGluIG9uZSBwYXJhZ3Jh cGg7IHBsZWFzZSByZWN0aWZ5Lg0KDQpSZWdhcmRzLA0KWGlhbg0KDQpGcm9tOiBUZWFzIFttYWls dG86dGVhcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVmlzaG51IFBhdmFuIEJlZXJh bQ0KU2VudDogMjAxNuW5tDTmnIgyOeaXpSA0OjQyDQpUbzogdGVhc0BpZXRmLm9yZw0KU3ViamVj dDogW1RlYXNdIFdHIExhc3QgQ2FsbCBvbiBkcmFmdC1pZXRmLXRlYXMtcnN2cC10ZS1zcmxnLWNv bGxlY3QtMDUNCg0KQWxsLA0KVGhpcyBzdGFydHMgYSB0d28gd2VlayB3b3JraW5nIGdyb3VwIGxh c3QgY2FsbCBvbg0KZHJhZnQtaWV0Zi10ZWFzLXJzdnAtdGUtc3JsZy1jb2xsZWN0LTA1Lg0KDQpU aGUgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBvbiBUaHVyc2RheSwgTWF5IDEydGguIFBs ZWFzZQ0Kc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBURUFTIG1haWxpbmcgbGlzdC4NCg0KQXMg aXMgYWx3YXlzIHRoZSBjYXNlLCBwb3NpdGl2ZSBjb21tZW50cywgZS5nLiwgIkkndmUgcmV2aWV3 ZWQgdGhpcw0KZG9jdW1lbnQgYW5kIGJlbGlldmUgaXQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9u IiwgYXJlIHdlbGNvbWUhDQpUaGlzIGlzIHVzZWZ1bCBhbmQgaW1wb3J0YW50LCBldmVuIGZyb20g YXV0aG9ycy4NCk5vdGUsIElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgb24gdGhpcyBkcmFmdC4NCg0K VGhhbmtzLA0KUGF2YW4gKGFuZCBMb3UpDQo= --_000_C636AF2FA540124E9B9ACB5A6BECCE6B7DEA6AACSZXEMA512MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpwLk1zb0xpc3RQYXJh Z3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1z dHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cgl0ZXh0LWluZGVudDoyMS4wcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrl rovkvZM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkw LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3Qg RGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjMwODA5Njg0MTsNCgltc28t bGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTcxNDU3NDI0MCAtMTQw NjEyMTExNCA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5 ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRl eHQ6IiUxXCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxOC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxNTgyODMzMDUyOw0KCW1zby1saXN0LXR5cGU6 aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMjEzNjAxNTE1MiA4ODM2MTIwNjQgNjc2 OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3 MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC10ZXh0OiIlMVwpIjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJbWFyZ2luLWxlZnQ6MTguMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0Kb2wNCgl7 bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5IaSwgYWxsLCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkndmUgcmV2aWV3ZWQgdGhpcyBkb2N1 bWVudCBhbmQgYmVsaWV2ZSBpdCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5JIGhhdmUgb25lIHN1Z2dlc3Rpb24gb24gdGhlIGVuY29kaW5nIHNlY3Rpb246IGNv dWxkIHdlIGFkZCB0aGUgYml0IG51bWJlciBmb3IgZWFjaCBmaWVsZCBleHBsYW5hdGlvbj8gSXQg bWF5IGJlIGEgYml0IHJlZHVuZGFudCwgYnV0IEkgZmluZCBpdCB1c3VhbGx5IGNsZWFyZXIgaWYg d2UgaGF2ZSBzdWNoIGluZm9ybWF0aW9uIGluIHRoZSB0ZXh0Lg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5PdGhlcnMgYXJlIGp1c3Qgc29tZSBuaXRzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4xPC9zcGFuPu+8miA8c3BhbiBsYW5n PSJFTi1VUyI+cy9Ob3RlIHRoYXQgc3BlY2lmaWNhdGlvbiBvZiB0aGUgdGhlIHVzZSBvZiB0aGUg Y29sbGVjdGVkIFNSTEdzIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuL05v dGUgdGhhdCBzcGVjaWZpY2F0aW9uIG9mIHRoZSB1c2Ugb2YgdGhlIGNvbGxlY3RlZCBTUkxHcyBp cyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzDQogZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjI8L3NwYW4+77ya PHNwYW4gbGFuZz0iRU4tVVMiPnMvU1JMRyBpbmZvcm1hdGlvbiBpcyBmb3IgZWFjaCBob3AgaXMg YWRkZWQgdG8gdGhlIFBhdGggUlJPIGR1cmluZyBQYXRoIG1lc3NhZ2UgcHJvY2Vzc2luZy4vU1JM RyBpbmZvcm1hdGlvbiBpcyBhZGRlZCBieSBlYWNoIGhvcCB0byB0aGUgUGF0aCBSUk8gZHVyaW5n IFBhdGggbWVzc2FnZSBwcm9jZXNzaW5nLig/KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4zOiBjb25zaWRlciByZWxvY2F0aW5n IHRoZSBmb2xsb3dpbmcgc2VudGVuY2UgdG8gdGhlIHZlcnkgYmVnaW5uaW5nIG9mIHRoaXMgc2Vj dGlvbig1LjEpLCBtYXliZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6MTguMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+QSBub2Rl IFNIT1VMRCBOT1QgYWRkIFNSTEcgaW5mb3JtYXRpb24gd2l0aG91dCBhbiBleHBsaWNpdCByZXF1 ZXN0IGZvciBpdCBiZWluZyBtYWRlIGJ5IHRoZSBpbmdyZXNzIG5vZGUgaW4gdGhlIFBhdGggbWVz c2FnZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+NDogVGhlIHBvaW50cyBsaXN0ZWQgaW4gU2VjdGlvbiA2LjEgc3RhcnRlZCB3 aXRoIOKAnG/igJ0gYXJlIHNxdWVlemVkIHRvZ2V0aGVyIGluIG9uZSBwYXJhZ3JhcGg7IHBsZWFz ZSByZWN0aWZ5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+WGlhbjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVGVhcyBbbWFp bHRvOnRlYXMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+VmlzaG51IFBh dmFuIEJlZXJhbTxicj4NCjxiPlNlbnQ6PC9iPiAyMDE2PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij7lubQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij40PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7mnIg8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4yOTwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5pelPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+DQogNDo0Mjxicj4NCjxiPlRvOjwvYj4gdGVhc0BpZXRmLm9yZzxi cj4NCjxiPlN1YmplY3Q6PC9iPiBbVGVhc10gV0cgTGFzdCBDYWxsIG9uIGRyYWZ0LWlldGYtdGVh cy1yc3ZwLXRlLXNybGctY29sbGVjdC0wNTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+QWxsLDxicj4NClRoaXMgc3Rh cnRzIGEgdHdvIHdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb248YnI+DQpkcmFmdC1pZXRm LXRlYXMtcnN2cC10ZS1zcmxnLWNvbGxlY3QtMDUuPGJyPg0KPGJyPg0KVGhlIHdvcmtpbmcgZ3Jv dXAgbGFzdCBjYWxsIGVuZHMgb24gVGh1cnNkYXksIE1heSAxMnRoLiBQbGVhc2U8YnI+DQpzZW5k IHlvdXIgY29tbWVudHMgdG8gdGhlIFRFQVMgbWFpbGluZyBsaXN0Ljxicj4NCjxicj4NCkFzIGlz IGFsd2F5cyB0aGUgY2FzZSwgcG9zaXRpdmUgY29tbWVudHMsIGUuZy4sICZxdW90O0kndmUgcmV2 aWV3ZWQgdGhpczxicj4NCmRvY3VtZW50IGFuZCBiZWxpZXZlIGl0IGlzIHJlYWR5IGZvciBwdWJs aWNhdGlvbiZxdW90OywgYXJlIHdlbGNvbWUhPGJyPg0KVGhpcyBpcyB1c2VmdWwgYW5kIGltcG9y dGFudCwgZXZlbiBmcm9tIGF1dGhvcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Tm90ZSwgSVBSIGhhcyBiZWVu IGRpc2Nsb3NlZCBvbiB0aGlzIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KVGhhbmtzLDxicj4N ClBhdmFuIChhbmQgTG91KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_C636AF2FA540124E9B9ACB5A6BECCE6B7DEA6AACSZXEMA512MBSchi_-- From nobody Mon May 2 23:52:31 2016 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 6D09A12D0F8; Mon, 2 May 2016 23:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ze2FnMnJ3sXS; Mon, 2 May 2016 23:52:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8730D12B011; Mon, 2 May 2016 23:52:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJA39427; Tue, 03 May 2016 06:52:21 +0000 (GMT) Received: from SZXEMA417-HUB.china.huawei.com (10.82.72.34) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 3 May 2016 07:52:20 +0100 Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.101]) by SZXEMA417-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0235.001; Tue, 3 May 2016 14:52:09 +0800 From: Longhao To: Daniele Ceccarelli , "Yemin (Amy)" , Gregory Mirsky , "D'Alessandro Alessandro Gerardo (alessandro.dalessandro@telecomitalia.it)" , "hshah@ciena.com" Thread-Topic: [CCAMP] Regarding IPR on draft-ietf-ccamp-ospf-availability-extension-04 Thread-Index: AdGgeDxNesVQlem3QeSqagGktKCXxwEj9aDw Date: Tue, 3 May 2016 06:52:08 +0000 Message-ID: <27AADBCF3D83CF468918A05EC75F2084383A4296@SZXEMA504-MBS.china.huawei.com> References: <4A1562797D64E44993C5CBF38CF1BE48162BD0A5@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48162BD0A5@ESESSMB301.ericsson.se> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.169.50.117] Content-Type: multipart/alternative; boundary="_000_27AADBCF3D83CF468918A05EC75F2084383A4296SZXEMA504MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.57284AA5.00EC, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.101, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c732daff02f669d07e9bfeefa0ce3c05 Archived-At: Cc: "CCAMP \(ccamp@ietf.org\)" , "teas-chairs@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [Teas] [CCAMP] Regarding IPR on draft-ietf-ccamp-ospf-availability-extension-04 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 06:52:27 -0000 --_000_27AADBCF3D83CF468918A05EC75F2084383A4296SZXEMA504MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No, I'm not aware of any IPR that applies to this draft. Hao From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Daniele Ceccarelli Sent: Wednesday, April 27, 2016 7:35 PM To: Longhao; Yemin (Amy); Gregory Mirsky; D'Alessandro Alessandro Gerardo (= alessandro.dalessandro@telecomitalia.it); hshah@ciena.com Cc: CCAMP (ccamp@ietf.org); teas-chairs@ietf.org; TEAS WG (teas@ietf.org) Subject: [CCAMP] Regarding IPR on draft-ietf-ccamp-ospf-availability-extens= ion-04 Authors, Contributors, CCAMP, TEAS, It's time to move on with the bandwidth availability drafts. As agreed with= the TEAS WG chairs the last call of draft-ietf-ccamp-ospf-availability-ext= ension-04 will be run jointly by the CCAMP and the TEAS WGs. In preparation= for WG LC here is the IPR polling. Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropria= te. If you are listed as a document author or contributor please answer the= above by responding to this email regardless of whether or not you are awa= re of any relevant IPR. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or co= ntributor, we remind you of your obligations under the IETF IPR rules which= encourages you to notify the IETF if you are aware of IPR of others on an = IETF contribution, or to refrain from participating in any contribution or = discussion related to your undisclosed IPR. For more information, please se= e the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki= /IntellectualProperty. Thank you, Daniele & Fatai --_000_27AADBCF3D83CF468918A05EC75F2084383A4296SZXEMA504MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

No, I'm not aware of any IPR that applies to this draft.

 

Hao

 

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Daniele Ceccarelli
Sent: Wednesday, April 27, 2016 7:35 PM
To: Longhao; Yemin (Amy); Gregory Mirsky; D'Alessandro Alessandro Ge= rardo (alessandro.dalessandro@telecomitalia.it); hshah@ciena.com
Cc: CCAMP (ccamp@ietf.org); teas-chairs@ietf.org; TEAS WG (teas@ietf= .org)
Subject: [CCAMP] Regarding IPR on draft-ietf-ccamp-ospf-availability= -extension-04

 

Authors, Contributors, CCAMP, T= EAS,

 

It’s time to move on with= the bandwidth availability drafts. As agreed with the TEAS WG chairs the l= ast call of draft-ietf-ccamp-ospf-availability-extension-04 will be run joi= ntly by the CCAMP and the TEAS WGs. In preparation for WG LC here is the IPR polling.

 

Are you aware of any IPR that a= pplies to draft identified above?

 

Please state either:=

"No, I'm not aware of any = IPR that applies to this draft"

or

"Yes, I'm aware of IPR tha= t applies to this draft"

 

If so, has this IPR been disclo= sed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 f= or more details)?

If yes to the above, please sta= te either:

 

"Yes, the IPR has been dis= closed in compliance with IETF IPR rules"

or

"No, the IPR has not been = disclosed"

 

If you answer no, please provid= e any additional details you think appropriate. If you are listed as a docu= ment author or contributor please answer the above by responding to this em= ail regardless of whether or not you are aware of any relevant IPR.

 

NOTE: THIS APPLIES TO ALL OF YO= U LISTED IN THIS MESSAGE'S TO LINES.

 

If you are on the CCAMP WG emai= l list but are not listed as an author or contributor, we remind you of you= r obligations under the IETF IPR rules which encourages you to notify the I= ETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribut= ion or discussion related to your undisclosed IPR. For more information, pl= ease see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty<= /a>.

 

Thank you,

Daniele & Fatai<= /span>

 

--_000_27AADBCF3D83CF468918A05EC75F2084383A4296SZXEMA504MBSchi_-- From nobody Mon May 2 23:57:01 2016 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 AF55112D0EF; Mon, 2 May 2016 23:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dm_XUoW3kXy; Mon, 2 May 2016 23:56:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54C4412B02A; Mon, 2 May 2016 23:56:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CNU57128; Tue, 03 May 2016 06:56:55 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 3 May 2016 07:56:53 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.160]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0235.001; Tue, 3 May 2016 14:56:39 +0800 From: "Yemin (Amy)" To: Daniele Ceccarelli , Longhao , Gregory Mirsky , "D'Alessandro Alessandro Gerardo (alessandro.dalessandro@telecomitalia.it)" , "hshah@ciena.com" Thread-Topic: [Teas] Regarding IPR on draft-ietf-ccamp-ospf-availability-extension-04 Thread-Index: AdGgeDxNesVQlem3QeSqagGktKCXxwEkDCfQ Date: Tue, 3 May 2016 06:56:39 +0000 Message-ID: <9C5FD3EFA72E1740A3D41BADDE0B461F9CD871D1@szxema506-mbs.china.huawei.com> References: <4A1562797D64E44993C5CBF38CF1BE48162BD0A5@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48162BD0A5@ESESSMB301.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.169.31.176] Content-Type: multipart/alternative; boundary="_000_9C5FD3EFA72E1740A3D41BADDE0B461F9CD871D1szxema506mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.57284BB7.00DD, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.160, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a83c1184cc95d7c91612302eda367403 Archived-At: Cc: "CCAMP \(ccamp@ietf.org\)" , "teas-chairs@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [Teas] Regarding IPR on draft-ietf-ccamp-ospf-availability-extension-04 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 06:57:00 -0000 --_000_9C5FD3EFA72E1740A3D41BADDE0B461F9CD871D1szxema506mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No, I'm not aware of any IPR that applies to this draft. BR, Amy ________________________________ This e-mail and its attachments contain confidential information from HUAWE= I, which is intended only for the person or entity whose address is listed above. An= y use of the information contained herein in any way (including, but not limited to, tot= al or partial disclosure, reproduction, or dissemination) by persons other than the inten= ded recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by phone or email immediately and delete it! From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Daniele Ceccarelli Sent: Wednesday, April 27, 2016 7:35 PM To: Longhao; Yemin (Amy); Gregory Mirsky; D'Alessandro Alessandro Gerardo (= alessandro.dalessandro@telecomitalia.it); hshah@ciena.com Cc: CCAMP (ccamp@ietf.org); teas-chairs@ietf.org; TEAS WG (teas@ietf.org) Subject: [Teas] Regarding IPR on draft-ietf-ccamp-ospf-availability-extensi= on-04 Authors, Contributors, CCAMP, TEAS, It's time to move on with the bandwidth availability drafts. As agreed with= the TEAS WG chairs the last call of draft-ietf-ccamp-ospf-availability-ext= ension-04 will be run jointly by the CCAMP and the TEAS WGs. In preparation= for WG LC here is the IPR polling. Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropria= te. If you are listed as a document author or contributor please answer the= above by responding to this email regardless of whether or not you are awa= re of any relevant IPR. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or co= ntributor, we remind you of your obligations under the IETF IPR rules which= encourages you to notify the IETF if you are aware of IPR of others on an = IETF contribution, or to refrain from participating in any contribution or = discussion related to your undisclosed IPR. For more information, please se= e the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki= /IntellectualProperty. Thank you, Daniele & Fatai --_000_9C5FD3EFA72E1740A3D41BADDE0B461F9CD871D1szxema506mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

No, I'm not aware of any IPR th= at applies to this draft.

 

BR,

Amy

This e-mail and its attachments = contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. An= y use of the
information contained herein in any way (including, but not limited to, tot= al or partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by
phone or email immediately and delete it!

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Daniele Ceccarelli
Sent: Wednesday, April 27, 2016 7:35 PM
To: Longhao; Yemin (Amy); Gregory Mirsky; D'Alessandro Alessandro Ge= rardo (alessandro.dalessandro@telecomitalia.it); hshah@ciena.com
Cc: CCAMP (ccamp@ietf.org); teas-chairs@ietf.org; TEAS WG (teas@ietf= .org)
Subject: [Teas] Regarding IPR on draft-ietf-ccamp-ospf-availability-= extension-04

 

Authors, Contributors, CCAMP, T= EAS,

 

It’s time to move on with= the bandwidth availability drafts. As agreed with the TEAS WG chairs the l= ast call of draft-ietf-ccamp-ospf-availability-extension-04 will be run joi= ntly by the CCAMP and the TEAS WGs. In preparation for WG LC here is the IPR polling.

 

Are you aware of any IPR that a= pplies to draft identified above?

 

Please state either:=

"No, I'm not aware of any = IPR that applies to this draft"

or

"Yes, I'm aware of IPR tha= t applies to this draft"

 

If so, has this IPR been disclo= sed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 f= or more details)?

If yes to the above, please sta= te either:

 

"Yes, the IPR has been dis= closed in compliance with IETF IPR rules"

or

"No, the IPR has not been = disclosed"

 

If you answer no, please provid= e any additional details you think appropriate. If you are listed as a docu= ment author or contributor please answer the above by responding to this em= ail regardless of whether or not you are aware of any relevant IPR.

 

NOTE: THIS APPLIES TO ALL OF YO= U LISTED IN THIS MESSAGE'S TO LINES.

 

If you are on the CCAMP WG emai= l list but are not listed as an author or contributor, we remind you of you= r obligations under the IETF IPR rules which encourages you to notify the I= ETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribut= ion or discussion related to your undisclosed IPR. For more information, pl= ease see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty<= /a>.

 

Thank you,

Daniele & Fatai<= /span>

 

--_000_9C5FD3EFA72E1740A3D41BADDE0B461F9CD871D1szxema506mbschi_-- From nobody Mon May 2 23:57:23 2016 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 130D912D517; Mon, 2 May 2016 23:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 dZ_QSnd5kmhm; Mon, 2 May 2016 23:57:11 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 250F412D106; Mon, 2 May 2016 23:57:07 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-77-572844420d29 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id CA.BC.09012.24448275; Tue, 3 May 2016 08:25:06 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0248.002; Tue, 3 May 2016 02:57:05 -0400 From: Gregory Mirsky To: Longhao , Daniele Ceccarelli , "Yemin (Amy)" , "D'Alessandro Alessandro Gerardo (alessandro.dalessandro@telecomitalia.it)" , "hshah@ciena.com" Thread-Topic: [CCAMP] Regarding IPR on draft-ietf-ccamp-ospf-availability-extension-04 Thread-Index: AQHRpQhaY0CmSRRAj0+xgXJSUsEZzp+mx6YQ Date: Tue, 3 May 2016 06:57:05 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A653AC@eusaamb103.ericsson.se> References: <4A1562797D64E44993C5CBF38CF1BE48162BD0A5@ESESSMB301.ericsson.se> <27AADBCF3D83CF468918A05EC75F2084383A4296@SZXEMA504-MBS.china.huawei.com> In-Reply-To: <27AADBCF3D83CF468918A05EC75F2084383A4296@SZXEMA504-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221A653ACeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJIsWRmVeSWpSXmKPExsUyuXRPlK6Ti0a4waSNchYnlh1msdjcsYHN 4smcGywWuzauZrQ4efc6u0XT3F1MFq0/drA4sHucvfmPxaPlyFtWjyVLfjJ5tJzrZQ9gieKy SUnNySxLLdK3S+DK+N31j72gKb1iyebXTA2M3dFdjJwcEgImEtvnbGKHsMUkLtxbz9bFyMUh JHCUUWLL3U9QzjJGiakvv4FVsQkYSbzY2MMOkhARWMAkcbtjGROIwyzQyShxseM2E0iVsEC4 xKZrmxhBbBGBCIkbaw6xQdhGErNmTWAGsVkEVCQ+Lp3ICmLzCvhKzD7xDCwuJDCTUeJrnyGI zSkQJtH7pxtsMyPQfd9PrQGbzywgLnHryXwmiLsFJJbsOc8MYYtKvHz8jxXCVpKY8/oaM0R9 vsTbCWeYIXYJSpyc+YRlAqPoLCSjZiEpm4WkDCKuI7Fg9yc2CFtbYtnC18ww9pkDj5mQxRcw sq9i5CgtLsjJTTcy2MQIjNBjEmy6OxjvT/c8xCjAwajEw6vAphEuxJpYVlyZe4hRgoNZSYR3 gy1QiDclsbIqtSg/vqg0J7X4EKM0B4uSOK/YI8VwIYH0xJLU7NTUgtQimCwTB6dUA2Pd4p8b f07cfqX53JmM3OQ5ApEswYxrv/34H5ozOSx37/6n3PVb2N7YT3HStDtn/HHZ09AHd7w+Jc+4 WiwlPWF3G9P7t+k2noaf3MWZ46uf/XCvzuA5Lr/zq2Qfu3pycv7uIOuKveGhLJk7w08JM09e lfZ9bu/EW8tYP8a3t9xmKdO8wWj431mJpTgj0VCLuag4EQABJIfWzAIAAA== Archived-At: Cc: "CCAMP \(ccamp@ietf.org\)" , "teas-chairs@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [Teas] [CCAMP] Regarding IPR on draft-ietf-ccamp-ospf-availability-extension-04 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 06:57:17 -0000 --_000_7347100B5761DC41A166AC17F22DF11221A653ACeusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm not aware of any IPR that applies to this drat. Regards, Greg From: Longhao [mailto:longhao@huawei.com] Sent: Monday, May 02, 2016 11:52 PM To: Daniele Ceccarelli; Yemin (Amy); Gregory Mirsky; D'Alessandro Alessandr= o Gerardo (alessandro.dalessandro@telecomitalia.it); hshah@ciena.com Cc: CCAMP (ccamp@ietf.org); teas-chairs@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [CCAMP] Regarding IPR on draft-ietf-ccamp-ospf-availability-ex= tension-04 No, I'm not aware of any IPR that applies to this draft. Hao From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Daniele Ceccarelli Sent: Wednesday, April 27, 2016 7:35 PM To: Longhao; Yemin (Amy); Gregory Mirsky; D'Alessandro Alessandro Gerardo (= alessandro.dalessandro@telecomitalia.it); hshah@ciena.com Cc: CCAMP (ccamp@ietf.org); teas-chairs@ietf.org; TEAS WG (teas@ietf.org) Subject: [CCAMP] Regarding IPR on draft-ietf-ccamp-ospf-availability-extens= ion-04 Authors, Contributors, CCAMP, TEAS, It's time to move on with the bandwidth availability drafts. As agreed with= the TEAS WG chairs the last call of draft-ietf-ccamp-ospf-availability-ext= ension-04 will be run jointly by the CCAMP and the TEAS WGs. In preparation= for WG LC here is the IPR polling. Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropria= te. If you are listed as a document author or contributor please answer the= above by responding to this email regardless of whether or not you are awa= re of any relevant IPR. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or co= ntributor, we remind you of your obligations under the IETF IPR rules which= encourages you to notify the IETF if you are aware of IPR of others on an = IETF contribution, or to refrain from participating in any contribution or = discussion related to your undisclosed IPR. For more information, please se= e the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki= /IntellectualProperty. Thank you, Daniele & Fatai --_000_7347100B5761DC41A166AC17F22DF11221A653ACeusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m not aware of= any IPR that applies to this drat.

 

   &nbs= p;            Regard= s,

   &nbs= p;            &= nbsp;           &nbs= p;   Greg

 

From: Longhao = [mailto:longhao@huawei.com]
Sent: Monday, May 02, 2016 11:52 PM
To: Daniele Ceccarelli; Yemin (Amy); Gregory Mirsky; D'Alessandro Al= essandro Gerardo (alessandro.dalessandro@telecomitalia.it); hshah@ciena.com=
Cc: CCAMP (ccamp@ietf.org); teas-chairs@ietf.org; TEAS WG (teas@ietf= .org)
Subject: RE: [CCAMP] Regarding IPR on draft-ietf-ccamp-ospf-availabi= lity-extension-04

 

No, I'm not aware of any IPR that applies to this dra= ft.

 

Hao

 

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Daniele Ceccarelli
Sent: Wednesday, April 27, 2016 7:35 PM
To: Longhao; Yemin (Amy); Gregory Mirsky; D'Alessandro Alessandro Ge= rardo (alessandr= o.dalessandro@telecomitalia.it); hshah@ciena.com
Cc: CCAMP (ccamp@ietf.org); teas-chairs@ietf.org; TEAS WG (teas@ie= tf.org)
Subject: [CCAMP] Regarding IPR on draft-ietf-ccamp-ospf-availability= -extension-04

&nbs= p;

Authors, = Contributors, CCAMP, TEAS,

&nbs= p;

It’= s time to move on with the bandwidth availability drafts. As agreed with th= e TEAS WG chairs the last call of draft-ietf-ccamp-ospf-availability-extens= ion-04 will be run jointly by the CCAMP and the TEAS WGs. In preparation for WG LC here is the IPR polling.=

&nbs= p;

Are you a= ware of any IPR that applies to draft identified above?

&nbs= p;

Please st= ate either:

"No,= I'm not aware of any IPR that applies to this draft"

or

"Yes= , I'm aware of IPR that applies to this draft"

&nbs= p;

If so, ha= s this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979,= 4879, 3669 and 5378 for more details)?

If yes to= the above, please state either:

&nbs= p;

"Yes= , the IPR has been disclosed in compliance with IETF IPR rules"

or

"No,= the IPR has not been disclosed"

&nbs= p;

If you an= swer no, please provide any additional details you think appropriate. If yo= u are listed as a document author or contributor please answer the above by= responding to this email regardless of whether or not you are aware of any relevant IPR.

&nbs= p;

NOTE: THI= S APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.

&nbs= p;

If you ar= e on the CCAMP WG email list but are not listed as an author or contributor= , we remind you of your obligations under the IETF IPR rules which encourag= es you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from partici= pating in any contribution or discussion related to your undisclosed IPR. F= or more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty<= /a>.

&nbs= p;

Thank you= ,

Daniele &= amp; Fatai

&nbs= p;

--_000_7347100B5761DC41A166AC17F22DF11221A653ACeusaamb103erics_-- From nobody Tue May 3 06:51:18 2016 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 0AB1D12D814; Tue, 3 May 2016 06:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZgiynPf75KG; Tue, 3 May 2016 06:51:03 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) (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 7F9D012D7FF; Tue, 3 May 2016 06:50:43 -0700 (PDT) Received: from pps.filterd (m0002317.ppops.net [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u43DknTW026783; Tue, 3 May 2016 09:50:30 -0400 Received: from mdwvexchht01.ciena.com (lin1-118-36-28.ciena.com [63.118.36.28]) by mx0b-00103a01.pphosted.com with ESMTP id 22mrxfj9nr-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Tue, 03 May 2016 09:50:30 -0400 Received: from VAWVE2K13MBX01.ciena.com (10.4.156.87) by MDWVEXCHHT01.ciena.com (10.4.156.175) with Microsoft SMTP Server (TLS) id 8.3.389.2; Tue, 3 May 2016 09:50:29 -0400 Received: from ONWVEXCHHT01.ciena.com (10.128.6.16) by VAWVE2K13MBX01.ciena.com (10.4.156.87) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 May 2016 09:50:29 -0400 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT01.ciena.com ([::1]) with mapi; Tue, 3 May 2016 09:50:28 -0400 From: "Shah, Himanshu" To: "Yemin (Amy)" , Daniele Ceccarelli , Longhao , "Gregory Mirsky" , "D'Alessandro Alessandro Gerardo (alessandro.dalessandro@telecomitalia.it)" Date: Tue, 3 May 2016 09:49:18 -0400 Thread-Topic: [Teas] Regarding IPR on draft-ietf-ccamp-ospf-availability-extension-04 Thread-Index: AdGgeDxNesVQlem3QeSqagGktKCXxwEkDCfQAA6KXuc= Message-ID: <40746B2300A8FC4AB04EE722A593182BABDF9727@ONWVEXCHMB04.ciena.com> References: <4A1562797D64E44993C5CBF38CF1BE48162BD0A5@ESESSMB301.ericsson.se>, <9C5FD3EFA72E1740A3D41BADDE0B461F9CD871D1@szxema506-mbs.china.huawei.com> In-Reply-To: <9C5FD3EFA72E1740A3D41BADDE0B461F9CD871D1@szxema506-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-TM-AS-Product-Ver: SMEX-11.0.0.4179-8.000.1202-22298.007 X-TM-AS-Result: No--6.242500-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-03_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 impostorscore=0 lowpriorityscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1605030215 Archived-At: Cc: "CCAMP \(ccamp@ietf.org\)" , "teas-chairs@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [Teas] Regarding IPR on draft-ietf-ccamp-ospf-availability-extension-04 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 13:51:08 -0000 I am not aware of any IPR that applies to this draft. Himanshu using iPad (so excuse the auto-corrects...) ________________________________________ From: Yemin (Amy) [amy.yemin@huawei.com] Sent: Tuesday, May 03, 2016 2:56 AM To: Daniele Ceccarelli; Longhao; Gregory Mirsky; D'Alessandro Alessandro Ge= rardo (alessandro.dalessandro@telecomitalia.it); Shah, Himanshu Cc: CCAMP (ccamp@ietf.org); teas-chairs@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [Teas] Regarding IPR on draft-ietf-ccamp-ospf-availability-= extension-04 No, I'm not aware of any IPR that applies to this draft. BR, Amy ________________________________ This e-mail and its attachments contain confidential information from HUAWE= I, which is intended only for the person or entity whose address is listed above. An= y use of the information contained herein in any way (including, but not limited to, tot= al or partial disclosure, reproduction, or dissemination) by persons other than the inten= ded recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by phone or email immediately and delete it! From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Daniele Ceccarelli Sent: Wednesday, April 27, 2016 7:35 PM To: Longhao; Yemin (Amy); Gregory Mirsky; D'Alessandro Alessandro Gerardo (= alessandro.dalessandro@telecomitalia.it); hshah@ciena.com Cc: CCAMP (ccamp@ietf.org); teas-chairs@ietf.org; TEAS WG (teas@ietf.org) Subject: [Teas] Regarding IPR on draft-ietf-ccamp-ospf-availability-extensi= on-04 Authors, Contributors, CCAMP, TEAS, It=92s time to move on with the bandwidth availability drafts. As agreed wi= th the TEAS WG chairs the last call of draft-ietf-ccamp-ospf-availability-e= xtension-04 will be run jointly by the CCAMP and the TEAS WGs. In preparati= on for WG LC here is the IPR polling. Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropria= te. If you are listed as a document author or contributor please answer the= above by responding to this email regardless of whether or not you are awa= re of any relevant IPR. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or co= ntributor, we remind you of your obligations under the IETF IPR rules which= encourages you to notify the IETF if you are aware of IPR of others on an = IETF contribution, or to refrain from participating in any contribution or = discussion related to your undisclosed IPR. For more information, please se= e the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki= /IntellectualProperty. Thank you, Daniele & Fatai From nobody Tue May 3 07:35:04 2016 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 925E612D83B; Tue, 3 May 2016 07:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYEvxdn4l6Z7; Tue, 3 May 2016 07:34:50 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBEAC12D836; Tue, 3 May 2016 07:34:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18533; q=dns/txt; s=iport; t=1462286087; x=1463495687; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=6hapEK+4a5NqZEWnEcnwCcVDxluvGkBsuEWvYhVB5YY=; b=gMKK5CMKI/VhRpfuu3P9n9yWhPOF4kNfF8ROe7fbBv762fdU6gkfEqan wUT+rrldSLpB42Bh0G4MlPYYu7YVxZmN9c+udVUtRvZmihTFEeUxN1qho Ij+TaFRODtw4rmJBOVK2xXxtSX7eVPvBnRqeS1/EIQ1KIfOqyRTLWGfhi c=; X-IronPort-AV: E=Sophos;i="5.24,572,1454976000"; d="scan'208,217";a="677025390" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 May 2016 14:34:45 +0000 Received: from [10.63.23.130] (dhcp-ensft1-uk-vla370-10-63-23-130.cisco.com [10.63.23.130]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u43EYifm013526; Tue, 3 May 2016 14:34:44 GMT To: "Tarek Saad (tsaad)" References: <4A05DD10-0885-435C-9D13-9634388B9F4B@cisco.com> <20160429.122943.1926404425708749601.mbj@tail-f.com> <50BEAA4E-C645-4DCE-A992-44B14B4EFC43@cisco.com> From: Robert Wilton Message-ID: Date: Tue, 3 May 2016 15:34:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <50BEAA4E-C645-4DCE-A992-44B14B4EFC43@cisco.com> Content-Type: multipart/alternative; boundary="------------57E5E5B11600F1732E20E271" Archived-At: Cc: "mpls@ietf.org" , Martin Bjorklund , "netmod@ietf.org" , "teas@ietf.org" , "draft-ietf-teas-yang-te@ietf.org" , "draft-ietf-netmod-schema-mount@ietf.org" Subject: Re: [Teas] [netmod] Use of schema mounts for common model X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 14:34:56 -0000 This is a multi-part message in MIME format. --------------57E5E5B11600F1732E20E271 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Tarek, I'm also wondering whether using schema mount in this way might be a bit like using a sledgehammer to crack a nut. With interfaces, there is a per device global list of interfaces where each list entry can have a different type and different properties. Currently these are using the iana:iftype to differentiate their different schema modes, but there is an idea to use more abstract identities. I'm not really familiar with the tunnel YANG models, but I was wondering whether the same approach has been considered for the TE tunnel YANG models at all? I.e. rather than having a separate protocol instantiation for each different data plane technology, instead have a per device global list of tunnels that hold the configuration and operational state, making use of when statements and identities (if required) to manage dataplane specific leaves. Each protocol specific data plane module could also maintain a protocol specific list containing leaf-refs back to the appropriate tunnels in the master list. Thanks, Rob On 29/04/2016 17:17, Tarek Saad (tsaad) wrote: > Thanks Martin, please see inline.. > > > On 2016-04-29, 6:29 AM, "Martin Bjorklund" > wrote: > > "Tarek Saad (tsaad)" > wrote: > > Hi authors/WG, > In draft-ietf-teas-yang-te, we are driving the definition for a > generic TE YANG model that can/may be used (and extended when > necessary) for different data plane technologies (e.g. MPLS, > OTN, WDM, > etc.). > Reviewing the schema mount idea presented in > draft-ietf-netmod-schema-mount, we are thinking this proposal is > useful and can facilitate the reuse of the our model in multiple > places in the YANG tree (once per each technology), e.g.: > …/mpls/mount-points/mount-point/module=ietf-te.yang > …/otn/mount-points/mount-point/module=ietf-te.yang > > > Schema mount is probably not the right solution to your problem. I > think a better solution in your case is to define groupings. > Groupings are designed to be re-used at different places in the > hierarchy. > > > We thought of this earlier, and found groupings pose their own set of > challenges too.. Specifically: > - a groupings with leafrefs could not reference data nodes that reside > in another grouping > - a grouping with leafrefs of relative path were challenge when the > relative path references data nodes outside the grouping > - the augmentation of the grouping by other modules is not as > straightforward > > That said, the grouping proposal seems to > > one could also think that with groupings one could address reuse of > the a model (e.g. Ietf-interfaces) for logical devices or VM (see > below). In fact, in your draft (section 2) you explicitly discourage > this approach as not scalable solution > > > With the "uses" approach, ietf-interfaces would have to define a > grouping with all its nodes, and the new model for logical devices > would have to use this grouping. This is a not a scalable solution, > since every time there is a new model defined, we would have to > update our model for logical devices to use a grouping from the new > model. Another problem is that this approach cannot handle vendor- > > > > We have a comment/concern/suggestion and we value your feedback. > The generic TE model currently references data nodes in the global > tree (e.g. from the ietf-interfaces model to define additional TE > properties associated with a specific device interface). Our > understanding after reading section 3.1 of your draft is the > mounted > model can *not* reference any data nodes outside the scope of the > mount-point (e.g. global data nodes in the yang tree). This > poses a > limitation for us, do you have a suggestion for this problem? > One possible solution we thought of was to replace the leaf-refs > pointing to the global data nodes (e.g. Ietf-interfaces) with > context > names (e.g. the interface name).. This decouples the data-nodes > defined in the TE generic model from those in the global tree > (e.g. the actual interface ietf-interfaces model). Any feedback on > this or better suggestions? > > > If you use groupings instead, you can still use proper leafrefs. > > > Not in all cases — as described above. > > Regards, > Tarek > > > > /martin > > > > Regards, > Tarek > Excerpt from draft-ietf-netmod-schema-mount > 3.1. > Augment and Validation in Mounted Data > All paths (in leafrefs, instance-identifiers, XPath > expressions, and > target nodes of augments) in the data models mounted at a > mount point > are interpreted with the mount point as the root node, and the > mounted data nodes as its children. This means that data > within a > mounted subtree can never refer to data outside of this > subtree. > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------57E5E5B11600F1732E20E271 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Tarek,

I'm also wondering whether using schema mount in this way might be a bit like using a sledgehammer to crack a nut.

With interfaces, there is a per device global list of interfaces where each list entry can have a different type and different properties.  Currently these are using the iana:iftype to differentiate their different schema modes, but there is an idea to use more abstract identities.

I'm not really familiar with the tunnel YANG models, but I was wondering whether the same approach has been considered for the TE tunnel YANG models at all?

I.e. rather than having a separate protocol instantiation for each different data plane technology, instead have a per device global list of tunnels that hold the configuration and operational state, making use of when statements and identities (if required) to manage dataplane specific leaves.  Each protocol specific data plane module could also maintain a protocol specific list containing leaf-refs back to the appropriate tunnels in the master list.

Thanks,
Rob


On 29/04/2016 17:17, Tarek Saad (tsaad) wrote:
Thanks Martin, please see inline..

"Tarek Saad (tsaad)" <tsaad@cisco.com> wrote:
Hi authors/WG,
In draft-ietf-teas-yang-te, we are driving the definition for a
generic TE YANG model that can/may be used (and extended when
necessary) for different data plane technologies (e.g. MPLS, OTN, WDM,
etc.).
Reviewing the schema mount idea presented in
draft-ietf-netmod-schema-mount, we are thinking this proposal is
useful and can facilitate the reuse of the our model in multiple
places in the YANG tree (once per each technology), e.g.:
…/mpls/mount-points/mount-point/module=ietf-te.yang
…/otn/mount-points/mount-point/module=ietf-te.yang

Schema mount is probably not the right solution to your problem.  I
think a better solution in your case is to define groupings.
Groupings are designed to be re-used at different places in the
hierarchy.

We thought of this earlier, and found groupings pose their own set of challenges too.. Specifically:
- a groupings with leafrefs could not reference data nodes that reside in another grouping
- a grouping with leafrefs of relative path were challenge when the relative path references data nodes outside the grouping
- the augmentation of the grouping by other modules is not as straightforward

That said, the grouping proposal seems to 

one could also think that with groupings one could address reuse of the a model (e.g. Ietf-interfaces) for logical devices or VM (see below). In fact, in your draft (section 2) you explicitly discourage this approach as not scalable solution


   With the "uses" approach, ietf-interfaces would have to define a
   grouping with all its nodes, and the new model for logical devices
   would have to use this grouping.  This is a not a scalable solution,
   since every time there is a new model defined, we would have to
   update our model for logical devices to use a grouping from the new
   model.  Another problem is that this approach cannot handle vendor-



We have a comment/concern/suggestion and we value your feedback.
The generic TE model currently references data nodes in the global
tree (e.g. from the ietf-interfaces model to define additional TE
properties associated with a specific device interface). Our
understanding after reading section 3.1 of your draft is the mounted
model can *not* reference any data nodes outside the scope of the
mount-point (e.g. global data nodes in the yang tree). This poses a
limitation for us, do you have a suggestion for this problem?
One possible solution we thought of was to replace the leaf-refs
pointing to the global data nodes (e.g. Ietf-interfaces) with context
names (e.g. the interface name).. This decouples the data-nodes
defined in the TE generic model from those in the global tree
(e.g. the actual interface ietf-interfaces model). Any feedback on
this or better suggestions?

If you use groupings instead, you can still use proper leafrefs.

Not in all cases — as described above.

Regards,
Tarek



/martin



Regards,
Tarek
Excerpt from draft-ietf-netmod-schema-mount
Augment and Validation in Mounted Data
    All paths (in leafrefs, instance-identifiers, XPath expressions, and
    target nodes of augments) in the data models mounted at a mount point
    are interpreted with the mount point as the root node, and the
    mounted data nodes as its children.  This means that data within a
    mounted subtree can never refer to data outside of this subtree.



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

--------------57E5E5B11600F1732E20E271-- From nobody Tue May 3 08:12:01 2016 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 A890D12D534 for ; Tue, 3 May 2016 08:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q86SO_mHk6nf for ; Tue, 3 May 2016 08:11:56 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EE5912D51B for ; Tue, 3 May 2016 08:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16424; q=dns/txt; s=iport; t=1462288316; x=1463497916; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=OpnVmXSX/GVrJQ+TalO1ZK0YcJ/A27VlRKKWxw4UQLs=; b=YIQ4FWsdxRc/A3uIHecB3zGrvaKeGFxBkXK9jwuXbBu17JmD7YZ6G90w ddQmgM8AqIFGrqFNyiFxywCHjbEYjaMwwVvtm4GZGFl74JOTSgJc+KB/f E/G3PJhyjOQJEeclm6s3VxSN0BKy48ByHNmvuKeVeDsqxfNMwPn8Cff47 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A5AwBdvyhX/49dJa1fgmxMU30GgnWyJ?= =?us-ascii?q?IRzAQ2BdYYQAhyBITgUAQEBAQEBAWUnhEEBAQEEDBcKQQsQAgEGAhEEAQEoAwI?= =?us-ascii?q?CAjAUCQgCBAENBQiIIo4ZnR2RGQEBAQEBAQEBAQEBAQEBAQEBAQEBARWGIINKg?= =?us-ascii?q?QOEdYJKglkFmBYBjhCBb4RNgymFNI8xAR4BAUKDa2yHPQF+AQEB?= X-IronPort-AV: E=Sophos; i="5.24,572,1454976000"; d="scan'208,217"; a="98602329" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 May 2016 15:11:49 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u43FBn6s009051 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 May 2016 15:11:49 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 May 2016 10:11:48 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Tue, 3 May 2016 10:11:48 -0500 From: "Matt Hartley (mhartley)" To: "Zhangxian (Xian)" , Vishnu Pavan Beeram , "teas@ietf.org" Thread-Topic: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-srlg-collect-05 Thread-Index: AQHRoY5hFf7aW4q4tU+wo+eHX2JTR5+mesmQgADdSbA= Date: Tue, 3 May 2016 15:11:48 +0000 Message-ID: <0ae55833714244719342e83bce5abe78@XCH-RCD-001.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.213.23] Content-Type: multipart/alternative; boundary="_000_0ae55833714244719342e83bce5abe78XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Matt Hartley \(mhartley\)" Subject: Re: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-srlg-collect-05 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 15:11:59 -0000 --_000_0ae55833714244719342e83bce5abe78XCHRCD001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgY29tbWVudHMsIFhpYW4hDQoNCk9uIHRoZSBlbmNvZGluZyBzZWN0aW9u OiB0aGUgZmVlZGJhY2sgSeKAmXZlIHJlY2VpdmVkIGluIHRoZSBwYXN0IGlzIHRoYXQgaXTigJlz IGJldHRlciBub3QgdG8gZG8gYWRkIHRoZSBiaXQgbnVtYmVycyB0byB0aGUgZW5jb2Rpbmcgc2Vj dGlvbiBhcyB5b3UgaGF2ZSB0byBtYXJrIHRoZW0gYXMgcHJvdmlzaW9uYWwvVEJELCBhbmQgdGhh dOKAmXMgdGhlbiBtb3JlIHdvcmsgZm9yIHRoZSBSRkMgRWRpdG9yIHRvIGNsZWFuIHVwIHdoZW4g SUFOQSBkb2VzIHRoZSBhc3NpZ25tZW504oCmIGJ1dCBJIGFncmVlLCB0aGUgZG9jIHdvdWxkIHJl YWQgYmV0dGVyIGlmIHlvdSBkaWRu4oCZdCBoYXZlIHRvIGdvIHRvIGFub3RoZXIgc2VjdGlvbiB0 byBzZWUgdGhlIHZhbHVlcy4gQ2hhaXJzLCBEZWJvcmFoIOKAkyBhbnkgY29tbWVudCBvbiB0aGlz Pw0KDQpUaGFua3MgZm9yIHRoZSBuaXRzIOKAkyBJ4oCZbGwgc29ydCB0aG9zZSBvdXQgd2hlbiBM QyBpcyBkb25lLg0KDQpDaGVlcnMNCg0KTWF0dA0KDQpIaSwgYWxsLA0KDQpJJ3ZlIHJldmlld2Vk IHRoaXMgZG9jdW1lbnQgYW5kIGJlbGlldmUgaXQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLg0K DQpJIGhhdmUgb25lIHN1Z2dlc3Rpb24gb24gdGhlIGVuY29kaW5nIHNlY3Rpb246IGNvdWxkIHdl IGFkZCB0aGUgYml0IG51bWJlciBmb3IgZWFjaCBmaWVsZCBleHBsYW5hdGlvbj8gSXQgbWF5IGJl IGEgYml0IHJlZHVuZGFudCwgYnV0IEkgZmluZCBpdCB1c3VhbGx5IGNsZWFyZXIgaWYgd2UgaGF2 ZSBzdWNoIGluZm9ybWF0aW9uIGluIHRoZSB0ZXh0Lg0KDQpPdGhlcnMgYXJlIGp1c3Qgc29tZSBu aXRzOg0KMe+8miBzL05vdGUgdGhhdCBzcGVjaWZpY2F0aW9uIG9mIHRoZSB0aGUgdXNlIG9mIHRo ZSBjb2xsZWN0ZWQgU1JMR3MgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4v Tm90ZSB0aGF0IHNwZWNpZmljYXRpb24gb2YgdGhlIHVzZSBvZiB0aGUgY29sbGVjdGVkIFNSTEdz IGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQoy77yacy9TUkxHIGluZm9y bWF0aW9uIGlzIGZvciBlYWNoIGhvcCBpcyBhZGRlZCB0byB0aGUgUGF0aCBSUk8gZHVyaW5nIFBh dGggbWVzc2FnZSBwcm9jZXNzaW5nLi9TUkxHIGluZm9ybWF0aW9uIGlzIGFkZGVkIGJ5IGVhY2gg aG9wIHRvIHRoZSBQYXRoIFJSTyBkdXJpbmcgUGF0aCBtZXNzYWdlIHByb2Nlc3NpbmcuKD8pDQoz OiBjb25zaWRlciByZWxvY2F0aW5nIHRoZSBmb2xsb3dpbmcgc2VudGVuY2UgdG8gdGhlIHZlcnkg YmVnaW5uaW5nIG9mIHRoaXMgc2VjdGlvbig1LjEpLCBtYXliZT8NCkEgbm9kZSBTSE9VTEQgTk9U IGFkZCBTUkxHIGluZm9ybWF0aW9uIHdpdGhvdXQgYW4gZXhwbGljaXQgcmVxdWVzdCBmb3IgaXQg YmVpbmcgbWFkZSBieSB0aGUgaW5ncmVzcyBub2RlIGluIHRoZSBQYXRoIG1lc3NhZ2UuDQo0OiBU aGUgcG9pbnRzIGxpc3RlZCBpbiBTZWN0aW9uIDYuMSBzdGFydGVkIHdpdGgg4oCcb+KAnSBhcmUg c3F1ZWV6ZWQgdG9nZXRoZXIgaW4gb25lIHBhcmFncmFwaDsgcGxlYXNlIHJlY3RpZnkuDQoNClJl Z2FyZHMsDQpYaWFuDQoNCkZyb206IFRlYXMgW21haWx0bzp0ZWFzLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBWaXNobnUgUGF2YW4gQmVlcmFtDQpTZW50OiAyMDE25bm0NOaciDI55pel IDQ6NDINClRvOiB0ZWFzQGlldGYub3JnPG1haWx0bzp0ZWFzQGlldGYub3JnPg0KU3ViamVjdDog W1RlYXNdIFdHIExhc3QgQ2FsbCBvbiBkcmFmdC1pZXRmLXRlYXMtcnN2cC10ZS1zcmxnLWNvbGxl Y3QtMDUNCg0KQWxsLA0KVGhpcyBzdGFydHMgYSB0d28gd2VlayB3b3JraW5nIGdyb3VwIGxhc3Qg Y2FsbCBvbg0KZHJhZnQtaWV0Zi10ZWFzLXJzdnAtdGUtc3JsZy1jb2xsZWN0LTA1Lg0KDQpUaGUg d29ya2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBvbiBUaHVyc2RheSwgTWF5IDEydGguIFBsZWFz ZQ0Kc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBURUFTIG1haWxpbmcgbGlzdC4NCg0KQXMgaXMg YWx3YXlzIHRoZSBjYXNlLCBwb3NpdGl2ZSBjb21tZW50cywgZS5nLiwgIkkndmUgcmV2aWV3ZWQg dGhpcw0KZG9jdW1lbnQgYW5kIGJlbGlldmUgaXQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uIiwg YXJlIHdlbGNvbWUhDQpUaGlzIGlzIHVzZWZ1bCBhbmQgaW1wb3J0YW50LCBldmVuIGZyb20gYXV0 aG9ycy4NCk5vdGUsIElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgb24gdGhpcyBkcmFmdC4NCg0KVGhh bmtzLA0KUGF2YW4gKGFuZCBMb3UpDQo= --_000_0ae55833714244719342e83bce5abe78XCHRCD001ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJCb29rbWFuIE9sZCBT dHlsZSI7DQoJcGFub3NlLTE6MiA1IDYgNCA1IDUgNSAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUg NCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OlNpbVN1bjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OlNpbVN1bjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5N c29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWluZGVudDoyMS4wcHQ7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseTpTaW1TdW47fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hh cg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9u dC1mYW1pbHk6U2ltU3VuO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkJvb2ttYW4gT2xkIFN0eWxlIixzZXJpZjsNCgljb2xvcjojOUUzNDAw O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjI1aW4gMS4waW4gMS4yNWluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1b3Q7LHNlcmlmO2NvbG9yOiM5RTM0MDAiPlRoYW5r cyBmb3IgdGhlIGNvbW1lbnRzLCBYaWFuITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1b3Q7LHNlcmlmO2NvbG9yOiM5RTM0MDAiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1b3Q7 LHNlcmlmO2NvbG9yOiM5RTM0MDAiPk9uIHRoZSBlbmNvZGluZyBzZWN0aW9uOiB0aGUgZmVlZGJh Y2sgSeKAmXZlIHJlY2VpdmVkIGluIHRoZSBwYXN0IGlzIHRoYXQgaXTigJlzIGJldHRlciBub3Qg dG8gZG8gYWRkIHRoZSBiaXQgbnVtYmVycyB0byB0aGUgZW5jb2Rpbmcgc2VjdGlvbiBhcyB5b3Ug aGF2ZSB0bw0KIG1hcmsgdGhlbSBhcyBwcm92aXNpb25hbC9UQkQsIGFuZCB0aGF04oCZcyB0aGVu IG1vcmUgd29yayBmb3IgdGhlIFJGQyBFZGl0b3IgdG8gY2xlYW4gdXAgd2hlbiBJQU5BIGRvZXMg dGhlIGFzc2lnbm1lbnTigKYgYnV0IEkgYWdyZWUsIHRoZSBkb2Mgd291bGQgcmVhZCBiZXR0ZXIg aWYgeW91IGRpZG7igJl0IGhhdmUgdG8gZ28gdG8gYW5vdGhlciBzZWN0aW9uIHRvIHNlZSB0aGUg dmFsdWVzLiBDaGFpcnMsIERlYm9yYWgg4oCTIGFueSBjb21tZW50IG9uIHRoaXM/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9va21hbiBPbGQgU3R5bGUmcXVvdDssc2VyaWY7 Y29sb3I6IzlFMzQwMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Qm9va21hbiBPbGQgU3R5bGUmcXVvdDssc2VyaWY7Y29sb3I6IzlFMzQwMCI+VGhhbmtzIGZvciB0 aGUgbml0cyDigJMgSeKAmWxsIHNvcnQgdGhvc2Ugb3V0IHdoZW4gTEMgaXMgZG9uZS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtCb29rbWFuIE9sZCBTdHlsZSZxdW90OyxzZXJp Zjtjb2xvcjojOUUzNDAwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtCb29rbWFuIE9sZCBTdHlsZSZxdW90OyxzZXJpZjtjb2xvcjojOUUzNDAwIj5DaGVlcnM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtCb29rbWFuIE9sZCBTdHlsZSZxdW90Oyxz ZXJpZjtjb2xvcjojOUUzNDAwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtCb29rbWFuIE9sZCBTdHlsZSZxdW90OyxzZXJpZjtjb2xvcjojOUUzNDAwIj5NYXR0PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9va21hbiBPbGQgU3R5bGUmcXVvdDss c2VyaWY7Y29sb3I6IzlFMzQwMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBp biAwaW4gMGluIDQuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+SGksIGFsbCwgPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkkndmUgcmV2aWV3ZWQgdGhp cyBkb2N1bWVudCBhbmQgYmVsaWV2ZSBpdCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PkkgaGF2ZSBvbmUgc3VnZ2VzdGlvbiBvbiB0aGUgZW5jb2Rpbmcgc2VjdGlvbjogY291bGQgd2Ug YWRkIHRoZSBiaXQgbnVtYmVyIGZvciBlYWNoIGZpZWxkIGV4cGxhbmF0aW9uPyBJdCBtYXkgYmUg YSBiaXQgcmVkdW5kYW50LCBidXQgSSBmaW5kIGl0IHVzdWFsbHkgY2xlYXJlciBpZiB3ZSBoYXZl IHN1Y2ggaW5mb3JtYXRpb24gaW4gdGhlDQogdGV4dC4gPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPk90aGVycyBhcmUganVzdCBz b21lIG5pdHM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4xPHNwYW4gbGFuZz0iWkgtQ04i Pu+8mjwvc3Bhbj4gcy9Ob3RlIHRoYXQgc3BlY2lmaWNhdGlvbiBvZiB0aGUgdGhlIHVzZSBvZiB0 aGUgY29sbGVjdGVkIFNSTEdzIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQu L05vdGUgdGhhdCBzcGVjaWZpY2F0aW9uIG9mIHRoZSB1c2Ugb2YgdGhlIGNvbGxlY3RlZCBTUkxH cyBpcyBvdXRzaWRlDQogdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj4yPHNwYW4gbGFuZz0iWkgtQ04iPu+8mjwvc3Bhbj5zL1NSTEcgaW5mb3Jt YXRpb24gaXMgZm9yIGVhY2ggaG9wIGlzIGFkZGVkIHRvIHRoZSBQYXRoIFJSTyBkdXJpbmcgUGF0 aCBtZXNzYWdlIHByb2Nlc3NpbmcuL1NSTEcgaW5mb3JtYXRpb24gaXMgYWRkZWQgYnkgZWFjaCBo b3AgdG8gdGhlIFBhdGggUlJPIGR1cmluZyBQYXRoIG1lc3NhZ2UgcHJvY2Vzc2luZy4oPyk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjM6IGNvbnNpZGVyIHJlbG9jYXRpbmcgdGhlIGZvbGxv d2luZyBzZW50ZW5jZSB0byB0aGUgdmVyeSBiZWdpbm5pbmcgb2YgdGhpcyBzZWN0aW9uKDUuMSks IG1heWJlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJ0ZXh0LWluZGVudDouMjVpbiI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj5BIG5vZGUgU0hPVUxEIE5PVCBhZGQgU1JMRyBpbmZvcm1hdGlvbiB3aXRob3V0IGFuIGV4 cGxpY2l0IHJlcXVlc3QgZm9yIGl0IGJlaW5nIG1hZGUgYnkgdGhlIGluZ3Jlc3Mgbm9kZSBpbiB0 aGUgUGF0aCBtZXNzYWdlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+NDogVGhlIHBvaW50 cyBsaXN0ZWQgaW4gU2VjdGlvbiA2LjEgc3RhcnRlZCB3aXRoDQo8c3BhbiBsYW5nPSJaSC1DTiI+ 4oCcPC9zcGFuPm88c3BhbiBsYW5nPSJaSC1DTiI+4oCdPC9zcGFuPiBhcmUgc3F1ZWV6ZWQgdG9n ZXRoZXIgaW4gb25lIHBhcmFncmFwaDsgcGxlYXNlIHJlY3RpZnkuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5S ZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+WGlhbjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiBUZWFzIFs8 YSBocmVmPSJtYWlsdG86dGVhcy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86dGVhcy1ib3VuY2Vz QGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+VmlzaG51IFBhdmFuIEJlZXJhbTxi cj4NCjxiPlNlbnQ6PC9iPiAyMDE2PC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+5bm0PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oyxz YW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj40PC9zcGFuPjxzcGFuIGxhbmc9 IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+5pyIPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4y OTwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPuaXpTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+DQogNDo0Mjxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRv OnRlYXNAaWV0Zi5vcmciPnRlYXNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtU ZWFzXSBXRyBMYXN0IENhbGwgb24gZHJhZnQtaWV0Zi10ZWFzLXJzdnAtdGUtc3JsZy1jb2xsZWN0 LTA1PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPkFsbCw8YnI+DQpUaGlzIHN0YXJ0cyBhIHR3byB3ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBj YWxsIG9uPGJyPg0KZHJhZnQtaWV0Zi10ZWFzLXJzdnAtdGUtc3JsZy1jb2xsZWN0LTA1Ljxicj4N Cjxicj4NClRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBlbmRzIG9uIFRodXJzZGF5LCBNYXkg MTJ0aC4gUGxlYXNlPGJyPg0Kc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBURUFTIG1haWxpbmcg bGlzdC48YnI+DQo8YnI+DQpBcyBpcyBhbHdheXMgdGhlIGNhc2UsIHBvc2l0aXZlIGNvbW1lbnRz LCBlLmcuLCAmcXVvdDtJJ3ZlIHJldmlld2VkIHRoaXM8YnI+DQpkb2N1bWVudCBhbmQgYmVsaWV2 ZSBpdCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24mcXVvdDssIGFyZSB3ZWxjb21lITxicj4NClRo aXMgaXMgdXNlZnVsIGFuZCBpbXBvcnRhbnQsIGV2ZW4gZnJvbSBhdXRob3JzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5Ob3RlLCBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIG9u IHRoaXMgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PGJyPg0KVGhh bmtzLDxicj4NClBhdmFuIChhbmQgTG91KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_0ae55833714244719342e83bce5abe78XCHRCD001ciscocom_-- From nobody Tue May 3 20:48:01 2016 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 399BD12D5C6 for ; Tue, 3 May 2016 20:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id My9Y42zBe2HS for ; Tue, 3 May 2016 20:47:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE53E12D134 for ; Tue, 3 May 2016 20:47:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJD15227; Wed, 04 May 2016 03:47:55 +0000 (GMT) Received: from SZXEMA415-HUB.china.huawei.com (10.82.72.33) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 4 May 2016 04:47:54 +0100 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.211]) by SZXEMA415-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0235.001; Wed, 4 May 2016 11:47:50 +0800 From: "Zhangxian (Xian)" To: "Matt Hartley (mhartley)" Thread-Topic: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-srlg-collect-05 Thread-Index: AQHRoY5hFf7aW4q4tU+wo+eHX2JTR5+mesmQgADdSbCAANJjAA== Date: Wed, 4 May 2016 03:47:50 +0000 Message-ID: References: <0ae55833714244719342e83bce5abe78@XCH-RCD-001.cisco.com> In-Reply-To: <0ae55833714244719342e83bce5abe78@XCH-RCD-001.cisco.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.104.209] Content-Type: multipart/alternative; boundary="_000_C636AF2FA540124E9B9ACB5A6BECCE6B7DEA6D57SZXEMA512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.572970EC.0019, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.211, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 14bd6ad2e43c9b2e145dbaf265c16119 Archived-At: Cc: Vishnu Pavan Beeram , "teas@ietf.org" Subject: Re: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-srlg-collect-05 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 04 May 2016 03:48:00 -0000 --_000_C636AF2FA540124E9B9ACB5A6BECCE6B7DEA6D57SZXEMA512MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIE1hdHQsDQoNCiAgICBHcmVhdDsganVzdCBvbmUgY2xhcmlmaWNhdGlvbiBpbmxpbmU6DQoN CiAgIEZyb206IE1hdHQgSGFydGxleSAobWhhcnRsZXkpIFttYWlsdG86bWhhcnRsZXlAY2lzY28u Y29tXQ0KU2VudDogMjAxNuW5tDXmnIgz5pelIDIzOjEyDQpUbzogWmhhbmd4aWFuIChYaWFuKTsg VmlzaG51IFBhdmFuIEJlZXJhbTsgdGVhc0BpZXRmLm9yZw0KQ2M6IE1hdHQgSGFydGxleSAobWhh cnRsZXkpDQpTdWJqZWN0OiBSRTogW1RlYXNdIFdHIExhc3QgQ2FsbCBvbiBkcmFmdC1pZXRmLXRl YXMtcnN2cC10ZS1zcmxnLWNvbGxlY3QtMDUNCg0KVGhhbmtzIGZvciB0aGUgY29tbWVudHMsIFhp YW4hDQoNCk9uIHRoZSBlbmNvZGluZyBzZWN0aW9uOiB0aGUgZmVlZGJhY2sgSeKAmXZlIHJlY2Vp dmVkIGluIHRoZSBwYXN0IGlzIHRoYXQgaXTigJlzIGJldHRlciBub3QgdG8gZG8gYWRkIHRoZSBi aXQgbnVtYmVycyB0byB0aGUgZW5jb2Rpbmcgc2VjdGlvbiBhcyB5b3UgaGF2ZSB0byBtYXJrIHRo ZW0gYXMgcHJvdmlzaW9uYWwvVEJELCBhbmQgdGhhdOKAmXMgdGhlbiBtb3JlIHdvcmsgZm9yIHRo ZSBSRkMgRWRpdG9yIHRvIGNsZWFuIHVwIHdoZW4gSUFOQSBkb2VzIHRoZSBhc3NpZ25tZW504oCm IGJ1dCBJIGFncmVlLCB0aGUgZG9jIHdvdWxkIHJlYWQgYmV0dGVyIGlmIHlvdSBkaWRu4oCZdCBo YXZlIHRvIGdvIHRvIGFub3RoZXIgc2VjdGlvbiB0byBzZWUgdGhlIHZhbHVlcy4gQ2hhaXJzLCBE ZWJvcmFoIOKAkyBhbnkgY29tbWVudCBvbiB0aGlzPw0KDQpKdXN0IHRvIG1ha2Ugc3VyZSBJIGdl dCBteSBwb2ludCB0aHJvdWdoLCBJIGFtIG5vdCB0YWxraW5nIGFib3V0IHRoZSBjb2RlIHBvaW50 IGFsbG9jYXRpb24sIGJ1dCBqdXN0IGhvdyBtYW55IGJpdHMgZWFjaCBmaWVsZCB0YWtlcyAoZm9y IGV4YW1wbGU6IElzIGxlbmd0aCBmaWVsZCA4LWJpdCBvciA3LWJpdD8gQSBiYWQgZXhhbXBsZSwg anVzdCB0byBpbGx1c3RyYXRlIHRoZSBwb2ludCkuIEFGQUlLLCBJQU5BIHNlY3Rpb24gZG9lcyBu b3QgY292ZXIgdGhpcyBpbmZvcm1hdGlvbi4gSWYgaXQgaXMgbm90IHByb3ZpZGVkLCB0aGUgcmVh ZGVyL2ltcGxlbWVudGVyIG1heSBuZWVkIHRvIGRvIGEgbWFudWFsIGNvdW50LiAgQnV0IHRoZSBl bmNvZGluZyBpbiB0aGlzIGRyYWZ0IGlzIHNvIHNpbXBsZSB0aGF0IHlvdSBtYXkgbm90IHNlZSB0 aGUgbmVjZXNzaXR5LCBzbyB1cCB0byB5b3UvdGhlIGRyYWZ0IGVkaXRvci4NCg0KUmVnYXJkcywN ClhpYW4NCg0KVGhhbmtzIGZvciB0aGUgbml0cyDigJMgSeKAmWxsIHNvcnQgdGhvc2Ugb3V0IHdo ZW4gTEMgaXMgZG9uZS4NCg0KQ2hlZXJzDQoNCk1hdHQNCg0KSGksIGFsbCwNCg0KSSd2ZSByZXZp ZXdlZCB0aGlzIGRvY3VtZW50IGFuZCBiZWxpZXZlIGl0IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlv bi4NCg0KSSBoYXZlIG9uZSBzdWdnZXN0aW9uIG9uIHRoZSBlbmNvZGluZyBzZWN0aW9uOiBjb3Vs ZCB3ZSBhZGQgdGhlIGJpdCBudW1iZXIgZm9yIGVhY2ggZmllbGQgZXhwbGFuYXRpb24/IEl0IG1h eSBiZSBhIGJpdCByZWR1bmRhbnQsIGJ1dCBJIGZpbmQgaXQgdXN1YWxseSBjbGVhcmVyIGlmIHdl IGhhdmUgc3VjaCBpbmZvcm1hdGlvbiBpbiB0aGUgdGV4dC4NCg0KT3RoZXJzIGFyZSBqdXN0IHNv bWUgbml0czoNCjHvvJogcy9Ob3RlIHRoYXQgc3BlY2lmaWNhdGlvbiBvZiB0aGUgdGhlIHVzZSBv ZiB0aGUgY29sbGVjdGVkIFNSTEdzIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1l bnQuL05vdGUgdGhhdCBzcGVjaWZpY2F0aW9uIG9mIHRoZSB1c2Ugb2YgdGhlIGNvbGxlY3RlZCBT UkxHcyBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KMu+8mnMvU1JMRyBp bmZvcm1hdGlvbiBpcyBmb3IgZWFjaCBob3AgaXMgYWRkZWQgdG8gdGhlIFBhdGggUlJPIGR1cmlu ZyBQYXRoIG1lc3NhZ2UgcHJvY2Vzc2luZy4vU1JMRyBpbmZvcm1hdGlvbiBpcyBhZGRlZCBieSBl YWNoIGhvcCB0byB0aGUgUGF0aCBSUk8gZHVyaW5nIFBhdGggbWVzc2FnZSBwcm9jZXNzaW5nLig/ KQ0KMzogY29uc2lkZXIgcmVsb2NhdGluZyB0aGUgZm9sbG93aW5nIHNlbnRlbmNlIHRvIHRoZSB2 ZXJ5IGJlZ2lubmluZyBvZiB0aGlzIHNlY3Rpb24oNS4xKSwgbWF5YmU/DQpBIG5vZGUgU0hPVUxE IE5PVCBhZGQgU1JMRyBpbmZvcm1hdGlvbiB3aXRob3V0IGFuIGV4cGxpY2l0IHJlcXVlc3QgZm9y IGl0IGJlaW5nIG1hZGUgYnkgdGhlIGluZ3Jlc3Mgbm9kZSBpbiB0aGUgUGF0aCBtZXNzYWdlLg0K NDogVGhlIHBvaW50cyBsaXN0ZWQgaW4gU2VjdGlvbiA2LjEgc3RhcnRlZCB3aXRoIOKAnG/igJ0g YXJlIHNxdWVlemVkIHRvZ2V0aGVyIGluIG9uZSBwYXJhZ3JhcGg7IHBsZWFzZSByZWN0aWZ5Lg0K DQpSZWdhcmRzLA0KWGlhbg0KDQpGcm9tOiBUZWFzIFttYWlsdG86dGVhcy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgVmlzaG51IFBhdmFuIEJlZXJhbQ0KU2VudDogMjAxNuW5tDTmnIgy OeaXpSA0OjQyDQpUbzogdGVhc0BpZXRmLm9yZzxtYWlsdG86dGVhc0BpZXRmLm9yZz4NClN1Ympl Y3Q6IFtUZWFzXSBXRyBMYXN0IENhbGwgb24gZHJhZnQtaWV0Zi10ZWFzLXJzdnAtdGUtc3JsZy1j b2xsZWN0LTA1DQoNCkFsbCwNClRoaXMgc3RhcnRzIGEgdHdvIHdlZWsgd29ya2luZyBncm91cCBs YXN0IGNhbGwgb24NCmRyYWZ0LWlldGYtdGVhcy1yc3ZwLXRlLXNybGctY29sbGVjdC0wNS4NCg0K VGhlIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGVuZHMgb24gVGh1cnNkYXksIE1heSAxMnRoLiBQ bGVhc2UNCnNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgVEVBUyBtYWlsaW5nIGxpc3QuDQoNCkFz IGlzIGFsd2F5cyB0aGUgY2FzZSwgcG9zaXRpdmUgY29tbWVudHMsIGUuZy4sICJJJ3ZlIHJldmll d2VkIHRoaXMNCmRvY3VtZW50IGFuZCBiZWxpZXZlIGl0IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlv biIsIGFyZSB3ZWxjb21lIQ0KVGhpcyBpcyB1c2VmdWwgYW5kIGltcG9ydGFudCwgZXZlbiBmcm9t IGF1dGhvcnMuDQpOb3RlLCBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIG9uIHRoaXMgZHJhZnQuDQoN ClRoYW5rcywNClBhdmFuIChhbmQgTG91KQ0K --_000_C636AF2FA540124E9B9ACB5A6BECCE6B7DEA6D57SZXEMA512MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJCb29rbWFuIE9sZCBTdHlsZSI7DQoJcGFub3NlLTE6MiA1IDYgNCA1IDUg NSAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5N c29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWluZGVudDoyMS4wcHQ7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hh cg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9u dC1mYW1pbHk65a6L5L2TO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQm9va21hbiBPbGQgU3R5bGUiLCJzZXJpZiI7DQoJY29sb3I6IzlFMzQwMDt9 DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkhpLCBNYXR0LA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0dyZWF0OyBqdXN0IG9uZSBjbGFyaWZpY2F0aW9u IGlubGluZToNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTWF0dCBIYXJ0bGV5IChtaGFydGxleSkg W21haWx0bzptaGFydGxleUBjaXNjby5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMjAxNjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5bm0PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+NTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+5pyIPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Mzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5pelPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQogMjM6MTI8YnI+DQo8Yj5Ubzo8 L2I+IFpoYW5neGlhbiAoWGlhbik7IFZpc2hudSBQYXZhbiBCZWVyYW07IHRlYXNAaWV0Zi5vcmc8 YnI+DQo8Yj5DYzo8L2I+IE1hdHQgSGFydGxleSAobWhhcnRsZXkpPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJFOiBbVGVhc10gV0cgTGFzdCBDYWxsIG9uIGRyYWZ0LWlldGYtdGVhcy1yc3ZwLXRlLXNy bGctY29sbGVjdC0wNTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiM5RTM0MDAiPlRoYW5rcyBmb3IgdGhlIGNvbW1lbnRz LCBYaWFuITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtC b29rbWFuIE9sZCBTdHlsZSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojOUUzNDAwIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9v a21hbiBPbGQgU3R5bGUmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzlFMzQwMCI+T24g dGhlIGVuY29kaW5nIHNlY3Rpb246IHRoZSBmZWVkYmFjayBJ4oCZdmUgcmVjZWl2ZWQgaW4gdGhl IHBhc3QgaXMgdGhhdCBpdOKAmXMgYmV0dGVyIG5vdCB0byBkbyBhZGQgdGhlIGJpdCBudW1iZXJz IHRvIHRoZSBlbmNvZGluZyBzZWN0aW9uDQogYXMgeW91IGhhdmUgdG8gbWFyayB0aGVtIGFzIHBy b3Zpc2lvbmFsL1RCRCwgYW5kIHRoYXTigJlzIHRoZW4gbW9yZSB3b3JrIGZvciB0aGUgUkZDIEVk aXRvciB0byBjbGVhbiB1cCB3aGVuIElBTkEgZG9lcyB0aGUgYXNzaWdubWVudOKApiBidXQgSSBh Z3JlZSwgdGhlIGRvYyB3b3VsZCByZWFkIGJldHRlciBpZiB5b3UgZGlkbuKAmXQgaGF2ZSB0byBn byB0byBhbm90aGVyIHNlY3Rpb24gdG8gc2VlIHRoZSB2YWx1ZXMuIENoYWlycywgRGVib3JhaCDi gJMgYW55DQogY29tbWVudCBvbiB0aGlzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtCb29rbWFuIE9sZCBTdHlsZSZxdW90OywmcXVvdDtzZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6OS42cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SnVzdCB0byBtYWtlIHN1cmUgSSBn ZXQgbXkgcG9pbnQgdGhyb3VnaCwgSSBhbSBub3QgdGFsa2luZyBhYm91dCB0aGUgY29kZSBwb2lu dCBhbGxvY2F0aW9uLCBidXQganVzdCBob3cgbWFueSBiaXRzIGVhY2gNCiBmaWVsZCB0YWtlcyAo Zm9yIGV4YW1wbGU6IElzIGxlbmd0aCBmaWVsZCA4LWJpdCBvciA3LWJpdD8gQSBiYWQgZXhhbXBs ZSwganVzdCB0byBpbGx1c3RyYXRlIHRoZSBwb2ludCkuIEFGQUlLLCBJQU5BIHNlY3Rpb24gZG9l cyBub3QgY292ZXIgdGhpcyBpbmZvcm1hdGlvbi4gSWYgaXQgaXMgbm90IHByb3ZpZGVkLCB0aGUg cmVhZGVyL2ltcGxlbWVudGVyIG1heSBuZWVkIHRvIGRvIGEgbWFudWFsIGNvdW50LiAmbmJzcDtC dXQgdGhlIGVuY29kaW5nIGluIHRoaXMNCiBkcmFmdCBpcyBzbyBzaW1wbGUgdGhhdCB5b3UgbWF5 IG5vdCBzZWUgdGhlIG5lY2Vzc2l0eSwgc28gdXAgdG8geW91L3RoZSBkcmFmdCBlZGl0b3IuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5k ZW50OjkuNnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlhp YW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtCb29rbWFuIE9sZCBT dHlsZSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojOUUzNDAwIj5UaGFua3MgZm9yIHRo ZSBuaXRzIOKAkyBJ4oCZbGwgc29ydCB0aG9zZSBvdXQgd2hlbiBMQyBpcyBkb25lLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtCb29rbWFuIE9sZCBTdHls ZSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojOUUzNDAwIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9va21hbiBPbGQgU3R5bGUm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzlFMzQwMCI+Q2hlZXJzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiM5RTM0MDAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtCb29rbWFuIE9sZCBTdHlsZSZxdW90 OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojOUUzNDAwIj5NYXR0PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O2NvbG9yOiM5RTM0MDAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+SGksIGFsbCwgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JJ3ZlIHJldmlld2VkIHRo aXMgZG9jdW1lbnQgYW5kIGJlbGlldmUgaXQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+SSBoYXZlIG9uZSBzdWdnZXN0aW9uIG9uIHRoZSBlbmNvZGluZyBzZWN0 aW9uOiBjb3VsZCB3ZSBhZGQgdGhlIGJpdCBudW1iZXIgZm9yIGVhY2ggZmllbGQgZXhwbGFuYXRp b24/IEl0IG1heSBiZSBhIGJpdCByZWR1bmRhbnQsIGJ1dCBJIGZpbmQgaXQgdXN1YWxseSBjbGVh cmVyIGlmIHdlIGhhdmUgc3VjaCBpbmZvcm1hdGlvbiBpbiB0aGUgdGV4dC4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+T3RoZXJzIGFyZSBqdXN0IHNvbWUgbml0czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+MTwvc3Bhbj7vvJo8c3Bh biBsYW5nPSJFTi1VUyI+IHMvTm90ZSB0aGF0IHNwZWNpZmljYXRpb24gb2YgdGhlIHRoZSB1c2Ug b2YgdGhlIGNvbGxlY3RlZCBTUkxHcyBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3Vt ZW50Li9Ob3RlIHRoYXQgc3BlY2lmaWNhdGlvbiBvZiB0aGUgdXNlIG9mIHRoZSBjb2xsZWN0ZWQg U1JMR3MgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcw0KIGRvY3VtZW50LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4yPC9z cGFuPu+8mjxzcGFuIGxhbmc9IkVOLVVTIj5zL1NSTEcgaW5mb3JtYXRpb24gaXMgZm9yIGVhY2gg aG9wIGlzIGFkZGVkIHRvIHRoZSBQYXRoIFJSTyBkdXJpbmcgUGF0aCBtZXNzYWdlIHByb2Nlc3Np bmcuL1NSTEcgaW5mb3JtYXRpb24gaXMgYWRkZWQgYnkgZWFjaCBob3AgdG8gdGhlIFBhdGggUlJP IGR1cmluZyBQYXRoIG1lc3NhZ2UgcHJvY2Vzc2luZy4oPyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+MzogY29uc2lkZXIgcmVs b2NhdGluZyB0aGUgZm9sbG93aW5nIHNlbnRlbmNlIHRvIHRoZSB2ZXJ5IGJlZ2lubmluZyBvZiB0 aGlzIHNlY3Rpb24oNS4xKSwgbWF5YmU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50OjE4LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMi PkEgbm9kZSBTSE9VTEQgTk9UIGFkZCBTUkxHIGluZm9ybWF0aW9uIHdpdGhvdXQgYW4gZXhwbGlj aXQgcmVxdWVzdCBmb3IgaXQgYmVpbmcgbWFkZSBieSB0aGUgaW5ncmVzcyBub2RlIGluIHRoZSBQ YXRoIG1lc3NhZ2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjQ6IFRoZSBwb2ludHMgbGlzdGVkIGluIFNlY3Rpb24gNi4xIHN0 YXJ0ZWQgd2l0aA0KPC9zcGFuPuKAnDxzcGFuIGxhbmc9IkVOLVVTIj5vPC9zcGFuPuKAnTxzcGFu IGxhbmc9IkVOLVVTIj4gYXJlIHNxdWVlemVkIHRvZ2V0aGVyIGluIG9uZSBwYXJhZ3JhcGg7IHBs ZWFzZSByZWN0aWZ5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+WGlhbjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVGVhcyBb PGEgaHJlZj0ibWFpbHRvOnRlYXMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnRlYXMtYm91bmNl c0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlZpc2hudSBQYXZhbiBCZWVyYW08 YnI+DQo8Yj5TZW50OjwvYj4gMjAxNjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+5bm0PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+NDwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5pyIPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Mjk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPuaXpTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPg0KIDQ6NDI8YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzp0ZWFzQGlldGYu b3JnIj50ZWFzQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbVGVhc10gV0cgTGFz dCBDYWxsIG9uIGRyYWZ0LWlldGYtdGVhcy1yc3ZwLXRlLXNybGctY29sbGVjdC0wNTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+QWxsLDxicj4NClRoaXMgc3RhcnRzIGEgdHdvIHdlZWsgd29ya2luZyBncm91cCBsYXN0 IGNhbGwgb248YnI+DQpkcmFmdC1pZXRmLXRlYXMtcnN2cC10ZS1zcmxnLWNvbGxlY3QtMDUuPGJy Pg0KPGJyPg0KVGhlIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGVuZHMgb24gVGh1cnNkYXksIE1h eSAxMnRoLiBQbGVhc2U8YnI+DQpzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIFRFQVMgbWFpbGlu ZyBsaXN0Ljxicj4NCjxicj4NCkFzIGlzIGFsd2F5cyB0aGUgY2FzZSwgcG9zaXRpdmUgY29tbWVu dHMsIGUuZy4sICZxdW90O0kndmUgcmV2aWV3ZWQgdGhpczxicj4NCmRvY3VtZW50IGFuZCBiZWxp ZXZlIGl0IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbiZxdW90OywgYXJlIHdlbGNvbWUhPGJyPg0K VGhpcyBpcyB1c2VmdWwgYW5kIGltcG9ydGFudCwgZXZlbiBmcm9tIGF1dGhvcnMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+Tm90ZSwgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBvbiB0aGlzIGRyYWZ0LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PGJyPg0KVGhhbmtzLDxicj4NClBhdmFuIChhbmQgTG91KTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_C636AF2FA540124E9B9ACB5A6BECCE6B7DEA6D57SZXEMA512MBSchi_-- From nobody Wed May 4 08:57:12 2016 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 F255412DA6F for ; Wed, 4 May 2016 08:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5qFweQiZvwH for ; Wed, 4 May 2016 08:57:04 -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 BF0CC12D766 for ; Wed, 4 May 2016 08:50:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25086; q=dns/txt; s=iport; t=1462377044; x=1463586644; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=f+aBi9eb13uWEnbhsYRE8J08tSjHmzdyzE9t/qp27oo=; b=E9LDAuo0tLjubxd5f7bxproFvENl2FdPr8Mj3RgTUhuUH13oW7XWcJEu fqBIbdNVabXIj8nnLvu0bhk1SIU/oG512RKTqWlkgW8jNDNXRz3GWsnV7 nJrYknG+GwwE+QGOXa4GwYTmOLrUwfNEPzb2TugDM8IMJH8UZIUIyiLdw 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CwAgCGGSpX/4QNJK1egmxMU30GgnW2b?= =?us-ascii?q?QENgXWGEAIcgRk4FAEBAQEBAQFlJ4RBAQEBBAwXCkELEAIBBgIRBAEBKAMCAgI?= =?us-ascii?q?wFAkIAgQOBQiIIo8ZnR2RAwEBAQEBAQEBAQEBAQEBAQEBAQEBARWGIINKgQOEd?= =?us-ascii?q?YJKglkFmBkBjhCBb4RNgymFNY8zAR4BAUKDa2yHPQF+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,577,1454976000"; d="scan'208,217";a="100808444" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 May 2016 15:50:43 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u44Foh7b013129 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 May 2016 15:50:43 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 May 2016 10:50:43 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Wed, 4 May 2016 10:50:43 -0500 From: "Matt Hartley (mhartley)" To: "Zhangxian (Xian)" Thread-Topic: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-srlg-collect-05 Thread-Index: AQHRoY5hFf7aW4q4tU+wo+eHX2JTR5+mesmQgADdSbCAANJjAIAAy7wQ Date: Wed, 4 May 2016 15:50:42 +0000 Message-ID: <360e911befe44c9d92608d70f6418be9@XCH-RCD-001.cisco.com> References: <0ae55833714244719342e83bce5abe78@XCH-RCD-001.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.213.152] Content-Type: multipart/alternative; boundary="_000_360e911befe44c9d92608d70f6418be9XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Matt Hartley \(mhartley\)" , Vishnu Pavan Beeram , "teas@ietf.org" Subject: Re: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-srlg-collect-05 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 04 May 2016 15:57:11 -0000 --_000_360e911befe44c9d92608d70f6418be9XCHRCD001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WGlhbiwNCg0KT0sg4oCTIEkgdW5kZXJzdGFuZCB3aGF0IHlvdSBtZWFuIG5vdy4gSeKAmWxsIGRv IHRoYXQgdG9vLg0KDQpDaGVlcnMNCg0KTWF0dA0KDQoNCkhpLCBNYXR0LA0KDQogICAgR3JlYXQ7 IGp1c3Qgb25lIGNsYXJpZmljYXRpb24gaW5saW5lOg0KDQogICBGcm9tOiBNYXR0IEhhcnRsZXkg KG1oYXJ0bGV5KSBbbWFpbHRvOm1oYXJ0bGV5QGNpc2NvLmNvbV0NClNlbnQ6IDIwMTblubQ15pyI M+aXpSAyMzoxMg0KVG86IFpoYW5neGlhbiAoWGlhbik7IFZpc2hudSBQYXZhbiBCZWVyYW07IHRl YXNAaWV0Zi5vcmc8bWFpbHRvOnRlYXNAaWV0Zi5vcmc+DQpDYzogTWF0dCBIYXJ0bGV5IChtaGFy dGxleSkNClN1YmplY3Q6IFJFOiBbVGVhc10gV0cgTGFzdCBDYWxsIG9uIGRyYWZ0LWlldGYtdGVh cy1yc3ZwLXRlLXNybGctY29sbGVjdC0wNQ0KDQpUaGFua3MgZm9yIHRoZSBjb21tZW50cywgWGlh biENCg0KT24gdGhlIGVuY29kaW5nIHNlY3Rpb246IHRoZSBmZWVkYmFjayBJ4oCZdmUgcmVjZWl2 ZWQgaW4gdGhlIHBhc3QgaXMgdGhhdCBpdOKAmXMgYmV0dGVyIG5vdCB0byBkbyBhZGQgdGhlIGJp dCBudW1iZXJzIHRvIHRoZSBlbmNvZGluZyBzZWN0aW9uIGFzIHlvdSBoYXZlIHRvIG1hcmsgdGhl bSBhcyBwcm92aXNpb25hbC9UQkQsIGFuZCB0aGF04oCZcyB0aGVuIG1vcmUgd29yayBmb3IgdGhl IFJGQyBFZGl0b3IgdG8gY2xlYW4gdXAgd2hlbiBJQU5BIGRvZXMgdGhlIGFzc2lnbm1lbnTigKYg YnV0IEkgYWdyZWUsIHRoZSBkb2Mgd291bGQgcmVhZCBiZXR0ZXIgaWYgeW91IGRpZG7igJl0IGhh dmUgdG8gZ28gdG8gYW5vdGhlciBzZWN0aW9uIHRvIHNlZSB0aGUgdmFsdWVzLiBDaGFpcnMsIERl Ym9yYWgg4oCTIGFueSBjb21tZW50IG9uIHRoaXM/DQoNCkp1c3QgdG8gbWFrZSBzdXJlIEkgZ2V0 IG15IHBvaW50IHRocm91Z2gsIEkgYW0gbm90IHRhbGtpbmcgYWJvdXQgdGhlIGNvZGUgcG9pbnQg YWxsb2NhdGlvbiwgYnV0IGp1c3QgaG93IG1hbnkgYml0cyBlYWNoIGZpZWxkIHRha2VzIChmb3Ig ZXhhbXBsZTogSXMgbGVuZ3RoIGZpZWxkIDgtYml0IG9yIDctYml0PyBBIGJhZCBleGFtcGxlLCBq dXN0IHRvIGlsbHVzdHJhdGUgdGhlIHBvaW50KS4gQUZBSUssIElBTkEgc2VjdGlvbiBkb2VzIG5v dCBjb3ZlciB0aGlzIGluZm9ybWF0aW9uLiBJZiBpdCBpcyBub3QgcHJvdmlkZWQsIHRoZSByZWFk ZXIvaW1wbGVtZW50ZXIgbWF5IG5lZWQgdG8gZG8gYSBtYW51YWwgY291bnQuICBCdXQgdGhlIGVu Y29kaW5nIGluIHRoaXMgZHJhZnQgaXMgc28gc2ltcGxlIHRoYXQgeW91IG1heSBub3Qgc2VlIHRo ZSBuZWNlc3NpdHksIHNvIHVwIHRvIHlvdS90aGUgZHJhZnQgZWRpdG9yLg0KDQpSZWdhcmRzLA0K WGlhbg0KDQpUaGFua3MgZm9yIHRoZSBuaXRzIOKAkyBJ4oCZbGwgc29ydCB0aG9zZSBvdXQgd2hl biBMQyBpcyBkb25lLg0KDQpDaGVlcnMNCg0KTWF0dA0KDQpIaSwgYWxsLA0KDQpJJ3ZlIHJldmll d2VkIHRoaXMgZG9jdW1lbnQgYW5kIGJlbGlldmUgaXQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9u Lg0KDQpJIGhhdmUgb25lIHN1Z2dlc3Rpb24gb24gdGhlIGVuY29kaW5nIHNlY3Rpb246IGNvdWxk IHdlIGFkZCB0aGUgYml0IG51bWJlciBmb3IgZWFjaCBmaWVsZCBleHBsYW5hdGlvbj8gSXQgbWF5 IGJlIGEgYml0IHJlZHVuZGFudCwgYnV0IEkgZmluZCBpdCB1c3VhbGx5IGNsZWFyZXIgaWYgd2Ug aGF2ZSBzdWNoIGluZm9ybWF0aW9uIGluIHRoZSB0ZXh0Lg0KDQpPdGhlcnMgYXJlIGp1c3Qgc29t ZSBuaXRzOg0KMe+8miBzL05vdGUgdGhhdCBzcGVjaWZpY2F0aW9uIG9mIHRoZSB0aGUgdXNlIG9m IHRoZSBjb2xsZWN0ZWQgU1JMR3MgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVu dC4vTm90ZSB0aGF0IHNwZWNpZmljYXRpb24gb2YgdGhlIHVzZSBvZiB0aGUgY29sbGVjdGVkIFNS TEdzIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQoy77yacy9TUkxHIGlu Zm9ybWF0aW9uIGlzIGZvciBlYWNoIGhvcCBpcyBhZGRlZCB0byB0aGUgUGF0aCBSUk8gZHVyaW5n IFBhdGggbWVzc2FnZSBwcm9jZXNzaW5nLi9TUkxHIGluZm9ybWF0aW9uIGlzIGFkZGVkIGJ5IGVh Y2ggaG9wIHRvIHRoZSBQYXRoIFJSTyBkdXJpbmcgUGF0aCBtZXNzYWdlIHByb2Nlc3NpbmcuKD8p DQozOiBjb25zaWRlciByZWxvY2F0aW5nIHRoZSBmb2xsb3dpbmcgc2VudGVuY2UgdG8gdGhlIHZl cnkgYmVnaW5uaW5nIG9mIHRoaXMgc2VjdGlvbig1LjEpLCBtYXliZT8NCkEgbm9kZSBTSE9VTEQg Tk9UIGFkZCBTUkxHIGluZm9ybWF0aW9uIHdpdGhvdXQgYW4gZXhwbGljaXQgcmVxdWVzdCBmb3Ig aXQgYmVpbmcgbWFkZSBieSB0aGUgaW5ncmVzcyBub2RlIGluIHRoZSBQYXRoIG1lc3NhZ2UuDQo0 OiBUaGUgcG9pbnRzIGxpc3RlZCBpbiBTZWN0aW9uIDYuMSBzdGFydGVkIHdpdGgg4oCcb+KAnSBh cmUgc3F1ZWV6ZWQgdG9nZXRoZXIgaW4gb25lIHBhcmFncmFwaDsgcGxlYXNlIHJlY3RpZnkuDQoN ClJlZ2FyZHMsDQpYaWFuDQoNCkZyb206IFRlYXMgW21haWx0bzp0ZWFzLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBWaXNobnUgUGF2YW4gQmVlcmFtDQpTZW50OiAyMDE25bm0NOaciDI5 5pelIDQ6NDINClRvOiB0ZWFzQGlldGYub3JnPG1haWx0bzp0ZWFzQGlldGYub3JnPg0KU3ViamVj dDogW1RlYXNdIFdHIExhc3QgQ2FsbCBvbiBkcmFmdC1pZXRmLXRlYXMtcnN2cC10ZS1zcmxnLWNv bGxlY3QtMDUNCg0KQWxsLA0KVGhpcyBzdGFydHMgYSB0d28gd2VlayB3b3JraW5nIGdyb3VwIGxh c3QgY2FsbCBvbg0KZHJhZnQtaWV0Zi10ZWFzLXJzdnAtdGUtc3JsZy1jb2xsZWN0LTA1Lg0KDQpU aGUgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBvbiBUaHVyc2RheSwgTWF5IDEydGguIFBs ZWFzZQ0Kc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBURUFTIG1haWxpbmcgbGlzdC4NCg0KQXMg aXMgYWx3YXlzIHRoZSBjYXNlLCBwb3NpdGl2ZSBjb21tZW50cywgZS5nLiwgIkkndmUgcmV2aWV3 ZWQgdGhpcw0KZG9jdW1lbnQgYW5kIGJlbGlldmUgaXQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9u IiwgYXJlIHdlbGNvbWUhDQpUaGlzIGlzIHVzZWZ1bCBhbmQgaW1wb3J0YW50LCBldmVuIGZyb20g YXV0aG9ycy4NCk5vdGUsIElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgb24gdGhpcyBkcmFmdC4NCg0K VGhhbmtzLA0KUGF2YW4gKGFuZCBMb3UpDQo= --_000_360e911befe44c9d92608d70f6418be9XCHRCD001ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJCb29rbWFuIE9sZCBT dHlsZSI7DQoJcGFub3NlLTE6MiA1IDYgNCA1IDUgNSAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUg NCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OlNpbVN1bjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OlNpbVN1bjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5N c29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWluZGVudDoyMS4wcHQ7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseTpTaW1TdW47fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hh cg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9u dC1mYW1pbHk6U2ltU3VuO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkJvb2ttYW4gT2xkIFN0eWxlIixzZXJpZjsNCgljb2xvcjojOUUzNDAwO30NCnNw YW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkJvb2tt YW4gT2xkIFN0eWxlIixzZXJpZjsNCgljb2xvcjojOUUzNDAwO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjI1aW4g MS4waW4gMS4yNWluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2ttYW4gT2xkIFN0 eWxlJnF1b3Q7LHNlcmlmO2NvbG9yOiM5RTM0MDAiPlhpYW4sPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Qm9va21hbiBPbGQgU3R5bGUmcXVvdDssc2VyaWY7Y29sb3I6IzlFMzQw MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9va21hbiBPbGQg U3R5bGUmcXVvdDssc2VyaWY7Y29sb3I6IzlFMzQwMCI+T0sg4oCTIEkgdW5kZXJzdGFuZCB3aGF0 IHlvdSBtZWFuIG5vdy4gSeKAmWxsIGRvIHRoYXQgdG9vLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1b3Q7LHNlcmlmO2NvbG9yOiM5RTM0MDAi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2ttYW4gT2xkIFN0 eWxlJnF1b3Q7LHNlcmlmO2NvbG9yOiM5RTM0MDAiPkNoZWVyczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1b3Q7LHNlcmlmO2NvbG9yOiM5RTM0 MDAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2ttYW4gT2xk IFN0eWxlJnF1b3Q7LHNlcmlmO2NvbG9yOiM5RTM0MDAiPk1hdHQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtCb29rbWFuIE9sZCBTdHlsZSZxdW90OyxzZXJpZjtjb2xvcjojOUUz NDAwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+SGksIE1hdHQsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0dyZWF0OyBqdXN0IG9uZSBjbGFyaWZpY2F0 aW9uIGlubGluZToNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOyZuYnNwOw0KPC9zcGFuPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiBNYXR0IEhhcnRsZXkg KG1oYXJ0bGV5KSBbPGEgaHJlZj0ibWFpbHRvOm1oYXJ0bGV5QGNpc2NvLmNvbSI+bWFpbHRvOm1o YXJ0bGV5QGNpc2NvLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMjAxNjwvc3Bhbj48c3Bh biBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPuW5tDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+NTwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPuaciDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjttc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Mzwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPuaXpTwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+DQogMjM6MTI8YnI+DQo8 Yj5Ubzo8L2I+IFpoYW5neGlhbiAoWGlhbik7IFZpc2hudSBQYXZhbiBCZWVyYW07IDxhIGhyZWY9 Im1haWx0bzp0ZWFzQGlldGYub3JnIj4NCnRlYXNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+Q2M6PC9i PiBNYXR0IEhhcnRsZXkgKG1oYXJ0bGV5KTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW1RlYXNd IFdHIExhc3QgQ2FsbCBvbiBkcmFmdC1pZXRmLXRlYXMtcnN2cC10ZS1zcmxnLWNvbGxlY3QtMDU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtCb29rbWFuIE9sZCBTdHlsZSZxdW90OyxzZXJp Zjtjb2xvcjojOUUzNDAwO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5UaGFua3MgZm9yIHRo ZSBjb21tZW50cywgWGlhbiE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtCb29r bWFuIE9sZCBTdHlsZSZxdW90OyxzZXJpZjtjb2xvcjojOUUzNDAwO21zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtCb29r bWFuIE9sZCBTdHlsZSZxdW90OyxzZXJpZjtjb2xvcjojOUUzNDAwO21zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOIj5PbiB0aGUgZW5jb2Rpbmcgc2VjdGlvbjogdGhlIGZlZWRiYWNrIEnigJl2ZSBy ZWNlaXZlZCBpbiB0aGUgcGFzdCBpcyB0aGF0IGl04oCZcyBiZXR0ZXIgbm90IHRvIGRvIGFkZCB0 aGUgYml0IG51bWJlcnMgdG8gdGhlIGVuY29kaW5nDQogc2VjdGlvbiBhcyB5b3UgaGF2ZSB0byBt YXJrIHRoZW0gYXMgcHJvdmlzaW9uYWwvVEJELCBhbmQgdGhhdOKAmXMgdGhlbiBtb3JlIHdvcmsg Zm9yIHRoZSBSRkMgRWRpdG9yIHRvIGNsZWFuIHVwIHdoZW4gSUFOQSBkb2VzIHRoZSBhc3NpZ25t ZW504oCmIGJ1dCBJIGFncmVlLCB0aGUgZG9jIHdvdWxkIHJlYWQgYmV0dGVyIGlmIHlvdSBkaWRu 4oCZdCBoYXZlIHRvIGdvIHRvIGFub3RoZXIgc2VjdGlvbiB0byBzZWUgdGhlIHZhbHVlcy4gQ2hh aXJzLCBEZWJvcmFoDQog4oCTIGFueSBjb21tZW50IG9uIHRoaXM/PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Qm9va21hbiBPbGQgU3R5bGUmcXVvdDssc2VyaWY7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50OjkuNnB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+SnVz dCB0byBtYWtlIHN1cmUgSSBnZXQgbXkgcG9pbnQgdGhyb3VnaCwgSSBhbSBub3QgdGFsa2luZyBh Ym91dCB0aGUgY29kZSBwb2ludCBhbGxvY2F0aW9uLCBidXQganVzdCBob3cNCiBtYW55IGJpdHMg ZWFjaCBmaWVsZCB0YWtlcyAoZm9yIGV4YW1wbGU6IElzIGxlbmd0aCBmaWVsZCA4LWJpdCBvciA3 LWJpdD8gQSBiYWQgZXhhbXBsZSwganVzdCB0byBpbGx1c3RyYXRlIHRoZSBwb2ludCkuIEFGQUlL LCBJQU5BIHNlY3Rpb24gZG9lcyBub3QgY292ZXIgdGhpcyBpbmZvcm1hdGlvbi4gSWYgaXQgaXMg bm90IHByb3ZpZGVkLCB0aGUgcmVhZGVyL2ltcGxlbWVudGVyIG1heSBuZWVkIHRvIGRvIGEgbWFu dWFsIGNvdW50LiAmbmJzcDtCdXQgdGhlDQogZW5jb2RpbmcgaW4gdGhpcyBkcmFmdCBpcyBzbyBz aW1wbGUgdGhhdCB5b3UgbWF5IG5vdCBzZWUgdGhlIG5lY2Vzc2l0eSwgc28gdXAgdG8geW91L3Ro ZSBkcmFmdCBlZGl0b3IuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9InRleHQtaW5kZW50OjkuNnB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlhpYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Qm9va21hbiBPbGQgU3R5bGUmcXVvdDssc2VyaWY7Y29sb3I6IzlFMzQwMDttc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTiI+VGhhbmtzIGZvciB0aGUgbml0cyDigJMgSeKAmWxsIHNvcnQgdGhvc2Ug b3V0IHdoZW4gTEMgaXMgZG9uZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtC b29rbWFuIE9sZCBTdHlsZSZxdW90OyxzZXJpZjtjb2xvcjojOUUzNDAwO21zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtC b29rbWFuIE9sZCBTdHlsZSZxdW90OyxzZXJpZjtjb2xvcjojOUUzNDAwO21zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj5DaGVlcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtC b29rbWFuIE9sZCBTdHlsZSZxdW90OyxzZXJpZjtjb2xvcjojOUUzNDAwO21zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtC b29rbWFuIE9sZCBTdHlsZSZxdW90OyxzZXJpZjtjb2xvcjojOUUzNDAwO21zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj5NYXR0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9v a21hbiBPbGQgU3R5bGUmcXVvdDssc2VyaWY7Y29sb3I6IzlFMzQwMDttc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDQuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTiI+SGksIGFsbCwgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkkndmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVu dCBhbmQgYmVsaWV2ZSBpdCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkkgaGF2ZSBv bmUgc3VnZ2VzdGlvbiBvbiB0aGUgZW5jb2Rpbmcgc2VjdGlvbjogY291bGQgd2UgYWRkIHRoZSBi aXQgbnVtYmVyIGZvciBlYWNoIGZpZWxkIGV4cGxhbmF0aW9uPyBJdCBtYXkgYmUgYSBiaXQgcmVk dW5kYW50LCBidXQgSSBmaW5kIGl0IHVzdWFsbHkgY2xlYXJlciBpZiB3ZSBoYXZlIHN1Y2ggaW5m b3JtYXRpb24gaW4gdGhlDQogdGV4dC4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPk90aGVycyBhcmUganVzdCBzb21lIG5pdHM6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4xPHNwYW4gbGFuZz0iWkgtQ04iPu+8mjwvc3Bh bj4gcy9Ob3RlIHRoYXQgc3BlY2lmaWNhdGlvbiBvZiB0aGUgdGhlIHVzZSBvZiB0aGUgY29sbGVj dGVkIFNSTEdzIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuL05vdGUgdGhh dCBzcGVjaWZpY2F0aW9uIG9mIHRoZSB1c2Ugb2YgdGhlIGNvbGxlY3RlZCBTUkxHcyBpcyBvdXRz aWRlDQogdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj4yPHNwYW4gbGFuZz0iWkgtQ04iPu+8mjwvc3Bhbj5zL1NSTEcgaW5mb3JtYXRpb24gaXMg Zm9yIGVhY2ggaG9wIGlzIGFkZGVkIHRvIHRoZSBQYXRoIFJSTyBkdXJpbmcgUGF0aCBtZXNzYWdl IHByb2Nlc3NpbmcuL1NSTEcgaW5mb3JtYXRpb24gaXMgYWRkZWQgYnkgZWFjaCBob3AgdG8gdGhl IFBhdGggUlJPIGR1cmluZyBQYXRoIG1lc3NhZ2UgcHJvY2Vzc2luZy4oPyk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPjM6IGNvbnNpZGVyIHJlbG9jYXRpbmcgdGhlIGZvbGxvd2luZyBzZW50 ZW5jZSB0byB0aGUgdmVyeSBiZWdpbm5pbmcgb2YgdGhpcyBzZWN0aW9uKDUuMSksIG1heWJlPzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWlu ZGVudDouMjVpbiI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5BIG5v ZGUgU0hPVUxEIE5PVCBhZGQgU1JMRyBpbmZvcm1hdGlvbiB3aXRob3V0IGFuIGV4cGxpY2l0IHJl cXVlc3QgZm9yIGl0IGJlaW5nIG1hZGUgYnkgdGhlIGluZ3Jlc3Mgbm9kZSBpbiB0aGUgUGF0aCBt ZXNzYWdlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+NDogVGhlIHBvaW50cyBsaXN0ZWQg aW4gU2VjdGlvbiA2LjEgc3RhcnRlZCB3aXRoDQo8c3BhbiBsYW5nPSJaSC1DTiI+4oCcPC9zcGFu Pm88c3BhbiBsYW5nPSJaSC1DTiI+4oCdPC9zcGFuPiBhcmUgc3F1ZWV6ZWQgdG9nZXRoZXIgaW4g b25lIHBhcmFncmFwaDsgcGxlYXNlIHJlY3RpZnkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5SZWdhcmRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+WGlhbjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oyxz YW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiBUZWFzIFs8YSBocmVmPSJt YWlsdG86dGVhcy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86dGVhcy1ib3VuY2VzQGlldGYub3Jn PC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+VmlzaG51IFBhdmFuIEJlZXJhbTxicj4NCjxiPlNl bnQ6PC9iPiAyMDE2PC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+5bm0PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlm O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj40PC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+5pyIPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4yOTwvc3Bhbj48 c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6WkgtQ04iPuaXpTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+DQogNDo0Mjxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnRlYXNAaWV0 Zi5vcmciPnRlYXNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtUZWFzXSBXRyBM YXN0IENhbGwgb24gZHJhZnQtaWV0Zi10ZWFzLXJzdnAtdGUtc3JsZy1jb2xsZWN0LTA1PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkFsbCw8 YnI+DQpUaGlzIHN0YXJ0cyBhIHR3byB3ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uPGJy Pg0KZHJhZnQtaWV0Zi10ZWFzLXJzdnAtdGUtc3JsZy1jb2xsZWN0LTA1Ljxicj4NCjxicj4NClRo ZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBlbmRzIG9uIFRodXJzZGF5LCBNYXkgMTJ0aC4gUGxl YXNlPGJyPg0Kc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBURUFTIG1haWxpbmcgbGlzdC48YnI+ DQo8YnI+DQpBcyBpcyBhbHdheXMgdGhlIGNhc2UsIHBvc2l0aXZlIGNvbW1lbnRzLCBlLmcuLCAm cXVvdDtJJ3ZlIHJldmlld2VkIHRoaXM8YnI+DQpkb2N1bWVudCBhbmQgYmVsaWV2ZSBpdCBpcyBy ZWFkeSBmb3IgcHVibGljYXRpb24mcXVvdDssIGFyZSB3ZWxjb21lITxicj4NClRoaXMgaXMgdXNl ZnVsIGFuZCBpbXBvcnRhbnQsIGV2ZW4gZnJvbSBhdXRob3JzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj5Ob3RlLCBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIG9uIHRoaXMgZHJh ZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PGJyPg0KVGhhbmtzLDxicj4N ClBhdmFuIChhbmQgTG91KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_360e911befe44c9d92608d70f6418be9XCHRCD001ciscocom_-- From nobody Thu May 5 02:43:06 2016 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 A7BA212D0C9; Thu, 5 May 2016 02:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.206 X-Spam-Level: X-Spam-Status: No, score=-5.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTKJtZ_Biqhh; Thu, 5 May 2016 02:42:49 -0700 (PDT) Received: from TELEDG002RM001.telecomitalia.it (teledg002rm001.telecomitalia.it [217.169.121.30]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4BD112D09C; Thu, 5 May 2016 02:42:47 -0700 (PDT) Content-Type: multipart/mixed; boundary="_e5ffcfdd-fe02-4b9d-b721-c41579b10f57_" Received: from TELMBXA05RM001.telecomitalia.local (10.14.252.32) by TELEDG002RM001.telecomitalia.it (10.19.3.112) with Microsoft SMTP Server (TLS) id 14.3.266.1; Thu, 5 May 2016 11:42:43 +0200 Received: from TELMBXA05RM001.telecomitalia.local (10.14.252.32) by TELMBXA05RM001.telecomitalia.local (10.14.252.32) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 5 May 2016 11:42:43 +0200 Received: from TELMBXA05RM001.telecomitalia.local ([fe80::cce8:4f15:2cf1:376]) by TELMBXA05RM001.telecomitalia.local ([fe80::cce8:4f15:2cf1:376%19]) with mapi id 15.00.1178.000; Thu, 5 May 2016 11:42:43 +0200 From: D'Alessandro Alessandro Gerardo To: Gregory Mirsky , Longhao , Daniele Ceccarelli , "Yemin (Amy)" , "hshah@ciena.com" Thread-Topic: [CCAMP] Regarding IPR on draft-ietf-ccamp-ospf-availability-extension-04 Thread-Index: AQHRpQhdtLe/Eb1qcESC6FlPebSBaJ+mpmiAgAN0YaA= Date: Thu, 5 May 2016 09:42:43 +0000 Message-ID: <61f9d43ff2ca437788968983a9f39468@TELMBXA05RM001.telecomitalia.local> References: <4A1562797D64E44993C5CBF38CF1BE48162BD0A5@ESESSMB301.ericsson.se> <27AADBCF3D83CF468918A05EC75F2084383A4296@SZXEMA504-MBS.china.huawei.com> <7347100B5761DC41A166AC17F22DF11221A653AC@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A653AC@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.14.252.238] x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Archived-At: Cc: "CCAMP \(ccamp@ietf.org\)" , "teas-chairs@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: [Teas] R: [CCAMP] Regarding IPR on draft-ietf-ccamp-ospf-availability-extension-04 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 05 May 2016 09:43:00 -0000 --_e5ffcfdd-fe02-4b9d-b721-c41579b10f57_ Content-Type: multipart/related; boundary="_004_61f9d43ff2ca437788968983a9f39468TELMBXA05RM001telecomit_"; type="multipart/alternative" --_004_61f9d43ff2ca437788968983a9f39468TELMBXA05RM001telecomit_ Content-Type: multipart/alternative; boundary="_000_61f9d43ff2ca437788968983a9f39468TELMBXA05RM001telecomit_" --_000_61f9d43ff2ca437788968983a9f39468TELMBXA05RM001telecomit_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm not aware of any IPR that applies to this draft. Best regards, Alessandro ------------------------------------------------------------------ [logo1] Alessandro Gerardo D'Alessandro Transport Innovation Transport and IP Innovation Via Reiss Romoli, 274 - 10148 Torino phone: +39 011 228 5887 mobile: +39 335 766 9607 fax: +39 06 418 639 07 Tim Official: Facebook - Twitter<= https://twitter.com/tim_official> www.tim.it Da: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Inviato: marted=EC 3 maggio 2016 08:57 A: Longhao; Daniele Ceccarelli; Yemin (Amy); D'Alessandro Alessandro Gerard= o; hshah@ciena.com Cc: CCAMP (ccamp@ietf.org); teas-chairs@ietf.org; TEAS WG (teas@ietf.org) Oggetto: RE: [CCAMP] Regarding IPR on draft-ietf-ccamp-ospf-availability-ex= tension-04 I'm not aware of any IPR that applies to this drat. Regards, Greg From: Longhao [mailto:longhao@huawei.com] Sent: Monday, May 02, 2016 11:52 PM To: Daniele Ceccarelli; Yemin (Amy); Gregory Mirsky; D'Alessandro Alessandr= o Gerardo (alessandro.dalessandro@telecomitalia.it); hshah@ciena.com Cc: CCAMP (ccamp@ietf.org); teas-chairs@ietf.org; TEAS WG (teas@ietf.org) Subject: RE: [CCAMP] Regarding IPR on draft-ietf-ccamp-ospf-availability-ex= tension-04 No, I'm not aware of any IPR that applies to this draft. Hao From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Daniele Ceccarelli Sent: Wednesday, April 27, 2016 7:35 PM To: Longhao; Yemin (Amy); Gregory Mirsky; D'Alessandro Alessandro Gerardo (= alessandro.dalessandro@telecomitalia.it); hshah@ciena.com Cc: CCAMP (ccamp@ietf.org); teas-chairs@ietf.org; TEAS WG (teas@ietf.org) Subject: [CCAMP] Regarding IPR on draft-ietf-ccamp-ospf-availability-extens= ion-04 Authors, Contributors, CCAMP, TEAS, It's time to move on with the bandwidth availability drafts. As agreed with= the TEAS WG chairs the last call of draft-ietf-ccamp-ospf-availability-ext= ension-04 will be run jointly by the CCAMP and the TEAS WGs. In preparation= for WG LC here is the IPR polling. Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropria= te. If you are listed as a document author or contributor please answer the= above by responding to this email regardless of whether or not you are awa= re of any relevant IPR. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or co= ntributor, we remind you of your obligations under the IETF IPR rules which= encourages you to notify the IETF if you are aware of IPR of others on an = IETF contribution, or to refrain from participating in any contribution or = discussion related to your undisclosed IPR. For more information, please se= e the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki= /IntellectualProperty. Thank you, Daniele & Fatai Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mail se non = =E8 necessario. --_000_61f9d43ff2ca437788968983a9f39468TELMBXA05RM001telecomit_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I'm not aware = of any IPR that applies to this draft.

Best regards,=

Alessandro

 

-------------= -----------------------------------------------------
3D"logo1"<= span lang=3D"IT" style=3D"font-size:7.5pt;font-family:"Helvetica"= ,"sans-serif";mso-fareast-font-family:"Times New Roman"= ;color:#012169;mso-ansi-language:IT;mso-fareast-language:IT;mso-no-proof:ye= s">

Alessandro Gerardo D'Alessandro
Transport Innovation

Transport and IP Innovation<= /span>
Via Reiss Romoli, 274 - 10148 Torino
phone:  +39 011 228 5887
mobile: +39 335 766 9607
fax: +39 06 418 639 07

Tim Official: Facebook - Twitter

www.tim.it

 

Da: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
Inviato: marted=EC 3 maggio 2016 08:57
A: Longhao; Daniele Ceccarelli; Yemin (Amy); D'Alessandro Alessandro= Gerardo; hshah@ciena.com
Cc: CCAMP (ccamp@ietf.org); teas-chairs@ietf.org; TEAS WG (teas@ietf= .org)
Oggetto: RE: [CCAMP] Regarding IPR on draft-ietf-ccamp-ospf-availabi= lity-extension-04

 

I’m not aware of any IPR that applies to this drat.<= o:p>

 

         &nbs= p;      Regards,

         &nbs= p;            &= nbsp;         Greg

 

 

No, I'm not aw= are of any IPR that applies to this draft.

 

Hao=

 

From:= CCAMP [mailto:ccamp-bounces@ietf= .org] On Behalf Of Daniele Ceccarelli
Sent: Wednesday, April 27, 2016 7:35 PM
To: Longhao; Yemin (Amy); Gregory Mirsky; D'Alessandro Alessandro Ge= rardo (alessandr= o.dalessandro@telecomitalia.it); hshah@ciena.com
Cc: CCAMP (ccamp@ietf.org); teas-chairs@ietf.org; TEAS WG (teas@ie= tf.org)
Subject: [CCAMP] Regarding IPR on draft-ietf-ccamp-ospf-availability= -extension-04

 

Authors, Contributors, CCAMP, TEAS,

 

It’s time to move on with the bandwidth= availability drafts. As agreed with the TEAS WG chairs the last call of dr= aft-ietf-ccamp-ospf-availability-extension-04 will be run jointly by the CCAMP and the TEAS WGs. In preparation for WG L= C here is the IPR polling.

 

Are you aware of any IPR that applies to draf= t identified above?

 

Please state either:

"No, I'm not aware of any IPR that appli= es to this draft"

or

"Yes, I'm aware of IPR that applies to t= his draft"

 

If so, has this IPR been disclosed in complia= nce with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more detail= s)?

If yes to the above, please state either:

 

"Yes, the IPR has been disclosed in comp= liance with IETF IPR rules"

or

"No, the IPR has not been disclosed"= ;

 

If you answer no, please provide any addition= al details you think appropriate. If you are listed as a document author or= contributor please answer the above by responding to this email regardless of whether or not you are aware of any= relevant IPR.

 

NOTE: THIS APPLIES TO ALL OF YOU LISTED IN TH= IS MESSAGE'S TO LINES.

 

If you are on the CCAMP WG email list but are= not listed as an author or contributor, we remind you of your obligations = under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contri= bution, or to refrain from participating in any contribution or discussion = related to your undisclosed IPR. For more information, please see the RFCs = listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty<= /a>.

 

Thank you,

Daniele & Fatai

 

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non =E8 necessario.

--_000_61f9d43ff2ca437788968983a9f39468TELMBXA05RM001telecomit_-- --_004_61f9d43ff2ca437788968983a9f39468TELMBXA05RM001telecomit_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=2519; creation-date="Thu, 05 May 2016 09:42:43 GMT"; modification-date="Thu, 05 May 2016 09:42:43 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/4QPARXhpZgAATU0AKgAAAAgADwD+AAQAAAABAAAAAAEAAAQA AAABAAADMwEBAAQAAAABAAABzAECAAMAAAADAAAAwgEDAAMAAAABAAUAAAEGAAMAAAABAAIAAAER AAQAAABcAAAAyAEVAAMAAAABAAMAAAEWAAQAAAABAAAABQEXAAQAAABcAAACOAEaAAUAAAABAAAD qAEbAAUAAAABAAADsAEcAAMAAAABAAEAAAEoAAMAAAABAAIAAAE9AAMAAAABAAIAAAAAAAAACAAI AAgAAAAIAAADGQAABaQAAAfvAAAKlAAADVcAAA9QAAARSQAAFAYAABdXAAAalAAAHgkAACE5AAAj cAAAJaYAAChhAAArbAAALaUAADADAAAzjgAANEsAADUIAAA1xQAANoIAADc/AAA3/AAAOLkAADl2 AAA6MwAAOvAAADutAAA8agAAPScAAD3kAAA+oQAAP14AAEAbAABA2AAAQZUAAEJSAABDDwAAQ8wA AESJAABFRgAARgMAAEbAAABHfQAASDoAAEj3AABJtAAASnEAAEsuAABL6wAATKgAAE1lAABOIgAA Tt8AAE+cAABQWQAAURYAAFHTAABSkAAAU00AAFQKAABUxwAAVYQAAFZBAABW/gAAV7sAAFh4AABZ NQAAWfIAAFqvAABbbAAAXCkAAFzmAABdowAAXmAAAF8dAABf2gAAYJcAAGFUAABiEQAAYs4AAGOL AABkSAAAZQUAAGXCAABmfwAAZzwAAGf5AABotgAAAxEAAAKLAAACSwAAAqUAAALDAAAB+QAAAfkA AAK9AAADUQAAAz0AAAN1AAADMAAAAjcAAAI2AAACuwAAAwsAAAI5AAACXgAAA4sAAAC9AAAAvQAA AL0AAAC9AAAAvQAAAL0AAAC9AAAAvQAAAL0AAAC9AAAAvQAAAL0AAAC9AAAAvQAAAL0AAAC9AAAA vQAAAL0AAAC9AAAAvQAAAL0AAAC9AAAAvQAAAL0AAAC9AAAAvQAAAL0AAAC9AAAAvQAAAL0AAAC9 AAAAvQAAAL0AAAC9AAAAvQAAAL0AAAC9AAAAvQAAAL0AAAC9AAAAvQAAAL0AAAC9AAAAvQAAAL0A AAC9AAAAvQAAAL0AAAC9AAAAvQAAAL0AAAC9AAAAvQAAAL0AAAC9AAAAvQAAAL0AAAC9AAAAvQAA AL0AAAC9AAAAvQAAAL0AAAC9AAAAvQAAAL0AAAC9AAAAvQAAAL0AAAC9AAAAvQAAAL0AAAC9AAF3 AAAAA+gAAXcAAAAD6P/bAEMAAgEBAgEBAgICAgICAgIDBQMDAwMDBgQEAwUHBgcHBwYHBwgJCwkI CAoIBwcKDQoKCwwMDAwHCQ4PDQwOCwwMDP/bAEMBAgICAwMDBgMDBgwIBwgMDAwMDAwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIABIAOQMBIgACEQEDEQH/ xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMA BBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVG R0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0 tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEB AQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2Fx EyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TF xsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/APZvGX7JHwf8Y/GH WYF/bw1iDV9X124iXT1u53eKeW5YC34uQGKu2zgAccAdKufG3/gmr4D/AGbvGUXh7x5+274m8K63 PZpfpZX8txHK0DvIiSAfavulopAD/sGucg/an/ZPb9qpNPj/AGbfEMHiD/hNDaJfvqhjWO8/tAoJ zHn5QJPn2dhxXt3/AAWM+Pf7P3wy/a70/Tfil8F9Y+IXiZ/Cdlcxapa6kbeOK0a7vljg2Z6q6TNn v5g9K+R9nh3SnU9y6a6ztr313P7K/tXiSlmmByyH1pQq0pS5fY4LnfKlZw93l5V15nzWtY900H9j Cx/aZ/4JU+H/AIV+Dvjp4i1CwuTHNafEPT5pZby8EOotcOoInV9oZWgx5vyqmOcYr8xv2Zf+CfXj P9o7/gor8WvgJJ+0H8UtIt/htaXFxFraaneyyX5iubeDDQ/awEyJieGP3RX7Hf8ABNzxZ4Q8b/sS eANW8BeFLvwR4SvbWd9P0W5YtJZr9qmDksfvB5A8gb+ISA96+E/+CZ0Mq/8ABw1+1S3kzBBpl/lz GwXnUrHbyRjnBx64OOlfrvCGa4jD5ZiYUpJKNNSjonaV4K6um9uj/M/ifxCwEavEMniFLmdeopXf LLebtJQagpX35dL6LQm13XPEXgj/AIOUPg94MHizxRd6JZeEfss1o+q3Is70x6Df/vJLfzDGzM6L Icg/MA2cgGvl/wDYc/bt8Wfs7/8ABZvW/wDhIfFPirUPAPizxzqvg/U4dQ1e5urKza5vZVs5FSWQ xxmOdYhkAYiaTHAxX0/8Vo5T/wAHVHwwPkz7P+EcnYv5TbAP7C1IZ3YxjOBnPU4618x/s5/sMap+ 35rX7bHgvQRbWfi+w8ZW2s+HbnUGltbaK7i1O/3o8oRmUSQPIuVBKs0bYO3B+wwcsIsN/taXJLD0 k3ppzTkub5Xv30PhsQsS66WHbvGtUaWuvLFO3z27XNX/AILEftyeKvin/wAFVND8N+FvE3ijSPCP w117S/DbDS9VubK3u9RN1FJdlxDIquy7liwwyPLcdDX7yV+A37cn7Evin9jH4bfs5Wfju5tta+Jf jz4rX3iXxTf2DyXcNxdT3dtsUSmNGc7cuSVB3TOAMAV+/NfL8WfVlhMHDC25Yqcbr7XLJJy+bu16 nvcPfWPrGJlib8zcXb+W62+XXzGOP3dIg4/E0UV8SfUCH73+fSlHKA9zRRUoQDiMfWhh8v1oopRL BO/tRRRVxJe5/9k= --_004_61f9d43ff2ca437788968983a9f39468TELMBXA05RM001telecomit_-- --_e5ffcfdd-fe02-4b9d-b721-c41579b10f57_ Content-Description: logo Ambiente_foglia2.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000003@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_e5ffcfdd-fe02-4b9d-b721-c41579b10f57_-- From nobody Thu May 5 07:36:19 2016 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 2D2C512DA1C; Thu, 5 May 2016 07:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w194R4fI-ccy; Thu, 5 May 2016 07:36:14 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB5E712DA25; Thu, 5 May 2016 07:28:23 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-0c-572b58864296 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 81.C8.12926.6885B275; Thu, 5 May 2016 16:28:22 +0200 (CEST) Received: from [159.107.198.150] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.3.248.2; Thu, 5 May 2016 16:28:21 +0200 To: Xufeng Liu , "'Joel M. Halpern'" , "'Tarek Saad (tsaad)'" , 'Martin Bjorklund' References: <4A05DD10-0885-435C-9D13-9634388B9F4B@cisco.com> <20160429.122943.1926404425708749601.mbj@tail-f.com> <50BEAA4E-C645-4DCE-A992-44B14B4EFC43@cisco.com> <01fc01d1a259$71cfae00$556f0a00$@gmail.com> From: Balazs Lengyel Message-ID: <243c1632-b802-7125-3335-096db431d560@ericsson.com> Date: Thu, 5 May 2016 16:28:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <01fc01d1a259$71cfae00$556f0a00$@gmail.com> Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM2J7uG5bhHa4wY5PfBYTD9hbfOp4yWLx 8dQbJovu7mfsFreWrmS1mH+xkdWi9ccOFotPJ34yWVw5/ofJgdNjyu+NrB47Z91l91iy5CeT x7kp3xk9Nv5azBLAGsVlk5Kak1mWWqRvl8CVMev0CpaCbxEVTbdPszQwHnPpYuTgkBAwkbi9 lK+LkRPIFJO4cG89WxcjF4eQwBFGiT9b57NDOGsYJQ50PWECqRIWcJJY93IrM0hCRGAFo8Sl 158ZIap6mSROLZ7NAuIwC3QwSry5s4YNpIVNwEhiav95FhCbV8Be4sGXR8wgu1kEVCQm/q8G CYsKREk8Ob2WGaJEUOLkzCdg5ZwCFhJb1pwGs5kF9CWu37nPCmHLSzRvnQ1WLySgIfHwwl/W CYyCs5C0z0LSMgtJywJG5lWMosWpxUm56UbGeqlFmcnFxfl5enmpJZsYgVFxcMtv1R2Ml984 HmIU4GBU4uFVWKkVLsSaWFZcmXuIUYKDWUmE93m4drgQb0piZVVqUX58UWlOavEhRmkOFiVx Xv+XiuFCAumJJanZqakFqUUwWSYOTqkGRoa9u8t9D8mrZZYVMy+Yf+t+8hXprRuL3iu0i09e 9TGXb8Era7UvrOfiwy6UPIrXElR2+XjQwWHB7qK7Py8/Ztgja7SHzTzgX+ec61ssWXZNTdNe fIJVYnPN/A8hLrox6tqTdtguamoOmnQyxvum33t9g6dJeRF1Iuv9czj1zNLsHlm++DErTIml OCPRUIu5qDgRAOAWiFWGAgAA Archived-At: Cc: draft-ietf-teas-yang-te@ietf.org, mpls@ietf.org, teas@ietf.org, netmod@ietf.org, draft-ietf-netmod-schema-mount@ietf.org Subject: Re: [Teas] [netmod] Use of schema mounts for common model X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 05 May 2016 14:36:18 -0000

Hello,

As I see it the problem is that as we don't know the mount relationships early. All you can say in the constraint is "point at some interface". So having a specific path statement is not feasible.

Using instance-identifiers may help. While it is hard it is not impossible to constrain instance-identifiers. You can put a regular expression on their "string" representation, e.g.  rematch(.,'/.*/interface[name=.*]')

 This would alow you to point at an interface anywhere (as long as the list is named interface with a key called name :-( ). Note the regexp is not 100% OK.
regards Balazs

On 2016-04-29 22:55, Xufeng Liu wrote:
We still hope that schema mount can handle cross-referencing across mounted
modules. It is also needed when ietf-interfaces model is mounted to
logical-network-element  and network-instance models.

More comments for this case below in-line.

Thanks,

- Xufeng


-----Original Message-----
From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Joel M. Halpern
Sent: Friday, April 29, 2016 1:05 PM
To: Tarek Saad (tsaad) <tsaad@cisco.com>; Martin Bjorklund

<mbj@tail-f.com>

Cc: draft-ietf-teas-yang-te@ietf.org; mpls@ietf.org; teas@ietf.org;
netmod@ietf.org; draft-ietf-netmod-schema-mount@ietf.org
Subject: Re: [Teas] [netmod] Use of schema mounts for common model

With regard to leafrefs trying to point into groupings, would

instance-identifiers

work for your use case?


In this case, it would be hard to specify the must conditions for these
instance-identifiers to make them always applicable when the groupings are
used in various situations. If we are willing to re-structure everything,
the method used in draft-halpern-supa-generic-policy-data-model could be an
option to explore. 


Yours,
Joel

On 4/29/16 12:17 PM, Tarek Saad (tsaad) wrote:

Thanks Martin, please see inline..


On 2016-04-29, 6:29 AM, "Martin Bjorklund" <mbj@tail-f.com
<mailto:mbj@tail-f.com>> wrote:

    "Tarek Saad (tsaad)" <tsaad@cisco.com <mailto:tsaad@cisco.com>>

wrote:

        Hi authors/WG,
        In draft-ietf-teas-yang-te, we are driving the definition for a
        generic TE YANG model that can/may be used (and extended when
        necessary) for different data plane technologies (e.g. MPLS,
        OTN, WDM,
        etc.).
        Reviewing the schema mount idea presented in
        draft-ietf-netmod-schema-mount, we are thinking this proposal is
        useful and can facilitate the reuse of the our model in multiple
        places in the YANG tree (once per each technology), e.g.:
        ./mpls/mount-points/mount-point/module=ietf-te.yang
        ./otn/mount-points/mount-point/module=ietf-te.yang


    Schema mount is probably not the right solution to your problem.  I
    think a better solution in your case is to define groupings.
    Groupings are designed to be re-used at different places in the
    hierarchy.


We thought of this earlier, and found groupings pose their own set of
challenges too.. Specifically:
- a groupings with leafrefs could not reference data nodes that reside
in another grouping
- a grouping with leafrefs of relative path were challenge when the
relative path references data nodes outside the grouping
- the augmentation of the grouping by other modules is not as
straightforward

That said, the grouping proposal seems to

one could also think that with groupings one could address reuse of
the a model (e.g. Ietf-interfaces) for logical devices or VM (see
below). In fact, in your draft (section 2) you explicitly discourage
this approach as not scalable solution


   With the "uses" approach, ietf-interfaces would have to define a
   grouping with all its nodes, and the new model for logical devices
   would have to use this grouping.  This is a not a scalable solution,
   since every time there is a new model defined, we would have to
   update our model for logical devices to use a grouping from the new
   model.  Another problem is that this approach cannot handle vendor-



        We have a comment/concern/suggestion and we value your feedback.
        The generic TE model currently references data nodes in the

global

        tree (e.g. from the ietf-interfaces model to define additional

TE

        properties associated with a specific device interface). Our
        understanding after reading section 3.1 of your draft is the

mounted

        model can *not* reference any data nodes outside the scope of

the

        mount-point (e.g. global data nodes in the yang tree). This

poses a

        limitation for us, do you have a suggestion for this problem?
        One possible solution we thought of was to replace the leaf-refs
        pointing to the global data nodes (e.g. Ietf-interfaces) with
        context
        names (e.g. the interface name).. This decouples the data-nodes
        defined in the TE generic model from those in the global tree
        (e.g. the actual interface ietf-interfaces model). Any feedback

on

        this or better suggestions?


In this case, there are multiple augmentations to ietf-te.yang, such as
ietf-rsvp-te and ietf-sr-te. If ietf-te is a grouping, we cannot do the
augmentations before ietf-te is used. Using the grouping would be very
awkward when ietf-te is used. We would have to make the same many
augmentations at that time. Even worse, there could be future augmentations,
we cannot specify these augmentations now because they are not defined yet.


    If you use groupings instead, you can still use proper leafrefs.


Not in all cases - as described above.

Regards,
Tarek



    /martin



        Regards,
        Tarek
        Excerpt from draft-ietf-netmod-schema-mount
        3.1<https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-

01#section-3.1>.

        Augment and Validation in Mounted Data
            All paths (in leafrefs, instance-identifiers, XPath
        expressions, and
            target nodes of augments) in the data models mounted at a
        mount point
            are interpreted with the mount point as the root node, and

the

            mounted data nodes as its children.  This means that data
        within a
            mounted subtree can never refer to data outside of this

subtree.




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


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

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



-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
From nobody Fri May 6 07:24:22 2016 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 B524712D61A for ; Fri, 6 May 2016 07:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2VnaezjkEfY for ; Fri, 6 May 2016 07:24:11 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CE8F12D60D for ; Fri, 6 May 2016 07:24:11 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u46EO9YE026507 for ; Fri, 6 May 2016 15:24:09 +0100 Received: from 950129200 ([92.207.169.18]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u46EO67V026419 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 6 May 2016 15:24:08 +0100 From: "Adrian Farrel" To: Date: Fri, 6 May 2016 15:24:02 +0100 Message-ID: <0c6c01d1a7a2$f1a24860$d4e6d920$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdGnosEWtnZGzgfkR5SQqz0Nm22cLQ== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22304.007 X-TM-AS-Result: No--22.896-10.0-31-10 X-imss-scan-details: No--22.896-10.0-31-10 X-TMASE-MatchedRID: IGdrTCYEWhFeqtHp15N9U1Pjo7D4SFg4QKuv8uQBDjr4JyR+b5tvoLuT SmkziLGEBA19C356nKoMo1U+ogv8V+QhIU5adD4PCFaAixm5eU9u/Xr6CKXiN7VhTD1Udgq8h3r xJ1Zk0E+ORNZGXn3P5ii6NtUf2AxdoqesYRoqSFkpa6LJktEjgLd2noO4P7rALraGNlLRahj2Rn Xgb9sKtMoLbse3mfomPYoc3x1xFgT3gr9T3KhP3gizXxlOHX34lnrMq7Sriu2dI/DikZ1UPN0HA AkfLxBxpmXcRoqbQErw6BX+s8AV64sN38OKtvda4bl1FkKDELczc8FC0MEwT0dMZyBoWgnkODUm 4pNxtIo2gANXtj6BAQNDWy0eadEVvQD12XFqHNMI8o+oRtTdk6APS3vFyaW62PljLKYGMfrdO1I Vye3Jy2epEVNLV6e/ECTq1hdYNfG4EooHfudG2oDqq/69HfgsD2lsxv9ktobM7zpEspqG//NvmS aCnjTlsBb3Q0HEUXwFnwbZRaSvqQzyMxeMEX6wOX/V8P8ail3InWAWA4yE6bazRqvlkBL0q7rFU cuGp/G8QIu4z6HhEH7cGd19dSFd Archived-At: Subject: [Teas] A New I-D on PCE as a central controller X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk 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, 06 May 2016 14:24:17 -0000 Hi, The idea of a "PCE-based central controller" has been bouncing around between PCE and TEAS for a bit. There have been plenty of use cases proposed and some protocol extension work. In Buenos Aires a group of us got together to try to work out where all this was going and how to structure the work to get more progress especially on the bits that some people are very keen to advance quickly. The result is this architecture document which we are targeting at TEAS. Originally intended to be very short and simple it has already grown a bit, but it is still a manageable read. Our idea is that the different use cases will result in a variety of distinct protocol extensions to PCEP that can be handled in separate documents in the PCE working group . This will allow different people to support different use cases and work on them at their own speed. Discussion is encouraged. Adrian (per pro "the team") > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: 06 May 2016 15:16 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-zhao-teas-pce-control-function-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : An Architecture for Use of PCE and PCEP in a Network with Central > Control > Authors : Adrian Farrel > Quintin Zhao > Robin Li > Chao Zhou > Filename : draft-zhao-teas-pce-control-function-00.txt > Pages : 21 > Date : 2016-05-06 > > Abstract: > The Path Computation Element (PCE) has become established as a core > component of Software Defined Networking (SDN) systems. It can > compute optimal paths for traffic across a network for any definition > of "optimal" and can also monitor changes in resource availability > and traffic demands to update the paths. > > Conventionally, the PCE has been used to derive paths for MPLS Label > Switched Paths (LSPs). These paths are supplied using the Path > Computation Element Communication Protocol (PCEP) to the head end of > the LSP for signaling in the MPLS network. > > SDN has a far broader applicability than just signaled MPLS traffic > engineered networks, and the PCE may be used to determine paths in a > wide range of use cases including static LSPs, segment routing, > service function chaining (SFC), and indeed any form of routed or > switched network. It is, therefore reasonable to consider PCEP as a > general southbound control protocol for use in these environments to > allow the PCE to be fully enabled as a central controller. > > This document briefly introduces the architecture for PCE as a > central controller, examines the motivations and applicability for > PCEP as a southbound interface, and introduces the implications for > the protocol. This document does not describe the use cases in > detail and does not define protocol extensions: that work is left for > other documents. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-zhao-teas-pce-control-function/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-zhao-teas-pce-control-function-00 > > > 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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon May 9 06:13:02 2016 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 2E7D712B00A for ; Mon, 9 May 2016 06:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLK8gpFG_4mS for ; Mon, 9 May 2016 06:12:58 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B821D12B030 for ; Mon, 9 May 2016 06:12:57 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id y84so200034135lfc.0 for ; Mon, 09 May 2016 06:12:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=XquDEk/2XPm5jm6o8GinI+2QcgrnMOEQosHg+bnURP0=; b=BOB/PjS0uXEBmvpeWhS88sxxROZiR52pdwi4M2Ti4G+veMHZAOlIAvKIdOZGBO5z+T lVkKEY1vbjaFjAY1Afwl7sgYxKCWDUHZrFHF60cg33yNhOybRgx1H3mL2poLDO8S4Ulh q4UTdW9xxINYFycFMn9naXtHcBH9fRj8uDEoxmuN5Idc3GISkU09KDamqE8xmI9O6eA0 ZUzRX7Yoq9xZ0m1JtM5yiR98W0k2kjcwQTm3PKjxFd51DuoITYOXUMESfAHAoub6VwEC pGpBVmp6c+GivdyxUmYoxRDwkXb+PXUvF+5PlsVxKyj1GAMXFI0OVsqrChF6ZaU+Yn2V D0lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=XquDEk/2XPm5jm6o8GinI+2QcgrnMOEQosHg+bnURP0=; b=YYXTpBVLdoJtovHtQNitm3XP/tYrAdXLj8SEx+5T9Y1v8LSnAnVe8fqibk48Q1XMR3 jmCTczlvU94MuP9s8VCQi2mHd93KkTaQlh5LO36bEzU1BMsAMfPAWF10yfiNFympm6Gw 2lC5Eh8LUXCGmB0IAe5VmU06/adrumyel71wxjZ+Z+CnOTGogchDqMfLZgigjjZ+Ct4C BZ7QNu+n/mRs+TfFxB26MR73GNorzaGhvDAEbd3QcCBSpBw2N65Mkm0lfZzFvDewSmaY 7JiwkvwSxbippSAVR7Vbt0FXNbKVLo/iLDe8e43CZ8Ue5aqJdiHbaAMLriapVERiwQTK NKwQ== X-Gm-Message-State: AOPr4FVdEbBGcp2Cvn4AY9dQokhiBF1Etp3xUe70rKNLmsW083X7F/Y/dBZsUMqKb/KjXw== X-Received: by 10.25.81.13 with SMTP id f13mr15662121lfb.78.1462799575791; Mon, 09 May 2016 06:12:55 -0700 (PDT) Received: from xliuus (wsip-98-191-72-170.dc.dc.cox.net. [98.191.72.170]) by smtp.gmail.com with ESMTPSA id zu7sm1643712lbb.11.2016.05.09.06.12.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 May 2016 06:12:55 -0700 (PDT) From: "Xufeng Liu" To: References: <01c301d1a251$ec05f880$c411e980$@gmail.com> In-Reply-To: <01c301d1a251$ec05f880$c411e980$@gmail.com> Date: Mon, 9 May 2016 09:12:54 -0400 Message-ID: <043101d1a9f4$80c4f1c0$824ed540$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQDNzFYbOgvt6IgPTakhw8AUAx1WMaG4TfFw Content-Language: en-us Archived-At: Subject: Re: [Teas] Multi-layer support in draft-ietf-teas-yang-te-topo X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 09 May 2016 13:13:00 -0000 - As discussions continued on multi-layer topology modeling, the following additional changes are planned: > Approach 1: Transitional link: - Model changes: Link attribute: add a flag for transitional. Model changes: augment /nw:networks/nw:network/nt:link: +--rw te! +--rw config | +--rw interface-switching-capability* [switching-capability] | | +--rw switching-capability identityref | | +--rw encoding? identityref | | +--rw max-lsp-bandwidth* [priority] | | | +--rw priority uint8 | | | +--rw bandwidth? decimal64 | | +--rw time-division-multiplex-capable | | | +--rw minimum-lsp-bandwidth? decimal64 | | | +--rw indication? enumeration + +--ro is-transitional? Empty > Approach 2: Inter layer lock: - Don't split node - Can be modeled as: augment /nw:networks/nw:network/nw:node: +--rw te! +--rw te-node-id te-node-id +--rw tunnel-termination-point* [tunnel-tp-id] +--rw tunnel-tp-id binary +--rw config | +--rw termination-capability* [link-tp] | +--rw link-tp leafref + | +--rw inter-layer-lock-id uint32 +--ro state +--ro termination-capability* [link-tp] | +--ro link-tp leafref + +--rw inter-layer-lock-id uint32 +--ro switching-capability identityref +--ro encoding identityref augment /nw:networks/nw:network/nw:node/nt:termination-point: +--rw te! +--rw te-tp-id te-tp-id +--rw config | +--rw schedules | | +--rw schedule* [schedule-id] | | +--rw schedule-id uint32 | | +--rw start? yang:date-and-time | | +--rw schedule-duration? string | | +--rw repeat-interval? string + | +--rw inter-layer-lock-id uint32 +--ro state +--ro schedules | +--ro schedule* [schedule-id] | +--ro schedule-id uint32 | +--ro start? yang:date-and-time | +--ro schedule-duration? string | +--ro repeat-interval? string + +--rw inter-layer-lock-id uint32 - TTP to support protection. Attribute to specify protection type that the TTP is capable of. (Identity will be use with values as described in RFC4427.) augment /nw:networks/nw:network/nw:node: +--rw te! +--rw tunnel-termination-point* [tunnel-tp-id] +--rw tunnel-tp-id binary +--rw config + | +--rw protection-type? identityref +--ro state + +--ro protection-type? identityref Thanks, - Xufeng > -----Original Message----- > From: Xufeng Liu [mailto:xufeng.liu.ietf@gmail.com] > Sent: Friday, April 29, 2016 4:01 PM > To: teas@ietf.org > Subject: Multi-layer support in draft-ietf-teas-yang-te-topo > > Authors and contributors are continuing discussions on multi-layer topology > modeling. > > Approach 1: Transitional link was presented in IETF95. Model changes are being > proposed: > Link TP: will need to have switch-layer > Link attribute: add a flag for transitional. > > Current: > > node 1 link node 2 > tp-1 ---- och ----> tp-2 > tp-1 <--- odu ----- tp-2 > > > augment /nw:networks/nw:network/nw:node/nt:termination-point: > +--rw te! > +--rw te-tp-id te-tp-id > +--rw config > | +--rw schedules > | +--rw schedule* [schedule-id] > | +--rw schedule-id uint32 > | +--rw start? yang:date-and-time > | +--rw schedule-duration? string > | +--rw repeat-interval? string > +--ro state > +--ro schedules > +--ro schedule* [schedule-id] > +--ro schedule-id uint32 > +--ro start? yang:date-and-time > +--ro schedule-duration? string > +--ro repeat-interval? string > > augment /nw:networks/nw:network/nt:link: > +--rw te! > +--rw config > | +--rw interface-switching-capability* [switching-capability] > | | +--rw switching-capability identityref > | | +--rw encoding? identityref > | | +--rw max-lsp-bandwidth* [priority] > | | | +--rw priority uint8 > | | | +--rw bandwidth? decimal64 > | | +--rw time-division-multiplex-capable > | | | +--rw minimum-lsp-bandwidth? decimal64 > | | | +--rw indication? enumeration > | | +--rw interface-adjustment-capability* [upper-sc] > | | +--rw upper-sc identityref > | | +--rw upper-encoding? identityref > | | +--rw max-lsp-bandwidth* [priority] > | | +--rw priority uint8 > | | +--rw bandwidth? decimal64 > > > To improve the model to handle uni-directional link, we suggest to add > switching-capability to TP: > > node 1 link node 2 > tp-1 ---- och ----> tp-2 > och odu > > tp-1 <--- odu ----- tp-2 > > > Model changes: > > augment /nw:networks/nw:network/nw:node/nt:termination-point: > +--rw te! > +--rw te-tp-id te-tp-id > +--rw config > | +--rw schedules > | | +--rw schedule* [schedule-id] > | | +--rw schedule-id uint32 > | | +--rw start? yang:date-and-time > | | +--rw schedule-duration? string > | | +--rw repeat-interval? string > + | +--rw interface-switching-capability* [switching-capability] > + | +--rw switching-capability identityref > + | +--rw encoding? identityref > + | +--rw max-lsp-bandwidth* [priority] > + | | +--rw priority uint8 > + | | +--rw bandwidth? decimal64 > + | +--rw time-division-multiplex-capable > + | | +--rw minimum-lsp-bandwidth? decimal64 > + | | +--rw indication? enumeration > - | +--rw interface-adjustment-capability* [upper-sc] > - | +--rw upper-sc identityref > - | +--rw upper-encoding? identityref > - | +--rw max-lsp-bandwidth* [priority] > - | +--rw priority uint8 > - | +--rw bandwidth? decimal64 > +--ro state > +--ro schedules > | +--ro schedule* [schedule-id] > | +--ro schedule-id uint32 > | +--ro start? yang:date-and-time > | +--ro schedule-duration? string > | +--ro repeat-interval? string > +--ro interface-switching-capability* [switching-capability] > ... > > augment /nw:networks/nw:network/nt:link: > +--rw te! > +--rw config > | +--rw interface-switching-capability* [switching-capability] > | | +--rw switching-capability identityref > | | +--rw encoding? identityref > | | +--rw max-lsp-bandwidth* [priority] > | | | +--rw priority uint8 > | | | +--rw bandwidth? decimal64 > | | +--rw time-division-multiplex-capable > | | | +--rw minimum-lsp-bandwidth? decimal64 > | | | +--rw indication? enumeration > - | | +--rw interface-adjustment-capability* [upper-sc] > - | | +--rw upper-sc identityref > - | | +--rw upper-encoding? identityref > - | | +--rw max-lsp-bandwidth* [priority] > - | | +--rw priority uint8 > - | | +--rw bandwidth? decimal64 > > > augment /nw:networks/nw:network/nw:node: > +--rw te! > +--rw tunnel-termination-point* [tunnel-tp-id] > +--rw tunnel-tp-id binary > +--rw config > | +--rw termination-capability* [link-tp] > | +--rw link-tp leafref > +--ro state > +--ro termination-capability* [link-tp] > | +--ro link-tp leafref > +--ro switching-capability identityref > +--ro encoding identityref > + +--rw max-lsp-bandwidth* [priority] > + +--rw priority uint8 > + +--rw bandwidth? decimal64 > > Because IACD is already covered by the relations between tunnel-termination- > point and link termination-point. We will remove the related section from link > attributes. The max-lsp-bandwidth section is to be added as above to complete > all necessary attributes for IACD. > > Authors are preparing further detailed descriptions and use case examples. The > proposed text and illustrations will be provided. > > Thanks, > > - Xufeng From nobody Mon May 9 08:44:33 2016 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 EC3D912D102; Mon, 9 May 2016 08:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJKj2NAS3PM3; Mon, 9 May 2016 08:44:25 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9BEE12D106; Mon, 9 May 2016 08:44:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31996; q=dns/txt; s=iport; t=1462808665; x=1464018265; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+BY36WFLPyXTIaaVciQbaoq0PzVPl18pzRXOKexCEOQ=; b=ejmeeD23tY4gYy/Tc2F1NZc7c7VPnVd+zuzJie8MKujUWUPu+1N2LNQy aYbH3RUmSww7rBlx24PtwPqNkBsTWQ6naJWmWdpMw9dpsgkSBiTX4RDRt sEid+8pUzRgRIaMov3dgJKH07GgZPJwnQf5cKrPzuQjetuICRY73ZTFGF g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AbAgDmrzBX/4wNJK1dgmxMVW4PBrh/A?= =?us-ascii?q?Q2BdhcBDIUiSgIcgRU4FAEBAQEBAQFlJ4RBAQEBBAEBASBLCxACAQgRAwECIQc?= =?us-ascii?q?DAgICJQsUCQgCBA4FCRKIEA6vEZBVAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYgg?= =?us-ascii?q?XYIgk6CNYFmOwkWgkorgi4FjV6FToR2AYV8iB+BaYRPiF+GKYkRAR4BAUKCBRu?= =?us-ascii?q?BS24Bh0cCHgcYAX4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,601,1454976000"; d="scan'208,217";a="270648733" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 May 2016 15:44:23 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u49FiN7r019060 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 9 May 2016 15:44:23 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 9 May 2016 11:44:22 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Mon, 9 May 2016 11:44:22 -0400 From: "Tarek Saad (tsaad)" To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" Thread-Topic: [netmod] Use of schema mounts for common model Thread-Index: AQHRoYTn8Q7ybSBq9EC0qN+9tgYLnp+hBBqAgAAeDQCABm+7AIAJPmKA Date: Mon, 9 May 2016 15:44:22 +0000 Message-ID: References: <4A05DD10-0885-435C-9D13-9634388B9F4B@cisco.com> <20160429.122943.1926404425708749601.mbj@tail-f.com> <50BEAA4E-C645-4DCE-A992-44B14B4EFC43@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.15.1.160411 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.213.203] Content-Type: multipart/alternative; boundary="_000_D5AA9261193D4100AF1581F4BF98654Cciscocom_" MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , Martin Bjorklund , "netmod@ietf.org" , "teas@ietf.org" , "draft-ietf-teas-yang-te@ietf.org" , "draft-ietf-netmod-schema-mount@ietf.org" Subject: Re: [Teas] [netmod] Use of schema mounts for common model X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 09 May 2016 15:44:28 -0000 --_000_D5AA9261193D4100AF1581F4BF98654Cciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpUaGFua3MuIFBsZWFzZSBzZWUgaW5saW5l4oCmDQoNCkZyb206ICJSb2Jl cnQgV2lsdG9uIC1YIChyd2lsdG9uIC0gRU5TT0ZUIExJTUlURUQgYXQgQ2lzY28pIiA8cndpbHRv bkBjaXNjby5jb208bWFpbHRvOnJ3aWx0b25AY2lzY28uY29tPj4NCkRhdGU6IFR1ZXNkYXksIE1h eSAzLCAyMDE2IGF0IDEwOjM0IEFNDQpUbzogVGFyZWsgU2FhZCA8dHNhYWRAY2lzY28uY29tPG1h aWx0bzp0c2FhZEBjaXNjby5jb20+Pg0KQ2M6IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYu Y29tPG1haWx0bzptYmpAdGFpbC1mLmNvbT4+LCAiZHJhZnQtaWV0Zi10ZWFzLXlhbmctdGVAaWV0 Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtdGVhcy15YW5nLXRlQGlldGYub3JnPiIgPGRyYWZ0LWll dGYtdGVhcy15YW5nLXRlQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLXRlYXMteWFuZy10ZUBp ZXRmLm9yZz4+LCAibXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4iIDxtcGxzQGll dGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPj4sICJuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5l dG1vZEBpZXRmLm9yZz4iIDxuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4+ LCAidGVhc0BpZXRmLm9yZzxtYWlsdG86dGVhc0BpZXRmLm9yZz4iIDx0ZWFzQGlldGYub3JnPG1h aWx0bzp0ZWFzQGlldGYub3JnPj4sICJkcmFmdC1pZXRmLW5ldG1vZC1zY2hlbWEtbW91bnRAaWV0 Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtbmV0bW9kLXNjaGVtYS1tb3VudEBpZXRmLm9yZz4iIDxk cmFmdC1pZXRmLW5ldG1vZC1zY2hlbWEtbW91bnRAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYt bmV0bW9kLXNjaGVtYS1tb3VudEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW25ldG1vZF0gVXNl IG9mIHNjaGVtYSBtb3VudHMgZm9yIGNvbW1vbiBtb2RlbA0KDQoNCkhpIFRhcmVrLA0KDQpJJ20g YWxzbyB3b25kZXJpbmcgd2hldGhlciB1c2luZyBzY2hlbWEgbW91bnQgaW4gdGhpcyB3YXkgbWln aHQgYmUgYSBiaXQgbGlrZSB1c2luZyBhIHNsZWRnZWhhbW1lciB0byBjcmFjayBhIG51dC4NCg0K V2l0aCBpbnRlcmZhY2VzLCB0aGVyZSBpcyBhIHBlciBkZXZpY2UgZ2xvYmFsIGxpc3Qgb2YgaW50 ZXJmYWNlcyB3aGVyZSBlYWNoIGxpc3QgZW50cnkgY2FuIGhhdmUgYSBkaWZmZXJlbnQgdHlwZSBh bmQgZGlmZmVyZW50IHByb3BlcnRpZXMuICBDdXJyZW50bHkgdGhlc2UgYXJlIHVzaW5nIHRoZSBp YW5hOmlmdHlwZSB0byBkaWZmZXJlbnRpYXRlIHRoZWlyIGRpZmZlcmVudCBzY2hlbWEgbW9kZXMs IGJ1dCB0aGVyZSBpcyBhbiBpZGVhIHRvIHVzZSBtb3JlIGFic3RyYWN0IGlkZW50aXRpZXMuDQoN CkknbSBub3QgcmVhbGx5IGZhbWlsaWFyIHdpdGggdGhlIHR1bm5lbCBZQU5HIG1vZGVscywgYnV0 IEkgd2FzIHdvbmRlcmluZyB3aGV0aGVyIHRoZSBzYW1lIGFwcHJvYWNoIGhhcyBiZWVuIGNvbnNp ZGVyZWQgZm9yIHRoZSBURSB0dW5uZWwgWUFORyBtb2RlbHMgYXQgYWxsPw0KDQpJLmUuIHJhdGhl ciB0aGFuIGhhdmluZyBhIHNlcGFyYXRlIHByb3RvY29sIGluc3RhbnRpYXRpb24gZm9yIGVhY2gg ZGlmZmVyZW50IGRhdGEgcGxhbmUgdGVjaG5vbG9neSwgaW5zdGVhZCBoYXZlIGEgcGVyIGRldmlj ZSBnbG9iYWwgbGlzdCBvZiB0dW5uZWxzIHRoYXQgaG9sZCB0aGUgY29uZmlndXJhdGlvbiBhbmQg b3BlcmF0aW9uYWwgc3RhdGUsIG1ha2luZyB1c2Ugb2Ygd2hlbiBzdGF0ZW1lbnRzIGFuZCBpZGVu dGl0aWVzIChpZiByZXF1aXJlZCkgdG8gbWFuYWdlIGRhdGFwbGFuZSBzcGVjaWZpYyBsZWF2ZXMu ICBFYWNoIHByb3RvY29sIHNwZWNpZmljIGRhdGEgcGxhbmUgbW9kdWxlIGNvdWxkIGFsc28gbWFp bnRhaW4gYSBwcm90b2NvbCBzcGVjaWZpYyBsaXN0IGNvbnRhaW5pbmcgbGVhZi1yZWZzIGJhY2sg dG8gdGhlIGFwcHJvcHJpYXRlIHR1bm5lbHMgaW4gdGhlIG1hc3RlciBsaXN0Lg0KDQpbVFNdOiBD dXJyZW50bHkgdGhlIFRFIHR1bm5lbCBtb2RlbCBoYXMgYSBnbG9iYWwgbGlzdCBvZiBpbnRlcmZh Y2VzLiBUaGUgdGVhbSBoYXMgZGlzY3Vzc2VkIHRoZSBpZGVhIG9mIGNvbnRpbnVpbmcgdG8gaGF2 ZSBhIHNpbmdsZSBnbG9iYWwgbGlzdCBhbmQgdGhlbiBhc3NpZ25pbmcgdGhlIHR1bm5lbCB0ZWNo bm9sb2d5IHR5cGUgb24gcGVyIHR1bm5lbC4gVGhpcyBpbXBsaWNhdGVzIHRoZSBmb2xsb3dpbmc6 DQoNCiAgMS4gIFRoZXJlIHdpbGwgYmUgMSBmdWxsIGxpc3Qgb2YgVEUgdHVubmVscyBmb3IgYWxs IHRlY2hub2xvZ3kgdHlwZXMuIFRoZSBsaXN0IHdpbGwgYmUga2V5ZWQgYnkgeyh0dW5uZWwgbmFt ZSkrKHR1bm5lbC10ZWNobm9sb2d5LXR5cGUpfS4gT24gbm9kZXMgdGhhdCBtYXkgc3VwcG9ydCBt dWx0aXBsZSB0ZWNobm9sb2d5IHR5cGVzIChlLmcuIFBhY2tldCBhbmQgb3B0aWNhbCksIHRoZSB0 dW5uZWxzL0xTUHMgZm9yIG11bHRpcGxlIHRlY2hub2xvZ2llcyB3aWxsIGJlIGludGVybWl4ZWQg aW4gdGhlIHNhbWUgbGlzdC4NCiAgMi4gIFRoZSBzYW1lIGdvZXMgZm9yIHRoZSBsaXN0IG9mIExT UHMgKGluc3RhbnRpYXRpb25zIG9mIHR1bm5lbHMgb24gaW5ncmVzcy90cmFuc2l0L2VncmVzcyBu b2Rlcy4uIEluIHRoaXMgY2FzZSwgc3VjaCBMU1BzIG9mIGRpZmZlcmVudCB0ZWNobm9sb2d5IHBh cnRzIHdpbGwgYmUgaW50ZXJtaXhlZCB0b28uDQoNClRoaXMgaXMgcG9zc2libGUsIGJ1dCBtYXkg bm90IGJlIG1vc3QgZWxlZ2FudCB3YXkgb2YgcHJlc2VudGluZyB0aGlzLi4gV2Ugd2VyZSBob3Bp bmcgaXQgd2lsbCBiZSBwb3NzaWJsZSB0byBoYXZlIHRoZSBzZWdyZWdhdGlvbiBvbiBwZXIgdGVj aG5vbG9neSBieSBtb3VudGluZyB0aGUgdHVubmVsIGxpc3QgdW5kZXIgdGhlIHJlc3BlY3RpdmUg dGVjaG5vbG9neSAocGFja2V0LCBvdG4sIGV0Yy4pLi4NCkxhc3RseSwgcGxheWluZyBkZXZpbOKA mXMgYWR2b2NhdGUgOiksIG9uZSBjb3VsZCBhcmd1ZSBpdOKAmXMgYWxzbyBwb3NzaWJsZSB0byBo YXZlIG9uZSBnbG9iYWwgbGlzdCBvZiBpbnRlcmZhY2VzIGluIHRoZSBpbnRlcmZhY2VzIG1vZGVs IGFuZCBtYWtlIHRoZSBkZXZpY2UvVk0gYW4gYXR0cmlidXRlIChhbmQgcGFydCBvZiB0aGUga2V5 KSBvZiB0aGUgaW50ZXJmYWNlIGxpc3QuLiBUaGF0IGlzIGFuIGludGVyZmFjZSBuYW1lIGZvbyBj YW4gYXBwZWFyIG11bHRpcGxlIHRpbWVzIGluIHRoZSBpbnRlcmZhY2UgbGlzdCAob25jZSBwZXIg Vk0gb3IgcGh5c2ljYWwpLi4gT2YgY291cnNlLCBJTU8gdGhlIG1vdW50aW5nIHByb3Bvc2FsIGlz IG1vcmUgZWxlZ2FudCBpbiB0aGlzIGNhc2UuLg0KDQpSZWdhcmRzLA0KVGFyZWsNCg0KDQpUaGFu a3MsDQpSb2INCg0KDQpPbiAyOS8wNC8yMDE2IDE3OjE3LCBUYXJlayBTYWFkICh0c2FhZCkgd3Jv dGU6DQpUaGFua3MgTWFydGluLCBwbGVhc2Ugc2VlIGlubGluZS4uDQoNCg0KT24gMjAxNi0wNC0y OSwgNjoyOSBBTSwgIk1hcnRpbiBCam9ya2x1bmQiIDw8bWFpbHRvOm1iakB0YWlsLWYuY29tPm1i akB0YWlsLWYuY29tPG1haWx0bzptYmpAdGFpbC1mLmNvbT4+IHdyb3RlOg0KDQoiVGFyZWsgU2Fh ZCAodHNhYWQpIiA8dHNhYWRAY2lzY28uY29tPG1haWx0bzp0c2FhZEBjaXNjby5jb20+PiB3cm90 ZToNCkhpIGF1dGhvcnMvV0csDQpJbiBkcmFmdC1pZXRmLXRlYXMteWFuZy10ZSwgd2UgYXJlIGRy aXZpbmcgdGhlIGRlZmluaXRpb24gZm9yIGENCmdlbmVyaWMgVEUgWUFORyBtb2RlbCB0aGF0IGNh bi9tYXkgYmUgdXNlZCAoYW5kIGV4dGVuZGVkIHdoZW4NCm5lY2Vzc2FyeSkgZm9yIGRpZmZlcmVu dCBkYXRhIHBsYW5lIHRlY2hub2xvZ2llcyAoZS5nLiBNUExTLCBPVE4sIFdETSwNCmV0Yy4pLg0K UmV2aWV3aW5nIHRoZSBzY2hlbWEgbW91bnQgaWRlYSBwcmVzZW50ZWQgaW4NCmRyYWZ0LWlldGYt bmV0bW9kLXNjaGVtYS1tb3VudCwgd2UgYXJlIHRoaW5raW5nIHRoaXMgcHJvcG9zYWwgaXMNCnVz ZWZ1bCBhbmQgY2FuIGZhY2lsaXRhdGUgdGhlIHJldXNlIG9mIHRoZSBvdXIgbW9kZWwgaW4gbXVs dGlwbGUNCnBsYWNlcyBpbiB0aGUgWUFORyB0cmVlIChvbmNlIHBlciBlYWNoIHRlY2hub2xvZ3kp LCBlLmcuOg0K4oCmL21wbHMvbW91bnQtcG9pbnRzL21vdW50LXBvaW50L21vZHVsZT1pZXRmLXRl LnlhbmcNCuKApi9vdG4vbW91bnQtcG9pbnRzL21vdW50LXBvaW50L21vZHVsZT1pZXRmLXRlLnlh bmcNCg0KU2NoZW1hIG1vdW50IGlzIHByb2JhYmx5IG5vdCB0aGUgcmlnaHQgc29sdXRpb24gdG8g eW91ciBwcm9ibGVtLiAgSQ0KdGhpbmsgYSBiZXR0ZXIgc29sdXRpb24gaW4geW91ciBjYXNlIGlz IHRvIGRlZmluZSBncm91cGluZ3MuDQpHcm91cGluZ3MgYXJlIGRlc2lnbmVkIHRvIGJlIHJlLXVz ZWQgYXQgZGlmZmVyZW50IHBsYWNlcyBpbiB0aGUNCmhpZXJhcmNoeS4NCg0KV2UgdGhvdWdodCBv ZiB0aGlzIGVhcmxpZXIsIGFuZCBmb3VuZCBncm91cGluZ3MgcG9zZSB0aGVpciBvd24gc2V0IG9m IGNoYWxsZW5nZXMgdG9vLi4gU3BlY2lmaWNhbGx5Og0KLSBhIGdyb3VwaW5ncyB3aXRoIGxlYWZy ZWZzIGNvdWxkIG5vdCByZWZlcmVuY2UgZGF0YSBub2RlcyB0aGF0IHJlc2lkZSBpbiBhbm90aGVy IGdyb3VwaW5nDQotIGEgZ3JvdXBpbmcgd2l0aCBsZWFmcmVmcyBvZiByZWxhdGl2ZSBwYXRoIHdl cmUgY2hhbGxlbmdlIHdoZW4gdGhlIHJlbGF0aXZlIHBhdGggcmVmZXJlbmNlcyBkYXRhIG5vZGVz IG91dHNpZGUgdGhlIGdyb3VwaW5nDQotIHRoZSBhdWdtZW50YXRpb24gb2YgdGhlIGdyb3VwaW5n IGJ5IG90aGVyIG1vZHVsZXMgaXMgbm90IGFzIHN0cmFpZ2h0Zm9yd2FyZA0KDQpUaGF0IHNhaWQs IHRoZSBncm91cGluZyBwcm9wb3NhbCBzZWVtcyB0bw0KDQpvbmUgY291bGQgYWxzbyB0aGluayB0 aGF0IHdpdGggZ3JvdXBpbmdzIG9uZSBjb3VsZCBhZGRyZXNzIHJldXNlIG9mIHRoZSBhIG1vZGVs IChlLmcuIElldGYtaW50ZXJmYWNlcykgZm9yIGxvZ2ljYWwgZGV2aWNlcyBvciBWTSAoc2VlIGJl bG93KS4gSW4gZmFjdCwgaW4geW91ciBkcmFmdCAoc2VjdGlvbiAyKSB5b3UgZXhwbGljaXRseSBk aXNjb3VyYWdlIHRoaXMgYXBwcm9hY2ggYXMgbm90IHNjYWxhYmxlIHNvbHV0aW9uDQoNCg0KICAg V2l0aCB0aGUgInVzZXMiIGFwcHJvYWNoLCBpZXRmLWludGVyZmFjZXMgd291bGQgaGF2ZSB0byBk ZWZpbmUgYQ0KICAgZ3JvdXBpbmcgd2l0aCBhbGwgaXRzIG5vZGVzLCBhbmQgdGhlIG5ldyBtb2Rl bCBmb3IgbG9naWNhbCBkZXZpY2VzDQogICB3b3VsZCBoYXZlIHRvIHVzZSB0aGlzIGdyb3VwaW5n LiAgVGhpcyBpcyBhIG5vdCBhIHNjYWxhYmxlIHNvbHV0aW9uLA0KICAgc2luY2UgZXZlcnkgdGlt ZSB0aGVyZSBpcyBhIG5ldyBtb2RlbCBkZWZpbmVkLCB3ZSB3b3VsZCBoYXZlIHRvDQogICB1cGRh dGUgb3VyIG1vZGVsIGZvciBsb2dpY2FsIGRldmljZXMgdG8gdXNlIGEgZ3JvdXBpbmcgZnJvbSB0 aGUgbmV3DQogICBtb2RlbC4gIEFub3RoZXIgcHJvYmxlbSBpcyB0aGF0IHRoaXMgYXBwcm9hY2gg Y2Fubm90IGhhbmRsZSB2ZW5kb3ItDQoNCg0KDQpXZSBoYXZlIGEgY29tbWVudC9jb25jZXJuL3N1 Z2dlc3Rpb24gYW5kIHdlIHZhbHVlIHlvdXIgZmVlZGJhY2suDQpUaGUgZ2VuZXJpYyBURSBtb2Rl bCBjdXJyZW50bHkgcmVmZXJlbmNlcyBkYXRhIG5vZGVzIGluIHRoZSBnbG9iYWwNCnRyZWUgKGUu Zy4gZnJvbSB0aGUgaWV0Zi1pbnRlcmZhY2VzIG1vZGVsIHRvIGRlZmluZSBhZGRpdGlvbmFsIFRF DQpwcm9wZXJ0aWVzIGFzc29jaWF0ZWQgd2l0aCBhIHNwZWNpZmljIGRldmljZSBpbnRlcmZhY2Up LiBPdXINCnVuZGVyc3RhbmRpbmcgYWZ0ZXIgcmVhZGluZyBzZWN0aW9uIDMuMSBvZiB5b3VyIGRy YWZ0IGlzIHRoZSBtb3VudGVkDQptb2RlbCBjYW4gKm5vdCogcmVmZXJlbmNlIGFueSBkYXRhIG5v ZGVzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoZQ0KbW91bnQtcG9pbnQgKGUuZy4gZ2xvYmFsIGRh dGEgbm9kZXMgaW4gdGhlIHlhbmcgdHJlZSkuIFRoaXMgcG9zZXMgYQ0KbGltaXRhdGlvbiBmb3Ig dXMsIGRvIHlvdSBoYXZlIGEgc3VnZ2VzdGlvbiBmb3IgdGhpcyBwcm9ibGVtPw0KT25lIHBvc3Np YmxlIHNvbHV0aW9uIHdlIHRob3VnaHQgb2Ygd2FzIHRvIHJlcGxhY2UgdGhlIGxlYWYtcmVmcw0K cG9pbnRpbmcgdG8gdGhlIGdsb2JhbCBkYXRhIG5vZGVzIChlLmcuIElldGYtaW50ZXJmYWNlcykg d2l0aCBjb250ZXh0DQpuYW1lcyAoZS5nLiB0aGUgaW50ZXJmYWNlIG5hbWUpLi4gVGhpcyBkZWNv dXBsZXMgdGhlIGRhdGEtbm9kZXMNCmRlZmluZWQgaW4gdGhlIFRFIGdlbmVyaWMgbW9kZWwgZnJv bSB0aG9zZSBpbiB0aGUgZ2xvYmFsIHRyZWUNCihlLmcuIHRoZSBhY3R1YWwgaW50ZXJmYWNlIGll dGYtaW50ZXJmYWNlcyBtb2RlbCkuIEFueSBmZWVkYmFjayBvbg0KdGhpcyBvciBiZXR0ZXIgc3Vn Z2VzdGlvbnM/DQoNCklmIHlvdSB1c2UgZ3JvdXBpbmdzIGluc3RlYWQsIHlvdSBjYW4gc3RpbGwg dXNlIHByb3BlciBsZWFmcmVmcy4NCg0KTm90IGluIGFsbCBjYXNlcyDigJQgYXMgZGVzY3JpYmVk IGFib3ZlLg0KDQpSZWdhcmRzLA0KVGFyZWsNCg0KDQoNCi9tYXJ0aW4NCg0KDQoNClJlZ2FyZHMs DQpUYXJlaw0KRXhjZXJwdCBmcm9tIGRyYWZ0LWlldGYtbmV0bW9kLXNjaGVtYS1tb3VudA0KMy4x PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldG1vZC1zY2hlbWEtbW91 bnQtMDEjc2VjdGlvbi0zLjE+Lg0KQXVnbWVudCBhbmQgVmFsaWRhdGlvbiBpbiBNb3VudGVkIERh dGENCiAgICBBbGwgcGF0aHMgKGluIGxlYWZyZWZzLCBpbnN0YW5jZS1pZGVudGlmaWVycywgWFBh dGggZXhwcmVzc2lvbnMsIGFuZA0KICAgIHRhcmdldCBub2RlcyBvZiBhdWdtZW50cykgaW4gdGhl IGRhdGEgbW9kZWxzIG1vdW50ZWQgYXQgYSBtb3VudCBwb2ludA0KICAgIGFyZSBpbnRlcnByZXRl ZCB3aXRoIHRoZSBtb3VudCBwb2ludCBhcyB0aGUgcm9vdCBub2RlLCBhbmQgdGhlDQogICAgbW91 bnRlZCBkYXRhIG5vZGVzIGFzIGl0cyBjaGlsZHJlbi4gIFRoaXMgbWVhbnMgdGhhdCBkYXRhIHdp dGhpbiBhDQogICAgbW91bnRlZCBzdWJ0cmVlIGNhbiBuZXZlciByZWZlciB0byBkYXRhIG91dHNp ZGUgb2YgdGhpcyBzdWJ0cmVlLg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3Jn PG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRtb2QNCg0K --_000_D5AA9261193D4100AF1581F4BF98654Cciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0K PGRpdj4NCjxkaXY+SGkgUm9iZXJ0LDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhh bmtzLiBQbGVhc2Ugc2VlIGlubGluZeKApjwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9Ik1BQ19PVVRM T09LX1NJR05BVFVSRSI+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Zm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlf U0VDVElPTiIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OkNhbGlicmk7IGZvbnQtc2l6ZToxMnB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBC T1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURE SU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBC T1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsg UEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTog PC9zcGFuPiZxdW90O1JvYmVydCBXaWx0b24gLVggKHJ3aWx0b24gLSBFTlNPRlQgTElNSVRFRCBh dCBDaXNjbykmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbSI+cndp bHRvbkBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5EYXRlOiA8L3NwYW4+VHVlc2RheSwgTWF5IDMsIDIwMTYgYXQgMTA6MzQgQU08YnI+DQo8c3Bh biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5UYXJlayBTYWFkICZsdDs8YSBo cmVmPSJtYWlsdG86dHNhYWRAY2lzY28uY29tIj50c2FhZEBjaXNjby5jb208L2E+Jmd0Ozxicj4N CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPk1hcnRpbiBCam9ya2x1 bmQgJmx0OzxhIGhyZWY9Im1haWx0bzptYmpAdGFpbC1mLmNvbSI+bWJqQHRhaWwtZi5jb208L2E+ Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtdGVhcy15YW5nLXRlQGlldGYu b3JnIj5kcmFmdC1pZXRmLXRlYXMteWFuZy10ZUBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzpkcmFmdC1pZXRmLXRlYXMteWFuZy10ZUBpZXRmLm9yZyI+ZHJhZnQtaWV0Zi10 ZWFzLXlhbmctdGVAaWV0Zi5vcmc8L2E+Jmd0OywNCiAmcXVvdDs8YSBocmVmPSJtYWlsdG86bXBs c0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpt cGxzQGlldGYub3JnIj5tcGxzQGlldGYub3JnPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0 bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9 Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8 YSBocmVmPSJtYWlsdG86dGVhc0BpZXRmLm9yZyI+dGVhc0BpZXRmLm9yZzwvYT4mcXVvdDsNCiAm bHQ7PGEgaHJlZj0ibWFpbHRvOnRlYXNAaWV0Zi5vcmciPnRlYXNAaWV0Zi5vcmc8L2E+Jmd0Oywg JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtbmV0bW9kLXNjaGVtYS1tb3VudEBpZXRm Lm9yZyI+ZHJhZnQtaWV0Zi1uZXRtb2Qtc2NoZW1hLW1vdW50QGlldGYub3JnPC9hPiZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtbmV0bW9kLXNjaGVtYS1tb3VudEBpZXRmLm9y ZyI+ZHJhZnQtaWV0Zi1uZXRtb2Qtc2NoZW1hLW1vdW50QGlldGYub3JnPC9hPiZndDs8YnI+DQo8 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbbmV0bW9k XSBVc2Ugb2Ygc2NoZW1hIG1vdW50cyBmb3IgY29tbW9uIG1vZGVsPGJyPg0KPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k eSI+DQo8ZGl2Pg0KPGRpdiBiZ2NvbG9yPSIjRkZGRkZGIiB0ZXh0PSIjMDAwMDAwIj4NCjxwPkhp IFRhcmVrLDxicj4NCjwvcD4NCjxwPkknbSBhbHNvIHdvbmRlcmluZyB3aGV0aGVyIHVzaW5nIHNj aGVtYSBtb3VudCBpbiB0aGlzIHdheSBtaWdodCBiZSBhIGJpdCBsaWtlIHVzaW5nIGEgc2xlZGdl aGFtbWVyIHRvIGNyYWNrIGEgbnV0LjwvcD4NCjxwPldpdGggaW50ZXJmYWNlcywgdGhlcmUgaXMg YSBwZXIgZGV2aWNlIGdsb2JhbCBsaXN0IG9mIGludGVyZmFjZXMgd2hlcmUgZWFjaCBsaXN0IGVu dHJ5IGNhbiBoYXZlIGEgZGlmZmVyZW50IHR5cGUgYW5kIGRpZmZlcmVudCBwcm9wZXJ0aWVzLiZu YnNwOyBDdXJyZW50bHkgdGhlc2UgYXJlIHVzaW5nIHRoZSBpYW5hOmlmdHlwZSB0byBkaWZmZXJl bnRpYXRlIHRoZWlyIGRpZmZlcmVudCBzY2hlbWEgbW9kZXMsIGJ1dCB0aGVyZSBpcyBhbiBpZGVh IHRvIHVzZQ0KIG1vcmUgYWJzdHJhY3QgaWRlbnRpdGllcy48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9zcGFuPjwvc3Bhbj48c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iIHN0eWxlPSJjb2xv cjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1z aXplOiAxNHB4OyI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ DQo8ZGl2Pg0KPGRpdiBiZ2NvbG9yPSIjRkZGRkZGIiB0ZXh0PSIjMDAwMDAwIj4NCjxwPkknbSBu b3QgcmVhbGx5IGZhbWlsaWFyIHdpdGggdGhlIHR1bm5lbCBZQU5HIG1vZGVscywgYnV0IEkgd2Fz IHdvbmRlcmluZyB3aGV0aGVyIHRoZSBzYW1lIGFwcHJvYWNoIGhhcyBiZWVuIGNvbnNpZGVyZWQg Zm9yIHRoZSBURSB0dW5uZWwgWUFORyBtb2RlbHMgYXQgYWxsPzwvcD4NCjxwPkkuZS4gcmF0aGVy IHRoYW4gaGF2aW5nIGEgc2VwYXJhdGUgcHJvdG9jb2wgaW5zdGFudGlhdGlvbiBmb3IgZWFjaCBk aWZmZXJlbnQgZGF0YSBwbGFuZSB0ZWNobm9sb2d5LCBpbnN0ZWFkIGhhdmUgYSBwZXIgZGV2aWNl IGdsb2JhbCBsaXN0IG9mIHR1bm5lbHMgdGhhdCBob2xkIHRoZSBjb25maWd1cmF0aW9uIGFuZCBv cGVyYXRpb25hbCBzdGF0ZSwgbWFraW5nIHVzZSBvZiB3aGVuIHN0YXRlbWVudHMgYW5kIGlkZW50 aXRpZXMgKGlmIHJlcXVpcmVkKQ0KIHRvIG1hbmFnZSBkYXRhcGxhbmUgc3BlY2lmaWMgbGVhdmVz LiZuYnNwOyBFYWNoIHByb3RvY29sIHNwZWNpZmljIGRhdGEgcGxhbmUgbW9kdWxlIGNvdWxkIGFs c28gbWFpbnRhaW4gYSBwcm90b2NvbCBzcGVjaWZpYyBsaXN0IGNvbnRhaW5pbmcgbGVhZi1yZWZz IGJhY2sgdG8gdGhlIGFwcHJvcHJpYXRlIHR1bm5lbHMgaW4gdGhlIG1hc3RlciBsaXN0LjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+PC9zcGFuPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImNvbG9y OiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNp emU6IDE0cHg7Ij4NCjxiPjxpPltUU106IEN1cnJlbnRseSB0aGUgVEUgdHVubmVsIG1vZGVsIGhh cyBhIGdsb2JhbCBsaXN0IG9mIGludGVyZmFjZXMuIFRoZSB0ZWFtIGhhcyBkaXNjdXNzZWQgdGhl IGlkZWEgb2YgY29udGludWluZyB0byBoYXZlIGEgc2luZ2xlIGdsb2JhbCBsaXN0IGFuZCB0aGVu IGFzc2lnbmluZyB0aGUgdHVubmVsIHRlY2hub2xvZ3kgdHlwZSBvbiBwZXIgdHVubmVsLiBUaGlz IGltcGxpY2F0ZXMgdGhlIGZvbGxvd2luZzo8L2k+PC9iPjwvZGl2Pg0KPG9sPg0KPGxpIHN0eWxl PSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Zm9udC1zaXplOiAxNHB4OyI+DQo8Yj48aT5UaGVyZSB3aWxsIGJlIDEgZnVsbCBsaXN0IG9mIFRF IHR1bm5lbHMgZm9yIGFsbCB0ZWNobm9sb2d5IHR5cGVzLiBUaGUgbGlzdCB3aWxsIGJlIGtleWVk IGJ5IHsodHVubmVsIG5hbWUpJiM0MzsodHVubmVsLXRlY2hub2xvZ3ktdHlwZSl9LiBPbiBub2Rl cyB0aGF0IG1heSBzdXBwb3J0IG11bHRpcGxlIHRlY2hub2xvZ3kgdHlwZXMgKGUuZy4gUGFja2V0 IGFuZCBvcHRpY2FsKSwgdGhlIHR1bm5lbHMvTFNQcyBmb3IgbXVsdGlwbGUgdGVjaG5vbG9naWVz DQogd2lsbCBiZSBpbnRlcm1peGVkIGluIHRoZSBzYW1lIGxpc3QuPC9pPjwvYj48L2xpPjxsaT48 Yj48aT48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPlRoZSBzYW1lIGdvZXMgZm9yIHRo ZSBsaXN0IG9mIExTUHMgKGluc3RhbnRpYXRpb25zIG9mIHR1bm5lbHMgb24gaW5ncmVzcy90cmFu c2l0L2VncmVzcyBub2Rlcy4uIEluIHRoaXMgY2FzZSwgc3VjaCBMU1BzIG9mIGRpZmZlcmVudCB0 ZWNobm9sb2d5IHBhcnRzIHdpbGwgYmUgaW50ZXJtaXhlZCB0b28uPC9mb250PjwvaT48L2I+PC9s aT48L29sPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGI+PGk+VGhpcyBpcyBwb3Nz aWJsZSwgYnV0IG1heSBub3QgYmUgbW9zdCBlbGVnYW50IHdheSBvZiBwcmVzZW50aW5nIHRoaXMu LiBXZSB3ZXJlIGhvcGluZyBpdCB3aWxsIGJlIHBvc3NpYmxlIHRvIGhhdmUgdGhlIHNlZ3JlZ2F0 aW9uIG9uIHBlciB0ZWNobm9sb2d5IGJ5IG1vdW50aW5nIHRoZSB0dW5uZWwgbGlzdCB1bmRlciB0 aGUgcmVzcGVjdGl2ZSB0ZWNobm9sb2d5IChwYWNrZXQsIG90biwgZXRjLikuLjwvaT48L2I+PC9k aXY+DQo8ZGl2PjxiPjxpPjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+TGFzdGx5LCBw bGF5aW5nIGRldmls4oCZcyBhZHZvY2F0ZSA6KSwgb25lIGNvdWxkIGFyZ3VlIGl04oCZcyBhbHNv IHBvc3NpYmxlIHRvIGhhdmUgb25lIGdsb2JhbCBsaXN0IG9mIGludGVyZmFjZXMgaW4gdGhlIGlu dGVyZmFjZXMgbW9kZWwgYW5kIG1ha2UgdGhlIGRldmljZS9WTSBhbiBhdHRyaWJ1dGUgKGFuZCBw YXJ0IG9mIHRoZSBrZXkpIG9mIHRoZSBpbnRlcmZhY2UgbGlzdC4uDQogVGhhdCBpcyBhbiBpbnRl cmZhY2UgbmFtZSBmb28gY2FuIGFwcGVhciBtdWx0aXBsZSB0aW1lcyBpbiB0aGUgaW50ZXJmYWNl IGxpc3QgKG9uY2UgcGVyIFZNIG9yIHBoeXNpY2FsKS4uIE9mIGNvdXJzZSwgSU1PIHRoZSBtb3Vu dGluZyBwcm9wb3NhbCBpcyBtb3JlIGVsZWdhbnQgaW4gdGhpcyBjYXNlLi4mbmJzcDs8L2ZvbnQ+ PC9pPjwvYj48L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxiPjxpPjxicj4N CjwvaT48L2I+PC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8Yj48aT5SZWdh cmRzLDwvaT48L2I+PC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8Yj48aT5U YXJlazwvaT48L2I+PC9kaXY+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElP TiIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWxCb2R5Ij4NCjxkaXY+DQo8ZGl2IGJnY29sb3I9IiNGRkZGRkYiIHRleHQ9IiMwMDAw MDAiPg0KPHA+PGJyPg0KPC9wPg0KPHA+VGhhbmtzLDxicj4NClJvYjwvcD4NCjxwPjxicj4NCjwv cD4NCjxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+T24gMjkvMDQvMjAxNiAxNzoxNywgVGFy ZWsgU2FhZCAodHNhYWQpIHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2l0ZT0ibWlk OjUwQkVBQTRFLUM2NDUtNERDRS1BOTkyLTQ0QjE0QjRFRkM0M0BjaXNjby5jb20iIHR5cGU9ImNp dGUiPg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyBmb250LWZhbWlseTogQ29uc29sYXMs IG1vbm9zcGFjZTsiPg0KPGRpdj5UaGFua3MgTWFydGluLCBwbGVhc2Ugc2VlIGlubGluZS4uPC9k aXY+DQo8ZGl2Pg0KPGRpdiBpZD0iIj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHg7IGZvbnQtZmFtaWx5OiBDb25z b2xhcywgbW9ub3NwYWNlOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEy cHg7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgbW9ub3NwYWNlOyI+T24gMjAxNi0wNC0yOSwgNjoy OSBBTSwgJnF1b3Q7TWFydGluIEJqb3JrbHVuZCZxdW90OyAmbHQ7PGEgbW96LWRvLW5vdC1zZW5k PSJ0cnVlIiBocmVmPSJtYWlsdG86bWJqQHRhaWwtZi5jb20iPjwvYT48YSBjbGFzcz0ibW96LXR4 dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86bWJqQHRhaWwtZi5jb20iPm1iakB0YWls LWYuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHg7 IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgbW9ub3NwYWNlOyI+PGJyPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9ImZvbnQt c2l6ZTogMTJweDsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBtb25vc3BhY2U7DQogICAgICAgIGJv cmRlci1sZWZ0LWNvbG9yOiByZ2IoMTgxLCAxOTYsIDIyMyk7IGJvcmRlci1sZWZ0LXdpZHRoOiA1 cHg7DQogICAgICAgIGJvcmRlci1sZWZ0LXN0eWxlOiBzb2xpZDsgcGFkZGluZzogMHB4IDBweCAw cHggNXB4OyBtYXJnaW46IDBweA0KICAgICAgICAwcHggMHB4IDVweDsiPg0KPGRpdj4mcXVvdDtU YXJlayBTYWFkICh0c2FhZCkmcXVvdDsgJmx0OzxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJl Zj0ibWFpbHRvOnRzYWFkQGNpc2NvLmNvbSI+dHNhYWRAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6 PC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9U RSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsg TUFSR0lOOjANCiAgICAgICAgICAwIDAgNTsiPg0KPGRpdj5IaSBhdXRob3JzL1dHLDwvZGl2Pg0K PGRpdj5JbiBkcmFmdC1pZXRmLXRlYXMteWFuZy10ZSwgd2UgYXJlIGRyaXZpbmcgdGhlIGRlZmlu aXRpb24gZm9yIGE8L2Rpdj4NCjxkaXY+Z2VuZXJpYyBURSBZQU5HIG1vZGVsIHRoYXQgY2FuL21h eSBiZSB1c2VkIChhbmQgZXh0ZW5kZWQgd2hlbjwvZGl2Pg0KPGRpdj5uZWNlc3NhcnkpIGZvciBk aWZmZXJlbnQgZGF0YSBwbGFuZSB0ZWNobm9sb2dpZXMgKGUuZy4gTVBMUywgT1ROLCBXRE0sPC9k aXY+DQo8ZGl2PmV0Yy4pLjwvZGl2Pg0KPGRpdj5SZXZpZXdpbmcgdGhlIHNjaGVtYSBtb3VudCBp ZGVhIHByZXNlbnRlZCBpbjwvZGl2Pg0KPGRpdj5kcmFmdC1pZXRmLW5ldG1vZC1zY2hlbWEtbW91 bnQsIHdlIGFyZSB0aGlua2luZyB0aGlzIHByb3Bvc2FsIGlzPC9kaXY+DQo8ZGl2PnVzZWZ1bCBh bmQgY2FuIGZhY2lsaXRhdGUgdGhlIHJldXNlIG9mIHRoZSBvdXIgbW9kZWwgaW4gbXVsdGlwbGU8 L2Rpdj4NCjxkaXY+cGxhY2VzIGluIHRoZSBZQU5HIHRyZWUgKG9uY2UgcGVyIGVhY2ggdGVjaG5v bG9neSksIGUuZy46PC9kaXY+DQo8ZGl2PuKApi9tcGxzL21vdW50LXBvaW50cy9tb3VudC1wb2lu dC9tb2R1bGU9aWV0Zi10ZS55YW5nPC9kaXY+DQo8ZGl2PuKApi9vdG4vbW91bnQtcG9pbnRzL21v dW50LXBvaW50L21vZHVsZT1pZXRmLXRlLnlhbmc8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PlNjaGVtYSBtb3VudCBpcyBwcm9iYWJseSBub3QgdGhlIHJpZ2h0 IHNvbHV0aW9uIHRvIHlvdXIgcHJvYmxlbS4mbmJzcDsmbmJzcDtJPC9kaXY+DQo8ZGl2PnRoaW5r IGEgYmV0dGVyIHNvbHV0aW9uIGluIHlvdXIgY2FzZSBpcyB0byBkZWZpbmUgZ3JvdXBpbmdzLjwv ZGl2Pg0KPGRpdj5Hcm91cGluZ3MgYXJlIGRlc2lnbmVkIHRvIGJlIHJlLXVzZWQgYXQgZGlmZmVy ZW50IHBsYWNlcyBpbiB0aGU8L2Rpdj4NCjxkaXY+aGllcmFyY2h5LjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyBmb250LWZhbWlseTogQ29uc29sYXMs IG1vbm9zcGFjZTsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyBm b250LWZhbWlseTogQ29uc29sYXMsIG1vbm9zcGFjZTsiPldlIHRob3VnaHQgb2YgdGhpcyBlYXJs aWVyLCBhbmQgZm91bmQgZ3JvdXBpbmdzIHBvc2UgdGhlaXIgb3duIHNldCBvZiBjaGFsbGVuZ2Vz IHRvby4uIFNwZWNpZmljYWxseTo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsg Zm9udC1mYW1pbHk6IENvbnNvbGFzLCBtb25vc3BhY2U7Ij4tIGEgZ3JvdXBpbmdzIHdpdGggbGVh ZnJlZnMgY291bGQgbm90IHJlZmVyZW5jZSBkYXRhIG5vZGVzIHRoYXQgcmVzaWRlIGluIGFub3Ro ZXIgZ3JvdXBpbmc8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsgZm9udC1mYW1p bHk6IENvbnNvbGFzLCBtb25vc3BhY2U7Ij4tIGEgZ3JvdXBpbmcgd2l0aCBsZWFmcmVmcyBvZiBy ZWxhdGl2ZSBwYXRoIHdlcmUgY2hhbGxlbmdlIHdoZW4gdGhlIHJlbGF0aXZlIHBhdGggcmVmZXJl bmNlcyBkYXRhIG5vZGVzIG91dHNpZGUgdGhlIGdyb3VwaW5nPC9kaXY+DQo8ZGl2IHN0eWxlPSJm b250LXNpemU6IDEycHg7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgbW9ub3NwYWNlOyI+LSB0aGUg YXVnbWVudGF0aW9uIG9mIHRoZSBncm91cGluZyBieSBvdGhlciBtb2R1bGVzIGlzIG5vdCBhcyBz dHJhaWdodGZvcndhcmQ8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsgZm9udC1m YW1pbHk6IENvbnNvbGFzLCBtb25vc3BhY2U7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZv bnQtc2l6ZTogMTJweDsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBtb25vc3BhY2U7Ij5UaGF0IHNh aWQsIHRoZSBncm91cGluZyBwcm9wb3NhbCBzZWVtcyB0byZuYnNwOzwvZGl2Pg0KPGRpdiBzdHls ZT0iZm9udC1zaXplOiAxMnB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIG1vbm9zcGFjZTsiPjxi cj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyBmb250LWZhbWlseTogQ29u c29sYXMsIG1vbm9zcGFjZTsiPm9uZSBjb3VsZCBhbHNvIHRoaW5rIHRoYXQgd2l0aCBncm91cGlu Z3Mgb25lIGNvdWxkIGFkZHJlc3MgcmV1c2Ugb2YgdGhlIGEgbW9kZWwgKGUuZy4gSWV0Zi1pbnRl cmZhY2VzKSBmb3IgbG9naWNhbCBkZXZpY2VzIG9yIFZNIChzZWUgYmVsb3cpLiBJbiBmYWN0LCBp biB5b3VyIGRyYWZ0IChzZWN0aW9uIDIpIHlvdSBleHBsaWNpdGx5IGRpc2NvdXJhZ2UNCiB0aGlz IGFwcHJvYWNoIGFzIG5vdCBzY2FsYWJsZSBzb2x1dGlvbjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u dC1zaXplOiAxMnB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIG1vbm9zcGFjZTsiPjxicj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyBmb250LWZhbWlseTogQ29uc29sYXMs IG1vbm9zcGFjZTsiPjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+PGZvbnQgc3R5bGU9ImZvbnQt c2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwNCiAgICAgICAgICAgIDI1NSwg MCk7IiBmYWNlPSJDb25zb2xhcyxtb25vc3BhY2UiPiZuYnNwOyAmbmJzcDtXaXRoIHRoZSAmcXVv dDt1c2VzJnF1b3Q7IGFwcHJvYWNoLCBpZXRmLWludGVyZmFjZXMgd291bGQgaGF2ZSB0byBkZWZp bmUgYTwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsgYmFj a2dyb3VuZC1jb2xvcjogcmdiKDI1NSwNCiAgICAgICAgICAgIDI1NSwgMCk7IiBmYWNlPSJDb25z b2xhcyxtb25vc3BhY2UiPiZuYnNwOyAmbmJzcDtncm91cGluZyB3aXRoIGFsbCBpdHMgbm9kZXMs IGFuZCB0aGUgbmV3IG1vZGVsIGZvciBsb2dpY2FsIGRldmljZXM8L2ZvbnQ+PC9kaXY+DQo8ZGl2 Pjxmb250IHN0eWxlPSJmb250LXNpemU6IDEycHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUs DQogICAgICAgICAgICAyNTUsIDApOyIgZmFjZT0iQ29uc29sYXMsbW9ub3NwYWNlIj4mbmJzcDsg Jm5ic3A7d291bGQgaGF2ZSB0byB1c2UgdGhpcyBncm91cGluZy4gJm5ic3A7VGhpcyBpcyBhIG5v dCBhIHNjYWxhYmxlIHNvbHV0aW9uLDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgc3R5bGU9ImZv bnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwNCiAgICAgICAgICAgIDI1 NSwgMCk7IiBmYWNlPSJDb25zb2xhcyxtb25vc3BhY2UiPiZuYnNwOyAmbmJzcDtzaW5jZSBldmVy eSB0aW1lIHRoZXJlIGlzIGEgbmV3IG1vZGVsIGRlZmluZWQsIHdlIHdvdWxkIGhhdmUgdG88L2Zv bnQ+PC9kaXY+DQo8ZGl2Pjxmb250IHN0eWxlPSJmb250LXNpemU6IDEycHg7IGJhY2tncm91bmQt Y29sb3I6IHJnYigyNTUsDQogICAgICAgICAgICAyNTUsIDApOyIgZmFjZT0iQ29uc29sYXMsbW9u b3NwYWNlIj4mbmJzcDsgJm5ic3A7dXBkYXRlIG91ciBtb2RlbCBmb3IgbG9naWNhbCBkZXZpY2Vz IHRvIHVzZSBhIGdyb3VwaW5nIGZyb20gdGhlIG5ldzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQg c3R5bGU9ImZvbnQtc2l6ZTogMTJweDsiIGZhY2U9IkNvbnNvbGFzLG1vbm9zcGFjZSI+PHNwYW4g c3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMCk7Ij4mbmJzcDsgJm5ic3A7 bW9kZWwuDQo8L3NwYW4+Jm5ic3A7QW5vdGhlciBwcm9ibGVtIGlzIHRoYXQgdGhpcyBhcHByb2Fj aCBjYW5ub3QgaGFuZGxlIHZlbmRvci08L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OiBDb25zb2xhcywgbW9ub3NwYWNlOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTogQ29uc29sYXMsIG1vbm9zcGFjZTsiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDEycHg7Ij48YnI+DQo8L3NwYW4+PC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09V VExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xh cywgbW9ub3NwYWNlOyBib3JkZXItbGVmdC1jb2xvcjoNCiAgICAgICAgcmdiKDE4MSwgMTk2LCAy MjMpOyBib3JkZXItbGVmdC13aWR0aDogNXB4OyBib3JkZXItbGVmdC1zdHlsZToNCiAgICAgICAg c29saWQ7IHBhZGRpbmc6IDBweCAwcHggMHB4IDVweDsgbWFyZ2luOiAwcHggMHB4IDBweCA1cHg7 Ij4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklC VVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsgYm9yZGVyLWxlZnQtY29s b3I6IHJnYigxODEsIDE5NiwgMjIzKTsNCiAgICAgICAgICBib3JkZXItbGVmdC13aWR0aDogNXB4 OyBib3JkZXItbGVmdC1zdHlsZTogc29saWQ7IHBhZGRpbmc6IDBweA0KICAgICAgICAgIDBweCAw cHggNXB4OyBtYXJnaW46IDBweCAwcHggMHB4IDVweDsiPg0KPGRpdj5XZSBoYXZlIGEgY29tbWVu dC9jb25jZXJuL3N1Z2dlc3Rpb24gYW5kIHdlIHZhbHVlIHlvdXIgZmVlZGJhY2suPC9kaXY+DQo8 ZGl2PlRoZSBnZW5lcmljIFRFIG1vZGVsIGN1cnJlbnRseSByZWZlcmVuY2VzIGRhdGEgbm9kZXMg aW4gdGhlIGdsb2JhbDwvZGl2Pg0KPGRpdj50cmVlIChlLmcuIGZyb20gdGhlIGlldGYtaW50ZXJm YWNlcyBtb2RlbCB0byBkZWZpbmUgYWRkaXRpb25hbCBURTwvZGl2Pg0KPGRpdj5wcm9wZXJ0aWVz IGFzc29jaWF0ZWQgd2l0aCBhIHNwZWNpZmljIGRldmljZSBpbnRlcmZhY2UpLiBPdXI8L2Rpdj4N CjxkaXY+dW5kZXJzdGFuZGluZyBhZnRlciByZWFkaW5nIHNlY3Rpb24gMy4xIG9mIHlvdXIgZHJh ZnQgaXMgdGhlIG1vdW50ZWQ8L2Rpdj4NCjxkaXY+bW9kZWwgY2FuICpub3QqIHJlZmVyZW5jZSBh bnkgZGF0YSBub2RlcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGU8L2Rpdj4NCjxkaXY+bW91bnQt cG9pbnQgKGUuZy4gZ2xvYmFsIGRhdGEgbm9kZXMgaW4gdGhlIHlhbmcgdHJlZSkuIFRoaXMgcG9z ZXMgYTwvZGl2Pg0KPGRpdj5saW1pdGF0aW9uIGZvciB1cywgZG8geW91IGhhdmUgYSBzdWdnZXN0 aW9uIGZvciB0aGlzIHByb2JsZW0/PC9kaXY+DQo8ZGl2Pk9uZSBwb3NzaWJsZSBzb2x1dGlvbiB3 ZSB0aG91Z2h0IG9mIHdhcyB0byByZXBsYWNlIHRoZSBsZWFmLXJlZnM8L2Rpdj4NCjxkaXY+cG9p bnRpbmcgdG8gdGhlIGdsb2JhbCBkYXRhIG5vZGVzIChlLmcuIElldGYtaW50ZXJmYWNlcykgd2l0 aCBjb250ZXh0PC9kaXY+DQo8ZGl2Pm5hbWVzIChlLmcuIHRoZSBpbnRlcmZhY2UgbmFtZSkuLiBU aGlzIGRlY291cGxlcyB0aGUgZGF0YS1ub2RlczwvZGl2Pg0KPGRpdj5kZWZpbmVkIGluIHRoZSBU RSBnZW5lcmljIG1vZGVsIGZyb20gdGhvc2UgaW4gdGhlIGdsb2JhbCB0cmVlPC9kaXY+DQo8ZGl2 PihlLmcuIHRoZSBhY3R1YWwgaW50ZXJmYWNlIGlldGYtaW50ZXJmYWNlcyBtb2RlbCkuIEFueSBm ZWVkYmFjayBvbjwvZGl2Pg0KPGRpdj50aGlzIG9yIGJldHRlciBzdWdnZXN0aW9ucz88L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsiPjxicj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyI+SWYgeW91IHVzZSBncm91cGluZ3MgaW5z dGVhZCwgeW91IGNhbiBzdGlsbCB1c2UgcHJvcGVyIGxlYWZyZWZzLjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Tm90IGluIGFsbCBjYXNlcyDigJQgYXMgZGVz Y3JpYmVkIGFib3ZlLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJmb250LWZhbWlseTogQ29uc29sYXMsIG1vbm9zcGFjZTsiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDEycHg7Ij5SZWdhcmRzLDwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiBDb25zb2xhcywgbW9ub3NwYWNlOyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsiPlRh cmVrPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29s YXMsIG1vbm9zcGFjZTsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHg7Ij48YnI+DQo8L3Nw YW4+PC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tR VU9URSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhcywgbW9ub3NwYWNlOyBib3JkZXItbGVm dC1jb2xvcjoNCiAgICAgICAgcmdiKDE4MSwgMTk2LCAyMjMpOyBib3JkZXItbGVmdC13aWR0aDog NXB4OyBib3JkZXItbGVmdC1zdHlsZToNCiAgICAgICAgc29saWQ7IHBhZGRpbmc6IDBweCAwcHgg MHB4IDVweDsgbWFyZ2luOiAwcHggMHB4IDBweCA1cHg7Ij4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6 ZTogMTJweDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyI+PGJy Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHg7Ij4vbWFydGluPC9kaXY+DQo8 ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHg7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZv bnQtc2l6ZTogMTJweDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB4 OyI+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05f QkxPQ0tRVU9URSIgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsgYm9yZGVyLWxlZnQtY29sb3I6IHJn YigxODEsIDE5NiwgMjIzKTsNCiAgICAgICAgICBib3JkZXItbGVmdC13aWR0aDogNXB4OyBib3Jk ZXItbGVmdC1zdHlsZTogc29saWQ7IHBhZGRpbmc6IDBweA0KICAgICAgICAgIDBweCAwcHggNXB4 OyBtYXJnaW46IDBweCAwcHggMHB4IDVweDsiPg0KPGRpdj5SZWdhcmRzLDwvZGl2Pg0KPGRpdj5U YXJlazwvZGl2Pg0KPGRpdj5FeGNlcnB0IGZyb20gZHJhZnQtaWV0Zi1uZXRtb2Qtc2NoZW1hLW1v dW50PC9kaXY+DQo8ZGl2PjMuMSZsdDs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldG1vZC1zY2hlbWEtbW91bnQt MDEjc2VjdGlvbi0zLjEiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5l dG1vZC1zY2hlbWEtbW91bnQtMDEjc2VjdGlvbi0zLjE8L2E+Jmd0Oy48L2Rpdj4NCjxkaXY+QXVn bWVudCBhbmQgVmFsaWRhdGlvbiBpbiBNb3VudGVkIERhdGE8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7QWxsIHBhdGhzIChpbiBsZWFmcmVmcywgaW5zdGFuY2UtaWRlbnRpZmll cnMsIFhQYXRoIGV4cHJlc3Npb25zLCBhbmQ8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7dGFyZ2V0IG5vZGVzIG9mIGF1Z21lbnRzKSBpbiB0aGUgZGF0YSBtb2RlbHMgbW91bnRl ZCBhdCBhIG1vdW50IHBvaW50PC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2Fy ZSBpbnRlcnByZXRlZCB3aXRoIHRoZSBtb3VudCBwb2ludCBhcyB0aGUgcm9vdCBub2RlLCBhbmQg dGhlPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO21vdW50ZWQgZGF0YSBub2Rl cyBhcyBpdHMgY2hpbGRyZW4uJm5ic3A7Jm5ic3A7VGhpcyBtZWFucyB0aGF0IGRhdGEgd2l0aGlu IGE8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bW91bnRlZCBzdWJ0cmVlIGNh biBuZXZlciByZWZlciB0byBkYXRhIG91dHNpZGUgb2YgdGhpcyBzdWJ0cmVlLjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyI+PGJyPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8YnI+DQo8ZmllbGRzZXQgY2xhc3M9Im1pbWVBdHRhY2htZW50SGVhZGVy Ij48L2ZpZWxkc2V0PiA8YnI+DQo8cHJlIHdyYXA9IiI+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCjxhIGNsYXNzPSJt b3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5l dG1vZEBpZXRmLm9yZzwvYT48YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+ DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_D5AA9261193D4100AF1581F4BF98654Cciscocom_-- From nobody Mon May 9 17:02:55 2016 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 5027312B05D; Mon, 9 May 2016 17:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.898 X-Spam-Level: X-Spam-Status: No, score=-107.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 KC16nkBPcpvT; Mon, 9 May 2016 17:02:47 -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 79D2B12D1AC; Mon, 9 May 2016 17:02:47 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 77EF418019D; Mon, 9 May 2016 17:01:56 -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 Message-Id: <20160510000156.77EF418019D@rfc-editor.org> Date: Mon, 9 May 2016 17:01:56 -0700 (PDT) Archived-At: Cc: teas@ietf.org, rfc-editor@rfc-editor.org Subject: [Teas] RFC 7823 on Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 10 May 2016 00:02:53 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7823 Title: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions Author: A. Atlas, J. Drake, S. Giacalone, S. Previdi Status: Informational Stream: IETF Date: May 2016 Mailbox: akatlas@juniper.net, jdrake@juniper.net, spencer.giacalone@gmail.com, sprevidi@cisco.com Pages: 10 Characters: 23256 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-teas-te-express-path-05.txt URL: https://www.rfc-editor.org/info/rfc7823 DOI: http://dx.doi.org/10.17487/RFC7823 In certain networks, it is critical to consider network performance criteria when selecting the path for an explicitly routed RSVP-TE Label Switched Path (LSP). Such performance criteria can include latency, jitter, and loss or other indications such as the conformance to link performance objectives and non-RSVP TE traffic load. This specification describes how a path computation function may use network performance data, such as is advertised via the OSPF and IS-IS TE metric extensions (defined outside the scope of this document) to perform such path selections. 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 May 10 05:41:55 2016 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 F1CD712D643; Tue, 10 May 2016 05:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEZOsXmMHdhn; Tue, 10 May 2016 05:41:51 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E59FA12D642; Tue, 10 May 2016 05:41:47 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u4ACfjOR009821; Tue, 10 May 2016 13:41:45 +0100 Received: from 950129200 ([79.141.128.249]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u4ACfi5x009810 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 10 May 2016 13:41:44 +0100 From: "Adrian Farrel" To: Date: Tue, 10 May 2016 13:41:43 +0100 Message-ID: <015f01d1aab9$4f16c8e0$ed445aa0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdGquU0SuIg3y/cpQh2ZgOTeJKNB2A== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22312.007 X-TM-AS-Result: No--9.089-10.0-31-10 X-imss-scan-details: No--9.089-10.0-31-10 X-TMASE-MatchedRID: CBjzljA4xB6IUXxlE/cMzFbWTTCHhOTx0Wobj8GkNVpnnK6mXN72mxKA ewg97VeYzBpa9nzaDQwMo1U+ogv8V5ZYcUpbXru4b8JTZf0kEzsh/JA0dHadpsKKRXnO6IwFf/b TCoZRptJNYvDaO9t+nPE/T9QKeKEbzCsOCBxDp3UtMfCdg6KRDTXCCNdZfnq4wDlgqbx3AzqgS5 f11vvha1T+ATxJuezeAfY6QPkaxbtAYS7mW5FtjWZUc2jtcaSd/SbaT95N+tRlhvCMthsWGt61y ++iSofCKUkPazQdQqImKKpGMde8jBCgP4uv/JEpnVTWWiNp+v9Aq6/y5AEOOrJ3rmpkUU+TZ3KR kLO0vRk0cyESKOBv9AXOZdORTuqr5NfCQaRNDqowKDcSSka1a30tCKdnhB58vqq8s2MNhPDPPeN 6HN6d7N7f/25JKIC+C24oEZ6SpSmcfuxsiY4QFAc0QCdV2LGgePpnLPYVmvOQOxy9IjwamHeJ9t Ma1rYTMK3QNUbmXIqX2WTaUBvcSu3Ds7jEnkOU+F4hZA6D6DUytvb+uyZncOQ/bJqlQQ/copZ51 QxAj3fx+wL7E8WTG+w2n3R9PgSOsBTJSD2iAW0= Archived-At: Cc: draft-zhuang-teas-scheduled-resources@ietf.org Subject: [Teas] A unified draft on resource scheduling X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk 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, 10 May 2016 12:41:54 -0000 Hi All, In Yokohama two I-Ds were presented that showed different approaches to managing scheduled resource usage in TE networks. Since then the authors of the two drafts have spent time discussing the best way forward to merge their ideas. We have now reached that point and posted a new revision of one of the drafts (see below) that we are all happy with as an overall architecture. We think that the WG in Yokohama expressed an interest in having this sort of document to record consensus on how to handle resource scheduling and serve as a basis for any protocol extension work. If that is right, we believe that this document is now ready for the WG to consider for adoption and to develop into a TEAS RFC. Please review and let us know your thoughts. Chairs: any next steps for adoption? Thanks, Adrian > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: 10 May 2016 10:16 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-zhuang-teas-scheduled-resources-02.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Architecture for Scheduled Use of Resources > Authors : Yan Zhuang > Qin Wu > Huaimo Chen > Adrian Farrel > Filename : draft-zhuang-teas-scheduled-resources-02.txt > Pages : 13 > Date : 2016-05-10 > > Abstract: > Time-Scheduled reservation of traffic engineering (TE) resources can > be used to provide resource booking for TE Label Switched Paths so as > to better guarantee services for customers and to improve the > efficiency of network resource usage into the future. This document > provides a framework that describes and discusses the architecture > for the scheduled reservation of TE resources. This document does > not describe specific protocols or protocol extensions needed to > realize this service. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-zhuang-teas-scheduled-resources/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-zhuang-teas-scheduled-resources-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-zhuang-teas-scheduled-resources-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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Tue May 10 05:55:38 2016 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 CF70212B03D; Tue, 10 May 2016 05:55:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160510125532.412.55504.idtracker@ietfa.amsl.com> Date: Tue, 10 May 2016 05:55:32 -0700 Archived-At: Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-interconnected-te-info-exchange-06.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 10 May 2016 12:55:33 -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 of the IETF. Title : Problem Statement and Architecture for Information Exchange Between Interconnected Traffic Engineered Networks Authors : Adrian Farrel John Drake Nabil Bitar George Swallow Daniele Ceccarelli Xian Zhang Filename : draft-ietf-teas-interconnected-te-info-exchange-06.txt Pages : 61 Date : 2016-05-10 Abstract: In Traffic Engineered (TE) systems, it is sometimes desirable to establish an end-to-end TE path with a set of constraints (such as bandwidth) across one or more network from a source to a destination. TE information is the data relating to nodes and TE links that is used in the process of selecting a TE path. TE information is usually only available within a network. We call such a zone of visibility of TE information a domain. An example of a domain may be an IGP area or an Autonomous System. In order to determine the potential to establish a TE path through a series of connected networks, it is necessary to have available a certain amount of TE information about each network. This need not be the full set of TE information available within each network, but does need to express the potential of providing TE connectivity. This subset of TE information is called TE reachability information. This document sets out the problem statement for the exchange of TE information between interconnected TE networks in support of end-to- end TE path establishment and describes the best current practice architecture to meet this problem statement. For reasons that are explained in the document, this work is limited to simple TE constraints and information that determine TE reachability. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-interconnected-te-info-exchange/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-teas-interconnected-te-info-exchange-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-interconnected-te-info-exchange-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 May 10 06:04:58 2016 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 81B0712D644; Tue, 10 May 2016 06:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8ycqZDFgs76; Tue, 10 May 2016 06:04:55 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1E7312D675; Tue, 10 May 2016 06:04:49 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u4AD4koB023334; Tue, 10 May 2016 14:04:46 +0100 Received: from 950129200 ([79.141.128.249]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u4AD4jHO023323 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 10 May 2016 14:04:45 +0100 From: "Adrian Farrel" To: Date: Tue, 10 May 2016 14:04:44 +0100 Message-ID: <016001d1aabc$8647efd0$92d7cf70$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdGqvH7KKcee39rDSomF0LywguTC2w== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22312.007 X-TM-AS-Result: No--22.281-10.0-31-10 X-imss-scan-details: No--22.281-10.0-31-10 X-TMASE-MatchedRID: G2LVun06lflZU9fjAumhWJMSBMTQNiSA69mNWFAof4vSYAzZ6KmqWpf4 ZcFCUg+SmKgXX6uw1DptGMMKNqG38ubNhPxw6RtZwCZxkTHxcclVyg4Yz2U7pGsTVziYHlSaPzh oMzR4E2SYpZQh7wSj/5VUHwLxHk0zvKcA55DXCb9gP1dNF1ow7X08MksGfqucBF6xna5Hpe6a1x DavWicTDvqjGF99ejx8U8MeFCSDHKC0nWR/OzqYJVRzPxemJL0WDdWpJMntKgaK6XhXABo91pq2 K/Emlk1rtMiBXvboUso4LmTgl363jK42JVSvu3A5DSMPEZQAkP8d3gJRYhL8be+d17yNu5sMqCU TVmFLuBkpgwC5uOBF5oF52T0zFZtmlLXzDiDGEP87vS8PQu3wJdIzbo51vdjEd+K6O5Nt52tZXA 67sG7W+yFE44p7M/DDmCxW/tybLEPKzM1XxqFfam4PbloS2C3dZPoD9V2prSbKItl61J/ycnjLT A/UDoAHwAqApZ40aFix43hpI4fV90H8LFZNFG7JQhrLH5KSJ0= Archived-At: Cc: draft-ietf-teas-interconnected-te-info-exchange.all@ietf.org, brian.e.carpenter@gmail.com, Hilarie Orman Subject: [Teas] Update to draft-ietf-teas-interconnected-te-info-exchange X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk 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, 10 May 2016 13:04:57 -0000 Hi, I posted an update to this draft after the completion of IETF last call. We received a GenART review from Brian Carpenter and a SecDir review from Hilarie Orman. These gave rise to some changes and some email discussion. (Stewart's RtgDir review was handled in -05 before IETF last call started.) I believe we have closed down all points except one from Brian about whether the content and precise wording is consistent with the document as a BCP. At the moment I am reluctant to change the text to make it consistent with the chosen publication track (especially since the authors originally proposed Standards Track not BFP) and prefer to find the correct track for the current document. My reasoning is two-fold: - This is the document that we (the WG) wanted to publish. Changing the text to suit the publication track seems to be back-to-front. - IESG review has a likelihood of changing the publication track again or wanting more changes to keep it as a BCP. I would prefer to see all of these changes in one batch rather than trickling them in. The Diff will show a few more changes than expected because the layout changed so that figures don't fall on page breaks. Cheers, Adrian > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: 10 May 2016 13:56 > To: i-d-announce@ietf.org > Cc: teas@ietf.org > Subject: [Teas] I-D Action: draft-ietf-teas-interconnected-te-info-exchange- > 06.txt > > > 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 of > the IETF. > > Title : Problem Statement and Architecture for Information Exchange > Between Interconnected Traffic Engineered Networks > Authors : Adrian Farrel > John Drake > Nabil Bitar > George Swallow > Daniele Ceccarelli > Xian Zhang > Filename : draft-ietf-teas-interconnected-te-info-exchange-06.txt > Pages : 61 > Date : 2016-05-10 > > Abstract: > In Traffic Engineered (TE) systems, it is sometimes desirable to > establish an end-to-end TE path with a set of constraints (such as > bandwidth) across one or more network from a source to a destination. > TE information is the data relating to nodes and TE links that is > used in the process of selecting a TE path. TE information is > usually only available within a network. We call such a zone of > visibility of TE information a domain. An example of a domain may be > an IGP area or an Autonomous System. > > In order to determine the potential to establish a TE path through a > series of connected networks, it is necessary to have available a > certain amount of TE information about each network. This need not > be the full set of TE information available within each network, but > does need to express the potential of providing TE connectivity. This > subset of TE information is called TE reachability information. > > This document sets out the problem statement for the exchange of TE > information between interconnected TE networks in support of end-to- > end TE path establishment and describes the best current practice > architecture to meet this problem statement. For reasons that are > explained in the document, this work is limited to simple TE > constraints and information that determine TE reachability. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-teas-interconnected-te-info- > exchange/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-teas-interconnected-te-info-exchange-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-interconnected-te-info- > exchange-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/ > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Tue May 10 06:45:04 2016 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 08C8212D09F for ; Tue, 10 May 2016 06:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 2q457tAmvLrP for ; Tue, 10 May 2016 06:45:00 -0700 (PDT) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 647BE12D173 for ; Tue, 10 May 2016 06:45:00 -0700 (PDT) Received: (qmail 18656 invoked by uid 0); 10 May 2016 13:44:58 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy5.mail.unifiedlayer.com with SMTP; 10 May 2016 13:44:58 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id sdkl1s00H2SSUrH01dkoTA; Tue, 10 May 2016 07:44:54 -0600 X-Authority-Analysis: v=2.1 cv=Nal1iQz4 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=yrkiwgmsf1kA:10 a=48vgC7mUAAAA:8 a=kX0MQ5EFXNq7ZAKXsPMA:9 a=txWS-xd2GQbQQVC7:21 a=czk95a4kiy_taGpK:21 a=pILNOxqGKmIA:10 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject; bh=eBXfVeBgV3cppVqwC8R4euakvC7+93L7KyqcChJLjls=; b=Xs+BJYd1w9G/42ek0Mfv371n12 UTzqRWfsMsFhEw5N/9xd+dX6cAed42fheuelafxCAhTsFta75fcurmFw7229vwZYditcdqAdZzGPy L8At60eA9ukmRCvox3sYsdQNi; Received: from box313.bluehost.com ([69.89.31.113]:35585 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1b07xv-0007n8-1S; Tue, 10 May 2016 07:44:47 -0600 To: adrian@olddog.co.uk, teas@ietf.org References: <016001d1aabc$8647efd0$92d7cf70$@olddog.co.uk> From: Lou Berger Message-ID: <5731E5C9.5030009@labn.net> Date: Tue, 10 May 2016 09:44:41 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <016001d1aabc$8647efd0$92d7cf70$@olddog.co.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: draft-ietf-teas-interconnected-te-info-exchange.all@ietf.org, brian.e.carpenter@gmail.com, Hilarie Orman Subject: Re: [Teas] Update to draft-ietf-teas-interconnected-te-info-exchange X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 10 May 2016 13:45:03 -0000 Adrian, Authors, Thank you got all the hard work to get the document to this point. The end objective is almost here! Can you recap exactly what change is being proposed to address Brian's comment? Thank you, Lou On 5/10/2016 9:04 AM, Adrian Farrel wrote: > Hi, > > I posted an update to this draft after the completion of IETF last call. > > We received a GenART review from Brian Carpenter and a SecDir review from > Hilarie Orman. These gave rise to some changes and some email discussion. > (Stewart's RtgDir review was handled in -05 before IETF last call started.) > > I believe we have closed down all points except one from Brian about whether the > content and precise wording is consistent with the document as a BCP. At the > moment I am reluctant to change the text to make it consistent with the chosen > publication track (especially since the authors originally proposed Standards > Track not BFP) and prefer to find the correct track for the current document. My > reasoning is two-fold: > > - This is the document that we (the WG) wanted to publish. Changing the > text to suit the publication track seems to be back-to-front. > > - IESG review has a likelihood of changing the publication track again or > wanting more changes to keep it as a BCP. I would prefer to see all of > these changes in one batch rather than trickling them in. > > The Diff will show a few more changes than expected because the layout changed > so that figures don't fall on page breaks. > > Cheers, > Adrian > >> -----Original Message----- >> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org >> Sent: 10 May 2016 13:56 >> To: i-d-announce@ietf.org >> Cc: teas@ietf.org >> Subject: [Teas] I-D Action: draft-ietf-teas-interconnected-te-info-exchange- >> 06.txt >> >> >> 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 of >> the IETF. >> >> Title : Problem Statement and Architecture for Information > Exchange >> Between Interconnected Traffic Engineered Networks >> Authors : Adrian Farrel >> John Drake >> Nabil Bitar >> George Swallow >> Daniele Ceccarelli >> Xian Zhang >> Filename : draft-ietf-teas-interconnected-te-info-exchange-06.txt >> Pages : 61 >> Date : 2016-05-10 >> >> Abstract: >> In Traffic Engineered (TE) systems, it is sometimes desirable to >> establish an end-to-end TE path with a set of constraints (such as >> bandwidth) across one or more network from a source to a destination. >> TE information is the data relating to nodes and TE links that is >> used in the process of selecting a TE path. TE information is >> usually only available within a network. We call such a zone of >> visibility of TE information a domain. An example of a domain may be >> an IGP area or an Autonomous System. >> >> In order to determine the potential to establish a TE path through a >> series of connected networks, it is necessary to have available a >> certain amount of TE information about each network. This need not >> be the full set of TE information available within each network, but >> does need to express the potential of providing TE connectivity. This >> subset of TE information is called TE reachability information. >> >> This document sets out the problem statement for the exchange of TE >> information between interconnected TE networks in support of end-to- >> end TE path establishment and describes the best current practice >> architecture to meet this problem statement. For reasons that are >> explained in the document, this work is limited to simple TE >> constraints and information that determine TE reachability. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-teas-interconnected-te-info- >> exchange/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-teas-interconnected-te-info-exchange-06 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-interconnected-te-info- >> exchange-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/ >> >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > From nobody Tue May 10 09:15:30 2016 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 4131712D516; Tue, 10 May 2016 09:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yA8fvhAepMMX; Tue, 10 May 2016 09:15:24 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F17512D725; Tue, 10 May 2016 09:15:23 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u4AGFKG0001405; Tue, 10 May 2016 17:15:20 +0100 Received: from 950129200 ([79.141.128.249]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u4AGFIbf001375 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 10 May 2016 17:15:19 +0100 From: "Adrian Farrel" To: "'Lou Berger'" , References: <016001d1aabc$8647efd0$92d7cf70$@olddog.co.uk> <5731E5C9.5030009@labn.net> In-Reply-To: <5731E5C9.5030009@labn.net> Date: Tue, 10 May 2016 17:15:17 +0100 Message-ID: <01d901d1aad7$2547ad40$6fd707c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHGY8vnNTJbBebVyBv4JJ1RFWV4dwLrX5XEn7GCBGA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22314.000 X-TM-AS-Result: No--33.355-10.0-31-10 X-imss-scan-details: No--33.355-10.0-31-10 X-TMASE-MatchedRID: IeZYkn8zfFq5qJcHKhN0j1bWTTCHhOTxBdebOqawiLuIlH0NRaWl1Z9C 0HgY5O+2+LSggqFmoj6pjGDCb1aOSBPoX8jcWGowA9lly13c/gEhotH7bEpEMkuCjz4ggdtwLBE ps7wAXzJ6hyLUyv12+xsOD8l7W//gFkrTnESQKQJswYo64ufkVSQqzcugG1CVLLoMUXmFqmaJVy b80B1IQ7uAybuX4TNI3r1zm2d99+qFACKYHKCfIsxTqHgXR/59y73+RA6DaIoifM7JMNHW68R68 eK5afxIm4Sn2vfIJl4mKKpGMde8jGXHsLx6b+1WsyNb+yeIRAqXYX34rFl3x23D6f6IpbLImQrF TKU9Y1dS275gJTvSaABekK2wNWBF+FujNfhAEcZIRA38P/dwbuU28KlVaRfjHqeNNK3aTguBXgb NtVgNv0zU0S0GarAgEzXK5vGAsQTXFDY6Be2LlfVFR4sC8dPyVjkEEmuL2x21eX0jEQ9c6gbE8Q mnGWcVDrNdzcvcuGVx53fwOqBIr7mvMSppeWbNJrUxoq6hvw9+Mk6ACsw4JsUmcSma304TOXUFK +IJNsJPi6Rt71EEFrorMF3Fkrby/j3hsHetKfLHt9VUPuskRpE+3DCX3uibPpePGJoKs77q4LKG p1BNM7C9IDmRo2d4cAwOsowI+VL3gr9T3KhP3gizXxlOHX34z5hzQnUnsHYqFjgOpGJXOWelhqD AC9jJGpHkh1XhVaWglj7ZOsMUtdy4rf2S59d1R+GtoiXVeDFDGFvBeB2nXGFPYygUWryNYuB8si +nmISahMqmNXa3RU+Cka/89um3MHsCEB6xhyOeAiCmPx4NwLTrdaH1ZWqCpvI8UZOf47ih5DOWG PdqWY2j49Ftap9EkGUtrowrXLg= Archived-At: Cc: draft-ietf-teas-interconnected-te-info-exchange.all@ietf.org, brian.e.carpenter@gmail.com Subject: Re: [Teas] Update to draft-ietf-teas-interconnected-te-info-exchange X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk 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, 10 May 2016 16:15:28 -0000 Brian (as the reviewer) and Deborah (as our AD) had an exchange of ideas. Deborah summarised the issue as: Section 5 and section 5.4 say that minor modifications to existing protocols would be necessary to fully satisfy this architecture, but the status of BCP implies that you can and do do things with existing tools. Furthermore, Deborah claims "the solution described in this document doesn't require any modifications to the protocols. " Deborah proposed three changes... 1. Section 6 title change from "Applicability to Optical Domains and Networks" to "An Abstraction Solution for Optical Domains and Networks" 2. Section 7 title change from "Modeling the User-to-Network Interface" to "Abstraction in the User-to-Network Interface" 3. Some rewording of section 5 to preclude additional protocol work to be consistent with the concept of a BCP. I am pushing back on these changes. Part of this is philosophical - an architecture tells you how to build stuff and IMHO this can be normative. I think that makes the document Standards Track, but whatever the result of that discussion, I think it is fine for an architecture to point out that protocol work is still needed. But the main push-back is to be correct! Sections 6 and 7 describe how the architecture fits the with specific network deployments. While those sections describe how some protocols could be applied, they are not a solution, they are an application of the architecture. They could be re-titled "Applicability of The Architecture Described in This Document to Optical Domains and Networks" and "Modeling the User-to-Network Interface Using The Architecture Described in This Document" although those seem rather long-winded. Section 5 possibly does not go far enough as it is! It notes some relevant protocol work that has not been completed, but it does not build a comprehensive list. And it does that deliberately in order to not attempt to deliver or prejudge a solution. Mentioning that BGP-LS does not (yet) have an RFC that describes extensions for GMPLS networks is possibly over-reaching because no-one has said that it is a requirement to use BGP-LS to export abstractions of optical links. In any case, it would be wrong for this document to preclude additional protocol work. If all of that means that this is not a BCP, that's OK. It is what it is. If it is still the opinion of our leaders (who have to support publication) that this is not Standards Track, that's OK too. We may end up as Informational. However, there is zero value in us doing either of: - Changing the document that we wanted to publish just to make it match a particular publication track. - Trying to second-guess the IESG. They may say BCP is OK as written. They might ask us to make more changes even after the ones Deborah suggests. The former is the tail wagging the dog. The latter is whack-a-mole. Cheers, Adrian > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: 10 May 2016 14:45 > To: adrian@olddog.co.uk; teas@ietf.org > Cc: draft-ietf-teas-interconnected-te-info-exchange.all@ietf.org; > brian.e.carpenter@gmail.com; Hilarie Orman > Subject: Re: [Teas] Update to draft-ietf-teas-interconnected-te-info-exchange > > Adrian, Authors, > Thank you got all the hard work to get the document to this point. > The end objective is almost here! > > Can you recap exactly what change is being proposed to address Brian's > comment? > > Thank you, > Lou > > On 5/10/2016 9:04 AM, Adrian Farrel wrote: > > Hi, > > > > I posted an update to this draft after the completion of IETF last call. > > > > We received a GenART review from Brian Carpenter and a SecDir review from > > Hilarie Orman. These gave rise to some changes and some email discussion. > > (Stewart's RtgDir review was handled in -05 before IETF last call started.) > > > > I believe we have closed down all points except one from Brian about whether > the > > content and precise wording is consistent with the document as a BCP. At the > > moment I am reluctant to change the text to make it consistent with the > chosen > > publication track (especially since the authors originally proposed Standards > > Track not BFP) and prefer to find the correct track for the current document. > My > > reasoning is two-fold: > > > > - This is the document that we (the WG) wanted to publish. Changing the > > text to suit the publication track seems to be back-to-front. > > > > - IESG review has a likelihood of changing the publication track again or > > wanting more changes to keep it as a BCP. I would prefer to see all of > > these changes in one batch rather than trickling them in. > > > > The Diff will show a few more changes than expected because the layout > changed > > so that figures don't fall on page breaks. > > > > Cheers, > > Adrian > > > >> -----Original Message----- > >> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of > > internet-drafts@ietf.org > >> Sent: 10 May 2016 13:56 > >> To: i-d-announce@ietf.org > >> Cc: teas@ietf.org > >> Subject: [Teas] I-D Action: draft-ietf-teas-interconnected-te-info-exchange- > >> 06.txt > >> > >> > >> 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 of > >> the IETF. > >> > >> Title : Problem Statement and Architecture for Information > > Exchange > >> Between Interconnected Traffic Engineered Networks > >> Authors : Adrian Farrel > >> John Drake > >> Nabil Bitar > >> George Swallow > >> Daniele Ceccarelli > >> Xian Zhang > >> Filename : draft-ietf-teas-interconnected-te-info-exchange-06.txt > >> Pages : 61 > >> Date : 2016-05-10 > >> > >> Abstract: > >> In Traffic Engineered (TE) systems, it is sometimes desirable to > >> establish an end-to-end TE path with a set of constraints (such as > >> bandwidth) across one or more network from a source to a destination. > >> TE information is the data relating to nodes and TE links that is > >> used in the process of selecting a TE path. TE information is > >> usually only available within a network. We call such a zone of > >> visibility of TE information a domain. An example of a domain may be > >> an IGP area or an Autonomous System. > >> > >> In order to determine the potential to establish a TE path through a > >> series of connected networks, it is necessary to have available a > >> certain amount of TE information about each network. This need not > >> be the full set of TE information available within each network, but > >> does need to express the potential of providing TE connectivity. This > >> subset of TE information is called TE reachability information. > >> > >> This document sets out the problem statement for the exchange of TE > >> information between interconnected TE networks in support of end-to- > >> end TE path establishment and describes the best current practice > >> architecture to meet this problem statement. For reasons that are > >> explained in the document, this work is limited to simple TE > >> constraints and information that determine TE reachability. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-teas-interconnected-te-info- > >> exchange/ > >> > >> There's also a htmlized version available at: > >> https://tools.ietf.org/html/draft-ietf-teas-interconnected-te-info-exchange- > 06 > >> > >> A diff from the previous version is available at: > >> https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-interconnected-te-info- > >> exchange-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/ > >> > >> _______________________________________________ > >> Teas mailing list > >> Teas@ietf.org > >> https://www.ietf.org/mailman/listinfo/teas > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org > > https://www.ietf.org/mailman/listinfo/teas > > From nobody Tue May 10 10:51:58 2016 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 A85BB12D7B6; Tue, 10 May 2016 10:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 Dov7TpjsICKM; Tue, 10 May 2016 10:51:54 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0777.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::777]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0E8712D590; Tue, 10 May 2016 10:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=a8qeWj/M8dH7ekkPRnoJcPZjE3rgUsQ3IyMsMHX/Dwo=; b=JaNbjYrTHrLyQqTiTViGvS/8fH+orKhcjBROktWYpScBI4mR71Gkdn6JkI8fZNQ+vBaHsnrZ9g5NxJ2Q/ouW/rXO3fqUftQU9WJ8oE8H/Mks3uwT4u2eDW4ws1gqQLELnHKniTAA68lcD6nBiVIIHqSN7Js8P1VLad7jOEcZgNQ= Received: from SN1PR0501MB1709.namprd05.prod.outlook.com (10.163.130.155) by SN1PR0501MB1711.namprd05.prod.outlook.com (10.163.130.157) with Microsoft SMTP Server (TLS) id 15.1.492.11; Tue, 10 May 2016 17:51:34 +0000 Received: from SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) by SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) with mapi id 15.01.0492.016; Tue, 10 May 2016 17:51:33 +0000 From: John E Drake To: "adrian@olddog.co.uk" , 'Lou Berger' , "teas@ietf.org" Thread-Topic: [Teas] Update to draft-ietf-teas-interconnected-te-info-exchange Thread-Index: AdGqvH7KKcee39rDSomF0LywguTC2wABZtiAAAVCeIAAAzlFIA== Date: Tue, 10 May 2016 17:51:33 +0000 Message-ID: References: <016001d1aabc$8647efd0$92d7cf70$@olddog.co.uk> <5731E5C9.5030009@labn.net> <01d901d1aad7$2547ad40$6fd707c0$@olddog.co.uk> In-Reply-To: <01d901d1aad7$2547ad40$6fd707c0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: olddog.co.uk; dkim=none (message not signed) header.d=none;olddog.co.uk; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.14] x-ms-office365-filtering-correlation-id: 3bb823f3-fac0-4b0c-1419-08d378fbb9e0 x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1711; 5:qLTHT6BaD0OwYqMsmgfTckcnjXCLI6hUXGg2aI5puYn9ENCYB6L27KRkAed1raHLvztp2wS1O96Eixulk4U0AsM+WZ+zWVSFlVWLHv4hJtApY82Aklt2MdToJNiBJRfC2Zn/LWgYNWXJD2Q5RDtePQ==; 24:UEMkfPNU5l1QtJcoGi6rD7yj0R9VsISo5wbOgaNpax08yThKvYcwvDlKqOV6OUsowZemjX5txEJLBZ6z24CBNp4r/BgzpO3/1/vWyzuh5Qg=; 7:Xm5Gfd3JhhkHZ1fP5naGWrfYe8F21zTtlFNd/9mvxUBuME6k8+mQvmQxPhQD9pHm70K9jwVUFrs7bjZkwScBCMclzhXroiLaZYlMvgI2/flghNueNd/7IDBfIVtdTb1wNkUp9Jtc0VIk0ZwnUbuLK6u6RqDoaC/f5zrjKha3xtLiGcxH8McGEGzsaEylYLH3 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB1711; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:SN1PR0501MB1711; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1711; x-forefront-prvs: 0938781D02 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377424004)(377454003)(24454002)(51444003)(13464003)(99286002)(15975445007)(5002640100001)(5003600100002)(189998001)(77096005)(66066001)(54356999)(50986999)(4326007)(81166006)(86362001)(33656002)(2906002)(76176999)(8936002)(230783001)(76576001)(586003)(5001770100001)(1220700001)(6116002)(3846002)(102836003)(5004730100002)(19580395003)(5008740100001)(15650500001)(3280700002)(3660700001)(19580405001)(2501003)(9686002)(2950100001)(122556002)(2900100001)(92566002)(10400500002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1711; H:SN1PR0501MB1709.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2016 17:51:33.9028 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1711 Archived-At: Cc: "draft-ietf-teas-interconnected-te-info-exchange.all@ietf.org" , "brian.e.carpenter@gmail.com" Subject: Re: [Teas] Update to draft-ietf-teas-interconnected-te-info-exchange X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 10 May 2016 17:51:58 -0000 Hi, The logic behind changing from ST, which is what the WG approved, to BCP ha= s always escaped me and I would be happy to go back to ST before sending it= to the IESG. What we are doing now is neither wagging dogs nor whacking moles, but rathe= r wandering at random. Yours Irrespectively, John > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Tuesday, May 10, 2016 12:15 PM > To: 'Lou Berger'; teas@ietf.org > Cc: draft-ietf-teas-interconnected-te-info-exchange.all@ietf.org; > brian.e.carpenter@gmail.com > Subject: Re: [Teas] Update to draft-ietf-teas-interconnected-te-info-exch= ange >=20 > Brian (as the reviewer) and Deborah (as our AD) had an exchange of ideas. >=20 > Deborah summarised the issue as: > Section 5 and section 5.4 say that minor modifications to existing protoc= ols would be > necessary to fully satisfy this architecture, but the status of BCP impli= es that you can and do > do things with existing tools. >=20 > Furthermore, Deborah claims "the solution described in this document does= n't require any > modifications to the protocols. " >=20 > Deborah proposed three changes... >=20 > 1. Section 6 title change from "Applicability to Optical Domains and Netw= orks" > to "An Abstraction Solution for Optical Domains and Networks" > 2. Section 7 title change from "Modeling the User-to-Network Interface" t= o "Abstraction in > the User-to-Network Interface" > 3. Some rewording of section 5 to preclude additional protocol work to be= consistent with > the concept of a BCP. >=20 > I am pushing back on these changes. Part of this is philosophical - an ar= chitecture tells you > how to build stuff and IMHO this can be normative. I think that makes the= document > Standards Track, but whatever the result of that discussion, I think it i= s fine for an > architecture to point out that protocol work is still needed. >=20 > But the main push-back is to be correct! >=20 > Sections 6 and 7 describe how the architecture fits the with specific net= work deployments. > While those sections describe how some protocols could be applied, they a= re not a solution, > they are an application of the architecture. They could be re-titled "App= licability of The > Architecture Described in This Document to Optical Domains and Networks" = and "Modeling > the User-to-Network Interface Using The Architecture Described in This Do= cument" > although those seem rather long-winded. >=20 > Section 5 possibly does not go far enough as it is! It notes some relevan= t protocol work that > has not been completed, but it does not build a comprehensive list. And i= t does that > deliberately in order to not attempt to deliver or prejudge a solution. M= entioning that BGP- > LS does not (yet) have an RFC that describes extensions for GMPLS network= s is possibly > over-reaching because no-one has said that it is a requirement to use BGP= -LS to export > abstractions of optical links. In any case, it would be wrong for this do= cument to preclude > additional protocol work. >=20 > If all of that means that this is not a BCP, that's OK. It is what it is. > If it is still the opinion of our leaders (who have to support publicatio= n) that this is not > Standards Track, that's OK too. > We may end up as Informational. >=20 > However, there is zero value in us doing either of: > - Changing the document that we wanted to publish just to make it match a= particular > publication track. > - Trying to second-guess the IESG. They may say BCP is OK as written. The= y might ask us to > make more changes even after the ones Deborah suggests. >=20 > The former is the tail wagging the dog. > The latter is whack-a-mole. >=20 > Cheers, > Adrian > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: 10 May 2016 14:45 > > To: adrian@olddog.co.uk; teas@ietf.org > > Cc: draft-ietf-teas-interconnected-te-info-exchange.all@ietf.org; > > brian.e.carpenter@gmail.com; Hilarie Orman > > Subject: Re: [Teas] Update to > > draft-ietf-teas-interconnected-te-info-exchange > > > > Adrian, Authors, > > Thank you got all the hard work to get the document to this point. > > The end objective is almost here! > > > > Can you recap exactly what change is being proposed to address Brian's > > comment? > > > > Thank you, > > Lou > > > > On 5/10/2016 9:04 AM, Adrian Farrel wrote: > > > Hi, > > > > > > I posted an update to this draft after the completion of IETF last ca= ll. > > > > > > We received a GenART review from Brian Carpenter and a SecDir review > > > from Hilarie Orman. These gave rise to some changes and some email di= scussion. > > > (Stewart's RtgDir review was handled in -05 before IETF last call > > > started.) > > > > > > I believe we have closed down all points except one from Brian about > > > whether > > the > > > content and precise wording is consistent with the document as a > > > BCP. At the moment I am reluctant to change the text to make it > > > consistent with the > > chosen > > > publication track (especially since the authors originally proposed > Standards > > > Track not BFP) and prefer to find the correct track for the current > document. > > My > > > reasoning is two-fold: > > > > > > - This is the document that we (the WG) wanted to publish. Changing t= he > > > text to suit the publication track seems to be back-to-front. > > > > > > - IESG review has a likelihood of changing the publication track agai= n or > > > wanting more changes to keep it as a BCP. I would prefer to see al= l of > > > these changes in one batch rather than trickling them in. > > > > > > The Diff will show a few more changes than expected because the > > > layout > > changed > > > so that figures don't fall on page breaks. > > > > > > Cheers, > > > Adrian > > > > > >> -----Original Message----- > > >> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of > > > internet-drafts@ietf.org > > >> Sent: 10 May 2016 13:56 > > >> To: i-d-announce@ietf.org > > >> Cc: teas@ietf.org > > >> Subject: [Teas] I-D Action: > draft-ietf-teas-interconnected-te-info-exchange- > > >> 06.txt > > >> > > >> > > >> 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 of > > >> the IETF. > > >> > > >> Title : Problem Statement and Architecture for > Information > > > Exchange > > >> Between Interconnected Traffic Engineered Networks > > >> Authors : Adrian Farrel > > >> John Drake > > >> Nabil Bitar > > >> George Swallow > > >> Daniele Ceccarelli > > >> Xian Zhang > > >> Filename : draft-ietf-teas-interconnected-te-info-exchange-0= 6.txt > > >> Pages : 61 > > >> Date : 2016-05-10 > > >> > > >> Abstract: > > >> In Traffic Engineered (TE) systems, it is sometimes desirable to > > >> establish an end-to-end TE path with a set of constraints (such a= s > > >> bandwidth) across one or more network from a source to a destinat= ion. > > >> TE information is the data relating to nodes and TE links that is > > >> used in the process of selecting a TE path. TE information is > > >> usually only available within a network. We call such a zone of > > >> visibility of TE information a domain. An example of a domain may= be > > >> an IGP area or an Autonomous System. > > >> > > >> In order to determine the potential to establish a TE path throug= h a > > >> series of connected networks, it is necessary to have available a > > >> certain amount of TE information about each network. This need n= ot > > >> be the full set of TE information available within each network, = but > > >> does need to express the potential of providing TE connectivity. = This > > >> subset of TE information is called TE reachability information. > > >> > > >> This document sets out the problem statement for the exchange of = TE > > >> information between interconnected TE networks in support of end-= to- > > >> end TE path establishment and describes the best current practice > > >> architecture to meet this problem statement. For reasons that ar= e > > >> explained in the document, this work is limited to simple TE > > >> constraints and information that determine TE reachability. > > >> > > >> > > >> The IETF datatracker status page for this draft is: > > >> https://datatracker.ietf.org/doc/draft-ietf-teas-interconnected-te- > > >> info- > > >> exchange/ > > >> > > >> There's also a htmlized version available at: > > >> > https://tools.ietf.org/html/draft-ietf-teas-interconnected-te-info-exchan= ge- > > 06 > > >> > > >> A diff from the previous version is available at: > > >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-interconnected-t= e > > >> -info- > > >> exchange-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/ > > >> > > >> _______________________________________________ > > >> Teas mailing list > > >> Teas@ietf.org > > >> https://www.ietf.org/mailman/listinfo/teas > > > _______________________________________________ > > > Teas mailing list > > > Teas@ietf.org > > > https://www.ietf.org/mailman/listinfo/teas > > > >=20 >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Tue May 10 14:15:13 2016 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 BC5C512D8CF; Tue, 10 May 2016 14:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6h6YEmD_Oia; Tue, 10 May 2016 14:15:10 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1DD312D628; Tue, 10 May 2016 14:14:54 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id 206so9977853pfu.0; Tue, 10 May 2016 14:14:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=JDR68f7Wg61C/zRr/B+HJzCDVaWkfk9tvfjUaNd13Ps=; b=YWYtTVCDGC9C4A6f4zq+CvShzE/4/chbUlOlu04krF6pvR7OzktUGq9Iv3q3DGb3t1 jhl52J2SJR4ZLd5JHZmeNI2KmhMV6/mvZFM1aDFI6n5H4ANHCZoexWq0AdpH4dywbNWa u0LBLT+EMqVtVVOuS30G0LurDmmpRX1oejxIeqBVvQjY5R6Q3n+sVzhajBBub2ulNEc6 4gcQpea20BQkXCjEZxy8zs/X7ULLpqLaq7DZkuFZkmdFLCrM+H4xbCTY7e+t8t+tDlPj E0kDTg5+kQtT2uyfvO8r1a+Ki2G/mjsuU7mphtQtMcpJ2LeGS+oVshAYaKzWgFWNNzuk TYyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=JDR68f7Wg61C/zRr/B+HJzCDVaWkfk9tvfjUaNd13Ps=; b=GuNfC7SpvkzVXBeuG58YGh9X06ooTzyLJuWemy9XqJ+ByIfFZrcHij1ITVkSnvgun/ i6j5ElPwTf23+rB7cl2QvodsD8JMkiieaJ1Lvd23uaCBP5mVu3eGid8p0/pPGDHUF1V2 0M1jRQc7zmYoGB0dhDNEWDCyWJ4tr1JG1RKZOAQIcy1V/5XZTKiYI0Fqf/mu15TEmYwo zxHDkXafQr/a176W7TNvlvSuW/zeJjUAPEX57FuviVSyx5SwWbjaPw414vfyI/5a9yyx 1tityv5980bl1chV6LmpMjx6Q4FHeUKOMQHhOC2et0LFG1BTrSpVPBpxqG847CZSXR5X ebLQ== X-Gm-Message-State: AOPr4FWEKpCZs7u2mC/HVsjwP3UQzc0XREspEMCGBnRX1NsEA+lKE1NHvAXFtp7p4b/N2Q== X-Received: by 10.98.0.9 with SMTP id 9mr47409226pfa.19.1462914894189; Tue, 10 May 2016 14:14:54 -0700 (PDT) Received: from [10.10.16.137] ([125.7.18.32]) by smtp.gmail.com with ESMTPSA id zn12sm6676874pab.14.2016.05.10.14.14.50 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 May 2016 14:14:53 -0700 (PDT) To: John E Drake , "adrian@olddog.co.uk" , 'Lou Berger' , "teas@ietf.org" References: <016001d1aabc$8647efd0$92d7cf70$@olddog.co.uk> <5731E5C9.5030009@labn.net> <01d901d1aad7$2547ad40$6fd707c0$@olddog.co.uk> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 11 May 2016 09:15:11 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-teas-interconnected-te-info-exchange.all@ietf.org" Subject: Re: [Teas] Update to draft-ietf-teas-interconnected-te-info-exchange X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 10 May 2016 21:15:13 -0000 1) Thanks for all the detailed updates. This is a fine document that should certainly be published. 2) It's above my pay grade as a Gen-ART reviewer to decide the best status for the document. I have some doubts but I'm completely happy for the IESG to decide. Regards Brian Carpenter On 11/05/2016 05:51, John E Drake wrote: > Hi, > > The logic behind changing from ST, which is what the WG approved, to BCP has always escaped me and I would be happy to go back to ST before sending it to the IESG. > > What we are doing now is neither wagging dogs nor whacking moles, but rather wandering at random. > > Yours Irrespectively, > > John > >> -----Original Message----- >> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Adrian Farrel >> Sent: Tuesday, May 10, 2016 12:15 PM >> To: 'Lou Berger'; teas@ietf.org >> Cc: draft-ietf-teas-interconnected-te-info-exchange.all@ietf.org; >> brian.e.carpenter@gmail.com >> Subject: Re: [Teas] Update to draft-ietf-teas-interconnected-te-info-exchange >> >> Brian (as the reviewer) and Deborah (as our AD) had an exchange of ideas. >> >> Deborah summarised the issue as: >> Section 5 and section 5.4 say that minor modifications to existing protocols would be >> necessary to fully satisfy this architecture, but the status of BCP implies that you can and do >> do things with existing tools. >> >> Furthermore, Deborah claims "the solution described in this document doesn't require any >> modifications to the protocols. " >> >> Deborah proposed three changes... >> >> 1. Section 6 title change from "Applicability to Optical Domains and Networks" >> to "An Abstraction Solution for Optical Domains and Networks" >> 2. Section 7 title change from "Modeling the User-to-Network Interface" to "Abstraction in >> the User-to-Network Interface" >> 3. Some rewording of section 5 to preclude additional protocol work to be consistent with >> the concept of a BCP. >> >> I am pushing back on these changes. Part of this is philosophical - an architecture tells you >> how to build stuff and IMHO this can be normative. I think that makes the document >> Standards Track, but whatever the result of that discussion, I think it is fine for an >> architecture to point out that protocol work is still needed. >> >> But the main push-back is to be correct! >> >> Sections 6 and 7 describe how the architecture fits the with specific network deployments. >> While those sections describe how some protocols could be applied, they are not a solution, >> they are an application of the architecture. They could be re-titled "Applicability of The >> Architecture Described in This Document to Optical Domains and Networks" and "Modeling >> the User-to-Network Interface Using The Architecture Described in This Document" >> although those seem rather long-winded. >> >> Section 5 possibly does not go far enough as it is! It notes some relevant protocol work that >> has not been completed, but it does not build a comprehensive list. And it does that >> deliberately in order to not attempt to deliver or prejudge a solution. Mentioning that BGP- >> LS does not (yet) have an RFC that describes extensions for GMPLS networks is possibly >> over-reaching because no-one has said that it is a requirement to use BGP-LS to export >> abstractions of optical links. In any case, it would be wrong for this document to preclude >> additional protocol work. >> >> If all of that means that this is not a BCP, that's OK. It is what it is. >> If it is still the opinion of our leaders (who have to support publication) that this is not >> Standards Track, that's OK too. >> We may end up as Informational. >> >> However, there is zero value in us doing either of: >> - Changing the document that we wanted to publish just to make it match a particular >> publication track. >> - Trying to second-guess the IESG. They may say BCP is OK as written. They might ask us to >> make more changes even after the ones Deborah suggests. >> >> The former is the tail wagging the dog. >> The latter is whack-a-mole. >> >> Cheers, >> Adrian >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: 10 May 2016 14:45 >>> To: adrian@olddog.co.uk; teas@ietf.org >>> Cc: draft-ietf-teas-interconnected-te-info-exchange.all@ietf.org; >>> brian.e.carpenter@gmail.com; Hilarie Orman >>> Subject: Re: [Teas] Update to >>> draft-ietf-teas-interconnected-te-info-exchange >>> >>> Adrian, Authors, >>> Thank you got all the hard work to get the document to this point. >>> The end objective is almost here! >>> >>> Can you recap exactly what change is being proposed to address Brian's >>> comment? >>> >>> Thank you, >>> Lou >>> >>> On 5/10/2016 9:04 AM, Adrian Farrel wrote: >>>> Hi, >>>> >>>> I posted an update to this draft after the completion of IETF last call. >>>> >>>> We received a GenART review from Brian Carpenter and a SecDir review >>>> from Hilarie Orman. These gave rise to some changes and some email discussion. >>>> (Stewart's RtgDir review was handled in -05 before IETF last call >>>> started.) >>>> >>>> I believe we have closed down all points except one from Brian about >>>> whether >>> the >>>> content and precise wording is consistent with the document as a >>>> BCP. At the moment I am reluctant to change the text to make it >>>> consistent with the >>> chosen >>>> publication track (especially since the authors originally proposed >> Standards >>>> Track not BFP) and prefer to find the correct track for the current >> document. >>> My >>>> reasoning is two-fold: >>>> >>>> - This is the document that we (the WG) wanted to publish. Changing the >>>> text to suit the publication track seems to be back-to-front. >>>> >>>> - IESG review has a likelihood of changing the publication track again or >>>> wanting more changes to keep it as a BCP. I would prefer to see all of >>>> these changes in one batch rather than trickling them in. >>>> >>>> The Diff will show a few more changes than expected because the >>>> layout >>> changed >>>> so that figures don't fall on page breaks. >>>> >>>> Cheers, >>>> Adrian >>>> >>>>> -----Original Message----- >>>>> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of >>>> internet-drafts@ietf.org >>>>> Sent: 10 May 2016 13:56 >>>>> To: i-d-announce@ietf.org >>>>> Cc: teas@ietf.org >>>>> Subject: [Teas] I-D Action: >> draft-ietf-teas-interconnected-te-info-exchange- >>>>> 06.txt >>>>> >>>>> >>>>> 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 of >>>>> the IETF. >>>>> >>>>> Title : Problem Statement and Architecture for >> Information >>>> Exchange >>>>> Between Interconnected Traffic Engineered Networks >>>>> Authors : Adrian Farrel >>>>> John Drake >>>>> Nabil Bitar >>>>> George Swallow >>>>> Daniele Ceccarelli >>>>> Xian Zhang >>>>> Filename : draft-ietf-teas-interconnected-te-info-exchange-06.txt >>>>> Pages : 61 >>>>> Date : 2016-05-10 >>>>> >>>>> Abstract: >>>>> In Traffic Engineered (TE) systems, it is sometimes desirable to >>>>> establish an end-to-end TE path with a set of constraints (such as >>>>> bandwidth) across one or more network from a source to a destination. >>>>> TE information is the data relating to nodes and TE links that is >>>>> used in the process of selecting a TE path. TE information is >>>>> usually only available within a network. We call such a zone of >>>>> visibility of TE information a domain. An example of a domain may be >>>>> an IGP area or an Autonomous System. >>>>> >>>>> In order to determine the potential to establish a TE path through a >>>>> series of connected networks, it is necessary to have available a >>>>> certain amount of TE information about each network. This need not >>>>> be the full set of TE information available within each network, but >>>>> does need to express the potential of providing TE connectivity. This >>>>> subset of TE information is called TE reachability information. >>>>> >>>>> This document sets out the problem statement for the exchange of TE >>>>> information between interconnected TE networks in support of end-to- >>>>> end TE path establishment and describes the best current practice >>>>> architecture to meet this problem statement. For reasons that are >>>>> explained in the document, this work is limited to simple TE >>>>> constraints and information that determine TE reachability. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-teas-interconnected-te- >>>>> info- >>>>> exchange/ >>>>> >>>>> There's also a htmlized version available at: >>>>> >> https://tools.ietf.org/html/draft-ietf-teas-interconnected-te-info-exchange- >>> 06 >>>>> >>>>> A diff from the previous version is available at: >>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-interconnected-te >>>>> -info- >>>>> exchange-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/ >>>>> >>>>> _______________________________________________ >>>>> Teas mailing list >>>>> Teas@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/teas >>>> _______________________________________________ >>>> Teas mailing list >>>> Teas@ietf.org >>>> https://www.ietf.org/mailman/listinfo/teas >>>> >> >> >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas > From nobody Wed May 11 12:49:40 2016 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 9D43112D7F2; Wed, 11 May 2016 12:49:39 -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] 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 gSjm9L1En7do; Wed, 11 May 2016 12:49:29 -0700 (PDT) Received: from newdragon.webhostserver.biz (newdragon.webhostserver.biz [69.25.136.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CF4412D7FD; Wed, 11 May 2016 12:49:29 -0700 (PDT) Received: from [::1] (port=59172) by newdragon.webhostserver.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.86_1) (envelope-from ) id 1b0a8O-0003P8-5k; Wed, 11 May 2016 23:49:28 +0400 To: adrian@olddog.co.uk, teas@ietf.org References: <016001d1aabc$8647efd0$92d7cf70$@olddog.co.uk> <5731E5C9.5030009@labn.net> <01d901d1aad7$2547ad40$6fd707c0$@olddog.co.uk> From: Lou Berger Message-ID: <57338CC6.2010300@labn.net> Date: Wed, 11 May 2016 15:49:26 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <01d901d1aad7$2547ad40$6fd707c0$@olddog.co.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - newdragon.webhostserver.biz X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Get-Message-Sender-Via: newdragon.webhostserver.biz: authenticated_id: lberger@blabn.com X-Authenticated-Sender: newdragon.webhostserver.biz: lberger@blabn.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: draft-ietf-teas-interconnected-te-info-exchange.all@ietf.org, brian.e.carpenter@gmail.com Subject: Re: [Teas] Update to draft-ietf-teas-interconnected-te-info-exchange X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 11 May 2016 19:49:39 -0000 Authors, WG, So, I've been doing a bit of archeology on this one. some key aspects from the threads (and of course without full context): On 5/4/2016 1:25 AM, Brian E Carpenter wrote: > I find it hard to read the introduction to this section and understand > why the draft is proposed for BCP rather than Informational. For example, ... On 5/4/2016 7:02 PM, BRUNGARD, DEBORAH A wrote: > ...To help the reader, I'd say section 6's and section 7's headers > should be more clearly labelled "An Abstraction Solution for Optical > Domains and Networks" and for section 7 "Abstraction in the > User-to-Network Interface". And these titles will align better with > Section 8 "Abstraction in L3VPN...". On 5/4/2016 8:48 PM, Brian E Carpenter wrote: > Yes. Basically it needs to be clear that the architecture can be 100% > implemented using current specifications, and that the possible extensions > are not required for this (and are therefore not really part of the core of > the BCP). So the discussion goes on for a bit, but I think the fundamental comment is a fair one: ** That the document needs to clearly delineate what can be done today, and what might be useful (extensions) in the future. This holds even if the document were to be published as the authors viewpoint is held to publish as PS -- which BTW is not a topic of this message/thread. Before getting into any details on specific changes to the document, I think it would be good to get WG opinion/consensus on this one point, see ** above. Does anyone object to, or care to comment on, clarifying this one point? Thanks, Lou On 5/10/2016 12:15 PM, Adrian Farrel wrote: > Brian (as the reviewer) and Deborah (as our AD) had an exchange of ideas. > > Deborah summarised the issue as: > Section 5 and section 5.4 say that minor modifications to existing protocols > would be necessary to fully satisfy this architecture, but the status of BCP > implies that you can and do do things with existing tools. > > Furthermore, Deborah claims "the solution described in this document doesn't > require any modifications to the protocols. " > > Deborah proposed three changes... > > 1. Section 6 title change from "Applicability to Optical Domains and Networks" > to "An Abstraction Solution for Optical Domains and Networks" > 2. Section 7 title change from "Modeling the User-to-Network Interface" to > "Abstraction in the User-to-Network Interface" > 3. Some rewording of section 5 to preclude additional protocol work to be > consistent with the concept of a BCP. > > I am pushing back on these changes. Part of this is philosophical - an > architecture tells you how to build stuff and IMHO this can be normative. I > think that makes the document Standards Track, but whatever the result of that > discussion, I think it is fine for an architecture to point out that protocol > work is still needed. > > But the main push-back is to be correct! > > Sections 6 and 7 describe how the architecture fits the with specific network > deployments. While those sections describe how some protocols could be applied, > they are not a solution, they are an application of the architecture. They could > be re-titled "Applicability of The Architecture Described in This Document to > Optical Domains and Networks" and "Modeling the User-to-Network Interface Using > The Architecture Described in This Document" although those seem rather > long-winded. > > Section 5 possibly does not go far enough as it is! It notes some relevant > protocol work that has not been completed, but it does not build a comprehensive > list. And it does that deliberately in order to not attempt to deliver or > prejudge a solution. Mentioning that BGP-LS does not (yet) have an RFC that > describes extensions for GMPLS networks is possibly over-reaching because no-one > has said that it is a requirement to use BGP-LS to export abstractions of > optical links. In any case, it would be wrong for this document to preclude > additional protocol work. > > If all of that means that this is not a BCP, that's OK. It is what it is. > If it is still the opinion of our leaders (who have to support publication) that > this is not Standards Track, that's OK too. > We may end up as Informational. > > However, there is zero value in us doing either of: > - Changing the document that we wanted to publish just to make it match a > particular publication track. > - Trying to second-guess the IESG. They may say BCP is OK as written. They might > ask us to make more changes even after the ones Deborah suggests. > > The former is the tail wagging the dog. > The latter is whack-a-mole. > > Cheers, > Adrian >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: 10 May 2016 14:45 >> To: adrian@olddog.co.uk; teas@ietf.org >> Cc: draft-ietf-teas-interconnected-te-info-exchange.all@ietf.org; >> brian.e.carpenter@gmail.com; Hilarie Orman >> Subject: Re: [Teas] Update to draft-ietf-teas-interconnected-te-info-exchange >> >> Adrian, Authors, >> Thank you got all the hard work to get the document to this point. >> The end objective is almost here! >> >> Can you recap exactly what change is being proposed to address Brian's >> comment? >> >> Thank you, >> Lou >> >> On 5/10/2016 9:04 AM, Adrian Farrel wrote: >>> Hi, >>> >>> I posted an update to this draft after the completion of IETF last call. >>> >>> We received a GenART review from Brian Carpenter and a SecDir review from >>> Hilarie Orman. These gave rise to some changes and some email discussion. >>> (Stewart's RtgDir review was handled in -05 before IETF last call started.) >>> >>> I believe we have closed down all points except one from Brian about whether >> the >>> content and precise wording is consistent with the document as a BCP. At the >>> moment I am reluctant to change the text to make it consistent with the >> chosen >>> publication track (especially since the authors originally proposed > Standards >>> Track not BFP) and prefer to find the correct track for the current > document. >> My >>> reasoning is two-fold: >>> >>> - This is the document that we (the WG) wanted to publish. Changing the >>> text to suit the publication track seems to be back-to-front. >>> >>> - IESG review has a likelihood of changing the publication track again or >>> wanting more changes to keep it as a BCP. I would prefer to see all of >>> these changes in one batch rather than trickling them in. >>> >>> The Diff will show a few more changes than expected because the layout >> changed >>> so that figures don't fall on page breaks. >>> >>> Cheers, >>> Adrian >>> >>>> -----Original Message----- >>>> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of >>> internet-drafts@ietf.org >>>> Sent: 10 May 2016 13:56 >>>> To: i-d-announce@ietf.org >>>> Cc: teas@ietf.org >>>> Subject: [Teas] I-D Action: > draft-ietf-teas-interconnected-te-info-exchange- >>>> 06.txt >>>> >>>> >>>> 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 of >>>> the IETF. >>>> >>>> Title : Problem Statement and Architecture for > Information >>> Exchange >>>> Between Interconnected Traffic Engineered Networks >>>> Authors : Adrian Farrel >>>> John Drake >>>> Nabil Bitar >>>> George Swallow >>>> Daniele Ceccarelli >>>> Xian Zhang >>>> Filename : draft-ietf-teas-interconnected-te-info-exchange-06.txt >>>> Pages : 61 >>>> Date : 2016-05-10 >>>> >>>> Abstract: >>>> In Traffic Engineered (TE) systems, it is sometimes desirable to >>>> establish an end-to-end TE path with a set of constraints (such as >>>> bandwidth) across one or more network from a source to a destination. >>>> TE information is the data relating to nodes and TE links that is >>>> used in the process of selecting a TE path. TE information is >>>> usually only available within a network. We call such a zone of >>>> visibility of TE information a domain. An example of a domain may be >>>> an IGP area or an Autonomous System. >>>> >>>> In order to determine the potential to establish a TE path through a >>>> series of connected networks, it is necessary to have available a >>>> certain amount of TE information about each network. This need not >>>> be the full set of TE information available within each network, but >>>> does need to express the potential of providing TE connectivity. This >>>> subset of TE information is called TE reachability information. >>>> >>>> This document sets out the problem statement for the exchange of TE >>>> information between interconnected TE networks in support of end-to- >>>> end TE path establishment and describes the best current practice >>>> architecture to meet this problem statement. For reasons that are >>>> explained in the document, this work is limited to simple TE >>>> constraints and information that determine TE reachability. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-teas-interconnected-te-info- >>>> exchange/ >>>> >>>> There's also a htmlized version available at: >>>> > https://tools.ietf.org/html/draft-ietf-teas-interconnected-te-info-exchange- >> 06 >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-interconnected-te-info- >>>> exchange-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/ >>>> >>>> _______________________________________________ >>>> Teas mailing list >>>> Teas@ietf.org >>>> https://www.ietf.org/mailman/listinfo/teas >>> _______________________________________________ >>> Teas mailing list >>> Teas@ietf.org >>> https://www.ietf.org/mailman/listinfo/teas >>> > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > From nobody Wed May 11 13:29:37 2016 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 6F1C412D80C; Wed, 11 May 2016 13:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 J7WLhgjxaMBS; Wed, 11 May 2016 13:29:34 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0785.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:785]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4167512B04B; Wed, 11 May 2016 13:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Zg9lx+mQg8zu/NhrVGqx3aIZQ+4alzA4GzXVn6RhCPY=; b=cef4qJikS4IhWjaFtEYg91/xxVUNOaxQy509E6GyrP6onj45irar5O9+pzoeYeWZ8nGImWDsskJalmBsqZOz9wsS1Va4OOigkdT1QCSwBPdcm0P9lnd4TY1ZbOG/G682P6E6UTOhcNRDXfiJ51QnAAiA2CNFWEv1/9Zi5lGZibg= Received: from SN1PR0501MB1709.namprd05.prod.outlook.com (10.163.130.155) by SN1PR0501MB1711.namprd05.prod.outlook.com (10.163.130.157) with Microsoft SMTP Server (TLS) id 15.1.492.11; Wed, 11 May 2016 20:29:14 +0000 Received: from SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) by SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) with mapi id 15.01.0492.016; Wed, 11 May 2016 20:29:14 +0000 From: John E Drake To: Lou Berger , "adrian@olddog.co.uk" , "teas@ietf.org" Thread-Topic: [Teas] Update to draft-ietf-teas-interconnected-te-info-exchange Thread-Index: AdGqvH7KKcee39rDSomF0LywguTC2wABZtiAAAVCeIAAOcVBAAAA9a9w Date: Wed, 11 May 2016 20:29:14 +0000 Message-ID: References: <016001d1aabc$8647efd0$92d7cf70$@olddog.co.uk> <5731E5C9.5030009@labn.net> <01d901d1aad7$2547ad40$6fd707c0$@olddog.co.uk> <57338CC6.2010300@labn.net> In-Reply-To: <57338CC6.2010300@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: labn.net; dkim=none (message not signed) header.d=none;labn.net; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.14] x-ms-office365-filtering-correlation-id: a46d5b8b-f12b-4353-321d-08d379daeb5d x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1711; 5:PiglzNxUZO9fwpcG+n2jFGlY/BVLoW6q9kzUzHioxBkP2ZBRdDz2UALijH+inLAteDSI176n/TjBUCAf44UKu03xHX6wwDmYWSEPZq2Q8exiXd6rNba4jgsdJHPfkWKoWQ7cP0xTTm3E6T4FtolkuA==; 24:Q3sEMeVJHB0CTitGx0UPG3HZsDcpYMT3a+ZkkKMI2PuvZh3ApD0nvV23F7wX1CfabtZNWARQvUeNklrbJyeTqN3TIKwCXykcF8bD/PoJKaA=; 7:C5Jbud0YWR7auUcJjpbUPeAO6/iySbv3xeNAhbKiLoTfLiDw0baAk8huxpY6bZdhJ7tbgpCG4GAy4QvGvirlYKO+yn9Vqlc9gLg9wqVNWUemyIsXvrNmlmeQqmgybCLnRe5IyDpmnuxuKVjsQlKekcX+OwlLloED5E4sF7kQP776uhve6ij3TfFMH5e2N38L x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB1711; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:SN1PR0501MB1711; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1711; x-forefront-prvs: 0939529DE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(5002640100001)(87936001)(5003600100002)(189998001)(66066001)(77096005)(230783001)(99286002)(50986999)(4326007)(2201001)(54356999)(86362001)(33656002)(2906002)(8936002)(93886004)(81166006)(76176999)(76576001)(586003)(1220700001)(5001770100001)(6116002)(3846002)(102836003)(3280700002)(5004730100002)(5008740100001)(15650500001)(11100500001)(3660700001)(2501003)(74316001)(9686002)(2950100001)(122556002)(2900100001)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1711; H:SN1PR0501MB1709.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2016 20:29:14.7488 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1711 Archived-At: Cc: "draft-ietf-teas-interconnected-te-info-exchange.all@ietf.org" , "brian.e.carpenter@gmail.com" Subject: Re: [Teas] Update to draft-ietf-teas-interconnected-te-info-exchange X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 11 May 2016 20:29:36 -0000 Lou, Snipped, comment inline Yours Irrespectively, John > On 5/4/2016 8:48 PM, Brian E Carpenter wrote: > > Yes. Basically it needs to be clear that the architecture can be 100% > > implemented using current specifications, and that the possible > > extensions are not required for this (and are therefore not really > > part of the core of the BCP). >=20 > So the discussion goes on for a bit, but I think the fundamental comment = is a fair one: >=20 > ** That the document needs to clearly delineate what can be done today, a= nd what might > be useful (extensions) in the future. [JD] This is not my reading of what Brian said. My reading is that he sa= id that if it were to=20 be published as a BCP it would have to clearly state that the architecture = it describes can be completely implemented using current specifications Your reformulation is fundamentally different and, from what Brian writes, = incompatible with the definition of a BCP =20 >=20 > This holds even if the document were to be published as the authors viewp= oint is held to > publish as PS -- which BTW is not a topic of this message/thread. [JD] From what I have read, both the above statement and your reformulatio= n of Brian's comment are strictly and solely your own opinion =20 From nobody Wed May 11 13:40:38 2016 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 B0B7112D5EF; Wed, 11 May 2016 13:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNm45YkxflMa; Wed, 11 May 2016 13:40:35 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF61312D514; Wed, 11 May 2016 13:40:34 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id 77so22163565pfv.2; Wed, 11 May 2016 13:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=K5ckdr1fdS5Sp5zwMDPolthDcq/L4LuK22VLwDh6PX4=; b=I/t2k+F9oyMx1X7Ygp0UFgWCOSOiJkFxiupz4BSlGy9ZN1LEOoWboIXMXyvI+TevfC bdVqA8m5gQP/K2QPcbEGnw2EiZ1fTm0URz7vfzsDqgKMVSEH/Xvnz9LMM7ZR1OOBaTka u5Fz6mlaHmpLZPiDkvsQ4C2SxTIHtuYI78U4TkC5C54JKaZ006ph6KX5pGGxFZYeVb3q g+ZWJV5aGObLPBAHOx0beWf3C0SSvM85wKocoLzvuYyw6JPjuB9S19BFnL7RQc/o035V MJntf1hn5ujmu3tGhEtpuYOtdNu2O4Up62LEzXDOdnnxVQTN6z/75W8PiPv/bq47Q0ex izMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=K5ckdr1fdS5Sp5zwMDPolthDcq/L4LuK22VLwDh6PX4=; b=llaLDGUZ9E/nuEG5fjfg1d1uF7/1cEwJgqfT3hMELZZ6XBMBZiXr11lKQtWDYNjaUy L6+kfZ5sG9sXsA0ZRBNaNTEDabcflqgaB4MOBO27m8p8wAO6XbnVNvbaLSevkEb0YEEM t8jvRaQ5SXzqM1CoR4DxlvMoHGZ2pihzoYklnJovIUWHKe0XHL1lg51S/NzjagG+BagV DDKzaGNaa8Icbn4xWN76rEpx1vHKlAoH4E/fcG/jkS/R0TTW2Vt4ZffdZxf7Pdv1zMs9 4eN6lDjIbqA9SlZ9dEXou1/XZpopkWUfHNICNdY14gwXAZbYY3pSsek+T34kW78vmuzk I8Ug== X-Gm-Message-State: AOPr4FWpL5LeM+bEKRQqDygHKu+Ivn4gCf3Ot/nKeMsRfIkGqqDYizlOUY39onijIDayxA== X-Received: by 10.98.85.195 with SMTP id j186mr8125778pfb.50.1462999234508; Wed, 11 May 2016 13:40:34 -0700 (PDT) Received: from ?IPv6:2406:e007:5004:1:28cc:dc4c:9703:6781? ([2406:e007:5004:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id x123sm14298615pfb.54.2016.05.11.13.40.31 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 May 2016 13:40:33 -0700 (PDT) To: John E Drake , Lou Berger , "adrian@olddog.co.uk" , "teas@ietf.org" References: <016001d1aabc$8647efd0$92d7cf70$@olddog.co.uk> <5731E5C9.5030009@labn.net> <01d901d1aad7$2547ad40$6fd707c0$@olddog.co.uk> <57338CC6.2010300@labn.net> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 12 May 2016 08:40:55 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-teas-interconnected-te-info-exchange.all@ietf.org" Subject: Re: [Teas] Update to draft-ietf-teas-interconnected-te-info-exchange X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 11 May 2016 20:40:37 -0000 On 12/05/2016 08:29, John E Drake wrote: > Lou, > > Snipped, comment inline > > Yours Irrespectively, > > John > >> On 5/4/2016 8:48 PM, Brian E Carpenter wrote: >>> Yes. Basically it needs to be clear that the architecture can be 100% >>> implemented using current specifications, and that the possible >>> extensions are not required for this (and are therefore not really >>> part of the core of the BCP). >> >> So the discussion goes on for a bit, but I think the fundamental comment is a fair one: >> >> ** That the document needs to clearly delineate what can be done today, and what might >> be useful (extensions) in the future. > > > [JD] This is not my reading of what Brian said. My reading is that he said that if it were to > be published as a BCP it would have to clearly state that the architecture it describes can > be completely implemented using current specifications > > Your reformulation is fundamentally different and, from what Brian writes, incompatible > with the definition of a BCP You can include non-normative sections in a BCP or standards track document, as long as they are clearly identified as non-normative. I don't think this would be hard to do - it's just annotation of the existing text, not a rewrite or any change to what I understand to be the WG consensus. Brian > > >> >> This holds even if the document were to be published as the authors viewpoint is held to >> publish as PS -- which BTW is not a topic of this message/thread. > > > [JD] From what I have read, both the above statement and your reformulation of Brian's > comment are strictly and solely your own opinion > > > From nobody Wed May 11 13:46:54 2016 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 2838B12D5EA for ; Wed, 11 May 2016 13:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 ywxL4UoaucV5 for ; Wed, 11 May 2016 13:46:45 -0700 (PDT) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 2590F12B01E for ; Wed, 11 May 2016 13:46:45 -0700 (PDT) Received: (qmail 18244 invoked by uid 0); 11 May 2016 20:46:41 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy7.mail.unifiedlayer.com with SMTP; 11 May 2016 20:46:41 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id t8ma1s00D2SSUrH018mdhk; Wed, 11 May 2016 14:46:39 -0600 X-Authority-Analysis: v=2.1 cv=Nal1iQz4 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=yrkiwgmsf1kA:10 a=48vgC7mUAAAA:8 a=HIdiRbk3N60f9sRGXskA:9 a=pILNOxqGKmIA:10 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject; bh=GKN5soOBJ6mSVnd5vcEL+z/BNjNA884xeQARPa/7KKo=; b=HqGWEAUoJUYV7ym7IVaArJ7MlE A+6aNXj8ACltyHtXei+AU4Ld759mBBtv3VKqxSqqpI01kO0eHHKMe83gCUiooR1TEfrkAcIB1ycqO OnmlO/qB+UGNiVUJHxFJPXUV+; Received: from box313.bluehost.com ([69.89.31.113]:51418 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1b0b1g-0004lm-2h; Wed, 11 May 2016 14:46:36 -0600 To: Brian E Carpenter , John E Drake , "adrian@olddog.co.uk" , "teas@ietf.org" References: <016001d1aabc$8647efd0$92d7cf70$@olddog.co.uk> <5731E5C9.5030009@labn.net> <01d901d1aad7$2547ad40$6fd707c0$@olddog.co.uk> <57338CC6.2010300@labn.net> From: Lou Berger Message-ID: <57339A26.8070909@labn.net> Date: Wed, 11 May 2016 16:46:30 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: "draft-ietf-teas-interconnected-te-info-exchange.all@ietf.org" Subject: Re: [Teas] Update to draft-ietf-teas-interconnected-te-info-exchange X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 11 May 2016 20:46:52 -0000 Brian, Thanks for the quick response. Would addressing the following address your objection? ** That the document needs to clearly delineate what can be done today, and what might be useful (extensions) in the future. Thank you, Lou On 5/11/2016 4:40 PM, Brian E Carpenter wrote: > On 12/05/2016 08:29, John E Drake wrote: >> Lou, >> >> Snipped, comment inline >> >> Yours Irrespectively, >> >> John >> >>> On 5/4/2016 8:48 PM, Brian E Carpenter wrote: >>>> Yes. Basically it needs to be clear that the architecture can be 100% >>>> implemented using current specifications, and that the possible >>>> extensions are not required for this (and are therefore not really >>>> part of the core of the BCP). >>> So the discussion goes on for a bit, but I think the fundamental comment is a fair one: >>> >>> ** That the document needs to clearly delineate what can be done today, and what might >>> be useful (extensions) in the future. >> >> [JD] This is not my reading of what Brian said. My reading is that he said that if it were to >> be published as a BCP it would have to clearly state that the architecture it describes can >> be completely implemented using current specifications >> >> Your reformulation is fundamentally different and, from what Brian writes, incompatible >> with the definition of a BCP > You can include non-normative sections in a BCP or standards track document, > as long as they are clearly identified as non-normative. I don't think this would > be hard to do - it's just annotation of the existing text, not a rewrite or > any change to what I understand to be the WG consensus. > > Brian > >> >>> This holds even if the document were to be published as the authors viewpoint is held to >>> publish as PS -- which BTW is not a topic of this message/thread. >> >> [JD] From what I have read, both the above statement and your reformulation of Brian's >> comment are strictly and solely your own opinion >> >> >> > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > From nobody Wed May 11 13:50:25 2016 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 7C2CD12D5C4; Wed, 11 May 2016 13:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 yojBP2RyXVUB; Wed, 11 May 2016 13:50:20 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0760.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::760]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA25612D1DE; Wed, 11 May 2016 13:50:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=y6UdRXD+rwA5OHIFzK+W1YztSfGH7cD4/OgY5H/54Qo=; b=WUIGt676sKHtOLOuRZXjcS1e2/uME+Mn/ka39yVRB71DCBIafhxnTmSfjpBk3jekYyJt+6FNI96tRcacRgIzlxo5jsvhY4fUGw/s1yOHRlqtLokXqzeHaHvosKJtjjW1JzelS/Vo+YoDFpLv8RTi87LHX8xuZ3ZWa/u/Apu+Q8Y= Received: from SN1PR0501MB1709.namprd05.prod.outlook.com (10.163.130.155) by SN1PR0501MB1710.namprd05.prod.outlook.com (10.163.130.156) with Microsoft SMTP Server (TLS) id 15.1.492.11; Wed, 11 May 2016 20:49:59 +0000 Received: from SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) by SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) with mapi id 15.01.0492.016; Wed, 11 May 2016 20:49:59 +0000 From: John E Drake To: Brian E Carpenter , Lou Berger , "adrian@olddog.co.uk" , "teas@ietf.org" Thread-Topic: [Teas] Update to draft-ietf-teas-interconnected-te-info-exchange Thread-Index: AdGqvH7KKcee39rDSomF0LywguTC2wABZtiAAAVCeIAAOcVBAAAA9a9wAADWnYAAACmSEA== Date: Wed, 11 May 2016 20:49:59 +0000 Message-ID: References: <016001d1aabc$8647efd0$92d7cf70$@olddog.co.uk> <5731E5C9.5030009@labn.net> <01d901d1aad7$2547ad40$6fd707c0$@olddog.co.uk> <57338CC6.2010300@labn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.14] x-ms-office365-filtering-correlation-id: bfa1b451-0ab2-4c45-8b02-08d379ddd11b x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1710; 5:YiSp0/ptDWaHVIss9pzU6q+YuIBIBlpmoqi+3jzDC9NJSEmlumSjDvbYUf/O4n0Fmf3rl3MxFJPLpUxEd7SrpS8UWu9waMr5RN0DZ5oynIYFsmU8L7fuUuHlfMfkzAFLb80wcr/bBHFstXh6MitP9g==; 24:O2c0vyfBhWzv6+iODA9e/OTYVVUZBomnXkyCAQxezvR9pfo+6M/HpLR8HB0YkJQpYbJDVgWH4mE9xqPSGorQoRkopad99lRkJoR+kSfXRJs=; 7:Spl4AloJxCJIDAFYeB2LG0GoU+t6Q8gth9oZcWJ2Lb6cKcHiTYkyYkZsDskV+cmUpGjsI73B1Q35PZmfdlXsn5/nY44DSkW8PoQbKwVJiLACWplm5D2RpDF/Y/IJCcXuZgzZs+/Yu4HTgbNNno+6S3HfZand9wv/PqBJnTPAdtkZzlWTdZvcVZxPgAuI/d9f x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB1710; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:SN1PR0501MB1710; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1710; x-forefront-prvs: 0939529DE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(13464003)(86362001)(122556002)(11100500001)(3660700001)(3280700002)(9686002)(2501003)(2906002)(54356999)(87936001)(50986999)(76176999)(2900100001)(33656002)(230783001)(5004730100002)(76576001)(5008740100001)(2950100001)(99286002)(5002640100001)(6116002)(92566002)(1220700001)(66066001)(102836003)(5001770100001)(5003600100002)(77096005)(189998001)(93886004)(8936002)(74316001)(4326007)(19580405001)(19580395003)(3846002)(2201001)(15650500001)(81166006)(586003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1710; H:SN1PR0501MB1709.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2016 20:49:59.0785 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1710 Archived-At: Cc: "draft-ietf-teas-interconnected-te-info-exchange.all@ietf.org" Subject: Re: [Teas] Update to draft-ietf-teas-interconnected-te-info-exchange X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 11 May 2016 20:50:23 -0000 QnJpYW4sDQoNCkkgdGhpbmsgdGhpcyBpcyB2ZXJ5IHVzZWZ1bCBhZHZpY2UuICAgIA0KDQpZb3Vy cyBJcnJlc3BlY3RpdmVseSwNCg0KSm9obg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IEJyaWFuIEUgQ2FycGVudGVyIFttYWlsdG86YnJpYW4uZS5jYXJwZW50ZXJAZ21h aWwuY29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIE1heSAxMSwgMjAxNiA0OjQxIFBNDQo+IFRvOiBK b2huIEUgRHJha2U7IExvdSBCZXJnZXI7IGFkcmlhbkBvbGRkb2cuY28udWs7IHRlYXNAaWV0Zi5v cmcNCj4gQ2M6IGRyYWZ0LWlldGYtdGVhcy1pbnRlcmNvbm5lY3RlZC10ZS1pbmZvLWV4Y2hhbmdl LmFsbEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW1RlYXNdIFVwZGF0ZSB0byBkcmFmdC1pZXRm LXRlYXMtaW50ZXJjb25uZWN0ZWQtdGUtaW5mby1leGNoYW5nZQ0KPiANCj4gT24gMTIvMDUvMjAx NiAwODoyOSwgSm9obiBFIERyYWtlIHdyb3RlOg0KPiA+IExvdSwNCj4gPg0KPiA+IFNuaXBwZWQs IGNvbW1lbnQgaW5saW5lDQo+ID4NCj4gPiBZb3VycyBJcnJlc3BlY3RpdmVseSwNCj4gPg0KPiA+ IEpvaG4NCj4gPg0KPiA+PiBPbiA1LzQvMjAxNiA4OjQ4IFBNLCBCcmlhbiBFIENhcnBlbnRlciB3 cm90ZToNCj4gPj4+IFllcy4gQmFzaWNhbGx5IGl0IG5lZWRzIHRvIGJlIGNsZWFyIHRoYXQgdGhl IGFyY2hpdGVjdHVyZSBjYW4gYmUNCj4gPj4+IDEwMCUgaW1wbGVtZW50ZWQgdXNpbmcgY3VycmVu dCBzcGVjaWZpY2F0aW9ucywgYW5kIHRoYXQgdGhlIHBvc3NpYmxlDQo+ID4+PiBleHRlbnNpb25z IGFyZSBub3QgcmVxdWlyZWQgZm9yIHRoaXMgKGFuZCBhcmUgdGhlcmVmb3JlIG5vdCByZWFsbHkN Cj4gPj4+IHBhcnQgb2YgdGhlIGNvcmUgb2YgdGhlIEJDUCkuDQo+ID4+DQo+ID4+IFNvIHRoZSBk aXNjdXNzaW9uIGdvZXMgb24gZm9yIGEgYml0LCBidXQgSSB0aGluayB0aGUgZnVuZGFtZW50YWwg Y29tbWVudCBpcyBhIGZhaXIgb25lOg0KPiA+Pg0KPiA+PiAqKiBUaGF0IHRoZSBkb2N1bWVudCBu ZWVkcyB0byBjbGVhcmx5IGRlbGluZWF0ZSB3aGF0IGNhbiBiZSBkb25lDQo+ID4+IHRvZGF5LCBh bmQgd2hhdCBtaWdodCBiZSB1c2VmdWwgKGV4dGVuc2lvbnMpIGluIHRoZSBmdXR1cmUuDQo+ID4N Cj4gPg0KPiA+IFtKRF0gIFRoaXMgaXMgbm90IG15IHJlYWRpbmcgb2Ygd2hhdCBCcmlhbiBzYWlk LiAgTXkgcmVhZGluZyBpcyB0aGF0DQo+ID4gaGUgc2FpZCB0aGF0IGlmIGl0IHdlcmUgdG8gYmUg cHVibGlzaGVkIGFzIGEgQkNQIGl0IHdvdWxkIGhhdmUgdG8NCj4gPiBjbGVhcmx5IHN0YXRlIHRo YXQgdGhlIGFyY2hpdGVjdHVyZSBpdCBkZXNjcmliZXMgY2FuIGJlIGNvbXBsZXRlbHkNCj4gPiBp bXBsZW1lbnRlZCB1c2luZyBjdXJyZW50IHNwZWNpZmljYXRpb25zDQo+ID4NCj4gPiBZb3VyIHJl Zm9ybXVsYXRpb24gaXMgZnVuZGFtZW50YWxseSBkaWZmZXJlbnQgYW5kLCBmcm9tIHdoYXQgQnJp YW4NCj4gPiB3cml0ZXMsIGluY29tcGF0aWJsZSB3aXRoIHRoZSBkZWZpbml0aW9uIG9mIGEgQkNQ DQo+IA0KPiBZb3UgY2FuIGluY2x1ZGUgbm9uLW5vcm1hdGl2ZSBzZWN0aW9ucyBpbiBhIEJDUCBv ciBzdGFuZGFyZHMgdHJhY2sgZG9jdW1lbnQsIGFzIGxvbmcgYXMNCj4gdGhleSBhcmUgY2xlYXJs eSBpZGVudGlmaWVkIGFzIG5vbi1ub3JtYXRpdmUuIEkgZG9uJ3QgdGhpbmsgdGhpcyB3b3VsZCBi ZSBoYXJkIHRvIGRvIC0gaXQncyBqdXN0DQo+IGFubm90YXRpb24gb2YgdGhlIGV4aXN0aW5nIHRl eHQsIG5vdCBhIHJld3JpdGUgb3IgYW55IGNoYW5nZSB0byB3aGF0IEkgdW5kZXJzdGFuZCB0byBi ZSB0aGUNCj4gV0cgY29uc2Vuc3VzLg0KPiANCj4gICAgQnJpYW4NCj4gDQo+ID4NCj4gPg0KPiA+ Pg0KPiA+PiBUaGlzIGhvbGRzIGV2ZW4gaWYgdGhlIGRvY3VtZW50IHdlcmUgdG8gYmUgcHVibGlz aGVkIGFzIHRoZSBhdXRob3JzDQo+ID4+IHZpZXdwb2ludCBpcyBoZWxkIHRvIHB1Ymxpc2ggYXMg UFMgLS0gd2hpY2ggQlRXIGlzIG5vdCBhIHRvcGljIG9mIHRoaXMgbWVzc2FnZS90aHJlYWQuDQo+ ID4NCj4gPg0KPiA+IFtKRF0gIEZyb20gd2hhdCBJIGhhdmUgcmVhZCwgYm90aCB0aGUgYWJvdmUg c3RhdGVtZW50IGFuZCB5b3VyIHJlZm9ybXVsYXRpb24gb2YgQnJpYW4ncw0KPiA+IGNvbW1lbnQg YXJlIHN0cmljdGx5IGFuZCBzb2xlbHkgeW91ciBvd24gb3Bpbmlvbg0KPiA+DQo+ID4NCj4gPg0K From nobody Wed May 11 13:56:40 2016 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 3ECE512D6E9; Wed, 11 May 2016 13:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 vO33qJ_JkUKZ; Wed, 11 May 2016 13:56:32 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0121.outbound.protection.outlook.com [65.55.169.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83A6F12D753; Wed, 11 May 2016 13:56:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qXGZL6O8+weysKPkucru9ViHHdmoCLss5mqb1H9LCrk=; b=PkO8CG1vuXrIdlSkdyCKdzIvyfmJGNUgZSJGvFdGERX986qmeQQ+FLGE2w00bZmLNJYjjrlwTQinPDTcEHVLc1IstgoX65mehsP40B1zB0kpVQw41QbcFEKobAOJJRAsEm3sDycrH1KIm3yVkFJ5pXKHt5kyVQfi44lMzPmblvQ= Received: from SN1PR0501MB1709.namprd05.prod.outlook.com (10.163.130.155) by SN1PR0501MB1712.namprd05.prod.outlook.com (10.163.130.158) with Microsoft SMTP Server (TLS) id 15.1.492.11; Wed, 11 May 2016 20:56:30 +0000 Received: from SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) by SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) with mapi id 15.01.0492.016; Wed, 11 May 2016 20:56:30 +0000 From: John E Drake To: Lou Berger , Brian E Carpenter , "adrian@olddog.co.uk" , "teas@ietf.org" Thread-Topic: [Teas] Update to draft-ietf-teas-interconnected-te-info-exchange Thread-Index: AdGqvH7KKcee39rDSomF0LywguTC2wABZtiAAAVCeIAAOcVBAAAA9a9wAADWnYAAADHrAAAAO3Iw Date: Wed, 11 May 2016 20:56:30 +0000 Message-ID: References: <016001d1aabc$8647efd0$92d7cf70$@olddog.co.uk> <5731E5C9.5030009@labn.net> <01d901d1aad7$2547ad40$6fd707c0$@olddog.co.uk> <57338CC6.2010300@labn.net> <57339A26.8070909@labn.net> In-Reply-To: <57339A26.8070909@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: labn.net; dkim=none (message not signed) header.d=none;labn.net; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.14] x-ms-office365-filtering-correlation-id: 04a6442f-a528-4d1f-10b2-08d379deba1f x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1712; 5:TcL85O4rD6tCqZWVm+j70Yk9g4WaMle/8pzlI9d8I9wStOtVZeibabrbN8Pdr+bSi7/aYMg/eVu17OcuAcw7/6MRMykPpfca5gTTcDzTF8f0wHFCMR/hs8oJdHB4lEGgJh2cJGGwByLL2Kg0VJXwYw==; 24:2/12VJ1i0vbUHMb3iw9GhtmDInnwnBcTdxsWRAc4Dqb2qcXZI4lmuS9fWu/vBIOpioSFZ21Op1kmM077qewskZrortBcELpkIk3icKxIFd0=; 7:cRrrINccv+QR1a5rFYMLDI6SP8bV6vV7ya4PXESadQ+/+sZMXRHt/Co2T82TW2q3qvSeIN2tdRLcr+nWNgmgf2ehAo24GmDYKeYFPEoRxWq3R9lcA/YQSAvAtnd4SdAvSBYZnh8al/hKM0TjG+R7VzpIT8I6nTWmHdLv93EGJfCTPCkmK/AeNHOVBv8OFrw1 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB1712; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:SN1PR0501MB1712; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1712; x-forefront-prvs: 0939529DE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51914003)(24454002)(13464003)(377454003)(74316001)(15650500001)(99286002)(5001770100001)(77096005)(2900100001)(1220700001)(92566002)(8936002)(586003)(81166006)(3846002)(93886004)(6116002)(102836003)(2950100001)(15975445007)(76576001)(33656002)(5004730100002)(2201001)(122556002)(19580405001)(19580395003)(2501003)(86362001)(66066001)(5003600100002)(230783001)(4326007)(50986999)(9686002)(76176999)(5002640100001)(3660700001)(11100500001)(189998001)(2906002)(5008740100001)(3280700002)(87936001)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1712; H:SN1PR0501MB1709.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2016 20:56:30.0576 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1712 Archived-At: Cc: "draft-ietf-teas-interconnected-te-info-exchange.all@ietf.org" Subject: Re: [Teas] Update to draft-ietf-teas-interconnected-te-info-exchange X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 11 May 2016 20:56:37 -0000 Lou, What I thought Brian said was to mark sections as either normative or non-n= ormative and this seems clear to me. Your reformulation does not seem eith= er clear nor bounded in terms of effort.=20 Yours Irrespectively, John > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Wednesday, May 11, 2016 4:47 PM > To: Brian E Carpenter; John E Drake; adrian@olddog.co.uk; teas@ietf.org > Cc: draft-ietf-teas-interconnected-te-info-exchange.all@ietf.org > Subject: Re: [Teas] Update to draft-ietf-teas-interconnected-te-info-exch= ange >=20 > Brian, >=20 > Thanks for the quick response. Would addressing the following address yo= ur objection? >=20 > ** That the document needs to clearly delineate what can be done today, a= nd what might > be useful (extensions) in the future. >=20 >=20 > Thank you, > Lou >=20 > On 5/11/2016 4:40 PM, Brian E Carpenter wrote: > > On 12/05/2016 08:29, John E Drake wrote: > >> Lou, > >> > >> Snipped, comment inline > >> > >> Yours Irrespectively, > >> > >> John > >> > >>> On 5/4/2016 8:48 PM, Brian E Carpenter wrote: > >>>> Yes. Basically it needs to be clear that the architecture can be > >>>> 100% implemented using current specifications, and that the > >>>> possible extensions are not required for this (and are therefore > >>>> not really part of the core of the BCP). > >>> So the discussion goes on for a bit, but I think the fundamental comm= ent is a fair one: > >>> > >>> ** That the document needs to clearly delineate what can be done > >>> today, and what might be useful (extensions) in the future. > >> > >> [JD] This is not my reading of what Brian said. My reading is that > >> he said that if it were to be published as a BCP it would have to > >> clearly state that the architecture it describes can be completely > >> implemented using current specifications > >> > >> Your reformulation is fundamentally different and, from what Brian > >> writes, incompatible with the definition of a BCP > > You can include non-normative sections in a BCP or standards track > > document, as long as they are clearly identified as non-normative. I > > don't think this would be hard to do - it's just annotation of the > > existing text, not a rewrite or any change to what I understand to be t= he WG consensus. > > > > Brian > > > >> > >>> This holds even if the document were to be published as the authors > >>> viewpoint is held to publish as PS -- which BTW is not a topic of thi= s message/thread. > >> > >> [JD] From what I have read, both the above statement and your reformu= lation of Brian's > >> comment are strictly and solely your own opinion > >> > >> > >> > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org > > https://www.ietf.org/mailman/listinfo/teas > > >=20 From nobody Wed May 11 14:38:28 2016 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 A34F412D160; Wed, 11 May 2016 14:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xo3pdl5D36lp; Wed, 11 May 2016 14:38:23 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5829112D141; Wed, 11 May 2016 14:38:22 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id u4BLcKmH009720; Wed, 11 May 2016 22:38:20 +0100 Received: from 950129200 ([79.141.128.249]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id u4BLcHtt009696 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 11 May 2016 22:38:19 +0100 From: "Adrian Farrel" To: "'Lou Berger'" , "'Brian E Carpenter'" , "'John E Drake'" , References: <016001d1aabc$8647efd0$92d7cf70$@olddog.co.uk> <5731E5C9.5030009@labn.net> <01d901d1aad7$2547ad40$6fd707c0$@olddog.co.uk> <57338CC6.2010300@labn.net> <57339A26.8070909@labn.net> In-Reply-To: <57339A26.8070909@labn.net> Date: Wed, 11 May 2016 22:38:16 +0100 Message-ID: <00ae01d1abcd$6ee100e0$4ca302a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHGY8vnNTJbBebVyBv4JJ1RFWV4dwLrX5XEAlqp/OABbbvYpgIxbiqXAbF4p98B+4wp/Z9mP2sQ Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22316.003 X-TM-AS-Result: No--25.351-10.0-31-10 X-imss-scan-details: No--25.351-10.0-31-10 X-TMASE-MatchedRID: TmlY9+XBoTldpLkh5p97g2gws6g0ewz2dro788ABUTUgUEQTkIWiYhry H8gzcR0W5w4eELFQBrNZs4umC/0LtgVcD+m/PiZI/bxP0FQ1eSFUENBIMyKD0dp1biJhIyNRp7u eaEkDqTPuzcUA0q2gBa7mJhtFskd9QylVlmxnJkbmAId+2bAQwpB7Nczg7hDU2oLGTNKlb9db2X fqc6ksX64FOedMHR6MQmALdaGCALefeiNngYomh5pWgCLYjjT9F0R6C/1uGOqrzPs85fwUk+Uul HzdXvNOVhboMG6PiMBwkz+UDoRpveG5o3Ih4/5zSk3ASAlP7626QCTCuzfiVSSqFMz9Rn22zvzH mNQbg4sNjAnghZAIyMFXU8A+eF/wvKCRtYTf5/gVV8fuPc31t22h91WzhP05CTU081fTUYKnnoC PGfH37N5Ig+ERxFLrlUokJ7VMhLSknzO/Syr0IOJ28Kqpjndpkk5xcxBziMER34ro7k23nfNvmS aCnjTlt+odoSua73aRk6XtYogiarQ/aqQZTRfKVnRXm1iHN1bEQdG7H66TyOk/y0w7JiZo Archived-At: Cc: draft-ietf-teas-interconnected-te-info-exchange.all@ietf.org Subject: Re: [Teas] Update to draft-ietf-teas-interconnected-te-info-exchange X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk 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, 11 May 2016 21:38:26 -0000 This document is not describing a protocol solution. I don't think architectures do that (applicability statements, or frameworks might). I continue to want to find the right track on which to publish *this* document, not to try to massage the document to fit one track or another. Whether those massages are considered technical or editorial is not relevant for me, they would be changing the document purely for reasons of process. *If* someone wants to do some analysis of how to "solve" this architecture with existing protocols, or wishes to produce requirements for new protocols or protocol extensions, that would be a fine idea. They might limit that to specific deployment scenarios or attempt a broad solution. Anyway... I *think* the WG consensus on this I-D was called, and (judging by the presence of the document on an IESG telechat agenda) the IETF consensus was also called. Adrian > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: 11 May 2016 21:47 > To: Brian E Carpenter; John E Drake; adrian@olddog.co.uk; teas@ietf.org > Cc: draft-ietf-teas-interconnected-te-info-exchange.all@ietf.org > Subject: Re: [Teas] Update to draft-ietf-teas-interconnected-te-info-exchange > > Brian, > > Thanks for the quick response. Would addressing the following address > your objection? > > ** That the document needs to clearly delineate what can be done today, and > what might be useful (extensions) in the future. > > > Thank you, > Lou > > On 5/11/2016 4:40 PM, Brian E Carpenter wrote: > > On 12/05/2016 08:29, John E Drake wrote: > >> Lou, > >> > >> Snipped, comment inline > >> > >> Yours Irrespectively, > >> > >> John > >> > >>> On 5/4/2016 8:48 PM, Brian E Carpenter wrote: > >>>> Yes. Basically it needs to be clear that the architecture can be 100% > >>>> implemented using current specifications, and that the possible > >>>> extensions are not required for this (and are therefore not really > >>>> part of the core of the BCP). > >>> So the discussion goes on for a bit, but I think the fundamental comment is a > fair one: > >>> > >>> ** That the document needs to clearly delineate what can be done today, > and what might > >>> be useful (extensions) in the future. > >> > >> [JD] This is not my reading of what Brian said. My reading is that he said that > if it were to > >> be published as a BCP it would have to clearly state that the architecture it > describes can > >> be completely implemented using current specifications > >> > >> Your reformulation is fundamentally different and, from what Brian writes, > incompatible > >> with the definition of a BCP > > You can include non-normative sections in a BCP or standards track document, > > as long as they are clearly identified as non-normative. I don't think this would > > be hard to do - it's just annotation of the existing text, not a rewrite or > > any change to what I understand to be the WG consensus. > > > > Brian > > > >> > >>> This holds even if the document were to be published as the authors > viewpoint is held to > >>> publish as PS -- which BTW is not a topic of this message/thread. > >> > >> [JD] From what I have read, both the above statement and your > reformulation of Brian's > >> comment are strictly and solely your own opinion > >> > >> > >> > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org > > https://www.ietf.org/mailman/listinfo/teas > > From nobody Wed May 11 14:48:43 2016 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 75A9812D5E4 for ; Wed, 11 May 2016 14:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 ml-PimDz56_G for ; Wed, 11 May 2016 14:48:40 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id 83E9712D7AA for ; Wed, 11 May 2016 14:48:06 -0700 (PDT) Received: (qmail 13745 invoked by uid 0); 11 May 2016 21:48:04 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy9.mail.unifiedlayer.com with SMTP; 11 May 2016 21:48:04 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id t9nw1s00X2SSUrH019nzSS; Wed, 11 May 2016 15:48:04 -0600 X-Authority-Analysis: v=2.1 cv=Cd2butbl c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=yrkiwgmsf1kA:10 a=wU2YTnxGAAAA:8 a=AEDFM0qtAAAA:8 a=48vgC7mUAAAA:8 a=v51MGYIwPWsOxPo8ecoA:9 a=XXnNMwZK5MQ8zPVX:21 a=-zWqmf4ELNLKuvk5:21 a=pILNOxqGKmIA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=NCq4FBG6EvGFEERSFaZp:22 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject; bh=KUuO+hTWVeFb+c82vKUhzNW7I5G66uH75Kv6ieLjSNk=; b=1sB6S0Fdgg7IVGNiX7HSD8v7xM 5k66U/DltJDC2NlwTDDrgYMpWUNOUeqVuCdoj5LcPA6dqNwcHBcQrQDmadRuhhwOcjomrqQGGtAPH Hw1py6U8KyTncY+x/qWTfO8xI; Received: from box313.bluehost.com ([69.89.31.113]:57105 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1b0bz2-0004n8-GM; Wed, 11 May 2016 15:47:56 -0600 To: John E Drake , Brian E Carpenter , "adrian@olddog.co.uk" , "teas@ietf.org" References: <016001d1aabc$8647efd0$92d7cf70$@olddog.co.uk> <5731E5C9.5030009@labn.net> <01d901d1aad7$2547ad40$6fd707c0$@olddog.co.uk> <57338CC6.2010300@labn.net> <57339A26.8070909@labn.net> From: Lou Berger Message-ID: <5733A887.8070609@labn.net> Date: Wed, 11 May 2016 17:47:51 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: "draft-ietf-teas-interconnected-te-info-exchange.all@ietf.org" Subject: Re: [Teas] Update to draft-ietf-teas-interconnected-te-info-exchange X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 11 May 2016 21:48:42 -0000 John, On 5/11/2016 4:56 PM, John E Drake wrote: > Lou, > > What I thought Brian said was to mark sections as either normative or non-normative and this seems clear to me. This works for me (and seems to me to be a way to address the objection I thought was being raised - but we don't need to argue this further). Can you propose specific changes to address this comment? Lou > Your reformulation does not seem either clear nor bounded in terms of effort. > > Yours Irrespectively, > > John > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Wednesday, May 11, 2016 4:47 PM >> To: Brian E Carpenter; John E Drake; adrian@olddog.co.uk; teas@ietf.org >> Cc: draft-ietf-teas-interconnected-te-info-exchange.all@ietf.org >> Subject: Re: [Teas] Update to draft-ietf-teas-interconnected-te-info-exchange >> >> Brian, >> >> Thanks for the quick response. Would addressing the following address your objection? >> >> ** That the document needs to clearly delineate what can be done today, and what might >> be useful (extensions) in the future. >> >> >> Thank you, >> Lou >> >> On 5/11/2016 4:40 PM, Brian E Carpenter wrote: >>> On 12/05/2016 08:29, John E Drake wrote: >>>> Lou, >>>> >>>> Snipped, comment inline >>>> >>>> Yours Irrespectively, >>>> >>>> John >>>> >>>>> On 5/4/2016 8:48 PM, Brian E Carpenter wrote: >>>>>> Yes. Basically it needs to be clear that the architecture can be >>>>>> 100% implemented using current specifications, and that the >>>>>> possible extensions are not required for this (and are therefore >>>>>> not really part of the core of the BCP). >>>>> So the discussion goes on for a bit, but I think the fundamental comment is a fair one: >>>>> >>>>> ** That the document needs to clearly delineate what can be done >>>>> today, and what might be useful (extensions) in the future. >>>> [JD] This is not my reading of what Brian said. My reading is that >>>> he said that if it were to be published as a BCP it would have to >>>> clearly state that the architecture it describes can be completely >>>> implemented using current specifications >>>> >>>> Your reformulation is fundamentally different and, from what Brian >>>> writes, incompatible with the definition of a BCP >>> You can include non-normative sections in a BCP or standards track >>> document, as long as they are clearly identified as non-normative. I >>> don't think this would be hard to do - it's just annotation of the >>> existing text, not a rewrite or any change to what I understand to be the WG consensus. >>> >>> Brian >>> >>>>> This holds even if the document were to be published as the authors >>>>> viewpoint is held to publish as PS -- which BTW is not a topic of this message/thread. >>>> [JD] From what I have read, both the above statement and your reformulation of Brian's >>>> comment are strictly and solely your own opinion >>>> >>>> >>>> >>> _______________________________________________ >>> Teas mailing list >>> Teas@ietf.org >>> https://www.ietf.org/mailman/listinfo/teas >>> > From nobody Wed May 11 15:11:55 2016 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 BD6EF12D18B; Wed, 11 May 2016 15:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 bZkGRDido_L7; Wed, 11 May 2016 15:11:52 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0779.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:779]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3474512D5D0; Wed, 11 May 2016 15:11:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JVqvFijmmAC7uGAYopdaJ8EHZJfMY2NaAeY/Tqa5wE0=; b=bCS6BV7zJaZRy011pbnTutYo1UlYDkLhHVBh2peFqFcn+VPMGdw32mYlZwnrTKaom1GrnYUIjvDHBaHIdvOUaJrSCB16p0IstAj8O4fgHkJaCeBMGKn6VhKvJFCD1qul1uL5RHrhOl0xcYU44lEEjc3apOHtFBDCtQGIRExkFsc= Received: from SN1PR0501MB1709.namprd05.prod.outlook.com (10.163.130.155) by SN1PR0501MB1711.namprd05.prod.outlook.com (10.163.130.157) with Microsoft SMTP Server (TLS) id 15.1.492.11; Wed, 11 May 2016 22:11:31 +0000 Received: from SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) by SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) with mapi id 15.01.0492.016; Wed, 11 May 2016 22:11:30 +0000 From: John E Drake To: Lou Berger , Brian E Carpenter , "adrian@olddog.co.uk" , "teas@ietf.org" Thread-Topic: [Teas] Update to draft-ietf-teas-interconnected-te-info-exchange Thread-Index: AdGqvH7KKcee39rDSomF0LywguTC2wABZtiAAAVCeIAAOcVBAAAA9a9wAADWnYAAADHrAAAAO3IwAAHpEYAAALku8A== Date: Wed, 11 May 2016 22:11:30 +0000 Message-ID: References: <016001d1aabc$8647efd0$92d7cf70$@olddog.co.uk> <5731E5C9.5030009@labn.net> <01d901d1aad7$2547ad40$6fd707c0$@olddog.co.uk> <57338CC6.2010300@labn.net> <57339A26.8070909@labn.net> <5733A887.8070609@labn.net> In-Reply-To: <5733A887.8070609@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: labn.net; dkim=none (message not signed) header.d=none;labn.net; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.14] x-ms-office365-filtering-correlation-id: 101a9f26-280b-4b01-7d6c-08d379e934c8 x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1711; 5:czvUtl+ngekvvAM0mS4Yc4bgfSQbI+C9OonY1Wf33u8/Jh4Oqs4fSoqvrspuX7+My/35IFVhfatmtJTfcdO7GdRD94HQ4O62Hge1aycTc0xR8IJpz264ORqEClkLUJ27U47AVUCKkL9dD4ehz9X1pQ==; 24:x8pni0p+QqQZ3x1SZZTylFeRB5O6I9/UwaRt6cb+vNDUr/CshCFb5TmK6Clc/4WKyGm/WDpurGM7GZsRjlr8tToNpnHxhz0waqaw+LvmviI=; 7:jHyiuUc+NRqbfQ/hv7Ae4IGyWfbmPc34VtXNyZiI4l4Pp3kQJ3/BT3zc4H+OW7evp1GOuUzfjeqjE0E/tOMFVn1XL3Q4hEWlSThh1sEhGPxBgK05EEhgzU/hFjfgnUifZrSAPEV3GD0DO/KVBStBD74+uJqBW+Ulyo6hz29bxD+s01sdP2CIdknY6MK9l4Z4 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB1711; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:SN1PR0501MB1711; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1711; x-forefront-prvs: 0939529DE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(51914003)(13464003)(377454003)(15650500001)(19580405001)(3280700002)(5008740100001)(19580395003)(5004730100002)(3660700001)(5001770100001)(1220700001)(586003)(3846002)(102836003)(6116002)(92566002)(122556002)(2900100001)(2950100001)(9686002)(2501003)(74316001)(77096005)(66066001)(230783001)(15975445007)(5002640100001)(87936001)(5003600100002)(189998001)(99286002)(8936002)(2906002)(76176999)(76576001)(81166006)(93886004)(2201001)(4326007)(50986999)(86362001)(33656002)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1711; H:SN1PR0501MB1709.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2016 22:11:30.8486 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1711 Archived-At: Cc: "draft-ietf-teas-interconnected-te-info-exchange.all@ietf.org" Subject: Re: [Teas] Update to draft-ietf-teas-interconnected-te-info-exchange X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 11 May 2016 22:11:55 -0000 Lou, I think this entire discussion has been OBE because the IESG is scheduled t= o discuss it next week; i.e., they will be looking at the document in its = current form so there is no point in changing it. If they have similar objections, then Brian's suggestion can be proposed by= the authors. Yours Irrespectively, John > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Wednesday, May 11, 2016 5:48 PM > To: John E Drake; Brian E Carpenter; adrian@olddog.co.uk; teas@ietf.org > Cc: draft-ietf-teas-interconnected-te-info-exchange.all@ietf.org > Subject: Re: [Teas] Update to draft-ietf-teas-interconnected-te-info-exch= ange >=20 >=20 > John, >=20 > On 5/11/2016 4:56 PM, John E Drake wrote: > > Lou, > > > > What I thought Brian said was to mark sections as either normative or n= on-normative and > this seems clear to me. >=20 > This works for me (and seems to me to be a way to address the objection I= thought was > being raised - but we don't need to argue this further). >=20 > Can you propose specific changes to address this comment? >=20 > Lou >=20 > > Your reformulation does not seem either clear nor bounded in terms of e= ffort. > > > > Yours Irrespectively, > > > > John > > > >> -----Original Message----- > >> From: Lou Berger [mailto:lberger@labn.net] > >> Sent: Wednesday, May 11, 2016 4:47 PM > >> To: Brian E Carpenter; John E Drake; adrian@olddog.co.uk; > >> teas@ietf.org > >> Cc: draft-ietf-teas-interconnected-te-info-exchange.all@ietf.org > >> Subject: Re: [Teas] Update to > >> draft-ietf-teas-interconnected-te-info-exchange > >> > >> Brian, > >> > >> Thanks for the quick response. Would addressing the following address= your objection? > >> > >> ** That the document needs to clearly delineate what can be done > >> today, and what might be useful (extensions) in the future. > >> > >> > >> Thank you, > >> Lou > >> > >> On 5/11/2016 4:40 PM, Brian E Carpenter wrote: > >>> On 12/05/2016 08:29, John E Drake wrote: > >>>> Lou, > >>>> > >>>> Snipped, comment inline > >>>> > >>>> Yours Irrespectively, > >>>> > >>>> John > >>>> > >>>>> On 5/4/2016 8:48 PM, Brian E Carpenter wrote: > >>>>>> Yes. Basically it needs to be clear that the architecture can be > >>>>>> 100% implemented using current specifications, and that the > >>>>>> possible extensions are not required for this (and are therefore > >>>>>> not really part of the core of the BCP). > >>>>> So the discussion goes on for a bit, but I think the fundamental co= mment is a fair > one: > >>>>> > >>>>> ** That the document needs to clearly delineate what can be done > >>>>> today, and what might be useful (extensions) in the future. > >>>> [JD] This is not my reading of what Brian said. My reading is > >>>> that he said that if it were to be published as a BCP it would have > >>>> to clearly state that the architecture it describes can be > >>>> completely implemented using current specifications > >>>> > >>>> Your reformulation is fundamentally different and, from what Brian > >>>> writes, incompatible with the definition of a BCP > >>> You can include non-normative sections in a BCP or standards track > >>> document, as long as they are clearly identified as non-normative. I > >>> don't think this would be hard to do - it's just annotation of the > >>> existing text, not a rewrite or any change to what I understand to be= the WG > consensus. > >>> > >>> Brian > >>> > >>>>> This holds even if the document were to be published as the > >>>>> authors viewpoint is held to publish as PS -- which BTW is not a to= pic of this > message/thread. > >>>> [JD] From what I have read, both the above statement and your > >>>> reformulation of Brian's comment are strictly and solely your own > >>>> opinion > >>>> > >>>> > >>>> > >>> _______________________________________________ > >>> Teas mailing list > >>> Teas@ietf.org > >>> https://www.ietf.org/mailman/listinfo/teas > >>> > > >=20 From nobody Wed May 11 18:39:31 2016 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 35D7C12D831; Wed, 11 May 2016 18:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNx7-TAOVwbK; Wed, 11 May 2016 18:39:27 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (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 9037812D0A5; Wed, 11 May 2016 18:39:27 -0700 (PDT) Received: by mail-pa0-x22c.google.com with SMTP id bt5so23290917pac.3; Wed, 11 May 2016 18:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=PHdHHeDMpbbsVltlaOm8cWfmxGqwSFFaeevflsd9HXo=; b=gcD9FmzSnvFUO6//EpDVYI91PQ3UZcQTj1pGgLUv0XbmSyIMwr8nwgyC71576cE4o2 QYMeuPOuhf6YL/29Bnr2iexth1DPNKAoWxameSKFQvO3+7YF4788UsemYS9gnoYamzfL OtZIXbKZdxMiZOQhCW4/78Y89ZoPnEGYumqBGmMfKtYJtvwuDvcuLqqaqN/bnbooxkdL f+lohHvk8H8DrFyJaHaidJnaoBZHjknAsTkF2x4BkvGGVpjWzHszwbfYLynKHfCnVG2+ N6lmd5qT+w98Ri8/bSpu9JbNGNod4yyEAsoFIDlygRxKDyEwRyNf3/YO0nYa5mhY/10a 1xtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=PHdHHeDMpbbsVltlaOm8cWfmxGqwSFFaeevflsd9HXo=; b=Rtv2fP+I+GQwEhDRk69mcGaLcKDUl+5N/P4yu86RSayQvNB8qRNTId4lNyAwcgUJur jKtUD6QsLYK+EzqQDnNGsUqm0hfEty/NQCo3T1b1keeh6z9qF/pvUxVuFkJ9bpIU2hrg hz+759fNVRRSnoNIOOZjbOdqfRg02hOPRMj9d8kvZUI+Q84zmT04R8fniKYCVLuWoFV7 bgw/RlFujWyTh3wjlAfjK811OvSy3JKq64+P2ZHCTQCRw6Y7p2sitmalSEwqFVt+iL4k TFp2lza4XBPBVB00OofIdJ9Xu550bglCm4vMJdqHbWNCyNNt63miLjyzhA5H5ODLIXgd DeTA== X-Gm-Message-State: AOPr4FUQSOUeR5urHkjBa3pAVNW1U5KUelchLXkfTy/oDwurV/vVce6K0f/SJwuGxLCg1A== X-Received: by 10.66.153.174 with SMTP id vh14mr9761154pab.131.1463017167122; Wed, 11 May 2016 18:39:27 -0700 (PDT) Received: from ?IPv6:2406:e007:5004:1:28cc:dc4c:9703:6781? ([2406:e007:5004:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id n6sm15171915pfa.2.2016.05.11.18.39.21 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 May 2016 18:39:24 -0700 (PDT) To: John E Drake , Lou Berger , "adrian@olddog.co.uk" , "teas@ietf.org" References: <016001d1aabc$8647efd0$92d7cf70$@olddog.co.uk> <5731E5C9.5030009@labn.net> <01d901d1aad7$2547ad40$6fd707c0$@olddog.co.uk> <57338CC6.2010300@labn.net> <57339A26.8070909@labn.net> <5733A887.8070609@labn.net> From: Brian E Carpenter Organization: University of Auckland Message-ID: <78bb0ac1-a1a1-6c40-01c7-2378f635770f@gmail.com> Date: Thu, 12 May 2016 13:39:47 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-teas-interconnected-te-info-exchange.all@ietf.org" , Jari Arkko Subject: Re: [Teas] Update to draft-ietf-teas-interconnected-te-info-exchange X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 12 May 2016 01:39:30 -0000 I agree. Either the IESG has the same question that I do, which (IMHO) would lead to very mild editing, or they are happy with it as-is. (Copying Jari as the AD who receives Gen-ART reviews - there has been quite a long off-list thread but no clear agreement on whether changes are needed to identify which sections are the actual BCP and which sections are not.) Regards Brian On 12/05/2016 10:11, John E Drake wrote: > Lou, > > I think this entire discussion has been OBE because the IESG is scheduled to discuss it next week; i.e., they will be looking at the document in its current form so there is no point in changing it. > > If they have similar objections, then Brian's suggestion can be proposed by the authors. > > Yours Irrespectively, > > John > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Wednesday, May 11, 2016 5:48 PM >> To: John E Drake; Brian E Carpenter; adrian@olddog.co.uk; teas@ietf.org >> Cc: draft-ietf-teas-interconnected-te-info-exchange.all@ietf.org >> Subject: Re: [Teas] Update to draft-ietf-teas-interconnected-te-info-exchange >> >> >> John, >> >> On 5/11/2016 4:56 PM, John E Drake wrote: >>> Lou, >>> >>> What I thought Brian said was to mark sections as either normative or non-normative and >> this seems clear to me. >> >> This works for me (and seems to me to be a way to address the objection I thought was >> being raised - but we don't need to argue this further). >> >> Can you propose specific changes to address this comment? >> >> Lou >> >>> Your reformulation does not seem either clear nor bounded in terms of effort. >>> >>> Yours Irrespectively, >>> >>> John >>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Wednesday, May 11, 2016 4:47 PM >>>> To: Brian E Carpenter; John E Drake; adrian@olddog.co.uk; >>>> teas@ietf.org >>>> Cc: draft-ietf-teas-interconnected-te-info-exchange.all@ietf.org >>>> Subject: Re: [Teas] Update to >>>> draft-ietf-teas-interconnected-te-info-exchange >>>> >>>> Brian, >>>> >>>> Thanks for the quick response. Would addressing the following address your objection? >>>> >>>> ** That the document needs to clearly delineate what can be done >>>> today, and what might be useful (extensions) in the future. >>>> >>>> >>>> Thank you, >>>> Lou >>>> >>>> On 5/11/2016 4:40 PM, Brian E Carpenter wrote: >>>>> On 12/05/2016 08:29, John E Drake wrote: >>>>>> Lou, >>>>>> >>>>>> Snipped, comment inline >>>>>> >>>>>> Yours Irrespectively, >>>>>> >>>>>> John >>>>>> >>>>>>> On 5/4/2016 8:48 PM, Brian E Carpenter wrote: >>>>>>>> Yes. Basically it needs to be clear that the architecture can be >>>>>>>> 100% implemented using current specifications, and that the >>>>>>>> possible extensions are not required for this (and are therefore >>>>>>>> not really part of the core of the BCP). >>>>>>> So the discussion goes on for a bit, but I think the fundamental comment is a fair >> one: >>>>>>> >>>>>>> ** That the document needs to clearly delineate what can be done >>>>>>> today, and what might be useful (extensions) in the future. >>>>>> [JD] This is not my reading of what Brian said. My reading is >>>>>> that he said that if it were to be published as a BCP it would have >>>>>> to clearly state that the architecture it describes can be >>>>>> completely implemented using current specifications >>>>>> >>>>>> Your reformulation is fundamentally different and, from what Brian >>>>>> writes, incompatible with the definition of a BCP >>>>> You can include non-normative sections in a BCP or standards track >>>>> document, as long as they are clearly identified as non-normative. I >>>>> don't think this would be hard to do - it's just annotation of the >>>>> existing text, not a rewrite or any change to what I understand to be the WG >> consensus. >>>>> >>>>> Brian >>>>> >>>>>>> This holds even if the document were to be published as the >>>>>>> authors viewpoint is held to publish as PS -- which BTW is not a topic of this >> message/thread. >>>>>> [JD] From what I have read, both the above statement and your >>>>>> reformulation of Brian's comment are strictly and solely your own >>>>>> opinion >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Teas mailing list >>>>> Teas@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/teas >>>>> >>> >> > > From nobody Thu May 12 01:25:50 2016 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 D322B12B044; Thu, 12 May 2016 01:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 4ztcm5_7d1mP; Thu, 12 May 2016 01:25:44 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07D2512B02D; Thu, 12 May 2016 01:25:42 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-23-57343e052b21 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 9A.78.12926.50E34375; Thu, 12 May 2016 10:25:41 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.65]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0248.002; Thu, 12 May 2016 10:25:11 +0200 From: Daniele Ceccarelli To: "CCAMP (ccamp@ietf.org)" , "TEAS WG (teas@ietf.org)" Thread-Topic: Joint WG last call on draft-ietf-ospf-availability-extension-04 Thread-Index: AdGsJ0Ek7gP9RQQrQ6a+ZIh0V1wFmA== Date: Thu, 12 May 2016 08:25:11 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE48162CC275@ESESSMB301.ericsson.se> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE48162CC275ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZGbHdQ5fVziTcYO1FIYulOzYxWTyZc4PF omnuLiaL1h87WBxYPJYs+ckUwBjFZZOSmpNZllqkb5fAldGz+wJbwWTFiikr5rE1MM6S7WLk 5JAQMJF439rEBmGLSVy4tx7I5uIQEjjCKDG/dxIjhLOYUeLF7mesXYwcHGwCVhJPDvmANIgI REms/jgBrJlZIEXi7b+tjCC2sICHxOVnX9kganwl5u7dwQxh60l8OwVRzyKgKjHn0Ax2EJsX qGbPiYlMIDajgKzEhN2LGCFmikvcejKfCeI4AYkle84zQ9iiEi8f/2OFsJUkfmy4xAJRny/R /+UCM8RMQYmTM5+wTGAUnoVk1CwkZbOQlEHEdSQW7P7EBmFrSyxb+JoZxj5z4DETsvgCRvZV jKLFqcVJuelGxnqpRZnJxcX5eXp5qSWbGIGRdHDLb9UdjJffOB5iFOBgVOLhXfDYOFyINbGs uDL3EKMEB7OSCC+PuUm4EG9KYmVValF+fFFpTmrxIUZpDhYlcV7/l4rhQgLpiSWp2ampBalF MFkmDk6pBsbwtd/YJggK1lxa6r44OfTAsvsXZq35OUvF7lnuN5/pZodDVBXSF2Vfv/v0p8/9 6p5Vh/n63/wpey257csy9h8mTb59JyN6dPm8nuaHL8jeGMRcHFS/mCfoc3qtJce/NYJ766z/ JnTGynu73lgrcvfN1cWxRmr/V+ZNF3uh+8PkyMaNx37IXXZSYinOSDTUYi4qTgQAHdI++qAC AAA= Archived-At: Cc: "ccamp-chairs@ietf.org" , "teas-chairs@ietf.org" Subject: [Teas] Joint WG last call on draft-ietf-ospf-availability-extension-04 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 12 May 2016 08:25:46 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE48162CC275ESESSMB301erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable CCAMP, TEAS, This starts a two weeks joint working group last call on draft-ietf-ccamp-o= spf-availability-extension-04 The last call end on Wednesday May 26th. Please send your comments to both = the CCAMP and TEAS mailing lists. All the IPR declarations from authors and contributors have been collected = and can be found in the history of the document: https://datatracker.ietf.o= rg/doc/draft-ietf-ccamp-ospf-availability-extension/history/ Please note that no IPR was disclosed against this draft. As usual this is also a call for shepherd. If anyone is willing to be the s= hepherd of the document, please volunteer. Thanks Daniele, Fatai, Lou, Pavan --_000_4A1562797D64E44993C5CBF38CF1BE48162CC275ESESSMB301erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

CCAMP, TEAS,

 

This starts a two weeks joint working group last cal= l on draft-ietf-ccamp-ospf-availability-extension-04

The last call end on Wednesday May 26th. = Please send your comments to both the CCAMP and TEAS mailing lists.

 

All the IPR declarations from authors and contributo= rs have been collected and can be found in the history of the document: https://datatracker.ietf.org/doc/draft-ietf-ccamp-ospf-availability-extensi= on/history/

Please note that no IPR was disclosed against this d= raft.

 

As usual this is also a call for shepherd. If anyone= is willing to be the shepherd of the document, please volunteer.

 

Thanks

Daniele, Fatai, Lou, Pavan

 

--_000_4A1562797D64E44993C5CBF38CF1BE48162CC275ESESSMB301erics_-- From nobody Thu May 12 04:06:54 2016 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 3426012D908; Thu, 12 May 2016 04:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cCLpD0cYCrN; Thu, 12 May 2016 04:06:50 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A95A12D90F; Thu, 12 May 2016 04:06:44 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 25F80F1EE1402; Thu, 12 May 2016 11:06:28 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4CB6TS1018788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 May 2016 11:06:29 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u4CB3gOI005924 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 May 2016 13:06:21 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.44]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Thu, 12 May 2016 13:04:14 +0200 From: "Scharf, Michael (Nokia - DE)" To: "adrian@olddog.co.uk" , "teas@ietf.org" Thread-Topic: [Teas] A unified draft on resource scheduling Thread-Index: AdGquU0SuIg3y/cpQh2ZgOTeJKNB2ABgM3kQ Date: Thu, 12 May 2016 11:04:14 +0000 Message-ID: <655C07320163294895BBADA28372AF5D4884601B@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <015f01d1aab9$4f16c8e0$ed445aa0$@olddog.co.uk> In-Reply-To: <015f01d1aab9$4f16c8e0$ed445aa0$@olddog.co.uk> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-zhuang-teas-scheduled-resources@ietf.org" Subject: Re: [Teas] A unified draft on resource scheduling X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 12 May 2016 11:06:53 -0000 I wonder why Section 3.1 does not mention that central storage may have sca= ling limitations as well, even if this may not really change the overall tr= adeoff between the two approaches. I believe it would make sense to also look at the implications of "a busy n= etwork with a high arrival rate of new LSPs and a low hold time for each LS= P" for the centralized case, to have a more balanced discussion. While it m= ay be true that the centralized approach scales better, e.g., because it ca= n better leverage modern DB technology, any persistent storage of huge amou= nts of possibly highly dynamic data does not come entirely for free, right? Michael -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of EXT Adrian Farrel Sent: Tuesday, May 10, 2016 2:42 PM To: teas@ietf.org Cc: draft-zhuang-teas-scheduled-resources@ietf.org Subject: [Teas] A unified draft on resource scheduling Hi All, In Yokohama two I-Ds were presented that showed different approaches to man= aging scheduled resource usage in TE networks. Since then the authors of th= e two drafts have spent time discussing the best way forward to merge their= ideas. We have now reached that point and posted a new revision of one of the draf= ts (see below) that we are all happy with as an overall architecture. We think that the WG in Yokohama expressed an interest in having this sort = of document to record consensus on how to handle resource scheduling and se= rve as a basis for any protocol extension work. If that is right, we believe that this document is now ready for the WG to = consider for adoption and to develop into a TEAS RFC. Please review and let us know your thoughts. Chairs: any next steps for adoption? Thanks, Adrian > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of=20 > internet-drafts@ietf.org > Sent: 10 May 2016 10:16 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-zhuang-teas-scheduled-resources-02.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts directories. >=20 >=20 > Title : Architecture for Scheduled Use of Resources > Authors : Yan Zhuang > Qin Wu > Huaimo Chen > Adrian Farrel > Filename : draft-zhuang-teas-scheduled-resources-02.txt > Pages : 13 > Date : 2016-05-10 >=20 > Abstract: > Time-Scheduled reservation of traffic engineering (TE) resources can > be used to provide resource booking for TE Label Switched Paths so as > to better guarantee services for customers and to improve the > efficiency of network resource usage into the future. This document > provides a framework that describes and discusses the architecture > for the scheduled reservation of TE resources. This document does > not describe specific protocols or protocol extensions needed to > realize this service. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-zhuang-teas-scheduled-resources > / >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-zhuang-teas-scheduled-resources-02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-zhuang-teas-scheduled-resource > s-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Thu May 12 04:42:05 2016 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 7B61112D977; Thu, 12 May 2016 04:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UlzZMDE6smj; Thu, 12 May 2016 04:42:01 -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 B45A912D66A; Thu, 12 May 2016 04:41:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9625; q=dns/txt; s=iport; t=1463053317; x=1464262917; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Qy9hMqTOCXl6noRcsRGtH64JJwTPRGgGXu2jUkyhRD0=; b=em8zAldjJ9yeMoV/i+XfVcqD6ZbdhIce5Qsj1EaSaUuloFYIDD8cKt9q c6BvVRUfhxD8AfOmovrgUka/5d1PhsNAiDBn92Otevro4q0xiTyICCL5E ms6A7GlklVPZW7xIrJbMKLdO8dyTlcH+0YKrAQJ+4VMq8aJm/cOpAZiKG k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DbAgCiazRX/4cNJK1egmxMVX0GtF2Ed?= =?us-ascii?q?wENgXYkhXACHIEROBQBAQEBAQEBZSeEQgEBAQQdBgpBCxACAQgRAwECKAMCAgI?= =?us-ascii?q?wFAkIAgQBDQWILw6rG5B+AQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSKbIRfgmCCW?= =?us-ascii?q?QWYJwGFfYgggWmET4hhj0ABHgEBQoNrbocyfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,609,1454976000"; d="scan'208,217";a="101799109" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 May 2016 11:41:56 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u4CBfuDu001721 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 12 May 2016 11:41:56 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 12 May 2016 07:41:55 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Thu, 12 May 2016 07:41:55 -0400 From: "Acee Lindem (acee)" To: Daniele Ceccarelli , "CCAMP (ccamp@ietf.org)" , "TEAS WG (teas@ietf.org)" Thread-Topic: [Teas] Joint WG last call on draft-ietf-ospf-availability-extension-04 Thread-Index: AQHRrENIRgSsmvfWRU2f/UUwoeFDUw== Date: Thu, 12 May 2016 11:41:55 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE48162CC275@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48162CC275@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: multipart/alternative; boundary="_000_D359E38860A6Daceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "teas-chairs@ietf.org" , "ccamp-chairs@ietf.org" Subject: Re: [Teas] Joint WG last call on draft-ietf-ospf-availability-extension-04 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 12 May 2016 11:42:03 -0000 --_000_D359E38860A6Daceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSByZWFsaXplIGl0IGhhcyBhbHdheXMgYmVlbiB0aGlzIHdheSBidXQgdGhlIHRlcm1pbm9sb2d5 IG9mIHRoZSBkcmFmdCAoaW5jbHVkaW5nIHRoZSB0aXRsZSkgaXMgc29tZXdoYXQgbWlzbGVhZGlu ZyBhcyB0aGUgZG9lcyBub3QgZXh0ZW5kIHRoZSBPU1BGIHJvdXRpbmcgcHJvdG9jb2wuIFJhdGhl ciwgaXQgIGV4dGVuZHMgdGhlIE9TUEYgR01QTFMgZW5jb2RpbmdzIGFzIGRlZmluZWQgaW4gUkZD IDQyMDMuDQpUaGFua3MsDQpBY2VlDQoNCkZyb206IFRlYXMgPHRlYXMtYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86dGVhcy1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIERhbmllbGUgQ2Vj Y2FyZWxsaSA8ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbTxtYWlsdG86ZGFuaWVsZS5j ZWNjYXJlbGxpQGVyaWNzc29uLmNvbT4+DQpEYXRlOiBUaHVyc2RheSwgTWF5IDEyLCAyMDE2IGF0 IDQ6MjUgQU0NClRvOiAiQ0NBTVAgKGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9y Zz4pIiA8Y2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPj4sICJURUFTIFdHICh0 ZWFzQGlldGYub3JnPG1haWx0bzp0ZWFzQGlldGYub3JnPikiIDx0ZWFzQGlldGYub3JnPG1haWx0 bzp0ZWFzQGlldGYub3JnPj4NCkNjOiAiY2NhbXAtY2hhaXJzQGlldGYub3JnPG1haWx0bzpjY2Ft cC1jaGFpcnNAaWV0Zi5vcmc+IiA8Y2NhbXAtY2hhaXJzQGlldGYub3JnPG1haWx0bzpjY2FtcC1j aGFpcnNAaWV0Zi5vcmc+PiwgInRlYXMtY2hhaXJzQGlldGYub3JnPG1haWx0bzp0ZWFzLWNoYWly c0BpZXRmLm9yZz4iIDx0ZWFzLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86dGVhcy1jaGFpcnNAaWV0 Zi5vcmc+Pg0KU3ViamVjdDogW1RlYXNdIEpvaW50IFdHIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRm LW9zcGYtYXZhaWxhYmlsaXR5LWV4dGVuc2lvbi0wNA0KDQpDQ0FNUCwgVEVBUywNCg0KVGhpcyBz dGFydHMgYSB0d28gd2Vla3Mgam9pbnQgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb24gZHJhZnQt aWV0Zi1jY2FtcC1vc3BmLWF2YWlsYWJpbGl0eS1leHRlbnNpb24tMDQNClRoZSBsYXN0IGNhbGwg ZW5kIG9uIFdlZG5lc2RheSBNYXkgMjZ0aC4gUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byBi b3RoIHRoZSBDQ0FNUCBhbmQgVEVBUyBtYWlsaW5nIGxpc3RzLg0KDQpBbGwgdGhlIElQUiBkZWNs YXJhdGlvbnMgZnJvbSBhdXRob3JzIGFuZCBjb250cmlidXRvcnMgaGF2ZSBiZWVuIGNvbGxlY3Rl ZCBhbmQgY2FuIGJlIGZvdW5kIGluIHRoZSBoaXN0b3J5IG9mIHRoZSBkb2N1bWVudDogaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jY2FtcC1vc3BmLWF2YWlsYWJp bGl0eS1leHRlbnNpb24vaGlzdG9yeS8NClBsZWFzZSBub3RlIHRoYXQgbm8gSVBSIHdhcyBkaXNj bG9zZWQgYWdhaW5zdCB0aGlzIGRyYWZ0Lg0KDQpBcyB1c3VhbCB0aGlzIGlzIGFsc28gYSBjYWxs IGZvciBzaGVwaGVyZC4gSWYgYW55b25lIGlzIHdpbGxpbmcgdG8gYmUgdGhlIHNoZXBoZXJkIG9m IHRoZSBkb2N1bWVudCwgcGxlYXNlIHZvbHVudGVlci4NCg0KDQoNClRoYW5rcw0KDQpEYW5pZWxl LCBGYXRhaSwgTG91LCBQYXZhbg0KDQo= --_000_D359E38860A6Daceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <684204695BFA6B48A96D04626B61EF17@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5JIHJlYWxpemUg aXQgaGFzIGFsd2F5cyBiZWVuIHRoaXMgd2F5IGJ1dCB0aGUgdGVybWlub2xvZ3kgb2YgdGhlIGRy YWZ0IChpbmNsdWRpbmcgdGhlIHRpdGxlKSBpcyBzb21ld2hhdCBtaXNsZWFkaW5nIGFzIHRoZSBk b2VzIG5vdCBleHRlbmQgdGhlIE9TUEYgcm91dGluZyBwcm90b2NvbC4gUmF0aGVyLCBpdCAmbmJz cDtleHRlbmRzIHRoZSBPU1BGIEdNUExTIGVuY29kaW5ncyBhcyBkZWZpbmVkIGluIFJGQyA0MjAz LiZuYnNwOzwvZGl2Pg0KPGRpdj5UaGFua3MsPC9kaXY+DQo8ZGl2PkFjZWUmbmJzcDs8L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246 bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVG VDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQ QURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVIt UklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+VGVhcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRlYXMt Ym91bmNlc0BpZXRmLm9yZyI+dGVhcy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxm IG9mIERhbmllbGUgQ2VjY2FyZWxsaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRhbmllbGUuY2VjY2Fy ZWxsaUBlcmljc3Nvbi5jb20iPmRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb208L2E+Jmd0 Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+VGh1cnNk YXksIE1heSAxMiwgMjAxNiBhdCA0OjI1IEFNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0 OmJvbGQiPlRvOiA8L3NwYW4+JnF1b3Q7Q0NBTVAgKDxhIGhyZWY9Im1haWx0bzpjY2FtcEBpZXRm Lm9yZyI+Y2NhbXBAaWV0Zi5vcmc8L2E+KSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNjYW1w QGlldGYub3JnIj5jY2FtcEBpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDtURUFTIFdHICg8YSBocmVm PSJtYWlsdG86dGVhc0BpZXRmLm9yZyI+dGVhc0BpZXRmLm9yZzwvYT4pJnF1b3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86dGVhc0BpZXRmLm9yZyI+dGVhc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFp bHRvOmNjYW1wLWNoYWlyc0BpZXRmLm9yZyI+Y2NhbXAtY2hhaXJzQGlldGYub3JnPC9hPiZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNjYW1wLWNoYWlyc0BpZXRmLm9yZyI+Y2NhbXAtY2hhaXJz QGlldGYub3JnPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzp0ZWFzLWNoYWlyc0BpZXRm Lm9yZyI+dGVhcy1jaGFpcnNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 dGVhcy1jaGFpcnNAaWV0Zi5vcmciPnRlYXMtY2hhaXJzQGlldGYub3JnPC9hPiZndDs8YnI+DQo8 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPltUZWFzXSBKb2lu dCBXRyBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1vc3BmLWF2YWlsYWJpbGl0eS1leHRlbnNpb24t MDQ8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09V VExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRm IDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXYgeG1sbnM6 dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVybjpzY2hlbWFzLW1p Y3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0 LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9v ZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0 MCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChm aWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAy IDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFn cmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0 eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJ bWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt Y29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3 MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Q0NBTVAsIFRFQVMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgc3RhcnRzIGEgdHdv IHdlZWtzIGpvaW50IHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtY2NhbXAt b3NwZi1hdmFpbGFiaWxpdHktZXh0ZW5zaW9uLTA0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGUgbGFzdCBjYWxsIGVuZCBvbiBXZWRuZXNkYXkgTWF5IDI2PHN1cD50aDwv c3VwPi4gUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byBib3RoIHRoZSBDQ0FNUCBhbmQgVEVB UyBtYWlsaW5nIGxpc3RzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbGwgdGhlIElQUiBkZWNs YXJhdGlvbnMgZnJvbSBhdXRob3JzIGFuZCBjb250cmlidXRvcnMgaGF2ZSBiZWVuIGNvbGxlY3Rl ZCBhbmQgY2FuIGJlIGZvdW5kIGluIHRoZSBoaXN0b3J5IG9mIHRoZSBkb2N1bWVudDoNCjxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY2NhbXAtb3Nw Zi1hdmFpbGFiaWxpdHktZXh0ZW5zaW9uL2hpc3RvcnkvIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY2NhbXAtb3NwZi1hdmFpbGFiaWxpdHktZXh0ZW5zaW9u L2hpc3RvcnkvPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNl IG5vdGUgdGhhdCBubyBJUFIgd2FzIGRpc2Nsb3NlZCBhZ2FpbnN0IHRoaXMgZHJhZnQuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkFzIHVzdWFsIHRoaXMgaXMgYWxzbyBhIGNhbGwgZm9yIHNoZXBo ZXJkLiBJZiBhbnlvbmUgaXMgd2lsbGluZyB0byBiZSB0aGUgc2hlcGhlcmQgb2YgdGhlIGRvY3Vt ZW50LCBwbGVhc2Ugdm9sdW50ZWVyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiPlRoYW5rczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiPkRh bmllbGUsIEZhdGFpLCBMb3UsIFBhdmFuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D359E38860A6Daceeciscocom_-- From nobody Thu May 12 04:43:05 2016 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 AE79712D95C for ; Thu, 12 May 2016 04:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dMEtudaijCf for ; Thu, 12 May 2016 04:43:01 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C44212D66A for ; Thu, 12 May 2016 04:43:01 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 879ABC9936092; Thu, 12 May 2016 11:42:57 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4CBgxN7006300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 May 2016 11:42:59 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u4CBfaup016007 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 May 2016 13:42:57 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.44]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 12 May 2016 13:41:14 +0200 From: "Scharf, Michael (Nokia - DE)" To: "adrian@olddog.co.uk" , "teas@ietf.org" Thread-Topic: [Teas] A New I-D on PCE as a central controller Thread-Index: AdGnosEWtnZGzgfkR5SQqz0Nm22cLQEn1m5Q Date: Thu, 12 May 2016 11:41:13 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48846127@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <0c6c01d1a7a2$f1a24860$d4e6d920$@olddog.co.uk> In-Reply-To: <0c6c01d1a7a2$f1a24860$d4e6d920$@olddog.co.uk> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Teas] A New I-D on PCE as a central controller X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 12 May 2016 11:43:04 -0000 When reading about uses cases such as L3VPN service delivery in "Section 3.= 2.3", what is the author's view on the line of demarcation between NETCONF = and PCEP? Thanks Michael -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of EXT Adrian Farrel Sent: Friday, May 06, 2016 4:24 PM To: teas@ietf.org Subject: [Teas] A New I-D on PCE as a central controller Hi, The idea of a "PCE-based central controller" has been bouncing around betwe= en PCE and TEAS for a bit. There have been plenty of use cases proposed and= some protocol extension work. In Buenos Aires a group of us got together to try to work out where all thi= s was going and how to structure the work to get more progress especially o= n the bits that some people are very keen to advance quickly. The result is this architecture document which we are targeting at TEAS. Originally intended to be very short and simple it has already grown a bit,= but it is still a manageable read. Our idea is that the different use case= s will result in a variety of distinct protocol extensions to PCEP that can= be handled in separate documents in the PCE working group . This will allo= w different people to support different use cases and work on them at their= own speed. Discussion is encouraged. Adrian (per pro "the team") > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of=20 > internet-drafts@ietf.org > Sent: 06 May 2016 15:16 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-zhao-teas-pce-control-function-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts directories. >=20 >=20 > Title : An Architecture for Use of PCE and PCEP in a Ne= twork with Central > Control > Authors : Adrian Farrel > Quintin Zhao > Robin Li > Chao Zhou > Filename : draft-zhao-teas-pce-control-function-00.txt > Pages : 21 > Date : 2016-05-06 >=20 > Abstract: > The Path Computation Element (PCE) has become established as a core > component of Software Defined Networking (SDN) systems. It can > compute optimal paths for traffic across a network for any definition > of "optimal" and can also monitor changes in resource availability > and traffic demands to update the paths. >=20 > Conventionally, the PCE has been used to derive paths for MPLS Label > Switched Paths (LSPs). These paths are supplied using the Path > Computation Element Communication Protocol (PCEP) to the head end of > the LSP for signaling in the MPLS network. >=20 > SDN has a far broader applicability than just signaled MPLS traffic > engineered networks, and the PCE may be used to determine paths in a > wide range of use cases including static LSPs, segment routing, > service function chaining (SFC), and indeed any form of routed or > switched network. It is, therefore reasonable to consider PCEP as a > general southbound control protocol for use in these environments to > allow the PCE to be fully enabled as a central controller. >=20 > This document briefly introduces the architecture for PCE as a > central controller, examines the motivations and applicability for > PCEP as a southbound interface, and introduces the implications for > the protocol. This document does not describe the use cases in > detail and does not define protocol extensions: that work is left for > other documents. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-zhao-teas-pce-control-function/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-zhao-teas-pce-control-function-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Fri May 13 03:09:48 2016 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 9EF2A12D142; Fri, 13 May 2016 03:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 PqV1NRYiSWNJ; Fri, 13 May 2016 03:09:44 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 448DC12D103; Fri, 13 May 2016 03:09:42 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-10-5735a7e4dff5 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 3B.FE.12516.4E7A5375; Fri, 13 May 2016 12:09:40 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.65]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0248.002; Fri, 13 May 2016 12:09:40 +0200 From: Daniele Ceccarelli To: "Acee Lindem (acee)" , "CCAMP (ccamp@ietf.org)" , "TEAS WG (teas@ietf.org)" Thread-Topic: [Teas] Joint WG last call on draft-ietf-ospf-availability-extension-04 Thread-Index: AdGsJ0Ek7gP9RQQrQ6a+ZIh0V1wFmAAC0PaAADM81dA= Date: Fri, 13 May 2016 10:09:39 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE48162CDFB4@ESESSMB301.ericsson.se> References: <4A1562797D64E44993C5CBF38CF1BE48162CC275@ESESSMB301.ericsson.se> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE48162CDFB4ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDIsWRmVeSWpSXmKPExsUyM2K7pe6T5abhBj+faFpMfjuP2WLpjk1M Fk/m3GCxaJq7i8mi9ccOFgdWjym/N7J6LFnykymAKYrLJiU1J7MstUjfLoEr49isXawFbzIr ph+6z9LA+Ceti5GTQ0LARGLZ4yYmCFtM4sK99WxdjFwcQgJHGCWWvfjADOEsZpTYNaGDsYuR g4NNwEriySEfkAYRgUZGiYPXeEHCzAIpEnefaoOEhQVCJfpmn2OGKAmT2DZ1JwuEbSVxfe5/ NhCbRUBV4supCWB7eQV8JY5fnQFmCwnkSyy/toIVZCSngI7Etl0JIGFGAVmJCbsXMYLYzALi EreezIc6WUBiyZ7zzBC2qMTLx/9YIWxFiavTlzNB1OdL/Ln3nAVilaDEyZlPWCYwis5CMmoW krJZSMpmgT2mKbF+lz5EiaLElO6H7BC2hkTrnLnsyOILGNlXMYoWpxYX56YbGeulFmUmFxfn 5+nlpZZsYgTG4cEtv3V3MK5+7XiIUYCDUYmHV8HUNFyINbGsuDL3EKMEB7OSCO/hZUAh3pTE yqrUovz4otKc1OJDjNIcLErivP4vFcOFBNITS1KzU1MLUotgskwcnFINjHnTm68+MFxkcTWX 52PRKmPPJZbz69Z7Ca85kWJ+XnrZPDXmvsCQKz8uMF4RmP975gT/INudSirXjMteysqdC5xu duM83/ugOX+s0m433BY1L0ivnVXVUuxQ5Zec2td80a5hf8hzXoZFYU2qyadmrqhuZov5uyxV 6d16llDlLgvehX9zDpgYKbEUZyQaajEXFScCAJrnG5q/AgAA Archived-At: Cc: "teas-chairs@ietf.org" , "ccamp-chairs@ietf.org" Subject: Re: [Teas] Joint WG last call on draft-ietf-ospf-availability-extension-04 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 13 May 2016 10:09:46 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE48162CDFB4ESESSMB301erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R29vZCBwb2ludCBBY2VlLg0KDQpJIGFncmVlIHdpdGggeW91IEnigJltIGZpbmUgd2l0aCB1cGRh dGluZyB0aGUgSUQgYWNjb3JkaW5nbHkuDQoNClRoYW5rcw0KRGFuaWVsZQ0KDQpGcm9tOiBBY2Vl IExpbmRlbSAoYWNlZSkgW21haWx0bzphY2VlQGNpc2NvLmNvbV0NClNlbnQ6IGdpb3ZlZMOsIDEy IG1hZ2dpbyAyMDE2IDEzOjQyDQpUbzogRGFuaWVsZSBDZWNjYXJlbGxpOyBDQ0FNUCAoY2NhbXBA aWV0Zi5vcmcpOyBURUFTIFdHICh0ZWFzQGlldGYub3JnKQ0KQ2M6IGNjYW1wLWNoYWlyc0BpZXRm Lm9yZzsgdGVhcy1jaGFpcnNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVGVhc10gSm9pbnQgV0cg bGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtb3NwZi1hdmFpbGFiaWxpdHktZXh0ZW5zaW9uLTA0DQoN CkkgcmVhbGl6ZSBpdCBoYXMgYWx3YXlzIGJlZW4gdGhpcyB3YXkgYnV0IHRoZSB0ZXJtaW5vbG9n eSBvZiB0aGUgZHJhZnQgKGluY2x1ZGluZyB0aGUgdGl0bGUpIGlzIHNvbWV3aGF0IG1pc2xlYWRp bmcgYXMgdGhlIGRvZXMgbm90IGV4dGVuZCB0aGUgT1NQRiByb3V0aW5nIHByb3RvY29sLiBSYXRo ZXIsIGl0ICBleHRlbmRzIHRoZSBPU1BGIEdNUExTIGVuY29kaW5ncyBhcyBkZWZpbmVkIGluIFJG QyA0MjAzLg0KVGhhbmtzLA0KQWNlZQ0KDQpGcm9tOiBUZWFzIDx0ZWFzLWJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOnRlYXMtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBEYW5pZWxlIENl Y2NhcmVsbGkgPGRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb208bWFpbHRvOmRhbmllbGUu Y2VjY2FyZWxsaUBlcmljc3Nvbi5jb20+Pg0KRGF0ZTogVGh1cnNkYXksIE1heSAxMiwgMjAxNiBh dCA0OjI1IEFNDQpUbzogIkNDQU1QIChjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5v cmc+KSIgPGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4+LCAiVEVBUyBXRyAo dGVhc0BpZXRmLm9yZzxtYWlsdG86dGVhc0BpZXRmLm9yZz4pIiA8dGVhc0BpZXRmLm9yZzxtYWls dG86dGVhc0BpZXRmLm9yZz4+DQpDYzogImNjYW1wLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86Y2Nh bXAtY2hhaXJzQGlldGYub3JnPiIgPGNjYW1wLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86Y2NhbXAt Y2hhaXJzQGlldGYub3JnPj4sICJ0ZWFzLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86dGVhcy1jaGFp cnNAaWV0Zi5vcmc+IiA8dGVhcy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOnRlYXMtY2hhaXJzQGll dGYub3JnPj4NClN1YmplY3Q6IFtUZWFzXSBKb2ludCBXRyBsYXN0IGNhbGwgb24gZHJhZnQtaWV0 Zi1vc3BmLWF2YWlsYWJpbGl0eS1leHRlbnNpb24tMDQNCg0KQ0NBTVAsIFRFQVMsDQoNClRoaXMg c3RhcnRzIGEgdHdvIHdlZWtzIGpvaW50IHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uIGRyYWZ0 LWlldGYtY2NhbXAtb3NwZi1hdmFpbGFiaWxpdHktZXh0ZW5zaW9uLTA0DQpUaGUgbGFzdCBjYWxs IGVuZCBvbiBXZWRuZXNkYXkgTWF5IDI2dGguIFBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8g Ym90aCB0aGUgQ0NBTVAgYW5kIFRFQVMgbWFpbGluZyBsaXN0cy4NCg0KQWxsIHRoZSBJUFIgZGVj bGFyYXRpb25zIGZyb20gYXV0aG9ycyBhbmQgY29udHJpYnV0b3JzIGhhdmUgYmVlbiBjb2xsZWN0 ZWQgYW5kIGNhbiBiZSBmb3VuZCBpbiB0aGUgaGlzdG9yeSBvZiB0aGUgZG9jdW1lbnQ6IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY2NhbXAtb3NwZi1hdmFpbGFi aWxpdHktZXh0ZW5zaW9uL2hpc3RvcnkvDQpQbGVhc2Ugbm90ZSB0aGF0IG5vIElQUiB3YXMgZGlz Y2xvc2VkIGFnYWluc3QgdGhpcyBkcmFmdC4NCg0KQXMgdXN1YWwgdGhpcyBpcyBhbHNvIGEgY2Fs bCBmb3Igc2hlcGhlcmQuIElmIGFueW9uZSBpcyB3aWxsaW5nIHRvIGJlIHRoZSBzaGVwaGVyZCBv ZiB0aGUgZG9jdW1lbnQsIHBsZWFzZSB2b2x1bnRlZXIuDQoNCg0KDQpUaGFua3MNCg0KRGFuaWVs ZSwgRmF0YWksIExvdSwgUGF2YW4NCg0K --_000_4A1562797D64E44993C5CBF38CF1BE48162CDFB4ESESSMB301erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRl LCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xp c3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0K CW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYu MHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFt ZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkdv b2QgcG9pbnQgQWNlZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkkgYWdy ZWUgd2l0aCB5b3UgSeKAmW0gZmluZSB3aXRoIHVwZGF0aW5nIHRoZSBJRCBhY2NvcmRpbmdseS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoYW5rczxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5EYW5pZWxlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFjZWUgTGluZGVtIChhY2Vl KSBbbWFpbHRvOmFjZWVAY2lzY28uY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IGdpb3ZlZMOsIDEy IG1hZ2dpbyAyMDE2IDEzOjQyPGJyPg0KPGI+VG86PC9iPiBEYW5pZWxlIENlY2NhcmVsbGk7IEND QU1QIChjY2FtcEBpZXRmLm9yZyk7IFRFQVMgV0cgKHRlYXNAaWV0Zi5vcmcpPGJyPg0KPGI+Q2M6 PC9iPiBjY2FtcC1jaGFpcnNAaWV0Zi5vcmc7IHRlYXMtY2hhaXJzQGlldGYub3JnPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbVGVhc10gSm9pbnQgV0cgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYt b3NwZi1hdmFpbGFiaWxpdHktZXh0ZW5zaW9uLTA0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2NvbG9yOmJsYWNrIj5JIHJlYWxpemUgaXQgaGFzIGFsd2F5cyBiZWVuIHRoaXMgd2F5IGJ1dCB0 aGUgdGVybWlub2xvZ3kgb2YgdGhlIGRyYWZ0IChpbmNsdWRpbmcgdGhlIHRpdGxlKSBpcyBzb21l d2hhdCBtaXNsZWFkaW5nIGFzIHRoZSBkb2VzIG5vdCBleHRlbmQgdGhlIE9TUEYgcm91dGluZyBw cm90b2NvbC4gUmF0aGVyLCBpdCAmbmJzcDtleHRlbmRzIHRoZSBPU1BGDQogR01QTFMgZW5jb2Rp bmdzIGFzIGRlZmluZWQgaW4gUkZDIDQyMDMuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Y29sb3I6YmxhY2siPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtjb2xvcjpibGFjayI+QWNlZSZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPlRlYXMgJmx0OzxhIGhyZWY9Im1haWx0bzp0ZWFzLWJvdW5jZXNAaWV0Zi5vcmciPnRlYXMt Ym91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBEYW5pZWxlIENlY2NhcmVsbGkg Jmx0OzxhIGhyZWY9Im1haWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tIj5kYW5p ZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VGh1 cnNkYXksIE1heSAxMiwgMjAxNiBhdCA0OjI1IEFNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtDQ0FN UCAoPGEgaHJlZj0ibWFpbHRvOmNjYW1wQGlldGYub3JnIj5jY2FtcEBpZXRmLm9yZzwvYT4pJnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Y2NhbXBAaWV0Zi5vcmciPmNjYW1wQGlldGYub3JnPC9h PiZndDssICZxdW90O1RFQVMgV0cgKDxhIGhyZWY9Im1haWx0bzp0ZWFzQGlldGYub3JnIj50ZWFz QGlldGYub3JnPC9hPikmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp0ZWFzQGlldGYub3JnIj50 ZWFzQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90OzxhIGhyZWY9Im1haWx0 bzpjY2FtcC1jaGFpcnNAaWV0Zi5vcmciPmNjYW1wLWNoYWlyc0BpZXRmLm9yZzwvYT4mcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpjY2FtcC1jaGFpcnNAaWV0Zi5vcmciPmNjYW1wLWNoYWlyc0Bp ZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86dGVhcy1jaGFpcnNAaWV0Zi5v cmciPnRlYXMtY2hhaXJzQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRl YXMtY2hhaXJzQGlldGYub3JnIj50ZWFzLWNoYWlyc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+ U3ViamVjdDogPC9iPltUZWFzXSBKb2ludCBXRyBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1vc3Bm LWF2YWlsYWJpbGl0eS1leHRlbnNpb24tMDQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tcmln aHQ6MGNtIiBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Q0NB TVAsIFRFQVMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoaXMgc3RhcnRzIGEg dHdvIHdlZWtzIGpvaW50IHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtY2Nh bXAtb3NwZi1hdmFpbGFiaWxpdHktZXh0ZW5zaW9uLTA0PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUgbGFzdCBj YWxsIGVuZCBvbiBXZWRuZXNkYXkgTWF5IDI2PHN1cD50aDwvc3VwPi4gUGxlYXNlIHNlbmQgeW91 ciBjb21tZW50cyB0byBib3RoIHRoZSBDQ0FNUCBhbmQgVEVBUyBtYWlsaW5nIGxpc3RzLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5BbGwgdGhlIElQUiBkZWNsYXJhdGlvbnMgZnJv bSBhdXRob3JzIGFuZCBjb250cmlidXRvcnMgaGF2ZSBiZWVuIGNvbGxlY3RlZCBhbmQgY2FuIGJl IGZvdW5kIGluIHRoZSBoaXN0b3J5IG9mIHRoZSBkb2N1bWVudDoNCjxhIGhyZWY9Imh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY2NhbXAtb3NwZi1hdmFpbGFiaWxp dHktZXh0ZW5zaW9uL2hpc3RvcnkvIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtY2NhbXAtb3NwZi1hdmFpbGFiaWxpdHktZXh0ZW5zaW9uL2hpc3RvcnkvPC9h PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+UGxlYXNlIG5vdGUgdGhhdCBubyBJUFIgd2FzIGRpc2Nsb3NlZCBhZ2Fp bnN0IHRoaXMgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkFzIHVzdWFs IHRoaXMgaXMgYWxzbyBhIGNhbGwgZm9yIHNoZXBoZXJkLiBJZiBhbnlvbmUgaXMgd2lsbGluZyB0 byBiZSB0aGUgc2hlcGhlcmQgb2YgdGhlIGRvY3VtZW50LCBwbGVhc2Ugdm9sdW50ZWVyLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoYW5rczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPkRhbmllbGUsIEZhdGFpLCBMb3UsIFBhdmFuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4A1562797D64E44993C5CBF38CF1BE48162CDFB4ESESSMB301erics_-- From nobody Fri May 13 03:46:49 2016 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 DB82E12B032; Fri, 13 May 2016 03:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sZT1Ts2R1U9; Fri, 13 May 2016 03:46:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C6B712B020; Fri, 13 May 2016 03:46:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJU87956; Fri, 13 May 2016 10:46:42 +0000 (GMT) Received: from BLREML405-HUB.china.huawei.com (10.20.4.41) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 13 May 2016 11:46:41 +0100 Received: from BLREML509-MBX.china.huawei.com ([169.254.7.238]) by BLREML405-HUB.china.huawei.com ([10.20.4.41]) with mapi id 14.03.0235.001; Fri, 13 May 2016 16:16:35 +0530 From: Dhruv Dhody To: "'adrian@olddog.co.uk'" , "teas@ietf.org" Thread-Topic: [Teas] A unified draft on resource scheduling Thread-Index: AdGquU0SuIg3y/cpQh2ZgOTeJKNB2ABVeU5A Date: Fri, 13 May 2016 10:46:34 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8C77142B@BLREML509-MBX.china.huawei.com> References: <015f01d1aab9$4f16c8e0$ed445aa0$@olddog.co.uk> In-Reply-To: <015f01d1aab9$4f16c8e0$ed445aa0$@olddog.co.uk> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.18.244.252] Content-Type: multipart/mixed; boundary="_002_23CE718903A838468A8B325B80962F9B8C77142BBLREML509MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5735B092.016A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.238, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 44349529605ca6d9ad8309a7a5036583 Archived-At: Cc: "draft-zhuang-teas-scheduled-resources@ietf.org" Subject: Re: [Teas] A unified draft on resource scheduling X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 13 May 2016 10:46:48 -0000 --_002_23CE718903A838468A8B325B80962F9B8C77142BBLREML509MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, This is good draft, thanks for consolidating.=20 I have one suggestion that IMHO can improve the document. If we can display TS-TED and TS-LSP-DB as a separate component (of course implementation can choose to implement them together) would help in highlighting which part is new and which, already exist (such as the interfaces (d), (e), (f) and now (b1) and (c1) ). =20 ------------------- | Service Requester | ------------------- ^ a| v ------- b1 -------- | |<--->| LSP-DB | | | -------- | PCE | b2 ----------- | |<------>| TS-LSP-DB | | | ----------- | | | | c1 ----- | |<---->| TED | | | ----- | | c2 -------- | |<------>| TS-TED | | | -------- ------- ^ ^ | | d| |e | | ------+-----+-------------------- | | Network | -------- | | Router | v -------- ----- ----- | LSR |<------>| LSR | ----- f -----=20 Some other comments -=20 (1) We can explicitly highlight the benefit of this architecture=20 v/s doing time-scheduling at NMS/OSS layer.=20 (2) In section 2.4 which describes Requisite state information=20 can we also describe the future LSP state that needs to be=20 maintained, most of the description that exist for resource on each=20 link is also applicable to future LSP (for ex. Start time, end=20 time, cycle etc) Thanks!=20 Dhruv > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: 10 May 2016 18:12 > To: teas@ietf.org > Cc: draft-zhuang-teas-scheduled-resources@ietf.org > Subject: [Teas] A unified draft on resource scheduling >=20 > Hi All, >=20 > In Yokohama two I-Ds were presented that showed different approaches to > managing scheduled resource usage in TE networks. Since then the authors > of the two drafts have spent time discussing the best way forward to merg= e > their ideas. >=20 > We have now reached that point and posted a new revision of one of the dr= afts > (see below) that we are all happy with as an overall architecture. >=20 > We think that the WG in Yokohama expressed an interest in having this sor= t > of document to record consensus on how to handle resource scheduling and > serve as a basis for any protocol extension work. >=20 > If that is right, we believe that this document is now ready for the WG > to consider for adoption and to develop into a TEAS RFC. >=20 > Please review and let us know your thoughts. >=20 > Chairs: any next steps for adoption? >=20 > Thanks, > Adrian >=20 > > -----Original Message----- > > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > > internet-drafts@ietf.org > > Sent: 10 May 2016 10:16 > > To: i-d-announce@ietf.org > > Subject: I-D Action: draft-zhuang-teas-scheduled-resources-02.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : Architecture for Scheduled Use of Resources > > Authors : Yan Zhuang > > Qin Wu > > Huaimo Chen > > Adrian Farrel > > Filename : draft-zhuang-teas-scheduled-resources-02.txt > > Pages : 13 > > Date : 2016-05-10 > > > > Abstract: > > Time-Scheduled reservation of traffic engineering (TE) resources can > > be used to provide resource booking for TE Label Switched Paths so a= s > > to better guarantee services for customers and to improve the > > efficiency of network resource usage into the future. This document > > provides a framework that describes and discusses the architecture > > for the scheduled reservation of TE resources. This document does > > not describe specific protocols or protocol extensions needed to > > realize this service. > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-zhuang-teas-scheduled-resources > > / > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-zhuang-teas-scheduled-resources-02 > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-zhuang-teas-scheduled-resource > > s-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/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas --_002_23CE718903A838468A8B325B80962F9B8C77142BBLREML509MBXchi_ Content-Type: application/octet-stream; name="draft-zhuang-teas-scheduled-resources-02.nroff" Content-Description: draft-zhuang-teas-scheduled-resources-02.nroff Content-Disposition: attachment; filename="draft-zhuang-teas-scheduled-resources-02.nroff"; size=7849; creation-date="Thu, 12 May 2016 06:41:22 GMT"; modification-date="Thu, 12 May 2016 06:41:22 GMT" Content-Transfer-Encoding: base64 LnBsIDEwLjBpDQoucG8gMA0KLmxsIDcuMmkNCi5sdCA3LjJpDQoubnIgTEwgNy4yaQ0KLm5yIExU IDcuMmkNCi5kcyBMRiA8QXV0aG9yPiANCi5kcyBSRiBGT1JNRkVFRFtQYWdlICVdDQouZHMgTEgg SU5URVJORVQgRFJBRlQNCi5kcyBSSCA8SXNzdWUgRGF0ZT4NCi5kcyBDSCA8RG9jdW1lbnQgVGl0 bGU+DQouZHMgQ0YgRXhwaXJlcyA8RXhwaXJ5IERhdGU+DQouaHkgMA0KLm5oDQouYWQgbA0KLmlu IDANCg0KLm5mDQoudGwgJ0lOVEVSTkVULURSQUZUJyc8QXV0aG9yPicNCi50bCAnSW50ZW5kZWQg U3RhdHVzOiA8U3RhdHVzLCBlLmcuUHJvcG9zZWQgU3RhbmRhcmQ+JycoPEF1dGhvciBPcmc+KScN Ci50bCAnRXhwaXJlczogPEV4cGlyeSBEYXRlPicnPElzc3VlIERhdGU+Jw0KLmZpDQoNCi5cIiBO b3RlLiBUaGUgIi50bCIgZGlyZWN0aXZlIGlzIHVzZWQgdG8gZ2VuZXJhdGUgdGhlIGxlYWRpbmcg aGVhZGVyIA0KLlwiIGluIEludGVybmV0IGRyYWZ0cy4gVGhlIGluZm9ybWF0aW9uIHNwZWNpZmll ZCBhZnRlciAiLnRsIiBwcm92aWRlcw0KLlwiIGxlZnQsIGNlbnRlciBhbmQgcmlnaHQgY29tcG9u ZW50cyBvZiBhIGxpbmUgc2VwYXJhdGVkIGJ5IHRoZSAnIGNoYXJhY3Rlcg0KLlwiIGluIHRoZSBm b2xsb3dpbmcgbWFubmVyOg0KLlwiIA0KLlwiICAudGwgJzxsZWZ0IGNvbXBvbmVudD4nPGNlbnRl ciBjb21wb25lbnQ+JzxyaWdodCBjb21wb25lbnQ+Jw0KLlwiDQouXCIgT25seSB0aGUgbGVmdCBh bmQgcmlnaHQgY29tcG9uZW50cyBhcmUgdXNlZCBpbiBJbnRlcm5ldC1kcmFmdCBoZWFkZXJzDQou XCIgVGhpcyBhbmQgb3RoZXIgY29tbWVudHMgaW4gdGhpcyB0ZW1wbGF0ZSBjYW4gc2FmZWx5IGJl IGRlbGV0ZWQuDQoNCi5jZSAyDQo8U3RhbmRhcmQgTmFtZT4gDQpkcmFmdC1pZXRmLWdyb3VwT3JT dWJtaXR0ZXItbmFtZS0wMA0KLmZpDQouaW4gMw0KDQoNCi50aSAwDQpBYnN0cmFjdA0KDQo8QWJz dHJhY3QgVGV4dD4NCg0KDQoudGkgMA0KU3RhdHVzIG9mIHRoaXMgTWVtbw0KDQpUaGlzIEludGVy bmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCB0byBJRVRGIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0 aGUgcHJvdmlzaW9ucyBvZiBCQ1BcMDc4IGFuZCBCQ1BcMDc5Lg0KDQpJbnRlcm5ldC1EcmFmdHMg YXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNrIEZv cmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0 IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIFwl SW50ZXJuZXQtRHJhZnRzLg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2 YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBs YWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkgdGltZS4gIEl0IGlz IGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UgbWF0ZXJp YWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQpU aGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQgXCVo dHRwOi8vd3d3LmlldGYub3JnLzFpZC1hYnN0cmFjdHMuaHRtbA0KDQpUaGUgbGlzdCBvZiBJbnRl cm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0IGh0dHA6Ly93 d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwNCg0KDQoudGkgMA0KQ29weXJpZ2h0IGFuZCBMaWNlbnNl IE5vdGljZVwiIEJvaWxlcnBsYXRlIGZyb20gRGVjZW1iZXIgMjAwOQ0KDQouXCIgTk9URTogSW5z ZXJ0IGN1cnJlbnQgPHllYXI+IGluIHRoZSBmb2xsb3dpbmcgcGFyYWdyYXBoDQpDb3B5cmlnaHQg KGMpIDx5ZWFyPiBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZSBk b2N1bWVudCBhdXRob3JzLiBBbGwgcmlnaHRzIHJlc2VydmVkLg0KDQpUaGlzIGRvY3VtZW50IGlz IHN1YmplY3QgdG8gQkNQXDA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbCBQcm92aXNpb25z IFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzIFwlKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xp Y2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mIHB1YmxpY2F0aW9uIG9mIHRoaXMg ZG9jdW1lbnQuIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzIGNhcmVmdWxseSwgYXMgdGhl eSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVjdCB0byB0 aGlzIGRvY3VtZW50LiBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVu dCBtdXN0IGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBp biBTZWN0aW9uXDA0LmUgb2YgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92 aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzIGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0Qg TGljZW5zZS4NCg0KDQoNCi5cIiBcIyBURDQgIC0tIFNldCBUT0MgZGVwdGggYnkgYWx0ZXJpbmcg dGhpcyB2YWx1ZSAoVEQ1ID0gZGVwdGggNSkNCi5cIiBcIyBUT0MgIC0tIEJlZ2lubmluZyBvZiBh dXRvIHVwZGF0ZWQgVGFibGUgb2YgQ29udGVudHMNCi5pbiAwDQpUYWJsZSBvZiBDb250ZW50cw0K DQoubmYNCiAgIDEgIEludHJvZHVjdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgMw0KICAgICAxLjEgIFRlcm1pbm9sb2d5IC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzDQogICAyLiAgVGl0bGUgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMN CiAgIDMgIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgNA0KICAgNCAgSUFOQSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0DQogICA1ICBSZWZlcmVuY2VzICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQNCiAgICAg NS4xICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgNA0KICAgICA1LjIgIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0DQogICBBdXRob3JzJyBBZGRyZXNzZXMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQNCiAgIEhpLCAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgNA0KLmZpDQouaW4gMw0KDQouXCIgXCMgRVRDIC0tIEVuZCBvZiBhdXRvIHVwZGF0ZWQgVGFi bGUgb2YgQ29udGVudHMNCg0KLmJwDQoudGkgMA0KMSAgSW50cm9kdWN0aW9uDQoNCjxJbnRyb2R1 Y3Rpb24gVGV4dD4NCg0KLnRpIDANCjEuMSAgVGVybWlub2xvZ3kNCg0KVGhlIGtleSB3b3JkcyAi TVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLCAiU0hP VUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIg aW4gdGhpcyBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJG QyAyMTE5IFtSRkMyMTE5XS4NCg0KDQoudGkgMA0KMi4gIFRpdGxlDQoNCi5cIiBDb21tZW50IGxp bmUgcHJvdmlkaW5nIGluZm8gZm9yIHRoZSBBdXRob3JzIG9yIHRoZSBSRkMgRWRpdG9yDQo8RG9j dW1lbnQgdGV4dD4NCg0KLmluIDYNCi5uZg0KRGVmaW5pdGlvbnMgYW5kIGNvZGUgew0KICBsaW5l IDENCiAgbGluZSAyDQp9DQouZmkNCi5pbiAzDQoNCi5cIiBEaXJlY3RpdmVzIChlLmcgLnRpIGFu ZCAuaW4pIGFuZCBlc2NhcGUgc2VxdWVuY2VzIChcLCBcJiwgXCUsIFwiIGFuZCBcMCkgYXJlIHVz ZWQgdG8gY29udHJvbA0KLlwiIEZvcm1hdHRpbmcgYW5kIGFyZSBub3QgZGlzcGxheWVkIGluIHRo ZSB0ZXh0IGRvY3VtZW50Lg0KDQpTcGVjaWFsIGNoYXJhY3RlcnMgZXhhbXBsZXM6DQogDQpUaGUg Y2hhcmFjdGVycyBcMCwgXCYsIFwlLCBcIiBhcmUgbm90IHNob3duIGluIHRleHQuDQouXCINCi5c IiBZb3UgY2FuIGRpc3BsYXkgdGhlc2UgY2hhcmFjdGVyIHNlcXVlbmNlcyBpbiB0aGUgdGV4dCBk b2N1bWVudCBieQ0KLlwiIGluc2VydGluZyB0aGUgZXNjYXBlIGNoYXJhY3RlciAnXCcuDQpIb3dl dmVyLCB0aGUgY2hhcmFjdGVycyBcXDAsIFxcJiwgXFwlLCBcXCIgYXJlIGRpc3BsYXllZC4NCg0K XCYudGkgMCAgaXMgZGlzcGxheWVkIGluIHRleHQgaW5zdGVhZCBvZiB1c2VkIGFzIGEgZGlyZWN0 aXZlLiANCi5icg0KXCYuXFwiICBpcyBkaXNwbGF5ZWQgaW4gZG9jdW1lbnQgaW5zdGVhZCBvZiBi ZWluZyB0cmVhdGVkIGFzIGEgY29tbWVudA0KDQpDOlxcZGlyXFxzdWJkaXJcXGZpbGUuZXh0ICBT aG93cyBpbmNsdXNpb24gb2YgYmFja3NsYXNoICJcXCIuDQoNCg0KLmJwDQoudGkgMA0KMyAgU2Vj dXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KPFNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHRleHQ+DQoN Cg0KLnRpIDANCjQgIElBTkEgQ29uc2lkZXJhdGlvbnMNCg0KPElBTkEgY29uc2lkZXJhdGlvbnMg dGV4dD4NCg0KDQoudGkgMA0KNSAgUmVmZXJlbmNlcw0KDQoudGkgMCANCjUuMSAgTm9ybWF0aXZl IFJlZmVyZW5jZXMNCg0KLmluIDE0DQouXCIgXCMgUkVGICAtLSBNYW5hZ2VkIHJlZmVyZW5jZSBs aXN0LiBTeW50YXg6IFtSRkNdbm5ubls7TGFiZWxdLCAuLi4gLFtSRkNdbm5ubls7TGFiZWxdDQou XCIgXCMgMjExOTtLRVlXT1JEUywgMTc3NiwgUkZDMTkyNTtUUlVUSFMNCi5cIiBcIyBFUkYgLS0g RW5kIG9mIG1hbmFnZWQgcmVmZXJlbmNlIGxpc3QNCi5cIiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQouXCIgVGhlIHJlZmVyZW5jZSBsaXN0IGNhbiBiZSBjaGFuZ2Vk IGF0IGFueSB0aW1lIGJ5IGFsdGVyaW5nIHRoZSBSRkMgbGlzdCBpbiB0aGUgbGluZSBiZWxvdyB0 aGUgLlwiIFwjIFJFRiBkaXJlY3RpdmUNCi5cIiBJbiBvcmRlciB0byBleGVjdXRlIGFueSBjaGFu Z2UsIGNsaWNrIG9uIHRoZSAnVXBkYXRlIEFsbCcgYnV0dG9uIG9yIHNlbGVjdCAiVXBkYXRlICdU YWJsZSBvZiBDb250ZW50cycgYW5kIFJlZmVyZW5jZXMiDQouXCIgZnJvbSB0aGUgIkVkaXQiIG1l bnUgb3IgcHJlc3MgPEYzPi4NCi5cIiBOT1RFOiBNYW5hZ2VkIHJlZmVyZW5jZSBsaXN0IHJlcXVp cmVzIE5yb2ZmRWRpdCB2ZXJzaW9uIDEuNDAgb3IgbGF0ZXIuDQoNCi50aSAwDQo1LjIgIEluZm9y bWF0aXZlIFJlZmVyZW5jZXMNCg0KLmluIDE0DQouXCIgXCMgUkVGICAtLSBNYW5hZ2VkIHJlZmVy ZW5jZSBsaXN0LiBTeW50YXg6IFtSRkNdbm5ubls7TGFiZWxdLCAuLi4gLFtSRkNdbm5ubls7TGFi ZWxdDQouXCIgXCMgMzUxNDtFVklMQklULCA1NTEzLCA1NTE0DQouXCIgXCMgRVJGIC0tIEVuZCBv ZiBtYW5hZ2VkIHJlZmVyZW5jZSBsaXN0DQouaW4gMw0KDQoNCi50aSAwDQpBdXRob3JzJyBBZGRy ZXNzZXMNCg0KLnNwDQoubmYNCk5hbWUNCmFuZA0KQWRkcmVzcw0KDQpFTWFpbDogbmFtZUBleGFt cGxlLmNvbQ0KLnNwDQouZmkNCg0KLnRpIDANCkhpLA0KDQpUaGlzIGlzIGdvb2QgZHJhZnQsIHRo YW5rcyBmb3IgY29uc29saWRhdGluZy4gDQoNCkkgaGF2ZSBvbmUgc3VnZ2VzdGlvbiB0aGF0IElN SE8gY2FuIGltcHJvdmUgdGhlIGRvY3VtZW50LiANCklmIHdlIGNhbiBkaXNwbGF5IFRTLVRFRCBh bmQgVFMtTFNQLURCIGFzIGEgc2VwYXJhdGUgY29tcG9uZW50IChvZiBjb3Vyc2UgaW1wbGVtZW50 YXRpb24gY2FuIGNob29zZSB0byBpbXBsZW1lbnQgdGhlbSB0b2dldGhlcikgd291bGQgaGVscCBp biBoaWdobGlnaHRpbmcgd2hpY2ggcGFydCBpcyBuZXcgYW5kIHdoaWNoIGFscmVhZHkgZXhpc3Qg KGFzIG1vc3Qgb2YgdGhlIGludGVyZmFjZXMgKGQpLCAoZSksIChmKSBhbmQgbm93IChiMSkgYW5k IChjMSkgYWxyZWFkeSBleGlzdCkuICAgDQoNCi5uZg0KICAgICAgICAgIC0tLS0tLS0tLS0tLS0t LS0tLS0NCiAgICAgICAgIHwgU2VydmljZSBSZXF1ZXN0ZXIgfA0KICAgICAgICAgIC0tLS0tLS0t LS0tLS0tLS0tLS0NCiAgICAgICAgICAgICAgICAgICAgIF4NCiAgICAgICAgICAgICAgICAgICAg YXwNCiAgICAgICAgICAgICAgICAgICAgIHYNCiAgICAgICAgICAgICAgICAgIC0tLS0tLS0gICBi MSAgLS0tLS0tLS0NCiAgICAgICAgICAgICAgICAgfCAgICAgICB8PC0tLT58IExTUC1EQiB8DQog ICAgICAgICAgICAgICAgIHwgICAgICAgfCAgICAgIC0tLS0tLS0tDQogICAgICAgICAgICAgICAg IHwgIFBDRSAgfCAgYjIgICAgIC0tLS0tLS0tLS0tDQogICAgICAgICAgICAgICAgIHwgICAgICAg fDwtLS0tLS0+fCBUUy1MU1AtREIgfA0KICAgICAgICAgICAgICAgICB8ICAgICAgIHwgICAgICAg ICAtLS0tLS0tLS0tLQ0KICAgICAgICAgICAgICAgICB8ICAgICAgIHwNCiAgICAgICAgICAgICAg ICAgfCAgICAgICB8DQogICAgICAgICAgICAgICAgIHwgICAgICAgfCAgYzEgICAtLS0tLQ0KICAg ICAgICAgICAgICAgICB8ICAgICAgIHw8LS0tLT58IFRFRCB8DQogICAgICAgICAgICAgICAgIHwg ICAgICAgfCAgICAgICAtLS0tLQ0KICAgICAgICAgICAgICAgICB8ICAgICAgIHwgIGMyICAgICAt LS0tLS0tLQ0KICAgICAgICAgICAgICAgICB8ICAgICAgIHw8LS0tLS0tPnwgVFMtVEVEIHwNCiAg ICAgICAgICAgICAgICAgfCAgICAgICB8ICAgICAgICAgLS0tLS0tLS0NCiAgICAgICAgICAgICAg ICAgfCAgICAgICB8DQogICAgICAgICAgICAgICAgICAtLS0tLS0tDQogICAgICAgICAgICAgICAg ICBeICAgICBeDQogICAgICAgICAgICAgICAgICB8ICAgICB8DQogICAgICAgICAgICAgICAgIGR8 ICAgICB8ZQ0KICAgICAgICAgICAgICAgICAgfCAgICAgfA0KICAgICAgICAgICAgLS0tLS0tKy0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgICAgICAgICAgICAgICB8ICAgICB8ICAgICAg ICAgIE5ldHdvcmsNCiAgICAgICAgICAgICAgICAgIHwgICAgIC0tLS0tLS0tDQogICAgICAgICAg ICAgICAgICB8ICAgIHwgUm91dGVyIHwNCiAgICAgICAgICAgICAgICAgIHYgICAgIC0tLS0tLS0t DQogICAgICAgICAgICAgICAgLS0tLS0gICAgICAgICAgLS0tLS0NCiAgICAgICAgICAgICAgIHwg TFNSIHw8LS0tLS0tPnwgTFNSIHwNCiAgICAgICAgICAgICAgICAtLS0tLSAgICAgZiAgICAtLS0t LQ0KDQouaW4gMw0KU29tZSBvdGhlciBjb21tZW50cyAtIA0KDQooMSkgV2UgY2FuIGV4cGxpY2l0 bHkgaGlnaGxpZ2h0IHRoZSBiZW5lZml0IG9mIHRoaXMgYXJjaGl0ZWN0dXJlIA0Kdi9zIGRvaW5n IHRpbWUtc2NoZWR1bGluZyBhdCBOTVMvT1NTIGxheWVyLiANCg0KKDIpIEluIHNlY3Rpb24gMi40 IHdoaWNoIGRlc2NyaWJlcyBSZXF1aXNpdGUgc3RhdGUgaW5mb3JtYXRpb24gDQpjYW4gd2UgYWxz byBkZXNjcmliZSB0aGUgZnV0dXJlIExTUCBzdGF0ZSB0aGF0IG5lZWRzIHRvIGJlIA0KbWFpbnRh aW5lZCwgbW9zdG9mIHRoZSBkZXNjcmlwdGlvbiB0aGF0IGV4aXN0IGZvciByZXNvdXJjZSBvbiBl YWNoIA0KbGluayBpcyBhbHNvIGFwcGxpY2FibGUgdG8gZnV0dXJlIExTUCAoZm9yIGV4LiBTdGFy dCB0aW1lLCBlbmQgDQp0aW1lLCBjeWNsZSBldGMpDQoNCg0KDQoNCg== --_002_23CE718903A838468A8B325B80962F9B8C77142BBLREML509MBXchi_-- From nobody Fri May 13 09:15:22 2016 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 C272E12D5BB; Fri, 13 May 2016 09:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOKQTKLtz5Hs; Fri, 13 May 2016 09:15:03 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E258D12D187; Fri, 13 May 2016 09:15:02 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id u4DGF0SN015304; Fri, 13 May 2016 17:15:00 +0100 Received: from 950129200 ([79.141.128.249]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id u4DGExdl015276 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 13 May 2016 17:15:00 +0100 From: "Adrian Farrel" To: "'Scharf, Michael \(Nokia - DE\)'" , References: <015f01d1aab9$4f16c8e0$ed445aa0$@olddog.co.uk> <655C07320163294895BBADA28372AF5D4884601B@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D4884601B@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Fri, 13 May 2016 17:14:56 +0100 Message-ID: <040a01d1ad32$97ab48d0$c701da70$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG8lBoeJIUMmWIE8+BfLDGiIn/9AQJuPaQOn83KDIA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22320.001 X-TM-AS-Result: No--2.676-10.0-31-10 X-imss-scan-details: No--2.676-10.0-31-10 X-TMASE-MatchedRID: zGP2F0O7j/s4HKI/yaqRm1aA5UKX+E3VQECsueNnG3Tab/3HGLlBic+c wCLpvDnEw7YdcPgEShZjtX6mE5W/ENThl4QBS8PLM8XTtgUzttMyAhDXQri0SMjmhR8Ym2krR0h q5bSfBIZ9coICW+AIlmde1hCXNTEEfAKP1Uqvjuw1CmKclztgU8/uM/bm1ypvq0JLtjyqy0zSLv 4Q3aNAf68eP+y+anJKEubYZQfPWltNfs8n85Te8v7E6GNqs6ceavP8b9lJtWr6C0ePs7A07blX3 Pe+qTcq9ZAc5Pl08nHolC+KqEkE2Zn2gs7rT9Q6Fgo1q2cgEWsaHWFFvlJezt5mCFbkXwr0kJ60 Yg/gc94SHghsuZdoLiXmV/FZxr0Fh8f9+fd10RPkvmU7gj2frT4n7o4CNd3aPbiTch0pm34= Archived-At: Cc: draft-zhuang-teas-scheduled-resources@ietf.org Subject: Re: [Teas] A unified draft on resource scheduling X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk 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, 13 May 2016 16:15:08 -0000 Hello Michael, > I wonder why Section 3.1 does not mention that central storage may have scaling > limitations as well, even if this may not really change the overall tradeoff > between the two approaches. > > I believe it would make sense to also look at the implications of "a busy network > with a high arrival rate of new LSPs and a low hold time for each LSP" for the > centralized case, to have a more balanced discussion. While it may be true that > the centralized approach scales better, e.g., because it can better leverage > modern DB technology, any persistent storage of huge amounts of possibly > highly dynamic data does not come entirely for free, right? Yes, this is a reasonable point and I have it on the list for the next revision (unless you want to suggest text :-) Adrian From nobody Fri May 13 09:33:42 2016 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 1836B12D5DD; Fri, 13 May 2016 09:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NItRA37QVj59; Fri, 13 May 2016 09:33:38 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C89912D5DB; Fri, 13 May 2016 09:33:37 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u4DGXREN009620; Fri, 13 May 2016 17:33:27 +0100 Received: from 950129200 ([79.141.128.249]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u4DGXQgH009605 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 13 May 2016 17:33:26 +0100 From: "Adrian Farrel" To: "'Dhruv Dhody'" , References: <015f01d1aab9$4f16c8e0$ed445aa0$@olddog.co.uk> <23CE718903A838468A8B325B80962F9B8C77142B@BLREML509-MBX.china.huawei.com> In-Reply-To: <23CE718903A838468A8B325B80962F9B8C77142B@BLREML509-MBX.china.huawei.com> Date: Fri, 13 May 2016 17:33:23 +0100 Message-ID: <041101d1ad35$2b8407c0$828c1740$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG8lBoeJIUMmWIE8+BfLDGiIn/9AQKl14dHn8wOi1A= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22320.001 X-TM-AS-Result: No--6.864-10.0-31-10 X-imss-scan-details: No--6.864-10.0-31-10 X-TMASE-MatchedRID: 6otD/cJAac2nykMun0J1wpmug812qIbzC/ExpXrHizy638ZUY6gSd0fY 8VfcKiarQx95p3GYmc8hg9ZU6ER8gvwkUt2a9O4KxZQoGMRGhhM6VbUEB5u/MMWkDW4kV3WaASS 25Kb4JAKbn5kxyyE8ztFHzHVGz8gvYqmUd3tOErVGJnE5XyPHNdIyb6dppQlgXCmcAC8DBrPA1/ n5ffsZh5u0Eiv4P+8mvVoPRFfidXkrOJFe5eLTz8zTXZLlLS82YpovC7zX5q+oOzmgh5mQ65Zac 85UxiH5WiaTAptjMRWFHfMt6I+Wb1Sd1psTkBbtyKTEsCRIdyV9LQinZ4QefL6qvLNjDYTwzz3j ehzeneyrusVRy4an8SdET58jp62S+QLXYsEeAb2xj2odhee8NUFvatpNcyTtFjfub10jjfNWdS1 RvZacPV183h/RihP6QKf2KujQinFD+5BMfr7AroQV1g0SZIsu6Hq9RCTLxvsstHmcXeW1eBVSGW 4LjW40FYnPSoXfG8ckhYHVA/r8kw== Archived-At: Cc: draft-zhuang-teas-scheduled-resources@ietf.org Subject: Re: [Teas] A unified draft on resource scheduling X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk 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, 13 May 2016 16:33:41 -0000 Hi Dhurv, Thanks for your thoughts. > This is good draft, thanks for consolidating. > > I have one suggestion that IMHO can improve the document. If we can > display TS-TED and TS-LSP-DB as a separate component (of course > implementation can choose to implement them together) would help in > highlighting which part is new and which, already exist (such as > the interfaces (d), (e), (f) and now (b1) and (c1) ). > > ------------------- > | Service Requester | > ------------------- > ^ > a| > v > ------- b1 -------- > | |<--->| LSP-DB | > | | -------- > | PCE | b2 ----------- > | |<------>| TS-LSP-DB | > | | ----------- > | | > | | c1 ----- > | |<---->| TED | > | | ----- > | | c2 -------- > | |<------>| TS-TED | > | | -------- > ------- > ^ ^ > | | > d| |e > | | > ------+-----+-------------------- > | | Network > | -------- > | | Router | > v -------- > ----- ----- > | LSR |<------>| LSR | > ----- f ----- If I read this right you are pointing out that the data stored might be split into "the current state of the network" and "future plans". That's a fair point. I would prefer to not complicate the diagram and thereby imply that that split is required in an implementation, but I think the text should point out that this is separate data. We'll work on it. > Some other comments - > > (1) We can explicitly highlight the benefit of this architecture > v/s doing time-scheduling at NMS/OSS layer. Yes. The comparison is so stark that I think it never occurred to us to make it. But it is simple to add and explain that scheduling without a view of the network or an understanding of how services might be placed in the network is likely to result in late surprises or suboptimal network use. > (2) In section 2.4 which describes Requisite state information > can we also describe the future LSP state that needs to be > maintained, most of the description that exist for resource on each > link is also applicable to future LSP (for ex. Start time, end > time, cycle etc) Yes. I have some concerns about the information model in particular because the way the information is held to facilitate an implementation (i.e., the data models) may be very different from how the information is held in permanent storage. But I think you are right that the planned LSPs also need to be held (if for no other reason than the PCE must cause them to be initiated later!) Thanks, Adrian From nobody Fri May 13 09:54:19 2016 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 9FF0E12D5FE for ; Fri, 13 May 2016 09:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5irIiDY9AO0W for ; Fri, 13 May 2016 09:54:17 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDED812D5FA for ; Fri, 13 May 2016 09:54:16 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id u4DGsEiF022121; Fri, 13 May 2016 17:54:14 +0100 Received: from 950129200 ([79.141.128.249]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id u4DGsD3X022115 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 13 May 2016 17:54:14 +0100 From: "Adrian Farrel" To: "'Scharf, Michael \(Nokia - DE\)'" , References: <0c6c01d1a7a2$f1a24860$d4e6d920$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48846127@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D48846127@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Fri, 13 May 2016 17:54:10 +0100 Message-ID: <042101d1ad38$12da5f50$388f1df0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJA1E+Zq/sUNt+MoVFJT1Mxjgw0wgGJwDglnsxz4HA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22320.001 X-TM-AS-Result: No--3.829-10.0-31-10 X-imss-scan-details: No--3.829-10.0-31-10 X-TMASE-MatchedRID: 9zTThWtzImvvkBiM1eNiXpmug812qIbzC/ExpXrHizyCsBeCv8CM/SFS iPJ1ANBwuk+Uz5O8aqTUljiP9jtgVmGN6M1vhJ4HxZQoGMRGhhNQCOsAlaxN7yzhrBYbT/iEjJp bgmqCT3WE7B8l9ThvGNs+VuS9haRJB4rexQR1xI7YxkZC4pzxSASU19bH/YovdEG7y+D7o5ADkd 7WQNL44uLzNWBegCW2XC3N7C7YzrfkwjHXXC/4I8ZW5ai5WKlybYqOwk2wopen0ylBmODtAF73X Ujvl3sKm54TvX30BJI9XruKRA0RUfswZ4HykcCEXgVUmQ63693GFIkxFd95krWpP9ogUTt0NhaO BHxzal2OTCSnRTeg+iPVIUGLlI4nRt01ZrBZr35mO3qi78sNJA== Archived-At: Subject: Re: [Teas] A New I-D on PCE as a central controller X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk 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, 13 May 2016 16:54:18 -0000 Hello again, Michael, it seems to be my day for replying to your emails. > When reading about uses cases such as L3VPN service delivery in "Section 3.2.3", > what is the author's view on the line of demarcation between NETCONF and > PCEP? Well, I wonder which interface you're talking about. The ones that out in here are: - the interface between customer and operator - the interface between "service orchestrator" and "network orchestrator" The former of these is like the interface used in L3SM. As co-chair of L3SM, you might not be surprised to hear that my view is that NETCONF is a fine solution - well, the use of a YANG data model, in any case. The latter is the interface between "Orchestrator / Service Manager / OSS / NMS" and "PCE-based Controller" as shown on the various figures in the picture. We haven't discussed this interface in the document, and perhaps we should. If you look at Figure 6 (with the hierarchy of controllers) you might observe that the parent controller could be implemented to act as though it is talking to an NE (in the abstract node model) and that means that the southbound interface of the parent controller would be PCEP. That means (of course) that the northbound interface of the child controller would also be PCEP. Then, it might seem obvious that we would want all PCE implementations to behave the same way and so that makes the northbound interface of the parent PCE would/could/should/might also be PCEP. What do you think? Thanks, Adrian From nobody Fri May 13 15:08:00 2016 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 5801B12D1D8 for ; Fri, 13 May 2016 15:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBxfcY-x_ss4 for ; Fri, 13 May 2016 15:07:58 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) (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 8E86F12B05A for ; Fri, 13 May 2016 15:07:58 -0700 (PDT) Received: from pps.filterd (m0000419.ppops.net [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u4DM45t4023533; Fri, 13 May 2016 18:07:57 -0400 Received: from mdwvexchht01.ciena.com (lin1-118-36-28.ciena.com [63.118.36.28]) by mx0a-00103a01.pphosted.com with ESMTP id 22wnm18dtj-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Fri, 13 May 2016 18:07:57 -0400 Received: from ONWVEXCHHT02.ciena.com (10.128.6.17) by MDWVEXCHHT01.ciena.com (10.4.156.175) with Microsoft SMTP Server (TLS) id 8.3.389.2; Fri, 13 May 2016 18:07:56 -0400 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT02.ciena.com ([::1]) with mapi; Fri, 13 May 2016 18:07:56 -0400 From: "Shah, Himanshu" To: Vishnu Pavan Beeram , "teas@ietf.org" Date: Fri, 13 May 2016 18:07:54 -0400 Thread-Topic: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-srlg-collect-05 Thread-Index: AdGhjl9Lm9PlvphJRS+ulp168pRJsQL0mRkQ Message-ID: <40746B2300A8FC4AB04EE722A593182BAC1B121C@ONWVEXCHMB04.ciena.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_40746B2300A8FC4AB04EE722A593182BAC1B121CONWVEXCHMB04cie_" MIME-Version: 1.0 X-TM-AS-Product-Ver: SMEX-11.0.0.4179-8.000.1202-22320.003 X-TM-AS-Result: No--21.472300-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-13_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 impostorscore=0 lowpriorityscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1605130289 Archived-At: Subject: Re: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-srlg-collect-05 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 13 May 2016 22:08:00 -0000 --_000_40746B2300A8FC4AB04EE722A593182BAC1B121CONWVEXCHMB04cie_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29ycnkgZm9yIHRoZSBsYXRlIHJlcGx5Li4gKE9uIFBUTy4uKQ0KDQpXaGlsZSBhZGRpbmcgb2Yg 4oCcY29tcGxldGlvbiBmbGFn4oCdIChvciBzaW1pbGFyIHRvIOKAnHBhcnRpYWwgYml04oCdIHVz ZWQgaW4gQkdQKSB3b3VsZCBoYXZlIGJlZW4gYSBuaWNlIGZlYXR1cmUNCnRvIGhhdmUsIHRoZSBT UkxHIGNvbGxlY3QgZHJhZnQgYnkgaXRzZWxmIGlzIGFuIGltcG9ydGFudCBmZWF0dXJlIHRvIGhh dmUsIHNvLi4NCg0KSSBzdXBwb3J0IHByb2dyZXNzaW5nIHRoZSBkb2N1bWVudCB0byBwdWJsaWNh dGlvbi4NCg0KVGhhbmtzLA0KSGltYW5zaHUNCg0KRnJvbTogVGVhcyBbbWFpbHRvOnRlYXMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFZpc2hudSBQYXZhbiBCZWVyYW0NClNlbnQ6IFRo dXJzZGF5LCBBcHJpbCAyOCwgMjAxNiA0OjQyIFBNDQpUbzogdGVhc0BpZXRmLm9yZw0KU3ViamVj dDogW1RlYXNdIFdHIExhc3QgQ2FsbCBvbiBkcmFmdC1pZXRmLXRlYXMtcnN2cC10ZS1zcmxnLWNv bGxlY3QtMDUNCg0KQWxsLA0KVGhpcyBzdGFydHMgYSB0d28gd2VlayB3b3JraW5nIGdyb3VwIGxh c3QgY2FsbCBvbg0KZHJhZnQtaWV0Zi10ZWFzLXJzdnAtdGUtc3JsZy1jb2xsZWN0LTA1Lg0KDQpU aGUgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBvbiBUaHVyc2RheSwgTWF5IDEydGguIFBs ZWFzZQ0Kc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBURUFTIG1haWxpbmcgbGlzdC4NCg0KQXMg aXMgYWx3YXlzIHRoZSBjYXNlLCBwb3NpdGl2ZSBjb21tZW50cywgZS5nLiwgIkkndmUgcmV2aWV3 ZWQgdGhpcw0KZG9jdW1lbnQgYW5kIGJlbGlldmUgaXQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9u IiwgYXJlIHdlbGNvbWUhDQpUaGlzIGlzIHVzZWZ1bCBhbmQgaW1wb3J0YW50LCBldmVuIGZyb20g YXV0aG9ycy4NCk5vdGUsIElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgb24gdGhpcyBkcmFmdC4NCg0K VGhhbmtzLA0KUGF2YW4gKGFuZCBMb3UpDQo= --_000_40746B2300A8FC4AB04EE722A593182BAC1B121CONWVEXCHMB04cie_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnN0YW50aWE7 DQoJcGFub3NlLTE6MiAzIDYgMiA1IDMgNiAzIDMgMzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvbnN0YW50aWEiLCJzZXJpZiI7DQoJY29sb3I6Ymx1ZTsN Cglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTppdGFsaWM7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2 bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxp PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb25zdGFudGlhIiwi c2VyaWYiO2NvbG9yOmJsdWUnPlNvcnJ5IGZvciB0aGUgbGF0ZSByZXBseS4uIChPbiBQVE8uLik8 bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48aT48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ29uc3RhbnRpYSIsInNlcmlmIjtjb2xv cjpibHVlJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48aT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ29uc3RhbnRp YSIsInNlcmlmIjtjb2xvcjpibHVlJz5XaGlsZSBhZGRpbmcgb2Yg4oCcY29tcGxldGlvbiBmbGFn 4oCdIChvciBzaW1pbGFyIHRvIOKAnHBhcnRpYWwgYml04oCdIHVzZWQgaW4gQkdQKSB3b3VsZCBo YXZlIGJlZW4gYSBuaWNlIGZlYXR1cmU8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48aT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q29uc3RhbnRpYSIsInNlcmlmIjtjb2xvcjpibHVlJz50byBoYXZlLCB0aGUgU1JMRyBjb2xsZWN0 IGRyYWZ0IGJ5IGl0c2VsZiBpcyBhbiBpbXBvcnRhbnQgZmVhdHVyZSB0byBoYXZlLCBzby4uPG86 cD48L286cD48L3NwYW4+PC9pPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PGk+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvbnN0YW50aWEiLCJzZXJpZiI7Y29sb3I6 Ymx1ZSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PGk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvbnN0YW50aWEi LCJzZXJpZiI7Y29sb3I6Ymx1ZSc+SSBzdXBwb3J0IHByb2dyZXNzaW5nIHRoZSBkb2N1bWVudCB0 byBwdWJsaWNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48aT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ29uc3RhbnRp YSIsInNlcmlmIjtjb2xvcjpibHVlJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48aT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDb25zb2xhcztjb2xvcjpibHVlJz5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9pPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PGk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6Ymx1ZSc+SGltYW5zaHU8bzpwPjwvbzpwPjwvc3Bhbj48 L2k+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48aT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ29uc3RhbnRpYSIsInNlcmlmIjtjb2xvcjpibHVlJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2k+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiInPiBUZWFzIFttYWlsdG86dGVhcy1ib3VuY2VzQGlldGYub3JnXSA8 Yj5PbiBCZWhhbGYgT2YgPC9iPlZpc2hudSBQYXZhbiBCZWVyYW08YnI+PGI+U2VudDo8L2I+IFRo dXJzZGF5LCBBcHJpbCAyOCwgMjAxNiA0OjQyIFBNPGJyPjxiPlRvOjwvYj4gdGVhc0BpZXRmLm9y Zzxicj48Yj5TdWJqZWN0OjwvYj4gW1RlYXNdIFdHIExhc3QgQ2FsbCBvbiBkcmFmdC1pZXRmLXRl YXMtcnN2cC10ZS1zcmxnLWNvbGxlY3QtMDU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz5BbGwsPGJyPlRoaXMgc3RhcnRzIGEgdHdv IHdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb248YnI+ZHJhZnQtaWV0Zi10ZWFzLXJzdnAt dGUtc3JsZy1jb2xsZWN0LTA1Ljxicj48YnI+VGhlIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGVu ZHMgb24gVGh1cnNkYXksIE1heSAxMnRoLiBQbGVhc2U8YnI+c2VuZCB5b3VyIGNvbW1lbnRzIHRv IHRoZSBURUFTIG1haWxpbmcgbGlzdC48YnI+PGJyPkFzIGlzIGFsd2F5cyB0aGUgY2FzZSwgcG9z aXRpdmUgY29tbWVudHMsIGUuZy4sICZxdW90O0kndmUgcmV2aWV3ZWQgdGhpczxicj5kb2N1bWVu dCBhbmQgYmVsaWV2ZSBpdCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24mcXVvdDssIGFyZSB3ZWxj b21lITxicj5UaGlzIGlzIHVzZWZ1bCBhbmQgaW1wb3J0YW50LCBldmVuIGZyb20gYXV0aG9ycy48 bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Tm90ZSwgSVBSIGhhcyBiZWVu IGRpc2Nsb3NlZCBvbiB0aGlzIGRyYWZ0LjxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxicj5UaGFua3MsPGJyPlBhdmFuIChhbmQgTG91KTxvOnA+PC9vOnA+PC9wPjwvZGl2 PjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_40746B2300A8FC4AB04EE722A593182BAC1B121CONWVEXCHMB04cie_-- From nobody Fri May 13 17:16:00 2016 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 1BB3212D133; Fri, 13 May 2016 17:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-gFkxFkV7a8; Fri, 13 May 2016 17:15:57 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (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 364F912D098; Fri, 13 May 2016 17:15:54 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id z184so2423735vkg.0; Fri, 13 May 2016 17:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=trORhkrao5904dz0c7ZsP5rTuJVOATJMRBTU48Chots=; b=u2qBUiTWAQHrSn6vdsQEuxjjedHXJMCWc8w3VtY+UU0EOu86LMcqVKSM94HmYuCYgB rMcNvYVILFra6f0oC+OEvuEq4EmLmBZNkLaK5dwAv19Ou31AvfYDqn9zzIVw9zDV12DK WPi1kG3h5f3fUrMgwmhAp5YWMbRuLzRbqnm0HRmV9n8bl4zwe8ZcJreq0i1GhzLEQT3w LLZ1zivmb3APK32ZpVSASuzZg8lTrVb0nYFe9amBuyKDsFMSAOvPBF5ScVQ68IfKPhMq 5wezFkvM773PLuHeUWiIFHxDy8aSPEc2JGKPsQ32fHfdahQG82+ZHAp+jc9d+9/mNRQZ Elvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=trORhkrao5904dz0c7ZsP5rTuJVOATJMRBTU48Chots=; b=RMQ0K4bO4EqdUejGL1Tb/sv94Fz6aiT/tBTs1b3fIbaa6Ys5kRtRCXcERGeB3WFylq ig3jJEPAMeyVAFVP0VWYvd0pMKhZlb4FMGoYGpMjC1SaOtkPxtdhBtA5tvkTWWX/G6q1 eC7qDWaWaVpeQSStZWkOW17CuO+xcaVjoaoChpX4JKYYsY2OW0HLh4fSLgPhfHg5jwZc MOTJGJ87A5s8tbDyCJ5Z7UgmaF4NDVd+p3wtf9JD3lic+zXBXOtjR+nqJOOJ22tsIL7a Nmuwk7ZQo8kgU5BuQqdsnCNeV8ywH8QMVXg28TSQuuYC5lF8E3QDEcsiDEJX0GUmv035 Cgdw== X-Gm-Message-State: AOPr4FW6HZLiLGGTXxU9SoUx+p0cY6/VBGc5uww4jvG2QnrO8f/o4DHCm1epXoDt16n1wt1dQABC0Y5aTreClg== MIME-Version: 1.0 X-Received: by 10.31.139.139 with SMTP id n133mr9456088vkd.71.1463184953083; Fri, 13 May 2016 17:15:53 -0700 (PDT) Received: by 10.31.67.196 with HTTP; Fri, 13 May 2016 17:15:53 -0700 (PDT) In-Reply-To: <40746B2300A8FC4AB04EE722A593182BAC1B121C@ONWVEXCHMB04.ciena.com> References: <40746B2300A8FC4AB04EE722A593182BAC1B121C@ONWVEXCHMB04.ciena.com> Date: Fri, 13 May 2016 20:15:53 -0400 Message-ID: From: Vishnu Pavan Beeram To: "teas@ietf.org" , draft-ietf-teas-rsvp-te-srlg-collect@ietf.org Content-Type: multipart/alternative; boundary=001a11442a645e906f0532c24b02 Archived-At: Subject: Re: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-srlg-collect-05 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 14 May 2016 00:15:59 -0000 --001a11442a645e906f0532c24b02 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The WG LC for this document is now closed. Matt (and other authors), Please go ahead and publish a new revision addressing the minor comments received during the LC. Regards, -Pavan (and Lou) On Fri, May 13, 2016 at 6:07 PM, Shah, Himanshu wrote: > *Sorry for the late reply.. (On PTO..)* > > > > *While adding of =E2=80=9Ccompletion flag=E2=80=9D (or similar to =E2=80= =9Cpartial bit=E2=80=9D used in > BGP) would have been a nice feature* > > *to have, the SRLG collect draft by itself is an important feature to > have, so..* > > > > *I support progressing the document to publication.* > > > > *Thanks,* > > *Himanshu* > > > > *From:* Teas [mailto:teas-bounces@ietf.org] *On Behalf Of *Vishnu Pavan > Beeram > *Sent:* Thursday, April 28, 2016 4:42 PM > *To:* teas@ietf.org > *Subject:* [Teas] WG Last Call on draft-ietf-teas-rsvp-te-srlg-collect-05 > > > > All, > > This starts a two week working group last call on > draft-ietf-teas-rsvp-te-srlg-collect-05. > > The working group last call ends on Thursday, May 12th. Please > send your comments to the TEAS mailing list. > > As is always the case, positive comments, e.g., "I've reviewed this > document and believe it is ready for publication", are welcome! > This is useful and important, even from authors. > > Note, IPR has been disclosed on this draft. > > > Thanks, > Pavan (and Lou) > --001a11442a645e906f0532c24b02 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The WG LC for this document is now closed.
Matt (and other authors),
Please go ahead and publish a new revi= sion addressing the minor comments received during the LC.

Regards,
-Pavan (and Lou)

On Fri, May 13, 2016 at 6:07 PM, Sh= ah, Himanshu <hshah@ciena.com> wrote:

Sorry for the late reply.. (On PTO.= .)

=C2=A0

While adding of =E2=80=9Ccompletion flag=E2=80=9D (or similar t= o =E2=80=9Cpartial bit=E2=80=9D used in BGP) would have been a nice feature=

=C2=A0

I support progressing the document to publication.

= =C2=A0

Thanks,

Himanshu

=C2=A0

From: Teas [mailto:teas-bounces@ietf.o= rg] On Behalf Of Vishnu Pavan Beeram
Sent: Thursday, A= pril 28, 2016 4:42 PM
To: teas@ietf.org
Subject: [Teas] WG= Last Call on draft-ietf-teas-rsvp-te-srlg-collect-05<= /span>

=C2=A0

All,


This starts a two week working group last call on
draft-ietf-teas-= rsvp-te-srlg-collect-05.

The working group last call ends on Thursda= y, May 12th. Please
send your comments to the TEAS mailing list.

= As is always the case, positive comments, e.g., "I've reviewed thi= s
document and believe it is ready for publication", are welcome!This is useful and important, even from authors.

Note, IPR has b= een disclosed on this draft.

<= br>Thanks,
Pavan (and Lou)


--001a11442a645e906f0532c24b02-- From nobody Sun May 15 20:43:03 2016 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 CD94312D0A4; Sun, 15 May 2016 20:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 CnfdA_oWyAfD; Sun, 15 May 2016 20:43:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7533212B071; Sun, 15 May 2016 20:42:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJY87082; Mon, 16 May 2016 03:42:56 +0000 (GMT) Received: from BLREML405-HUB.china.huawei.com (10.20.4.41) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 16 May 2016 04:42:55 +0100 Received: from BLREML509-MBX.china.huawei.com ([169.254.7.95]) by BLREML405-HUB.china.huawei.com ([10.20.4.41]) with mapi id 14.03.0235.001; Mon, 16 May 2016 09:12:51 +0530 From: Dhruv Dhody To: "adrian@olddog.co.uk" , "teas@ietf.org" Thread-Topic: [Teas] A unified draft on resource scheduling Thread-Index: AdGquU0SuIg3y/cpQh2ZgOTeJKNB2ABVeU5AAD33pYAAh2aGsA== Date: Mon, 16 May 2016 03:42:51 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8C796916@BLREML509-MBX.china.huawei.com> References: <015f01d1aab9$4f16c8e0$ed445aa0$@olddog.co.uk> <23CE718903A838468A8B325B80962F9B8C77142B@BLREML509-MBX.china.huawei.com> <041101d1ad35$2b8407c0$828c1740$@olddog.co.uk> In-Reply-To: <041101d1ad35$2b8407c0$828c1740$@olddog.co.uk> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.244.252] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.573941C1.004C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.95, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 44349529605ca6d9ad8309a7a5036583 Archived-At: Cc: "draft-zhuang-teas-scheduled-resources@ietf.org" Subject: Re: [Teas] A unified draft on resource scheduling X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 16 May 2016 03:43:02 -0000 Hi Adrian,=20 I agree with all your suggested resolutions. Looking forward to the next up= date.=20 I support putting this work for WG adoption.=20 Thanks! Dhruv > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: 13 May 2016 22:03 > To: Dhruv Dhody ; teas@ietf.org > Cc: draft-zhuang-teas-scheduled-resources@ietf.org > Subject: RE: [Teas] A unified draft on resource scheduling >=20 > Hi Dhurv, >=20 > Thanks for your thoughts. >=20 > > This is good draft, thanks for consolidating. > > > > I have one suggestion that IMHO can improve the document. If we can > > display TS-TED and TS-LSP-DB as a separate component (of course > > implementation can choose to implement them together) would help in > > highlighting which part is new and which, already exist (such as > > the interfaces (d), (e), (f) and now (b1) and (c1) ). > > > > ------------------- > > | Service Requester | > > ------------------- > > ^ > > a| > > v > > ------- b1 -------- > > | |<--->| LSP-DB | > > | | -------- > > | PCE | b2 ----------- > > | |<------>| TS-LSP-DB | > > | | ----------- > > | | > > | | c1 ----- > > | |<---->| TED | > > | | ----- > > | | c2 -------- > > | |<------>| TS-TED | > > | | -------- > > ------- > > ^ ^ > > | | > > d| |e > > | | > > ------+-----+-------------------- > > | | Network > > | -------- > > | | Router | > > v -------- > > ----- ----- > > | LSR |<------>| LSR | > > ----- f ----- >=20 > If I read this right you are pointing out that the data stored might be s= plit > into "the current state of the network" and "future plans". >=20 > That's a fair point. I would prefer to not complicate the diagram and the= reby > imply that that split is required in an implementation, but I think the t= ext > should point out that this is separate data. We'll work on it. >=20 > > Some other comments - > > > > (1) We can explicitly highlight the benefit of this architecture > > v/s doing time-scheduling at NMS/OSS layer. >=20 > Yes. The comparison is so stark that I think it never occurred to us to m= ake > it. > But it is simple to add and explain that scheduling without a view of the > network or an understanding of how services might be placed in the networ= k > is likely to result in late surprises or suboptimal network use. >=20 > > (2) In section 2.4 which describes Requisite state information > > can we also describe the future LSP state that needs to be > > maintained, most of the description that exist for resource on each > > link is also applicable to future LSP (for ex. Start time, end > > time, cycle etc) >=20 > Yes. I have some concerns about the information model in particular becau= se > the way the information is held to facilitate an implementation (i.e., th= e > data > models) may be very different from how the information is held in permane= nt > storage. But I think you are right that the planned LSPs also need to be > held (if for no other reason than the PCE must cause them to be initiated > later!) >=20 > Thanks, > Adrian >=20 From nobody Mon May 16 06:27:31 2016 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 9237D12D169 for ; Mon, 16 May 2016 06:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlHZPOOP10pA for ; Mon, 16 May 2016 06:27:29 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41F5B12D09B for ; Mon, 16 May 2016 06:27:29 -0700 (PDT) Received: by mail-lb0-x22e.google.com with SMTP id jj5so49974258lbc.0 for ; Mon, 16 May 2016 06:27:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=LZ0pFG6SXjhMl7cOqTocKeOlBE42foqOARO/4GkAN4c=; b=fcQKDpFgeoXH+IDDjiYo34E0e2W1qLh/snvESXLiuTkpiyjoZ588pdwZNsHv8U8Uva wRHJSXVXEH0l6II5x+IesiUN7GZbzMJVb6cQU1rfl9Vh36tYMOtXvACsK99/mpsBklPW gXTDkxm6sVdP3yTBBev49pvt6xDcTdjow7JJrPCbSn8m9H28+TPYFiApHjzJf5T2EEtu zlZ4Ir+COCYOM1uzWiFZkunu8tGGgkDsy7YIAIe9RncovoFySf2AwrqbmZnPuUa3W6tH C8uYu/UiV4mOkt04xmHrm7Yn5actV/i+6OqjFiX94/DjJlt+SwfXW3kLKi0Nr4cFHHQy CcmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=LZ0pFG6SXjhMl7cOqTocKeOlBE42foqOARO/4GkAN4c=; b=S0PtrQVRFY2Z2I+1R4DfgRp1JN5GNeUS1Vqq1vWNZUrhjfFQIls0J+/d+jZ1fSsgIG PWQZQ4Hpo0YfMeAaUszbWVMyzPoWBt2dm0BRx/JJ0G2jDnx79+AMplYHPlT2Sttevmi9 8TNMocwnNm7T6n+zagw8QQg5eg96oY6q8ghKYe4GmfUPELJez4uvm3ia/8Fv609mqAB8 t67LJlRefwrpv2lx066YnZG/UB1sMingV0/izcVswHQLHcng6PHFkl1/yNb82HwxGf/N bJ5w/HpngOlAP7Pbz15/gP6pSAVjnzvPNzQHB23AxwSEi5gYX4PZm4l/227ZHuSS6pNw nIYA== X-Gm-Message-State: AOPr4FW2jsjb/d6rPJsCj8DGQkfW5kXyCtrvVxY8+QER6mcSKCQ7LqruRg16LQsqKegM6g== X-Received: by 10.112.172.105 with SMTP id bb9mr9841635lbc.129.1463405247445; Mon, 16 May 2016 06:27:27 -0700 (PDT) Received: from xliuus (wsip-98-191-72-170.dc.dc.cox.net. [98.191.72.170]) by smtp.gmail.com with ESMTPSA id e26sm5279894lfi.9.2016.05.16.06.27.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 May 2016 06:27:26 -0700 (PDT) From: "Xufeng Liu" To: Date: Mon, 16 May 2016 09:27:23 -0400 Message-ID: <02d101d1af76$b0317cd0$10947670$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdGvdpxN0yo8TMwnRjC4jbLnP05ymw== Content-Language: en-us Archived-At: Subject: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 16 May 2016 13:27:30 -0000 Authors and contributors have discussed the use case of abstract topology, to address the incompleteness of connectivity matrix. Current connectivity modeling is as follows: | +--rw connectivity-matrix* [id] | | +--rw id uint32 | | +--rw from | | | +--rw tp-ref? leafref | | +--rw to | | | +--rw tp-ref? leafref | | +--rw is-allowed? Boolean A Link TP may connect or disconnect to another Link TP, without detailed information such as cost and resource sharing restriction. To get a better abstraction of such connectivity, the following additional attributes are planned to be added: max-bandwidth? decimal64 max-resv-bandwidth? decimal64 unreserved-bandwidth* [priority] priority uint8 +-- bandwidth? decimal64 +-- te-default-metric uint32 performance-metric // re-use the container from te-link-atrributes te-srlgs // re-use the container from te-link-atrributes Comments are welcome. Thanks, - Xufeng From nobody Tue May 17 19:33:15 2016 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 1D96D12B025; Tue, 17 May 2016 19:33:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160518023315.24800.18684.idtracker@ietfa.amsl.com> Date: Tue, 17 May 2016 19:33:15 -0700 Archived-At: Cc: draft-ietf-teas-interconnected-te-info-exchange@ietf.org, teas-chairs@ietf.org, teas@ietf.org, lberger@labn.net Subject: [Teas] Spencer Dawkins' Yes on draft-ietf-teas-interconnected-te-info-exchange-06: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 18 May 2016 02:33:15 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-teas-interconnected-te-info-exchange-06: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-interconnected-te-info-exchange/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This document is terrifically helpful. Thanks for producing it. From nobody Wed May 18 10:48:17 2016 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 7B4F312D5FB; Wed, 18 May 2016 10:48:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160518174814.14661.53120.idtracker@ietfa.amsl.com> Date: Wed, 18 May 2016 10:48:14 -0700 Archived-At: Cc: draft-ietf-teas-interconnected-te-info-exchange@ietf.org, teas-chairs@ietf.org, teas@ietf.org, lberger@labn.net Subject: [Teas] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-teas-interconnected-te-info-exchange-06=3A_=28with_COMMENT?= =?utf-8?q?=29?= X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 18 May 2016 17:48:14 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-teas-interconnected-te-info-exchange-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-interconnected-te-info-exchange/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I fully support Alvaro's Discuss and I was just in the process of deciding if I want to raise a Discuss or not when his ballot position came in. Even though this document is well written and provides a lot of interesting information, to be honest, I could not find any recommendation on a best current pratice as this document mainly takes about requirements for future work. For me this document provides a problem statement, use cases, and requirements as well as some survery about the applicability of existing protocols and therefore should be an Informational document. From nobody Wed May 18 14:00:21 2016 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 27BB212D738 for ; Wed, 18 May 2016 14:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVEIuKlRkn3C for ; Wed, 18 May 2016 14:00:17 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A532212D73E for ; Wed, 18 May 2016 14:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10628; q=dns/txt; s=iport; t=1463605215; x=1464814815; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7cqqfOjrFqTORJYPd3VAozOc8V9+5a57Z21F//ZEEj8=; b=Jh9lLHUNUsPlqpYGpzEB3jLl7KNNlImS6WV6F3CfBs3T7/IRbO+9okLD IC1c2iHd97rR4OcAHdUwaidR4Jl6aA1v8rJIW7aH1+3PGkdboodcT4SFl JKk6tVFHLAc3PpAixkx0hQO6YF4ROapARyyc7oUPsKdTK5+z7latjvPzJ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DFAgBr1zxX/4gNJK1egmxLVn4GtHyEe?= =?us-ascii?q?QENgXWGEQIcgSg4FAEBAQEBAQFlJ4RCAQEBBCMKQQsQAgEIEQQBASgDAgICMBQ?= =?us-ascii?q?JCAEBBAENBQiIJ7I2kVEBAQEBAQEBAQEBAQEBAQEBAQEBAQEchiWETYR1gkqCW?= =?us-ascii?q?QWYKwGOGIFwhE+IYo9IAR4BAUKDbW6HBwF+AQEB?= X-IronPort-AV: E=Sophos;i="5.26,330,1459814400"; d="scan'208,217";a="275033647" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 May 2016 21:00:14 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u4IL0Eos011361 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 18 May 2016 21:00:14 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 18 May 2016 16:00:14 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Wed, 18 May 2016 16:00:14 -0500 From: "Matt Hartley (mhartley)" To: "Shah, Himanshu" , Vishnu Pavan Beeram , "teas@ietf.org" Thread-Topic: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-srlg-collect-05 Thread-Index: AdGhjl9Lm9PlvphJRS+ulp168pRJsQL0mRkQAPnZbsA= Date: Wed, 18 May 2016 21:00:14 +0000 Message-ID: <8798c1b7c8834eeb91683fbbe9fa2abf@XCH-RCD-001.cisco.com> References: <40746B2300A8FC4AB04EE722A593182BAC1B121C@ONWVEXCHMB04.ciena.com> In-Reply-To: <40746B2300A8FC4AB04EE722A593182BAC1B121C@ONWVEXCHMB04.ciena.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.193.144] Content-Type: multipart/alternative; boundary="_000_8798c1b7c8834eeb91683fbbe9fa2abfXCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Matt Hartley \(mhartley\)" Subject: Re: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-srlg-collect-05 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 18 May 2016 21:00:19 -0000 --_000_8798c1b7c8834eeb91683fbbe9fa2abfXCHRCD001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzLCBIaW1hbnNodS4NCg0KRldJVywgSSBzZWUgbm8gcmVhc29uIHdoeSB0aGUgY29tcGxl dGlvbiBmbGFnIGNhbuKAmXQgYmUgYWRkZWQgYXMgYSBzdWJzZXF1ZW50IGVuaGFuY2VtZW50IGlu IGEgbmV3IGRyYWZ0LCBpZiB0aGVyZeKAmXMgYSBkZXNpcmUgdG8gZG8gc28uDQoNCkNoZWVycw0K DQpNYXR0DQoNClNvcnJ5IGZvciB0aGUgbGF0ZSByZXBseS4uIChPbiBQVE8uLikNCg0KV2hpbGUg YWRkaW5nIG9mIOKAnGNvbXBsZXRpb24gZmxhZ+KAnSAob3Igc2ltaWxhciB0byDigJxwYXJ0aWFs IGJpdOKAnSB1c2VkIGluIEJHUCkgd291bGQgaGF2ZSBiZWVuIGEgbmljZSBmZWF0dXJlDQp0byBo YXZlLCB0aGUgU1JMRyBjb2xsZWN0IGRyYWZ0IGJ5IGl0c2VsZiBpcyBhbiBpbXBvcnRhbnQgZmVh dHVyZSB0byBoYXZlLCBzby4uDQoNCkkgc3VwcG9ydCBwcm9ncmVzc2luZyB0aGUgZG9jdW1lbnQg dG8gcHVibGljYXRpb24uDQoNClRoYW5rcywNCkhpbWFuc2h1DQoNCkZyb206IFRlYXMgW21haWx0 bzp0ZWFzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBWaXNobnUgUGF2YW4gQmVlcmFt DQpTZW50OiBUaHVyc2RheSwgQXByaWwgMjgsIDIwMTYgNDo0MiBQTQ0KVG86IHRlYXNAaWV0Zi5v cmc8bWFpbHRvOnRlYXNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbVGVhc10gV0cgTGFzdCBDYWxsIG9u IGRyYWZ0LWlldGYtdGVhcy1yc3ZwLXRlLXNybGctY29sbGVjdC0wNQ0KDQpBbGwsDQpUaGlzIHN0 YXJ0cyBhIHR3byB3ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uDQpkcmFmdC1pZXRmLXRl YXMtcnN2cC10ZS1zcmxnLWNvbGxlY3QtMDUuDQoNClRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2Fs bCBlbmRzIG9uIFRodXJzZGF5LCBNYXkgMTJ0aC4gUGxlYXNlDQpzZW5kIHlvdXIgY29tbWVudHMg dG8gdGhlIFRFQVMgbWFpbGluZyBsaXN0Lg0KDQpBcyBpcyBhbHdheXMgdGhlIGNhc2UsIHBvc2l0 aXZlIGNvbW1lbnRzLCBlLmcuLCAiSSd2ZSByZXZpZXdlZCB0aGlzDQpkb2N1bWVudCBhbmQgYmVs aWV2ZSBpdCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24iLCBhcmUgd2VsY29tZSENClRoaXMgaXMg dXNlZnVsIGFuZCBpbXBvcnRhbnQsIGV2ZW4gZnJvbSBhdXRob3JzLg0KTm90ZSwgSVBSIGhhcyBi ZWVuIGRpc2Nsb3NlZCBvbiB0aGlzIGRyYWZ0Lg0KDQpUaGFua3MsDQpQYXZhbiAoYW5kIExvdSkN Cg== --_000_8798c1b7c8834eeb91683fbbe9fa2abfXCHRCD001ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJCb29rbWFuIE9sZCBTdHlsZSI7DQoJcGFub3NlLTE6MiA1IDYgNCA1IDUgNSAyIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnN0YW50aWE7DQoJcGFub3NlLTE6MiAzIDYgMiA1 IDMgNiAzIDMgMzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxT dHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDb25zdGFu dGlhIixzZXJpZjsNCgljb2xvcjpibHVlOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0 eWxlOml0YWxpYzt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQm9va21hbiBPbGQgU3R5bGUiLHNlcmlmOw0KCWNvbG9y OiM5RTM0MDA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1b3Q7LHNlcmlmO2NvbG9yOiM5RTM0MDAi PlRoYW5rcywgSGltYW5zaHUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9v a21hbiBPbGQgU3R5bGUmcXVvdDssc2VyaWY7Y29sb3I6IzlFMzQwMCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9va21hbiBPbGQgU3R5bGUmcXVvdDssc2VyaWY7 Y29sb3I6IzlFMzQwMCI+RldJVywgSSBzZWUgbm8gcmVhc29uIHdoeSB0aGUgY29tcGxldGlvbiBm bGFnIGNhbuKAmXQgYmUgYWRkZWQgYXMgYSBzdWJzZXF1ZW50IGVuaGFuY2VtZW50IGluIGEgbmV3 IGRyYWZ0LCBpZiB0aGVyZeKAmXMgYSBkZXNpcmUgdG8gZG8gc28uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Qm9va21hbiBPbGQgU3R5bGUmcXVvdDssc2VyaWY7Y29sb3I6IzlF MzQwMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9va21hbiBP bGQgU3R5bGUmcXVvdDssc2VyaWY7Y29sb3I6IzlFMzQwMCI+Q2hlZXJzPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9va21hbiBPbGQgU3R5bGUmcXVvdDssc2VyaWY7Y29sb3I6 IzlFMzQwMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9va21h biBPbGQgU3R5bGUmcXVvdDssc2VyaWY7Y29sb3I6IzlFMzQwMCI+TWF0dDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1b3Q7LHNlcmlmO2NvbG9y OiM5RTM0MDAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDb25zdGFudGlhJnF1b3Q7LHNlcmlmO2NvbG9yOmJsdWUi PlNvcnJ5IGZvciB0aGUgbGF0ZSByZXBseS4uIChPbiBQVE8uLik8bzpwPjwvbzpwPjwvc3Bhbj48 L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q29uc3RhbnRpYSZxdW90OyxzZXJpZjtjb2xvcjpibHVl Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q29uc3Rh bnRpYSZxdW90OyxzZXJpZjtjb2xvcjpibHVlIj5XaGlsZSBhZGRpbmcgb2Yg4oCcY29tcGxldGlv biBmbGFn4oCdIChvciBzaW1pbGFyIHRvIOKAnHBhcnRpYWwgYml04oCdIHVzZWQgaW4gQkdQKSB3 b3VsZCBoYXZlIGJlZW4gYSBuaWNlIGZlYXR1cmU8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q29uc3RhbnRpYSZxdW90OyxzZXJpZjtjb2xvcjpibHVlIj50byBoYXZl LCB0aGUgU1JMRyBjb2xsZWN0IGRyYWZ0IGJ5IGl0c2VsZiBpcyBhbiBpbXBvcnRhbnQgZmVhdHVy ZSB0byBoYXZlLCBzby4uPG86cD48L286cD48L3NwYW4+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvbnN0YW50aWEmcXVvdDssc2VyaWY7Y29sb3I6Ymx1ZSI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvbnN0YW50aWEmcXVvdDssc2VyaWY7Y29sb3I6 Ymx1ZSI+SSBzdXBwb3J0IHByb2dyZXNzaW5nIHRoZSBkb2N1bWVudCB0byBwdWJsaWNhdGlvbi48 bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q29uc3RhbnRpYSZxdW90 OyxzZXJpZjtjb2xvcjpibHVlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q29uc29sYXM7Y29sb3I6Ymx1ZSI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvaT48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibHVlIj5IaW1hbnNodTxvOnA+PC9vOnA+PC9z cGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb25zdGFudGlhJnF1b3Q7LHNlcmlmO2NvbG9y OmJsdWUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj4g VGVhcyBbPGEgaHJlZj0ibWFpbHRvOnRlYXMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnRlYXMt Ym91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlZpc2hudSBQYXZhbiBC ZWVyYW08YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEFwcmlsIDI4LCAyMDE2IDQ6NDIgUE08 YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzp0ZWFzQGlldGYub3JnIj50ZWFzQGlldGYu b3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbVGVhc10gV0cgTGFzdCBDYWxsIG9uIGRyYWZ0 LWlldGYtdGVhcy1yc3ZwLXRlLXNybGctY29sbGVjdC0wNTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkFsbCw8 YnI+DQpUaGlzIHN0YXJ0cyBhIHR3byB3ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uPGJy Pg0KZHJhZnQtaWV0Zi10ZWFzLXJzdnAtdGUtc3JsZy1jb2xsZWN0LTA1Ljxicj4NCjxicj4NClRo ZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBlbmRzIG9uIFRodXJzZGF5LCBNYXkgMTJ0aC4gUGxl YXNlPGJyPg0Kc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBURUFTIG1haWxpbmcgbGlzdC48YnI+ DQo8YnI+DQpBcyBpcyBhbHdheXMgdGhlIGNhc2UsIHBvc2l0aXZlIGNvbW1lbnRzLCBlLmcuLCAm cXVvdDtJJ3ZlIHJldmlld2VkIHRoaXM8YnI+DQpkb2N1bWVudCBhbmQgYmVsaWV2ZSBpdCBpcyBy ZWFkeSBmb3IgcHVibGljYXRpb24mcXVvdDssIGFyZSB3ZWxjb21lITxicj4NClRoaXMgaXMgdXNl ZnVsIGFuZCBpbXBvcnRhbnQsIGV2ZW4gZnJvbSBhdXRob3JzLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3RlLCBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIG9u IHRoaXMgZHJhZnQuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyPg0KVGhhbmtzLDxicj4NClBhdmFuIChhbmQgTG91KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_8798c1b7c8834eeb91683fbbe9fa2abfXCHRCD001ciscocom_-- From nobody Wed May 18 16:12:59 2016 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 4C4A412D7B6; Wed, 18 May 2016 16:12:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160518231257.14629.75268.idtracker@ietfa.amsl.com> Date: Wed, 18 May 2016 16:12:57 -0700 Archived-At: Cc: draft-ietf-teas-interconnected-te-info-exchange@ietf.org, teas-chairs@ietf.org, teas@ietf.org, lberger@labn.net Subject: [Teas] Ben Campbell's No Objection on draft-ietf-teas-interconnected-te-info-exchange-06: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 18 May 2016 23:12:57 -0000 Ben Campbell has entered the following ballot position for draft-ietf-teas-interconnected-te-info-exchange-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-interconnected-te-info-exchange/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I too share the confusion over the intended status. (And I agree with Alissa that this seems like an informational) From nobody Thu May 19 06:46:52 2016 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 D2E3112D137; Thu, 19 May 2016 06:46:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160519134649.17318.42019.idtracker@ietfa.amsl.com> Date: Thu, 19 May 2016 06:46:49 -0700 Archived-At: Cc: draft-ietf-teas-interconnected-te-info-exchange@ietf.org, teas-chairs@ietf.org, teas@ietf.org, lberger@labn.net Subject: [Teas] Stephen Farrell's No Objection on draft-ietf-teas-interconnected-te-info-exchange-06: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 19 May 2016 13:46:50 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-teas-interconnected-te-info-exchange-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-interconnected-te-info-exchange/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - The security considerations says to use IPsec or TCP-AO. To what extent do we think that this could help with implementation and deployment of TCP-AO? If it can, great. If it wouldn't, then I'm not sure there's much point in mentioning TCP-AO given what I understand it the current state of play there. - IPsec can clearly be used, but I wondered if there's really no place for using TLS between the domains here? That might need a bit of work, (e.g. to allocate ports or define a STARTTLS equivalent), but perhaps there's the opportunity here to get that kind of thing done? That's maybe less of a question for this document, but more for the WG in general. (Though if (D)TLS made sense as part of this, saying so here would be good probably.) - I note that the IPR declaration refers to a "standard." As of now, this document is aiming for BCP, so I've no idea how to interpret the text in the declaration unless this reverts to PS. (That said: I don't care much about what kind of RFC results here, but I agree with the authors that just picking wihtout requiring text changes for process reasons is right.) From nobody Thu May 19 07:08:00 2016 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 238B412DA6B; Thu, 19 May 2016 07:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2ZpmLy5JPPt; Thu, 19 May 2016 07:07:52 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11B9312DA6E; Thu, 19 May 2016 07:07:50 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u4JE7f8P029436; Thu, 19 May 2016 15:07:41 +0100 Received: from 950129200 (jplon-nat11.juniper.net [193.110.55.11]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u4JE7ZKO029352 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 19 May 2016 15:07:38 +0100 From: "Adrian Farrel" To: "'Stephen Farrell'" , "'The IESG'" References: <20160519134649.17318.42019.idtracker@ietfa.amsl.com> In-Reply-To: <20160519134649.17318.42019.idtracker@ietfa.amsl.com> Date: Thu, 19 May 2016 15:07:35 +0100 Message-ID: <08e601d1b1d7$ce700d70$6b502850$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG8x6IO3WYy673eDScpuN0BHPlb0J/qHMWg Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22332.000 X-TM-AS-Result: No--11.276-10.0-31-10 X-imss-scan-details: No--11.276-10.0-31-10 X-TMASE-MatchedRID: PL66URbwWA+YDcnhtY9LdHGBmLio+mJgKx5ICGp/WtFxOimTS6/0f1Ih JHNPOsd2NH+L+EwoByhycY64ARf1wxyCaonaIG/AtOeVIsIYD4vAMyYDvAr9phI+jlzyGLPnMQY WN5nDJFTumCPfBxt2LlLNP9nb8HdEkwjBgO+RHzKVSBCoZUyqbDoSfZud5+GgWcVk1+PpebZeSF +P1eXHLRwhwH9TSW0lhKe1S7dTIOhbRbA/K/rHzMzWN98iBBeGWDdWpJMntKhfM5MEKdJKDyTCV wyY5KnU7QGZk/T0l90eQXALcqqZe4GcnkRO1Zd9EroQVzSW9XS6hgVvSdGKo9KFZyZqKcjf2zUI fORoaiK6MCI4ZJN6mlfUsDLvDURghkl5WhaVumFIRA38P/dwbtFqG4/BpDVakzE2kM4b6HrOb5J Z/dOlBFz9rBcD0jZ7+9hPqEmfjXoKT+RHLhCkHIbBPrt55wnwj5hUmqusTPjYWrp179pohkY+90 4TUg2taFK9tdhG3GxftuJwrFEhTbew1twePJJB3QfwsVk0UbtuRXh7bFKB7nQjj33UPRaeVOoB+ MrvW118+C621KYPVv5mpQGnYBXfXwjihSrlWBo= Archived-At: Cc: draft-ietf-teas-interconnected-te-info-exchange@ietf.org, teas-chairs@ietf.org, teas@ietf.org, lberger@labn.net Subject: Re: [Teas] Stephen Farrell's No Objection on draft-ietf-teas-interconnected-te-info-exchange-06: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk 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, 19 May 2016 14:07:55 -0000 Stephen, Happy to be guided on relative merits of TCP-AO and TLS. When we pushed RFC 5440 through we were asked to include the following = text: The TCP Authentication Option [TCP-AUTH] (TCP-AO) specifies new security procedures for TCP, but is not yet complete. Since it is believed that [TCP-AUTH] will offer significantly improved security for applications using TCP, implementers should expect to update their implementation as soon as the TCP Authentication Option is published as an RFC. RFC 6952 says: Since TCP-AO [RFC5925] has now been published, new PCEP implementations should fully support TCP-AO. 6952 goes on to appear to say that routing protocols carried over TCP = should implement TCP-AO. Appendix A refers to PCEP (RFC 5440) and also BGP hence the mention in = Section 12. Now, it is OK if all this has changed or if the "shouldiness" of the = advice really doesn't mean anything.=20 Please advise what a post-KARP document that refers to a TCP-base = routing protocol should say. Cheers, Adrian > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: 19 May 2016 14:47 > To: The IESG > Cc: draft-ietf-teas-interconnected-te-info-exchange@ietf.org; Lou = Berger; teas- > chairs@ietf.org; lberger@labn.net; teas@ietf.org > Subject: Stephen Farrell's No Objection on = draft-ietf-teas-interconnected-te- > info-exchange-06: (with COMMENT) >=20 > Stephen Farrell has entered the following ballot position for > draft-ietf-teas-interconnected-te-info-exchange-06: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > = https://datatracker.ietf.org/doc/draft-ietf-teas-interconnected-te-info- > exchange/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > - The security considerations says to use IPsec or TCP-AO. To > what extent do we think that this could help with implementation > and deployment of TCP-AO? If it can, great. If it wouldn't, then I'm > not sure there's much point in mentioning TCP-AO given what I > understand it the current state of play there. >=20 > - IPsec can clearly be used, but I wondered if there's really no > place for using TLS between the domains here? That might need a > bit of work, (e.g. to allocate ports or define a STARTTLS > equivalent), but perhaps there's the opportunity here to get that > kind of thing done? That's maybe less of a question for this > document, but more for the WG in general. (Though if (D)TLS > made sense as part of this, saying so here would be good > probably.) >=20 > - I note that the IPR declaration refers to a "standard." As of > now, this document is aiming for BCP, so I've no idea how to > interpret the text in the declaration unless this reverts to PS. > (That said: I don't care much about what kind of RFC results > here, but I agree with the authors that just picking wihtout > requiring text changes for process reasons is right.) From nobody Thu May 19 07:30:50 2016 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 9F96512B059; Thu, 19 May 2016 07:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0S-KqAWg6-pS; Thu, 19 May 2016 07:30:44 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A557812B062; Thu, 19 May 2016 07:30:44 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 50776E0923299; Thu, 19 May 2016 14:30:40 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4JEUKUi002394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 May 2016 14:30:42 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u4JEUHjG023723 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 May 2016 16:30:18 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.44]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 19 May 2016 16:30:18 +0200 From: "Scharf, Michael (Nokia - DE)" To: "adrian@olddog.co.uk" , "'Stephen Farrell'" , "'The IESG'" Thread-Topic: [Teas] Stephen Farrell's No Objection on draft-ietf-teas-interconnected-te-info-exchange-06: (with COMMENT) Thread-Index: AQHRsdTzZW9MQfMuFk2awp1AVmVPjp/AKmSAgAAkRtA= Date: Thu, 19 May 2016 14:30:18 +0000 Message-ID: <655C07320163294895BBADA28372AF5D4885CA2A@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20160519134649.17318.42019.idtracker@ietfa.amsl.com> <08e601d1b1d7$ce700d70$6b502850$@olddog.co.uk> In-Reply-To: <08e601d1b1d7$ce700d70$6b502850$@olddog.co.uk> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-teas-interconnected-te-info-exchange@ietf.org" , "teas-chairs@ietf.org" , "teas@ietf.org" , "lberger@labn.net" Subject: Re: [Teas] Stephen Farrell's No Objection on draft-ietf-teas-interconnected-te-info-exchange-06: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 19 May 2016 14:30:46 -0000 For what it is worth, I do not understand the sentence below "If it wouldn'= t, then I'm not sure there's much point in mentioning TCP-AO given what I u= nderstand it the current state of play there." TCP-AO is a proposed standard by TCPM and specifically addresses some of th= e protocols typically used in such environments. Michael (TCPM co-chair) -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Thursday, May 19, 2016 4:08 PM To: 'Stephen Farrell'; 'The IESG' Cc: draft-ietf-teas-interconnected-te-info-exchange@ietf.org; teas-chairs@i= etf.org; teas@ietf.org; lberger@labn.net Subject: Re: [Teas] Stephen Farrell's No Objection on draft-ietf-teas-inter= connected-te-info-exchange-06: (with COMMENT) Stephen, Happy to be guided on relative merits of TCP-AO and TLS. When we pushed RFC 5440 through we were asked to include the following text= : The TCP Authentication Option [TCP-AUTH] (TCP-AO) specifies new security procedures for TCP, but is not yet complete. Since it is believed that [TCP-AUTH] will offer significantly improved security for applications using TCP, implementers should expect to update their implementation as soon as the TCP Authentication Option is published as an RFC. RFC 6952 says: Since TCP-AO [RFC5925] has now been published, new PCEP implementations should fully support TCP-AO. 6952 goes on to appear to say that routing protocols carried over TCP shoul= d implement TCP-AO. Appendix A refers to PCEP (RFC 5440) and also BGP hence the mention in Sect= ion 12. Now, it is OK if all this has changed or if the "shouldiness" of the advice= really doesn't mean anything.=20 Please advise what a post-KARP document that refers to a TCP-base routing p= rotocol should say. Cheers, Adrian > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: 19 May 2016 14:47 > To: The IESG > Cc: draft-ietf-teas-interconnected-te-info-exchange@ietf.org; Lou=20 > Berger; teas- chairs@ietf.org; lberger@labn.net; teas@ietf.org > Subject: Stephen Farrell's No Objection on=20 > draft-ietf-teas-interconnected-te- > info-exchange-06: (with COMMENT) >=20 > Stephen Farrell has entered the following ballot position for > draft-ietf-teas-interconnected-te-info-exchange-06: No Objection >=20 > When responding, please keep the subject line intact and reply to all=20 > email addresses included in the To and CC lines. (Feel free to cut=20 > this introductory paragraph, however.) >=20 >=20 > Please refer to=20 > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-teas-interconnected-te-inf > o- > exchange/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > - The security considerations says to use IPsec or TCP-AO. To what=20 > extent do we think that this could help with implementation and=20 > deployment of TCP-AO? If it can, great. If it wouldn't, then I'm not=20 > sure there's much point in mentioning TCP-AO given what I understand=20 > it the current state of play there. >=20 > - IPsec can clearly be used, but I wondered if there's really no place=20 > for using TLS between the domains here? That might need a bit of work,=20 > (e.g. to allocate ports or define a STARTTLS equivalent), but perhaps=20 > there's the opportunity here to get that kind of thing done? That's=20 > maybe less of a question for this document, but more for the WG in=20 > general. (Though if (D)TLS made sense as part of this, saying so here=20 > would be good > probably.) >=20 > - I note that the IPR declaration refers to a "standard." As of now,=20 > this document is aiming for BCP, so I've no idea how to interpret the=20 > text in the declaration unless this reverts to PS. > (That said: I don't care much about what kind of RFC results here, but=20 > I agree with the authors that just picking wihtout requiring text=20 > changes for process reasons is right.) _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Thu May 19 07:45:04 2016 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 7ABBB12D1D2; Thu, 19 May 2016 07:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 UrekUkSmcrn2; Thu, 19 May 2016 07:45:00 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E6D912D11E; Thu, 19 May 2016 07:45:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 412E8BE2D; Thu, 19 May 2016 15:44:59 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7kifvYU-xZ7; Thu, 19 May 2016 15:44:59 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9EB6CBE35; Thu, 19 May 2016 15:44:58 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1463669099; bh=L7q2GUc9YuycZv6bK2kZVbZ1xjTbI47r+Q0HY5OinLQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=3pySCa0ERoe/DYAUjsiWmStxiODGHL/UjX6tFOOmTpZ3NLvG00ODve5lumj33z4O7 XwaiQX6PZwFktkClfX9k4fGPolUro7rwkt5XJNp5r8iOFNDW7iBAcwMZwtERAL2XhN GfBCBcHsbeRuy8tu1mpzug8gvCoZbz/DaB0uHMf0= To: adrian@olddog.co.uk, 'The IESG' References: <20160519134649.17318.42019.idtracker@ietfa.amsl.com> <08e601d1b1d7$ce700d70$6b502850$@olddog.co.uk> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <573DD169.2000308@cs.tcd.ie> Date: Thu, 19 May 2016 15:44:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <08e601d1b1d7$ce700d70$6b502850$@olddog.co.uk> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080506010902000600090303" Archived-At: Cc: draft-ietf-teas-interconnected-te-info-exchange@ietf.org, teas-chairs@ietf.org, teas@ietf.org, lberger@labn.net Subject: Re: [Teas] Stephen Farrell's No Objection on draft-ietf-teas-interconnected-te-info-exchange-06: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 19 May 2016 14:45:02 -0000 This is a cryptographically signed message in MIME format. --------------ms080506010902000600090303 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 19/05/16 15:07, Adrian Farrel wrote: > Stephen, >=20 > Happy to be guided on relative merits of TCP-AO and TLS. >=20 > When we pushed RFC 5440 through we were asked to include the > following text: >=20 > The TCP Authentication Option [TCP-AUTH] (TCP-AO) specifies new=20 > security procedures for TCP, but is not yet complete. Since it is=20 > believed that [TCP-AUTH] will offer significantly improved security=20 > for applications using TCP, implementers should expect to update=20 > their implementation as soon as the TCP Authentication Option is=20 > published as an RFC. >=20 > RFC 6952 says: Since TCP-AO [RFC5925] has now been published, new > PCEP implementations should fully support TCP-AO. >=20 > 6952 goes on to appear to say that routing protocols carried over TCP > should implement TCP-AO. >=20 > Appendix A refers to PCEP (RFC 5440) and also BGP hence the mention > in Section 12. >=20 > Now, it is OK if all this has changed or if the "shouldiness" of the > advice really doesn't mean anything. >=20 > Please advise what a post-KARP document that refers to a TCP-base > routing protocol should say. I don't believe there's any new document there no, so your text is ok. Cheers, S >=20 > Cheers, Adrian >=20 >=20 >=20 >> -----Original Message----- From: Stephen Farrell >> [mailto:stephen.farrell@cs.tcd.ie] Sent: 19 May 2016 14:47 To: The >> IESG Cc: draft-ietf-teas-interconnected-te-info-exchange@ietf.org; >> Lou Berger; teas- chairs@ietf.org; lberger@labn.net; teas@ietf.org=20 >> Subject: Stephen Farrell's No Objection on >> draft-ietf-teas-interconnected-te- info-exchange-06: (with >> COMMENT) >>=20 >> Stephen Farrell has entered the following ballot position for=20 >> draft-ietf-teas-interconnected-te-info-exchange-06: No Objection >>=20 >> When responding, please keep the subject line intact and reply to >> all email addresses included in the To and CC lines. (Feel free to >> cut this introductory paragraph, however.) >>=20 >>=20 >> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html for more >> information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found >> here:=20 >> https://datatracker.ietf.org/doc/draft-ietf-teas-interconnected-te-inf= o- >> >>=20 exchange/ >>=20 >>=20 >>=20 >> ----------------------------------------------------------------------= >> >>=20 COMMENT: >> ----------------------------------------------------------------------= >> >> >> >>=20 - The security considerations says to use IPsec or TCP-AO. To >> what extent do we think that this could help with implementation=20 >> and deployment of TCP-AO? If it can, great. If it wouldn't, then >> I'm not sure there's much point in mentioning TCP-AO given what I=20 >> understand it the current state of play there. >>=20 >> - IPsec can clearly be used, but I wondered if there's really no=20 >> place for using TLS between the domains here? That might need a bit >> of work, (e.g. to allocate ports or define a STARTTLS equivalent), >> but perhaps there's the opportunity here to get that kind of thing >> done? That's maybe less of a question for this document, but more >> for the WG in general. (Though if (D)TLS made sense as part of >> this, saying so here would be good probably.) >>=20 >> - I note that the IPR declaration refers to a "standard." As of=20 >> now, this document is aiming for BCP, so I've no idea how to=20 >> interpret the text in the declaration unless this reverts to PS.=20 >> (That said: I don't care much about what kind of RFC results here, >> but I agree with the authors that just picking wihtout requiring >> text changes for process reasons is right.) >=20 >=20 --------------ms080506010902000600090303 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MTkx NDQ0NTdaMC8GCSqGSIb3DQEJBDEiBCBd0kqCP9YKVOBMGqY/xpiYQbcjK+KlNtjATbG5fwkI jDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBHuIBGUvbwNCZmUsV66dmT0U3TrtsoJ1mpZ7m5gZbCV9QXympt2ySh aBKZNngP/j0Vxl4EUMzpofVgXE0UZu+OEaGm7J32QOOEMNQu2nA3ACDFQHTv02i371gGAvIW wFR80OPOyidKL/hei3MP9W3r+yJRfr6ptkQJthBSGC5JK33ZKu4NfJsdl4L0cPaCnKliRrqY YKs6YzIZgWPx2JnfBUO/ogJGRCGY1DjVmP4rofEtN3dcNhMgs6KC5vwMWtb33Rxuzfz0ZdXL Uk4Z2z1jBLmDaOB7IeJbp/jqnOS6gj9bjZIaKSZ7qJp2vR7nVxsOMXNHRQxMKv5EYj6KKxbR AAAAAAAA --------------ms080506010902000600090303-- From nobody Thu May 19 07:55:47 2016 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 4B44912B011; Thu, 19 May 2016 07:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 Rks3ARTIlbfl; Thu, 19 May 2016 07:55:39 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DCEE12D168; Thu, 19 May 2016 07:55:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 40A03BE35; Thu, 19 May 2016 15:55:35 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g96sjM6qULSz; Thu, 19 May 2016 15:55:35 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A765FBE2D; Thu, 19 May 2016 15:55:34 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1463669735; bh=PeWURYIj2UFQ1lnrb5nmlJ81w0+hWr93LB0yf683Nf4=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=uiJvuh56yS+Obowu1eNQI4+fo6kF3FmlGJHXjlGEkRewe4PDvxDI6sBFXAd4NWOgz 5m0olUgum/QbVZaDZDp7xZb1IkS5m4KqgXvqAXduL5lJT2wkVjXA3kgTrKXYvCb8Tu 20onDTkbAferAujo1PxIGTmGHWmWER2ZouYFSIs0= To: "Scharf, Michael (Nokia - DE)" , "adrian@olddog.co.uk" , 'The IESG' References: <20160519134649.17318.42019.idtracker@ietfa.amsl.com> <08e601d1b1d7$ce700d70$6b502850$@olddog.co.uk> <655C07320163294895BBADA28372AF5D4885CA2A@FR712WXCHMBA15.zeu.alcatel-lucent.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <573DD3E5.4060108@cs.tcd.ie> Date: Thu, 19 May 2016 15:55:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <655C07320163294895BBADA28372AF5D4885CA2A@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020709000501050302010600" Archived-At: Cc: "draft-ietf-teas-interconnected-te-info-exchange@ietf.org" , "teas-chairs@ietf.org" , "teas@ietf.org" , "lberger@labn.net" Subject: Re: [Teas] Stephen Farrell's No Objection on draft-ietf-teas-interconnected-te-info-exchange-06: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 19 May 2016 14:55:41 -0000 This is a cryptographically signed message in MIME format. --------------ms020709000501050302010600 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Michael, On 19/05/16 15:30, Scharf, Michael (Nokia - DE) wrote: > For what it is worth, I do not understand the sentence below "If it > wouldn't, then I'm not sure there's much point in mentioning TCP-AO > given what I understand it the current state of play there." >=20 > TCP-AO is a proposed standard by TCPM and specifically addresses some > of the protocols typically used in such environments. Sure, there's no issue with the RFC. If the RFC were widely implemented and deployed that'd be great. My understanding though is that that's not currently the case so I wondered if teas might be something that'd help that along. If it is not something that'd help that along, then the text in the draft right now is a tiny bit misleading as it proposes (as an option) to depend on something that won't be used which I don't think is actually a good way to improve security. I get that we have to start somewhere, and shouldn't give up easily, but equally, if an RFC isn't being deployed, then at some point we should also pay attention to that. I'm not saying we're at that stage with TCP-AO btw, but it has been 6 years so I do wonder about it. (And to be clear: none of the above is asking for a change to the current document unless the authors/wg want to make such a change, which it seems they don't.) Cheers, S. >=20 > Michael (TCPM co-chair) >=20 >=20 > -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] > On Behalf Of Adrian Farrel Sent: Thursday, May 19, 2016 4:08 PM To: > 'Stephen Farrell'; 'The IESG' Cc: > draft-ietf-teas-interconnected-te-info-exchange@ietf.org; > teas-chairs@ietf.org; teas@ietf.org; lberger@labn.net Subject: Re: > [Teas] Stephen Farrell's No Objection on > draft-ietf-teas-interconnected-te-info-exchange-06: (with COMMENT) >=20 > Stephen, >=20 > Happy to be guided on relative merits of TCP-AO and TLS. >=20 > When we pushed RFC 5440 through we were asked to include the > following text: >=20 > The TCP Authentication Option [TCP-AUTH] (TCP-AO) specifies new=20 > security procedures for TCP, but is not yet complete. Since it is=20 > believed that [TCP-AUTH] will offer significantly improved security=20 > for applications using TCP, implementers should expect to update=20 > their implementation as soon as the TCP Authentication Option is=20 > published as an RFC. >=20 > RFC 6952 says: Since TCP-AO [RFC5925] has now been published, new > PCEP implementations should fully support TCP-AO. >=20 > 6952 goes on to appear to say that routing protocols carried over TCP > should implement TCP-AO. >=20 > Appendix A refers to PCEP (RFC 5440) and also BGP hence the mention > in Section 12. >=20 > Now, it is OK if all this has changed or if the "shouldiness" of the > advice really doesn't mean anything. >=20 > Please advise what a post-KARP document that refers to a TCP-base > routing protocol should say. >=20 > Cheers, Adrian >=20 >=20 >=20 >> -----Original Message----- From: Stephen Farrell >> [mailto:stephen.farrell@cs.tcd.ie] Sent: 19 May 2016 14:47 To: The >> IESG Cc: draft-ietf-teas-interconnected-te-info-exchange@ietf.org; >> Lou Berger; teas- chairs@ietf.org; lberger@labn.net; teas@ietf.org=20 >> Subject: Stephen Farrell's No Objection on=20 >> draft-ietf-teas-interconnected-te- info-exchange-06: (with >> COMMENT) >>=20 >> Stephen Farrell has entered the following ballot position for=20 >> draft-ietf-teas-interconnected-te-info-exchange-06: No Objection >>=20 >> When responding, please keep the subject line intact and reply to >> all email addresses included in the To and CC lines. (Feel free to >> cut this introductory paragraph, however.) >>=20 >>=20 >> Please refer to=20 >> https://www.ietf.org/iesg/statement/discuss-criteria.html for more >> information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found >> here:=20 >> https://datatracker.ietf.org/doc/draft-ietf-teas-interconnected-te-inf= >> >>=20 o- >> exchange/ >>=20 >>=20 >>=20 >> ----------------------------------------------------------------------= >> >>=20 COMMENT: >> ----------------------------------------------------------------------= >> >> >> >>=20 - The security considerations says to use IPsec or TCP-AO. To what >> extent do we think that this could help with implementation and=20 >> deployment of TCP-AO? If it can, great. If it wouldn't, then I'm >> not sure there's much point in mentioning TCP-AO given what I >> understand it the current state of play there. >>=20 >> - IPsec can clearly be used, but I wondered if there's really no >> place for using TLS between the domains here? That might need a bit >> of work, (e.g. to allocate ports or define a STARTTLS equivalent), >> but perhaps there's the opportunity here to get that kind of thing >> done? That's maybe less of a question for this document, but more >> for the WG in general. (Though if (D)TLS made sense as part of >> this, saying so here would be good probably.) >>=20 >> - I note that the IPR declaration refers to a "standard." As of >> now, this document is aiming for BCP, so I've no idea how to >> interpret the text in the declaration unless this reverts to PS.=20 >> (That said: I don't care much about what kind of RFC results here, >> but I agree with the authors that just picking wihtout requiring >> text changes for process reasons is right.) >=20 >=20 > _______________________________________________ Teas mailing list=20 > Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas >=20 --------------ms020709000501050302010600 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MTkx NDU1MzNaMC8GCSqGSIb3DQEJBDEiBCCiRVgaNJrqsAJ3cpweMcRy3NFaYeFHR/u0Xz8iJFVb KTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQA6gy11O1azcR6cAkL4LkllX55vp2mQb2KeIykSh96e0hPg45DIYeJe kG9GJxZELuZAtt3UR5scihhNaYta3ANqCNfXu2CauC7KqbC0coq384jCnqf6efynwF9BP1O2 X5MxorKcKSJ42+KxQohkx4dLqHwdNgTRd3L65iZnBYlcCr9F5FQMc1TpdjYysvJjeOzc024e GYodsQy5is3LQZehQFAo/oV3xUt/jwYo7i7N+4Sg2RryKDwvsMCm7qoqne3No5kIqIMxCFa6 fjOgKGmHYEDK397AVK89Cu2YuzGivTdKnYeofcLCEQD2VjFJWc7iwvjLHoizdiJMInoiyz20 AAAAAAAA --------------ms020709000501050302010600-- From nobody Thu May 19 08:10:42 2016 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 2766E12D122; Thu, 19 May 2016 08:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLBLGCfH63Mx; Thu, 19 May 2016 08:10:32 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC3DA12D103; Thu, 19 May 2016 08:10:31 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 72A1ACF6F2178; Thu, 19 May 2016 15:10:26 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4JFATXY021348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 May 2016 15:10:29 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u4JFAOfY022326 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 May 2016 17:10:26 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.44]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 19 May 2016 17:10:23 +0200 From: "Scharf, Michael (Nokia - DE)" To: Stephen Farrell , "adrian@olddog.co.uk" , "'The IESG'" Thread-Topic: [Teas] Stephen Farrell's No Objection on draft-ietf-teas-interconnected-te-info-exchange-06: (with COMMENT) Thread-Index: AQHRsdTzZW9MQfMuFk2awp1AVmVPjp/AKmSAgAAkRtD//+khgIAAIe+Q Date: Thu, 19 May 2016 15:10:22 +0000 Message-ID: <655C07320163294895BBADA28372AF5D4885CC0F@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20160519134649.17318.42019.idtracker@ietfa.amsl.com> <08e601d1b1d7$ce700d70$6b502850$@olddog.co.uk> <655C07320163294895BBADA28372AF5D4885CA2A@FR712WXCHMBA15.zeu.alcatel-lucent.com> <573DD3E5.4060108@cs.tcd.ie> In-Reply-To: <573DD3E5.4060108@cs.tcd.ie> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0008_01D1B1F1.537953F0" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-teas-interconnected-te-info-exchange@ietf.org" , "teas-chairs@ietf.org" , "teas@ietf.org" , "lberger@labn.net" Subject: Re: [Teas] Stephen Farrell's No Objection on draft-ietf-teas-interconnected-te-info-exchange-06: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 19 May 2016 15:10:36 -0000 ------=_NextPart_000_0008_01D1B1F1.537953F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit The pre-standard version of TCP-AO seems very widely deployed with interoperability among the TCP stacks. But why does this matter for a TEAS document? This is TCPM business. Michael -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] Sent: Thursday, May 19, 2016 4:56 PM To: Scharf, Michael (Nokia - DE); adrian@olddog.co.uk; 'The IESG' Cc: draft-ietf-teas-interconnected-te-info-exchange@ietf.org; teas-chairs@ietf.org; teas@ietf.org; lberger@labn.net Subject: Re: [Teas] Stephen Farrell's No Objection on draft-ietf-teas-interconnected-te-info-exchange-06: (with COMMENT) Hi Michael, On 19/05/16 15:30, Scharf, Michael (Nokia - DE) wrote: > For what it is worth, I do not understand the sentence below "If it > wouldn't, then I'm not sure there's much point in mentioning TCP-AO > given what I understand it the current state of play there." > > TCP-AO is a proposed standard by TCPM and specifically addresses some > of the protocols typically used in such environments. Sure, there's no issue with the RFC. If the RFC were widely implemented and deployed that'd be great. My understanding though is that that's not currently the case so I wondered if teas might be something that'd help that along. If it is not something that'd help that along, then the text in the draft right now is a tiny bit misleading as it proposes (as an option) to depend on something that won't be used which I don't think is actually a good way to improve security. I get that we have to start somewhere, and shouldn't give up easily, but equally, if an RFC isn't being deployed, then at some point we should also pay attention to that. I'm not saying we're at that stage with TCP-AO btw, but it has been 6 years so I do wonder about it. (And to be clear: none of the above is asking for a change to the current document unless the authors/wg want to make such a change, which it seems they don't.) Cheers, S. > > Michael (TCPM co-chair) > > > -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] > On Behalf Of Adrian Farrel Sent: Thursday, May 19, 2016 4:08 PM To: > 'Stephen Farrell'; 'The IESG' Cc: > draft-ietf-teas-interconnected-te-info-exchange@ietf.org; > teas-chairs@ietf.org; teas@ietf.org; lberger@labn.net Subject: Re: > [Teas] Stephen Farrell's No Objection on > draft-ietf-teas-interconnected-te-info-exchange-06: (with COMMENT) > > Stephen, > > Happy to be guided on relative merits of TCP-AO and TLS. > > When we pushed RFC 5440 through we were asked to include the > following text: > > The TCP Authentication Option [TCP-AUTH] (TCP-AO) specifies new > security procedures for TCP, but is not yet complete. Since it is > believed that [TCP-AUTH] will offer significantly improved security > for applications using TCP, implementers should expect to update > their implementation as soon as the TCP Authentication Option is > published as an RFC. > > RFC 6952 says: Since TCP-AO [RFC5925] has now been published, new > PCEP implementations should fully support TCP-AO. > > 6952 goes on to appear to say that routing protocols carried over TCP > should implement TCP-AO. > > Appendix A refers to PCEP (RFC 5440) and also BGP hence the mention > in Section 12. > > Now, it is OK if all this has changed or if the "shouldiness" of the > advice really doesn't mean anything. > > Please advise what a post-KARP document that refers to a TCP-base > routing protocol should say. > > Cheers, Adrian > > > >> -----Original Message----- From: Stephen Farrell >> [mailto:stephen.farrell@cs.tcd.ie] Sent: 19 May 2016 14:47 To: The >> IESG Cc: draft-ietf-teas-interconnected-te-info-exchange@ietf.org; >> Lou Berger; teas- chairs@ietf.org; lberger@labn.net; teas@ietf.org >> Subject: Stephen Farrell's No Objection on >> draft-ietf-teas-interconnected-te- info-exchange-06: (with >> COMMENT) >> >> Stephen Farrell has entered the following ballot position for >> draft-ietf-teas-interconnected-te-info-exchange-06: No Objection >> >> When responding, please keep the subject line intact and reply to >> all email addresses included in the To and CC lines. (Feel free to >> cut this introductory paragraph, however.) >> >> >> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html for more >> information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found >> here: >> https://datatracker.ietf.org/doc/draft-ietf-teas-interconnected-te-inf >> >> o- >> exchange/ >> >> >> >> ---------------------------------------------------------------------- >> >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> >> - The security considerations says to use IPsec or TCP-AO. To what >> extent do we think that this could help with implementation and >> deployment of TCP-AO? If it can, great. If it wouldn't, then I'm >> not sure there's much point in mentioning TCP-AO given what I >> understand it the current state of play there. >> >> - IPsec can clearly be used, but I wondered if there's really no >> place for using TLS between the domains here? That might need a bit >> of work, (e.g. to allocate ports or define a STARTTLS equivalent), >> but perhaps there's the opportunity here to get that kind of thing >> done? That's maybe less of a question for this document, but more >> for the WG in general. (Though if (D)TLS made sense as part of >> this, saying so here would be good probably.) >> >> - I note that the IPR declaration refers to a "standard." As of >> now, this document is aiming for BCP, so I've no idea how to >> interpret the text in the declaration unless this reverts to PS. >> (That said: I don't care much about what kind of RFC results here, >> but I agree with the authors that just picking wihtout requiring >> text changes for process reasons is right.) > > > _______________________________________________ Teas mailing list > Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas > ------=_NextPart_000_0008_01D1B1F1.537953F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQATCCA7Ew ggKZoAMCAQICEBErBTlXKN63QvT+VRPTt1EwDQYJKoZIhvcNAQEFBQAwQzEXMBUGA1UEChMOQWxj YXRlbCBMdWNlbnQxKDAmBgNVBAMTH0FsY2F0ZWwgTHVjZW50IEludGVybmFsIFJvb3QgQ0EwHhcN MDgxMTAzMTU0MTE2WhcNMjgxMTAzMTU0MTE2WjBDMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEo MCYGA1UEAxMfQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAL5IGBVth8afQdnpuLDI0Z37GgIcPWznOOzFJUV1gVbztqQ5CIxkVL4K soAfLzc8LQHqNl2Nk3YbVBputIyCe2nzGsRjQeVt+HO2PV7h2YpMQlVd+XGsmpJ4fAP3A38wkTl6 tFPAYspyUFvjNON1J3BJE/2cuY7apvn9ZfSz99x7y4QBZh3hvm4g5Fn7mK04/q7K6O4Z8Y6zkSxG ZFNyZ6NIuAPNCODZASqYnHiAgtEcCR4WPs6rj+Y8MU0q56ddwuIZ0qeP2ScHY0wVtnmqXzHyCzEQ Eb2eJCsGpXFwUalVaxPUZEVoVDfjO+2ZN5gNJrGMTu7Mv9k1WG0LR3zZ1QsCAwEAAaOBoDCBnTAL BgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB6yyWvZhiXxcfOvilycpaQyK H/AwEAYJKwYBBAGCNxUBBAMCAQAwTAYDVR0gBEUwQzBBBgRVHSAAMDkwNwYIKwYBBQUHAgEWK2h0 dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9jcC9jcC5odG0wDQYJKoZIhvcNAQEFBQAD ggEBADBMWG3WQyC6+mBzuuFuCGqJAiC4v+TQ3ZErd5KKSRGh8dwjzK5L2C51wJPVe6EAjb59CEb2 p2aPKSkoMrCC8seBRM/bs23DMyna1Jr9Q5EZDrmRqBLJy3Cs8NFpa/cKb6SkegFHcB/vi+SYgSdR BwoNE5+y6MRPXcEBadI/9W8Zlkk5sJ3w55e+i8OCNg/fDYAQuJPa+hD3/byWGxUgGSMNGQ/GS2st NETAa5Z/88Sh9FHk2BtrxSz7jPtekKhjsidD2ANJZTCyj9iRB+Nt9FEetNpcN6ke1FlepRbCsV10 I0y6weLwZ34h2GWbN9qEOSQV88NBA149a5ugJ/oCbHEwggTdMIIDxaADAgECAgoanQrOAAAAAAAG MA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNh dGVsIEx1Y2VudCBJbnRlcm5hbCBSb290IENBMB4XDTA4MTEyMTIxNTcyOFoXDTE4MTEyMTIyMDcy OFowgYUxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJ kiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRl bCBMdWNlbnQgSW50ZXJuYWwgU3ViIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 2Ocmcli3LbVU6TRh+JLMtquBr5/grS+gzfN5YL/lauFCHmDlF7kNQvxtDWqwNpOkzb97CwWcVsdf kyWAiGzVWeRIrYGhK/xNPFRYXOKYXLGqxFWkltZkYpSRudHzjTneUC4EVdMXnREMu8FTC0CM38Vb xMvQ+ygjEyicg2QT9lZHWkKP9kCI1818P+AmS7905t6kXR9Q2m1GjcCa0KqARPGX/xe2toQS+Vdi UwDary1Enk8j19KFmvFg1bhY2mNSHgzN2AWnhsOi/EID1SalzBwHylByB/UbbEv2dZUsAdMuOtYt Z/8dM1axS0d3fW7q7mAYV5uM42mYX9o1B/RzjwIDAQABo4IBjjCCAYowDwYDVR0TAQH/BAUwAwEB /zAdBgNVHQ4EFgQU2exrvZZYIvfYpnfN/k2B77qXvRIwCwYDVR0PBAQDAgHGMBAGCSsGAQQBgjcV AQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFAesslr2YYl8XHzr 4pcnKWkMih/wMHgGA1UdHwRxMG8wbaBroGmGOWh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0 ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybIYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5j b20vUEtJL3Jvb3RDQS5jcmwwgYIGCCsGAQUFBwEBBHYwdDA4BggrBgEFBQcwAoYsaHR0cDovL3d3 dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcnQwOAYIKwYBBQUHMAKGLGh0dHA6Ly93 d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCl GxDp5Z1IDjIEz8VaTEWa8Q1OWUbXwsszdoNg5Gg3F1a2VFFVegmsrpt4axbESlgE6AT/rkUUiyjb EhcUgY2OHdeKN5Gc7VOGh9D7SER9peARwSwx4NYRrsIaRXDrUswWAM6T6ilDUogjKYk3uK2zZ6Vy 7z3JewxVlhpeSsNPQSMoyNibKkYLRoh6rvz94vB0mvcT0uVx7xowPNoTOjjGRAk4J/MBaNOupvwf RfPmwRetdnD6NC5x8aRkhr4ZNBjvYxFT8IJaeLk8piQYMPRDlzi7dlb9d6C5WuC0LRpomk2r3bd6 /XpNOx2FyG18axeeASWtENgPvqEirM5MjwkCMIIHZzCCBk+gAwIBAgIKEdBXngAAAAGkKjANBgkq hkiG9w0BAQUFADCBhTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2Vu dDEUMBIGCgmSJomT8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQD Ex5BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTUwNzA3MTI1MjI0WhcNMTcwNzA2 MTI1MjI0WjBFMREwDwYDVQQDEwhtaXNjaGFyZjEwMC4GCSqGSIb3DQEJARYhTWljaGFlbC5TY2hh cmZAYWxjYXRlbC1sdWNlbnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtzEU omeI48sVSv1p3vBrPu2R9zjAZ2l2V7kRAeGDVDSnrrrCtR588pfGTiDiEN0f2t7IxtQd5DtLetAa v/JzespJGEjwxEYzM2QSz1bLEnVOW9h/Bf2KNXfqoJnjVbloKTCWZjS2KnMuLqaQrvmL/jKLxWKT qa4swSmSBy9DZH/2kUnDDKygODCUTqhDBCuDJLWj39deheW6aIS03cLHOLLTZbJhv56ywnsHSOsK ugKipi2d6XMJRB+0OIRJjiS2HKXGPOCk+dV6+3/NVCRbY/zg2p2eekX41j9Ib7JOX6Sl+62RQDMx 12GmMONMtLGNfHjEFdvSBYEc/JuspqY3PwIDAQABo4IEFjCCBBIwPQYJKwYBBAGCNxUHBDAwLgYm KwYBBAGCNxUIhb3FWYPjsTmHpYEqhr/DQoWUmBmBC/nmTIT9tVoCAWQCAQUwHwYDVR0lBBgwFgYK KwYBBAGCNwoDBAYIKwYBBQUHAwQwCwYDVR0PBAQDAgWgMCkGCSsGAQQBgjcVCgQcMBowDAYKKwYB BAGCNwoDBDAKBggrBgEFBQcDBDBEBgkqhkiG9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggq hkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcNAwcwHQYDVR0OBBYEFHOq3ZrNyCmSol7/jGsl P6p2O+JLMB8GA1UdIwQYMBaAFNnsa72WWCL32KZ3zf5Nge+6l70SMIIBXQYDVR0fBIIBVDCCAVAw ggFMoIIBSKCCAUSGgdlsZGFwOi8vL0NOPUFsY2F0ZWwlMjBMdWNlbnQlMjBJbnRlcm5hbCUyMFN1 YiUyMENBLENOPXVzbmF2c3BraTAzcCxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMs Q049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1sdWFkLERDPWx1Y2VudCxEQz1jb20/Y2Vy dGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBv aW50hixodHRwczovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3N1YkNBLmNybIY4aHR0cDov L3NlcnZpY2VzLnN1cHBvcnQuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcmwwggFhBggr BgEFBQcBAQSCAVMwggFPMIHMBggrBgEFBQcwAoaBv2xkYXA6Ly8vQ049QWxjYXRlbCUyMEx1Y2Vu dCUyMEludGVybmFsJTIwU3ViJTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2Vz LENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bHVhZCxEQz1sdWNlbnQsREM9Y29tP2NB Q2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDgGCCsG AQUFBzAChixodHRwczovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3N1YkNBLmNydDBEBggr BgEFBQcwAoY4aHR0cDovL3NlcnZpY2VzLnN1cHBvcnQuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9z dWJDQS5jcnQwLAYDVR0RBCUwI4EhTWljaGFlbC5TY2hhcmZAYWxjYXRlbC1sdWNlbnQuY29tMA0G CSqGSIb3DQEBBQUAA4IBAQA1Tq05l6EukeZlLzSnjcmBdYfzVOw66v7omaIn6rQ3jtTBYh9cXeI0 SScUeP61Nd6R+oJS8I9PHE0J+BChyHR4UV+bzYJWkqNJ3KLTLwDFrZqmfTpkr/rQF5xiZUyrlqPa 9rN16hQbkDoxOZQS3ouSae3wfKcqIgPkgh4Yx0QWtruWCIXl7Q+qhEd/WNMkiwjqUrTNAGiWbte3 MEI3DLD9xzLef9MVHkMUFI3jfD00sG21qTHUefGboMMW+Ooih2gkbVWZX1JZNnsboAoEhqT96/XO 9Z2ZyOLJ6G5fbqoAuRNNjd18R3ESXUYikKsJuA9N39b6nLPJrZMzQ0BKzGM3MYIEKTCCBCUCAQEw gZQwgYUxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJ kiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRl bCBMdWNlbnQgSW50ZXJuYWwgU3ViIENBAgoR0FeeAAAAAaQqMAkGBSsOAwIaBQCgggJpMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2MDUxOTE1MTAyMVowIwYJKoZI hvcNAQkEMRYEFK1bBU/KFny7N8594QJfyRL1eQiHMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYUxEzAR BgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJkiaJk/IsZAEZ FgRuYTAyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRlbCBMdWNlbnQg SW50ZXJuYWwgU3ViIENBAgoR0FeeAAAAAaQqMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBhTETMBEG CgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkW BG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1Y2VudCBJ bnRlcm5hbCBTdWIgQ0ECChHQV54AAAABpCowgbcGCSqGSIb3DQEJDzGBqTCBpjALBglghkgBZQME ASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAw BwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCwYJYIZIAWUD BAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwCgYIKoZIhvcNAgUwDQYJKoZIhvcNAQEBBQAE ggEAObHgdKaCwgEETMmrHZskjqohBn/gHpdTau63GT//raJ+Q/YEUCRHMdt/2Lbl5inlLrMbkt+W +hWkbhMFk2KzjC0a16fiVuOUO3SVBi6bE3QRD/dMU0mAPBP1rSYvEKcWvFPOO5XGzadUW6TofXUe 8EQsUu1NTNYeTxGcJ5bjMWoOQ+2XShVcgQeBLLiJKncAgxVudZWx1+ZHVbiNtmxA/uonGUB1i0PP WinN3Qjej1cYja8AEzLWtyQTNUqvT8YPCMaBuwW+L2/GoY5sCPIyYP9cHB9Vumm4Qofr0eAHCtdD wl2iCypz13ess1OgTR2cKeDd39FXWeuisdYYrFVWwQAAAAAAAA== ------=_NextPart_000_0008_01D1B1F1.537953F0-- From nobody Thu May 19 08:16:31 2016 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 2830612D1D9 for ; Thu, 19 May 2016 08:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 5yirnWWo6hD2 for ; Thu, 19 May 2016 08:16:16 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id 0EDFE12D103 for ; Thu, 19 May 2016 08:16:13 -0700 (PDT) Received: (qmail 4784 invoked by uid 0); 19 May 2016 15:16:08 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy9.mail.unifiedlayer.com with SMTP; 19 May 2016 15:16:08 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id wFFw1s01G2SSUrH01FFz8T; Thu, 19 May 2016 09:16:08 -0600 X-Authority-Analysis: v=2.1 cv=cYhB8BzM c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=yrkiwgmsf1kA:10 a=AEDFM0qtAAAA:8 a=48vgC7mUAAAA:8 a=wU2YTnxGAAAA:8 a=JgjIG_CqoGoyCZZw2jYA:9 a=glgG9sZhwK0cQWaN:21 a=NoIKLEOakFXpCTxw:21 a=pILNOxqGKmIA:10 a=mYAOWqAtFUkA:10 a=1dbGxDndw2gA:10 a=NCq4FBG6EvGFEERSFaZp:22 a=w1C3t2QeGrPiZgrLijVG:22 a=Yz9wTY_ffGCQnEDHKrcv:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject; bh=xngp3L+UwUGqJ8wcrl1I4Q/roaX+TwoZdNGoJ5Uh8s4=; b=Giu0FVYNKDiZdTCYgxs5Xy5DxW 4JxPTg62l910lhUMChVsJWJY7wWp/xLOs3wb1v8qD7vgWQy6nZ8wgPx0ywVoXCkX8nKnW5sVef9BM ogPDQXW+2KZwYrcvhjodJWYAN; Received: from box313.bluehost.com ([69.89.31.113]:44348 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1b3Pg4-0003uD-MX; Thu, 19 May 2016 09:15:56 -0600 To: "Scharf, Michael (Nokia - DE)" , Stephen Farrell , "adrian@olddog.co.uk" , 'The IESG' References: <20160519134649.17318.42019.idtracker@ietfa.amsl.com> <08e601d1b1d7$ce700d70$6b502850$@olddog.co.uk> <655C07320163294895BBADA28372AF5D4885CA2A@FR712WXCHMBA15.zeu.alcatel-lucent.com> <573DD3E5.4060108@cs.tcd.ie> <655C07320163294895BBADA28372AF5D4885CC0F@FR712WXCHMBA15.zeu.alcatel-lucent.com> From: Lou Berger Message-ID: <573DD8A6.2020900@labn.net> Date: Thu, 19 May 2016 11:15:50 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <655C07320163294895BBADA28372AF5D4885CC0F@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: "draft-ietf-teas-interconnected-te-info-exchange@ietf.org" , "teas-chairs@ietf.org" , "teas@ietf.org" Subject: Re: [Teas] Stephen Farrell's No Objection on draft-ietf-teas-interconnected-te-info-exchange-06: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 19 May 2016 15:16:30 -0000 On 5/19/2016 11:10 AM, Scharf, Michael (Nokia - DE) wrote: > The pre-standard version of TCP-AO seems very widely deployed with > interoperability among the TCP stacks. But why does this matter for a TEAS > document? This document, from TEAS, refers to BGP and PCEP. Both of these use TCP. Both also have their own WG, so TEAS is just the user here. Lou > This is TCPM business. > > Michael > > > > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Thursday, May 19, 2016 4:56 PM > To: Scharf, Michael (Nokia - DE); adrian@olddog.co.uk; 'The IESG' > Cc: draft-ietf-teas-interconnected-te-info-exchange@ietf.org; > teas-chairs@ietf.org; teas@ietf.org; lberger@labn.net > Subject: Re: [Teas] Stephen Farrell's No Objection on > draft-ietf-teas-interconnected-te-info-exchange-06: (with COMMENT) > > > Hi Michael, > > On 19/05/16 15:30, Scharf, Michael (Nokia - DE) wrote: >> For what it is worth, I do not understand the sentence below "If it >> wouldn't, then I'm not sure there's much point in mentioning TCP-AO >> given what I understand it the current state of play there." >> >> TCP-AO is a proposed standard by TCPM and specifically addresses some >> of the protocols typically used in such environments. > Sure, there's no issue with the RFC. If the RFC were widely > implemented and deployed that'd be great. My understanding > though is that that's not currently the case so I wondered if > teas might be something that'd help that along. If it is not > something that'd help that along, then the text in the draft > right now is a tiny bit misleading as it proposes (as an > option) to depend on something that won't be used which I > don't think is actually a good way to improve security. > > I get that we have to start somewhere, and shouldn't give > up easily, but equally, if an RFC isn't being deployed, then > at some point we should also pay attention to that. I'm not > saying we're at that stage with TCP-AO btw, but it has been > 6 years so I do wonder about it. > > (And to be clear: none of the above is asking for a change > to the current document unless the authors/wg want to make > such a change, which it seems they don't.) > > Cheers, > S. > >> Michael (TCPM co-chair) >> >> >> -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] >> On Behalf Of Adrian Farrel Sent: Thursday, May 19, 2016 4:08 PM To: >> 'Stephen Farrell'; 'The IESG' Cc: >> draft-ietf-teas-interconnected-te-info-exchange@ietf.org; >> teas-chairs@ietf.org; teas@ietf.org; lberger@labn.net Subject: Re: >> [Teas] Stephen Farrell's No Objection on >> draft-ietf-teas-interconnected-te-info-exchange-06: (with COMMENT) >> >> Stephen, >> >> Happy to be guided on relative merits of TCP-AO and TLS. >> >> When we pushed RFC 5440 through we were asked to include the >> following text: >> >> The TCP Authentication Option [TCP-AUTH] (TCP-AO) specifies new >> security procedures for TCP, but is not yet complete. Since it is >> believed that [TCP-AUTH] will offer significantly improved security >> for applications using TCP, implementers should expect to update >> their implementation as soon as the TCP Authentication Option is >> published as an RFC. >> >> RFC 6952 says: Since TCP-AO [RFC5925] has now been published, new >> PCEP implementations should fully support TCP-AO. >> >> 6952 goes on to appear to say that routing protocols carried over TCP >> should implement TCP-AO. >> >> Appendix A refers to PCEP (RFC 5440) and also BGP hence the mention >> in Section 12. >> >> Now, it is OK if all this has changed or if the "shouldiness" of the >> advice really doesn't mean anything. >> >> Please advise what a post-KARP document that refers to a TCP-base >> routing protocol should say. >> >> Cheers, Adrian >> >> >> >>> -----Original Message----- From: Stephen Farrell >>> [mailto:stephen.farrell@cs.tcd.ie] Sent: 19 May 2016 14:47 To: The >>> IESG Cc: draft-ietf-teas-interconnected-te-info-exchange@ietf.org; >>> Lou Berger; teas- chairs@ietf.org; lberger@labn.net; teas@ietf.org >>> Subject: Stephen Farrell's No Objection on >>> draft-ietf-teas-interconnected-te- info-exchange-06: (with >>> COMMENT) >>> >>> Stephen Farrell has entered the following ballot position for >>> draft-ietf-teas-interconnected-te-info-exchange-06: No Objection >>> >>> When responding, please keep the subject line intact and reply to >>> all email addresses included in the To and CC lines. (Feel free to >>> cut this introductory paragraph, however.) >>> >>> >>> Please refer to >>> https://www.ietf.org/iesg/statement/discuss-criteria.html for more >>> information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found >>> here: >>> https://datatracker.ietf.org/doc/draft-ietf-teas-interconnected-te-inf >>> >>> > o- >>> exchange/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> >>> > COMMENT: >>> ---------------------------------------------------------------------- >>> >>> >>> >>> > - The security considerations says to use IPsec or TCP-AO. To what >>> extent do we think that this could help with implementation and >>> deployment of TCP-AO? If it can, great. If it wouldn't, then I'm >>> not sure there's much point in mentioning TCP-AO given what I >>> understand it the current state of play there. >>> >>> - IPsec can clearly be used, but I wondered if there's really no >>> place for using TLS between the domains here? That might need a bit >>> of work, (e.g. to allocate ports or define a STARTTLS equivalent), >>> but perhaps there's the opportunity here to get that kind of thing >>> done? That's maybe less of a question for this document, but more >>> for the WG in general. (Though if (D)TLS made sense as part of >>> this, saying so here would be good probably.) >>> >>> - I note that the IPR declaration refers to a "standard." As of >>> now, this document is aiming for BCP, so I've no idea how to >>> interpret the text in the declaration unless this reverts to PS. >>> (That said: I don't care much about what kind of RFC results here, >>> but I agree with the authors that just picking wihtout requiring >>> text changes for process reasons is right.) >> >> _______________________________________________ Teas mailing list >> Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas >> > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Fri May 20 11:07:03 2016 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 1448712D5E8 for ; Fri, 20 May 2016 11:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jB96jQ1u4yau for ; Fri, 20 May 2016 11:06:59 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5BC212D5DF for ; Fri, 20 May 2016 11:06:59 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 5ACF69EF33DD4; Fri, 20 May 2016 18:06:54 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4KI6ucS012499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 May 2016 18:06:57 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u4KI6tjR010006 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 May 2016 20:06:56 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.44]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 20 May 2016 20:06:55 +0200 From: "Scharf, Michael (Nokia - DE)" To: "adrian@olddog.co.uk" , "teas@ietf.org" Thread-Topic: [Teas] A New I-D on PCE as a central controller Thread-Index: AdGnosEWtnZGzgfkR5SQqz0Nm22cLQEn1m5QADlM4QABYpJEYA== Date: Fri, 20 May 2016 18:06:55 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48860ADB@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <0c6c01d1a7a2$f1a24860$d4e6d920$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48846127@FR712WXCHMBA15.zeu.alcatel-lucent.com> <042101d1ad38$12da5f50$388f1df0$@olddog.co.uk> In-Reply-To: <042101d1ad38$12da5f50$388f1df0$@olddog.co.uk> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Teas] A New I-D on PCE as a central controller X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 20 May 2016 18:07:02 -0000 As I said, I specifically wonder about Section 3.2.3 "Service Delivery", wh= ich states (omitting some parts that are not relevant here): "Various network services may be offered over a network. These include prot= ection services [...] Virtual Private Network (VPN) service (such as Layer = 3 VPNs [RFC4364] or Ethernet VPNs [RFC7432]), or Pseudowires [RFC3985]. [..= .] A PCE-based central control can consider the whole network and all comp= onents of a service at once when planning how to deliver the service. It ca= n then use PCEP to manage the network resources and to install the necessar= y associations between those resources." This wording on use of PCEP confuses me, no matter what interface we talk a= bout. I would have assumed that YANG-based protocols such as NETCONF/RESTCO= NF could be useful in this context, and I am a bit surprised that the docum= ent focuses on using PCEP e.g. for L3VPN service delivery. By the way, I al= so wonder how PCEP fits into the discussion on QoS classification in Sectio= n 3.2.2. I wonder if the authors could add to Section 3.2.2 and Section 3.2.3 e.g. a= message sequence chart that illustrates how what is discussed in those sec= tions relates to PCEP? Michael -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of EXT Adrian Farrel Sent: Friday, May 13, 2016 6:54 PM To: Scharf, Michael (Nokia - DE); teas@ietf.org Subject: Re: [Teas] A New I-D on PCE as a central controller Hello again, Michael, it seems to be my day for replying to your emails. > When reading about uses cases such as L3VPN service delivery in=20 > "Section 3.2.3", > what is the author's view on the line of demarcation between NETCONF=20 > and PCEP? Well, I wonder which interface you're talking about. The ones that out in here are: - the interface between customer and operator - the interface between "service orchestrator" and "network orchestrator" The former of these is like the interface used in L3SM. As co-chair of L3SM= , you might not be surprised to hear that my view is that NETCONF is a fine= solution - well, the use of a YANG data model, in any case. The latter is the interface between "Orchestrator / Service Manager / OSS /= NMS" and "PCE-based Controller" as shown on the various figures in the picture. = We haven't discussed this interface in the document, and perhaps we should. If you look at Figure 6 (with the hierarchy of controllers) you might obser= ve that the parent controller could be implemented to act as though it is t= alking to an NE (in the abstract node model) and that means that the southb= ound interface of the parent controller would be PCEP. That means (of cours= e) that the northbound interface of the child controller would also be PCEP= . Then, it might seem obvious that we would want all PCE implementations to= behave the same way and so that makes the northbound interface of the pare= nt PCE would/could/should/might also be PCEP. What do you think? Thanks, Adrian _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Sat May 21 05:22:52 2016 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 6896D12D0A1; Sat, 21 May 2016 05:22:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160521122251.18638.6367.idtracker@ietfa.amsl.com> Date: Sat, 21 May 2016 05:22:51 -0700 Archived-At: Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-interconnected-te-info-exchange-07.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 21 May 2016 12:22:51 -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 of the IETF. Title : Problem Statement and Architecture for Information Exchange Between Interconnected Traffic Engineered Networks Authors : Adrian Farrel John Drake Nabil Bitar George Swallow Daniele Ceccarelli Xian Zhang Filename : draft-ietf-teas-interconnected-te-info-exchange-07.txt Pages : 61 Date : 2016-05-21 Abstract: In Traffic Engineered (TE) systems, it is sometimes desirable to establish an end-to-end TE path with a set of constraints (such as bandwidth) across one or more network from a source to a destination. TE information is the data relating to nodes and TE links that is used in the process of selecting a TE path. TE information is usually only available within a network. We call such a zone of visibility of TE information a domain. An example of a domain may be an IGP area or an Autonomous System. In order to determine the potential to establish a TE path through a series of connected networks, it is necessary to have available a certain amount of TE information about each network. This need not be the full set of TE information available within each network, but does need to express the potential of providing TE connectivity. This subset of TE information is called TE reachability information. This document sets out the problem statement for the exchange of TE information between interconnected TE networks in support of end-to- end TE path establishment and describes the best current practice architecture to meet this problem statement. For reasons that are explained in the document, this work is limited to simple TE constraints and information that determine TE reachability. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-interconnected-te-info-exchange/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-teas-interconnected-te-info-exchange-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-interconnected-te-info-exchange-07 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 Sat May 21 05:26:33 2016 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 AF2E412D51D; Sat, 21 May 2016 05:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vntFv5tsRv6c; Sat, 21 May 2016 05:26:30 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 495C712D0A2; Sat, 21 May 2016 05:26:30 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id u4LCQRjW016345; Sat, 21 May 2016 13:26:27 +0100 Received: from 950129200 (jplon-nat12.juniper.net [193.110.55.12]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id u4LCQO8W016322 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 21 May 2016 13:26:26 +0100 From: "Adrian Farrel" To: Date: Sat, 21 May 2016 13:26:24 +0100 Message-ID: <001f01d1b35b$ff6b6840$fe4238c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdGzW/vgsvcwPYvwQCK3tSh8NJjAZg== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22336.001 X-TM-AS-Result: No--15.708-10.0-31-10 X-imss-scan-details: No--15.708-10.0-31-10 X-TMASE-MatchedRID: zXc8qpa/YFIPjOdXhbMBru96wdiuTtuxH181YDtIVaq638ZUY6gSdz0J SifQ1MZ5EGnG9542IQ5xhflh9tC8USyTPIfegtsCj5hLPCX3ZdO36GGfwjLoZdp1biJhIyNRXa2 +zE1cP+Xpy2RAH6qC4f3selkw4oORmZGvWTp76WAIs18ZTh19+BkqnRJng/51UNzg/KvQ9bA0B4 2z9wit4ujQwdZQOVCrWkEwb/DqEvd6NuuFvb/6WsWUKBjERoYTrrEvQogcy/FSnx0d8Hk9EmjtE qyFPlQ/7UXWmJKyEwevO9YfTdeoemFqPXSLpNdASEQN/D/3cG6DddlymG7iSwzvg1/q1MH2Z3KR kLO0vRk0cyESKOBv9AXOZdORTuqrGAdnzrnkM485f9Xw/xqKXcidYBYDjITptrNGq+WQEvSrusV Ry4an8SAHAopEd76vY0C7rDsQhyywqDCHrmLBO2PA5o/aa19K0gas1L/THTQhIlwbE0IHLA== Archived-At: Cc: draft-ietf-teas-interconnected-te-info-exchange.all@ietf.org, brian.e.carpenter@gmail.com, iesg@ietf.org Subject: [Teas] New revision draft-ietf-teas-interconnected-te-info-exchange X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk 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: Sat, 21 May 2016 12:26:33 -0000 All, During IETF last call and IESG review questions were asked about whether all parts of this I-D qualified as BCP. To address these comments and after discussion with the document shepherd and sponsoring AD we have made a new revision. The changes are: - Change the titles of sections 6, 7, and 8 to be "Application of the Architecture to foo" - Mark sections 5 and 9 and the two appendixes explicitly as non-normative. Cheers, Adrian > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: 21 May 2016 13:23 > To: i-d-announce@ietf.org > Cc: teas@ietf.org > Subject: [Teas] I-D Action: draft-ietf-teas-interconnected-te-info-exchange- > 07.txt > > > 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 of > the IETF. > > Title : Problem Statement and Architecture for Information Exchange > Between Interconnected Traffic Engineered Networks > Authors : Adrian Farrel > John Drake > Nabil Bitar > George Swallow > Daniele Ceccarelli > Xian Zhang > Filename : draft-ietf-teas-interconnected-te-info-exchange-07.txt > Pages : 61 > Date : 2016-05-21 > > Abstract: > In Traffic Engineered (TE) systems, it is sometimes desirable to > establish an end-to-end TE path with a set of constraints (such as > bandwidth) across one or more network from a source to a destination. > TE information is the data relating to nodes and TE links that is > used in the process of selecting a TE path. TE information is > usually only available within a network. We call such a zone of > visibility of TE information a domain. An example of a domain may be > an IGP area or an Autonomous System. > > In order to determine the potential to establish a TE path through a > series of connected networks, it is necessary to have available a > certain amount of TE information about each network. This need not > be the full set of TE information available within each network, but > does need to express the potential of providing TE connectivity. This > subset of TE information is called TE reachability information. > > This document sets out the problem statement for the exchange of TE > information between interconnected TE networks in support of end-to- > end TE path establishment and describes the best current practice > architecture to meet this problem statement. For reasons that are > explained in the document, this work is limited to simple TE > constraints and information that determine TE reachability. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-teas-interconnected-te-info- > exchange/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-teas-interconnected-te-info-exchange-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-interconnected-te-info- > exchange-07 > > > 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/ > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Sat May 21 21:24:02 2016 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 0CD7612D172 for ; Sat, 21 May 2016 21:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwO05Oq-Vy5k for ; Sat, 21 May 2016 21:23:57 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FEFB12D141 for ; Sat, 21 May 2016 21:23:56 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id u4M4NsLj018229; Sun, 22 May 2016 05:23:54 +0100 Received: from 950129200 ([61.132.52.82]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id u4M4Nm86018162 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 22 May 2016 05:23:51 +0100 From: "Adrian Farrel" To: "'Scharf, Michael \(Nokia - DE\)'" References: <0c6c01d1a7a2$f1a24860$d4e6d920$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48846127@FR712WXCHMBA15.zeu.alcatel-lucent.com> <042101d1ad38$12da5f50$388f1df0$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48860ADB@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D48860ADB@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Sun, 22 May 2016 05:23:47 +0100 Message-ID: <001d01d1b3e1$bec637d0$3c52a770$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01D1B3EA.2090BA50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJA1E+Zq/sUNt+MoVFJT1Mxjgw0wgGJwDglArYWgCoCKVHAMJ6yxqPA Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22338.005 X-TM-AS-Result: No--42.257-10.0-31-10 X-imss-scan-details: No--42.257-10.0-31-10 X-TMASE-MatchedRID: IeZYkn8zfFqs7uBvvd6AmXBRIrj8R47FZa7LkubQvj8cVJCT3tVgalQS WdmUbN6C60Z3zKpKpCT5F1yiVNAj28FeWQ9rEC3Vt1AhvyEKdj62ZvhoMhZCihy/A9iZcrIfY7h CWgdYh4IZRW+U9kLqOank8BxYEkfIQLsQdie3qA/FlCgYxEaGE4HSaqO6kWzlkzE2kM4b6HrImJ UezF9c+GNT4pJ1vODJiQmRCw+pqtyite+kuPVDR4pAKqry9ioVVulQZWfkBK476rqmQGSwT/M+9 Fw01I7GU0hkXF0vykYOvjTKsZIYBjAnrFtOMFrmQoYfbYqT0j8hHWssEmb8zuCigm6l/zGvrRGi aFY8lpDJ//Qj80fwjnJxjrgBF/XDbC0NanHb+K7sjRHO89icwr/I3arxTrviyL0CMroLynVcyab xiVvR8x2C3tKeAO+P+WSEvCPMlw0qvVOPrBalEBwCzXusK42x1pnvzMqQcsasP4xgB5HN3/rqgj uDVtSDpJoXS6a6szPU+href+yv5296IeTQb5HS4t2mucDkRBEsleOknNBI0w+kahHW2HeeVSoV5 xgshP95b5gB3zTPzrPMJDbV0mqi4VGGT5XQyDv6daZahG7qsbfoYZ/CMuhl2nVuImEjI1FAyXGM Y0TP1VHikzHZLaontSjIT1ERRfbqlcL1cdvxj4Q6iEG+7EHndEB1/ZEcFc9XcER64EXG6o4makW SIXbD7d24Mhckf+/a1bO3o3BK6IjQo/Iw2s1SmlaAItiONP36rVj794QCtn1Dn+DKecbWdcfoN2 nPU+l7YBenfDEAZds+VuS9haRJ9gCZrQUdJx2eAiCmPx4NwGmRqNBHmBvevqq8s2MNhPDPPeN6H N6d7AGLeSok4rrZIAcCikR3vq+bdW4o6+XLnZjIb1HfWLW5Dm21BfFzYB6itFgEIW0SDkD0wJUd Xft/ Archived-At: Cc: teas@ietf.org Subject: Re: [Teas] A New I-D on PCE as a central controller X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk 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, 22 May 2016 04:24:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001E_01D1B3EA.2090BA50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Michael, I don't think it is complicated, but it is obviously not clear from the document, so thank you for raising the concern. You say it doesn't matter which interface we're talking about, but it does. PCEP is a protocol and protocols are used on interfaces. Let's start with southbound of the PCE. We already use PCEP on this interface. We have always done. It is what PCEP was invented for. And recent developments in Stateful PCE and PCE-Initiated LSPs have made PCEP (and this interface) able to send control "commands" as well as respond to requests. Thus, PCEP is an SBI protocol for use with signaling systems. Now, we might make several observations... In many (most?) MPLS-TE networks, every router is capable of being the head end of LSPs. That means that in a PCE-enabled MPLS-TE network, every router is a PCEP speaker. Additionally, we can observe that LSPs (or PWs) can be stitched together. The stitching, if under the control of a PCE, requires a special instruction to be sent to the stitching node. Furthermore, we can understand that a single end-to-end LSP is actually the stitching of lots of single hop LSPs. That is really what a statically provisioned LSP is. Finally, we can see a desire to send TE instructions from a computation engine (e.g., PCE) to individual network nodes to program their forwarding. For example, in a Segment Routed network or for static MPLS-TE LSPs. Put all of this together with the recognition that all TE path management is fundamentally the same and can be performed by the same engine, and that it does not make sense for such an engine to have to implement multiple SBI protocols, and you end up with this draft. I don't think we are saying that this approach is compulsory, but we are saying that it is possible. Other possibilities exist including using NETCONF/YANG in place of PCEP, and enhancing BGP in place of PCEP. Others have suggested XMPP. Frankly, if we were proposing a new protocol it would be correct to tell us not to, and to persuade us that one of the other protocols will do the job. But here we are with three (or four) protocols that fit the bill: each currently covers some of the function space and each could easily be extended to cover the whole space. I'm not capable of saying how to decide which protocol does which function, but I do see pressures of implementation and deployment that lead to this draft. [Historic note: I was somewhat opposed to adding PCE-Initiated LSP support to PCEP. I thought this bent the architecture further than was originally intended. But we went there in the PEC WG and the I-D is now "complete". By adding support of PCE initiation of LSPs, we naturally opened the path to this document. FWIW, this is not the first time that PCEP has been discussed as a more general SBI protocol - RFC 7491 shows it in this context although does not discuss it much (we should probably add a reference to ABNO in this document).] Now, you say you are surprised that "the document focuses on using PCEP e.g. for L3VPN service delivery." I think there is a significant difference between *requesting* a service and *delivering* that service. The service request (as, for example, in L3SM) does not involve a PCE and is easily achieved using a YANG model which, if the service request is on-line, can be delivered using NETCONF. However, service delivery requires "orchestration". Orchestration is the process of considering available network resources and selecting what will be provisioned to support the service. A PCE is at least a key feature of orchestration, just as it is a key component of a network controller. But the document does NOT focus on PCEP in quite the way you describe. In fact, the only discussion is in 3.2.3 (just two paragraphs in the whole document) where the focus is on the use of a PCE-based central controller that can "consider the whole network and all components of a service at once when planning how to deliver the service." It then goes on to observe that PCEP can be used "to manage the network resources and to install the necessary associations between those resources." If we included a message flow chart it would look something like... Service Manager PCE-based Controller NEs Request service---------> Compute Provision ------> <------------- Ack Update DBs <-------------------Ack If that simple figure helps with the understanding of this or any other part of the document, we can surely add it. Cheers, Adrian > -----Original Message----- > From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] > Sent: 20 May 2016 19:07 > To: adrian@olddog.co.uk; teas@ietf.org > Subject: RE: [Teas] A New I-D on PCE as a central controller > > As I said, I specifically wonder about Section 3.2.3 "Service Delivery", which states > (omitting some parts that are not relevant here): > > "Various network services may be offered over a network. These include > protection services [...] Virtual Private Network (VPN) service (such as Layer 3 > VPNs [RFC4364] or Ethernet VPNs [RFC7432]), or Pseudowires [RFC3985]. [...] A > PCE-based central control can consider the whole network and all components of > a service at once when planning how to deliver the service. It can then use PCEP > to manage the network resources and to install the necessary associations > between those resources." > > This wording on use of PCEP confuses me, no matter what interface we talk > about. I would have assumed that YANG-based protocols such as > NETCONF/RESTCONF could be useful in this context, and I am a bit surprised that > the document focuses on using PCEP e.g. for L3VPN service delivery. By the way, > I also wonder how PCEP fits into the discussion on QoS classification in Section > 3.2.2. > > I wonder if the authors could add to Section 3.2.2 and Section 3.2.3 e.g. a > message sequence chart that illustrates how what is discussed in those sections > relates to PCEP? > > Michael > > > > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of EXT Adrian Farrel > Sent: Friday, May 13, 2016 6:54 PM > To: Scharf, Michael (Nokia - DE); teas@ietf.org > Subject: Re: [Teas] A New I-D on PCE as a central controller > > Hello again, Michael, it seems to be my day for replying to your emails. > > > When reading about uses cases such as L3VPN service delivery in > > "Section > 3.2.3", > > what is the author's view on the line of demarcation between NETCONF > > and PCEP? > > Well, I wonder which interface you're talking about. > The ones that out in here are: > - the interface between customer and operator > - the interface between "service orchestrator" and "network orchestrator" > > The former of these is like the interface used in L3SM. As co-chair of L3SM, you > might not be surprised to hear that my view is that NETCONF is a fine solution - > well, the use of a YANG data model, in any case. > > The latter is the interface between "Orchestrator / Service Manager / OSS / > NMS" > and "PCE-based Controller" as shown on the various figures in the picture. We > haven't discussed this interface in the document, and perhaps we should. > > If you look at Figure 6 (with the hierarchy of controllers) you might observe that > the parent controller could be implemented to act as though it is talking to an NE > (in the abstract node model) and that means that the southbound interface of > the parent controller would be PCEP. That means (of course) that the > northbound interface of the child controller would also be PCEP. Then, it might > seem obvious that we would want all PCE implementations to behave the same > way and so that makes the northbound interface of the parent PCE > would/could/should/might also be PCEP. > > What do you think? > > Thanks, > Adrian > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas ------=_NextPart_000_001E_01D1B3EA.2090BA50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Michael,

 

I = don't think it is complicated, but it is obviously not clear from the = document, so thank you for raising the concern.

 

You = say it doesn't matter which interface we're talking about, but it does. = PCEP is a protocol and protocols are used on = interfaces.

 

Let's = start with southbound of the PCE. We already use PCEP on this interface. = We have always done. It is what PCEP was invented for. And recent = developments in Stateful PCE and PCE-Initiated LSPs have made PCEP (and = this interface) able to send control "commands" as well as = respond to requests. Thus, PCEP is an SBI protocol for use with = signaling systems.

 

Now, = we might make several observations...

 

In = many (most?) MPLS-TE networks, every router is capable of being the head = end of LSPs. That means that in a PCE-enabled MPLS-TE network, every = router is a PCEP speaker.

 

Additionally, we can observe that LSPs (or PWs) can = be stitched together. The stitching, if under the control of a PCE, = requires a special instruction to be sent to the stitching = node.

 

Furthermore, we can understand that a single = end-to-end LSP is actually the stitching of lots of single hop LSPs. = That is really what a statically provisioned LSP is.

 

Finally, we can see a desire to send TE = instructions from a computation engine (e.g., PCE) to individual network = nodes to program their forwarding. For example, in a Segment Routed = network or for static MPLS-TE LSPs.

 

 

Put = all of this together with the recognition that all TE path management is = fundamentally the same and can be performed by the same engine, and that = it does not make sense for such an engine to have to implement multiple = SBI protocols, and you end up with this draft.

 

I = don't think we are saying that this approach is compulsory, but we are = saying that it is possible. Other possibilities exist including using = NETCONF/YANG in place of PCEP, and enhancing BGP in place of PCEP. = Others have suggested XMPP. Frankly, if we were proposing a new protocol = it would be correct to tell us not to, and to persuade us that one of = the other protocols will do the job. But here we are with three (or = four) protocols that fit the bill: each currently covers some of the = function space and each could easily be extended to cover the whole = space. I'm not capable of saying how to decide which protocol does which = function, but I do see pressures of implementation and deployment that = lead to this draft.

 

[Historic note: I was somewhat opposed to adding = PCE-Initiated LSP support to PCEP. I thought this bent the architecture = further than was originally intended. But we went there in the PEC WG = and the I-D is now "complete". By adding support of PCE = initiation of LSPs, we naturally opened the path to this document. FWIW, = this is not the first time that PCEP has been discussed as a more = general SBI protocol - RFC 7491 shows it in this context although does = not discuss it much (we should probably add a reference to ABNO in this = document).]

 

 

Now, = you say you are surprised that "the document focuses on using PCEP = e.g. for L3VPN service delivery." I think there is a significant = difference between *requesting* a service and *delivering* that service. = The service request (as, for example, in L3SM) does not involve a PCE = and is easily achieved using a YANG model which, if the service request = is on-line, can be delivered using NETCONF. However, service delivery = requires "orchestration". Orchestration is the process of = considering available network resources and selecting what will be = provisioned to support the service. A PCE is at least a key feature of = orchestration, just as it is a key component of a network controller. =

 

But the document does NOT focus on PCEP in quite = the way you describe. In fact, the only discussion is in 3.2.3 (just two = paragraphs in the whole document) where the focus is on the use of a = PCE-based central controller that can "consider the whole network = and all components of a service at once when planning how to deliver the = service." It then goes on to observe that PCEP can be used "to = manage the network resources and to install the necessary associations = between those resources."

 

 

If we = included a message flow chart it would look something = like...

 

Service = Manager      PCE-based Controller     = NEs

     Request = service--------->

       &nbs= p;            = ;      Compute

       &nbs= p;            = ;           = Provision ------>

       &nbs= p;            = ;            = <------------- Ack

       &nbs= p;            = ;      Update = DBs

     = <-------------------Ack

 

If that simple figure helps with the = understanding of this or any other part of the document, we can surely = add it.

 

Cheers,

Adrian

 

> = -----Origina= l Message-----

> From: = Scharf, Michael (Nokia - DE) = [mailto:michael.scharf@nokia.com]

> = Sent: 20 = May 2016 19:07

> To: = adrian@olddog.co.uk; teas@ietf.org

> Subject: = RE: [Teas] A New I-D on PCE as a central controller

>

> As I said, I = specifically wonder about Section 3.2.3 "Service Delivery", = which states

> (omitting some parts that = are not relevant here):

>

> "Various network services may be offered = over a network. These include

> protection = services [...] Virtual Private Network (VPN) service (such as Layer = 3

> VPNs [RFC4364] or Ethernet VPNs = [RFC7432]), or Pseudowires [RFC3985]. [...]  A

> PCE-based central control can consider the = whole network and all components of

> a = service at once when planning how to deliver the service. It can then = use PCEP

> to manage the network resources = and to install the necessary associations

> between those resources."

>

> This wording = on use of PCEP confuses me, no matter what interface we talk

> about. I would have assumed that YANG-based = protocols such as

> NETCONF/RESTCONF could = be useful in this context, and I am a bit surprised that

> the document focuses on using PCEP e.g. for = L3VPN service delivery. By the way,

> I = also wonder how PCEP fits into the discussion on QoS classification in = Section

> 3.2.2.

>

> I wonder if = the authors could add to Section 3.2.2 and Section 3.2.3 e.g. a

> message sequence chart that illustrates how = what is discussed in those sections

> = relates to PCEP?

>

> Michael

>

>

>

> -----Original Message-----

> From: Teas [mailto:teas-bounces@ietf.org] On = Behalf Of EXT Adrian Farrel

> Sent: = Friday, May 13, 2016 6:54 PM

> To: Scharf, = Michael (Nokia - DE); teas@ietf.org

> = Subject: Re: [Teas] A New I-D on PCE as a central controller

>

> Hello again, = Michael, it seems to be my day for replying to your emails.

>

> > When = reading about uses cases such as L3VPN service delivery in

> > "Section

> 3.2.3",

> = > what is the author's view on the line of demarcation between = NETCONF

> > and PCEP?

>

> Well, I = wonder which interface you're talking about.

> The ones that out in here are:

> - the interface between customer and = operator

> - the interface between = "service orchestrator" and "network = orchestrator"

>

> The former of these is like the interface used = in L3SM. As co-chair of L3SM, you

> might = not be surprised to hear that my view is that NETCONF is a fine solution = -

> well, the use of a YANG data model, in = any case.

>

> The latter is the interface between = "Orchestrator / Service Manager / OSS /

> NMS"

> and = "PCE-based Controller" as shown on the various figures in the = picture. We

> haven't discussed this = interface in the document, and perhaps we should.

>

> If you look = at Figure 6 (with the hierarchy of controllers) you might observe = that

> the parent controller could be = implemented to act as though it is talking to an NE

> (in the abstract node model) and that means = that the southbound interface of

> the = parent controller would be PCEP. That means (of course) that the

> northbound interface of the child controller = would also be PCEP. Then, it might

> seem = obvious that we would want all PCE implementations to behave the = same

> way and so that makes the = northbound interface of the parent PCE

> = would/could/should/might also be PCEP.

> =

> What do you think?

>

> Thanks,

> Adrian

>

> = _______________________________________________

> Teas mailing list

> Teas@ietf.org

> = https://www.ietf.org/mailman/listinfo/teas

------=_NextPart_000_001E_01D1B3EA.2090BA50-- From nobody Sun May 22 14:34:17 2016 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 E505F12D5D0 for ; Sun, 22 May 2016 14:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0eu4WGpdae_8 for ; Sun, 22 May 2016 14:34:12 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6192812D5BC for ; Sun, 22 May 2016 14:34:12 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 01AA5CFC320F0; Sun, 22 May 2016 21:34:06 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4MLY93A021789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 22 May 2016 21:34:09 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u4MLY8I1030186 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 22 May 2016 23:34:08 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.44]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Sun, 22 May 2016 23:34:08 +0200 From: "Scharf, Michael (Nokia - DE)" To: "adrian@olddog.co.uk" Thread-Topic: [Teas] A New I-D on PCE as a central controller Thread-Index: AdGnosEWtnZGzgfkR5SQqz0Nm22cLQEn1m5QADlM4QABYpJEYABH2DeAACYha5A= Date: Sun, 22 May 2016 21:34:07 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48862397@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <0c6c01d1a7a2$f1a24860$d4e6d920$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48846127@FR712WXCHMBA15.zeu.alcatel-lucent.com> <042101d1ad38$12da5f50$388f1df0$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48860ADB@FR712WXCHMBA15.zeu.alcatel-lucent.com> <001d01d1b3e1$bec637d0$3c52a770$@olddog.co.uk> In-Reply-To: <001d01d1b3e1$bec637d0$3c52a770$@olddog.co.uk> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D48862397FR712WXCHMBA15z_" MIME-Version: 1.0 Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] A New I-D on PCE as a central controller X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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: Sun, 22 May 2016 21:34:16 -0000 --_000_655C07320163294895BBADA28372AF5D48862397FR712WXCHMBA15z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Adrian, Many thanks for the tutorial. Since RFC 7491 already acknowledges the role = of a PCE, I see little value of a high-level document that talks about PCEP= as a general SBI for the topics mentioned in Section 3.2.2 and Section 3.2= .3, if that document does not discuss more specifically the impact on PCEP,= data models, etc. It should be obvious that in my point of view the wording in Sections 3.2.2= and 3.2.3 is not clear. Just repeating the wording once again does not add= ress my question, since I have obviously read the document and since I know= the terminology (albeit I am not a native speaker). A generic flow chart n= ot detailing for which of the messages PCEP would be used, and with what co= ntent, also does not address my concern. In any case, if the content of Section 3.2.2 and Section 3.2.3 cannot be ma= de more explicit, it is impossible for me to understand whether the conclus= ion in Section 4 ... "As such, no substantial changes to PCEP are required = to support the concept of a PCE-based controller. The only work needed will= be small extensions to carry additional or specific information elements f= or the individual use cases." is correct and how it is actually justified f= or the technical areas such as Section 3.2.2 and Section 3.2.3 . >From my personal experience this sort of entirely generic conclusion could = perhaps be a bit of simplification, but this may depend on the actual use c= ase. But in an I-D, I believe such a generic conclusion needs backing by co= ntent and as far as I understand for Section 3.2.2 and Section 3.2.3 this b= acking is lacking in the document right now. Thanks Michael From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Sunday, May 22, 2016 6:24 AM To: Scharf, Michael (Nokia - DE) Cc: teas@ietf.org Subject: RE: [Teas] A New I-D on PCE as a central controller Michael, I don't think it is complicated, but it is obviously not clear from the doc= ument, so thank you for raising the concern. You say it doesn't matter which interface we're talking about, but it does.= PCEP is a protocol and protocols are used on interfaces. Let's start with southbound of the PCE. We already use PCEP on this interfa= ce. We have always done. It is what PCEP was invented for. And recent devel= opments in Stateful PCE and PCE-Initiated LSPs have made PCEP (and this int= erface) able to send control "commands" as well as respond to requests. Thu= s, PCEP is an SBI protocol for use with signaling systems. Now, we might make several observations... In many (most?) MPLS-TE networks, every router is capable of being the head= end of LSPs. That means that in a PCE-enabled MPLS-TE network, every route= r is a PCEP speaker. Additionally, we can observe that LSPs (or PWs) can be stitched together. T= he stitching, if under the control of a PCE, requires a special instruction= to be sent to the stitching node. Furthermore, we can understand that a single end-to-end LSP is actually the= stitching of lots of single hop LSPs. That is really what a statically pro= visioned LSP is. Finally, we can see a desire to send TE instructions from a computation eng= ine (e.g., PCE) to individual network nodes to program their forwarding. Fo= r example, in a Segment Routed network or for static MPLS-TE LSPs. Put all of this together with the recognition that all TE path management i= s fundamentally the same and can be performed by the same engine, and that = it does not make sense for such an engine to have to implement multiple SBI= protocols, and you end up with this draft. I don't think we are saying that this approach is compulsory, but we are sa= ying that it is possible. Other possibilities exist including using NETCONF= /YANG in place of PCEP, and enhancing BGP in place of PCEP. Others have sug= gested XMPP. Frankly, if we were proposing a new protocol it would be corre= ct to tell us not to, and to persuade us that one of the other protocols wi= ll do the job. But here we are with three (or four) protocols that fit the = bill: each currently covers some of the function space and each could easil= y be extended to cover the whole space. I'm not capable of saying how to de= cide which protocol does which function, but I do see pressures of implemen= tation and deployment that lead to this draft. [Historic note: I was somewhat opposed to adding PCE-Initiated LSP support = to PCEP. I thought this bent the architecture further than was originally i= ntended. But we went there in the PEC WG and the I-D is now "complete". By = adding support of PCE initiation of LSPs, we naturally opened the path to t= his document. FWIW, this is not the first time that PCEP has been discussed= as a more general SBI protocol - RFC 7491 shows it in this context althoug= h does not discuss it much (we should probably add a reference to ABNO in t= his document).] Now, you say you are surprised that "the document focuses on using PCEP e.g= . for L3VPN service delivery." I think there is a significant difference be= tween *requesting* a service and *delivering* that service. The service req= uest (as, for example, in L3SM) does not involve a PCE and is easily achiev= ed using a YANG model which, if the service request is on-line, can be deli= vered using NETCONF. However, service delivery requires "orchestration". Or= chestration is the process of considering available network resources and s= electing what will be provisioned to support the service. A PCE is at least= a key feature of orchestration, just as it is a key component of a network= controller. But the document does NOT focus on PCEP in quite the way you describe. In f= act, the only discussion is in 3.2.3 (just two paragraphs in the whole docu= ment) where the focus is on the use of a PCE-based central controller that = can "consider the whole network and all components of a service at once whe= n planning how to deliver the service." It then goes on to observe that PCE= P can be used "to manage the network resources and to install the necessary= associations between those resources." If we included a message flow chart it would look something like... Service Manager PCE-based Controller NEs Request service---------> Compute Provision ------> <------------- Ack Update DBs <-------------------Ack If that simple figure helps with the understanding of this or any other par= t of the document, we can surely add it. Cheers, Adrian > -----Original Message----- > From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] > Sent: 20 May 2016 19:07 > To: adrian@olddog.co.uk; teas@ietf.org > Subject: RE: [Teas] A New I-D on PCE as a central controller > > As I said, I specifically wonder about Section 3.2.3 "Service Delivery", = which states > (omitting some parts that are not relevant here): > > "Various network services may be offered over a network. These include > protection services [...] Virtual Private Network (VPN) service (such as = Layer 3 > VPNs [RFC4364] or Ethernet VPNs [RFC7432]), or Pseudowires [RFC3985]. [..= .] A > PCE-based central control can consider the whole network and all componen= ts of > a service at once when planning how to deliver the service. It can then u= se PCEP > to manage the network resources and to install the necessary associations > between those resources." > > This wording on use of PCEP confuses me, no matter what interface we talk > about. I would have assumed that YANG-based protocols such as > NETCONF/RESTCONF could be useful in this context, and I am a bit surprise= d that > the document focuses on using PCEP e.g. for L3VPN service delivery. By th= e way, > I also wonder how PCEP fits into the discussion on QoS classification in = Section > 3.2.2. > > I wonder if the authors could add to Section 3.2.2 and Section 3.2.3 e.g.= a > message sequence chart that illustrates how what is discussed in those se= ctions > relates to PCEP? > > Michael > > > > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of EXT Adrian Farrel > Sent: Friday, May 13, 2016 6:54 PM > To: Scharf, Michael (Nokia - DE); teas@ietf.org > Subject: Re: [Teas] A New I-D on PCE as a central controller > > Hello again, Michael, it seems to be my day for replying to your emails. > > > When reading about uses cases such as L3VPN service delivery in > > "Section > 3.2.3", > > what is the author's view on the line of demarcation between NETCONF > > and PCEP? > > Well, I wonder which interface you're talking about. > The ones that out in here are: > - the interface between customer and operator > - the interface between "service orchestrator" and "network orchestrator" > > The former of these is like the interface used in L3SM. As co-chair of L3= SM, you > might not be surprised to hear that my view is that NETCONF is a fine sol= ution - > well, the use of a YANG data model, in any case. > > The latter is the interface between "Orchestrator / Service Manager / OSS= / > NMS" > and "PCE-based Controller" as shown on the various figures in the picture= . We > haven't discussed this interface in the document, and perhaps we should. > > If you look at Figure 6 (with the hierarchy of controllers) you might obs= erve that > the parent controller could be implemented to act as though it is talking= to an NE > (in the abstract node model) and that means that the southbound interface= of > the parent controller would be PCEP. That means (of course) that the > northbound interface of the child controller would also be PCEP. Then, it= might > seem obvious that we would want all PCE implementations to behave the sam= e > way and so that makes the northbound interface of the parent PCE > would/could/should/might also be PCEP. > > What do you think? > > Thanks, > Adrian > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas --_000_655C07320163294895BBADA28372AF5D48862397FR712WXCHMBA15z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Adri= an,

&n= bsp;

Many th= anks for the tutorial. Since RFC 7491 already acknowledges the role of a PC= E, I see little value of a high-level document that talks about PCEP as a g= eneral SBI for the topics mentioned in Section 3.2.2 and Section 3.2.3, if that document does not discuss more sp= ecifically the impact on PCEP, data models, etc.

&n= bsp;

It shou= ld be obvious that in my point of view the wording in Sections 3.2.2 and 3.= 2.3 is not clear. Just repeating the wording once again does not address my= question, since I have obviously read the document and since I know the terminology (albeit I am not a native sp= eaker). A generic flow chart not detailing for which of the messages PCEP w= ould be used, and with what content, also does not address my concern.=

In any = case, if the content of Section 3.2.2 and Section 3.2.3 cannot be made more= explicit, it is impossible for me to understand whether the conclusion in = Section 4 … “As such, no substantial changes to PCEP are required to support the concept of a PCE-based controller. The= only work needed will be small extensions to carry additional or specific = information elements for the individual use cases.” is correct and ho= w it is actually justified for the technical areas such as Section 3.2.2 and Section 3.2.3 .

&n= bsp;

From my= personal experience this sort of entirely generic conclusion could perhaps= be a bit of simplification, but this may depend on the actual use case. Bu= t in an I-D, I believe such a generic conclusion needs backing by content and as far as I understand for Section= 3.2.2 and Section 3.2.3 this backing is lacking in the document right now.

&n= bsp;

Thanks<= o:p>

&n= bsp;

Michael=

&n= bsp;

&n= bsp;

From: Adrian F= arrel [mailto:adrian@olddog.co.uk]
Sent: Sunday, May 22, 2016 6:24 AM
To: Scharf, Michael (Nokia - DE)
Cc: teas@ietf.org
Subject: RE: [Teas] A New I-D on PCE as a central controller

 

Michael, <= /p>

 

I don't think it is complica= ted, but it is obviously not clear from the document, so thank you for rais= ing the concern.

 

You say it doesn't matter wh= ich interface we're talking about, but it does. PCEP is a protocol and prot= ocols are used on interfaces.

 

Let's start with southbound = of the PCE. We already use PCEP on this interface. We have always done. It = is what PCEP was invented for. And recent developments in Stateful PCE and = PCE-Initiated LSPs have made PCEP (and this interface) able to send control "commands" as well as respo= nd to requests. Thus, PCEP is an SBI protocol for use with signaling system= s.

 

Now, we might make several o= bservations...

 

In many (most?) MPLS-TE netw= orks, every router is capable of being the head end of LSPs. That means tha= t in a PCE-enabled MPLS-TE network, every router is a PCEP speaker.

 

Additionally, we can observe= that LSPs (or PWs) can be stitched together. The stitching, if under the c= ontrol of a PCE, requires a special instruction to be sent to the stitching= node.

 

Furthermore, we can understa= nd that a single end-to-end LSP is actually the stitching of lots of single= hop LSPs. That is really what a statically provisioned LSP is.<= /span>

 

Finally, we can see a desire= to send TE instructions from a computation engine (e.g., PCE) to individua= l network nodes to program their forwarding. For example, in a Segment Rout= ed network or for static MPLS-TE LSPs.

 

 

Put all of this together wit= h the recognition that all TE path management is fundamentally the same and= can be performed by the same engine, and that it does not make sense for s= uch an engine to have to implement multiple SBI protocols, and you end up with this draft.

 

I don't think we are saying = that this approach is compulsory, but we are saying that it is possible. Ot= her possibilities exist including using NETCONF/YANG in place of PCEP, and = enhancing BGP in place of PCEP. Others have suggested XMPP. Frankly, if we were proposing a new protocol it would= be correct to tell us not to, and to persuade us that one of the other pro= tocols will do the job. But here we are with three (or four) protocols that= fit the bill: each currently covers some of the function space and each could easily be extended to cover the = whole space. I'm not capable of saying how to decide which protocol does wh= ich function, but I do see pressures of implementation and deployment that = lead to this draft.

 

[Historic note: I was somewh= at opposed to adding PCE-Initiated LSP support to PCEP. I thought this bent= the architecture further than was originally intended. But we went there i= n the PEC WG and the I-D is now "complete". By adding support of PCE initiation of LSPs, we naturally opened the path = to this document. FWIW, this is not the first time that PCEP has been discu= ssed as a more general SBI protocol - RFC 7491 shows it in this context alt= hough does not discuss it much (we should probably add a reference to ABNO in this document).]

 

 

Now, you say you are surpris= ed that "the document focuses on using PCEP e.g. for L3VPN service del= ivery." I think there is a significant difference between *requesting*= a service and *delivering* that service. The service request (as, for example, in L3SM) does not involve a PCE and is e= asily achieved using a YANG model which, if the service request is on-line,= can be delivered using NETCONF. However, service delivery requires "o= rchestration". Orchestration is the process of considering available network resources and selecting what will be prov= isioned to support the service. A PCE is at least a key feature of orchestr= ation, just as it is a key component of a network controller.

 

But the document does NOT fo= cus on PCEP in quite the way you describe. In fact, the only discussion is = in 3.2.3 (just two paragraphs in the whole document) where the focus is on = the use of a PCE-based central controller that can "consider the whole network and all components of a service = at once when planning how to deliver the service." It then goes on to = observe that PCEP can be used "to manage the network resources and to = install the necessary associations between those resources."

 

 

If we included a message flo= w chart it would look something like...

 

Service Manager      PCE-based C= ontroller     NEs

     Request service--------->

         &nb= sp;            =     Compute

         &nb= sp;            =          Provision ------><= /o:p>

         &nb= sp;            =           <------------- Ac= k

         &nb= sp;            =     Update DBs

     <-------------------Ack<= /o:p>

 

If that simple figure helps with the understanding of thi= s or any other part of the document, we can surely add it.

 

Cheers,

Adrian

 

> -----Original Message-----

> From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]<= o:p>

> Sent: 20 May 2016 19:07<= /p>

> To: adrian@olddog.co.uk; teas@ietf.org=

> Subject: RE: [Teas] A New I-D on PCE as a central controller

>

> As I said, I specifical= ly wonder about Section 3.2.3 "Service Delivery", which states

> (omitting some parts th= at are not relevant here):

>

> "Various network s= ervices may be offered over a network. These include

> protection services [..= .] Virtual Private Network (VPN) service (such as Layer 3=

> VPNs [RFC4364] or Ether= net VPNs [RFC7432]), or Pseudowires [RFC3985]. [...]  A

> PCE-based central contr= ol can consider the whole network and all components of

> a service at once when = planning how to deliver the service. It can then use PCEP=

> to manage the network r= esources and to install the necessary associations

> between those resources= ."

>

> This wording on use of = PCEP confuses me, no matter what interface we talk

> about. I would have ass= umed that YANG-based protocols such as

> NETCONF/RESTCONF could = be useful in this context, and I am a bit surprised that<= /p>

> the document focuses on= using PCEP e.g. for L3VPN service delivery. By the way,<= /p>

> I also wonder how PCEP = fits into the discussion on QoS classification in Section=

> 3.2.2.

>

> I wonder if the authors= could add to Section 3.2.2 and Section 3.2.3 e.g. a

> message sequence chart = that illustrates how what is discussed in those sections<= /p>

> relates to PCEP?

>

> Michael

>

>

>

> -----Original Message--= ---

> From: Teas [mailto:teas-bounces@ietf.org] On Behalf O= f EXT Adrian Farrel

> Sent: Friday, May 13, 2= 016 6:54 PM

> To: Scharf, Michael (No= kia - DE); teas@ietf.org

> Subject: Re: [Teas] A N= ew I-D on PCE as a central controller

>

> Hello again, Michael, i= t seems to be my day for replying to your emails.

>

> > When reading about= uses cases such as L3VPN service delivery in

> > "Section=

> 3.2.3",=

> > what is the author= 's view on the line of demarcation between NETCONF

> > and PCEP?

>

> Well, I wonder which in= terface you're talking about.

> The ones that out in he= re are:

> - the interface between= customer and operator

> - the interface between= "service orchestrator" and "network orchestrator"=

>

> The former of these is = like the interface used in L3SM. As co-chair of L3SM, you=

> might not be surprised = to hear that my view is that NETCONF is a fine solution -=

> well, the use of a YANG= data model, in any case.

>

> The latter is the inter= face between "Orchestrator / Service Manager / OSS /=

> NMS"

> and "PCE-based Con= troller" as shown on the various figures in the picture. We=

> haven't discussed this = interface in the document, and perhaps we should.

>

> If you look at Figure 6= (with the hierarchy of controllers) you might observe that

> the parent controller c= ould be implemented to act as though it is talking to an NE

> (in the abstract node m= odel) and that means that the southbound interface of

> the parent controller w= ould be PCEP. That means (of course) that the

> northbound interface of= the child controller would also be PCEP. Then, it might<= /p>

> seem obvious that we wo= uld want all PCE implementations to behave the same

> way and so that makes t= he northbound interface of the parent PCE

> would/could/should/migh= t also be PCEP.

>

> What do you think?=

>

> Thanks,

> Adrian

>

> _______________________= ________________________

> Teas mailing list<= /o:p>

> Teas@ietf.org

> https://www.ietf.org/mailman/listinfo/teas

--_000_655C07320163294895BBADA28372AF5D48862397FR712WXCHMBA15z_-- From nobody Mon May 23 06:18:12 2016 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 30DF412D8BC for ; Mon, 23 May 2016 06:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=kuatrotechnology.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 M6f7A3l1GK6v for ; Mon, 23 May 2016 06:18:09 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0612.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::612]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D606412D8B9 for ; Mon, 23 May 2016 06:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kuatrotechnology.onmicrosoft.com; s=selector1-kuatrotech-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gxKW/OENATlz2LYyh4Qwm72OWNqGipn9z7nRGhGA6bg=; b=GHlhtTSS8rWUpM0LV5GHTY2KH1MbLqBEqY7rCw7mJldqW8B52ZRAA0LQV5NBix3aQFLTdXQX355XcLyzWbhTMsCO9TASfGR6NVPuWZi/tsk08wsQLJvrE9hgTWl3DLcnT3jbT0OAP5mmTIrvgWtqFQ+cX3GMG1DFDHCvy04d/AM= Received: from DBXPR06MB623.eurprd06.prod.outlook.com (10.255.71.170) by DBXPR06MB623.eurprd06.prod.outlook.com (10.255.71.170) with Microsoft SMTP Server (TLS) id 15.1.497.12; Mon, 23 May 2016 13:17:49 +0000 Received: from DBXPR06MB623.eurprd06.prod.outlook.com ([169.254.1.6]) by DBXPR06MB623.eurprd06.prod.outlook.com ([169.254.1.6]) with mapi id 15.01.0497.019; Mon, 23 May 2016 13:17:48 +0000 From: Xufeng Liu To: Xufeng Liu , Vishnu Pavan Beeram , Igor Bryskin , "Oscar Gonzalez De Dios" , Tarek Saad , Himanshu Shah , Lou Berger , "BRUNGARD, DEBORAH A (ATTLABS)" , Susan Hares , "Zafar Ali (zali)" , "Khaddam, Mazen (CCI-Atlanta)" , Tony Le , "BELOTTI, SERGIO (SERGIO)" , "Beller, Dieter (Dieter)" , Rajan Rao , "Zhangxian (Xian)" , "xufeng.liu.ietf@gmail.com" , "Belotti, Sergio (Nokia - IT)" , Anurag Sharma Thread-Topic: IETF TE Topology YANG Model Design Meeting Notes - 2016-05-16 Thread-Index: AdG09O37kGyGYjCeTx2nIR8wOsWPRw== Date: Mon, 23 May 2016 13:17:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: juniper.net; dkim=none (message not signed) header.d=none; juniper.net; dmarc=none action=none header.from=kuatrotech.com; x-originating-ip: [98.191.72.170] x-ms-office365-filtering-correlation-id: 90c8e133-d0fd-4599-29a3-08d3830ca2f4 x-microsoft-exchange-diagnostics: 1; DBXPR06MB623; 5:fGFePfBzYU58YERVfu4XKc9kxrWLJ3hY209pih+7mLg4z6JnLf2z2BTGkv5vAIivaqnvPkG2oMt7YJJB74hfg/iAVinil7xAp/l+AKQbRYNOt0DsvdAAA/IhDsw6sFKsTKQx/yUqpDXUPTJPCvQgzw==; 24:gjeZhz4caS8bbgK/TRXJiW+2VUgPz7Nvf4royTqJmDnug1FRMJ3JyAGPxJoPxwacNXbjogFABmDwE4lohw3xGrzv+6ig8Gbx/IsiNIsmBM4=; 7:g7su6Ud/bqLDnxg9M2EyOWH6klDnU6tXsXb7ShpVx8X3fIGt6X3xVGMTXg/xDLZzZTRSYeT+HXp0Dstf4js8V6dwfebwt9O4uraqi8caIbffGlXixkMQftOGQVIVtsf4KGdy7rBaJ8vvEk0jh4A15FpcEdpqrO5a1wr/+y0uy8TXTnxSt+tcp5Ki5NCZaoiA x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR06MB623; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040130)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041072)(6043046); SRVR:DBXPR06MB623; BCL:0; PCL:0; RULEID:; SRVR:DBXPR06MB623; x-forefront-prvs: 0951AB0A30 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(5423002)(5003600100002)(76576001)(85806002)(50986999)(2906002)(19300405004)(3846002)(790700001)(102836003)(86362001)(8676002)(1220700001)(586003)(87936001)(122556002)(9686002)(3280700002)(5002640100001)(54356999)(81166006)(8936002)(3660700001)(16236675004)(189998001)(5004730100002)(66066001)(2501003)(15975445007)(10400500002)(5008740100001)(5001770100001)(230783001)(92566002)(19580395003)(229853001)(4326007)(19625215002)(2900100001)(74316001)(6116002)(33656002)(7059030)(921003)(1121003); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR06MB623; H:DBXPR06MB623.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DBXPR06MB623B1E31D6EC308EC0DF794B14E0DBXPR06MB623eurprd_" MIME-Version: 1.0 X-OriginatorOrg: kuatrotech.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 May 2016 13:17:48.2696 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 99314f4e-50ab-4d4e-a9c6-b21b0c887384 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR06MB623 Archived-At: Cc: "teas@ietf.org" Subject: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016-05-16 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 13:18:11 -0000 --_000_DBXPR06MB623B1E31D6EC308EC0DF794B14E0DBXPR06MB623eurprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Participants: Igor, Xufeng, Pavan, Sergio, Tarek, - Discussed alignment with i2rs base network-topology model. > Before augmenting i2rs-yang-network-topo, for an access link, we could specify remote te-node-id and remote te-link-id, but we cannot do this after the augmentation, because the key for the link is a URI string. The solution for this issues is to add additional attributes to te-link-attributes when the link is an access link (represented by an open-ended link with one end of the te-link is not specified). - Discussed alignment with i2rs-yang-l3-topology model. > We will actively drive the progress of this draft, by reviewing and revising the model and texts. > We will make sure that the models and descriptions are consistent between i2rs-yang-l3-topology and te-topology - Separating te-topology and l3-te-topology drafts > During IETF95, we received a comment to recommend to move the module ietf-te-topology-psc out of draft-ietf-teas-yang-te-topo, because ietf-te-topology-psc is an augmentation to module ietf-te-topology and is PSC specific. After discussions, we agreed to move ietf-te-topology-psc to the l3-te-topology draft. - Started discussions on SR topology and SR-TE topology model. > Plan to construct the related modules as following: sr-topo augments l3-unicast-igp-topology sr-te-topo augments l3-te-topology Thanks, - Xufeng --_000_DBXPR06MB623B1E31D6EC308EC0DF794B14E0DBXPR06MB623eurprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Participants:

Igor, Xufeng, Pavan, Sergio, Tarek,

 

- Discussed alignment with i2rs base network-topolog= y model.

  > Before augmenting i2rs-yang-network-topo= , for an access link, we

    could specify remote te-node-id a= nd remote te-link-id, but we

    cannot do this after the augmenta= tion, because the key for the

    link is a URI string. The solutio= n for this issues is to add

    additional attributes <remote-= te-node-id, remote-te-tp-id> to

    te-link-attributes when the link = is an access link (represented by

    an open-ended link with one end o= f the te-link is not specified).

 

- Discussed alignment with i2rs-yang-l3-topology mod= el.

  > We will actively drive the progress of t= his draft, by reviewing

    and revising the model and texts.=

  > We will make sure that the models and de= scriptions are consistent

    between i2rs-yang-l3-topology and= te-topology

 

- Separating te-topology and l3-te-topology drafts

  > During IETF95, we received a comment to = recommend to move the module

    ietf-te-topology-psc out of draft= -ietf-teas-yang-te-topo, because

    ietf-te-topology-psc is an augmen= tation to module ietf-te-topology

    and is PSC specific. After discus= sions, we agreed to move

    ietf-te-topology-psc to the l3-te= -topology draft.

 

- Started discussions on SR topology and SR-TE topol= ogy model.

  > Plan to construct the related modules as= following:

    sr-topo augments l3-unicast-igp-t= opology

    sr-te-topo augments l3-te-topolog= y

 

Thanks,

 

- Xufeng

 

--_000_DBXPR06MB623B1E31D6EC308EC0DF794B14E0DBXPR06MB623eurprd_-- From nobody Mon May 23 06:35:42 2016 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 B27F512D8D0 for ; Mon, 23 May 2016 06:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNaNzfea4niy for ; Mon, 23 May 2016 06:35:31 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE04212D0F4 for ; Mon, 23 May 2016 06:35:31 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id b65so133066565oia.1 for ; Mon, 23 May 2016 06:35:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SLnF95I3fjiLbrPJaeYcMa3+QNtFQMQTvebazNHtqgA=; b=GjcyH3aFb+2FBBcdY11CQGg3Jkj2Oat46Hp5pkmueEIFWVjl2+Ev2VuRwLDd4XlP4U bznfERORVWCWWqyCvslluTje/eBmslbyiOFIsu5T2oXqmYA72TKVX0iipniiWKD+xodr nWyopHZrR0WxKVWYoG9WMjFr1yU5BSFa1/rgXrhpeYKanZGlrUEo4KPeS1LlDklTlWAY yDFACITQKJytVtYQRlnnGaLl9JnBNGNO1IzQumw7g5RASvEIm3pmkcklja/Bw4t7QyzT z6DswFjm9IpIC5hsjeuc32lnkzN/5XVPJA3ctydrkEP4z+CTtfFVFjKheZD7dyZWnNSC sXOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SLnF95I3fjiLbrPJaeYcMa3+QNtFQMQTvebazNHtqgA=; b=Bb6VYqLfwf+QfhafHvJYI/haCMxW8Cv+b6GRB03G6555N4gXII5Dk92KwcpYq+zvdh HjHZSMBcRgF+Xys6WDYy0tuBS1yG0KHZ4hLydBUodRiSs5bPJhGOB7r721NESWWxwlQt eL9ippRjtlHwTzLQ+YQrUiDx/t47dUmzjM0Lj8PIgp3f34pdz4dtMUtvz2tMwnQ63HUa x7WeAXZkbkjOvoPUPx8mp+ZihC+nYQ5FAYwW6f4qkEKL3H3BBfWS9Ptw9BvxzWnxz+q6 2lVl15J07yXfD1mTRCkPJcx697aF4PwCUjszihPqsvdmpESpoi9IOjtwn4EcGwimeUb3 ZQdA== X-Gm-Message-State: AOPr4FVRIPYS13j+NEC2ODTmIc7X/G4MYMfXq34/G3x+JxFhSbxYUW//s+Zn6V+iuTUGnEEnhPVl0WsN0fjE5A== X-Received: by 10.157.38.227 with SMTP id i32mr9859811otd.20.1464010530984; Mon, 23 May 2016 06:35:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.231.106 with HTTP; Mon, 23 May 2016 06:35:11 -0700 (PDT) In-Reply-To: <655C07320163294895BBADA28372AF5D48862397@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <0c6c01d1a7a2$f1a24860$d4e6d920$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48846127@FR712WXCHMBA15.zeu.alcatel-lucent.com> <042101d1ad38$12da5f50$388f1df0$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48860ADB@FR712WXCHMBA15.zeu.alcatel-lucent.com> <001d01d1b3e1$bec637d0$3c52a770$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48862397@FR712WXCHMBA15.zeu.alcatel-lucent.com> From: "Andrew G. Malis" Date: Mon, 23 May 2016 09:35:11 -0400 Message-ID: To: "Scharf, Michael (Nokia - DE)" Content-Type: multipart/alternative; boundary=001a113e4a0ca59839053382830d Archived-At: Cc: "adrian@olddog.co.uk" , "teas@ietf.org" Subject: Re: [Teas] A New I-D on PCE as a central controller X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 13:35:40 -0000 --001a113e4a0ca59839053382830d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Michael, I think you=E2=80=99re expecting too much from this draft. It=E2=80=99s mea= nt to be a very high-level informational document to introduce the concepts and a non-exhaustive list of possible applications and use cases. As with any such early document, there=E2=80=99s some amount of speculative writing, an= d there=E2=80=99s no expectation that all of the discussed applications or us= e cases will actually come to fruition, and there may be others in the future that do end up being implemented. But the actual details of protocol changes and applications will be the topics of other standards-track draft(s) to come. Cheers, Andy On Sun, May 22, 2016 at 5:34 PM, Scharf, Michael (Nokia - DE) < michael.scharf@nokia.com> wrote: > Hi Adrian, > > > > Many thanks for the tutorial. Since RFC 7491 already acknowledges the rol= e > of a PCE, I see little value of a high-level document that talks about PC= EP > as a general SBI for the topics mentioned in Section 3.2.2 and Section > 3.2.3, if that document does not discuss more specifically the impact on > PCEP, data models, etc. > > > > It should be obvious that in my point of view the wording in Sections > 3.2.2 and 3.2.3 is not clear. Just repeating the wording once again does > not address my question, since I have obviously read the document and sin= ce > I know the terminology (albeit I am not a native speaker). A generic flow > chart not detailing for which of the messages PCEP would be used, and wit= h > what content, also does not address my concern. > > In any case, if the content of Section 3.2.2 and Section 3.2.3 cannot be > made more explicit, it is impossible for me to understand whether the > conclusion in Section 4 =E2=80=A6 =E2=80=9CAs such, no substantial change= s to PCEP are > required to support the concept of a PCE-based controller. The only work > needed will be small extensions to carry additional or specific informati= on > elements for the individual use cases.=E2=80=9D is correct and how it is = actually > justified for the technical areas such as Section 3.2.2 and Section 3.2.3= . > > > > From my personal experience this sort of entirely generic conclusion coul= d > perhaps be a bit of simplification, but this may depend on the actual use > case. But in an I-D, I believe such a generic conclusion needs backing by > content and as far as I understand for Section 3.2.2 and Section 3.2.3 th= is > backing is lacking in the document right now. > > > > Thanks > > > > Michael > > > > > > *From:* Adrian Farrel [mailto:adrian@olddog.co.uk] > *Sent:* Sunday, May 22, 2016 6:24 AM > *To:* Scharf, Michael (Nokia - DE) > *Cc:* teas@ietf.org > > *Subject:* RE: [Teas] A New I-D on PCE as a central controller > > > > Michael, > > > > I don't think it is complicated, but it is obviously not clear from the > document, so thank you for raising the concern. > > > > You say it doesn't matter which interface we're talking about, but it > does. PCEP is a protocol and protocols are used on interfaces. > > > > Let's start with southbound of the PCE. We already use PCEP on this > interface. We have always done. It is what PCEP was invented for. And > recent developments in Stateful PCE and PCE-Initiated LSPs have made PCEP > (and this interface) able to send control "commands" as well as respond t= o > requests. Thus, PCEP is an SBI protocol for use with signaling systems. > > > > Now, we might make several observations... > > > > In many (most?) MPLS-TE networks, every router is capable of being the > head end of LSPs. That means that in a PCE-enabled MPLS-TE network, every > router is a PCEP speaker. > > > > Additionally, we can observe that LSPs (or PWs) can be stitched together. > The stitching, if under the control of a PCE, requires a special > instruction to be sent to the stitching node. > > > > Furthermore, we can understand that a single end-to-end LSP is actually > the stitching of lots of single hop LSPs. That is really what a staticall= y > provisioned LSP is. > > > > Finally, we can see a desire to send TE instructions from a computation > engine (e.g., PCE) to individual network nodes to program their forwardin= g. > For example, in a Segment Routed network or for static MPLS-TE LSPs. > > > > > > Put all of this together with the recognition that all TE path management > is fundamentally the same and can be performed by the same engine, and th= at > it does not make sense for such an engine to have to implement multiple S= BI > protocols, and you end up with this draft. > > > > I don't think we are saying that this approach is compulsory, but we are > saying that it is possible. Other possibilities exist including using > NETCONF/YANG in place of PCEP, and enhancing BGP in place of PCEP. Others > have suggested XMPP. Frankly, if we were proposing a new protocol it woul= d > be correct to tell us not to, and to persuade us that one of the other > protocols will do the job. But here we are with three (or four) protocols > that fit the bill: each currently covers some of the function space and > each could easily be extended to cover the whole space. I'm not capable o= f > saying how to decide which protocol does which function, but I do see > pressures of implementation and deployment that lead to this draft. > > > > [Historic note: I was somewhat opposed to adding PCE-Initiated LSP suppor= t > to PCEP. I thought this bent the architecture further than was originally > intended. But we went there in the PEC WG and the I-D is now "complete". = By > adding support of PCE initiation of LSPs, we naturally opened the path to > this document. FWIW, this is not the first time that PCEP has been > discussed as a more general SBI protocol - RFC 7491 shows it in this > context although does not discuss it much (we should probably add a > reference to ABNO in this document).] > > > > > > Now, you say you are surprised that "the document focuses on using PCEP > e.g. for L3VPN service delivery." I think there is a significant differen= ce > between *requesting* a service and *delivering* that service. The service > request (as, for example, in L3SM) does not involve a PCE and is easily > achieved using a YANG model which, if the service request is on-line, can > be delivered using NETCONF. However, service delivery requires > "orchestration". Orchestration is the process of considering available > network resources and selecting what will be provisioned to support the > service. A PCE is at least a key feature of orchestration, just as it is = a > key component of a network controller. > > > > But the document does NOT focus on PCEP in quite the way you describe. In > fact, the only discussion is in 3.2.3 (just two paragraphs in the whole > document) where the focus is on the use of a PCE-based central controller > that can "consider the whole network and all components of a service at > once when planning how to deliver the service." It then goes on to observ= e > that PCEP can be used "to manage the network resources and to install the > necessary associations between those resources." > > > > > > If we included a message flow chart it would look something like... > > > > Service Manager PCE-based Controller NEs > > Request service---------> > > Compute > > Provision ------> > > <------------- Ack > > Update DBs > > <-------------------Ack > > > > If that simple figure helps with the understanding of this or any other > part of the document, we can surely add it. > > > > Cheers, > > Adrian > > > > > -----Original Message----- > > > From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com > ] > > > Sent: 20 May 2016 19:07 > > > To: adrian@olddog.co.uk; teas@ietf.org > > > Subject: RE: [Teas] A New I-D on PCE as a central controller > > > > > > As I said, I specifically wonder about Section 3.2.3 "Service Delivery"= , > which states > > > (omitting some parts that are not relevant here): > > > > > > "Various network services may be offered over a network. These include > > > protection services [...] Virtual Private Network (VPN) service (such a= s > Layer 3 > > > VPNs [RFC4364] or Ethernet VPNs [RFC7432]), or Pseudowires [RFC3985]. > [...] A > > > PCE-based central control can consider the whole network and all > components of > > > a service at once when planning how to deliver the service. It can then > use PCEP > > > to manage the network resources and to install the necessary associatio= ns > > > between those resources." > > > > > > This wording on use of PCEP confuses me, no matter what interface we ta= lk > > > about. I would have assumed that YANG-based protocols such as > > > NETCONF/RESTCONF could be useful in this context, and I am a bit > surprised that > > > the document focuses on using PCEP e.g. for L3VPN service delivery. By > the way, > > > I also wonder how PCEP fits into the discussion on QoS classification i= n > Section > > > 3.2.2. > > > > > > I wonder if the authors could add to Section 3.2.2 and Section 3.2.3 > e.g. a > > > message sequence chart that illustrates how what is discussed in those > sections > > > relates to PCEP? > > > > > > Michael > > > > > > > > > > > > -----Original Message----- > > > From: Teas [mailto:teas-bounces@ietf.org ] On > Behalf Of EXT Adrian Farrel > > > Sent: Friday, May 13, 2016 6:54 PM > > > To: Scharf, Michael (Nokia - DE); teas@ietf.org > > > Subject: Re: [Teas] A New I-D on PCE as a central controller > > > > > > Hello again, Michael, it seems to be my day for replying to your emails= . > > > > > > > When reading about uses cases such as L3VPN service delivery in > > > > "Section > > > 3.2.3", > > > > what is the author's view on the line of demarcation between NETCONF > > > > and PCEP? > > > > > > Well, I wonder which interface you're talking about. > > > The ones that out in here are: > > > - the interface between customer and operator > > > - the interface between "service orchestrator" and "network orchestrato= r" > > > > > > The former of these is like the interface used in L3SM. As co-chair of > L3SM, you > > > might not be surprised to hear that my view is that NETCONF is a fine > solution - > > > well, the use of a YANG data model, in any case. > > > > > > The latter is the interface between "Orchestrator / Service Manager / > OSS / > > > NMS" > > > and "PCE-based Controller" as shown on the various figures in the > picture. We > > > haven't discussed this interface in the document, and perhaps we should= . > > > > > > If you look at Figure 6 (with the hierarchy of controllers) you might > observe that > > > the parent controller could be implemented to act as though it is > talking to an NE > > > (in the abstract node model) and that means that the southbound > interface of > > > the parent controller would be PCEP. That means (of course) that the > > > northbound interface of the child controller would also be PCEP. Then, > it might > > > seem obvious that we would want all PCE implementations to behave the > same > > > way and so that makes the northbound interface of the parent PCE > > > would/could/should/might also be PCEP. > > > > > > What do you think? > > > > > > Thanks, > > > Adrian > > > > > > _______________________________________________ > > > Teas mailing list > > > Teas@ietf.org > > > https://www.ietf.org/mailman/listinfo/teas > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > > --001a113e4a0ca59839053382830d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Michael,

I think you=E2=80=99re expecti= ng too much from this draft. It=E2=80=99s meant to be a very high-level inf= ormational document to introduce the concepts and a non-exhaustive list of = possible applications and use cases. As with any such early document, there= =E2=80=99s some amount of speculative writing, and there=E2=80=99s no expec= tation that all of the discussed applications or use cases will actually co= me to fruition, and there may be others in the future that do end up being = implemented. But the actual details of protocol changes and applications wi= ll be the topics of other standards-track draft(s) to come.

<= /div>
Cheers,
Andy


On Sun, May 22, 2016 at 5:34 PM, = Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com> wrote:

Hi Adri= an,

= =C2=A0

Many th= anks for the tutorial. Since RFC 7491 already acknowledges the role of a PC= E, I see little value of a high-level document that talks about PCEP as a g= eneral SBI for the topics mentioned in Section 3.2.2 and Section 3.2.3, if that document does not discuss more sp= ecifically the impact on PCEP, data models, etc.

= =C2=A0

It shou= ld be obvious that in my point of view the wording in Sections 3.2.2 and 3.= 2.3 is not clear. Just repeating the wording once again does not address my= question, since I have obviously read the document and since I know the terminology (albeit I am not a native sp= eaker). A generic flow chart not detailing for which of the messages PCEP w= ould be used, and with what content, also does not address my concern.

=

In any = case, if the content of Section 3.2.2 and Section 3.2.3 cannot be made more= explicit, it is impossible for me to understand whether the conclusion in = Section 4 =E2=80=A6 =E2=80=9CAs such, no substantial changes to PCEP are required to support the concept of a PCE-based controller. The= only work needed will be small extensions to carry additional or specific = information elements for the individual use cases.=E2=80=9D is correct and = how it is actually justified for the technical areas such as Section 3.2.2 and Section 3.2.3 .

= =C2=A0

From my= personal experience this sort of entirely generic conclusion could perhaps= be a bit of simplification, but this may depend on the actual use case. Bu= t in an I-D, I believe such a generic conclusion needs backing by content and as far as I understand for Section= 3.2.2 and Section 3.2.3 this backing is lacking in the document right now.

= =C2=A0

Thanks<= u>

= =C2=A0

Michael=

= =C2=A0

= =C2=A0

From: Adrian F= arrel [mailto:adri= an@olddog.co.uk]
Sent: Sunday, May 22, 2016 6:24 AM
To: Scharf, Michael (Nokia - DE)
Cc: teas@i= etf.org


Subject: RE: [Teas] A New I-D on PCE as a central controller<= u>

=C2=A0

Michael,

=C2=A0

I don't think it is complicated, but it is obvi= ously not clear from the document, so thank you for raising the concern.=

=C2=A0

You say it doesn't matter which interface we= 9;re talking about, but it does. PCEP is a protocol and protocols are used = on interfaces.

=C2=A0

Let's start with southbound of the PCE. We alre= ady use PCEP on this interface. We have always done. It is what PCEP was in= vented for. And recent developments in Stateful PCE and PCE-Initiated LSPs = have made PCEP (and this interface) able to send control "commands" as well as respo= nd to requests. Thus, PCEP is an SBI protocol for use with signaling system= s.

=C2=A0

Now, we might make several observations...

=C2=A0

In many (most?) MPLS-TE networks, every router is c= apable of being the head end of LSPs. That means that in a PCE-enabled MPLS= -TE network, every router is a PCEP speaker.

=C2=A0

Additionally, we can observe that LSPs (or PWs) can= be stitched together. The stitching, if under the control of a PCE, requir= es a special instruction to be sent to the stitching node.

=C2=A0

Furthermore, we can understand that a single end-to= -end LSP is actually the stitching of lots of single hop LSPs. That is real= ly what a statically provisioned LSP is.

=C2=A0

Finally, we can see a desire to send TE instruction= s from a computation engine (e.g., PCE) to individual network nodes to prog= ram their forwarding. For example, in a Segment Routed network or for stati= c MPLS-TE LSPs.

=C2=A0

=C2=A0

Put all of this together with the recognition that = all TE path management is fundamentally the same and can be performed by th= e same engine, and that it does not make sense for such an engine to have t= o implement multiple SBI protocols, and you end up with this draft.

=C2=A0

I don't think we are saying that this approach = is compulsory, but we are saying that it is possible. Other possibilities e= xist including using NETCONF/YANG in place of PCEP, and enhancing BGP in pl= ace of PCEP. Others have suggested XMPP. Frankly, if we were proposing a new protocol it would= be correct to tell us not to, and to persuade us that one of the other pro= tocols will do the job. But here we are with three (or four) protocols that= fit the bill: each currently covers some of the function space and each could easily be extended to cover the = whole space. I'm not capable of saying how to decide which protocol doe= s which function, but I do see pressures of implementation and deployment t= hat lead to this draft.

=C2=A0

[Historic note: I was somewhat opposed to adding PC= E-Initiated LSP support to PCEP. I thought this bent the architecture furth= er than was originally intended. But we went there in the PEC WG and the I-= D is now "complete". By adding support of PCE initiation of LSPs, we naturally opened the path = to this document. FWIW, this is not the first time that PCEP has been discu= ssed as a more general SBI protocol - RFC 7491 shows it in this context alt= hough does not discuss it much (we should probably add a reference to ABNO in this document).]<= /span>

=C2=A0

=C2=A0

Now, you say you are surprised that "the docum= ent focuses on using PCEP e.g. for L3VPN service delivery." I think th= ere is a significant difference between *requesting* a service and *deliver= ing* that service. The service request (as, for example, in L3SM) does not involve a PCE and is e= asily achieved using a YANG model which, if the service request is on-line,= can be delivered using NETCONF. However, service delivery requires "o= rchestration". Orchestration is the process of considering available network resources and selecting what will be prov= isioned to support the service. A PCE is at least a key feature of orchestr= ation, just as it is a key component of a network controller.

=C2=A0

But the document does NOT focus on PCEP in quite th= e way you describe. In fact, the only discussion is in 3.2.3 (just two para= graphs in the whole document) where the focus is on the use of a PCE-based = central controller that can "consider the whole network and all components of a service = at once when planning how to deliver the service." It then goes on to = observe that PCEP can be used "to manage the network resources and to = install the necessary associations between those resources."

=C2=A0

=C2=A0

If we included a message flow chart it would look s= omething like...

=C2=A0

Servi= ce Manager=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 PCE-based Controller=C2=A0=C2=A0= =C2=A0=C2=A0 NEs

=C2= =A0=C2=A0=C2=A0=C2=A0 Request service--------->

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Co= mpute

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Provision ------>

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <------------- Ack

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Up= date DBs

=C2= =A0=C2=A0=C2=A0=C2=A0 <-------------------Ack

=C2=A0

If th= at simple figure helps with the understanding of this or any other part of = the document, we can surely add it.

=C2=A0

Cheer= s,

Adria= n

=C2=A0

> -----Original Mess= age-----

> From: Scharf, Mich= ael (Nokia - DE) [mailto:michael.scharf@nokia.com]

> Sent: 20 May 2016 = 19:07

> To: adrian@olddog.co.uk; teas@ietf.org

> Subject: RE: [Teas= ] A New I-D on PCE as a central controller

>

> As I said, I specifically wonder about Section= 3.2.3 "Service Delivery", which states

> (omitting some parts that are not relevant her= e):

>

> "Various network services may be offered = over a network. These include

> protection services [...] Virtual Private Netw= ork (VPN) service (such as Layer 3

> VPNs [RFC4364] or Ethernet VPNs [RFC7432]), or= Pseudowires [RFC3985]. [...]=C2=A0 A

> PCE-based central control can consider the who= le network and all components of

> a service at once when planning how to deliver= the service. It can then use PCEP

> to manage the network resources and to install= the necessary associations

> between those resources."

>

> This wording on use of PCEP confuses me, no ma= tter what interface we talk

> about. I would have assumed that YANG-based pr= otocols such as

> NETCONF/RESTCONF could be useful in this conte= xt, and I am a bit surprised that

> the document focuses on using PCEP e.g. for L3= VPN service delivery. By the way,

> I also wonder how PCEP fits into the discussio= n on QoS classification in Section

> 3.2.2.

>

> I wonder if the authors could add to Section 3= .2.2 and Section 3.2.3 e.g. a

> message sequence chart that illustrates how wh= at is discussed in those sections

> relates to PCEP?

>

> Michael

>

>

>

> -----Original Message-----

> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of EXT= Adrian Farrel

> Sent: Friday, May 13, 2016 6:54 PM

> To: Scharf, Michael (Nokia - DE); teas@ietf.org

> Subject: Re: [Teas] A New I-D on PCE as a cent= ral controller

>

> Hello again, Michael, it seems to be my day fo= r replying to your emails.

>

> > When reading about uses cases such as L3V= PN service delivery in

> > "Section

> 3.2.3",

> > what is the author's view on the line= of demarcation between NETCONF

> > and PCEP?

>

> Well, I wonder which interface you're talk= ing about.

> The ones that out in here are:

> - the interface between customer and operator<= u>

> - the interface between "service orchestr= ator" and "network orchestrator"

>

> The former of these is like the interface used= in L3SM. As co-chair of L3SM, you

> might not be surprised to hear that my view is= that NETCONF is a fine solution -

> well, the use of a YANG data model, in any cas= e.

>

> The latter is the interface between "Orch= estrator / Service Manager / OSS /

> NMS"

> and "PCE-based Controller" as shown = on the various figures in the picture. We

> haven't discussed this interface in the do= cument, and perhaps we should.

>

> If you look at Figure 6 (with the hierarchy of= controllers) you might observe that

> the parent controller could be implemented to = act as though it is talking to an NE

> (in the abstract node model) and that means th= at the southbound interface of

> the parent controller would be PCEP. That mean= s (of course) that the

> northbound interface of the child controller w= ould also be PCEP. Then, it might

> seem obvious that we would want all PCE implem= entations to behave the same

> way and so that makes the northbound interface= of the parent PCE

> would/could/should/might also be PCEP.<= u>

>

> What do you think?

>

> Thanks,

> Adrian

>

> ______________________________________________= _

> Teas mailing list

> Teas@ietf.org

> https://www.ietf.org/mailman/listinfo/teas


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


--001a113e4a0ca59839053382830d-- From nobody Mon May 23 06:37:42 2016 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 1E43412D8E6 for ; Mon, 23 May 2016 06:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kHhYXwU1NpN for ; Mon, 23 May 2016 06:37:37 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED3EA12D8E3 for ; Mon, 23 May 2016 06:37:36 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id D94D6104F95; Mon, 23 May 2016 13:37:31 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4NDbXCg022211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 May 2016 13:37:34 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u4NDbNbA002059 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 May 2016 15:37:29 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.44]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 23 May 2016 15:37:11 +0200 From: "Scharf, Michael (Nokia - DE)" To: "Andrew G. Malis" Thread-Topic: [Teas] A New I-D on PCE as a central controller Thread-Index: AdGnosEWtnZGzgfkR5SQqz0Nm22cLQEn1m5QADlM4QABYpJEYABH2DeAACYha5AAH2sWgAAEO36g Date: Mon, 23 May 2016 13:37:11 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48862F8B@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <0c6c01d1a7a2$f1a24860$d4e6d920$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48846127@FR712WXCHMBA15.zeu.alcatel-lucent.com> <042101d1ad38$12da5f50$388f1df0$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48860ADB@FR712WXCHMBA15.zeu.alcatel-lucent.com> <001d01d1b3e1$bec637d0$3c52a770$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48862397@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D48862F8BFR712WXCHMBA15z_" MIME-Version: 1.0 Archived-At: Cc: "adrian@olddog.co.uk" , "teas@ietf.org" Subject: Re: [Teas] A New I-D on PCE as a central controller X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 13:37:41 -0000 --_000_655C07320163294895BBADA28372AF5D48862F8BFR712WXCHMBA15z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2h5IGRvZXNu4oCZdCB0aGUgZG9jdW1lbnQgdGhlbiBtZW50aW9uIHRoYXQgdGhlIHVzZSBjYXNl cyBhbmQgY29uY2x1c2lvbnMgb24gUENFUCBhcmUgaHlwb3RoZXRpY2FsPw0KDQpNaWNoYWVsDQoN Cg0KRnJvbTogQW5kcmV3IEcuIE1hbGlzIFttYWlsdG86YWdtYWxpc0BnbWFpbC5jb21dDQpTZW50 OiBNb25kYXksIE1heSAyMywgMjAxNiAzOjM1IFBNDQpUbzogU2NoYXJmLCBNaWNoYWVsIChOb2tp YSAtIERFKQ0KQ2M6IGFkcmlhbkBvbGRkb2cuY28udWs7IHRlYXNAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbVGVhc10gQSBOZXcgSS1EIG9uIFBDRSBhcyBhIGNlbnRyYWwgY29udHJvbGxlcg0KDQpN aWNoYWVsLA0KDQpJIHRoaW5rIHlvdeKAmXJlIGV4cGVjdGluZyB0b28gbXVjaCBmcm9tIHRoaXMg ZHJhZnQuIEl04oCZcyBtZWFudCB0byBiZSBhIHZlcnkgaGlnaC1sZXZlbCBpbmZvcm1hdGlvbmFs IGRvY3VtZW50IHRvIGludHJvZHVjZSB0aGUgY29uY2VwdHMgYW5kIGEgbm9uLWV4aGF1c3RpdmUg bGlzdCBvZiBwb3NzaWJsZSBhcHBsaWNhdGlvbnMgYW5kIHVzZSBjYXNlcy4gQXMgd2l0aCBhbnkg c3VjaCBlYXJseSBkb2N1bWVudCwgdGhlcmXigJlzIHNvbWUgYW1vdW50IG9mIHNwZWN1bGF0aXZl IHdyaXRpbmcsIGFuZCB0aGVyZeKAmXMgbm8gZXhwZWN0YXRpb24gdGhhdCBhbGwgb2YgdGhlIGRp c2N1c3NlZCBhcHBsaWNhdGlvbnMgb3IgdXNlIGNhc2VzIHdpbGwgYWN0dWFsbHkgY29tZSB0byBm cnVpdGlvbiwgYW5kIHRoZXJlIG1heSBiZSBvdGhlcnMgaW4gdGhlIGZ1dHVyZSB0aGF0IGRvIGVu ZCB1cCBiZWluZyBpbXBsZW1lbnRlZC4gQnV0IHRoZSBhY3R1YWwgZGV0YWlscyBvZiBwcm90b2Nv bCBjaGFuZ2VzIGFuZCBhcHBsaWNhdGlvbnMgd2lsbCBiZSB0aGUgdG9waWNzIG9mIG90aGVyIHN0 YW5kYXJkcy10cmFjayBkcmFmdChzKSB0byBjb21lLg0KDQpDaGVlcnMsDQpBbmR5DQoNCg0KT24g U3VuLCBNYXkgMjIsIDIwMTYgYXQgNTozNCBQTSwgU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERF KSA8bWljaGFlbC5zY2hhcmZAbm9raWEuY29tPG1haWx0bzptaWNoYWVsLnNjaGFyZkBub2tpYS5j b20+PiB3cm90ZToNCkhpIEFkcmlhbiwNCg0KTWFueSB0aGFua3MgZm9yIHRoZSB0dXRvcmlhbC4g U2luY2UgUkZDIDc0OTEgYWxyZWFkeSBhY2tub3dsZWRnZXMgdGhlIHJvbGUgb2YgYSBQQ0UsIEkg c2VlIGxpdHRsZSB2YWx1ZSBvZiBhIGhpZ2gtbGV2ZWwgZG9jdW1lbnQgdGhhdCB0YWxrcyBhYm91 dCBQQ0VQIGFzIGEgZ2VuZXJhbCBTQkkgZm9yIHRoZSB0b3BpY3MgbWVudGlvbmVkIGluIFNlY3Rp b24gMy4yLjIgYW5kIFNlY3Rpb24gMy4yLjMsIGlmIHRoYXQgZG9jdW1lbnQgZG9lcyBub3QgZGlz Y3VzcyBtb3JlIHNwZWNpZmljYWxseSB0aGUgaW1wYWN0IG9uIFBDRVAsIGRhdGEgbW9kZWxzLCBl dGMuDQoNCkl0IHNob3VsZCBiZSBvYnZpb3VzIHRoYXQgaW4gbXkgcG9pbnQgb2YgdmlldyB0aGUg d29yZGluZyBpbiBTZWN0aW9ucyAzLjIuMiBhbmQgMy4yLjMgaXMgbm90IGNsZWFyLiBKdXN0IHJl cGVhdGluZyB0aGUgd29yZGluZyBvbmNlIGFnYWluIGRvZXMgbm90IGFkZHJlc3MgbXkgcXVlc3Rp b24sIHNpbmNlIEkgaGF2ZSBvYnZpb3VzbHkgcmVhZCB0aGUgZG9jdW1lbnQgYW5kIHNpbmNlIEkg a25vdyB0aGUgdGVybWlub2xvZ3kgKGFsYmVpdCBJIGFtIG5vdCBhIG5hdGl2ZSBzcGVha2VyKS4g QSBnZW5lcmljIGZsb3cgY2hhcnQgbm90IGRldGFpbGluZyBmb3Igd2hpY2ggb2YgdGhlIG1lc3Nh Z2VzIFBDRVAgd291bGQgYmUgdXNlZCwgYW5kIHdpdGggd2hhdCBjb250ZW50LCBhbHNvIGRvZXMg bm90IGFkZHJlc3MgbXkgY29uY2Vybi4NCkluIGFueSBjYXNlLCBpZiB0aGUgY29udGVudCBvZiBT ZWN0aW9uIDMuMi4yIGFuZCBTZWN0aW9uIDMuMi4zIGNhbm5vdCBiZSBtYWRlIG1vcmUgZXhwbGlj aXQsIGl0IGlzIGltcG9zc2libGUgZm9yIG1lIHRvIHVuZGVyc3RhbmQgd2hldGhlciB0aGUgY29u Y2x1c2lvbiBpbiBTZWN0aW9uIDQg4oCmIOKAnEFzIHN1Y2gsIG5vIHN1YnN0YW50aWFsIGNoYW5n ZXMgdG8gUENFUCBhcmUgcmVxdWlyZWQgdG8gc3VwcG9ydCB0aGUgY29uY2VwdCBvZiBhIFBDRS1i YXNlZCBjb250cm9sbGVyLiBUaGUgb25seSB3b3JrIG5lZWRlZCB3aWxsIGJlIHNtYWxsIGV4dGVu c2lvbnMgdG8gY2FycnkgYWRkaXRpb25hbCBvciBzcGVjaWZpYyBpbmZvcm1hdGlvbiBlbGVtZW50 cyBmb3IgdGhlIGluZGl2aWR1YWwgdXNlIGNhc2VzLuKAnSBpcyBjb3JyZWN0IGFuZCBob3cgaXQg aXMgYWN0dWFsbHkganVzdGlmaWVkIGZvciB0aGUgdGVjaG5pY2FsIGFyZWFzIHN1Y2ggYXMgU2Vj dGlvbiAzLjIuMiBhbmQgU2VjdGlvbiAzLjIuMyAuDQoNCkZyb20gbXkgcGVyc29uYWwgZXhwZXJp ZW5jZSB0aGlzIHNvcnQgb2YgZW50aXJlbHkgZ2VuZXJpYyBjb25jbHVzaW9uIGNvdWxkIHBlcmhh cHMgYmUgYSBiaXQgb2Ygc2ltcGxpZmljYXRpb24sIGJ1dCB0aGlzIG1heSBkZXBlbmQgb24gdGhl IGFjdHVhbCB1c2UgY2FzZS4gQnV0IGluIGFuIEktRCwgSSBiZWxpZXZlIHN1Y2ggYSBnZW5lcmlj IGNvbmNsdXNpb24gbmVlZHMgYmFja2luZyBieSBjb250ZW50IGFuZCBhcyBmYXIgYXMgSSB1bmRl cnN0YW5kIGZvciBTZWN0aW9uIDMuMi4yIGFuZCBTZWN0aW9uIDMuMi4zIHRoaXMgYmFja2luZyBp cyBsYWNraW5nIGluIHRoZSBkb2N1bWVudCByaWdodCBub3cuDQoNClRoYW5rcw0KDQpNaWNoYWVs DQoNCg0KRnJvbTogQWRyaWFuIEZhcnJlbCBbbWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWs8bWFp bHRvOmFkcmlhbkBvbGRkb2cuY28udWs+XQ0KU2VudDogU3VuZGF5LCBNYXkgMjIsIDIwMTYgNjoy NCBBTQ0KVG86IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSkNCkNjOiB0ZWFzQGlldGYub3Jn PG1haWx0bzp0ZWFzQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSRTogW1RlYXNdIEEgTmV3IEktRCBv biBQQ0UgYXMgYSBjZW50cmFsIGNvbnRyb2xsZXINCg0KDQpNaWNoYWVsLA0KDQoNCg0KSSBkb24n dCB0aGluayBpdCBpcyBjb21wbGljYXRlZCwgYnV0IGl0IGlzIG9idmlvdXNseSBub3QgY2xlYXIg ZnJvbSB0aGUgZG9jdW1lbnQsIHNvIHRoYW5rIHlvdSBmb3IgcmFpc2luZyB0aGUgY29uY2Vybi4N Cg0KDQoNCllvdSBzYXkgaXQgZG9lc24ndCBtYXR0ZXIgd2hpY2ggaW50ZXJmYWNlIHdlJ3JlIHRh bGtpbmcgYWJvdXQsIGJ1dCBpdCBkb2VzLiBQQ0VQIGlzIGEgcHJvdG9jb2wgYW5kIHByb3RvY29s cyBhcmUgdXNlZCBvbiBpbnRlcmZhY2VzLg0KDQoNCg0KTGV0J3Mgc3RhcnQgd2l0aCBzb3V0aGJv dW5kIG9mIHRoZSBQQ0UuIFdlIGFscmVhZHkgdXNlIFBDRVAgb24gdGhpcyBpbnRlcmZhY2UuIFdl IGhhdmUgYWx3YXlzIGRvbmUuIEl0IGlzIHdoYXQgUENFUCB3YXMgaW52ZW50ZWQgZm9yLiBBbmQg cmVjZW50IGRldmVsb3BtZW50cyBpbiBTdGF0ZWZ1bCBQQ0UgYW5kIFBDRS1Jbml0aWF0ZWQgTFNQ cyBoYXZlIG1hZGUgUENFUCAoYW5kIHRoaXMgaW50ZXJmYWNlKSBhYmxlIHRvIHNlbmQgY29udHJv bCAiY29tbWFuZHMiIGFzIHdlbGwgYXMgcmVzcG9uZCB0byByZXF1ZXN0cy4gVGh1cywgUENFUCBp cyBhbiBTQkkgcHJvdG9jb2wgZm9yIHVzZSB3aXRoIHNpZ25hbGluZyBzeXN0ZW1zLg0KDQoNCg0K Tm93LCB3ZSBtaWdodCBtYWtlIHNldmVyYWwgb2JzZXJ2YXRpb25zLi4uDQoNCg0KDQpJbiBtYW55 IChtb3N0PykgTVBMUy1URSBuZXR3b3JrcywgZXZlcnkgcm91dGVyIGlzIGNhcGFibGUgb2YgYmVp bmcgdGhlIGhlYWQgZW5kIG9mIExTUHMuIFRoYXQgbWVhbnMgdGhhdCBpbiBhIFBDRS1lbmFibGVk IE1QTFMtVEUgbmV0d29yaywgZXZlcnkgcm91dGVyIGlzIGEgUENFUCBzcGVha2VyLg0KDQoNCg0K QWRkaXRpb25hbGx5LCB3ZSBjYW4gb2JzZXJ2ZSB0aGF0IExTUHMgKG9yIFBXcykgY2FuIGJlIHN0 aXRjaGVkIHRvZ2V0aGVyLiBUaGUgc3RpdGNoaW5nLCBpZiB1bmRlciB0aGUgY29udHJvbCBvZiBh IFBDRSwgcmVxdWlyZXMgYSBzcGVjaWFsIGluc3RydWN0aW9uIHRvIGJlIHNlbnQgdG8gdGhlIHN0 aXRjaGluZyBub2RlLg0KDQoNCg0KRnVydGhlcm1vcmUsIHdlIGNhbiB1bmRlcnN0YW5kIHRoYXQg YSBzaW5nbGUgZW5kLXRvLWVuZCBMU1AgaXMgYWN0dWFsbHkgdGhlIHN0aXRjaGluZyBvZiBsb3Rz IG9mIHNpbmdsZSBob3AgTFNQcy4gVGhhdCBpcyByZWFsbHkgd2hhdCBhIHN0YXRpY2FsbHkgcHJv dmlzaW9uZWQgTFNQIGlzLg0KDQoNCg0KRmluYWxseSwgd2UgY2FuIHNlZSBhIGRlc2lyZSB0byBz ZW5kIFRFIGluc3RydWN0aW9ucyBmcm9tIGEgY29tcHV0YXRpb24gZW5naW5lIChlLmcuLCBQQ0Up IHRvIGluZGl2aWR1YWwgbmV0d29yayBub2RlcyB0byBwcm9ncmFtIHRoZWlyIGZvcndhcmRpbmcu IEZvciBleGFtcGxlLCBpbiBhIFNlZ21lbnQgUm91dGVkIG5ldHdvcmsgb3IgZm9yIHN0YXRpYyBN UExTLVRFIExTUHMuDQoNCg0KDQoNCg0KUHV0IGFsbCBvZiB0aGlzIHRvZ2V0aGVyIHdpdGggdGhl IHJlY29nbml0aW9uIHRoYXQgYWxsIFRFIHBhdGggbWFuYWdlbWVudCBpcyBmdW5kYW1lbnRhbGx5 IHRoZSBzYW1lIGFuZCBjYW4gYmUgcGVyZm9ybWVkIGJ5IHRoZSBzYW1lIGVuZ2luZSwgYW5kIHRo YXQgaXQgZG9lcyBub3QgbWFrZSBzZW5zZSBmb3Igc3VjaCBhbiBlbmdpbmUgdG8gaGF2ZSB0byBp bXBsZW1lbnQgbXVsdGlwbGUgU0JJIHByb3RvY29scywgYW5kIHlvdSBlbmQgdXAgd2l0aCB0aGlz IGRyYWZ0Lg0KDQoNCg0KSSBkb24ndCB0aGluayB3ZSBhcmUgc2F5aW5nIHRoYXQgdGhpcyBhcHBy b2FjaCBpcyBjb21wdWxzb3J5LCBidXQgd2UgYXJlIHNheWluZyB0aGF0IGl0IGlzIHBvc3NpYmxl LiBPdGhlciBwb3NzaWJpbGl0aWVzIGV4aXN0IGluY2x1ZGluZyB1c2luZyBORVRDT05GL1lBTkcg aW4gcGxhY2Ugb2YgUENFUCwgYW5kIGVuaGFuY2luZyBCR1AgaW4gcGxhY2Ugb2YgUENFUC4gT3Ro ZXJzIGhhdmUgc3VnZ2VzdGVkIFhNUFAuIEZyYW5rbHksIGlmIHdlIHdlcmUgcHJvcG9zaW5nIGEg bmV3IHByb3RvY29sIGl0IHdvdWxkIGJlIGNvcnJlY3QgdG8gdGVsbCB1cyBub3QgdG8sIGFuZCB0 byBwZXJzdWFkZSB1cyB0aGF0IG9uZSBvZiB0aGUgb3RoZXIgcHJvdG9jb2xzIHdpbGwgZG8gdGhl IGpvYi4gQnV0IGhlcmUgd2UgYXJlIHdpdGggdGhyZWUgKG9yIGZvdXIpIHByb3RvY29scyB0aGF0 IGZpdCB0aGUgYmlsbDogZWFjaCBjdXJyZW50bHkgY292ZXJzIHNvbWUgb2YgdGhlIGZ1bmN0aW9u IHNwYWNlIGFuZCBlYWNoIGNvdWxkIGVhc2lseSBiZSBleHRlbmRlZCB0byBjb3ZlciB0aGUgd2hv bGUgc3BhY2UuIEknbSBub3QgY2FwYWJsZSBvZiBzYXlpbmcgaG93IHRvIGRlY2lkZSB3aGljaCBw cm90b2NvbCBkb2VzIHdoaWNoIGZ1bmN0aW9uLCBidXQgSSBkbyBzZWUgcHJlc3N1cmVzIG9mIGlt cGxlbWVudGF0aW9uIGFuZCBkZXBsb3ltZW50IHRoYXQgbGVhZCB0byB0aGlzIGRyYWZ0Lg0KDQoN Cg0KW0hpc3RvcmljIG5vdGU6IEkgd2FzIHNvbWV3aGF0IG9wcG9zZWQgdG8gYWRkaW5nIFBDRS1J bml0aWF0ZWQgTFNQIHN1cHBvcnQgdG8gUENFUC4gSSB0aG91Z2h0IHRoaXMgYmVudCB0aGUgYXJj aGl0ZWN0dXJlIGZ1cnRoZXIgdGhhbiB3YXMgb3JpZ2luYWxseSBpbnRlbmRlZC4gQnV0IHdlIHdl bnQgdGhlcmUgaW4gdGhlIFBFQyBXRyBhbmQgdGhlIEktRCBpcyBub3cgImNvbXBsZXRlIi4gQnkg YWRkaW5nIHN1cHBvcnQgb2YgUENFIGluaXRpYXRpb24gb2YgTFNQcywgd2UgbmF0dXJhbGx5IG9w ZW5lZCB0aGUgcGF0aCB0byB0aGlzIGRvY3VtZW50LiBGV0lXLCB0aGlzIGlzIG5vdCB0aGUgZmly c3QgdGltZSB0aGF0IFBDRVAgaGFzIGJlZW4gZGlzY3Vzc2VkIGFzIGEgbW9yZSBnZW5lcmFsIFNC SSBwcm90b2NvbCAtIFJGQyA3NDkxIHNob3dzIGl0IGluIHRoaXMgY29udGV4dCBhbHRob3VnaCBk b2VzIG5vdCBkaXNjdXNzIGl0IG11Y2ggKHdlIHNob3VsZCBwcm9iYWJseSBhZGQgYSByZWZlcmVu Y2UgdG8gQUJOTyBpbiB0aGlzIGRvY3VtZW50KS5dDQoNCg0KDQoNCg0KTm93LCB5b3Ugc2F5IHlv dSBhcmUgc3VycHJpc2VkIHRoYXQgInRoZSBkb2N1bWVudCBmb2N1c2VzIG9uIHVzaW5nIFBDRVAg ZS5nLiBmb3IgTDNWUE4gc2VydmljZSBkZWxpdmVyeS4iIEkgdGhpbmsgdGhlcmUgaXMgYSBzaWdu aWZpY2FudCBkaWZmZXJlbmNlIGJldHdlZW4gKnJlcXVlc3RpbmcqIGEgc2VydmljZSBhbmQgKmRl bGl2ZXJpbmcqIHRoYXQgc2VydmljZS4gVGhlIHNlcnZpY2UgcmVxdWVzdCAoYXMsIGZvciBleGFt cGxlLCBpbiBMM1NNKSBkb2VzIG5vdCBpbnZvbHZlIGEgUENFIGFuZCBpcyBlYXNpbHkgYWNoaWV2 ZWQgdXNpbmcgYSBZQU5HIG1vZGVsIHdoaWNoLCBpZiB0aGUgc2VydmljZSByZXF1ZXN0IGlzIG9u LWxpbmUsIGNhbiBiZSBkZWxpdmVyZWQgdXNpbmcgTkVUQ09ORi4gSG93ZXZlciwgc2VydmljZSBk ZWxpdmVyeSByZXF1aXJlcyAib3JjaGVzdHJhdGlvbiIuIE9yY2hlc3RyYXRpb24gaXMgdGhlIHBy b2Nlc3Mgb2YgY29uc2lkZXJpbmcgYXZhaWxhYmxlIG5ldHdvcmsgcmVzb3VyY2VzIGFuZCBzZWxl Y3Rpbmcgd2hhdCB3aWxsIGJlIHByb3Zpc2lvbmVkIHRvIHN1cHBvcnQgdGhlIHNlcnZpY2UuIEEg UENFIGlzIGF0IGxlYXN0IGEga2V5IGZlYXR1cmUgb2Ygb3JjaGVzdHJhdGlvbiwganVzdCBhcyBp dCBpcyBhIGtleSBjb21wb25lbnQgb2YgYSBuZXR3b3JrIGNvbnRyb2xsZXIuDQoNCg0KDQpCdXQg dGhlIGRvY3VtZW50IGRvZXMgTk9UIGZvY3VzIG9uIFBDRVAgaW4gcXVpdGUgdGhlIHdheSB5b3Ug ZGVzY3JpYmUuIEluIGZhY3QsIHRoZSBvbmx5IGRpc2N1c3Npb24gaXMgaW4gMy4yLjMgKGp1c3Qg dHdvIHBhcmFncmFwaHMgaW4gdGhlIHdob2xlIGRvY3VtZW50KSB3aGVyZSB0aGUgZm9jdXMgaXMg b24gdGhlIHVzZSBvZiBhIFBDRS1iYXNlZCBjZW50cmFsIGNvbnRyb2xsZXIgdGhhdCBjYW4gImNv bnNpZGVyIHRoZSB3aG9sZSBuZXR3b3JrIGFuZCBhbGwgY29tcG9uZW50cyBvZiBhIHNlcnZpY2Ug YXQgb25jZSB3aGVuIHBsYW5uaW5nIGhvdyB0byBkZWxpdmVyIHRoZSBzZXJ2aWNlLiIgSXQgdGhl biBnb2VzIG9uIHRvIG9ic2VydmUgdGhhdCBQQ0VQIGNhbiBiZSB1c2VkICJ0byBtYW5hZ2UgdGhl IG5ldHdvcmsgcmVzb3VyY2VzIGFuZCB0byBpbnN0YWxsIHRoZSBuZWNlc3NhcnkgYXNzb2NpYXRp b25zIGJldHdlZW4gdGhvc2UgcmVzb3VyY2VzLiINCg0KDQoNCg0KDQpJZiB3ZSBpbmNsdWRlZCBh IG1lc3NhZ2UgZmxvdyBjaGFydCBpdCB3b3VsZCBsb29rIHNvbWV0aGluZyBsaWtlLi4uDQoNCg0K DQpTZXJ2aWNlIE1hbmFnZXIgICAgICBQQ0UtYmFzZWQgQ29udHJvbGxlciAgICAgTkVzDQoNCiAg ICAgUmVxdWVzdCBzZXJ2aWNlLS0tLS0tLS0tPg0KDQogICAgICAgICAgICAgICAgICAgICAgICAg IENvbXB1dGUNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFByb3Zpc2lvbiAtLS0t LS0+DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC0tLS0tLS0tLS0tLS0gQWNr DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgVXBkYXRlIERCcw0KDQogICAgIDwtLS0tLS0t LS0tLS0tLS0tLS0tQWNrDQoNCg0KDQpJZiB0aGF0IHNpbXBsZSBmaWd1cmUgaGVscHMgd2l0aCB0 aGUgdW5kZXJzdGFuZGluZyBvZiB0aGlzIG9yIGFueSBvdGhlciBwYXJ0IG9mIHRoZSBkb2N1bWVu dCwgd2UgY2FuIHN1cmVseSBhZGQgaXQuDQoNCg0KDQpDaGVlcnMsDQoNCkFkcmlhbg0KDQoNCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQo+IEZyb206IFNjaGFyZiwgTWljaGFlbCAo Tm9raWEgLSBERSkgW21haWx0bzptaWNoYWVsLnNjaGFyZkBub2tpYS5jb21dDQoNCj4gU2VudDog MjAgTWF5IDIwMTYgMTk6MDcNCg0KPiBUbzogYWRyaWFuQG9sZGRvZy5jby51azxtYWlsdG86YWRy aWFuQG9sZGRvZy5jby51az47IHRlYXNAaWV0Zi5vcmc8bWFpbHRvOnRlYXNAaWV0Zi5vcmc+DQoN Cj4gU3ViamVjdDogUkU6IFtUZWFzXSBBIE5ldyBJLUQgb24gUENFIGFzIGEgY2VudHJhbCBjb250 cm9sbGVyDQoNCj4NCg0KPiBBcyBJIHNhaWQsIEkgc3BlY2lmaWNhbGx5IHdvbmRlciBhYm91dCBT ZWN0aW9uIDMuMi4zICJTZXJ2aWNlIERlbGl2ZXJ5Iiwgd2hpY2ggc3RhdGVzDQoNCj4gKG9taXR0 aW5nIHNvbWUgcGFydHMgdGhhdCBhcmUgbm90IHJlbGV2YW50IGhlcmUpOg0KDQo+DQoNCj4gIlZh cmlvdXMgbmV0d29yayBzZXJ2aWNlcyBtYXkgYmUgb2ZmZXJlZCBvdmVyIGEgbmV0d29yay4gVGhl c2UgaW5jbHVkZQ0KDQo+IHByb3RlY3Rpb24gc2VydmljZXMgWy4uLl0gVmlydHVhbCBQcml2YXRl IE5ldHdvcmsgKFZQTikgc2VydmljZSAoc3VjaCBhcyBMYXllciAzDQoNCj4gVlBOcyBbUkZDNDM2 NF0gb3IgRXRoZXJuZXQgVlBOcyBbUkZDNzQzMl0pLCBvciBQc2V1ZG93aXJlcyBbUkZDMzk4NV0u IFsuLi5dICBBDQoNCj4gUENFLWJhc2VkIGNlbnRyYWwgY29udHJvbCBjYW4gY29uc2lkZXIgdGhl IHdob2xlIG5ldHdvcmsgYW5kIGFsbCBjb21wb25lbnRzIG9mDQoNCj4gYSBzZXJ2aWNlIGF0IG9u Y2Ugd2hlbiBwbGFubmluZyBob3cgdG8gZGVsaXZlciB0aGUgc2VydmljZS4gSXQgY2FuIHRoZW4g dXNlIFBDRVANCg0KPiB0byBtYW5hZ2UgdGhlIG5ldHdvcmsgcmVzb3VyY2VzIGFuZCB0byBpbnN0 YWxsIHRoZSBuZWNlc3NhcnkgYXNzb2NpYXRpb25zDQoNCj4gYmV0d2VlbiB0aG9zZSByZXNvdXJj ZXMuIg0KDQo+DQoNCj4gVGhpcyB3b3JkaW5nIG9uIHVzZSBvZiBQQ0VQIGNvbmZ1c2VzIG1lLCBu byBtYXR0ZXIgd2hhdCBpbnRlcmZhY2Ugd2UgdGFsaw0KDQo+IGFib3V0LiBJIHdvdWxkIGhhdmUg YXNzdW1lZCB0aGF0IFlBTkctYmFzZWQgcHJvdG9jb2xzIHN1Y2ggYXMNCg0KPiBORVRDT05GL1JF U1RDT05GIGNvdWxkIGJlIHVzZWZ1bCBpbiB0aGlzIGNvbnRleHQsIGFuZCBJIGFtIGEgYml0IHN1 cnByaXNlZCB0aGF0DQoNCj4gdGhlIGRvY3VtZW50IGZvY3VzZXMgb24gdXNpbmcgUENFUCBlLmcu IGZvciBMM1ZQTiBzZXJ2aWNlIGRlbGl2ZXJ5LiBCeSB0aGUgd2F5LA0KDQo+IEkgYWxzbyB3b25k ZXIgaG93IFBDRVAgZml0cyBpbnRvIHRoZSBkaXNjdXNzaW9uIG9uIFFvUyBjbGFzc2lmaWNhdGlv biBpbiBTZWN0aW9uDQoNCj4gMy4yLjIuDQoNCj4NCg0KPiBJIHdvbmRlciBpZiB0aGUgYXV0aG9y cyBjb3VsZCBhZGQgdG8gU2VjdGlvbiAzLjIuMiBhbmQgU2VjdGlvbiAzLjIuMyBlLmcuIGENCg0K PiBtZXNzYWdlIHNlcXVlbmNlIGNoYXJ0IHRoYXQgaWxsdXN0cmF0ZXMgaG93IHdoYXQgaXMgZGlz Y3Vzc2VkIGluIHRob3NlIHNlY3Rpb25zDQoNCj4gcmVsYXRlcyB0byBQQ0VQPw0KDQo+DQoNCj4g TWljaGFlbA0KDQo+DQoNCj4NCg0KPg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoN Cj4gRnJvbTogVGVhcyBbbWFpbHRvOnRlYXMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEVYVCBBZHJpYW4gRmFycmVsDQoNCj4gU2VudDogRnJpZGF5LCBNYXkgMTMsIDIwMTYgNjo1NCBQ TQ0KDQo+IFRvOiBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUpOyB0ZWFzQGlldGYub3JnPG1h aWx0bzp0ZWFzQGlldGYub3JnPg0KDQo+IFN1YmplY3Q6IFJlOiBbVGVhc10gQSBOZXcgSS1EIG9u IFBDRSBhcyBhIGNlbnRyYWwgY29udHJvbGxlcg0KDQo+DQoNCj4gSGVsbG8gYWdhaW4sIE1pY2hh ZWwsIGl0IHNlZW1zIHRvIGJlIG15IGRheSBmb3IgcmVwbHlpbmcgdG8geW91ciBlbWFpbHMuDQoN Cj4NCg0KPiA+IFdoZW4gcmVhZGluZyBhYm91dCB1c2VzIGNhc2VzIHN1Y2ggYXMgTDNWUE4gc2Vy dmljZSBkZWxpdmVyeSBpbg0KDQo+ID4gIlNlY3Rpb24NCg0KPiAzLjIuMyIsDQoNCj4gPiB3aGF0 IGlzIHRoZSBhdXRob3IncyB2aWV3IG9uIHRoZSBsaW5lIG9mIGRlbWFyY2F0aW9uIGJldHdlZW4g TkVUQ09ORg0KDQo+ID4gYW5kIFBDRVA/DQoNCj4NCg0KPiBXZWxsLCBJIHdvbmRlciB3aGljaCBp bnRlcmZhY2UgeW91J3JlIHRhbGtpbmcgYWJvdXQuDQoNCj4gVGhlIG9uZXMgdGhhdCBvdXQgaW4g aGVyZSBhcmU6DQoNCj4gLSB0aGUgaW50ZXJmYWNlIGJldHdlZW4gY3VzdG9tZXIgYW5kIG9wZXJh dG9yDQoNCj4gLSB0aGUgaW50ZXJmYWNlIGJldHdlZW4gInNlcnZpY2Ugb3JjaGVzdHJhdG9yIiBh bmQgIm5ldHdvcmsgb3JjaGVzdHJhdG9yIg0KDQo+DQoNCj4gVGhlIGZvcm1lciBvZiB0aGVzZSBp cyBsaWtlIHRoZSBpbnRlcmZhY2UgdXNlZCBpbiBMM1NNLiBBcyBjby1jaGFpciBvZiBMM1NNLCB5 b3UNCg0KPiBtaWdodCBub3QgYmUgc3VycHJpc2VkIHRvIGhlYXIgdGhhdCBteSB2aWV3IGlzIHRo YXQgTkVUQ09ORiBpcyBhIGZpbmUgc29sdXRpb24gLQ0KDQo+IHdlbGwsIHRoZSB1c2Ugb2YgYSBZ QU5HIGRhdGEgbW9kZWwsIGluIGFueSBjYXNlLg0KDQo+DQoNCj4gVGhlIGxhdHRlciBpcyB0aGUg aW50ZXJmYWNlIGJldHdlZW4gIk9yY2hlc3RyYXRvciAvIFNlcnZpY2UgTWFuYWdlciAvIE9TUyAv DQoNCj4gTk1TIg0KDQo+IGFuZCAiUENFLWJhc2VkIENvbnRyb2xsZXIiIGFzIHNob3duIG9uIHRo ZSB2YXJpb3VzIGZpZ3VyZXMgaW4gdGhlIHBpY3R1cmUuIFdlDQoNCj4gaGF2ZW4ndCBkaXNjdXNz ZWQgdGhpcyBpbnRlcmZhY2UgaW4gdGhlIGRvY3VtZW50LCBhbmQgcGVyaGFwcyB3ZSBzaG91bGQu DQoNCj4NCg0KPiBJZiB5b3UgbG9vayBhdCBGaWd1cmUgNiAod2l0aCB0aGUgaGllcmFyY2h5IG9m IGNvbnRyb2xsZXJzKSB5b3UgbWlnaHQgb2JzZXJ2ZSB0aGF0DQoNCj4gdGhlIHBhcmVudCBjb250 cm9sbGVyIGNvdWxkIGJlIGltcGxlbWVudGVkIHRvIGFjdCBhcyB0aG91Z2ggaXQgaXMgdGFsa2lu ZyB0byBhbiBORQ0KDQo+IChpbiB0aGUgYWJzdHJhY3Qgbm9kZSBtb2RlbCkgYW5kIHRoYXQgbWVh bnMgdGhhdCB0aGUgc291dGhib3VuZCBpbnRlcmZhY2Ugb2YNCg0KPiB0aGUgcGFyZW50IGNvbnRy b2xsZXIgd291bGQgYmUgUENFUC4gVGhhdCBtZWFucyAob2YgY291cnNlKSB0aGF0IHRoZQ0KDQo+ IG5vcnRoYm91bmQgaW50ZXJmYWNlIG9mIHRoZSBjaGlsZCBjb250cm9sbGVyIHdvdWxkIGFsc28g YmUgUENFUC4gVGhlbiwgaXQgbWlnaHQNCg0KPiBzZWVtIG9idmlvdXMgdGhhdCB3ZSB3b3VsZCB3 YW50IGFsbCBQQ0UgaW1wbGVtZW50YXRpb25zIHRvIGJlaGF2ZSB0aGUgc2FtZQ0KDQo+IHdheSBh bmQgc28gdGhhdCBtYWtlcyB0aGUgbm9ydGhib3VuZCBpbnRlcmZhY2Ugb2YgdGhlIHBhcmVudCBQ Q0UNCg0KPiB3b3VsZC9jb3VsZC9zaG91bGQvbWlnaHQgYWxzbyBiZSBQQ0VQLg0KDQo+DQoNCj4g V2hhdCBkbyB5b3UgdGhpbms/DQoNCj4NCg0KPiBUaGFua3MsDQoNCj4gQWRyaWFuDQoNCj4NCg0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQo+IFRl YXMgbWFpbGluZyBsaXN0DQoNCj4gVGVhc0BpZXRmLm9yZzxtYWlsdG86VGVhc0BpZXRmLm9yZz4N Cg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RlYXMNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRlYXMgbWFpbGluZyBs aXN0DQpUZWFzQGlldGYub3JnPG1haWx0bzpUZWFzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90ZWFzDQoNCg== --_000_655C07320163294895BBADA28372AF5D48862F8BFR712WXCHMBA15z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENo YXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4 LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+V2h5IGRvZXNu4oCZdCB0aGUgZG9jdW1lbnQgdGhlbiBtZW50aW9uIHRoYXQgdGhl IHVzZSBjYXNlcyBhbmQgY29uY2x1c2lvbnMgb24gUENFUCBhcmUgaHlwb3RoZXRpY2FsPzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+TWljaGFlbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IEFuZHJldyBHLiBNYWxpcyBbbWFpbHRvOmFnbWFsaXNAZ21haWwuY29tXQ0KPGJyPg0K PGI+U2VudDo8L2I+IE1vbmRheSwgTWF5IDIzLCAyMDE2IDM6MzUgUE08YnI+DQo8Yj5Ubzo8L2I+ IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSk8YnI+DQo8Yj5DYzo8L2I+IGFkcmlhbkBvbGRk b2cuY28udWs7IHRlYXNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtUZWFzXSBB IE5ldyBJLUQgb24gUENFIGFzIGEgY2VudHJhbCBjb250cm9sbGVyPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NaWNoYWVsLDxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB5b3XigJlyZSBleHBlY3RpbmcgdG9v IG11Y2ggZnJvbSB0aGlzIGRyYWZ0LiBJdOKAmXMgbWVhbnQgdG8gYmUgYSB2ZXJ5IGhpZ2gtbGV2 ZWwgaW5mb3JtYXRpb25hbCBkb2N1bWVudCB0byBpbnRyb2R1Y2UgdGhlIGNvbmNlcHRzIGFuZCBh IG5vbi1leGhhdXN0aXZlIGxpc3Qgb2YgcG9zc2libGUgYXBwbGljYXRpb25zIGFuZCB1c2UgY2Fz ZXMuIEFzIHdpdGggYW55IHN1Y2ggZWFybHkgZG9jdW1lbnQsIHRoZXJl4oCZcw0KIHNvbWUgYW1v dW50IG9mIHNwZWN1bGF0aXZlIHdyaXRpbmcsIGFuZCB0aGVyZeKAmXMgbm8gZXhwZWN0YXRpb24g dGhhdCBhbGwgb2YgdGhlIGRpc2N1c3NlZCBhcHBsaWNhdGlvbnMgb3IgdXNlIGNhc2VzIHdpbGwg YWN0dWFsbHkgY29tZSB0byBmcnVpdGlvbiwgYW5kIHRoZXJlIG1heSBiZSBvdGhlcnMgaW4gdGhl IGZ1dHVyZSB0aGF0IGRvIGVuZCB1cCBiZWluZyBpbXBsZW1lbnRlZC4gQnV0IHRoZSBhY3R1YWwg ZGV0YWlscyBvZiBwcm90b2NvbCBjaGFuZ2VzDQogYW5kIGFwcGxpY2F0aW9ucyB3aWxsIGJlIHRo ZSB0b3BpY3Mgb2Ygb3RoZXIgc3RhbmRhcmRzLXRyYWNrIGRyYWZ0KHMpIHRvIGNvbWUuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycyw8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBTdW4sIE1heSAyMiwgMjAxNiBhdCA1OjM0IFBNLCBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0g REUpICZsdDs8YSBocmVmPSJtYWlsdG86bWljaGFlbC5zY2hhcmZAbm9raWEuY29tIiB0YXJnZXQ9 Il9ibGFuayI+bWljaGFlbC5zY2hhcmZAbm9raWEuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPkhpIEFkcmlhbiw8L3NwYW4+PHNwYW4gbGFuZz0iREUiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ TWFueSB0aGFua3MgZm9yIHRoZSB0dXRvcmlhbC4gU2luY2UgUkZDIDc0OTEgYWxyZWFkeSBhY2tu b3dsZWRnZXMgdGhlIHJvbGUgb2YgYSBQQ0UsIEkgc2VlIGxpdHRsZSB2YWx1ZSBvZiBhIGhpZ2gt bGV2ZWwgZG9jdW1lbnQgdGhhdCB0YWxrcyBhYm91dCBQQ0VQDQogYXMgYSBnZW5lcmFsIFNCSSBm b3IgdGhlIHRvcGljcyBtZW50aW9uZWQgaW4gU2VjdGlvbiAzLjIuMiBhbmQgU2VjdGlvbiAzLjIu MywgaWYgdGhhdCBkb2N1bWVudCBkb2VzIG5vdCBkaXNjdXNzIG1vcmUgc3BlY2lmaWNhbGx5IHRo ZSBpbXBhY3Qgb24gUENFUCwgZGF0YSBtb2RlbHMsIGV0Yy48L3NwYW4+PHNwYW4gbGFuZz0iREUi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJERSI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+SXQgc2hvdWxkIGJlIG9idmlvdXMgdGhhdCBpbiBteSBwb2ludCBvZiB2aWV3IHRo ZSB3b3JkaW5nIGluIFNlY3Rpb25zIDMuMi4yIGFuZCAzLjIuMyBpcyBub3QgY2xlYXIuIEp1c3Qg cmVwZWF0aW5nIHRoZSB3b3JkaW5nIG9uY2UgYWdhaW4gZG9lcyBub3QgYWRkcmVzcw0KIG15IHF1 ZXN0aW9uLCBzaW5jZSBJIGhhdmUgb2J2aW91c2x5IHJlYWQgdGhlIGRvY3VtZW50IGFuZCBzaW5j ZSBJIGtub3cgdGhlIHRlcm1pbm9sb2d5IChhbGJlaXQgSSBhbSBub3QgYSBuYXRpdmUgc3BlYWtl cikuIEEgZ2VuZXJpYyBmbG93IGNoYXJ0IG5vdCBkZXRhaWxpbmcgZm9yIHdoaWNoIG9mIHRoZSBt ZXNzYWdlcyBQQ0VQIHdvdWxkIGJlIHVzZWQsIGFuZCB3aXRoIHdoYXQgY29udGVudCwgYWxzbyBk b2VzIG5vdCBhZGRyZXNzIG15IGNvbmNlcm4uPC9zcGFuPjxzcGFuIGxhbmc9IkRFIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj5JbiBhbnkgY2FzZSwgaWYgdGhlIGNvbnRlbnQgb2YgU2VjdGlvbiAzLjIuMiBh bmQgU2VjdGlvbiAzLjIuMyBjYW5ub3QgYmUgbWFkZSBtb3JlIGV4cGxpY2l0LCBpdCBpcyBpbXBv c3NpYmxlIGZvciBtZSB0byB1bmRlcnN0YW5kIHdoZXRoZXIgdGhlIGNvbmNsdXNpb24NCiBpbiBT ZWN0aW9uIDQg4oCmIOKAnEFzIHN1Y2gsIG5vIHN1YnN0YW50aWFsIGNoYW5nZXMgdG8gUENFUCBh cmUgcmVxdWlyZWQgdG8gc3VwcG9ydCB0aGUgY29uY2VwdCBvZiBhIFBDRS1iYXNlZCBjb250cm9s bGVyLiBUaGUgb25seSB3b3JrIG5lZWRlZCB3aWxsIGJlIHNtYWxsIGV4dGVuc2lvbnMgdG8gY2Fy cnkgYWRkaXRpb25hbCBvciBzcGVjaWZpYyBpbmZvcm1hdGlvbiBlbGVtZW50cyBmb3IgdGhlIGlu ZGl2aWR1YWwgdXNlIGNhc2VzLuKAnSBpcyBjb3JyZWN0DQogYW5kIGhvdyBpdCBpcyBhY3R1YWxs eSBqdXN0aWZpZWQgZm9yIHRoZSB0ZWNobmljYWwgYXJlYXMgc3VjaCBhcyBTZWN0aW9uIDMuMi4y IGFuZCBTZWN0aW9uIDMuMi4zIC48L3NwYW4+PHNwYW4gbGFuZz0iREUiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+RnJvbSBt eSBwZXJzb25hbCBleHBlcmllbmNlIHRoaXMgc29ydCBvZiBlbnRpcmVseSBnZW5lcmljIGNvbmNs dXNpb24gY291bGQgcGVyaGFwcyBiZSBhIGJpdCBvZiBzaW1wbGlmaWNhdGlvbiwgYnV0IHRoaXMg bWF5IGRlcGVuZCBvbiB0aGUgYWN0dWFsIHVzZQ0KIGNhc2UuIEJ1dCBpbiBhbiBJLUQsIEkgYmVs aWV2ZSBzdWNoIGEgZ2VuZXJpYyBjb25jbHVzaW9uIG5lZWRzIGJhY2tpbmcgYnkgY29udGVudCBh bmQgYXMgZmFyIGFzIEkgdW5kZXJzdGFuZCBmb3IgU2VjdGlvbiAzLjIuMiBhbmQgU2VjdGlvbiAz LjIuMyB0aGlzIGJhY2tpbmcgaXMgbGFja2luZyBpbiB0aGUgZG9jdW1lbnQgcmlnaHQgbm93Lg0K PC9zcGFuPjxzcGFuIGxhbmc9IkRFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iREUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoYW5rczwvc3Bhbj48c3BhbiBsYW5nPSJE RSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkRFIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj5NaWNoYWVsPC9zcGFuPjxzcGFuIGxhbmc9IkRFIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iREUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkRFIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkRFIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFkcmlh bg0KIEZhcnJlbCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrIiB0 YXJnZXQ9Il9ibGFuayI+YWRyaWFuQG9sZGRvZy5jby51azwvYT5dDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gU3VuZGF5LCBNYXkgMjIsIDIwMTYgNjoyNCBBTTxicj4NCjxiPlRvOjwvYj4gU2NoYXJmLCBN aWNoYWVsIChOb2tpYSAtIERFKTxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnRlYXNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50ZWFzQGlldGYub3JnPC9hPjwvc3Bhbj48c3BhbiBs YW5nPSJERSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJERSI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbVGVh c10gQSBOZXcgSS1EIG9uIFBDRSBhcyBhIGNlbnRyYWwgY29udHJvbGxlcjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkRFIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+TWljaGFlbCwgPC9zcGFuPjxzcGFuIGxh bmc9IkRFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkRFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3Bh biBsYW5nPSJFTi1HQiI+SSBkb24ndCB0aGluayBpdCBpcyBjb21wbGljYXRlZCwgYnV0IGl0IGlz IG9idmlvdXNseSBub3QgY2xlYXIgZnJvbSB0aGUgZG9jdW1lbnQsIHNvIHRoYW5rIHlvdSBmb3Ig cmFpc2luZyB0aGUgY29uY2Vybi48L3NwYW4+PHNwYW4gbGFuZz0iREUiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i REUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj5Zb3Ugc2F5 IGl0IGRvZXNuJ3QgbWF0dGVyIHdoaWNoIGludGVyZmFjZSB3ZSdyZSB0YWxraW5nIGFib3V0LCBi dXQgaXQgZG9lcy4gUENFUCBpcyBhIHByb3RvY29sIGFuZCBwcm90b2NvbHMgYXJlIHVzZWQgb24g aW50ZXJmYWNlcy48L3NwYW4+PHNwYW4gbGFuZz0iREUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iREUiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj5MZXQncyBzdGFydCB3aXRo IHNvdXRoYm91bmQgb2YgdGhlIFBDRS4gV2UgYWxyZWFkeSB1c2UgUENFUCBvbiB0aGlzIGludGVy ZmFjZS4gV2UgaGF2ZSBhbHdheXMgZG9uZS4gSXQgaXMgd2hhdCBQQ0VQIHdhcyBpbnZlbnRlZCBm b3IuIEFuZCByZWNlbnQgZGV2ZWxvcG1lbnRzIGluIFN0YXRlZnVsIFBDRSBhbmQgUENFLUluaXRp YXRlZCBMU1BzIGhhdmUgbWFkZSBQQ0VQIChhbmQgdGhpcyBpbnRlcmZhY2UpIGFibGUNCiB0byBz ZW5kIGNvbnRyb2wgJnF1b3Q7Y29tbWFuZHMmcXVvdDsgYXMgd2VsbCBhcyByZXNwb25kIHRvIHJl cXVlc3RzLiBUaHVzLCBQQ0VQIGlzIGFuIFNCSSBwcm90b2NvbCBmb3IgdXNlIHdpdGggc2lnbmFs aW5nIHN5c3RlbXMuPC9zcGFuPjxzcGFuIGxhbmc9IkRFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkRFIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Tm93LCB3ZSBtaWdodCBt YWtlIHNldmVyYWwgb2JzZXJ2YXRpb25zLi4uPC9zcGFuPjxzcGFuIGxhbmc9IkRFIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkRFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+ SW4gbWFueSAobW9zdD8pIE1QTFMtVEUgbmV0d29ya3MsIGV2ZXJ5IHJvdXRlciBpcyBjYXBhYmxl IG9mIGJlaW5nIHRoZSBoZWFkIGVuZCBvZiBMU1BzLiBUaGF0IG1lYW5zIHRoYXQgaW4gYSBQQ0Ut ZW5hYmxlZCBNUExTLVRFIG5ldHdvcmssIGV2ZXJ5IHJvdXRlciBpcyBhIFBDRVAgc3BlYWtlci48 L3NwYW4+PHNwYW4gbGFuZz0iREUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxh bmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iREUiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj5BZGRpdGlvbmFsbHksIHdlIGNhbiBvYnNlcnZl IHRoYXQgTFNQcyAob3IgUFdzKSBjYW4gYmUgc3RpdGNoZWQgdG9nZXRoZXIuIFRoZSBzdGl0Y2hp bmcsIGlmIHVuZGVyIHRoZSBjb250cm9sIG9mIGEgUENFLCByZXF1aXJlcyBhIHNwZWNpYWwgaW5z dHJ1Y3Rpb24gdG8gYmUgc2VudCB0byB0aGUgc3RpdGNoaW5nIG5vZGUuPC9zcGFuPjxzcGFuIGxh bmc9IkRFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkRFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3Bh biBsYW5nPSJFTi1HQiI+RnVydGhlcm1vcmUsIHdlIGNhbiB1bmRlcnN0YW5kIHRoYXQgYSBzaW5n bGUgZW5kLXRvLWVuZCBMU1AgaXMgYWN0dWFsbHkgdGhlIHN0aXRjaGluZyBvZiBsb3RzIG9mIHNp bmdsZSBob3AgTFNQcy4gVGhhdCBpcyByZWFsbHkgd2hhdCBhIHN0YXRpY2FsbHkgcHJvdmlzaW9u ZWQgTFNQIGlzLjwvc3Bhbj48c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJERSI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPkZpbmFsbHksIHdlIGNhbiBz ZWUgYSBkZXNpcmUgdG8gc2VuZCBURSBpbnN0cnVjdGlvbnMgZnJvbSBhIGNvbXB1dGF0aW9uIGVu Z2luZSAoZS5nLiwgUENFKSB0byBpbmRpdmlkdWFsIG5ldHdvcmsgbm9kZXMgdG8gcHJvZ3JhbSB0 aGVpciBmb3J3YXJkaW5nLiBGb3IgZXhhbXBsZSwgaW4gYSBTZWdtZW50IFJvdXRlZCBuZXR3b3Jr IG9yIGZvciBzdGF0aWMgTVBMUy1URSBMU1BzLjwvc3Bhbj48c3BhbiBsYW5nPSJERSI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0Ii PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+ PHNwYW4gbGFuZz0iRU4tR0IiPlB1dCBhbGwgb2YgdGhpcyB0b2dldGhlciB3aXRoIHRoZSByZWNv Z25pdGlvbiB0aGF0IGFsbCBURSBwYXRoIG1hbmFnZW1lbnQgaXMgZnVuZGFtZW50YWxseSB0aGUg c2FtZSBhbmQgY2FuIGJlIHBlcmZvcm1lZCBieSB0aGUgc2FtZSBlbmdpbmUsIGFuZCB0aGF0IGl0 IGRvZXMgbm90IG1ha2Ugc2Vuc2UgZm9yIHN1Y2ggYW4gZW5naW5lIHRvIGhhdmUgdG8gaW1wbGVt ZW50IG11bHRpcGxlIFNCSSBwcm90b2NvbHMsDQogYW5kIHlvdSBlbmQgdXAgd2l0aCB0aGlzIGRy YWZ0Ljwvc3Bhbj48c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNw YW4gbGFuZz0iRU4tR0IiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPkkgZG9uJ3QgdGhpbmsgd2UgYXJlIHNh eWluZyB0aGF0IHRoaXMgYXBwcm9hY2ggaXMgY29tcHVsc29yeSwgYnV0IHdlIGFyZSBzYXlpbmcg dGhhdCBpdCBpcyBwb3NzaWJsZS4gT3RoZXIgcG9zc2liaWxpdGllcyBleGlzdCBpbmNsdWRpbmcg dXNpbmcgTkVUQ09ORi9ZQU5HIGluIHBsYWNlIG9mIFBDRVAsIGFuZCBlbmhhbmNpbmcgQkdQIGlu IHBsYWNlIG9mIFBDRVAuIE90aGVycyBoYXZlIHN1Z2dlc3RlZCBYTVBQLg0KIEZyYW5rbHksIGlm IHdlIHdlcmUgcHJvcG9zaW5nIGEgbmV3IHByb3RvY29sIGl0IHdvdWxkIGJlIGNvcnJlY3QgdG8g dGVsbCB1cyBub3QgdG8sIGFuZCB0byBwZXJzdWFkZSB1cyB0aGF0IG9uZSBvZiB0aGUgb3RoZXIg cHJvdG9jb2xzIHdpbGwgZG8gdGhlIGpvYi4gQnV0IGhlcmUgd2UgYXJlIHdpdGggdGhyZWUgKG9y IGZvdXIpIHByb3RvY29scyB0aGF0IGZpdCB0aGUgYmlsbDogZWFjaCBjdXJyZW50bHkgY292ZXJz IHNvbWUgb2YgdGhlIGZ1bmN0aW9uDQogc3BhY2UgYW5kIGVhY2ggY291bGQgZWFzaWx5IGJlIGV4 dGVuZGVkIHRvIGNvdmVyIHRoZSB3aG9sZSBzcGFjZS4gSSdtIG5vdCBjYXBhYmxlIG9mIHNheWlu ZyBob3cgdG8gZGVjaWRlIHdoaWNoIHByb3RvY29sIGRvZXMgd2hpY2ggZnVuY3Rpb24sIGJ1dCBJ IGRvIHNlZSBwcmVzc3VyZXMgb2YgaW1wbGVtZW50YXRpb24gYW5kIGRlcGxveW1lbnQgdGhhdCBs ZWFkIHRvIHRoaXMgZHJhZnQuPC9zcGFuPjxzcGFuIGxhbmc9IkRFIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkRF Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+W0hpc3Rvcmlj IG5vdGU6IEkgd2FzIHNvbWV3aGF0IG9wcG9zZWQgdG8gYWRkaW5nIFBDRS1Jbml0aWF0ZWQgTFNQ IHN1cHBvcnQgdG8gUENFUC4gSSB0aG91Z2h0IHRoaXMgYmVudCB0aGUgYXJjaGl0ZWN0dXJlIGZ1 cnRoZXIgdGhhbiB3YXMgb3JpZ2luYWxseSBpbnRlbmRlZC4gQnV0IHdlIHdlbnQgdGhlcmUgaW4g dGhlIFBFQyBXRyBhbmQgdGhlIEktRCBpcyBub3cgJnF1b3Q7Y29tcGxldGUmcXVvdDsuIEJ5IGFk ZGluZyBzdXBwb3J0DQogb2YgUENFIGluaXRpYXRpb24gb2YgTFNQcywgd2UgbmF0dXJhbGx5IG9w ZW5lZCB0aGUgcGF0aCB0byB0aGlzIGRvY3VtZW50LiBGV0lXLCB0aGlzIGlzIG5vdCB0aGUgZmly c3QgdGltZSB0aGF0IFBDRVAgaGFzIGJlZW4gZGlzY3Vzc2VkIGFzIGEgbW9yZSBnZW5lcmFsIFNC SSBwcm90b2NvbCAtIFJGQyA3NDkxIHNob3dzIGl0IGluIHRoaXMgY29udGV4dCBhbHRob3VnaCBk b2VzIG5vdCBkaXNjdXNzIGl0IG11Y2ggKHdlIHNob3VsZCBwcm9iYWJseQ0KIGFkZCBhIHJlZmVy ZW5jZSB0byBBQk5PIGluIHRoaXMgZG9jdW1lbnQpLl08L3NwYW4+PHNwYW4gbGFuZz0iREUiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iREUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVO LUdCIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iREUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwPjxzcGFuIGxhbmc9IkVOLUdCIj5Ob3csIHlvdSBzYXkgeW91IGFyZSBzdXJwcmlzZWQgdGhh dCAmcXVvdDt0aGUgZG9jdW1lbnQgZm9jdXNlcyBvbiB1c2luZyBQQ0VQIGUuZy4gZm9yIEwzVlBO IHNlcnZpY2UgZGVsaXZlcnkuJnF1b3Q7IEkgdGhpbmsgdGhlcmUgaXMgYSBzaWduaWZpY2FudCBk aWZmZXJlbmNlIGJldHdlZW4gKnJlcXVlc3RpbmcqIGEgc2VydmljZSBhbmQgKmRlbGl2ZXJpbmcq IHRoYXQgc2VydmljZS4gVGhlIHNlcnZpY2UgcmVxdWVzdCAoYXMsDQogZm9yIGV4YW1wbGUsIGlu IEwzU00pIGRvZXMgbm90IGludm9sdmUgYSBQQ0UgYW5kIGlzIGVhc2lseSBhY2hpZXZlZCB1c2lu ZyBhIFlBTkcgbW9kZWwgd2hpY2gsIGlmIHRoZSBzZXJ2aWNlIHJlcXVlc3QgaXMgb24tbGluZSwg Y2FuIGJlIGRlbGl2ZXJlZCB1c2luZyBORVRDT05GLiBIb3dldmVyLCBzZXJ2aWNlIGRlbGl2ZXJ5 IHJlcXVpcmVzICZxdW90O29yY2hlc3RyYXRpb24mcXVvdDsuIE9yY2hlc3RyYXRpb24gaXMgdGhl IHByb2Nlc3Mgb2YgY29uc2lkZXJpbmcNCiBhdmFpbGFibGUgbmV0d29yayByZXNvdXJjZXMgYW5k IHNlbGVjdGluZyB3aGF0IHdpbGwgYmUgcHJvdmlzaW9uZWQgdG8gc3VwcG9ydCB0aGUgc2Vydmlj ZS4gQSBQQ0UgaXMgYXQgbGVhc3QgYSBrZXkgZmVhdHVyZSBvZiBvcmNoZXN0cmF0aW9uLCBqdXN0 IGFzIGl0IGlzIGEga2V5IGNvbXBvbmVudCBvZiBhIG5ldHdvcmsgY29udHJvbGxlci4NCjwvc3Bh bj48c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0i RU4tR0IiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPkJ1dCB0aGUgZG9jdW1lbnQgZG9lcyBOT1QgZm9jdXMg b24gUENFUCBpbiBxdWl0ZSB0aGUgd2F5IHlvdSBkZXNjcmliZS4gSW4gZmFjdCwgdGhlIG9ubHkg ZGlzY3Vzc2lvbiBpcyBpbiAzLjIuMyAoanVzdCB0d28gcGFyYWdyYXBocyBpbiB0aGUgd2hvbGUg ZG9jdW1lbnQpIHdoZXJlIHRoZSBmb2N1cyBpcyBvbiB0aGUgdXNlIG9mIGEgUENFLWJhc2VkIGNl bnRyYWwgY29udHJvbGxlciB0aGF0IGNhbiAmcXVvdDtjb25zaWRlcg0KIHRoZSB3aG9sZSBuZXR3 b3JrIGFuZCBhbGwgY29tcG9uZW50cyBvZiBhIHNlcnZpY2UgYXQgb25jZSB3aGVuIHBsYW5uaW5n IGhvdyB0byBkZWxpdmVyIHRoZSBzZXJ2aWNlLiZxdW90OyBJdCB0aGVuIGdvZXMgb24gdG8gb2Jz ZXJ2ZSB0aGF0IFBDRVAgY2FuIGJlIHVzZWQgJnF1b3Q7dG8gbWFuYWdlIHRoZSBuZXR3b3JrIHJl c291cmNlcyBhbmQgdG8gaW5zdGFsbCB0aGUgbmVjZXNzYXJ5IGFzc29jaWF0aW9ucyBiZXR3ZWVu IHRob3NlIHJlc291cmNlcy4mcXVvdDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJERSI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJERSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNw YW4gbGFuZz0iRU4tR0IiPklmIHdlIGluY2x1ZGVkIGEgbWVzc2FnZSBmbG93IGNoYXJ0IGl0IHdv dWxkIGxvb2sgc29tZXRoaW5nIGxpa2UuLi48L3NwYW4+PHNwYW4gbGFuZz0iREUiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iREUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNlcnZpY2UgTWFuYWdl ciZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQQ0UtYmFzZWQgQ29udHJvbGxlciZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBORXM8L3NwYW4+PHNwYW4gbGFuZz0iREUiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZXF1ZXN0IHNl cnZpY2UtLS0tLS0tLS0mZ3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkRFIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ29t cHV0ZTwvc3Bhbj48c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFByb3Zpc2lvbiAtLS0tLS0mZ3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkRFIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0Oy0tLS0t LS0tLS0tLS0gQWNrPC9zcGFuPjxzcGFuIGxhbmc9IkRFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cD48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVXBkYXRlIERC czwvc3Bhbj48c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDstLS0tLS0tLS0tLS0tLS0tLS0tQWNrPC9zcGFu PjxzcGFuIGxhbmc9IkRFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iREUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPklm IHRoYXQgc2ltcGxlIGZpZ3VyZSBoZWxwcyB3aXRoIHRoZSB1bmRlcnN0YW5kaW5nIG9mIHRoaXMg b3IgYW55IG90aGVyIHBhcnQgb2YgdGhlIGRvY3VtZW50LCB3ZSBjYW4gc3VyZWx5IGFkZCBpdC48 L3NwYW4+PHNwYW4gbGFuZz0iREUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Q2hlZXJzLDwvc3Bhbj48c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+QWRyaWFuPC9zcGFuPjxzcGFuIGxhbmc9IkRFIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkRFIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyA8L3NwYW4+ LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgPC9zcGFuPkZyb206IFNjaGFyZiwg TWljaGFlbCAoTm9raWEgLSBERSkgWzxhIGhyZWY9Im1haWx0bzptaWNoYWVsLnNjaGFyZkBub2tp YS5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86bWljaGFlbC5zY2hhcmZAbm9raWEuY29tPC9h Pl08c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0i RU4tR0IiPiZndDsgPC9zcGFuPlNlbnQ6IDIwIE1heSAyMDE2IDE5OjA3PHNwYW4gbGFuZz0iREUi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IDwvc3Bh bj5UbzogPGEgaHJlZj0ibWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWsiIHRhcmdldD0iX2JsYW5r Ij4NCmFkcmlhbkBvbGRkb2cuY28udWs8L2E+OyA8YSBocmVmPSJtYWlsdG86dGVhc0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPnRlYXNAaWV0Zi5vcmc8L2E+PHNwYW4gbGFuZz0iREUiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IDwvc3Bhbj5TdWJq ZWN0OiBSRTogW1RlYXNdIEEgTmV3IEktRCBvbiBQQ0UgYXMgYSBjZW50cmFsIGNvbnRyb2xsZXI8 c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4t R0IiPiZndDsgPC9zcGFuPjxzcGFuIGxhbmc9IkRFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyBBcyBJIHNhaWQsIEkgc3BlY2lmaWNhbGx5IHdvbmRl ciBhYm91dCBTZWN0aW9uIDMuMi4zICZxdW90O1NlcnZpY2UgRGVsaXZlcnkmcXVvdDssIHdoaWNo IHN0YXRlczwvc3Bhbj48c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+ PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgKG9taXR0aW5nIHNvbWUgcGFydHMgdGhhdCBhcmUgbm90 IHJlbGV2YW50IGhlcmUpOjwvc3Bhbj48c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgPC9zcGFuPjxzcGFuIGxhbmc9IkRFIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyAmcXVvdDtW YXJpb3VzIG5ldHdvcmsgc2VydmljZXMgbWF5IGJlIG9mZmVyZWQgb3ZlciBhIG5ldHdvcmsuIFRo ZXNlIGluY2x1ZGU8L3NwYW4+PHNwYW4gbGFuZz0iREUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IHByb3RlY3Rpb24gc2VydmljZXMgWy4uLl0gVmly dHVhbCBQcml2YXRlIE5ldHdvcmsgKFZQTikgc2VydmljZSAoc3VjaCBhcyBMYXllciAzPC9zcGFu PjxzcGFuIGxhbmc9IkRFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJF Ti1HQiI+Jmd0OyBWUE5zIFtSRkM0MzY0XSBvciBFdGhlcm5ldCBWUE5zIFtSRkM3NDMyXSksIG9y IFBzZXVkb3dpcmVzIFtSRkMzOTg1XS4gWy4uLl0mbmJzcDsgQTwvc3Bhbj48c3BhbiBsYW5nPSJE RSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgUENF LWJhc2VkIGNlbnRyYWwgY29udHJvbCBjYW4gY29uc2lkZXIgdGhlIHdob2xlIG5ldHdvcmsgYW5k IGFsbCBjb21wb25lbnRzIG9mPC9zcGFuPjxzcGFuIGxhbmc9IkRFIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyBhIHNlcnZpY2UgYXQgb25jZSB3aGVu IHBsYW5uaW5nIGhvdyB0byBkZWxpdmVyIHRoZSBzZXJ2aWNlLiBJdCBjYW4gdGhlbiB1c2UgUENF UDwvc3Bhbj48c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4g bGFuZz0iRU4tR0IiPiZndDsgdG8gbWFuYWdlIHRoZSBuZXR3b3JrIHJlc291cmNlcyBhbmQgdG8g aW5zdGFsbCB0aGUgbmVjZXNzYXJ5IGFzc29jaWF0aW9uczwvc3Bhbj48c3BhbiBsYW5nPSJERSI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgYmV0d2Vl biB0aG9zZSByZXNvdXJjZXMuJnF1b3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkRFIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyA8L3NwYW4+PHNwYW4gbGFu Zz0iREUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7 IFRoaXMgd29yZGluZyBvbiB1c2Ugb2YgUENFUCBjb25mdXNlcyBtZSwgbm8gbWF0dGVyIHdoYXQg aW50ZXJmYWNlIHdlIHRhbGs8L3NwYW4+PHNwYW4gbGFuZz0iREUiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IGFib3V0LiBJIHdvdWxkIGhhdmUgYXNz dW1lZCB0aGF0IFlBTkctYmFzZWQgcHJvdG9jb2xzIHN1Y2ggYXM8L3NwYW4+PHNwYW4gbGFuZz0i REUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IE5F VENPTkYvUkVTVENPTkYgY291bGQgYmUgdXNlZnVsIGluIHRoaXMgY29udGV4dCwgYW5kIEkgYW0g YSBiaXQgc3VycHJpc2VkIHRoYXQ8L3NwYW4+PHNwYW4gbGFuZz0iREUiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IHRoZSBkb2N1bWVudCBmb2N1c2Vz IG9uIHVzaW5nIFBDRVAgZS5nLiBmb3IgTDNWUE4gc2VydmljZSBkZWxpdmVyeS4gQnkgdGhlIHdh eSw8L3NwYW4+PHNwYW4gbGFuZz0iREUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFu IGxhbmc9IkVOLUdCIj4mZ3Q7IEkgYWxzbyB3b25kZXIgaG93IFBDRVAgZml0cyBpbnRvIHRoZSBk aXNjdXNzaW9uIG9uIFFvUyBjbGFzc2lmaWNhdGlvbiBpbiBTZWN0aW9uPC9zcGFuPjxzcGFuIGxh bmc9IkRFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0 OyAzLjIuMi48L3NwYW4+PHNwYW4gbGFuZz0iREUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw PjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IDwvc3Bhbj48c3BhbiBsYW5nPSJERSI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgSSB3b25kZXIgaWYgdGhl IGF1dGhvcnMgY291bGQgYWRkIHRvIFNlY3Rpb24gMy4yLjIgYW5kIFNlY3Rpb24gMy4yLjMgZS5n LiBhPC9zcGFuPjxzcGFuIGxhbmc9IkRFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3Bh biBsYW5nPSJFTi1HQiI+Jmd0OyBtZXNzYWdlIHNlcXVlbmNlIGNoYXJ0IHRoYXQgaWxsdXN0cmF0 ZXMgaG93IHdoYXQgaXMgZGlzY3Vzc2VkIGluIHRob3NlIHNlY3Rpb25zPC9zcGFuPjxzcGFuIGxh bmc9IkRFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0 OyByZWxhdGVzIHRvIFBDRVA/PC9zcGFuPjxzcGFuIGxhbmc9IkRFIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0iREUi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IE1pY2hh ZWw8L3NwYW4+PHNwYW4gbGFuZz0iREUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFu IGxhbmc9IkVOLUdCIj4mZ3Q7IDwvc3Bhbj48c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgPC9zcGFuPjxzcGFuIGxhbmc9IkRF Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyA8L3Nw YW4+PHNwYW4gbGFuZz0iREUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9 IkVOLUdCIj4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9zcGFuPjxzcGFuIGxhbmc9 IkRFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyBG cm9tOiBUZWFzIFs8YSBocmVmPSJtYWlsdG86dGVhcy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+bWFpbHRvOnRlYXMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBF WFQgQWRyaWFuIEZhcnJlbDwvc3Bhbj48c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgU2VudDogRnJpZGF5LCBNYXkgMTMsIDIw MTYgNjo1NCBQTTwvc3Bhbj48c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgVG86IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBE RSk7IDxhIGhyZWY9Im1haWx0bzp0ZWFzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQp0ZWFz QGlldGYub3JnPC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgU3ViamVjdDogUmU6IFtUZWFzXSBBIE5ldyBJ LUQgb24gUENFIGFzIGEgY2VudHJhbCBjb250cm9sbGVyPC9zcGFuPjxzcGFuIGxhbmc9IkRFIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyA8L3NwYW4+ PHNwYW4gbGFuZz0iREUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVO LUdCIj4mZ3Q7IEhlbGxvIGFnYWluLCBNaWNoYWVsLCBpdCBzZWVtcyB0byBiZSBteSBkYXkgZm9y IHJlcGx5aW5nIHRvIHlvdXIgZW1haWxzLjwvc3Bhbj48c3BhbiBsYW5nPSJERSI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgPC9zcGFuPjxzcGFuIGxh bmc9IkRFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0 OyAmZ3Q7IFdoZW4gcmVhZGluZyBhYm91dCB1c2VzIGNhc2VzIHN1Y2ggYXMgTDNWUE4gc2Vydmlj ZSBkZWxpdmVyeSBpbjwvc3Bhbj48c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgJmd0OyAmcXVvdDtTZWN0aW9uPC9zcGFuPjxz cGFuIGxhbmc9IkRFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1H QiI+Jmd0OyAzLjIuMyZxdW90Oyw8L3NwYW4+PHNwYW4gbGFuZz0iREUiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7ICZndDsgd2hhdCBpcyB0aGUgYXV0 aG9yJ3MgdmlldyBvbiB0aGUgbGluZSBvZiBkZW1hcmNhdGlvbiBiZXR3ZWVuIE5FVENPTkY8L3Nw YW4+PHNwYW4gbGFuZz0iREUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9 IkVOLUdCIj4mZ3Q7ICZndDsgYW5kIFBDRVA/PC9zcGFuPjxzcGFuIGxhbmc9IkRFIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyA8L3NwYW4+PHNwYW4g bGFuZz0iREUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4m Z3Q7IFdlbGwsIEkgd29uZGVyIHdoaWNoIGludGVyZmFjZSB5b3UncmUgdGFsa2luZyBhYm91dC48 L3NwYW4+PHNwYW4gbGFuZz0iREUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxh bmc9IkVOLUdCIj4mZ3Q7IFRoZSBvbmVzIHRoYXQgb3V0IGluIGhlcmUgYXJlOjwvc3Bhbj48c3Bh biBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0Ii PiZndDsgLSB0aGUgaW50ZXJmYWNlIGJldHdlZW4gY3VzdG9tZXIgYW5kIG9wZXJhdG9yPC9zcGFu PjxzcGFuIGxhbmc9IkRFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJF Ti1HQiI+Jmd0OyAtIHRoZSBpbnRlcmZhY2UgYmV0d2VlbiAmcXVvdDtzZXJ2aWNlIG9yY2hlc3Ry YXRvciZxdW90OyBhbmQgJnF1b3Q7bmV0d29yayBvcmNoZXN0cmF0b3ImcXVvdDs8L3NwYW4+PHNw YW4gbGFuZz0iREUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdC Ij4mZ3Q7IDwvc3Bhbj48c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+ PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgVGhlIGZvcm1lciBvZiB0aGVzZSBpcyBsaWtlIHRoZSBp bnRlcmZhY2UgdXNlZCBpbiBMM1NNLiBBcyBjby1jaGFpciBvZiBMM1NNLCB5b3U8L3NwYW4+PHNw YW4gbGFuZz0iREUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdC Ij4mZ3Q7IG1pZ2h0IG5vdCBiZSBzdXJwcmlzZWQgdG8gaGVhciB0aGF0IG15IHZpZXcgaXMgdGhh dCBORVRDT05GIGlzIGEgZmluZSBzb2x1dGlvbiAtPC9zcGFuPjxzcGFuIGxhbmc9IkRFIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyB3ZWxsLCB0aGUg dXNlIG9mIGEgWUFORyBkYXRhIG1vZGVsLCBpbiBhbnkgY2FzZS48L3NwYW4+PHNwYW4gbGFuZz0i REUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IDwv c3Bhbj48c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFu Zz0iRU4tR0IiPiZndDsgVGhlIGxhdHRlciBpcyB0aGUgaW50ZXJmYWNlIGJldHdlZW4gJnF1b3Q7 T3JjaGVzdHJhdG9yIC8gU2VydmljZSBNYW5hZ2VyIC8gT1NTIC88L3NwYW4+PHNwYW4gbGFuZz0i REUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IE5N UyZxdW90Ozwvc3Bhbj48c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+ PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgYW5kICZxdW90O1BDRS1iYXNlZCBDb250cm9sbGVyJnF1 b3Q7IGFzIHNob3duIG9uIHRoZSB2YXJpb3VzIGZpZ3VyZXMgaW4gdGhlIHBpY3R1cmUuIFdlPC9z cGFuPjxzcGFuIGxhbmc9IkRFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5n PSJFTi1HQiI+Jmd0OyBoYXZlbid0IGRpc2N1c3NlZCB0aGlzIGludGVyZmFjZSBpbiB0aGUgZG9j dW1lbnQsIGFuZCBwZXJoYXBzIHdlIHNob3VsZC48L3NwYW4+PHNwYW4gbGFuZz0iREUiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IDwvc3Bhbj48c3Bh biBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0Ii PiZndDsgSWYgeW91IGxvb2sgYXQgRmlndXJlIDYgKHdpdGggdGhlIGhpZXJhcmNoeSBvZiBjb250 cm9sbGVycykgeW91IG1pZ2h0IG9ic2VydmUgdGhhdDwvc3Bhbj48c3BhbiBsYW5nPSJERSI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgdGhlIHBhcmVu dCBjb250cm9sbGVyIGNvdWxkIGJlIGltcGxlbWVudGVkIHRvIGFjdCBhcyB0aG91Z2ggaXQgaXMg dGFsa2luZyB0byBhbiBORTwvc3Bhbj48c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgKGluIHRoZSBhYnN0cmFjdCBub2RlIG1v ZGVsKSBhbmQgdGhhdCBtZWFucyB0aGF0IHRoZSBzb3V0aGJvdW5kIGludGVyZmFjZSBvZjwvc3Bh bj48c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0i RU4tR0IiPiZndDsgdGhlIHBhcmVudCBjb250cm9sbGVyIHdvdWxkIGJlIFBDRVAuIFRoYXQgbWVh bnMgKG9mIGNvdXJzZSkgdGhhdCB0aGU8L3NwYW4+PHNwYW4gbGFuZz0iREUiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IG5vcnRoYm91bmQgaW50ZXJm YWNlIG9mIHRoZSBjaGlsZCBjb250cm9sbGVyIHdvdWxkIGFsc28gYmUgUENFUC4gVGhlbiwgaXQg bWlnaHQ8L3NwYW4+PHNwYW4gbGFuZz0iREUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxz cGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IHNlZW0gb2J2aW91cyB0aGF0IHdlIHdvdWxkIHdhbnQgYWxs IFBDRSBpbXBsZW1lbnRhdGlvbnMgdG8gYmVoYXZlIHRoZSBzYW1lPC9zcGFuPjxzcGFuIGxhbmc9 IkRFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyB3 YXkgYW5kIHNvIHRoYXQgbWFrZXMgdGhlIG5vcnRoYm91bmQgaW50ZXJmYWNlIG9mIHRoZSBwYXJl bnQgUENFPC9zcGFuPjxzcGFuIGxhbmc9IkRFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48 c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyB3b3VsZC9jb3VsZC9zaG91bGQvbWlnaHQgYWxzbyBiZSBQ Q0VQLjwvc3Bhbj48c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNw YW4gbGFuZz0iRU4tR0IiPiZndDsgPC9zcGFuPjxzcGFuIGxhbmc9IkRFIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyBXaGF0IGRvIHlvdSB0aGluaz88 L3NwYW4+PHNwYW4gbGFuZz0iREUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxh bmc9IkVOLUdCIj4mZ3Q7IDwvc3Bhbj48c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgVGhhbmtzLDwvc3Bhbj48c3BhbiBsYW5n PSJERSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsg QWRyaWFuPC9zcGFuPjxzcGFuIGxhbmc9IkRFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48 c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0iREUiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxzcGFuIGxhbmc9IkRFIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyBUZWFzIG1haWxp bmcgbGlzdDwvc3Bhbj48c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+ PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgPGEgaHJlZj0ibWFpbHRvOlRlYXNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5UZWFzQGlldGYub3JnPC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJERSI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90ZWFzIiB0YXJnZXQ9Il9ibGFu ayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RlYXM8L2E+PC9zcGFu PjxzcGFuIGxhbmc9IkRFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NClRlYXMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv OlRlYXNAaWV0Zi5vcmciPlRlYXNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90ZWFzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90ZWFzPC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_655C07320163294895BBADA28372AF5D48862F8BFR712WXCHMBA15z_-- From nobody Mon May 23 06:41:02 2016 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 D242A12D0B7 for ; Mon, 23 May 2016 06:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2XgGsQPQPmM for ; Mon, 23 May 2016 06:40:59 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14E1C12D099 for ; Mon, 23 May 2016 06:40:59 -0700 (PDT) Received: by mail-ig0-x233.google.com with SMTP id fh2so22768249igd.1 for ; Mon, 23 May 2016 06:40:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=3p+3ZShS0WoZe9tERNPoK1V/XlvNF61QxjV+SzdbPxM=; b=kUa+BcOCcX+jWVCgr8radDeIWukuBdavXXhwk0kJiEqRD+uGw1BGvrKlKdbaKc7qV1 4D/q1j21MWKU5o0PlKg4b5vuj1IDKi3S4uln/JDQyqO1O6LEBqWQPRiP9NX8U63L5Rfh JDACHmCflldO0nnHCiwVLSVwdiUopA7dlD/1YSC0225cJbany3MoeBF0EGpy6ngkaiOS OAnj1e6/0hQR8UIflgfNRNO1QW/guYtq1FMeK7zFdei8q7sbLtxGetP32ZKuGGv+S0Zx ly45nv+8p6SIK0Si+AucBwjWaNtl31+FMJeceuOpiR/+LjUoLMbDNNEzmM3yMeesUij3 lgXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=3p+3ZShS0WoZe9tERNPoK1V/XlvNF61QxjV+SzdbPxM=; b=Z/8wkkaZLMeY5JCzUlJNsk+eFMhSHsSi+HISKDFfKC4SRQw+Xnvp0JoZJffkkmdAf2 FqvGsDz0NVxDtOG1fMstkzs1V3WWPEKShJAa7r+dJYhi0bog7k4ZNt25D7cK+thdX1o1 vY91bUUpona4WWRxIPLm1CIswRddk5yvgkXLe0fXihkHSE9w0Vf3SV+c6u6LwVdLCbCJ enOMBWu23gBkL102leCofy/cx7fnygoU8sEBVfmYtpKRQWP0cHtIuUEVyLOWSuhpA+zJ GbB4CdZa2EKSnAgsm5svVEeE/uD07aFmQLjveXGwEuKR2P/VNcSPFuaqGJc/6SXXNo0N Y/eA== X-Gm-Message-State: AOPr4FVyymEnvs3K08jJ+aFI5zDmG4YZ4P1RlqoiUsimxlJ4pr9H/m21hqL3h5SvDiHLc0faHyiRhmw/JyEE2Q== MIME-Version: 1.0 X-Received: by 10.50.8.2 with SMTP id n2mr12779081iga.39.1464010858221; Mon, 23 May 2016 06:40:58 -0700 (PDT) Received: by 10.107.5.72 with HTTP; Mon, 23 May 2016 06:40:58 -0700 (PDT) In-Reply-To: <02d101d1af76$b0317cd0$10947670$@gmail.com> References: <02d101d1af76$b0317cd0$10947670$@gmail.com> Date: Mon, 23 May 2016 09:40:58 -0400 Message-ID: From: Cyril Margaria To: Xufeng Liu Content-Type: multipart/alternative; boundary=089e013d0dcc26fb3d0533829788 Archived-At: Cc: TEAS WG Subject: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 13:41:01 -0000 --089e013d0dcc26fb3d0533829788 Content-Type: text/plain; charset=UTF-8 Hi, Another item that can be considered is to add a Label (Following RFC7579) restrictions. This is needed, for example, in case of Fixed muxponders, where the connectivity between the Low order ODUs to the high-order ODU is fixed on each end. Can it be added to the list of changes for the connectivity matrix? Thanks, Cyril On 16 May 2016 at 09:27, Xufeng Liu wrote: > Authors and contributors have discussed the use case of abstract topology, > to address the incompleteness of connectivity matrix. > > Current connectivity modeling is as follows: > > | +--rw connectivity-matrix* [id] > | | +--rw id uint32 > | | +--rw from > | | | +--rw tp-ref? leafref > | | +--rw to > | | | +--rw tp-ref? leafref > | | +--rw is-allowed? Boolean > > A Link TP may connect or disconnect to another Link TP, without detailed > information such as cost and resource sharing restriction. To get a better > abstraction of such connectivity, the following additional attributes are > planned to be added: > > max-bandwidth? decimal64 > max-resv-bandwidth? decimal64 > unreserved-bandwidth* [priority] > priority uint8 > +-- bandwidth? decimal64 > +-- te-default-metric uint32 > performance-metric // re-use the container from te-link-atrributes > te-srlgs // re-use the container from te-link-atrributes > > Comments are welcome. > > Thanks, > > - Xufeng > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > --089e013d0dcc26fb3d0533829788 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Another item that can be = considered is to add a Label (Following RFC7579) restrictions. This is need= ed, for example,=C2=A0 in case of Fixed muxponders, where the connectivity = between the Low order ODUs to the high-order ODU is fixed on each end.
<= br>
Can it be added to the list of changes for the connectivity m= atrix?

Thanks,
Cyril

On 16 May 2016 at 09:27, Xu= feng Liu <xufeng.liu.ietf@gmail.com> wrote:
Authors and contributors have discussed the use c= ase of abstract topology,
to address the incompleteness of connectivity matrix.

Current connectivity modeling is as follows:

=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0+--rw connectivity-matrix* [id] =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw id=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 uint32
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw from
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +--rw tp-ref?=C2= =A0 =C2=A0leafref
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw to
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +--rw tp-ref?=C2= =A0 =C2=A0leafref
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw is-allowed?=C2=A0 = =C2=A0Boolean

A Link TP may connect or disconnect to another Link TP, without detailed information such as cost and resource sharing restriction. To get a better<= br> abstraction of such connectivity, the following additional attributes are planned to be added:

=C2=A0 max-bandwidth?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0decimal64
=C2=A0 max-resv-bandwidth?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 decimal64
=C2=A0 unreserved-bandwidth* [priority]
=C2=A0 priority=C2=A0 =C2=A0 =C2=A0uint8
=C2=A0 =C2=A0 =C2=A0+-- bandwidth?=C2=A0 =C2=A0decimal64
=C2=A0 =C2=A0 =C2=A0+-- te-default-metric uint32
=C2=A0 performance-metric // re-use the container from te-link-atrributes =C2=A0 te-srlgs=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// re-use the conta= iner from te-link-atrributes

Comments are welcome.

Thanks,

- Xufeng


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

--089e013d0dcc26fb3d0533829788-- From nobody Mon May 23 06:43:54 2016 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 3C9F912D8E4 for ; Mon, 23 May 2016 06:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPUUKd7UGr_h for ; Mon, 23 May 2016 06:43:46 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1061512B034 for ; Mon, 23 May 2016 06:43:46 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id j1so39950310oih.3 for ; Mon, 23 May 2016 06:43:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=u/FBkGbWEOnj+pE2ERA1FdyK3eOhqYSYXOxbsdOy8fE=; b=SbYGDCxKzZG3jbP7I28O+gLJzrgCY5dHvue/i34LWkgV7XgT9BthHJOk5VJ+CfAAQg VX0ce8w55bEnX46/UoZbcGu7vH61Ix/4RfzYGZ7nr98UFw5EocbSDexUQiVNUXvVIQls 05REdVdgbsV0lnk0CTxPYuAkYHl0VqUjGukwKps5doUcshz5gqAyQqNkijkOx6oQ+pjO Fw932JmFUmeRt4etJv2h57jMBdysJJoiVznMheMiyP6O5X0PbBSAMU4vQdtOZwleINQ/ bsMT1pBimN6V8eSJv2lFqqBLU0/GjIZENE61KAIXiI87ZjRuDIqHztAh62rezoPzaOXH jN1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=u/FBkGbWEOnj+pE2ERA1FdyK3eOhqYSYXOxbsdOy8fE=; b=lQWRPa4owbnhjQMEFs/XebBtv+ziNZxSuUWiAyZoMyRNzoSbrq2v4d09CQNZccV4o+ l0K+6Jv3s02l3UYemmUOQvQ8D8sa6I5O4yW7wTgqdLCtMeSFIOy/YGQoujtFsntWsbHW tzT3shwb3R7xJ+N5uy2ixCYrlphM822LoYV/XADQOfFLOnecFtw71Fbt9cjvH5uqFApv VHvlmGcnpNOBOHCC4G+SxIq711sh2tLu7vEI387EvZ2LXwQFgwJERAOZ7cOsJzQV0pzp 6RpaRwZ+D6d/HBWYuPC8kN4bx4wcYGcUVJl6n9LIUPqWFbjDK28NNCvcfqUpfRzeTHCr AwUg== X-Gm-Message-State: AOPr4FVuxCa0MEeDeb4U+zSXhUkwlmNkG/GrwhuA7h+48BLKv/DemdRl8TFqeBxnKfbGoViU40qoH5VizDD8uw== X-Received: by 10.202.66.5 with SMTP id p5mr9452005oia.65.1464011025365; Mon, 23 May 2016 06:43:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.231.106 with HTTP; Mon, 23 May 2016 06:43:25 -0700 (PDT) In-Reply-To: <655C07320163294895BBADA28372AF5D48862F8B@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <0c6c01d1a7a2$f1a24860$d4e6d920$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48846127@FR712WXCHMBA15.zeu.alcatel-lucent.com> <042101d1ad38$12da5f50$388f1df0$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48860ADB@FR712WXCHMBA15.zeu.alcatel-lucent.com> <001d01d1b3e1$bec637d0$3c52a770$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48862397@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48862F8B@FR712WXCHMBA15.zeu.alcatel-lucent.com> From: "Andrew G. Malis" Date: Mon, 23 May 2016 09:43:25 -0400 Message-ID: To: "Scharf, Michael (Nokia - DE)" Content-Type: multipart/alternative; boundary=001a113d6bfc1d6bbd053382a1f9 Archived-At: Cc: "adrian@olddog.co.uk" , "teas@ietf.org" Subject: Re: [Teas] A New I-D on PCE as a central controller X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 13:43:52 -0000 --001a113d6bfc1d6bbd053382a1f9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Michael, The introduction to section 3 says: =E2=80=9CAs previously mentioned, this = section is intended to just make suggestions.=E2=80=9D. That sound like hypothetica= l to me. Cheers, Andy On Mon, May 23, 2016 at 9:37 AM, Scharf, Michael (Nokia - DE) < michael.scharf@nokia.com> wrote: > Why doesn=E2=80=99t the document then mention that the use cases and conc= lusions > on PCEP are hypothetical? > > > > Michael > > > > > > *From:* Andrew G. Malis [mailto:agmalis@gmail.com] > *Sent:* Monday, May 23, 2016 3:35 PM > *To:* Scharf, Michael (Nokia - DE) > *Cc:* adrian@olddog.co.uk; teas@ietf.org > > *Subject:* Re: [Teas] A New I-D on PCE as a central controller > > > > Michael, > > > > I think you=E2=80=99re expecting too much from this draft. It=E2=80=99s m= eant to be a very > high-level informational document to introduce the concepts and a > non-exhaustive list of possible applications and use cases. As with any > such early document, there=E2=80=99s some amount of speculative writing, = and > there=E2=80=99s no expectation that all of the discussed applications or = use cases > will actually come to fruition, and there may be others in the future tha= t > do end up being implemented. But the actual details of protocol changes a= nd > applications will be the topics of other standards-track draft(s) to come= . > > > > Cheers, > > Andy > > > > > > On Sun, May 22, 2016 at 5:34 PM, Scharf, Michael (Nokia - DE) < > michael.scharf@nokia.com> wrote: > > Hi Adrian, > > > > Many thanks for the tutorial. Since RFC 7491 already acknowledges the rol= e > of a PCE, I see little value of a high-level document that talks about PC= EP > as a general SBI for the topics mentioned in Section 3.2.2 and Section > 3.2.3, if that document does not discuss more specifically the impact on > PCEP, data models, etc. > > > > It should be obvious that in my point of view the wording in Sections > 3.2.2 and 3.2.3 is not clear. Just repeating the wording once again does > not address my question, since I have obviously read the document and sin= ce > I know the terminology (albeit I am not a native speaker). A generic flow > chart not detailing for which of the messages PCEP would be used, and wit= h > what content, also does not address my concern. > > In any case, if the content of Section 3.2.2 and Section 3.2.3 cannot be > made more explicit, it is impossible for me to understand whether the > conclusion in Section 4 =E2=80=A6 =E2=80=9CAs such, no substantial change= s to PCEP are > required to support the concept of a PCE-based controller. The only work > needed will be small extensions to carry additional or specific informati= on > elements for the individual use cases.=E2=80=9D is correct and how it is = actually > justified for the technical areas such as Section 3.2.2 and Section 3.2.3= . > > > > From my personal experience this sort of entirely generic conclusion coul= d > perhaps be a bit of simplification, but this may depend on the actual use > case. But in an I-D, I believe such a generic conclusion needs backing by > content and as far as I understand for Section 3.2.2 and Section 3.2.3 th= is > backing is lacking in the document right now. > > > > Thanks > > > > Michael > > > > > > *From:* Adrian Farrel [mailto:adrian@olddog.co.uk] > *Sent:* Sunday, May 22, 2016 6:24 AM > *To:* Scharf, Michael (Nokia - DE) > *Cc:* teas@ietf.org > > > *Subject:* RE: [Teas] A New I-D on PCE as a central controller > > > > Michael, > > > > I don't think it is complicated, but it is obviously not clear from the > document, so thank you for raising the concern. > > > > You say it doesn't matter which interface we're talking about, but it > does. PCEP is a protocol and protocols are used on interfaces. > > > > Let's start with southbound of the PCE. We already use PCEP on this > interface. We have always done. It is what PCEP was invented for. And > recent developments in Stateful PCE and PCE-Initiated LSPs have made PCEP > (and this interface) able to send control "commands" as well as respond t= o > requests. Thus, PCEP is an SBI protocol for use with signaling systems. > > > > Now, we might make several observations... > > > > In many (most?) MPLS-TE networks, every router is capable of being the > head end of LSPs. That means that in a PCE-enabled MPLS-TE network, every > router is a PCEP speaker. > > > > Additionally, we can observe that LSPs (or PWs) can be stitched together. > The stitching, if under the control of a PCE, requires a special > instruction to be sent to the stitching node. > > > > Furthermore, we can understand that a single end-to-end LSP is actually > the stitching of lots of single hop LSPs. That is really what a staticall= y > provisioned LSP is. > > > > Finally, we can see a desire to send TE instructions from a computation > engine (e.g., PCE) to individual network nodes to program their forwardin= g. > For example, in a Segment Routed network or for static MPLS-TE LSPs. > > > > > > Put all of this together with the recognition that all TE path management > is fundamentally the same and can be performed by the same engine, and th= at > it does not make sense for such an engine to have to implement multiple S= BI > protocols, and you end up with this draft. > > > > I don't think we are saying that this approach is compulsory, but we are > saying that it is possible. Other possibilities exist including using > NETCONF/YANG in place of PCEP, and enhancing BGP in place of PCEP. Others > have suggested XMPP. Frankly, if we were proposing a new protocol it woul= d > be correct to tell us not to, and to persuade us that one of the other > protocols will do the job. But here we are with three (or four) protocols > that fit the bill: each currently covers some of the function space and > each could easily be extended to cover the whole space. I'm not capable o= f > saying how to decide which protocol does which function, but I do see > pressures of implementation and deployment that lead to this draft. > > > > [Historic note: I was somewhat opposed to adding PCE-Initiated LSP suppor= t > to PCEP. I thought this bent the architecture further than was originally > intended. But we went there in the PEC WG and the I-D is now "complete". = By > adding support of PCE initiation of LSPs, we naturally opened the path to > this document. FWIW, this is not the first time that PCEP has been > discussed as a more general SBI protocol - RFC 7491 shows it in this > context although does not discuss it much (we should probably add a > reference to ABNO in this document).] > > > > > > Now, you say you are surprised that "the document focuses on using PCEP > e.g. for L3VPN service delivery." I think there is a significant differen= ce > between *requesting* a service and *delivering* that service. The service > request (as, for example, in L3SM) does not involve a PCE and is easily > achieved using a YANG model which, if the service request is on-line, can > be delivered using NETCONF. However, service delivery requires > "orchestration". Orchestration is the process of considering available > network resources and selecting what will be provisioned to support the > service. A PCE is at least a key feature of orchestration, just as it is = a > key component of a network controller. > > > > But the document does NOT focus on PCEP in quite the way you describe. In > fact, the only discussion is in 3.2.3 (just two paragraphs in the whole > document) where the focus is on the use of a PCE-based central controller > that can "consider the whole network and all components of a service at > once when planning how to deliver the service." It then goes on to observ= e > that PCEP can be used "to manage the network resources and to install the > necessary associations between those resources." > > > > > > If we included a message flow chart it would look something like... > > > > Service Manager PCE-based Controller NEs > > Request service---------> > > Compute > > Provision ------> > > <------------- Ack > > Update DBs > > <-------------------Ack > > > > If that simple figure helps with the understanding of this or any other > part of the document, we can surely add it. > > > > Cheers, > > Adrian > > > > > -----Original Message----- > > > From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com > ] > > > Sent: 20 May 2016 19:07 > > > To: adrian@olddog.co.uk; teas@ietf.org > > > Subject: RE: [Teas] A New I-D on PCE as a central controller > > > > > > As I said, I specifically wonder about Section 3.2.3 "Service Delivery"= , > which states > > > (omitting some parts that are not relevant here): > > > > > > "Various network services may be offered over a network. These include > > > protection services [...] Virtual Private Network (VPN) service (such a= s > Layer 3 > > > VPNs [RFC4364] or Ethernet VPNs [RFC7432]), or Pseudowires [RFC3985]. > [...] A > > > PCE-based central control can consider the whole network and all > components of > > > a service at once when planning how to deliver the service. It can then > use PCEP > > > to manage the network resources and to install the necessary associatio= ns > > > between those resources." > > > > > > This wording on use of PCEP confuses me, no matter what interface we ta= lk > > > about. I would have assumed that YANG-based protocols such as > > > NETCONF/RESTCONF could be useful in this context, and I am a bit > surprised that > > > the document focuses on using PCEP e.g. for L3VPN service delivery. By > the way, > > > I also wonder how PCEP fits into the discussion on QoS classification i= n > Section > > > 3.2.2. > > > > > > I wonder if the authors could add to Section 3.2.2 and Section 3.2.3 > e.g. a > > > message sequence chart that illustrates how what is discussed in those > sections > > > relates to PCEP? > > > > > > Michael > > > > > > > > > > > > -----Original Message----- > > > From: Teas [mailto:teas-bounces@ietf.org ] On > Behalf Of EXT Adrian Farrel > > > Sent: Friday, May 13, 2016 6:54 PM > > > To: Scharf, Michael (Nokia - DE); teas@ietf.org > > > Subject: Re: [Teas] A New I-D on PCE as a central controller > > > > > > Hello again, Michael, it seems to be my day for replying to your emails= . > > > > > > > When reading about uses cases such as L3VPN service delivery in > > > > "Section > > > 3.2.3", > > > > what is the author's view on the line of demarcation between NETCONF > > > > and PCEP? > > > > > > Well, I wonder which interface you're talking about. > > > The ones that out in here are: > > > - the interface between customer and operator > > > - the interface between "service orchestrator" and "network orchestrato= r" > > > > > > The former of these is like the interface used in L3SM. As co-chair of > L3SM, you > > > might not be surprised to hear that my view is that NETCONF is a fine > solution - > > > well, the use of a YANG data model, in any case. > > > > > > The latter is the interface between "Orchestrator / Service Manager / > OSS / > > > NMS" > > > and "PCE-based Controller" as shown on the various figures in the > picture. We > > > haven't discussed this interface in the document, and perhaps we should= . > > > > > > If you look at Figure 6 (with the hierarchy of controllers) you might > observe that > > > the parent controller could be implemented to act as though it is > talking to an NE > > > (in the abstract node model) and that means that the southbound > interface of > > > the parent controller would be PCEP. That means (of course) that the > > > northbound interface of the child controller would also be PCEP. Then, > it might > > > seem obvious that we would want all PCE implementations to behave the > same > > > way and so that makes the northbound interface of the parent PCE > > > would/could/should/might also be PCEP. > > > > > > What do you think? > > > > > > Thanks, > > > Adrian > > > > > > _______________________________________________ > > > Teas mailing list > > > Teas@ietf.org > > > https://www.ietf.org/mailman/listinfo/teas > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > > > --001a113d6bfc1d6bbd053382a1f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Michael,

The introduction to section 3 = says: =E2=80=9CAs previously mentioned, this section is intended to just ma= ke suggestions.=E2=80=9D. That sound like hypothetical to me.
Cheers,
Andy


On Mon, May 23, 2016 at 9:37 AM= , Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com> wrote:

Why doesn=E2=80=99t the d= ocument then mention that the use cases and conclusions on PCEP are hypothe= tical?

=C2=A0

Michael

=C2=A0

=C2=A0

From: Andrew G= . Malis [mailto:agma= lis@gmail.com]
Sent: Monday, May 23, 2016 3:35 PM
To: Scharf, Michael (Nokia - DE)
Cc: = adrian@olddog.co.uk; teas@ietf.org


Subject: Re: [Teas] A New I-D on PCE as a central controller<= u>

=C2=A0

Michael,

=C2=A0

I think you=E2=80=99re expecting too much from this = draft. It=E2=80=99s meant to be a very high-level informational document to= introduce the concepts and a non-exhaustive list of possible applications = and use cases. As with any such early document, there=E2=80=99s some amount of speculative writing, and there=E2=80=99s no expectation tha= t all of the discussed applications or use cases will actually come to frui= tion, and there may be others in the future that do end up being implemente= d. But the actual details of protocol changes and applications will be the topics of other standards-track draft(s) to c= ome.

=C2=A0

Cheers,

Andy

=C2=A0

=C2=A0

On Sun, May 22, 2016 at 5:34 PM, Scharf, Michael (No= kia - DE) <michael.scharf@nokia.com> wrote:

Hi Adrian,

=C2=A0

Many thanks for the tu= torial. Since RFC 7491 already acknowledges the role of a PCE, I see little= value of a high-level document that talks about PCEP as a general SBI for the topics mentioned in Section 3.2.2 and Section 3.2= .3, if that document does not discuss more specifically the impact on PCEP,= data models, etc.

=C2=A0

It should be obvious t= hat in my point of view the wording in Sections 3.2.2 and 3.2.3 is not clea= r. Just repeating the wording once again does not address my question, since I have obviously read the document and since I know the= terminology (albeit I am not a native speaker). A generic flow chart not d= etailing for which of the messages PCEP would be used, and with what conten= t, also does not address my concern.=

In any case, if the co= ntent of Section 3.2.2 and Section 3.2.3 cannot be made more explicit, it i= s impossible for me to understand whether the conclusion in Section 4 =E2=80=A6 =E2=80=9CAs such, no substantial changes to PCEP ar= e required to support the concept of a PCE-based controller. The only work = needed will be small extensions to carry additional or specific information= elements for the individual use cases.=E2=80=9D is correct and how it is actually justified for the technical areas such as Section 3= .2.2 and Section 3.2.3 .

=C2=A0

From my personal exper= ience this sort of entirely generic conclusion could perhaps be a bit of si= mplification, but this may depend on the actual use case. But in an I-D, I believe such a generic conclusion needs backing by = content and as far as I understand for Section 3.2.2 and Section 3.2.3 this= backing is lacking in the document right now.

=C2=A0

Thanks

=C2=A0

Michael

=C2=A0

=C2=A0

From: Adrian Farrel [mailto:ad= rian@olddog.co.uk]
Sent: Sunday, May 22, 2016 6:24 AM
To: Scharf, Michael (Nokia - DE)
Cc: teas@ietf.org=


Subject: RE: [Teas] A New I-D on PCE as a central controller<= u>

=C2=A0

Michael,

=C2=A0

I don't think it is complicated, but it is obvi= ously not clear from the document, so thank you for raising the concern.

=C2=A0

You say it doesn't matter which interface we= 9;re talking about, but it does. PCEP is a protocol and protocols are used = on interfaces.

=C2=A0

Let's start with southbound of the PCE. We alre= ady use PCEP on this interface. We have always done. It is what PCEP was in= vented for. And recent developments in Stateful PCE and PCE-Initiated LSPs = have made PCEP (and this interface) able to send control "commands" as well as respond to requests. Thus,= PCEP is an SBI protocol for use with signaling systems.

=C2=A0

Now, we might make several observations...

=C2=A0

In many (most?) MPLS-TE networks, every router is c= apable of being the head end of LSPs. That means that in a PCE-enabled MPLS= -TE network, every router is a PCEP speaker.

=C2=A0

Additionally, we can observe that LSPs (or PWs) can= be stitched together. The stitching, if under the control of a PCE, requir= es a special instruction to be sent to the stitching node.

=C2=A0

Furthermore, we can understand that a single end-to= -end LSP is actually the stitching of lots of single hop LSPs. That is real= ly what a statically provisioned LSP is.=

=C2=A0

Finally, we can see a desire to send TE instruction= s from a computation engine (e.g., PCE) to individual network nodes to prog= ram their forwarding. For example, in a Segment Routed network or for stati= c MPLS-TE LSPs.

=C2=A0

=C2=A0

Put all of this together with the recognition that = all TE path management is fundamentally the same and can be performed by th= e same engine, and that it does not make sense for such an engine to have t= o implement multiple SBI protocols, and you end up with this draft.

=C2=A0

I don't think we are saying that this approach = is compulsory, but we are saying that it is possible. Other possibilities e= xist including using NETCONF/YANG in place of PCEP, and enhancing BGP in pl= ace of PCEP. Others have suggested XMPP. Frankly, if we were proposing a new protocol it would be correct to tell u= s not to, and to persuade us that one of the other protocols will do the jo= b. But here we are with three (or four) protocols that fit the bill: each c= urrently covers some of the function space and each could easily be extended to cover the whole space. I'm = not capable of saying how to decide which protocol does which function, but= I do see pressures of implementation and deployment that lead to this draf= t.

=C2=A0

[Historic note: I was somewhat opposed to adding PC= E-Initiated LSP support to PCEP. I thought this bent the architecture furth= er than was originally intended. But we went there in the PEC WG and the I-= D is now "complete". By adding support of PCE initiation of LSPs, we naturally opened the path to this document. = FWIW, this is not the first time that PCEP has been discussed as a more gen= eral SBI protocol - RFC 7491 shows it in this context although does not dis= cuss it much (we should probably add a reference to ABNO in this document).]

=C2=A0

=C2=A0

Now, you say you are surprised that "the docum= ent focuses on using PCEP e.g. for L3VPN service delivery." I think th= ere is a significant difference between *requesting* a service and *deliver= ing* that service. The service request (as, for example, in L3SM) does not involve a PCE and is easily achieved using = a YANG model which, if the service request is on-line, can be delivered usi= ng NETCONF. However, service delivery requires "orchestration". O= rchestration is the process of considering available network resources and selecting what will be provisioned to supp= ort the service. A PCE is at least a key feature of orchestration, just as = it is a key component of a network controller.

=C2=A0

But the document does NOT focus on PCEP in quite th= e way you describe. In fact, the only discussion is in 3.2.3 (just two para= graphs in the whole document) where the focus is on the use of a PCE-based = central controller that can "consider the whole network and all components of a service at once when planning ho= w to deliver the service." It then goes on to observe that PCEP can be= used "to manage the network resources and to install the necessary as= sociations between those resources."

=C2=A0

=C2=A0

If we included a message flow chart it would look s= omething like...

=C2=A0

Servi= ce Manager=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 PCE-based Controller=C2=A0=C2=A0= =C2=A0=C2=A0 NEs

=C2= =A0=C2=A0=C2=A0=C2=A0 Request service--------->=

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Co= mpute

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Provision ------>

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <------------- Ack

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Up= date DBs

=C2= =A0=C2=A0=C2=A0=C2=A0 <-------------------Ack

=C2= =A0

If th= at simple figure helps with the understanding of this or any other part of = the document, we can surely add it.<= /span>

=C2= =A0

Cheer= s,

Adria= n

=C2=A0

> -----Original Message-----

> From: Scharf, Michael (Nokia - DE) [mailto:michael.s= charf@nokia.com]

> Sent: 20 May 2016 19:07

> To: adrian@olddog.co.uk; teas@ietf.org

> Subject: RE: [Teas] A New I-D on PCE as= a central controller

> =

> As I said, I specifically wonder about Section= 3.2.3 "Service Delivery", which states<= u>

> (omitting some parts that are not relevant her= e):

> =

> "Various network services may be offered = over a network. These include=

> protection services [...] Virtual Private Netw= ork (VPN) service (such as Layer 3

> VPNs [RFC4364] or Ethernet VPNs [RFC7432]), or= Pseudowires [RFC3985]. [...]=C2=A0 A

> PCE-based central control can consider the who= le network and all components of

> a service at once when planning how to deliver= the service. It can then use PCEP

> to manage the network resources and to install= the necessary associations

> between those resources."

> =

> This wording on use of PCEP confuses me, no ma= tter what interface we talk

> about. I would have assumed that YANG-based pr= otocols such as

> NETCONF/RESTCONF could be useful in this conte= xt, and I am a bit surprised that

> the document focuses on using PCEP e.g. for L3= VPN service delivery. By the way,

> I also wonder how PCEP fits into the discussio= n on QoS classification in Section

> 3.2.2.<= /span>

> =

> I wonder if the authors could add to Section 3= .2.2 and Section 3.2.3 e.g. a=

> message sequence chart that illustrates how wh= at is discussed in those sections

> relates to PCEP?

> =

> Michael=

> =

> =

> =

> -----Original Message-----

> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of EXT= Adrian Farrel

> Sent: Friday, May 13, 2016 6:54 PM

> To: Scharf, Michael (Nokia - DE); teas@ietf.org

> Subject: Re: [Teas] A New I-D on PCE as a cent= ral controller

> =

> Hello again, Michael, it seems to be my day fo= r replying to your emails.

> =

> > When reading about uses cases such as L3V= PN service delivery in

> > "Section=

> 3.2.3",

> > what is the author's view on the line= of demarcation between NETCONF

> > and PCEP?=

> =

> Well, I wonder which interface you're talk= ing about.

> The ones that out in here are:

> - the interface between customer and operator<= /span>

> - the interface between "service orchestr= ator" and "network orchestrator"=

> =

> The former of these is like the interface used= in L3SM. As co-chair of L3SM, you

> might not be surprised to hear that my view is= that NETCONF is a fine solution -

> well, the use of a YANG data model, in any cas= e.

> =

> The latter is the interface between "Orch= estrator / Service Manager / OSS /

> NMS"

> and "PCE-based Controller" as shown = on the various figures in the picture. We

> haven't discussed this interface in the do= cument, and perhaps we should.

> =

> If you look at Figure 6 (with the hierarchy of= controllers) you might observe that=

> the parent controller could be implemented to = act as though it is talking to an NE=

> (in the abstract node model) and that means th= at the southbound interface of

> the parent controller would be PCEP. That mean= s (of course) that the

> northbound interface of the child controller w= ould also be PCEP. Then, it might

> seem obvious that we would want all PCE implem= entations to behave the same<= /p>

> way and so that makes the northbound interface= of the parent PCE

> would/could/should/might also be PCEP.<= span lang=3D"DE">

> =

> What do you think?=

> =

> Thanks,=

> Adrian<= /span>

> =

> ______________________________________________= _

> Teas mailing list<= /u>

> Teas@ietf.org

> https://www.ietf.org/mailman/listinfo/teas<= /u>


_______________________________________________
Teas mailing list
Teas@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/teas

=C2=A0


--001a113d6bfc1d6bbd053382a1f9-- From nobody Mon May 23 06:52:09 2016 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 9FE5612D8F8 for ; Mon, 23 May 2016 06:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 Fr5sahVEWndM for ; Mon, 23 May 2016 06:52:05 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC6DE12D8F7 for ; Mon, 23 May 2016 06:52:04 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CPI52701; Mon, 23 May 2016 13:52:01 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 23 May 2016 14:52:00 +0100 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Mon, 23 May 2016 06:51:53 -0700 From: Igor Bryskin To: Cyril Margaria , Xufeng Liu Thread-Topic: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo Thread-Index: AdGvdpxN0yo8TMwnRjC4jbLnP05ymwFvMywAAA51YLA= Date: Mon, 23 May 2016 13:51:53 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908EDCB0A@dfweml501-mbx> References: <02d101d1af76$b0317cd0$10947670$@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.253.100] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908EDCB0Adfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.57430B02.013C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ab9c02f803473b3c816b6bb401f2f1e5 Archived-At: Cc: TEAS WG Subject: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 13:52:07 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908EDCB0Adfweml501mbx_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q3lyaWwsDQoNCllvdSBhcmUgYWJzb2x1dGVseSByaWdodC4gQnV0IHRoaXMgYmVsb25ncyB0byB0 aGUgbGF5ZXIgc3BlY2lmaWMgYXVnbWVudGF0aW9ucywgYWdyZWVkPw0KDQpPbiB0aGUgb3RoZXIg aGFuZCBJIGRvIGEgc2VlIGEgdmFsdWUgaW4gYWRkaW5nIGFuIGFic3RyYWN0IGxhYmVsIHRvIHRo ZSBjb25uZWN0aXZpdHkgbWF0cml4IChqdXN0IGxpa2UgYSBsYWJlbCBvYmplY3QgaW4gdGhlIFRF IHBhdGgpLCBzbyB0aGUgYmFzaWMgbW9kZWwgd2lsbCBiZSBtb3JlIGNvbXBsZXRlIHRvIGFkZHJl c3MgbW9yZSB0aGFuIG9uZSBsYXllci4NCg0KSWdvcg0KDQpGcm9tOiBUZWFzIFttYWlsdG86dGVh cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ3lyaWwgTWFyZ2FyaWENClNlbnQ6IE1v bmRheSwgTWF5IDIzLCAyMDE2IDk6NDEgQU0NClRvOiBYdWZlbmcgTGl1DQpDYzogVEVBUyBXRw0K U3ViamVjdDogUmU6IFtUZWFzXSBDb25uZWN0aXZpdHkgbWF0cml4IGluIGRyYWZ0LWlldGYtdGVh cy15YW5nLXRlLXRvcG8NCg0KSGksDQpBbm90aGVyIGl0ZW0gdGhhdCBjYW4gYmUgY29uc2lkZXJl ZCBpcyB0byBhZGQgYSBMYWJlbCAoRm9sbG93aW5nIFJGQzc1NzkpIHJlc3RyaWN0aW9ucy4gVGhp cyBpcyBuZWVkZWQsIGZvciBleGFtcGxlLCAgaW4gY2FzZSBvZiBGaXhlZCBtdXhwb25kZXJzLCB3 aGVyZSB0aGUgY29ubmVjdGl2aXR5IGJldHdlZW4gdGhlIExvdyBvcmRlciBPRFVzIHRvIHRoZSBo aWdoLW9yZGVyIE9EVSBpcyBmaXhlZCBvbiBlYWNoIGVuZC4NCkNhbiBpdCBiZSBhZGRlZCB0byB0 aGUgbGlzdCBvZiBjaGFuZ2VzIGZvciB0aGUgY29ubmVjdGl2aXR5IG1hdHJpeD8NCg0KVGhhbmtz LA0KQ3lyaWwNCg0KT24gMTYgTWF5IDIwMTYgYXQgMDk6MjcsIFh1ZmVuZyBMaXUgPHh1ZmVuZy5s aXUuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnh1ZmVuZy5saXUuaWV0ZkBnbWFpbC5jb20+PiB3cm90 ZToNCkF1dGhvcnMgYW5kIGNvbnRyaWJ1dG9ycyBoYXZlIGRpc2N1c3NlZCB0aGUgdXNlIGNhc2Ug b2YgYWJzdHJhY3QgdG9wb2xvZ3ksDQp0byBhZGRyZXNzIHRoZSBpbmNvbXBsZXRlbmVzcyBvZiBj b25uZWN0aXZpdHkgbWF0cml4Lg0KDQpDdXJyZW50IGNvbm5lY3Rpdml0eSBtb2RlbGluZyBpcyBh cyBmb2xsb3dzOg0KDQogICAgICB8ICAgICArLS1ydyBjb25uZWN0aXZpdHktbWF0cml4KiBbaWRd DQogICAgICB8ICAgICB8ICArLS1ydyBpZCAgICAgICAgICAgIHVpbnQzMg0KICAgICAgfCAgICAg fCAgKy0tcncgZnJvbQ0KICAgICAgfCAgICAgfCAgfCAgKy0tcncgdHAtcmVmPyAgIGxlYWZyZWYN CiAgICAgIHwgICAgIHwgICstLXJ3IHRvDQogICAgICB8ICAgICB8ICB8ICArLS1ydyB0cC1yZWY/ ICAgbGVhZnJlZg0KICAgICAgfCAgICAgfCAgKy0tcncgaXMtYWxsb3dlZD8gICBCb29sZWFuDQoN CkEgTGluayBUUCBtYXkgY29ubmVjdCBvciBkaXNjb25uZWN0IHRvIGFub3RoZXIgTGluayBUUCwg d2l0aG91dCBkZXRhaWxlZA0KaW5mb3JtYXRpb24gc3VjaCBhcyBjb3N0IGFuZCByZXNvdXJjZSBz aGFyaW5nIHJlc3RyaWN0aW9uLiBUbyBnZXQgYSBiZXR0ZXINCmFic3RyYWN0aW9uIG9mIHN1Y2gg Y29ubmVjdGl2aXR5LCB0aGUgZm9sbG93aW5nIGFkZGl0aW9uYWwgYXR0cmlidXRlcyBhcmUNCnBs YW5uZWQgdG8gYmUgYWRkZWQ6DQoNCiAgbWF4LWJhbmR3aWR0aD8gICAgICAgICAgICAgICBkZWNp bWFsNjQNCiAgbWF4LXJlc3YtYmFuZHdpZHRoPyAgICAgICAgICBkZWNpbWFsNjQNCiAgdW5yZXNl cnZlZC1iYW5kd2lkdGgqIFtwcmlvcml0eV0NCiAgcHJpb3JpdHkgICAgIHVpbnQ4DQogICAgICst LSBiYW5kd2lkdGg/ICAgZGVjaW1hbDY0DQogICAgICstLSB0ZS1kZWZhdWx0LW1ldHJpYyB1aW50 MzINCiAgcGVyZm9ybWFuY2UtbWV0cmljIC8vIHJlLXVzZSB0aGUgY29udGFpbmVyIGZyb20gdGUt bGluay1hdHJyaWJ1dGVzDQogIHRlLXNybGdzICAgICAgICAgICAvLyByZS11c2UgdGhlIGNvbnRh aW5lciBmcm9tIHRlLWxpbmstYXRycmlidXRlcw0KDQpDb21tZW50cyBhcmUgd2VsY29tZS4NCg0K VGhhbmtzLA0KDQotIFh1ZmVuZw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpUZWFzIG1haWxpbmcgbGlzdA0KVGVhc0BpZXRmLm9yZzxtYWlsdG86 VGVhc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGVh cw0KDQo= --_000_0C72C38E7EBC34499E8A9E7DD007863908EDCB0Adfweml501mbx_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbWJyaWE7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1 IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFu b3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAu TXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYW1icmlhIiwic2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FtYnJpYSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5DeXJpbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FtYnJpYSZxdW90OywmcXVvdDtzZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FtYnJpYSZx dW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Zb3UgYXJlIGFic29sdXRlbHkg cmlnaHQuIEJ1dCB0aGlzIGJlbG9uZ3MgdG8gdGhlIGxheWVyIHNwZWNpZmljIGF1Z21lbnRhdGlv bnMsIGFncmVlZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FtYnJpYSZxdW90OywmcXVvdDtzZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FtYnJpYSZxdW90 OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PbiB0aGUgb3RoZXIgaGFuZCBJIGRv IGEgc2VlIGEgdmFsdWUgaW4gYWRkaW5nIGFuIGFic3RyYWN0IGxhYmVsIHRvIHRoZSBjb25uZWN0 aXZpdHkgbWF0cml4IChqdXN0IGxpa2UgYSBsYWJlbCBvYmplY3QgaW4gdGhlIFRFIHBhdGgpLCBz byB0aGUgYmFzaWMgbW9kZWwgd2lsbCBiZSBtb3JlIGNvbXBsZXRlIHRvDQogYWRkcmVzcyBtb3Jl IHRoYW4gb25lIGxheWVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYW1icmlhJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYW1icmlh JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklnb3I8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FtYnJpYSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVGVhcyBbbWFpbHRvOnRlYXMtYm91 bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Q3lyaWwgTWFyZ2FyaWE8YnI+DQo8 Yj5TZW50OjwvYj4gTW9uZGF5LCBNYXkgMjMsIDIwMTYgOTo0MSBBTTxicj4NCjxiPlRvOjwvYj4g WHVmZW5nIExpdTxicj4NCjxiPkNjOjwvYj4gVEVBUyBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW1RlYXNdIENvbm5lY3Rpdml0eSBtYXRyaXggaW4gZHJhZnQtaWV0Zi10ZWFzLXlhbmctdGUt dG9wbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSwgPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+QW5vdGhlciBpdGVtIHRoYXQgY2FuIGJlIGNvbnNpZGVyZWQgaXMgdG8gYWRkIGEg TGFiZWwgKEZvbGxvd2luZyBSRkM3NTc5KSByZXN0cmljdGlvbnMuIFRoaXMgaXMgbmVlZGVkLCBm b3IgZXhhbXBsZSwmbmJzcDsgaW4gY2FzZSBvZiBGaXhlZCBtdXhwb25kZXJzLCB3aGVyZSB0aGUg Y29ubmVjdGl2aXR5IGJldHdlZW4gdGhlIExvdyBvcmRlciBPRFVzIHRvIHRoZSBoaWdoLW9yZGVy DQogT0RVIGlzIGZpeGVkIG9uIGVhY2ggZW5kLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2FuIGl0IGJlIGFkZGVkIHRvIHRoZSBsaXN0IG9mIGNo YW5nZXMgZm9yIHRoZSBjb25uZWN0aXZpdHkgbWF0cml4PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcywgPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkN5cmlsIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gMTYgTWF5IDIwMTYgYXQgMDk6MjcsIFh1ZmVuZyBMaXUgJmx0 OzxhIGhyZWY9Im1haWx0bzp4dWZlbmcubGl1LmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFu ayI+eHVmZW5nLmxpdS5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXV0aG9ycyBhbmQgY29udHJpYnV0b3JzIGhhdmUgZGlz Y3Vzc2VkIHRoZSB1c2UgY2FzZSBvZiBhYnN0cmFjdCB0b3BvbG9neSw8YnI+DQp0byBhZGRyZXNz IHRoZSBpbmNvbXBsZXRlbmVzcyBvZiBjb25uZWN0aXZpdHkgbWF0cml4Ljxicj4NCjxicj4NCkN1 cnJlbnQgY29ubmVjdGl2aXR5IG1vZGVsaW5nIGlzIGFzIGZvbGxvd3M6PGJyPg0KPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3IGNvbm5lY3Rp dml0eS1tYXRyaXgqIFtpZF08YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNw OyAmbmJzcDt8Jm5ic3A7ICYjNDM7LS1ydyBpZCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IHVpbnQzMjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgJm5i c3A7ICZuYnNwO3wmbmJzcDsgJiM0MzstLXJ3IGZyb208YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyB8Jm5ic3A7ICZuYnNwOyAmbmJzcDt8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IHRwLXJlZj8m bmJzcDsgJm5ic3A7bGVhZnJlZjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgJm5i c3A7ICZuYnNwO3wmbmJzcDsgJiM0MzstLXJ3IHRvPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg fCZuYnNwOyAmbmJzcDsgJm5ic3A7fCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyB0cC1yZWY/Jm5i c3A7ICZuYnNwO2xlYWZyZWY8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNw OyAmbmJzcDt8Jm5ic3A7ICYjNDM7LS1ydyBpcy1hbGxvd2VkPyZuYnNwOyAmbmJzcDtCb29sZWFu PGJyPg0KPGJyPg0KQSBMaW5rIFRQIG1heSBjb25uZWN0IG9yIGRpc2Nvbm5lY3QgdG8gYW5vdGhl ciBMaW5rIFRQLCB3aXRob3V0IGRldGFpbGVkPGJyPg0KaW5mb3JtYXRpb24gc3VjaCBhcyBjb3N0 IGFuZCByZXNvdXJjZSBzaGFyaW5nIHJlc3RyaWN0aW9uLiBUbyBnZXQgYSBiZXR0ZXI8YnI+DQph YnN0cmFjdGlvbiBvZiBzdWNoIGNvbm5lY3Rpdml0eSwgdGhlIGZvbGxvd2luZyBhZGRpdGlvbmFs IGF0dHJpYnV0ZXMgYXJlPGJyPg0KcGxhbm5lZCB0byBiZSBhZGRlZDo8YnI+DQo8YnI+DQombmJz cDsgbWF4LWJhbmR3aWR0aD8mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ZGVjaW1hbDY0PGJyPg0KJm5ic3A7IG1heC1yZXN2LWJhbmR3aWR0aD8m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGRlY2ltYWw2NDxicj4NCiZuYnNwOyB1 bnJlc2VydmVkLWJhbmR3aWR0aCogW3ByaW9yaXR5XTxicj4NCiZuYnNwOyBwcmlvcml0eSZuYnNw OyAmbmJzcDsgJm5ic3A7dWludDg8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS0gYmFu ZHdpZHRoPyZuYnNwOyAmbmJzcDtkZWNpbWFsNjQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyYj NDM7LS0gdGUtZGVmYXVsdC1tZXRyaWMgdWludDMyPGJyPg0KJm5ic3A7IHBlcmZvcm1hbmNlLW1l dHJpYyAvLyByZS11c2UgdGhlIGNvbnRhaW5lciBmcm9tIHRlLWxpbmstYXRycmlidXRlczxicj4N CiZuYnNwOyB0ZS1zcmxncyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Ly8gcmUtdXNlIHRoZSBjb250YWluZXIgZnJvbSB0ZS1saW5rLWF0cnJpYnV0ZXM8YnI+DQo8YnI+ DQpDb21tZW50cyBhcmUgd2VsY29tZS48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KPGJyPg0KLSBY dWZlbmc8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NClRlYXMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv OlRlYXNAaWV0Zi5vcmciPlRlYXNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90ZWFzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90ZWFzPC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_0C72C38E7EBC34499E8A9E7DD007863908EDCB0Adfweml501mbx_-- From nobody Mon May 23 06:52:54 2016 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 2177712B034 for ; Mon, 23 May 2016 06:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dx099xtch6bt for ; Mon, 23 May 2016 06:52:50 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE23612D8F9 for ; Mon, 23 May 2016 06:52:48 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id A2B5C47663F2E; Mon, 23 May 2016 13:52:43 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4NDqk9I013153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 May 2016 13:52:46 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u4NDqepY007813 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 May 2016 15:52:45 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.44]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 23 May 2016 15:52:29 +0200 From: "Scharf, Michael (Nokia - DE)" To: "Andrew G. Malis" Thread-Topic: [Teas] A New I-D on PCE as a central controller Thread-Index: AdGnosEWtnZGzgfkR5SQqz0Nm22cLQEn1m5QADlM4QABYpJEYABH2DeAACYha5AAH2sWgAAEO36g///gcID//9z9YA== Date: Mon, 23 May 2016 13:52:29 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48863026@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <0c6c01d1a7a2$f1a24860$d4e6d920$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48846127@FR712WXCHMBA15.zeu.alcatel-lucent.com> <042101d1ad38$12da5f50$388f1df0$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48860ADB@FR712WXCHMBA15.zeu.alcatel-lucent.com> <001d01d1b3e1$bec637d0$3c52a770$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48862397@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48862F8B@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D48863026FR712WXCHMBA15z_" MIME-Version: 1.0 Archived-At: Cc: "adrian@olddog.co.uk" , "teas@ietf.org" Subject: Re: [Teas] A New I-D on PCE as a central controller X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 13:52:53 -0000 --_000_655C07320163294895BBADA28372AF5D48863026FR712WXCHMBA15z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RmFpciBwb2ludC4gQnV0IFNlY3Rpb24gNCBzaG91bGQgYWxzbyBiZSBtb3JlIGV4cGxpY2l0IHRo YXQgdGhlIGNvbmNsdXNpb24gdGhlcmUgYXMgaHlwb3RoZXRpY2FsIGFzIHRoZSB1c2UgY2FzZXMg U2VjdGlvbiAzLg0KDQpUaGlzIHdvdWxkIG5vdCBmaXggdGhlIHByb2JsZW0gd2l0aCBTZWN0aW9u IDMuMi4yIGFuZCBTZWN0aW9uIDMuMi4zIGJ1dCBhdCBsZWFzdCBtYWtlIGNsZWFyIHRoYXQgU2Vj dGlvbiA0IGlzIHB1cmUgc3BlY3VsYXRpb24gb25seS4NCg0KTWljaGFlbA0KDQoNCkZyb206IEFu ZHJldyBHLiBNYWxpcyBbbWFpbHRvOmFnbWFsaXNAZ21haWwuY29tXQ0KU2VudDogTW9uZGF5LCBN YXkgMjMsIDIwMTYgMzo0MyBQTQ0KVG86IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSkNCkNj OiBhZHJpYW5Ab2xkZG9nLmNvLnVrOyB0ZWFzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1RlYXNd IEEgTmV3IEktRCBvbiBQQ0UgYXMgYSBjZW50cmFsIGNvbnRyb2xsZXINCg0KTWljaGFlbCwNCg0K VGhlIGludHJvZHVjdGlvbiB0byBzZWN0aW9uIDMgc2F5czog4oCcQXMgcHJldmlvdXNseSBtZW50 aW9uZWQsIHRoaXMgc2VjdGlvbiBpcyBpbnRlbmRlZCB0byBqdXN0IG1ha2Ugc3VnZ2VzdGlvbnMu 4oCdLiBUaGF0IHNvdW5kIGxpa2UgaHlwb3RoZXRpY2FsIHRvIG1lLg0KDQpDaGVlcnMsDQpBbmR5 DQoNCg0KT24gTW9uLCBNYXkgMjMsIDIwMTYgYXQgOTozNyBBTSwgU2NoYXJmLCBNaWNoYWVsIChO b2tpYSAtIERFKSA8bWljaGFlbC5zY2hhcmZAbm9raWEuY29tPG1haWx0bzptaWNoYWVsLnNjaGFy ZkBub2tpYS5jb20+PiB3cm90ZToNCldoeSBkb2VzbuKAmXQgdGhlIGRvY3VtZW50IHRoZW4gbWVu dGlvbiB0aGF0IHRoZSB1c2UgY2FzZXMgYW5kIGNvbmNsdXNpb25zIG9uIFBDRVAgYXJlIGh5cG90 aGV0aWNhbD8NCg0KTWljaGFlbA0KDQoNCkZyb206IEFuZHJldyBHLiBNYWxpcyBbbWFpbHRvOmFn bWFsaXNAZ21haWwuY29tPG1haWx0bzphZ21hbGlzQGdtYWlsLmNvbT5dDQpTZW50OiBNb25kYXks IE1heSAyMywgMjAxNiAzOjM1IFBNDQpUbzogU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFKQ0K Q2M6IGFkcmlhbkBvbGRkb2cuY28udWs8bWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWs+OyB0ZWFz QGlldGYub3JnPG1haWx0bzp0ZWFzQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW1RlYXNdIEEg TmV3IEktRCBvbiBQQ0UgYXMgYSBjZW50cmFsIGNvbnRyb2xsZXINCg0KTWljaGFlbCwNCg0KSSB0 aGluayB5b3XigJlyZSBleHBlY3RpbmcgdG9vIG11Y2ggZnJvbSB0aGlzIGRyYWZ0LiBJdOKAmXMg bWVhbnQgdG8gYmUgYSB2ZXJ5IGhpZ2gtbGV2ZWwgaW5mb3JtYXRpb25hbCBkb2N1bWVudCB0byBp bnRyb2R1Y2UgdGhlIGNvbmNlcHRzIGFuZCBhIG5vbi1leGhhdXN0aXZlIGxpc3Qgb2YgcG9zc2li bGUgYXBwbGljYXRpb25zIGFuZCB1c2UgY2FzZXMuIEFzIHdpdGggYW55IHN1Y2ggZWFybHkgZG9j dW1lbnQsIHRoZXJl4oCZcyBzb21lIGFtb3VudCBvZiBzcGVjdWxhdGl2ZSB3cml0aW5nLCBhbmQg dGhlcmXigJlzIG5vIGV4cGVjdGF0aW9uIHRoYXQgYWxsIG9mIHRoZSBkaXNjdXNzZWQgYXBwbGlj YXRpb25zIG9yIHVzZSBjYXNlcyB3aWxsIGFjdHVhbGx5IGNvbWUgdG8gZnJ1aXRpb24sIGFuZCB0 aGVyZSBtYXkgYmUgb3RoZXJzIGluIHRoZSBmdXR1cmUgdGhhdCBkbyBlbmQgdXAgYmVpbmcgaW1w bGVtZW50ZWQuIEJ1dCB0aGUgYWN0dWFsIGRldGFpbHMgb2YgcHJvdG9jb2wgY2hhbmdlcyBhbmQg YXBwbGljYXRpb25zIHdpbGwgYmUgdGhlIHRvcGljcyBvZiBvdGhlciBzdGFuZGFyZHMtdHJhY2sg ZHJhZnQocykgdG8gY29tZS4NCg0KQ2hlZXJzLA0KQW5keQ0KDQoNCk9uIFN1biwgTWF5IDIyLCAy MDE2IGF0IDU6MzQgUE0sIFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSkgPG1pY2hhZWwuc2No YXJmQG5va2lhLmNvbTxtYWlsdG86bWljaGFlbC5zY2hhcmZAbm9raWEuY29tPj4gd3JvdGU6DQpI aSBBZHJpYW4sDQoNCk1hbnkgdGhhbmtzIGZvciB0aGUgdHV0b3JpYWwuIFNpbmNlIFJGQyA3NDkx IGFscmVhZHkgYWNrbm93bGVkZ2VzIHRoZSByb2xlIG9mIGEgUENFLCBJIHNlZSBsaXR0bGUgdmFs dWUgb2YgYSBoaWdoLWxldmVsIGRvY3VtZW50IHRoYXQgdGFsa3MgYWJvdXQgUENFUCBhcyBhIGdl bmVyYWwgU0JJIGZvciB0aGUgdG9waWNzIG1lbnRpb25lZCBpbiBTZWN0aW9uIDMuMi4yIGFuZCBT ZWN0aW9uIDMuMi4zLCBpZiB0aGF0IGRvY3VtZW50IGRvZXMgbm90IGRpc2N1c3MgbW9yZSBzcGVj aWZpY2FsbHkgdGhlIGltcGFjdCBvbiBQQ0VQLCBkYXRhIG1vZGVscywgZXRjLg0KDQpJdCBzaG91 bGQgYmUgb2J2aW91cyB0aGF0IGluIG15IHBvaW50IG9mIHZpZXcgdGhlIHdvcmRpbmcgaW4gU2Vj dGlvbnMgMy4yLjIgYW5kIDMuMi4zIGlzIG5vdCBjbGVhci4gSnVzdCByZXBlYXRpbmcgdGhlIHdv cmRpbmcgb25jZSBhZ2FpbiBkb2VzIG5vdCBhZGRyZXNzIG15IHF1ZXN0aW9uLCBzaW5jZSBJIGhh dmUgb2J2aW91c2x5IHJlYWQgdGhlIGRvY3VtZW50IGFuZCBzaW5jZSBJIGtub3cgdGhlIHRlcm1p bm9sb2d5IChhbGJlaXQgSSBhbSBub3QgYSBuYXRpdmUgc3BlYWtlcikuIEEgZ2VuZXJpYyBmbG93 IGNoYXJ0IG5vdCBkZXRhaWxpbmcgZm9yIHdoaWNoIG9mIHRoZSBtZXNzYWdlcyBQQ0VQIHdvdWxk IGJlIHVzZWQsIGFuZCB3aXRoIHdoYXQgY29udGVudCwgYWxzbyBkb2VzIG5vdCBhZGRyZXNzIG15 IGNvbmNlcm4uDQpJbiBhbnkgY2FzZSwgaWYgdGhlIGNvbnRlbnQgb2YgU2VjdGlvbiAzLjIuMiBh bmQgU2VjdGlvbiAzLjIuMyBjYW5ub3QgYmUgbWFkZSBtb3JlIGV4cGxpY2l0LCBpdCBpcyBpbXBv c3NpYmxlIGZvciBtZSB0byB1bmRlcnN0YW5kIHdoZXRoZXIgdGhlIGNvbmNsdXNpb24gaW4gU2Vj dGlvbiA0IOKApiDigJxBcyBzdWNoLCBubyBzdWJzdGFudGlhbCBjaGFuZ2VzIHRvIFBDRVAgYXJl IHJlcXVpcmVkIHRvIHN1cHBvcnQgdGhlIGNvbmNlcHQgb2YgYSBQQ0UtYmFzZWQgY29udHJvbGxl ci4gVGhlIG9ubHkgd29yayBuZWVkZWQgd2lsbCBiZSBzbWFsbCBleHRlbnNpb25zIHRvIGNhcnJ5 IGFkZGl0aW9uYWwgb3Igc3BlY2lmaWMgaW5mb3JtYXRpb24gZWxlbWVudHMgZm9yIHRoZSBpbmRp dmlkdWFsIHVzZSBjYXNlcy7igJ0gaXMgY29ycmVjdCBhbmQgaG93IGl0IGlzIGFjdHVhbGx5IGp1 c3RpZmllZCBmb3IgdGhlIHRlY2huaWNhbCBhcmVhcyBzdWNoIGFzIFNlY3Rpb24gMy4yLjIgYW5k IFNlY3Rpb24gMy4yLjMgLg0KDQpGcm9tIG15IHBlcnNvbmFsIGV4cGVyaWVuY2UgdGhpcyBzb3J0 IG9mIGVudGlyZWx5IGdlbmVyaWMgY29uY2x1c2lvbiBjb3VsZCBwZXJoYXBzIGJlIGEgYml0IG9m IHNpbXBsaWZpY2F0aW9uLCBidXQgdGhpcyBtYXkgZGVwZW5kIG9uIHRoZSBhY3R1YWwgdXNlIGNh c2UuIEJ1dCBpbiBhbiBJLUQsIEkgYmVsaWV2ZSBzdWNoIGEgZ2VuZXJpYyBjb25jbHVzaW9uIG5l ZWRzIGJhY2tpbmcgYnkgY29udGVudCBhbmQgYXMgZmFyIGFzIEkgdW5kZXJzdGFuZCBmb3IgU2Vj dGlvbiAzLjIuMiBhbmQgU2VjdGlvbiAzLjIuMyB0aGlzIGJhY2tpbmcgaXMgbGFja2luZyBpbiB0 aGUgZG9jdW1lbnQgcmlnaHQgbm93Lg0KDQpUaGFua3MNCg0KTWljaGFlbA0KDQoNCkZyb206IEFk cmlhbiBGYXJyZWwgW21haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrPG1haWx0bzphZHJpYW5Ab2xk ZG9nLmNvLnVrPl0NClNlbnQ6IFN1bmRheSwgTWF5IDIyLCAyMDE2IDY6MjQgQU0NClRvOiBTY2hh cmYsIE1pY2hhZWwgKE5va2lhIC0gREUpDQpDYzogdGVhc0BpZXRmLm9yZzxtYWlsdG86dGVhc0Bp ZXRmLm9yZz4NCg0KU3ViamVjdDogUkU6IFtUZWFzXSBBIE5ldyBJLUQgb24gUENFIGFzIGEgY2Vu dHJhbCBjb250cm9sbGVyDQoNCg0KTWljaGFlbCwNCg0KDQoNCkkgZG9uJ3QgdGhpbmsgaXQgaXMg Y29tcGxpY2F0ZWQsIGJ1dCBpdCBpcyBvYnZpb3VzbHkgbm90IGNsZWFyIGZyb20gdGhlIGRvY3Vt ZW50LCBzbyB0aGFuayB5b3UgZm9yIHJhaXNpbmcgdGhlIGNvbmNlcm4uDQoNCg0KDQpZb3Ugc2F5 IGl0IGRvZXNuJ3QgbWF0dGVyIHdoaWNoIGludGVyZmFjZSB3ZSdyZSB0YWxraW5nIGFib3V0LCBi dXQgaXQgZG9lcy4gUENFUCBpcyBhIHByb3RvY29sIGFuZCBwcm90b2NvbHMgYXJlIHVzZWQgb24g aW50ZXJmYWNlcy4NCg0KDQoNCkxldCdzIHN0YXJ0IHdpdGggc291dGhib3VuZCBvZiB0aGUgUENF LiBXZSBhbHJlYWR5IHVzZSBQQ0VQIG9uIHRoaXMgaW50ZXJmYWNlLiBXZSBoYXZlIGFsd2F5cyBk b25lLiBJdCBpcyB3aGF0IFBDRVAgd2FzIGludmVudGVkIGZvci4gQW5kIHJlY2VudCBkZXZlbG9w bWVudHMgaW4gU3RhdGVmdWwgUENFIGFuZCBQQ0UtSW5pdGlhdGVkIExTUHMgaGF2ZSBtYWRlIFBD RVAgKGFuZCB0aGlzIGludGVyZmFjZSkgYWJsZSB0byBzZW5kIGNvbnRyb2wgImNvbW1hbmRzIiBh cyB3ZWxsIGFzIHJlc3BvbmQgdG8gcmVxdWVzdHMuIFRodXMsIFBDRVAgaXMgYW4gU0JJIHByb3Rv Y29sIGZvciB1c2Ugd2l0aCBzaWduYWxpbmcgc3lzdGVtcy4NCg0KDQoNCk5vdywgd2UgbWlnaHQg bWFrZSBzZXZlcmFsIG9ic2VydmF0aW9ucy4uLg0KDQoNCg0KSW4gbWFueSAobW9zdD8pIE1QTFMt VEUgbmV0d29ya3MsIGV2ZXJ5IHJvdXRlciBpcyBjYXBhYmxlIG9mIGJlaW5nIHRoZSBoZWFkIGVu ZCBvZiBMU1BzLiBUaGF0IG1lYW5zIHRoYXQgaW4gYSBQQ0UtZW5hYmxlZCBNUExTLVRFIG5ldHdv cmssIGV2ZXJ5IHJvdXRlciBpcyBhIFBDRVAgc3BlYWtlci4NCg0KDQoNCkFkZGl0aW9uYWxseSwg d2UgY2FuIG9ic2VydmUgdGhhdCBMU1BzIChvciBQV3MpIGNhbiBiZSBzdGl0Y2hlZCB0b2dldGhl ci4gVGhlIHN0aXRjaGluZywgaWYgdW5kZXIgdGhlIGNvbnRyb2wgb2YgYSBQQ0UsIHJlcXVpcmVz IGEgc3BlY2lhbCBpbnN0cnVjdGlvbiB0byBiZSBzZW50IHRvIHRoZSBzdGl0Y2hpbmcgbm9kZS4N Cg0KDQoNCkZ1cnRoZXJtb3JlLCB3ZSBjYW4gdW5kZXJzdGFuZCB0aGF0IGEgc2luZ2xlIGVuZC10 by1lbmQgTFNQIGlzIGFjdHVhbGx5IHRoZSBzdGl0Y2hpbmcgb2YgbG90cyBvZiBzaW5nbGUgaG9w IExTUHMuIFRoYXQgaXMgcmVhbGx5IHdoYXQgYSBzdGF0aWNhbGx5IHByb3Zpc2lvbmVkIExTUCBp cy4NCg0KDQoNCkZpbmFsbHksIHdlIGNhbiBzZWUgYSBkZXNpcmUgdG8gc2VuZCBURSBpbnN0cnVj dGlvbnMgZnJvbSBhIGNvbXB1dGF0aW9uIGVuZ2luZSAoZS5nLiwgUENFKSB0byBpbmRpdmlkdWFs IG5ldHdvcmsgbm9kZXMgdG8gcHJvZ3JhbSB0aGVpciBmb3J3YXJkaW5nLiBGb3IgZXhhbXBsZSwg aW4gYSBTZWdtZW50IFJvdXRlZCBuZXR3b3JrIG9yIGZvciBzdGF0aWMgTVBMUy1URSBMU1BzLg0K DQoNCg0KDQoNClB1dCBhbGwgb2YgdGhpcyB0b2dldGhlciB3aXRoIHRoZSByZWNvZ25pdGlvbiB0 aGF0IGFsbCBURSBwYXRoIG1hbmFnZW1lbnQgaXMgZnVuZGFtZW50YWxseSB0aGUgc2FtZSBhbmQg Y2FuIGJlIHBlcmZvcm1lZCBieSB0aGUgc2FtZSBlbmdpbmUsIGFuZCB0aGF0IGl0IGRvZXMgbm90 IG1ha2Ugc2Vuc2UgZm9yIHN1Y2ggYW4gZW5naW5lIHRvIGhhdmUgdG8gaW1wbGVtZW50IG11bHRp cGxlIFNCSSBwcm90b2NvbHMsIGFuZCB5b3UgZW5kIHVwIHdpdGggdGhpcyBkcmFmdC4NCg0KDQoN CkkgZG9uJ3QgdGhpbmsgd2UgYXJlIHNheWluZyB0aGF0IHRoaXMgYXBwcm9hY2ggaXMgY29tcHVs c29yeSwgYnV0IHdlIGFyZSBzYXlpbmcgdGhhdCBpdCBpcyBwb3NzaWJsZS4gT3RoZXIgcG9zc2li aWxpdGllcyBleGlzdCBpbmNsdWRpbmcgdXNpbmcgTkVUQ09ORi9ZQU5HIGluIHBsYWNlIG9mIFBD RVAsIGFuZCBlbmhhbmNpbmcgQkdQIGluIHBsYWNlIG9mIFBDRVAuIE90aGVycyBoYXZlIHN1Z2dl c3RlZCBYTVBQLiBGcmFua2x5LCBpZiB3ZSB3ZXJlIHByb3Bvc2luZyBhIG5ldyBwcm90b2NvbCBp dCB3b3VsZCBiZSBjb3JyZWN0IHRvIHRlbGwgdXMgbm90IHRvLCBhbmQgdG8gcGVyc3VhZGUgdXMg dGhhdCBvbmUgb2YgdGhlIG90aGVyIHByb3RvY29scyB3aWxsIGRvIHRoZSBqb2IuIEJ1dCBoZXJl IHdlIGFyZSB3aXRoIHRocmVlIChvciBmb3VyKSBwcm90b2NvbHMgdGhhdCBmaXQgdGhlIGJpbGw6 IGVhY2ggY3VycmVudGx5IGNvdmVycyBzb21lIG9mIHRoZSBmdW5jdGlvbiBzcGFjZSBhbmQgZWFj aCBjb3VsZCBlYXNpbHkgYmUgZXh0ZW5kZWQgdG8gY292ZXIgdGhlIHdob2xlIHNwYWNlLiBJJ20g bm90IGNhcGFibGUgb2Ygc2F5aW5nIGhvdyB0byBkZWNpZGUgd2hpY2ggcHJvdG9jb2wgZG9lcyB3 aGljaCBmdW5jdGlvbiwgYnV0IEkgZG8gc2VlIHByZXNzdXJlcyBvZiBpbXBsZW1lbnRhdGlvbiBh bmQgZGVwbG95bWVudCB0aGF0IGxlYWQgdG8gdGhpcyBkcmFmdC4NCg0KDQoNCltIaXN0b3JpYyBu b3RlOiBJIHdhcyBzb21ld2hhdCBvcHBvc2VkIHRvIGFkZGluZyBQQ0UtSW5pdGlhdGVkIExTUCBz dXBwb3J0IHRvIFBDRVAuIEkgdGhvdWdodCB0aGlzIGJlbnQgdGhlIGFyY2hpdGVjdHVyZSBmdXJ0 aGVyIHRoYW4gd2FzIG9yaWdpbmFsbHkgaW50ZW5kZWQuIEJ1dCB3ZSB3ZW50IHRoZXJlIGluIHRo ZSBQRUMgV0cgYW5kIHRoZSBJLUQgaXMgbm93ICJjb21wbGV0ZSIuIEJ5IGFkZGluZyBzdXBwb3J0 IG9mIFBDRSBpbml0aWF0aW9uIG9mIExTUHMsIHdlIG5hdHVyYWxseSBvcGVuZWQgdGhlIHBhdGgg dG8gdGhpcyBkb2N1bWVudC4gRldJVywgdGhpcyBpcyBub3QgdGhlIGZpcnN0IHRpbWUgdGhhdCBQ Q0VQIGhhcyBiZWVuIGRpc2N1c3NlZCBhcyBhIG1vcmUgZ2VuZXJhbCBTQkkgcHJvdG9jb2wgLSBS RkMgNzQ5MSBzaG93cyBpdCBpbiB0aGlzIGNvbnRleHQgYWx0aG91Z2ggZG9lcyBub3QgZGlzY3Vz cyBpdCBtdWNoICh3ZSBzaG91bGQgcHJvYmFibHkgYWRkIGEgcmVmZXJlbmNlIHRvIEFCTk8gaW4g dGhpcyBkb2N1bWVudCkuXQ0KDQoNCg0KDQoNCk5vdywgeW91IHNheSB5b3UgYXJlIHN1cnByaXNl ZCB0aGF0ICJ0aGUgZG9jdW1lbnQgZm9jdXNlcyBvbiB1c2luZyBQQ0VQIGUuZy4gZm9yIEwzVlBO IHNlcnZpY2UgZGVsaXZlcnkuIiBJIHRoaW5rIHRoZXJlIGlzIGEgc2lnbmlmaWNhbnQgZGlmZmVy ZW5jZSBiZXR3ZWVuICpyZXF1ZXN0aW5nKiBhIHNlcnZpY2UgYW5kICpkZWxpdmVyaW5nKiB0aGF0 IHNlcnZpY2UuIFRoZSBzZXJ2aWNlIHJlcXVlc3QgKGFzLCBmb3IgZXhhbXBsZSwgaW4gTDNTTSkg ZG9lcyBub3QgaW52b2x2ZSBhIFBDRSBhbmQgaXMgZWFzaWx5IGFjaGlldmVkIHVzaW5nIGEgWUFO RyBtb2RlbCB3aGljaCwgaWYgdGhlIHNlcnZpY2UgcmVxdWVzdCBpcyBvbi1saW5lLCBjYW4gYmUg ZGVsaXZlcmVkIHVzaW5nIE5FVENPTkYuIEhvd2V2ZXIsIHNlcnZpY2UgZGVsaXZlcnkgcmVxdWly ZXMgIm9yY2hlc3RyYXRpb24iLiBPcmNoZXN0cmF0aW9uIGlzIHRoZSBwcm9jZXNzIG9mIGNvbnNp ZGVyaW5nIGF2YWlsYWJsZSBuZXR3b3JrIHJlc291cmNlcyBhbmQgc2VsZWN0aW5nIHdoYXQgd2ls bCBiZSBwcm92aXNpb25lZCB0byBzdXBwb3J0IHRoZSBzZXJ2aWNlLiBBIFBDRSBpcyBhdCBsZWFz dCBhIGtleSBmZWF0dXJlIG9mIG9yY2hlc3RyYXRpb24sIGp1c3QgYXMgaXQgaXMgYSBrZXkgY29t cG9uZW50IG9mIGEgbmV0d29yayBjb250cm9sbGVyLg0KDQoNCg0KQnV0IHRoZSBkb2N1bWVudCBk b2VzIE5PVCBmb2N1cyBvbiBQQ0VQIGluIHF1aXRlIHRoZSB3YXkgeW91IGRlc2NyaWJlLiBJbiBm YWN0LCB0aGUgb25seSBkaXNjdXNzaW9uIGlzIGluIDMuMi4zIChqdXN0IHR3byBwYXJhZ3JhcGhz IGluIHRoZSB3aG9sZSBkb2N1bWVudCkgd2hlcmUgdGhlIGZvY3VzIGlzIG9uIHRoZSB1c2Ugb2Yg YSBQQ0UtYmFzZWQgY2VudHJhbCBjb250cm9sbGVyIHRoYXQgY2FuICJjb25zaWRlciB0aGUgd2hv bGUgbmV0d29yayBhbmQgYWxsIGNvbXBvbmVudHMgb2YgYSBzZXJ2aWNlIGF0IG9uY2Ugd2hlbiBw bGFubmluZyBob3cgdG8gZGVsaXZlciB0aGUgc2VydmljZS4iIEl0IHRoZW4gZ29lcyBvbiB0byBv YnNlcnZlIHRoYXQgUENFUCBjYW4gYmUgdXNlZCAidG8gbWFuYWdlIHRoZSBuZXR3b3JrIHJlc291 cmNlcyBhbmQgdG8gaW5zdGFsbCB0aGUgbmVjZXNzYXJ5IGFzc29jaWF0aW9ucyBiZXR3ZWVuIHRo b3NlIHJlc291cmNlcy4iDQoNCg0KDQoNCg0KSWYgd2UgaW5jbHVkZWQgYSBtZXNzYWdlIGZsb3cg Y2hhcnQgaXQgd291bGQgbG9vayBzb21ldGhpbmcgbGlrZS4uLg0KDQoNCg0KU2VydmljZSBNYW5h Z2VyICAgICAgUENFLWJhc2VkIENvbnRyb2xsZXIgICAgIE5Fcw0KDQogICAgIFJlcXVlc3Qgc2Vy dmljZS0tLS0tLS0tLT4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICBDb21wdXRlDQoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQcm92aXNpb24gLS0tLS0tPg0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDwtLS0tLS0tLS0tLS0tIEFjaw0KDQogICAgICAgICAg ICAgICAgICAgICAgICAgIFVwZGF0ZSBEQnMNCg0KICAgICA8LS0tLS0tLS0tLS0tLS0tLS0tLUFj aw0KDQoNCg0KSWYgdGhhdCBzaW1wbGUgZmlndXJlIGhlbHBzIHdpdGggdGhlIHVuZGVyc3RhbmRp bmcgb2YgdGhpcyBvciBhbnkgb3RoZXIgcGFydCBvZiB0aGUgZG9jdW1lbnQsIHdlIGNhbiBzdXJl bHkgYWRkIGl0Lg0KDQoNCg0KQ2hlZXJzLA0KDQpBZHJpYW4NCg0KDQoNCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCg0KPiBGcm9tOiBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUpIFtt YWlsdG86bWljaGFlbC5zY2hhcmZAbm9raWEuY29tXQ0KDQo+IFNlbnQ6IDIwIE1heSAyMDE2IDE5 OjA3DQoNCj4gVG86IGFkcmlhbkBvbGRkb2cuY28udWs8bWFpbHRvOmFkcmlhbkBvbGRkb2cuY28u dWs+OyB0ZWFzQGlldGYub3JnPG1haWx0bzp0ZWFzQGlldGYub3JnPg0KDQo+IFN1YmplY3Q6IFJF OiBbVGVhc10gQSBOZXcgSS1EIG9uIFBDRSBhcyBhIGNlbnRyYWwgY29udHJvbGxlcg0KDQo+DQoN Cj4gQXMgSSBzYWlkLCBJIHNwZWNpZmljYWxseSB3b25kZXIgYWJvdXQgU2VjdGlvbiAzLjIuMyAi U2VydmljZSBEZWxpdmVyeSIsIHdoaWNoIHN0YXRlcw0KDQo+IChvbWl0dGluZyBzb21lIHBhcnRz IHRoYXQgYXJlIG5vdCByZWxldmFudCBoZXJlKToNCg0KPg0KDQo+ICJWYXJpb3VzIG5ldHdvcmsg c2VydmljZXMgbWF5IGJlIG9mZmVyZWQgb3ZlciBhIG5ldHdvcmsuIFRoZXNlIGluY2x1ZGUNCg0K PiBwcm90ZWN0aW9uIHNlcnZpY2VzIFsuLi5dIFZpcnR1YWwgUHJpdmF0ZSBOZXR3b3JrIChWUE4p IHNlcnZpY2UgKHN1Y2ggYXMgTGF5ZXIgMw0KDQo+IFZQTnMgW1JGQzQzNjRdIG9yIEV0aGVybmV0 IFZQTnMgW1JGQzc0MzJdKSwgb3IgUHNldWRvd2lyZXMgW1JGQzM5ODVdLiBbLi4uXSAgQQ0KDQo+ IFBDRS1iYXNlZCBjZW50cmFsIGNvbnRyb2wgY2FuIGNvbnNpZGVyIHRoZSB3aG9sZSBuZXR3b3Jr IGFuZCBhbGwgY29tcG9uZW50cyBvZg0KDQo+IGEgc2VydmljZSBhdCBvbmNlIHdoZW4gcGxhbm5p bmcgaG93IHRvIGRlbGl2ZXIgdGhlIHNlcnZpY2UuIEl0IGNhbiB0aGVuIHVzZSBQQ0VQDQoNCj4g dG8gbWFuYWdlIHRoZSBuZXR3b3JrIHJlc291cmNlcyBhbmQgdG8gaW5zdGFsbCB0aGUgbmVjZXNz YXJ5IGFzc29jaWF0aW9ucw0KDQo+IGJldHdlZW4gdGhvc2UgcmVzb3VyY2VzLiINCg0KPg0KDQo+ IFRoaXMgd29yZGluZyBvbiB1c2Ugb2YgUENFUCBjb25mdXNlcyBtZSwgbm8gbWF0dGVyIHdoYXQg aW50ZXJmYWNlIHdlIHRhbGsNCg0KPiBhYm91dC4gSSB3b3VsZCBoYXZlIGFzc3VtZWQgdGhhdCBZ QU5HLWJhc2VkIHByb3RvY29scyBzdWNoIGFzDQoNCj4gTkVUQ09ORi9SRVNUQ09ORiBjb3VsZCBi ZSB1c2VmdWwgaW4gdGhpcyBjb250ZXh0LCBhbmQgSSBhbSBhIGJpdCBzdXJwcmlzZWQgdGhhdA0K DQo+IHRoZSBkb2N1bWVudCBmb2N1c2VzIG9uIHVzaW5nIFBDRVAgZS5nLiBmb3IgTDNWUE4gc2Vy dmljZSBkZWxpdmVyeS4gQnkgdGhlIHdheSwNCg0KPiBJIGFsc28gd29uZGVyIGhvdyBQQ0VQIGZp dHMgaW50byB0aGUgZGlzY3Vzc2lvbiBvbiBRb1MgY2xhc3NpZmljYXRpb24gaW4gU2VjdGlvbg0K DQo+IDMuMi4yLg0KDQo+DQoNCj4gSSB3b25kZXIgaWYgdGhlIGF1dGhvcnMgY291bGQgYWRkIHRv IFNlY3Rpb24gMy4yLjIgYW5kIFNlY3Rpb24gMy4yLjMgZS5nLiBhDQoNCj4gbWVzc2FnZSBzZXF1 ZW5jZSBjaGFydCB0aGF0IGlsbHVzdHJhdGVzIGhvdyB3aGF0IGlzIGRpc2N1c3NlZCBpbiB0aG9z ZSBzZWN0aW9ucw0KDQo+IHJlbGF0ZXMgdG8gUENFUD8NCg0KPg0KDQo+IE1pY2hhZWwNCg0KPg0K DQo+DQoNCj4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQo+IEZyb206IFRlYXMg W21haWx0bzp0ZWFzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFWFQgQWRyaWFuIEZh cnJlbA0KDQo+IFNlbnQ6IEZyaWRheSwgTWF5IDEzLCAyMDE2IDY6NTQgUE0NCg0KPiBUbzogU2No YXJmLCBNaWNoYWVsIChOb2tpYSAtIERFKTsgdGVhc0BpZXRmLm9yZzxtYWlsdG86dGVhc0BpZXRm Lm9yZz4NCg0KPiBTdWJqZWN0OiBSZTogW1RlYXNdIEEgTmV3IEktRCBvbiBQQ0UgYXMgYSBjZW50 cmFsIGNvbnRyb2xsZXINCg0KPg0KDQo+IEhlbGxvIGFnYWluLCBNaWNoYWVsLCBpdCBzZWVtcyB0 byBiZSBteSBkYXkgZm9yIHJlcGx5aW5nIHRvIHlvdXIgZW1haWxzLg0KDQo+DQoNCj4gPiBXaGVu IHJlYWRpbmcgYWJvdXQgdXNlcyBjYXNlcyBzdWNoIGFzIEwzVlBOIHNlcnZpY2UgZGVsaXZlcnkg aW4NCg0KPiA+ICJTZWN0aW9uDQoNCj4gMy4yLjMiLA0KDQo+ID4gd2hhdCBpcyB0aGUgYXV0aG9y J3MgdmlldyBvbiB0aGUgbGluZSBvZiBkZW1hcmNhdGlvbiBiZXR3ZWVuIE5FVENPTkYNCg0KPiA+ IGFuZCBQQ0VQPw0KDQo+DQoNCj4gV2VsbCwgSSB3b25kZXIgd2hpY2ggaW50ZXJmYWNlIHlvdSdy ZSB0YWxraW5nIGFib3V0Lg0KDQo+IFRoZSBvbmVzIHRoYXQgb3V0IGluIGhlcmUgYXJlOg0KDQo+ IC0gdGhlIGludGVyZmFjZSBiZXR3ZWVuIGN1c3RvbWVyIGFuZCBvcGVyYXRvcg0KDQo+IC0gdGhl IGludGVyZmFjZSBiZXR3ZWVuICJzZXJ2aWNlIG9yY2hlc3RyYXRvciIgYW5kICJuZXR3b3JrIG9y Y2hlc3RyYXRvciINCg0KPg0KDQo+IFRoZSBmb3JtZXIgb2YgdGhlc2UgaXMgbGlrZSB0aGUgaW50 ZXJmYWNlIHVzZWQgaW4gTDNTTS4gQXMgY28tY2hhaXIgb2YgTDNTTSwgeW91DQoNCj4gbWlnaHQg bm90IGJlIHN1cnByaXNlZCB0byBoZWFyIHRoYXQgbXkgdmlldyBpcyB0aGF0IE5FVENPTkYgaXMg YSBmaW5lIHNvbHV0aW9uIC0NCg0KPiB3ZWxsLCB0aGUgdXNlIG9mIGEgWUFORyBkYXRhIG1vZGVs LCBpbiBhbnkgY2FzZS4NCg0KPg0KDQo+IFRoZSBsYXR0ZXIgaXMgdGhlIGludGVyZmFjZSBiZXR3 ZWVuICJPcmNoZXN0cmF0b3IgLyBTZXJ2aWNlIE1hbmFnZXIgLyBPU1MgLw0KDQo+IE5NUyINCg0K PiBhbmQgIlBDRS1iYXNlZCBDb250cm9sbGVyIiBhcyBzaG93biBvbiB0aGUgdmFyaW91cyBmaWd1 cmVzIGluIHRoZSBwaWN0dXJlLiBXZQ0KDQo+IGhhdmVuJ3QgZGlzY3Vzc2VkIHRoaXMgaW50ZXJm YWNlIGluIHRoZSBkb2N1bWVudCwgYW5kIHBlcmhhcHMgd2Ugc2hvdWxkLg0KDQo+DQoNCj4gSWYg eW91IGxvb2sgYXQgRmlndXJlIDYgKHdpdGggdGhlIGhpZXJhcmNoeSBvZiBjb250cm9sbGVycykg eW91IG1pZ2h0IG9ic2VydmUgdGhhdA0KDQo+IHRoZSBwYXJlbnQgY29udHJvbGxlciBjb3VsZCBi ZSBpbXBsZW1lbnRlZCB0byBhY3QgYXMgdGhvdWdoIGl0IGlzIHRhbGtpbmcgdG8gYW4gTkUNCg0K PiAoaW4gdGhlIGFic3RyYWN0IG5vZGUgbW9kZWwpIGFuZCB0aGF0IG1lYW5zIHRoYXQgdGhlIHNv dXRoYm91bmQgaW50ZXJmYWNlIG9mDQoNCj4gdGhlIHBhcmVudCBjb250cm9sbGVyIHdvdWxkIGJl IFBDRVAuIFRoYXQgbWVhbnMgKG9mIGNvdXJzZSkgdGhhdCB0aGUNCg0KPiBub3J0aGJvdW5kIGlu dGVyZmFjZSBvZiB0aGUgY2hpbGQgY29udHJvbGxlciB3b3VsZCBhbHNvIGJlIFBDRVAuIFRoZW4s IGl0IG1pZ2h0DQoNCj4gc2VlbSBvYnZpb3VzIHRoYXQgd2Ugd291bGQgd2FudCBhbGwgUENFIGlt cGxlbWVudGF0aW9ucyB0byBiZWhhdmUgdGhlIHNhbWUNCg0KPiB3YXkgYW5kIHNvIHRoYXQgbWFr ZXMgdGhlIG5vcnRoYm91bmQgaW50ZXJmYWNlIG9mIHRoZSBwYXJlbnQgUENFDQoNCj4gd291bGQv Y291bGQvc2hvdWxkL21pZ2h0IGFsc28gYmUgUENFUC4NCg0KPg0KDQo+IFdoYXQgZG8geW91IHRo aW5rPw0KDQo+DQoNCj4gVGhhbmtzLA0KDQo+IEFkcmlhbg0KDQo+DQoNCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KPiBUZWFzIG1haWxpbmcgbGlz dA0KDQo+IFRlYXNAaWV0Zi5vcmc8bWFpbHRvOlRlYXNAaWV0Zi5vcmc+DQoNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90ZWFzDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUZWFzIG1haWxpbmcgbGlzdA0KVGVhc0BpZXRm Lm9yZzxtYWlsdG86VGVhc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdGVhcw0KDQoNCg== --_000_655C07320163294895BBADA28372AF5D48863026FR712WXCHMBA15z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENo YXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4 LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+RmFpciBwb2ludC4gQnV0IFNlY3Rpb24gNCBzaG91bGQgYWxzbyBiZSBtb3JlIGV4 cGxpY2l0IHRoYXQgdGhlIGNvbmNsdXNpb24gdGhlcmUgYXMgaHlwb3RoZXRpY2FsIGFzIHRoZSB1 c2UgY2FzZXMgU2VjdGlvbiAzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpcyB3b3VsZCBub3QgZml4IHRoZSBwcm9i bGVtIHdpdGggU2VjdGlvbiAzLjIuMiBhbmQgU2VjdGlvbiAzLjIuMyBidXQgYXQgbGVhc3QgbWFr ZSBjbGVhciB0aGF0IFNlY3Rpb24gNCBpcyBwdXJlIHNwZWN1bGF0aW9uIG9ubHkuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5NaWNoYWVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4gQW5kcmV3IEcuIE1hbGlzIFttYWlsdG86YWdtYWxpc0BnbWFpbC5jb21dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gTW9uZGF5LCBNYXkgMjMsIDIwMTYgMzo0MyBQTTxicj4NCjxiPlRvOjwvYj4gU2No YXJmLCBNaWNoYWVsIChOb2tpYSAtIERFKTxicj4NCjxiPkNjOjwvYj4gYWRyaWFuQG9sZGRvZy5j by51azsgdGVhc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RlYXNdIEEgTmV3 IEktRCBvbiBQQ0UgYXMgYSBjZW50cmFsIGNvbnRyb2xsZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1pY2hhZWwsPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgaW50cm9kdWN0aW9uIHRvIHNlY3Rpb24gMyBzYXlz OiDigJxBcyBwcmV2aW91c2x5IG1lbnRpb25lZCwgdGhpcyBzZWN0aW9uIGlzIGludGVuZGVkIHRv IGp1c3QgbWFrZSBzdWdnZXN0aW9ucy7igJ0uIFRoYXQgc291bmQgbGlrZSBoeXBvdGhldGljYWwg dG8gbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBNb24sIE1heSAyMywgMjAxNiBhdCA5OjM3IEFNLCBTY2hhcmYsIE1pY2hh ZWwgKE5va2lhIC0gREUpICZsdDs8YSBocmVmPSJtYWlsdG86bWljaGFlbC5zY2hhcmZAbm9raWEu Y29tIiB0YXJnZXQ9Il9ibGFuayI+bWljaGFlbC5zY2hhcmZAbm9raWEuY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldoeSBkb2VzbuKAmXQg dGhlIGRvY3VtZW50IHRoZW4gbWVudGlvbiB0aGF0IHRoZSB1c2UgY2FzZXMgYW5kIGNvbmNsdXNp b25zIG9uIFBDRVAgYXJlIGh5cG90aGV0aWNhbD88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NaWNoYWVsPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQW5kcmV3 IEcuIE1hbGlzIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmFnbWFsaXNAZ21haWwuY29tIiB0YXJn ZXQ9Il9ibGFuayI+YWdtYWxpc0BnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1v bmRheSwgTWF5IDIzLCAyMDE2IDM6MzUgUE08YnI+DQo8Yj5Ubzo8L2I+IFNjaGFyZiwgTWljaGFl bCAoTm9raWEgLSBERSk8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzphZHJpYW5Ab2xk ZG9nLmNvLnVrIiB0YXJnZXQ9Il9ibGFuayI+YWRyaWFuQG9sZGRvZy5jby51azwvYT47DQo8YSBo cmVmPSJtYWlsdG86dGVhc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRlYXNAaWV0Zi5vcmc8 L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtUZWFzXSBBIE5ldyBJLUQgb24gUENFIGFz IGEgY2VudHJhbCBjb250cm9sbGVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5NaWNoYWVsLDxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgdGhpbmsgeW914oCZcmUg ZXhwZWN0aW5nIHRvbyBtdWNoIGZyb20gdGhpcyBkcmFmdC4gSXTigJlzIG1lYW50IHRvIGJlIGEg dmVyeSBoaWdoLWxldmVsIGluZm9ybWF0aW9uYWwgZG9jdW1lbnQgdG8gaW50cm9kdWNlIHRoZSBj b25jZXB0cyBhbmQgYSBub24tZXhoYXVzdGl2ZSBsaXN0IG9mIHBvc3NpYmxlIGFwcGxpY2F0aW9u cw0KIGFuZCB1c2UgY2FzZXMuIEFzIHdpdGggYW55IHN1Y2ggZWFybHkgZG9jdW1lbnQsIHRoZXJl 4oCZcyBzb21lIGFtb3VudCBvZiBzcGVjdWxhdGl2ZSB3cml0aW5nLCBhbmQgdGhlcmXigJlzIG5v IGV4cGVjdGF0aW9uIHRoYXQgYWxsIG9mIHRoZSBkaXNjdXNzZWQgYXBwbGljYXRpb25zIG9yIHVz ZSBjYXNlcyB3aWxsIGFjdHVhbGx5IGNvbWUgdG8gZnJ1aXRpb24sIGFuZCB0aGVyZSBtYXkgYmUg b3RoZXJzIGluIHRoZSBmdXR1cmUgdGhhdCBkbyBlbmQgdXANCiBiZWluZyBpbXBsZW1lbnRlZC4g QnV0IHRoZSBhY3R1YWwgZGV0YWlscyBvZiBwcm90b2NvbCBjaGFuZ2VzIGFuZCBhcHBsaWNhdGlv bnMgd2lsbCBiZSB0aGUgdG9waWNzIG9mIG90aGVyIHN0YW5kYXJkcy10cmFjayBkcmFmdChzKSB0 byBjb21lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5BbmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gU3VuLCBNYXkgMjIsIDIwMTYgYXQgNTozNCBQTSwg U2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pY2hhZWwu c2NoYXJmQG5va2lhLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1pY2hhZWwuc2NoYXJmQG5va2lhLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5IaSBBZHJpYW4sPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+TWFueSB0aGFua3MgZm9yIHRoZSB0 dXRvcmlhbC4gU2luY2UgUkZDIDc0OTEgYWxyZWFkeSBhY2tub3dsZWRnZXMgdGhlIHJvbGUgb2Yg YSBQQ0UsIEkgc2VlIGxpdHRsZSB2YWx1ZSBvZiBhIGhpZ2gtbGV2ZWwgZG9jdW1lbnQgdGhhdCB0 YWxrcyBhYm91dCBQQ0VQDQogYXMgYSBnZW5lcmFsIFNCSSBmb3IgdGhlIHRvcGljcyBtZW50aW9u ZWQgaW4gU2VjdGlvbiAzLjIuMiBhbmQgU2VjdGlvbiAzLjIuMywgaWYgdGhhdCBkb2N1bWVudCBk b2VzIG5vdCBkaXNjdXNzIG1vcmUgc3BlY2lmaWNhbGx5IHRoZSBpbXBhY3Qgb24gUENFUCwgZGF0 YSBtb2RlbHMsIGV0Yy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5J dCBzaG91bGQgYmUgb2J2aW91cyB0aGF0IGluIG15IHBvaW50IG9mIHZpZXcgdGhlIHdvcmRpbmcg aW4gU2VjdGlvbnMgMy4yLjIgYW5kIDMuMi4zIGlzIG5vdCBjbGVhci4gSnVzdCByZXBlYXRpbmcg dGhlIHdvcmRpbmcgb25jZSBhZ2FpbiBkb2VzIG5vdCBhZGRyZXNzDQogbXkgcXVlc3Rpb24sIHNp bmNlIEkgaGF2ZSBvYnZpb3VzbHkgcmVhZCB0aGUgZG9jdW1lbnQgYW5kIHNpbmNlIEkga25vdyB0 aGUgdGVybWlub2xvZ3kgKGFsYmVpdCBJIGFtIG5vdCBhIG5hdGl2ZSBzcGVha2VyKS4gQSBnZW5l cmljIGZsb3cgY2hhcnQgbm90IGRldGFpbGluZyBmb3Igd2hpY2ggb2YgdGhlIG1lc3NhZ2VzIFBD RVAgd291bGQgYmUgdXNlZCwgYW5kIHdpdGggd2hhdCBjb250ZW50LCBhbHNvIGRvZXMgbm90IGFk ZHJlc3MgbXkgY29uY2Vybi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JbiBhbnkgY2FzZSwgaWYgdGhlIGNv bnRlbnQgb2YgU2VjdGlvbiAzLjIuMiBhbmQgU2VjdGlvbiAzLjIuMyBjYW5ub3QgYmUgbWFkZSBt b3JlIGV4cGxpY2l0LCBpdCBpcyBpbXBvc3NpYmxlIGZvciBtZSB0byB1bmRlcnN0YW5kIHdoZXRo ZXIgdGhlIGNvbmNsdXNpb24NCiBpbiBTZWN0aW9uIDQg4oCmIOKAnEFzIHN1Y2gsIG5vIHN1YnN0 YW50aWFsIGNoYW5nZXMgdG8gUENFUCBhcmUgcmVxdWlyZWQgdG8gc3VwcG9ydCB0aGUgY29uY2Vw dCBvZiBhIFBDRS1iYXNlZCBjb250cm9sbGVyLiBUaGUgb25seSB3b3JrIG5lZWRlZCB3aWxsIGJl IHNtYWxsIGV4dGVuc2lvbnMgdG8gY2FycnkgYWRkaXRpb25hbCBvciBzcGVjaWZpYyBpbmZvcm1h dGlvbiBlbGVtZW50cyBmb3IgdGhlIGluZGl2aWR1YWwgdXNlIGNhc2VzLuKAnSBpcyBjb3JyZWN0 DQogYW5kIGhvdyBpdCBpcyBhY3R1YWxseSBqdXN0aWZpZWQgZm9yIHRoZSB0ZWNobmljYWwgYXJl YXMgc3VjaCBhcyBTZWN0aW9uIDMuMi4yIGFuZCBTZWN0aW9uIDMuMi4zIC48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Gcm9tIG15IHBlcnNvbmFsIGV4cGVyaWVuY2Ug dGhpcyBzb3J0IG9mIGVudGlyZWx5IGdlbmVyaWMgY29uY2x1c2lvbiBjb3VsZCBwZXJoYXBzIGJl IGEgYml0IG9mIHNpbXBsaWZpY2F0aW9uLCBidXQgdGhpcyBtYXkgZGVwZW5kIG9uIHRoZSBhY3R1 YWwgdXNlDQogY2FzZS4gQnV0IGluIGFuIEktRCwgSSBiZWxpZXZlIHN1Y2ggYSBnZW5lcmljIGNv bmNsdXNpb24gbmVlZHMgYmFja2luZyBieSBjb250ZW50IGFuZCBhcyBmYXIgYXMgSSB1bmRlcnN0 YW5kIGZvciBTZWN0aW9uIDMuMi4yIGFuZCBTZWN0aW9uIDMuMi4zIHRoaXMgYmFja2luZyBpcyBs YWNraW5nIGluIHRoZSBkb2N1bWVudCByaWdodCBub3cuDQo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5UaGFua3M8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj5NaWNoYWVsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxiPjxzcGFuIGxhbmc9IkRFIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkRFIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFkcmlhbg0KIEZhcnJlbCBb bWFpbHRvOjxhIGhyZWY9Im1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrIiB0YXJnZXQ9Il9ibGFu ayI+YWRyaWFuQG9sZGRvZy5jby51azwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBN YXkgMjIsIDIwMTYgNjoyNCBBTTxicj4NCjxiPlRvOjwvYj4gU2NoYXJmLCBNaWNoYWVsIChOb2tp YSAtIERFKTxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnRlYXNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj50ZWFzQGlldGYub3JnPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJERSI+PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJFOiBbVGVhc10gQSBOZXcgSS1EIG9uIFBDRSBhcyBhIGNlbnRyYWwg Y29udHJvbGxlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkRFIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+ TWljaGFlbCwgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj5JIGRvbid0 IHRoaW5rIGl0IGlzIGNvbXBsaWNhdGVkLCBidXQgaXQgaXMgb2J2aW91c2x5IG5vdCBjbGVhciBm cm9tIHRoZSBkb2N1bWVudCwgc28gdGhhbmsgeW91IGZvciByYWlzaW5nIHRoZSBjb25jZXJuLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+WW91IHNheSBpdCBkb2Vzbid0 IG1hdHRlciB3aGljaCBpbnRlcmZhY2Ugd2UncmUgdGFsa2luZyBhYm91dCwgYnV0IGl0IGRvZXMu IFBDRVAgaXMgYSBwcm90b2NvbCBhbmQgcHJvdG9jb2xzIGFyZSB1c2VkIG9uIGludGVyZmFjZXMu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj5MZXQncyBzdGFydCB3aXRo IHNvdXRoYm91bmQgb2YgdGhlIFBDRS4gV2UgYWxyZWFkeSB1c2UgUENFUCBvbiB0aGlzIGludGVy ZmFjZS4gV2UgaGF2ZSBhbHdheXMgZG9uZS4gSXQgaXMgd2hhdCBQQ0VQIHdhcyBpbnZlbnRlZCBm b3IuIEFuZCByZWNlbnQgZGV2ZWxvcG1lbnRzIGluIFN0YXRlZnVsIFBDRSBhbmQgUENFLUluaXRp YXRlZCBMU1BzIGhhdmUgbWFkZSBQQ0VQIChhbmQgdGhpcyBpbnRlcmZhY2UpIGFibGUNCiB0byBz ZW5kIGNvbnRyb2wgJnF1b3Q7Y29tbWFuZHMmcXVvdDsgYXMgd2VsbCBhcyByZXNwb25kIHRvIHJl cXVlc3RzLiBUaHVzLCBQQ0VQIGlzIGFuIFNCSSBwcm90b2NvbCBmb3IgdXNlIHdpdGggc2lnbmFs aW5nIHN5c3RlbXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0Ii PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj5Ob3cs IHdlIG1pZ2h0IG1ha2Ugc2V2ZXJhbCBvYnNlcnZhdGlvbnMuLi48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tR0IiPkluIG1hbnkgKG1vc3Q/KSBNUExTLVRFIG5ldHdvcmtzLCBl dmVyeSByb3V0ZXIgaXMgY2FwYWJsZSBvZiBiZWluZyB0aGUgaGVhZCBlbmQgb2YgTFNQcy4gVGhh dCBtZWFucyB0aGF0IGluIGEgUENFLWVuYWJsZWQgTVBMUy1URSBuZXR3b3JrLCBldmVyeSByb3V0 ZXIgaXMgYSBQQ0VQIHNwZWFrZXIuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFu Zz0iRU4tR0IiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVO LUdCIj5BZGRpdGlvbmFsbHksIHdlIGNhbiBvYnNlcnZlIHRoYXQgTFNQcyAob3IgUFdzKSBjYW4g YmUgc3RpdGNoZWQgdG9nZXRoZXIuIFRoZSBzdGl0Y2hpbmcsIGlmIHVuZGVyIHRoZSBjb250cm9s IG9mIGEgUENFLCByZXF1aXJlcyBhIHNwZWNpYWwgaW5zdHJ1Y3Rpb24gdG8gYmUgc2VudCB0byB0 aGUgc3RpdGNoaW5nIG5vZGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0i RU4tR0IiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdC Ij5GdXJ0aGVybW9yZSwgd2UgY2FuIHVuZGVyc3RhbmQgdGhhdCBhIHNpbmdsZSBlbmQtdG8tZW5k IExTUCBpcyBhY3R1YWxseSB0aGUgc3RpdGNoaW5nIG9mIGxvdHMgb2Ygc2luZ2xlIGhvcCBMU1Bz LiBUaGF0IGlzIHJlYWxseSB3aGF0IGEgc3RhdGljYWxseSBwcm92aXNpb25lZCBMU1AgaXMuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj5GaW5hbGx5LCB3ZSBjYW4gc2Vl IGEgZGVzaXJlIHRvIHNlbmQgVEUgaW5zdHJ1Y3Rpb25zIGZyb20gYSBjb21wdXRhdGlvbiBlbmdp bmUgKGUuZy4sIFBDRSkgdG8gaW5kaXZpZHVhbCBuZXR3b3JrIG5vZGVzIHRvIHByb2dyYW0gdGhl aXIgZm9yd2FyZGluZy4gRm9yIGV4YW1wbGUsIGluIGEgU2VnbWVudCBSb3V0ZWQgbmV0d29yayBv ciBmb3Igc3RhdGljIE1QTFMtVEUgTFNQcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3Bh biBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFu Zz0iRU4tR0IiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVO LUdCIj5QdXQgYWxsIG9mIHRoaXMgdG9nZXRoZXIgd2l0aCB0aGUgcmVjb2duaXRpb24gdGhhdCBh bGwgVEUgcGF0aCBtYW5hZ2VtZW50IGlzIGZ1bmRhbWVudGFsbHkgdGhlIHNhbWUgYW5kIGNhbiBi ZSBwZXJmb3JtZWQgYnkgdGhlIHNhbWUgZW5naW5lLCBhbmQgdGhhdCBpdCBkb2VzIG5vdCBtYWtl IHNlbnNlIGZvciBzdWNoIGFuIGVuZ2luZSB0byBoYXZlIHRvIGltcGxlbWVudCBtdWx0aXBsZSBT QkkgcHJvdG9jb2xzLA0KIGFuZCB5b3UgZW5kIHVwIHdpdGggdGhpcyBkcmFmdC48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPkkgZG9uJ3QgdGhpbmsgd2UgYXJlIHNheWlu ZyB0aGF0IHRoaXMgYXBwcm9hY2ggaXMgY29tcHVsc29yeSwgYnV0IHdlIGFyZSBzYXlpbmcgdGhh dCBpdCBpcyBwb3NzaWJsZS4gT3RoZXIgcG9zc2liaWxpdGllcyBleGlzdCBpbmNsdWRpbmcgdXNp bmcgTkVUQ09ORi9ZQU5HIGluIHBsYWNlIG9mIFBDRVAsIGFuZCBlbmhhbmNpbmcgQkdQIGluIHBs YWNlIG9mIFBDRVAuIE90aGVycyBoYXZlIHN1Z2dlc3RlZCBYTVBQLg0KIEZyYW5rbHksIGlmIHdl IHdlcmUgcHJvcG9zaW5nIGEgbmV3IHByb3RvY29sIGl0IHdvdWxkIGJlIGNvcnJlY3QgdG8gdGVs bCB1cyBub3QgdG8sIGFuZCB0byBwZXJzdWFkZSB1cyB0aGF0IG9uZSBvZiB0aGUgb3RoZXIgcHJv dG9jb2xzIHdpbGwgZG8gdGhlIGpvYi4gQnV0IGhlcmUgd2UgYXJlIHdpdGggdGhyZWUgKG9yIGZv dXIpIHByb3RvY29scyB0aGF0IGZpdCB0aGUgYmlsbDogZWFjaCBjdXJyZW50bHkgY292ZXJzIHNv bWUgb2YgdGhlIGZ1bmN0aW9uDQogc3BhY2UgYW5kIGVhY2ggY291bGQgZWFzaWx5IGJlIGV4dGVu ZGVkIHRvIGNvdmVyIHRoZSB3aG9sZSBzcGFjZS4gSSdtIG5vdCBjYXBhYmxlIG9mIHNheWluZyBo b3cgdG8gZGVjaWRlIHdoaWNoIHByb3RvY29sIGRvZXMgd2hpY2ggZnVuY3Rpb24sIGJ1dCBJIGRv IHNlZSBwcmVzc3VyZXMgb2YgaW1wbGVtZW50YXRpb24gYW5kIGRlcGxveW1lbnQgdGhhdCBsZWFk IHRvIHRoaXMgZHJhZnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4t R0IiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj5b SGlzdG9yaWMgbm90ZTogSSB3YXMgc29tZXdoYXQgb3Bwb3NlZCB0byBhZGRpbmcgUENFLUluaXRp YXRlZCBMU1Agc3VwcG9ydCB0byBQQ0VQLiBJIHRob3VnaHQgdGhpcyBiZW50IHRoZSBhcmNoaXRl Y3R1cmUgZnVydGhlciB0aGFuIHdhcyBvcmlnaW5hbGx5IGludGVuZGVkLiBCdXQgd2Ugd2VudCB0 aGVyZSBpbiB0aGUgUEVDIFdHIGFuZCB0aGUgSS1EIGlzIG5vdyAmcXVvdDtjb21wbGV0ZSZxdW90 Oy4gQnkgYWRkaW5nIHN1cHBvcnQNCiBvZiBQQ0UgaW5pdGlhdGlvbiBvZiBMU1BzLCB3ZSBuYXR1 cmFsbHkgb3BlbmVkIHRoZSBwYXRoIHRvIHRoaXMgZG9jdW1lbnQuIEZXSVcsIHRoaXMgaXMgbm90 IHRoZSBmaXJzdCB0aW1lIHRoYXQgUENFUCBoYXMgYmVlbiBkaXNjdXNzZWQgYXMgYSBtb3JlIGdl bmVyYWwgU0JJIHByb3RvY29sIC0gUkZDIDc0OTEgc2hvd3MgaXQgaW4gdGhpcyBjb250ZXh0IGFs dGhvdWdoIGRvZXMgbm90IGRpc2N1c3MgaXQgbXVjaCAod2Ugc2hvdWxkIHByb2JhYmx5DQogYWRk IGEgcmVmZXJlbmNlIHRvIEFCTk8gaW4gdGhpcyBkb2N1bWVudCkuXTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+ PHNwYW4gbGFuZz0iRU4tR0IiPk5vdywgeW91IHNheSB5b3UgYXJlIHN1cnByaXNlZCB0aGF0ICZx dW90O3RoZSBkb2N1bWVudCBmb2N1c2VzIG9uIHVzaW5nIFBDRVAgZS5nLiBmb3IgTDNWUE4gc2Vy dmljZSBkZWxpdmVyeS4mcXVvdDsgSSB0aGluayB0aGVyZSBpcyBhIHNpZ25pZmljYW50IGRpZmZl cmVuY2UgYmV0d2VlbiAqcmVxdWVzdGluZyogYSBzZXJ2aWNlIGFuZCAqZGVsaXZlcmluZyogdGhh dCBzZXJ2aWNlLiBUaGUgc2VydmljZSByZXF1ZXN0IChhcywNCiBmb3IgZXhhbXBsZSwgaW4gTDNT TSkgZG9lcyBub3QgaW52b2x2ZSBhIFBDRSBhbmQgaXMgZWFzaWx5IGFjaGlldmVkIHVzaW5nIGEg WUFORyBtb2RlbCB3aGljaCwgaWYgdGhlIHNlcnZpY2UgcmVxdWVzdCBpcyBvbi1saW5lLCBjYW4g YmUgZGVsaXZlcmVkIHVzaW5nIE5FVENPTkYuIEhvd2V2ZXIsIHNlcnZpY2UgZGVsaXZlcnkgcmVx dWlyZXMgJnF1b3Q7b3JjaGVzdHJhdGlvbiZxdW90Oy4gT3JjaGVzdHJhdGlvbiBpcyB0aGUgcHJv Y2VzcyBvZiBjb25zaWRlcmluZw0KIGF2YWlsYWJsZSBuZXR3b3JrIHJlc291cmNlcyBhbmQgc2Vs ZWN0aW5nIHdoYXQgd2lsbCBiZSBwcm92aXNpb25lZCB0byBzdXBwb3J0IHRoZSBzZXJ2aWNlLiBB IFBDRSBpcyBhdCBsZWFzdCBhIGtleSBmZWF0dXJlIG9mIG9yY2hlc3RyYXRpb24sIGp1c3QgYXMg aXQgaXMgYSBrZXkgY29tcG9uZW50IG9mIGEgbmV0d29yayBjb250cm9sbGVyLg0KPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj5CdXQgdGhlIGRvY3VtZW50IGRvZXMgTk9U IGZvY3VzIG9uIFBDRVAgaW4gcXVpdGUgdGhlIHdheSB5b3UgZGVzY3JpYmUuIEluIGZhY3QsIHRo ZSBvbmx5IGRpc2N1c3Npb24gaXMgaW4gMy4yLjMgKGp1c3QgdHdvIHBhcmFncmFwaHMgaW4gdGhl IHdob2xlIGRvY3VtZW50KSB3aGVyZSB0aGUgZm9jdXMgaXMgb24gdGhlIHVzZSBvZiBhIFBDRS1i YXNlZCBjZW50cmFsIGNvbnRyb2xsZXIgdGhhdCBjYW4gJnF1b3Q7Y29uc2lkZXINCiB0aGUgd2hv bGUgbmV0d29yayBhbmQgYWxsIGNvbXBvbmVudHMgb2YgYSBzZXJ2aWNlIGF0IG9uY2Ugd2hlbiBw bGFubmluZyBob3cgdG8gZGVsaXZlciB0aGUgc2VydmljZS4mcXVvdDsgSXQgdGhlbiBnb2VzIG9u IHRvIG9ic2VydmUgdGhhdCBQQ0VQIGNhbiBiZSB1c2VkICZxdW90O3RvIG1hbmFnZSB0aGUgbmV0 d29yayByZXNvdXJjZXMgYW5kIHRvIGluc3RhbGwgdGhlIG5lY2Vzc2FyeSBhc3NvY2lhdGlvbnMg YmV0d2VlbiB0aG9zZSByZXNvdXJjZXMuJnF1b3Q7DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cD48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNw YW4gbGFuZz0iRU4tR0IiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxh bmc9IkVOLUdCIj5JZiB3ZSBpbmNsdWRlZCBhIG1lc3NhZ2UgZmxvdyBjaGFydCBpdCB3b3VsZCBs b29rIHNvbWV0aGluZyBsaWtlLi4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFu Zz0iRU4tR0IiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNlcnZpY2Ug TWFuYWdlciZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQQ0UtYmFzZWQgQ29udHJvbGxl ciZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBORXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVxdWVzdCBzZXJ2aWNlLS0tLS0tLS0tJmd0 Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBDb21wdXRlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFByb3Zpc2lvbiAtLS0tLS0mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDstLS0tLS0tLS0tLS0tIEFjazwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBVcGRh dGUgREJzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZsdDstLS0tLS0tLS0tLS0tLS0tLS0tQWNrPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SWYgdGhhdCBz aW1wbGUgZmlndXJlIGhlbHBzIHdpdGggdGhlIHVuZGVyc3RhbmRpbmcgb2YgdGhpcyBvciBhbnkg b3RoZXIgcGFydCBvZiB0aGUgZG9jdW1lbnQsIHdlIGNhbiBzdXJlbHkgYWRkIGl0Ljwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPkNoZWVycyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5BZHJpYW48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgPC9zcGFuPi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+ Jmd0OyA8L3NwYW4+RnJvbTogU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFKSBbPGEgaHJlZj0i bWFpbHRvOm1pY2hhZWwuc2NoYXJmQG5va2lhLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpt aWNoYWVsLnNjaGFyZkBub2tpYS5jb208L2E+XTxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFu Zz0iRU4tR0IiPiZndDsgPC9zcGFuPlNlbnQ6IDIwIE1heSAyMDE2IDE5OjA3PG86cD48L286cD48 L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyA8L3NwYW4+VG86IDxhIGhyZWY9Im1haWx0 bzphZHJpYW5Ab2xkZG9nLmNvLnVrIiB0YXJnZXQ9Il9ibGFuayI+DQphZHJpYW5Ab2xkZG9nLmNv LnVrPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnRlYXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50 ZWFzQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZn dDsgPC9zcGFuPlN1YmplY3Q6IFJFOiBbVGVhc10gQSBOZXcgSS1EIG9uIFBDRSBhcyBhIGNlbnRy YWwgY29udHJvbGxlcjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsg PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgQXMgSSBz YWlkLCBJIHNwZWNpZmljYWxseSB3b25kZXIgYWJvdXQgU2VjdGlvbiAzLjIuMyAmcXVvdDtTZXJ2 aWNlIERlbGl2ZXJ5JnF1b3Q7LCB3aGljaCBzdGF0ZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyAob21pdHRpbmcgc29tZSBwYXJ0cyB0aGF0IGFyZSBu b3QgcmVsZXZhbnQgaGVyZSk6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0i RU4tR0IiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0Ii PiZndDsgJnF1b3Q7VmFyaW91cyBuZXR3b3JrIHNlcnZpY2VzIG1heSBiZSBvZmZlcmVkIG92ZXIg YSBuZXR3b3JrLiBUaGVzZSBpbmNsdWRlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4g bGFuZz0iRU4tR0IiPiZndDsgcHJvdGVjdGlvbiBzZXJ2aWNlcyBbLi4uXSBWaXJ0dWFsIFByaXZh dGUgTmV0d29yayAoVlBOKSBzZXJ2aWNlIChzdWNoIGFzIExheWVyIDM8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyBWUE5zIFtSRkM0MzY0XSBvciBFdGhl cm5ldCBWUE5zIFtSRkM3NDMyXSksIG9yIFBzZXVkb3dpcmVzIFtSRkMzOTg1XS4gWy4uLl0mbmJz cDsgQTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IFBD RS1iYXNlZCBjZW50cmFsIGNvbnRyb2wgY2FuIGNvbnNpZGVyIHRoZSB3aG9sZSBuZXR3b3JrIGFu ZCBhbGwgY29tcG9uZW50cyBvZjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9 IkVOLUdCIj4mZ3Q7IGEgc2VydmljZSBhdCBvbmNlIHdoZW4gcGxhbm5pbmcgaG93IHRvIGRlbGl2 ZXIgdGhlIHNlcnZpY2UuIEl0IGNhbiB0aGVuIHVzZSBQQ0VQPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgdG8gbWFuYWdlIHRoZSBuZXR3b3JrIHJlc291 cmNlcyBhbmQgdG8gaW5zdGFsbCB0aGUgbmVjZXNzYXJ5IGFzc29jaWF0aW9uczwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IGJldHdlZW4gdGhvc2UgcmVz b3VyY2VzLiZxdW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdC Ij4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7 IFRoaXMgd29yZGluZyBvbiB1c2Ugb2YgUENFUCBjb25mdXNlcyBtZSwgbm8gbWF0dGVyIHdoYXQg aW50ZXJmYWNlIHdlIHRhbGs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJF Ti1HQiI+Jmd0OyBhYm91dC4gSSB3b3VsZCBoYXZlIGFzc3VtZWQgdGhhdCBZQU5HLWJhc2VkIHBy b3RvY29scyBzdWNoIGFzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4t R0IiPiZndDsgTkVUQ09ORi9SRVNUQ09ORiBjb3VsZCBiZSB1c2VmdWwgaW4gdGhpcyBjb250ZXh0 LCBhbmQgSSBhbSBhIGJpdCBzdXJwcmlzZWQgdGhhdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw PjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IHRoZSBkb2N1bWVudCBmb2N1c2VzIG9uIHVzaW5nIFBD RVAgZS5nLiBmb3IgTDNWUE4gc2VydmljZSBkZWxpdmVyeS4gQnkgdGhlIHdheSw8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyBJIGFsc28gd29uZGVyIGhv dyBQQ0VQIGZpdHMgaW50byB0aGUgZGlzY3Vzc2lvbiBvbiBRb1MgY2xhc3NpZmljYXRpb24gaW4g U2VjdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7 IDMuMi4yLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7 IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IEkgd29u ZGVyIGlmIHRoZSBhdXRob3JzIGNvdWxkIGFkZCB0byBTZWN0aW9uIDMuMi4yIGFuZCBTZWN0aW9u IDMuMi4zIGUuZy4gYTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdC Ij4mZ3Q7IG1lc3NhZ2Ugc2VxdWVuY2UgY2hhcnQgdGhhdCBpbGx1c3RyYXRlcyBob3cgd2hhdCBp cyBkaXNjdXNzZWQgaW4gdGhvc2Ugc2VjdGlvbnM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48 c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyByZWxhdGVzIHRvIFBDRVA/PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgTWljaGFlbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxz cGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxh bmc9IkVOLUdCIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVO LUdCIj4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgRnJvbTogVGVhcyBbPGEgaHJlZj0ibWFpbHRv OnRlYXMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzp0ZWFzLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgRVhUIEFkcmlhbiBGYXJyZWw8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyBTZW50OiBGcmlkYXksIE1h eSAxMywgMjAxNiA2OjU0IFBNPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0i RU4tR0IiPiZndDsgVG86IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSk7IDxhIGhyZWY9Im1h aWx0bzp0ZWFzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQp0ZWFzQGlldGYub3JnPC9hPjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IFN1YmplY3Q6 IFJlOiBbVGVhc10gQSBOZXcgSS1EIG9uIFBDRSBhcyBhIGNlbnRyYWwgY29udHJvbGxlcjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IEhlbGxvIGFnYWluLCBNaWNo YWVsLCBpdCBzZWVtcyB0byBiZSBteSBkYXkgZm9yIHJlcGx5aW5nIHRvIHlvdXIgZW1haWxzLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7ICZndDsgV2hlbiByZWFk aW5nIGFib3V0IHVzZXMgY2FzZXMgc3VjaCBhcyBMM1ZQTiBzZXJ2aWNlIGRlbGl2ZXJ5IGluPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgJmd0OyAmcXVv dDtTZWN0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZn dDsgMy4yLjMmcXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4t R0IiPiZndDsgJmd0OyB3aGF0IGlzIHRoZSBhdXRob3IncyB2aWV3IG9uIHRoZSBsaW5lIG9mIGRl bWFyY2F0aW9uIGJldHdlZW4gTkVUQ09ORjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFu IGxhbmc9IkVOLUdCIj4mZ3Q7ICZndDsgYW5kIFBDRVA/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNw YW4gbGFuZz0iRU4tR0IiPiZndDsgV2VsbCwgSSB3b25kZXIgd2hpY2ggaW50ZXJmYWNlIHlvdSdy ZSB0YWxraW5nIGFib3V0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVO LUdCIj4mZ3Q7IFRoZSBvbmVzIHRoYXQgb3V0IGluIGhlcmUgYXJlOjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IC0gdGhlIGludGVyZmFjZSBiZXR3ZWVu IGN1c3RvbWVyIGFuZCBvcGVyYXRvcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxh bmc9IkVOLUdCIj4mZ3Q7IC0gdGhlIGludGVyZmFjZSBiZXR3ZWVuICZxdW90O3NlcnZpY2Ugb3Jj aGVzdHJhdG9yJnF1b3Q7IGFuZCAmcXVvdDtuZXR3b3JrIG9yY2hlc3RyYXRvciZxdW90Ozwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IFRoZSBmb3JtZXIgb2YgdGhl c2UgaXMgbGlrZSB0aGUgaW50ZXJmYWNlIHVzZWQgaW4gTDNTTS4gQXMgY28tY2hhaXIgb2YgTDNT TSwgeW91PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsg bWlnaHQgbm90IGJlIHN1cnByaXNlZCB0byBoZWFyIHRoYXQgbXkgdmlldyBpcyB0aGF0IE5FVENP TkYgaXMgYSBmaW5lIHNvbHV0aW9uIC08L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBs YW5nPSJFTi1HQiI+Jmd0OyB3ZWxsLCB0aGUgdXNlIG9mIGEgWUFORyBkYXRhIG1vZGVsLCBpbiBh bnkgY2FzZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0 OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyBUaGUg bGF0dGVyIGlzIHRoZSBpbnRlcmZhY2UgYmV0d2VlbiAmcXVvdDtPcmNoZXN0cmF0b3IgLyBTZXJ2 aWNlIE1hbmFnZXIgLyBPU1MgLzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9 IkVOLUdCIj4mZ3Q7IE5NUyZxdW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxh bmc9IkVOLUdCIj4mZ3Q7IGFuZCAmcXVvdDtQQ0UtYmFzZWQgQ29udHJvbGxlciZxdW90OyBhcyBz aG93biBvbiB0aGUgdmFyaW91cyBmaWd1cmVzIGluIHRoZSBwaWN0dXJlLiBXZTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IGhhdmVuJ3QgZGlzY3Vzc2Vk IHRoaXMgaW50ZXJmYWNlIGluIHRoZSBkb2N1bWVudCwgYW5kIHBlcmhhcHMgd2Ugc2hvdWxkLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IElmIHlvdSBsb29rIGF0 IEZpZ3VyZSA2ICh3aXRoIHRoZSBoaWVyYXJjaHkgb2YgY29udHJvbGxlcnMpIHlvdSBtaWdodCBv YnNlcnZlIHRoYXQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+ Jmd0OyB0aGUgcGFyZW50IGNvbnRyb2xsZXIgY291bGQgYmUgaW1wbGVtZW50ZWQgdG8gYWN0IGFz IHRob3VnaCBpdCBpcyB0YWxraW5nIHRvIGFuIE5FPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+ PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgKGluIHRoZSBhYnN0cmFjdCBub2RlIG1vZGVsKSBhbmQg dGhhdCBtZWFucyB0aGF0IHRoZSBzb3V0aGJvdW5kIGludGVyZmFjZSBvZjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IHRoZSBwYXJlbnQgY29udHJvbGxl ciB3b3VsZCBiZSBQQ0VQLiBUaGF0IG1lYW5zIChvZiBjb3Vyc2UpIHRoYXQgdGhlPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgbm9ydGhib3VuZCBpbnRl cmZhY2Ugb2YgdGhlIGNoaWxkIGNvbnRyb2xsZXIgd291bGQgYWxzbyBiZSBQQ0VQLiBUaGVuLCBp dCBtaWdodDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7 IHNlZW0gb2J2aW91cyB0aGF0IHdlIHdvdWxkIHdhbnQgYWxsIFBDRSBpbXBsZW1lbnRhdGlvbnMg dG8gYmVoYXZlIHRoZSBzYW1lPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0i RU4tR0IiPiZndDsgd2F5IGFuZCBzbyB0aGF0IG1ha2VzIHRoZSBub3J0aGJvdW5kIGludGVyZmFj ZSBvZiB0aGUgcGFyZW50IFBDRTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9 IkVOLUdCIj4mZ3Q7IHdvdWxkL2NvdWxkL3Nob3VsZC9taWdodCBhbHNvIGJlIFBDRVAuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgV2hhdCBkbyB5b3UgdGhpbms/ PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgVGhhbmtzLDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IEFkcmlhbjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+ PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgVGVhcyBtYWlsaW5nIGxpc3Q8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyA8YSBocmVmPSJtYWlsdG86VGVhc0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlRlYXNAaWV0Zi5vcmc8L2E+PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90ZWFzIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RlYXM8L2E+PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy LjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpUZWFzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpUZWFzQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+VGVhc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RlYXMiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RlYXM8L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_655C07320163294895BBADA28372AF5D48863026FR712WXCHMBA15z_-- From nobody Mon May 23 07:01:33 2016 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 BF2D412D8C7 for ; Mon, 23 May 2016 07:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHikrMdTotvG for ; Mon, 23 May 2016 07:01:29 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB1EC12D198 for ; Mon, 23 May 2016 07:01:28 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id b65so134302830oia.1 for ; Mon, 23 May 2016 07:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ApXyd193PO7HxpE9B86u17fUnN/HJcM37vjDIa81zE0=; b=ReoOMojdcI7VLw+0d2xxDzsnEvoxr7D+lG3SEFPvBSOPyJHVAFzLm/QoGmsENKyyup xxhlWE3siyBgePV2lZJoZdZFzPsUIln1i8ilHBHTwLi3ntl+a4MKc9Zyopal512HQPEC 7OELtKe1HmpTdFixmOXXU1pLi5Wou55H7Ject+SZqVt5KX5Qjp3uwFTNQENpPJiMCIRz Znx6F9YoMTqxBGEibYCdHWOvsEx42572cE3OreEO6Ao1HnMfyODxAtfskIY/Pn4P37gP opPr0A/eTkvXHSN+PID0jFjw3IwYcaSEsz9qpW6a2v/GsSOmxD3Jc6BxeeuNJSbKICjL j1Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ApXyd193PO7HxpE9B86u17fUnN/HJcM37vjDIa81zE0=; b=D8hNHcoqNu+y+i7VN7SS3A6WxfXsheLDLsalDUbVMIQolcSpDdlganBYfYkrfDdGUM 45dff7dAAXmXojEzQT8aXyy/J/yV0YSPNN1g9QfkJ3smDvGzxsD4WgXKKiGj1ovuerU9 tXQo6kbT4zqtzTYsJix9WKewWvf3Mivil0OL15KT29H7WU6+CxN51bGyeinmq6umw8rk QV7XQeGa337kXJu6y5Oa/p07eVZI3I0CZGIi00+aX5vhG+zyVorvo2b1x2LOUvGaxby/ zwB8B8OfqF+teo4Dn82VZNl5VxY2gxtDdep+qOy7G5sFXxucy1TBL99yq0968NPKU1BK taDw== X-Gm-Message-State: AOPr4FV9ZlufAdhblDAOUZqE02v53NsvXe9BkEhXmlrC/Eozjwdj5Oc6g4uUXFzB1S7N4IqsSFwIahHmZ35fZg== X-Received: by 10.157.33.85 with SMTP id l21mr8586744otd.61.1464012086550; Mon, 23 May 2016 07:01:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.231.106 with HTTP; Mon, 23 May 2016 07:01:07 -0700 (PDT) In-Reply-To: <655C07320163294895BBADA28372AF5D48863026@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <0c6c01d1a7a2$f1a24860$d4e6d920$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48846127@FR712WXCHMBA15.zeu.alcatel-lucent.com> <042101d1ad38$12da5f50$388f1df0$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48860ADB@FR712WXCHMBA15.zeu.alcatel-lucent.com> <001d01d1b3e1$bec637d0$3c52a770$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48862397@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48862F8B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48863026@FR712WXCHMBA15.zeu.alcatel-lucent.com> From: "Andrew G. Malis" Date: Mon, 23 May 2016 10:01:07 -0400 Message-ID: To: "Scharf, Michael (Nokia - DE)" Content-Type: multipart/alternative; boundary=001a11463b925da685053382e01f Archived-At: Cc: "adrian@olddog.co.uk" , "teas@ietf.org" Subject: Re: [Teas] A New I-D on PCE as a central controller X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 14:01:33 -0000 --001a11463b925da685053382e01f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Michael, I agree that we don=E2=80=99t yet positively know that the conclusions in s= ection 4 are correct, but there=E2=80=99s also no specific knowledge that they are incorrect. So I think it would be fair to change the sentence "As such, no substantial changes to PCEP are required to support the concept of a PCE-based controller.=E2=80=9D to "As such, no substantial changes to PCEP = are expected to support the concept of a PCE-based controller.=E2=80=9D Cheers, Andy On Mon, May 23, 2016 at 9:52 AM, Scharf, Michael (Nokia - DE) < michael.scharf@nokia.com> wrote: > Fair point. But Section 4 should also be more explicit that the conclusio= n > there as hypothetical as the use cases Section 3. > > > > This would not fix the problem with Section 3.2.2 and Section 3.2.3 but a= t > least make clear that Section 4 is pure speculation only. > > > > Michael > > > > > > *From:* Andrew G. Malis [mailto:agmalis@gmail.com] > *Sent:* Monday, May 23, 2016 3:43 PM > > *To:* Scharf, Michael (Nokia - DE) > *Cc:* adrian@olddog.co.uk; teas@ietf.org > *Subject:* Re: [Teas] A New I-D on PCE as a central controller > > > > Michael, > > > > The introduction to section 3 says: =E2=80=9CAs previously mentioned, thi= s section > is intended to just make suggestions.=E2=80=9D. That sound like hypotheti= cal to me. > > > > Cheers, > > Andy > > > > > > On Mon, May 23, 2016 at 9:37 AM, Scharf, Michael (Nokia - DE) < > michael.scharf@nokia.com> wrote: > > Why doesn=E2=80=99t the document then mention that the use cases and conc= lusions > on PCEP are hypothetical? > > > > Michael > > > > > > *From:* Andrew G. Malis [mailto:agmalis@gmail.com] > *Sent:* Monday, May 23, 2016 3:35 PM > *To:* Scharf, Michael (Nokia - DE) > *Cc:* adrian@olddog.co.uk; teas@ietf.org > > > *Subject:* Re: [Teas] A New I-D on PCE as a central controller > > > > Michael, > > > > I think you=E2=80=99re expecting too much from this draft. It=E2=80=99s m= eant to be a very > high-level informational document to introduce the concepts and a > non-exhaustive list of possible applications and use cases. As with any > such early document, there=E2=80=99s some amount of speculative writing, = and > there=E2=80=99s no expectation that all of the discussed applications or = use cases > will actually come to fruition, and there may be others in the future tha= t > do end up being implemented. But the actual details of protocol changes a= nd > applications will be the topics of other standards-track draft(s) to come= . > > > > Cheers, > > Andy > > > > > > On Sun, May 22, 2016 at 5:34 PM, Scharf, Michael (Nokia - DE) < > michael.scharf@nokia.com> wrote: > > Hi Adrian, > > > > Many thanks for the tutorial. Since RFC 7491 already acknowledges the rol= e > of a PCE, I see little value of a high-level document that talks about PC= EP > as a general SBI for the topics mentioned in Section 3.2.2 and Section > 3.2.3, if that document does not discuss more specifically the impact on > PCEP, data models, etc. > > > > It should be obvious that in my point of view the wording in Sections > 3.2.2 and 3.2.3 is not clear. Just repeating the wording once again does > not address my question, since I have obviously read the document and sin= ce > I know the terminology (albeit I am not a native speaker). A generic flow > chart not detailing for which of the messages PCEP would be used, and wit= h > what content, also does not address my concern. > > In any case, if the content of Section 3.2.2 and Section 3.2.3 cannot be > made more explicit, it is impossible for me to understand whether the > conclusion in Section 4 =E2=80=A6 =E2=80=9CAs such, no substantial change= s to PCEP are > required to support the concept of a PCE-based controller. The only work > needed will be small extensions to carry additional or specific informati= on > elements for the individual use cases.=E2=80=9D is correct and how it is = actually > justified for the technical areas such as Section 3.2.2 and Section 3.2.3= . > > > > From my personal experience this sort of entirely generic conclusion coul= d > perhaps be a bit of simplification, but this may depend on the actual use > case. But in an I-D, I believe such a generic conclusion needs backing by > content and as far as I understand for Section 3.2.2 and Section 3.2.3 th= is > backing is lacking in the document right now. > > > > Thanks > > > > Michael > > > > > > *From:* Adrian Farrel [mailto:adrian@olddog.co.uk] > *Sent:* Sunday, May 22, 2016 6:24 AM > *To:* Scharf, Michael (Nokia - DE) > *Cc:* teas@ietf.org > > > *Subject:* RE: [Teas] A New I-D on PCE as a central controller > > > > Michael, > > > > I don't think it is complicated, but it is obviously not clear from the > document, so thank you for raising the concern. > > > > You say it doesn't matter which interface we're talking about, but it > does. PCEP is a protocol and protocols are used on interfaces. > > > > Let's start with southbound of the PCE. We already use PCEP on this > interface. We have always done. It is what PCEP was invented for. And > recent developments in Stateful PCE and PCE-Initiated LSPs have made PCEP > (and this interface) able to send control "commands" as well as respond t= o > requests. Thus, PCEP is an SBI protocol for use with signaling systems. > > > > Now, we might make several observations... > > > > In many (most?) MPLS-TE networks, every router is capable of being the > head end of LSPs. That means that in a PCE-enabled MPLS-TE network, every > router is a PCEP speaker. > > > > Additionally, we can observe that LSPs (or PWs) can be stitched together. > The stitching, if under the control of a PCE, requires a special > instruction to be sent to the stitching node. > > > > Furthermore, we can understand that a single end-to-end LSP is actually > the stitching of lots of single hop LSPs. That is really what a staticall= y > provisioned LSP is. > > > > Finally, we can see a desire to send TE instructions from a computation > engine (e.g., PCE) to individual network nodes to program their forwardin= g. > For example, in a Segment Routed network or for static MPLS-TE LSPs. > > > > > > Put all of this together with the recognition that all TE path management > is fundamentally the same and can be performed by the same engine, and th= at > it does not make sense for such an engine to have to implement multiple S= BI > protocols, and you end up with this draft. > > > > I don't think we are saying that this approach is compulsory, but we are > saying that it is possible. Other possibilities exist including using > NETCONF/YANG in place of PCEP, and enhancing BGP in place of PCEP. Others > have suggested XMPP. Frankly, if we were proposing a new protocol it woul= d > be correct to tell us not to, and to persuade us that one of the other > protocols will do the job. But here we are with three (or four) protocols > that fit the bill: each currently covers some of the function space and > each could easily be extended to cover the whole space. I'm not capable o= f > saying how to decide which protocol does which function, but I do see > pressures of implementation and deployment that lead to this draft. > > > > [Historic note: I was somewhat opposed to adding PCE-Initiated LSP suppor= t > to PCEP. I thought this bent the architecture further than was originally > intended. But we went there in the PEC WG and the I-D is now "complete". = By > adding support of PCE initiation of LSPs, we naturally opened the path to > this document. FWIW, this is not the first time that PCEP has been > discussed as a more general SBI protocol - RFC 7491 shows it in this > context although does not discuss it much (we should probably add a > reference to ABNO in this document).] > > > > > > Now, you say you are surprised that "the document focuses on using PCEP > e.g. for L3VPN service delivery." I think there is a significant differen= ce > between *requesting* a service and *delivering* that service. The service > request (as, for example, in L3SM) does not involve a PCE and is easily > achieved using a YANG model which, if the service request is on-line, can > be delivered using NETCONF. However, service delivery requires > "orchestration". Orchestration is the process of considering available > network resources and selecting what will be provisioned to support the > service. A PCE is at least a key feature of orchestration, just as it is = a > key component of a network controller. > > > > But the document does NOT focus on PCEP in quite the way you describe. In > fact, the only discussion is in 3.2.3 (just two paragraphs in the whole > document) where the focus is on the use of a PCE-based central controller > that can "consider the whole network and all components of a service at > once when planning how to deliver the service." It then goes on to observ= e > that PCEP can be used "to manage the network resources and to install the > necessary associations between those resources." > > > > > > If we included a message flow chart it would look something like... > > > > Service Manager PCE-based Controller NEs > > Request service---------> > > Compute > > Provision ------> > > <------------- Ack > > Update DBs > > <-------------------Ack > > > > If that simple figure helps with the understanding of this or any other > part of the document, we can surely add it. > > > > Cheers, > > Adrian > > > > > -----Original Message----- > > > From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com > ] > > > Sent: 20 May 2016 19:07 > > > To: adrian@olddog.co.uk; teas@ietf.org > > > Subject: RE: [Teas] A New I-D on PCE as a central controller > > > > > > As I said, I specifically wonder about Section 3.2.3 "Service Delivery"= , > which states > > > (omitting some parts that are not relevant here): > > > > > > "Various network services may be offered over a network. These include > > > protection services [...] Virtual Private Network (VPN) service (such a= s > Layer 3 > > > VPNs [RFC4364] or Ethernet VPNs [RFC7432]), or Pseudowires [RFC3985]. > [...] A > > > PCE-based central control can consider the whole network and all > components of > > > a service at once when planning how to deliver the service. It can then > use PCEP > > > to manage the network resources and to install the necessary associatio= ns > > > between those resources." > > > > > > This wording on use of PCEP confuses me, no matter what interface we ta= lk > > > about. I would have assumed that YANG-based protocols such as > > > NETCONF/RESTCONF could be useful in this context, and I am a bit > surprised that > > > the document focuses on using PCEP e.g. for L3VPN service delivery. By > the way, > > > I also wonder how PCEP fits into the discussion on QoS classification i= n > Section > > > 3.2.2. > > > > > > I wonder if the authors could add to Section 3.2.2 and Section 3.2.3 > e.g. a > > > message sequence chart that illustrates how what is discussed in those > sections > > > relates to PCEP? > > > > > > Michael > > > > > > > > > > > > -----Original Message----- > > > From: Teas [mailto:teas-bounces@ietf.org ] On > Behalf Of EXT Adrian Farrel > > > Sent: Friday, May 13, 2016 6:54 PM > > > To: Scharf, Michael (Nokia - DE); teas@ietf.org > > > Subject: Re: [Teas] A New I-D on PCE as a central controller > > > > > > Hello again, Michael, it seems to be my day for replying to your emails= . > > > > > > > When reading about uses cases such as L3VPN service delivery in > > > > "Section > > > 3.2.3", > > > > what is the author's view on the line of demarcation between NETCONF > > > > and PCEP? > > > > > > Well, I wonder which interface you're talking about. > > > The ones that out in here are: > > > - the interface between customer and operator > > > - the interface between "service orchestrator" and "network orchestrato= r" > > > > > > The former of these is like the interface used in L3SM. As co-chair of > L3SM, you > > > might not be surprised to hear that my view is that NETCONF is a fine > solution - > > > well, the use of a YANG data model, in any case. > > > > > > The latter is the interface between "Orchestrator / Service Manager / > OSS / > > > NMS" > > > and "PCE-based Controller" as shown on the various figures in the > picture. We > > > haven't discussed this interface in the document, and perhaps we should= . > > > > > > If you look at Figure 6 (with the hierarchy of controllers) you might > observe that > > > the parent controller could be implemented to act as though it is > talking to an NE > > > (in the abstract node model) and that means that the southbound > interface of > > > the parent controller would be PCEP. That means (of course) that the > > > northbound interface of the child controller would also be PCEP. Then, > it might > > > seem obvious that we would want all PCE implementations to behave the > same > > > way and so that makes the northbound interface of the parent PCE > > > would/could/should/might also be PCEP. > > > > > > What do you think? > > > > > > Thanks, > > > Adrian > > > > > > _______________________________________________ > > > Teas mailing list > > > Teas@ietf.org > > > https://www.ietf.org/mailman/listinfo/teas > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > > > > > --001a11463b925da685053382e01f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Michael,

I agree that we don=E2=80=99t = yet positively know that the conclusions in section 4 are correct, but ther= e=E2=80=99s also no specific knowledge that they are incorrect. So I think = it would be fair to change the sentence "As such, no substantial chang= es to PCEP are required to support the concept of a PCE-based controller.= =E2=80=9D to "As such, no substantial changes to PCEP are expected to = support the concept of a PCE-based controller.=E2=80=9D

Cheers,
Andy

On Mon, May 23, 2016 at 9:52 AM, Scharf, Michael (No= kia - DE) <michael.scharf@nokia.com> wrote:

Fair point. But Section 4= should also be more explicit that the conclusion there as hypothetical as = the use cases Section 3.

=C2=A0

This would not fix the pr= oblem with Section 3.2.2 and Section 3.2.3 but at least make clear that Sec= tion 4 is pure speculation only.

=C2=A0

Michael

=C2=A0

=C2=A0

From: Andrew G= . Malis [mailto:agma= lis@gmail.com]
Sent: Monday, May 23, 2016 3:43 PM

=
To: Scharf, Michael (Nokia - DE)
Cc: adrian@= olddog.co.uk; teas@i= etf.org
Subject: Re: [Teas] A New I-D on PCE as a central controller<= u>

=C2=A0

Michael,

=C2=A0

The introduction to section 3 says: =E2=80=9CAs prev= iously mentioned, this section is intended to just make suggestions.=E2=80= =9D. That sound like hypothetical to me.

=C2=A0

Cheers,

Andy

=C2=A0

=C2=A0

On Mon, May 23, 2016 at 9:37 AM, Scharf, Michael (No= kia - DE) <michael.scharf@nokia.com> wrote:

Why doesn=E2=80=99t the d= ocument then mention that the use cases and conclusions on PCEP are hypothe= tical?

=C2=A0

Michael<= /u>

=C2=A0

=C2=A0

From: Andrew G= . Malis [mailto:agma= lis@gmail.com]
Sent: Monday, May 23, 2016 3:35 PM
To: Scharf, Michael (Nokia - DE)
Cc: adrian@= olddog.co.uk; teas@ietf.org=


Subject: Re: [Teas] A New I-D on PCE as a central controller<= u>

=C2=A0

Michael,

=C2=A0

I think you=E2=80=99re expecting too much from this = draft. It=E2=80=99s meant to be a very high-level informational document to= introduce the concepts and a non-exhaustive list of possible applications and use cases. As with any such early document, there=E2=80=99s some amoun= t of speculative writing, and there=E2=80=99s no expectation that all of th= e discussed applications or use cases will actually come to fruition, and t= here may be others in the future that do end up being implemented. But the actual details of protocol changes and applicat= ions will be the topics of other standards-track draft(s) to come.

=C2=A0

Cheers,

Andy

=C2=A0

=C2=A0

On Sun, May 22, 2016 at 5:34 PM, Scharf, Michael (No= kia - DE) <michael.scharf@nokia.com> wrote:

Hi Adrian,

=C2=A0

Many thanks for the tu= torial. Since RFC 7491 already acknowledges the role of a PCE, I see little= value of a high-level document that talks about PCEP as a general SBI for the topics mentioned in Section 3.2.2 and Section 3.2= .3, if that document does not discuss more specifically the impact on PCEP,= data models, etc.

=C2=A0

It should be obvious t= hat in my point of view the wording in Sections 3.2.2 and 3.2.3 is not clea= r. Just repeating the wording once again does not address my question, since I have obviously read the document and since I know the= terminology (albeit I am not a native speaker). A generic flow chart not d= etailing for which of the messages PCEP would be used, and with what conten= t, also does not address my concern.

In any case, if the co= ntent of Section 3.2.2 and Section 3.2.3 cannot be made more explicit, it i= s impossible for me to understand whether the conclusion in Section 4 =E2=80=A6 =E2=80=9CAs such, no substantial changes to PCEP ar= e required to support the concept of a PCE-based controller. The only work = needed will be small extensions to carry additional or specific information= elements for the individual use cases.=E2=80=9D is correct and how it is actually justified for the technical areas such as Section 3= .2.2 and Section 3.2.3 .

=C2=A0

From my personal exper= ience this sort of entirely generic conclusion could perhaps be a bit of si= mplification, but this may depend on the actual use case. But in an I-D, I believe such a generic conclusion needs backing by = content and as far as I understand for Section 3.2.2 and Section 3.2.3 this= backing is lacking in the document right now.

=C2=A0

Thanks

=C2=A0

Michael<= u>

=C2=A0

=C2=A0

From: Adrian Farrel [mailto:ad= rian@olddog.co.uk]
Sent: Sunday, May 22, 2016 6:24 AM
To: Scharf, Michael (Nokia - DE)
Cc: teas@ietf.org=


Subject: RE: [Teas] A New I-D on PCE as a central controller<= u>

=C2=A0

Michael,

=C2=A0

I don't think it is complicated, but it is obvi= ously not clear from the document, so thank you for raising the concern.

=C2=A0

You say it doesn't matter which interface we= 9;re talking about, but it does. PCEP is a protocol and protocols are used = on interfaces.

=C2=A0

Let's start with southbound of the PCE. We alre= ady use PCEP on this interface. We have always done. It is what PCEP was in= vented for. And recent developments in Stateful PCE and PCE-Initiated LSPs = have made PCEP (and this interface) able to send control "commands" as well as respond to requests. Thus,= PCEP is an SBI protocol for use with signaling systems.

=C2=A0

Now, we might make several observations...

=C2=A0

In many (most?) MPLS-TE networks, every router is c= apable of being the head end of LSPs. That means that in a PCE-enabled MPLS= -TE network, every router is a PCEP speaker.

=C2=A0

Additionally, we can observe that LSPs (or PWs) can= be stitched together. The stitching, if under the control of a PCE, requir= es a special instruction to be sent to the stitching node.=

=C2=A0

Furthermore, we can understand that a single end-to= -end LSP is actually the stitching of lots of single hop LSPs. That is real= ly what a statically provisioned LSP is.

=C2=A0

Finally, we can see a desire to send TE instruction= s from a computation engine (e.g., PCE) to individual network nodes to prog= ram their forwarding. For example, in a Segment Routed network or for stati= c MPLS-TE LSPs.

=C2=A0

=C2=A0

Put all of this together with the recognition that = all TE path management is fundamentally the same and can be performed by th= e same engine, and that it does not make sense for such an engine to have t= o implement multiple SBI protocols, and you end up with this draft.

=C2=A0

I don't think we are saying that this approach = is compulsory, but we are saying that it is possible. Other possibilities e= xist including using NETCONF/YANG in place of PCEP, and enhancing BGP in pl= ace of PCEP. Others have suggested XMPP. Frankly, if we were proposing a new protocol it would be correct to tell u= s not to, and to persuade us that one of the other protocols will do the jo= b. But here we are with three (or four) protocols that fit the bill: each c= urrently covers some of the function space and each could easily be extended to cover the whole space. I'm = not capable of saying how to decide which protocol does which function, but= I do see pressures of implementation and deployment that lead to this draf= t.

=C2=A0

[Historic note: I was somewhat opposed to adding PC= E-Initiated LSP support to PCEP. I thought this bent the architecture furth= er than was originally intended. But we went there in the PEC WG and the I-= D is now "complete". By adding support of PCE initiation of LSPs, we naturally opened the path to this document. = FWIW, this is not the first time that PCEP has been discussed as a more gen= eral SBI protocol - RFC 7491 shows it in this context although does not dis= cuss it much (we should probably add a reference to ABNO in this document).]

=C2=A0

=C2=A0

Now, you say you are surprised that "the docum= ent focuses on using PCEP e.g. for L3VPN service delivery." I think th= ere is a significant difference between *requesting* a service and *deliver= ing* that service. The service request (as, for example, in L3SM) does not involve a PCE and is easily achieved using = a YANG model which, if the service request is on-line, can be delivered usi= ng NETCONF. However, service delivery requires "orchestration". O= rchestration is the process of considering available network resources and selecting what will be provisioned to supp= ort the service. A PCE is at least a key feature of orchestration, just as = it is a key component of a network controller.

=C2=A0

But the document does NOT focus on PCEP in quite th= e way you describe. In fact, the only discussion is in 3.2.3 (just two para= graphs in the whole document) where the focus is on the use of a PCE-based = central controller that can "consider the whole network and all components of a service at once when planning ho= w to deliver the service." It then goes on to observe that PCEP can be= used "to manage the network resources and to install the necessary as= sociations between those resources."

=C2=A0

=C2=A0

If we included a message flow chart it would look s= omething like...

=C2=A0

Servi= ce Manager=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 PCE-based Controller=C2=A0=C2=A0= =C2=A0=C2=A0 NEs

=C2= =A0=C2=A0=C2=A0=C2=A0 Request service--------->

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Co= mpute

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Provision ------>

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <------------- Ack

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Up= date DBs

=C2= =A0=C2=A0=C2=A0=C2=A0 <-------------------Ack

=C2= =A0

If th= at simple figure helps with the understanding of this or any other part of = the document, we can surely add it.

=C2= =A0

Cheer= s,

Adria= n

=C2=A0

> -----Original Message-----

> From: Scharf, Michael (Nokia - DE) [mailto:michael.s= charf@nokia.com]

> Sent: 20 May 2016 19:07

> To: adrian@olddog.co.uk; teas@ietf.org

> Subject: RE: [Teas] A New I-D on PCE as= a central controller

>

> As I said, I specifically wonder about Section= 3.2.3 "Service Delivery", which states

> (omitting some parts that are not relevant her= e):

>

> "Various network services may be offered = over a network. These include

> protection services [...] Virtual Private Netw= ork (VPN) service (such as Layer 3

> VPNs [RFC4364] or Ethernet VPNs [RFC7432]), or= Pseudowires [RFC3985]. [...]=C2=A0 A

> PCE-based central control can consider the who= le network and all components of

> a service at once when planning how to deliver= the service. It can then use PCEP

> to manage the network resources and to install= the necessary associations

> between those resources."

>

> This wording on use of PCEP confuses me, no ma= tter what interface we talk

> about. I would have assumed that YANG-based pr= otocols such as

> NETCONF/RESTCONF could be useful in this conte= xt, and I am a bit surprised that

> the document focuses on using PCEP e.g. for L3= VPN service delivery. By the way,

> I also wonder how PCEP fits into the discussio= n on QoS classification in Section

> 3.2.2.

>

> I wonder if the authors could add to Section 3= .2.2 and Section 3.2.3 e.g. a

> message sequence chart that illustrates how wh= at is discussed in those sections

> relates to PCEP?

>

> Michael

>

>

>

> -----Original Message-----

> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of EXT= Adrian Farrel

> Sent: Friday, May 13, 2016 6:54 PM

> To: Scharf, Michael (Nokia - DE); teas@ietf.org

> Subject: Re: [Teas] A New I-D on PCE as a cent= ral controller

>

> Hello again, Michael, it seems to be my day fo= r replying to your emails.

>

> > When reading about uses cases such as L3V= PN service delivery in

> > "Section

> 3.2.3",

> > what is the author's view on the line= of demarcation between NETCONF

> > and PCEP?

>

> Well, I wonder which interface you're talk= ing about.

> The ones that out in here are:

> - the interface between customer and operator<= /span>

> - the interface between "service orchestr= ator" and "network orchestrator"

>

> The former of these is like the interface used= in L3SM. As co-chair of L3SM, you

> might not be surprised to hear that my view is= that NETCONF is a fine solution -

> well, the use of a YANG data model, in any cas= e.

>

> The latter is the interface between "Orch= estrator / Service Manager / OSS /

> NMS"

> and "PCE-based Controller" as shown = on the various figures in the picture. We

> haven't discussed this interface in the do= cument, and perhaps we should.

>

> If you look at Figure 6 (with the hierarchy of= controllers) you might observe that

> the parent controller could be implemented to = act as though it is talking to an NE

> (in the abstract node model) and that means th= at the southbound interface of

> the parent controller would be PCEP. That mean= s (of course) that the

> northbound interface of the child controller w= ould also be PCEP. Then, it might

> seem obvious that we would want all PCE implem= entations to behave the same

> way and so that makes the northbound interface= of the parent PCE

> would/could/should/might also be PCEP.<= u>

>

> What do you think?

>

> Thanks,

> Adrian

>

> ______________________________________________= _

> Teas mailing list

> Teas@ietf.org

> https://www.ietf.org/mailman/listinfo/teas


_______________________________________________
Teas mailing list
Teas@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/teas

=C2=A0

=C2=A0


--001a11463b925da685053382e01f-- From nobody Mon May 23 07:02:22 2016 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 0735F12D8EA for ; Mon, 23 May 2016 07:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43MLzWRu7ofY for ; Mon, 23 May 2016 07:02:18 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E483612B064 for ; Mon, 23 May 2016 07:02:17 -0700 (PDT) Received: by mail-ig0-x22a.google.com with SMTP id l10so24544108igk.0 for ; Mon, 23 May 2016 07:02:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=UidU2h6eoVvWaHXfIZ689RH1wNHQSPlUzSpDuezREB4=; b=adtOSUuIcH5jhxICIPibfWUdSArkh6sV+VSYrUTpHAAAoO47cehQSaf3w8wLsbvPhH rpo+njcmkabUBONKxeSuF5Ae40naqLxyUYiL9U97jTGA8zIMU+L1FOw9teVJejToHiQG Yf8ZqJaASw2/QaEVVwyzGIZZqhhj+iKboAdFdautl7cJsCV/L9fnhRkZxgCEve7Ew+NK wXNLbtc5EMVIo8m8dY4TxonjBvpjCqNQTgGOO3yFleRkKpRLUmaFk6Yt4SumyMCNwMbp HTzkQ4CYv/4Vs3EQS5OQUbRl2fzrssYFKIf111qgmT7nw/2a0h0xJa3+UKgW2v/m+YXv XBNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=UidU2h6eoVvWaHXfIZ689RH1wNHQSPlUzSpDuezREB4=; b=DTPjpuFAUsMA4O/KVfPoCEclMSOEY5D5m7UwT44Kmj+hOTdYtlPvnBZ3VkRYxVJSvP K3E+xCjLbq+oRK9AMEe7j4RXJfEVUPRXlCJP/dLUqnfG3glJwNFGmqVgY8tfKJWGYSEx aHqHZ0YWva1V0/Kpn1aUGSPaZzanuJoDnEOYxtXaRVpkRIymiiMxeTajanOKguuZUHXC zw6ziSB0oHXl/uyTMgkC84s+icx5KffZyhGL8Z3XUsdRwZoFZg8RiwL3lFt1TOMr2J9P 7zo/nHUFd8RiqegAkffA+3nQUQvtSzxe0lDa9vMp67mHZR5YbeO6H37Mu957257/oF7n qb3g== X-Gm-Message-State: ALyK8tJKiwdw6NVT47uSPCD0Etwn+OVzbYw38ca8OKzWMiJbNfUE3mGwzDVHBqBLQabCVyr0PxwvYZFSeaaRsQ== MIME-Version: 1.0 X-Received: by 10.50.156.168 with SMTP id wf8mr369609igb.39.1464012135738; Mon, 23 May 2016 07:02:15 -0700 (PDT) Received: by 10.107.5.72 with HTTP; Mon, 23 May 2016 07:02:15 -0700 (PDT) In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908EDCB0A@dfweml501-mbx> References: <02d101d1af76$b0317cd0$10947670$@gmail.com> <0C72C38E7EBC34499E8A9E7DD007863908EDCB0A@dfweml501-mbx> Date: Mon, 23 May 2016 10:02:15 -0400 Message-ID: From: Cyril Margaria To: Igor Bryskin Content-Type: multipart/alternative; boundary=e89a8f3ba6a94c3c60053382e309 Archived-At: Cc: Xufeng Liu , TEAS WG Subject: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 14:02:20 -0000 --e89a8f3ba6a94c3c60053382e309 Content-Type: text/plain; charset=UTF-8 Hi, As you indicated, having an abstract label in the base would be better, its applicable to all MPLS/GMPLS networks. For layer specific label format/restrictions, this indeed belongs to the layer specific augmentations. Thanks, Cyril On 23 May 2016 at 09:51, Igor Bryskin wrote: > Cyril, > > > > You are absolutely right. But this belongs to the layer specific > augmentations, agreed? > > > > On the other hand I do a see a value in adding an abstract label to the > connectivity matrix (just like a label object in the TE path), so the basic > model will be more complete to address more than one layer. > > > > Igor > > > > *From:* Teas [mailto:teas-bounces@ietf.org] *On Behalf Of *Cyril Margaria > *Sent:* Monday, May 23, 2016 9:41 AM > *To:* Xufeng Liu > *Cc:* TEAS WG > *Subject:* Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo > > > > Hi, > > Another item that can be considered is to add a Label (Following RFC7579) > restrictions. This is needed, for example, in case of Fixed muxponders, > where the connectivity between the Low order ODUs to the high-order ODU is > fixed on each end. > > Can it be added to the list of changes for the connectivity matrix? > > > > Thanks, > > Cyril > > > > On 16 May 2016 at 09:27, Xufeng Liu wrote: > > Authors and contributors have discussed the use case of abstract topology, > to address the incompleteness of connectivity matrix. > > Current connectivity modeling is as follows: > > | +--rw connectivity-matrix* [id] > | | +--rw id uint32 > | | +--rw from > | | | +--rw tp-ref? leafref > | | +--rw to > | | | +--rw tp-ref? leafref > | | +--rw is-allowed? Boolean > > A Link TP may connect or disconnect to another Link TP, without detailed > information such as cost and resource sharing restriction. To get a better > abstraction of such connectivity, the following additional attributes are > planned to be added: > > max-bandwidth? decimal64 > max-resv-bandwidth? decimal64 > unreserved-bandwidth* [priority] > priority uint8 > +-- bandwidth? decimal64 > +-- te-default-metric uint32 > performance-metric // re-use the container from te-link-atrributes > te-srlgs // re-use the container from te-link-atrributes > > Comments are welcome. > > Thanks, > > - Xufeng > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > > > --e89a8f3ba6a94c3c60053382e309 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

As you indicated, ha= ving an abstract label in the base would be better, its applicable to all M= PLS/GMPLS networks.

For layer specific label format/restrictio= ns, this indeed belongs to the layer specific augmentations.

T= hanks,
Cyril

On 23 May 2016 at 09:51, Igor Bryskin &l= t;Igor.Bryskin= @huawei.com> wrote:

Cyril,

=C2=A0

You are absolutely right. But this belongs to t= he layer specific augmentations, agreed?

=C2=A0

On the other hand I do a see a value in adding = an abstract label to the connectivity matrix (just like a label object in t= he TE path), so the basic model will be more complete to address more than one layer.

=C2=A0

Igor

=C2=A0

From: Teas [ma= ilto:teas-bounce= s@ietf.org] On Behalf Of Cyril Margaria
Sent: Monday, May 23, 2016 9:41 AM
To: Xufeng Liu
Cc: TEAS WG
Subject: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-t= opo

=C2=A0

Hi,

Another item that can= be considered is to add a Label (Following RFC7579) restrictions. This is = needed, for example,=C2=A0 in case of Fixed muxponders, where the connectiv= ity between the Low order ODUs to the high-order ODU is fixed on each end.

Can it be added to the list of changes for the conne= ctivity matrix?

=C2=A0

Thanks,

Cyril

=C2=A0

On 16 May 2016 at 09:27, Xufeng Liu <xufeng.liu.ietf@gmail.co= m> wrote:

Authors and contributors have discussed the use case= of abstract topology,
to address the incompleteness of connectivity matrix.

Current connectivity modeling is as follows:

=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0+--rw connectivity-matrix* [id] =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw id=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 uint32
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw from
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +--rw tp-ref?=C2= =A0 =C2=A0leafref
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw to
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +--rw tp-ref?=C2= =A0 =C2=A0leafref
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw is-allowed?=C2=A0 = =C2=A0Boolean

A Link TP may connect or disconnect to another Link TP, without detailed information such as cost and resource sharing restriction. To get a better<= br> abstraction of such connectivity, the following additional attributes are planned to be added:

=C2=A0 max-bandwidth?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0decimal64
=C2=A0 max-resv-bandwidth?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 decimal64
=C2=A0 unreserved-bandwidth* [priority]
=C2=A0 priority=C2=A0 =C2=A0 =C2=A0uint8
=C2=A0 =C2=A0 =C2=A0+-- bandwidth?=C2=A0 =C2=A0decimal64
=C2=A0 =C2=A0 =C2=A0+-- te-default-metric uint32
=C2=A0 performance-metric // re-use the container from te-link-atrributes =C2=A0 te-srlgs=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// re-use the conta= iner from te-link-atrributes

Comments are welcome.

Thanks,

- Xufeng


_______________________________________________
Teas mailing list
Teas@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/teas

=C2=A0


--e89a8f3ba6a94c3c60053382e309-- From nobody Mon May 23 07:07:02 2016 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 4C1B612D909 for ; Mon, 23 May 2016 07:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.197 X-Spam-Level: X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16EABlA2Bqkc for ; Mon, 23 May 2016 07:06:58 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75D8D12D8F5 for ; Mon, 23 May 2016 07:06:58 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 7E3BC1684C470; Mon, 23 May 2016 14:06:53 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4NE6uo9021899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 May 2016 14:06:56 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u4NE6sti003870 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 May 2016 16:06:55 +0200 Received: from [149.204.106.226] (135.239.27.40) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 23 May 2016 16:06:26 +0200 To: Igor Bryskin , Cyril Margaria , Xufeng Liu References: <02d101d1af76$b0317cd0$10947670$@gmail.com> <0C72C38E7EBC34499E8A9E7DD007863908EDCB0A@dfweml501-mbx> From: Dieter Beller Organization: Nokia Message-ID: <551bf645-eeb8-a0aa-ff41-26d1043d8d84@nokia.com> Date: Mon, 23 May 2016 16:06:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908EDCB0A@dfweml501-mbx> Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.40] Archived-At: Cc: TEAS WG Subject: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 14:07:00 -0000

Hi Igor, Cyril, all,

fixed client to server mappings is s multi-layer aspect if I'm not wrong.

I thought that the connectivity matrix was trying to address abstraction drawbacks within a single network layer, i.e., to provide additional
information that would get lost during the abstraction process (example: srlg information associated with the underlying topology that was
abstracted into a single node).


Thanks,
Dieter

On 23.05.2016 15:51, Igor Bryskin wrote:

Cyril,

 

You are absolutely right. But this belongs to the layer specific augmentations, agreed?

 

On the other hand I do a see a value in adding an abstract label to the connectivity matrix (just like a label object in the TE path), so the basic model will be more complete to address more than one layer.

 

Igor

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Cyril Margaria
Sent: Monday, May 23, 2016 9:41 AM
To: Xufeng Liu
Cc: TEAS WG
Subject: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo

 

Hi,

Another item that can be considered is to add a Label (Following RFC7579) restrictions. This is needed, for example,  in case of Fixed muxponders, where the connectivity between the Low order ODUs to the high-order ODU is fixed on each end.

Can it be added to the list of changes for the connectivity matrix?

 

Thanks,

Cyril

 

On 16 May 2016 at 09:27, Xufeng Liu <xufeng.liu.ietf@gmail.com> wrote:

Authors and contributors have discussed the use case of abstract topology,
to address the incompleteness of connectivity matrix.

Current connectivity modeling is as follows:

      |     +--rw connectivity-matrix* [id]
      |     |  +--rw id            uint32
      |     |  +--rw from
      |     |  |  +--rw tp-ref?   leafref
      |     |  +--rw to
      |     |  |  +--rw tp-ref?   leafref
      |     |  +--rw is-allowed?   Boolean

A Link TP may connect or disconnect to another Link TP, without detailed
information such as cost and resource sharing restriction. To get a better
abstraction of such connectivity, the following additional attributes are
planned to be added:

  max-bandwidth?               decimal64
  max-resv-bandwidth?          decimal64
  unreserved-bandwidth* [priority]
  priority     uint8
     +-- bandwidth?   decimal64
     +-- te-default-metric uint32
  performance-metric // re-use the container from te-link-atrributes
  te-srlgs           // re-use the container from te-link-atrributes

Comments are welcome.

Thanks,

- Xufeng


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

 



_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas
From nobody Mon May 23 07:08:56 2016 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 3EFC412D90A for ; Mon, 23 May 2016 07:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCreliqKrH88 for ; Mon, 23 May 2016 07:08:52 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D97B412D8F5 for ; Mon, 23 May 2016 07:08:51 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 901AC6603947B; Mon, 23 May 2016 14:08:46 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4NE8nHs024846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 May 2016 14:08:49 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u4NE8jAU006942 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 May 2016 16:08:49 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.44]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Mon, 23 May 2016 16:08:38 +0200 From: "Scharf, Michael (Nokia - DE)" To: "Andrew G. Malis" Thread-Topic: [Teas] A New I-D on PCE as a central controller Thread-Index: AdGnosEWtnZGzgfkR5SQqz0Nm22cLQEn1m5QADlM4QABYpJEYABH2DeAACYha5AAH2sWgAAEO36g///gcID//9z9YIAAJ/WA///c9FA= Date: Mon, 23 May 2016 14:08:38 +0000 Message-ID: <655C07320163294895BBADA28372AF5D488630EA@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <0c6c01d1a7a2$f1a24860$d4e6d920$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48846127@FR712WXCHMBA15.zeu.alcatel-lucent.com> <042101d1ad38$12da5f50$388f1df0$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48860ADB@FR712WXCHMBA15.zeu.alcatel-lucent.com> <001d01d1b3e1$bec637d0$3c52a770$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48862397@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48862F8B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48863026@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D488630EAFR712WXCHMBA15z_" MIME-Version: 1.0 Archived-At: Cc: "adrian@olddog.co.uk" , "teas@ietf.org" Subject: Re: [Teas] A New I-D on PCE as a central controller X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 14:08:55 -0000 --_000_655C07320163294895BBADA28372AF5D488630EAFR712WXCHMBA15z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdCB3b3JkaW5nIGlzIHNvbWV3aGF0IGJldHRlci4gRnJvbSBteSBleHBlcmllbmNlIHdpdGgg dXNlIGNhc2VzIGRpc2N1c3NlZCBpbiB0aGlzIGRyYWZ0IGl0IHdvdWxkIGJlIGEgc3VycHJpc2Ug aWYgdGhhdCBleHBlY3RhdGlvbiB3YXMgdHJ1ZS4gQnV0LCBvZiBjb3Vyc2UsIHlvdXIgbWlsZWFn ZSBtYXkgdmFyeS4NCg0KTWljaGFlbA0KDQoNCkZyb206IEFuZHJldyBHLiBNYWxpcyBbbWFpbHRv OmFnbWFsaXNAZ21haWwuY29tXQ0KU2VudDogTW9uZGF5LCBNYXkgMjMsIDIwMTYgNDowMSBQTQ0K VG86IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSkNCkNjOiBhZHJpYW5Ab2xkZG9nLmNvLnVr OyB0ZWFzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1RlYXNdIEEgTmV3IEktRCBvbiBQQ0UgYXMg YSBjZW50cmFsIGNvbnRyb2xsZXINCg0KTWljaGFlbCwNCg0KSSBhZ3JlZSB0aGF0IHdlIGRvbuKA mXQgeWV0IHBvc2l0aXZlbHkga25vdyB0aGF0IHRoZSBjb25jbHVzaW9ucyBpbiBzZWN0aW9uIDQg YXJlIGNvcnJlY3QsIGJ1dCB0aGVyZeKAmXMgYWxzbyBubyBzcGVjaWZpYyBrbm93bGVkZ2UgdGhh dCB0aGV5IGFyZSBpbmNvcnJlY3QuIFNvIEkgdGhpbmsgaXQgd291bGQgYmUgZmFpciB0byBjaGFu Z2UgdGhlIHNlbnRlbmNlICJBcyBzdWNoLCBubyBzdWJzdGFudGlhbCBjaGFuZ2VzIHRvIFBDRVAg YXJlIHJlcXVpcmVkIHRvIHN1cHBvcnQgdGhlIGNvbmNlcHQgb2YgYSBQQ0UtYmFzZWQgY29udHJv bGxlci7igJ0gdG8gIkFzIHN1Y2gsIG5vIHN1YnN0YW50aWFsIGNoYW5nZXMgdG8gUENFUCBhcmUg ZXhwZWN0ZWQgdG8gc3VwcG9ydCB0aGUgY29uY2VwdCBvZiBhIFBDRS1iYXNlZCBjb250cm9sbGVy LuKAnQ0KDQpDaGVlcnMsDQpBbmR5DQoNCk9uIE1vbiwgTWF5IDIzLCAyMDE2IGF0IDk6NTIgQU0s IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSkgPG1pY2hhZWwuc2NoYXJmQG5va2lhLmNvbTxt YWlsdG86bWljaGFlbC5zY2hhcmZAbm9raWEuY29tPj4gd3JvdGU6DQpGYWlyIHBvaW50LiBCdXQg U2VjdGlvbiA0IHNob3VsZCBhbHNvIGJlIG1vcmUgZXhwbGljaXQgdGhhdCB0aGUgY29uY2x1c2lv biB0aGVyZSBhcyBoeXBvdGhldGljYWwgYXMgdGhlIHVzZSBjYXNlcyBTZWN0aW9uIDMuDQoNClRo aXMgd291bGQgbm90IGZpeCB0aGUgcHJvYmxlbSB3aXRoIFNlY3Rpb24gMy4yLjIgYW5kIFNlY3Rp b24gMy4yLjMgYnV0IGF0IGxlYXN0IG1ha2UgY2xlYXIgdGhhdCBTZWN0aW9uIDQgaXMgcHVyZSBz cGVjdWxhdGlvbiBvbmx5Lg0KDQpNaWNoYWVsDQoNCg0KRnJvbTogQW5kcmV3IEcuIE1hbGlzIFtt YWlsdG86YWdtYWxpc0BnbWFpbC5jb208bWFpbHRvOmFnbWFsaXNAZ21haWwuY29tPl0NClNlbnQ6 IE1vbmRheSwgTWF5IDIzLCAyMDE2IDM6NDMgUE0NCg0KVG86IFNjaGFyZiwgTWljaGFlbCAoTm9r aWEgLSBERSkNCkNjOiBhZHJpYW5Ab2xkZG9nLmNvLnVrPG1haWx0bzphZHJpYW5Ab2xkZG9nLmNv LnVrPjsgdGVhc0BpZXRmLm9yZzxtYWlsdG86dGVhc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBb VGVhc10gQSBOZXcgSS1EIG9uIFBDRSBhcyBhIGNlbnRyYWwgY29udHJvbGxlcg0KDQpNaWNoYWVs LA0KDQpUaGUgaW50cm9kdWN0aW9uIHRvIHNlY3Rpb24gMyBzYXlzOiDigJxBcyBwcmV2aW91c2x5 IG1lbnRpb25lZCwgdGhpcyBzZWN0aW9uIGlzIGludGVuZGVkIHRvIGp1c3QgbWFrZSBzdWdnZXN0 aW9ucy7igJ0uIFRoYXQgc291bmQgbGlrZSBoeXBvdGhldGljYWwgdG8gbWUuDQoNCkNoZWVycywN CkFuZHkNCg0KDQpPbiBNb24sIE1heSAyMywgMjAxNiBhdCA5OjM3IEFNLCBTY2hhcmYsIE1pY2hh ZWwgKE5va2lhIC0gREUpIDxtaWNoYWVsLnNjaGFyZkBub2tpYS5jb208bWFpbHRvOm1pY2hhZWwu c2NoYXJmQG5va2lhLmNvbT4+IHdyb3RlOg0KV2h5IGRvZXNu4oCZdCB0aGUgZG9jdW1lbnQgdGhl biBtZW50aW9uIHRoYXQgdGhlIHVzZSBjYXNlcyBhbmQgY29uY2x1c2lvbnMgb24gUENFUCBhcmUg aHlwb3RoZXRpY2FsPw0KDQpNaWNoYWVsDQoNCg0KRnJvbTogQW5kcmV3IEcuIE1hbGlzIFttYWls dG86YWdtYWxpc0BnbWFpbC5jb208bWFpbHRvOmFnbWFsaXNAZ21haWwuY29tPl0NClNlbnQ6IE1v bmRheSwgTWF5IDIzLCAyMDE2IDM6MzUgUE0NClRvOiBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0g REUpDQpDYzogYWRyaWFuQG9sZGRvZy5jby51azxtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51az47 IHRlYXNAaWV0Zi5vcmc8bWFpbHRvOnRlYXNAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBbVGVh c10gQSBOZXcgSS1EIG9uIFBDRSBhcyBhIGNlbnRyYWwgY29udHJvbGxlcg0KDQpNaWNoYWVsLA0K DQpJIHRoaW5rIHlvdeKAmXJlIGV4cGVjdGluZyB0b28gbXVjaCBmcm9tIHRoaXMgZHJhZnQuIEl0 4oCZcyBtZWFudCB0byBiZSBhIHZlcnkgaGlnaC1sZXZlbCBpbmZvcm1hdGlvbmFsIGRvY3VtZW50 IHRvIGludHJvZHVjZSB0aGUgY29uY2VwdHMgYW5kIGEgbm9uLWV4aGF1c3RpdmUgbGlzdCBvZiBw b3NzaWJsZSBhcHBsaWNhdGlvbnMgYW5kIHVzZSBjYXNlcy4gQXMgd2l0aCBhbnkgc3VjaCBlYXJs eSBkb2N1bWVudCwgdGhlcmXigJlzIHNvbWUgYW1vdW50IG9mIHNwZWN1bGF0aXZlIHdyaXRpbmcs IGFuZCB0aGVyZeKAmXMgbm8gZXhwZWN0YXRpb24gdGhhdCBhbGwgb2YgdGhlIGRpc2N1c3NlZCBh cHBsaWNhdGlvbnMgb3IgdXNlIGNhc2VzIHdpbGwgYWN0dWFsbHkgY29tZSB0byBmcnVpdGlvbiwg YW5kIHRoZXJlIG1heSBiZSBvdGhlcnMgaW4gdGhlIGZ1dHVyZSB0aGF0IGRvIGVuZCB1cCBiZWlu ZyBpbXBsZW1lbnRlZC4gQnV0IHRoZSBhY3R1YWwgZGV0YWlscyBvZiBwcm90b2NvbCBjaGFuZ2Vz IGFuZCBhcHBsaWNhdGlvbnMgd2lsbCBiZSB0aGUgdG9waWNzIG9mIG90aGVyIHN0YW5kYXJkcy10 cmFjayBkcmFmdChzKSB0byBjb21lLg0KDQpDaGVlcnMsDQpBbmR5DQoNCg0KT24gU3VuLCBNYXkg MjIsIDIwMTYgYXQgNTozNCBQTSwgU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFKSA8bWljaGFl bC5zY2hhcmZAbm9raWEuY29tPG1haWx0bzptaWNoYWVsLnNjaGFyZkBub2tpYS5jb20+PiB3cm90 ZToNCkhpIEFkcmlhbiwNCg0KTWFueSB0aGFua3MgZm9yIHRoZSB0dXRvcmlhbC4gU2luY2UgUkZD IDc0OTEgYWxyZWFkeSBhY2tub3dsZWRnZXMgdGhlIHJvbGUgb2YgYSBQQ0UsIEkgc2VlIGxpdHRs ZSB2YWx1ZSBvZiBhIGhpZ2gtbGV2ZWwgZG9jdW1lbnQgdGhhdCB0YWxrcyBhYm91dCBQQ0VQIGFz IGEgZ2VuZXJhbCBTQkkgZm9yIHRoZSB0b3BpY3MgbWVudGlvbmVkIGluIFNlY3Rpb24gMy4yLjIg YW5kIFNlY3Rpb24gMy4yLjMsIGlmIHRoYXQgZG9jdW1lbnQgZG9lcyBub3QgZGlzY3VzcyBtb3Jl IHNwZWNpZmljYWxseSB0aGUgaW1wYWN0IG9uIFBDRVAsIGRhdGEgbW9kZWxzLCBldGMuDQoNCkl0 IHNob3VsZCBiZSBvYnZpb3VzIHRoYXQgaW4gbXkgcG9pbnQgb2YgdmlldyB0aGUgd29yZGluZyBp biBTZWN0aW9ucyAzLjIuMiBhbmQgMy4yLjMgaXMgbm90IGNsZWFyLiBKdXN0IHJlcGVhdGluZyB0 aGUgd29yZGluZyBvbmNlIGFnYWluIGRvZXMgbm90IGFkZHJlc3MgbXkgcXVlc3Rpb24sIHNpbmNl IEkgaGF2ZSBvYnZpb3VzbHkgcmVhZCB0aGUgZG9jdW1lbnQgYW5kIHNpbmNlIEkga25vdyB0aGUg dGVybWlub2xvZ3kgKGFsYmVpdCBJIGFtIG5vdCBhIG5hdGl2ZSBzcGVha2VyKS4gQSBnZW5lcmlj IGZsb3cgY2hhcnQgbm90IGRldGFpbGluZyBmb3Igd2hpY2ggb2YgdGhlIG1lc3NhZ2VzIFBDRVAg d291bGQgYmUgdXNlZCwgYW5kIHdpdGggd2hhdCBjb250ZW50LCBhbHNvIGRvZXMgbm90IGFkZHJl c3MgbXkgY29uY2Vybi4NCkluIGFueSBjYXNlLCBpZiB0aGUgY29udGVudCBvZiBTZWN0aW9uIDMu Mi4yIGFuZCBTZWN0aW9uIDMuMi4zIGNhbm5vdCBiZSBtYWRlIG1vcmUgZXhwbGljaXQsIGl0IGlz IGltcG9zc2libGUgZm9yIG1lIHRvIHVuZGVyc3RhbmQgd2hldGhlciB0aGUgY29uY2x1c2lvbiBp biBTZWN0aW9uIDQg4oCmIOKAnEFzIHN1Y2gsIG5vIHN1YnN0YW50aWFsIGNoYW5nZXMgdG8gUENF UCBhcmUgcmVxdWlyZWQgdG8gc3VwcG9ydCB0aGUgY29uY2VwdCBvZiBhIFBDRS1iYXNlZCBjb250 cm9sbGVyLiBUaGUgb25seSB3b3JrIG5lZWRlZCB3aWxsIGJlIHNtYWxsIGV4dGVuc2lvbnMgdG8g Y2FycnkgYWRkaXRpb25hbCBvciBzcGVjaWZpYyBpbmZvcm1hdGlvbiBlbGVtZW50cyBmb3IgdGhl IGluZGl2aWR1YWwgdXNlIGNhc2VzLuKAnSBpcyBjb3JyZWN0IGFuZCBob3cgaXQgaXMgYWN0dWFs bHkganVzdGlmaWVkIGZvciB0aGUgdGVjaG5pY2FsIGFyZWFzIHN1Y2ggYXMgU2VjdGlvbiAzLjIu MiBhbmQgU2VjdGlvbiAzLjIuMyAuDQoNCkZyb20gbXkgcGVyc29uYWwgZXhwZXJpZW5jZSB0aGlz IHNvcnQgb2YgZW50aXJlbHkgZ2VuZXJpYyBjb25jbHVzaW9uIGNvdWxkIHBlcmhhcHMgYmUgYSBi aXQgb2Ygc2ltcGxpZmljYXRpb24sIGJ1dCB0aGlzIG1heSBkZXBlbmQgb24gdGhlIGFjdHVhbCB1 c2UgY2FzZS4gQnV0IGluIGFuIEktRCwgSSBiZWxpZXZlIHN1Y2ggYSBnZW5lcmljIGNvbmNsdXNp b24gbmVlZHMgYmFja2luZyBieSBjb250ZW50IGFuZCBhcyBmYXIgYXMgSSB1bmRlcnN0YW5kIGZv ciBTZWN0aW9uIDMuMi4yIGFuZCBTZWN0aW9uIDMuMi4zIHRoaXMgYmFja2luZyBpcyBsYWNraW5n IGluIHRoZSBkb2N1bWVudCByaWdodCBub3cuDQoNClRoYW5rcw0KDQpNaWNoYWVsDQoNCg0KRnJv bTogQWRyaWFuIEZhcnJlbCBbbWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWs8bWFpbHRvOmFkcmlh bkBvbGRkb2cuY28udWs+XQ0KU2VudDogU3VuZGF5LCBNYXkgMjIsIDIwMTYgNjoyNCBBTQ0KVG86 IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSkNCkNjOiB0ZWFzQGlldGYub3JnPG1haWx0bzp0 ZWFzQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSRTogW1RlYXNdIEEgTmV3IEktRCBvbiBQQ0UgYXMg YSBjZW50cmFsIGNvbnRyb2xsZXINCg0KDQpNaWNoYWVsLA0KDQoNCg0KSSBkb24ndCB0aGluayBp dCBpcyBjb21wbGljYXRlZCwgYnV0IGl0IGlzIG9idmlvdXNseSBub3QgY2xlYXIgZnJvbSB0aGUg ZG9jdW1lbnQsIHNvIHRoYW5rIHlvdSBmb3IgcmFpc2luZyB0aGUgY29uY2Vybi4NCg0KDQoNCllv dSBzYXkgaXQgZG9lc24ndCBtYXR0ZXIgd2hpY2ggaW50ZXJmYWNlIHdlJ3JlIHRhbGtpbmcgYWJv dXQsIGJ1dCBpdCBkb2VzLiBQQ0VQIGlzIGEgcHJvdG9jb2wgYW5kIHByb3RvY29scyBhcmUgdXNl ZCBvbiBpbnRlcmZhY2VzLg0KDQoNCg0KTGV0J3Mgc3RhcnQgd2l0aCBzb3V0aGJvdW5kIG9mIHRo ZSBQQ0UuIFdlIGFscmVhZHkgdXNlIFBDRVAgb24gdGhpcyBpbnRlcmZhY2UuIFdlIGhhdmUgYWx3 YXlzIGRvbmUuIEl0IGlzIHdoYXQgUENFUCB3YXMgaW52ZW50ZWQgZm9yLiBBbmQgcmVjZW50IGRl dmVsb3BtZW50cyBpbiBTdGF0ZWZ1bCBQQ0UgYW5kIFBDRS1Jbml0aWF0ZWQgTFNQcyBoYXZlIG1h ZGUgUENFUCAoYW5kIHRoaXMgaW50ZXJmYWNlKSBhYmxlIHRvIHNlbmQgY29udHJvbCAiY29tbWFu ZHMiIGFzIHdlbGwgYXMgcmVzcG9uZCB0byByZXF1ZXN0cy4gVGh1cywgUENFUCBpcyBhbiBTQkkg cHJvdG9jb2wgZm9yIHVzZSB3aXRoIHNpZ25hbGluZyBzeXN0ZW1zLg0KDQoNCg0KTm93LCB3ZSBt aWdodCBtYWtlIHNldmVyYWwgb2JzZXJ2YXRpb25zLi4uDQoNCg0KDQpJbiBtYW55IChtb3N0Pykg TVBMUy1URSBuZXR3b3JrcywgZXZlcnkgcm91dGVyIGlzIGNhcGFibGUgb2YgYmVpbmcgdGhlIGhl YWQgZW5kIG9mIExTUHMuIFRoYXQgbWVhbnMgdGhhdCBpbiBhIFBDRS1lbmFibGVkIE1QTFMtVEUg bmV0d29yaywgZXZlcnkgcm91dGVyIGlzIGEgUENFUCBzcGVha2VyLg0KDQoNCg0KQWRkaXRpb25h bGx5LCB3ZSBjYW4gb2JzZXJ2ZSB0aGF0IExTUHMgKG9yIFBXcykgY2FuIGJlIHN0aXRjaGVkIHRv Z2V0aGVyLiBUaGUgc3RpdGNoaW5nLCBpZiB1bmRlciB0aGUgY29udHJvbCBvZiBhIFBDRSwgcmVx dWlyZXMgYSBzcGVjaWFsIGluc3RydWN0aW9uIHRvIGJlIHNlbnQgdG8gdGhlIHN0aXRjaGluZyBu b2RlLg0KDQoNCg0KRnVydGhlcm1vcmUsIHdlIGNhbiB1bmRlcnN0YW5kIHRoYXQgYSBzaW5nbGUg ZW5kLXRvLWVuZCBMU1AgaXMgYWN0dWFsbHkgdGhlIHN0aXRjaGluZyBvZiBsb3RzIG9mIHNpbmds ZSBob3AgTFNQcy4gVGhhdCBpcyByZWFsbHkgd2hhdCBhIHN0YXRpY2FsbHkgcHJvdmlzaW9uZWQg TFNQIGlzLg0KDQoNCg0KRmluYWxseSwgd2UgY2FuIHNlZSBhIGRlc2lyZSB0byBzZW5kIFRFIGlu c3RydWN0aW9ucyBmcm9tIGEgY29tcHV0YXRpb24gZW5naW5lIChlLmcuLCBQQ0UpIHRvIGluZGl2 aWR1YWwgbmV0d29yayBub2RlcyB0byBwcm9ncmFtIHRoZWlyIGZvcndhcmRpbmcuIEZvciBleGFt cGxlLCBpbiBhIFNlZ21lbnQgUm91dGVkIG5ldHdvcmsgb3IgZm9yIHN0YXRpYyBNUExTLVRFIExT UHMuDQoNCg0KDQoNCg0KUHV0IGFsbCBvZiB0aGlzIHRvZ2V0aGVyIHdpdGggdGhlIHJlY29nbml0 aW9uIHRoYXQgYWxsIFRFIHBhdGggbWFuYWdlbWVudCBpcyBmdW5kYW1lbnRhbGx5IHRoZSBzYW1l IGFuZCBjYW4gYmUgcGVyZm9ybWVkIGJ5IHRoZSBzYW1lIGVuZ2luZSwgYW5kIHRoYXQgaXQgZG9l cyBub3QgbWFrZSBzZW5zZSBmb3Igc3VjaCBhbiBlbmdpbmUgdG8gaGF2ZSB0byBpbXBsZW1lbnQg bXVsdGlwbGUgU0JJIHByb3RvY29scywgYW5kIHlvdSBlbmQgdXAgd2l0aCB0aGlzIGRyYWZ0Lg0K DQoNCg0KSSBkb24ndCB0aGluayB3ZSBhcmUgc2F5aW5nIHRoYXQgdGhpcyBhcHByb2FjaCBpcyBj b21wdWxzb3J5LCBidXQgd2UgYXJlIHNheWluZyB0aGF0IGl0IGlzIHBvc3NpYmxlLiBPdGhlciBw b3NzaWJpbGl0aWVzIGV4aXN0IGluY2x1ZGluZyB1c2luZyBORVRDT05GL1lBTkcgaW4gcGxhY2Ug b2YgUENFUCwgYW5kIGVuaGFuY2luZyBCR1AgaW4gcGxhY2Ugb2YgUENFUC4gT3RoZXJzIGhhdmUg c3VnZ2VzdGVkIFhNUFAuIEZyYW5rbHksIGlmIHdlIHdlcmUgcHJvcG9zaW5nIGEgbmV3IHByb3Rv Y29sIGl0IHdvdWxkIGJlIGNvcnJlY3QgdG8gdGVsbCB1cyBub3QgdG8sIGFuZCB0byBwZXJzdWFk ZSB1cyB0aGF0IG9uZSBvZiB0aGUgb3RoZXIgcHJvdG9jb2xzIHdpbGwgZG8gdGhlIGpvYi4gQnV0 IGhlcmUgd2UgYXJlIHdpdGggdGhyZWUgKG9yIGZvdXIpIHByb3RvY29scyB0aGF0IGZpdCB0aGUg YmlsbDogZWFjaCBjdXJyZW50bHkgY292ZXJzIHNvbWUgb2YgdGhlIGZ1bmN0aW9uIHNwYWNlIGFu ZCBlYWNoIGNvdWxkIGVhc2lseSBiZSBleHRlbmRlZCB0byBjb3ZlciB0aGUgd2hvbGUgc3BhY2Uu IEknbSBub3QgY2FwYWJsZSBvZiBzYXlpbmcgaG93IHRvIGRlY2lkZSB3aGljaCBwcm90b2NvbCBk b2VzIHdoaWNoIGZ1bmN0aW9uLCBidXQgSSBkbyBzZWUgcHJlc3N1cmVzIG9mIGltcGxlbWVudGF0 aW9uIGFuZCBkZXBsb3ltZW50IHRoYXQgbGVhZCB0byB0aGlzIGRyYWZ0Lg0KDQoNCg0KW0hpc3Rv cmljIG5vdGU6IEkgd2FzIHNvbWV3aGF0IG9wcG9zZWQgdG8gYWRkaW5nIFBDRS1Jbml0aWF0ZWQg TFNQIHN1cHBvcnQgdG8gUENFUC4gSSB0aG91Z2h0IHRoaXMgYmVudCB0aGUgYXJjaGl0ZWN0dXJl IGZ1cnRoZXIgdGhhbiB3YXMgb3JpZ2luYWxseSBpbnRlbmRlZC4gQnV0IHdlIHdlbnQgdGhlcmUg aW4gdGhlIFBFQyBXRyBhbmQgdGhlIEktRCBpcyBub3cgImNvbXBsZXRlIi4gQnkgYWRkaW5nIHN1 cHBvcnQgb2YgUENFIGluaXRpYXRpb24gb2YgTFNQcywgd2UgbmF0dXJhbGx5IG9wZW5lZCB0aGUg cGF0aCB0byB0aGlzIGRvY3VtZW50LiBGV0lXLCB0aGlzIGlzIG5vdCB0aGUgZmlyc3QgdGltZSB0 aGF0IFBDRVAgaGFzIGJlZW4gZGlzY3Vzc2VkIGFzIGEgbW9yZSBnZW5lcmFsIFNCSSBwcm90b2Nv bCAtIFJGQyA3NDkxIHNob3dzIGl0IGluIHRoaXMgY29udGV4dCBhbHRob3VnaCBkb2VzIG5vdCBk aXNjdXNzIGl0IG11Y2ggKHdlIHNob3VsZCBwcm9iYWJseSBhZGQgYSByZWZlcmVuY2UgdG8gQUJO TyBpbiB0aGlzIGRvY3VtZW50KS5dDQoNCg0KDQoNCg0KTm93LCB5b3Ugc2F5IHlvdSBhcmUgc3Vy cHJpc2VkIHRoYXQgInRoZSBkb2N1bWVudCBmb2N1c2VzIG9uIHVzaW5nIFBDRVAgZS5nLiBmb3Ig TDNWUE4gc2VydmljZSBkZWxpdmVyeS4iIEkgdGhpbmsgdGhlcmUgaXMgYSBzaWduaWZpY2FudCBk aWZmZXJlbmNlIGJldHdlZW4gKnJlcXVlc3RpbmcqIGEgc2VydmljZSBhbmQgKmRlbGl2ZXJpbmcq IHRoYXQgc2VydmljZS4gVGhlIHNlcnZpY2UgcmVxdWVzdCAoYXMsIGZvciBleGFtcGxlLCBpbiBM M1NNKSBkb2VzIG5vdCBpbnZvbHZlIGEgUENFIGFuZCBpcyBlYXNpbHkgYWNoaWV2ZWQgdXNpbmcg YSBZQU5HIG1vZGVsIHdoaWNoLCBpZiB0aGUgc2VydmljZSByZXF1ZXN0IGlzIG9uLWxpbmUsIGNh biBiZSBkZWxpdmVyZWQgdXNpbmcgTkVUQ09ORi4gSG93ZXZlciwgc2VydmljZSBkZWxpdmVyeSBy ZXF1aXJlcyAib3JjaGVzdHJhdGlvbiIuIE9yY2hlc3RyYXRpb24gaXMgdGhlIHByb2Nlc3Mgb2Yg Y29uc2lkZXJpbmcgYXZhaWxhYmxlIG5ldHdvcmsgcmVzb3VyY2VzIGFuZCBzZWxlY3Rpbmcgd2hh dCB3aWxsIGJlIHByb3Zpc2lvbmVkIHRvIHN1cHBvcnQgdGhlIHNlcnZpY2UuIEEgUENFIGlzIGF0 IGxlYXN0IGEga2V5IGZlYXR1cmUgb2Ygb3JjaGVzdHJhdGlvbiwganVzdCBhcyBpdCBpcyBhIGtl eSBjb21wb25lbnQgb2YgYSBuZXR3b3JrIGNvbnRyb2xsZXIuDQoNCg0KDQpCdXQgdGhlIGRvY3Vt ZW50IGRvZXMgTk9UIGZvY3VzIG9uIFBDRVAgaW4gcXVpdGUgdGhlIHdheSB5b3UgZGVzY3JpYmUu IEluIGZhY3QsIHRoZSBvbmx5IGRpc2N1c3Npb24gaXMgaW4gMy4yLjMgKGp1c3QgdHdvIHBhcmFn cmFwaHMgaW4gdGhlIHdob2xlIGRvY3VtZW50KSB3aGVyZSB0aGUgZm9jdXMgaXMgb24gdGhlIHVz ZSBvZiBhIFBDRS1iYXNlZCBjZW50cmFsIGNvbnRyb2xsZXIgdGhhdCBjYW4gImNvbnNpZGVyIHRo ZSB3aG9sZSBuZXR3b3JrIGFuZCBhbGwgY29tcG9uZW50cyBvZiBhIHNlcnZpY2UgYXQgb25jZSB3 aGVuIHBsYW5uaW5nIGhvdyB0byBkZWxpdmVyIHRoZSBzZXJ2aWNlLiIgSXQgdGhlbiBnb2VzIG9u IHRvIG9ic2VydmUgdGhhdCBQQ0VQIGNhbiBiZSB1c2VkICJ0byBtYW5hZ2UgdGhlIG5ldHdvcmsg cmVzb3VyY2VzIGFuZCB0byBpbnN0YWxsIHRoZSBuZWNlc3NhcnkgYXNzb2NpYXRpb25zIGJldHdl ZW4gdGhvc2UgcmVzb3VyY2VzLiINCg0KDQoNCg0KDQpJZiB3ZSBpbmNsdWRlZCBhIG1lc3NhZ2Ug ZmxvdyBjaGFydCBpdCB3b3VsZCBsb29rIHNvbWV0aGluZyBsaWtlLi4uDQoNCg0KDQpTZXJ2aWNl IE1hbmFnZXIgICAgICBQQ0UtYmFzZWQgQ29udHJvbGxlciAgICAgTkVzDQoNCiAgICAgUmVxdWVz dCBzZXJ2aWNlLS0tLS0tLS0tPg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgIENvbXB1dGUN Cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFByb3Zpc2lvbiAtLS0tLS0+DQoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC0tLS0tLS0tLS0tLS0gQWNrDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgVXBkYXRlIERCcw0KDQogICAgIDwtLS0tLS0tLS0tLS0tLS0t LS0tQWNrDQoNCg0KDQpJZiB0aGF0IHNpbXBsZSBmaWd1cmUgaGVscHMgd2l0aCB0aGUgdW5kZXJz dGFuZGluZyBvZiB0aGlzIG9yIGFueSBvdGhlciBwYXJ0IG9mIHRoZSBkb2N1bWVudCwgd2UgY2Fu IHN1cmVseSBhZGQgaXQuDQoNCg0KDQpDaGVlcnMsDQoNCkFkcmlhbg0KDQoNCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQo+IEZyb206IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBE RSkgW21haWx0bzptaWNoYWVsLnNjaGFyZkBub2tpYS5jb21dDQoNCj4gU2VudDogMjAgTWF5IDIw MTYgMTk6MDcNCg0KPiBUbzogYWRyaWFuQG9sZGRvZy5jby51azxtYWlsdG86YWRyaWFuQG9sZGRv Zy5jby51az47IHRlYXNAaWV0Zi5vcmc8bWFpbHRvOnRlYXNAaWV0Zi5vcmc+DQoNCj4gU3ViamVj dDogUkU6IFtUZWFzXSBBIE5ldyBJLUQgb24gUENFIGFzIGEgY2VudHJhbCBjb250cm9sbGVyDQoN Cj4NCg0KPiBBcyBJIHNhaWQsIEkgc3BlY2lmaWNhbGx5IHdvbmRlciBhYm91dCBTZWN0aW9uIDMu Mi4zICJTZXJ2aWNlIERlbGl2ZXJ5Iiwgd2hpY2ggc3RhdGVzDQoNCj4gKG9taXR0aW5nIHNvbWUg cGFydHMgdGhhdCBhcmUgbm90IHJlbGV2YW50IGhlcmUpOg0KDQo+DQoNCj4gIlZhcmlvdXMgbmV0 d29yayBzZXJ2aWNlcyBtYXkgYmUgb2ZmZXJlZCBvdmVyIGEgbmV0d29yay4gVGhlc2UgaW5jbHVk ZQ0KDQo+IHByb3RlY3Rpb24gc2VydmljZXMgWy4uLl0gVmlydHVhbCBQcml2YXRlIE5ldHdvcmsg KFZQTikgc2VydmljZSAoc3VjaCBhcyBMYXllciAzDQoNCj4gVlBOcyBbUkZDNDM2NF0gb3IgRXRo ZXJuZXQgVlBOcyBbUkZDNzQzMl0pLCBvciBQc2V1ZG93aXJlcyBbUkZDMzk4NV0uIFsuLi5dICBB DQoNCj4gUENFLWJhc2VkIGNlbnRyYWwgY29udHJvbCBjYW4gY29uc2lkZXIgdGhlIHdob2xlIG5l dHdvcmsgYW5kIGFsbCBjb21wb25lbnRzIG9mDQoNCj4gYSBzZXJ2aWNlIGF0IG9uY2Ugd2hlbiBw bGFubmluZyBob3cgdG8gZGVsaXZlciB0aGUgc2VydmljZS4gSXQgY2FuIHRoZW4gdXNlIFBDRVAN Cg0KPiB0byBtYW5hZ2UgdGhlIG5ldHdvcmsgcmVzb3VyY2VzIGFuZCB0byBpbnN0YWxsIHRoZSBu ZWNlc3NhcnkgYXNzb2NpYXRpb25zDQoNCj4gYmV0d2VlbiB0aG9zZSByZXNvdXJjZXMuIg0KDQo+ DQoNCj4gVGhpcyB3b3JkaW5nIG9uIHVzZSBvZiBQQ0VQIGNvbmZ1c2VzIG1lLCBubyBtYXR0ZXIg d2hhdCBpbnRlcmZhY2Ugd2UgdGFsaw0KDQo+IGFib3V0LiBJIHdvdWxkIGhhdmUgYXNzdW1lZCB0 aGF0IFlBTkctYmFzZWQgcHJvdG9jb2xzIHN1Y2ggYXMNCg0KPiBORVRDT05GL1JFU1RDT05GIGNv dWxkIGJlIHVzZWZ1bCBpbiB0aGlzIGNvbnRleHQsIGFuZCBJIGFtIGEgYml0IHN1cnByaXNlZCB0 aGF0DQoNCj4gdGhlIGRvY3VtZW50IGZvY3VzZXMgb24gdXNpbmcgUENFUCBlLmcuIGZvciBMM1ZQ TiBzZXJ2aWNlIGRlbGl2ZXJ5LiBCeSB0aGUgd2F5LA0KDQo+IEkgYWxzbyB3b25kZXIgaG93IFBD RVAgZml0cyBpbnRvIHRoZSBkaXNjdXNzaW9uIG9uIFFvUyBjbGFzc2lmaWNhdGlvbiBpbiBTZWN0 aW9uDQoNCj4gMy4yLjIuDQoNCj4NCg0KPiBJIHdvbmRlciBpZiB0aGUgYXV0aG9ycyBjb3VsZCBh ZGQgdG8gU2VjdGlvbiAzLjIuMiBhbmQgU2VjdGlvbiAzLjIuMyBlLmcuIGENCg0KPiBtZXNzYWdl IHNlcXVlbmNlIGNoYXJ0IHRoYXQgaWxsdXN0cmF0ZXMgaG93IHdoYXQgaXMgZGlzY3Vzc2VkIGlu IHRob3NlIHNlY3Rpb25zDQoNCj4gcmVsYXRlcyB0byBQQ0VQPw0KDQo+DQoNCj4gTWljaGFlbA0K DQo+DQoNCj4NCg0KPg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCj4gRnJvbTog VGVhcyBbbWFpbHRvOnRlYXMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVYVCBBZHJp YW4gRmFycmVsDQoNCj4gU2VudDogRnJpZGF5LCBNYXkgMTMsIDIwMTYgNjo1NCBQTQ0KDQo+IFRv OiBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUpOyB0ZWFzQGlldGYub3JnPG1haWx0bzp0ZWFz QGlldGYub3JnPg0KDQo+IFN1YmplY3Q6IFJlOiBbVGVhc10gQSBOZXcgSS1EIG9uIFBDRSBhcyBh IGNlbnRyYWwgY29udHJvbGxlcg0KDQo+DQoNCj4gSGVsbG8gYWdhaW4sIE1pY2hhZWwsIGl0IHNl ZW1zIHRvIGJlIG15IGRheSBmb3IgcmVwbHlpbmcgdG8geW91ciBlbWFpbHMuDQoNCj4NCg0KPiA+ IFdoZW4gcmVhZGluZyBhYm91dCB1c2VzIGNhc2VzIHN1Y2ggYXMgTDNWUE4gc2VydmljZSBkZWxp dmVyeSBpbg0KDQo+ID4gIlNlY3Rpb24NCg0KPiAzLjIuMyIsDQoNCj4gPiB3aGF0IGlzIHRoZSBh dXRob3IncyB2aWV3IG9uIHRoZSBsaW5lIG9mIGRlbWFyY2F0aW9uIGJldHdlZW4gTkVUQ09ORg0K DQo+ID4gYW5kIFBDRVA/DQoNCj4NCg0KPiBXZWxsLCBJIHdvbmRlciB3aGljaCBpbnRlcmZhY2Ug eW91J3JlIHRhbGtpbmcgYWJvdXQuDQoNCj4gVGhlIG9uZXMgdGhhdCBvdXQgaW4gaGVyZSBhcmU6 DQoNCj4gLSB0aGUgaW50ZXJmYWNlIGJldHdlZW4gY3VzdG9tZXIgYW5kIG9wZXJhdG9yDQoNCj4g LSB0aGUgaW50ZXJmYWNlIGJldHdlZW4gInNlcnZpY2Ugb3JjaGVzdHJhdG9yIiBhbmQgIm5ldHdv cmsgb3JjaGVzdHJhdG9yIg0KDQo+DQoNCj4gVGhlIGZvcm1lciBvZiB0aGVzZSBpcyBsaWtlIHRo ZSBpbnRlcmZhY2UgdXNlZCBpbiBMM1NNLiBBcyBjby1jaGFpciBvZiBMM1NNLCB5b3UNCg0KPiBt aWdodCBub3QgYmUgc3VycHJpc2VkIHRvIGhlYXIgdGhhdCBteSB2aWV3IGlzIHRoYXQgTkVUQ09O RiBpcyBhIGZpbmUgc29sdXRpb24gLQ0KDQo+IHdlbGwsIHRoZSB1c2Ugb2YgYSBZQU5HIGRhdGEg bW9kZWwsIGluIGFueSBjYXNlLg0KDQo+DQoNCj4gVGhlIGxhdHRlciBpcyB0aGUgaW50ZXJmYWNl IGJldHdlZW4gIk9yY2hlc3RyYXRvciAvIFNlcnZpY2UgTWFuYWdlciAvIE9TUyAvDQoNCj4gTk1T Ig0KDQo+IGFuZCAiUENFLWJhc2VkIENvbnRyb2xsZXIiIGFzIHNob3duIG9uIHRoZSB2YXJpb3Vz IGZpZ3VyZXMgaW4gdGhlIHBpY3R1cmUuIFdlDQoNCj4gaGF2ZW4ndCBkaXNjdXNzZWQgdGhpcyBp bnRlcmZhY2UgaW4gdGhlIGRvY3VtZW50LCBhbmQgcGVyaGFwcyB3ZSBzaG91bGQuDQoNCj4NCg0K PiBJZiB5b3UgbG9vayBhdCBGaWd1cmUgNiAod2l0aCB0aGUgaGllcmFyY2h5IG9mIGNvbnRyb2xs ZXJzKSB5b3UgbWlnaHQgb2JzZXJ2ZSB0aGF0DQoNCj4gdGhlIHBhcmVudCBjb250cm9sbGVyIGNv dWxkIGJlIGltcGxlbWVudGVkIHRvIGFjdCBhcyB0aG91Z2ggaXQgaXMgdGFsa2luZyB0byBhbiBO RQ0KDQo+IChpbiB0aGUgYWJzdHJhY3Qgbm9kZSBtb2RlbCkgYW5kIHRoYXQgbWVhbnMgdGhhdCB0 aGUgc291dGhib3VuZCBpbnRlcmZhY2Ugb2YNCg0KPiB0aGUgcGFyZW50IGNvbnRyb2xsZXIgd291 bGQgYmUgUENFUC4gVGhhdCBtZWFucyAob2YgY291cnNlKSB0aGF0IHRoZQ0KDQo+IG5vcnRoYm91 bmQgaW50ZXJmYWNlIG9mIHRoZSBjaGlsZCBjb250cm9sbGVyIHdvdWxkIGFsc28gYmUgUENFUC4g VGhlbiwgaXQgbWlnaHQNCg0KPiBzZWVtIG9idmlvdXMgdGhhdCB3ZSB3b3VsZCB3YW50IGFsbCBQ Q0UgaW1wbGVtZW50YXRpb25zIHRvIGJlaGF2ZSB0aGUgc2FtZQ0KDQo+IHdheSBhbmQgc28gdGhh dCBtYWtlcyB0aGUgbm9ydGhib3VuZCBpbnRlcmZhY2Ugb2YgdGhlIHBhcmVudCBQQ0UNCg0KPiB3 b3VsZC9jb3VsZC9zaG91bGQvbWlnaHQgYWxzbyBiZSBQQ0VQLg0KDQo+DQoNCj4gV2hhdCBkbyB5 b3UgdGhpbms/DQoNCj4NCg0KPiBUaGFua3MsDQoNCj4gQWRyaWFuDQoNCj4NCg0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQo+IFRlYXMgbWFpbGlu ZyBsaXN0DQoNCj4gVGVhc0BpZXRmLm9yZzxtYWlsdG86VGVhc0BpZXRmLm9yZz4NCg0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RlYXMNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRlYXMgbWFpbGluZyBsaXN0DQpUZWFz QGlldGYub3JnPG1haWx0bzpUZWFzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby90ZWFzDQoNCg0KDQo= --_000_655C07320163294895BBADA28372AF5D488630EAFR712WXCHMBA15z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENo YXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4 LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+VGhhdCB3b3JkaW5nIGlzIHNvbWV3aGF0IGJldHRlci4gRnJvbSBteSBleHBlcmll bmNlIHdpdGggdXNlIGNhc2VzIGRpc2N1c3NlZCBpbiB0aGlzIGRyYWZ0IGl0IHdvdWxkIGJlIGEg c3VycHJpc2UgaWYgdGhhdCBleHBlY3RhdGlvbiB3YXMgdHJ1ZS4gQnV0LCBvZiBjb3Vyc2UsDQog eW91ciBtaWxlYWdlIG1heSB2YXJ5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWljaGFlbDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFuZHJldyBHLiBNYWxpcyBbbWFpbHRv OmFnbWFsaXNAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgTWF5IDIzLCAy MDE2IDQ6MDEgUE08YnI+DQo8Yj5Ubzo8L2I+IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSk8 YnI+DQo8Yj5DYzo8L2I+IGFkcmlhbkBvbGRkb2cuY28udWs7IHRlYXNAaWV0Zi5vcmc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFtUZWFzXSBBIE5ldyBJLUQgb24gUENFIGFzIGEgY2VudHJhbCBj b250cm9sbGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5N aWNoYWVsLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBh Z3JlZSB0aGF0IHdlIGRvbuKAmXQgeWV0IHBvc2l0aXZlbHkga25vdyB0aGF0IHRoZSBjb25jbHVz aW9ucyBpbiBzZWN0aW9uIDQgYXJlIGNvcnJlY3QsIGJ1dCB0aGVyZeKAmXMgYWxzbyBubyBzcGVj aWZpYyBrbm93bGVkZ2UgdGhhdCB0aGV5IGFyZSBpbmNvcnJlY3QuIFNvIEkgdGhpbmsgaXQgd291 bGQgYmUgZmFpciB0byBjaGFuZ2UgdGhlIHNlbnRlbmNlICZxdW90O0FzIHN1Y2gsIG5vIHN1YnN0 YW50aWFsIGNoYW5nZXMNCiB0byBQQ0VQIGFyZSByZXF1aXJlZCB0byBzdXBwb3J0IHRoZSBjb25j ZXB0IG9mIGEgUENFLWJhc2VkIGNvbnRyb2xsZXIu4oCdIHRvICZxdW90O0FzIHN1Y2gsIG5vIHN1 YnN0YW50aWFsIGNoYW5nZXMgdG8gUENFUCBhcmUgZXhwZWN0ZWQgdG8gc3VwcG9ydCB0aGUgY29u Y2VwdCBvZiBhIFBDRS1iYXNlZCBjb250cm9sbGVyLuKAnTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVlcnMsPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgTWF5IDIzLCAyMDE2 IGF0IDk6NTIgQU0sIFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSkgJmx0OzxhIGhyZWY9Im1h aWx0bzptaWNoYWVsLnNjaGFyZkBub2tpYS5jb20iIHRhcmdldD0iX2JsYW5rIj5taWNoYWVsLnNj aGFyZkBub2tpYS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+RmFpciBwb2ludC4gQnV0IFNlY3Rpb24gNCBzaG91bGQgYWxzbyBiZSBtb3Jl IGV4cGxpY2l0IHRoYXQgdGhlIGNvbmNsdXNpb24gdGhlcmUgYXMgaHlwb3RoZXRpY2FsDQogYXMg dGhlIHVzZSBjYXNlcyBTZWN0aW9uIDMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpcyB3b3VsZCBub3QgZml4 IHRoZSBwcm9ibGVtIHdpdGggU2VjdGlvbiAzLjIuMiBhbmQgU2VjdGlvbiAzLjIuMyBidXQgYXQg bGVhc3QgbWFrZSBjbGVhciB0aGF0DQogU2VjdGlvbiA0IGlzIHB1cmUgc3BlY3VsYXRpb24gb25s eS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5NaWNoYWVsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQW5kcmV3IEcuIE1hbGlzIFttYWlsdG86PGEgaHJlZj0i bWFpbHRvOmFnbWFsaXNAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+YWdtYWxpc0BnbWFpbC5j b208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgTWF5IDIzLCAyMDE2IDM6NDMgUE08 L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxicj4NCjxiPlRvOjwvYj4gU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFKTxicj4NCjxiPkNj OjwvYj4gPGEgaHJlZj0ibWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWsiIHRhcmdldD0iX2JsYW5r Ij5hZHJpYW5Ab2xkZG9nLmNvLnVrPC9hPjsNCjxhIGhyZWY9Im1haWx0bzp0ZWFzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+dGVhc0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtUZWFzXSBBIE5ldyBJLUQgb24gUENFIGFzIGEgY2VudHJhbCBjb250cm9sbGVyPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5NaWNoYWVsLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPlRoZSBpbnRyb2R1Y3Rpb24gdG8gc2VjdGlvbiAzIHNheXM6IOKAnEFzIHBy ZXZpb3VzbHkgbWVudGlvbmVkLCB0aGlzIHNlY3Rpb24gaXMgaW50ZW5kZWQgdG8ganVzdCBtYWtl IHN1Z2dlc3Rpb25zLuKAnS4gVGhhdCBzb3VuZCBsaWtlIGh5cG90aGV0aWNhbCB0byBtZS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNo ZWVycyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPk9uIE1vbiwgTWF5IDIzLCAyMDE2IGF0IDk6MzcgQU0sIFNjaGFyZiwgTWlj aGFlbCAoTm9raWEgLSBERSkgJmx0OzxhIGhyZWY9Im1haWx0bzptaWNoYWVsLnNjaGFyZkBub2tp YS5jb20iIHRhcmdldD0iX2JsYW5rIj5taWNoYWVsLnNjaGFyZkBub2tpYS5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2h5IGRvZXNu4oCZ dCB0aGUgZG9jdW1lbnQgdGhlbiBtZW50aW9uIHRoYXQgdGhlIHVzZSBjYXNlcyBhbmQgY29uY2x1 c2lvbnMgb24gUENFUCBhcmUgaHlwb3RoZXRpY2FsPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1pY2hhZWw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBBbmRy ZXcgRy4gTWFsaXMgW21haWx0bzo8YSBocmVmPSJtYWlsdG86YWdtYWxpc0BnbWFpbC5jb20iIHRh cmdldD0iX2JsYW5rIj5hZ21hbGlzQGdtYWlsLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4g TW9uZGF5LCBNYXkgMjMsIDIwMTYgMzozNSBQTTxicj4NCjxiPlRvOjwvYj4gU2NoYXJmLCBNaWNo YWVsIChOb2tpYSAtIERFKTxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmFkcmlhbkBv bGRkb2cuY28udWsiIHRhcmdldD0iX2JsYW5rIj5hZHJpYW5Ab2xkZG9nLmNvLnVrPC9hPjsNCjxh IGhyZWY9Im1haWx0bzp0ZWFzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dGVhc0BpZXRmLm9y ZzwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVGVhc10gQSBOZXcgSS1EIG9uIFBD RSBhcyBhIGNlbnRyYWwgY29udHJvbGxlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TWljaGFlbCw8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHRoaW5rIHlvdeKA mXJlIGV4cGVjdGluZyB0b28gbXVjaCBmcm9tIHRoaXMgZHJhZnQuIEl04oCZcyBtZWFudCB0byBi ZSBhIHZlcnkgaGlnaC1sZXZlbCBpbmZvcm1hdGlvbmFsIGRvY3VtZW50IHRvIGludHJvZHVjZSB0 aGUgY29uY2VwdHMgYW5kIGEgbm9uLWV4aGF1c3RpdmUgbGlzdCBvZiBwb3NzaWJsZSBhcHBsaWNh dGlvbnMNCiBhbmQgdXNlIGNhc2VzLiBBcyB3aXRoIGFueSBzdWNoIGVhcmx5IGRvY3VtZW50LCB0 aGVyZeKAmXMgc29tZSBhbW91bnQgb2Ygc3BlY3VsYXRpdmUgd3JpdGluZywgYW5kIHRoZXJl4oCZ cyBubyBleHBlY3RhdGlvbiB0aGF0IGFsbCBvZiB0aGUgZGlzY3Vzc2VkIGFwcGxpY2F0aW9ucyBv ciB1c2UgY2FzZXMgd2lsbCBhY3R1YWxseSBjb21lIHRvIGZydWl0aW9uLCBhbmQgdGhlcmUgbWF5 IGJlIG90aGVycyBpbiB0aGUgZnV0dXJlIHRoYXQgZG8gZW5kIHVwDQogYmVpbmcgaW1wbGVtZW50 ZWQuIEJ1dCB0aGUgYWN0dWFsIGRldGFpbHMgb2YgcHJvdG9jb2wgY2hhbmdlcyBhbmQgYXBwbGlj YXRpb25zIHdpbGwgYmUgdGhlIHRvcGljcyBvZiBvdGhlciBzdGFuZGFyZHMtdHJhY2sgZHJhZnQo cykgdG8gY29tZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFN1biwgTWF5IDIyLCAyMDE2IGF0IDU6MzQg UE0sIFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSkgJmx0OzxhIGhyZWY9Im1haWx0bzptaWNo YWVsLnNjaGFyZkBub2tpYS5jb20iIHRhcmdldD0iX2JsYW5rIj5taWNoYWVsLnNjaGFyZkBub2tp YS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SGkgQWRyaWFuLDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk1hbnkgdGhhbmtzIGZvciB0 aGUgdHV0b3JpYWwuIFNpbmNlIFJGQyA3NDkxIGFscmVhZHkgYWNrbm93bGVkZ2VzIHRoZSByb2xl IG9mIGEgUENFLCBJIHNlZSBsaXR0bGUgdmFsdWUgb2YgYSBoaWdoLWxldmVsIGRvY3VtZW50IHRo YXQgdGFsa3MgYWJvdXQgUENFUA0KIGFzIGEgZ2VuZXJhbCBTQkkgZm9yIHRoZSB0b3BpY3MgbWVu dGlvbmVkIGluIFNlY3Rpb24gMy4yLjIgYW5kIFNlY3Rpb24gMy4yLjMsIGlmIHRoYXQgZG9jdW1l bnQgZG9lcyBub3QgZGlzY3VzcyBtb3JlIHNwZWNpZmljYWxseSB0aGUgaW1wYWN0IG9uIFBDRVAs IGRhdGEgbW9kZWxzLCBldGMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+SXQgc2hvdWxkIGJlIG9idmlvdXMgdGhhdCBpbiBteSBwb2ludCBvZiB2aWV3IHRoZSB3b3Jk aW5nIGluIFNlY3Rpb25zIDMuMi4yIGFuZCAzLjIuMyBpcyBub3QgY2xlYXIuIEp1c3QgcmVwZWF0 aW5nIHRoZSB3b3JkaW5nIG9uY2UgYWdhaW4gZG9lcyBub3QgYWRkcmVzcw0KIG15IHF1ZXN0aW9u LCBzaW5jZSBJIGhhdmUgb2J2aW91c2x5IHJlYWQgdGhlIGRvY3VtZW50IGFuZCBzaW5jZSBJIGtu b3cgdGhlIHRlcm1pbm9sb2d5IChhbGJlaXQgSSBhbSBub3QgYSBuYXRpdmUgc3BlYWtlcikuIEEg Z2VuZXJpYyBmbG93IGNoYXJ0IG5vdCBkZXRhaWxpbmcgZm9yIHdoaWNoIG9mIHRoZSBtZXNzYWdl cyBQQ0VQIHdvdWxkIGJlIHVzZWQsIGFuZCB3aXRoIHdoYXQgY29udGVudCwgYWxzbyBkb2VzIG5v dCBhZGRyZXNzIG15IGNvbmNlcm4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SW4gYW55IGNhc2UsIGlmIHRo ZSBjb250ZW50IG9mIFNlY3Rpb24gMy4yLjIgYW5kIFNlY3Rpb24gMy4yLjMgY2Fubm90IGJlIG1h ZGUgbW9yZSBleHBsaWNpdCwgaXQgaXMgaW1wb3NzaWJsZSBmb3IgbWUgdG8gdW5kZXJzdGFuZCB3 aGV0aGVyIHRoZSBjb25jbHVzaW9uDQogaW4gU2VjdGlvbiA0IOKApiDigJxBcyBzdWNoLCBubyBz dWJzdGFudGlhbCBjaGFuZ2VzIHRvIFBDRVAgYXJlIHJlcXVpcmVkIHRvIHN1cHBvcnQgdGhlIGNv bmNlcHQgb2YgYSBQQ0UtYmFzZWQgY29udHJvbGxlci4gVGhlIG9ubHkgd29yayBuZWVkZWQgd2ls bCBiZSBzbWFsbCBleHRlbnNpb25zIHRvIGNhcnJ5IGFkZGl0aW9uYWwgb3Igc3BlY2lmaWMgaW5m b3JtYXRpb24gZWxlbWVudHMgZm9yIHRoZSBpbmRpdmlkdWFsIHVzZSBjYXNlcy7igJ0gaXMgY29y cmVjdA0KIGFuZCBob3cgaXQgaXMgYWN0dWFsbHkganVzdGlmaWVkIGZvciB0aGUgdGVjaG5pY2Fs IGFyZWFzIHN1Y2ggYXMgU2VjdGlvbiAzLjIuMiBhbmQgU2VjdGlvbiAzLjIuMyAuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+RnJvbSBteSBwZXJzb25hbCBleHBlcmll bmNlIHRoaXMgc29ydCBvZiBlbnRpcmVseSBnZW5lcmljIGNvbmNsdXNpb24gY291bGQgcGVyaGFw cyBiZSBhIGJpdCBvZiBzaW1wbGlmaWNhdGlvbiwgYnV0IHRoaXMgbWF5IGRlcGVuZCBvbiB0aGUg YWN0dWFsIHVzZQ0KIGNhc2UuIEJ1dCBpbiBhbiBJLUQsIEkgYmVsaWV2ZSBzdWNoIGEgZ2VuZXJp YyBjb25jbHVzaW9uIG5lZWRzIGJhY2tpbmcgYnkgY29udGVudCBhbmQgYXMgZmFyIGFzIEkgdW5k ZXJzdGFuZCBmb3IgU2VjdGlvbiAzLjIuMiBhbmQgU2VjdGlvbiAzLjIuMyB0aGlzIGJhY2tpbmcg aXMgbGFja2luZyBpbiB0aGUgZG9jdW1lbnQgcmlnaHQgbm93Lg0KPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhhbmtzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+TWljaGFlbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBw dCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48Yj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBBZHJpYW4NCiBGYXJy ZWwgW21haWx0bzo8YSBocmVmPSJtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51ayIgdGFyZ2V0PSJf YmxhbmsiPmFkcmlhbkBvbGRkb2cuY28udWs8L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRh eSwgTWF5IDIyLCAyMDE2IDY6MjQgQU08YnI+DQo8Yj5Ubzo8L2I+IFNjaGFyZiwgTWljaGFlbCAo Tm9raWEgLSBERSk8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzp0ZWFzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+dGVhc0BpZXRmLm9yZzwvYT48L3NwYW4+PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iREUiPjxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW1RlYXNdIEEgTmV3IEktRCBvbiBQQ0UgYXMgYSBjZW50 cmFsIGNvbnRyb2xsZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJERSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4t R0IiPk1pY2hhZWwsIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdC Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+SSBk b24ndCB0aGluayBpdCBpcyBjb21wbGljYXRlZCwgYnV0IGl0IGlzIG9idmlvdXNseSBub3QgY2xl YXIgZnJvbSB0aGUgZG9jdW1lbnQsIHNvIHRoYW5rIHlvdSBmb3IgcmFpc2luZyB0aGUgY29uY2Vy bi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPllvdSBzYXkgaXQgZG9l c24ndCBtYXR0ZXIgd2hpY2ggaW50ZXJmYWNlIHdlJ3JlIHRhbGtpbmcgYWJvdXQsIGJ1dCBpdCBk b2VzLiBQQ0VQIGlzIGEgcHJvdG9jb2wgYW5kIHByb3RvY29scyBhcmUgdXNlZCBvbiBpbnRlcmZh Y2VzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+TGV0J3Mgc3RhcnQg d2l0aCBzb3V0aGJvdW5kIG9mIHRoZSBQQ0UuIFdlIGFscmVhZHkgdXNlIFBDRVAgb24gdGhpcyBp bnRlcmZhY2UuIFdlIGhhdmUgYWx3YXlzIGRvbmUuIEl0IGlzIHdoYXQgUENFUCB3YXMgaW52ZW50 ZWQgZm9yLiBBbmQgcmVjZW50IGRldmVsb3BtZW50cyBpbiBTdGF0ZWZ1bCBQQ0UgYW5kIFBDRS1J bml0aWF0ZWQgTFNQcyBoYXZlIG1hZGUgUENFUCAoYW5kIHRoaXMgaW50ZXJmYWNlKSBhYmxlDQog dG8gc2VuZCBjb250cm9sICZxdW90O2NvbW1hbmRzJnF1b3Q7IGFzIHdlbGwgYXMgcmVzcG9uZCB0 byByZXF1ZXN0cy4gVGh1cywgUENFUCBpcyBhbiBTQkkgcHJvdG9jb2wgZm9yIHVzZSB3aXRoIHNp Z25hbGluZyBzeXN0ZW1zLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVO LUdCIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+ Tm93LCB3ZSBtaWdodCBtYWtlIHNldmVyYWwgb2JzZXJ2YXRpb25zLi4uPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj5JbiBtYW55IChtb3N0PykgTVBMUy1URSBuZXR3b3Jr cywgZXZlcnkgcm91dGVyIGlzIGNhcGFibGUgb2YgYmVpbmcgdGhlIGhlYWQgZW5kIG9mIExTUHMu IFRoYXQgbWVhbnMgdGhhdCBpbiBhIFBDRS1lbmFibGVkIE1QTFMtVEUgbmV0d29yaywgZXZlcnkg cm91dGVyIGlzIGEgUENFUCBzcGVha2VyLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFu IGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5n PSJFTi1HQiI+QWRkaXRpb25hbGx5LCB3ZSBjYW4gb2JzZXJ2ZSB0aGF0IExTUHMgKG9yIFBXcykg Y2FuIGJlIHN0aXRjaGVkIHRvZ2V0aGVyLiBUaGUgc3RpdGNoaW5nLCBpZiB1bmRlciB0aGUgY29u dHJvbCBvZiBhIFBDRSwgcmVxdWlyZXMgYSBzcGVjaWFsIGluc3RydWN0aW9uIHRvIGJlIHNlbnQg dG8gdGhlIHN0aXRjaGluZyBub2RlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxh bmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJF Ti1HQiI+RnVydGhlcm1vcmUsIHdlIGNhbiB1bmRlcnN0YW5kIHRoYXQgYSBzaW5nbGUgZW5kLXRv LWVuZCBMU1AgaXMgYWN0dWFsbHkgdGhlIHN0aXRjaGluZyBvZiBsb3RzIG9mIHNpbmdsZSBob3Ag TFNQcy4gVGhhdCBpcyByZWFsbHkgd2hhdCBhIHN0YXRpY2FsbHkgcHJvdmlzaW9uZWQgTFNQIGlz Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+RmluYWxseSwgd2UgY2Fu IHNlZSBhIGRlc2lyZSB0byBzZW5kIFRFIGluc3RydWN0aW9ucyBmcm9tIGEgY29tcHV0YXRpb24g ZW5naW5lIChlLmcuLCBQQ0UpIHRvIGluZGl2aWR1YWwgbmV0d29yayBub2RlcyB0byBwcm9ncmFt IHRoZWlyIGZvcndhcmRpbmcuIEZvciBleGFtcGxlLCBpbiBhIFNlZ21lbnQgUm91dGVkIG5ldHdv cmsgb3IgZm9yIHN0YXRpYyBNUExTLVRFIExTUHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+ PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFu IGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5n PSJFTi1HQiI+UHV0IGFsbCBvZiB0aGlzIHRvZ2V0aGVyIHdpdGggdGhlIHJlY29nbml0aW9uIHRo YXQgYWxsIFRFIHBhdGggbWFuYWdlbWVudCBpcyBmdW5kYW1lbnRhbGx5IHRoZSBzYW1lIGFuZCBj YW4gYmUgcGVyZm9ybWVkIGJ5IHRoZSBzYW1lIGVuZ2luZSwgYW5kIHRoYXQgaXQgZG9lcyBub3Qg bWFrZSBzZW5zZSBmb3Igc3VjaCBhbiBlbmdpbmUgdG8gaGF2ZSB0byBpbXBsZW1lbnQgbXVsdGlw bGUgU0JJIHByb3RvY29scywNCiBhbmQgeW91IGVuZCB1cCB3aXRoIHRoaXMgZHJhZnQuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj5JIGRvbid0IHRoaW5rIHdlIGFyZSBz YXlpbmcgdGhhdCB0aGlzIGFwcHJvYWNoIGlzIGNvbXB1bHNvcnksIGJ1dCB3ZSBhcmUgc2F5aW5n IHRoYXQgaXQgaXMgcG9zc2libGUuIE90aGVyIHBvc3NpYmlsaXRpZXMgZXhpc3QgaW5jbHVkaW5n IHVzaW5nIE5FVENPTkYvWUFORyBpbiBwbGFjZSBvZiBQQ0VQLCBhbmQgZW5oYW5jaW5nIEJHUCBp biBwbGFjZSBvZiBQQ0VQLiBPdGhlcnMgaGF2ZSBzdWdnZXN0ZWQgWE1QUC4NCiBGcmFua2x5LCBp ZiB3ZSB3ZXJlIHByb3Bvc2luZyBhIG5ldyBwcm90b2NvbCBpdCB3b3VsZCBiZSBjb3JyZWN0IHRv IHRlbGwgdXMgbm90IHRvLCBhbmQgdG8gcGVyc3VhZGUgdXMgdGhhdCBvbmUgb2YgdGhlIG90aGVy IHByb3RvY29scyB3aWxsIGRvIHRoZSBqb2IuIEJ1dCBoZXJlIHdlIGFyZSB3aXRoIHRocmVlIChv ciBmb3VyKSBwcm90b2NvbHMgdGhhdCBmaXQgdGhlIGJpbGw6IGVhY2ggY3VycmVudGx5IGNvdmVy cyBzb21lIG9mIHRoZSBmdW5jdGlvbg0KIHNwYWNlIGFuZCBlYWNoIGNvdWxkIGVhc2lseSBiZSBl eHRlbmRlZCB0byBjb3ZlciB0aGUgd2hvbGUgc3BhY2UuIEknbSBub3QgY2FwYWJsZSBvZiBzYXlp bmcgaG93IHRvIGRlY2lkZSB3aGljaCBwcm90b2NvbCBkb2VzIHdoaWNoIGZ1bmN0aW9uLCBidXQg SSBkbyBzZWUgcHJlc3N1cmVzIG9mIGltcGxlbWVudGF0aW9uIGFuZCBkZXBsb3ltZW50IHRoYXQg bGVhZCB0byB0aGlzIGRyYWZ0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9 IkVOLUdCIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1H QiI+W0hpc3RvcmljIG5vdGU6IEkgd2FzIHNvbWV3aGF0IG9wcG9zZWQgdG8gYWRkaW5nIFBDRS1J bml0aWF0ZWQgTFNQIHN1cHBvcnQgdG8gUENFUC4gSSB0aG91Z2h0IHRoaXMgYmVudCB0aGUgYXJj aGl0ZWN0dXJlIGZ1cnRoZXIgdGhhbiB3YXMgb3JpZ2luYWxseSBpbnRlbmRlZC4gQnV0IHdlIHdl bnQgdGhlcmUgaW4gdGhlIFBFQyBXRyBhbmQgdGhlIEktRCBpcyBub3cgJnF1b3Q7Y29tcGxldGUm cXVvdDsuIEJ5IGFkZGluZyBzdXBwb3J0DQogb2YgUENFIGluaXRpYXRpb24gb2YgTFNQcywgd2Ug bmF0dXJhbGx5IG9wZW5lZCB0aGUgcGF0aCB0byB0aGlzIGRvY3VtZW50LiBGV0lXLCB0aGlzIGlz IG5vdCB0aGUgZmlyc3QgdGltZSB0aGF0IFBDRVAgaGFzIGJlZW4gZGlzY3Vzc2VkIGFzIGEgbW9y ZSBnZW5lcmFsIFNCSSBwcm90b2NvbCAtIFJGQyA3NDkxIHNob3dzIGl0IGluIHRoaXMgY29udGV4 dCBhbHRob3VnaCBkb2VzIG5vdCBkaXNjdXNzIGl0IG11Y2ggKHdlIHNob3VsZCBwcm9iYWJseQ0K IGFkZCBhIHJlZmVyZW5jZSB0byBBQk5PIGluIHRoaXMgZG9jdW1lbnQpLl08L3NwYW4+PG86cD48 L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwPjxzcGFuIGxhbmc9IkVOLUdCIj5Ob3csIHlvdSBzYXkgeW91IGFyZSBzdXJwcmlzZWQgdGhh dCAmcXVvdDt0aGUgZG9jdW1lbnQgZm9jdXNlcyBvbiB1c2luZyBQQ0VQIGUuZy4gZm9yIEwzVlBO IHNlcnZpY2UgZGVsaXZlcnkuJnF1b3Q7IEkgdGhpbmsgdGhlcmUgaXMgYSBzaWduaWZpY2FudCBk aWZmZXJlbmNlIGJldHdlZW4gKnJlcXVlc3RpbmcqIGEgc2VydmljZSBhbmQgKmRlbGl2ZXJpbmcq IHRoYXQgc2VydmljZS4gVGhlIHNlcnZpY2UgcmVxdWVzdCAoYXMsDQogZm9yIGV4YW1wbGUsIGlu IEwzU00pIGRvZXMgbm90IGludm9sdmUgYSBQQ0UgYW5kIGlzIGVhc2lseSBhY2hpZXZlZCB1c2lu ZyBhIFlBTkcgbW9kZWwgd2hpY2gsIGlmIHRoZSBzZXJ2aWNlIHJlcXVlc3QgaXMgb24tbGluZSwg Y2FuIGJlIGRlbGl2ZXJlZCB1c2luZyBORVRDT05GLiBIb3dldmVyLCBzZXJ2aWNlIGRlbGl2ZXJ5 IHJlcXVpcmVzICZxdW90O29yY2hlc3RyYXRpb24mcXVvdDsuIE9yY2hlc3RyYXRpb24gaXMgdGhl IHByb2Nlc3Mgb2YgY29uc2lkZXJpbmcNCiBhdmFpbGFibGUgbmV0d29yayByZXNvdXJjZXMgYW5k IHNlbGVjdGluZyB3aGF0IHdpbGwgYmUgcHJvdmlzaW9uZWQgdG8gc3VwcG9ydCB0aGUgc2Vydmlj ZS4gQSBQQ0UgaXMgYXQgbGVhc3QgYSBrZXkgZmVhdHVyZSBvZiBvcmNoZXN0cmF0aW9uLCBqdXN0 IGFzIGl0IGlzIGEga2V5IGNvbXBvbmVudCBvZiBhIG5ldHdvcmsgY29udHJvbGxlci4NCjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+QnV0IHRoZSBkb2N1bWVudCBkb2Vz IE5PVCBmb2N1cyBvbiBQQ0VQIGluIHF1aXRlIHRoZSB3YXkgeW91IGRlc2NyaWJlLiBJbiBmYWN0 LCB0aGUgb25seSBkaXNjdXNzaW9uIGlzIGluIDMuMi4zIChqdXN0IHR3byBwYXJhZ3JhcGhzIGlu IHRoZSB3aG9sZSBkb2N1bWVudCkgd2hlcmUgdGhlIGZvY3VzIGlzIG9uIHRoZSB1c2Ugb2YgYSBQ Q0UtYmFzZWQgY2VudHJhbCBjb250cm9sbGVyIHRoYXQgY2FuICZxdW90O2NvbnNpZGVyDQogdGhl IHdob2xlIG5ldHdvcmsgYW5kIGFsbCBjb21wb25lbnRzIG9mIGEgc2VydmljZSBhdCBvbmNlIHdo ZW4gcGxhbm5pbmcgaG93IHRvIGRlbGl2ZXIgdGhlIHNlcnZpY2UuJnF1b3Q7IEl0IHRoZW4gZ29l cyBvbiB0byBvYnNlcnZlIHRoYXQgUENFUCBjYW4gYmUgdXNlZCAmcXVvdDt0byBtYW5hZ2UgdGhl IG5ldHdvcmsgcmVzb3VyY2VzIGFuZCB0byBpbnN0YWxsIHRoZSBuZWNlc3NhcnkgYXNzb2NpYXRp b25zIGJldHdlZW4gdGhvc2UgcmVzb3VyY2VzLiZxdW90Ow0KPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw PjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3Bh biBsYW5nPSJFTi1HQiI+SWYgd2UgaW5jbHVkZWQgYSBtZXNzYWdlIGZsb3cgY2hhcnQgaXQgd291 bGQgbG9vayBzb21ldGhpbmcgbGlrZS4uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFu IGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TZXJ2 aWNlIE1hbmFnZXImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUENFLWJhc2VkIENvbnRy b2xsZXImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTkVzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlcXVlc3Qgc2VydmljZS0tLS0tLS0t LSZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgQ29tcHV0ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBQcm92aXNpb24gLS0tLS0tJmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7LS0tLS0tLS0tLS0tLSBBY2s8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg VXBkYXRlIERCczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLUFjazwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPklmIHRo YXQgc2ltcGxlIGZpZ3VyZSBoZWxwcyB3aXRoIHRoZSB1bmRlcnN0YW5kaW5nIG9mIHRoaXMgb3Ig YW55IG90aGVyIHBhcnQgb2YgdGhlIGRvY3VtZW50LCB3ZSBjYW4gc3VyZWx5IGFkZCBpdC48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cD48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij5DaGVlcnMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QWRyaWFu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IDwvc3Bhbj4tLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4t R0IiPiZndDsgPC9zcGFuPkZyb206IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSkgWzxhIGhy ZWY9Im1haWx0bzptaWNoYWVsLnNjaGFyZkBub2tpYS5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWls dG86bWljaGFlbC5zY2hhcmZAbm9raWEuY29tPC9hPl08bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFu IGxhbmc9IkVOLUdCIj4mZ3Q7IDwvc3Bhbj5TZW50OiAyMCBNYXkgMjAxNiAxOTowNzxvOnA+PC9v OnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgPC9zcGFuPlRvOiA8YSBocmVmPSJt YWlsdG86YWRyaWFuQG9sZGRvZy5jby51ayIgdGFyZ2V0PSJfYmxhbmsiPg0KYWRyaWFuQG9sZGRv Zy5jby51azwvYT47IDxhIGhyZWY9Im1haWx0bzp0ZWFzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+dGVhc0BpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdC Ij4mZ3Q7IDwvc3Bhbj5TdWJqZWN0OiBSRTogW1RlYXNdIEEgTmV3IEktRCBvbiBQQ0UgYXMgYSBj ZW50cmFsIGNvbnRyb2xsZXI8bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4m Z3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IEFz IEkgc2FpZCwgSSBzcGVjaWZpY2FsbHkgd29uZGVyIGFib3V0IFNlY3Rpb24gMy4yLjMgJnF1b3Q7 U2VydmljZSBEZWxpdmVyeSZxdW90Oywgd2hpY2ggc3RhdGVzPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgKG9taXR0aW5nIHNvbWUgcGFydHMgdGhhdCBh cmUgbm90IHJlbGV2YW50IGhlcmUpOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxh bmc9IkVOLUdCIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVO LUdCIj4mZ3Q7ICZxdW90O1ZhcmlvdXMgbmV0d29yayBzZXJ2aWNlcyBtYXkgYmUgb2ZmZXJlZCBv dmVyIGEgbmV0d29yay4gVGhlc2UgaW5jbHVkZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxz cGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IHByb3RlY3Rpb24gc2VydmljZXMgWy4uLl0gVmlydHVhbCBQ cml2YXRlIE5ldHdvcmsgKFZQTikgc2VydmljZSAoc3VjaCBhcyBMYXllciAzPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgVlBOcyBbUkZDNDM2NF0gb3Ig RXRoZXJuZXQgVlBOcyBbUkZDNzQzMl0pLCBvciBQc2V1ZG93aXJlcyBbUkZDMzk4NV0uIFsuLi5d Jm5ic3A7IEE8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0 OyBQQ0UtYmFzZWQgY2VudHJhbCBjb250cm9sIGNhbiBjb25zaWRlciB0aGUgd2hvbGUgbmV0d29y ayBhbmQgYWxsIGNvbXBvbmVudHMgb2Y8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBs YW5nPSJFTi1HQiI+Jmd0OyBhIHNlcnZpY2UgYXQgb25jZSB3aGVuIHBsYW5uaW5nIGhvdyB0byBk ZWxpdmVyIHRoZSBzZXJ2aWNlLiBJdCBjYW4gdGhlbiB1c2UgUENFUDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IHRvIG1hbmFnZSB0aGUgbmV0d29yayBy ZXNvdXJjZXMgYW5kIHRvIGluc3RhbGwgdGhlIG5lY2Vzc2FyeSBhc3NvY2lhdGlvbnM8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyBiZXR3ZWVuIHRob3Nl IHJlc291cmNlcy4mcXVvdDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJF Ti1HQiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+ Jmd0OyBUaGlzIHdvcmRpbmcgb24gdXNlIG9mIFBDRVAgY29uZnVzZXMgbWUsIG5vIG1hdHRlciB3 aGF0IGludGVyZmFjZSB3ZSB0YWxrPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFu Zz0iRU4tR0IiPiZndDsgYWJvdXQuIEkgd291bGQgaGF2ZSBhc3N1bWVkIHRoYXQgWUFORy1iYXNl ZCBwcm90b2NvbHMgc3VjaCBhczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9 IkVOLUdCIj4mZ3Q7IE5FVENPTkYvUkVTVENPTkYgY291bGQgYmUgdXNlZnVsIGluIHRoaXMgY29u dGV4dCwgYW5kIEkgYW0gYSBiaXQgc3VycHJpc2VkIHRoYXQ8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyB0aGUgZG9jdW1lbnQgZm9jdXNlcyBvbiB1c2lu ZyBQQ0VQIGUuZy4gZm9yIEwzVlBOIHNlcnZpY2UgZGVsaXZlcnkuIEJ5IHRoZSB3YXksPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgSSBhbHNvIHdvbmRl ciBob3cgUENFUCBmaXRzIGludG8gdGhlIGRpc2N1c3Npb24gb24gUW9TIGNsYXNzaWZpY2F0aW9u IGluIFNlY3Rpb248L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+ Jmd0OyAzLjIuMi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+ Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyBJ IHdvbmRlciBpZiB0aGUgYXV0aG9ycyBjb3VsZCBhZGQgdG8gU2VjdGlvbiAzLjIuMiBhbmQgU2Vj dGlvbiAzLjIuMyBlLmcuIGE8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJF Ti1HQiI+Jmd0OyBtZXNzYWdlIHNlcXVlbmNlIGNoYXJ0IHRoYXQgaWxsdXN0cmF0ZXMgaG93IHdo YXQgaXMgZGlzY3Vzc2VkIGluIHRob3NlIHNlY3Rpb25zPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgcmVsYXRlcyB0byBQQ0VQPzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IE1pY2hhZWw8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3Bh biBsYW5nPSJFTi1HQiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5n PSJFTi1HQiI+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IEZyb206IFRlYXMgWzxhIGhyZWY9Im1h aWx0bzp0ZWFzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86dGVhcy1i b3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIEVYVCBBZHJpYW4gRmFycmVsPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgU2VudDogRnJpZGF5 LCBNYXkgMTMsIDIwMTYgNjo1NCBQTTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxh bmc9IkVOLUdCIj4mZ3Q7IFRvOiBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUpOyA8YSBocmVm PSJtYWlsdG86dGVhc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdGVhc0BpZXRmLm9yZzwv YT48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyBTdWJq ZWN0OiBSZTogW1RlYXNdIEEgTmV3IEktRCBvbiBQQ0UgYXMgYSBjZW50cmFsIGNvbnRyb2xsZXI8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyA8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyBIZWxsbyBhZ2Fpbiwg TWljaGFlbCwgaXQgc2VlbXMgdG8gYmUgbXkgZGF5IGZvciByZXBseWluZyB0byB5b3VyIGVtYWls cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyA8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyAmZ3Q7IFdoZW4g cmVhZGluZyBhYm91dCB1c2VzIGNhc2VzIHN1Y2ggYXMgTDNWUE4gc2VydmljZSBkZWxpdmVyeSBp bjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7ICZndDsg JnF1b3Q7U2VjdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdC Ij4mZ3Q7IDMuMi4zJnF1b3Q7LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9 IkVOLUdCIj4mZ3Q7ICZndDsgd2hhdCBpcyB0aGUgYXV0aG9yJ3MgdmlldyBvbiB0aGUgbGluZSBv ZiBkZW1hcmNhdGlvbiBiZXR3ZWVuIE5FVENPTkY8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48 c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyAmZ3Q7IGFuZCBQQ0VQPzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw PjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IFdlbGwsIEkgd29uZGVyIHdoaWNoIGludGVyZmFjZSB5 b3UncmUgdGFsa2luZyBhYm91dC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5n PSJFTi1HQiI+Jmd0OyBUaGUgb25lcyB0aGF0IG91dCBpbiBoZXJlIGFyZTo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyAtIHRoZSBpbnRlcmZhY2UgYmV0 d2VlbiBjdXN0b21lciBhbmQgb3BlcmF0b3I8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3Bh biBsYW5nPSJFTi1HQiI+Jmd0OyAtIHRoZSBpbnRlcmZhY2UgYmV0d2VlbiAmcXVvdDtzZXJ2aWNl IG9yY2hlc3RyYXRvciZxdW90OyBhbmQgJnF1b3Q7bmV0d29yayBvcmNoZXN0cmF0b3ImcXVvdDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyA8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyBUaGUgZm9ybWVyIG9m IHRoZXNlIGlzIGxpa2UgdGhlIGludGVyZmFjZSB1c2VkIGluIEwzU00uIEFzIGNvLWNoYWlyIG9m IEwzU00sIHlvdTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4m Z3Q7IG1pZ2h0IG5vdCBiZSBzdXJwcmlzZWQgdG8gaGVhciB0aGF0IG15IHZpZXcgaXMgdGhhdCBO RVRDT05GIGlzIGEgZmluZSBzb2x1dGlvbiAtPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNw YW4gbGFuZz0iRU4tR0IiPiZndDsgd2VsbCwgdGhlIHVzZSBvZiBhIFlBTkcgZGF0YSBtb2RlbCwg aW4gYW55IGNhc2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0Ii PiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsg VGhlIGxhdHRlciBpcyB0aGUgaW50ZXJmYWNlIGJldHdlZW4gJnF1b3Q7T3JjaGVzdHJhdG9yIC8g U2VydmljZSBNYW5hZ2VyIC8gT1NTIC88L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBs YW5nPSJFTi1HQiI+Jmd0OyBOTVMmcXVvdDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3Bh biBsYW5nPSJFTi1HQiI+Jmd0OyBhbmQgJnF1b3Q7UENFLWJhc2VkIENvbnRyb2xsZXImcXVvdDsg YXMgc2hvd24gb24gdGhlIHZhcmlvdXMgZmlndXJlcyBpbiB0aGUgcGljdHVyZS4gV2U8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyBoYXZlbid0IGRpc2N1 c3NlZCB0aGlzIGludGVyZmFjZSBpbiB0aGUgZG9jdW1lbnQsIGFuZCBwZXJoYXBzIHdlIHNob3Vs ZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyA8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyBJZiB5b3UgbG9v ayBhdCBGaWd1cmUgNiAod2l0aCB0aGUgaGllcmFyY2h5IG9mIGNvbnRyb2xsZXJzKSB5b3UgbWln aHQgb2JzZXJ2ZSB0aGF0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4t R0IiPiZndDsgdGhlIHBhcmVudCBjb250cm9sbGVyIGNvdWxkIGJlIGltcGxlbWVudGVkIHRvIGFj dCBhcyB0aG91Z2ggaXQgaXMgdGFsa2luZyB0byBhbiBORTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IChpbiB0aGUgYWJzdHJhY3Qgbm9kZSBtb2RlbCkg YW5kIHRoYXQgbWVhbnMgdGhhdCB0aGUgc291dGhib3VuZCBpbnRlcmZhY2Ugb2Y8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyB0aGUgcGFyZW50IGNvbnRy b2xsZXIgd291bGQgYmUgUENFUC4gVGhhdCBtZWFucyAob2YgY291cnNlKSB0aGF0IHRoZTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IG5vcnRoYm91bmQg aW50ZXJmYWNlIG9mIHRoZSBjaGlsZCBjb250cm9sbGVyIHdvdWxkIGFsc28gYmUgUENFUC4gVGhl biwgaXQgbWlnaHQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+ Jmd0OyBzZWVtIG9idmlvdXMgdGhhdCB3ZSB3b3VsZCB3YW50IGFsbCBQQ0UgaW1wbGVtZW50YXRp b25zIHRvIGJlaGF2ZSB0aGUgc2FtZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxh bmc9IkVOLUdCIj4mZ3Q7IHdheSBhbmQgc28gdGhhdCBtYWtlcyB0aGUgbm9ydGhib3VuZCBpbnRl cmZhY2Ugb2YgdGhlIHBhcmVudCBQQ0U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBs YW5nPSJFTi1HQiI+Jmd0OyB3b3VsZC9jb3VsZC9zaG91bGQvbWlnaHQgYWxzbyBiZSBQQ0VQLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IFdoYXQgZG8geW91IHRo aW5rPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IFRoYW5rcyw8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyBBZHJpYW48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyA8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IFRlYXMgbWFpbGluZyBsaXN0PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgPGEgaHJlZj0ibWFpbHRvOlRl YXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5UZWFzQGlldGYub3JnPC9hPjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IDxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGVhcyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90ZWFzPC9hPjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRv bToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KVGVhcyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86VGVhc0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlRlYXNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90ZWFzIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90ZWFzPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_655C07320163294895BBADA28372AF5D488630EAFR712WXCHMBA15z_-- From nobody Mon May 23 07:25:27 2016 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 2E16512D932 for ; Mon, 23 May 2016 07:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.636 X-Spam-Level: X-Spam-Status: No, score=-5.636 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNXog77S9sca for ; Mon, 23 May 2016 07:25:23 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE67D12D937 for ; Mon, 23 May 2016 07:25:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CPI59014; Mon, 23 May 2016 14:25:19 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 23 May 2016 15:25:07 +0100 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Mon, 23 May 2016 07:25:05 -0700 From: Igor Bryskin To: Dieter Beller , Cyril Margaria , Xufeng Liu Thread-Topic: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo Thread-Index: AdGvdpxN0yo8TMwnRjC4jbLnP05ymwFvMywAAA51YLD//5NrAIAAcWJg Date: Mon, 23 May 2016 14:25:04 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908EDCB69@dfweml501-mbx> References: <02d101d1af76$b0317cd0$10947670$@gmail.com> <0C72C38E7EBC34499E8A9E7DD007863908EDCB0A@dfweml501-mbx> <551bf645-eeb8-a0aa-ff41-26d1043d8d84@nokia.com> In-Reply-To: <551bf645-eeb8-a0aa-ff41-26d1043d8d84@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.253.100] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908EDCB69dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.574312D0.0213, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ab9c02f803473b3c816b6bb401f2f1e5 Archived-At: Cc: TEAS WG Subject: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 14:25:26 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908EDCB69dfweml501mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dieter, Your understanding is correct, and it does not contradict to what Cyril is = saying. For example, a connectivity matrix in the OCh layer must provided o= n a lambda (not link) level. Likewise, as we discussed, in the OTN/ODUk lay= er the connectivity matrix entry should be specific, generally speaking, t= o ODU type. As you see, this has nothing to do with the inter-layer relatio= nships. Cheers, Igor From: Dieter Beller [mailto:Dieter.Beller@nokia.com] Sent: Monday, May 23, 2016 10:06 AM To: Igor Bryskin; Cyril Margaria; Xufeng Liu Cc: TEAS WG Subject: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo Hi Igor, Cyril, all, fixed client to server mappings is s multi-layer aspect if I'm not wrong. I thought that the connectivity matrix was trying to address abstraction dr= awbacks within a single network layer, i.e., to provide additional information that would get lost during the abstraction process (example: sr= lg information associated with the underlying topology that was abstracted into a single node). Thanks, Dieter On 23.05.2016 15:51, Igor Bryskin wrote: Cyril, You are absolutely right. But this belongs to the layer specific augmentati= ons, agreed? On the other hand I do a see a value in adding an abstract label to the con= nectivity matrix (just like a label object in the TE path), so the basic mo= del will be more complete to address more than one layer. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Cyril Margaria Sent: Monday, May 23, 2016 9:41 AM To: Xufeng Liu Cc: TEAS WG Subject: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo Hi, Another item that can be considered is to add a Label (Following RFC7579) r= estrictions. This is needed, for example, in case of Fixed muxponders, whe= re the connectivity between the Low order ODUs to the high-order ODU is fix= ed on each end. Can it be added to the list of changes for the connectivity matrix? Thanks, Cyril On 16 May 2016 at 09:27, Xufeng Liu > wrote: Authors and contributors have discussed the use case of abstract topology, to address the incompleteness of connectivity matrix. Current connectivity modeling is as follows: | +--rw connectivity-matrix* [id] | | +--rw id uint32 | | +--rw from | | | +--rw tp-ref? leafref | | +--rw to | | | +--rw tp-ref? leafref | | +--rw is-allowed? Boolean A Link TP may connect or disconnect to another Link TP, without detailed information such as cost and resource sharing restriction. To get a better abstraction of such connectivity, the following additional attributes are planned to be added: max-bandwidth? decimal64 max-resv-bandwidth? decimal64 unreserved-bandwidth* [priority] priority uint8 +-- bandwidth? decimal64 +-- te-default-metric uint32 performance-metric // re-use the container from te-link-atrributes te-srlgs // re-use the container from te-link-atrributes Comments are welcome. Thanks, - Xufeng _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas --_000_0C72C38E7EBC34499E8A9E7DD007863908EDCB69dfweml501mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dieter,

 

Your understanding is correct, and it does not = contradict to what Cyril is saying. For example, a connectivity matrix in t= he OCh layer must provided on a lambda (not link) level. Likewise, as we discussed, in the OTN/ODUk layer the connectivity matrix e= ntry should be specific, generally speaking,  to ODU type. As you see,= this has nothing to do with the inter-layer relationships.

 

Cheers,

Igor

 

From: Dieter Beller [mailto:Dieter.Beller@nokia.com]
Sent: Monday, May 23, 2016 10:06 AM
To: Igor Bryskin; Cyril Margaria; Xufeng Liu
Cc: TEAS WG
Subject: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-t= opo

 

Hi Igor, Cyril, all,

fixed client to serve= r mappings is s multi-layer aspect if I'm not wrong.

I thought that the connectivity matrix was trying to address abstraction dr= awbacks within a single network layer, i.e., to provide additional
information that would get lost during the abstraction process (example: sr= lg information associated with the underlying topology that was
abstracted into a single node).


Thanks,
Dieter

On 23.05.2016 15:51, Igor Bryskin wrote:<= /p>

Cyril,

 

You are absolutely right. But this belongs to t= he layer specific augmentations, agreed?

 

On the other hand I do a see a value in adding = an abstract label to the connectivity matrix (just like a label object in t= he TE path), so the basic model will be more complete to address more than one layer.

 

Igor

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Cyril Margaria
Sent: Monday, May 23, 2016 9:41 AM
To: Xufeng Liu
Cc: TEAS WG
Subject: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-t= opo

 

Hi,

Another item that can= be considered is to add a Label (Following RFC7579) restrictions. This is = needed, for example,  in case of Fixed muxponders, where the connectiv= ity between the Low order ODUs to the high-order ODU is fixed on each end.

Can it be added to the list of changes for the conne= ctivity matrix?

 

Thanks,

Cyril

 

On 16 May 2016 at 09:27, Xufeng Liu <xufeng.liu.ietf@gmail.co= m> wrote:

Authors and contributors have discussed the use case= of abstract topology,
to address the incompleteness of connectivity matrix.

Current connectivity modeling is as follows:

      |     +--rw connectivity-matrix* [i= d]
      |     |  +--rw id   =         uint32
      |     |  +--rw from
      |     |  |  +--rw tp-ref?=    leafref
      |     |  +--rw to
      |     |  |  +--rw tp-ref?=    leafref
      |     |  +--rw is-allowed?&nbs= p;  Boolean

A Link TP may connect or disconnect to another Link TP, without detailed information such as cost and resource sharing restriction. To get a better<= br> abstraction of such connectivity, the following additional attributes are planned to be added:

  max-bandwidth?               = ;decimal64
  max-resv-bandwidth?          decimal64
  unreserved-bandwidth* [priority]
  priority     uint8
     +-- bandwidth?   decimal64
     +-- te-default-metric uint32
  performance-metric // re-use the container from te-link-atrributes   te-srlgs           // re-use the conta= iner from te-link-atrributes

Comments are welcome.

Thanks,

- Xufeng


_______________________________________________
Teas mailing list
Teas@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/teas

 




_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.iet=
f.org/mailman/listinfo/teas
--_000_0C72C38E7EBC34499E8A9E7DD007863908EDCB69dfweml501mbx_-- From nobody Mon May 23 07:44:15 2016 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 B456A1200A0 for ; Mon, 23 May 2016 07:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.187 X-Spam-Level: X-Spam-Status: No, score=-6.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 BnMsbB9XGDgF for ; Mon, 23 May 2016 07:44:12 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D7C112B064 for ; Mon, 23 May 2016 07:44:11 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 84FEFE0FCBF2E; Mon, 23 May 2016 14:44:06 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4NEi7HD026448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 May 2016 14:44:09 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u4NEhxpp016466 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 May 2016 16:44:03 +0200 Received: from [149.204.106.226] (135.239.27.41) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 23 May 2016 16:43:45 +0200 To: Igor Bryskin , Cyril Margaria , Xufeng Liu References: <02d101d1af76$b0317cd0$10947670$@gmail.com> <0C72C38E7EBC34499E8A9E7DD007863908EDCB0A@dfweml501-mbx> <551bf645-eeb8-a0aa-ff41-26d1043d8d84@nokia.com> <0C72C38E7EBC34499E8A9E7DD007863908EDCB69@dfweml501-mbx> From: Dieter Beller Organization: Nokia Message-ID: <77293aff-c53d-3043-7d24-b9c95f2ac776@nokia.com> Date: Mon, 23 May 2016 16:43:44 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908EDCB69@dfweml501-mbx> Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.41] Archived-At: Cc: TEAS WG Subject: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 14:44:14 -0000 Hi Igor,

I am confused - maybe something we can clarify during our TEAS call today that will start in 15min.


Thanks,
Dieter

On 23.05.2016 16:25, Igor Bryskin wrote:

Dieter,

 

Your understanding is correct, and it does not contradict to what Cyril is saying. For example, a connectivity matrix in the OCh layer must provided on a lambda (not link) level. Likewise, as we discussed, in the OTN/ODUk layer the connectivity matrix entry should be specific, generally speaking,  to ODU type. As you see, this has nothing to do with the inter-layer relationships.

 

Cheers,

Igor

 

From: Dieter Beller [mailto:Dieter.Beller@nokia.com]
Sent: Monday, May 23, 2016 10:06 AM
To: Igor Bryskin; Cyril Margaria; Xufeng Liu
Cc: TEAS WG
Subject: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo

 

Hi Igor, Cyril, all,

fixed client to server mappings is s multi-layer aspect if I'm not wrong.

I thought that the connectivity matrix was trying to address abstraction drawbacks within a single network layer, i.e., to provide additional
information that would get lost during the abstraction process (example: srlg information associated with the underlying topology that was
abstracted into a single node).


Thanks,
Dieter

On 23.05.2016 15:51, Igor Bryskin wrote:

Cyril,

 

You are absolutely right. But this belongs to the layer specific augmentations, agreed?

 

On the other hand I do a see a value in adding an abstract label to the connectivity matrix (just like a label object in the TE path), so the basic model will be more complete to address more than one layer.

 

Igor

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Cyril Margaria
Sent: Monday, May 23, 2016 9:41 AM
To: Xufeng Liu
Cc: TEAS WG
Subject: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo

 

Hi,

Another item that can be considered is to add a Label (Following RFC7579) restrictions. This is needed, for example,  in case of Fixed muxponders, where the connectivity between the Low order ODUs to the high-order ODU is fixed on each end.

Can it be added to the list of changes for the connectivity matrix?

 

Thanks,

Cyril

 

On 16 May 2016 at 09:27, Xufeng Liu <xufeng.liu.ietf@gmail.com> wrote:

Authors and contributors have discussed the use case of abstract topology,
to address the incompleteness of connectivity matrix.

Current connectivity modeling is as follows:

      |     +--rw connectivity-matrix* [id]
      |     |  +--rw id            uint32
      |     |  +--rw from
      |     |  |  +--rw tp-ref?   leafref
      |     |  +--rw to
      |     |  |  +--rw tp-ref?   leafref
      |     |  +--rw is-allowed?   Boolean

A Link TP may connect or disconnect to another Link TP, without detailed
information such as cost and resource sharing restriction. To get a better
abstraction of such connectivity, the following additional attributes are
planned to be added:

  max-bandwidth?               decimal64
  max-resv-bandwidth?          decimal64
  unreserved-bandwidth* [priority]
  priority     uint8
     +-- bandwidth?   decimal64
     +-- te-default-metric uint32
  performance-metric // re-use the container from te-link-atrributes
  te-srlgs           // re-use the container from te-link-atrributes

Comments are welcome.

Thanks,

- Xufeng


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

 




_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas
From nobody Mon May 23 07:48:24 2016 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 3461E12D0AC for ; Mon, 23 May 2016 07:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9q8XgCVsz3u for ; Mon, 23 May 2016 07:48:21 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07D9012B043 for ; Mon, 23 May 2016 07:48:20 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 3106D2EC22077; Mon, 23 May 2016 14:48:16 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4NEmJNp017989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 May 2016 14:48:19 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u4NEm4ek025208 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 May 2016 16:48:15 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.203]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 23 May 2016 16:47:46 +0200 From: "Belotti, Sergio (Nokia - IT)" To: Igor Bryskin , "Beller, Dieter (Nokia - DE)" , Cyril Margaria , Xufeng Liu Thread-Topic: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo Thread-Index: AdGvdpxN0yo8TMwnRjC4jbLnP05ymwFcVzIAAABhm4AAAIExAAAAp30AAATYshA= Date: Mon, 23 May 2016 14:47:46 +0000 Message-ID: References: <02d101d1af76$b0317cd0$10947670$@gmail.com> <0C72C38E7EBC34499E8A9E7DD007863908EDCB0A@dfweml501-mbx> <551bf645-eeb8-a0aa-ff41-26d1043d8d84@nokia.com> <0C72C38E7EBC34499E8A9E7DD007863908EDCB69@dfweml501-mbx> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908EDCB69@dfweml501-mbx> Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_B9FEE68CE3A78C41A2B3C67549A96F48B76B2342FR711WXCHMBA05z_" MIME-Version: 1.0 Archived-At: Cc: TEAS WG Subject: [Teas] R: Connectivity matrix in draft-ietf-teas-yang-te-topo X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 14:48:23 -0000 --_000_B9FEE68CE3A78C41A2B3C67549A96F48B76B2342FR711WXCHMBA05z_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Igor, I'm a little confused : connectivity matrix is a concept introduced in the = WSON context afaik, I do not understand the relationship at OTN/ODUk where= we suppose to have no blocking matrix . Probably need to clarify the picture in the coming call. Cheers Sergio Sergio Belotti Da: Teas [mailto:teas-bounces@ietf.org] Per conto di Igor Bryskin Inviato: luned=EC 23 maggio 2016 16:25 A: Beller, Dieter (Nokia - DE); Cyril Margaria; Xufeng Liu Cc: TEAS WG Oggetto: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo Dieter, Your understanding is correct, and it does not contradict to what Cyril is = saying. For example, a connectivity matrix in the OCh layer must provided o= n a lambda (not link) level. Likewise, as we discussed, in the OTN/ODUk lay= er the connectivity matrix entry should be specific, generally speaking, t= o ODU type. As you see, this has nothing to do with the inter-layer relatio= nships. Cheers, Igor From: Dieter Beller [mailto:Dieter.Beller@nokia.com] Sent: Monday, May 23, 2016 10:06 AM To: Igor Bryskin; Cyril Margaria; Xufeng Liu Cc: TEAS WG Subject: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo Hi Igor, Cyril, all, fixed client to server mappings is s multi-layer aspect if I'm not wrong. I thought that the connectivity matrix was trying to address abstraction dr= awbacks within a single network layer, i.e., to provide additional information that would get lost during the abstraction process (example: sr= lg information associated with the underlying topology that was abstracted into a single node). Thanks, Dieter On 23.05.2016 15:51, Igor Bryskin wrote: Cyril, You are absolutely right. But this belongs to the layer specific augmentati= ons, agreed? On the other hand I do a see a value in adding an abstract label to the con= nectivity matrix (just like a label object in the TE path), so the basic mo= del will be more complete to address more than one layer. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Cyril Margaria Sent: Monday, May 23, 2016 9:41 AM To: Xufeng Liu Cc: TEAS WG Subject: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo Hi, Another item that can be considered is to add a Label (Following RFC7579) r= estrictions. This is needed, for example, in case of Fixed muxponders, whe= re the connectivity between the Low order ODUs to the high-order ODU is fix= ed on each end. Can it be added to the list of changes for the connectivity matrix? Thanks, Cyril On 16 May 2016 at 09:27, Xufeng Liu > wrote: Authors and contributors have discussed the use case of abstract topology, to address the incompleteness of connectivity matrix. Current connectivity modeling is as follows: | +--rw connectivity-matrix* [id] | | +--rw id uint32 | | +--rw from | | | +--rw tp-ref? leafref | | +--rw to | | | +--rw tp-ref? leafref | | +--rw is-allowed? Boolean A Link TP may connect or disconnect to another Link TP, without detailed information such as cost and resource sharing restriction. To get a better abstraction of such connectivity, the following additional attributes are planned to be added: max-bandwidth? decimal64 max-resv-bandwidth? decimal64 unreserved-bandwidth* [priority] priority uint8 +-- bandwidth? decimal64 +-- te-default-metric uint32 performance-metric // re-use the container from te-link-atrributes te-srlgs // re-use the container from te-link-atrributes Comments are welcome. Thanks, - Xufeng _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas --_000_B9FEE68CE3A78C41A2B3C67549A96F48B76B2342FR711WXCHMBA05z_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Igor,

I’m a little confus= ed : connectivity matrix is a concept introduced in the WSON context afaik,= I do not understand  the relationship at OTN/ODUk where we suppose to have no blocking matrix .

Probably need to clarify = the picture in the coming call.

 <= /p>

Cheers<= /p>

Sergio<= /p>

 <= /p>

Sergio Belotti=

 <= /p>

Da: Teas [mailto:teas-bounc= es@ietf.org] Per conto di Igor Bryskin
Inviato: luned=EC 23 maggio 2016 16:25
A: Beller, Dieter (Nokia - DE); Cyril Margaria; Xufeng Liu
Cc: TEAS WG
Oggetto: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-t= opo

 

Dieter,

 

Your understanding is correct, and it does not = contradict to what Cyril is saying. For example, a connectivity matrix in t= he OCh layer must provided on a lambda (not link) level. Likewise, as we discussed, in the OTN/ODUk layer the connectivity matrix e= ntry should be specific, generally speaking,  to ODU type. As you see,= this has nothing to do with the inter-layer relationships.

 

Cheers,

Igor

 

From: Dieter Beller [mailto:Dieter.Beller@nokia.com]
Sent: Monday, May 23, 2016 10:06 AM
To: Igor Bryskin; Cyril Margaria; Xufeng Liu
Cc: TEAS WG
Subject: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-t= opo

 

Hi Igor, Cyril, all,

fixed client to serve= r mappings is s multi-layer aspect if I'm not wrong.

I thought that the connectivity matrix was trying to address abstraction dr= awbacks within a single network layer, i.e., to provide additional
information that would get lost during the abstraction process (example: sr= lg information associated with the underlying topology that was
abstracted into a single node).


Thanks,
Dieter

On 23.05.2016 15:51, Igor Bryskin wrote:<= /p>

Cyril,

 

You are absolutely right. But this belongs to t= he layer specific augmentations, agreed?

 

On the other hand I do a see a value in adding = an abstract label to the connectivity matrix (just like a label object in t= he TE path), so the basic model will be more complete to address more than one layer.

 

Igor

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Cyril Margaria
Sent: Monday, May 23, 2016 9:41 AM
To: Xufeng Liu
Cc: TEAS WG
Subject: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-t= opo

 

Hi,

Another item that can= be considered is to add a Label (Following RFC7579) restrictions. This is = needed, for example,  in case of Fixed muxponders, where the connectiv= ity between the Low order ODUs to the high-order ODU is fixed on each end.

Can it be added to the list of changes for the conne= ctivity matrix?

 

Thanks,

Cyril

 

On 16 May 2016 at 09:27, Xufeng Liu <xufeng.liu.ietf@gmail.co= m> wrote:

Authors and contributors have discussed the use case= of abstract topology,
to address the incompleteness of connectivity matrix.

Current connectivity modeling is as follows:

      |     +--rw connectivity-matrix* [i= d]
      |     |  +--rw id   =         uint32
      |     |  +--rw from
      |     |  |  +--rw tp-ref?=    leafref
      |     |  +--rw to
      |     |  |  +--rw tp-ref?=    leafref
      |     |  +--rw is-allowed?&nbs= p;  Boolean

A Link TP may connect or disconnect to another Link TP, without detailed information such as cost and resource sharing restriction. To get a better<= br> abstraction of such connectivity, the following additional attributes are planned to be added:

  max-bandwidth?               = ;decimal64
  max-resv-bandwidth?          decimal64
  unreserved-bandwidth* [priority]
  priority     uint8
     +-- bandwidth?   decimal64
     +-- te-default-metric uint32
  performance-metric // re-use the container from te-link-atrributes   te-srlgs           // re-use the conta= iner from te-link-atrributes

Comments are welcome.

Thanks,

- Xufeng


_______________________________________________
Teas mailing list
Teas@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/teas

 



_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.iet=
f.org/mailman/listinfo/teas
--_000_B9FEE68CE3A78C41A2B3C67549A96F48B76B2342FR711WXCHMBA05z_-- From nobody Mon May 23 07:50:40 2016 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 A8C6F12B01F for ; Mon, 23 May 2016 07:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.636 X-Spam-Level: X-Spam-Status: No, score=-5.636 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpJIf3jrihvo for ; Mon, 23 May 2016 07:50:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3813C12B01A for ; Mon, 23 May 2016 07:50:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CKM69115; Mon, 23 May 2016 14:50:33 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 23 May 2016 15:50:23 +0100 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Mon, 23 May 2016 07:50:20 -0700 From: Igor Bryskin To: Dieter Beller , Cyril Margaria , Xufeng Liu Thread-Topic: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo Thread-Index: AdGvdpxN0yo8TMwnRjC4jbLnP05ymwFvMywAAA51YLD//5NrAIAAcWJg//+ZEQCAAHOioA== Date: Mon, 23 May 2016 14:50:19 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908EDCBB0@dfweml501-mbx> References: <02d101d1af76$b0317cd0$10947670$@gmail.com> <0C72C38E7EBC34499E8A9E7DD007863908EDCB0A@dfweml501-mbx> <551bf645-eeb8-a0aa-ff41-26d1043d8d84@nokia.com> <0C72C38E7EBC34499E8A9E7DD007863908EDCB69@dfweml501-mbx> <77293aff-c53d-3043-7d24-b9c95f2ac776@nokia.com> In-Reply-To: <77293aff-c53d-3043-7d24-b9c95f2ac776@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.253.100] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908EDCBB0dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.574318BA.0158, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b70b7e22ca3779c68bd0ecca126a4eac Archived-At: Cc: TEAS WG Subject: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 14:50:39 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908EDCBB0dfweml501mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sure, we can do this. Igor From: Dieter Beller [mailto:Dieter.Beller@nokia.com] Sent: Monday, May 23, 2016 10:44 AM To: Igor Bryskin; Cyril Margaria; Xufeng Liu Cc: TEAS WG Subject: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo Hi Igor, I am confused - maybe something we can clarify during our TEAS call today t= hat will start in 15min. Thanks, Dieter On 23.05.2016 16:25, Igor Bryskin wrote: Dieter, Your understanding is correct, and it does not contradict to what Cyril is = saying. For example, a connectivity matrix in the OCh layer must provided o= n a lambda (not link) level. Likewise, as we discussed, in the OTN/ODUk lay= er the connectivity matrix entry should be specific, generally speaking, t= o ODU type. As you see, this has nothing to do with the inter-layer relatio= nships. Cheers, Igor From: Dieter Beller [mailto:Dieter.Beller@nokia.com] Sent: Monday, May 23, 2016 10:06 AM To: Igor Bryskin; Cyril Margaria; Xufeng Liu Cc: TEAS WG Subject: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo Hi Igor, Cyril, all, fixed client to server mappings is s multi-layer aspect if I'm not wrong. I thought that the connectivity matrix was trying to address abstraction dr= awbacks within a single network layer, i.e., to provide additional information that would get lost during the abstraction process (example: sr= lg information associated with the underlying topology that was abstracted into a single node). Thanks, Dieter On 23.05.2016 15:51, Igor Bryskin wrote: Cyril, You are absolutely right. But this belongs to the layer specific augmentati= ons, agreed? On the other hand I do a see a value in adding an abstract label to the con= nectivity matrix (just like a label object in the TE path), so the basic mo= del will be more complete to address more than one layer. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Cyril Margaria Sent: Monday, May 23, 2016 9:41 AM To: Xufeng Liu Cc: TEAS WG Subject: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo Hi, Another item that can be considered is to add a Label (Following RFC7579) r= estrictions. This is needed, for example, in case of Fixed muxponders, whe= re the connectivity between the Low order ODUs to the high-order ODU is fix= ed on each end. Can it be added to the list of changes for the connectivity matrix? Thanks, Cyril On 16 May 2016 at 09:27, Xufeng Liu > wrote: Authors and contributors have discussed the use case of abstract topology, to address the incompleteness of connectivity matrix. Current connectivity modeling is as follows: | +--rw connectivity-matrix* [id] | | +--rw id uint32 | | +--rw from | | | +--rw tp-ref? leafref | | +--rw to | | | +--rw tp-ref? leafref | | +--rw is-allowed? Boolean A Link TP may connect or disconnect to another Link TP, without detailed information such as cost and resource sharing restriction. To get a better abstraction of such connectivity, the following additional attributes are planned to be added: max-bandwidth? decimal64 max-resv-bandwidth? decimal64 unreserved-bandwidth* [priority] priority uint8 +-- bandwidth? decimal64 +-- te-default-metric uint32 performance-metric // re-use the container from te-link-atrributes te-srlgs // re-use the container from te-link-atrributes Comments are welcome. Thanks, - Xufeng _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas --_000_0C72C38E7EBC34499E8A9E7DD007863908EDCBB0dfweml501mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sure, we can do this.

 

Igor

 

From: Dieter Beller [mailto:Dieter.Beller@nokia.com]
Sent: Monday, May 23, 2016 10:44 AM
To: Igor Bryskin; Cyril Margaria; Xufeng Liu
Cc: TEAS WG
Subject: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-t= opo

 

Hi Igor,

I am confused - maybe something we can clarify during our TEAS call today t= hat will start in 15min.


Thanks,
Dieter

On 23.05.2016 16:25, Igor Bryskin wrote:<= /p>

Dieter,

 

Your understanding is correct, and it does not = contradict to what Cyril is saying. For example, a connectivity matrix in t= he OCh layer must provided on a lambda (not link) level. Likewise, as we discussed, in the OTN/ODUk layer the connectivity matrix e= ntry should be specific, generally speaking,  to ODU type. As you see,= this has nothing to do with the inter-layer relationships.

 

Cheers,

Igor

 

From: Dieter Beller [mailto:Dieter.Beller@nokia.com]
Sent: Monday, May 23, 2016 10:06 AM
To: Igor Bryskin; Cyril Margaria; Xufeng Liu
Cc: TEAS WG
Subject: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-t= opo

 

Hi Igor, Cyril, all,

fixed client to serve= r mappings is s multi-layer aspect if I'm not wrong.

I thought that the connectivity matrix was trying to address abstraction dr= awbacks within a single network layer, i.e., to provide additional
information that would get lost during the abstraction process (example: sr= lg information associated with the underlying topology that was
abstracted into a single node).


Thanks,
Dieter

On 23.05.2016 15:51, Igor Bryskin wrote:<= /p>

Cyril,

 

You are absolutely right. But this belongs to t= he layer specific augmentations, agreed?

 

On the other hand I do a see a value in adding = an abstract label to the connectivity matrix (just like a label object in t= he TE path), so the basic model will be more complete to address more than one layer.

 

Igor

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Cyril Margaria
Sent: Monday, May 23, 2016 9:41 AM
To: Xufeng Liu
Cc: TEAS WG
Subject: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-t= opo

 

Hi,

Another item that can= be considered is to add a Label (Following RFC7579) restrictions. This is = needed, for example,  in case of Fixed muxponders, where the connectiv= ity between the Low order ODUs to the high-order ODU is fixed on each end.

Can it be added to the list of changes for the conne= ctivity matrix?

 

Thanks,

Cyril

 

On 16 May 2016 at 09:27, Xufeng Liu <xufeng.liu.ietf@gmail.co= m> wrote:

Authors and contributors have discussed the use case= of abstract topology,
to address the incompleteness of connectivity matrix.

Current connectivity modeling is as follows:

      |     +--rw connectivity-matrix* [i= d]
      |     |  +--rw id   =         uint32
      |     |  +--rw from
      |     |  |  +--rw tp-ref?=    leafref
      |     |  +--rw to
      |     |  |  +--rw tp-ref?=    leafref
      |     |  +--rw is-allowed?&nbs= p;  Boolean

A Link TP may connect or disconnect to another Link TP, without detailed information such as cost and resource sharing restriction. To get a better<= br> abstraction of such connectivity, the following additional attributes are planned to be added:

  max-bandwidth?               = ;decimal64
  max-resv-bandwidth?          decimal64
  unreserved-bandwidth* [priority]
  priority     uint8
     +-- bandwidth?   decimal64
     +-- te-default-metric uint32
  performance-metric // re-use the container from te-link-atrributes   te-srlgs           // re-use the conta= iner from te-link-atrributes

Comments are welcome.

Thanks,

- Xufeng


_______________________________________________
Teas mailing list
Teas@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/teas

 





_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.iet=
f.org/mailman/listinfo/teas
--_000_0C72C38E7EBC34499E8A9E7DD007863908EDCBB0dfweml501mbx_-- From nobody Mon May 23 07:59:45 2016 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 64DA012B01A for ; Mon, 23 May 2016 07:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.636 X-Spam-Level: X-Spam-Status: No, score=-5.636 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7v1UiBlcggZ for ; Mon, 23 May 2016 07:59:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C64B812D91A for ; Mon, 23 May 2016 07:59:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CKM70602; Mon, 23 May 2016 14:59:38 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 23 May 2016 15:59:38 +0100 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Mon, 23 May 2016 07:59:36 -0700 From: Igor Bryskin To: "Belotti, Sergio (Nokia - IT)" , "Beller, Dieter (Nokia - DE)" , Cyril Margaria , Xufeng Liu Thread-Topic: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo Thread-Index: AdGvdpxN0yo8TMwnRjC4jbLnP05ymwFvMywAAA51YLD//5NrAIAAcWJg//+aMQCAAHRw0A== Date: Mon, 23 May 2016 14:59:35 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908EDCBCB@dfweml501-mbx> References: <02d101d1af76$b0317cd0$10947670$@gmail.com> <0C72C38E7EBC34499E8A9E7DD007863908EDCB0A@dfweml501-mbx> <551bf645-eeb8-a0aa-ff41-26d1043d8d84@nokia.com> <0C72C38E7EBC34499E8A9E7DD007863908EDCB69@dfweml501-mbx> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.253.100] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908EDCBCBdfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.57431ADB.0145, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b70b7e22ca3779c68bd0ecca126a4eac Archived-At: Cc: TEAS WG Subject: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 14:59:44 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908EDCBCBdfweml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sergio, Connectivity matrix is relevant to all layers , not just OCh. I am aware of= ODU physical switches which are severely constrained because, to lower the= cost, they are implemented as cascades of ADMs. Furthermore, this is much more pronounced/obvious when you consider, say, O= TN/ODUk domains, presented as TE nodes. In this case, there is no guarantee= that, say, ODU2 TE path arriving at such a node over one of the inter-doma= in TE links can exit the node from any other of its inter-domain links (bec= ause the necessary intra-node TE path may not be feasible). To describe suc= h limitations we need a connectivity matrix to decorate the abstract TE nod= es. Igor From: Belotti, Sergio (Nokia - IT) [mailto:sergio.belotti@nokia.com] Sent: Monday, May 23, 2016 10:48 AM To: Igor Bryskin; Beller, Dieter (Nokia - DE); Cyril Margaria; Xufeng Liu Cc: TEAS WG Subject: R: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo Hi Igor, I'm a little confused : connectivity matrix is a concept introduced in the = WSON context afaik, I do not understand the relationship at OTN/ODUk where= we suppose to have no blocking matrix . Probably need to clarify the picture in the coming call. Cheers Sergio Sergio Belotti Da: Teas [mailto:teas-bounces@ietf.org] Per conto di Igor Bryskin Inviato: luned=EC 23 maggio 2016 16:25 A: Beller, Dieter (Nokia - DE); Cyril Margaria; Xufeng Liu Cc: TEAS WG Oggetto: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo Dieter, Your understanding is correct, and it does not contradict to what Cyril is = saying. For example, a connectivity matrix in the OCh layer must provided o= n a lambda (not link) level. Likewise, as we discussed, in the OTN/ODUk lay= er the connectivity matrix entry should be specific, generally speaking, t= o ODU type. As you see, this has nothing to do with the inter-layer relatio= nships. Cheers, Igor From: Dieter Beller [mailto:Dieter.Beller@nokia.com] Sent: Monday, May 23, 2016 10:06 AM To: Igor Bryskin; Cyril Margaria; Xufeng Liu Cc: TEAS WG Subject: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo Hi Igor, Cyril, all, fixed client to server mappings is s multi-layer aspect if I'm not wrong. I thought that the connectivity matrix was trying to address abstraction dr= awbacks within a single network layer, i.e., to provide additional information that would get lost during the abstraction process (example: sr= lg information associated with the underlying topology that was abstracted into a single node). Thanks, Dieter On 23.05.2016 15:51, Igor Bryskin wrote: Cyril, You are absolutely right. But this belongs to the layer specific augmentati= ons, agreed? On the other hand I do a see a value in adding an abstract label to the con= nectivity matrix (just like a label object in the TE path), so the basic mo= del will be more complete to address more than one layer. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Cyril Margaria Sent: Monday, May 23, 2016 9:41 AM To: Xufeng Liu Cc: TEAS WG Subject: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo Hi, Another item that can be considered is to add a Label (Following RFC7579) r= estrictions. This is needed, for example, in case of Fixed muxponders, whe= re the connectivity between the Low order ODUs to the high-order ODU is fix= ed on each end. Can it be added to the list of changes for the connectivity matrix? Thanks, Cyril On 16 May 2016 at 09:27, Xufeng Liu > wrote: Authors and contributors have discussed the use case of abstract topology, to address the incompleteness of connectivity matrix. Current connectivity modeling is as follows: | +--rw connectivity-matrix* [id] | | +--rw id uint32 | | +--rw from | | | +--rw tp-ref? leafref | | +--rw to | | | +--rw tp-ref? leafref | | +--rw is-allowed? Boolean A Link TP may connect or disconnect to another Link TP, without detailed information such as cost and resource sharing restriction. To get a better abstraction of such connectivity, the following additional attributes are planned to be added: max-bandwidth? decimal64 max-resv-bandwidth? decimal64 unreserved-bandwidth* [priority] priority uint8 +-- bandwidth? decimal64 +-- te-default-metric uint32 performance-metric // re-use the container from te-link-atrributes te-srlgs // re-use the container from te-link-atrributes Comments are welcome. Thanks, - Xufeng _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas --_000_0C72C38E7EBC34499E8A9E7DD007863908EDCBCBdfweml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Sergio,

 

Connectivity matrix is relevant to all layers ,= not just OCh. I am aware of ODU physical switches which are severely const= rained because, to lower the cost, they are implemented as cascades of ADMs.

Furthermore, this is much more pronounced/obvio= us when you consider, say, OTN/ODUk domains, presented as TE nodes. In this= case, there is no guarantee that, say, ODU2 TE path arriving at such a node over one of the inter-domain TE links can exit the node fro= m any other of its inter-domain links (because the necessary intra-node TE = path may not be feasible). To describe such limitations we need a connectiv= ity matrix to decorate the abstract TE nodes.

 

Igor

 

From: Belotti, Sergio (Nokia - IT) [mailto:sergio.belot= ti@nokia.com]
Sent: Monday, May 23, 2016 10:48 AM
To: Igor Bryskin; Beller, Dieter (Nokia - DE); Cyril Margaria; Xufen= g Liu
Cc: TEAS WG
Subject: R: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-to= po

 

Hi Igor,

I’m a little confus= ed : connectivity matrix is a concept introduced in the WSON context afaik,= I do not understand  the relationship at OTN/ODUk where we suppose to have no blocking matrix .

Probably need to clarify = the picture in the coming call.

 <= /p>

Cheers<= /p>

Sergio<= /p>

 <= /p>

Sergio Belotti=

 <= /p>

Da: Teas [mailto:teas-bounc= es@ietf.org] Per conto di Igor Bryskin
Inviato: luned=EC 23 maggio 2016 16:25
A: Beller, Dieter (Nokia - DE); Cyril Margaria; Xufeng Liu
Cc: TEAS WG
Oggetto: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-t= opo

 

Dieter,

 

Your understanding is correct, and it does not = contradict to what Cyril is saying. For example, a connectivity matrix in t= he OCh layer must provided on a lambda (not link) level. Likewise, as we discussed, in the OTN/ODUk layer the connectivity matrix e= ntry should be specific, generally speaking,  to ODU type. As you see,= this has nothing to do with the inter-layer relationships.

 

Cheers,

Igor

 

From: Dieter Beller [mailto:Dieter.Beller@nokia.com]
Sent: Monday, May 23, 2016 10:06 AM
To: Igor Bryskin; Cyril Margaria; Xufeng Liu
Cc: TEAS WG
Subject: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-t= opo

 

Hi Igor, Cyril, all,

fixed client to serve= r mappings is s multi-layer aspect if I'm not wrong.

I thought that the connectivity matrix was trying to address abstraction dr= awbacks within a single network layer, i.e., to provide additional
information that would get lost during the abstraction process (example: sr= lg information associated with the underlying topology that was
abstracted into a single node).


Thanks,
Dieter

On 23.05.2016 15:51, Igor Bryskin wrote:<= /p>

Cyril,

 

You are absolutely right. But this belongs to t= he layer specific augmentations, agreed?

 

On the other hand I do a see a value in adding = an abstract label to the connectivity matrix (just like a label object in t= he TE path), so the basic model will be more complete to address more than one layer.

 

Igor

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Cyril Margaria
Sent: Monday, May 23, 2016 9:41 AM
To: Xufeng Liu
Cc: TEAS WG
Subject: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-t= opo

 

Hi,

Another item that can= be considered is to add a Label (Following RFC7579) restrictions. This is = needed, for example,  in case of Fixed muxponders, where the connectiv= ity between the Low order ODUs to the high-order ODU is fixed on each end.

Can it be added to the list of changes for the conne= ctivity matrix?

 

Thanks,

Cyril

 

On 16 May 2016 at 09:27, Xufeng Liu <xufeng.liu.ietf@gmail.co= m> wrote:

Authors and contributors have discussed the use case= of abstract topology,
to address the incompleteness of connectivity matrix.

Current connectivity modeling is as follows:

      |     +--rw connectivity-matrix* [i= d]
      |     |  +--rw id   =         uint32
      |     |  +--rw from
      |     |  |  +--rw tp-ref?=    leafref
      |     |  +--rw to
      |     |  |  +--rw tp-ref?=    leafref
      |     |  +--rw is-allowed?&nbs= p;  Boolean

A Link TP may connect or disconnect to another Link TP, without detailed information such as cost and resource sharing restriction. To get a better<= br> abstraction of such connectivity, the following additional attributes are planned to be added:

  max-bandwidth?               = ;decimal64
  max-resv-bandwidth?          decimal64
  unreserved-bandwidth* [priority]
  priority     uint8
     +-- bandwidth?   decimal64
     +-- te-default-metric uint32
  performance-metric // re-use the container from te-link-atrributes   te-srlgs           // re-use the conta= iner from te-link-atrributes

Comments are welcome.

Thanks,

- Xufeng


_______________________________________________
Teas mailing list
Teas@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/teas

 

 

_=
______________________________________________
T=
eas mailing list
<=
a href=3D"mailto:Teas@ietf.org">Teas@ietf.org
<=
a href=3D"https://www.ietf.org/mailman/listinfo/teas">https://www.ietf.org/=
mailman/listinfo/teas
--_000_0C72C38E7EBC34499E8A9E7DD007863908EDCBCBdfweml501mbx_-- From nobody Mon May 23 09:44:13 2016 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 0756F12D91E; Mon, 23 May 2016 09:44:11 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160523164411.20876.84167.idtracker@ietfa.amsl.com> Date: Mon, 23 May 2016 09:44:11 -0700 Archived-At: Cc: lberger@labn.net, db3546@att.com, teas-chairs@ietf.org, teas@ietf.org, The IESG , draft-ietf-teas-interconnected-te-info-exchange@ietf.org, rfc-editor@rfc-editor.org Subject: [Teas] Protocol Action: 'Problem Statement and Architecture for Information Exchange Between Interconnected Traffic Engineered Networks' to Best Current Practice (draft-ietf-teas-interconnected-te-info-exchange-07.txt) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 16:44:11 -0000 The IESG has approved the following document: - 'Problem Statement and Architecture for Information Exchange Between Interconnected Traffic Engineered Networks' (draft-ietf-teas-interconnected-te-info-exchange-07.txt) as Best Current Practice This document is the product of the Traffic Engineering Architecture and Signaling Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-interconnected-te-info-exchange/ Technical Summary This document sets out the problem statement for the exchange of TE information between interconnected TE networks in support of end-to- end TE path establishment and describes the best current practice architecture to meet this problem statement. For reasons that are explained in the document, this work is limited to simple TE constraints and information that determine TE reachability. Working Group Summary This document has been in process for a long time. There were many heated discussions that eventually led to the this document which has a high degree of support. Recent delays were largely editorial rather than in content. Document Quality This document has been discussed and reviewed by the WG many times. It has a wide scope and covers it comprehensively. Having this information consolidated in a single place has real value to the WG, users and vendors. Personnel Who is the Document Shepherd? Lou Berger Who is the Responsible Area Director? Deborah Brungard From nobody Tue May 24 03:12:41 2016 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 70B1412D62C for ; Tue, 24 May 2016 03:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r07wH-OtQngg for ; Tue, 24 May 2016 03:12:36 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86F0612D65D for ; Tue, 24 May 2016 03:12:33 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u4OAC4Mu001896; Tue, 24 May 2016 11:12:04 +0100 Received: from 950129200 (jplon-nat13.juniper.net [193.110.55.13]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u4OAC0fo001788 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 24 May 2016 11:12:01 +0100 From: "Adrian Farrel" To: "'Scharf, Michael \(Nokia - DE\)'" , "'Andrew G. Malis'" References: <0c6c01d1a7a2$f1a24860$d4e6d920$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48846127@FR712WXCHMBA15.zeu.alcatel-lucent.com> <042101d1ad38$12da5f50$388f1df0$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48860ADB@FR712WXCHMBA15.zeu.alcatel-lucent.com> <001d01d1b3e1$bec637d0$3c52a770$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48862397@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48862F8B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48863026@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D488630EA@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D488630EA@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Tue, 24 May 2016 11:11:59 +0100 Message-ID: <033a01d1b5a4$b6b60060$24220120$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_033B_01D1B5AD.1884A190" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJA1E+Zq/sUNt+MoVFJT1Mxjgw0wgGJwDglArYWgCoCKVHAMAKLIq7PAjOFwrUCdCTXaAJHqFzBATAJ76ABHmmCbwKCWhugAlgeESueMTnVkA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22342.006 X-TM-AS-Result: No--26.216-10.0-31-10 X-imss-scan-details: No--26.216-10.0-31-10 X-TMASE-MatchedRID: UP6whsI5SHJbJCKOm3VRCaj5v7I4/SgY6ZSXgqg5qsvwlgxQKArHNFuO hGJuS77wfaWBs777U0nr/EBmiNuXt9aZ78zKkHLG47E6rstCUYt8BQ1mJKd4wa/8DL/vZVLb+m8 4l7uA86C77rpLLmM7Amgws6g0ewz2AZn/4A9db2QdGynCN4u9JZnMdECuBnFmUJaZHMPW6PxCLD HkRBvY64S2KcusOPFAcFEiuPxHjsUecJFiVRR1gvA23JZZuBX6N/IPgHUHVfBaoQLHdFhTGZHoy OpJ36wtC2s6EMq6ZtK9HTxRE6QQB1xIyn/X4SmnW/Kb+C9IfiLacYkeo0jQIu7GNOYc182em1zP tXRJIipveiHk0G+R0pmug812qIbzIaLR+2xKRDJAzN12EZ9S+Od0ekswGs6aC2LSbHrzHY3VDVy KStKeRpG468S7yeiwLUfH1TEwaN00AKed0u9fB914Aqe8EzF8ABZrZVX1zxg7Vr4aECXbm7XAKv XVvfCAdLTHjoswkho+bWumFri5NpWr6iSXWtgPxN4K0DXKS1jSg5kBtzyRnodOZtIeEJUceo0SM 3MKIFh/TZ/6kP79zsamcgjprEPz8GRhP/nTHNY26GPcGi6KL+lhgfFGvhkM467e7yLe4QctWFHu 5AW+VMEElERnDJHC5Lm3wIkdqWOjISEe13lmJQX3vTgk3QifWB1CTktboe4GrINsHLJ8O0nOYTD FtFSyYsviPUi7ptDg0Al6r0gNLIab/1O/b86BFJ4V2QoSrxfQ76clLi0jFZZZVeSN06TWx+nzp2 6Eqnfte0Kv05Ihe3317SsjPnPrGf83J4WEtBqbKItl61J/yZUdXE/WGn0FSXhbxZVQ5H+K65U5a tRZ+cXV8A5bPnwASOe8j5vgYt3xwegEUmzWT8Z+YXZCmXTH Archived-At: Cc: teas@ietf.org Subject: Re: [Teas] A New I-D on PCE as a central controller X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk 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, 24 May 2016 10:12:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_033B_01D1B5AD.1884A190 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thanks Andy and Michael for pushing this forward while I was otherwise = engaged. =20 I can modify the paragraph in section 4 to something like... =20 As such, there is an expectation that no substantial changes to = PCEP are required to support the=20 concept of a PCE-based controller. The only work expected to be = needed is small extensions to carry additional or specific information elements for the individual = use cases. Where possible, consistent with the general principles of how protocols are extended, any = additions to the protocol should be made in a generic way such that they are open to use in a range of = applications. =20 But before posting this I'd like to pick a little at Michael's point = because if he is right then some of this work may collapse. Of course, = it may all depend on some relative terms: "substantial" and "small". =20 What I meant to imply in the document was that existing mechanisms (PCEP = sessions over TCP) and messages (such as PCInitiate) are likely to be = adequate to achieve all of the functions since the required protocol = will need to be session-based and reliable, and since *some* message to = push state is needed. It is also my opinion that the sort of state being = pushed is: - to a network element - concerned with programming a forwarding instruction - related to reserving forwarding resources All of those things already exist to some extent in PCEP. =20 Do I think new objects/TLVs will be needed? Yes, probably, for some = uses. Do I think new values for some distinguishers will be needed? Yes, = definitely. =20 Would it help to go further in the proposed text by clarifying = "substantial"? =20 Thanks, Adrian =20 From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]=20 Sent: 23 May 2016 15:09 To: Andrew G. Malis Cc: adrian@olddog.co.uk; teas@ietf.org Subject: RE: [Teas] A New I-D on PCE as a central controller =20 That wording is somewhat better. From my experience with use cases = discussed in this draft it would be a surprise if that expectation was = true. But, of course, your mileage may vary. =20 Michael =20 =20 From: Andrew G. Malis [mailto:agmalis@gmail.com]=20 Sent: Monday, May 23, 2016 4:01 PM To: Scharf, Michael (Nokia - DE) Cc: adrian@olddog.co.uk; teas@ietf.org Subject: Re: [Teas] A New I-D on PCE as a central controller =20 Michael, =20 I agree that we don=E2=80=99t yet positively know that the conclusions = in section 4 are correct, but there=E2=80=99s also no specific knowledge = that they are incorrect. So I think it would be fair to change the = sentence "As such, no substantial changes to PCEP are required to = support the concept of a PCE-based controller.=E2=80=9D to "As such, no = substantial changes to PCEP are expected to support the concept of a = PCE-based controller.=E2=80=9D =20 Cheers, Andy =20 On Mon, May 23, 2016 at 9:52 AM, Scharf, Michael (Nokia - DE) = wrote: Fair point. But Section 4 should also be more explicit that the = conclusion there as hypothetical as the use cases Section 3. =20 This would not fix the problem with Section 3.2.2 and Section 3.2.3 but = at least make clear that Section 4 is pure speculation only. =20 Michael =20 =20 From: Andrew G. Malis [mailto:agmalis@gmail.com]=20 Sent: Monday, May 23, 2016 3:43 PM To: Scharf, Michael (Nokia - DE) Cc: adrian@olddog.co.uk; teas@ietf.org Subject: Re: [Teas] A New I-D on PCE as a central controller =20 Michael, =20 The introduction to section 3 says: =E2=80=9CAs previously mentioned, = this section is intended to just make suggestions.=E2=80=9D. That sound = like hypothetical to me. =20 Cheers, Andy =20 =20 On Mon, May 23, 2016 at 9:37 AM, Scharf, Michael (Nokia - DE) = wrote: Why doesn=E2=80=99t the document then mention that the use cases and = conclusions on PCEP are hypothetical? =20 Michael =20 =20 From: Andrew G. Malis [mailto:agmalis@gmail.com]=20 Sent: Monday, May 23, 2016 3:35 PM To: Scharf, Michael (Nokia - DE) Cc: adrian@olddog.co.uk; teas@ietf.org Subject: Re: [Teas] A New I-D on PCE as a central controller =20 Michael, =20 I think you=E2=80=99re expecting too much from this draft. It=E2=80=99s = meant to be a very high-level informational document to introduce the = concepts and a non-exhaustive list of possible applications and use = cases. As with any such early document, there=E2=80=99s some amount of = speculative writing, and there=E2=80=99s no expectation that all of the = discussed applications or use cases will actually come to fruition, and = there may be others in the future that do end up being implemented. But = the actual details of protocol changes and applications will be the = topics of other standards-track draft(s) to come. =20 Cheers, Andy =20 =20 On Sun, May 22, 2016 at 5:34 PM, Scharf, Michael (Nokia - DE) = wrote: Hi Adrian, =20 Many thanks for the tutorial. Since RFC 7491 already acknowledges the = role of a PCE, I see little value of a high-level document that talks = about PCEP as a general SBI for the topics mentioned in Section 3.2.2 = and Section 3.2.3, if that document does not discuss more specifically = the impact on PCEP, data models, etc. =20 It should be obvious that in my point of view the wording in Sections = 3.2.2 and 3.2.3 is not clear. Just repeating the wording once again does = not address my question, since I have obviously read the document and = since I know the terminology (albeit I am not a native speaker). A = generic flow chart not detailing for which of the messages PCEP would be = used, and with what content, also does not address my concern. In any case, if the content of Section 3.2.2 and Section 3.2.3 cannot be = made more explicit, it is impossible for me to understand whether the = conclusion in Section 4 =E2=80=A6 =E2=80=9CAs such, no substantial = changes to PCEP are required to support the concept of a PCE-based = controller. The only work needed will be small extensions to carry = additional or specific information elements for the individual use = cases.=E2=80=9D is correct and how it is actually justified for the = technical areas such as Section 3.2.2 and Section 3.2.3 . =20 >From my personal experience this sort of entirely generic conclusion = could perhaps be a bit of simplification, but this may depend on the = actual use case. But in an I-D, I believe such a generic conclusion = needs backing by content and as far as I understand for Section 3.2.2 = and Section 3.2.3 this backing is lacking in the document right now.=20 =20 Thanks =20 Michael =20 =20 From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Sunday, May 22, 2016 6:24 AM To: Scharf, Michael (Nokia - DE) Cc: teas@ietf.org Subject: RE: [Teas] A New I-D on PCE as a central controller =20 Michael,=20 =20 I don't think it is complicated, but it is obviously not clear from the = document, so thank you for raising the concern. =20 You say it doesn't matter which interface we're talking about, but it = does. PCEP is a protocol and protocols are used on interfaces. =20 Let's start with southbound of the PCE. We already use PCEP on this = interface. We have always done. It is what PCEP was invented for. And = recent developments in Stateful PCE and PCE-Initiated LSPs have made = PCEP (and this interface) able to send control "commands" as well as = respond to requests. Thus, PCEP is an SBI protocol for use with = signaling systems. =20 Now, we might make several observations... =20 In many (most?) MPLS-TE networks, every router is capable of being the = head end of LSPs. That means that in a PCE-enabled MPLS-TE network, = every router is a PCEP speaker. =20 Additionally, we can observe that LSPs (or PWs) can be stitched = together. The stitching, if under the control of a PCE, requires a = special instruction to be sent to the stitching node. =20 Furthermore, we can understand that a single end-to-end LSP is actually = the stitching of lots of single hop LSPs. That is really what a = statically provisioned LSP is. =20 Finally, we can see a desire to send TE instructions from a computation = engine (e.g., PCE) to individual network nodes to program their = forwarding. For example, in a Segment Routed network or for static = MPLS-TE LSPs. =20 =20 Put all of this together with the recognition that all TE path = management is fundamentally the same and can be performed by the same = engine, and that it does not make sense for such an engine to have to = implement multiple SBI protocols, and you end up with this draft. =20 I don't think we are saying that this approach is compulsory, but we are = saying that it is possible. Other possibilities exist including using = NETCONF/YANG in place of PCEP, and enhancing BGP in place of PCEP. = Others have suggested XMPP. Frankly, if we were proposing a new protocol = it would be correct to tell us not to, and to persuade us that one of = the other protocols will do the job. But here we are with three (or = four) protocols that fit the bill: each currently covers some of the = function space and each could easily be extended to cover the whole = space. I'm not capable of saying how to decide which protocol does which = function, but I do see pressures of implementation and deployment that = lead to this draft. =20 [Historic note: I was somewhat opposed to adding PCE-Initiated LSP = support to PCEP. I thought this bent the architecture further than was = originally intended. But we went there in the PEC WG and the I-D is now = "complete". By adding support of PCE initiation of LSPs, we naturally = opened the path to this document. FWIW, this is not the first time that = PCEP has been discussed as a more general SBI protocol - RFC 7491 shows = it in this context although does not discuss it much (we should probably = add a reference to ABNO in this document).] =20 =20 Now, you say you are surprised that "the document focuses on using PCEP = e.g. for L3VPN service delivery." I think there is a significant = difference between *requesting* a service and *delivering* that service. = The service request (as, for example, in L3SM) does not involve a PCE = and is easily achieved using a YANG model which, if the service request = is on-line, can be delivered using NETCONF. However, service delivery = requires "orchestration". Orchestration is the process of considering = available network resources and selecting what will be provisioned to = support the service. A PCE is at least a key feature of orchestration, = just as it is a key component of a network controller.=20 =20 But the document does NOT focus on PCEP in quite the way you describe. = In fact, the only discussion is in 3.2.3 (just two paragraphs in the = whole document) where the focus is on the use of a PCE-based central = controller that can "consider the whole network and all components of a = service at once when planning how to deliver the service." It then goes = on to observe that PCEP can be used "to manage the network resources and = to install the necessary associations between those resources."=20 =20 =20 If we included a message flow chart it would look something like... =20 Service Manager PCE-based Controller NEs Request service---------> Compute Provision ------> <------------- Ack Update DBs <-------------------Ack =20 If that simple figure helps with the understanding of this or any other = part of the document, we can surely add it. =20 Cheers, Adrian =20 > -----Original Message----- > From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] > Sent: 20 May 2016 19:07 > To: adrian@olddog.co.uk; teas@ietf.org > Subject: RE: [Teas] A New I-D on PCE as a central controller >=20 > As I said, I specifically wonder about Section 3.2.3 "Service = Delivery", which states > (omitting some parts that are not relevant here): >=20 > "Various network services may be offered over a network. These include > protection services [...] Virtual Private Network (VPN) service (such = as Layer 3 > VPNs [RFC4364] or Ethernet VPNs [RFC7432]), or Pseudowires [RFC3985]. = [...] A > PCE-based central control can consider the whole network and all = components of > a service at once when planning how to deliver the service. It can = then use PCEP > to manage the network resources and to install the necessary = associations > between those resources." >=20 > This wording on use of PCEP confuses me, no matter what interface we = talk > about. I would have assumed that YANG-based protocols such as > NETCONF/RESTCONF could be useful in this context, and I am a bit = surprised that > the document focuses on using PCEP e.g. for L3VPN service delivery. By = the way, > I also wonder how PCEP fits into the discussion on QoS classification = in Section > 3.2.2. >=20 > I wonder if the authors could add to Section 3.2.2 and Section 3.2.3 = e.g. a > message sequence chart that illustrates how what is discussed in those = sections > relates to PCEP? >=20 > Michael >=20 >=20 >=20 > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of EXT Adrian = Farrel > Sent: Friday, May 13, 2016 6:54 PM > To: Scharf, Michael (Nokia - DE); teas@ietf.org > Subject: Re: [Teas] A New I-D on PCE as a central controller >=20 > Hello again, Michael, it seems to be my day for replying to your = emails. >=20 > > When reading about uses cases such as L3VPN service delivery in > > "Section > 3.2.3", > > what is the author's view on the line of demarcation between NETCONF > > and PCEP? >=20 > Well, I wonder which interface you're talking about. > The ones that out in here are: > - the interface between customer and operator > - the interface between "service orchestrator" and "network = orchestrator" >=20 > The former of these is like the interface used in L3SM. As co-chair of = L3SM, you > might not be surprised to hear that my view is that NETCONF is a fine = solution - > well, the use of a YANG data model, in any case. >=20 > The latter is the interface between "Orchestrator / Service Manager / = OSS / > NMS" > and "PCE-based Controller" as shown on the various figures in the = picture. We > haven't discussed this interface in the document, and perhaps we = should. >=20 > If you look at Figure 6 (with the hierarchy of controllers) you might = observe that > the parent controller could be implemented to act as though it is = talking to an NE > (in the abstract node model) and that means that the southbound = interface of > the parent controller would be PCEP. That means (of course) that the > northbound interface of the child controller would also be PCEP. Then, = it might > seem obvious that we would want all PCE implementations to behave the = same > way and so that makes the northbound interface of the parent PCE > would/could/should/might also be PCEP. >=20 > What do you think? >=20 > Thanks, > Adrian >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas =20 =20 =20 ------=_NextPart_000_033B_01D1B5AD.1884A190 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Thanks Andy and Michael for = pushing this forward while I was otherwise = engaged.

 

I can modify the paragraph in = section 4 to something like...

 

=C2=A0=C2=A0=C2=A0=C2=A0 <t>As = such, there is an expectation that no substantial changes to PCEP are = required to support the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= concept of a PCE-based controller.=C2=A0 The only work expected to be = needed is small extensions to carry

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = additional or specific information elements for the individual = use cases.=C2=A0 Where possible, = consistent

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = with the general principles of how protocols are extended, any = additions to the protocol should be made

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = in a generic way such that they are open to use in a range of = applications.</t>

 

But before posting this I'd = like to pick a little at Michael's point because if he is right then = some of this work may collapse. Of course, it may all depend on some = relative terms: "substantial" and = "small".

 

What I meant to imply in the = document was that existing mechanisms (PCEP sessions over TCP) and = messages (such as PCInitiate) are likely to be adequate to achieve all = of the functions since the required protocol will need to be = session-based and reliable, and since *some* message to push state is = needed. It is also my opinion that the sort of state being pushed = is:

- to a network = element

- concerned with programming a = forwarding instruction

- related to reserving = forwarding resources

All of those things already = exist to some extent in PCEP.

 

Do I think new objects/TLVs = will be needed? Yes, probably, for some uses.

Do I think new values for some = distinguishers will be needed? Yes, definitely.

 

Would it help to go further in = the proposed text by clarifying = "substantial"?

 

Thanks,

Adrian

 

From: Scharf, Michael = (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: 23 May = 2016 15:09
To: Andrew G. Malis
Cc: = adrian@olddog.co.uk; teas@ietf.org
Subject: RE: [Teas] A New = I-D on PCE as a central controller

 

That wording is somewhat better. From my = experience with use cases discussed in this draft it would be a surprise = if that expectation was true. But, of course, your mileage may = vary.

 

Michael

 

 

From: Andrew G. Malis [mailto:agmalis@gmail.com]
Sent: = Monday, May 23, 2016 4:01 PM
To: Scharf, Michael (Nokia - = DE)
Cc: adrian@olddog.co.uk; teas@ietf.org
Subject: = Re: [Teas] A New I-D on PCE as a central = controller

 

Michael,

 

=

I agree that we don=E2=80=99t yet = positively know that the conclusions in section 4 are correct, but = there=E2=80=99s also no specific knowledge that they are incorrect. So I = think it would be fair to change the sentence "As such, no = substantial changes to PCEP are required to support the concept of a = PCE-based controller.=E2=80=9D to "As such, no substantial changes = to PCEP are expected to support the concept of a PCE-based = controller.=E2=80=9D

 

=

Cheers,

Andy

<= div>

 

On Mon, May 23, 2016 at 9:52 AM, = Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com> = wrote:

Fair point. But Section 4 should also be more = explicit that the conclusion there as hypothetical as the use cases = Section 3.

 

This would not fix the problem with Section = 3.2.2 and Section 3.2.3 but at least make clear that Section 4 is pure = speculation only.

 

Michael

 

 

From: Andrew G. Malis [mailto:agmalis@gmail.com]
Sent: Monday, May = 23, 2016 3:43 PM


To: Scharf, Michael (Nokia = - DE)
Cc: adrian@olddog.co.uk; teas@ietf.org
Subject: Re: [Teas] A New = I-D on PCE as a central = controller

 

Michael,

 

=

The introduction to = section 3 says: =E2=80=9CAs previously mentioned, this section is = intended to just make suggestions.=E2=80=9D. That sound like = hypothetical to me.

 

=

Cheers,

Andy

 

 

On Mon, May 23, 2016 at = 9:37 AM, Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com> = wrote:

Why doesn=E2=80=99t the document then mention = that the use cases and conclusions on PCEP are hypothetical?

 

Michael

 

 

From: Andrew G. Malis [mailto:agmalis@gmail.com]
Sent: Monday, May = 23, 2016 3:35 PM
To: Scharf, Michael (Nokia - = DE)
Cc: adrian@olddog.co.uk; teas@ietf.org


Subject: Re: = [Teas] A New I-D on PCE as a central = controller

 

Michael,

 

=

I think you=E2=80=99re = expecting too much from this draft. It=E2=80=99s meant to be a very = high-level informational document to introduce the concepts and a = non-exhaustive list of possible applications and use cases. As with any = such early document, there=E2=80=99s some amount of speculative writing, = and there=E2=80=99s no expectation that all of the discussed = applications or use cases will actually come to fruition, and there may = be others in the future that do end up being implemented. But the actual = details of protocol changes and applications will be the topics of other = standards-track draft(s) to come.

 

=

Cheers,

Andy

 

 

On Sun, May 22, 2016 at = 5:34 PM, Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com> = wrote:

Hi = Adrian,

 

Many thanks = for the tutorial. Since RFC 7491 already acknowledges the role of a PCE, = I see little value of a high-level document that talks about PCEP as a = general SBI for the topics mentioned in Section 3.2.2 and Section 3.2.3, = if that document does not discuss more specifically the impact on PCEP, = data models, etc.

 

It should = be obvious that in my point of view the wording in Sections 3.2.2 and = 3.2.3 is not clear. Just repeating the wording once again does not = address my question, since I have obviously read the document and since = I know the terminology (albeit I am not a native speaker). A generic = flow chart not detailing for which of the messages PCEP would be used, = and with what content, also does not address my concern.

In any = case, if the content of Section 3.2.2 and Section 3.2.3 cannot be made = more explicit, it is impossible for me to understand whether the = conclusion in Section 4 =E2=80=A6 =E2=80=9CAs such, no substantial = changes to PCEP are required to support the concept of a PCE-based = controller. The only work needed will be small extensions to carry = additional or specific information elements for the individual use = cases.=E2=80=9D is correct and how it is actually justified for the = technical areas such as Section 3.2.2 and Section 3.2.3 .

 

From my = personal experience this sort of entirely generic conclusion could = perhaps be a bit of simplification, but this may depend on the actual = use case. But in an I-D, I believe such a generic conclusion needs = backing by content and as far as I understand for Section 3.2.2 and = Section 3.2.3 this backing is lacking in the document right now. =

 

Thanks

 

Michael

 

 

From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: Sunday, May = 22, 2016 6:24 AM
To: Scharf, Michael (Nokia - = DE)
Cc: teas@ietf.org


Subject: RE: [Teas] = A New I-D on PCE as a central controller

 

Michael, =

 

I don't think = it is complicated, but it is obviously not clear from the document, so = thank you for raising the concern.

 

You say it = doesn't matter which interface we're talking about, but it does. PCEP is = a protocol and protocols are used on interfaces.

 

Let's start = with southbound of the PCE. We already use PCEP on this interface. We = have always done. It is what PCEP was invented for. And recent = developments in Stateful PCE and PCE-Initiated LSPs have made PCEP (and = this interface) able to send control "commands" as well as = respond to requests. Thus, PCEP is an SBI protocol for use with = signaling systems.

 

Now, we might = make several observations...

 

In many = (most?) MPLS-TE networks, every router is capable of being the head end = of LSPs. That means that in a PCE-enabled MPLS-TE network, every router = is a PCEP speaker.

 

Additionally, = we can observe that LSPs (or PWs) can be stitched together. The = stitching, if under the control of a PCE, requires a special instruction = to be sent to the stitching node.

 

Furthermore, = we can understand that a single end-to-end LSP is actually the stitching = of lots of single hop LSPs. That is really what a statically provisioned = LSP is.

 

Finally, we = can see a desire to send TE instructions from a computation engine = (e.g., PCE) to individual network nodes to program their forwarding. For = example, in a Segment Routed network or for static MPLS-TE LSPs.

 

 

Put all of = this together with the recognition that all TE path management is = fundamentally the same and can be performed by the same engine, and that = it does not make sense for such an engine to have to implement multiple = SBI protocols, and you end up with this draft.

 

I don't think = we are saying that this approach is compulsory, but we are saying that = it is possible. Other possibilities exist including using NETCONF/YANG = in place of PCEP, and enhancing BGP in place of PCEP. Others have = suggested XMPP. Frankly, if we were proposing a new protocol it would be = correct to tell us not to, and to persuade us that one of the other = protocols will do the job. But here we are with three (or four) = protocols that fit the bill: each currently covers some of the function = space and each could easily be extended to cover the whole space. I'm = not capable of saying how to decide which protocol does which function, = but I do see pressures of implementation and deployment that lead to = this draft.

 

[Historic = note: I was somewhat opposed to adding PCE-Initiated LSP support to = PCEP. I thought this bent the architecture further than was originally = intended. But we went there in the PEC WG and the I-D is now = "complete". By adding support of PCE initiation of LSPs, we = naturally opened the path to this document. FWIW, this is not the first = time that PCEP has been discussed as a more general SBI protocol - RFC = 7491 shows it in this context although does not discuss it much (we = should probably add a reference to ABNO in this document).]

 

 

Now, you say = you are surprised that "the document focuses on using PCEP e.g. for = L3VPN service delivery." I think there is a significant difference = between *requesting* a service and *delivering* that service. The = service request (as, for example, in L3SM) does not involve a PCE and is = easily achieved using a YANG model which, if the service request is = on-line, can be delivered using NETCONF. However, service delivery = requires "orchestration". Orchestration is the process of = considering available network resources and selecting what will be = provisioned to support the service. A PCE is at least a key feature of = orchestration, just as it is a key component of a network controller. =

 

But the = document does NOT focus on PCEP in quite the way you describe. In fact, = the only discussion is in 3.2.3 (just two paragraphs in the whole = document) where the focus is on the use of a PCE-based central = controller that can "consider the whole network and all components = of a service at once when planning how to deliver the service." It = then goes on to observe that PCEP can be used "to manage the = network resources and to install the necessary associations between = those resources."

 

 

If we = included a message flow chart it would look something like...

 

Service = Manager      PCE-based = Controller     NEs

     Request = service--------->

           &= nbsp;           &n= bsp;  Compute

           &= nbsp;           &n= bsp;       Provision = ------>

           &= nbsp;           &n= bsp;        <------------- = Ack

           &= nbsp;           &n= bsp;  Update DBs

     = <-------------------Ack

 

If that simple figure helps with the = understanding of this or any other part of the document, we can surely = add it.

 

Cheers,

Adrian

 

> -----Original = Message-----

> From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]<= /p>

> Sent: 20 = May 2016 19:07

> To: adrian@olddog.co.uk; teas@ietf.org

> Subject: RE: [Teas] A New = I-D on PCE as a central controller

>

> As I = said, I specifically wonder about Section 3.2.3 "Service = Delivery", which states

> = (omitting some parts that are not relevant here):

>

> = "Various network services may be offered over a network. These = include

> = protection services [...] Virtual Private Network (VPN) service (such as = Layer 3

> VPNs = [RFC4364] or Ethernet VPNs [RFC7432]), or Pseudowires [RFC3985]. = [...]  A

> = PCE-based central control can consider the whole network and all = components of

> a = service at once when planning how to deliver the service. It can then = use PCEP

> to = manage the network resources and to install the necessary = associations

> between = those resources."

>

> This = wording on use of PCEP confuses me, no matter what interface we = talk

> about. I = would have assumed that YANG-based protocols such as

> = NETCONF/RESTCONF could be useful in this context, and I am a bit = surprised that

> the = document focuses on using PCEP e.g. for L3VPN service delivery. By the = way,

> I also = wonder how PCEP fits into the discussion on QoS classification in = Section

> = 3.2.2.

>

> I wonder = if the authors could add to Section 3.2.2 and Section 3.2.3 e.g. a

> message = sequence chart that illustrates how what is discussed in those = sections

> relates = to PCEP?

>

> = Michael

>

>

>

> = -----Original Message-----

> From: = Teas [mailto:teas-bounces@ietf.org] On Behalf Of EXT = Adrian Farrel

> Sent: = Friday, May 13, 2016 6:54 PM

> To: = Scharf, Michael (Nokia - DE); teas@ietf.org

> Subject: = Re: [Teas] A New I-D on PCE as a central controller

>

> Hello = again, Michael, it seems to be my day for replying to your emails.

>

> > = When reading about uses cases such as L3VPN service delivery in

> > = "Section

> = 3.2.3",

> > = what is the author's view on the line of demarcation between = NETCONF

> > and = PCEP?

>

> Well, I = wonder which interface you're talking about.

> The ones = that out in here are:

> - the = interface between customer and operator

> - the = interface between "service orchestrator" and "network = orchestrator"

>

> The = former of these is like the interface used in L3SM. As co-chair of L3SM, = you

> might = not be surprised to hear that my view is that NETCONF is a fine solution = -

> well, = the use of a YANG data model, in any case.

>

> The = latter is the interface between "Orchestrator / Service Manager / = OSS /

> = NMS"

> and = "PCE-based Controller" as shown on the various figures in the = picture. We

> haven't = discussed this interface in the document, and perhaps we should.

>

> If you = look at Figure 6 (with the hierarchy of controllers) you might observe = that

> the = parent controller could be implemented to act as though it is talking to = an NE

> (in the = abstract node model) and that means that the southbound interface = of

> the = parent controller would be PCEP. That means (of course) that the

> = northbound interface of the child controller would also be PCEP. Then, = it might

> seem = obvious that we would want all PCE implementations to behave the = same

> way and = so that makes the northbound interface of the parent PCE

> = would/could/should/might also be PCEP.

>

> What do = you think?

>

> = Thanks,

> = Adrian

>

> = _______________________________________________

> Teas = mailing list

> Teas@ietf.org

> https://www.ietf.org/mailman/listinfo/teas


___________________________________= ____________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas

 

 

 

------=_NextPart_000_033B_01D1B5AD.1884A190-- From nobody Tue May 24 12:30:10 2016 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 2733412D1CA for ; Tue, 24 May 2016 12:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAi2XMHuF1Oy for ; Tue, 24 May 2016 12:30:06 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99E0012D183 for ; Tue, 24 May 2016 12:30:06 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id k23so43547660oih.0 for ; Tue, 24 May 2016 12:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RnYAIgJS0H5AIWY/WB2unBRBjK8XDry2MPx7vmbbHd0=; b=ImqUizPAoti8YhtOZa+E7nWj1Mcz53CQxp9iJ82CWvLOxfy5iRbrEMJDbvQcZKHRLN KD6Mi1GKvohHjhJLB8+QIwnxjEzA2ojnsLgCzw6BIgaiUD0zx+0K2WU/ny6ii2oWNLGT PjHjHftsR5j1V+2hBDjTOd7KKkDZqaGFbmCZZgmdxrZ17nvl5yGDaXDwf4LOh7/qr961 VY7YFljIj5Z9vMTw7VIUpmFcTQ6tNlaeimfPArYiI1cj7XIpSEA1Oba3Vpxl1FIdpQxX UFrrb9IbBZgoXWLMTYPbMQfUkRniID7pcRR21EVyObDj4SOiczFkgZOLlDpdYQtjrkKM 5ArA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RnYAIgJS0H5AIWY/WB2unBRBjK8XDry2MPx7vmbbHd0=; b=Rjr1ycNB+BAxUUWVffdgtrrbCtAiww1fnXqYuJG6lq71yPIi1tOsLMdSmplIegFler w12d1Ow+AWg2rs2Q5Ez+g8itzVaMakLtE4wzAHnCQz2O58VgEzySQ16dZV04GS+9KSYJ CjIaNbii+SHEEUXQuW90wP/brT3q0t+2kFsEgzn+tt8hpbR+sPvRzK7aX9yfC3OwHI0K VnIfn4p813rw27kNIa1dIf9/18kpf8Vp7GkJSVzRPOsyqJRUSGJpV5AQErkrYWWz6E6T HPoeBreSCbV8wtKYGdaBHGOU69ZJNhK0Ebb9oqhHNwoW6fzgwpqu8XIspTSU2j+KjBjg rdTA== X-Gm-Message-State: ALyK8tJsqqNH3eCDycxidtT2IRE0L7F5quGDwZ/h9YFpYowVL83FCEzsEc4VdnHZIDMntPjh8c1p/p2VDNb1lQ== X-Received: by 10.157.34.12 with SMTP id o12mr3850688ota.55.1464118205836; Tue, 24 May 2016 12:30:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.231.106 with HTTP; Tue, 24 May 2016 12:29:46 -0700 (PDT) In-Reply-To: <033a01d1b5a4$b6b60060$24220120$@olddog.co.uk> References: <0c6c01d1a7a2$f1a24860$d4e6d920$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48846127@FR712WXCHMBA15.zeu.alcatel-lucent.com> <042101d1ad38$12da5f50$388f1df0$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48860ADB@FR712WXCHMBA15.zeu.alcatel-lucent.com> <001d01d1b3e1$bec637d0$3c52a770$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48862397@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48862F8B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48863026@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D488630EA@FR712WXCHMBA15.zeu.alcatel-lucent.com> <033a01d1b5a4$b6b60060$24220120$@olddog.co.uk> From: "Andrew G. Malis" Date: Tue, 24 May 2016 15:29:46 -0400 Message-ID: To: Adrian Farrel Content-Type: multipart/alternative; boundary=001a113bff7a91747005339b95ae Archived-At: Cc: "Scharf, Michael \(Nokia - DE\)" , "teas@ietf.org" Subject: Re: [Teas] A New I-D on PCE as a central controller X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 24 May 2016 19:30:10 -0000 --001a113bff7a91747005339b95ae Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Adrian, It might be easier to just say =E2=80=9Crelatively minor changes=E2=80=9D r= ather than =E2=80=9Cno substantial changes=E2=80=9D. I think people in general have a good feel fo= r what a =E2=80=9Creiatively minor=E2=80=9D change to an existing protocol entails, = and again, this is not a standards track document, just informational, and it=E2=80=99s jus= t an expectation. Just my two cents. Cheers, Andy On Tue, May 24, 2016 at 6:11 AM, Adrian Farrel wrote: > Thanks Andy and Michael for pushing this forward while I was otherwise > engaged. > > > > I can modify the paragraph in section 4 to something like... > > > > As such, there is an expectation that no substantial changes to > PCEP are required to support the > > concept of a PCE-based controller. The only work expected to be > needed is small extensions to carry > > additional or specific information elements for the individual > use cases. Where possible, consistent > > with the general principles of how protocols are extended, any > additions to the protocol should be made > > in a generic way such that they are open to use in a range of > applications. > > > > But before posting this I'd like to pick a little at Michael's point > because if he is right then some of this work may collapse. Of course, it > may all depend on some relative terms: "substantial" and "small". > > > > What I meant to imply in the document was that existing mechanisms (PCEP > sessions over TCP) and messages (such as PCInitiate) are likely to be > adequate to achieve all of the functions since the required protocol will > need to be session-based and reliable, and since *some* message to push > state is needed. It is also my opinion that the sort of state being pushe= d > is: > > - to a network element > > - concerned with programming a forwarding instruction > > - related to reserving forwarding resources > > All of those things already exist to some extent in PCEP. > > > > Do I think new objects/TLVs will be needed? Yes, probably, for some uses. > > Do I think new values for some distinguishers will be needed? Yes, > definitely. > > > > Would it help to go further in the proposed text by clarifying > "substantial"? > > > > Thanks, > > Adrian > > > > *From:* Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] > *Sent:* 23 May 2016 15:09 > *To:* Andrew G. Malis > *Cc:* adrian@olddog.co.uk; teas@ietf.org > > *Subject:* RE: [Teas] A New I-D on PCE as a central controller > > > > That wording is somewhat better. From my experience with use cases > discussed in this draft it would be a surprise if that expectation was > true. But, of course, your mileage may vary. > > > > Michael > > > > > > *From:* Andrew G. Malis [mailto:agmalis@gmail.com] > *Sent:* Monday, May 23, 2016 4:01 PM > *To:* Scharf, Michael (Nokia - DE) > *Cc:* adrian@olddog.co.uk; teas@ietf.org > *Subject:* Re: [Teas] A New I-D on PCE as a central controller > > > > Michael, > > > > I agree that we don=E2=80=99t yet positively know that the conclusions in= section > 4 are correct, but there=E2=80=99s also no specific knowledge that they a= re > incorrect. So I think it would be fair to change the sentence "As such, n= o > substantial changes to PCEP are required to support the concept of a > PCE-based controller.=E2=80=9D to "As such, no substantial changes to PCE= P are > expected to support the concept of a PCE-based controller.=E2=80=9D > > > > Cheers, > > Andy > > > > On Mon, May 23, 2016 at 9:52 AM, Scharf, Michael (Nokia - DE) < > michael.scharf@nokia.com> wrote: > > Fair point. But Section 4 should also be more explicit that the conclusio= n > there as hypothetical as the use cases Section 3. > > > > This would not fix the problem with Section 3.2.2 and Section 3.2.3 but a= t > least make clear that Section 4 is pure speculation only. > > > > Michael > > > > > > *From:* Andrew G. Malis [mailto:agmalis@gmail.com] > *Sent:* Monday, May 23, 2016 3:43 PM > > > *To:* Scharf, Michael (Nokia - DE) > *Cc:* adrian@olddog.co.uk; teas@ietf.org > *Subject:* Re: [Teas] A New I-D on PCE as a central controller > > > > Michael, > > > > The introduction to section 3 says: =E2=80=9CAs previously mentioned, thi= s section > is intended to just make suggestions.=E2=80=9D. That sound like hypotheti= cal to me. > > > > Cheers, > > Andy > > > > > > On Mon, May 23, 2016 at 9:37 AM, Scharf, Michael (Nokia - DE) < > michael.scharf@nokia.com> wrote: > > Why doesn=E2=80=99t the document then mention that the use cases and conc= lusions > on PCEP are hypothetical? > > > > Michael > > > > > > *From:* Andrew G. Malis [mailto:agmalis@gmail.com] > *Sent:* Monday, May 23, 2016 3:35 PM > *To:* Scharf, Michael (Nokia - DE) > *Cc:* adrian@olddog.co.uk; teas@ietf.org > > > *Subject:* Re: [Teas] A New I-D on PCE as a central controller > > > > Michael, > > > > I think you=E2=80=99re expecting too much from this draft. It=E2=80=99s m= eant to be a very > high-level informational document to introduce the concepts and a > non-exhaustive list of possible applications and use cases. As with any > such early document, there=E2=80=99s some amount of speculative writing, = and > there=E2=80=99s no expectation that all of the discussed applications or = use cases > will actually come to fruition, and there may be others in the future tha= t > do end up being implemented. But the actual details of protocol changes a= nd > applications will be the topics of other standards-track draft(s) to come= . > > > > Cheers, > > Andy > > > > > > On Sun, May 22, 2016 at 5:34 PM, Scharf, Michael (Nokia - DE) < > michael.scharf@nokia.com> wrote: > > Hi Adrian, > > > > Many thanks for the tutorial. Since RFC 7491 already acknowledges the rol= e > of a PCE, I see little value of a high-level document that talks about PC= EP > as a general SBI for the topics mentioned in Section 3.2.2 and Section > 3.2.3, if that document does not discuss more specifically the impact on > PCEP, data models, etc. > > > > It should be obvious that in my point of view the wording in Sections > 3.2.2 and 3.2.3 is not clear. Just repeating the wording once again does > not address my question, since I have obviously read the document and sin= ce > I know the terminology (albeit I am not a native speaker). A generic flow > chart not detailing for which of the messages PCEP would be used, and wit= h > what content, also does not address my concern. > > In any case, if the content of Section 3.2.2 and Section 3.2.3 cannot be > made more explicit, it is impossible for me to understand whether the > conclusion in Section 4 =E2=80=A6 =E2=80=9CAs such, no substantial change= s to PCEP are > required to support the concept of a PCE-based controller. The only work > needed will be small extensions to carry additional or specific informati= on > elements for the individual use cases.=E2=80=9D is correct and how it is = actually > justified for the technical areas such as Section 3.2.2 and Section 3.2.3= . > > > > From my personal experience this sort of entirely generic conclusion coul= d > perhaps be a bit of simplification, but this may depend on the actual use > case. But in an I-D, I believe such a generic conclusion needs backing by > content and as far as I understand for Section 3.2.2 and Section 3.2.3 th= is > backing is lacking in the document right now. > > > > Thanks > > > > Michael > > > > > > *From:* Adrian Farrel [mailto:adrian@olddog.co.uk] > *Sent:* Sunday, May 22, 2016 6:24 AM > *To:* Scharf, Michael (Nokia - DE) > *Cc:* teas@ietf.org > > > *Subject:* RE: [Teas] A New I-D on PCE as a central controller > > > > Michael, > > > > I don't think it is complicated, but it is obviously not clear from the > document, so thank you for raising the concern. > > > > You say it doesn't matter which interface we're talking about, but it > does. PCEP is a protocol and protocols are used on interfaces. > > > > Let's start with southbound of the PCE. We already use PCEP on this > interface. We have always done. It is what PCEP was invented for. And > recent developments in Stateful PCE and PCE-Initiated LSPs have made PCEP > (and this interface) able to send control "commands" as well as respond t= o > requests. Thus, PCEP is an SBI protocol for use with signaling systems. > > > > Now, we might make several observations... > > > > In many (most?) MPLS-TE networks, every router is capable of being the > head end of LSPs. That means that in a PCE-enabled MPLS-TE network, every > router is a PCEP speaker. > > > > Additionally, we can observe that LSPs (or PWs) can be stitched together. > The stitching, if under the control of a PCE, requires a special > instruction to be sent to the stitching node. > > > > Furthermore, we can understand that a single end-to-end LSP is actually > the stitching of lots of single hop LSPs. That is really what a staticall= y > provisioned LSP is. > > > > Finally, we can see a desire to send TE instructions from a computation > engine (e.g., PCE) to individual network nodes to program their forwardin= g. > For example, in a Segment Routed network or for static MPLS-TE LSPs. > > > > > > Put all of this together with the recognition that all TE path management > is fundamentally the same and can be performed by the same engine, and th= at > it does not make sense for such an engine to have to implement multiple S= BI > protocols, and you end up with this draft. > > > > I don't think we are saying that this approach is compulsory, but we are > saying that it is possible. Other possibilities exist including using > NETCONF/YANG in place of PCEP, and enhancing BGP in place of PCEP. Others > have suggested XMPP. Frankly, if we were proposing a new protocol it woul= d > be correct to tell us not to, and to persuade us that one of the other > protocols will do the job. But here we are with three (or four) protocols > that fit the bill: each currently covers some of the function space and > each could easily be extended to cover the whole space. I'm not capable o= f > saying how to decide which protocol does which function, but I do see > pressures of implementation and deployment that lead to this draft. > > > > [Historic note: I was somewhat opposed to adding PCE-Initiated LSP suppor= t > to PCEP. I thought this bent the architecture further than was originally > intended. But we went there in the PEC WG and the I-D is now "complete". = By > adding support of PCE initiation of LSPs, we naturally opened the path to > this document. FWIW, this is not the first time that PCEP has been > discussed as a more general SBI protocol - RFC 7491 shows it in this > context although does not discuss it much (we should probably add a > reference to ABNO in this document).] > > > > > > Now, you say you are surprised that "the document focuses on using PCEP > e.g. for L3VPN service delivery." I think there is a significant differen= ce > between *requesting* a service and *delivering* that service. The service > request (as, for example, in L3SM) does not involve a PCE and is easily > achieved using a YANG model which, if the service request is on-line, can > be delivered using NETCONF. However, service delivery requires > "orchestration". Orchestration is the process of considering available > network resources and selecting what will be provisioned to support the > service. A PCE is at least a key feature of orchestration, just as it is = a > key component of a network controller. > > > > But the document does NOT focus on PCEP in quite the way you describe. In > fact, the only discussion is in 3.2.3 (just two paragraphs in the whole > document) where the focus is on the use of a PCE-based central controller > that can "consider the whole network and all components of a service at > once when planning how to deliver the service." It then goes on to observ= e > that PCEP can be used "to manage the network resources and to install the > necessary associations between those resources." > > > > > > If we included a message flow chart it would look something like... > > > > Service Manager PCE-based Controller NEs > > Request service---------> > > Compute > > Provision ------> > > <------------- Ack > > Update DBs > > <-------------------Ack > > > > If that simple figure helps with the understanding of this or any other > part of the document, we can surely add it. > > > > Cheers, > > Adrian > > > > > -----Original Message----- > > > From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com > ] > > > Sent: 20 May 2016 19:07 > > > To: adrian@olddog.co.uk; teas@ietf.org > > > Subject: RE: [Teas] A New I-D on PCE as a central controller > > > > > > As I said, I specifically wonder about Section 3.2.3 "Service Delivery"= , > which states > > > (omitting some parts that are not relevant here): > > > > > > "Various network services may be offered over a network. These include > > > protection services [...] Virtual Private Network (VPN) service (such a= s > Layer 3 > > > VPNs [RFC4364] or Ethernet VPNs [RFC7432]), or Pseudowires [RFC3985]. > [...] A > > > PCE-based central control can consider the whole network and all > components of > > > a service at once when planning how to deliver the service. It can then > use PCEP > > > to manage the network resources and to install the necessary associatio= ns > > > between those resources." > > > > > > This wording on use of PCEP confuses me, no matter what interface we ta= lk > > > about. I would have assumed that YANG-based protocols such as > > > NETCONF/RESTCONF could be useful in this context, and I am a bit > surprised that > > > the document focuses on using PCEP e.g. for L3VPN service delivery. By > the way, > > > I also wonder how PCEP fits into the discussion on QoS classification i= n > Section > > > 3.2.2. > > > > > > I wonder if the authors could add to Section 3.2.2 and Section 3.2.3 > e.g. a > > > message sequence chart that illustrates how what is discussed in those > sections > > > relates to PCEP? > > > > > > Michael > > > > > > > > > > > > -----Original Message----- > > > From: Teas [mailto:teas-bounces@ietf.org ] On > Behalf Of EXT Adrian Farrel > > > Sent: Friday, May 13, 2016 6:54 PM > > > To: Scharf, Michael (Nokia - DE); teas@ietf.org > > > Subject: Re: [Teas] A New I-D on PCE as a central controller > > > > > > Hello again, Michael, it seems to be my day for replying to your emails= . > > > > > > > When reading about uses cases such as L3VPN service delivery in > > > > "Section > > > 3.2.3", > > > > what is the author's view on the line of demarcation between NETCONF > > > > and PCEP? > > > > > > Well, I wonder which interface you're talking about. > > > The ones that out in here are: > > > - the interface between customer and operator > > > - the interface between "service orchestrator" and "network orchestrato= r" > > > > > > The former of these is like the interface used in L3SM. As co-chair of > L3SM, you > > > might not be surprised to hear that my view is that NETCONF is a fine > solution - > > > well, the use of a YANG data model, in any case. > > > > > > The latter is the interface between "Orchestrator / Service Manager / > OSS / > > > NMS" > > > and "PCE-based Controller" as shown on the various figures in the > picture. We > > > haven't discussed this interface in the document, and perhaps we should= . > > > > > > If you look at Figure 6 (with the hierarchy of controllers) you might > observe that > > > the parent controller could be implemented to act as though it is > talking to an NE > > > (in the abstract node model) and that means that the southbound > interface of > > > the parent controller would be PCEP. That means (of course) that the > > > northbound interface of the child controller would also be PCEP. Then, > it might > > > seem obvious that we would want all PCE implementations to behave the > same > > > way and so that makes the northbound interface of the parent PCE > > > would/could/should/might also be PCEP. > > > > > > What do you think? > > > > > > Thanks, > > > Adrian > > > > > > _______________________________________________ > > > Teas mailing list > > > Teas@ietf.org > > > https://www.ietf.org/mailman/listinfo/teas > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > > > > > > > --001a113bff7a91747005339b95ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Adrian,

It might be easier to just say = =E2=80=9Crelatively minor changes=E2=80=9D rather than =E2=80=9Cno substant= ial changes=E2=80=9D. I think people in general have a good feel for what a= =E2=80=9Creiatively minor=E2=80=9D change to an existing protocol entails,= and again, this is not a standards track document, just informational, and= it=E2=80=99s just an expectation.

Just my two cen= ts.

Cheers,
Andy


On Tue, May 24= , 2016 at 6:11 AM, Adrian Farrel <adrian@olddog.co.uk> wro= te:

Thanks= Andy and Michael for pushing this forward while I was otherwise engaged.

=C2=A0

I can modify the paragraph in section 4 to something like...<= /u>

=C2= =A0

=C2=A0=C2=A0=C2=A0=C2=A0 <t>As such, there is an expectation= that no substantial changes to PCEP are required to support the =

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0concept of a PCE-based = controller.=C2=A0 The only work expected to be needed is small= extensions to carry

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 additional or specific information elements for the individual use cases.<= span>=C2=A0 Where possible, consistent

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 with the general principles of how protocols are = extended, any additions to the protocol should be made=

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 in a generic way such that they are open= to use in a range of applications.</t>

=C2=A0

But before posting this = I'd like to pick a little at Michael's point because if he is right= then some of this work may collapse. Of course, it may all depend on some = relative terms: "substantial" and "small".

=C2=A0=

What I = meant to imply in the document was that existing mechanisms (PCEP sessions = over TCP) and messages (such as PCInitiate) are likely to be adequate to ac= hieve all of the functions since the required protocol will need to be sess= ion-based and reliable, and since *some* message to push state is needed. I= t is also my opinion that the sort of state being pushed is:<= /span>

- to a network = element

- concerned with programming a forwarding instruction<= /span>

- related to re= serving forwarding resources

All of those things already exist to some exten= t in PCEP.

=C2=A0

Do I think new objects/TLVs will be needed? Yes, probably, = for some uses.

Do I think new values for some distinguishers will be neede= d? Yes, definitely.

=C2=A0

Would it help to go further in the proposed text b= y clarifying "substantial"?

=C2=A0

Thanks,

=

Adrian

=C2=A0

From: Scharf, Michael (Nok= ia - DE) [mailto:michael.scharf@nokia.com]
Sent: 23 May 2016 15:09
= To: Andrew G. Malis
Cc: adrian@olddog.co.uk; teas@ietf.org

Subject: RE: [Teas] A New I-D on PCE as a central controller=

=C2=A0

That wording is somewhat better. From my experience = with use cases discussed in this draft it would be a surprise if that expec= tation was true. But, of course, your mileage may vary.

=C2=A0

Michael

=C2=A0

=C2=A0=

From: Andrew G. Malis [mailto:agmalis@gmail.com] Sent: Monday, May 23, 2016 4:01 PM
To: Scharf, Michael (= Nokia - DE)
Cc: adrian@olddog.co.uk; teas@ietf.org
Subject: Re: [Teas] A New I-D on PCE a= s a central controller

=C2=A0

Michael,

=C2=A0

I agree that we don=E2=80=99= t yet positively know that the conclusions in section 4 are correct, but th= ere=E2=80=99s also no specific knowledge that they are incorrect. So I thin= k it would be fair to change the sentence "As such, no substantial cha= nges to PCEP are required to support the concept of a PCE-based controller.= =E2=80=9D to "As such, no substantial changes to PCEP are expected to = support the concept of a PCE-based controller.=E2=80=9D

=C2=A0

Chee= rs,

Andy

=C2=A0

On Mon, May 23, 2016 at 9:52 AM, Scharf, Michae= l (Nokia - DE) <michael.scharf@nokia.com> wrote:

=

Fair = point. But Section 4 should also be more explicit that the conclusion there= as hypothetical as the use cases Section 3.=

=C2=A0

This would not= fix the problem with Section 3.2.2 and Section 3.2.3 but at least make cle= ar that Section 4 is pure speculation only.<= /u>

=C2=A0

Michael<= span lang=3D"EN-US">

=C2=A0

=C2=A0

From: Andrew G. Malis [mailto:agmalis@gmail.com]
Sent: Monday,= May 23, 2016 3:43 PM

<= div>


To: Scharf,= Michael (Nokia - DE)
Cc: adrian@olddog.co.uk; teas@ietf.org
Subject: Re: [Teas] A New I-= D on PCE as a central controller

=

=C2=A0<= /span>

Michael,<= u>

=C2=A0=

The introduction to section 3 says: =E2=80=9CAs previously mentioned, thi= s section is intended to just make suggestions.=E2=80=9D. That sound like h= ypothetical to me.

=C2=A0

Cheers,

<= div>

Andy

=C2=A0

= =C2=A0

On Mon, May 23, 2016 at 9:37 AM, Scharf, Michael (Nokia - DE) <michael.scharf@no= kia.com> wrote:

Why doesn=E2=80=99t the docu= ment then mention that the use cases and conclusions on PCEP are hypothetic= al?

=C2=A0

Michael

=C2= =A0

=C2=A0

From: Andrew G. Mali= s [mailto:agmalis@gm= ail.com]
Sent: Monday, May 23, 2016 3:35 PM
To: Sc= harf, Michael (Nokia - DE)
Cc: adrian@olddog.co.uk; teas@ietf.org

Subject: Re: [Teas] A New I-D on PCE as a central controller

=C2=A0

= Michael,

=C2=A0

I think you=E2=80=99re expecting too= much from this draft. It=E2=80=99s meant to be a very high-level informati= onal document to introduce the concepts and a non-exhaustive list of possib= le applications and use cases. As with any such early document, there=E2=80= =99s some amount of speculative writing, and there=E2=80=99s no expectation= that all of the discussed applications or use cases will actually come to = fruition, and there may be others in the future that do end up being implem= ented. But the actual details of protocol changes and applications will be = the topics of other standards-track draft(s) to come.<= /p>

=C2=A0<= /u>

Cheers= ,

Andy

=C2=A0

=C2=A0

On Sun, May 22, 2016 at 5:34 PM, Schar= f, Michael (Nokia - DE) <michael.scharf@nokia.com> wrote:=

Hi Adrian,

=C2=A0

Many thanks for the tutorial. Since= RFC 7491 already acknowledges the role of a PCE, I see little value of a h= igh-level document that talks about PCEP as a general SBI for the topics me= ntioned in Section 3.2.2 and Section 3.2.3, if that document does not discu= ss more specifically the impact on PCEP, data models, etc.

=C2=A0

It should be obvious that in my point of view the wording in Sections= 3.2.2 and 3.2.3 is not clear. Just repeating the wording once again does n= ot address my question, since I have obviously read the document and since = I know the terminology (albeit I am not a native speaker). A generic flow c= hart not detailing for which of the messages PCEP would be used, and with w= hat content, also does not address my concern.<= u>

In any case, if the content of Section 3.2.2 and Section= 3.2.3 cannot be made more explicit, it is impossible for me to understand = whether the conclusion in Section 4 =E2=80=A6 =E2=80=9CAs such, no substant= ial changes to PCEP are required to support the concept of a PCE-based cont= roller. The only work needed will be small extensions to carry additional o= r specific information elements for the individual use cases.=E2=80=9D is c= orrect and how it is actually justified for the technical areas such as Sec= tion 3.2.2 and Section 3.2.3 .

=C2=A0

From my personal exper= ience this sort of entirely generic conclusion could perhaps be a bit of si= mplification, but this may depend on the actual use case. But in an I-D, I = believe such a generic conclusion needs backing by content and as far as I = understand for Section 3.2.2 and Section 3.2.3 this backing is lacking in t= he document right now.

=C2=A0=

Thanks

=C2=A0

= Michael

=C2=A0

=C2=A0<= /u>

From: Adrian Farrel [mailto:adrian@olddog.co.uk<= /a>]
Sent: Sunday, May 22, 2016 6:24 AM
To: Scharf, Mi= chael (Nokia - DE)
Cc: teas@ietf.org=


Subject: = RE: [Teas] A New I-D on PCE as a central controller

=C2=A0

Michael,

= =C2=A0

I don't think it= is complicated, but it is obviously not clear from the document, so thank = you for raising the concern.

<= p>=C2=A0

You say it doesn&#= 39;t matter which interface we're talking about, but it does. PCEP is a= protocol and protocols are used on interfaces.=

=C2=A0

Let's start with southbound of the PCE. We already use PCEP on this in= terface. We have always done. It is what PCEP was invented for. And recent = developments in Stateful PCE and PCE-Initiated LSPs have made PCEP (and thi= s interface) able to send control "commands" as well as respond t= o requests. Thus, PCEP is an SBI protocol for use with signaling systems.

=C2=A0<= u>

Now, we might make several observations...

=C2=A0

In many (most?) MPLS-TE networks, every router is ca= pable of being the head end of LSPs. That means that in a PCE-enabled MPLS-= TE network, every router is a PCEP speaker.<= /u>

=C2=A0

Add= itionally, we can observe that LSPs (or PWs) can be stitched together. The = stitching, if under the control of a PCE, requires a special instruction to= be sent to the stitching node.

=C2=A0

Furthermore, we= can understand that a single end-to-end LSP is actually the stitching of l= ots of single hop LSPs. That is really what a statically provisioned LSP is= .

=C2=A0

Finally, we can see a desire to send TE instr= uctions from a computation engine (e.g., PCE) to individual network nodes t= o program their forwarding. For example, in a Segment Routed network or for= static MPLS-TE LSPs.

=C2= =A0

=C2=A0

Put all of this together with the recogniti= on that all TE path management is fundamentally the same and can be perform= ed by the same engine, and that it does not make sense for such an engine t= o have to implement multiple SBI protocols, and you end up with this draft.=

=C2=A0

I don't think we are saying that this appr= oach is compulsory, but we are saying that it is possible. Other possibilit= ies exist including using NETCONF/YANG in place of PCEP, and enhancing BGP = in place of PCEP. Others have suggested XMPP. Frankly, if we were proposing= a new protocol it would be correct to tell us not to, and to persuade us t= hat one of the other protocols will do the job. But here we are with three = (or four) protocols that fit the bill: each currently covers some of the fu= nction space and each could easily be extended to cover the whole space. I&= #39;m not capable of saying how to decide which protocol does which functio= n, but I do see pressures of implementation and deployment that lead to thi= s draft.

=C2=A0

[Historic note: I was somewhat oppos= ed to adding PCE-Initiated LSP support to PCEP. I thought this bent the arc= hitecture further than was originally intended. But we went there in the PE= C WG and the I-D is now "complete". By adding support of PCE init= iation of LSPs, we naturally opened the path to this document. FWIW, this i= s not the first time that PCEP has been discussed as a more general SBI pro= tocol - RFC 7491 shows it in this context although does not discuss it much= (we should probably add a reference to ABNO in this document).]

=C2=A0

=C2=A0

N= ow, you say you are surprised that "the document focuses on using PCEP= e.g. for L3VPN service delivery." I think there is a significant diff= erence between *requesting* a service and *delivering* that service. The se= rvice request (as, for example, in L3SM) does not involve a PCE and is easi= ly achieved using a YANG model which, if the service request is on-line, ca= n be delivered using NETCONF. However, service delivery requires "orch= estration". Orchestration is the process of considering available netw= ork resources and selecting what will be provisioned to support the service= . A PCE is at least a key feature of orchestration, just as it is a key com= ponent of a network controller. <= /p>

=C2=A0

But the docume= nt does NOT focus on PCEP in quite the way you describe. In fact, the only = discussion is in 3.2.3 (just two paragraphs in the whole document) where th= e focus is on the use of a PCE-based central controller that can "cons= ider the whole network and all components of a service at once when plannin= g how to deliver the service." It then goes on to observe that PCEP ca= n be used "to manage the network resources and to install the necessar= y associations between those resources." <= u>

=C2=A0

= =C2=A0

If we included a mes= sage flow chart it would look something like...=

=C2=A0

Service Manager=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 PCE-based Controller=C2=A0=C2=A0=C2=A0=C2=A0 NEs

=C2=A0=C2=A0=C2=A0=C2=A0 Request service----= ----->

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Compute

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Provision ------>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <------------- Ac= k

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Update DBs=

=C2=A0=C2=A0=C2=A0=C2=A0 <-------------------Ack

=C2=A0

=

If that simple figur= e helps with the understanding of this or any other part of the document, w= e can surely add it.

=C2=A0

Cheers,

Adrian

=C2=A0<= /u>

> -----Original Message----= -

> From: Scharf, Michae= l (Nokia - DE) [mailto:michael.scharf@nokia.com]

> Sent: 20 May 2016 19:07

> <= span lang=3D"EN-US">To: adrian@olddog.co.uk; teas@ietf.org

> Subject: RE: [Teas] A New I-D on PCE as a central controller

>

> = As I said, I specifically wonder about Section 3.2.3 "Service Delivery= ", which states

> (= omitting some parts that are not relevant here):

>

> "Various network services may be offered over a network. These i= nclude

> protection serv= ices [...] Virtual Private Network (VPN) service (such as Layer 3

> VPNs [RFC4364] or Ethernet VPNs= [RFC7432]), or Pseudowires [RFC3985]. [...]=C2=A0 A

> PCE-based central control can consider the w= hole network and all components of

> a service at once when planning how to deliver the service. It= can then use PCEP

> to = manage the network resources and to install the necessary associations

> between those resources.&q= uot;

>

> This wording on use of PCEP confuses m= e, no matter what interface we talk

> about. I would have assumed that YANG-based protocols such as=

> NETCONF/RESTCONF coul= d be useful in this context, and I am a bit surprised that

> the document focuses on using PCEP e.g= . for L3VPN service delivery. By the way,

> I also wonder how PCEP fits into the discussion on QoS = classification in Section

&= gt; 3.2.2.

>

> I wonder if the authors could a= dd to Section 3.2.2 and Section 3.2.3 e.g. a=

> message sequence chart that illustrates how what is = discussed in those sections

> relates to PCEP?

>=

> Michael

>

>

> <= span lang=3D"EN-US">

> -----Original Message-= ----

> From: Teas [mailto:teas-bounces@i= etf.org] On Behalf Of EXT Adrian Farrel<= /u>

> Sent: Friday, May 13, 2016 6:54 PM

> To: Scharf, Michael (Nokia - DE); teas@ietf.org

> Subject: Re: [Teas] A New I-D on P= CE as a central controller

= >

> Hello again, Mic= hael, it seems to be my day for replying to your emails.

>

> > When reading about uses cases such as L3VPN service deli= very in

> > "Sec= tion

> 3.2.3",

> > what is the author= 9;s view on the line of demarcation between NETCONF=

> > and PCEP?=

>

>= ; Well, I wonder which interface you're talking about.

> The ones that out in here are:

> - the interface between custo= mer and operator

> - the= interface between "service orchestrator" and "network orche= strator"

>

> The former of these is like t= he interface used in L3SM. As co-chair of L3SM, you=

> might not be surprised to hear that my view i= s that NETCONF is a fine solution -

> well, the use of a YANG data model, in any case.

>

> The latter is the interface between "Orchestrator = / Service Manager / OSS /

&= gt; NMS"

> and &quo= t;PCE-based Controller" as shown on the various figures in the picture= . We

> haven't discu= ssed this interface in the document, and perhaps we should.

>

> If you look at Figure 6 (with the hierarchy of controllers= ) you might observe that

&g= t; the parent controller could be implemented to act as though it is talkin= g to an NE

> (in the abs= tract node model) and that means that the southbound interface of

> the parent controller would be = PCEP. That means (of course) that the

> northbound interface of the child controller would also be = PCEP. Then, it might

> s= eem obvious that we would want all PCE implementations to behave the same

> way and so that makes t= he northbound interface of the parent PCE

> would/could/should/might also be PCEP.

>

> What do you think?

>

> Thanks,<= span lang=3D"EN-US">

> Adrian

>

> _______________________________________________

> Teas mailing list

> Teas@ietf.org=

> https://www.ietf.org/mailman/listinfo/teas


____________= ___________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org= /mailman/listinfo/teas

=C2=A0

=

=C2=A0=

=C2=A0


--001a113bff7a91747005339b95ae-- From nobody Tue May 24 14:37:26 2016 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 A13E712D57D for ; Tue, 24 May 2016 14:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGUJRoHJT3iB for ; Tue, 24 May 2016 14:37:22 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4346A12B056 for ; Tue, 24 May 2016 14:37:22 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id u4OLbKp4021955 for ; Tue, 24 May 2016 22:37:20 +0100 Received: from 950129200 ([79.141.128.249]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id u4OLbJQv021944 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 24 May 2016 22:37:19 +0100 From: "Adrian Farrel" To: References: <20160524213154.14117.6196.idtracker@ietfa.amsl.com> In-Reply-To: <20160524213154.14117.6196.idtracker@ietfa.amsl.com> Date: Tue, 24 May 2016 22:37:17 +0100 Message-ID: <050101d1b604$725061d0$56f12570$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQId9GMF5n06zPoxW8FUY6OUtMoRR58wHsbA Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22344.003 X-TM-AS-Result: No--20.043-10.0-31-10 X-imss-scan-details: No--20.043-10.0-31-10 X-TMASE-MatchedRID: rqmDq8+jU9OrmmW6xY+ZmPSG/+sPtZVkwx0jRRxcQfMn+p552csI1f8/ wVGTg2t19gg/IUvZeVKXYp1n4P1o0MkwYM+oZdHX5gCHftmwEMK3dp6DuD+6wG47M5sxfdoIYV4 QM7iNzW73hZIQK2TvRYQSjqSszbEG/jsbtWBGy0yzI1v7J4hECsTtVLsmq3vpZqT7LuN3BFFxQ9 CNI5RA3ZCboGiMT9bPLlKENBVH3JOPnoiNOctH6UK9qlwiTElfodwXyYUrWAVjyv+d0Z0OxfWnL 2FmW8ATlTrfppylHpAsFqxeblbzZGlaYefQTGcyUWDKbJeCAy0cQnDpQ6FX09dMDzSLr8ovPJ05 UREtjOWOr9X/y8WA5bgMQ3J1BYG2qe71qacBlWOOjIrMSa2sR3dPyDB89Hr5JxXJwKAKea9J5zF oTDP8/S33SVoDBGyZsanRvDcLto2aTrLrmn0xGy0x8J2DopENfS0Ip2eEHnzUHQeTVDUrIqHkM5 YY92pZjaPj0W1qn0SQZS2ujCtcuA== Archived-At: Subject: [Teas] FW: New Version Notification for draft-zhao-teas-pce-control-function-01.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk 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, 24 May 2016 21:37:24 -0000 Hello again TEAS, After some discussions on and off the list, here is a new revision. The changes are small: - spelling - add a note to 3.1.2 to observe that a PCE-based controller may take=20 responsibility for managing the partition of an MPLS label space - clarify the expectations of protocol change in section 4 Please continue to discuss. Thanks, Adrian > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: 24 May 2016 22:32 > To: Zhenbin Li; Adrian Farrel; Robin Li; Quintin Zhao; Chao Zhou > Subject: New Version Notification for = draft-zhao-teas-pce-control-function-01.txt >=20 >=20 > A new version of I-D, draft-zhao-teas-pce-control-function-01.txt > has been successfully submitted by Adrian Farrel and posted to the > IETF repository. >=20 > Name: draft-zhao-teas-pce-control-function > Revision: 01 > Title: An Architecture for Use of PCE and PCEP in a Network with > Central Control > Document date: 2016-05-24 > Group: Individual Submission > Pages: 21 > URL: = https://www.ietf.org/internet-drafts/draft-zhao-teas-pce-control- > function-01.txt > Status: = https://datatracker.ietf.org/doc/draft-zhao-teas-pce-control- > function/ > Htmlized: = https://tools.ietf.org/html/draft-zhao-teas-pce-control-function-01 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-zhao-teas-pce-control- > function-01 >=20 > Abstract: > The Path Computation Element (PCE) has become established as a core > component of Software Defined Networking (SDN) systems. It can > compute optimal paths for traffic across a network for any = definition > of "optimal" and can also monitor changes in resource availability > and traffic demands to update the paths. >=20 > Conventionally, the PCE has been used to derive paths for MPLS = Label > Switched Paths (LSPs). These paths are supplied using the Path > Computation Element Communication Protocol (PCEP) to the head end = of > the LSP for signaling in the MPLS network. >=20 > SDN has a far broader applicability than just signaled MPLS traffic > engineered networks, and the PCE may be used to determine paths in = a > wide range of use cases including static LSPs, segment routing, > service function chaining (SFC), and indeed any form of routed or > switched network. It is, therefore reasonable to consider PCEP as = a > general southbound control protocol for use in these environments = to > allow the PCE to be fully enabled as a central controller. >=20 > This document briefly introduces the architecture for PCE as a > central controller, examines the motivations and applicability for > PCEP as a southbound interface, and introduces the implications for > the protocol. This document does not describe the use cases in > detail and does not define protocol extensions: that work is left = for > other documents. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat From nobody Wed May 25 11:12:56 2016 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 551FB12D130; Wed, 25 May 2016 11:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8EmvOS1QgQt; Wed, 25 May 2016 11:12:52 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1840C12D096; Wed, 25 May 2016 11:12:52 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id f66so75599170vkh.2; Wed, 25 May 2016 11:12:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=QXk79LvohAW3fJJStJcyzid3eJacCz0X22/lG74nulU=; b=JZKM/sXP61gXwLt6hvyGbMNSXFt3JazVjf1e53CQmB4zGcon5TPqgAgKQ1kXqpg29u m6QQusPkxYwvNSV1i6lNCtgZNDWsVtDO3inS57x1lTxBjakp6Uabd4yW9DpTUnUql74f Rixv01vYqekUqcje3opppjfbDmf4C9tlWC+gMU7isaed714IOXhKCpCJaAhf8d+z/d/0 fDJzwc+dNiEwosvNaWPHHdTBsvrQTSUqYJw4nBJDYDrnXAiw4zIbrxvobcseWxcRxGpZ HyIBUZ7uMOT1aFOkZvF9y+o7wui8CnmfmzyaU9p1uA2j9VGksWDpQbt/d1dBc0LfybKP 1XYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=QXk79LvohAW3fJJStJcyzid3eJacCz0X22/lG74nulU=; b=MJIULZcDdqtdYY4j5JZ+qjsiKu2hUxTX/Le5OhPiaRUF7sqTiE/mGeaYjk1SNJFtbC 184DGKCdKcrEGXPN1VKvKEIFrVkXu9aa1WvyelbX2PdMtDY8pDsNHySy+huYwQ2dE+Jo +2Hj0tjANsLUU8kTVbyCI3/ZLjWEZAtuS8kM8CT3QMvkN261dbaX8V7+RCjR17nbf6Db yJcZMPMR58vZyQ82gyXO5TwuMPf0UCcO/YPEXMyuDNEaGqd1OziAh+w5Bmi8PoQPQim3 /0eKzeuNLbhe12bwSDWO48gor0eR/NMImICJP1dbZ1x7Uuh8PkgMoum4bojVYlXSuSsS XGRw== X-Gm-Message-State: ALyK8tLyNDmM8g3ahpdUf3NZ5zALIJP+cdaZIcXbfJ0mJlhctP1+8ygD7rTaz9iLFB7Too0nkow42czD26IWKg== MIME-Version: 1.0 X-Received: by 10.159.55.196 with SMTP id q62mr2835071uaq.8.1464199971034; Wed, 25 May 2016 11:12:51 -0700 (PDT) Received: by 10.31.67.141 with HTTP; Wed, 25 May 2016 11:12:50 -0700 (PDT) In-Reply-To: References: <40746B2300A8FC4AB04EE722A593182BAC1B121C@ONWVEXCHMB04.ciena.com> Date: Wed, 25 May 2016 14:12:50 -0400 Message-ID: From: Vishnu Pavan Beeram To: "teas@ietf.org" , draft-ietf-teas-rsvp-te-srlg-collect@ietf.org Content-Type: multipart/alternative; boundary=94eb2c04cade2762630533ae9f0c Archived-At: Subject: Re: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-srlg-collect-05 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 25 May 2016 18:12:54 -0000 --94eb2c04cade2762630533ae9f0c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Authors, Hi! I'm in the process of updating the Shepherd's write-up for this document. I'm expecting you to submit another rev for this draft (addressing the nits that were raised during the LC). I found a few other nits (pasted below) during my review. Please see if you can take care of these as well in the next rev. I'll resubmit the publication request as soon as the new version shows up. Regards, -Pavan ** Section 1. - s/This document provides a mechanism to collect the SRLGs used by a LSP,/This document provides a signaling mechanism to collect the SRLGs used by a LSP, [Comment - signaling mechanism as opposed to routing mechanism; The introduction section doesn=E2=80=99t explicitly say (maybe it should) that = this mechanism is useful in scenarios where the SRLG info cannot be obtained via IGP-TE (via routing)] - s/Note that specification of the the use of the collected SRLGs is outside the scope of this document./Note that specification of the use of the collected SRLGs is outside the scope of this document. [Comment - You may even consider removing the above line altogether (given that the document does discuss an applicability example in 1.1)] Section 3.1: - Fix indentation for the whole section Section 3.2: - Fix indentation for the whole section. - s/SRLG information is for each hop is added to the Path RRO during Path message processing./SRLG information is added by each hop to the Path RRO during Path message processing. - Consider removing the following line [Comment - it doesn=E2=80=99t seem t= o be bringing in any additional value in this section]: The endpoints of the LSP can make use of the collected SRLG information, for example, for routing, sharing and TE link configuration purposes. Section 3.3: - Fix indentation for the whole section. - s/This means that that the signaling procedure needs to be capable of updating the new SRLG information./This means that the signaling procedure needs to be capable of updating the new SRLG information. Section 3.4: - Fix indentation for the whole section. Section 4.1: - Fix indentation for the first paragraph. Section 6.1 - Policy Configuration: - Fix the bullets; All bullet points =E2=80=9Co=E2=80=9D are squeezed toget= her in one paragraph. Section 8.2 ROUTE_RECORD Object - Fix the indentation of the table (align it with the table in 8.1) Section 8.3 Policy Control Failure Error subcodes - Fix the indentation of the table (align it with the table in 8.1) On Fri, May 13, 2016 at 8:15 PM, Vishnu Pavan Beeram wrote: > The WG LC for this document is now closed. > > Matt (and other authors), > Please go ahead and publish a new revision addressing the minor comments > received during the LC. > > Regards, > -Pavan (and Lou) > > On Fri, May 13, 2016 at 6:07 PM, Shah, Himanshu wrote: > >> *Sorry for the late reply.. (On PTO..)* >> >> >> >> *While adding of =E2=80=9Ccompletion flag=E2=80=9D (or similar to =E2=80= =9Cpartial bit=E2=80=9D used in >> BGP) would have been a nice feature* >> >> *to have, the SRLG collect draft by itself is an important feature to >> have, so..* >> >> >> >> *I support progressing the document to publication.* >> >> >> >> *Thanks,* >> >> *Himanshu* >> >> >> >> *From:* Teas [mailto:teas-bounces@ietf.org] *On Behalf Of *Vishnu Pavan >> Beeram >> *Sent:* Thursday, April 28, 2016 4:42 PM >> *To:* teas@ietf.org >> *Subject:* [Teas] WG Last Call on draft-ietf-teas-rsvp-te-srlg-collect-0= 5 >> >> >> >> All, >> >> This starts a two week working group last call on >> draft-ietf-teas-rsvp-te-srlg-collect-05. >> >> The working group last call ends on Thursday, May 12th. Please >> send your comments to the TEAS mailing list. >> >> As is always the case, positive comments, e.g., "I've reviewed this >> document and believe it is ready for publication", are welcome! >> This is useful and important, even from authors. >> >> Note, IPR has been disclosed on this draft. >> >> >> Thanks, >> Pavan (and Lou) >> > > --94eb2c04cade2762630533ae9f0c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Authors, Hi!

I'm in the pr= ocess of updating the Shepherd's write-up for this document. I'm ex= pecting you to submit another rev for this draft (addressing the nits that = were raised during the LC). I found a few other nits (pasted below) during = my review. Please see if you can take care of these as well in the next rev= .

I'll resubmit the publication request as soon as th= e new version shows up.

Regards,
-Pavan

**
Section 1.

- s/This document provide= s a mechanism to collect the SRLGs used by a LSP,/This document provides a = signaling mechanism to collect the SRLGs used by a LSP,
[Comment - signa= ling mechanism as opposed to routing mechanism; The introduction section do= esn=E2=80=99t explicitly say (maybe it should) that this mechanism is usefu= l in scenarios where the SRLG info cannot be obtained via IGP-TE (via routi= ng)]

- s/Note that specification of the the use of the collected SRL= Gs is outside the scope of this document./Note that specification of the us= e of the collected SRLGs is outside the scope of this document.
[Comment= - You may even consider removing the above line altogether (given that the= document does discuss an applicability example in 1.1)]


Section= 3.1:

- Fix indentation for the whole section


Section 3.2= :

- Fix indentation for the whole section.

- s/SRLG informati= on is for each hop is added to the Path RRO during Path message processing.= /SRLG information is added by each hop to the Path RRO during Path message = processing.

- Consider removing the following line [Comment - it doe= sn=E2=80=99t seem to be bringing in any additional value in this section]:<= br>The endpoints of the LSP can make use of the collected SRLG information,= for example, for routing, sharing and TE link configuration purposes.
<= br>
Section 3.3:

- Fix indentation for the whole section.

= - s/This means that that the signaling procedure needs to be capable of upd= ating the new SRLG information./This means that the signaling procedure nee= ds to be capable of updating the new SRLG information.


Section 3= .4:

- Fix indentation for the whole section.


Section 4.1:=

- Fix indentation for the first paragraph.


Section 6.1 -= Policy Configuration:

- Fix the bullets; All bullet points =E2=80= =9Co=E2=80=9D are squeezed together in one paragraph.


Section 8.= 2 ROUTE_RECORD Object

- Fix the indentation of the table (align it w= ith the table in 8.1)


Section 8.3 Policy Control Failure Error s= ubcodes

- Fix the indentation of the table (align it with the table = in 8.1)


 --94eb2c04cade2762630533ae9f0c-- From nobody Thu May 26 07:48:20 2016 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 355DB12D715 for ; Thu, 26 May 2016 07:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.811 X-Spam-Level: X-Spam-Status: No, score=-1.811 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=kuatrotechnology.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 VZLZdNlV6A_6 for ; Thu, 26 May 2016 07:48:15 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0047.outbound.protection.outlook.com [104.47.2.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1485B12D700 for ; Thu, 26 May 2016 07:48:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kuatrotechnology.onmicrosoft.com; s=selector1-kuatrotech-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vmiouv7Xsp0LG2Xxp4uRCw/aAk50kc0LPBfX84CdDTQ=; b=S4CAV+g+/bLDpWRWuDXnO9kL2zA4f6bTm7ekOQ9KUA7yC8YsbFIu5jeh26OkDZErBEfCq/N5v+eJWnwm1mKZlpJg/ls4K7Ihy/jy8FdwkUuqxs4Ros6hUo+04TmVMrCUM8N+G6/ukEZW5RwDgESiVPsL9roR4Nd0ZbbNon4PkOo= Received: from DBXPR06MB623.eurprd06.prod.outlook.com (10.255.71.170) by DBXPR06MB623.eurprd06.prod.outlook.com (10.255.71.170) with Microsoft SMTP Server (TLS) id 15.1.497.12; Thu, 26 May 2016 14:48:05 +0000 Received: from DBXPR06MB623.eurprd06.prod.outlook.com ([169.254.1.6]) by DBXPR06MB623.eurprd06.prod.outlook.com ([169.254.1.6]) with mapi id 15.01.0497.022; Thu, 26 May 2016 14:48:05 +0000 From: Xufeng Liu To: Vishnu Pavan Beeram , Igor Bryskin , Oscar Gonzalez De Dios , Tarek Saad , "Himanshu Shah" , Lou Berger , "BRUNGARD, DEBORAH A (ATTLABS)" , Susan Hares , "Zafar Ali (zali)" , "Khaddam, Mazen (CCI-Atlanta)" , Tony Le , "BELOTTI, SERGIO (SERGIO)" , "Beller, Dieter (Dieter)" , Rajan Rao , "Zhangxian (Xian)" , "xufeng.liu.ietf@gmail.com" , "Belotti, Sergio (Nokia - IT)" , Anurag Sharma Thread-Topic: IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23 Thread-Index: AdG3XGalY3SICAUtQf2LvT1Umc0SGw== Date: Thu, 26 May 2016 14:48:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: juniper.net; dkim=none (message not signed) header.d=none; juniper.net; dmarc=none action=none header.from=kuatrotech.com; x-originating-ip: [98.191.72.170] x-ms-office365-filtering-correlation-id: 841e9b16-e0b7-4362-f25a-08d38574bf2f x-microsoft-exchange-diagnostics: 1; DBXPR06MB623; 5:Zfrlbxg7khPkgVxNeLLYHuSBnKUNx6cUrkFTI8kzny03fJRoMaM3qpEZeuG535DrMm4CLT+Dvz0NgSeL0iycjIwJfpuqu3TfhFxkPbDi9uSxxNJ904MEy5bd6Ox34FJiAGkIKo4cZaBfxpiHIH4YoQ==; 24:tItkXoitAGKIBq1BUpx+3pmRxXzZDcjkB9PAWpJDJsBigejsoqJfBZS5xwMkJzBom8XAvehamEJ5RFtuV4emdX2pQsjYounNRNvEPKD4vAk=; 7:dCbR9ucMx8NQEeN4QEWlyJIhbSDakkaYo6PFaJhriMe/YSjNFEd0/ORCkIbJAHjwcB9EV35VWp40cuzossAHTNCbYOMM5RnGxkLxTMKzmPU5GU8HGm0wJV3f600yTDPjFvQrskPKAinSpSbVUbMuO0LJjvl7fYiVKqDVhcLws9cc0tFxSa6fpUwxjorLC0ZG x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR06MB623; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040130)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041072)(6043046); SRVR:DBXPR06MB623; BCL:0; PCL:0; RULEID:; SRVR:DBXPR06MB623; x-forefront-prvs: 0954EE4910 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(5423002)(8666003)(92566002)(1220700001)(3280700002)(87936001)(5001770100001)(5003600100002)(85806002)(229853001)(54356999)(5008740100001)(76576001)(10400500002)(2900100001)(122556002)(81166006)(86362001)(3660700001)(2501003)(102836003)(6116002)(4326007)(790700001)(19625215002)(33656002)(2906002)(3846002)(8936002)(230783001)(74316001)(586003)(16236675004)(50986999)(19300405004)(19580395003)(8676002)(189998001)(11100500001)(66066001)(15975445007)(5004730100002)(5002640100001)(9686002)(7059030)(921003)(1121003); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR06MB623; H:DBXPR06MB623.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DBXPR06MB623990C55CF493EFF51421EB1410DBXPR06MB623eurprd_" MIME-Version: 1.0 X-OriginatorOrg: kuatrotech.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2016 14:48:05.7946 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 99314f4e-50ab-4d4e-a9c6-b21b0c887384 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR06MB623 Archived-At: Cc: "teas@ietf.org" Subject: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 26 May 2016 14:48:19 -0000 --_000_DBXPR06MB623990C55CF493EFF51421EB1410DBXPR06MB623eurprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Participants: Igor, Xufeng, Pavan, Dieter, Sergio, Himanshu - Information sources > Discussed two use cases related to information sources: 1) Provider applies policies to pick the most preferred. 2) Provider does not apply policies and the decision is done by custome= r. > The model currently supports 1) well, but is not clear on 2). > Agreed to clarify the model by: 1) Change "alt-information-sources" to "information-sources" to include all sources, including the selected one. 2) For use case 1), the applied attribute has the selected value, and "information-sources" list all available sources. For use case 2), the applied attribute does not have value, and "information-sources" list all available sources. - Connectivity Matrix > Discussed the comment from Cyril "to add a Label (Following RFC7579) restrictions". > Participants agreed that such constraint information is useful. > Participants agreed that such constraint information is generic enough to be used in various layers and use cases, including optical OTN, and abstract network topologies. > Participants agreed to send the suggestion TEAS WG to add such information to te-topology model. > The potential model change can be: For each connectivity-matrix entry, add: list of labels list types o inclusive-list o exclusive-list o inclusive-range o exclusive-range For each label o exclusivity (true/false) Working members: please provide any comments. Thanks, - Xufeng Note: Please drop me an email if you need an invite for joining the weekly = call. PS. Meeting on May 30 will be canceled for US holiday. --_000_DBXPR06MB623990C55CF493EFF51421EB1410DBXPR06MB623eurprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Participants:

Igor, Xufeng, Pavan, Dieter, Sergio, Himanshu

 

- Information sources

  > Discussed two use cases related to infor= mation sources:

    1) Provider applies policies to p= ick the most preferred.

    2) Provider does not apply polici= es and the decision is done by customer.

  > The model currently supports 1) well, bu= t is not clear on 2).

  > Agreed to clarify the model by:

    1) Change "alt-information-s= ources" to "information-sources" to

       include all sou= rces, including the selected one.

    2) For use case 1), the applied a= ttribute has the selected value, and

       "informati= on-sources" list all available sources.

       For use case 2)= , the applied attribute does not have value, and

       "info= rmation-sources" list all available sources.

 

- Connectivity Matrix

  > Discussed the comment from Cyril "t= o add a Label (Following

    RFC7579) restrictions".=

  > Participants agreed that such constraint= information is useful.

  > Participants agreed that such constraint= information is generic

    enough to be used in various laye= rs and use cases, including optical

    OTN, and abstract network topolog= ies.

  > Participants agreed to send the suggesti= on TEAS WG to add such

    information to te-topology model.=

  > The potential model change can be:<= o:p>

    For each connectivity-matrix entr= y, add:

      list of labels

        list type= s

         &nb= sp;     o inclusive-list

         &nb= sp;     o exclusive-list

         &nb= sp;     o inclusive-range

         &nb= sp;     o exclusive-range

         &nb= sp;     For each label

         &nb= sp;     o exclusivity (true/false)

Working members: please provide any comments.

 

Thanks,

 

- Xufeng

 

Note: Please drop me an email if you need an invite = for joining the weekly call.

 

PS. Meeting on May 30 will be canceled for US holida= y.

--_000_DBXPR06MB623990C55CF493EFF51421EB1410DBXPR06MB623eurprd_-- From nobody Thu May 26 08:31:36 2016 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 A850F12D724 for ; Thu, 26 May 2016 08:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.644 X-Spam-Level: X-Spam-Status: No, score=-5.644 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 59xtdplutRLG for ; Thu, 26 May 2016 08:31:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DA6212D722 for ; Thu, 26 May 2016 08:31:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CPQ59584; Thu, 26 May 2016 15:31:18 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 26 May 2016 16:31:16 +0100 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Thu, 26 May 2016 08:31:08 -0700 From: Leeyoung To: Xufeng Liu , Vishnu Pavan Beeram , Igor Bryskin , "Oscar Gonzalez De Dios" , Tarek Saad , Himanshu Shah , Lou Berger , "BRUNGARD, DEBORAH A (ATTLABS)" , "Susan Hares" , "Zafar Ali (zali)" , "Khaddam, Mazen (CCI-Atlanta)" , Tony Le , "BELOTTI, SERGIO (SERGIO)" , "Beller, Dieter (Dieter)" , Rajan Rao , "Zhangxian (Xian)" , "xufeng.liu.ietf@gmail.com" , "Belotti, Sergio (Nokia - IT)" , Anurag Sharma Thread-Topic: IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23 Thread-Index: AdG3XGalY3SICAUtQf2LvT1Umc0SGwABG4MA Date: Thu, 26 May 2016 15:31:08 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172A88ECF3@dfweml501-mbx> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.218.137.191] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E172A88ECF3dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.574716C6.0150, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d1c10d952ca2cdf6985ba037fa1f913d Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 26 May 2016 15:31:33 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E172A88ECF3dfweml501mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Xufeng, Thanks for this update. Your notes are always very helpful to understand th= e latest progress of this draft. I have a few questions on the potentially adding model for labels for the c= onnectivity matrix. 1. You said: For each label o exclusivity (true/false) Do you mean this bitmap? 2. Are you aware of label restrictions applied for the connectivity ma= trix other than WSON? If so, then this model addition makes sense; if not, = then we can add the label model for the connectivity matrix in the WSON YAN= G model. If the extent to which label model addition is not really a major = constraint in the switching technologies other than WSON, it would be worth= while to evaluate if we should do label restriction model in a generic way = (per this draft) or do it in WSON specific way? I am not aware of any labe= l restriction model for the connectivity matrix for GMPLS other than WSON. 3. If we were to extend the label model for the connectivity matrix, = I would think we also need to have label restriction model for TTP LLCL as = well. What do you think? Thanks. Young From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Xufeng Liu Sent: Thursday, May 26, 2016 9:48 AM To: Vishnu Pavan Beeram; Igor Bryskin; Oscar Gonzalez De Dios; Tarek Saad; = Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan Hares; Zafa= r Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, SERGIO (SERGI= O); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.liu.ietf@g= mail.com; Belotti, Sergio (Nokia - IT); Anurag Sharma Cc: teas@ietf.org Subject: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016-05-= 23 Participants: Igor, Xufeng, Pavan, Dieter, Sergio, Himanshu - Information sources > Discussed two use cases related to information sources: 1) Provider applies policies to pick the most preferred. 2) Provider does not apply policies and the decision is done by custome= r. > The model currently supports 1) well, but is not clear on 2). > Agreed to clarify the model by: 1) Change "alt-information-sources" to "information-sources" to include all sources, including the selected one. 2) For use case 1), the applied attribute has the selected value, and "information-sources" list all available sources. For use case 2), the applied attribute does not have value, and "information-sources" list all available sources. - Connectivity Matrix > Discussed the comment from Cyril "to add a Label (Following RFC7579) restrictions". > Participants agreed that such constraint information is useful. > Participants agreed that such constraint information is generic enough to be used in various layers and use cases, including optical OTN, and abstract network topologies. > Participants agreed to send the suggestion TEAS WG to add such information to te-topology model. > The potential model change can be: For each connectivity-matrix entry, add: list of labels list types o inclusive-list o exclusive-list o inclusive-range o exclusive-range For each label o exclusivity (true/false) Working members: please provide any comments. Thanks, - Xufeng Note: Please drop me an email if you need an invite for joining the weekly = call. PS. Meeting on May 30 will be canceled for US holiday. --_000_7AEB3D6833318045B4AE71C2C87E8E172A88ECF3dfweml501mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Xufeng,<= /span>

 

Thanks for this update= . Your notes are always very helpful to understand the latest progress of t= his draft.

 

I have a few questions= on the potentially adding model for labels for the connectivity matrix.

 

1.&n= bsp;     You said:=

 

         &nb= sp;     For each label

         &nb= sp;     o exclusivity (true/false)

 

Do you mean this bitmap?

 

2.&n= bsp;     Are you aware = of label restrictions applied for the connectivity matrix other than WSON? = If so, then this model addition makes sense; if not, then we can add the la= bel model for the connectivity matrix in the WSON YANG model. If the extent to which label model addition is not= really a major constraint in the switching technologies other than WSON, i= t would be worthwhile to evaluate if we should do label restriction model i= n a generic way (per this draft) or do it in WSON specific way?  I am not aware of any label restricti= on model for the connectivity matrix for GMPLS other than WSON.

 

3.&n= bsp;      If we we= re to extend the label model for the connectivity matrix, I would think we = also need to have label restriction model for TTP LLCL as well. What do you= think?

 

Thanks.

Young

 

 

From: Teas [ma= ilto:teas-bounces@ietf.org] On Behalf Of Xufeng Liu
Sent: Thursday, May 26, 2016 9:48 AM
To: Vishnu Pavan Beeram; Igor Bryskin; Oscar Gonzalez De Dios; Tarek= Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan Hare= s; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, SERGIO= (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.liu.ietf@gmail.com; Belotti, Sergio (N= okia - IT); Anurag Sharma
Cc: teas@ietf.org
Subject: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2= 016-05-23

 

Participants:

Igor, Xufeng, Pavan, Dieter, Sergio, Himanshu

 

- Information sources

  > Discussed two use cases related to infor= mation sources:

    1) Provider applies policies to p= ick the most preferred.

    2) Provider does not apply polici= es and the decision is done by customer.

  > The model currently supports 1) well, bu= t is not clear on 2).

  > Agreed to clarify the model by:

    1) Change "alt-information-s= ources" to "information-sources" to

       include all sou= rces, including the selected one.

    2) For use case 1), the applied a= ttribute has the selected value, and

       "informati= on-sources" list all available sources.

       For use case 2)= , the applied attribute does not have value, and

       "info= rmation-sources" list all available sources.

 

- Connectivity Matrix

  > Discussed the comment from Cyril "t= o add a Label (Following

    RFC7579) restrictions".=

  > Participants agreed that such constraint= information is useful.

  > Participants agreed that such constraint= information is generic

    enough to be used in various laye= rs and use cases, including optical

    OTN, and abstract network topolog= ies.

  > Participants agreed to send the suggesti= on TEAS WG to add such

    information to te-topology model.=

  > The potential model change can be:<= o:p>

    For each connectivity-matrix entr= y, add:

      list of labels

        list type= s

         &nb= sp;     o inclusive-list

         &nb= sp;     o exclusive-list

         &nb= sp;     o inclusive-range

         &nb= sp;     o exclusive-range

         &nb= sp;     For each label

         &nb= sp;     o exclusivity (true/false)

 

Working members: please provide any comments.

 

Thanks,

 

- Xufeng

 

Note: Please drop me an email if you need an invite = for joining the weekly call.

 

PS. Meeting on May 30 will be canceled for US holida= y.

--_000_7AEB3D6833318045B4AE71C2C87E8E172A88ECF3dfweml501mbx_-- From nobody Thu May 26 09:44:48 2016 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 A923612D654 for ; Thu, 26 May 2016 09:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 9-QEtxT1iRgi for ; Thu, 26 May 2016 09:44:43 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9998D12D0A7 for ; Thu, 26 May 2016 09:44:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CPQ67777; Thu, 26 May 2016 16:44:40 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 26 May 2016 17:44:36 +0100 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Thu, 26 May 2016 09:44:24 -0700 From: Igor Bryskin To: Leeyoung , Xufeng Liu , "Vishnu Pavan Beeram" , Oscar Gonzalez De Dios , Tarek Saad , Himanshu Shah , Lou Berger , "BRUNGARD, DEBORAH A (ATTLABS)" , Susan Hares , "Zafar Ali (zali)" , "Khaddam, Mazen (CCI-Atlanta)" , Tony Le , "BELOTTI, SERGIO (SERGIO)" , "Beller, Dieter (Dieter)" , Rajan Rao , "Zhangxian (Xian)" , "xufeng.liu.ietf@gmail.com" , "Belotti, Sergio (Nokia - IT)" , Anurag Sharma Thread-Topic: IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23 Thread-Index: AdG3XGalY3SICAUtQf2LvT1Umc0SGwABG4MAAALVFfA= Date: Thu, 26 May 2016 16:44:24 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908EDD175@dfweml501-mbx> References: <7AEB3D6833318045B4AE71C2C87E8E172A88ECF3@dfweml501-mbx> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172A88ECF3@dfweml501-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.253.100] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908EDD175dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.574727F8.0254, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d1c10d952ca2cdf6985ba037fa1f913d Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 26 May 2016 16:44:47 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908EDD175dfweml501mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Young, Please, see in-line, Igor From: Leeyoung Sent: Thursday, May 26, 2016 11:31 AM To: Xufeng Liu; Vishnu Pavan Beeram; Igor Bryskin; Oscar Gonzalez De Dios; = Tarek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan= Hares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, S= ERGIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufen= g.liu.ietf@gmail.com; Belotti, Sergio (Nokia - IT); Anurag Sharma Cc: teas@ietf.org Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23 Hi Xufeng, Thanks for this update. Your notes are always very helpful to understand th= e latest progress of this draft. I have a few questions on the potentially adding model for labels for the c= onnectivity matrix. 1. You said: For each label o exclusivity (true/false) Do you mean this bitmap? 2. Are you aware of label restrictions applied for the connectivity ma= trix other than WSON? If so, then this model addition makes sense; if not, = then we can add the label model for the connectivity matrix in the WSON YAN= G model. If the extent to which label model addition is not really a major = constraint in the switching technologies other than WSON, it would be worth= while to evaluate if we should do label restriction model in a generic way = (per this draft) or do it in WSON specific way? I am not aware of any labe= l restriction model for the connectivity matrix for GMPLS other than WSON. IB>> We had this discussion many time already. There are physical OTN switc= hes that have constraints on the ODUk type level. For example, a switch can= switch ODU2 from link 1 to link2, but ODU2e from link 1 to only link3. Thi= s is especially true for abstract compound nodes which may represent entire= network domains. As you know abstract TE modes are very important for this= model. So, no, connectivity restriction on a label level does not apply on= ly to WDM. 3. If we were to extend the label model for the connectivity matrix, = I would think we also need to have label restriction model for TTP LLCL as = well. What do you think? IB>> This is actually a good point. Thanks for pointing out. Cheers, Igor Thanks. Young From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Xufeng Liu Sent: Thursday, May 26, 2016 9:48 AM To: Vishnu Pavan Beeram; Igor Bryskin; Oscar Gonzalez De Dios; Tarek Saad; = Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan Hares; Zafa= r Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, SERGIO (SERGI= O); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.liu.ietf@g= mail.com; Belotti, Sergio (Nokia - IT); Anurag Sharma Cc: teas@ietf.org Subject: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016-05-= 23 Participants: Igor, Xufeng, Pavan, Dieter, Sergio, Himanshu - Information sources > Discussed two use cases related to information sources: 1) Provider applies policies to pick the most preferred. 2) Provider does not apply policies and the decision is done by custome= r. > The model currently supports 1) well, but is not clear on 2). > Agreed to clarify the model by: 1) Change "alt-information-sources" to "information-sources" to include all sources, including the selected one. 2) For use case 1), the applied attribute has the selected value, and "information-sources" list all available sources. For use case 2), the applied attribute does not have value, and "information-sources" list all available sources. - Connectivity Matrix > Discussed the comment from Cyril "to add a Label (Following RFC7579) restrictions". > Participants agreed that such constraint information is useful. > Participants agreed that such constraint information is generic enough to be used in various layers and use cases, including optical OTN, and abstract network topologies. > Participants agreed to send the suggestion TEAS WG to add such information to te-topology model. > The potential model change can be: For each connectivity-matrix entry, add: list of labels list types o inclusive-list o exclusive-list o inclusive-range o exclusive-range For each label o exclusivity (true/false) Working members: please provide any comments. Thanks, - Xufeng Note: Please drop me an email if you need an invite for joining the weekly = call. PS. Meeting on May 30 will be canceled for US holiday. --_000_0C72C38E7EBC34499E8A9E7DD007863908EDD175dfweml501mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Young,

 

Please, see in-line,

 

Igor

 

From: Leeyoung
Sent: Thursday, May 26, 2016 11:31 AM
To: Xufeng Liu; Vishnu Pavan Beeram; Igor Bryskin; Oscar Gonzalez De= Dios; Tarek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS)= ; Susan Hares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BEL= OTTI, SERGIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.liu.ietf@gmail.com; Belotti,= Sergio (Nokia - IT); Anurag Sharma
Cc: teas@ietf.org
Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016= -05-23

 

Hi Xufeng,<= /span>

 

Thanks for this update= . Your notes are always very helpful to understand the latest progress of t= his draft.

 

I have a few questions= on the potentially adding model for labels for the connectivity matrix.

 

1.&n= bsp;     You said:=

 

         &nb= sp;     For each label

         &nb= sp;     o exclusivity (true/false)

 

Do you mean this bitmap?

 

2.&n= bsp;     Are you aware = of label restrictions applied for the connectivity matrix other than WSON? = If so, then this model addition makes sense; if not, then we can add the la= bel model for the connectivity matrix in the WSON YANG model. If the extent to which label model addition is not= really a major constraint in the switching technologies other than WSON, i= t would be worthwhile to evaluate if we should do label restriction model i= n a generic way (per this draft) or do it in WSON specific way?  I am not aware of any label restricti= on model for the connectivity matrix for GMPLS other than WSON.

IB>> We had this= discussion many time already. There are physical OTN switches that have co= nstraints on the ODUk type level. For example, a switch can switch ODU2 fro= m link 1 to link2, but ODU2e from link 1 to only link3. This is especially true for abstract compound nodes which may = represent entire network domains. As you know abstract TE modes are very im= portant for this model. So, no, connectivity restriction on a label level d= oes not apply only to WDM.

 

 

3.&n= bsp;      If we we= re to extend the label model for the connectivity matrix, I would think we = also need to have label restriction model for TTP LLCL as well. What do you= think?

IB>> This is act= ually a good point. Thanks for pointing out.

 

Cheers,

Igor=

 

Thanks.

Young

 

 

From: Teas [ma= ilto:teas-bounces@ietf.org] On Behalf Of Xufeng Liu
Sent: Thursday, May 26, 2016 9:48 AM
To: Vishnu Pavan Beeram; Igor Bryskin; Oscar Gonzalez De Dios; Tarek= Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan Hare= s; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, SERGIO= (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.liu.ietf@gmail.com; Belotti, Sergio (N= okia - IT); Anurag Sharma
Cc: teas@ietf.org
Subject: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2= 016-05-23

 

Participants:

Igor, Xufeng, Pavan, Dieter, Sergio, Himanshu

 

- Information sources

  > Discussed two use cases related to infor= mation sources:

    1) Provider applies policies to p= ick the most preferred.

    2) Provider does not apply polici= es and the decision is done by customer.

  > The model currently supports 1) well, bu= t is not clear on 2).

  > Agreed to clarify the model by:

    1) Change "alt-information-s= ources" to "information-sources" to

       include all sou= rces, including the selected one.

    2) For use case 1), the applied a= ttribute has the selected value, and

       "informati= on-sources" list all available sources.

       For use case 2)= , the applied attribute does not have value, and

       "info= rmation-sources" list all available sources.

 

- Connectivity Matrix

  > Discussed the comment from Cyril "t= o add a Label (Following

    RFC7579) restrictions".=

  > Participants agreed that such constraint= information is useful.

  > Participants agreed that such constraint= information is generic

    enough to be used in various laye= rs and use cases, including optical

    OTN, and abstract network topolog= ies.

  > Participants agreed to send the suggesti= on TEAS WG to add such

    information to te-topology model.=

  > The potential model change can be:<= o:p>

    For each connectivity-matrix entr= y, add:

      list of labels

        list type= s

         &nb= sp;     o inclusive-list

         &nb= sp;     o exclusive-list

         &nb= sp;     o inclusive-range

         &nb= sp;     o exclusive-range

         &nb= sp;     For each label

         &nb= sp;     o exclusivity (true/false)

 

Working members: please provide any comments.

 

Thanks,

 

- Xufeng

 

Note: Please drop me an email if you need an invite = for joining the weekly call.

 

PS. Meeting on May 30 will be canceled for US holida= y.

 

 

--_000_0C72C38E7EBC34499E8A9E7DD007863908EDD175dfweml501mbx_-- From nobody Thu May 26 11:58:31 2016 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 C71D012D88A for ; Thu, 26 May 2016 11:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.644 X-Spam-Level: X-Spam-Status: No, score=-5.644 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 4c-Jgt0Ngx_A for ; Thu, 26 May 2016 11:58:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10E3412D87F for ; Thu, 26 May 2016 11:58:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CKV49920; Thu, 26 May 2016 18:58:18 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 26 May 2016 19:58:16 +0100 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Thu, 26 May 2016 11:58:04 -0700 From: Leeyoung To: Igor Bryskin , Xufeng Liu , Vishnu Pavan Beeram , Oscar Gonzalez De Dios , Tarek Saad , Himanshu Shah , Lou Berger , "BRUNGARD, DEBORAH A (ATTLABS)" , Susan Hares , "Zafar Ali (zali)" , "Khaddam, Mazen (CCI-Atlanta)" , Tony Le , "BELOTTI, SERGIO (SERGIO)" , "Beller, Dieter (Dieter)" , Rajan Rao , "Zhangxian (Xian)" , "xufeng.liu.ietf@gmail.com" , "Belotti, Sergio (Nokia - IT)" , Anurag Sharma Thread-Topic: IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23 Thread-Index: AdG3XGalY3SICAUtQf2LvT1Umc0SGwABG4MAAALVFfAABDuCwA== Date: Thu, 26 May 2016 18:58:04 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172A88EDAD@dfweml501-mbx> References: <7AEB3D6833318045B4AE71C2C87E8E172A88ECF3@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908EDD175@dfweml501-mbx> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908EDD175@dfweml501-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.218.137.191] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E172A88EDADdfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.5747474B.0008, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 81e946f201bf060d027a43516f9b5ed6 Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 26 May 2016 18:58:29 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E172A88EDADdfweml501mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Igor, Thanks for your comments. In OTN, if you consider ODUk as labels, I am fine with that. I thought ODUk= is more or less Switching/Encoding in the ISCD Link model than a label. Another question on the TTP, can REG/WC (Wavelength Converter) element be c= onsidered as a type of the TTP? If so, I think TTP can be generalized to in= clude Transponders and REG/WC elements. Thanks. Young From: Igor Bryskin Sent: Thursday, May 26, 2016 11:44 AM To: Leeyoung; Xufeng Liu; Vishnu Pavan Beeram; Oscar Gonzalez De Dios; Tare= k Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan Har= es; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, SERGI= O (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.li= u.ietf@gmail.com; Belotti, Sergio (Nokia - IT); Anurag Sharma Cc: teas@ietf.org Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23 Hi Young, Please, see in-line, Igor From: Leeyoung Sent: Thursday, May 26, 2016 11:31 AM To: Xufeng Liu; Vishnu Pavan Beeram; Igor Bryskin; Oscar Gonzalez De Dios; = Tarek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan= Hares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, S= ERGIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufen= g.liu.ietf@gmail.com; Belotti, Sergio (No= kia - IT); Anurag Sharma Cc: teas@ietf.org Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23 Hi Xufeng, Thanks for this update. Your notes are always very helpful to understand th= e latest progress of this draft. I have a few questions on the potentially adding model for labels for the c= onnectivity matrix. 1. You said: For each label o exclusivity (true/false) Do you mean this bitmap? 2. Are you aware of label restrictions applied for the connectivity ma= trix other than WSON? If so, then this model addition makes sense; if not, = then we can add the label model for the connectivity matrix in the WSON YAN= G model. If the extent to which label model addition is not really a major = constraint in the switching technologies other than WSON, it would be worth= while to evaluate if we should do label restriction model in a generic way = (per this draft) or do it in WSON specific way? I am not aware of any labe= l restriction model for the connectivity matrix for GMPLS other than WSON. IB>> We had this discussion many time already. There are physical OTN switc= hes that have constraints on the ODUk type level. For example, a switch can= switch ODU2 from link 1 to link2, but ODU2e from link 1 to only link3. Thi= s is especially true for abstract compound nodes which may represent entire= network domains. As you know abstract TE modes are very important for this= model. So, no, connectivity restriction on a label level does not apply on= ly to WDM. 3. If we were to extend the label model for the connectivity matrix, = I would think we also need to have label restriction model for TTP LLCL as = well. What do you think? IB>> This is actually a good point. Thanks for pointing out. Cheers, Igor Thanks. Young From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Xufeng Liu Sent: Thursday, May 26, 2016 9:48 AM To: Vishnu Pavan Beeram; Igor Bryskin; Oscar Gonzalez De Dios; Tarek Saad; = Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan Hares; Zafa= r Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, SERGIO (SERGI= O); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.liu.ietf@g= mail.com; Belotti, Sergio (Nokia - IT); A= nurag Sharma Cc: teas@ietf.org Subject: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016-05-= 23 Participants: Igor, Xufeng, Pavan, Dieter, Sergio, Himanshu - Information sources > Discussed two use cases related to information sources: 1) Provider applies policies to pick the most preferred. 2) Provider does not apply policies and the decision is done by custome= r. > The model currently supports 1) well, but is not clear on 2). > Agreed to clarify the model by: 1) Change "alt-information-sources" to "information-sources" to include all sources, including the selected one. 2) For use case 1), the applied attribute has the selected value, and "information-sources" list all available sources. For use case 2), the applied attribute does not have value, and "information-sources" list all available sources. - Connectivity Matrix > Discussed the comment from Cyril "to add a Label (Following RFC7579) restrictions". > Participants agreed that such constraint information is useful. > Participants agreed that such constraint information is generic enough to be used in various layers and use cases, including optical OTN, and abstract network topologies. > Participants agreed to send the suggestion TEAS WG to add such information to te-topology model. > The potential model change can be: For each connectivity-matrix entry, add: list of labels list types o inclusive-list o exclusive-list o inclusive-range o exclusive-range For each label o exclusivity (true/false) Working members: please provide any comments. Thanks, - Xufeng Note: Please drop me an email if you need an invite for joining the weekly = call. PS. Meeting on May 30 will be canceled for US holiday. --_000_7AEB3D6833318045B4AE71C2C87E8E172A88EDADdfweml501mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Igor,

 

Thanks for your commen= ts.

 

In OTN, if you conside= r ODUk as labels, I am fine with that. I thought ODUk is more or less Switc= hing/Encoding in the ISCD Link model than a label.

 

Another question on th= e TTP, can REG/WC (Wavelength Converter) element be considered as a type of= the TTP? If so, I think TTP can be generalized to include Transponders and= REG/WC elements.

 

Thanks.

Young

 

From: Igor Bry= skin
Sent: Thursday, May 26, 2016 11:44 AM
To: Leeyoung; Xufeng Liu; Vishnu Pavan Beeram; Oscar Gonzalez De Dio= s; Tarek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Su= san Hares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI= , SERGIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.liu.ietf@gmail.com; Belotti,= Sergio (Nokia - IT); Anurag Sharma
Cc: teas@ietf.org
Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016= -05-23

 

Hi Young,

 

Please, see in-line,

 

Igor

 

From: Leeyoung
Sent: Thursday, May 26, 2016 11:31 AM
To: Xufeng Liu; Vishnu Pavan Beeram; Igor Bryskin; Oscar Gonzalez De= Dios; Tarek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS)= ; Susan Hares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BEL= OTTI, SERGIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.liu.ietf@gmail.com; Belotti, Sergio (Nokia - IT); Anurag Sharma<= br> Cc: teas@ietf.org
Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016= -05-23

 

Hi Xufeng,<= /span>

 

Thanks for this update= . Your notes are always very helpful to understand the latest progress of t= his draft.

 

I have a few questions= on the potentially adding model for labels for the connectivity matrix.

 

1.&n= bsp;     You said:=

 

         &nb= sp;     For each label

         &nb= sp;     o exclusivity (true/false)

 

Do you mean this bitmap?

 

2.&n= bsp;     Are you aware = of label restrictions applied for the connectivity matrix other than WSON? = If so, then this model addition makes sense; if not, then we can add the la= bel model for the connectivity matrix in the WSON YANG model. If the extent to which label model addition is not= really a major constraint in the switching technologies other than WSON, i= t would be worthwhile to evaluate if we should do label restriction model i= n a generic way (per this draft) or do it in WSON specific way?  I am not aware of any label restricti= on model for the connectivity matrix for GMPLS other than WSON.

IB>> We had this= discussion many time already. There are physical OTN switches that have co= nstraints on the ODUk type level. For example, a switch can switch ODU2 fro= m link 1 to link2, but ODU2e from link 1 to only link3. This is especially true for abstract compound nodes which may = represent entire network domains. As you know abstract TE modes are very im= portant for this model. So, no, connectivity restriction on a label level d= oes not apply only to WDM.

 

 

 

3.&n= bsp;      If we we= re to extend the label model for the connectivity matrix, I would think we = also need to have label restriction model for TTP LLCL as well. What do you= think?

IB>> This is act= ually a good point. Thanks for pointing out.

 

Cheers,

Igor=

 

Thanks.

Young

 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Xufeng Liu
Sent: Thursday, May 26, 2016 9:48 AM
To: Vishnu Pavan Beeram; Igor Bryskin; Oscar Gonzalez De Dios; Tarek= Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan Hare= s; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, SERGIO= (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); = xufeng.liu.ietf@gmail.com; Belotti, Sergio (Nokia - IT); Anurag Sharma<= br> Cc: teas@ietf.org
Subject: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2= 016-05-23

 

Participants:

Igor, Xufeng, Pavan, Dieter, Sergio, Himanshu

 

- Information sources

  > Discussed two use cases related to infor= mation sources:

    1) Provider applies policies to p= ick the most preferred.

    2) Provider does not apply polici= es and the decision is done by customer.

  > The model currently supports 1) well, bu= t is not clear on 2).

  > Agreed to clarify the model by:

    1) Change "alt-information-s= ources" to "information-sources" to

       include all sou= rces, including the selected one.

    2) For use case 1), the applied a= ttribute has the selected value, and

       "informati= on-sources" list all available sources.

       For use case 2)= , the applied attribute does not have value, and

       "info= rmation-sources" list all available sources.

 

- Connectivity Matrix

  > Discussed the comment from Cyril "t= o add a Label (Following

    RFC7579) restrictions".=

  > Participants agreed that such constraint= information is useful.

  > Participants agreed that such constraint= information is generic

    enough to be used in various laye= rs and use cases, including optical

    OTN, and abstract network topolog= ies.

  > Participants agreed to send the suggesti= on TEAS WG to add such

    information to te-topology model.=

  > The potential model change can be:<= o:p>

    For each connectivity-matrix entr= y, add:

      list of labels

        list type= s

         &nb= sp;     o inclusive-list

         &nb= sp;     o exclusive-list

         &nb= sp;     o inclusive-range

         &nb= sp;     o exclusive-range

         &nb= sp;     For each label

         &nb= sp;     o exclusivity (true/false)

 

Working members: please provide any comments.

 

Thanks,

 

- Xufeng

 

Note: Please drop me an email if you need an invite = for joining the weekly call.

 

PS. Meeting on May 30 will be canceled for US holida= y.

 

 

--_000_7AEB3D6833318045B4AE71C2C87E8E172A88EDADdfweml501mbx_-- From nobody Thu May 26 13:18:17 2016 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 5539812D996 for ; Thu, 26 May 2016 13:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 aKp1yvbdWfYM for ; Thu, 26 May 2016 13:18:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2309F12D98C for ; Thu, 26 May 2016 13:18:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CKV56156; Thu, 26 May 2016 20:18:07 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 26 May 2016 21:18:06 +0100 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Thu, 26 May 2016 13:17:49 -0700 From: Igor Bryskin To: Leeyoung , Xufeng Liu , "Vishnu Pavan Beeram" , Oscar Gonzalez De Dios , Tarek Saad , Himanshu Shah , Lou Berger , "BRUNGARD, DEBORAH A (ATTLABS)" , Susan Hares , "Zafar Ali (zali)" , "Khaddam, Mazen (CCI-Atlanta)" , Tony Le , "BELOTTI, SERGIO (SERGIO)" , "Beller, Dieter (Dieter)" , Rajan Rao , "Zhangxian (Xian)" , "xufeng.liu.ietf@gmail.com" , "Belotti, Sergio (Nokia - IT)" , Anurag Sharma Thread-Topic: IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23 Thread-Index: AdG3XGalY3SICAUtQf2LvT1Umc0SGwABG4MAAALVFfAABDuCwAADMsUQ Date: Thu, 26 May 2016 20:17:48 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908EDD212@dfweml501-mbx> References: <7AEB3D6833318045B4AE71C2C87E8E172A88ECF3@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908EDD175@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A88EDAD@dfweml501-mbx> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172A88EDAD@dfweml501-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.253.100] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908EDD212dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.57475A00.00D4, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 81e946f201bf060d027a43516f9b5ed6 Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 26 May 2016 20:18:15 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908EDD212dfweml501mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Young, "Another question on the TTP, can REG/WC (Wavelength Converter) element be = considered as a type of the TTP? If so, I think TTP can be generalized to i= nclude Transponders and REG/WC elements." One important role of TTP is to represent topologically a client/server lay= er adaptor to facilitate inter-layer path computations. REG/WC has no adapt= ation capabilities. WDM augmentation could IMHO model REG/WC as a TTP with no adaptation caps, = however, because this is only pertinent to OCh layer, it should not be part= of the basic TE topology model. Igor From: Leeyoung Sent: Thursday, May 26, 2016 2:58 PM To: Igor Bryskin; Xufeng Liu; Vishnu Pavan Beeram; Oscar Gonzalez De Dios; = Tarek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan= Hares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, S= ERGIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufen= g.liu.ietf@gmail.com; Belotti, Sergio (Nokia - IT); Anurag Sharma Cc: teas@ietf.org Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23 Hi Igor, Thanks for your comments. In OTN, if you consider ODUk as labels, I am fine with that. I thought ODUk= is more or less Switching/Encoding in the ISCD Link model than a label. Youmg, Thanks. Young From: Igor Bryskin Sent: Thursday, May 26, 2016 11:44 AM To: Leeyoung; Xufeng Liu; Vishnu Pavan Beeram; Oscar Gonzalez De Dios; Tare= k Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan Har= es; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, SERGI= O (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.li= u.ietf@gmail.com; Belotti, Sergio (Nokia - IT); Anurag Sharma Cc: teas@ietf.org Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23 Hi Young, Please, see in-line, Igor From: Leeyoung Sent: Thursday, May 26, 2016 11:31 AM To: Xufeng Liu; Vishnu Pavan Beeram; Igor Bryskin; Oscar Gonzalez De Dios; = Tarek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan= Hares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, S= ERGIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufen= g.liu.ietf@gmail.com; Belotti, Sergio (No= kia - IT); Anurag Sharma Cc: teas@ietf.org Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23 Hi Xufeng, Thanks for this update. Your notes are always very helpful to understand th= e latest progress of this draft. I have a few questions on the potentially adding model for labels for the c= onnectivity matrix. 1. You said: For each label o exclusivity (true/false) Do you mean this bitmap? 2. Are you aware of label restrictions applied for the connectivity ma= trix other than WSON? If so, then this model addition makes sense; if not, = then we can add the label model for the connectivity matrix in the WSON YAN= G model. If the extent to which label model addition is not really a major = constraint in the switching technologies other than WSON, it would be worth= while to evaluate if we should do label restriction model in a generic way = (per this draft) or do it in WSON specific way? I am not aware of any labe= l restriction model for the connectivity matrix for GMPLS other than WSON. IB>> We had this discussion many time already. There are physical OTN switc= hes that have constraints on the ODUk type level. For example, a switch can= switch ODU2 from link 1 to link2, but ODU2e from link 1 to only link3. Thi= s is especially true for abstract compound nodes which may represent entire= network domains. As you know abstract TE modes are very important for this= model. So, no, connectivity restriction on a label level does not apply on= ly to WDM. 3. If we were to extend the label model for the connectivity matrix, = I would think we also need to have label restriction model for TTP LLCL as = well. What do you think? IB>> This is actually a good point. Thanks for pointing out. Cheers, Igor Thanks. Young From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Xufeng Liu Sent: Thursday, May 26, 2016 9:48 AM To: Vishnu Pavan Beeram; Igor Bryskin; Oscar Gonzalez De Dios; Tarek Saad; = Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan Hares; Zafa= r Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, SERGIO (SERGI= O); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.liu.ietf@g= mail.com; Belotti, Sergio (Nokia - IT); A= nurag Sharma Cc: teas@ietf.org Subject: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016-05-= 23 Participants: Igor, Xufeng, Pavan, Dieter, Sergio, Himanshu - Information sources > Discussed two use cases related to information sources: 1) Provider applies policies to pick the most preferred. 2) Provider does not apply policies and the decision is done by custome= r. > The model currently supports 1) well, but is not clear on 2). > Agreed to clarify the model by: 1) Change "alt-information-sources" to "information-sources" to include all sources, including the selected one. 2) For use case 1), the applied attribute has the selected value, and "information-sources" list all available sources. For use case 2), the applied attribute does not have value, and "information-sources" list all available sources. - Connectivity Matrix > Discussed the comment from Cyril "to add a Label (Following RFC7579) restrictions". > Participants agreed that such constraint information is useful. > Participants agreed that such constraint information is generic enough to be used in various layers and use cases, including optical OTN, and abstract network topologies. > Participants agreed to send the suggestion TEAS WG to add such information to te-topology model. > The potential model change can be: For each connectivity-matrix entry, add: list of labels list types o inclusive-list o exclusive-list o inclusive-range o exclusive-range For each label o exclusivity (true/false) Working members: please provide any comments. Thanks, - Xufeng Note: Please drop me an email if you need an invite for joining the weekly = call. PS. Meeting on May 30 will be canceled for US holiday. --_000_0C72C38E7EBC34499E8A9E7DD007863908EDD212dfweml501mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Young,

 

“Another question on the TTP, can REG/WC (Wavelength Converter= ) element be considered as a type of the TTP? If so, I think TTP can be generalized to include Transponders and REG/WC elements.”

 

One important role of = TTP is to represent topologically a client/server layer adaptor to facilita= te inter-layer path computations. REG/WC has no adaptation capabilities.

WDM augmentation could IMHO mo= del REG/WC as a TTP with no adaptation cap= s, however, because this is only pertinent to OCh layer, it should not be p= art of the basic TE topology model.

 

Igor

 

From: Leeyoung
Sent: Thursday, May 26, 2016 2:58 PM
To: Igor Bryskin; Xufeng Liu; Vishnu Pavan Beeram; Oscar Gonzalez De= Dios; Tarek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS)= ; Susan Hares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BEL= OTTI, SERGIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.liu.ietf@gmail.com; Belotti,= Sergio (Nokia - IT); Anurag Sharma
Cc: teas@ietf.org
Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016= -05-23

 

Hi Igor,

 

Thanks for your commen= ts.

 

In OTN, if you conside= r ODUk as labels, I am fine with that. I thought ODUk is more or less Switc= hing/Encoding in the ISCD Link model than a label.

 

Youmg,

 

Thanks.

Young

 

From: Igor Bry= skin
Sent: Thursday, May 26, 2016 11:44 AM
To: Leeyoung; Xufeng Liu; Vishnu Pavan Beeram; Oscar Gonzalez De Dio= s; Tarek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Su= san Hares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI= , SERGIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.liu.ietf@gmail.com; Belotti,= Sergio (Nokia - IT); Anurag Sharma
Cc: teas@ietf.org
Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016= -05-23

 

Hi Young,

 

Please, see in-line,

 

Igor

 

From: Leeyoung
Sent: Thursday, May 26, 2016 11:31 AM
To: Xufeng Liu; Vishnu Pavan Beeram; Igor Bryskin; Oscar Gonzalez De= Dios; Tarek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS)= ; Susan Hares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BEL= OTTI, SERGIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.liu.ietf@gmail.com; Belotti, Sergio (Nokia - IT); Anurag Sharma<= br> Cc: teas@ietf.org
Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016= -05-23

 

Hi Xufeng,<= /span>

 

Thanks for this update= . Your notes are always very helpful to understand the latest progress of t= his draft.

 

I have a few questions= on the potentially adding model for labels for the connectivity matrix.

 

1.&n= bsp;     You said:=

 

         &nb= sp;     For each label

         &nb= sp;     o exclusivity (true/false)

 

Do you mean this bitmap?

 

2.&n= bsp;     Are you aware = of label restrictions applied for the connectivity matrix other than WSON? = If so, then this model addition makes sense; if not, then we can add the la= bel model for the connectivity matrix in the WSON YANG model. If the extent to which label model addition is not= really a major constraint in the switching technologies other than WSON, i= t would be worthwhile to evaluate if we should do label restriction model i= n a generic way (per this draft) or do it in WSON specific way?  I am not aware of any label restricti= on model for the connectivity matrix for GMPLS other than WSON.

IB>> We had this= discussion many time already. There are physical OTN switches that have co= nstraints on the ODUk type level. For example, a switch can switch ODU2 fro= m link 1 to link2, but ODU2e from link 1 to only link3. This is especially true for abstract compound nodes which may = represent entire network domains. As you know abstract TE modes are very im= portant for this model. So, no, connectivity restriction on a label level d= oes not apply only to WDM.

 

 

 

3.&n= bsp;      If we we= re to extend the label model for the connectivity matrix, I would think we = also need to have label restriction model for TTP LLCL as well. What do you= think?

IB>> This is act= ually a good point. Thanks for pointing out.

 

Cheers,

Igor=

 

Thanks.

Young

 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Xufeng Liu
Sent: Thursday, May 26, 2016 9:48 AM
To: Vishnu Pavan Beeram; Igor Bryskin; Oscar Gonzalez De Dios; Tarek= Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan Hare= s; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, SERGIO= (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); = xufeng.liu.ietf@gmail.com; Belotti, Sergio (Nokia - IT); Anurag Sharma<= br> Cc: teas@ietf.org
Subject: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2= 016-05-23

 

Participants:

Igor, Xufeng, Pavan, Dieter, Sergio, Himanshu

 

- Information sources

  > Discussed two use cases related to infor= mation sources:

    1) Provider applies policies to p= ick the most preferred.

    2) Provider does not apply polici= es and the decision is done by customer.

  > The model currently supports 1) well, bu= t is not clear on 2).

  > Agreed to clarify the model by:

    1) Change "alt-information-s= ources" to "information-sources" to

       include all sou= rces, including the selected one.

    2) For use case 1), the applied a= ttribute has the selected value, and

       "informati= on-sources" list all available sources.

       For use case 2)= , the applied attribute does not have value, and

       "info= rmation-sources" list all available sources.

 

- Connectivity Matrix

  > Discussed the comment from Cyril "t= o add a Label (Following

    RFC7579) restrictions".=

  > Participants agreed that such constraint= information is useful.

  > Participants agreed that such constraint= information is generic

    enough to be used in various laye= rs and use cases, including optical

    OTN, and abstract network topolog= ies.

  > Participants agreed to send the suggesti= on TEAS WG to add such

    information to te-topology model.=

  > The potential model change can be:<= o:p>

    For each connectivity-matrix entr= y, add:

      list of labels

        list type= s

         &nb= sp;     o inclusive-list

         &nb= sp;     o exclusive-list

         &nb= sp;     o inclusive-range

         &nb= sp;     o exclusive-range

         &nb= sp;     For each label

         &nb= sp;     o exclusivity (true/false)

 

Working members: please provide any comments.

 

Thanks,

 

- Xufeng

 

Note: Please drop me an email if you need an invite = for joining the weekly call.

 

PS. Meeting on May 30 will be canceled for US holida= y.

 

 

--_000_0C72C38E7EBC34499E8A9E7DD007863908EDD212dfweml501mbx_-- From nobody Thu May 26 19:20:31 2016 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 E152E12D154; Thu, 26 May 2016 19:20:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160527022027.14492.40422.idtracker@ietfa.amsl.com> Date: Thu, 26 May 2016 19:20:27 -0700 Archived-At: Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-06.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 27 May 2016 02:20:28 -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 of the IETF. Title : RSVP-TE Extensions for Collecting SRLG Information Authors : Fatai Zhang Oscar Gonzalez de Dios Matt Hartley Zafar Ali Cyril Margaria Filename : draft-ietf-teas-rsvp-te-srlg-collect-06.txt Pages : 15 Date : 2016-05-26 Abstract: This document provides extensions for the Resource ReserVation Protocol-Traffic Engineering (RSVP-TE), including GMPLS, to support automatic collection of Shared Risk Link Group (SRLG) information for the TE link formed by a Label Switched Path (LSP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-collect/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-srlg-collect-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te-srlg-collect-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 Thu May 26 19:23:46 2016 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 C49E212D165; Thu, 26 May 2016 19:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXt9GGRPGGrJ; Thu, 26 May 2016 19:23:42 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05BFF12D154; Thu, 26 May 2016 19:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22286; q=dns/txt; s=iport; t=1464315822; x=1465525422; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Jm9BzSSAhxQtKlH1jtgEMqUOErgURO2l5sant6jOE6k=; b=ilnZhc4Vbsp2X0u/Ox4iX0+a0xChVadC3mmIWk1TAr/z4yl7fAWdBbJK E4eUbn8vC9tzEa/fns1pDb3vF4yt/Jut4e1X8bv/X6EFXWJ28KKLcakod +u1SsO6O/Q5HmLjY5Flvigmz8xyfZHDNCgp2faCol8V6CrEaQKen5BiUG A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BlAgBorkdX/40NJK1cgmxNVn0GgnerA?= =?us-ascii?q?IZ2hHkBDYF4hhECHIEdOBQBAQEBAQEBZSeEQwEBAQQMFwpBCxACAQYCEQQBASg?= =?us-ascii?q?DAgICHxEUCQgCBAENBQiIDQMXlRGdHY0ZDYQjAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBHIYnhEyCQ4IygkuCWQWYBDMBjCaBcoFwhE+IZIdkh2cBHgEBQoNtbokWfwE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.26,371,1459814400"; d="scan'208,217";a="278388749" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 May 2016 02:23:39 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u4R2NcVr022474 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 27 May 2016 02:23:39 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 26 May 2016 21:23:38 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Thu, 26 May 2016 21:23:37 -0500 From: "Matt Hartley (mhartley)" To: Vishnu Pavan Beeram , "teas@ietf.org" , "draft-ietf-teas-rsvp-te-srlg-collect@ietf.org" Thread-Topic: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-srlg-collect-05 Thread-Index: AQHRtrEQTTSciYLRWkuiixGbqes60p/MEAwQ Date: Fri, 27 May 2016 02:23:37 +0000 Message-ID: References: <40746B2300A8FC4AB04EE722A593182BAC1B121C@ONWVEXCHMB04.ciena.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.243.52] Content-Type: multipart/alternative; boundary="_000_cef3cb4259504638b7ff41cc29b2ac2eXCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Matt Hartley \(mhartley\)" Subject: Re: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-srlg-collect-05 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 27 May 2016 02:23:45 -0000 --_000_cef3cb4259504638b7ff41cc29b2ac2eXCHRCD001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGF2YW4sIGFsbCwNCg0KVjYgcG9zdGVkIHdpdGggbWFya3VwcyBmcm9tIHRoZSBMQyBjb21tZW50 cy4NCg0KQ2hlZXJzDQoNCk1hdHQNCg0KDQpBdXRob3JzLCBIaSENCkknbSBpbiB0aGUgcHJvY2Vz cyBvZiB1cGRhdGluZyB0aGUgU2hlcGhlcmQncyB3cml0ZS11cCBmb3IgdGhpcyBkb2N1bWVudC4g SSdtIGV4cGVjdGluZyB5b3UgdG8gc3VibWl0IGFub3RoZXIgcmV2IGZvciB0aGlzIGRyYWZ0IChh ZGRyZXNzaW5nIHRoZSBuaXRzIHRoYXQgd2VyZSByYWlzZWQgZHVyaW5nIHRoZSBMQykuIEkgZm91 bmQgYSBmZXcgb3RoZXIgbml0cyAocGFzdGVkIGJlbG93KSBkdXJpbmcgbXkgcmV2aWV3LiBQbGVh c2Ugc2VlIGlmIHlvdSBjYW4gdGFrZSBjYXJlIG9mIHRoZXNlIGFzIHdlbGwgaW4gdGhlIG5leHQg cmV2Lg0KSSdsbCByZXN1Ym1pdCB0aGUgcHVibGljYXRpb24gcmVxdWVzdCBhcyBzb29uIGFzIHRo ZSBuZXcgdmVyc2lvbiBzaG93cyB1cC4NCg0KUmVnYXJkcywNCi1QYXZhbg0KDQoqKg0KU2VjdGlv biAxLg0KDQotIHMvVGhpcyBkb2N1bWVudCBwcm92aWRlcyBhIG1lY2hhbmlzbSB0byBjb2xsZWN0 IHRoZSBTUkxHcyB1c2VkIGJ5IGEgTFNQLC9UaGlzIGRvY3VtZW50IHByb3ZpZGVzIGEgc2lnbmFs aW5nIG1lY2hhbmlzbSB0byBjb2xsZWN0IHRoZSBTUkxHcyB1c2VkIGJ5IGEgTFNQLA0KW0NvbW1l bnQgLSBzaWduYWxpbmcgbWVjaGFuaXNtIGFzIG9wcG9zZWQgdG8gcm91dGluZyBtZWNoYW5pc207 IFRoZSBpbnRyb2R1Y3Rpb24gc2VjdGlvbiBkb2VzbuKAmXQgZXhwbGljaXRseSBzYXkgKG1heWJl IGl0IHNob3VsZCkgdGhhdCB0aGlzIG1lY2hhbmlzbSBpcyB1c2VmdWwgaW4gc2NlbmFyaW9zIHdo ZXJlIHRoZSBTUkxHIGluZm8gY2Fubm90IGJlIG9idGFpbmVkIHZpYSBJR1AtVEUgKHZpYSByb3V0 aW5nKV0NCg0KLSBzL05vdGUgdGhhdCBzcGVjaWZpY2F0aW9uIG9mIHRoZSB0aGUgdXNlIG9mIHRo ZSBjb2xsZWN0ZWQgU1JMR3MgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4v Tm90ZSB0aGF0IHNwZWNpZmljYXRpb24gb2YgdGhlIHVzZSBvZiB0aGUgY29sbGVjdGVkIFNSTEdz IGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQpbQ29tbWVudCAtIFlvdSBt YXkgZXZlbiBjb25zaWRlciByZW1vdmluZyB0aGUgYWJvdmUgbGluZSBhbHRvZ2V0aGVyIChnaXZl biB0aGF0IHRoZSBkb2N1bWVudCBkb2VzIGRpc2N1c3MgYW4gYXBwbGljYWJpbGl0eSBleGFtcGxl IGluIDEuMSldDQoNCg0KU2VjdGlvbiAzLjE6DQoNCi0gRml4IGluZGVudGF0aW9uIGZvciB0aGUg d2hvbGUgc2VjdGlvbg0KDQoNClNlY3Rpb24gMy4yOg0KDQotIEZpeCBpbmRlbnRhdGlvbiBmb3Ig dGhlIHdob2xlIHNlY3Rpb24uDQoNCi0gcy9TUkxHIGluZm9ybWF0aW9uIGlzIGZvciBlYWNoIGhv cCBpcyBhZGRlZCB0byB0aGUgUGF0aCBSUk8gZHVyaW5nIFBhdGggbWVzc2FnZSBwcm9jZXNzaW5n Li9TUkxHIGluZm9ybWF0aW9uIGlzIGFkZGVkIGJ5IGVhY2ggaG9wIHRvIHRoZSBQYXRoIFJSTyBk dXJpbmcgUGF0aCBtZXNzYWdlIHByb2Nlc3NpbmcuDQoNCi0gQ29uc2lkZXIgcmVtb3ZpbmcgdGhl IGZvbGxvd2luZyBsaW5lIFtDb21tZW50IC0gaXQgZG9lc27igJl0IHNlZW0gdG8gYmUgYnJpbmdp bmcgaW4gYW55IGFkZGl0aW9uYWwgdmFsdWUgaW4gdGhpcyBzZWN0aW9uXToNClRoZSBlbmRwb2lu dHMgb2YgdGhlIExTUCBjYW4gbWFrZSB1c2Ugb2YgdGhlIGNvbGxlY3RlZCBTUkxHIGluZm9ybWF0 aW9uLCBmb3IgZXhhbXBsZSwgZm9yIHJvdXRpbmcsIHNoYXJpbmcgYW5kIFRFIGxpbmsgY29uZmln dXJhdGlvbiBwdXJwb3Nlcy4NCg0KDQpTZWN0aW9uIDMuMzoNCg0KLSBGaXggaW5kZW50YXRpb24g Zm9yIHRoZSB3aG9sZSBzZWN0aW9uLg0KDQotIHMvVGhpcyBtZWFucyB0aGF0IHRoYXQgdGhlIHNp Z25hbGluZyBwcm9jZWR1cmUgbmVlZHMgdG8gYmUgY2FwYWJsZSBvZiB1cGRhdGluZyB0aGUgbmV3 IFNSTEcgaW5mb3JtYXRpb24uL1RoaXMgbWVhbnMgdGhhdCB0aGUgc2lnbmFsaW5nIHByb2NlZHVy ZSBuZWVkcyB0byBiZSBjYXBhYmxlIG9mIHVwZGF0aW5nIHRoZSBuZXcgU1JMRyBpbmZvcm1hdGlv bi4NCg0KDQpTZWN0aW9uIDMuNDoNCg0KLSBGaXggaW5kZW50YXRpb24gZm9yIHRoZSB3aG9sZSBz ZWN0aW9uLg0KDQoNClNlY3Rpb24gNC4xOg0KDQotIEZpeCBpbmRlbnRhdGlvbiBmb3IgdGhlIGZp cnN0IHBhcmFncmFwaC4NCg0KDQpTZWN0aW9uIDYuMSAtIFBvbGljeSBDb25maWd1cmF0aW9uOg0K DQotIEZpeCB0aGUgYnVsbGV0czsgQWxsIGJ1bGxldCBwb2ludHMg4oCcb+KAnSBhcmUgc3F1ZWV6 ZWQgdG9nZXRoZXIgaW4gb25lIHBhcmFncmFwaC4NCg0KDQpTZWN0aW9uIDguMiBST1VURV9SRUNP UkQgT2JqZWN0DQoNCi0gRml4IHRoZSBpbmRlbnRhdGlvbiBvZiB0aGUgdGFibGUgKGFsaWduIGl0 IHdpdGggdGhlIHRhYmxlIGluIDguMSkNCg0KDQpTZWN0aW9uIDguMyBQb2xpY3kgQ29udHJvbCBG YWlsdXJlIEVycm9yIHN1YmNvZGVzDQoNCi0gRml4IHRoZSBpbmRlbnRhdGlvbiBvZiB0aGUgdGFi bGUgKGFsaWduIGl0IHdpdGggdGhlIHRhYmxlIGluIDguMSkNCg0KDQpPbiBGcmksIE1heSAxMywg MjAxNiBhdCA4OjE1IFBNLCBWaXNobnUgUGF2YW4gQmVlcmFtIDx2aXNobnVwYXZhbkBnbWFpbC5j b208bWFpbHRvOnZpc2hudXBhdmFuQGdtYWlsLmNvbT4+IHdyb3RlOg0KVGhlIFdHIExDIGZvciB0 aGlzIGRvY3VtZW50IGlzIG5vdyBjbG9zZWQuDQpNYXR0IChhbmQgb3RoZXIgYXV0aG9ycyksDQpQ bGVhc2UgZ28gYWhlYWQgYW5kIHB1Ymxpc2ggYSBuZXcgcmV2aXNpb24gYWRkcmVzc2luZyB0aGUg bWlub3IgY29tbWVudHMgcmVjZWl2ZWQgZHVyaW5nIHRoZSBMQy4NClJlZ2FyZHMsDQotUGF2YW4g KGFuZCBMb3UpDQoNCk9uIEZyaSwgTWF5IDEzLCAyMDE2IGF0IDY6MDcgUE0sIFNoYWgsIEhpbWFu c2h1IDxoc2hhaEBjaWVuYS5jb208bWFpbHRvOmhzaGFoQGNpZW5hLmNvbT4+IHdyb3RlOg0KU29y cnkgZm9yIHRoZSBsYXRlIHJlcGx5Li4gKE9uIFBUTy4uKQ0KDQpXaGlsZSBhZGRpbmcgb2Yg4oCc Y29tcGxldGlvbiBmbGFn4oCdIChvciBzaW1pbGFyIHRvIOKAnHBhcnRpYWwgYml04oCdIHVzZWQg aW4gQkdQKSB3b3VsZCBoYXZlIGJlZW4gYSBuaWNlIGZlYXR1cmUNCnRvIGhhdmUsIHRoZSBTUkxH IGNvbGxlY3QgZHJhZnQgYnkgaXRzZWxmIGlzIGFuIGltcG9ydGFudCBmZWF0dXJlIHRvIGhhdmUs IHNvLi4NCg0KSSBzdXBwb3J0IHByb2dyZXNzaW5nIHRoZSBkb2N1bWVudCB0byBwdWJsaWNhdGlv bi4NCg0KVGhhbmtzLA0KSGltYW5zaHUNCg0KRnJvbTogVGVhcyBbbWFpbHRvOnRlYXMtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86dGVhcy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFZp c2hudSBQYXZhbiBCZWVyYW0NClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAyOCwgMjAxNiA0OjQyIFBN DQpUbzogdGVhc0BpZXRmLm9yZzxtYWlsdG86dGVhc0BpZXRmLm9yZz4NClN1YmplY3Q6IFtUZWFz XSBXRyBMYXN0IENhbGwgb24gZHJhZnQtaWV0Zi10ZWFzLXJzdnAtdGUtc3JsZy1jb2xsZWN0LTA1 DQoNCkFsbCwNCg0KVGhpcyBzdGFydHMgYSB0d28gd2VlayB3b3JraW5nIGdyb3VwIGxhc3QgY2Fs bCBvbg0KZHJhZnQtaWV0Zi10ZWFzLXJzdnAtdGUtc3JsZy1jb2xsZWN0LTA1Lg0KDQpUaGUgd29y a2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBvbiBUaHVyc2RheSwgTWF5IDEydGguIFBsZWFzZQ0K c2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBURUFTIG1haWxpbmcgbGlzdC4NCg0KQXMgaXMgYWx3 YXlzIHRoZSBjYXNlLCBwb3NpdGl2ZSBjb21tZW50cywgZS5nLiwgIkkndmUgcmV2aWV3ZWQgdGhp cw0KZG9jdW1lbnQgYW5kIGJlbGlldmUgaXQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uIiwgYXJl IHdlbGNvbWUhDQpUaGlzIGlzIHVzZWZ1bCBhbmQgaW1wb3J0YW50LCBldmVuIGZyb20gYXV0aG9y cy4NCk5vdGUsIElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgb24gdGhpcyBkcmFmdC4NCg0KVGhhbmtz LA0KUGF2YW4gKGFuZCBMb3UpDQoNCg0K --_000_cef3cb4259504638b7ff41cc29b2ac2eXCHRCD001ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQm9va21hbiBPbGQgU3R5bGUiOw0KCXBh bm9zZS0xOjIgNSA2IDQgNSA1IDUgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpU YWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnN0YW50aWE7DQoJcGFub3NlLTE6MiAzIDYgMiA1 IDMgNiAzIDMgMzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkJvb2ttYW4gT2xkIFN0eWxlIixzZXJpZjsNCgljb2xvcjojOUUzNDAwO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Qm9va21hbiBPbGQgU3R5bGUmcXVvdDssc2VyaWY7Y29sb3I6IzlF MzQwMCI+UGF2YW4sIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtCb29r bWFuIE9sZCBTdHlsZSZxdW90OyxzZXJpZjtjb2xvcjojOUUzNDAwIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtCb29rbWFuIE9sZCBTdHlsZSZxdW90OyxzZXJpZjtj b2xvcjojOUUzNDAwIj5WNiBwb3N0ZWQgd2l0aCBtYXJrdXBzIGZyb20gdGhlIExDIGNvbW1lbnRz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1 b3Q7LHNlcmlmO2NvbG9yOiM5RTM0MDAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1b3Q7LHNlcmlmO2NvbG9yOiM5RTM0MDAiPkNo ZWVyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxl JnF1b3Q7LHNlcmlmO2NvbG9yOiM5RTM0MDAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1b3Q7LHNlcmlmO2NvbG9yOiM5RTM0MDAi Pk1hdHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtCb29rbWFuIE9sZCBTdHls ZSZxdW90OyxzZXJpZjtjb2xvcjojOUUzNDAwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5BdXRob3JzLCBIaSE8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij5JJ20gaW4gdGhlIHByb2Nlc3Mgb2YgdXBkYXRpbmcgdGhlIFNoZXBoZXJkJ3Mgd3Jp dGUtdXAgZm9yIHRoaXMgZG9jdW1lbnQuIEknbSBleHBlY3RpbmcgeW91IHRvIHN1Ym1pdCBhbm90 aGVyIHJldiBmb3IgdGhpcyBkcmFmdCAoYWRkcmVzc2luZyB0aGUgbml0cyB0aGF0IHdlcmUgcmFp c2VkIGR1cmluZyB0aGUgTEMpLiBJIGZvdW5kIGEgZmV3IG90aGVyIG5pdHMNCiAocGFzdGVkIGJl bG93KSBkdXJpbmcgbXkgcmV2aWV3LiBQbGVhc2Ugc2VlIGlmIHlvdSBjYW4gdGFrZSBjYXJlIG9m IHRoZXNlIGFzIHdlbGwgaW4gdGhlIG5leHQgcmV2LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdsbCByZXN1Ym1pdCB0aGUgcHVibGljYXRpb24g cmVxdWVzdCBhcyBzb29uIGFzIHRoZSBuZXcgdmVyc2lvbiBzaG93cyB1cC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tUGF2YW48bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxicj4NCioqPGJyPg0KU2VjdGlvbiAxLiA8YnI+DQo8YnI+DQot IHMvVGhpcyBkb2N1bWVudCBwcm92aWRlcyBhIG1lY2hhbmlzbSB0byBjb2xsZWN0IHRoZSBTUkxH cyB1c2VkIGJ5IGEgTFNQLC9UaGlzIGRvY3VtZW50IHByb3ZpZGVzIGEgc2lnbmFsaW5nIG1lY2hh bmlzbSB0byBjb2xsZWN0IHRoZSBTUkxHcyB1c2VkIGJ5IGEgTFNQLDxicj4NCltDb21tZW50IC0g c2lnbmFsaW5nIG1lY2hhbmlzbSBhcyBvcHBvc2VkIHRvIHJvdXRpbmcgbWVjaGFuaXNtOyBUaGUg aW50cm9kdWN0aW9uIHNlY3Rpb24gZG9lc27igJl0IGV4cGxpY2l0bHkgc2F5IChtYXliZSBpdCBz aG91bGQpIHRoYXQgdGhpcyBtZWNoYW5pc20gaXMgdXNlZnVsIGluIHNjZW5hcmlvcyB3aGVyZSB0 aGUgU1JMRyBpbmZvIGNhbm5vdCBiZSBvYnRhaW5lZCB2aWEgSUdQLVRFICh2aWEgcm91dGluZyld PGJyPg0KPGJyPg0KLSBzL05vdGUgdGhhdCBzcGVjaWZpY2F0aW9uIG9mIHRoZSB0aGUgdXNlIG9m IHRoZSBjb2xsZWN0ZWQgU1JMR3MgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVu dC4vTm90ZSB0aGF0IHNwZWNpZmljYXRpb24gb2YgdGhlIHVzZSBvZiB0aGUgY29sbGVjdGVkIFNS TEdzIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuPGJyPg0KW0NvbW1lbnQg LSBZb3UgbWF5IGV2ZW4gY29uc2lkZXIgcmVtb3ZpbmcgdGhlIGFib3ZlIGxpbmUgYWx0b2dldGhl ciAoZ2l2ZW4gdGhhdCB0aGUgZG9jdW1lbnQgZG9lcyBkaXNjdXNzIGFuIGFwcGxpY2FiaWxpdHkg ZXhhbXBsZSBpbiAxLjEpXTxicj4NCjxicj4NCjxicj4NClNlY3Rpb24gMy4xOjxicj4NCjxicj4N Ci0gRml4IGluZGVudGF0aW9uIGZvciB0aGUgd2hvbGUgc2VjdGlvbjxicj4NCjxicj4NCjxicj4N ClNlY3Rpb24gMy4yOjxicj4NCjxicj4NCi0gRml4IGluZGVudGF0aW9uIGZvciB0aGUgd2hvbGUg c2VjdGlvbi48YnI+DQo8YnI+DQotIHMvU1JMRyBpbmZvcm1hdGlvbiBpcyBmb3IgZWFjaCBob3Ag aXMgYWRkZWQgdG8gdGhlIFBhdGggUlJPIGR1cmluZyBQYXRoIG1lc3NhZ2UgcHJvY2Vzc2luZy4v U1JMRyBpbmZvcm1hdGlvbiBpcyBhZGRlZCBieSBlYWNoIGhvcCB0byB0aGUgUGF0aCBSUk8gZHVy aW5nIFBhdGggbWVzc2FnZSBwcm9jZXNzaW5nLjxicj4NCjxicj4NCi0gQ29uc2lkZXIgcmVtb3Zp bmcgdGhlIGZvbGxvd2luZyBsaW5lIFtDb21tZW50IC0gaXQgZG9lc27igJl0IHNlZW0gdG8gYmUg YnJpbmdpbmcgaW4gYW55IGFkZGl0aW9uYWwgdmFsdWUgaW4gdGhpcyBzZWN0aW9uXTo8YnI+DQpU aGUgZW5kcG9pbnRzIG9mIHRoZSBMU1AgY2FuIG1ha2UgdXNlIG9mIHRoZSBjb2xsZWN0ZWQgU1JM RyBpbmZvcm1hdGlvbiwgZm9yIGV4YW1wbGUsIGZvciByb3V0aW5nLCBzaGFyaW5nIGFuZCBURSBs aW5rIGNvbmZpZ3VyYXRpb24gcHVycG9zZXMuPGJyPg0KPGJyPg0KPGJyPg0KU2VjdGlvbiAzLjM6 PGJyPg0KPGJyPg0KLSBGaXggaW5kZW50YXRpb24gZm9yIHRoZSB3aG9sZSBzZWN0aW9uLjxicj4N Cjxicj4NCi0gcy9UaGlzIG1lYW5zIHRoYXQgdGhhdCB0aGUgc2lnbmFsaW5nIHByb2NlZHVyZSBu ZWVkcyB0byBiZSBjYXBhYmxlIG9mIHVwZGF0aW5nIHRoZSBuZXcgU1JMRyBpbmZvcm1hdGlvbi4v VGhpcyBtZWFucyB0aGF0IHRoZSBzaWduYWxpbmcgcHJvY2VkdXJlIG5lZWRzIHRvIGJlIGNhcGFi bGUgb2YgdXBkYXRpbmcgdGhlIG5ldyBTUkxHIGluZm9ybWF0aW9uLjxicj4NCjxicj4NCjxicj4N ClNlY3Rpb24gMy40Ojxicj4NCjxicj4NCi0gRml4IGluZGVudGF0aW9uIGZvciB0aGUgd2hvbGUg c2VjdGlvbi48YnI+DQo8YnI+DQo8YnI+DQpTZWN0aW9uIDQuMTo8YnI+DQo8YnI+DQotIEZpeCBp bmRlbnRhdGlvbiBmb3IgdGhlIGZpcnN0IHBhcmFncmFwaC48YnI+DQo8YnI+DQo8YnI+DQpTZWN0 aW9uIDYuMSAtIFBvbGljeSBDb25maWd1cmF0aW9uOjxicj4NCjxicj4NCi0gRml4IHRoZSBidWxs ZXRzOyBBbGwgYnVsbGV0IHBvaW50cyDigJxv4oCdIGFyZSBzcXVlZXplZCB0b2dldGhlciBpbiBv bmUgcGFyYWdyYXBoLjxicj4NCjxicj4NCjxicj4NClNlY3Rpb24gOC4yIFJPVVRFX1JFQ09SRCBP YmplY3Q8YnI+DQo8YnI+DQotIEZpeCB0aGUgaW5kZW50YXRpb24gb2YgdGhlIHRhYmxlIChhbGln biBpdCB3aXRoIHRoZSB0YWJsZSBpbiA4LjEpPGJyPg0KPGJyPg0KPGJyPg0KU2VjdGlvbiA4LjMg UG9saWN5IENvbnRyb2wgRmFpbHVyZSBFcnJvciBzdWJjb2Rlczxicj4NCjxicj4NCi0gRml4IHRo ZSBpbmRlbnRhdGlvbiBvZiB0aGUgdGFibGUgKGFsaWduIGl0IHdpdGggdGhlIHRhYmxlIGluIDgu MSk8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBNYXkgMTMsIDIwMTYg YXQgODoxNSBQTSwgVmlzaG51IFBhdmFuIEJlZXJhbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZpc2hu dXBhdmFuQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZpc2hudXBhdmFuQGdtYWlsLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ VGhlIFdHIExDIGZvciB0aGlzIGRvY3VtZW50IGlzIG5vdyBjbG9zZWQuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+TWF0dCAoYW5kIG90aGVyIGF1dGhvcnMpLDxicj4NClBsZWFzZSBnbyBhaGVhZCBhbmQgcHVi bGlzaCBhIG5ldyByZXZpc2lvbiBhZGRyZXNzaW5nIHRoZSBtaW5vciBjb21tZW50cyByZWNlaXZl ZCBkdXJpbmcgdGhlIExDLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPi1QYXZhbiAoYW5kIExvdSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIE1heSAx MywgMjAxNiBhdCA2OjA3IFBNLCBTaGFoLCBIaW1hbnNodSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhz aGFoQGNpZW5hLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmhzaGFoQGNpZW5hLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDb25zdGFudGlhJnF1b3Q7LHNlcmlmO2NvbG9yOmJsdWUiPlNvcnJ5IGZvciB0aGUg bGF0ZSByZXBseS4uIChPbiBQVE8uLik8L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDb25zdGFudGlhJnF1b3Q7LHNlcmlmO2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bh bj48L2k+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxpPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvbnN0YW50aWEmcXVvdDss c2VyaWY7Y29sb3I6Ymx1ZSI+V2hpbGUgYWRkaW5nIG9mIOKAnGNvbXBsZXRpb24gZmxhZ+KAnSAo b3Igc2ltaWxhciB0byDigJxwYXJ0aWFsIGJpdOKAnSB1c2VkIGluIEJHUCkgd291bGQgaGF2ZSBi ZWVuIGEgbmljZSBmZWF0dXJlPC9zcGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q29uc3RhbnRpYSZxdW90OyxzZXJpZjtjb2xvcjpibHVlIj50byBoYXZlLCB0aGUgU1JM RyBjb2xsZWN0IGRyYWZ0IGJ5IGl0c2VsZiBpcyBhbiBpbXBvcnRhbnQgZmVhdHVyZSB0byBoYXZl LCBzby4uPC9zcGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q29uc3Rh bnRpYSZxdW90OyxzZXJpZjtjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PC9pPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDb25zdGFudGlhJnF1b3Q7LHNlcmlmO2NvbG9yOmJsdWUi Pkkgc3VwcG9ydCBwcm9ncmVzc2luZyB0aGUgZG9jdW1lbnQgdG8gcHVibGljYXRpb24uPC9zcGFu PjwvaT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q29uc3RhbnRpYSZxdW90Oyxz ZXJpZjtjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDb25zb2xhcztjb2xvcjpibHVlIj5UaGFua3MsPC9zcGFuPjwvaT48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6Ymx1ZSI+SGltYW5zaHU8L3NwYW4+PC9pPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48aT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb25zdGFudGlhJnF1b3Q7LHNlcmlmO2Nv bG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48L2k+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2Vy aWYiPiBUZWFzIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnRlYXMtYm91bmNlc0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnRlYXMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPlZpc2hudSBQYXZhbiBCZWVyYW08YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEFw cmlsIDI4LCAyMDE2IDQ6NDIgUE08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzp0ZWFz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dGVhc0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gW1RlYXNdIFdHIExhc3QgQ2FsbCBvbiBkcmFmdC1pZXRmLXRlYXMtcnN2cC10ZS1z cmxnLWNvbGxlY3QtMDU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQi PkFsbCw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyPg0KVGhpcyBzdGFydHMgYSB0d28gd2VlayB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbjxi cj4NCmRyYWZ0LWlldGYtdGVhcy1yc3ZwLXRlLXNybGctY29sbGVjdC0wNS48YnI+DQo8YnI+DQpU aGUgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBvbiBUaHVyc2RheSwgTWF5IDEydGguIFBs ZWFzZTxicj4NCnNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgVEVBUyBtYWlsaW5nIGxpc3QuPGJy Pg0KPGJyPg0KQXMgaXMgYWx3YXlzIHRoZSBjYXNlLCBwb3NpdGl2ZSBjb21tZW50cywgZS5nLiwg JnF1b3Q7SSd2ZSByZXZpZXdlZCB0aGlzPGJyPg0KZG9jdW1lbnQgYW5kIGJlbGlldmUgaXQgaXMg cmVhZHkgZm9yIHB1YmxpY2F0aW9uJnF1b3Q7LCBhcmUgd2VsY29tZSE8YnI+DQpUaGlzIGlzIHVz ZWZ1bCBhbmQgaW1wb3J0YW50LCBldmVuIGZyb20gYXV0aG9ycy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5Ob3RlLCBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIG9uIHRoaXMgZHJhZnQuPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQpUaGFua3MsPGJyPg0KUGF2 YW4gKGFuZCBMb3UpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_cef3cb4259504638b7ff41cc29b2ac2eXCHRCD001ciscocom_-- From nobody Fri May 27 06:51:05 2016 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 66F1912D528 for ; Fri, 27 May 2016 06:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.811 X-Spam-Level: X-Spam-Status: No, score=-1.811 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=kuatrotechnology.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 pUHo46Yt_7MC for ; Fri, 27 May 2016 06:50:59 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0056.outbound.protection.outlook.com [104.47.2.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F3A112B019 for ; Fri, 27 May 2016 06:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kuatrotechnology.onmicrosoft.com; s=selector1-kuatrotech-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ho/ZLybN1k3iNkclgegoD6znMNh6b7UPxo28s+JaUEU=; b=d5guA/ebb/J4eGGrs971ZWXfQGLoHab5ryovv273Xgc8yQEzj0hqXUH4talV88XjjkCyhFxw7urZGDGIePszj7xyZhYmeyXSNGXgrxLEcQhQByXTMBf2uyhqNSUVi8wwh6Pe4nrErEvKWq6pSRumGvo+tCAB13uPYUXzTIEX0jI= Received: from VI1PR06MB1488.eurprd06.prod.outlook.com (10.164.86.30) by VI1PR06MB1487.eurprd06.prod.outlook.com (10.164.86.29) with Microsoft SMTP Server (TLS) id 15.1.506.2; Fri, 27 May 2016 13:50:53 +0000 Received: from VI1PR06MB1488.eurprd06.prod.outlook.com ([10.164.86.30]) by VI1PR06MB1488.eurprd06.prod.outlook.com ([10.164.86.30]) with mapi id 15.01.0506.009; Fri, 27 May 2016 13:50:53 +0000 From: Xufeng Liu To: Igor Bryskin , Leeyoung , Vishnu Pavan Beeram , Oscar Gonzalez De Dios , Tarek Saad , "Himanshu Shah" , Lou Berger , "BRUNGARD, DEBORAH A (ATTLABS)" , Susan Hares , "Zafar Ali (zali)" , "Khaddam, Mazen (CCI-Atlanta)" , Tony Le , "BELOTTI, SERGIO (SERGIO)" , "Beller, Dieter (Dieter)" , Rajan Rao , "Zhangxian (Xian)" , "xufeng.liu.ietf@gmail.com" , "Belotti, Sergio (Nokia - IT)" , Anurag Sharma Thread-Topic: IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23 Thread-Index: AdG3XGalY3SICAUtQf2LvT1Umc0SGwABG4MAAALVFfAABDuCwAADMsUQACUNjwA= Date: Fri, 27 May 2016 13:50:52 +0000 Message-ID: References: <7AEB3D6833318045B4AE71C2C87E8E172A88ECF3@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908EDD175@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A88EDAD@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908EDD212@dfweml501-mbx> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908EDD212@dfweml501-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=kuatrotech.com; x-originating-ip: [98.191.72.170] x-ms-office365-filtering-correlation-id: 4b6e4177-012f-4419-ea9c-08d38635eb85 x-microsoft-exchange-diagnostics: 1; VI1PR06MB1487; 5:Gm+o1EDbcmCwkcVs9cltbwNHJT+mmwVQu7XLBBwetbh/T/Y5H7SF6uNe1kwUSMdz0qCCBn4h6BJqNA93dYeK5+P/5DZlln9m8UztMSaf3ip/zIG6AFkWdzh5kfhrAxyoBbMuOz3eq77ndRDDjKS56Q==; 24:+QYUuoWftQsckdDQh+mOv9Dt1K7Vvqj8t6Ne6mypiSPuLyDzBhCX1qBpNKWeS+1sagL9FUfFW8sNyklcF7E+DYVAugzCH5/0H2Zby/MaNnQ=; 7:bFmU2svCUUNXD8XmDZGdrTOmSYld1nO2WkcnEmOfEGisHvmAY6Jixs9RFzh8p/Sqwq2xgFaBWiYRNI94sZ01TFBot2Tgjt0ds8DQrf/LoZwbOhSvFOphdRejapg+S8kYordrxYtrSOI7ZY1L6Q2CVXkJ5m+L7z1C5Eo2SArHo6TgMwxo4B5dNAmo3LQh5GXX x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR06MB1487; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(40392960112811)(158342451672863)(50582790962513)(82608151540597)(97927398514766)(95692535739014)(136967371223342)(138986009662008)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040130)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041072)(6043046); SRVR:VI1PR06MB1487; BCL:0; PCL:0; RULEID:; SRVR:VI1PR06MB1487; x-forefront-prvs: 09555FB1AD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377424004)(377454003)(76104003)(5423002)(76576001)(2906002)(9326002)(50986999)(76176999)(230783001)(3280700002)(92566002)(93886004)(122556002)(3660700001)(54356999)(10400500002)(8936002)(19580405001)(81166006)(8666003)(5004730100002)(8676002)(16236675004)(17750500001)(19580395003)(1220700001)(5001770100001)(33656002)(74316001)(586003)(87936001)(189998001)(77096005)(6116002)(790700001)(86362001)(9686002)(2501003)(19625215002)(2900100001)(5002640100001)(2950100001)(3846002)(4326007)(66066001)(19300405004)(102836003)(5003600100002)(15975445007)(11100500001)(5008740100001)(7059030)(921003)(1121003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR06MB1487; H:VI1PR06MB1488.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR06MB14884888E2B10749B965F661B1420VI1PR06MB1488eurp_" MIME-Version: 1.0 X-OriginatorOrg: kuatrotech.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2016 13:50:52.6088 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 99314f4e-50ab-4d4e-a9c6-b21b0c887384 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR06MB1487 Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 27 May 2016 13:51:03 -0000 --_000_VI1PR06MB14884888E2B10749B965F661B1420VI1PR06MB1488eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Young, More below. Thanks, - Xufeng From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: Thursday, May 26, 2016 4:18 PM To: Leeyoung ; Xufeng Liu ; Vishn= u Pavan Beeram ; Oscar Gonzalez De Dios ; Tarek Saad ; Himanshu Shah ; Lou Berger ; BRUNGARD, DEBORAH A (ATTLABS) <= db3546@att.com>; Susan Hares ; Zafar Ali (zali) ; Khaddam, Mazen (CCI-Atlanta) ; Tony Le ; BELOTTI, SERGIO (SERGIO) ; Beller, Dieter (Dieter) ; Rajan Rao <= rrao@infinera.com>; Zhangxian (Xian) ; xufeng.liu.ie= tf@gmail.com; Belotti, Sergio (Nokia - IT) ; Anur= ag Sharma Cc: teas@ietf.org Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23 Young, "Another question on the TTP, can REG/WC (Wavelength Converter) element be = considered as a type of the TTP? If so, I think TTP can be generalized to i= nclude Transponders and REG/WC elements." One important role of TTP is to represent topologically a client/server lay= er adaptor to facilitate inter-layer path computations. REG/WC has no adapt= ation capabilities. WDM augmentation could IMHO model REG/WC as a TTP with no adaptation caps, = however, because this is only pertinent to OCh layer, it should not be part= of the basic TE topology model. Igor From: Leeyoung Sent: Thursday, May 26, 2016 2:58 PM To: Igor Bryskin; Xufeng Liu; Vishnu Pavan Beeram; Oscar Gonzalez De Dios; = Tarek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan= Hares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, S= ERGIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufen= g.liu.ietf@gmail.com; Belotti, Sergio (No= kia - IT); Anurag Sharma Cc: teas@ietf.org Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23 Hi Igor, Thanks for your comments. In OTN, if you consider ODUk as labels, I am fine with that. I thought ODUk= is more or less Switching/Encoding in the ISCD Link model than a label. Youmg, Thanks. Young From: Igor Bryskin Sent: Thursday, May 26, 2016 11:44 AM To: Leeyoung; Xufeng Liu; Vishnu Pavan Beeram; Oscar Gonzalez De Dios; Tare= k Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan Har= es; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, SERGI= O (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.li= u.ietf@gmail.com; Belotti, Sergio (Nokia = - IT); Anurag Sharma Cc: teas@ietf.org Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23 Hi Young, Please, see in-line, Igor From: Leeyoung Sent: Thursday, May 26, 2016 11:31 AM To: Xufeng Liu; Vishnu Pavan Beeram; Igor Bryskin; Oscar Gonzalez De Dios; = Tarek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan= Hares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, S= ERGIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufen= g.liu.ietf@gmail.com; Belotti, Sergio (No= kia - IT); Anurag Sharma Cc: teas@ietf.org Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23 Hi Xufeng, Thanks for this update. Your notes are always very helpful to understand th= e latest progress of this draft. I have a few questions on the potentially adding model for labels for the c= onnectivity matrix. 1. You said: For each label o exclusivity (true/false) Do you mean this bitmap? [Xufeng] This is the LINK_LABEL_EXCLUSIVITY in RFC 7579. 2. Are you aware of label restrictions applied for the connectivity ma= trix other than WSON? If so, then this model addition makes sense; if not, = then we can add the label model for the connectivity matrix in the WSON YAN= G model. If the extent to which label model addition is not really a major = constraint in the switching technologies other than WSON, it would be worth= while to evaluate if we should do label restriction model in a generic way = (per this draft) or do it in WSON specific way? I am not aware of any labe= l restriction model for the connectivity matrix for GMPLS other than WSON. IB>> We had this discussion many time already. There are physical OTN switc= hes that have constraints on the ODUk type level. For example, a switch can= switch ODU2 from link 1 to link2, but ODU2e from link 1 to only link3. Thi= s is especially true for abstract compound nodes which may represent entire= network domains. As you know abstract TE modes are very important for this= model. So, no, connectivity restriction on a label level does not apply on= ly to WDM. 3. If we were to extend the label model for the connectivity matrix, = I would think we also need to have label restriction model for TTP LLCL as = well. What do you think? IB>> This is actually a good point. Thanks for pointing out. Cheers, Igor Thanks. Young From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Xufeng Liu Sent: Thursday, May 26, 2016 9:48 AM To: Vishnu Pavan Beeram; Igor Bryskin; Oscar Gonzalez De Dios; Tarek Saad; = Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan Hares; Zafa= r Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, SERGIO (SERGI= O); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.liu.ietf@g= mail.com; Belotti, Sergio (Nokia - IT); A= nurag Sharma Cc: teas@ietf.org Subject: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016-05-= 23 Participants: Igor, Xufeng, Pavan, Dieter, Sergio, Himanshu - Information sources > Discussed two use cases related to information sources: 1) Provider applies policies to pick the most preferred. 2) Provider does not apply policies and the decision is done by custome= r. > The model currently supports 1) well, but is not clear on 2). > Agreed to clarify the model by: 1) Change "alt-information-sources" to "information-sources" to include all sources, including the selected one. 2) For use case 1), the applied attribute has the selected value, and "information-sources" list all available sources. For use case 2), the applied attribute does not have value, and "information-sources" list all available sources. - Connectivity Matrix > Discussed the comment from Cyril "to add a Label (Following RFC7579) restrictions". > Participants agreed that such constraint information is useful. > Participants agreed that such constraint information is generic enough to be used in various layers and use cases, including optical OTN, and abstract network topologies. > Participants agreed to send the suggestion TEAS WG to add such information to te-topology model. > The potential model change can be: For each connectivity-matrix entry, add: list of labels list types o inclusive-list o exclusive-list o inclusive-range o exclusive-range For each label o exclusivity (true/false) Working members: please provide any comments. Thanks, - Xufeng Note: Please drop me an email if you need an invite for joining the weekly = call. PS. Meeting on May 30 will be canceled for US holiday. --_000_VI1PR06MB14884888E2B10749B965F661B1420VI1PR06MB1488eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Young,

 

More below.

Thanks,

 

- Xufeng

 

From: Igor Bryskin [mailto:Igor.Bryskin@huawe= i.com]
Sent: Thursday, May 26, 2016 4:18 PM
To: Leeyoung <leeyoung@huawei.com>; Xufeng Liu <xliu@kuatro= tech.com>; Vishnu Pavan Beeram <vbeeram@juniper.net>; Oscar Gonzal= ez De Dios <oscar.gonzalezdedios@telefonica.com>; Tarek Saad <tsaa= d@cisco.com>; Himanshu Shah <hshah@ciena.com>; Lou Berger <lber= ger@labn.net>; BRUNGARD, DEBORAH A (ATTLABS) <db3546@att.com>; Susan Hares <shar= es@ndzh.com>; Zafar Ali (zali) <zali@cisco.com>; Khaddam, Mazen (C= CI-Atlanta) <Mazen.Khaddam@cox.com>; Tony Le <tonyle@juniper.net&g= t;; BELOTTI, SERGIO (SERGIO) <sergio.belotti@alcatel-lucent.com>; Beller, Dieter (Dieter) <dieter.beller@alcatel-lucent.com>; Rajan Ra= o <rrao@infinera.com>; Zhangxian (Xian) <zhang.xian@huawei.com>= ; xufeng.liu.ietf@gmail.com; Belotti, Sergio (Nokia - IT) <sergio.belott= i@nokia.com>; Anurag Sharma <AnSharma@infinera.com>
Cc: teas@ietf.org
Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016= -05-23

 

Young,

 

“Another question on the TTP, can REG/WC (Wavelength Converter) element be= considered as a type of the TTP? If so, I think TTP can be generalized to include Transponders and REG/WC elements.”

 

One important role of = TTP is to represent topologically a client/server layer adaptor to facilita= te inter-layer path computations. REG/WC has no adaptation capabilities.

WDM augmentation could IMHO model REG/WC as a TTP with no adaptation cap= s, however, because this is only pertinent to OCh layer, it should not be p= art of the basic TE topology model.

 

Igor =

 

From: Leeyoung
Sent: Thursday, May 26, 2016 2:58 PM
To: Igor Bryskin; Xufeng Liu; Vishnu Pavan Beeram; Oscar Gonzalez De= Dios; Tarek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS)= ; Susan Hares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BEL= OTTI, SERGIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.liu.ietf@gmail.com; Belotti, Sergio (Nokia - IT); Anurag Sharma
Cc: teas@ietf.org= =
Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016= -05-23

 

Hi Igor,

 

Thanks for your commen= ts.

 

In OTN, if you conside= r ODUk as labels, I am fine with that. I thought ODUk is more or less Switc= hing/Encoding in the ISCD Link model than a label.

 

Youmg,

 

 

Thanks.

Young

 

From: Igor Bryskin
Sent: Thursday, May 26, 2016 11:44 AM
To: Leeyoung; Xufeng Liu; Vishnu Pavan Beeram; Oscar Gonzalez De Dio= s; Tarek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Su= san Hares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI= , SERGIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.liu.ietf@gmail.com; Belotti, Sergio (Nokia - IT); Anurag Sharma
Cc: teas@ietf.org= =
Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016= -05-23

 

Hi Young,

 

Please, see in-line,

 

Igor

 

From: Leeyoung
Sent: Thursday, May 26, 2016 11:31 AM
To: Xufeng Liu; Vishnu Pavan Beeram; Igor Bryskin; Oscar Gonzalez De= Dios; Tarek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS)= ; Susan Hares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BEL= OTTI, SERGIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.liu.ietf@gmail.com; Belotti, Sergio (Nokia - IT); Anurag Sharma
Cc: teas@ietf.org= =
Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016= -05-23

 

Hi Xufeng,<= /span>

 

Thanks for this update= . Your notes are always very helpful to understand the latest progress of t= his draft.

 

I have a few questions= on the potentially adding model for labels for the connectivity matrix.

 

1.&n= bsp;     You said:=

 

         &nb= sp;     For each label

         &nb= sp;     o exclusivity (true/false)

 

Do you mean this bitmap?

[Xufeng] This is the LINK_LABEL_EXCLUSIVITY in= RFC 7579.

 

2.&n= bsp;     Are you aware = of label restrictions applied for the connectivity matrix other than WSON? = If so, then this model addition makes sense; if not, then we can add the la= bel model for the connectivity matrix in the WSON YANG model. If the extent to which label model addition is not= really a major constraint in the switching technologies other than WSON, i= t would be worthwhile to evaluate if we should do label restriction model i= n a generic way (per this draft) or do it in WSON specific way?  I am not aware of any label restricti= on model for the connectivity matrix for GMPLS other than WSON.

IB>> We had this= discussion many time already. There are physical OTN switches that have co= nstraints on the ODUk type level. For example, a switch can switch ODU2 fro= m link 1 to link2, but ODU2e from link 1 to only link3. This is especially true for abstract compound nodes which may = represent entire network domains. As you know abstract TE modes are very im= portant for this model. So, no, connectivity restriction on a label level d= oes not apply only to WDM.

 

 

 

3.&n= bsp;      If we we= re to extend the label model for the connectivity matrix, I would think we = also need to have label restriction model for TTP LLCL as well. What do you= think?

IB>> This is act= ually a good point. Thanks for pointing out.

 

Cheers,

Igor=

 

Thanks.

Young

 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Xufeng Liu
Sent: Thursday, May 26, 2016 9:48 AM
To: Vishnu Pavan Beeram; Igor Bryskin; Oscar Gonzalez De Dios; Tarek= Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan Hare= s; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, SERGIO= (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.liu.ietf@gmail.com; Belotti, Sergio (Nokia - IT); Anurag Sharma
Cc: teas@ietf.org= =
Subject: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2= 016-05-23

 

Participants:

Igor, Xufeng, Pavan, Dieter, Sergio, Himanshu

 

- Information sources

  > Discussed two use cases related to infor= mation sources:

    1) Provider applies policies to p= ick the most preferred.

    2) Provider does not apply polici= es and the decision is done by customer.

  > The model currently supports 1) well, bu= t is not clear on 2).

  > Agreed to clarify the model by:

    1) Change "alt-information-s= ources" to "information-sources" to

       include all sou= rces, including the selected one.

    2) For use case 1), the applied a= ttribute has the selected value, and

       "informati= on-sources" list all available sources.

       For use case 2)= , the applied attribute does not have value, and

       "info= rmation-sources" list all available sources.

 

- Connectivity Matrix

  > Discussed the comment from Cyril "t= o add a Label (Following

    RFC7579) restrictions".=

  > Participants agreed that such constraint= information is useful.

  > Participants agreed that such constraint= information is generic

    enough to be used in various laye= rs and use cases, including optical

    OTN, and abstract network topolog= ies.

  > Participants agreed to send the suggesti= on TEAS WG to add such

    information to te-topology model.=

  > The potential model change can be:<= o:p>

    For each connectivity-matrix entr= y, add:

      list of labels

        list type= s

         &nb= sp;     o inclusive-list

         &nb= sp;     o exclusive-list

         &nb= sp;     o inclusive-range

         &nb= sp;     o exclusive-range

         &nb= sp;     For each label

         &nb= sp;     o exclusivity (true/false)

 

Working members: please provide any comments.

 

Thanks,

 

- Xufeng

 

Note: Please drop me an email if you need an invite = for joining the weekly call.

 

PS. Meeting on May 30 will be canceled for US holida= y.

 

 

--_000_VI1PR06MB14884888E2B10749B965F661B1420VI1PR06MB1488eurp_-- From nobody Fri May 27 08:33:59 2016 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 C461412D588 for ; Fri, 27 May 2016 08:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3ccKuyf2he7 for ; Fri, 27 May 2016 08:33:54 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB4AA12D6B1 for ; Fri, 27 May 2016 08:33:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=52058; q=dns/txt; s=iport; t=1464363234; x=1465572834; h=from:to:cc:subject:date:message-id:mime-version; bh=zIPvpTuC3YE0+kY2sHR4K5A4dgUa8MKre+gqyAcmtKU=; b=lvR1Iq/zzv2YGriW4aEQJa0MFOkcdtLaZgqwOjpj2TI6NAYUhSVxmP10 vg9qII9fbrg0FXfhRPxRt++3yUiG7fTXeEVIYzeByQ4t2IMaN9yZmdrzH SbFrQD4O2Z3KsO0EjIWl1kTmXmTo9ThEtplJbrJMeVordAYI8K0k6aJ1O I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BRAADRZ0hX/4QNJK1CFwOCbA8+Vn0Gt?= =?us-ascii?q?1qCDwENgRAFYySFbR6BFDgUAQEBAQEBAWUnhEMBAQECAiMEBjkTDgQBCBUCFQQ?= =?us-ascii?q?IAQMGAgQZFx0HAwQBDQWILw4ssjaFDYw3AQEBAQEBAQEBAQEBAQEBAQEBAQEBF?= =?us-ascii?q?wUFhiKBdgiCToQcFCYKJgeCMyuCLgWIYYUEilIBhX+FZYI7gWkXhDiIZIYziRg?= =?us-ascii?q?BHgEBQoIGHIEAS24BiEo+fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,374,1459814400"; d="scan'208,217";a="278546879" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 May 2016 15:33:52 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u4RFXqhj031793 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 27 May 2016 15:33:52 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 27 May 2016 11:33:51 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Fri, 27 May 2016 11:33:51 -0400 From: "Tarek Saad (tsaad)" To: "Chenxia (D)" , Himanshu Shah , "Wen, Bin" , "Vishnu Pavan Beeram" , Raqib Jones , "Rakesh Gandhi (rgandhi)" , "Kamran Raza (skraza)" , "xufeng.liu.ietf@gmail.com" , Igor Bryskin , "Zhangxian (Xian)" , =?utf-8?B?UGF3ZcWCIEJyem96b3dza2k=?= , "Anurag Sharma" , Xufeng Liu , =?utf-8?B?UGF3ZcWCIEthY3ptYXJlaw==?= Thread-Topic: MPLS and TE tunnels YANG data model meeting Thread-Index: AQHRuC0r38wJcuvMEE6orGReyfkjWQ== Date: Fri, 27 May 2016 15:33:51 +0000 Message-ID: <5F01580A-8462-4C3E-B353-FBB0C960527E@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.16.0.160506 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.245.137] Content-Type: multipart/alternative; boundary="_000_5F01580A84624C3EB353FBB0C960527Eciscocom_" MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf" , "teas@ietf.org" Subject: Re: [Teas] MPLS and TE tunnels YANG data model meeting X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 27 May 2016 15:33:57 -0000 --_000_5F01580A84624C3EB353FBB0C960527Eciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29weWluZyBXRyBmb3IgZnlpIGFzIGZlZWRiYWNrIGFzIHBlciBhZ3JlZW1lbnQuDQoNClRoYW5r cyBhbGwgZm9yIGF0dGVuZGluZyBtZWV0aW5nIHdlZWtseSBtZWV0aW5nIHRvZGF5LiBCZWxvdyBh cmUgdG9kYXnigJlzIE1vTXMuIEZlZWwgZnJlZSB0byBhZGQgaWYgSSBtaXNzZWQgYW55Lg0KDQpS ZWdhcmRzLA0KVGFyZWsNCg0KRnJpZGF5IE1heSAyNywgMjAxNjoNCj09PT09PT09PT09PT09PT09 PT0NCkFnZW5kYToNCkEuIERpc2N1c3MgbmV3IHVwZGF0ZShzKSB0byBNUExTIHN0YXRpYyBMU1Bz IG1vZHVsZQ0KICAgLSBuZXcgc3RhdGljIExTUCBhdHRyaWJ1dGVzDQogICAtIHN0YXRpYyBiaWRp cmVjdGlvbmFsIExTUHMNCiAgIC0gc3RhdGljIE1CQg0KICAgLSBzdGF0aWMgZW5kLXRvLWVuZCBM U1AgcHJvdGVjdGlvbg0KQi4gRGlzY3VzcyBTUi1URSBuZXcgbW9kdWxlIGRldGFpbHMNCkMuIGhv dyB0byBwcm9jZWVkIHdpdGggc2NoZW1hIG1vdW50DQoNCi0tPiBBSTogdG8gc2VuZCBhIGRvb2Rs ZSBmb3IgU1ItVEUgbWVldGluZw0KDQpBLiBTUi1URToNCj09PT09PT09PQ0KRXhwbGljaXQgcGF0 aDoNCi0gbGFiZWwgKGFscmVhZHkgaGF2ZSBpdCBpbiBURSBtb2RlbCkNCi0gU0lEIGluZGV4DQoN ClR1bm5lbDoNCm5ldzogYmluZGluZy1sYWJlbCAobm90IHNwZWNpZmljIHRvIFNSIHR1bm5lbCkN Cm5ldzogcGVyIHBhdGggInNlZ21lbnQtcm91dGluZyIgYXR0cmlidXRlDQpuZXc6IHBlciBwYXRo IGNvbnN0cmFpbnRzOg0KICAgICAgLSBjb3N0IGxpbWl0DQogICAgICAtIGxpbmsvYWRqLVNJRCBw cm90ZWN0aW9uIHR5cGVzOiBhbnksIHByb3RlY3RlZCwgdW5wcm90ZWN0ZWQNCiAgICAgIC0gaW52 YWxpZGF0aW9uIHRpbWVvdXQNCiAgICAgIC0gaW52YWxpZGF0aW9uIGFjdGlvbg0KICAgICAgICAt IGRyb3ANCiAgICAgICAgLSB0ZWFyDQogICAgICAtIHByZXBlbmQgbGFiZWwocykgcGVyIHBhdGgN CiAgICAgIC0gcHJlcGVuZCBiZ3AtbmV4dC1ob3ANCg0KDQpOZXcgVEUgbGluayBhdHRyaWJ1dGVz IChzdGF0ZS1vbmx5KToNCkRlbGF5Og0K4oCTIFVuaWRpcmVjdGlvbmFsIExpbmsgRGVsYXkgKEQp DQrigJMgTWluL01heCBVbmlkaXJlY3Rpb25hbCBMaW5rIERlbGF5IChETSkNCuKAkyBVbmlkaXJl Y3Rpb25hbCBEZWxheSBWYXJpYXRpb24gKERWKQ0KDQpMb3NzOg0K4oCTIFVuaWRpcmVjdGlvbmFs IExpbmsgTG9zcyAoTCkNCg0KQmFuZHdpZHRoOg0K4oCTIFVuaWRpcmVjdGlvbmFsIFJlc2lkdWFs IEJhbmR3aWR0aCAoQlIpDQrigJMgVW5pZGlyZWN0aW9uYWwgQXZhaWxhYmxlIEJhbmR3aWR0aCAo QkEpDQrigJMgVW5pZGlyZWN0aW9uYWwgVXRpbGl6ZWQgQmFuZHdpZHRoIChCVVRJTCkNCg0KDQpC LiBVcGRhdGUgdG8gTVBMUyBzdGF0aWMgTFNQcw0KTmV3IGF0dHJpYnV0ZXMgZm9yIHN0YXRpYyBM U1BzIG5lZWRlZCB0byBhbGxvY2F0ZSByZXNvdXJjZXMgb24gcGVyIGhvcC9saW5rOg0KLSBCVyB3 aXRoIENUcz8NCi0gcHJpb3JpdHkvcHJlZW1wdGlvbg0KLSBkaXNjdXNzaW9uLCB3aGF0IG9jY3Vy cyBpZiBzdGF0aWMgTFNQcyBpcyBjb250ZW5kaW5nIHdpdGggUlNWUCBhbGxvY2F0aW9uIChhdCBz YW1lIG9yIGRpZmZlcmVudCBwcmlvcml0eSk/DQoNCkJpZGlyZWN0aW9uYWwgU3RhdGljIExTUHM6 DQpPcHRpb24gIzE6DQoNCi0gICAgICAgICAgYXNzb2NpYXRpb24gb2YgZm9yd2FyZC9yZXZlcnNl IHNpYmxpbmdzIG1haW50YWluZWQgaW4gaGllcmFyY2hpY2FsIGNvbmZpZ3VyYXRpb24gKHVuZGVy IHNhbWUgTFNQKG5hbWU9Zm9vKSkNCkxTUChuYW1lPWZvbyk6DQpCVw0KYmlkaXJlY3Rpb25hbA0K Zm9yd2FyZA0KICAgQlcxDQogICBpbi1zZWdtZW50IChpbi1sYWJlbCwgbmV4dC1ob3ApDQogICBv dXQtc2VnbWVudCAob3V0LWxhYmVsKHMpLCBuZXh0LWhvcCkNCnJldmVyc2UNCiAgIEJXMg0KICAg aW4tc2VnbWVudCAoaW4tbGFiZWwsIG5leHQtaG9wKQ0KICAgb3V0LXNlZ21lbnQgKG91dC1sYWJl bChzKSwgbmV4dC1ob3ApDQoNCi0tPiBJbiBjdXJyZW50IG1vZGVsIHRoZSBMU1AgaGFzIG9ubHkg b25lIGNyb3NzLWNvbm5lY3QNCi0tPiB3aWxsIG5lZWQgdG8gaGF2ZSBtdWx0aXBsZSBjcm9zcy1j b25uZWN0cyBwZXIgTFNQDQotLS0+IHRvIHJlYWxpemUgYXN5bW1ldHJpY2FsIGJlaGF2aW9yIChl Zy4gQlcgYWxsb2MpIG5lZWQgdG8gYWxsb3cgY29uZmlnIHVuZGVyIGVhY2ggZm9yd2FyZC9yZXZl cnNlIGxlZw0KDQpPcHRpb24gIzI6DQoNCi0gICAgICAgICAgZm9yd2FyZC9yZXZlcnNlIExTUHMg YXMgc2VwYXJhdGUgZW50cmllcyBpbiB0aGUgc3RhdGljIExTUCBsaXN0DQoNCi0gICAgICAgICAg ZW50cmllcyBoYXZlIGRpZmZlcmVudCBuYW1lcywgYnV0IGFzc29jaWF0ZWQgdXNpbmcgYmVsb3cN Cg0KLSAgICAgICAgICB1c2UgYSBjb25maWd1cmVkIGFzc29jaWF0aW9uLUlEICh0dW5uZWwtSUQg b3Igc2VydmljZS1JRCkgYXMgd2F5IHRvIGFzc29jaWF0ZSBMU1BzDQpMU1AobmFtZT1mb28tZm9y d2FyZCk6DQpiaWRpcmVjdGlvbmFsDQpmb3J3YXJkDQphc3NvY2lhdGlvbiBJRCA9IDEwMDENCmlu LXNlZ21lbnQgKGluLWxhYmVsLCBuZXh0LWhvcCkNCm91dC1zZWdtZW50IChvdXQtbGFiZWwocyks IG5leHQtaG9wKQ0KDQpMU1AobmFtZT1mb28tcmV2ZXJzZSk6DQpiaWRpcmVjdGlvbmFsDQpyZXZl cnNlDQphc3NvY2lhdGlvbiBJRCA9IDEwMDENCmluLXNlZ21lbnQgKGluLWxhYmVsLCBuZXh0LWhv cCkNCm91dC1zZWdtZW50IChvdXQtbGFiZWwocyksIG5leHQtaG9wKQ0KDQpPcHRpb24gIzM6DQoN Ci0gICAgICAgICAgZm9yd2FyZC9yZXZlcnNlIExTUHMgYXMgc2VwYXJhdGUgZW50cmllcyBpbiB0 aGUgc3RhdGljIExTUCBsaXN0DQoNCi0gICAgICAgICAgYm90aCBlbnRyaWVzIGhhdmUgdGhlIHNh bWUgbmFtZSwgYnV0IG5ldyBrZXkgaXMgbmVlZGVkIGlpbiB0aGUgbGlzdCAocm9sZT8sIGUuZy4g c2libGluZzEsIHNpYmxpbmcyLCBldGMuLikNCg0KDQpNQkIgZm9yIFN0YXRpYzoNCjEuIGhvdyB0 byByZWFsaXplIHJlc291cmNlIHNoYXJpbmcgaWYgbmVlZGVkPw0KMi4gY29vcmRpbmF0ZSBzd2l0 Y2hvdmVyIG9uIHRoZSBpbmdyZXNzIHVzaW5nIGNvbmZpZ3VyYXRpb24NCg0KT3B0aW9uIzIgKGFk ZCByb2xlIGluIGxpc3Qgb2YgTFNQcyBrZXkpLCBlLmcuIGtleT0gKG5hbWU9Zm9vLCByb2xlPW1i Yi1zaWJsaW5nMSksIChuYW1lPWZvbywgbWJiLXNpYmxpbmcyKSwgKG5hbWU9Zm9vLCBwYXRoLXBy b3RlY3Qtc2libGluZzEpLCAobmFtZT1mb28sIHBhdGgtcHJvdGVjdC1zaWJsaW5nMikNCg0KTFNQ KGZvbywgbWJiLXNpYmxpbmcxKToNCmluLXNlZ21lbnQgKGluLWxhYmVsLCBuZXh0LWhvcCkNCm91 dC1zZWdtZW50IChvdXQtbGFiZWwocyksIG5leHQtaG9wKQ0KYXNzb2NpYXRpb24gSUQgPSAxMDAx DQpyb2xlPU1CQiBzaWJsaW5nDQoNCkxTUChmb28sIG1iYi1zaWJsaW5nMik6DQppbi1zZWdtZW50 IChpbi1sYWJlbCwgbmV4dC1ob3ApDQpvdXQtc2VnbWVudCAob3V0LWxhYmVsKHMpLCBuZXh0LWhv cCkNCmFzc29jaWF0aW9uIElEID0gMTAwMQ0Kcm9sZT1NQkIgc2libGluZw0KDQpUMDogdHJhZmZp YyBvbiBMU1AoZm9vMSkNClQxOiBjb25maWd1cmUgTFNQKGZvbzIpIG9uIG1pZChzKQ0KVDI6IG1h cCB0cmFmZmljIHRvIExTUChmb28yKSBvbiBpbmdyZXNzDQpUMzogZGVsZXRlIExTUChmb28xKQ0K DQoNCkJhY2tncm91bmQgKHNuaXBwZXQgZnJvbSBIdWF3ZWnigJlzIE9TIHN1cHBvcnQgZm9yIHN0 YXRpYyBMU1ApOg0KW0xTUkFdIGJpZGlyZWN0aW9uYWwgc3RhdGljLWNyLWxzcCBpbmdyZXNzIFR1 bm5lbDEvMC8wDQpbTFNSQS1iaS1zdGF0aWMtaW5ncmVzcy1UdW5uZWxsLzAvMF0gZm9yd2FyZCBu ZXh0aG9wIDIuMS4xLjIgb3V0LWxhYmVsIDIwIGJhbmR3aWR0aCBjdDAgMTAwMDANCltMU1JBLWJp LXN0YXRpYy1pbmdyZXNzLVR1bm5lbGwvMC8wXSBiYWNrd2FyZCBpbi1sYWJlbCAyMA0KW0xTUkJd YmlkaXJlY3Rpb25hbCBzdGF0aWMtY3ItbHNwIHRyYW5zaXQgbHNwMQ0KW0xTUkItYmktc3RhdGlj LXRyYW5zaXQtbHNwMV0gZm9yd2FyZCBpbi1sYWJlbCAyMCBuZXh0aG9wIDMuMi4xLjIgb3V0LWxh YmVsIDQwIGJhbmR3aWR0aCBjdDAgMTAwMDANCltMU1JCLWJpLXN0YXRpYy10cmFuc2l0LWxzcDFd IGJhY2t3YXJkIGluLWxhYmVsIDE2IG5leHRob3AgMi4xLjEuMSBvdXQtbGFiZWwgMjAgYmFuZHdp ZHRoIGN0MCAxMDAwMA0KW0xTUkNdIGJpZGlyZWN0aW9uYWwgc3RhdGljLWNyLWxzcCBlZ3Jlc3Mg bHNwMQ0KW0xTUkMtYmktc3RhdGljLWVncmVzcy1sc3AxXSBmb3J3YXJkIGluLWxhYmVsIDQwIGxz cmlkIDEuMS4xLjEgdHVubmVsLWlkIDEwMA0KDQpSZWdhcmRzLA0KVGFyZWsNCg0KDQpGcm9tOiB0 c2FhZEBjaXNjby5jb20NCldoZW46IDEwOjAwIEFNIC0gMTE6MDAgQU0gTWF5IDI3LCAyMDE2DQpT dWJqZWN0OiBNUExTIGFuZCBURSB0dW5uZWxzIFlBTkcgZGF0YSBtb2RlbCBtZWV0aW5nDQpMb2Nh dGlvbjogd2ViZXgNCg0KDQpSZWZyZXNoaW5nIGludml0ZSBmb3IgTVBMUyBhbmQgVEUgdHVubmVs cyBZQU5HIGRhdGEgbW9kZWwgbWVldGluZy4gUGxlYXNlIGZvcndhcmQgdG8gYW55b25lIEkgbWlz c2VkLg0KDQoNCg0KDQoNCg0KDQoNCg0KLS0gRG8gbm90IGRlbGV0ZSBvciBjaGFuZ2UgYW55IG9m IHRoZSBmb2xsb3dpbmcgdGV4dC4gLS0NCg0KDQpKb2luIFdlYkV4IG1lZXRpbmc8aHR0cHM6Ly9j aXNjby53ZWJleC5jb20vY2lzY29zYWxlcy9qLnBocD9NVElEPW1jMDU5ODJmMmQzYzQwNDJkZjIw YzJkZjU2ZjNjYzEyNz4NCk1lZXRpbmcgbnVtYmVyOiAyMDEgOTY2IDY5Mg0KTWVldGluZyBwYXNz d29yZDogM2p3TVJYRWQNCg0KDQpJZiB5b3UgYXJlIGEgaG9zdCwgZ28gaGVyZTxodHRwczovL2Np c2NvLndlYmV4LmNvbS9jaXNjb3NhbGVzL2oucGhwP01USUQ9bWU3ZjY1NDYyZWIyNTFkMjA1Yzhl MjE2NjhlNTE0ZWU3PiB0byB2aWV3IGhvc3QgaW5mb3JtYXRpb24uDQoNCkpvaW4gYnkgcGhvbmUN CisxLTQwOC01MjUtNjgwMCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpDQorMS04NjYt NDMyLTk5MDMgQ2FsbC1pbiB0b2xsLWZyZWUgbnVtYmVyIChVUy9DYW5hZGEpDQpBY2Nlc3MgY29k ZTogMjAxIDk2NiA2OTINCk51bWVyaWMgbWVldGluZyBwYXNzd29yZDogMjE3OTQxNzINCkdsb2Jh bCBjYWxsLWluIG51bWJlcnM8aHR0cHM6Ly9jaXNjby53ZWJleC5jb20vY2lzY29zYWxlcy9nbG9i YWxjYWxsaW4ucGhwP3NlcnZpY2VUeXBlPU1DJkVEPTM1MTQ5NzMzMiZ0b2xsRnJlZT0xPiB8IFRv bGwtZnJlZSBjYWxsaW5nIHJlc3RyaWN0aW9uczxodHRwczovL3d3dy53ZWJleC5jb20vcGRmL3Rv bGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGY+DQoNCg0KQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8gQ29u dGFjdCBzdXBwb3J0LjxodHRwczovL2Npc2NvLndlYmV4LmNvbS9jaXNjb3NhbGVzL21jPg0KDQpJ TVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxv d3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRv IGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVy LiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBz dWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwg ZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNl c3Npb24uLg0KDQo= --_000_5F01580A84624C3EB353FBB0C960527Eciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <1F58D8846A9D66458C56049FBB0AEC38@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6QXJpYWw7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAy IDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCXBh bm9zZS0xOjIgNyAzIDkgMiAyIDUgMiA0IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpX aW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlNlZ29lIFVJIjsN CglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBh cmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFy Z2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQg NzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE3OTk4NDAy MTA7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEyODU2 OTk3ODIgLTE2ODQyNTM5MTQgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2 OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21z by1sZXZlbC1zdGFydC1hdDoyOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyMC4yNXB0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tZmFyZWFzdC1mb250LWZhbWls eTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBs aXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6NTYuMjVwdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CW1hcmdpbi1sZWZ0OjkyLjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjEyOC4yNXB0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTY0LjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJn aW4tbGVmdDoyMDAuMjVwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjM2LjI1cHQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgltYXJnaW4tbGVmdDoyNzIuMjVwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1s ZWZ0OjMwOC4yNXB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjIxMTk1MjI1MjA7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEwNzcwNDAxMzggMTYwNjMxODkyOCA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5 ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjI7 DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tZmFy ZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0K LS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaSI+Q29weWluZyBXRyBmb3IgZnlpIGFzIGZlZWRiYWNrIGFzIHBlciBhZ3Jl ZW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+VGhhbmtzIGFsbCBmb3IgYXR0ZW5kaW5n IG1lZXRpbmcgd2Vla2x5IG1lZXRpbmcgdG9kYXkuIEJlbG93IGFyZSB0b2RheeKAmXMgTW9Ncy4g RmVlbCBmcmVlIHRvIGFkZCBpZiBJIG1pc3NlZCBhbnkuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy aSI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5UYXJlazxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkZyaWRheSBNYXkgMjcsIDIwMTY6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PT09PT09PT09PT09PT09PT09PTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkFnZW5kYTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj5BLiBEaXNjdXNzIG5ldyB1cGRhdGUocykgdG8gTVBMUyBzdGF0aWMg TFNQcyBtb2R1bGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsm bmJzcDsgLSBuZXcgc3RhdGljIExTUCBhdHRyaWJ1dGVzPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7IC0gc3RhdGljIGJpZGlyZWN0aW9uYWwgTFNQczxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyAtIHN0YXRp YyBNQkI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsg LSBzdGF0aWMgZW5kLXRvLWVuZCBMU1AgcHJvdGVjdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmkiPkIuIERpc2N1c3MgU1ItVEUgbmV3IG1vZHVsZSBkZXRhaWxzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Qy4gaG93IHRvIHByb2NlZWQgd2l0aCBz Y2hlbWEgbW91bnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4tLSZndDsgQUk6IHRvIHNlbmQg YSBkb29kbGUgZm9yIFNSLVRFIG1lZXRpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD YWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5BLiBT Ui1URTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj49PT09PT09PT08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5FeHBsaWNpdCBwYXRoOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPi0gbGFiZWwgKGFscmVhZHkgaGF2ZSBpdCBp biBURSBtb2RlbCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4tIFNJRCBp bmRleDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlR1bm5lbDo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDYWxpYnJpIj5uZXc6IGJpbmRpbmctbGFiZWwgKG5vdCBzcGVjaWZpYyB0byBT UiB0dW5uZWwpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+bmV3OiBwZXIg cGF0aCAmcXVvdDtzZWdtZW50LXJvdXRpbmcmcXVvdDsgYXR0cmlidXRlPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+bmV3OiBwZXIgcGF0aCBjb25zdHJhaW50czo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgLSBjb3N0IGxpbWl0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gbGluay9hZGotU0lEIHByb3RlY3Rpb24g dHlwZXM6IGFueSwgcHJvdGVjdGVkLCB1bnByb3RlY3RlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIGludmFsaWRh dGlvbiB0aW1lb3V0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gaW52YWxpZGF0aW9uIGFjdGlvbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAtIGRyb3A8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJp Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSB0ZWFyPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOy0gcHJlcGVuZCBsYWJlbChzKSBwZXIgcGF0aDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIHByZXBlbmQg YmdwLW5leHQtaG9wPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+TmV3IFRFIGxpbmsgYXR0cmlidXRlcyAoc3RhdGUt b25seSk6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+RGVsYXk6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+4oCTIFVuaWRpcmVjdGlvbmFsIExpbmsg RGVsYXkgKEQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+4oCTIE1pbi9N YXggVW5pZGlyZWN0aW9uYWwgTGluayBEZWxheSAoRE0pPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaSI+4oCTIFVuaWRpcmVjdGlvbmFsIERlbGF5IFZhcmlhdGlvbiAoRFYpPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+TG9zczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj7igJMgVW5pZGlyZWN0aW9uYWwgTGluayBMb3NzIChMKTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkNhbGlicmkiPkJhbmR3aWR0aDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpIj7igJMgVW5pZGlyZWN0aW9uYWwgUmVzaWR1YWwgQmFuZHdpZHRoIChCUik8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj7igJMgVW5pZGlyZWN0aW9uYWwgQXZhaWxhYmxl IEJhbmR3aWR0aCAoQkEpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+4oCT IFVuaWRpcmVjdGlvbmFsIFV0aWxpemVkIEJhbmR3aWR0aCAoQlVUSUwpPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0ibXNv LWVsZW1lbnQ6cGFyYS1ib3JkZXItZGl2O2JvcmRlcjpub25lO2JvcmRlci1ib3R0b206ZG91Ymxl IHdpbmRvd3RleHQgMi4yNXB0O3BhZGRpbmc6MGNtIDBjbSAxLjBwdCAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJvcmRlcjpub25lO3BhZGRpbmc6MGNtIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5CLiBVcGRhdGUgdG8gTVBMUyBz dGF0aWMgTFNQczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+ TmV3IGF0dHJpYnV0ZXMgZm9yIHN0YXRpYyBMU1BzIG5lZWRlZCB0byBhbGxvY2F0ZSByZXNvdXJj ZXMgb24gcGVyIGhvcC9saW5rOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmki Pi0gQlcgd2l0aCBDVHM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+LSBw cmlvcml0eS9wcmVlbXB0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+ LSBkaXNjdXNzaW9uLCB3aGF0IG9jY3VycyBpZiBzdGF0aWMgTFNQcyBpcyBjb250ZW5kaW5nIHdp dGggUlNWUCBhbGxvY2F0aW9uIChhdCBzYW1lIG9yIGRpZmZlcmVudCBwcmlvcml0eSk/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q2FsaWJyaSI+QmlkaXJlY3Rpb25hbCBTdGF0aWMgTFNQczo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5PcHRpb24gIzE6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTgu MHB0O21zby1saXN0OmwxIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5hc3NvY2lhdGlvbiBvZiBmb3J3 YXJkL3JldmVyc2Ugc2libGluZ3MgbWFpbnRhaW5lZCBpbiBoaWVyYXJjaGljYWwgY29uZmlndXJh dGlvbiAodW5kZXIgc2FtZSBMU1AobmFtZT1mb28pKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkNhbGlicmkiPkxTUChuYW1lPWZvbyk6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaSI+Qlc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5iaWRpcmVj dGlvbmFsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Zm9yd2FyZDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyBCVzE8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsgaW4tc2VnbWVudCAo aW4tbGFiZWwsIG5leHQtaG9wKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmki PiZuYnNwOyZuYnNwOyBvdXQtc2VnbWVudCAob3V0LWxhYmVsKHMpLCBuZXh0LWhvcCk8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5yZXZlcnNlPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7IEJXMjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyBpbi1zZWdtZW50IChpbi1sYWJlbCwgbmV4 dC1ob3ApPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7 IG91dC1zZWdtZW50IChvdXQtbGFiZWwocyksIG5leHQtaG9wKTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNh bGlicmkiPi0tJmd0OyBJbiBjdXJyZW50IG1vZGVsIHRoZSBMU1AgaGFzIG9ubHkgb25lIGNyb3Nz LWNvbm5lY3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4tLSZndDsgd2ls bCBuZWVkIHRvIGhhdmUgbXVsdGlwbGUgY3Jvc3MtY29ubmVjdHMgcGVyIExTUDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPi08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzIj7DoDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4gdG8gcmVhbGl6ZSBhc3ltbWV0cmlj YWwgYmVoYXZpb3IgKGVnLiBCVyBhbGxvYykgbmVlZCB0byBhbGxvdyBjb25maWcNCiB1bmRlciBl YWNoIGZvcndhcmQvcmV2ZXJzZSBsZWc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5PcHRpb24g IzI6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW4tbGVmdDoyMC4yNXB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Zm9yd2FyZC9yZXZlcnNlIExTUHMgYXMgc2VwYXJhdGUg ZW50cmllcyBpbiB0aGUgc3RhdGljIExTUCBsaXN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMC4yNXB0O3RleHQt aW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRM aXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+ PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+ZW50cmll cyBoYXZlDQo8Yj48dT5kaWZmZXJlbnQ8L3U+PC9iPiBuYW1lcywgYnV0IGFzc29jaWF0ZWQgdXNp bmcgYmVsb3c8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIwLjI1cHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlz dDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj51c2UgYSBjb25maWd1cmVkIGFzc29jaWF0aW9u LUlEICh0dW5uZWwtSUQgb3Igc2VydmljZS1JRCkgYXMgd2F5IHRvIGFzc29jaWF0ZSBMU1BzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+TFNQKG5hbWU9Zm9vLWZvcndhcmQp OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPmJpZGlyZWN0aW9uYWw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5mb3J3YXJkPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+YXNzb2NpYXRpb24gSUQgPSAxMDAxPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+aW4tc2VnbWVudCAoaW4tbGFiZWwsIG5leHQtaG9w KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPm91dC1zZWdtZW50IChvdXQt bGFiZWwocyksIG5leHQtaG9wKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmki PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkxTUChuYW1lPWZv by1yZXZlcnNlKTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5iaWRpcmVj dGlvbmFsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+cmV2ZXJzZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPmFzc29jaWF0aW9uIElEID0gMTAwMTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPmluLXNlZ21lbnQgKGluLWxhYmVs LCBuZXh0LWhvcCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5vdXQtc2Vn bWVudCAob3V0LWxhYmVsKHMpLCBuZXh0LWhvcCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5P cHRpb24gIzM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMC4yNXB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Zm9yd2FyZC9yZXZlcnNlIExTUHMgYXMgc2Vw YXJhdGUgZW50cmllcyBpbiB0aGUgc3RhdGljIExTUCBsaXN0PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMC4yNXB0 O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2Fs aWJyaSI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+ Ym90aCBlbnRyaWVzIGhhdmUgdGhlDQo8Yj48dT5zYW1lPC91PjwvYj4gbmFtZSwgYnV0IG5ldyBr ZXkgaXMgbmVlZGVkIGlpbiB0aGUgbGlzdCAocm9sZT8sIGUuZy4gc2libGluZzEsIHNpYmxpbmcy LCBldGMuLikNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXYgc3R5bGU9Im1zby1lbGVtZW50OnBhcmEtYm9yZGVyLWRpdjtib3JkZXI6 bm9uZTtib3JkZXItYm90dG9tOmRvdWJsZSB3aW5kb3d0ZXh0IDIuMjVwdDtwYWRkaW5nOjBjbSAw Y20gMS4wcHQgMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJib3JkZXI6bm9uZTtw YWRkaW5nOjBjbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2Fs aWJyaSI+TUJCIGZvciBTdGF0aWM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48dT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj4xLiBob3cgdG8gcmVhbGl6ZSByZXNvdXJjZSBzaGFyaW5nIGlmIG5l ZWRlZD88bzpwPjwvbzpwPjwvc3Bhbj48L3U+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjx1PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmki PjIuIGNvb3JkaW5hdGUgc3dpdGNob3ZlciBvbiB0aGUgaW5ncmVzcyB1c2luZyBjb25maWd1cmF0 aW9uPG86cD48L286cD48L3NwYW4+PC91PjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5PcHRpb24jMiAoYWRkIHJvbGUg aW4gbGlzdCBvZiBMU1BzIGtleSksIGUuZy4ga2V5PSAobmFtZT1mb28sIHJvbGU9bWJiLXNpYmxp bmcxKSwgKG5hbWU9Zm9vLCBtYmItc2libGluZzIpLCAobmFtZT1mb28sIHBhdGgtcHJvdGVjdC1z aWJsaW5nMSksIChuYW1lPWZvbywgcGF0aC1wcm90ZWN0LXNpYmxpbmcyKTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkNhbGlicmkiPkxTUChmb28sIG1iYi1zaWJsaW5nMSk6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q2FsaWJyaSI+aW4tc2VnbWVudCAoaW4tbGFiZWwsIG5leHQtaG9wKTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPm91dC1zZWdtZW50IChvdXQtbGFiZWwocyks IG5leHQtaG9wKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPmFzc29jaWF0 aW9uIElEID0gMTAwMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPnJvbGU9 TUJCIHNpYmxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5MU1AoZm9vLCBtYmItc2libGlu ZzIpOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPmluLXNlZ21lbnQgKGlu LWxhYmVsLCBuZXh0LWhvcCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5v dXQtc2VnbWVudCAob3V0LWxhYmVsKHMpLCBuZXh0LWhvcCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj5hc3NvY2lhdGlvbiBJRCA9IDEwMDE8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDYWxpYnJpIj5yb2xlPU1CQiBzaWJsaW5nPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2Fs aWJyaSI+VDA6IHRyYWZmaWMgb24gTFNQKGZvbzEpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6Q2FsaWJyaSI+VDE6IGNvbmZpZ3VyZSBMU1AoZm9vMikgb24gbWlkKHMpPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+VDI6IG1hcCB0cmFmZmljIHRvIExTUChmb28yKSBv biBpbmdyZXNzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+VDM6IGRlbGV0 ZSBMU1AoZm9vMSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5CYWNrZ3JvdW5kIChzbmlwcGV0IGZyb20gSHVhd2Vp 4oCZcyBPUyBzdXBwb3J0IGZvciBzdGF0aWMgTFNQKTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj5bTFNSQV0gYmlkaXJlY3Rpb25hbCBzdGF0aWMtY3ItbHNwIGluZ3Jlc3Mg VHVubmVsMS8wLzA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5bTFNSQS1i aS1zdGF0aWMtaW5ncmVzcy1UdW5uZWxsLzAvMF0gZm9yd2FyZCBuZXh0aG9wIDIuMS4xLjIgb3V0 LWxhYmVsIDIwIGJhbmR3aWR0aCBjdDAgMTAwMDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj5bTFNSQS1iaS1zdGF0aWMtaW5ncmVzcy1UdW5uZWxsLzAvMF0gYmFja3dhcmQg aW4tbGFiZWwgMjA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5bTFNSQl1i aWRpcmVjdGlvbmFsIHN0YXRpYy1jci1sc3AgdHJhbnNpdCBsc3AxPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q2FsaWJyaSI+W0xTUkItYmktc3RhdGljLXRyYW5zaXQtbHNwMV0gZm9yd2Fy ZCBpbi1sYWJlbCAyMCBuZXh0aG9wIDMuMi4xLjIgb3V0LWxhYmVsIDQwIGJhbmR3aWR0aCBjdDAg MTAwMDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5bTFNSQi1iaS1zdGF0 aWMtdHJhbnNpdC1sc3AxXSBiYWNrd2FyZCBpbi1sYWJlbCAxNiBuZXh0aG9wIDIuMS4xLjEgb3V0 LWxhYmVsIDIwIGJhbmR3aWR0aCBjdDAgMTAwMDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj5bTFNSQ10gYmlkaXJlY3Rpb25hbCBzdGF0aWMtY3ItbHNwIGVncmVzcyBsc3Ax PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+W0xTUkMtYmktc3RhdGljLWVn cmVzcy1sc3AxXSBmb3J3YXJkIGluLWxhYmVsIDQwIGxzcmlkIDEuMS4xLjEgdHVubmVsLWlkIDEw MDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q2FsaWJyaSI+VGFyZWs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+DQo8 L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPnRzYWFkQGNp c2NvLmNvbTxicj4NCjxiPldoZW46IDwvYj4xMDowMCBBTSAtIDExOjAwIEFNIE1heSAyNywgMjAx NiA8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+TVBMUyBhbmQgVEUgdHVubmVscyBZQU5HIGRhdGEgbW9k ZWwgbWVldGluZzxicj4NCjxiPkxvY2F0aW9uOiA8L2I+d2ViZXg8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2si PlJlZnJlc2hpbmcgaW52aXRlIGZvciBNUExTIGFuZCBURSB0dW5uZWxzIFlBTkcgZGF0YSBtb2Rl bCBtZWV0aW5nLiBQbGVhc2UgZm9yd2FyZCB0byBhbnlvbmUgSSBtaXNzZWQuPGJyPg0KPGJyPg0K PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2si Pjxicj4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OkNhbGlicmk7Y29sb3I6YmxhY2siPjxicj4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6YmxhY2siPjxicj4NCjxicj4NCjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjojNjY2NjY2 Ij48YnI+DQo8YnI+DQotPGEgbmFtZT0iTWFjQmVnaW5XQlhUYWciPjwvYT4tIERvIG5vdCBkZWxl dGUgb3IgY2hhbmdlIGFueSBvZiB0aGUgZm9sbG93aW5nIHRleHQuIC0tPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6IzY2NjY2NiI+DQo8 YnI+DQo8YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9u dC1mYW1pbHk6QXJpYWw7Y29sb3I6IzY2NjY2NiI+PGEgaHJlZj0iaHR0cHM6Ly9jaXNjby53ZWJl eC5jb20vY2lzY29zYWxlcy9qLnBocD9NVElEPW1jMDU5ODJmMmQzYzQwNDJkZjIwYzJkZjU2ZjNj YzEyNyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6IzAwQUZGOSI+Sm9pbiBX ZWJFeCBtZWV0aW5nPC9zcGFuPjwvYT4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjojNjY2NjY2Ij5NZWV0aW5nIG51bWJl cjogMjAxIDk2NiA2OTI8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1m YW1pbHk6QXJpYWw7Y29sb3I6IzY2NjY2NiI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6IzY2NjY2NiI+TWVldGluZyBw YXNzd29yZDo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6 QXJpYWw7Y29sb3I6IzY2NjY2NiI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6IzY2NjY2NiI+M2p3TVJYRWQ8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6IzY2NjY2NiI+ DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTpB cmlhbDtjb2xvcjojNjY2NjY2Ij48YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDs7Y29sb3I6IzY2NjY2NiI+SWYgeW91IGFyZSBhIGhvc3QsDQo8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjojNjY2NjY2Ij48YSBo cmVmPSJodHRwczovL2Npc2NvLndlYmV4LmNvbS9jaXNjb3NhbGVzL2oucGhwP01USUQ9bWU3ZjY1 NDYyZWIyNTFkMjA1YzhlMjE2NjhlNTE0ZWU3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xv cjojMDBBRkY5Ij5nbyBoZXJlPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6IzY2NjY2NiI+DQogdG8gdmlldyBob3N0IGluZm9ybWF0aW9uLjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiM2NjY2NjYi Pjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6 IzY2NjY2NiI+Sm9pbiBieSBwaG9uZTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVw dDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjojNjY2NjY2Ij4NCjxicj4NCjwvc3Bhbj48c3Ryb25n PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiM2 NjY2NjYiPiYjNDM7MS00MDgtNTI1LTY4MDA8L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6IzY2NjY2NiI+IENhbGwtaW4g dG9sbCBudW1iZXIgKFVTL0NhbmFkYSk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41 cHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6IzY2NjY2NiI+DQo8YnI+DQo8L3NwYW4+PHN0cm9u Zz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjoj NjY2NjY2Ij4mIzQzOzEtODY2LTQzMi05OTAzPC9zcGFuPjwvc3Ryb25nPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiM2NjY2NjYiPiBDYWxsLWlu IHRvbGwtZnJlZSBudW1iZXIgKFVTL0NhbmFkYSk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMy41cHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6IzY2NjY2NiI+DQo8YnI+DQo8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6IzY2 NjY2NiI+QWNjZXNzIGNvZGU6IDIwMSA5NjYgNjkyPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTMuNXB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiM2NjY2NjYiPg0KPGJyPg0KPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiM2 NjY2NjYiPk51bWVyaWMgbWVldGluZyBwYXNzd29yZDogMjE3OTQxNzI8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6IzY2NjY2NiI+DQo8 YnI+DQo8YSBocmVmPSJodHRwczovL2Npc2NvLndlYmV4LmNvbS9jaXNjb3NhbGVzL2dsb2JhbGNh bGxpbi5waHA/c2VydmljZVR5cGU9TUMmYW1wO0VEPTM1MTQ5NzMzMiZhbXA7dG9sbEZyZWU9MSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtjb2xvcjojMDBBRkY5Ij5HbG9iYWwgY2FsbC1p biBudW1iZXJzPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtm b250LWZhbWlseTpBcmlhbDtjb2xvcjojNjY2NjY2Ij4gfA0KPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiM2NjY2NjYiPjxhIGhyZWY9 Imh0dHBzOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtjb2xvcjojMDBBRkY5Ij5Ub2xsLWZyZWUgY2FsbGlu ZyByZXN0cmljdGlvbnM8L3NwYW4+PC9hPg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6IzY2NjY2NiI+PGJyPg0KPGJyPg0K Q2FuJ3Qgam9pbiB0aGUgbWVldGluZz8gPGEgaHJlZj0iaHR0cHM6Ly9jaXNjby53ZWJleC5jb20v Y2lzY29zYWxlcy9tYyI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEFGRjkiPkNvbnRhY3Qgc3VwcG9y dC48L3NwYW4+PC9hPg0KPGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 Ny41cHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6I0EwQTBBMCI+SU1QT1JUQU5UIE5PVElDRTog UGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhl ciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hp Y2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlz DQogc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3Mu IElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNv bmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uLjwvc3Bhbj48 YSBuYW1lPSJNYWNFbmRXQlhUYWciPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2Zv bnQtZmFtaWx5OkFyaWFsO2NvbG9yOiM2NjY2NjYiPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPjxicj4NCjxicj4N Cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_5F01580A84624C3EB353FBB0C960527Eciscocom_-- From nobody Fri May 27 08:44:34 2016 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 6C6FB12B02E; Fri, 27 May 2016 08:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGO7qD1eKmXR; Fri, 27 May 2016 08:44:30 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1E0912D6B1; Fri, 27 May 2016 08:35:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=55518; q=dns/txt; s=iport; t=1464363309; x=1465572909; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bJJTv2Zx3tiGjwdHVEHJ4tIyAqsu/XVjKm9MbiZW8/0=; b=Vy48q4imyvZHZE83ns+92g+vg0TP3+h1Qiiae1xbkfx3jSEIG/OY+M5v CZC+DXY/0VisngdX/47nJ4Ft4J3akWzKt2R7+mVSbcJ/YnDK461J7vaXm /R1qzLF8R6kKiTmuOpkjmrja+1Oh+N6ZVh5bTnissaTEzheV6FRRAmqFq 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BRAADRZ0hX/5tdJa1CFwOCbA8+Vn0Gr?= =?us-ascii?q?XqJYIIPAQ2BEAVjJIVtAhyBFDgUAQEBAQEBAWUnhEMBAQECAiMEBjkTDgICAQg?= =?us-ascii?q?RAwECFQQIAQMGAgICGQYRHQcBAgQBDQWIFQMXDiyyNoUNiAcNhCMBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEXBQWGIoF2glaCQ4FZFAwRCQkBFw8HgjMrgi4FiGGFBIo?= =?us-ascii?q?fMwGFf4VlQoF5gWkXhDiIZIYzgTGHZwEeAQFCggYcgQBLbgGISj5/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,374,1459814400"; d="scan'208,217";a="277862564" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 May 2016 15:35:08 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u4RFZ8ic029369 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 27 May 2016 15:35:08 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 27 May 2016 11:35:07 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Fri, 27 May 2016 11:35:07 -0400 From: "Tarek Saad (tsaad)" To: "Chenxia (D)" , Himanshu Shah , "Wen, Bin" , "Vishnu Pavan Beeram" , Raqib Jones , "Rakesh Gandhi (rgandhi)" , "Kamran Raza (skraza)" , "xufeng.liu.ietf@gmail.com" , Igor Bryskin , "Zhangxian (Xian)" , =?utf-8?B?UGF3ZcWCIEJyem96b3dza2k=?= , "Anurag Sharma" , Xufeng Liu , =?utf-8?B?UGF3ZcWCIEthY3ptYXJlaw==?= Thread-Topic: MPLS and TE tunnels YANG data model meeting Thread-Index: AQHRuC0r38wJcuvMEE6orGReyfkjWZ/M6lSA Date: Fri, 27 May 2016 15:35:07 +0000 Message-ID: References: <5F01580A-8462-4C3E-B353-FBB0C960527E@cisco.com> In-Reply-To: <5F01580A-8462-4C3E-B353-FBB0C960527E@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.16.0.160506 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.245.137] Content-Type: multipart/alternative; boundary="_000_DA890DD196B24A63A6D5E174EF651C66ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , "teas@ietf.org" Subject: Re: [Teas] MPLS and TE tunnels YANG data model meeting X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 27 May 2016 15:44:32 -0000 --_000_DA890DD196B24A63A6D5E174EF651C66ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29ycmVjdGluZyBtcGxzIFdHIGFsaWFzLA0KDQpGcm9tOiBUYXJlayBTYWFkIDx0c2FhZEBjaXNj by5jb20+DQpEYXRlOiBGcmlkYXksIE1heSAyNywgMjAxNiBhdCAxMTozMyBBTQ0KVG86ICJDaGVu eGlhIChEKSIgPGplc2NpYS5jaGVueGlhQGh1YXdlaS5jb20+LCBIaW1hbnNodSBTaGFoIDxoc2hh aEBjaWVuYS5jb20+LCAiV2VuLCBCaW4iIDxCaW5fV2VuQGNhYmxlLmNvbWNhc3QuY29tPiwgVmlz aG51IFBhdmFuIEJlZXJhbSA8dmJlZXJhbUBqdW5pcGVyLm5ldD4sIFJhcWliIEpvbmVzIDxyYXFp YkBCcm9jYWRlLmNvbT4sICJSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKSIgPHJnYW5kaGlAY2lzY28u Y29tPiwgIkthbXJhbiBSYXphIChza3JhemEpIiA8c2tyYXphQGNpc2NvLmNvbT4sICJ4dWZlbmcu bGl1LmlldGZAZ21haWwuY29tIiA8eHVmZW5nLmxpdS5pZXRmQGdtYWlsLmNvbT4sIElnb3IgQnJ5 c2tpbiA8SWdvci5Ccnlza2luQGh1YXdlaS5jb20+LCAiWmhhbmd4aWFuIChYaWFuKSIgPHpoYW5n LnhpYW5AaHVhd2VpLmNvbT4sIFBhd2XFgiBCcnpvem93c2tpIDxQQnJ6b3pvd3NraUBhZHZhb3B0 aWNhbC5jb20+LCBBbnVyYWcgU2hhcm1hIDxBblNoYXJtYUBpbmZpbmVyYS5jb20+LCBYdWZlbmcg TGl1IDx4bGl1QGt1YXRyb3RlY2guY29tPiwgUGF3ZcWCIEthY3ptYXJlayA8UEthY3ptYXJla0Bh ZHZhb3B0aWNhbC5jb20+DQpDYzogInRlYXNAaWV0Zi5vcmciIDx0ZWFzQGlldGYub3JnPiwgIm1w bHNAaWV0ZiIgPG1wbHNAaWV0Zj4NClN1YmplY3Q6IFJlOiBNUExTIGFuZCBURSB0dW5uZWxzIFlB TkcgZGF0YSBtb2RlbCBtZWV0aW5nDQoNCkNvcHlpbmcgV0cgZm9yIGZ5aSBhcyBmZWVkYmFjayBh cyBwZXIgYWdyZWVtZW50Lg0KDQpUaGFua3MgYWxsIGZvciBhdHRlbmRpbmcgbWVldGluZyB3ZWVr bHkgbWVldGluZyB0b2RheS4gQmVsb3cgYXJlIHRvZGF54oCZcyBNb01zLiBGZWVsIGZyZWUgdG8g YWRkIGlmIEkgbWlzc2VkIGFueS4NCg0KUmVnYXJkcywNClRhcmVrDQoNCkZyaWRheSBNYXkgMjcs IDIwMTY6DQo9PT09PT09PT09PT09PT09PT09DQpBZ2VuZGE6DQpBLiBEaXNjdXNzIG5ldyB1cGRh dGUocykgdG8gTVBMUyBzdGF0aWMgTFNQcyBtb2R1bGUNCiAgIC0gbmV3IHN0YXRpYyBMU1AgYXR0 cmlidXRlcw0KICAgLSBzdGF0aWMgYmlkaXJlY3Rpb25hbCBMU1BzDQogICAtIHN0YXRpYyBNQkIN CiAgIC0gc3RhdGljIGVuZC10by1lbmQgTFNQIHByb3RlY3Rpb24NCkIuIERpc2N1c3MgU1ItVEUg bmV3IG1vZHVsZSBkZXRhaWxzDQpDLiBob3cgdG8gcHJvY2VlZCB3aXRoIHNjaGVtYSBtb3VudA0K DQotLT4gQUk6IHRvIHNlbmQgYSBkb29kbGUgZm9yIFNSLVRFIG1lZXRpbmcNCg0KQS4gU1ItVEU6 DQo9PT09PT09PT0NCkV4cGxpY2l0IHBhdGg6DQotIGxhYmVsIChhbHJlYWR5IGhhdmUgaXQgaW4g VEUgbW9kZWwpDQotIFNJRCBpbmRleA0KDQpUdW5uZWw6DQpuZXc6IGJpbmRpbmctbGFiZWwgKG5v dCBzcGVjaWZpYyB0byBTUiB0dW5uZWwpDQpuZXc6IHBlciBwYXRoICJzZWdtZW50LXJvdXRpbmci IGF0dHJpYnV0ZQ0KbmV3OiBwZXIgcGF0aCBjb25zdHJhaW50czoNCiAgICAgIC0gY29zdCBsaW1p dA0KICAgICAgLSBsaW5rL2Fkai1TSUQgcHJvdGVjdGlvbiB0eXBlczogYW55LCBwcm90ZWN0ZWQs IHVucHJvdGVjdGVkDQogICAgICAtIGludmFsaWRhdGlvbiB0aW1lb3V0DQogICAgICAtIGludmFs aWRhdGlvbiBhY3Rpb24NCiAgICAgICAgLSBkcm9wDQogICAgICAgIC0gdGVhcg0KICAgICAgLSBw cmVwZW5kIGxhYmVsKHMpIHBlciBwYXRoDQogICAgICAtIHByZXBlbmQgYmdwLW5leHQtaG9wDQoN Cg0KTmV3IFRFIGxpbmsgYXR0cmlidXRlcyAoc3RhdGUtb25seSk6DQpEZWxheToNCuKAkyBVbmlk aXJlY3Rpb25hbCBMaW5rIERlbGF5IChEKQ0K4oCTIE1pbi9NYXggVW5pZGlyZWN0aW9uYWwgTGlu ayBEZWxheSAoRE0pDQrigJMgVW5pZGlyZWN0aW9uYWwgRGVsYXkgVmFyaWF0aW9uIChEVikNCg0K TG9zczoNCuKAkyBVbmlkaXJlY3Rpb25hbCBMaW5rIExvc3MgKEwpDQoNCkJhbmR3aWR0aDoNCuKA kyBVbmlkaXJlY3Rpb25hbCBSZXNpZHVhbCBCYW5kd2lkdGggKEJSKQ0K4oCTIFVuaWRpcmVjdGlv bmFsIEF2YWlsYWJsZSBCYW5kd2lkdGggKEJBKQ0K4oCTIFVuaWRpcmVjdGlvbmFsIFV0aWxpemVk IEJhbmR3aWR0aCAoQlVUSUwpDQoNCg0KQi4gVXBkYXRlIHRvIE1QTFMgc3RhdGljIExTUHMNCk5l dyBhdHRyaWJ1dGVzIGZvciBzdGF0aWMgTFNQcyBuZWVkZWQgdG8gYWxsb2NhdGUgcmVzb3VyY2Vz IG9uIHBlciBob3AvbGluazoNCi0gQlcgd2l0aCBDVHM/DQotIHByaW9yaXR5L3ByZWVtcHRpb24N Ci0gZGlzY3Vzc2lvbiwgd2hhdCBvY2N1cnMgaWYgc3RhdGljIExTUHMgaXMgY29udGVuZGluZyB3 aXRoIFJTVlAgYWxsb2NhdGlvbiAoYXQgc2FtZSBvciBkaWZmZXJlbnQgcHJpb3JpdHkpPw0KDQpC aWRpcmVjdGlvbmFsIFN0YXRpYyBMU1BzOg0KT3B0aW9uICMxOg0KDQotICAgICAgICAgIGFzc29j aWF0aW9uIG9mIGZvcndhcmQvcmV2ZXJzZSBzaWJsaW5ncyBtYWludGFpbmVkIGluIGhpZXJhcmNo aWNhbCBjb25maWd1cmF0aW9uICh1bmRlciBzYW1lIExTUChuYW1lPWZvbykpDQpMU1AobmFtZT1m b28pOg0KQlcNCmJpZGlyZWN0aW9uYWwNCmZvcndhcmQNCiAgIEJXMQ0KICAgaW4tc2VnbWVudCAo aW4tbGFiZWwsIG5leHQtaG9wKQ0KICAgb3V0LXNlZ21lbnQgKG91dC1sYWJlbChzKSwgbmV4dC1o b3ApDQpyZXZlcnNlDQogICBCVzINCiAgIGluLXNlZ21lbnQgKGluLWxhYmVsLCBuZXh0LWhvcCkN CiAgIG91dC1zZWdtZW50IChvdXQtbGFiZWwocyksIG5leHQtaG9wKQ0KDQotLT4gSW4gY3VycmVu dCBtb2RlbCB0aGUgTFNQIGhhcyBvbmx5IG9uZSBjcm9zcy1jb25uZWN0DQotLT4gd2lsbCBuZWVk IHRvIGhhdmUgbXVsdGlwbGUgY3Jvc3MtY29ubmVjdHMgcGVyIExTUA0KLS0tPiB0byByZWFsaXpl IGFzeW1tZXRyaWNhbCBiZWhhdmlvciAoZWcuIEJXIGFsbG9jKSBuZWVkIHRvIGFsbG93IGNvbmZp ZyB1bmRlciBlYWNoIGZvcndhcmQvcmV2ZXJzZSBsZWcNCg0KT3B0aW9uICMyOg0KDQotICAgICAg ICAgIGZvcndhcmQvcmV2ZXJzZSBMU1BzIGFzIHNlcGFyYXRlIGVudHJpZXMgaW4gdGhlIHN0YXRp YyBMU1AgbGlzdA0KDQotICAgICAgICAgIGVudHJpZXMgaGF2ZSBkaWZmZXJlbnQgbmFtZXMsIGJ1 dCBhc3NvY2lhdGVkIHVzaW5nIGJlbG93DQoNCi0gICAgICAgICAgdXNlIGEgY29uZmlndXJlZCBh c3NvY2lhdGlvbi1JRCAodHVubmVsLUlEIG9yIHNlcnZpY2UtSUQpIGFzIHdheSB0byBhc3NvY2lh dGUgTFNQcw0KTFNQKG5hbWU9Zm9vLWZvcndhcmQpOg0KYmlkaXJlY3Rpb25hbA0KZm9yd2FyZA0K YXNzb2NpYXRpb24gSUQgPSAxMDAxDQppbi1zZWdtZW50IChpbi1sYWJlbCwgbmV4dC1ob3ApDQpv dXQtc2VnbWVudCAob3V0LWxhYmVsKHMpLCBuZXh0LWhvcCkNCg0KTFNQKG5hbWU9Zm9vLXJldmVy c2UpOg0KYmlkaXJlY3Rpb25hbA0KcmV2ZXJzZQ0KYXNzb2NpYXRpb24gSUQgPSAxMDAxDQppbi1z ZWdtZW50IChpbi1sYWJlbCwgbmV4dC1ob3ApDQpvdXQtc2VnbWVudCAob3V0LWxhYmVsKHMpLCBu ZXh0LWhvcCkNCg0KT3B0aW9uICMzOg0KDQotICAgICAgICAgIGZvcndhcmQvcmV2ZXJzZSBMU1Bz IGFzIHNlcGFyYXRlIGVudHJpZXMgaW4gdGhlIHN0YXRpYyBMU1AgbGlzdA0KDQotICAgICAgICAg IGJvdGggZW50cmllcyBoYXZlIHRoZSBzYW1lIG5hbWUsIGJ1dCBuZXcga2V5IGlzIG5lZWRlZCBp aW4gdGhlIGxpc3QgKHJvbGU/LCBlLmcuIHNpYmxpbmcxLCBzaWJsaW5nMiwgZXRjLi4pDQoNCg0K TUJCIGZvciBTdGF0aWM6DQoxLiBob3cgdG8gcmVhbGl6ZSByZXNvdXJjZSBzaGFyaW5nIGlmIG5l ZWRlZD8NCjIuIGNvb3JkaW5hdGUgc3dpdGNob3ZlciBvbiB0aGUgaW5ncmVzcyB1c2luZyBjb25m aWd1cmF0aW9uDQoNCk9wdGlvbiMyIChhZGQgcm9sZSBpbiBsaXN0IG9mIExTUHMga2V5KSwgZS5n LiBrZXk9IChuYW1lPWZvbywgcm9sZT1tYmItc2libGluZzEpLCAobmFtZT1mb28sIG1iYi1zaWJs aW5nMiksIChuYW1lPWZvbywgcGF0aC1wcm90ZWN0LXNpYmxpbmcxKSwgKG5hbWU9Zm9vLCBwYXRo LXByb3RlY3Qtc2libGluZzIpDQoNCkxTUChmb28sIG1iYi1zaWJsaW5nMSk6DQppbi1zZWdtZW50 IChpbi1sYWJlbCwgbmV4dC1ob3ApDQpvdXQtc2VnbWVudCAob3V0LWxhYmVsKHMpLCBuZXh0LWhv cCkNCmFzc29jaWF0aW9uIElEID0gMTAwMQ0Kcm9sZT1NQkIgc2libGluZw0KDQpMU1AoZm9vLCBt YmItc2libGluZzIpOg0KaW4tc2VnbWVudCAoaW4tbGFiZWwsIG5leHQtaG9wKQ0Kb3V0LXNlZ21l bnQgKG91dC1sYWJlbChzKSwgbmV4dC1ob3ApDQphc3NvY2lhdGlvbiBJRCA9IDEwMDENCnJvbGU9 TUJCIHNpYmxpbmcNCg0KVDA6IHRyYWZmaWMgb24gTFNQKGZvbzEpDQpUMTogY29uZmlndXJlIExT UChmb28yKSBvbiBtaWQocykNClQyOiBtYXAgdHJhZmZpYyB0byBMU1AoZm9vMikgb24gaW5ncmVz cw0KVDM6IGRlbGV0ZSBMU1AoZm9vMSkNCg0KDQpCYWNrZ3JvdW5kIChzbmlwcGV0IGZyb20gSHVh d2Vp4oCZcyBPUyBzdXBwb3J0IGZvciBzdGF0aWMgTFNQKToNCltMU1JBXSBiaWRpcmVjdGlvbmFs IHN0YXRpYy1jci1sc3AgaW5ncmVzcyBUdW5uZWwxLzAvMA0KW0xTUkEtYmktc3RhdGljLWluZ3Jl c3MtVHVubmVsbC8wLzBdIGZvcndhcmQgbmV4dGhvcCAyLjEuMS4yIG91dC1sYWJlbCAyMCBiYW5k d2lkdGggY3QwIDEwMDAwDQpbTFNSQS1iaS1zdGF0aWMtaW5ncmVzcy1UdW5uZWxsLzAvMF0gYmFj a3dhcmQgaW4tbGFiZWwgMjANCltMU1JCXWJpZGlyZWN0aW9uYWwgc3RhdGljLWNyLWxzcCB0cmFu c2l0IGxzcDENCltMU1JCLWJpLXN0YXRpYy10cmFuc2l0LWxzcDFdIGZvcndhcmQgaW4tbGFiZWwg MjAgbmV4dGhvcCAzLjIuMS4yIG91dC1sYWJlbCA0MCBiYW5kd2lkdGggY3QwIDEwMDAwDQpbTFNS Qi1iaS1zdGF0aWMtdHJhbnNpdC1sc3AxXSBiYWNrd2FyZCBpbi1sYWJlbCAxNiBuZXh0aG9wIDIu MS4xLjEgb3V0LWxhYmVsIDIwIGJhbmR3aWR0aCBjdDAgMTAwMDANCltMU1JDXSBiaWRpcmVjdGlv bmFsIHN0YXRpYy1jci1sc3AgZWdyZXNzIGxzcDENCltMU1JDLWJpLXN0YXRpYy1lZ3Jlc3MtbHNw MV0gZm9yd2FyZCBpbi1sYWJlbCA0MCBsc3JpZCAxLjEuMS4xIHR1bm5lbC1pZCAxMDANCg0KUmVn YXJkcywNClRhcmVrDQoNCg0KRnJvbTogdHNhYWRAY2lzY28uY29tDQpXaGVuOiAxMDowMCBBTSAt IDExOjAwIEFNIE1heSAyNywgMjAxNg0KU3ViamVjdDogTVBMUyBhbmQgVEUgdHVubmVscyBZQU5H IGRhdGEgbW9kZWwgbWVldGluZw0KTG9jYXRpb246IHdlYmV4DQoNCg0KUmVmcmVzaGluZyBpbnZp dGUgZm9yIE1QTFMgYW5kIFRFIHR1bm5lbHMgWUFORyBkYXRhIG1vZGVsIG1lZXRpbmcuIFBsZWFz ZSBmb3J3YXJkIHRvIGFueW9uZSBJIG1pc3NlZC4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCi0t IERvIG5vdCBkZWxldGUgb3IgY2hhbmdlIGFueSBvZiB0aGUgZm9sbG93aW5nIHRleHQuIC0tDQoN Cg0KSm9pbiBXZWJFeCBtZWV0aW5nPGh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Npc2Nvc2FsZXMv ai5waHA/TVRJRD1tYzA1OTgyZjJkM2M0MDQyZGYyMGMyZGY1NmYzY2MxMjc+DQpNZWV0aW5nIG51 bWJlcjogMjAxIDk2NiA2OTINCk1lZXRpbmcgcGFzc3dvcmQ6IDNqd01SWEVkDQoNCg0KSWYgeW91 IGFyZSBhIGhvc3QsIGdvIGhlcmU8aHR0cHM6Ly9jaXNjby53ZWJleC5jb20vY2lzY29zYWxlcy9q LnBocD9NVElEPW1lN2Y2NTQ2MmViMjUxZDIwNWM4ZTIxNjY4ZTUxNGVlNz4gdG8gdmlldyBob3N0 IGluZm9ybWF0aW9uLg0KDQpKb2luIGJ5IHBob25lDQorMS00MDgtNTI1LTY4MDAgQ2FsbC1pbiB0 b2xsIG51bWJlciAoVVMvQ2FuYWRhKQ0KKzEtODY2LTQzMi05OTAzIENhbGwtaW4gdG9sbC1mcmVl IG51bWJlciAoVVMvQ2FuYWRhKQ0KQWNjZXNzIGNvZGU6IDIwMSA5NjYgNjkyDQpOdW1lcmljIG1l ZXRpbmcgcGFzc3dvcmQ6IDIxNzk0MTcyDQpHbG9iYWwgY2FsbC1pbiBudW1iZXJzPGh0dHBzOi8v Y2lzY28ud2ViZXguY29tL2Npc2Nvc2FsZXMvZ2xvYmFsY2FsbGluLnBocD9zZXJ2aWNlVHlwZT1N QyZFRD0zNTE0OTczMzImdG9sbEZyZWU9MT4gfCBUb2xsLWZyZWUgY2FsbGluZyByZXN0cmljdGlv bnM8aHR0cHM6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMucGRmPg0K DQoNCkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/IENvbnRhY3Qgc3VwcG9ydC48aHR0cHM6Ly9jaXNj by53ZWJleC5jb20vY2lzY29zYWxlcy9tYz4NCg0KSU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5v dGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1h dGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJl IGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24s IHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8g bm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRo IHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLi4NCg0KDQo= --_000_DA890DD196B24A63A6D5E174EF651C66ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <95B6B0FCFE6302488CBF6E56D8FBC747@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6QXJpYWw7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAy IDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCXBh bm9zZS0xOjIgNyAzIDkgMiAyIDUgMiA0IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpX aW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlNlZ29lIFVJIjsN CglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6TWluZ0xpVTsNCglwYW5vc2UtMToyIDIgNSA5IDAgMCAwIDAgMCAwO30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBk aXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRv cDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4t bGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWls U3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpD YWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4w cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERl ZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNzk5ODQwMjEwOw0KCW1zby1s aXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMjg1Njk5NzgyIC0xNjg0 MjUzOTE0IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4 Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3Rh cnQtYXQ6MjsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjAuMjVwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsN Cgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZl bDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCW1hcmdpbi1sZWZ0OjU2LjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVm dDo5Mi4yNXB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxMjguMjVwdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CW1hcmdpbi1sZWZ0OjE2NC4yNXB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjAw LjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIzNi4yNXB0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFy Z2luLWxlZnQ6MjcyLjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDozMDguMjVw dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMQ0KCXttc28tbGlzdC1pZDoyMTE5NTIyNTIwOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0K CW1zby1saXN0LXRlbXBsYXRlLWlkczoxMDc3MDQwMTM4IDE2MDYzMTg5MjggNjc2OTg2OTEgNjc2 OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2 OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoyOw0KCW1zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWZhcmVhc3QtZm9udC1m YW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9 DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBs aXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21h cmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+ DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGli cmkiPkNvcnJlY3RpbmcgbXBscyBXRyBhbGlhcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5UYXJlayBTYWFkICZsdDt0c2FhZEBjaXNj by5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPkZyaWRheSwgTWF5IDI3LCAyMDE2IGF0IDExOjMz IEFNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtDaGVueGlhIChEKSZxdW90OyAmbHQ7amVzY2lhLmNo ZW54aWFAaHVhd2VpLmNvbSZndDssIEhpbWFuc2h1IFNoYWggJmx0O2hzaGFoQGNpZW5hLmNvbSZn dDssICZxdW90O1dlbiwgQmluJnF1b3Q7ICZsdDtCaW5fV2VuQGNhYmxlLmNvbWNhc3QuY29tJmd0 OywgVmlzaG51IFBhdmFuIEJlZXJhbSAmbHQ7dmJlZXJhbUBqdW5pcGVyLm5ldCZndDssIFJhcWli IEpvbmVzICZsdDtyYXFpYkBCcm9jYWRlLmNvbSZndDssICZxdW90O1Jha2VzaCBHYW5kaGkgKHJn YW5kaGkpJnF1b3Q7ICZsdDtyZ2FuZGhpQGNpc2NvLmNvbSZndDssICZxdW90O0thbXJhbg0KIFJh emEgKHNrcmF6YSkmcXVvdDsgJmx0O3NrcmF6YUBjaXNjby5jb20mZ3Q7LCAmcXVvdDt4dWZlbmcu bGl1LmlldGZAZ21haWwuY29tJnF1b3Q7ICZsdDt4dWZlbmcubGl1LmlldGZAZ21haWwuY29tJmd0 OywgSWdvciBCcnlza2luICZsdDtJZ29yLkJyeXNraW5AaHVhd2VpLmNvbSZndDssICZxdW90O1po YW5neGlhbiAoWGlhbikmcXVvdDsgJmx0O3poYW5nLnhpYW5AaHVhd2VpLmNvbSZndDssIFBhd2XF giBCcnpvem93c2tpICZsdDtQQnJ6b3pvd3NraUBhZHZhb3B0aWNhbC5jb20mZ3Q7LCBBbnVyYWcg U2hhcm1hICZsdDtBblNoYXJtYUBpbmZpbmVyYS5jb20mZ3Q7LA0KIFh1ZmVuZyBMaXUgJmx0O3hs aXVAa3VhdHJvdGVjaC5jb20mZ3Q7LCBQYXdlxYIgS2Fjem1hcmVrICZsdDtQS2Fjem1hcmVrQGFk dmFvcHRpY2FsLmNvbSZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Ok1pbmdMaVU7 Y29sb3I6YmxhY2siPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaTtjb2xvcjpibGFjayI+Q2M6IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNhbGlicmk7Y29sb3I6YmxhY2siPiZxdW90O3RlYXNAaWV0Zi5vcmcmcXVvdDsgJmx0O3RlYXNA aWV0Zi5vcmcmZ3Q7LCAmcXVvdDttcGxzQGlldGYmcXVvdDsgJmx0O21wbHNAaWV0ZiZndDs8YnI+ DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IE1QTFMgYW5kIFRFIHR1bm5lbHMgWUFORyBkYXRhIG1vZGVs IG1lZXRpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj5Db3B5aW5nIFdHIGZvciBmeWkgYXMgZmVlZGJhY2sgYXMgcGVyIGFncmVl bWVudC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5UaGFua3MgYWxsIGZvciBhdHRlbmRpbmcg bWVldGluZyB3ZWVrbHkgbWVldGluZyB0b2RheS4gQmVsb3cgYXJlIHRvZGF54oCZcyBNb01zLiBG ZWVsIGZyZWUgdG8gYWRkIGlmIEkgbWlzc2VkIGFueS48L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJp Ij5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlRhcmVrPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+RnJpZGF5IE1heSAyNywgMjAxNjo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj49PT09PT09PT09PT09PT09PT09PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+QWdlbmRhOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmkiPkEuIERpc2N1c3MgbmV3IHVwZGF0ZShzKSB0byBNUExTIHN0YXRpYyBM U1BzIG1vZHVsZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZu YnNwOyAtIG5ldyBzdGF0aWMgTFNQIGF0dHJpYnV0ZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsgLSBzdGF0aWMgYmlkaXJlY3Rpb25hbCBMU1BzPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7IC0gc3RhdGlj IE1CQjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyAt IHN0YXRpYyBlbmQtdG8tZW5kIExTUCBwcm90ZWN0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaSI+Qi4gRGlzY3VzcyBTUi1URSBuZXcgbW9kdWxlIGRldGFpbHM8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5DLiBob3cgdG8gcHJvY2VlZCB3aXRoIHNj aGVtYSBtb3VudDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPi0tJmd0OyBBSTogdG8gc2VuZCBh IGRvb2RsZSBmb3IgU1ItVEUgbWVldGluZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNh bGlicmkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkEuIFNS LVRFOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPj09PT09PT09PTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkV4cGxpY2l0IHBhdGg6PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+LSBsYWJlbCAoYWxyZWFkeSBoYXZlIGl0IGlu IFRFIG1vZGVsKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPi0gU0lEIGlu ZGV4PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+VHVubmVsOjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OkNhbGlicmkiPm5ldzogYmluZGluZy1sYWJlbCAobm90IHNwZWNpZmljIHRvIFNS IHR1bm5lbCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5uZXc6IHBlciBw YXRoICZxdW90O3NlZ21lbnQtcm91dGluZyZxdW90OyBhdHRyaWJ1dGU8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDYWxpYnJpIj5uZXc6IHBlciBwYXRoIGNvbnN0cmFpbnRzOjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAtIGNvc3QgbGltaXQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBsaW5rL2Fkai1TSUQgcHJvdGVjdGlvbiB0 eXBlczogYW55LCBwcm90ZWN0ZWQsIHVucHJvdGVjdGVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gaW52YWxpZGF0 aW9uIHRpbWVvdXQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBpbnZhbGlkYXRpb24gYWN0aW9uPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IC0gZHJvcDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmki PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIHRlYXI8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7LSBwcmVwZW5kIGxhYmVsKHMpIHBlciBwYXRoPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gcHJlcGVuZCBi Z3AtbmV4dC1ob3A8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5OZXcgVEUgbGluayBhdHRyaWJ1dGVzIChzdGF0ZS1v bmx5KTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5EZWxheTo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj7igJMgVW5pZGlyZWN0aW9uYWwgTGluayBE ZWxheSAoRCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj7igJMgTWluL01h eCBVbmlkaXJlY3Rpb25hbCBMaW5rIERlbGF5IChETSk8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj7igJMgVW5pZGlyZWN0aW9uYWwgRGVsYXkgVmFyaWF0aW9uIChEVik8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDYWxpYnJpIj5Mb3NzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmkiPuKAkyBVbmlkaXJlY3Rpb25hbCBMaW5rIExvc3MgKEwpPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6Q2FsaWJyaSI+QmFuZHdpZHRoOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGli cmkiPuKAkyBVbmlkaXJlY3Rpb25hbCBSZXNpZHVhbCBCYW5kd2lkdGggKEJSKTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPuKAkyBVbmlkaXJlY3Rpb25hbCBBdmFpbGFibGUg QmFuZHdpZHRoIChCQSk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj7igJMg VW5pZGlyZWN0aW9uYWwgVXRpbGl6ZWQgQmFuZHdpZHRoIChCVVRJTCk8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItYm90dG9tOmRvdWJsZSB3aW5kb3d0ZXh0IDIuMjVwdDtwYWRkaW5nOjBj bSAwY20gMS4wcHQgMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkIuIFVwZGF0ZSB0byBNUExTIHN0YXRp YyBMU1BzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5OZXcg YXR0cmlidXRlcyBmb3Igc3RhdGljIExTUHMgbmVlZGVkIHRvIGFsbG9jYXRlIHJlc291cmNlcyBv biBwZXIgaG9wL2xpbms6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+LSBC VyB3aXRoIENUcz88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4tIHByaW9y aXR5L3ByZWVtcHRpb248L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4tIGRp c2N1c3Npb24sIHdoYXQgb2NjdXJzIGlmIHN0YXRpYyBMU1BzIGlzIGNvbnRlbmRpbmcgd2l0aCBS U1ZQIGFsbG9jYXRpb24gKGF0IHNhbWUgb3IgZGlmZmVyZW50IHByaW9yaXR5KT88L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj5CaWRpcmVjdGlvbmFsIFN0YXRpYyBMU1BzOjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPk9wdGlvbiAjMTo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7 bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTpDYWxpYnJpIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNw YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj5hc3NvY2lhdGlvbiBvZiBmb3J3YXJkL3JldmVyc2Ugc2libGluZ3Mg bWFpbnRhaW5lZCBpbiBoaWVyYXJjaGljYWwgY29uZmlndXJhdGlvbiAodW5kZXIgc2FtZSBMU1Ao bmFtZT1mb28pKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkxTUChuYW1l PWZvbyk6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Qlc8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5iaWRpcmVjdGlvbmFsPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Zm9yd2FyZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyBCVzE8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsgaW4tc2VnbWVudCAoaW4tbGFiZWwsIG5leHQtaG9wKTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyBvdXQtc2Vn bWVudCAob3V0LWxhYmVsKHMpLCBuZXh0LWhvcCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj5yZXZlcnNlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+ Jm5ic3A7Jm5ic3A7IEJXMjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZu YnNwOyZuYnNwOyBpbi1zZWdtZW50IChpbi1sYWJlbCwgbmV4dC1ob3ApPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7IG91dC1zZWdtZW50IChvdXQtbGFi ZWwocyksIG5leHQtaG9wKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPi0tJmd0OyBJbiBjdXJy ZW50IG1vZGVsIHRoZSBMU1AgaGFzIG9ubHkgb25lIGNyb3NzLWNvbm5lY3Q8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4tLSZndDsgd2lsbCBuZWVkIHRvIGhhdmUgbXVsdGlw bGUgY3Jvc3MtY29ubmVjdHMgcGVyIExTUDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNh bGlicmkiPi08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzIj7DoDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj4gdG8gcmVhbGl6ZSBhc3ltbWV0cmljYWwgYmVoYXZpb3IgKGVnLiBCVyBh bGxvYykgbmVlZCB0byBhbGxvdyBjb25maWcNCiB1bmRlciBlYWNoIGZvcndhcmQvcmV2ZXJzZSBs ZWc8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5PcHRpb24gIzI6PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMC4y NXB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzQiPg0KPCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPmZvcndhcmQvcmV2ZXJz ZSBMU1BzIGFzIHNlcGFyYXRlIGVudHJpZXMgaW4gdGhlIHN0YXRpYyBMU1AgbGlzdDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MjAuMjVwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm80 Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJp Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlm XT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5lbnRy aWVzIGhhdmUNCjxiPjx1PmRpZmZlcmVudDwvdT48L2I+IG5hbWVzLCBidXQgYXNzb2NpYXRlZCB1 c2luZyBiZWxvdzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjAuMjVwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1s aXN0OmwwIGxldmVsMSBsZm80Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpDYWxpYnJpIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj51c2UgYSBjb25maWd1cmVkIGFzc29jaWF0aW9uLUlEICh0dW5uZWwtSUQg b3Igc2VydmljZS1JRCkgYXMgd2F5IHRvIGFzc29jaWF0ZSBMU1BzPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q2FsaWJyaSI+TFNQKG5hbWU9Zm9vLWZvcndhcmQpOjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPmJpZGlyZWN0aW9uYWw8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDYWxpYnJpIj5mb3J3YXJkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaSI+YXNzb2NpYXRpb24gSUQgPSAxMDAxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6Q2FsaWJyaSI+aW4tc2VnbWVudCAoaW4tbGFiZWwsIG5leHQtaG9wKTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPm91dC1zZWdtZW50IChvdXQtbGFiZWwocyksIG5leHQt aG9wKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkxTUChuYW1lPWZvby1yZXZlcnNlKTo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5iaWRpcmVjdGlvbmFsPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+cmV2ZXJzZTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OkNhbGlicmkiPmFzc29jaWF0aW9uIElEID0gMTAwMTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNhbGlicmkiPmluLXNlZ21lbnQgKGluLWxhYmVsLCBuZXh0LWhvcCk8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5vdXQtc2VnbWVudCAob3V0LWxhYmVs KHMpLCBuZXh0LWhvcCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5PcHRpb24gIzM6PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJn aW4tbGVmdDoyMC4yNXB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzQiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGli cmkiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPmZv cndhcmQvcmV2ZXJzZSBMU1BzIGFzIHNlcGFyYXRlIGVudHJpZXMgaW4gdGhlIHN0YXRpYyBMU1Ag bGlzdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MjAuMjVwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0Omww IGxldmVsMSBsZm80Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpDYWxpYnJpIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9 ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9z cGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD YWxpYnJpIj5ib3RoIGVudHJpZXMgaGF2ZSB0aGUNCjxiPjx1PnNhbWU8L3U+PC9iPiBuYW1lLCBi dXQgbmV3IGtleSBpcyBuZWVkZWQgaWluIHRoZSBsaXN0IChyb2xlPywgZS5nLiBzaWJsaW5nMSwg c2libGluZzIsIGV0Yy4uKQ0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWJvdHRvbTpk b3VibGUgd2luZG93dGV4dCAyLjI1cHQ7cGFkZGluZzowY20gMGNtIDEuMHB0IDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj5NQkIgZm9yIFN0YXRpYzo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjx1PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjEuIGhvdyB0byByZWFsaXplIHJlc291cmNlIHNoYXJpbmcg aWYgbmVlZGVkPzwvc3Bhbj48L3U+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2Fs aWJyaSI+Mi4gY29vcmRpbmF0ZSBzd2l0Y2hvdmVyIG9uIHRoZSBpbmdyZXNzIHVzaW5nIGNvbmZp Z3VyYXRpb248L3NwYW4+PC91PjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPk9wdGlvbiMyIChhZGQg cm9sZSBpbiBsaXN0IG9mIExTUHMga2V5KSwgZS5nLiBrZXk9IChuYW1lPWZvbywgcm9sZT1tYmIt c2libGluZzEpLCAobmFtZT1mb28sIG1iYi1zaWJsaW5nMiksIChuYW1lPWZvbywgcGF0aC1wcm90 ZWN0LXNpYmxpbmcxKSwgKG5hbWU9Zm9vLCBwYXRoLXByb3RlY3Qtc2libGluZzIpPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q2FsaWJyaSI+TFNQKGZvbywgbWJiLXNpYmxpbmcxKTo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDYWxpYnJpIj5pbi1zZWdtZW50IChpbi1sYWJlbCwgbmV4dC1ob3ApPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+b3V0LXNlZ21lbnQgKG91dC1sYWJl bChzKSwgbmV4dC1ob3ApPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+YXNz b2NpYXRpb24gSUQgPSAxMDAxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+ cm9sZT1NQkIgc2libGluZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkxTUChmb28sIG1iYi1z aWJsaW5nMik6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+aW4tc2VnbWVu dCAoaW4tbGFiZWwsIG5leHQtaG9wKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGli cmkiPm91dC1zZWdtZW50IChvdXQtbGFiZWwocyksIG5leHQtaG9wKTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNhbGlicmkiPmFzc29jaWF0aW9uIElEID0gMTAwMTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPnJvbGU9TUJCIHNpYmxpbmc8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj5UMDogdHJhZmZpYyBvbiBMU1AoZm9vMSk8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj5UMTogY29uZmlndXJlIExTUChmb28yKSBvbiBtaWQocyk8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5UMjogbWFwIHRyYWZmaWMgdG8gTFNQKGZv bzIpIG9uIGluZ3Jlc3M8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5UMzog ZGVsZXRlIExTUChmb28xKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkJhY2tncm91bmQgKHNuaXBwZXQgZnJvbSBI dWF3ZWnigJlzIE9TIHN1cHBvcnQgZm9yIHN0YXRpYyBMU1ApOjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OkNhbGlicmkiPltMU1JBXSBiaWRpcmVjdGlvbmFsIHN0YXRpYy1jci1sc3AgaW5n cmVzcyBUdW5uZWwxLzAvMDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPltM U1JBLWJpLXN0YXRpYy1pbmdyZXNzLVR1bm5lbGwvMC8wXSBmb3J3YXJkIG5leHRob3AgMi4xLjEu MiBvdXQtbGFiZWwgMjAgYmFuZHdpZHRoIGN0MCAxMDAwMDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmkiPltMU1JBLWJpLXN0YXRpYy1pbmdyZXNzLVR1bm5lbGwvMC8wXSBiYWNr d2FyZCBpbi1sYWJlbCAyMDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPltM U1JCXWJpZGlyZWN0aW9uYWwgc3RhdGljLWNyLWxzcCB0cmFuc2l0IGxzcDE8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5bTFNSQi1iaS1zdGF0aWMtdHJhbnNpdC1sc3AxXSBm b3J3YXJkIGluLWxhYmVsIDIwIG5leHRob3AgMy4yLjEuMiBvdXQtbGFiZWwgNDAgYmFuZHdpZHRo IGN0MCAxMDAwMDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPltMU1JCLWJp LXN0YXRpYy10cmFuc2l0LWxzcDFdIGJhY2t3YXJkIGluLWxhYmVsIDE2IG5leHRob3AgMi4xLjEu MSBvdXQtbGFiZWwgMjAgYmFuZHdpZHRoIGN0MCAxMDAwMDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmkiPltMU1JDXSBiaWRpcmVjdGlvbmFsIHN0YXRpYy1jci1sc3AgZWdyZXNz IGxzcDE8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5bTFNSQy1iaS1zdGF0 aWMtZWdyZXNzLWxzcDFdIGZvcndhcmQgaW4tbGFiZWwgNDAgbHNyaWQgMS4xLjEuMSB0dW5uZWwt aWQgMTAwPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDYWxpYnJpIj5UYXJlazwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bh bj4NCjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+dHNh YWRAY2lzY28uY29tPGJyPg0KPGI+V2hlbjogPC9iPjEwOjAwIEFNIC0gMTE6MDAgQU0gTWF5IDI3 LCAyMDE2IDxicj4NCjxiPlN1YmplY3Q6IDwvYj5NUExTIGFuZCBURSB0dW5uZWxzIFlBTkcgZGF0 YSBtb2RlbCBtZWV0aW5nPGJyPg0KPGI+TG9jYXRpb246IDwvYj53ZWJleDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpi bGFjayI+UmVmcmVzaGluZyBpbnZpdGUgZm9yIE1QTFMgYW5kIFRFIHR1bm5lbHMgWUFORyBkYXRh IG1vZGVsIG1lZXRpbmcuIFBsZWFzZSBmb3J3YXJkIHRvIGFueW9uZSBJIG1pc3NlZC48YnI+DQo8 YnI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtj b2xvcjpibGFjayI+PGJyPg0KPGJyPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+PGJyPg0KPGJyPg0KPGJyPg0K PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibGFjayI+ PGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OkFyaWFsO2NvbG9yOiM2NjY2NjYiPjxicj4NCjxicj4NCi08YSBuYW1lPSJNYWNCZWdpbldC WFRhZyI+PC9hPi0gRG8gbm90IGRlbGV0ZSBvciBjaGFuZ2UgYW55IG9mIHRoZSBmb2xsb3dpbmcg dGV4dC4gLS08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTpB cmlhbDtjb2xvcjojNjY2NjY2Ij4NCjxicj4NCjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjojNjY2NjY2Ij48YSBo cmVmPSJodHRwczovL2Npc2NvLndlYmV4LmNvbS9jaXNjb3NhbGVzL2oucGhwP01USUQ9bWMwNTk4 MmYyZDNjNDA0MmRmMjBjMmRmNTZmM2NjMTI3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjojMDBBRkY5Ij5Kb2luIFdlYkV4IG1lZXRpbmc8L3NwYW4+PC9hPg0KPGJyPg0KPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9y OiM2NjY2NjYiPk1lZXRpbmcgbnVtYmVyOiAyMDEgOTY2IDY5Mjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjojNjY2NjY2Ij4NCjxicj4N Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtj b2xvcjojNjY2NjY2Ij5NZWV0aW5nIHBhc3N3b3JkOjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEzLjVwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjojNjY2NjY2Ij4NCjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjojNjY2NjY2 Ij4zandNUlhFZDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWls eTpBcmlhbDtjb2xvcjojNjY2NjY2Ij4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuNXB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiM2NjY2NjYiPjxicj4NCjxicj4NCjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdv ZSBVSSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojNjY2NjY2Ij5JZiB5b3UgYXJlIGEg aG9zdCwNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OkFy aWFsO2NvbG9yOiM2NjY2NjYiPjxhIGhyZWY9Imh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Npc2Nv c2FsZXMvai5waHA/TVRJRD1tZTdmNjU0NjJlYjI1MWQyMDVjOGUyMTY2OGU1MTRlZTciPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMwMEFGRjkiPmdvIGhlcmU8L3NwYW4+PC9hPjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBV SSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojNjY2NjY2Ij4NCiB0byB2aWV3IGhvc3Qg aW5mb3JtYXRpb24uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1p bHk6QXJpYWw7Y29sb3I6IzY2NjY2NiI+PGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpBcmlhbDtjb2xvcjojNjY2NjY2Ij5Kb2luIGJ5IHBob25lPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiM2NjY2NjYi Pg0KPGJyPg0KPC9zcGFuPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6QXJpYWw7Y29sb3I6IzY2NjY2NiI+JiM0MzsxLTQwOC01MjUtNjgwMDwvc3Bhbj48 L3N0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtj b2xvcjojNjY2NjY2Ij4gQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjojNjY2NjY2 Ij4NCjxicj4NCjwvc3Bhbj48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OkFyaWFsO2NvbG9yOiM2NjY2NjYiPiYjNDM7MS04NjYtNDMyLTk5MDM8L3NwYW4+ PC9zdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7 Y29sb3I6IzY2NjY2NiI+IENhbGwtaW4gdG9sbC1mcmVlIG51bWJlciAoVVMvQ2FuYWRhKTwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjoj NjY2NjY2Ij4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTpBcmlhbDtjb2xvcjojNjY2NjY2Ij5BY2Nlc3MgY29kZTogMjAxIDk2NiA2OTI8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6 IzY2NjY2NiI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6QXJpYWw7Y29sb3I6IzY2NjY2NiI+TnVtZXJpYyBtZWV0aW5nIHBhc3N3b3JkOiAy MTc5NDE3Mjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTpB cmlhbDtjb2xvcjojNjY2NjY2Ij4NCjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vY2lzY28ud2ViZXgu Y29tL2Npc2Nvc2FsZXMvZ2xvYmFsY2FsbGluLnBocD9zZXJ2aWNlVHlwZT1NQyZhbXA7RUQ9MzUx NDk3MzMyJmFtcDt0b2xsRnJlZT0xIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2NvbG9y OiMwMEFGRjkiPkdsb2JhbCBjYWxsLWluIG51bWJlcnM8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiM2NjY2NjYiPiB8 DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6QXJpYWw7 Y29sb3I6IzY2NjY2NiI+PGEgaHJlZj0iaHR0cHM6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJl ZV9yZXN0cmljdGlvbnMucGRmIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2NvbG9yOiMw MEFGRjkiPlRvbGwtZnJlZSBjYWxsaW5nIHJlc3RyaWN0aW9uczwvc3Bhbj48L2E+DQo8YnI+DQo8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTpBcmlhbDtjb2xv cjojNjY2NjY2Ij48YnI+DQo8YnI+DQpDYW4ndCBqb2luIHRoZSBtZWV0aW5nPyA8YSBocmVmPSJo dHRwczovL2Npc2NvLndlYmV4LmNvbS9jaXNjb3NhbGVzL21jIj48c3BhbiBzdHlsZT0iY29sb3I6 IzAwQUZGOSI+Q29udGFjdCBzdXBwb3J0Ljwvc3Bhbj48L2E+DQo8YnI+DQo8YnI+DQo8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjojQTBB MEEwIj5JTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2Vydmlj ZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNz aW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwg bWF0dGVyLiBCeSBqb2luaW5nIHRoaXMNCiBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25z ZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJl Y29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9p biB0aGUgc2Vzc2lvbi4uPC9zcGFuPjxhIG5hbWU9Ik1hY0VuZFdCWFRhZyI+PC9hPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6IzY2NjY2NiI+DQo8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtj b2xvcjpibGFjayI+PGJyPg0KPGJyPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_DA890DD196B24A63A6D5E174EF651C66ciscocom_-- From nobody Fri May 27 10:13:57 2016 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 7A39C12DAFC for ; Fri, 27 May 2016 10:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.644 X-Spam-Level: X-Spam-Status: No, score=-5.644 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 RXJwnOOuMnJZ for ; Fri, 27 May 2016 10:13:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6594812D9EC for ; Fri, 27 May 2016 10:13:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CKX88613; Fri, 27 May 2016 17:13:46 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 27 May 2016 18:13:45 +0100 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Fri, 27 May 2016 10:13:33 -0700 From: Leeyoung To: Xufeng Liu , Igor Bryskin , Vishnu Pavan Beeram , Oscar Gonzalez De Dios , Tarek Saad , Himanshu Shah , Lou Berger , "BRUNGARD, DEBORAH A (ATTLABS)" , Susan Hares , "Zafar Ali (zali)" , "Khaddam, Mazen (CCI-Atlanta)" , Tony Le , "BELOTTI, SERGIO (SERGIO)" , "Beller, Dieter (Dieter)" , Rajan Rao , "Zhangxian (Xian)" , "xufeng.liu.ietf@gmail.com" , "Belotti, Sergio (Nokia - IT)" , Anurag Sharma Thread-Topic: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23 Thread-Index: AQHRuB7bG2oGA/m9hki059z0o+bATp/NBLNw Date: Fri, 27 May 2016 17:13:33 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172A88F114@dfweml501-mbx> References: <7AEB3D6833318045B4AE71C2C87E8E172A88ECF3@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908EDD175@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A88EDAD@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908EDD212@dfweml501-mbx> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.150.143] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E172A88F114dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.5748804B.0097, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a54d0605a6e2384b1e4246515130f295 Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 27 May 2016 17:13:56 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E172A88F114dfweml501mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Xufeng, Thanks for your reply. I think you should look at Section 2.6 Label Set Fie= ld (RFC 7579) where the following actions are defined. Action: 0 - Inclusive List 1 - Exclusive List 2 - Inclusive Range 3 - Exclusive Range 4 - Bitmap Set --- This is by far the simplest ways to represent the= label availability. What do you think? Young From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Xufeng Liu Sent: Friday, May 27, 2016 8:51 AM To: Igor Bryskin; Leeyoung; Vishnu Pavan Beeram; Oscar Gonzalez De Dios; Ta= rek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan H= ares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, SER= GIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.= liu.ietf@gmail.com; Belotti, Sergio (Nokia - IT); Anurag Sharma Cc: teas@ietf.org Subject: Re: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016= -05-23 Hi Young, More below. Thanks, - Xufeng From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: Thursday, May 26, 2016 4:18 PM To: Leeyoung >; Xufeng Liu = >; Vishnu Pavan Beeram >; Oscar Gonzalez De Dios = >; Tarek Saad >; Himanshu Shah >; Lou Berger >; BRUNGARD, DEBORAH A (ATTLABS) >; Susan Hares >; Zafa= r Ali (zali) >; Khaddam, Mazen (CCI-A= tlanta) >; Tony Le >; BELOTTI, SERGIO (SERGIO) >; B= eller, Dieter (Dieter) >; Rajan Rao >; Zhangxian (Xian) >; xufeng.liu.ietf@gmail.com; Belotti, S= ergio (Nokia - IT) >; Anurag Sharma > Cc: teas@ietf.org Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23 Young, "Another question on the TTP, can REG/WC (Wavelength Converter) element be = considered as a type of the TTP? If so, I think TTP can be generalized to i= nclude Transponders and REG/WC elements." One important role of TTP is to represent topologically a client/server lay= er adaptor to facilitate inter-layer path computations. REG/WC has no adapt= ation capabilities. WDM augmentation could IMHO model REG/WC as a TTP with no adaptation caps, = however, because this is only pertinent to OCh layer, it should not be part= of the basic TE topology model. Igor From: Leeyoung Sent: Thursday, May 26, 2016 2:58 PM To: Igor Bryskin; Xufeng Liu; Vishnu Pavan Beeram; Oscar Gonzalez De Dios; = Tarek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan= Hares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, S= ERGIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufen= g.liu.ietf@gmail.com; Belotti, Sergio (No= kia - IT); Anurag Sharma Cc: teas@ietf.org Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23 Hi Igor, Thanks for your comments. In OTN, if you consider ODUk as labels, I am fine with that. I thought ODUk= is more or less Switching/Encoding in the ISCD Link model than a label. Youmg, Thanks. Young From: Igor Bryskin Sent: Thursday, May 26, 2016 11:44 AM To: Leeyoung; Xufeng Liu; Vishnu Pavan Beeram; Oscar Gonzalez De Dios; Tare= k Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan Har= es; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, SERGI= O (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.li= u.ietf@gmail.com; Belotti, Sergio (Nokia = - IT); Anurag Sharma Cc: teas@ietf.org Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23 Hi Young, Please, see in-line, Igor From: Leeyoung Sent: Thursday, May 26, 2016 11:31 AM To: Xufeng Liu; Vishnu Pavan Beeram; Igor Bryskin; Oscar Gonzalez De Dios; = Tarek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan= Hares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, S= ERGIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufen= g.liu.ietf@gmail.com; Belotti, Sergio (No= kia - IT); Anurag Sharma Cc: teas@ietf.org Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23 Hi Xufeng, Thanks for this update. Your notes are always very helpful to understand th= e latest progress of this draft. I have a few questions on the potentially adding model for labels for the c= onnectivity matrix. 1. You said: For each label o exclusivity (true/false) Do you mean this bitmap? [Xufeng] This is the LINK_LABEL_EXCLUSIVITY in RFC 7579. 2. Are you aware of label restrictions applied for the connectivity ma= trix other than WSON? If so, then this model addition makes sense; if not, = then we can add the label model for the connectivity matrix in the WSON YAN= G model. If the extent to which label model addition is not really a major = constraint in the switching technologies other than WSON, it would be worth= while to evaluate if we should do label restriction model in a generic way = (per this draft) or do it in WSON specific way? I am not aware of any labe= l restriction model for the connectivity matrix for GMPLS other than WSON. IB>> We had this discussion many time already. There are physical OTN switc= hes that have constraints on the ODUk type level. For example, a switch can= switch ODU2 from link 1 to link2, but ODU2e from link 1 to only link3. Thi= s is especially true for abstract compound nodes which may represent entire= network domains. As you know abstract TE modes are very important for this= model. So, no, connectivity restriction on a label level does not apply on= ly to WDM. 3. If we were to extend the label model for the connectivity matrix, = I would think we also need to have label restriction model for TTP LLCL as = well. What do you think? IB>> This is actually a good point. Thanks for pointing out. Cheers, Igor Thanks. Young From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Xufeng Liu Sent: Thursday, May 26, 2016 9:48 AM To: Vishnu Pavan Beeram; Igor Bryskin; Oscar Gonzalez De Dios; Tarek Saad; = Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan Hares; Zafa= r Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, SERGIO (SERGI= O); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.liu.ietf@g= mail.com; Belotti, Sergio (Nokia - IT); A= nurag Sharma Cc: teas@ietf.org Subject: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016-05-= 23 Participants: Igor, Xufeng, Pavan, Dieter, Sergio, Himanshu - Information sources > Discussed two use cases related to information sources: 1) Provider applies policies to pick the most preferred. 2) Provider does not apply policies and the decision is done by custome= r. > The model currently supports 1) well, but is not clear on 2). > Agreed to clarify the model by: 1) Change "alt-information-sources" to "information-sources" to include all sources, including the selected one. 2) For use case 1), the applied attribute has the selected value, and "information-sources" list all available sources. For use case 2), the applied attribute does not have value, and "information-sources" list all available sources. - Connectivity Matrix > Discussed the comment from Cyril "to add a Label (Following RFC7579) restrictions". > Participants agreed that such constraint information is useful. > Participants agreed that such constraint information is generic enough to be used in various layers and use cases, including optical OTN, and abstract network topologies. > Participants agreed to send the suggestion TEAS WG to add such information to te-topology model. > The potential model change can be: For each connectivity-matrix entry, add: list of labels list types o inclusive-list o exclusive-list o inclusive-range o exclusive-range For each label o exclusivity (true/false) Working members: please provide any comments. Thanks, - Xufeng Note: Please drop me an email if you need an invite for joining the weekly = call. PS. Meeting on May 30 will be canceled for US holiday. --_000_7AEB3D6833318045B4AE71C2C87E8E172A88F114dfweml501mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Xufeng,<= /span>

 

Thanks for your reply.= I think you should look at Section 2.6 Label Set Field (RFC 7579) where th= e following actions are defined.

 

Action:

 =

  = ;    0 - Inclusive List

 =

  = ;    1 - Exclusive List

 =

  = ;    2 - Inclusive Range

 =

  = ;    3 - Exclusive Range

 =

  = ;    4 - Bitmap Set  --- This is by far the simplest wa= ys to represent the label availability.

 =

What do you think?

 

Young

 =

 

 

From: Teas [ma= ilto:teas-bounces@ietf.org] On Behalf Of Xufeng Liu
Sent: Friday, May 27, 2016 8:51 AM
To: Igor Bryskin; Leeyoung; Vishnu Pavan Beeram; Oscar Gonzalez De D= ios; Tarek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); = Susan Hares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOT= TI, SERGIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.liu.ietf@gmail.com; Belotti,= Sergio (Nokia - IT); Anurag Sharma
Cc: teas@ietf.org
Subject: Re: [Teas] IETF TE Topology YANG Model Design Meeting Notes= - 2016-05-23

 

Hi Young,

 

More below.

Thanks,

 

- Xufeng

 

From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: Thursday, May 26, 2016 4:18 PM
To: Leeyoung <leeyoung@hua= wei.com>; Xufeng Liu <xliu= @kuatrotech.com>; Vishnu Pavan Beeram <vbeeram@juniper.net>; Oscar Gonzalez De Dios <oscar.g= onzalezdedios@telefonica.com>; Tarek Saad <tsaad@cisco.com>; Himanshu Shah <hshah@ciena.com>; Lou Berger <lberger@labn.net>; BRUNGARD, DEBORAH A (ATTLABS) <db3546= @att.com>; Susan Hares <shares= @ndzh.com>; Zafar Ali (zali) <z= ali@cisco.com>; Khaddam, Mazen (CCI-Atlanta) <Mazen.Khaddam@cox.com>; Tony Le <tonyle@juniper.net&g= t;; BELOTTI, SERGIO (SERGIO) <sergio.belotti@alcatel-lucent.com>; Beller, Dieter (Diete= r) <dieter.beller@al= catel-lucent.com>; Rajan Rao <rrao@infinera.com&g= t;; Zhangxian (Xian) <zhang.xia= n@huawei.com>; xufeng.liu.ietf@gmail.com;= Belotti, Sergio (Nokia - IT) <sergio.belotti@nokia.com>; Anurag Sharma <AnSharma@infinera.com>
Cc: teas@ietf.org
Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016= -05-23

 

Young,

 

“Another question on the TTP, can REG/WC (Wavelength Converter= ) element be considered as a type of the TTP? If so, I think TTP can be generalized to include Transponders and REG/WC elements.”

 

One important role of = TTP is to represent topologically a client/server layer adaptor to facilita= te inter-layer path computations. REG/WC has no adaptation capabilities.

WDM augmentation could IMHO mo= del REG/WC as a TTP with no adaptation cap= s, however, because this is only pertinent to OCh layer, it should not be p= art of the basic TE topology model.

 

Igor

 

From: Leeyoung
Sent: Thursday, May 26, 2016 2:58 PM
To: Igor Bryskin; Xufeng Liu; Vishnu Pavan Beeram; Oscar Gonzalez De= Dios; Tarek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS)= ; Susan Hares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BEL= OTTI, SERGIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.liu.ietf@gmail.com; Belotti, Sergio (Nokia - IT); Anurag Sharma
Cc: teas@ietf.or= g
Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016= -05-23

 

Hi Igor,

 

Thanks for your commen= ts.

 

In OTN, if you conside= r ODUk as labels, I am fine with that. I thought ODUk is more or less Switc= hing/Encoding in the ISCD Link model than a label.

 

Youmg,

 

 

Thanks.

Young

 

From: Igor Bry= skin
Sent: Thursday, May 26, 2016 11:44 AM
To: Leeyoung; Xufeng Liu; Vishnu Pavan Beeram; Oscar Gonzalez De Dio= s; Tarek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Su= san Hares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI= , SERGIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.liu.ietf@gmail.com; Belotti, Sergio (Nokia - IT); Anurag Sharma
Cc: teas@ietf.or= g
Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016= -05-23

 

Hi Young,

 

Please, see in-line,

 

Igor

 

From: Leeyoung
Sent: Thursday, May 26, 2016 11:31 AM
To: Xufeng Liu; Vishnu Pavan Beeram; Igor Bryskin; Oscar Gonzalez De= Dios; Tarek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS)= ; Susan Hares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BEL= OTTI, SERGIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.liu.ietf@gmail.com; Belotti, Sergio (Nokia - IT); Anurag Sharma
Cc: teas@ietf.or= g
Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016= -05-23

 

Hi Xufeng,<= /span>

 

Thanks for this update= . Your notes are always very helpful to understand the latest progress of t= his draft.

 

I have a few questions= on the potentially adding model for labels for the connectivity matrix.

 

1.    = ;  You said:

 

         &nb= sp;     For each label

         &nb= sp;     o exclusivity (true/false)

 

Do you mean this bitmap?

[Xufeng] This is the LINK_LABEL_EXCLUSIVITY in= RFC 7579.

 

2.    = ;  Are you aware of label restrictions ap= plied for the connectivity matrix other than WSON? If so, then this model a= ddition makes sense; if not, then we can add the label model for the connec= tivity matrix in the WSON YANG model. If the extent to which label model addition is not really a major constrai= nt in the switching technologies other than WSON, it would be worthwhile to= evaluate if we should do label restriction model in a generic way (per thi= s draft) or do it in WSON specific way?  I am not aware of any label restriction model for the connectiv= ity matrix for GMPLS other than WSON.

IB>> We had this= discussion many time already. There are physical OTN switches that have co= nstraints on the ODUk type level. For example, a switch can switch ODU2 fro= m link 1 to link2, but ODU2e from link 1 to only link3. This is especially true for abstract compound nodes which may = represent entire network domains. As you know abstract TE modes are very im= portant for this model. So, no, connectivity restriction on a label level d= oes not apply only to WDM.

 

 

 

3.    = ;   If we were to extend the label m= odel for the connectivity matrix, I would think we also need to have label = restriction model for TTP LLCL as well. What do you think?

IB>> This is act= ually a good point. Thanks for pointing out.

 

Cheers,

Igor=

 

Thanks.

Young

 

 

From: Teas [mailto:teas-bounc= es@ietf.org] On Behalf Of Xufeng Liu
Sent: Thursday, May 26, 2016 9:48 AM
To: Vishnu Pavan Beeram; Igor Bryskin; Oscar Gonzalez De Dios; Tarek= Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan Hare= s; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, SERGIO= (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.liu.ietf@gmail.com; Belott= i, Sergio (Nokia - IT); Anurag Sharma
Cc: teas@ietf.or= g
Subject: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2= 016-05-23

 

Participants:

Igor, Xufeng, Pavan, Dieter, Sergio, Himanshu

 

- Information sources

  > Discussed two use cases related to infor= mation sources:

    1) Provider applies policies to p= ick the most preferred.

    2) Provider does not apply polici= es and the decision is done by customer.

  > The model currently supports 1) well, bu= t is not clear on 2).

  > Agreed to clarify the model by:

    1) Change "alt-information-s= ources" to "information-sources" to

       include all sou= rces, including the selected one.

    2) For use case 1), the applied a= ttribute has the selected value, and

       "informati= on-sources" list all available sources.

       For use case 2)= , the applied attribute does not have value, and

       "info= rmation-sources" list all available sources.

 

- Connectivity Matrix

  > Discussed the comment from Cyril "t= o add a Label (Following

    RFC7579) restrictions".=

  > Participants agreed that such constraint= information is useful.

  > Participants agreed that such constraint= information is generic

    enough to be used in various laye= rs and use cases, including optical

    OTN, and abstract network topolog= ies.

  > Participants agreed to send the suggesti= on TEAS WG to add such

    information to te-topology model.=

  > The potential model change can be:<= o:p>

    For each connectivity-matrix entr= y, add:

      list of labels

        list type= s

         &nb= sp;     o inclusive-list

         &nb= sp;     o exclusive-list

         &nb= sp;     o inclusive-range

         &nb= sp;     o exclusive-range

         &nb= sp;     For each label

         &nb= sp;     o exclusivity (true/false)

 

Working members: please provide any comments.

 

Thanks,

 

- Xufeng

 

Note: Please drop me an email if you need an invite = for joining the weekly call.

 

PS. Meeting on May 30 will be canceled for US holida= y.

 

 

--_000_7AEB3D6833318045B4AE71C2C87E8E172A88F114dfweml501mbx_-- From nobody Fri May 27 13:09:40 2016 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 8390812D11D; Fri, 27 May 2016 13:09:39 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160527200939.11074.62677.idtracker@ietfa.amsl.com> Date: Fri, 27 May 2016 13:09:39 -0700 Archived-At: Cc: vbeeram@juniper.net, teas-chairs@ietf.org, draft-ietf-teas-rsvp-te-srlg-collect@ietf.org, teas@ietf.org, db3546@att.com Subject: [Teas] Last Call: (RSVP-TE Extensions for Collecting SRLG Information) to Proposed Standard X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org 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, 27 May 2016 20:09:39 -0000 The IESG has received a request from the Traffic Engineering Architecture and Signaling WG (teas) to consider the following document: - 'RSVP-TE Extensions for Collecting SRLG Information' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-06-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides extensions for the Resource ReserVation Protocol-Traffic Engineering (RSVP-TE), including GMPLS, to support automatic collection of Shared Risk Link Group (SRLG) information for the TE link formed by a Label Switched Path (LSP). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-collect/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-collect/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2478/ From nobody Fri May 27 14:07:44 2016 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 1E88B12D190; Fri, 27 May 2016 14:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 uy81mMxbZ91T; Fri, 27 May 2016 14:07:39 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C516A12D816; Fri, 27 May 2016 14:07:37 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-ae-5748b71700fe Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id CE.97.12926.717B8475; Fri, 27 May 2016 23:07:35 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.74]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0294.000; Fri, 27 May 2016 23:07:35 +0200 From: Daniele Ceccarelli To: Daniele Ceccarelli , "CCAMP (ccamp@ietf.org)" , "TEAS WG (teas@ietf.org)" Thread-Topic: Joint WG last call on draft-ietf-ospf-availability-extension-04 Thread-Index: AdGsJ0Ek7gP9RQQrQ6a+ZIh0V1wFmAL2G1WA Date: Fri, 27 May 2016 21:07:35 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE48162F21C8@ESESSMB301.ericsson.se> References: <4A1562797D64E44993C5CBF38CF1BE48162CC275@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48162CC275@ESESSMB301.ericsson.se> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE48162F21C8ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUyM2K7qK7Edo9wgzdCFkt3bGKyeDLnBotF 09xdTBatP3awOLB4LFnykymAMYrLJiU1J7MstUjfLoEr49m380wFi94zVjz8Ft3A+OoSYxcj J4eEgInE4c/vWSFsMYkL99azdTFycQgJHGGUeHVvBwuEs5hRYuHV7exdjBwcbAJWEk8O+YDE RQQmMErs/v+BBaSbWSBF4u2/rWBThQV8JJrOzAGzRQR8Jebu3cEMYRtJzFpxCayeRUBV4vCZ /2wgNi9QzdTrG8DiQkD2qbn3weo5BfwkDiyYAjaHUUBWYsLuRYwQu8Qlbj2ZzwRxtYDEkj3n mSFsUYmXj/9BfaMk0bjkCStEfb7Eon9n2CF2CUqcnPmEZQKj6Cwko2YhKZuFpAwiridxY+oU NghbW2LZwtfMELauxIx/h1iQxRcwsq9iFC1OLU7KTTcy1kstykwuLs7P08tLLdnECIy9g1t+ q+5gvPzG8RCjAAejEg/vg0L3cCHWxLLiytxDjBIczEoivCe3eoQL8aYkVlalFuXHF5XmpBYf YpTmYFES5/V/qRguJJCeWJKanZpakFoEk2Xi4JRqYMxL0tSq/PncftofMZuPW9u3azwK6tK7 vPNt8/1vVinbcxbvDT/15PG9qdzR3ErbQ3d0NmR/3hcjuqFN/rboz+l/TKriBZnmmCz/1tNR Uf1o+omVCQmLFr7mrQlIjbJa2/DWzrDn1JzNaR+veAj/WLTS5uc1non8bAWhmvxZdkv3blwU nusUeUaJpTgj0VCLuag4EQBPRJ2GuQIAAA== Archived-At: Cc: "ccamp-chairs@ietf.org" , "teas-chairs@ietf.org" Subject: Re: [Teas] Joint WG last call on draft-ietf-ospf-availability-extension-04 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 27 May 2016 21:07:42 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE48162F21C8ESESSMB301erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Authors, I did my review of the document. Please find below some comments: - Section 1: please put [G.827, F.1703, P.530] in a reference form= at [G.827] [F.1703][P.530]. - Section 1: Could you elaborate this sentence? "The availability = is a time scale that the requested bandwidth is ensured." The meaning is no= t fully clear to me. - Section 1: [ASTE] curious acronym choice! Is it correct to have = this as a normative reference? - Section 1: [RFC4202]: I would say that this is a normative refer= ence, it is reported as informative. - Section 1: " If there is a hop that cannot support the Availab= ility sub-TLV, the Availability sub-TLV should be ignored." This is normati= ve text. It should be written in capital letters and I'd suggest to move it= from the intro to section 3. Going on with the reading I see that it is pr= operly state in section 3.2, hence I suggest just dropping the sentence in = section 1. - Section 1: "...is defined to support in routing signaling." Ther= e must be something missing here. What about just "...is defined."? - Section 2: s/should contain/should include - Section 2: I suggest rephrasing this sentence: " The list provid= es the information that how much bandwidth a link can support for a specifi= ed availability." What about "The list provides the mapping between the lin= k nominal bandwidth and its availability level"? - Section 2: s/label switched path/Label Switched Path - Section 2: suggested rephrasing OLD To setup a label switching path (LSP), a node may collect link information which is spread in OSPF TE LSA messages by network nodes to get know about the network topology, calculate out an LSP route based on the network topology and send the calculated LSP route to signaling to initiate a PATH/RESV message for setting up the LSP. Availability information is required to carry in the signaling message to better utilize the link bandwidth. The signaling extension for availability can be found in [ASTE]. NEW The setup of a Label Switched Path requires this piece of information to be= flooded in the network and used by the nodes or the PCE for the path compu= tation. The computed path can then be provisioned via the signaling protoco= l. Availability information also need to be carried by the signaling for a bet= ter utilization of the link bandwidth (CAN YOU EXPLAIN WHY?). Extensions to RSVP-TE can be found in [ASTE]. - Section 3.1 - ISCD already expanded in section 1, you can use th= e acronym. - Section 3.1: "Type: TBA by IANA, suggested value is 0x01" - Section 3.1: "Length" you should state the units (bit? Bytes?). = Moreover I see this is a fixed length TLV, hence I would say: "Length: A 16= bits field that expresses the length of the TLV in bytes" - Section 3.1: "Availability level": is there a discrete set of av= ailability levels? E.g. 0.99, 0.999, 0.9999, or it can be filled with any n= umber between O and 1? This needs to be explained a bit better. - LSP bandwidth at availability level: the unit is missing. - 3.2 Why signaling process? It would rather say "Processing Proce= dures" ? - Section 4: Please add a reference to the OSPF and GMPLS security= RFCs. - IANA section: Please make sure that it is state which registry n= eeds to be updated and how. - References: there is a number of references that is not used in = the document e.g. RFC 2210, RFC 3473 and so on. - Header: "OSPF -- Availability extension" please remove the dashe= s. I also suggest to substitute with "Availability extensions to OSPF-TE". - Please also check the IdNits Thanks Daniele From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: gioved=EC 12 maggio 2016 10:25 To: CCAMP (ccamp@ietf.org) ; TEAS WG (teas@ietf.org) Cc: teas-chairs@ietf.org; ccamp-chairs@ietf.org Subject: Joint WG last call on draft-ietf-ospf-availability-extension-04 CCAMP, TEAS, This starts a two weeks joint working group last call on draft-ietf-ccamp-o= spf-availability-extension-04 The last call end on Wednesday May 26th. Please send your comments to both = the CCAMP and TEAS mailing lists. All the IPR declarations from authors and contributors have been collected = and can be found in the history of the document: https://datatracker.ietf.o= rg/doc/draft-ietf-ccamp-ospf-availability-extension/history/ Please note that no IPR was disclosed against this draft. As usual this is also a call for shepherd. If anyone is willing to be the s= hepherd of the document, please volunteer. Thanks Daniele, Fatai, Lou, Pavan --_000_4A1562797D64E44993C5CBF38CF1BE48162F21C8ESESSMB301erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Authors,

 

I did my review of the document. Please find below some comments:

 

-        &= nbsp; Section 1: please put [G.827, F.1703, P.530] in a reference f= ormat [G.827] [F.1703][P.530].

-        &= nbsp; Section 1: Could you elaborate this sentence? “The avai= lability is a time scale that the requested bandwidth is ensured.” Th= e meaning is not fully clear to me.

-        &= nbsp; Section 1: [ASTE] curious acronym choice! Is it correct to ha= ve this as a normative reference?

-        &= nbsp; Section 1: [RFC4202]: I would say that this is a normative re= ference, it is reported as informative.

-        &= nbsp; Section 1: “   If there is a hop that cannot = support the Availability sub-TLV, the Availability sub-TLV should be ignore= d.” This is normative text. It should be written in capital letters and I’d suggest to move it from the intro to section= 3. Going on with the reading I see that it is properly state in section 3.= 2, hence I suggest just dropping the sentence in section 1.

-        &= nbsp; Section 1: “…is defined to support in routing sig= naling.” There must be something missing here. What about just “= ;…is defined.”?

-        &= nbsp; Section 2: s/should contain/should include<= /p>

-        &= nbsp; Section 2: I suggest rephrasing this sentence: “ The li= st provides the information that how much bandwidth a link can support for = a specified availability.” What about “The list provides the mapping between the link nominal bandwidth and its avail= ability level”?

-        &= nbsp; Section 2: s/label switched path/Label Switched Path

-        &= nbsp; Section 2: suggested rephrasing

OLD

  To setup a label sw= itching path (LSP), a node may collect link

   information which = is spread in OSPF TE LSA messages by network nodes

   to get know about = the network topology, calculate out an LSP route

   based on the netwo= rk topology and send the calculated LSP route to

   signaling to initi= ate a PATH/RESV message for setting up the LSP.

   Availability i=
nformation is required to carry in the signaling
   message to bet=
ter utilize the link bandwidth. The signaling
   extension for =
availability can be found in [ASTE].

 

NEW

The setup of a Label Switched P= ath requires this piece of information to be flooded in the network and use= d by the nodes or the PCE for the path computation. The computed path can then be provisioned via the signaling protocol.=

Availability information also n= eed to be carried by the signaling for a better utilization of the link ban= dwidth (CAN YOU EXPLAIN WHY?).

Extensions to RSVP-TE can be fo= und in [ASTE].

 

-        &= nbsp; Section 3.1 – ISCD already expanded in section 1, you c= an use the acronym.

-        &= nbsp; Section 3.1: “Type: TBA by IANA, suggested value is 0x0= 1”

-        &= nbsp; Section 3.1: “Length” you should state the units = (bit? Bytes?). Moreover I see this is a fixed length TLV, hence I would say= : “Length: A 16 bits field that expresses the length of the TLV in bytes”

-        &= nbsp; Section 3.1: “Availability level”: is there a dis= crete set of availability levels? E.g. 0.99, 0.999, 0.9999, or it can be fi= lled with any number between O and 1? This needs to be explained a bit better.

-        &= nbsp; LSP bandwidth at availability level: the unit is missing.

-        &= nbsp; 3.2 Why signaling process? It would rather say “Process= ing Procedures” ?

-        &= nbsp; Section 4: Please add a reference to the OSPF and GMPLS secur= ity RFCs.

-        &= nbsp; IANA section: Please make sure that it is state which registr= y needs to be updated and how.

-        &= nbsp; References: there is a number of references that is not used = in the document e.g. RFC 2210, RFC 3473 and so on.

-        &= nbsp; Header: “OSPF -- Availability extension” please r= emove the dashes. I also suggest to substitute with “Availability ext= ensions to OSPF-TE”.

-        &= nbsp; Please also check the IdNits

 

 

Thanks

Daniele

 

 

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: gioved=EC 12 maggio 2016 10:25
To: CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; TEAS WG (teas@iet= f.org) <teas@ietf.org>
Cc: teas-chairs@ietf.org; ccamp-chairs@ietf.org
Subject: Joint WG last call on draft-ietf-ospf-availability-extensio= n-04

 

CCAMP, TEAS,<= /p>

 

This starts a two weeks joint w= orking group last call on draft-ietf-ccamp-ospf-availability-extension-04

The last call end on Wednesday = May 26th. Please send your comments to both the CCAMP and TEAS m= ailing lists.

 

All the IPR declarations from a= uthors and contributors have been collected and can be found in the history= of the document: https://datatracker.ietf.org/doc/draft-ietf-ccamp-ospf-availability-extensi= on/history/

Please note that no IPR was dis= closed against this draft.

 

As usual this is also a call fo= r shepherd. If anyone is willing to be the shepherd of the document, please= volunteer.

 =

Thanks=

Daniele, Fatai, Lou, Pav= an

 

--_000_4A1562797D64E44993C5CBF38CF1BE48162F21C8ESESSMB301erics_-- From nobody Fri May 27 14:22:46 2016 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 7198412D548; Fri, 27 May 2016 14:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 F6z0SRa2vHUk; Fri, 27 May 2016 14:22:40 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B503512D0C8; Fri, 27 May 2016 14:22:39 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-b1-5748b719a830 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 5F.97.12926.917B8475; Fri, 27 May 2016 23:07:37 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.74]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0294.000; Fri, 27 May 2016 23:07:37 +0200 From: Daniele Ceccarelli To: Daniele Ceccarelli , "CCAMP (ccamp@ietf.org)" , "TEAS WG (teas@ietf.org)" Thread-Topic: Joint WG last call on draft-ietf-ospf-availability-extension-04 Thread-Index: AdGsJ0Ek7gP9RQQrQ6a+ZIh0V1wFmAL7ZFGA Date: Fri, 27 May 2016 21:07:37 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE48162F21D4@ESESSMB301.ericsson.se> References: <4A1562797D64E44993C5CBF38CF1BE48162CC275@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48162CC275@ESESSMB301.ericsson.se> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE48162F21D4ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsUyM2K7tK7kdo9wg3eLjC2W7tjEZPFkzg0W i6a5u5gsWn/sYHFg8Viy5CdTAGMUl01Kak5mWWqRvl0CV8ajg+eYC2ZaVcz+vJm5gfGacRcj J4eEgInE0gd32SBsMYkL99YD2VwcQgJHGCU2T54D5SxmlPix/hR7FyMHB5uAlcSTQz4gcRGB CYwSu/9/YAHpZhZIkXj7bysjiC0s4CPRdGYOmC0i4Csxd+8OZgjbSOLXnN+sIDaLgKrEjU+b wOK8QDV7zk8HqxcCsk/NvQ8W5xTwkziwYApYnFFAVmLC7kWMELvEJW49mc8EcbWAxJI955kh bFGJl4//sULYShKNS56wgtzMLJAv8e66DcQqQYmTM5+wTGAUnYVk0iyEqllIqiBK9CRuTJ3C BmFrSyxb+JoZwtaVmPHvEAuy+AJG9lWMosWpxUm56UbGeqlFmcnFxfl5enmpJZsYgXF3cMtv 1R2Ml984HmIU4GBU4uF9UOgeLsSaWFZcmXuIUYKDWUmE9+RWj3Ah3pTEyqrUovz4otKc1OJD jNIcLErivP4vFcOFBNITS1KzU1MLUotgskwcnFINjGGrLlrw5SaE2QQ23jmsd3ayswkb4+3T B5dLqWV+F1u1//C6SbmGJfztaTe7Z7UuatE90v97WUmH5tl5fqFTY05kTlmm+/DdMu/szuhZ uorvDSNlErv2iJ6fxda4dXHrrrNRgtnHlp/RaizNXDCjpS0/KKDnjIPzjSzXNOuu+b+vJdy6 9FV1jxJLcUaioRZzUXEiAMhUdwC3AgAA Archived-At: Cc: "ccamp-chairs@ietf.org" , "teas-chairs@ietf.org" Subject: Re: [Teas] Joint WG last call on draft-ietf-ospf-availability-extension-04 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 27 May 2016 21:22:42 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE48162F21D4ESESSMB301erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Working groups, The WG Last Call is now closed. Authors, please resolve Acee's comments and mine. Thanks, Daniele, Fatai, Lou, Pavan From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: gioved=EC 12 maggio 2016 10:25 To: CCAMP (ccamp@ietf.org) ; TEAS WG (teas@ietf.org) Cc: teas-chairs@ietf.org; ccamp-chairs@ietf.org Subject: Joint WG last call on draft-ietf-ospf-availability-extension-04 CCAMP, TEAS, This starts a two weeks joint working group last call on draft-ietf-ccamp-o= spf-availability-extension-04 The last call end on Wednesday May 26th. Please send your comments to both = the CCAMP and TEAS mailing lists. All the IPR declarations from authors and contributors have been collected = and can be found in the history of the document: https://datatracker.ietf.o= rg/doc/draft-ietf-ccamp-ospf-availability-extension/history/ Please note that no IPR was disclosed against this draft. As usual this is also a call for shepherd. If anyone is willing to be the s= hepherd of the document, please volunteer. Thanks Daniele, Fatai, Lou, Pavan --_000_4A1562797D64E44993C5CBF38CF1BE48162F21D4ESESSMB301erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Working groups,

 

The WG Last Call is now closed.

 

Authors, please resolve Acee’s comments and mine.

 

Thanks,

Daniele, Fatai, Lou, Pav= an

 

 

 

 

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: gioved=EC 12 maggio 2016 10:25
To: CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; TEAS WG (teas@iet= f.org) <teas@ietf.org>
Cc: teas-chairs@ietf.org; ccamp-chairs@ietf.org
Subject: Joint WG last call on draft-ietf-ospf-availability-extensio= n-04

 

CCAMP, TEAS,<= /p>

 

This starts a two weeks joint w= orking group last call on draft-ietf-ccamp-ospf-availability-extension-04

The last call end on Wednesday = May 26th. Please send your comments to both the CCAMP and TEAS m= ailing lists.

 

All the IPR declarations from a= uthors and contributors have been collected and can be found in the history= of the document: https://datatracker.ietf.org/doc/draft-ietf-ccamp-ospf-availability-extensi= on/history/

Please note that no IPR was dis= closed against this draft.

 

As usual this is also a call fo= r shepherd. If anyone is willing to be the shepherd of the document, please= volunteer.

 =

Thanks=

Daniele, Fatai, Lou, Pav= an

 

--_000_4A1562797D64E44993C5CBF38CF1BE48162F21D4ESESSMB301erics_-- From nobody Fri May 27 14:40:34 2016 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 CFEEC12D0E0; Fri, 27 May 2016 14:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=infinera.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 Fa1jcngN9xaz; Fri, 27 May 2016 14:40:27 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0069.outbound.protection.outlook.com [207.46.100.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C2CC12B013; Fri, 27 May 2016 14:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infinera.onmicrosoft.com; s=selector1-infinera-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5mr3qINkTqh0X0y4W57rXnmmyy6fzhN4f2zAJ/+41EY=; b=EmEdSSTMzTEZrvalmip/lNDcasiCZ9t5C94+Fz7MWk+oM3StB8mlykVB8wrlMm3BZzHDhEF3bfYYpfgYgIcPQOh9mtw7gzFYUVT28cYvb4ZtI2AcEQXijEV8tm1ndJ3Y3V2P/KVv7N1gJLM+fDdddb8WgT6P+GfDMZRMsBazAw0= Received: from CY1PR1001CA0025.namprd10.prod.outlook.com (10.163.136.35) by SN1PR10MB0446.namprd10.prod.outlook.com (10.162.102.26) with Microsoft SMTP Server (TLS) id 15.1.506.9; Fri, 27 May 2016 21:40:13 +0000 Received: from BY2FFO11FD020.protection.gbl (2a01:111:f400:7c0c::133) by CY1PR1001CA0025.outlook.office365.com (2a01:111:e400:5311::35) with Microsoft SMTP Server (TLS) id 15.1.506.9 via Frontend Transport; Fri, 27 May 2016 21:40:13 +0000 Authentication-Results: spf=pass (sender IP is 204.128.141.23) smtp.mailfrom=infinera.com; cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=bestguesspass action=none header.from=infinera.com; Received-SPF: Pass (protection.outlook.com: domain of infinera.com designates 204.128.141.23 as permitted sender) receiver=protection.outlook.com; client-ip=204.128.141.23; helo=owa.infinera.com; Received: from owa.infinera.com (204.128.141.23) by BY2FFO11FD020.mail.protection.outlook.com (10.1.14.137) with Microsoft SMTP Server (TLS) id 15.1.497.8 via Frontend Transport; Fri, 27 May 2016 21:40:12 +0000 Received: from SV-EX13-PRD1.infinera.com (10.100.103.228) by sv-ex13-prd1.infinera.com (10.100.103.228) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 27 May 2016 14:39:42 -0700 Received: from SV-EX13-PRD1.infinera.com ([10.100.97.11]) by sv-ex13-prd1.infinera.com ([10.100.97.11]) with mapi id 15.00.1178.000; Fri, 27 May 2016 14:39:42 -0700 From: Iftekhar Hussain To: "Tarek Saad (tsaad)" , "Chenxia (D)" , Himanshu Shah , "Wen, Bin" , Vishnu Pavan Beeram , "Raqib Jones" , "Rakesh Gandhi (rgandhi)" , "Kamran Raza (skraza)" , "xufeng.liu.ietf@gmail.com" , Igor Bryskin , "Zhangxian (Xian)" , =?utf-8?B?UGF3ZcWCIEJyem96b3dza2k=?= , "Anurag Sharma" , Xufeng Liu , =?utf-8?B?UGF3ZcWCIEthY3ptYXJlaw==?= Thread-Topic: [Teas] MPLS and TE tunnels YANG data model meeting Thread-Index: AQHRuC6jLG/BK6O9nE28Z5qBXSAj3Z/NTaBg Date: Fri, 27 May 2016 21:39:41 +0000 Message-ID: References: <5F01580A-8462-4C3E-B353-FBB0C960527E@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.100.99.93] Content-Type: multipart/alternative; boundary="_000_c4bf27174a104d96bbfe99d6878b2cebsvex13prd1infineracom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:204.128.141.23; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(2980300002)(438002)(377454003)(37854004)(189002)(199003)(52044002)(497574002)(1220700001)(102836003)(586003)(33646002)(3846002)(19617315012)(6116002)(790700001)(5001970100001)(11100500001)(16236675004)(189998001)(87936001)(15975445007)(5001770100001)(108616004)(2906002)(86362001)(16796002)(92566002)(50986999)(77096005)(80792005)(4326007)(5004730100002)(76176999)(19300405004)(54356999)(10400500002)(2900100001)(2950100001)(551544002)(84326002)(4546004)(106116001)(19625215002)(106466001)(53416004)(8936002)(512874002)(19580405001)(5008740100001)(5003600100002)(6806005)(2501003)(8666003)(16799955002)(8676002)(19580395003)(24736003)(7059030)(921003)(1121003)(559001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR10MB0446; H:owa.infinera.com; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD020; 1:pdHip76NtoOlg2AoQK7dD5Ufgm6XnfMFoLY8eCuU5XhTxFLfDwj388RcOFzxK/gCpXoS91JApZues2Ae+vodKP9CPvg62J+VOUEH/qfGUY+1wEVtW5TVyfX2xfapxCMK9RDpl/Vq63glq4G0pEo5kC+FiPjz9781SMeDXe0a7cpdwS5hJRRby1u6+cS14swhuWSpSfgnSsnMmrbP7gYqu2SJX/CCPdYgEEQ5SRZAArvDc+uZOW5aP7n4B9Cg6q9q/M7PJr2i83cyC6R8MqCItlsa/P0VENiGtmBLARSilahXBGYpuqLy1AVPh8Yo4oJPB5mpPRCFeMJmRLLHhiKRTaXzaR3UOGOWsfdszJHDfBmqpf/HB9Rs5vXZjAnABRcfxTuN6xRIEZI8PfbYM8AB955HuNHcWmyUU/wg03Sz+WuhkaMOtkNuqHoLmed/LVHHKO+TsfeC6bN5jbvgAPuBgv9kxe13Xhvf4a8gSrUxkCg5BeOl79vppXtnxFVOFrblNjFrsI97qlJwxol2M2c1w7f0+A6E0Q13GVsZa/v+t18= X-MS-Office365-Filtering-Correlation-Id: aff329b5-287f-4ba2-cb5a-08d386777c05 X-Microsoft-Exchange-Diagnostics: 1; SN1PR10MB0446; 2:Mp7ABgo7KJVMiZAzm9yhYeQhaLGIQ5oQ9VygI5CqLz5f67B+hdvkRJK6hSI6GBLxKAdzeYlx6XKtU8i/myi3dkwZBc732Uhogohs4soP8UQkI2ByL0Gztu7nG21cBiOD+weg3qYCjg0NGdDMM86SzUGaC6rPi5rTIjFkYuhGMJnjlC+kZ7Mqis0ZP+mKzngD; 3:GzwxJSQyNspklAvSV0ExFxidxfWX0Re2k3Ew06FRHHCPpSNPHasFOk3Lsad2WzSEMr1OND7Sr729Wenb6fDqojd4V9o6Tt0JRMisM5nQOWehfQGnxQJqqu+hbsuxQ1zcEI18lfXEIqjYgnk7SK++ZN0EThl+8n4a+wzUQzGbb+9TXEskNXqux8RwYXtz2+kIkg2HDX3x8f+bsXsWDy4ompDgpqEBu+Cxazfy7E/JVehSqf8MWYnsEvtG0H6sHwRPqzMO1xDLeBf1w9IuxIiDRQ== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:SN1PR10MB0446; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN1PR10MB0446; 25:5ElDGJLWXiUtr+JLxjyAJ40Cb7S+eTlrs4mCGt+LU?= =?us-ascii?Q?Iou9R4V0qrSiM8LayBOd6glCoCuDrnTD2lfefdqashGzwmiH87Fw1k0rVX/X?= =?us-ascii?Q?acGWCMP+EIwBr/6veF4cxjDe+8vqwpI1G0saGrDZlsd2hIh4+WjnWsNR1IF4?= =?us-ascii?Q?ACfaadvQSFPwcoFQ5YIm1mQbsAeBXdpcmx0t/+vlJ9sPcTDCUo6ef1lvtmV4?= =?us-ascii?Q?UlcDZ6EAU/kD2kJQtaYttl71PYtSpRJNDvc1KVCBfO4W4I5gqBkdAIDWXy2g?= =?us-ascii?Q?uyd3NikbVVaF6ARrWzsh+y+7oJviB07JKiqNq0pP1sX4xCWBABCbwdaQzwly?= =?us-ascii?Q?9SnsdUyHNs42vBNweg2RjDhAoIKyxCY3j+85OdF17f7G6nsOBlTqy06fwMAN?= =?us-ascii?Q?pSKkl7aKwxsIbLtkauMhWUWnAd/5qKHCFOmjsShvMGfw3Dn8VaYDFx5OmtWK?= =?us-ascii?Q?d0SDb2ui2fzY4d5cxhhkg23orSAf7rf2wcVOh9Nr83KRzv+eUhYXXnOa42uI?= =?us-ascii?Q?gKxQdDrccv1Jxdd3G3BrcAdq2APEBoYSIzPSi3+uS3zbHCovrAmfQ78/GuKp?= =?us-ascii?Q?o73K+iAIo0gqyMPwe7JOsKkjbA6dbgOAw6syieUAxsIa5IXp2g6tqamjAR/7?= =?us-ascii?Q?13o2Mo7w7cXbpeUQE6Glh2V9PlipsjY3At/YTK+1P3j8ME9nMkpK/08UfFt5?= =?us-ascii?Q?0m0WQOEn7Oo2aFFZJRZTpBk+nFdkcVA43q3PK6xYYCXhacF6U39Fpr+hr/Lq?= =?us-ascii?Q?v03iI9HJnT3J2K2+bfo1tLCBgA+lXNalqz6DdngWGrp3XF23HgwZNwNWXGVW?= =?us-ascii?Q?ex5ruvLNQ9AkMJAO0swakvJ3FHvOVwABlKFeDcwqh68z5wDf6RyBWdCN7H/L?= =?us-ascii?Q?Wmc9YlpUcPodMQHs9QNtyKGv2rsyumob5byeteZteqGh+vEix0LCe4rFfZc0?= =?us-ascii?Q?dNHWQi5QPA+QBF9LVTNn52FqEa3oYLRoXH1f1ITZgKnQfz8ubn6c96lbXY/s?= =?us-ascii?Q?223HWDz9jHUSoofW/IBcbx8cJYgPAhoycYCiJqXwdEK0A=3D=3D?= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(99586504457433)(50582790962513)(62221491112393)(94707916325470)(95692535739014)(198313997877955)(21748063052155)(138986009662008)(118321135141591); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13023025)(8121501046)(13018025)(13015025)(5005006)(13017025)(13024025)(3002001)(10201501046); SRVR:SN1PR10MB0446; BCL:0; PCL:0; RULEID:; SRVR:SN1PR10MB0446; X-Microsoft-Exchange-Diagnostics: 1; SN1PR10MB0446; 4:izUrhmFD+S7ohx41SKCi5pC67Ke8kNZq0js+Su3XQmBR4Lg5kuYGlecR0HU7SKAPmD/jgjTTpHypjV7yfgsuBO+9d3m18CVOaMt7gQYY9WuGsXpqft8henXtfLVY2aJSaqytb6MJbFE1fq/Iir4S5RfGaQKgWgtwFXXyL13cWAJUy1TsSHhi+ycj/V9BLouRgqX2MDNkd2ke+opTHEeoqk1UkU/0ju53DVbwHbsHo+Stb3En2fmd1CB0VSu/QI8bZ+rmv1M/tInxeIOO9d5/OeB++p8FMQEDO2xK6gb47esefgn+Pksj/u+s5UnM7+JuFoxX1tE9GR7JnkfeLln5H+ZbrcGfDLCpO7zFGeSrlyI55jURL5ZjZYOKFzhwI20y9rIJALZ28orV/tY5+hcnCw2ZiGFwbH5Tz2zJ+6wHJNGoXy/26/gpJINFdf1FWj1qljg/CLFFJN+ZH2hduo3Fl8PpaJhc1OzedqVA8i5LbZDR8Ly8e8/C7LJrMY1YbIBKW95I8eYXUiXcyXuc+9EAwWeNkh07JRxtbvQZxyDMAIuu05yMi8GnjMJWXKXVLEi5X+72CI7bQK1PkqEEiY+sLL4NY4KO2X0AnPfuAmRlsPA7M9c6070YRCekmUvQGiBG8KT1G39Tu6SgJn7W8eyQoQ99ItUMhF0LEmQwrjjzmf7ert/xSZFDZY2txC0Kdb9tl82WOexulYVw+jMcro37hE1x+BklihBBgaxd/YxT9+kgzP8pzNdhRCjyamdCa8xTgyJIYoy5dUtt0ZBLrHhUTw== X-Forefront-PRVS: 09555FB1AD X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN1PR10MB0446; 23:omyHjAp50iCxyMzwn9sgoszizlR8WmMp5HwXHgl3Q?= =?us-ascii?Q?cdgWw+Eitrc8oshmSBPJvhPlTOQB99I8PwvuOvqcRdD7plahgLu/zZDaCB9k?= =?us-ascii?Q?sxfQeKlsxQ4ShpFe5C082hinyKVATuy+wl8ryRhDTPaK7QpeXsEg61UAB3qW?= =?us-ascii?Q?Mwz68kU5y4zwlawxEQfX268H4TP2GINaX9kTA1HMyS8WnFny3AgnXQ5cEliB?= =?us-ascii?Q?0N7tj8PkLCW3VRKAY7/z/jMryJnDXoxaDdKnypFe2y0iUWbNeJYyNCAifVHq?= =?us-ascii?Q?bhDZBeMMFL2jb6Zg5IgXbZrjzHBK7mbFp393yR3avlWoUXe+kxf3jlykFclA?= =?us-ascii?Q?fJi6hhH5hA77329NUuWSy6j5DKNwN3B1kWfRSudsJRYHwUNCD6FR5BH88OFP?= =?us-ascii?Q?PxTHW2cA1szesiemoV/UOy/R0tZXyQ2Hi5g0orgvbY4FcVKRJUJbGJn8kfq2?= =?us-ascii?Q?QjFMx/zuBNPx6qbzlo4BZpPcESXinDTpvSA2MORSyROB/aBXvWz9yrz0gnXA?= =?us-ascii?Q?eHCdo1B2WI7DQrc1Qh9WVE77xicftcYBtGnMZRl2HkaYUf7RXp6mp6mmUGb4?= =?us-ascii?Q?ZnvUvKXYHLRMPA8W9zO83Eq2ekmK5JJTTUMP1f9r6/GZd+1JW2et2VxUfAX0?= =?us-ascii?Q?iscnUDtgNWI2RgNPwSPjiWXFqUePSTXHb3pHP3V2JotGdwlgtPXXHFNWaJMR?= =?us-ascii?Q?nGz1WoDAXCXWw6MdssN1dk5AW6MemLOEz0eRqPDdobZUl44vN+jeNUaz0suC?= =?us-ascii?Q?Xj+QYXi/JK8VU7raWAJggX85rBQ5m9/em6ckvG1Cn8ofRBgGg6cjVQotsa52?= =?us-ascii?Q?JNG71g2VF59DhSlyc2w5xz7/v/tx8HwE9OLj2FxjTGKZek6R9LqmljVh7OJu?= =?us-ascii?Q?TE2TI8MeAyMhpGHVW7pk3BdrtE0f1WBoXxo8xFgk8QOzEgBotX9292FqjqHf?= =?us-ascii?Q?bd6Gfg4jC+CCh0IZaGFrrOug+apKT7ayIiHkJQDFz0U7ydv9CeQS6wDww19N?= =?us-ascii?Q?cPbZ/93bXqTaf5qWbpa4X4ZLhfKOmbFP3//gFpmzNQ1A/TTALMmuWNAwjYhU?= =?us-ascii?Q?QpXUMGpKN4TdW6PZTPmDK8PJOtWg6NM4pLBPL5ip6JBaP9VVIzr6z8UUGDmd?= =?us-ascii?Q?lDez+FWO0SbGAaz5O/m3JyX6irlNJjNqA2Lv5HwRdXSrWzXAvwBm2BTdOl9e?= =?us-ascii?Q?FldLpDktHhsmxQZLYXgwmql7U2oKRX7+wue5l0gdB8d2ICvlbX8TkSQ1qf5J?= =?us-ascii?Q?R2nin5j3ogjByeULHHbs7s5WlXS7WdKn123syJvnnNsrmsX1B4v5vGWZQ6Z5?= =?us-ascii?Q?yIdySsDqHfudo+lP7UCyUNlL6Cbh/P8/OYNn0FDSXsptupGNkDtOH4KXeZjp?= =?us-ascii?Q?Dy5KIfbZT4NwBVYk4KYXNcrA+TLnot3BmWhlECROvSjm0frofen3nEZBYW7y?= =?us-ascii?Q?g7uuVYjpJUdPe8Wh70hBfrOqbz0ZPJd4AYJDiA60PSyx6DmJhhqYtW6D+1Xh?= =?us-ascii?Q?yN0r973jP12zTiZVG0am1tnmTlPsbbAScLk3qnCosESLHu8bufZw0PbjqTib?= =?us-ascii?Q?60Yd6nUziQwqkNA/BsLLRi9G8gjeESjvbCHa7qSMJeUqUI3tziegRkp0M+k?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR10MB0446; 5:KSBtnj/bqy4x9UQrWi7RgV7ERBtzHwSralNY3nuO1emlMbx4i5RQlh7HT8zlMIJrkJxiIDwooBNadqbSjPJGYJfRSBr5FQj70jvRmEzJl4d+pEkXQpGqybMMWXIZwZuj/c15bCA5pnbqz9oXfHIxEQ==; 24:Xg4Rhdp5RQphh2l5Ynkpoee7AST+RvEsG+ah2fqO7LwJbuTcG//nSPNLFGPFc+YPiFvWMjIMB/vOENfL/709M54o70k1NXzt+JdOtWYBIAw=; 7:gIfNztA44208kv6/GJ1Bl24QSWHeUlP39X5PR+9OeL/EWsBcQgKV5V9BlkqdxmgYCWnXesKFOVVhrCc0mcOXseFeDkndm8Wzq/eDDZMepWoIpmcZ3t/n8ao6Cq1Gr1WHSPbqzwmD33wK0iteeJ6EKrPG9ptTb7Q+pxzFj/wpKI72cQU1SvWo6IBaqrcDWgKP SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: infinera.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 May 2016 21:40:12.8108 (UTC) X-MS-Exchange-CrossTenant-Id: 285643de-5f5b-4b03-a153-0ae2dc8aaf77 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=285643de-5f5b-4b03-a153-0ae2dc8aaf77; Ip=[204.128.141.23]; Helo=[owa.infinera.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR10MB0446 Archived-At: Cc: "mpls@ietf.org" , "teas@ietf.org" Subject: Re: [Teas] MPLS and TE tunnels YANG data model meeting X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 27 May 2016 21:40:31 -0000 --_000_c4bf27174a104d96bbfe99d6878b2cebsvex13prd1infineracom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGFyZWsgYW5kIEFsbCwNCg0KSnVzdCBjYXRjaGluZyB1cC4gIENvdXBsZSBvZiBxdWljayBx dWVzdGlvbi4gQXBvbG9naWVzIGlmIGl0IGhhcyBhbHJlYWR5IGJlZW4gZGlzY3Vzc2VkLg0KDQrC tyAgICAgICAgIFN0YXRpYyBMU1Agb3B0aW9uICMyIGJlbG93LCBkbyB5b3UgbWVhbiBMU1AtSUQg aW5zdGVhZCBvZiDigJx0dW5uZWwgSUTigJ0/DQoNCsK3ICAgICAgICAgSG93IGlzIHRoZSBvcGVy YXRpb25hbCBzdGF0ZSBvZiBiaWRpcmVjdGlvbmFsIExTUCBtb2RlbGVkPw0KDQrCtyAgICAgICAg IENhbiB5b3UgcGxlYXNlIHNlbmQgYSBwb2ludGVyIHRvIHRoZSBTUi1URSB0dW5uZWwgbW9kZWw/ DQoNClRoYW5rcywNCklmdGVraGFyDQoNCkZyb206IFRhcmVrIFNhYWQgKHRzYWFkKSBbbWFpbHRv OnRzYWFkQGNpc2NvLmNvbV0NClNlbnQ6IEZyaWRheSwgTWF5IDI3LCAyMDE2IDg6MzUgQU0NClRv OiBDaGVueGlhIChEKTsgSGltYW5zaHUgU2hhaDsgV2VuLCBCaW47IFZpc2hudSBQYXZhbiBCZWVy YW07IFJhcWliIEpvbmVzOyBSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKTsgS2FtcmFuIFJhemEgKHNr cmF6YSk7IHh1ZmVuZy5saXUuaWV0ZkBnbWFpbC5jb207IElnb3IgQnJ5c2tpbjsgWmhhbmd4aWFu IChYaWFuKTsgUGF3ZcWCIEJyem96b3dza2k7IEFudXJhZyBTaGFybWE7IFh1ZmVuZyBMaXU7IFBh d2XFgiBLYWN6bWFyZWsNCkNjOiBtcGxzQGlldGYub3JnOyB0ZWFzQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW1RlYXNdIE1QTFMgYW5kIFRFIHR1bm5lbHMgWUFORyBkYXRhIG1vZGVsIG1lZXRpbmcN Cg0KQ29ycmVjdGluZyBtcGxzIFdHIGFsaWFzLA0KDQpGcm9tOiBUYXJlayBTYWFkIDx0c2FhZEBj aXNjby5jb208bWFpbHRvOnRzYWFkQGNpc2NvLmNvbT4+DQpEYXRlOiBGcmlkYXksIE1heSAyNywg MjAxNiBhdCAxMTozMyBBTQ0KVG86ICJDaGVueGlhIChEKSIgPGplc2NpYS5jaGVueGlhQGh1YXdl aS5jb208bWFpbHRvOmplc2NpYS5jaGVueGlhQGh1YXdlaS5jb20+PiwgSGltYW5zaHUgU2hhaCA8 aHNoYWhAY2llbmEuY29tPG1haWx0bzpoc2hhaEBjaWVuYS5jb20+PiwgIldlbiwgQmluIiA8Qmlu X1dlbkBjYWJsZS5jb21jYXN0LmNvbTxtYWlsdG86QmluX1dlbkBjYWJsZS5jb21jYXN0LmNvbT4+ LCBWaXNobnUgUGF2YW4gQmVlcmFtIDx2YmVlcmFtQGp1bmlwZXIubmV0PG1haWx0bzp2YmVlcmFt QGp1bmlwZXIubmV0Pj4sIFJhcWliIEpvbmVzIDxyYXFpYkBCcm9jYWRlLmNvbTxtYWlsdG86cmFx aWJAQnJvY2FkZS5jb20+PiwgIlJha2VzaCBHYW5kaGkgKHJnYW5kaGkpIiA8cmdhbmRoaUBjaXNj by5jb208bWFpbHRvOnJnYW5kaGlAY2lzY28uY29tPj4sICJLYW1yYW4gUmF6YSAoc2tyYXphKSIg PHNrcmF6YUBjaXNjby5jb208bWFpbHRvOnNrcmF6YUBjaXNjby5jb20+PiwgInh1ZmVuZy5saXUu aWV0ZkBnbWFpbC5jb208bWFpbHRvOnh1ZmVuZy5saXUuaWV0ZkBnbWFpbC5jb20+IiA8eHVmZW5n LmxpdS5pZXRmQGdtYWlsLmNvbTxtYWlsdG86eHVmZW5nLmxpdS5pZXRmQGdtYWlsLmNvbT4+LCBJ Z29yIEJyeXNraW4gPElnb3IuQnJ5c2tpbkBodWF3ZWkuY29tPG1haWx0bzpJZ29yLkJyeXNraW5A aHVhd2VpLmNvbT4+LCAiWmhhbmd4aWFuIChYaWFuKSIgPHpoYW5nLnhpYW5AaHVhd2VpLmNvbTxt YWlsdG86emhhbmcueGlhbkBodWF3ZWkuY29tPj4sIFBhd2XFgiBCcnpvem93c2tpIDxQQnJ6b3pv d3NraUBhZHZhb3B0aWNhbC5jb208bWFpbHRvOlBCcnpvem93c2tpQGFkdmFvcHRpY2FsLmNvbT4+ LCBBbnVyYWcgU2hhcm1hIDxBblNoYXJtYUBpbmZpbmVyYS5jb208bWFpbHRvOkFuU2hhcm1hQGlu ZmluZXJhLmNvbT4+LCBYdWZlbmcgTGl1IDx4bGl1QGt1YXRyb3RlY2guY29tPG1haWx0bzp4bGl1 QGt1YXRyb3RlY2guY29tPj4sIFBhd2XFgiBLYWN6bWFyZWsgPFBLYWN6bWFyZWtAYWR2YW9wdGlj YWwuY29tPG1haWx0bzpQS2Fjem1hcmVrQGFkdmFvcHRpY2FsLmNvbT4+DQpDYzogInRlYXNAaWV0 Zi5vcmc8bWFpbHRvOnRlYXNAaWV0Zi5vcmc+IiA8dGVhc0BpZXRmLm9yZzxtYWlsdG86dGVhc0Bp ZXRmLm9yZz4+LCAibXBsc0BpZXRmIiA8bXBsc0BpZXRmPg0KU3ViamVjdDogUmU6IE1QTFMgYW5k IFRFIHR1bm5lbHMgWUFORyBkYXRhIG1vZGVsIG1lZXRpbmcNCg0KQ29weWluZyBXRyBmb3IgZnlp IGFzIGZlZWRiYWNrIGFzIHBlciBhZ3JlZW1lbnQuDQoNClRoYW5rcyBhbGwgZm9yIGF0dGVuZGlu ZyBtZWV0aW5nIHdlZWtseSBtZWV0aW5nIHRvZGF5LiBCZWxvdyBhcmUgdG9kYXnigJlzIE1vTXMu IEZlZWwgZnJlZSB0byBhZGQgaWYgSSBtaXNzZWQgYW55Lg0KDQpSZWdhcmRzLA0KVGFyZWsNCg0K RnJpZGF5IE1heSAyNywgMjAxNjoNCj09PT09PT09PT09PT09PT09PT0NCkFnZW5kYToNCkEuIERp c2N1c3MgbmV3IHVwZGF0ZShzKSB0byBNUExTIHN0YXRpYyBMU1BzIG1vZHVsZQ0KICAgLSBuZXcg c3RhdGljIExTUCBhdHRyaWJ1dGVzDQogICAtIHN0YXRpYyBiaWRpcmVjdGlvbmFsIExTUHMNCiAg IC0gc3RhdGljIE1CQg0KICAgLSBzdGF0aWMgZW5kLXRvLWVuZCBMU1AgcHJvdGVjdGlvbg0KQi4g RGlzY3VzcyBTUi1URSBuZXcgbW9kdWxlIGRldGFpbHMNCkMuIGhvdyB0byBwcm9jZWVkIHdpdGgg c2NoZW1hIG1vdW50DQoNCi0tPiBBSTogdG8gc2VuZCBhIGRvb2RsZSBmb3IgU1ItVEUgbWVldGlu Zw0KDQpBLiBTUi1URToNCj09PT09PT09PQ0KRXhwbGljaXQgcGF0aDoNCi0gbGFiZWwgKGFscmVh ZHkgaGF2ZSBpdCBpbiBURSBtb2RlbCkNCi0gU0lEIGluZGV4DQoNClR1bm5lbDoNCm5ldzogYmlu ZGluZy1sYWJlbCAobm90IHNwZWNpZmljIHRvIFNSIHR1bm5lbCkNCm5ldzogcGVyIHBhdGggInNl Z21lbnQtcm91dGluZyIgYXR0cmlidXRlDQpuZXc6IHBlciBwYXRoIGNvbnN0cmFpbnRzOg0KICAg ICAgLSBjb3N0IGxpbWl0DQogICAgICAtIGxpbmsvYWRqLVNJRCBwcm90ZWN0aW9uIHR5cGVzOiBh bnksIHByb3RlY3RlZCwgdW5wcm90ZWN0ZWQNCiAgICAgIC0gaW52YWxpZGF0aW9uIHRpbWVvdXQN CiAgICAgIC0gaW52YWxpZGF0aW9uIGFjdGlvbg0KICAgICAgICAtIGRyb3ANCiAgICAgICAgLSB0 ZWFyDQogICAgICAtIHByZXBlbmQgbGFiZWwocykgcGVyIHBhdGgNCiAgICAgIC0gcHJlcGVuZCBi Z3AtbmV4dC1ob3ANCg0KDQpOZXcgVEUgbGluayBhdHRyaWJ1dGVzIChzdGF0ZS1vbmx5KToNCkRl bGF5Og0K4oCTIFVuaWRpcmVjdGlvbmFsIExpbmsgRGVsYXkgKEQpDQrigJMgTWluL01heCBVbmlk aXJlY3Rpb25hbCBMaW5rIERlbGF5IChETSkNCuKAkyBVbmlkaXJlY3Rpb25hbCBEZWxheSBWYXJp YXRpb24gKERWKQ0KDQpMb3NzOg0K4oCTIFVuaWRpcmVjdGlvbmFsIExpbmsgTG9zcyAoTCkNCg0K QmFuZHdpZHRoOg0K4oCTIFVuaWRpcmVjdGlvbmFsIFJlc2lkdWFsIEJhbmR3aWR0aCAoQlIpDQri gJMgVW5pZGlyZWN0aW9uYWwgQXZhaWxhYmxlIEJhbmR3aWR0aCAoQkEpDQrigJMgVW5pZGlyZWN0 aW9uYWwgVXRpbGl6ZWQgQmFuZHdpZHRoIChCVVRJTCkNCg0KDQpCLiBVcGRhdGUgdG8gTVBMUyBz dGF0aWMgTFNQcw0KTmV3IGF0dHJpYnV0ZXMgZm9yIHN0YXRpYyBMU1BzIG5lZWRlZCB0byBhbGxv Y2F0ZSByZXNvdXJjZXMgb24gcGVyIGhvcC9saW5rOg0KLSBCVyB3aXRoIENUcz8NCi0gcHJpb3Jp dHkvcHJlZW1wdGlvbg0KLSBkaXNjdXNzaW9uLCB3aGF0IG9jY3VycyBpZiBzdGF0aWMgTFNQcyBp cyBjb250ZW5kaW5nIHdpdGggUlNWUCBhbGxvY2F0aW9uIChhdCBzYW1lIG9yIGRpZmZlcmVudCBw cmlvcml0eSk/DQoNCkJpZGlyZWN0aW9uYWwgU3RhdGljIExTUHM6DQpPcHRpb24gIzE6DQoNCi0g ICAgICAgICAgYXNzb2NpYXRpb24gb2YgZm9yd2FyZC9yZXZlcnNlIHNpYmxpbmdzIG1haW50YWlu ZWQgaW4gaGllcmFyY2hpY2FsIGNvbmZpZ3VyYXRpb24gKHVuZGVyIHNhbWUgTFNQKG5hbWU9Zm9v KSkNCkxTUChuYW1lPWZvbyk6DQpCVw0KYmlkaXJlY3Rpb25hbA0KZm9yd2FyZA0KICAgQlcxDQog ICBpbi1zZWdtZW50IChpbi1sYWJlbCwgbmV4dC1ob3ApDQogICBvdXQtc2VnbWVudCAob3V0LWxh YmVsKHMpLCBuZXh0LWhvcCkNCnJldmVyc2UNCiAgIEJXMg0KICAgaW4tc2VnbWVudCAoaW4tbGFi ZWwsIG5leHQtaG9wKQ0KICAgb3V0LXNlZ21lbnQgKG91dC1sYWJlbChzKSwgbmV4dC1ob3ApDQoN Ci0tPiBJbiBjdXJyZW50IG1vZGVsIHRoZSBMU1AgaGFzIG9ubHkgb25lIGNyb3NzLWNvbm5lY3QN Ci0tPiB3aWxsIG5lZWQgdG8gaGF2ZSBtdWx0aXBsZSBjcm9zcy1jb25uZWN0cyBwZXIgTFNQDQot LS0+IHRvIHJlYWxpemUgYXN5bW1ldHJpY2FsIGJlaGF2aW9yIChlZy4gQlcgYWxsb2MpIG5lZWQg dG8gYWxsb3cgY29uZmlnIHVuZGVyIGVhY2ggZm9yd2FyZC9yZXZlcnNlIGxlZw0KDQpPcHRpb24g IzI6DQoNCi0gICAgICAgICAgZm9yd2FyZC9yZXZlcnNlIExTUHMgYXMgc2VwYXJhdGUgZW50cmll cyBpbiB0aGUgc3RhdGljIExTUCBsaXN0DQoNCi0gICAgICAgICAgZW50cmllcyBoYXZlIGRpZmZl cmVudCBuYW1lcywgYnV0IGFzc29jaWF0ZWQgdXNpbmcgYmVsb3cNCg0KLSAgICAgICAgICB1c2Ug YSBjb25maWd1cmVkIGFzc29jaWF0aW9uLUlEICh0dW5uZWwtSUQgb3Igc2VydmljZS1JRCkgYXMg d2F5IHRvIGFzc29jaWF0ZSBMU1BzDQpMU1AobmFtZT1mb28tZm9yd2FyZCk6DQpiaWRpcmVjdGlv bmFsDQpmb3J3YXJkDQphc3NvY2lhdGlvbiBJRCA9IDEwMDENCmluLXNlZ21lbnQgKGluLWxhYmVs LCBuZXh0LWhvcCkNCm91dC1zZWdtZW50IChvdXQtbGFiZWwocyksIG5leHQtaG9wKQ0KDQpMU1Ao bmFtZT1mb28tcmV2ZXJzZSk6DQpiaWRpcmVjdGlvbmFsDQpyZXZlcnNlDQphc3NvY2lhdGlvbiBJ RCA9IDEwMDENCmluLXNlZ21lbnQgKGluLWxhYmVsLCBuZXh0LWhvcCkNCm91dC1zZWdtZW50IChv dXQtbGFiZWwocyksIG5leHQtaG9wKQ0KDQpPcHRpb24gIzM6DQoNCi0gICAgICAgICAgZm9yd2Fy ZC9yZXZlcnNlIExTUHMgYXMgc2VwYXJhdGUgZW50cmllcyBpbiB0aGUgc3RhdGljIExTUCBsaXN0 DQoNCi0gICAgICAgICAgYm90aCBlbnRyaWVzIGhhdmUgdGhlIHNhbWUgbmFtZSwgYnV0IG5ldyBr ZXkgaXMgbmVlZGVkIGlpbiB0aGUgbGlzdCAocm9sZT8sIGUuZy4gc2libGluZzEsIHNpYmxpbmcy LCBldGMuLikNCg0KDQpNQkIgZm9yIFN0YXRpYzoNCjEuIGhvdyB0byByZWFsaXplIHJlc291cmNl IHNoYXJpbmcgaWYgbmVlZGVkPw0KMi4gY29vcmRpbmF0ZSBzd2l0Y2hvdmVyIG9uIHRoZSBpbmdy ZXNzIHVzaW5nIGNvbmZpZ3VyYXRpb24NCg0KT3B0aW9uIzIgKGFkZCByb2xlIGluIGxpc3Qgb2Yg TFNQcyBrZXkpLCBlLmcuIGtleT0gKG5hbWU9Zm9vLCByb2xlPW1iYi1zaWJsaW5nMSksIChuYW1l PWZvbywgbWJiLXNpYmxpbmcyKSwgKG5hbWU9Zm9vLCBwYXRoLXByb3RlY3Qtc2libGluZzEpLCAo bmFtZT1mb28sIHBhdGgtcHJvdGVjdC1zaWJsaW5nMikNCg0KTFNQKGZvbywgbWJiLXNpYmxpbmcx KToNCmluLXNlZ21lbnQgKGluLWxhYmVsLCBuZXh0LWhvcCkNCm91dC1zZWdtZW50IChvdXQtbGFi ZWwocyksIG5leHQtaG9wKQ0KYXNzb2NpYXRpb24gSUQgPSAxMDAxDQpyb2xlPU1CQiBzaWJsaW5n DQoNCkxTUChmb28sIG1iYi1zaWJsaW5nMik6DQppbi1zZWdtZW50IChpbi1sYWJlbCwgbmV4dC1o b3ApDQpvdXQtc2VnbWVudCAob3V0LWxhYmVsKHMpLCBuZXh0LWhvcCkNCmFzc29jaWF0aW9uIElE ID0gMTAwMQ0Kcm9sZT1NQkIgc2libGluZw0KDQpUMDogdHJhZmZpYyBvbiBMU1AoZm9vMSkNClQx OiBjb25maWd1cmUgTFNQKGZvbzIpIG9uIG1pZChzKQ0KVDI6IG1hcCB0cmFmZmljIHRvIExTUChm b28yKSBvbiBpbmdyZXNzDQpUMzogZGVsZXRlIExTUChmb28xKQ0KDQoNCkJhY2tncm91bmQgKHNu aXBwZXQgZnJvbSBIdWF3ZWnigJlzIE9TIHN1cHBvcnQgZm9yIHN0YXRpYyBMU1ApOg0KW0xTUkFd IGJpZGlyZWN0aW9uYWwgc3RhdGljLWNyLWxzcCBpbmdyZXNzIFR1bm5lbDEvMC8wDQpbTFNSQS1i aS1zdGF0aWMtaW5ncmVzcy1UdW5uZWxsLzAvMF0gZm9yd2FyZCBuZXh0aG9wIDIuMS4xLjIgb3V0 LWxhYmVsIDIwIGJhbmR3aWR0aCBjdDAgMTAwMDANCltMU1JBLWJpLXN0YXRpYy1pbmdyZXNzLVR1 bm5lbGwvMC8wXSBiYWNrd2FyZCBpbi1sYWJlbCAyMA0KW0xTUkJdYmlkaXJlY3Rpb25hbCBzdGF0 aWMtY3ItbHNwIHRyYW5zaXQgbHNwMQ0KW0xTUkItYmktc3RhdGljLXRyYW5zaXQtbHNwMV0gZm9y d2FyZCBpbi1sYWJlbCAyMCBuZXh0aG9wIDMuMi4xLjIgb3V0LWxhYmVsIDQwIGJhbmR3aWR0aCBj dDAgMTAwMDANCltMU1JCLWJpLXN0YXRpYy10cmFuc2l0LWxzcDFdIGJhY2t3YXJkIGluLWxhYmVs IDE2IG5leHRob3AgMi4xLjEuMSBvdXQtbGFiZWwgMjAgYmFuZHdpZHRoIGN0MCAxMDAwMA0KW0xT UkNdIGJpZGlyZWN0aW9uYWwgc3RhdGljLWNyLWxzcCBlZ3Jlc3MgbHNwMQ0KW0xTUkMtYmktc3Rh dGljLWVncmVzcy1sc3AxXSBmb3J3YXJkIGluLWxhYmVsIDQwIGxzcmlkIDEuMS4xLjEgdHVubmVs LWlkIDEwMA0KDQpSZWdhcmRzLA0KVGFyZWsNCg0KDQpGcm9tOiB0c2FhZEBjaXNjby5jb208bWFp bHRvOnRzYWFkQGNpc2NvLmNvbT4NCldoZW46IDEwOjAwIEFNIC0gMTE6MDAgQU0gTWF5IDI3LCAy MDE2DQpTdWJqZWN0OiBNUExTIGFuZCBURSB0dW5uZWxzIFlBTkcgZGF0YSBtb2RlbCBtZWV0aW5n DQpMb2NhdGlvbjogd2ViZXgNCg0KDQpSZWZyZXNoaW5nIGludml0ZSBmb3IgTVBMUyBhbmQgVEUg dHVubmVscyBZQU5HIGRhdGEgbW9kZWwgbWVldGluZy4gUGxlYXNlIGZvcndhcmQgdG8gYW55b25l IEkgbWlzc2VkLg0KDQoNCg0KDQoNCg0KDQoNCg0KLS0gRG8gbm90IGRlbGV0ZSBvciBjaGFuZ2Ug YW55IG9mIHRoZSBmb2xsb3dpbmcgdGV4dC4gLS0NCg0KDQpKb2luIFdlYkV4IG1lZXRpbmc8aHR0 cHM6Ly9jaXNjby53ZWJleC5jb20vY2lzY29zYWxlcy9qLnBocD9NVElEPW1jMDU5ODJmMmQzYzQw NDJkZjIwYzJkZjU2ZjNjYzEyNz4NCk1lZXRpbmcgbnVtYmVyOiAyMDEgOTY2IDY5Mg0KTWVldGlu ZyBwYXNzd29yZDogM2p3TVJYRWQNCg0KDQpJZiB5b3UgYXJlIGEgaG9zdCwgZ28gaGVyZTxodHRw czovL2Npc2NvLndlYmV4LmNvbS9jaXNjb3NhbGVzL2oucGhwP01USUQ9bWU3ZjY1NDYyZWIyNTFk MjA1YzhlMjE2NjhlNTE0ZWU3PiB0byB2aWV3IGhvc3QgaW5mb3JtYXRpb24uDQoNCkpvaW4gYnkg cGhvbmUNCisxLTQwOC01MjUtNjgwMCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpDQor MS04NjYtNDMyLTk5MDMgQ2FsbC1pbiB0b2xsLWZyZWUgbnVtYmVyIChVUy9DYW5hZGEpDQpBY2Nl c3MgY29kZTogMjAxIDk2NiA2OTINCk51bWVyaWMgbWVldGluZyBwYXNzd29yZDogMjE3OTQxNzIN Ckdsb2JhbCBjYWxsLWluIG51bWJlcnM8aHR0cHM6Ly9jaXNjby53ZWJleC5jb20vY2lzY29zYWxl cy9nbG9iYWxjYWxsaW4ucGhwP3NlcnZpY2VUeXBlPU1DJkVEPTM1MTQ5NzMzMiZ0b2xsRnJlZT0x PiB8IFRvbGwtZnJlZSBjYWxsaW5nIHJlc3RyaWN0aW9uczxodHRwczovL3d3dy53ZWJleC5jb20v cGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGY+DQoNCg0KQ2FuJ3Qgam9pbiB0aGUgbWVldGlu Zz8gQ29udGFjdCBzdXBwb3J0LjxodHRwczovL2Npc2NvLndlYmV4LmNvbS9jaXNjb3NhbGVzL21j Pg0KDQpJTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2Vydmlj ZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNz aW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwg bWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2Vu dCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNv cmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4g dGhlIHNlc3Npb24uLg0KDQo= --_000_c4bf27174a104d96bbfe99d6878b2cebsvex13prd1infineracom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpNaW5nTGlVOw0KCXBhbm9zZS0xOjIgMiA1IDkgMCAwIDAgMCAwIDA7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJTZWdvZSBVSSI7DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiXEBNaW5nTGlVIjsNCglwYW5vc2UtMToyIDIgNSA5IDAgMCAwIDAg MCAwO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlm Ijt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3Jh cGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHls ZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1h cmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4u RW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5 bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyog TGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTI0NjAzODU1NjsN Cgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MzcwMTg5NzYy IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3 Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg bDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE3OTk4NDAyMTA7DQoJ bXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEyODU2OTk3ODIg LTE2ODQyNTM5MTQgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZl bC1zdGFydC1hdDoyOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyMC4yNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWZv bnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biI7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo1Ni4yNXB0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgltYXJnaW4tbGVmdDo5Mi4yNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjEy OC4yNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxNjQuMjVwdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ bWFyZ2luLWxlZnQ6MjAwLjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjM2LjI1cHQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTps ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjI3Mi4yNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4t bGVmdDozMDguMjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjIxMTk1MjI1MjA7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEwNzcwNDAxMzggMTYwNjMxODkyOCA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5 ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjI7 DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDMN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMjpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxp c3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTow aW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SGkgVGFyZWsgYW5kIEFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkp1c3QgY2F0Y2hpbmcgdXAuICZuYnNwO0Nv dXBsZSBvZiBxdWljayBxdWVzdGlvbi4gQXBvbG9naWVzIGlmIGl0IGhhcyBhbHJlYWR5IGJlZW4g ZGlzY3Vzc2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm81Ij48 IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpTeW1ib2w7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5TdGF0aWMgTFNQIG9wdGlvbiAjMiBiZWxvdywgZG8geW91IG1lYW4gTFNQLUlEIGlu c3RlYWQgb2Yg4oCcdHVubmVsIElE4oCdPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0Omww IGxldmVsMSBsZm81Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Ib3cgaXMgdGhlIG9wZXJhdGlvbmFsIHN0YXRlIG9mIGJp ZGlyZWN0aW9uYWwgTFNQIG1vZGVsZWQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzUiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNhbiB5b3UgcGxlYXNlIHNlbmQgYSBwb2ludGVyIHRvIHRo ZSBTUi1URSB0dW5uZWwgbW9kZWw/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPklmdGVraGFyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBUYXJlayBTYWFkICh0 c2FhZCkgW21haWx0bzp0c2FhZEBjaXNjby5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5 LCBNYXkgMjcsIDIwMTYgODozNSBBTTxicj4NCjxiPlRvOjwvYj4gQ2hlbnhpYSAoRCk7IEhpbWFu c2h1IFNoYWg7IFdlbiwgQmluOyBWaXNobnUgUGF2YW4gQmVlcmFtOyBSYXFpYiBKb25lczsgUmFr ZXNoIEdhbmRoaSAocmdhbmRoaSk7IEthbXJhbiBSYXphIChza3JhemEpOyB4dWZlbmcubGl1Lmll dGZAZ21haWwuY29tOyBJZ29yIEJyeXNraW47IFpoYW5neGlhbiAoWGlhbik7IFBhd2XFgiBCcnpv em93c2tpOyBBbnVyYWcgU2hhcm1hOyBYdWZlbmcgTGl1OyBQYXdlxYIgS2Fjem1hcmVrPGJyPg0K PGI+Q2M6PC9iPiBtcGxzQGlldGYub3JnOyB0ZWFzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbVGVhc10gTVBMUyBhbmQgVEUgdHVubmVscyBZQU5HIGRhdGEgbW9kZWwgbWVldGlu ZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q29ycmVjdGluZyBtcGxzIFdHIGFsaWFzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJv bToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGFyZWsgU2FhZCAmbHQ7PGEg aHJlZj0ibWFpbHRvOnRzYWFkQGNpc2NvLmNvbSI+dHNhYWRAY2lzY28uY29tPC9hPiZndDs8YnI+ DQo8Yj5EYXRlOiA8L2I+RnJpZGF5LCBNYXkgMjcsIDIwMTYgYXQgMTE6MzMgQU08YnI+DQo8Yj5U bzogPC9iPiZxdW90O0NoZW54aWEgKEQpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86amVzY2lh LmNoZW54aWFAaHVhd2VpLmNvbSI+amVzY2lhLmNoZW54aWFAaHVhd2VpLmNvbTwvYT4mZ3Q7LCBI aW1hbnNodSBTaGFoICZsdDs8YSBocmVmPSJtYWlsdG86aHNoYWhAY2llbmEuY29tIj5oc2hhaEBj aWVuYS5jb208L2E+Jmd0OywgJnF1b3Q7V2VuLCBCaW4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzpCaW5fV2VuQGNhYmxlLmNvbWNhc3QuY29tIj5CaW5fV2VuQGNhYmxlLmNvbWNhc3QuY29tPC9h PiZndDssDQogVmlzaG51IFBhdmFuIEJlZXJhbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZiZWVyYW1A anVuaXBlci5uZXQiPnZiZWVyYW1AanVuaXBlci5uZXQ8L2E+Jmd0OywgUmFxaWIgSm9uZXMgJmx0 OzxhIGhyZWY9Im1haWx0bzpyYXFpYkBCcm9jYWRlLmNvbSI+cmFxaWJAQnJvY2FkZS5jb208L2E+ Jmd0OywgJnF1b3Q7UmFrZXNoIEdhbmRoaSAocmdhbmRoaSkmcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzpyZ2FuZGhpQGNpc2NvLmNvbSI+cmdhbmRoaUBjaXNjby5jb208L2E+Jmd0OywgJnF1b3Q7 S2FtcmFuIFJhemEgKHNrcmF6YSkmcXVvdDsNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNrcmF6YUBj aXNjby5jb20iPnNrcmF6YUBjaXNjby5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRv Onh1ZmVuZy5saXUuaWV0ZkBnbWFpbC5jb20iPnh1ZmVuZy5saXUuaWV0ZkBnbWFpbC5jb208L2E+ JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86eHVmZW5nLmxpdS5pZXRmQGdtYWlsLmNvbSI+eHVm ZW5nLmxpdS5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7LCBJZ29yIEJyeXNraW4gJmx0OzxhIGhyZWY9 Im1haWx0bzpJZ29yLkJyeXNraW5AaHVhd2VpLmNvbSI+SWdvci5Ccnlza2luQGh1YXdlaS5jb208 L2E+Jmd0OywNCiAmcXVvdDtaaGFuZ3hpYW4gKFhpYW4pJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86emhhbmcueGlhbkBodWF3ZWkuY29tIj56aGFuZy54aWFuQGh1YXdlaS5jb208L2E+Jmd0Oywg UGF3ZcWCIEJyem96b3dza2kgJmx0OzxhIGhyZWY9Im1haWx0bzpQQnJ6b3pvd3NraUBhZHZhb3B0 aWNhbC5jb20iPlBCcnpvem93c2tpQGFkdmFvcHRpY2FsLmNvbTwvYT4mZ3Q7LCBBbnVyYWcgU2hh cm1hICZsdDs8YSBocmVmPSJtYWlsdG86QW5TaGFybWFAaW5maW5lcmEuY29tIj5BblNoYXJtYUBp bmZpbmVyYS5jb208L2E+Jmd0OywNCiBYdWZlbmcgTGl1ICZsdDs8YSBocmVmPSJtYWlsdG86eGxp dUBrdWF0cm90ZWNoLmNvbSI+eGxpdUBrdWF0cm90ZWNoLmNvbTwvYT4mZ3Q7LCBQYXdlxYIgS2Fj em1hcmVrICZsdDs8YSBocmVmPSJtYWlsdG86UEthY3ptYXJla0BhZHZhb3B0aWNhbC5jb20iPlBL YWN6bWFyZWtAYWR2YW9wdGljYWwuY29tPC9hPiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5Ok1pbmdMaVU7Y29sb3I6YmxhY2siPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj5DYzogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZxdW90 OzxhIGhyZWY9Im1haWx0bzp0ZWFzQGlldGYub3JnIj50ZWFzQGlldGYub3JnPC9hPiZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOnRlYXNAaWV0Zi5vcmciPnRlYXNAaWV0Zi5vcmc8L2E+Jmd0Oywg JnF1b3Q7bXBsc0BpZXRmJnF1b3Q7ICZsdDttcGxzQGlldGYmZ3Q7PGJyPg0KPGI+U3ViamVjdDog PC9iPlJlOiBNUExTIGFuZCBURSB0dW5uZWxzIFlBTkcgZGF0YSBtb2RlbCBtZWV0aW5nPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Db3B5aW5nIFdHIGZvciBmeWkgYXMg ZmVlZGJhY2sgYXMgcGVyIGFncmVlbWVudC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+VGhhbmtzIGFsbCBmb3IgYXR0ZW5kaW5nIG1lZXRpbmcgd2Vla2x5IG1lZXRpbmcg dG9kYXkuIEJlbG93IGFyZSB0b2RheeKAmXMgTW9Ncy4gRmVlbCBmcmVlIHRvIGFkZCBpZiBJIG1p c3NlZCBhbnkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlJlZ2FyZHMs PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5UYXJlazwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5GcmlkYXkgTWF5IDI3LCAyMDE2Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PT09PT09PT09PT09PT09 PT09PTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+QWdlbmRhOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QS4gRGlzY3VzcyBu ZXcgdXBkYXRlKHMpIHRvIE1QTFMgc3RhdGljIExTUHMgbW9kdWxlPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4m bmJzcDsmbmJzcDsgLSBuZXcgc3RhdGljIExTUCBhdHRyaWJ1dGVzPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4m bmJzcDsmbmJzcDsgLSBzdGF0aWMgYmlkaXJlY3Rpb25hbCBMU1BzPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4m bmJzcDsmbmJzcDsgLSBzdGF0aWMgTUJCPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsgLSBz dGF0aWMgZW5kLXRvLWVuZCBMU1AgcHJvdGVjdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Qi4gRGlzY3Vz cyBTUi1URSBuZXcgbW9kdWxlIGRldGFpbHM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkMuIGhvdyB0byBwcm9j ZWVkIHdpdGggc2NoZW1hIG1vdW50PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPi0tJmd0OyBBSTogdG8gc2VuZCBhIGRvb2RsZSBmb3IgU1ItVEUgbWVldGluZzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BLiBTUi1URTo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi Pj09PT09PT09PTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RXhwbGljaXQgcGF0aDo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi Pi0gbGFiZWwgKGFscmVhZHkgaGF2ZSBpdCBpbiBURSBtb2RlbCk8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi0g U0lEIGluZGV4PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlR1bm5lbDo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPm5ldzogYmluZGluZy1sYWJlbCAobm90IHNwZWNpZmljIHRvIFNSIHR1 bm5lbCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPm5ldzogcGVyIHBhdGggJnF1b3Q7c2VnbWVudC1yb3V0aW5n JnF1b3Q7IGF0dHJpYnV0ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+bmV3OiBwZXIgcGF0aCBjb25zdHJhaW50 czo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIGNvc3Qg bGltaXQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIGxp bmsvYWRqLVNJRCBwcm90ZWN0aW9uIHR5cGVzOiBhbnksIHByb3RlY3RlZCwgdW5wcm90ZWN0ZWQ8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIGludmFsaWRh dGlvbiB0aW1lb3V0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgLSBpbnZhbGlkYXRpb24gYWN0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBkcm9wPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSB0ZWFyPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4mbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LSBwcmVwZW5kIGxhYmVsKHMpIHBlciBw YXRoPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBwcmVw ZW5kIGJncC1uZXh0LWhvcDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPk5ldyBURSBsaW5rIGF0dHJpYnV0ZXMgKHN0YXRlLW9ubHkp Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RGVsYXk6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igJMgVW5pZGlyZWN0aW9u YWwgTGluayBEZWxheSAoRCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuKAkyBNaW4vTWF4IFVuaWRpcmVjdGlv bmFsIExpbmsgRGVsYXkgKERNKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+4oCTIFVuaWRpcmVjdGlvbmFsIERl bGF5IFZhcmlhdGlvbiAoRFYpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi Pkxvc3M6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igJMgVW5pZGlyZWN0aW9uYWwgTGluayBMb3NzIChMKTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5CYW5kd2lkdGg6PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij7igJMgVW5pZGlyZWN0aW9uYWwgUmVzaWR1YWwgQmFuZHdpZHRoIChCUik8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPuKAkyBVbmlkaXJlY3Rpb25hbCBBdmFpbGFibGUgQmFuZHdpZHRoIChCQSk8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPuKAkyBVbmlkaXJlY3Rpb25hbCBVdGlsaXplZCBCYW5kd2lkdGggKEJVVElM KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItYm90dG9tOmRvdWJs ZSB3aW5kb3d0ZXh0IDIuMjVwdDtwYWRkaW5nOjBpbiAwaW4gMS4wcHQgMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Qi4gVXBkYXRlIHRvIE1Q TFMgc3RhdGljIExTUHM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TmV3IGF0dHJpYnV0ZXMgZm9y IHN0YXRpYyBMU1BzIG5lZWRlZCB0byBhbGxvY2F0ZSByZXNvdXJjZXMgb24gcGVyIGhvcC9saW5r Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+LSBCVyB3aXRoIENUcz88L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi0gcHJpb3Jp dHkvcHJlZW1wdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+LSBkaXNjdXNzaW9uLCB3aGF0IG9jY3VycyBp ZiBzdGF0aWMgTFNQcyBpcyBjb250ZW5kaW5nIHdpdGggUlNWUCBhbGxvY2F0aW9uIChhdCBzYW1l IG9yIGRpZmZlcmVudCBwcmlvcml0eSk/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkJpZGlyZWN0aW9uYWwgU3RhdGljIExTUHM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PcHRpb24g IzE6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzIiPjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08 c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu Pjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+YXNz b2NpYXRpb24gb2YgZm9yd2FyZC9yZXZlcnNlIHNpYmxpbmdzIG1haW50YWluZWQgaW4gaGllcmFy Y2hpY2FsIGNvbmZpZ3VyYXRpb24gKHVuZGVyIHNhbWUgTFNQKG5hbWU9Zm9vKSk8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkxTUChuYW1lPWZvbyk6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5CVzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ YmlkaXJlY3Rpb25hbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Zm9yd2FyZDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5i c3A7Jm5ic3A7IEJXMTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7IGluLXNlZ21lbnQgKGlu LWxhYmVsLCBuZXh0LWhvcCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyBvdXQtc2VnbWVu dCAob3V0LWxhYmVsKHMpLCBuZXh0LWhvcCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnJldmVyc2U8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiZuYnNwOyZuYnNwOyBCVzI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyBp bi1zZWdtZW50IChpbi1sYWJlbCwgbmV4dC1ob3ApPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJz cDsgb3V0LXNlZ21lbnQgKG91dC1sYWJlbChzKSwgbmV4dC1ob3ApPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPi0tJmd0OyBJbiBjdXJyZW50IG1vZGVsIHRoZSBMU1AgaGFz IG9ubHkgb25lIGNyb3NzLWNvbm5lY3Q8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi0tJmd0OyB3aWxsIG5lZWQg dG8gaGF2ZSBtdWx0aXBsZSBjcm9zcy1jb25uZWN0cyBwZXIgTFNQPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4t PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5n cyI+w6A8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gdG8gcmVhbGl6ZSBhc3lt bWV0cmljYWwgYmVoYXZpb3IgKGVnLg0KIEJXIGFsbG9jKSBuZWVkIHRvIGFsbG93IGNvbmZpZyB1 bmRlciBlYWNoIGZvcndhcmQvcmV2ZXJzZSBsZWc8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+T3B0aW9uICMyOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjAuMjVwdDt0ZXh0LWluZGVudDot LjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzQiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250 OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5mb3J3YXJkL3JldmVyc2UgTFNQ cyBhcyBzZXBhcmF0ZSBlbnRyaWVzIGluIHRoZSBzdGF0aWMgTFNQIGxpc3Q8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjIwLjI1cHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm80Ij4NCjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+ZW50cmllcyBoYXZlDQo8Yj48dT5kaWZmZXJlbnQ8L3U+PC9iPiBuYW1lcywgYnV0IGFzc29j aWF0ZWQgdXNpbmcgYmVsb3c8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIwLjI1cHQ7dGV4dC1pbmRlbnQ6LS4yNWlu O21zby1saXN0OmwxIGxldmVsMSBsZm80Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+dXNlIGEgY29uZmlndXJlZCBhc3NvY2lh dGlvbi1JRCAodHVubmVsLUlEIG9yIHNlcnZpY2UtSUQpIGFzIHdheSB0byBhc3NvY2lhdGUgTFNQ czwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+TFNQKG5hbWU9Zm9vLWZvcndhcmQpOjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ YmlkaXJlY3Rpb25hbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Zm9yd2FyZDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+YXNz b2NpYXRpb24gSUQgPSAxMDAxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5pbi1zZWdtZW50IChpbi1sYWJlbCwg bmV4dC1ob3ApPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5vdXQtc2VnbWVudCAob3V0LWxhYmVsKHMpLCBuZXh0 LWhvcCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TFNQKG5hbWU9Zm9v LXJldmVyc2UpOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+YmlkaXJlY3Rpb25hbDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ cmV2ZXJzZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+YXNzb2NpYXRpb24gSUQgPSAxMDAxPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5pbi1zZWdtZW50IChpbi1sYWJlbCwgbmV4dC1ob3ApPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5vdXQt c2VnbWVudCAob3V0LWxhYmVsKHMpLCBuZXh0LWhvcCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+T3B0aW9uICMzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjAuMjVwdDt0ZXh0LWluZGVu dDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzQiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5mb3J3YXJkL3JldmVyc2Ug TFNQcyBhcyBzZXBhcmF0ZSBlbnRyaWVzIGluIHRoZSBzdGF0aWMgTFNQIGxpc3Q8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjIwLjI1cHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm80Ij4N CjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ Z25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+Ym90aCBlbnRyaWVzIGhhdmUgdGhlDQo8Yj48dT5zYW1lPC91PjwvYj4gbmFtZSwgYnV0 IG5ldyBrZXkgaXMgbmVlZGVkIGlpbiB0aGUgbGlzdCAocm9sZT8sIGUuZy4gc2libGluZzEsIHNp YmxpbmcyLCBldGMuLikNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItYm90dG9tOmRvdWJsZSB3aW5kb3d0ZXh0IDIuMjVwdDtwYWRkaW5nOjBpbiAwaW4gMS4wcHQg MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ TUJCIGZvciBTdGF0aWM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48dT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjEuIGhvdyB0byBy ZWFsaXplIHJlc291cmNlIHNoYXJpbmcgaWYgbmVlZGVkPzwvc3Bhbj48L3U+PC9iPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4yLiBjb29yZGluYXRlIHN3aXRjaG92ZXIgb24gdGhlIGluZ3Jlc3MgdXNpbmcgY29u ZmlndXJhdGlvbjwvc3Bhbj48L3U+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi Pk9wdGlvbiMyIChhZGQgcm9sZSBpbiBsaXN0IG9mIExTUHMga2V5KSwgZS5nLiBrZXk9IChuYW1l PWZvbywgcm9sZT1tYmItc2libGluZzEpLCAobmFtZT1mb28sIG1iYi1zaWJsaW5nMiksIChuYW1l PWZvbywgcGF0aC1wcm90ZWN0LXNpYmxpbmcxKSwgKG5hbWU9Zm9vLCBwYXRoLXByb3RlY3Qtc2li bGluZzIpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkxTUChmb28sIG1i Yi1zaWJsaW5nMSk6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5pbi1zZWdtZW50IChpbi1sYWJlbCwgbmV4dC1o b3ApPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5vdXQtc2VnbWVudCAob3V0LWxhYmVsKHMpLCBuZXh0LWhvcCk8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPmFzc29jaWF0aW9uIElEID0gMTAwMTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+cm9s ZT1NQkIgc2libGluZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5MU1Ao Zm9vLCBtYmItc2libGluZzIpOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+aW4tc2VnbWVudCAoaW4tbGFiZWws IG5leHQtaG9wKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+b3V0LXNlZ21lbnQgKG91dC1sYWJlbChzKSwgbmV4 dC1ob3ApPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5hc3NvY2lhdGlvbiBJRCA9IDEwMDE8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPnJvbGU9TUJCIHNpYmxpbmc8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+VDA6IHRyYWZmaWMgb24gTFNQKGZvbzEpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UMTogY29uZmlndXJl IExTUChmb28yKSBvbiBtaWQocyk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlQyOiBtYXAgdHJhZmZpYyB0byBM U1AoZm9vMikgb24gaW5ncmVzczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VDM6IGRlbGV0ZSBMU1AoZm9vMSk8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5CYWNrZ3JvdW5kIChzbmlwcGV0IGZyb20gSHVhd2Vp4oCZcyBPUyBzdXBwb3J0IGZvciBz dGF0aWMgTFNQKTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPltMU1JBXSBiaWRpcmVjdGlvbmFsIHN0YXRpYy1j ci1sc3AgaW5ncmVzcyBUdW5uZWwxLzAvMDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+W0xTUkEtYmktc3RhdGlj LWluZ3Jlc3MtVHVubmVsbC8wLzBdIGZvcndhcmQgbmV4dGhvcCAyLjEuMS4yIG91dC1sYWJlbCAy MCBiYW5kd2lkdGggY3QwIDEwMDAwPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5bTFNSQS1iaS1zdGF0aWMtaW5n cmVzcy1UdW5uZWxsLzAvMF0gYmFja3dhcmQgaW4tbGFiZWwgMjA8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPltM U1JCXWJpZGlyZWN0aW9uYWwgc3RhdGljLWNyLWxzcCB0cmFuc2l0IGxzcDE8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPltMU1JCLWJpLXN0YXRpYy10cmFuc2l0LWxzcDFdIGZvcndhcmQgaW4tbGFiZWwgMjAgbmV4 dGhvcCAzLjIuMS4yIG91dC1sYWJlbCA0MCBiYW5kd2lkdGggY3QwIDEwMDAwPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5bTFNSQi1iaS1zdGF0aWMtdHJhbnNpdC1sc3AxXSBiYWNrd2FyZCBpbi1sYWJlbCAxNiBu ZXh0aG9wIDIuMS4xLjEgb3V0LWxhYmVsIDIwIGJhbmR3aWR0aCBjdDAgMTAwMDA8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPltMU1JDXSBiaWRpcmVjdGlvbmFsIHN0YXRpYy1jci1sc3AgZWdyZXNzIGxzcDE8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPltMU1JDLWJpLXN0YXRpYy1lZ3Jlc3MtbHNwMV0gZm9yd2FyZCBpbi1sYWJl bCA0MCBsc3JpZCAxLjEuMS4xIHR1bm5lbC1pZCAxMDA8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRhcmVrPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJtYWlsdG86dHNhYWRAY2lzY28uY29t Ij50c2FhZEBjaXNjby5jb208L2E+PGJyPg0KPGI+V2hlbjogPC9iPjEwOjAwIEFNIC0gMTE6MDAg QU0gTWF5IDI3LCAyMDE2IDxicj4NCjxiPlN1YmplY3Q6IDwvYj5NUExTIGFuZCBURSB0dW5uZWxz IFlBTkcgZGF0YSBtb2RlbCBtZWV0aW5nPGJyPg0KPGI+TG9jYXRpb246IDwvYj53ZWJleDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPlJlZnJlc2hpbmcgaW52aXRlIGZvciBNUExTIGFuZCBURSB0 dW5uZWxzIFlBTkcgZGF0YSBtb2RlbCBtZWV0aW5nLiBQbGVhc2UgZm9yd2FyZCB0byBhbnlvbmUg SSBtaXNzZWQuPGJyPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YnI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ PGJyPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiM2NjY2NjYiPjxicj4NCjxicj4NCi08YSBuYW1lPSJNYWNCZWdpbldCWFRh ZyI+PC9hPi0gRG8gbm90IGRlbGV0ZSBvciBjaGFuZ2UgYW55IG9mIHRoZSBmb2xsb3dpbmcgdGV4 dC4gLS08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM2NjY2NjYiPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzY2 NjY2NiI+PGEgaHJlZj0iaHR0cHM6Ly9jaXNjby53ZWJleC5jb20vY2lzY29zYWxlcy9qLnBocD9N VElEPW1jMDU5ODJmMmQzYzQwNDJkZjIwYzJkZjU2ZjNjYzEyNyI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6IzAwQUZGOSI+Sm9pbiBXZWJFeCBtZWV0aW5nPC9zcGFuPjwvYT4N Cjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM2NjY2NjYiPk1l ZXRpbmcgbnVtYmVyOiAyMDEgOTY2IDY5Mjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEz LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiM2NjY2NjYiPg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzY2NjY2NiI+TWVldGluZyBwYXNzd29yZDo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojNjY2NjY2Ij4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiM2NjY2NjYiPjNqd01SWEVkPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzY2NjY2NiI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiM2NjY2NjYiPjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiM2NjY2NjYiPklmIHlvdSBhcmUgYSBob3N0LA0KPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojNjY2NjY2Ij48YSBocmVmPSJodHRwczovL2Npc2NvLndlYmV4 LmNvbS9jaXNjb3NhbGVzL2oucGhwP01USUQ9bWU3ZjY1NDYyZWIyNTFkMjA1YzhlMjE2NjhlNTE0 ZWU3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdv ZSBVSSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEFGRjkiPmdvDQogaGVy ZTwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzY2 NjY2NiI+IHRvIHZpZXcgaG9zdCBpbmZvcm1hdGlvbi48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiM2NjY2NjYiPjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj NjY2NjY2Ij5Kb2luIGJ5IHBob25lPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzY2NjY2NiI+DQo8YnI+DQo8L3NwYW4+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiM2NjY2NjYiPiYjNDM7MS00MDgtNTI1LTY4MDA8L3NwYW4+PC9zdHJvbmc+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNjY2NjY2Ij4gQ2FsbC1pbiB0b2xsIG51bWJl ciAoVVMvQ2FuYWRhKTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM2NjY2 NjYiPg0KPGJyPg0KPC9zcGFuPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojNjY2NjY2Ij4mIzQzOzEtODY2LTQzMi05OTAzPC9zcGFuPjwvc3Ryb25nPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzY2NjY2NiI+IENhbGwtaW4gdG9sbC1mcmVlIG51bWJlciAo VVMvQ2FuYWRhKTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM2NjY2NjYi Pg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzY2NjY2NiI+ QWNjZXNzIGNvZGU6IDIwMSA5NjYgNjkyPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzY2NjY2NiI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojNjY2NjY2Ij5OdW1lcmljIG1lZXRpbmcgcGFzc3dvcmQ6IDIxNzk0MTcyPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzY2NjY2NiI+DQo8YnI+DQo8YSBocmVmPSJo dHRwczovL2Npc2NvLndlYmV4LmNvbS9jaXNjb3NhbGVzL2dsb2JhbGNhbGxpbi5waHA/c2Vydmlj ZVR5cGU9TUMmYW1wO0VEPTM1MTQ5NzMzMiZhbXA7dG9sbEZyZWU9MSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjVwdDtjb2xvcjojMDBBRkY5Ij5HbG9iYWwgY2FsbC1pbiBudW1iZXJzPC9zcGFu PjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM2NjY2NjYiPg0KIHwg PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzY2NjY2NiI+PGEgaHJlZj0i aHR0cHM6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMucGRmIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2NvbG9yOiMwMEFGRjkiPlRvbGwtZnJlZSBjYWxsaW5n IHJlc3RyaWN0aW9uczwvc3Bhbj48L2E+DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiM2NjY2NjYiPjxicj4NCjxicj4NCkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/ IDxhIGhyZWY9Imh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Npc2Nvc2FsZXMvbWMiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMDBBRkY5Ij5Db250YWN0IHN1cHBvcnQuPC9zcGFuPjwvYT4NCjxicj4NCjxi cj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0EwQTBBMCI+SU1QT1JU QU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1 ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSBy ZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4NCiBC eSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNo IHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlz Y3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Np b24uLjwvc3Bhbj48YSBuYW1lPSJNYWNFbmRXQlhUYWciPjwvYT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzY2NjY2NiI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj48YnI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_c4bf27174a104d96bbfe99d6878b2cebsvex13prd1infineracom_-- From nobody Sat May 28 00:54:06 2016 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 5436A12D5A8; Sat, 28 May 2016 00:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 X-pIRt4lgthY; Sat, 28 May 2016 00:54:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1852612D5BD; Sat, 28 May 2016 00:53:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CKY55036; Sat, 28 May 2016 07:53:56 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 28 May 2016 08:53:33 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.196]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0235.001; Sat, 28 May 2016 15:53:29 +0800 From: "Yemin (Amy)" To: Daniele Ceccarelli , "CCAMP (ccamp@ietf.org)" , "TEAS WG (teas@ietf.org)" Thread-Topic: [Teas] Joint WG last call on draft-ietf-ospf-availability-extension-04 Thread-Index: AdGsJ0Ek7gP9RQQrQ6a+ZIh0V1wFmAL2G1WAACD7MBA= Date: Sat, 28 May 2016 07:53:28 +0000 Message-ID: <9C5FD3EFA72E1740A3D41BADDE0B461F9CDB675F@szxema506-mbs.china.huawei.com> References: <4A1562797D64E44993C5CBF38CF1BE48162CC275@ESESSMB301.ericsson.se> <4A1562797D64E44993C5CBF38CF1BE48162F21C8@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48162F21C8@ESESSMB301.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.169.31.176] Content-Type: multipart/alternative; boundary="_000_9C5FD3EFA72E1740A3D41BADDE0B461F9CDB675Fszxema506mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.57494E95.004D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.196, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d487771aa758f37b2ba819982c01f57c Archived-At: Cc: "teas-chairs@ietf.org" , "ccamp-chairs@ietf.org" Subject: Re: [Teas] Joint WG last call on draft-ietf-ospf-availability-extension-04 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 28 May 2016 07:54:03 -0000 --_000_9C5FD3EFA72E1740A3D41BADDE0B461F9CDB675Fszxema506mbschi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Daniele, Thanks for comments. I agree with most of them. Please see my response to some comments inline. BR, Amy ________________________________ This e-mail and its attachments contain confidential information from HUAWE= I, which is intended only for the person or entity whose address is listed above. An= y use of the information contained herein in any way (including, but not limited to, tot= al or partial disclosure, reproduction, or dissemination) by persons other than the inten= ded recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by phone or email immediately and delete it! From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Daniele Ceccarelli Sent: Saturday, May 28, 2016 5:08 AM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); TEAS WG (teas@ietf.org) Cc: ccamp-chairs@ietf.org; teas-chairs@ietf.org Subject: Re: [Teas] Joint WG last call on draft-ietf-ospf-availability-exte= nsion-04 Authors, I did my review of the document. Please find below some comments: - Section 1: please put [G.827, F.1703, P.530] in a reference form= at [G.827] [F.1703][P.530]. - Section 1: Could you elaborate this sentence? "The availability = is a time scale that the requested bandwidth is ensured." The meaning is no= t fully clear to me. [Amy] How about this: "The availability is a time scale, wh= ich is a proportion of the operating time that the requested bandwidth is e= nsured." - Section 1: [ASTE] curious acronym choice! Is it correct to have = this as a normative reference? [Amy] The title of the referenced draft was changed for onc= e. I will update the acronym according to the new title, how about [ETPAI]? - Section 1: [RFC4202]: I would say that this is a normative refer= ence, it is reported as informative. - Section 1: " If there is a hop that cannot support the Availab= ility sub-TLV, the Availability sub-TLV should be ignored." This is normati= ve text. It should be written in capital letters and I'd suggest to move it= from the intro to section 3. Going on with the reading I see that it is pr= operly state in section 3.2, hence I suggest just dropping the sentence in = section 1. - Section 1: "...is defined to support in routing signaling." Ther= e must be something missing here. What about just "...is defined."? - Section 2: s/should contain/should include - Section 2: I suggest rephrasing this sentence: " The list provid= es the information that how much bandwidth a link can support for a specifi= ed availability." What about "The list provides the mapping between the lin= k nominal bandwidth and its availability level"? - Section 2: s/label switched path/Label Switched Path - Section 2: suggested rephrasing OLD To setup a label switching path (LSP), a node may collect link information which is spread in OSPF TE LSA messages by network nodes to get know about the network topology, calculate out an LSP route based on the network topology and send the calculated LSP route to signaling to initiate a PATH/RESV message for setting up the LSP. Availability information is required to carry in the signaling message to better utilize the link bandwidth. The signaling extension for availability can be found in [ASTE]. NEW The setup of a Label Switched Path requires this piece of information to be= flooded in the network and used by the nodes or the PCE for the path compu= tation. The computed path can then be provisioned via the signaling protoco= l. Availability information also need to be carried by the signaling for a bet= ter utilization of the link bandwidth (CAN YOU EXPLAIN WHY?). Extensions to RSVP-TE can be found in [ASTE]. [Amy] How about the following text: The setup of a Label Switched Path requires this piece of information to be= flooded in the network and used by the nodes or the PCE for the path compu= tation. The computed path can then be provisioned via the signaling protoco= l. For links with variable discrete bandwidth, Availability information is nee= d to be carried by the signaling for a better link bandwidth utilization. Extensions to RSVP-TE can be found in [ETPAI]. - Section 3.1 - ISCD already expanded in section 1, you can use th= e acronym. - Section 3.1: "Type: TBA by IANA, suggested value is 0x01" - Section 3.1: "Length" you should state the units (bit? Bytes?). = Moreover I see this is a fixed length TLV, hence I would say: "Length: A 16= bits field that expresses the length of the TLV in bytes" - Section 3.1: "Availability level": is there a discrete set of av= ailability levels? E.g. 0.99, 0.999, 0.9999, or it can be filled with any n= umber between O and 1? This needs to be explained a bit better. [Amy] There's no concrete discrete set of availability levels. 0.99, 0.999= , 0.9999 is the most common usage, 0.995 may also be used. However numbers = such as 0.996/0.997 are rarely used. I can add one sentence to explain more: "The Availability level is usually = expressed in the value of 0.99/0.999/0.9999/0.99999 ". - LSP bandwidth at availability level: the unit is missing. - 3.2 Why signaling process? It would rather say "Processing Proce= dures" ? - Section 4: Please add a reference to the OSPF and GMPLS security= RFCs. - IANA section: Please make sure that it is state which registry n= eeds to be updated and how. - References: there is a number of references that is not used in = the document e.g. RFC 2210, RFC 3473 and so on. - Header: "OSPF -- Availability extension" please remove the dashe= s. I also suggest to substitute with "Availability extensions to OSPF-TE". - Please also check the IdNits Thanks Daniele From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: gioved=EC 12 maggio 2016 10:25 To: CCAMP (ccamp@ietf.org) >; TEAS WG (teas@ietf.org) > Cc: teas-chairs@ietf.org; ccamp-chairs@ietf.or= g Subject: Joint WG last call on draft-ietf-ospf-availability-extension-04 CCAMP, TEAS, This starts a two weeks joint working group last call on draft-ietf-ccamp-o= spf-availability-extension-04 The last call end on Wednesday May 26th. Please send your comments to both = the CCAMP and TEAS mailing lists. All the IPR declarations from authors and contributors have been collected = and can be found in the history of the document: https://datatracker.ietf.o= rg/doc/draft-ietf-ccamp-ospf-availability-extension/history/ Please note that no IPR was disclosed against this draft. As usual this is also a call for shepherd. If anyone is willing to be the s= hepherd of the document, please volunteer. Thanks Daniele, Fatai, Lou, Pavan --_000_9C5FD3EFA72E1740A3D41BADDE0B461F9CDB675Fszxema506mbschi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Daniele,

 

Thanks for comments. I agree with most of them.

Please see my response to some comments inline.

 

BR,

Amy

 

This e-mail and its attachments = contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. An= y use of the
information contained herein in any way (including, but not limited to, tot= al or partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by
phone or email immediately and delete it!

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Daniele Ceccarelli
Sent: Saturday, May 28, 2016 5:08 AM
To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); TEAS WG (teas@ietf.o= rg)
Cc: ccamp-chairs@ietf.org; teas-chairs@ietf.org
Subject: Re: [Teas] Joint WG last call on draft-ietf-ospf-availabili= ty-extension-04

 

Authors,

 

I did my review of the document= . Please find below some comments:

 

-     &= nbsp;    Section 1: please put [G.827, F.1703, P.530] in= a reference format [G.827] [F.1703][P.530].

-     &= nbsp;    Section 1: Could you elaborate this sentence? &= #8220;The availability is a time scale that the requested bandwidth is ensu= red.” The meaning is not fully clear to me.

     &n= bsp;          [Amy] How about = this: “The availability is a time scale, which is a proportion of the= operating time that the requested bandwidth is ensured.”

 

-     &= nbsp;    Section 1: [ASTE] curious acronym choice! Is it= correct to have this as a normative reference?=

     &n= bsp;          [Amy] The title = of the referenced draft was changed for once. I will update the acronym acc= ording to the new title, how about [ETPAI]?

 

-     &= nbsp;    Section 1: [RFC4202]: I would say that this is = a normative reference, it is reported as informative.

-     &= nbsp;    Section 1: “   If there is a ho= p that cannot support the Availability sub-TLV, the Availability sub-TLV sh= ould be ignored.” This is normative text. It should be written in cap= ital letters and I’d suggest to move it from the intro to section 3. Going on with the reading I see that it is properly state in se= ction 3.2, hence I suggest just dropping the sentence in section 1.<= span lang=3D"EN-US">

-     &= nbsp;    Section 1: “…is defined to support = in routing signaling.” There must be something missing here. What abo= ut just “…is defined.”?<= /o:p>

-     &= nbsp;    Section 2: s/should contain/should include

-     &= nbsp;    Section 2: I suggest rephrasing this sentence: = “ The list provides the information that how much bandwidth a link ca= n support for a specified availability.” What about “The list p= rovides the mapping between the link nominal bandwidth and its availability level”?

-     &= nbsp;    Section 2: s/label switched path/Label Switched= Path

-     &= nbsp;    Section 2: suggested rephrasing

OLD

  To setup a label sw= itching path (LSP), a node may collect link

   information which = is spread in OSPF TE LSA messages by network nodes

   to get know about = the network topology, calculate out an LSP route

   based on the netwo= rk topology and send the calculated LSP route to

   signaling to initi= ate a PATH/RESV message for setting up the LSP.

   Availability i=
nformation is required to carry in the signaling
   message to bet=
ter utilize the link bandwidth. The signaling
   extension for =
availability can be found in [ASTE].

 

NEW

The setup of a Label Switched P= ath requires this piece of information to be flooded in the network and use= d by the nodes or the PCE for the path computation. The computed path can then be provisioned via the signaling protocol.=

Availability information also n= eed to be carried by the signaling for a better utilization of the link ban= dwidth (CAN YOU EXPLAIN WHY?).

Extensions to RSVP-TE can be fo= und in [ASTE].

[Amy] How about the following text:

The setup of a Label Switched Path requires this piece of informa= tion to be flooded in the network and used by the nodes or the PCE for the = path computation. The computed path can then be provisioned via the signaling protocol.

For links with variable discrete bandwidth, Availability informat= ion is need to be carried by the signaling for a better link bandwidth util= ization.

Extensions to RSVP-TE can be found in [ETPAI].<= /p>

 

-     &= nbsp;    Section 3.1 – ISCD already expanded in se= ction 1, you can use the acronym.

-     &= nbsp;    Section 3.1: “Type: TBA by IANA, suggeste= d value is 0x01”

-     &= nbsp;    Section 3.1: “Length” you should st= ate the units (bit? Bytes?). Moreover I see this is a fixed length TLV, hen= ce I would say: “Length: A 16 bits field that expresses the length of= the TLV in bytes”

-     &= nbsp;    Section 3.1: “Availability level”: = is there a discrete set of availability levels? E.g. 0.99, 0.999, 0.9999, o= r it can be filled with any number between O and 1? This needs to be explai= ned a bit better.

[Amy] There&= #8217;s no concrete discrete set of  availability levels. 0.99, 0.999,= 0.9999 is the most common usage, 0.995 may also be used. However numbers such as 0.996/0.997 are rarely used.

I can add on= e sentence to explain more: “The Availability level is usually expres= sed in the value of  0.99/0.999/0.9999/0.99999 ”.

 

-     &= nbsp;    LSP bandwidth at availability level: the unit i= s missing.

-     &= nbsp;    3.2 Why signaling process? It would rather say = “Processing Procedures” ?

-     &= nbsp;    Section 4: Please add a reference to the OSPF a= nd GMPLS security RFCs.

-     &= nbsp;    IANA section: Please make sure that it is state= which registry needs to be updated and how.

-     &= nbsp;    References: there is a number of references tha= t is not used in the document e.g. RFC 2210, RFC 3473 and so on.=

-     &= nbsp;    Header: “OSPF -- Availability extension&#= 8221; please remove the dashes. I also suggest to substitute with “Av= ailability extensions to OSPF-TE”.

-     &= nbsp;    Please also check the IdNits<= /p>

 

 

Thanks

Daniele

 

 

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: gioved=EC 12 maggio 2016 10:25
To: CCAMP (ccamp@ietf.org) <= ;ccamp@ietf.org>; TEAS WG (teas@ietf.org) <teas@ietf.org>
Cc: teas-chairs@ietf.org= ; ccamp-chairs@ietf.org
Subject: Joint WG last call on draft-ietf-ospf-availability-extensio= n-04

 

CCAMP, TEAS,<= /p>

 

This starts a two weeks joint w= orking group last call on draft-ietf-ccamp-ospf-availability-extension-04

The last call end on Wednesday = May 26th. Please send your comments to both the CCAMP and TEAS m= ailing lists.

 

All the IPR declarations from a= uthors and contributors have been collected and can be found in the history= of the document: https://datatracker.ietf.org/doc/draft-ietf-ccamp-ospf-availability-extensi= on/history/

Please note that no IPR was dis= closed against this draft.

 

As usual this is also a call fo= r shepherd. If anyone is willing to be the shepherd of the document, please= volunteer.

 =

Thanks=

Daniele, Fatai, Lou, Pav= an

 

--_000_9C5FD3EFA72E1740A3D41BADDE0B461F9CDB675Fszxema506mbschi_-- From nobody Sat May 28 06:10:34 2016 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 2962E12D0FC; Sat, 28 May 2016 06:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 pY_5hnRBNpbk; Sat, 28 May 2016 06:10:25 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCCD412B076; Sat, 28 May 2016 06:10:23 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-67-574998bd400f Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id EB.B2.12926.DB899475; Sat, 28 May 2016 15:10:21 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.74]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0294.000; Sat, 28 May 2016 15:09:44 +0200 From: Daniele Ceccarelli To: "Yemin (Amy)" , "CCAMP (ccamp@ietf.org)" , "TEAS WG (teas@ietf.org)" Thread-Topic: [Teas] Joint WG last call on draft-ietf-ospf-availability-extension-04 Thread-Index: AQHRuLYZPKK5sm0sB0OjhpAurrNFM5/OUNzg Date: Sat, 28 May 2016 13:09:44 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE48162F34FA@ESESSMB301.ericsson.se> References: <4A1562797D64E44993C5CBF38CF1BE48162CC275@ESESSMB301.ericsson.se> <4A1562797D64E44993C5CBF38CF1BE48162F21C8@ESESSMB301.ericsson.se> <9C5FD3EFA72E1740A3D41BADDE0B461F9CDB675F@szxema506-mbs.china.huawei.com> In-Reply-To: <9C5FD3EFA72E1740A3D41BADDE0B461F9CDB675F@szxema506-mbs.china.huawei.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE48162F34FAESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsUyM2K7uu7eGZ7hBjN7jCw2d2xgs1i6YxOT xZM5N1gsmubuYrJo/bGDxYHVo+XIW1aPJUt+MgUwRXHZpKTmZJalFunbJXBl7H1/jK2g4whT xf73P9kbGOfPZ+pi5OSQEDCRePv7FwuELSZx4d56ti5GLg4hgSOMEo9uzWCGcBYzSpzdfh0o w8HBJmAl8eSQD0hcRKCBUWLGgwZWkDizQIrE3afaIIOEBUIlvv/sYAEJiwiESeyb6wgSFhEw klhw8QTYXhYBVYk3vQ9ZQWxeAV+JBSd3Qq26yyixaOUXdpAEJ1Dv+c5OsAZGAVmJCbsXMYLY zALiEreewDwgILFkz3lmCFtU4uXjf6wQtpJE45InrBD1+RJLn99hh1gmKHFy5hOWCYyis5CM moWkbBaSMoi4nsSNqVPYIGxtiWULXzND2LoSM/4dYkEWX8DIvopRtDi1OCk33chYL7UoM7m4 OD9PLy+1ZBMjMCIPbvmtuoPx8hvHQ4wCHIxKPLwJhz3ChVgTy4orcw8xSnAwK4nwXprkGS7E m5JYWZValB9fVJqTWnyIUZqDRUmc1/+lYriQQHpiSWp2ampBahFMlomDU6qB0fko866svRP+ q7yP3qHLzPXe4PvEhTkz1iqnmFusrFk8j7vIPv5OrcRaM6Pzh0RL+371n1nW8P+hK7uEwC/9 WRKXmeLMX1wW0PjqPTvyZsLM/ioBJ8WXNhIfDmW98i3ZcIl15l3+H6udvGuU3xVYHvGeaJXR u9pZfV7t4jyBGQvEK+PP9sraKLEUZyQaajEXFScCAA3vAh/EAgAA Archived-At: Cc: "teas-chairs@ietf.org" , "ccamp-chairs@ietf.org" Subject: Re: [Teas] Joint WG last call on draft-ietf-ospf-availability-extension-04 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 28 May 2016 13:10:29 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE48162F34FAESESSMB301erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Amy, Please see my further replies in line. When you're done with the changes please update the draft and we can procee= d with the request for publication. Thanks Daniele From: Yemin (Amy) [mailto:amy.yemin@huawei.com] Sent: sabato 28 maggio 2016 09:53 To: Daniele Ceccarelli ; CCAMP (ccamp@ietf= .org) ; TEAS WG (teas@ietf.org) Cc: ccamp-chairs@ietf.org; teas-chairs@ietf.org Subject: RE: [Teas] Joint WG last call on draft-ietf-ospf-availability-exte= nsion-04 Hi Daniele, Thanks for comments. I agree with most of them. Please see my response to some comments inline. BR, Amy ________________________________ This e-mail and its attachments contain confidential information from HUAWE= I, which is intended only for the person or entity whose address is listed above. An= y use of the information contained herein in any way (including, but not limited to, tot= al or partial disclosure, reproduction, or dissemination) by persons other than the inten= ded recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by phone or email immediately and delete it! From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Daniele Ceccarelli Sent: Saturday, May 28, 2016 5:08 AM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); TEAS= WG (teas@ietf.org) Cc: ccamp-chairs@ietf.org; teas-chairs@ietf.o= rg Subject: Re: [Teas] Joint WG last call on draft-ietf-ospf-availability-exte= nsion-04 Authors, I did my review of the document. Please find below some comments: - Section 1: please put [G.827, F.1703, P.530] in a reference form= at [G.827] [F.1703][P.530]. - Section 1: Could you elaborate this sentence? "The availability = is a time scale that the requested bandwidth is ensured." The meaning is no= t fully clear to me. [Amy] How about this: "The availability is a time scale, wh= ich is a proportion of the operating time that the requested bandwidth is e= nsured." [DC] sounds good - Section 1: [ASTE] curious acronym choice! Is it correct to have = this as a normative reference? [Amy] The title of the referenced draft was changed for onc= e. I will update the acronym according to the new title, how about [ETPAI]? [DC] I have nothing against one or the other, I was just curious to know ho= w you end up with that one. Feel free to use the one you prefer. - Section 1: [RFC4202]: I would say that this is a normative refer= ence, it is reported as informative. - Section 1: " If there is a hop that cannot support the Availab= ility sub-TLV, the Availability sub-TLV should be ignored." This is normati= ve text. It should be written in capital letters and I'd suggest to move it= from the intro to section 3. Going on with the reading I see that it is pr= operly state in section 3.2, hence I suggest just dropping the sentence in = section 1. - Section 1: "...is defined to support in routing signaling." Ther= e must be something missing here. What about just "...is defined."? - Section 2: s/should contain/should include - Section 2: I suggest rephrasing this sentence: " The list provid= es the information that how much bandwidth a link can support for a specifi= ed availability." What about "The list provides the mapping between the lin= k nominal bandwidth and its availability level"? - Section 2: s/label switched path/Label Switched Path - Section 2: suggested rephrasing OLD To setup a label switching path (LSP), a node may collect link information which is spread in OSPF TE LSA messages by network nodes to get know about the network topology, calculate out an LSP route based on the network topology and send the calculated LSP route to signaling to initiate a PATH/RESV message for setting up the LSP. Availability information is required to carry in the signaling message to better utilize the link bandwidth. The signaling extension for availability can be found in [ASTE]. NEW The setup of a Label Switched Path requires this piece of information to be= flooded in the network and used by the nodes or the PCE for the path compu= tation. The computed path can then be provisioned via the signaling protoco= l. Availability information also need to be carried by the signaling for a bet= ter utilization of the link bandwidth (CAN YOU EXPLAIN WHY?). Extensions to RSVP-TE can be found in [ASTE]. [Amy] How about the following text: The setup of a Label Switched Path requires this piece of information to be= flooded in the network and used by the nodes or the PCE for the path compu= tation. The computed path can then be provisioned via the signaling protoco= l. For links with variable discrete bandwidth, Availability information is nee= d to be carried by the signaling for a better link bandwidth utilization. Extensions to RSVP-TE can be found in [ETPAI]. [DC] correct amendment. - Section 3.1 - ISCD already expanded in section 1, you can use th= e acronym. - Section 3.1: "Type: TBA by IANA, suggested value is 0x01" - Section 3.1: "Length" you should state the units (bit? Bytes?). = Moreover I see this is a fixed length TLV, hence I would say: "Length: A 16= bits field that expresses the length of the TLV in bytes" - Section 3.1: "Availability level": is there a discrete set of av= ailability levels? E.g. 0.99, 0.999, 0.9999, or it can be filled with any n= umber between O and 1? This needs to be explained a bit better. [Amy] There's no concrete discrete set of availability levels. 0.99, 0.999= , 0.9999 is the most common usage, 0.995 may also be used. However numbers = such as 0.996/0.997 are rarely used. I can add one sentence to explain more: "The Availability level is usually = expressed in the value of 0.99/0.999/0.9999/0.99999 ". [DC] That's fine. - LSP bandwidth at availability level: the unit is missing. - 3.2 Why signaling process? It would rather say "Processing Proce= dures" ? - Section 4: Please add a reference to the OSPF and GMPLS security= RFCs. - IANA section: Please make sure that it is state which registry n= eeds to be updated and how. - References: there is a number of references that is not used in = the document e.g. RFC 2210, RFC 3473 and so on. - Header: "OSPF -- Availability extension" please remove the dashe= s. I also suggest to substitute with "Availability extensions to OSPF-TE". - Please also check the IdNits Thanks Daniele From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: gioved=EC 12 maggio 2016 10:25 To: CCAMP (ccamp@ietf.org) >; TEAS WG (teas@ietf.org) > Cc: teas-chairs@ietf.org; ccamp-chairs@ietf.or= g Subject: Joint WG last call on draft-ietf-ospf-availability-extension-04 CCAMP, TEAS, This starts a two weeks joint working group last call on draft-ietf-ccamp-o= spf-availability-extension-04 The last call end on Wednesday May 26th. Please send your comments to both = the CCAMP and TEAS mailing lists. All the IPR declarations from authors and contributors have been collected = and can be found in the history of the document: https://datatracker.ietf.o= rg/doc/draft-ietf-ccamp-ospf-availability-extension/history/ Please note that no IPR was disclosed against this draft. As usual this is also a call for shepherd. If anyone is willing to be the s= hepherd of the document, please volunteer. Thanks Daniele, Fatai, Lou, Pavan --_000_4A1562797D64E44993C5CBF38CF1BE48162F34FAESESSMB301erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Amy,

 

Please see my further replies in line.
When you’re done with the changes please update the draft and we can = proceed with the request for publication.

 

Thanks

Daniele 

 

From: Yemin (Amy) [mailto:amy.yemin@huawei.com]
Sent: sabato 28 maggio 2016 09:53
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAM= P (ccamp@ietf.org) <ccamp@ietf.org>; TEAS WG (teas@ietf.org) <teas= @ietf.org>
Cc: ccamp-chairs@ietf.org; teas-chairs@ietf.org
Subject: RE: [Teas] Joint WG last call on draft-ietf-ospf-availabili= ty-extension-04

 

Hi Daniele,

 

Thanks for comments. I agree with most= of them.

Please see my response to some comment= s inline.

 

BR,

Amy

 

This e-mail and its attachments contain confid= ential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. An= y use of the
information contained herein in any way (including, but not limited to, tot= al or partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by
phone or email immediately and delete it!<= /span>

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Daniele Ceccarelli
Sent: Saturday, May 28, 2016 5:08 AM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); TEAS WG (teas@ietf.org)
Cc: ccamp-chairs@ietf.org; teas-chairs@ietf.org
Subject: Re: [Teas] Joint WG last call on draft-ietf-ospf-availabili= ty-extension-04

 

Authors,

 

I did my review of the document. Please find below some comments:

 

-          Section 1:= please put [G.827, F.1703, P.530] in a reference format [G.827] [F.1703][P= .530].

-          Section 1:= Could you elaborate this sentence? “The availability is a time scale= that the requested bandwidth is ensured.” The meaning is not fully c= lear to me.

 = ;            &n= bsp;  [Amy] How about this: “The availability is a time scale, w= hich is a proportion of the operating time that the requested bandwidth is ensured.”

[DC] sounds good

-          Section 1:= [ASTE] curious acronym choice! Is it correct to have this as a normative r= eference?

 = ;            &n= bsp;  [Amy] The title of the referenced draft was changed for once. I = will update the acronym according to the new title, how about [ETPAI]?

[DC] I have nothing= against one or the other, I was just curious to know how you end up with t= hat one. Feel free to use the one you prefer.

 

-          Section 1:= [RFC4202]: I would say that this is a normative reference, it is reported = as informative.

-          Section 1:= “   If there is a hop that cannot support the Availability= sub-TLV, the Availability sub-TLV should be ignored.” This is normat= ive text. It should be written in capital letters and I’d suggest to move it from the intro to section 3. Going on with the reading = I see that it is properly state in section 3.2, hence I suggest just droppi= ng the sentence in section 1.

-          Section 1:= “…is defined to support in routing signaling.” There mus= t be something missing here. What about just “…is defined.̶= 1;?

-          Section 2:= s/should contain/should include

-          Section 2:= I suggest rephrasing this sentence: “ The list provides the informat= ion that how much bandwidth a link can support for a specified availability= .” What about “The list provides the mapping between the link nominal bandwidth and its availability level”?

-          Section 2:= s/label switched path/Label Switched Path

-          Section 2:= suggested rephrasing

OLD

&nbs= p; To setup a label switching path (LSP), a node may collect link=

&nbs= p;  information which is spread in OSPF TE LSA messages by network nod= es

&nbs= p;  to get know about the network topology, calculate out an LSP route=

&nbs= p;  based on the network topology and send the calculated LSP route to=

&nbs= p;  signaling to initiate a PATH/RESV message for setting up the LSP.<= o:p>

   Availabil=
ity information is required to carry in the signaling

   message t=
o better utilize the link bandwidth. The signaling


   extension=
 for availability can be found in [=
ASTE].

 


NEW


The =
setup of a Label Switched Path requires this piece of information to be flo=
oded in the network and used by the nodes or the
 PCE for the path computation. The computed path can then be provisioned vi=
a the signaling protocol.


Avai=
lability information also need to be carried by the signaling for a better =
utilization of the link bandwidth (CAN YOU EXPLAIN
 WHY?).


Exte=
nsions to RSVP-TE can be found in [ASTE].


[Amy] How about the following text:


The setup of a Label Switched Path req=
uires this piece of information to be flooded in the network and used by th=
e nodes or the PCE for the path computation.
 The computed path can then be provisioned via the signaling protocol.=



For links with variable discrete bandw=
idth, Availability information is need to be carried by the signaling for a=
 better link bandwidth utilization.


Extensions to RSVP-TE can be found in =
[ETPAI].


[DC] correct amendment.


 


-         
Section 3.=
1 – ISCD already expanded in section 1, you can use the acronym.



-         
Section 3.=
1: “Type: TBA by IANA, suggested value is 0x01”


-         
Section 3.=
1: “Length” you should state the units (bit? Bytes?). Moreover =
I see this is a fixed length TLV, hence I would say: “Length: A 16 bi=
ts field that expresses the length of the TLV in bytes”


-         
Section 3.=
1: “Availability level”: is there a discrete set of availabilit=
y levels? E.g. 0.99, 0.999, 0.9999, or it can be filled with any number bet=
ween O and 1? This needs to be explained a bit better.

[Amy] There’s no concrete discrete set of  availa=
bility levels. 0.99, 0.999, 0.9999 is the most common
 usage, 0.995 may also be used. However numbers such as 0.996/0.997 are rar=
ely used.



I can add one sentence to explain more: “The Availabil=
ity level is usually expressed in the value of
  0.99/0.999/0.9999/0.99999 ”.


[DC] That’=
s fine.



 


-         
LSP bandwi=
dth at availability level: the unit is missing.


-         
3.2 Why si=
gnaling process? It would rather say “Processing Procedures” ?<=
o:p>


-         
Section 4:=
 Please add a reference to the OSPF and GMPLS security RFCs.


-         
IANA secti=
on: Please make sure that it is state which registry needs to be updated an=
d how.


-         
References=
: there is a number of references that is not used in the document e.g. RFC=
 2210, RFC 3473 and so on.


-         
Header: &#=
8220;OSPF -- Availability extension” please remove the dashes. I also=
 suggest to substitute with “Availability extensions to OSPF-TE”=
;.



-         
Please als=
o check the IdNits


 


 


Thanks


Daniele


 


 








From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]


Sent: gioved=EC 12 maggio 2016 10:25

To: CCAMP (ccamp@ietf.org) <=
;ccamp@ietf.org>; TEAS WG (teas@ietf.org) <teas@ietf.org>

Cc: teas-chairs@ietf.org=
; 
ccamp-chairs@ietf.org

Subject: Joint WG last call on draft-ietf-ospf-availability-extensio=
n-04






&nbs=
p;


CCAMP, TEAS,


 


This starts a two weeks joint working group last call on draft-ietf-c=
camp-ospf-availability-extension-04


The last call end on Wednesday May 26th. Please send your =
comments to both the CCAMP and TEAS mailing lists.


 


All the IPR declarations from authors and contributors have been coll=
ected and can be found in the history of the document:

https://datatracker.ietf.org/doc/draft-ietf-ccamp-ospf-availability-extensi=
on/history/



Please note that no IPR was disclosed against this draft.<=
/span>


 


As usual this is also a call for shepherd. If anyone is willing to be=
 the shepherd of the document, please volunteer.


 


Thanks


Daniele, Fatai, Lou, Pavan


 
--_000_4A1562797D64E44993C5CBF38CF1BE48162F34FAESESSMB301erics_-- From nobody Mon May 30 02:31:19 2016 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 7543912D1A8; Mon, 30 May 2016 02:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 RLVvReWkuqJj; Mon, 30 May 2016 02:31:14 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72A2712D13E; Mon, 30 May 2016 02:31:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CPV42733; Mon, 30 May 2016 09:31:09 +0000 (GMT) Received: from SZXEMA416-HUB.china.huawei.com (10.82.72.35) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 30 May 2016 10:31:08 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.196]) by SZXEMA416-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0235.001; Mon, 30 May 2016 17:30:40 +0800 From: "Yemin (Amy)" To: Daniele Ceccarelli , "Acee Lindem (acee)" , "CCAMP (ccamp@ietf.org)" , "TEAS WG (teas@ietf.org)" Thread-Topic: [Teas] Joint WG last call on draft-ietf-ospf-availability-extension-04 Thread-Index: AQHRrENg2RhFJF80w0iwtIkwVPiYfp+2IHuAgBsySEA= Date: Mon, 30 May 2016 09:30:39 +0000 Message-ID: <9C5FD3EFA72E1740A3D41BADDE0B461F9CDB6B09@szxema506-mbs.china.huawei.com> References: <4A1562797D64E44993C5CBF38CF1BE48162CC275@ESESSMB301.ericsson.se> <4A1562797D64E44993C5CBF38CF1BE48162CDFB4@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48162CDFB4@ESESSMB301.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.169.31.176] Content-Type: multipart/alternative; boundary="_000_9C5FD3EFA72E1740A3D41BADDE0B461F9CDB6B09szxema506mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.574C085E.0020, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.196, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2f3c3c071566a1cd3814857a42167201 Archived-At: Cc: "ccamp-chairs@ietf.org" , "teas-chairs@ietf.org" Subject: Re: [Teas] Joint WG last call on draft-ietf-ospf-availability-extension-04 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 30 May 2016 09:31:17 -0000 --_000_9C5FD3EFA72E1740A3D41BADDE0B461F9CDB6B09szxema506mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWNlZSBhbmQgRGFuaWVsZSwNCg0KSSBwbGFuIHRvIGNoYW5nZSB0aGUgdGl0bGUgdG8g4oCc T1NQRi1URSBFeHRlbnNpb24gZm9yIExpbmtzIHdpdGggVmFyaWFibGUgRGlzY3JldGUgQmFuZHdp ZHRo4oCdLCB3aGF0IGRvIHlvdSB0aGluaz8NCkkgd2lsbCBhbHNvIHVwZGF0ZSB0aGUgdGV4dCBp biB0aGUgZHJhZnQgYWNjb3JkaW5nbHkuDQoNCkJSLA0KQW15DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KVGhpcyBlLW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBjb250YWluIGNv bmZpZGVudGlhbCBpbmZvcm1hdGlvbiBmcm9tIEhVQVdFSSwgd2hpY2gNCmlzIGludGVuZGVkIG9u bHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFib3Zl LiBBbnkgdXNlIG9mIHRoZQ0KaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpbiBhbnkgd2F5 IChpbmNsdWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bywgdG90YWwgb3IgcGFydGlhbA0KZGlzY2xv c3VyZSwgcmVwcm9kdWN0aW9uLCBvciBkaXNzZW1pbmF0aW9uKSBieSBwZXJzb25zIG90aGVyIHRo YW4gdGhlIGludGVuZGVkDQpyZWNpcGllbnQocykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2Vp dmUgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieQ0KcGhv bmUgb3IgZW1haWwgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSBpdCENCg0KRnJvbTogVGVhcyBbbWFp bHRvOnRlYXMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhbmllbGUgQ2VjY2FyZWxs aQ0KU2VudDogRnJpZGF5LCBNYXkgMTMsIDIwMTYgNjoxMCBQTQ0KVG86IEFjZWUgTGluZGVtIChh Y2VlKTsgQ0NBTVAgKGNjYW1wQGlldGYub3JnKTsgVEVBUyBXRyAodGVhc0BpZXRmLm9yZykNCkNj OiB0ZWFzLWNoYWlyc0BpZXRmLm9yZzsgY2NhbXAtY2hhaXJzQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW1RlYXNdIEpvaW50IFdHIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLW9zcGYtYXZhaWxhYmls aXR5LWV4dGVuc2lvbi0wNA0KDQpHb29kIHBvaW50IEFjZWUuDQoNCkkgYWdyZWUgd2l0aCB5b3Ug SeKAmW0gZmluZSB3aXRoIHVwZGF0aW5nIHRoZSBJRCBhY2NvcmRpbmdseS4NCg0KVGhhbmtzDQpE YW5pZWxlDQoNCkZyb206IEFjZWUgTGluZGVtIChhY2VlKSBbbWFpbHRvOmFjZWVAY2lzY28uY29t XQ0KU2VudDogZ2lvdmVkw6wgMTIgbWFnZ2lvIDIwMTYgMTM6NDINClRvOiBEYW5pZWxlIENlY2Nh cmVsbGk7IENDQU1QIChjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+KTsgVEVB UyBXRyAodGVhc0BpZXRmLm9yZzxtYWlsdG86dGVhc0BpZXRmLm9yZz4pDQpDYzogY2NhbXAtY2hh aXJzQGlldGYub3JnPG1haWx0bzpjY2FtcC1jaGFpcnNAaWV0Zi5vcmc+OyB0ZWFzLWNoYWlyc0Bp ZXRmLm9yZzxtYWlsdG86dGVhcy1jaGFpcnNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1RlYXNd IEpvaW50IFdHIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLW9zcGYtYXZhaWxhYmlsaXR5LWV4dGVu c2lvbi0wNA0KDQpJIHJlYWxpemUgaXQgaGFzIGFsd2F5cyBiZWVuIHRoaXMgd2F5IGJ1dCB0aGUg dGVybWlub2xvZ3kgb2YgdGhlIGRyYWZ0IChpbmNsdWRpbmcgdGhlIHRpdGxlKSBpcyBzb21ld2hh dCBtaXNsZWFkaW5nIGFzIHRoZSBkb2VzIG5vdCBleHRlbmQgdGhlIE9TUEYgcm91dGluZyBwcm90 b2NvbC4gUmF0aGVyLCBpdCAgZXh0ZW5kcyB0aGUgT1NQRiBHTVBMUyBlbmNvZGluZ3MgYXMgZGVm aW5lZCBpbiBSRkMgNDIwMy4NClRoYW5rcywNCkFjZWUNCg0KRnJvbTogVGVhcyA8dGVhcy1ib3Vu Y2VzQGlldGYub3JnPG1haWx0bzp0ZWFzLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2Yg RGFuaWVsZSBDZWNjYXJlbGxpIDxkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tPG1haWx0 bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tPj4NCkRhdGU6IFRodXJzZGF5LCBNYXkg MTIsIDIwMTYgYXQgNDoyNSBBTQ0KVG86ICJDQ0FNUCAoY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNj YW1wQGlldGYub3JnPikiIDxjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+Piwg IlRFQVMgV0cgKHRlYXNAaWV0Zi5vcmc8bWFpbHRvOnRlYXNAaWV0Zi5vcmc+KSIgPHRlYXNAaWV0 Zi5vcmc8bWFpbHRvOnRlYXNAaWV0Zi5vcmc+Pg0KQ2M6ICJjY2FtcC1jaGFpcnNAaWV0Zi5vcmc8 bWFpbHRvOmNjYW1wLWNoYWlyc0BpZXRmLm9yZz4iIDxjY2FtcC1jaGFpcnNAaWV0Zi5vcmc8bWFp bHRvOmNjYW1wLWNoYWlyc0BpZXRmLm9yZz4+LCAidGVhcy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRv OnRlYXMtY2hhaXJzQGlldGYub3JnPiIgPHRlYXMtY2hhaXJzQGlldGYub3JnPG1haWx0bzp0ZWFz LWNoYWlyc0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBbVGVhc10gSm9pbnQgV0cgbGFzdCBjYWxsIG9u IGRyYWZ0LWlldGYtb3NwZi1hdmFpbGFiaWxpdHktZXh0ZW5zaW9uLTA0DQoNCkNDQU1QLCBURUFT LA0KDQpUaGlzIHN0YXJ0cyBhIHR3byB3ZWVrcyBqb2ludCB3b3JraW5nIGdyb3VwIGxhc3QgY2Fs bCBvbiBkcmFmdC1pZXRmLWNjYW1wLW9zcGYtYXZhaWxhYmlsaXR5LWV4dGVuc2lvbi0wNA0KVGhl IGxhc3QgY2FsbCBlbmQgb24gV2VkbmVzZGF5IE1heSAyNnRoLiBQbGVhc2Ugc2VuZCB5b3VyIGNv bW1lbnRzIHRvIGJvdGggdGhlIENDQU1QIGFuZCBURUFTIG1haWxpbmcgbGlzdHMuDQoNCkFsbCB0 aGUgSVBSIGRlY2xhcmF0aW9ucyBmcm9tIGF1dGhvcnMgYW5kIGNvbnRyaWJ1dG9ycyBoYXZlIGJl ZW4gY29sbGVjdGVkIGFuZCBjYW4gYmUgZm91bmQgaW4gdGhlIGhpc3Rvcnkgb2YgdGhlIGRvY3Vt ZW50OiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNjYW1wLW9z cGYtYXZhaWxhYmlsaXR5LWV4dGVuc2lvbi9oaXN0b3J5Lw0KUGxlYXNlIG5vdGUgdGhhdCBubyBJ UFIgd2FzIGRpc2Nsb3NlZCBhZ2FpbnN0IHRoaXMgZHJhZnQuDQoNCkFzIHVzdWFsIHRoaXMgaXMg YWxzbyBhIGNhbGwgZm9yIHNoZXBoZXJkLiBJZiBhbnlvbmUgaXMgd2lsbGluZyB0byBiZSB0aGUg c2hlcGhlcmQgb2YgdGhlIGRvY3VtZW50LCBwbGVhc2Ugdm9sdW50ZWVyLg0KDQoNCg0KVGhhbmtz DQoNCkRhbmllbGUsIEZhdGFpLCBMb3UsIFBhdmFuDQoNCg== --_000_9C5FD3EFA72E1740A3D41BADDE0B461F9CDB6B09szxema506mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNl dGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiLmibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRp di5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9w OjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1s ZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQ2hhcg0KCXttc28t c3R5bGUtbmFtZToi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazrmibnms6jmoYbmlofmnKw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N CnAuQmFsbG9vblRleHQsIGxpLkJhbGxvb25UZXh0LCBkaXYuQmFsbG9vblRleHQNCgl7bXNvLXN0 eWxlLW5hbWU6IkJhbGxvb24gVGV4dCI7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBD aGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5CYWxs b29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1 cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+SGkgQWNl ZSBhbmQgRGFuaWVsZSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPkkg cGxhbiB0byBjaGFuZ2UgdGhlIHRpdGxlIHRvIOKAnE9TUEYtVEUgRXh0ZW5zaW9uIGZvciBMaW5r cyB3aXRoIFZhcmlhYmxlIERpc2NyZXRlIEJhbmR3aWR0aOKAnSwgd2hhdCBkbyB5b3UgdGhpbms/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPkkgd2lsbCBhbHNv IHVwZGF0ZSB0aGUgdGV4dCBpbiB0aGUgZHJhZnQgYWNjb3JkaW5nbHkuDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPkJSLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtjb2xvcjojMUY0OTdEIj5BbXk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp diBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50 ZXIiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0 OTdEIj4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+ PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3Rl eHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmdyYXkiPlRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgY29u dGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoDQo8YnI+DQpp cyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB3aG9zZSBhZGRyZXNzIGlz IGxpc3RlZCBhYm92ZS4gQW55IHVzZSBvZiB0aGUNCjxicj4NCmluZm9ybWF0aW9uIGNvbnRhaW5l ZCBoZXJlaW4gaW4gYW55IHdheSAoaW5jbHVkaW5nLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFs IG9yIHBhcnRpYWwNCjxicj4NCmRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5h dGlvbikgYnkgcGVyc29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCA8YnI+DQpyZWNpcGllbnQo cykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieQ0KPGJyPg0KcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRl bHkgYW5kIGRlbGV0ZSBpdCE8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBUZWFzIFttYWlsdG86dGVhcy1i b3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5EYW5pZWxlIENlY2NhcmVsbGk8 YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXkgMTMsIDIwMTYgNjoxMCBQTTxicj4NCjxiPlRv OjwvYj4gQWNlZSBMaW5kZW0gKGFjZWUpOyBDQ0FNUCAoY2NhbXBAaWV0Zi5vcmcpOyBURUFTIFdH ICh0ZWFzQGlldGYub3JnKTxicj4NCjxiPkNjOjwvYj4gdGVhcy1jaGFpcnNAaWV0Zi5vcmc7IGNj YW1wLWNoYWlyc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RlYXNdIEpvaW50 IFdHIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLW9zcGYtYXZhaWxhYmlsaXR5LWV4dGVuc2lvbi0w NDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5Hb29kIHBvaW50IEFjZWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgd2l0aCB5b3UgSeKAmW0gZmluZSB3aXRo IHVwZGF0aW5nIHRoZSBJRCBhY2NvcmRpbmdseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhhbmtzPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5EYW5pZWxlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFjZWUgTGluZGVtIChhY2VlKSBbPGEg aHJlZj0ibWFpbHRvOmFjZWVAY2lzY28uY29tIj5tYWlsdG86YWNlZUBjaXNjby5jb208L2E+XQ0K PGJyPg0KPGI+U2VudDo8L2I+IGdpb3ZlZMOsIDEyIG1hZ2dpbyAyMDE2IDEzOjQyPGJyPg0KPGI+ VG86PC9iPiBEYW5pZWxlIENlY2NhcmVsbGk7IENDQU1QICg8YSBocmVmPSJtYWlsdG86Y2NhbXBA aWV0Zi5vcmciPmNjYW1wQGlldGYub3JnPC9hPik7IFRFQVMgV0cgKDxhIGhyZWY9Im1haWx0bzp0 ZWFzQGlldGYub3JnIj50ZWFzQGlldGYub3JnPC9hPik8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9 Im1haWx0bzpjY2FtcC1jaGFpcnNAaWV0Zi5vcmciPmNjYW1wLWNoYWlyc0BpZXRmLm9yZzwvYT47 IDxhIGhyZWY9Im1haWx0bzp0ZWFzLWNoYWlyc0BpZXRmLm9yZyI+DQp0ZWFzLWNoYWlyc0BpZXRm Lm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtUZWFzXSBKb2ludCBXRyBsYXN0IGNh bGwgb24gZHJhZnQtaWV0Zi1vc3BmLWF2YWlsYWJpbGl0eS1leHRlbnNpb24tMDQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Y29sb3I6YmxhY2siPkkgcmVhbGl6ZSBpdCBoYXMgYWx3YXlzIGJlZW4gdGhpcyB3YXkgYnV0IHRo ZSB0ZXJtaW5vbG9neSBvZiB0aGUgZHJhZnQgKGluY2x1ZGluZyB0aGUgdGl0bGUpIGlzIHNvbWV3 aGF0IG1pc2xlYWRpbmcgYXMgdGhlIGRvZXMgbm90IGV4dGVuZCB0aGUgT1NQRiByb3V0aW5nIHBy b3RvY29sLiBSYXRoZXIsIGl0ICZuYnNwO2V4dGVuZHMNCiB0aGUgT1NQRiBHTVBMUyBlbmNvZGlu Z3MgYXMgZGVmaW5lZCBpbiBSRkMgNDIwMy4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPkFjZWUmbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOmJsYWNrIj5UZWFzICZsdDs8YSBocmVmPSJtYWlsdG86dGVhcy1ib3VuY2VzQGlldGYub3Jn Ij50ZWFzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgRGFuaWVsZSBDZWNj YXJlbGxpICZsdDs8YSBocmVmPSJtYWlsdG86ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNv bSI+ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTog PC9iPlRodXJzZGF5LCBNYXkgMTIsIDIwMTYgYXQgNDoyNSBBTTxicj4NCjxiPlRvOiA8L2I+JnF1 b3Q7Q0NBTVAgKDxhIGhyZWY9Im1haWx0bzpjY2FtcEBpZXRmLm9yZyI+Y2NhbXBAaWV0Zi5vcmc8 L2E+KSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNjYW1wQGlldGYub3JnIj5jY2FtcEBpZXRm Lm9yZzwvYT4mZ3Q7LCAmcXVvdDtURUFTIFdHICg8YSBocmVmPSJtYWlsdG86dGVhc0BpZXRmLm9y ZyI+dGVhc0BpZXRmLm9yZzwvYT4pJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86dGVhc0BpZXRm Lm9yZyI+dGVhc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDs8YSBocmVm PSJtYWlsdG86Y2NhbXAtY2hhaXJzQGlldGYub3JnIj5jY2FtcC1jaGFpcnNAaWV0Zi5vcmc8L2E+ JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Y2NhbXAtY2hhaXJzQGlldGYub3JnIj5jY2FtcC1j aGFpcnNAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnRlYXMtY2hhaXJz QGlldGYub3JnIj50ZWFzLWNoYWlyc0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzp0ZWFzLWNoYWlyc0BpZXRmLm9yZyI+dGVhcy1jaGFpcnNAaWV0Zi5vcmc8L2E+Jmd0Ozxi cj4NCjxiPlN1YmplY3Q6IDwvYj5bVGVhc10gSm9pbnQgV0cgbGFzdCBjYWxsIG9uIGRyYWZ0LWll dGYtb3NwZi1hdmFpbGFiaWxpdHktZXh0ZW5zaW9uLTA0PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQ7bWFyZ2luLWxl ZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9t OjUuMHB0IiBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6YmxhY2siPkNDQU1QLCBURUFTLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPlRoaXMgc3RhcnRzIGEgdHdvIHdlZWtzIGpvaW50IHdv cmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtY2NhbXAtb3NwZi1hdmFpbGFiaWxp dHktZXh0ZW5zaW9uLTA0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIGxhc3QgY2FsbCBl bmQgb24gV2VkbmVzZGF5IE1heSAyNjxzdXA+dGg8L3N1cD4uIFBsZWFzZSBzZW5kIHlvdXIgY29t bWVudHMgdG8gYm90aCB0aGUgQ0NBTVAgYW5kIFRFQVMgbWFpbGluZyBsaXN0cy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5BbGwgdGhl IElQUiBkZWNsYXJhdGlvbnMgZnJvbSBhdXRob3JzIGFuZCBjb250cmlidXRvcnMgaGF2ZSBiZWVu IGNvbGxlY3RlZCBhbmQgY2FuIGJlIGZvdW5kIGluIHRoZSBoaXN0b3J5IG9mIHRoZSBkb2N1bWVu dDoNCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt Y2NhbXAtb3NwZi1hdmFpbGFiaWxpdHktZXh0ZW5zaW9uL2hpc3RvcnkvIj4NCmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY2NhbXAtb3NwZi1hdmFpbGFiaWxpdHkt ZXh0ZW5zaW9uL2hpc3RvcnkvPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPlBsZWFzZSBu b3RlIHRoYXQgbm8gSVBSIHdhcyBkaXNjbG9zZWQgYWdhaW5zdCB0aGlzIGRyYWZ0LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPkFzIHVz dWFsIHRoaXMgaXMgYWxzbyBhIGNhbGwgZm9yIHNoZXBoZXJkLiBJZiBhbnlvbmUgaXMgd2lsbGlu ZyB0byBiZSB0aGUgc2hlcGhlcmQgb2YgdGhlIGRvY3VtZW50LCBwbGVhc2Ugdm9sdW50ZWVyLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjpibGFjayI+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPkRh bmllbGUsIEZhdGFpLCBMb3UsIFBhdmFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9C5FD3EFA72E1740A3D41BADDE0B461F9CDB6B09szxema506mbschi_-- From nobody Mon May 30 04:40:39 2016 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 5D44112D507; Mon, 30 May 2016 04:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pa0NB9WzB9h5; Mon, 30 May 2016 04:40:33 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEE3512D1F0; Mon, 30 May 2016 04:40:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25371; q=dns/txt; s=iport; t=1464608432; x=1465818032; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5uRZ1HybgHIAKJmnFk6KEJsADEssqwj0Nspyv2RKZMw=; b=XMgjC7ZOTbqglnTSndPYOzVtlHon6VRx22phuW4I4w5AKe9oI/IxhBgN CgOXp/BRuN385r/rmxB4nk5tZ+JJtMyqI10k/jPCb5Ddju5NWs81Swzup hBzv+KijJjUiZ34jeoueO9C4jKXjuM7lZgq6SMKViXVdlideM08SFZ8du c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B/AgBDJkxX/51dJa1dgm9NVn0Ggz22Q?= =?us-ascii?q?QENgXkkhW0CHIESOBQBAQEBAQEBZSeERQEBAQQdBgpBCxACAQgRAwEBASgDAgI?= =?us-ascii?q?CMBQJCAIEAQ0FiC8OqkyRBgEBAQEBAQEBAQEBAQEBAQEBAQEBARcFinSEEgoHA?= =?us-ascii?q?TwWglOCWQWTN4UAAYV/iCCBaYRPiGSGM4kYAR4BAUKDbW6HeBAXH38BAQE?= X-IronPort-AV: E=Sophos;i="5.26,389,1459814400"; d="scan'208,217";a="279571900" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 May 2016 11:40:31 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u4UBeVoi025296 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 30 May 2016 11:40:31 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 30 May 2016 07:40:30 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Mon, 30 May 2016 07:40:30 -0400 From: "Acee Lindem (acee)" To: "Yemin (Amy)" , Daniele Ceccarelli , "CCAMP (ccamp@ietf.org)" , "TEAS WG (teas@ietf.org)" Thread-Topic: [Teas] Joint WG last call on draft-ietf-ospf-availability-extension-04 Thread-Index: AQHRrENIRgSsmvfWRU2f/UUwoeFDU5+26aaAgBqsvID//+E9gA== Date: Mon, 30 May 2016 11:40:30 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE48162CC275@ESESSMB301.ericsson.se> <4A1562797D64E44993C5CBF38CF1BE48162CDFB4@ESESSMB301.ericsson.se> <9C5FD3EFA72E1740A3D41BADDE0B461F9CDB6B09@szxema506-mbs.china.huawei.com> In-Reply-To: <9C5FD3EFA72E1740A3D41BADDE0B461F9CDB6B09@szxema506-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: multipart/alternative; boundary="_000_D3719E1E62BB3aceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "ccamp-chairs@ietf.org" , "teas-chairs@ietf.org" Subject: Re: [Teas] Joint WG last call on draft-ietf-ospf-availability-extension-04 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 30 May 2016 11:40:35 -0000 --_000_D3719E1E62BB3aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW15LA0KVGhhdCB3b3VsZCBiZSBhY2NlcHRhYmxlLiBIb3dldmVyLCAgaXQgc2VlbXMgdGhh dCDigJxPU1BGLVRFIExpbmsgQXZhaWxhYmlsaXR5IEV4dGVuc2lvbuKAnSB3b3VsZCBiZSBtb3Jl IGFjY3VyYXRlLg0KVGhhbmtzLA0KQWNlZQ0KDQpGcm9tOiAiWWVtaW4gKEFteSkiIDxhbXkueWVt aW5AaHVhd2VpLmNvbTxtYWlsdG86YW15LnllbWluQGh1YXdlaS5jb20+Pg0KRGF0ZTogTW9uZGF5 LCBNYXkgMzAsIDIwMTYgYXQgNTozMCBBTQ0KVG86IERhbmllbGUgQ2VjY2FyZWxsaSA8ZGFuaWVs ZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbTxtYWlsdG86ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNz c29uLmNvbT4+LCBBY2VlIExpbmRlbSA8YWNlZUBjaXNjby5jb208bWFpbHRvOmFjZWVAY2lzY28u Y29tPj4sICJDQ0FNUCAoY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPikiIDxj Y2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+PiwgIlRFQVMgV0cgKHRlYXNAaWV0 Zi5vcmc8bWFpbHRvOnRlYXNAaWV0Zi5vcmc+KSIgPHRlYXNAaWV0Zi5vcmc8bWFpbHRvOnRlYXNA aWV0Zi5vcmc+Pg0KQ2M6ICJ0ZWFzLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86dGVhcy1jaGFpcnNA aWV0Zi5vcmc+IiA8dGVhcy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOnRlYXMtY2hhaXJzQGlldGYu b3JnPj4sICJjY2FtcC1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wLWNoYWlyc0BpZXRmLm9y Zz4iIDxjY2FtcC1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wLWNoYWlyc0BpZXRmLm9yZz4+ DQpTdWJqZWN0OiBSRTogW1RlYXNdIEpvaW50IFdHIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLW9z cGYtYXZhaWxhYmlsaXR5LWV4dGVuc2lvbi0wNA0KDQpIaSBBY2VlIGFuZCBEYW5pZWxlLA0KDQpJ IHBsYW4gdG8gY2hhbmdlIHRoZSB0aXRsZSB0byDigJxPU1BGLVRFIEV4dGVuc2lvbiBmb3IgTGlu a3Mgd2l0aCBWYXJpYWJsZSBEaXNjcmV0ZSBCYW5kd2lkdGjigJ0sIHdoYXQgZG8geW91IHRoaW5r Pw0KSSB3aWxsIGFsc28gdXBkYXRlIHRoZSB0ZXh0IGluIHRoZSBkcmFmdCBhY2NvcmRpbmdseS4N Cg0KQlIsDQpBbXkNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUaGlzIGUtbWFp bCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGZy b20gSFVBV0VJLCB3aGljaA0KaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiBvciBlbnRp dHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhlDQppbmZvcm1h dGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkgKGluY2x1ZGluZywgYnV0IG5vdCBsaW1p dGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsDQpkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIG9yIGRp c3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQNCnJlY2lwaWVu dChzKSBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZSB0aGlzIGUtbWFpbCBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5DQpwaG9uZSBvciBlbWFpbCBpbW1lZGlhdGVseSBh bmQgZGVsZXRlIGl0IQ0KDQpGcm9tOiBUZWFzIFttYWlsdG86dGVhcy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgRGFuaWVsZSBDZWNjYXJlbGxpDQpTZW50OiBGcmlkYXksIE1heSAxMywg MjAxNiA2OjEwIFBNDQpUbzogQWNlZSBMaW5kZW0gKGFjZWUpOyBDQ0FNUCAoY2NhbXBAaWV0Zi5v cmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPik7IFRFQVMgV0cgKHRlYXNAaWV0Zi5vcmc8bWFpbHRv OnRlYXNAaWV0Zi5vcmc+KQ0KQ2M6IHRlYXMtY2hhaXJzQGlldGYub3JnPG1haWx0bzp0ZWFzLWNo YWlyc0BpZXRmLm9yZz47IGNjYW1wLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86Y2NhbXAtY2hhaXJz QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtUZWFzXSBKb2ludCBXRyBsYXN0IGNhbGwgb24gZHJh ZnQtaWV0Zi1vc3BmLWF2YWlsYWJpbGl0eS1leHRlbnNpb24tMDQNCg0KR29vZCBwb2ludCBBY2Vl Lg0KDQpJIGFncmVlIHdpdGggeW91IEnigJltIGZpbmUgd2l0aCB1cGRhdGluZyB0aGUgSUQgYWNj b3JkaW5nbHkuDQoNClRoYW5rcw0KRGFuaWVsZQ0KDQpGcm9tOiBBY2VlIExpbmRlbSAoYWNlZSkg W21haWx0bzphY2VlQGNpc2NvLmNvbV0NClNlbnQ6IGdpb3ZlZMOsIDEyIG1hZ2dpbyAyMDE2IDEz OjQyDQpUbzogRGFuaWVsZSBDZWNjYXJlbGxpOyBDQ0FNUCAoY2NhbXBAaWV0Zi5vcmc8bWFpbHRv OmNjYW1wQGlldGYub3JnPik7IFRFQVMgV0cgKHRlYXNAaWV0Zi5vcmc8bWFpbHRvOnRlYXNAaWV0 Zi5vcmc+KQ0KQ2M6IGNjYW1wLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86Y2NhbXAtY2hhaXJzQGll dGYub3JnPjsgdGVhcy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOnRlYXMtY2hhaXJzQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFtUZWFzXSBKb2ludCBXRyBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1v c3BmLWF2YWlsYWJpbGl0eS1leHRlbnNpb24tMDQNCg0KSSByZWFsaXplIGl0IGhhcyBhbHdheXMg YmVlbiB0aGlzIHdheSBidXQgdGhlIHRlcm1pbm9sb2d5IG9mIHRoZSBkcmFmdCAoaW5jbHVkaW5n IHRoZSB0aXRsZSkgaXMgc29tZXdoYXQgbWlzbGVhZGluZyBhcyB0aGUgZG9lcyBub3QgZXh0ZW5k IHRoZSBPU1BGIHJvdXRpbmcgcHJvdG9jb2wuIFJhdGhlciwgaXQgIGV4dGVuZHMgdGhlIE9TUEYg R01QTFMgZW5jb2RpbmdzIGFzIGRlZmluZWQgaW4gUkZDIDQyMDMuDQpUaGFua3MsDQpBY2VlDQoN CkZyb206IFRlYXMgPHRlYXMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dGVhcy1ib3VuY2VzQGll dGYub3JnPj4gb24gYmVoYWxmIG9mIERhbmllbGUgQ2VjY2FyZWxsaSA8ZGFuaWVsZS5jZWNjYXJl bGxpQGVyaWNzc29uLmNvbTxtYWlsdG86ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbT4+ DQpEYXRlOiBUaHVyc2RheSwgTWF5IDEyLCAyMDE2IGF0IDQ6MjUgQU0NClRvOiAiQ0NBTVAgKGNj YW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4pIiA8Y2NhbXBAaWV0Zi5vcmc8bWFp bHRvOmNjYW1wQGlldGYub3JnPj4sICJURUFTIFdHICh0ZWFzQGlldGYub3JnPG1haWx0bzp0ZWFz QGlldGYub3JnPikiIDx0ZWFzQGlldGYub3JnPG1haWx0bzp0ZWFzQGlldGYub3JnPj4NCkNjOiAi Y2NhbXAtY2hhaXJzQGlldGYub3JnPG1haWx0bzpjY2FtcC1jaGFpcnNAaWV0Zi5vcmc+IiA8Y2Nh bXAtY2hhaXJzQGlldGYub3JnPG1haWx0bzpjY2FtcC1jaGFpcnNAaWV0Zi5vcmc+PiwgInRlYXMt Y2hhaXJzQGlldGYub3JnPG1haWx0bzp0ZWFzLWNoYWlyc0BpZXRmLm9yZz4iIDx0ZWFzLWNoYWly c0BpZXRmLm9yZzxtYWlsdG86dGVhcy1jaGFpcnNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW1RlYXNd IEpvaW50IFdHIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLW9zcGYtYXZhaWxhYmlsaXR5LWV4dGVu c2lvbi0wNA0KDQpDQ0FNUCwgVEVBUywNCg0KVGhpcyBzdGFydHMgYSB0d28gd2Vla3Mgam9pbnQg d29ya2luZyBncm91cCBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1jY2FtcC1vc3BmLWF2YWlsYWJp bGl0eS1leHRlbnNpb24tMDQNClRoZSBsYXN0IGNhbGwgZW5kIG9uIFdlZG5lc2RheSBNYXkgMjZ0 aC4gUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byBib3RoIHRoZSBDQ0FNUCBhbmQgVEVBUyBt YWlsaW5nIGxpc3RzLg0KDQpBbGwgdGhlIElQUiBkZWNsYXJhdGlvbnMgZnJvbSBhdXRob3JzIGFu ZCBjb250cmlidXRvcnMgaGF2ZSBiZWVuIGNvbGxlY3RlZCBhbmQgY2FuIGJlIGZvdW5kIGluIHRo ZSBoaXN0b3J5IG9mIHRoZSBkb2N1bWVudDogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1jY2FtcC1vc3BmLWF2YWlsYWJpbGl0eS1leHRlbnNpb24vaGlzdG9yeS8N ClBsZWFzZSBub3RlIHRoYXQgbm8gSVBSIHdhcyBkaXNjbG9zZWQgYWdhaW5zdCB0aGlzIGRyYWZ0 Lg0KDQpBcyB1c3VhbCB0aGlzIGlzIGFsc28gYSBjYWxsIGZvciBzaGVwaGVyZC4gSWYgYW55b25l IGlzIHdpbGxpbmcgdG8gYmUgdGhlIHNoZXBoZXJkIG9mIHRoZSBkb2N1bWVudCwgcGxlYXNlIHZv bHVudGVlci4NCg0KDQoNClRoYW5rcw0KDQpEYW5pZWxlLCBGYXRhaSwgTG91LCBQYXZhbg0KDQo= --_000_D3719E1E62BB3aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <75E0248469AFFF4291D4B5E39FE81C69@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBBbXksJm5i c3A7PC9kaXY+DQo8ZGl2PlRoYXQgd291bGQgYmUgYWNjZXB0YWJsZS4gSG93ZXZlciwgJm5ic3A7 aXQgc2VlbXMgdGhhdCDigJxPU1BGLVRFIExpbmsgQXZhaWxhYmlsaXR5IEV4dGVuc2lvbuKAnSB3 b3VsZCBiZSBtb3JlIGFjY3VyYXRlLiZuYnNwOzwvZGl2Pg0KPGRpdj5UaGFua3MsPC9kaXY+DQo8 ZGl2PkFjZWU8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZ X1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjEx cHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBu b25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJ TkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0 IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+JnF1b3Q7WWVtaW4gKEFt eSkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzphbXkueWVtaW5AaHVhd2VpLmNvbSI+YW15Lnll bWluQGh1YXdlaS5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5EYXRlOiA8L3NwYW4+TW9uZGF5LCBNYXkgMzAsIDIwMTYgYXQgNTozMCBBTTxicj4NCjxzcGFu IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPkRhbmllbGUgQ2VjY2FyZWxsaSAm bHQ7PGEgaHJlZj0ibWFpbHRvOmRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb20iPmRhbmll bGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb208L2E+Jmd0OywgQWNlZSBMaW5kZW0gJmx0OzxhIGhy ZWY9Im1haWx0bzphY2VlQGNpc2NvLmNvbSI+YWNlZUBjaXNjby5jb208L2E+Jmd0OywgJnF1b3Q7 Q0NBTVAgKDxhIGhyZWY9Im1haWx0bzpjY2FtcEBpZXRmLm9yZyI+Y2NhbXBAaWV0Zi5vcmc8L2E+ KSZxdW90Ow0KICZsdDs8YSBocmVmPSJtYWlsdG86Y2NhbXBAaWV0Zi5vcmciPmNjYW1wQGlldGYu b3JnPC9hPiZndDssICZxdW90O1RFQVMgV0cgKDxhIGhyZWY9Im1haWx0bzp0ZWFzQGlldGYub3Jn Ij50ZWFzQGlldGYub3JnPC9hPikmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp0ZWFzQGlldGYu b3JnIj50ZWFzQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6 Ym9sZCI+Q2M6IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86dGVhcy1jaGFpcnNAaWV0Zi5v cmciPnRlYXMtY2hhaXJzQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRl YXMtY2hhaXJzQGlldGYub3JnIj50ZWFzLWNoYWlyc0BpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8 YSBocmVmPSJtYWlsdG86Y2NhbXAtY2hhaXJzQGlldGYub3JnIj5jY2FtcC1jaGFpcnNAaWV0Zi5v cmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Y2NhbXAtY2hhaXJzQGlldGYub3JnIj5j Y2FtcC1jaGFpcnNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UkU6IFtUZWFzXSBKb2ludCBXRyBsYXN0IGNhbGwgb24g ZHJhZnQtaWV0Zi1vc3BmLWF2YWlsYWJpbGl0eS1leHRlbnNpb24tMDQ8YnI+DQo8L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05f QkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6 MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXYgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWlj cm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNl Om9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIg eG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1s IiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8bWV0YSBuYW1lPSJH ZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4N CjwhLS1baWYgIW1zb10+PHN0eWxlPnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30N Cm9cOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVybCgj ZGVmYXVsdCNWTUwpO30NCi5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9z dHlsZT48IVtlbmRpZl0tLT48c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAx IDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9z ZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxp YnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0 IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxp Lk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdy YXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFy Z2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCglt YXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkNoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms65om55rOo5qGG5paH5pysOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQpwLkJhbGxvb25UZXh0LCBsaS5CYWxsb29uVGV4dCwgZGl2LkJhbGxvb25UZXh0DQoJ e21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQiOw0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNw YW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQi Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUy NA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVw dCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8ZGl2IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+SGkgQWNlZSBh bmQgRGFuaWVsZSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPkkgcGxh biB0byBjaGFuZ2UgdGhlIHRpdGxlIHRvIOKAnE9TUEYtVEUgRXh0ZW5zaW9uIGZvciBMaW5rcyB3 aXRoIFZhcmlhYmxlIERpc2NyZXRlIEJhbmR3aWR0aOKAnSwgd2hhdCBkbyB5b3UgdGhpbms/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPkkgd2lsbCBhbHNvIHVw ZGF0ZSB0aGUgdGV4dCBpbiB0aGUgZHJhZnQgYWNjb3JkaW5nbHkuDQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPkJSLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtjb2xvcjojMUY0OTdEIj5BbXk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBj bGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdE Ij4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQt anVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IGdyYXk7 Ij5UaGlzIGUtbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGlu Zm9ybWF0aW9uIGZyb20gSFVBV0VJLCB3aGljaA0KPGJyPg0KaXMgaW50ZW5kZWQgb25seSBmb3Ig dGhlIHBlcnNvbiBvciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1 c2Ugb2YgdGhlDQo8YnI+DQppbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkg KGluY2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsDQo8YnI+DQpk aXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIG9yIGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3Ro ZXIgdGhhbiB0aGUgaW50ZW5kZWQgPGJyPg0KcmVjaXBpZW50KHMpIGlzIHByb2hpYml0ZWQuIElm IHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgYnkNCjxicj4NCnBob25lIG9yIGVtYWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQhPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0 OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZv bnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7Ij4gVGVhcyBbPGEgaHJlZj0ibWFpbHRvOnRl YXMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnRlYXMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8 Yj5PbiBCZWhhbGYgT2YgPC9iPkRhbmllbGUgQ2VjY2FyZWxsaTxicj4NCjxiPlNlbnQ6PC9iPiBG cmlkYXksIE1heSAxMywgMjAxNiA2OjEwIFBNPGJyPg0KPGI+VG86PC9iPiBBY2VlIExpbmRlbSAo YWNlZSk7IENDQU1QICg8YSBocmVmPSJtYWlsdG86Y2NhbXBAaWV0Zi5vcmciPmNjYW1wQGlldGYu b3JnPC9hPik7IFRFQVMgV0cgKDxhIGhyZWY9Im1haWx0bzp0ZWFzQGlldGYub3JnIj50ZWFzQGll dGYub3JnPC9hPik8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzp0ZWFzLWNoYWlyc0Bp ZXRmLm9yZyI+dGVhcy1jaGFpcnNAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86Y2NhbXAt Y2hhaXJzQGlldGYub3JnIj4NCmNjYW1wLWNoYWlyc0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtUZWFzXSBKb2ludCBXRyBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1vc3Bm LWF2YWlsYWJpbGl0eS1leHRlbnNpb24tMDQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+R29vZCBwb2ludCBBY2VlLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JIGFncmVl IHdpdGggeW91IEnigJltIGZpbmUgd2l0aCB1cGRhdGluZyB0aGUgSUQgYWNjb3JkaW5nbHkuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPlRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+RGFuaWVsZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTBw dDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9t YSwgc2Fucy1zZXJpZjsiPiBBY2VlIExpbmRlbSAoYWNlZSkgWzxhIGhyZWY9Im1haWx0bzphY2Vl QGNpc2NvLmNvbSI+bWFpbHRvOmFjZWVAY2lzY28uY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9i PiBnaW92ZWTDrCAxMiBtYWdnaW8gMjAxNiAxMzo0Mjxicj4NCjxiPlRvOjwvYj4gRGFuaWVsZSBD ZWNjYXJlbGxpOyBDQ0FNUCAoPGEgaHJlZj0ibWFpbHRvOmNjYW1wQGlldGYub3JnIj5jY2FtcEBp ZXRmLm9yZzwvYT4pOyBURUFTIFdHICg8YSBocmVmPSJtYWlsdG86dGVhc0BpZXRmLm9yZyI+dGVh c0BpZXRmLm9yZzwvYT4pPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86Y2NhbXAtY2hh aXJzQGlldGYub3JnIj5jY2FtcC1jaGFpcnNAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86 dGVhcy1jaGFpcnNAaWV0Zi5vcmciPg0KdGVhcy1jaGFpcnNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbVGVhc10gSm9pbnQgV0cgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYt b3NwZi1hdmFpbGFiaWxpdHktZXh0ZW5zaW9uLTA0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5JIHJl YWxpemUgaXQgaGFzIGFsd2F5cyBiZWVuIHRoaXMgd2F5IGJ1dCB0aGUgdGVybWlub2xvZ3kgb2Yg dGhlIGRyYWZ0IChpbmNsdWRpbmcgdGhlIHRpdGxlKSBpcyBzb21ld2hhdCBtaXNsZWFkaW5nIGFz IHRoZSBkb2VzIG5vdCBleHRlbmQgdGhlIE9TUEYgcm91dGluZyBwcm90b2NvbC4gUmF0aGVyLCBp dCAmbmJzcDtleHRlbmRzDQogdGhlIE9TUEYgR01QTFMgZW5jb2RpbmdzIGFzIGRlZmluZWQgaW4g UkZDIDQyMDMuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2NvbG9yOmJsYWNrIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5BY2VlJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPkZyb206 IDwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+VGVhcyAm bHQ7PGEgaHJlZj0ibWFpbHRvOnRlYXMtYm91bmNlc0BpZXRmLm9yZyI+dGVhcy1ib3VuY2VzQGll dGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIERhbmllbGUgQ2VjY2FyZWxsaSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb20iPmRhbmllbGUuY2VjY2Fy ZWxsaUBlcmljc3Nvbi5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHVyc2RheSwgTWF5 IDEyLCAyMDE2IGF0IDQ6MjUgQU08YnI+DQo8Yj5UbzogPC9iPiZxdW90O0NDQU1QICg8YSBocmVm PSJtYWlsdG86Y2NhbXBAaWV0Zi5vcmciPmNjYW1wQGlldGYub3JnPC9hPikmcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpjY2FtcEBpZXRmLm9yZyI+Y2NhbXBAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1 b3Q7VEVBUyBXRyAoPGEgaHJlZj0ibWFpbHRvOnRlYXNAaWV0Zi5vcmciPnRlYXNAaWV0Zi5vcmc8 L2E+KSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRlYXNAaWV0Zi5vcmciPnRlYXNAaWV0Zi5v cmc8L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmNjYW1wLWNo YWlyc0BpZXRmLm9yZyI+Y2NhbXAtY2hhaXJzQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmNjYW1wLWNoYWlyc0BpZXRmLm9yZyI+Y2NhbXAtY2hhaXJzQGlldGYub3JnPC9h PiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzp0ZWFzLWNoYWlyc0BpZXRmLm9yZyI+dGVhcy1j aGFpcnNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86dGVhcy1jaGFpcnNA aWV0Zi5vcmciPnRlYXMtY2hhaXJzQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8 L2I+W1RlYXNdIEpvaW50IFdHIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLW9zcGYtYXZhaWxhYmls aXR5LWV4dGVuc2lvbi0wNDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0 LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCIgaWQ9Ik1BQ19P VVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5DQ0FNUCwg VEVBUyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OmJsYWNrIj5UaGlzIHN0YXJ0cyBhIHR3byB3ZWVrcyBqb2ludCB3b3JraW5nIGdyb3VwIGxhc3Qg Y2FsbCBvbiBkcmFmdC1pZXRmLWNjYW1wLW9zcGYtYXZhaWxhYmlsaXR5LWV4dGVuc2lvbi0wNDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZSBsYXN0IGNhbGwgZW5kIG9uIFdlZG5lc2RheSBN YXkgMjY8c3VwPnRoPC9zdXA+LiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIGJvdGggdGhl IENDQU1QIGFuZCBURUFTIG1haWxpbmcgbGlzdHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+QWxsIHRoZSBJUFIgZGVjbGFyYXRpb25z IGZyb20gYXV0aG9ycyBhbmQgY29udHJpYnV0b3JzIGhhdmUgYmVlbiBjb2xsZWN0ZWQgYW5kIGNh biBiZSBmb3VuZCBpbiB0aGUgaGlzdG9yeSBvZiB0aGUgZG9jdW1lbnQ6DQo8YSBocmVmPSJodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNjYW1wLW9zcGYtYXZhaWxh YmlsaXR5LWV4dGVuc2lvbi9oaXN0b3J5LyI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLWNjYW1wLW9zcGYtYXZhaWxhYmlsaXR5LWV4dGVuc2lvbi9oaXN0b3J5 LzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5QbGVhc2Ugbm90ZSB0aGF0IG5vIElQUiB3 YXMgZGlzY2xvc2VkIGFnYWluc3QgdGhpcyBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5BcyB1c3VhbCB0aGlzIGlzIGFsc28g YSBjYWxsIGZvciBzaGVwaGVyZC4gSWYgYW55b25lIGlzIHdpbGxpbmcgdG8gYmUgdGhlIHNoZXBo ZXJkIG9mIHRoZSBkb2N1bWVudCwgcGxlYXNlIHZvbHVudGVlci48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPlRo YW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5EYW5pZWxlLCBGYXRhaSwgTG91 LCBQYXZhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D3719E1E62BB3aceeciscocom_-- From nobody Mon May 30 19:04:18 2016 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 1910F12D11A; Mon, 30 May 2016 19:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 DC8BbX9h2OHR; Mon, 30 May 2016 19:04:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF7D112D113; Mon, 30 May 2016 19:04:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLC17145; Tue, 31 May 2016 02:04:08 +0000 (GMT) Received: from SZXEMA415-HUB.china.huawei.com (10.82.72.33) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 31 May 2016 03:04:07 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.196]) by SZXEMA415-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0235.001; Tue, 31 May 2016 10:04:03 +0800 From: "Yemin (Amy)" To: "Acee Lindem (acee)" , Daniele Ceccarelli , "CCAMP (ccamp@ietf.org)" , "TEAS WG (teas@ietf.org)" Thread-Topic: [Teas] Joint WG last call on draft-ietf-ospf-availability-extension-04 Thread-Index: AQHRrENg2RhFJF80w0iwtIkwVPiYfp+2IHuAgBsySED//568AIABdtbg Date: Tue, 31 May 2016 02:04:03 +0000 Message-ID: <9C5FD3EFA72E1740A3D41BADDE0B461F9CDB6C9D@szxema506-mbs.china.huawei.com> References: <4A1562797D64E44993C5CBF38CF1BE48162CC275@ESESSMB301.ericsson.se> <4A1562797D64E44993C5CBF38CF1BE48162CDFB4@ESESSMB301.ericsson.se> <9C5FD3EFA72E1740A3D41BADDE0B461F9CDB6B09@szxema506-mbs.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.169.31.176] Content-Type: multipart/alternative; boundary="_000_9C5FD3EFA72E1740A3D41BADDE0B461F9CDB6C9Dszxema506mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.574CF119.012D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.196, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: cca986a31d884363e9d1ad3ef39f6c56 Archived-At: Cc: "ccamp-chairs@ietf.org" , "teas-chairs@ietf.org" Subject: Re: [Teas] Joint WG last call on draft-ietf-ospf-availability-extension-04 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.17 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, 31 May 2016 02:04:16 -0000 --_000_9C5FD3EFA72E1740A3D41BADDE0B461F9CDB6C9Dszxema506mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWNlZSwNCg0KVGhhbmtzIGZvciBzdWdnZXN0aW9uLCBJIHdpbGwgdXBkYXRlIHRoZSB0aXRs ZSBhcyB5b3Ugc3VnZ2VzdGVkLg0KDQpCUiwNCkFteQ0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NClRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgY29udGFpbiBjb25maWRl bnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoDQppcyBpbnRlbmRlZCBvbmx5IGZv ciB0aGUgcGVyc29uIG9yIGVudGl0eSB3aG9zZSBhZGRyZXNzIGlzIGxpc3RlZCBhYm92ZS4gQW55 IHVzZSBvZiB0aGUNCmluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4gYW55IHdheSAoaW5j bHVkaW5nLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwNCmRpc2Nsb3N1cmUs IHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgYnkgcGVyc29ucyBvdGhlciB0aGFuIHRo ZSBpbnRlbmRlZA0KcmVjaXBpZW50KHMpIGlzIHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlIHRo aXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYnkNCnBob25lIG9y IGVtYWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQhDQoNCkZyb206IEFjZWUgTGluZGVtIChh Y2VlKSBbbWFpbHRvOmFjZWVAY2lzY28uY29tXQ0KU2VudDogTW9uZGF5LCBNYXkgMzAsIDIwMTYg Nzo0MSBQTQ0KVG86IFllbWluIChBbXkpOyBEYW5pZWxlIENlY2NhcmVsbGk7IENDQU1QIChjY2Ft cEBpZXRmLm9yZyk7IFRFQVMgV0cgKHRlYXNAaWV0Zi5vcmcpDQpDYzogdGVhcy1jaGFpcnNAaWV0 Zi5vcmc7IGNjYW1wLWNoYWlyc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUZWFzXSBKb2ludCBX RyBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1vc3BmLWF2YWlsYWJpbGl0eS1leHRlbnNpb24tMDQN Cg0KSGkgQW15LA0KVGhhdCB3b3VsZCBiZSBhY2NlcHRhYmxlLiBIb3dldmVyLCAgaXQgc2VlbXMg dGhhdCDigJxPU1BGLVRFIExpbmsgQXZhaWxhYmlsaXR5IEV4dGVuc2lvbuKAnSB3b3VsZCBiZSBt b3JlIGFjY3VyYXRlLg0KVGhhbmtzLA0KQWNlZQ0KDQpGcm9tOiAiWWVtaW4gKEFteSkiIDxhbXku eWVtaW5AaHVhd2VpLmNvbTxtYWlsdG86YW15LnllbWluQGh1YXdlaS5jb20+Pg0KRGF0ZTogTW9u ZGF5LCBNYXkgMzAsIDIwMTYgYXQgNTozMCBBTQ0KVG86IERhbmllbGUgQ2VjY2FyZWxsaSA8ZGFu aWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbTxtYWlsdG86ZGFuaWVsZS5jZWNjYXJlbGxpQGVy aWNzc29uLmNvbT4+LCBBY2VlIExpbmRlbSA8YWNlZUBjaXNjby5jb208bWFpbHRvOmFjZWVAY2lz Y28uY29tPj4sICJDQ0FNUCAoY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPiki IDxjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+PiwgIlRFQVMgV0cgKHRlYXNA aWV0Zi5vcmc8bWFpbHRvOnRlYXNAaWV0Zi5vcmc+KSIgPHRlYXNAaWV0Zi5vcmc8bWFpbHRvOnRl YXNAaWV0Zi5vcmc+Pg0KQ2M6ICJ0ZWFzLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86dGVhcy1jaGFp cnNAaWV0Zi5vcmc+IiA8dGVhcy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOnRlYXMtY2hhaXJzQGll dGYub3JnPj4sICJjY2FtcC1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wLWNoYWlyc0BpZXRm Lm9yZz4iIDxjY2FtcC1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wLWNoYWlyc0BpZXRmLm9y Zz4+DQpTdWJqZWN0OiBSRTogW1RlYXNdIEpvaW50IFdHIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRm LW9zcGYtYXZhaWxhYmlsaXR5LWV4dGVuc2lvbi0wNA0KDQpIaSBBY2VlIGFuZCBEYW5pZWxlLA0K DQpJIHBsYW4gdG8gY2hhbmdlIHRoZSB0aXRsZSB0byDigJxPU1BGLVRFIEV4dGVuc2lvbiBmb3Ig TGlua3Mgd2l0aCBWYXJpYWJsZSBEaXNjcmV0ZSBCYW5kd2lkdGjigJ0sIHdoYXQgZG8geW91IHRo aW5rPw0KSSB3aWxsIGFsc28gdXBkYXRlIHRoZSB0ZXh0IGluIHRoZSBkcmFmdCBhY2NvcmRpbmds eS4NCg0KQlIsDQpBbXkNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUaGlzIGUt bWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9u IGZyb20gSFVBV0VJLCB3aGljaA0KaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiBvciBl bnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhlDQppbmZv cm1hdGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkgKGluY2x1ZGluZywgYnV0IG5vdCBs aW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsDQpkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIG9y IGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQNCnJlY2lw aWVudChzKSBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZSB0aGlzIGUtbWFpbCBpbiBlcnJv ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5DQpwaG9uZSBvciBlbWFpbCBpbW1lZGlhdGVs eSBhbmQgZGVsZXRlIGl0IQ0KDQpGcm9tOiBUZWFzIFttYWlsdG86dGVhcy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgRGFuaWVsZSBDZWNjYXJlbGxpDQpTZW50OiBGcmlkYXksIE1heSAx MywgMjAxNiA2OjEwIFBNDQpUbzogQWNlZSBMaW5kZW0gKGFjZWUpOyBDQ0FNUCAoY2NhbXBAaWV0 Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPik7IFRFQVMgV0cgKHRlYXNAaWV0Zi5vcmc8bWFp bHRvOnRlYXNAaWV0Zi5vcmc+KQ0KQ2M6IHRlYXMtY2hhaXJzQGlldGYub3JnPG1haWx0bzp0ZWFz LWNoYWlyc0BpZXRmLm9yZz47IGNjYW1wLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86Y2NhbXAtY2hh aXJzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtUZWFzXSBKb2ludCBXRyBsYXN0IGNhbGwgb24g ZHJhZnQtaWV0Zi1vc3BmLWF2YWlsYWJpbGl0eS1leHRlbnNpb24tMDQNCg0KR29vZCBwb2ludCBB Y2VlLg0KDQpJIGFncmVlIHdpdGggeW91IEnigJltIGZpbmUgd2l0aCB1cGRhdGluZyB0aGUgSUQg YWNjb3JkaW5nbHkuDQoNClRoYW5rcw0KRGFuaWVsZQ0KDQpGcm9tOiBBY2VlIExpbmRlbSAoYWNl ZSkgW21haWx0bzphY2VlQGNpc2NvLmNvbV0NClNlbnQ6IGdpb3ZlZMOsIDEyIG1hZ2dpbyAyMDE2 IDEzOjQyDQpUbzogRGFuaWVsZSBDZWNjYXJlbGxpOyBDQ0FNUCAoY2NhbXBAaWV0Zi5vcmc8bWFp bHRvOmNjYW1wQGlldGYub3JnPik7IFRFQVMgV0cgKHRlYXNAaWV0Zi5vcmc8bWFpbHRvOnRlYXNA aWV0Zi5vcmc+KQ0KQ2M6IGNjYW1wLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86Y2NhbXAtY2hhaXJz QGlldGYub3JnPjsgdGVhcy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOnRlYXMtY2hhaXJzQGlldGYu b3JnPg0KU3ViamVjdDogUmU6IFtUZWFzXSBKb2ludCBXRyBsYXN0IGNhbGwgb24gZHJhZnQtaWV0 Zi1vc3BmLWF2YWlsYWJpbGl0eS1leHRlbnNpb24tMDQNCg0KSSByZWFsaXplIGl0IGhhcyBhbHdh eXMgYmVlbiB0aGlzIHdheSBidXQgdGhlIHRlcm1pbm9sb2d5IG9mIHRoZSBkcmFmdCAoaW5jbHVk aW5nIHRoZSB0aXRsZSkgaXMgc29tZXdoYXQgbWlzbGVhZGluZyBhcyB0aGUgZG9lcyBub3QgZXh0 ZW5kIHRoZSBPU1BGIHJvdXRpbmcgcHJvdG9jb2wuIFJhdGhlciwgaXQgIGV4dGVuZHMgdGhlIE9T UEYgR01QTFMgZW5jb2RpbmdzIGFzIGRlZmluZWQgaW4gUkZDIDQyMDMuDQpUaGFua3MsDQpBY2Vl DQoNCkZyb206IFRlYXMgPHRlYXMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dGVhcy1ib3VuY2Vz QGlldGYub3JnPj4gb24gYmVoYWxmIG9mIERhbmllbGUgQ2VjY2FyZWxsaSA8ZGFuaWVsZS5jZWNj YXJlbGxpQGVyaWNzc29uLmNvbTxtYWlsdG86ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNv bT4+DQpEYXRlOiBUaHVyc2RheSwgTWF5IDEyLCAyMDE2IGF0IDQ6MjUgQU0NClRvOiAiQ0NBTVAg KGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4pIiA8Y2NhbXBAaWV0Zi5vcmc8 bWFpbHRvOmNjYW1wQGlldGYub3JnPj4sICJURUFTIFdHICh0ZWFzQGlldGYub3JnPG1haWx0bzp0 ZWFzQGlldGYub3JnPikiIDx0ZWFzQGlldGYub3JnPG1haWx0bzp0ZWFzQGlldGYub3JnPj4NCkNj OiAiY2NhbXAtY2hhaXJzQGlldGYub3JnPG1haWx0bzpjY2FtcC1jaGFpcnNAaWV0Zi5vcmc+IiA8 Y2NhbXAtY2hhaXJzQGlldGYub3JnPG1haWx0bzpjY2FtcC1jaGFpcnNAaWV0Zi5vcmc+PiwgInRl YXMtY2hhaXJzQGlldGYub3JnPG1haWx0bzp0ZWFzLWNoYWlyc0BpZXRmLm9yZz4iIDx0ZWFzLWNo YWlyc0BpZXRmLm9yZzxtYWlsdG86dGVhcy1jaGFpcnNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW1Rl YXNdIEpvaW50IFdHIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLW9zcGYtYXZhaWxhYmlsaXR5LWV4 dGVuc2lvbi0wNA0KDQpDQ0FNUCwgVEVBUywNCg0KVGhpcyBzdGFydHMgYSB0d28gd2Vla3Mgam9p bnQgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1jY2FtcC1vc3BmLWF2YWls YWJpbGl0eS1leHRlbnNpb24tMDQNClRoZSBsYXN0IGNhbGwgZW5kIG9uIFdlZG5lc2RheSBNYXkg MjZ0aC4gUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byBib3RoIHRoZSBDQ0FNUCBhbmQgVEVB UyBtYWlsaW5nIGxpc3RzLg0KDQpBbGwgdGhlIElQUiBkZWNsYXJhdGlvbnMgZnJvbSBhdXRob3Jz IGFuZCBjb250cmlidXRvcnMgaGF2ZSBiZWVuIGNvbGxlY3RlZCBhbmQgY2FuIGJlIGZvdW5kIGlu IHRoZSBoaXN0b3J5IG9mIHRoZSBkb2N1bWVudDogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi1jY2FtcC1vc3BmLWF2YWlsYWJpbGl0eS1leHRlbnNpb24vaGlzdG9y eS8NClBsZWFzZSBub3RlIHRoYXQgbm8gSVBSIHdhcyBkaXNjbG9zZWQgYWdhaW5zdCB0aGlzIGRy YWZ0Lg0KDQpBcyB1c3VhbCB0aGlzIGlzIGFsc28gYSBjYWxsIGZvciBzaGVwaGVyZC4gSWYgYW55 b25lIGlzIHdpbGxpbmcgdG8gYmUgdGhlIHNoZXBoZXJkIG9mIHRoZSBkb2N1bWVudCwgcGxlYXNl IHZvbHVudGVlci4NCg0KDQoNClRoYW5rcw0KDQpEYW5pZWxlLCBGYXRhaSwgTG91LCBQYXZhbg0K DQo= --_000_9C5FD3EFA72E1740A3D41BADDE0B461F9CDB6C9Dszxema506mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNl dGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiLmibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRp di5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9w OjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1s ZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQ2hhcg0KCXttc28t c3R5bGUtbmFtZToi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazrmibnms6jmoYbmlofmnKw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFt ZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7fQ0KcC5CYWxsb29uVGV4dCwgbGkuQmFsbG9vblRleHQsIGRpdi5CYWxsb29uVGV4dA0KCXtt c28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IjsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBU ZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2 MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPkhpIEFjZWUsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHN1Z2dlc3Rpb24sIEkg d2lsbCB1cGRhdGUgdGhlIHRpdGxlIGFzIHlvdSBzdWdnZXN0ZWQuDQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPkJSLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtjb2xvcjojMUY0OTdEIj5BbXk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBj bGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdE Ij4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQt anVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmdyYXkiPlRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgY29udGFp biBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoDQo8YnI+DQppcyBp bnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB3aG9zZSBhZGRyZXNzIGlzIGxp c3RlZCBhYm92ZS4gQW55IHVzZSBvZiB0aGUNCjxicj4NCmluZm9ybWF0aW9uIGNvbnRhaW5lZCBo ZXJlaW4gaW4gYW55IHdheSAoaW5jbHVkaW5nLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9y IHBhcnRpYWwNCjxicj4NCmRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlv bikgYnkgcGVyc29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCA8YnI+DQpyZWNpcGllbnQocykg aXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBieQ0KPGJyPg0KcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkg YW5kIGRlbGV0ZSBpdCE8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBBY2VlIExpbmRlbSAoYWNlZSkgW21h aWx0bzphY2VlQGNpc2NvLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE1heSAzMCwg MjAxNiA3OjQxIFBNPGJyPg0KPGI+VG86PC9iPiBZZW1pbiAoQW15KTsgRGFuaWVsZSBDZWNjYXJl bGxpOyBDQ0FNUCAoY2NhbXBAaWV0Zi5vcmcpOyBURUFTIFdHICh0ZWFzQGlldGYub3JnKTxicj4N CjxiPkNjOjwvYj4gdGVhcy1jaGFpcnNAaWV0Zi5vcmc7IGNjYW1wLWNoYWlyc0BpZXRmLm9yZzxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RlYXNdIEpvaW50IFdHIGxhc3QgY2FsbCBvbiBkcmFm dC1pZXRmLW9zcGYtYXZhaWxhYmlsaXR5LWV4dGVuc2lvbi0wNDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFj ayI+SGkgQW15LCZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtjb2xvcjpibGFjayI+VGhhdCB3b3VsZCBiZSBhY2NlcHRhYmxlLiBIb3dldmVyLCAmbmJz cDtpdCBzZWVtcyB0aGF0IOKAnE9TUEYtVEUgTGluayBBdmFpbGFiaWxpdHkgRXh0ZW5zaW9u4oCd IHdvdWxkIGJlIG1vcmUgYWNjdXJhdGUuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5BY2VlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Ymxh Y2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFj ayI+JnF1b3Q7WWVtaW4gKEFteSkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzphbXkueWVtaW5A aHVhd2VpLmNvbSI+YW15LnllbWluQGh1YXdlaS5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwv Yj5Nb25kYXksIE1heSAzMCwgMjAxNiBhdCA1OjMwIEFNPGJyPg0KPGI+VG86IDwvYj5EYW5pZWxl IENlY2NhcmVsbGkgJmx0OzxhIGhyZWY9Im1haWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nz b24uY29tIj5kYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tPC9hPiZndDssIEFjZWUgTGlu ZGVtICZsdDs8YSBocmVmPSJtYWlsdG86YWNlZUBjaXNjby5jb20iPmFjZWVAY2lzY28uY29tPC9h PiZndDssICZxdW90O0NDQU1QICg8YSBocmVmPSJtYWlsdG86Y2NhbXBAaWV0Zi5vcmciPmNjYW1w QGlldGYub3JnPC9hPikmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpjY2FtcEBpZXRmLm9yZyI+ Y2NhbXBAaWV0Zi5vcmc8L2E+Jmd0OywNCiAmcXVvdDtURUFTIFdHICg8YSBocmVmPSJtYWlsdG86 dGVhc0BpZXRmLm9yZyI+dGVhc0BpZXRmLm9yZzwvYT4pJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86dGVhc0BpZXRmLm9yZyI+dGVhc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4m cXVvdDs8YSBocmVmPSJtYWlsdG86dGVhcy1jaGFpcnNAaWV0Zi5vcmciPnRlYXMtY2hhaXJzQGll dGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRlYXMtY2hhaXJzQGlldGYub3Jn Ij50ZWFzLWNoYWlyc0BpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86Y2Nh bXAtY2hhaXJzQGlldGYub3JnIj5jY2FtcC1jaGFpcnNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86Y2NhbXAtY2hhaXJzQGlldGYub3JnIj5jY2FtcC1jaGFpcnNAaWV0Zi5v cmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SRTogW1RlYXNdIEpvaW50IFdHIGxhc3Qg Y2FsbCBvbiBkcmFmdC1pZXRmLW9zcGYtYXZhaWxhYmlsaXR5LWV4dGVuc2lvbi0wNDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tcmlnaHQ6MGNtIiBpZD0iTUFDX09VVExP T0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjoj MUY0OTdEIj5IaSBBY2VlIGFuZCBEYW5pZWxlLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj5JIHBsYW4gdG8g Y2hhbmdlIHRoZSB0aXRsZSB0byDigJxPU1BGLVRFIEV4dGVuc2lvbiBmb3IgTGlua3Mgd2l0aCBW YXJpYWJsZSBEaXNjcmV0ZSBCYW5kd2lkdGjigJ0sIHdoYXQgZG8geW91IHRoaW5rPzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+SSB3aWxsIGFsc28gdXBkYXRlIHRoZSB0ZXh0IGlu IHRoZSBkcmFmdCBhY2NvcmRpbmdseS4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj5CUiw8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPkFteTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBjbGFz cz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj4N CjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVz dGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmdyYXkiPlRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgY29udGFpbiBj b25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoDQo8YnI+DQppcyBpbnRl bmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB3aG9zZSBhZGRyZXNzIGlzIGxpc3Rl ZCBhYm92ZS4gQW55IHVzZSBvZiB0aGUNCjxicj4NCmluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJl aW4gaW4gYW55IHdheSAoaW5jbHVkaW5nLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBh cnRpYWwNCjxicj4NCmRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikg YnkgcGVyc29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCA8YnI+DQpyZWNpcGllbnQocykgaXMg cHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBieQ0KPGJyPg0KcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkgYW5k IGRlbGV0ZSBpdCE8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiBUZWFzIFs8YSBocmVmPSJtYWlsdG86dGVhcy1ib3Vu Y2VzQGlldGYub3JnIj5tYWlsdG86dGVhcy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJl aGFsZiBPZiA8L2I+RGFuaWVsZSBDZWNjYXJlbGxpPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwg TWF5IDEzLCAyMDE2IDY6MTAgUE08YnI+DQo8Yj5Ubzo8L2I+IEFjZWUgTGluZGVtIChhY2VlKTsg Q0NBTVAgKDxhIGhyZWY9Im1haWx0bzpjY2FtcEBpZXRmLm9yZyI+Y2NhbXBAaWV0Zi5vcmc8L2E+ KTsgVEVBUyBXRyAoPGEgaHJlZj0ibWFpbHRvOnRlYXNAaWV0Zi5vcmciPnRlYXNAaWV0Zi5vcmc8 L2E+KTxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnRlYXMtY2hhaXJzQGlldGYub3Jn Ij50ZWFzLWNoYWlyc0BpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpjY2FtcC1jaGFpcnNA aWV0Zi5vcmciPg0KY2NhbXAtY2hhaXJzQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW1RlYXNdIEpvaW50IFdHIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLW9zcGYtYXZhaWxh YmlsaXR5LWV4dGVuc2lvbi0wNDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Hb29kIHBvaW50IEFjZWUuPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB3aXRoIHlvdSBJ4oCZbSBmaW5l IHdpdGggdXBkYXRpbmcgdGhlIElEIGFjY29yZGluZ2x5Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPlRoYW5rczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkRhbmllbGU8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPiBBY2VlIExpbmRlbSAoYWNlZSkgWzxhIGhyZWY9Im1haWx0bzphY2VlQGNpc2NvLmNv bSI+bWFpbHRvOmFjZWVAY2lzY28uY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBnaW92ZWTD rCAxMiBtYWdnaW8gMjAxNiAxMzo0Mjxicj4NCjxiPlRvOjwvYj4gRGFuaWVsZSBDZWNjYXJlbGxp OyBDQ0FNUCAoPGEgaHJlZj0ibWFpbHRvOmNjYW1wQGlldGYub3JnIj5jY2FtcEBpZXRmLm9yZzwv YT4pOyBURUFTIFdHICg8YSBocmVmPSJtYWlsdG86dGVhc0BpZXRmLm9yZyI+dGVhc0BpZXRmLm9y ZzwvYT4pPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86Y2NhbXAtY2hhaXJzQGlldGYu b3JnIj5jY2FtcC1jaGFpcnNAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86dGVhcy1jaGFp cnNAaWV0Zi5vcmciPg0KdGVhcy1jaGFpcnNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbVGVhc10gSm9pbnQgV0cgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtb3NwZi1hdmFp bGFiaWxpdHktZXh0ZW5zaW9uLTA0PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5JIHJl YWxpemUgaXQgaGFzIGFsd2F5cyBiZWVuIHRoaXMgd2F5IGJ1dCB0aGUgdGVybWlub2xvZ3kgb2Yg dGhlIGRyYWZ0IChpbmNsdWRpbmcgdGhlIHRpdGxlKSBpcyBzb21ld2hhdCBtaXNsZWFkaW5nIGFz IHRoZSBkb2VzIG5vdCBleHRlbmQgdGhlIE9TUEYgcm91dGluZyBwcm90b2NvbC4gUmF0aGVyLCBp dCAmbmJzcDtleHRlbmRzDQogdGhlIE9TUEYgR01QTFMgZW5jb2RpbmdzIGFzIGRlZmluZWQgaW4g UkZDIDQyMDMuJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpi bGFjayI+VGhhbmtzLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6Ymxh Y2siPkFjZWUmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJs YWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 YmxhY2siPlRlYXMgJmx0OzxhIGhyZWY9Im1haWx0bzp0ZWFzLWJvdW5jZXNAaWV0Zi5vcmciPnRl YXMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBEYW5pZWxlIENlY2NhcmVs bGkgJmx0OzxhIGhyZWY9Im1haWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tIj5k YW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+ VGh1cnNkYXksIE1heSAxMiwgMjAxNiBhdCA0OjI1IEFNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtD Q0FNUCAoPGEgaHJlZj0ibWFpbHRvOmNjYW1wQGlldGYub3JnIj5jY2FtcEBpZXRmLm9yZzwvYT4p JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Y2NhbXBAaWV0Zi5vcmciPmNjYW1wQGlldGYub3Jn PC9hPiZndDssICZxdW90O1RFQVMgV0cgKDxhIGhyZWY9Im1haWx0bzp0ZWFzQGlldGYub3JnIj50 ZWFzQGlldGYub3JnPC9hPikmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp0ZWFzQGlldGYub3Jn Ij50ZWFzQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90OzxhIGhyZWY9Im1h aWx0bzpjY2FtcC1jaGFpcnNAaWV0Zi5vcmciPmNjYW1wLWNoYWlyc0BpZXRmLm9yZzwvYT4mcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzpjY2FtcC1jaGFpcnNAaWV0Zi5vcmciPmNjYW1wLWNoYWly c0BpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86dGVhcy1jaGFpcnNAaWV0 Zi5vcmciPnRlYXMtY2hhaXJzQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnRlYXMtY2hhaXJzQGlldGYub3JnIj50ZWFzLWNoYWlyc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0K PGI+U3ViamVjdDogPC9iPltUZWFzXSBKb2ludCBXRyBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1v c3BmLWF2YWlsYWJpbGl0eS1leHRlbnNpb24tMDQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERG IDQuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0IiBpZD0iTUFD X09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPkNDQU1Q LCBURUFTLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6YmxhY2siPlRoaXMgc3RhcnRzIGEgdHdvIHdlZWtzIGpvaW50IHdvcmtpbmcgZ3JvdXAgbGFz dCBjYWxsIG9uIGRyYWZ0LWlldGYtY2NhbXAtb3NwZi1hdmFpbGFiaWxpdHktZXh0ZW5zaW9uLTA0 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIGxhc3QgY2FsbCBlbmQgb24gV2VkbmVzZGF5 IE1heSAyNjxzdXA+dGg8L3N1cD4uIFBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gYm90aCB0 aGUgQ0NBTVAgYW5kIFRFQVMgbWFpbGluZyBsaXN0cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5BbGwgdGhlIElQUiBkZWNsYXJhdGlv bnMgZnJvbSBhdXRob3JzIGFuZCBjb250cmlidXRvcnMgaGF2ZSBiZWVuIGNvbGxlY3RlZCBhbmQg Y2FuIGJlIGZvdW5kIGluIHRoZSBoaXN0b3J5IG9mIHRoZSBkb2N1bWVudDoNCjxhIGhyZWY9Imh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY2NhbXAtb3NwZi1hdmFp bGFiaWxpdHktZXh0ZW5zaW9uL2hpc3RvcnkvIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtY2NhbXAtb3NwZi1hdmFpbGFiaWxpdHktZXh0ZW5zaW9uL2hpc3Rv cnkvPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPlBsZWFzZSBub3RlIHRoYXQgbm8gSVBS IHdhcyBkaXNjbG9zZWQgYWdhaW5zdCB0aGlzIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPkFzIHVzdWFsIHRoaXMgaXMgYWxz byBhIGNhbGwgZm9yIHNoZXBoZXJkLiBJZiBhbnlvbmUgaXMgd2lsbGluZyB0byBiZSB0aGUgc2hl cGhlcmQgb2YgdGhlIGRvY3VtZW50LCBwbGVhc2Ugdm9sdW50ZWVyLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+ VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPkRhbmllbGUsIEZhdGFpLCBM b3UsIFBhdmFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9C5FD3EFA72E1740A3D41BADDE0B461F9CDB6C9Dszxema506mbschi_--

On Fri, May 13, 2016 at 8:15 PM, Vishnu Pav= an Beeram <vishnupavan@gmail.com> wrote:
The WG LC for this document i= s now closed.

Matt (and other authors),
Please go ahead and= publish a new revision addressing the minor comments received during the L= C.

Regards,
-Pavan (and Lou)

On Fri, May 13, 2016 at 6:07 PM, Shah, Himanshu <hsh= ah@ciena.com> wrote:

Sorry for the late reply.. (On PTO..)<= /span>

=C2=A0=

While= adding of =E2=80=9Ccompletion flag=E2=80=9D (or similar to =E2=80=9Cpartia= l bit=E2=80=9D used in BGP) would have been a nice feature

to have, the SR= LG collect draft by itself is an important feature to have, so..<= /u>

= =C2=A0

I support progressing the document to publication.

=C2=A0

Thanks,

Himanshu

=C2=A0

From: Teas [mailto:teas-bounces@ietf.org] On = Behalf Of Vishnu Pavan Beeram
Sent: Thursday, April 28, 2016 = 4:42 PM
To: teas@ietf.org
Subject: [Teas] WG Last Call on draft-ietf-= teas-rsvp-te-srlg-collect-05

=C2=A0

All,


This starts a two week working g= roup last call on
draft-ietf-teas-rsvp-te-srlg-collect-05.

The wo= rking group last call ends on Thursday, May 12th. Please
send your comme= nts to the TEAS mailing list.

As is always the case, positive commen= ts, e.g., "I've reviewed this
document and believe it is ready = for publication", are welcome!
This is useful and important, even f= rom authors.

Note, IPR has been disclosed on this draft.

=


Thanks,
Pavan (and Lou)