From tang.kexin@zte.com.cn Tue Nov 1 00:34:21 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84DD21F8FAC for ; Tue, 1 Nov 2011 00:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.751 X-Spam-Level: X-Spam-Status: No, score=-96.751 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxmgQK3gHpuP for ; Tue, 1 Nov 2011 00:34:20 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 0783421F8F9E for ; Tue, 1 Nov 2011 00:34:19 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 566901441414862; Tue, 1 Nov 2011 14:55:16 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 20387.1441414862; Tue, 1 Nov 2011 15:03:57 +0800 (CST) Received: (from root@localhost) by mse01.zte.com.cn id pA173oug059059 for ; Tue, 1 Nov 2011 15:03:50 +0800 (GMT-8) (envelope-from tang.kexin@zte.com.cn) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id pA171kHj056409 for ; Tue, 1 Nov 2011 15:01:46 +0800 (GMT-8) (envelope-from tang.kexin@zte.com.cn) Message-Id: <201111010703.pA173oug059059@mse01.zte.com.cn> To: pce@ietf.org MIME-Version: 1.0 X-KeepSent: 2706FEB9:5260FBC7-4825793B:00245062; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 From: tang.kexin@zte.com.cn Date: Tue, 1 Nov 2011 15:01:43 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-11-01 15:01:48, Serialize complete at 2011-11-01 15:01:48 Content-Type: multipart/alternative; boundary="=_alternative 0026DF074825793B_=" X-MAIL: mse01.zte.com.cn pA173oug059059 X-MSS: AUDITRELEASE@mse01.zte.com.cn Subject: [Pce] Seeking comments on I-D "draft-tang-pce-stateful-pce-02.txt" X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 07:34:21 -0000 This is a multipart message in MIME format. --=_alternative 0026DF074825793B_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgUENFZXJzDQoNCldlIGhhZCBwcmVzZW50ZWQgIlN0YXRlZnVsIFBDRSIgSS1EIGF0IElFVEY3 OSxhbmQgcmVjZW50bHkgd2UgdXBkYXRlZCBpdCANCnRvIDAyIHZlcnNpb24gW2h0dHA6Ly93d3cu aWV0Zi5vcmcvaWQvZHJhZnQtdGFuZy1wY2Utc3RhdGVmdWwtcGNlLTAyLnR4dF0NCg0KVGhpcyBk b2N1bWVudCBpcyBhYm91dCB0aGUgc3RhdGVmdWwgUENFLCB3aGljaCBkZWZpbmVzIGEgc3luY2hy b25pemF0aW9uIA0KbWVjaGFuaXNtIA0KIHRvIG5vdGlmeSB0aGUgc3RhdGUgb2YgYSBMU1AuRmly c3RseSB0aGUgUENDIGFuZCBQQ0UgbmVnb3RpYXRlIHdoZXRoZXIgDQp0aGV5IGJvdGggc3VwcG9y dCANCnN0YXRlZnVsIFBDRSAsIHRoZW4gdXNlIHRoZSBzeW5jaHJvbml6YXRpb24gbWVjaGFuaXNt IGRlZmluZWQgaW4gdGhpcyANCmRyYWZ0LiANCg0KV2UgKHRoZSBhdXRob3JzKSBhcmUgc2Vla2lu ZyBtb3JlIGZlZWRiYWNrIGZyb20gdGhlIG1haWxpbmcgbGlzdCwgYW5kIA0Kd291bGQNCmJlIGdy YXRlZnVsIGlmIHlvdSBjb3VsZCByZXZpZXcgdGhlIGRvY3VtZW50IGFuZCBwb3N0IGNvbW1lbnRz IG9uIHRoZQ0KbWFpbGluZyBsaXN0Lg0KDQpCZXN0IHJlZ2FyZHMgDQoNClRoZSBhdXRob3JzIA0K DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CktleGluIFRhbmcNCkNvbnRyb2wgUGxhbmUgRW5naW5lZXINClpURSBDb3Jwb3JhdGlvbiANCg0K YWRkcmVzczogTm8uNTAgU29mdHdhcmUgQXZlbnVlLCBZdWh1YXRhaSBEaXN0cmljdCwNCiAgICAg ICAgIE5hbmppbmcsSmlhbmdzdSwgUC5SLkNoaW5hLDIxMDAxMg0KcGhvbmU6ICAgMTM4MTU4NzEy MDYNCmVtYWlsOiAgIHRhbmcua2V4aW5AenRlLmNvbS5jbg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQotLS0tLSDXqreiyMsgzMa/ydDEICDK sbzkIDIwMTEtMTEtMDEgMTQ6MDAgLS0tLS0NCg0KaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIA0K MjAxMS0xMC0zMSAxOToxOQ0KDQrK1bz+yMsNCnRhbmcua2V4aW5AenRlLmNvbS5jbg0Ks63LzQ0K Y2FvLnh1cGluZ0B6dGUuY29tLmNuLCB0YW5nLmtleGluQHp0ZS5jb20uY24sIHdhbmcueHVlcm9u Z0B6dGUuY29tLmNuDQrW98ziDQpOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXRh bmctcGNlLXN0YXRlZnVsLXBjZS0wMi50eHQNCg0KDQoNCg0KDQoNCkEgbmV3IHZlcnNpb24gb2Yg SS1ELCBkcmFmdC10YW5nLXBjZS1zdGF0ZWZ1bC1wY2UtMDIudHh0IGhhcyBiZWVuIA0Kc3VjY2Vz c2Z1bGx5IHN1Ym1pdHRlZCBieSBLZXhpbiBUYW5nIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVw b3NpdG9yeS4NCg0KRmlsZW5hbWU6ICAgICAgICAgICAgICAgICBkcmFmdC10YW5nLXBjZS1zdGF0 ZWZ1bC1wY2UNClJldmlzaW9uOiAgICAgICAgICAgICAgICAgMDINClRpdGxlOiAgICAgICAgICAg ICAgICAgICAgICAgICAgICBTdGF0ZWZ1bCBQQ0UNCkNyZWF0aW9uIGRhdGU6ICAgICAgICAgICAg MjAxMS0xMC0zMQ0KV0cgSUQ6ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEluZGl2aWR1YWwg U3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiA5DQoNCkFic3RyYWN0Og0KICAgQSBQQ0UgY2Fu IGJlIGVpdGhlciBzdGF0ZWZ1bCBvciBzdGF0ZWxlc3MuICBUaGUgaW5mb3JtYXRpb24gY2Fycmll ZA0KICAgaW4gYSBzdGF0ZWZ1bCBQQ0UgaXMgbW9yZSBkZXRhaWxlZCB0aGFuIHRoYXQgb2YgYSBz dGF0ZWxlc3MgUENFLg0KICAgVGhpcyBkcmFmdCBmb2N1cyBvbiBzdGF0ZWZ1bCBQQ0UsIGRlc2Ny aWJlcyB0aGUgcHJvYmxlbXMgd2l0aG91dA0KICAgc3RhdGVmdWwgUENFLCBhbmQgZ2l2ZXMgdGhl IElHUCBhbmQgUENFUCBleHRlbnNpb25zIHRvIHJlYWxpemUNCiAgIHN0YXRlZnVsIFBDRS4NCg0K ICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24g U2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBp cyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWls IGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFy ZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8g ZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpU aGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50 aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3Ig ZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1l c3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0 aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3Ig dmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 0026DF074825793B_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IkBBcmlhbCBVbmljb2RlIE1TIj5IaSBQQ0VlcnM8L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IkBBcmlhbCBVbmljb2RlIE1TIj5XZSBo YWQgcHJlc2VudGVkICZxdW90O1N0YXRlZnVsDQpQQ0UmcXVvdDsgSS1EIGF0IElFVEY3OSxhbmQg cmVjZW50bHkgd2UgdXBkYXRlZCBpdCAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZh Y2U9IkBBcmlhbCBVbmljb2RlIE1TIj50byAwMiB2ZXJzaW9uIFs8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGNvbG9yPWJsdWUgZmFjZT0iQEFyaWFsIFVuaWNvZGUgTVMiPmh0dHA6Ly93d3cuaWV0Zi5vcmcv aWQvZHJhZnQtdGFuZy1wY2Utc3RhdGVmdWwtcGNlLTAyLnR4dDwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0iQEFyaWFsIFVuaWNvZGUgTVMiPl08L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0z IGZhY2U9IkBBcmlhbCBVbmljb2RlIE1TIj5UaGlzIGRvY3VtZW50IGlzIGFib3V0IHRoZSBzdGF0 ZWZ1bA0KUENFLCB3aGljaCBkZWZpbmVzIGEgc3luY2hyb25pemF0aW9uIDwvZm9udD48YSBocmVm PWFwcDpkczptZWNoYW5pc20gdGFyZ2V0PV9zZWxmPjxmb250IHNpemU9MyBmYWNlPSJAQXJpYWwg VW5pY29kZSBNUyI+bWVjaGFuaXNtPC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0iQEFyaWFs IFVuaWNvZGUgTVMiPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJAQXJpYWwgVW5p Y29kZSBNUyI+Jm5ic3A7dG8gbm90aWZ5IHRoZSBzdGF0ZSBvZg0KYSBMU1AuRmlyc3RseSB0aGUg UENDIGFuZCBQQ0UgbmVnb3RpYXRlIHdoZXRoZXIgdGhleSBib3RoIHN1cHBvcnQgPC9mb250Pg0K PGJyPjxmb250IHNpemU9MyBmYWNlPSJAQXJpYWwgVW5pY29kZSBNUyI+c3RhdGVmdWwgUENFICwg dGhlbiB1c2UgdGhlIHN5bmNocm9uaXphdGlvbg0KPC9mb250PjxhIGhyZWY9YXBwOmRzOm1lY2hh bmlzbSB0YXJnZXQ9X3NlbGY+PGZvbnQgc2l6ZT0zIGZhY2U9IkBBcmlhbCBVbmljb2RlIE1TIj5t ZWNoYW5pc208L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJAQXJpYWwgVW5pY29kZSBNUyI+ DQpkZWZpbmVkIGluIHRoaXMgZHJhZnQuIDxicj4NCjxicj4NCldlICh0aGUgYXV0aG9ycykgYXJl IHNlZWtpbmcgbW9yZSBmZWVkYmFjayBmcm9tIHRoZSBtYWlsaW5nIGxpc3QsIGFuZCB3b3VsZDxi cj4NCmJlIGdyYXRlZnVsIGlmIHlvdSBjb3VsZCByZXZpZXcgdGhlIGRvY3VtZW50IGFuZCBwb3N0 IGNvbW1lbnRzIG9uIHRoZTxicj4NCm1haWxpbmcgbGlzdC48YnI+DQo8YnI+DQpCZXN0IHJlZ2Fy ZHMgPGJyPg0KPGJyPg0KVGhlIGF1dGhvcnMgPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08YnI+DQpLZXhpbiBUYW5nPGJyPg0KQ29udHJvbCBQbGFuZSBFbmdp bmVlcjxicj4NClpURSBDb3Jwb3JhdGlvbiA8YnI+DQo8YnI+DQphZGRyZXNzOiBOby41MCBTb2Z0 d2FyZSBBdmVudWUsIFl1aHVhdGFpIERpc3RyaWN0LDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgTmFuamluZyxKaWFuZ3N1LCBQLlIuQ2hpbmEsMjEwMDEyPGJyPg0KcGhvbmU6ICZu YnNwOyAxMzgxNTg3MTIwNjxicj4NCmVtYWlsOiAmbmJzcDsgdGFuZy5rZXhpbkB6dGUuY29tLmNu PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0jODAwMDgwIGZhY2U9InNhbnMtc2Vy aWYiPi0tLS0tINeqt6LIyyDMxr/J0MQNCiZuYnNwO8qxvOQgMjAxMS0xMS0wMSAxNDowMCAtLS0t LTwvZm9udD4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQg d2lkdGg9MzUlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5pbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+MjAxMS0xMC0zMSAxOToxOTwvZm9udD4NCjx0ZCB3aWR0aD02NCU+DQo8dGFibGUgd2lkdGg9 MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj50YW5nLmtleGluQHp0ZS5jb20uY248L2ZvbnQ+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPmNhby54dXBpbmdAenRlLmNvbS5jbiwgdGFuZy5rZXhpbkB6dGUuY29tLmNuLA0Kd2FuZy54 dWVyb25nQHp0ZS5jb20uY248L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxp Z249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+ DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPk5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtdGFuZy1wY2Utc3RhdGVmdWwtcGNlLTAyLnR4dDwvZm9udD48L3RhYmxl Pg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxi cj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+QSBuZXcgdmVyc2lv biBvZiBJLUQsIGRyYWZ0LXRhbmctcGNlLXN0YXRlZnVsLXBjZS0wMi50eHQNCmhhcyBiZWVuIHN1 Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgS2V4aW4gVGFuZyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRG IHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KRmlsZW5hbWU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwO2RyYWZ0LXRhbmctcGNlLXN0 YXRlZnVsLXBjZTxicj4NClJldmlzaW9uOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDswMjxicj4NClRpdGxlOiAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KU3Rh dGVmdWwgUENFPGJyPg0KQ3JlYXRpb24gZGF0ZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7MjAxMS0xMC0zMTxicj4NCldHIElE OiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOw0KSW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyPg0KTnVtYmVyIG9mIHBhZ2VzOiA5PGJy Pg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KICZuYnNwOyBBIFBDRSBjYW4gYmUgZWl0aGVyIHN0YXRl ZnVsIG9yIHN0YXRlbGVzcy4gJm5ic3A7VGhlIGluZm9ybWF0aW9uDQpjYXJyaWVkPGJyPg0KICZu YnNwOyBpbiBhIHN0YXRlZnVsIFBDRSBpcyBtb3JlIGRldGFpbGVkIHRoYW4gdGhhdCBvZiBhIHN0 YXRlbGVzcyBQQ0UuPGJyPg0KICZuYnNwOyBUaGlzIGRyYWZ0IGZvY3VzIG9uIHN0YXRlZnVsIFBD RSwgZGVzY3JpYmVzIHRoZSBwcm9ibGVtcyB3aXRob3V0PGJyPg0KICZuYnNwOyBzdGF0ZWZ1bCBQ Q0UsIGFuZCBnaXZlcyB0aGUgSUdQIGFuZCBQQ0VQIGV4dGVuc2lvbnMgdG8gcmVhbGl6ZTxicj4N CiAmbmJzcDsgc3RhdGVmdWwgUENFLjxicj4NCjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0KPGJyPg0KPGJyPg0K VGhlIElFVEYgU2VjcmV0YXJpYXQ8YnI+DQo8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48 cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5i c3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMm bmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7 dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwm bmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBp ZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0 byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZu YnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50 cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVy cy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJh bnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJz cDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3Vz ZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5i c3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJ ZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZu YnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtv cmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3Zp ZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2Fy ZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVy Lg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNw O2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJz cDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 0026DF074825793B_=-- From Dave.Cooper@Level3.com Tue Nov 1 23:02:09 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B2F11E8085 for ; Tue, 1 Nov 2011 23:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.604 X-Spam-Level: X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[AWL=0.995, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3vRNb1RslbS for ; Tue, 1 Nov 2011 23:02:09 -0700 (PDT) Received: from mailsrv-det.globalcrossing.com (mailsrv-det.globalcrossing.com [64.208.159.232]) by ietfa.amsl.com (Postfix) with ESMTP id 043B711E80B1 for ; Tue, 1 Nov 2011 23:02:08 -0700 (PDT) Received: from w3uspdyvs212.ams.gblxint.com (w3uspdyvs212.ams.gblxint.com [10.60.54.213]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id D26C1A372; Wed, 2 Nov 2011 02:02:02 -0400 (EDT) Received: from w3uspdyvs241.ams.gblxint.com ([10.60.54.202]) by w3uspdyvs212.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Nov 2011 01:59:00 -0400 Received: from w8uspdyvs14.ams.gblxint.com (10.60.64.82) by w3uspdyvs241.ams.gblxint.com (10.60.54.202) with Microsoft SMTP Server (TLS) id 8.3.159.2; Wed, 2 Nov 2011 01:58:59 -0400 Received: from W8USPDY131.ams.gblxint.com ([10.60.51.86]) by w8uspdyvs14.ams.gblxint.com ([fe80::c1cf:3337:9866:feff%11]) with mapi id 14.01.0289.001; Wed, 2 Nov 2011 01:58:59 -0400 From: "Cooper, Dave" To: Jan Medved , "pce@ietf.org" Thread-Topic: New Version Notification for draft-crabbe-pce-stateful-pce-01.txt Thread-Index: AcyXmvDG1wYF5mSSRkmPcXuE0CJKSABhua9Q Date: Wed, 2 Nov 2011 05:58:58 +0000 Message-ID: <949A8A83ECD6D24395E1762F14487C8F080273FF@w8uspdy131.ams.gblxint.com> References: <20111031065020.28833.69830.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [207.218.55.124] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Nov 2011 05:59:00.0785 (UTC) FILETIME=[84817210:01CC9924] Subject: Re: [Pce] New Version Notification for draft-crabbe-pce-stateful-pce-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 06:02:09 -0000 Hi Jan,=20 I'd like to express my support for this draft. One note; In the 3.1.2.3 Deadlock section, the first paragraph is a little confusing.= I'm unsure why the behavior is not desirable given the explanations made= . Do you mean that attempts to signal a LSP's bandwidth increase, for a gi= ven priority, may lead to sub-optimal allocation of "global" resources if t= he reservations of existing LSPs already signaled are not taken into accoun= t? Thanks, Dave > -----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of > Jan Medved > Sent: Monday, October 31, 2011 12:02 AM > To: pce@ietf.org > Subject: [Pce] FW: New Version Notification for draft-crabbe-pce-stateful= - > pce-01.txt >=20 > Hello, >=20 > We submitted a new version of the Stateful PCE draft, where we addressed > comments / suggestions from reviewers on the mailing list - many thanks t= o > all who reviewed & commented. >=20 > We to hope to have a good discussion of the draft in Taipei. >=20 >=20 > Thanks, > Ed+Jan+Robert >=20 >=20 >=20 >=20 > On 10/30/11 11:50 PM, "internet-drafts@ietf.org" > wrote: >=20 > >A new version of I-D, draft-crabbe-pce-stateful-pce-01.txt has been > >successfully submitted by Jan Medved and posted to the IETF repository. > > > >Filename: draft-crabbe-pce-stateful-pce > >Revision: 01 > >Title: PCEP Extensions for Stateful PCE > >Creation date: 2011-10-30 > >WG ID: Individual Submission > >Number of pages: 41 > > > >Abstract: > > The Path Computation Element Communication Protocol (PCEP) provides > > mechanisms for Path Computation Elements (PCEs) to perform path > > computations in response to Path Computation Clients (PCCs) requests. > > > > Although PCEP explicitly makes no assumptions regarding the > > information available to the PCE, it also makes no provisions for > > synchronization or PCE control of timing and sequence of path > > computations within and across PCEP sessions. This document > > describes a set of extensions to PCEP to enable this functionality, > > providing stateful control of Multiprotocol Label Switching (MPLS) > > Traffic Engineering Label Switched Paths (TE LSP) via PCEP. > > > > > > > > > > > > > >The IETF Secretariat >=20 > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From edc@google.com Tue Nov 1 23:31:06 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE3D11E8097 for ; Tue, 1 Nov 2011 23:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cozhQ6NEaSVR for ; Tue, 1 Nov 2011 23:31:06 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id E080511E8083 for ; Tue, 1 Nov 2011 23:31:05 -0700 (PDT) Received: by gye5 with SMTP id 5so638395gye.31 for ; Tue, 01 Nov 2011 23:31:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=BYxFUzhka8cEtwSbFv0xeC8IWOnpIiXvHcvXXSZBHeI=; b=psPZw0txKDGk8vkH+ydWtN2479Kj5eUYhu+f9hcn3e9uZV6tQizsgGbHZ3oLJEb0M4 2iAa4QePNYhXv+zyhVWw== Received: by 10.150.32.12 with SMTP id f12mr4201636ybf.66.1320215465267; Tue, 01 Nov 2011 23:31:05 -0700 (PDT) Received: by 10.150.32.12 with SMTP id f12mr4201618ybf.66.1320215465109; Tue, 01 Nov 2011 23:31:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.178.16 with HTTP; Tue, 1 Nov 2011 23:30:44 -0700 (PDT) In-Reply-To: <949A8A83ECD6D24395E1762F14487C8F080273FF@w8uspdy131.ams.gblxint.com> References: <20111031065020.28833.69830.idtracker@ietfa.amsl.com> <949A8A83ECD6D24395E1762F14487C8F080273FF@w8uspdy131.ams.gblxint.com> From: Edward Crabbe Date: Tue, 1 Nov 2011 23:30:44 -0700 Message-ID: To: "Cooper, Dave" Content-Type: multipart/alternative; boundary=000e0cd359fed32be404b0ba9d8d X-System-Of-Record: true Cc: "pce@ietf.org" Subject: Re: [Pce] New Version Notification for draft-crabbe-pce-stateful-pce-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 06:31:06 -0000 --000e0cd359fed32be404b0ba9d8d Content-Type: text/plain; charset=ISO-8859-1 Dave, Thanks, good catch - we're actually trying to say that the behavior is specified in 3209 AND is desirable for the reasons given. We will correct the text. cheers, -ed On Tue, Nov 1, 2011 at 10:58 PM, Cooper, Dave wrote: > Hi Jan, > I'd like to express my support for this draft. > > One note; > > In the 3.1.2.3 Deadlock section, the first paragraph is a little > confusing. I'm unsure why the behavior is not desirable given the > explanations made. Do you mean that attempts to signal a LSP's bandwidth > increase, for a given priority, may lead to sub-optimal allocation of > "global" resources if the reservations of existing LSPs already signaled > are not taken into account? > > Thanks, > Dave > > > > -----Original Message----- > > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of > > Jan Medved > > Sent: Monday, October 31, 2011 12:02 AM > > To: pce@ietf.org > > Subject: [Pce] FW: New Version Notification for > draft-crabbe-pce-stateful- > > pce-01.txt > > > > Hello, > > > > We submitted a new version of the Stateful PCE draft, where we addressed > > comments / suggestions from reviewers on the mailing list - many thanks > to > > all who reviewed & commented. > > > > We to hope to have a good discussion of the draft in Taipei. > > > > > > Thanks, > > Ed+Jan+Robert > > > > > > > > > > On 10/30/11 11:50 PM, "internet-drafts@ietf.org" > > wrote: > > > > >A new version of I-D, draft-crabbe-pce-stateful-pce-01.txt has been > > >successfully submitted by Jan Medved and posted to the IETF repository. > > > > > >Filename: draft-crabbe-pce-stateful-pce > > >Revision: 01 > > >Title: PCEP Extensions for Stateful PCE > > >Creation date: 2011-10-30 > > >WG ID: Individual Submission > > >Number of pages: 41 > > > > > >Abstract: > > > The Path Computation Element Communication Protocol (PCEP) provides > > > mechanisms for Path Computation Elements (PCEs) to perform path > > > computations in response to Path Computation Clients (PCCs) requests. > > > > > > Although PCEP explicitly makes no assumptions regarding the > > > information available to the PCE, it also makes no provisions for > > > synchronization or PCE control of timing and sequence of path > > > computations within and across PCEP sessions. This document > > > describes a set of extensions to PCEP to enable this functionality, > > > providing stateful control of Multiprotocol Label Switching (MPLS) > > > Traffic Engineering Label Switched Paths (TE LSP) via PCEP. > > > > > > > > > > > > > > > > > > > > >The IETF Secretariat > > > > _______________________________________________ > > Pce mailing list > > Pce@ietf.org > > https://www.ietf.org/mailman/listinfo/pce > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > --000e0cd359fed32be404b0ba9d8d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dave,


Thanks, good catch - we're= actually trying to say that the behavior is specified in 3209 AND is desir= able for the reasons given. =A0We will correct the text.

cheers,

=A0 -ed =A0

On Tue, Nov 1, 2011 at 10:58 PM, Cooper, Dave <Dave.Cooper@level3.com<= /a>> wrote:
Hi Jan,
I'd like to express my support for this draft.

One note;

In the 3.1.2.3 Deadlock section, the first paragraph is a little confusing.= =A0 I'm unsure why the behavior is not desirable given the explanation= s made. =A0Do you mean that attempts to signal a LSP's bandwidth increa= se, for a given priority, may lead to sub-optimal allocation of "globa= l" resources if the reservations of existing LSPs already signaled are= not taken into account?

Thanks,
Dave


> -----Original Message-----
> From: pce-bounces@ietf.org= [mailto:pce-bounces@ietf.org] = On Behalf Of
> Jan Medved
> Sent: Monday, October 31, 2011 12:02 AM
> To: pce@ietf.org
> Subject: [Pce] FW: New Version Notification for draft-crabbe-pce-state= ful-
> pce-01.txt
>
> Hello,
>
> We submitted a new version of the Stateful PCE draft, where we address= ed
> comments / suggestions from reviewers on the mailing list - many thank= s to
> all who reviewed & commented.
>
> We to hope to have a good discussion of the draft in Taipei.
>
>
> Thanks,
> Ed+Jan+Robert
>
>
>
>
> On 10/30/11 11:50 PM, "internet-drafts@ietf.org"
> <internet-drafts@ietf.o= rg> wrote:
>
> >A new version of I-D, draft-crabbe-pce-stateful-pce-01.txt has bee= n
> >successfully submitted by Jan Medved and posted to the IETF reposi= tory.
> >
> >Filename: =A0 =A0 draft-crabbe-pce-stateful-pce
> >Revision: =A0 =A0 01
> >Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0PCEP Extensions for Stateful= PCE
> >Creation date: =A0 =A0 =A0 =A02011-10-30
> >WG ID: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Individual Submission
> >Number of pages: 41
> >
> >Abstract:
> > =A0 The Path Computation Element Communication Protocol (PCEP) pr= ovides
> > =A0 mechanisms for Path Computation Elements (PCEs) to perform pa= th
> > =A0 computations in response to Path Computation Clients (PCCs) r= equests.
> >
> > =A0 Although PCEP explicitly makes no assumptions regarding the > > =A0 information available to the PCE, it also makes no provisions= for
> > =A0 synchronization or PCE control of timing and sequence of path=
> > =A0 computations within and across PCEP sessions. =A0This documen= t
> > =A0 describes a set of extensions to PCEP to enable this function= ality,
> > =A0 providing stateful control of Multiprotocol Label Switching (= MPLS)
> > =A0 Traffic Engineering Label Switched Paths (TE LSP) via PCEP. > >
> >
> >
> >
> >
> >
> >The IETF Secretariat
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce

--000e0cd359fed32be404b0ba9d8d-- From tang.kexin@zte.com.cn Tue Nov 1 23:50:10 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8358711E80B1 for ; Tue, 1 Nov 2011 23:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.872 X-Spam-Level: X-Spam-Status: No, score=-96.872 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjFjIkRmG20F for ; Tue, 1 Nov 2011 23:50:09 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id D3C2C21F9F00 for ; Tue, 1 Nov 2011 23:50:08 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 566901441414862; Wed, 2 Nov 2011 14:40:54 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 28253.1441414862; Wed, 2 Nov 2011 14:49:37 +0800 (CST) Received: (from root@localhost) by mse01.zte.com.cn id pA26nkOR062708 for ; Wed, 2 Nov 2011 14:49:46 +0800 (GMT-8) (envelope-from tang.kexin@zte.com.cn) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id pA26mDK7060599; Wed, 2 Nov 2011 14:48:13 +0800 (GMT-8) (envelope-from tang.kexin@zte.com.cn) Message-Id: <201111020649.pA26nkOR062708@mse01.zte.com.cn> In-Reply-To: <949A8A83ECD6D24395E1762F14487C8F080273FF@w8uspdy131.ams.gblxint.com> To: edc@google.com, jmedved@juniper.net, rvarga@juniper.net MIME-Version: 1.0 X-KeepSent: BB6D2E1E:86BC0D81-4825793C:002354C4; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 From: tang.kexin@zte.com.cn Date: Wed, 2 Nov 2011 14:48:06 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-11-02 14:48:14, Serialize complete at 2011-11-02 14:48:14 Content-Type: multipart/related; boundary="=_related 0025A1A84825793C_=" X-MAIL: mse01.zte.com.cn pA26nkOR062708 X-MSS: AUDITRELEASE@mse01.zte.com.cn Cc: "pce@ietf.org" Subject: [Pce] =?gb2312?b?tPC4tDogUmU6ICBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g?= =?gb2312?b?Zm9yIGRyYWZ0LWNyYWJiZS1wY2Utc3RhdGVmdWwtcGNlLTAxLnR4dA==?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 06:50:10 -0000 This is a multipart message in MIME format. --=_related 0025A1A84825793C_= Content-Type: multipart/alternative; boundary="=_alternative 0025A1AA4825793C_=" --=_alternative 0025A1AA4825793C_= Content-Type: text/plain; charset="US-ASCII" Dear Authors, I have reviewed your draft, the motivation described in 3.1.2 is very reasonable. I have a question. Do you make the assumption in your examples that there is no sufficient network resource for all the LSPs to be set up? We updated our "stateful PCE" I-D recently. http://tools.ietf.org/html/draft-tang-pce-stateful-pce-02 I think we are considering the same following problems. 1. Why stateful PCE is important? 2. How to realize stateful PCE? For the 1st problem, as I mentioned above, your consideration may mainly focus on the scenario where network resources is insufficient. Our motivation is mainly to the condition that the network capacity is enougy for all the LSPs to be set up. Our objective is to avoid resources conflict because lack of the state of LSPs. Take the follow demonstration topology for example. Link capacity of A-B / B-C / A-C: 100M Bandwidth demond: LSP 1 needs 80M. LSP2 needs 80M. Source and destination of LSP1 and LSP2: Both of them is from A to B. T1: PCE computed the shortest path for LSP1 : A-B (computation result did not synchronized with PCE) T2: PCE computed the shortest path for LSP2 : A-B (PCE assume the unreserved bandwidth of A-B is still 100M, although is 20M in fact) T3: LSP1 set up successful by signaling T4: LSP2 failed to set up by signaling (no sufficient link capacity aviable on link A-B) I think the objective of the two draft are the same that stateful PCE synchronized with the state of LSPs although by different mechanism. You defined two new PCEP messages (PCRpt and PCUpd), while we extended the existing PCNtf message. Thanks, Kexin > -----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of > Jan Medved > Sent: Monday, October 31, 2011 12:02 AM > To: pce@ietf.org > Subject: [Pce] FW: New Version Notification for draft-crabbe-pce-stateful- > pce-01.txt > > Hello, > > We submitted a new version of the Stateful PCE draft, where we addressed > comments / suggestions from reviewers on the mailing list - many thanks to > all who reviewed & commented. > > We to hope to have a good discussion of the draft in Taipei. > > > Thanks, > Ed+Jan+Robert > > > > > On 10/30/11 11:50 PM, "internet-drafts@ietf.org" > wrote: > > >A new version of I-D, draft-crabbe-pce-stateful-pce-01.txt has been > >successfully submitted by Jan Medved and posted to the IETF repository. > > > >Filename: draft-crabbe-pce-stateful-pce > >Revision: 01 > >Title: PCEP Extensions for Stateful PCE > >Creation date: 2011-10-30 > >WG ID: Individual Submission > >Number of pages: 41 > > > >Abstract: > > The Path Computation Element Communication Protocol (PCEP) provides > > mechanisms for Path Computation Elements (PCEs) to perform path > > computations in response to Path Computation Clients (PCCs) requests. > > > > Although PCEP explicitly makes no assumptions regarding the > > information available to the PCE, it also makes no provisions for > > synchronization or PCE control of timing and sequence of path > > computations within and across PCEP sessions. This document > > describes a set of extensions to PCEP to enable this functionality, > > providing stateful control of Multiprotocol Label Switching (MPLS) > > Traffic Engineering Label Switched Paths (TE LSP) via PCEP. > > > > > > > > > > > > > >The IETF Secretariat > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0025A1AA4825793C_= Content-Type: text/html; charset="US-ASCII"
Dear Authors,

I have reviewed your draft, the motivation described in 3.1.2 is very reasonable.
I have a question. Do you make the assumption in your examples that there is no sufficient network resource for all the LSPs to be set up?

We updated our "stateful PCE" I-D recently. http://tools.ietf.org/html/draft-tang-pce-stateful-pce-02
I think we are considering the same following problems.
1. Why stateful PCE is important?
2. How to realize stateful PCE?

For the 1st problem, as I mentioned above, your consideration may mainly focus on the scenario where network resources is insufficient.
Our motivation is mainly to the condition that the network capacity is enougy for all the LSPs to be set up.
Our objective is to avoid resources conflict because lack of the state of LSPs.
Take the follow demonstration topology for example.

         

Link capacity of A-B / B-C / A-C:  100M
Bandwidth demond: LSP 1 needs 80M. LSP2 needs 80M.
Source and destination of LSP1 and LSP2: Both of them is from A to B.
T1: PCE computed the shortest path for LSP1 : A-B (computation result did not synchronized with PCE)
T2: PCE computed the shortest path for LSP2 : A-B (PCE assume the unreserved bandwidth of A-B is still 100M, although is 20M in fact)
T3: LSP1 set up successful by signaling
T4: LSP2 failed to set up by signaling (no sufficient link capacity aviable on link A-B)

I think the objective of the two draft are the same that stateful PCE synchronized with the state of LSPs although by different mechanism.
You defined two new PCEP messages (PCRpt and PCUpd), while we extended the existing PCNtf message.

Thanks,
Kexin

> -----Original Message-----
> From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of
> Jan Medved
> Sent: Monday, October 31, 2011 12:02 AM
> To: pce@ietf.org
> Subject: [Pce] FW: New Version Notification for draft-crabbe-pce-stateful-
> pce-01.txt
>
> Hello,
>
> We submitted a new version of the Stateful PCE draft, where we addressed
> comments / suggestions from reviewers on the mailing list - many thanks to
> all who reviewed & commented.
>
> We to hope to have a good discussion of the draft in Taipei.
>
>
> Thanks,
> Ed+Jan+Robert
>
>
>
>
> On 10/30/11 11:50 PM, "internet-drafts@ietf.org"
> <internet-drafts@ietf.org> wrote:
>
> >A new version of I-D, draft-crabbe-pce-stateful-pce-01.txt has been
> >successfully submitted by Jan Medved and posted to the IETF repository.
> >
> >Filename:                  draft-crabbe-pce-stateful-pce
> >Revision:                  01
> >Title:                                   PCEP Extensions for Stateful PCE
> >Creation date:                  2011-10-30
> >WG ID:                                   Individual Submission
> >Number of pages: 41
> >
> >Abstract:
> >   The Path Computation Element Communication Protocol (PCEP) provides
> >   mechanisms for Path Computation Elements (PCEs) to perform path
> >   computations in response to Path Computation Clients (PCCs) requests.
> >
> >   Although PCEP explicitly makes no assumptions regarding the
> >   information available to the PCE, it also makes no provisions for
> >   synchronization or PCE control of timing and sequence of path
> >   computations within and across PCEP sessions.  This document
> >   describes a set of extensions to PCEP to enable this functionality,
> >   providing stateful control of Multiprotocol Label Switching (MPLS)
> >   Traffic Engineering Label Switched Paths (TE LSP) via PCEP.
> >
> >
> >
> >
> >
> >
> >The IETF Secretariat
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0025A1AA4825793C_=-- --=_related 0025A1A84825793C_= Content-Type: image/gif Content-ID: <_1_158755E8158752000025A1A74825793C> Content-Transfer-Encoding: base64 R0lGODlh8QCFAOcAAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA8QCFAEAI/wADCBxI sKDBgwgTKlzIsKHDhxAjSpxIseJCABgzatzIsaPHjyBDihxJsqTJkyhTqlzpUeDJhgAMxiw4k2DN gTdxstzJsydImDKD0hRKE6VLn0iTKl3KtKlTjEeNptT58qnVqxwDSIW6VWVUrGDDih079qtJrWLR kl3LUy1Yt0bhsp1Ll6XcujvN4m27l+ndvnn/ArY72Gthv4IPr0ysmLFiu44fK42clLLkypYva95c Vy/npZlj5v2M1TNppKH5nn5qerXqsKldl2wtu7Ztn7Rv6959Njbv37xzAx9OXHhLw1OJs+6a2jdU 386RK/dbFrL0t9ObRk++eHv27429A/8Wr5n8YOPg03NGb9t8dfUz4cuvzR68+5H3b9f/nj9kf/r/ rRbadgG6tt98CHZWIGkLZpXgTxZFKOGEFFZo4YUYIvTghpcdyOGHV3kI4oiIXVcaibO95xV0KqLo X4txuSgjWSI2uJGNv+GYUXQ1Jhebjrs1R9VZ1nFHJFdVzfgTc11NBaSSLooI5ZQk7QfUUFjaRJRN VF6pZZY4bTnkbE9SCaKUZqbZEZrnyVemVWwW9iZs08V52JzLZWenmmru+RiePQEKm6AhykbooHwm WqSijPaG4pOH9uWnfjCeGWmjxV1K149j4ifjpO0ludinms7F6Y+kYqqqSKDSV+mHrRr/+iqHsa4K a6m26odrrgDy6utzv/paa7Bu7krsZ8Mem16PaTEK6aKiYqfos92ZWOi0s1bJYrPYcruisqsmC66e 29LZrbnfGhntkYkOyOW6L5VLJKrnpogku05a6ym9OWklpr9guvRvvwQPbHDAbjW3Y5MxqlvlwvCa qfC99qbLMKsCW+lsvJ16Wq3D17abLX7GjiuZuCZnqm+eInubL8hwbuxywxfHXO+JH9fMMp/UWpwy zyX/LGfQQo9HdMXLqpyjekfTHJx9dTaNdHHkUq2c1C8XnSbKWuvGNa9Y+2w1pcuGrTOy8H1tqqtp mw1zefOpvelpbkPbNZRy3y1g3XqXZ8b3ZCMnmPfQFx385eHv3vpo4AgO3vd6fz/ulOOSdxg5aozH fTluTEZM6+aBej61pYvj+/aGlMvZuemkk9iz66BXjlrssgdKe+2BlY4u7JYWjnDBCN8uNq2ZF4v7 o8Ifn7XynzN/ZkAAOw== --=_related 0025A1A84825793C_=-- From dhruv.dhody@huawei.com Tue Nov 1 23:51:10 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F95E11E80B1 for ; Tue, 1 Nov 2011 23:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.072 X-Spam-Level: X-Spam-Status: No, score=-6.072 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rM+D9s8lmXeX for ; Tue, 1 Nov 2011 23:51:08 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 683BC11E807F for ; Tue, 1 Nov 2011 23:51:07 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU0000D5TNIYI@szxga05-in.huawei.com> for pce@ietf.org; Wed, 02 Nov 2011 14:50:06 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU0007QNTN7Y0@szxga05-in.huawei.com> for pce@ietf.org; Wed, 02 Nov 2011 14:50:06 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AER81746; Wed, 02 Nov 2011 14:50:05 +0800 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 02 Nov 2011 14:50:01 +0800 Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.196]) by szxeml405-hub.china.huawei.com ([10.82.67.60]) with mapi id 14.01.0270.001; Wed, 02 Nov 2011 14:49:49 +0800 Date: Wed, 02 Nov 2011 06:49:49 +0000 From: Dhruv Dhody X-Originating-IP: [10.18.24.83] To: "draft-crabbe-pce-stateful-pce@tools.ietf.org" Message-id: <23CE718903A838468A8B325B80962F9B263913CF@SZXEML520-MBX.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_L8ev9kaFanehn7lahOXnKw)" Content-language: en-US Accept-Language: en-GB, zh-CN, en-US Thread-topic: Comments on draft-crabbe-pce-stateful-pce-01 Thread-index: AcyZK5ybt2x94CjOTxmi4nM898u3uw== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Cc: "pce@ietf.org" Subject: [Pce] Comments on draft-crabbe-pce-stateful-pce-01 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 06:51:10 -0000 --Boundary_(ID_L8ev9kaFanehn7lahOXnKw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear Authors, Here are a few comments - 1. In section 5.2: "Path Computation State Report (PCRpt): a PCEP message sent by a PCE to a PCC to report the status of one or more LSPs." I think there is mistake, PCRpt is sent from PCC to PCE based on the rest of the draft. 2. In section 5:3: It's important to add correlation between PCE Capability Discovery by IGP and via OPEN. Do you suggest to use both methods interchangeably? 3. Multiple Timers needs to be described to handle Statefull sync making sure PCC finishes the synchronization and send PCRpt with SyncDone=1 within a timeframe. You can also consider adding state synchronization as a part of Statefull Session Up. I.e. PCEP Statefull session is declared up only when PCC sends PCRpt with SyncDone=1. 4. In Section 5.5.4 you touch on Redundant Statefull PCE, we should explore backup PCE in more details. Another mechanism can be Primary and Backup Statefull PCE have a direction session and relationship to handle primary failure in a much faster and secure mechanism. 5. Wrt to delegation, PCE updates LSP parameters and send PcUpd to PCC, if PCC apply Make-Before-Break policy where new applying new parameters has failed, it's important for PCC to send PCRpt stating that LSP is up but without updating the new parameters as suggested by PCE in PCUpd. 6. Wrt to section 6.1, ERO is used to carry the path as specified by PCE, RRO is also used if LSP is setup along the path. I am not sure why you need both ERO and RRO, can you give a use case? Similarly am not sure what is the purpose of IRO in PCUpd? Sorry for nit-picking I guess! :D Also few things that should be considered - 1) Synchronization Vector: If PCC request some LSP to be computed together I think this relationship should continue in Statefull PCE so PCRpt and PCUpd should continue to support that 2) Statefull PCE becoming Bottleneck: This needs to clearly specified, mechanism like Overload PCE notification should be enhanced to handle Statefull PCE, we can explore option of PCE-PCE communication (intradomain scope) to handle Primary Statefull PCE failure/overload conditions. The clear benefit would be only 2 entity (Primary PCE and Backup PCE) will be involved, otherwise all PCC in the system must send PCRpt with Delegate=1 for all LSP. Hope we have a fruitful discussion in Taipei. Regards, Dhruv *************************************************************************************** Dhruv Dhody, Senior Technical Leader, Huawei Technologies, Bangalore, India, Ph. +91-9845062422 This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! --Boundary_(ID_L8ev9kaFanehn7lahOXnKw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Dear Authors,

 

Here are a few comments –

 

1.       In section 5.2:

“Path Computation State Report (PCRpt): a PCEP message sent by a PCE to a PCC to report the status of one or more LSPs.”

I think there is mistake, PCRpt is sent from PCC to PCE based on the rest of the draft.

2.      In section 5:3: It’s important to add correlation between PCE Capability Discovery by IGP and via OPEN. Do you suggest to use both methods interchangeably?

3.      Multiple Timers needs to be described to handle Statefull sync making sure PCC finishes the synchronization and send PCRpt with SyncDone=1 within a timeframe.  You can also consider adding state synchronization as a part of Statefull Session Up. I.e. PCEP Statefull session is declared up only when PCC sends PCRpt with SyncDone=1.

4.     In Section 5.5.4 you touch on Redundant Statefull PCE, we should explore backup PCE in more details. Another mechanism can be Primary and Backup Statefull PCE have a direction session and relationship to handle primary failure in a much faster and secure mechanism.

5.      Wrt to delegation, PCE updates LSP parameters and send PcUpd to PCC,  if PCC apply Make-Before-Break policy where new applying new parameters has failed, it’s important for PCC to send PCRpt stating that LSP is up but without updating the new parameters as suggested by PCE in PCUpd.

6.     Wrt to section 6.1, ERO is used to carry the path as specified by PCE, RRO is also used if LSP is setup along the path. I am not sure why you need both ERO and RRO, can you give a use case? Similarly am not sure what is the purpose of IRO in PCUpd?

 

Sorry for nit-picking I guess! :D

 

Also few things that should be considered –

1)      Synchronization Vector: If PCC request some LSP to be computed together I think this relationship should continue in Statefull PCE so PCRpt and PCUpd should continue to support that

2)      Statefull PCE becoming Bottleneck: This needs to clearly specified, mechanism like Overload PCE notification should be enhanced to handle Statefull PCE, we can explore option of PCE-PCE communication (intradomain scope) to handle Primary Statefull PCE failure/overload conditions. The clear benefit would be only 2 entity (Primary PCE and Backup PCE) will be involved, otherwise all PCC in the system must send PCRpt with Delegate=1 for all  LSP.

 

Hope we have a fruitful discussion in Taipei.

 

Regards,

Dhruv

 

***************************************************************************************
Dhruv Dhody, Senior Technical Leader, Huawei Technologies, Bangalore, India, Ph. +91-9845062422

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

 

--Boundary_(ID_L8ev9kaFanehn7lahOXnKw)-- From julien.meuric@orange.com Wed Nov 2 06:27:15 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23CDE11E80A4 for ; Wed, 2 Nov 2011 06:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTdKAvUJ9qQb for ; Wed, 2 Nov 2011 06:27:14 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECBF11E8089 for ; Wed, 2 Nov 2011 06:27:14 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 24CF7103C002 for ; Wed, 2 Nov 2011 14:27:11 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 1C254103C001 for ; Wed, 2 Nov 2011 14:27:11 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Nov 2011 14:27:10 +0100 Received: from [10.193.71.201] ([10.193.71.201]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Nov 2011 14:27:10 +0100 Message-ID: <4EB1452E.2080901@orange.com> Date: Wed, 02 Nov 2011 14:27:10 +0100 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: "pce@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Nov 2011 13:27:10.0918 (UTC) FILETIME=[20461E60:01CC9963] Subject: [Pce] Fwd: RFC 6417 on How to Contribute Research Results to Internet Standardization X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 13:27:15 -0000 FYI -------- Message original -------- De : rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 6417 Title: How to Contribute Research Results to Internet Standardization Author: P. Eardley, L. Eggert, M. Bagnulo, R. Winter Status: Informational Stream: Independent Date: November 2011 Mailbox: philip.eardley@bt.com, lars.eggert@nokia.com, marcelo@it.uc3m.es, rolf.winter@neclab.eu Pages: 14 Characters: 33781 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-weeb-research-to-internet-stds-03.txt URL: http://www.rfc-editor.org/rfc/rfc6417.txt The development of new technology is driven by scientific research. The Internet, with its roots in the ARPANET and NSFNet, is no exception. Many of the fundamental, long-term improvements to the architecture, security, end-to-end protocols and management of the Internet originate in the related academic research communities. Even shorter-term, more commercially driven extensions are oftentimes derived from academic research. When interoperability is required, the IETF standardizes such new technology. Timely and relevant standardization benefits from continuous input and review from the academic research community. For an individual researcher, it can however be quite puzzling how to begin to most effectively participate in the IETF and arguably to a much lesser degree, the IRTF. The interactions in the IETF are much different than those in academic conferences, and effective participation follows different rules. The goal of this document is to highlight such differences and provide a rough guideline that will hopefully enable researchers new to the IETF to become successful contributors more quickly. This document is not an Internet Standards Track specification; it is published for informational purposes. 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 http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. 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 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From edc@google.com Wed Nov 2 10:15:45 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E54F011E811D for ; Wed, 2 Nov 2011 10:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.328 X-Spam-Level: X-Spam-Status: No, score=-99.328 tagged_above=-999 required=5 tests=[AWL=-3.647, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHpWowYQTQPj for ; Wed, 2 Nov 2011 10:15:45 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7737811E80F8 for ; Wed, 2 Nov 2011 10:15:36 -0700 (PDT) Received: by ywt2 with SMTP id 2so402478ywt.31 for ; Wed, 02 Nov 2011 10:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=KjOyEaDQLgYqBK21lO+8NIio7nVyrymPzxHF/YL+buM=; b=aWNaWKc6JQ7/mnkbBkJMRi1nXHq++M1C5saYIY667XKA0PS0YxPwfiFjAIBTHKML9O qJnZtEQk+GDlgoLvl2Xw== Received: by 10.150.143.18 with SMTP id q18mr6342820ybd.81.1320254134444; Wed, 02 Nov 2011 10:15:34 -0700 (PDT) Received: by 10.150.143.18 with SMTP id q18mr6342793ybd.81.1320254134245; Wed, 02 Nov 2011 10:15:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.178.16 with HTTP; Wed, 2 Nov 2011 10:15:13 -0700 (PDT) In-Reply-To: <201111020649.pA26nktc062751@mse01.zte.com.cn> References: <949A8A83ECD6D24395E1762F14487C8F080273FF@w8uspdy131.ams.gblxint.com> <201111020649.pA26nktc062751@mse01.zte.com.cn> From: Edward Crabbe Date: Wed, 2 Nov 2011 10:15:13 -0700 Message-ID: To: tang.kexin@zte.com.cn Content-Type: multipart/related; boundary=000e0cd56a3caf586d04b0c39e08 X-System-Of-Record: true Cc: "pce@ietf.org" , rvarga@juniper.net Subject: Re: [Pce] =?gb2312?b?tPC4tDogUmU6ICBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g?= =?gb2312?b?Zm9yIGRyYWZ0LWNyYWJiZS1wY2Utc3RhdGVmdWwtcGNlLTAxLnR4?= =?gb2312?b?dA==?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 17:15:46 -0000 --000e0cd56a3caf586d04b0c39e08 Content-Type: multipart/alternative; boundary=000e0cd56a3caf586704b0c39e07 --000e0cd56a3caf586704b0c39e07 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Kexin, Not true; in one case (3.1.2.3) there is insufficient capacity to meet a demand (and thus the demand set: ie: the network is underprovisioned). In the rest of the cases, there is sufficient aggregate capacity to meet the demands. The total demand time series set is given for each toy example. The problem may be that you are interpreting the column on the far left of the demand tables as an lsp id / demand index when it is a time point in the time series of demand characteristics? best, -ed On Tue, Nov 1, 2011 at 11:48 PM, wrote: > > Dear Authors, > > I have reviewed your draft, the motivation described in 3.1.2 is very > reasonable. > I have a question. Do you make the assumption in your examples that there > is no sufficient network resource for all the LSPs to be set up? > > We updated our "stateful PCE" I-D recently. > http://tools.ietf.org/html/draft-tang-pce-stateful-pce-02 > I think we are considering the same following problems. > 1. Why stateful PCE is important? > 2. How to realize stateful PCE? > > For the 1st problem, as I mentioned above, your consideration may mainly > focus on the scenario where network resources is insufficient. > Our motivation is mainly to the condition that the network capacity is > enougy for all the LSPs to be set up. > Our objective is to avoid resources conflict because lack of the state of > LSPs. > Take the follow demonstration topology for example. > > > > Link capacity of A-B / B-C / A-C: 100M > Bandwidth demond: LSP 1 needs 80M. LSP2 needs 80M. > Source and destination of LSP1 and LSP2: Both of them is from A to B. > T1: PCE computed the shortest path for LSP1 : A-B (computation result did > not synchronized with PCE) > T2: PCE computed the shortest path for LSP2 : A-B (PCE assume the > unreserved bandwidth of A-B is still 100M, although is 20M in fact) > T3: LSP1 set up successful by signaling > T4: LSP2 failed to set up by signaling (no sufficient link capacity > aviable on link A-B) > > I think the objective of the two draft are the same that stateful PCE > synchronized with the state of LSPs although by different mechanism. > You defined two new PCEP messages (PCRpt and PCUpd), while we extended th= e > existing PCNtf message. > > Thanks, > Kexin > > > > -----Original Message----- > > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of > > Jan Medved > > Sent: Monday, October 31, 2011 12:02 AM > > To: pce@ietf.org > > Subject: [Pce] FW: New Version Notification for > draft-crabbe-pce-stateful- > > pce-01.txt > > > > Hello, > > > > We submitted a new version of the Stateful PCE draft, where we addresse= d > > comments / suggestions from reviewers on the mailing list - many thanks > to > > all who reviewed & commented. > > > > We to hope to have a good discussion of the draft in Taipei. > > > > > > Thanks, > > Ed+Jan+Robert > > > > > > > > > > On 10/30/11 11:50 PM, "internet-drafts@ietf.org" > > wrote: > > > > >A new version of I-D, draft-crabbe-pce-stateful-pce-01.txt has been > > >successfully submitted by Jan Medved and posted to the IETF repository= . > > > > > >Filename: draft-crabbe-pce-stateful-pce > > >Revision: 01 > > >Title: PCEP Extensions for Stateful > PCE > > >Creation date: 2011-10-30 > > >WG ID: Individual Submission > > >Number of pages: 41 > > > > > >Abstract: > > > The Path Computation Element Communication Protocol (PCEP) provides > > > mechanisms for Path Computation Elements (PCEs) to perform path > > > computations in response to Path Computation Clients (PCCs) request= s. > > > > > > Although PCEP explicitly makes no assumptions regarding the > > > information available to the PCE, it also makes no provisions for > > > synchronization or PCE control of timing and sequence of path > > > computations within and across PCEP sessions. This document > > > describes a set of extensions to PCEP to enable this functionality, > > > providing stateful control of Multiprotocol Label Switching (MPLS) > > > Traffic Engineering Label Switched Paths (TE LSP) via PCEP. > > > > > > > > > > > > > > > > > > > > >The IETF Secretariat > > > > _______________________________________________ > > Pce mailing list > > Pce@ietf.org > > https://www.ietf.org/mailman/listinfo/pce > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail i= s solely property of the sender's organization. This mail communication is = confidential. Recipients named above are obligated to maintain secrecy and = are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intende= d solely for the use of the individual or entity to whom they are addressed= . If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individua= l sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. > > --000e0cd56a3caf586704b0c39e07 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Kexin,

Not true;   in one case (3.1.2.3) there is insufficient capacit= y to meet a demand (and thus the demand set: ie: the network is underprovis= ioned). 
In the res= t of the cases, there is sufficient aggregate capacity to meet the demands.=  The total demand time series set is given for each toy exampl= e.

The= problem may be that you are interpreting the column on the far left of the= demand tables as an lsp id / demand index when it is a time point in the t= ime series of demand characteristics?

bes= t,

  -ed

On Tue, No= v 1, 2011 at 11:48 PM, <tang.kexin@zte.com.cn> wrote:

Dear Authors,

I have reviewed your draft, the mo= tivation described in 3.1.2 is very reasonable.
I have a question. Do you make the= assumption in your examples that there is no sufficient network resource for all the LSPs to be set up?

We updated our "stateful PCE&= quot; I-D recently. http://tools.ietf.org/html/draft-tang-pce-statef= ul-pce-02
I think we are considering the sam= e following problems.
1. Why stateful PCE is important?<= /font>
2. How to realize stateful PCE?

For the 1st problem, as I mentione= d above, your consideration may mainly focus on the scenario where network resources is insufficient.
Our motivation is mainly to the co= ndition that the network capacity is enougy for all the LSPs to be set up.
Our objective is to avoid resource= s conflict because lack of the state of LSPs.
Take the follow demonstration topo= logy for example.

         =

Link capacity of A-B / B-C / A-C: =  100M
Bandwidth demond: LSP 1 needs 80M.= LSP2 needs 80M.
Source and destination of LSP1 and= LSP2: Both of them is from A to B.
T1: PCE computed the shortest path= for LSP1 : A-B (computation result did not synchronized with PCE)
T2: PCE computed the shortest path= for LSP2 : A-B (PCE assume the unreserved bandwidth of A-B is still 100M, altho= ugh is 20M in fact)
T3: LSP1 set up successful by sign= aling
T4: LSP2 failed to set up by signa= ling (no sufficient link capacity aviable on link A-B)

I think the objective of the two d= raft are the same that stateful PCE synchronized with the state of LSPs although by different mechanism.
You defined two new PCEP messages = (PCRpt and PCUpd), while we extended the existing PCNtf message.

Thanks,
Kexin


> -----Original Message-----
> From: pce-bo= unces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of
> Jan Medved
> Sent: Monday, October 31, 2011 12:02 AM
> To: pce@ietf.org=
> Subject: [Pce] FW: New Version Notification for draft-crabbe-pce-state= ful-
> pce-01.txt
>
> Hello,
>
> We submitted a new version of the Stateful PCE draft, where we address= ed
> comments / suggestions from reviewers on the mailing list - many thank= s to
> all who reviewed & commented.
>
> We to hope to have a good discussion of the draft in Taipei.
>
>
> Thanks,
> Ed+Jan+Robert
>
>
>
>
> On 10/30/11 11:50 PM, "internet-drafts@ietf.org"
> <inte= rnet-drafts@ietf.org> wrote:
>
> >A new version of I-D, draft-crabbe-pce-stateful-pce-01.txt has been
> >successfully submitted by Jan Medved and posted to the IETF reposi= tory.
> >
> >Filename:                  draft-crabbe-pce-stateful-pce
> >Revision:                  01
> >Title:                                   PCEP Extensions for Stateful PCE
> >Creation date:                  2011-10-30
> >WG ID:                                   Individual Submission
> >Number of pages: 41
> >
> >Abstract:
> >   The Path Computation Element Communication Protocol (PCEP) provides
> >   mechanisms for Path Computation Elements (PCEs) to perform path
> >   computations in response to Path Computation Clients (PCCs= ) requests.
> >
> >   Although PCEP explicitly makes no assumptions regarding the
> >   information available to the PCE, it also makes no provisi= ons for
> >   synchronization or PCE control of timing and sequence of path
> >   computations within and across PCEP sessions.  This document
> >   describes a set of extensions to PCEP to enable this funct= ionality,
> >   providing stateful control of Multiprotocol Label Switchin= g (MPLS)
> >   Traffic Engineering Label Switched Paths (TE LSP) via PCEP.
> >
> >
> >
> >
> >
> >
> >The IETF Secretariat
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce

 

--------------------------------------------------------
ZTE Information Security Notice: The information&n=
bsp;contained in this mail is solely property=
 of the sender's organization. This mail&=
nbsp;communication is confidential. Recipients named&nb=
sp;above are obligated to maintain secrecy an=
d are not permitted to disclose the cont=
ents of this communication to others.
This email and any files transmitted with&nbs=
p;it are confidential and intended solely for=
 the use of the individual or entity&nbs=
p;to whom they are addressed. If you hav=
e received this email in error please no=
tify the originator of the message. Any =
views expressed in this message are those&nbs=
p;of the individual sender.
This message has been scanned for viruses&nbs=
p;and Spam by ZTE Anti-Spam system.

--000e0cd56a3caf586704b0c39e07-- --000e0cd56a3caf586d04b0c39e08 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: <_1_158755E8158752000025A1A74825793C> X-Attachment-Id: cecc5e491825b03c_0.1 R0lGODlh8QCFAOcAAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA8QCFAEAI/wADCBxI sKDBgwgTKlzIsKHDhxAjSpxIseJCABgzatzIsaPHjyBDihxJsqTJkyhTqlzpUeDJhgAMxiw4k2DN gTdxstzJsydImDKD0hRKE6VLn0iTKl3KtKlTjEeNptT58qnVqxwDSIW6VWVUrGDDih079qtJrWLR kl3LUy1Yt0bhsp1Ll6XcujvN4m27l+ndvnn/ArY72Gthv4IPr0ysmLFiu44fK42clLLkypYva95c Vy/npZlj5v2M1TNppKH5nn5qerXqsKldl2wtu7Ztn7Rv6959Njbv37xzAx9OXHhLw1OJs+6a2jdU 386RK/dbFrL0t9ObRk++eHv27429A/8Wr5n8YOPg03NGb9t8dfUz4cuvzR68+5H3b9f/nj9kf/r/ rRbadgG6tt98CHZWIGkLZpXgTxZFKOGEFFZo4YUYIvTghpcdyOGHV3kI4oiIXVcaibO95xV0KqLo X4txuSgjWSI2uJGNv+GYUXQ1Jhebjrs1R9VZ1nFHJFdVzfgTc11NBaSSLooI5ZQk7QfUUFjaRJRN VF6pZZY4bTnkbE9SCaKUZqbZEZrnyVemVWwW9iZs08V52JzLZWenmmru+RiePQEKm6AhykbooHwm WqSijPaG4pOH9uWnfjCeGWmjxV1K149j4ifjpO0ludinms7F6Y+kYqqqSKDSV+mHrRr/+iqHsa4K a6m26odrrgDy6utzv/paa7Bu7krsZ8Mem16PaTEK6aKiYqfos92ZWOi0s1bJYrPYcruisqsmC66e 29LZrbnfGhntkYkOyOW6L5VLJKrnpogku05a6ym9OWklpr9guvRvvwQPbHDAbjW3Y5MxqlvlwvCa qfC99qbLMKsCW+lsvJ16Wq3D17abLX7GjiuZuCZnqm+eInubL8hwbuxywxfHXO+JH9fMMp/UWpwy zyX/LGfQQo9HdMXLqpyjekfTHJx9dTaNdHHkUq2c1C8XnSbKWuvGNa9Y+2w1pcuGrTOy8H1tqqtp mw1zefOpvelpbkPbNZRy3y1g3XqXZ8b3ZCMnmPfQFx385eHv3vpo4AgO3vd6fz/ulOOSdxg5aozH fTluTEZM6+aBej61pYvj+/aGlMvZuemkk9iz66BXjlrssgdKe+2BlY4u7JYWjnDBCN8uNq2ZF4v7 o8Ifn7XynzN/ZkAAOw== --000e0cd56a3caf586d04b0c39e08-- From jmedved@juniper.net Wed Nov 2 13:27:18 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA87711E811F for ; Wed, 2 Nov 2011 13:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOlAz983Y3SV for ; Wed, 2 Nov 2011 13:27:18 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id B9E9B11E80BC for ; Wed, 2 Nov 2011 13:27:17 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Wed, 02 Nov 2011 13:27:17 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 2 Nov 2011 13:26:45 -0700 From: Jan Medved To: Dhruv Dhody Date: Wed, 2 Nov 2011 13:26:38 -0700 Thread-Topic: [Pce] Comments on draft-crabbe-pce-stateful-pce-01 Thread-Index: AcyZnb0MHGnUep/iQ32EvBlo6le05w== Message-ID: In-Reply-To: <23CE718903A838468A8B325B80962F9B263913CF@SZXEML520-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pce@ietf.org" Subject: Re: [Pce] Comments on draft-crabbe-pce-stateful-pce-01 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 20:27:18 -0000 Hi Dhruv, Thanks for the comments, please see inline. /Jan On 11/1/11 11:49 PM, "Dhruv Dhody" > wrote: Dear Authors, Here are a few comments =96 1. In section 5.2: =93Path Computation State Report (PCRpt): a PCEP message sent by a PCE to a= PCC to report the status of one or more LSPs.=94 I think there is mistake, PCRpt is sent from PCC to PCE based on the rest o= f the draft. Yes, indeed. We will correct the text. In fact, the PCRpt can be sent from= a PCE to another PCE to sync the state between PCEs. 2. In section 5:3: It=92s important to add correlation between PCE Cap= ability Discovery by IGP and via OPEN. Do you suggest to use both methods i= nterchangeably? We think both are required. Capability discovery by IGP is clearly needed, = but we wanted to limit the scope of this draft to PCEP and describe statefu= l capability discovery by IGPs in a separate draft. Capability negotiation= in PCEP is still needed - both PCEP speakers need to confirm at the beginn= ing of a PCEP session that the discovered capabilities are indeed supported= . 3. Multiple Timers needs to be described to handle Statefull sync maki= ng sure PCC finishes the synchronization and send PCRpt with SyncDone=3D1 w= ithin a timeframe. You can also consider adding state synchronization as a= part of Statefull Session Up. I.e. PCEP Statefull session is declared up o= nly when PCC sends PCRpt with SyncDone=3D1. The timer is good idea. It's value could be a parameter negotiated at the = beginning of the PCEP session. We think it's better if the synchronization = is done after the PCEP session is up =96 then we know for sure that the cha= nnel between PCEP Speakers is up (we have Keepalives going on). Also, a PCE= may want to start to service requests or set up LSPs even if it's not full= y synchronized with a PCC (whether a PCE does this is an implementation/con= figuration issue). 4. In Section 5.5.4 you touch on Redundant Statefull PCE, we should exp= lore backup PCE in more details. Agreed. Another mechanism can be Primary and Backup Statefull PCE have a direction = session and relationship to handle primary failure in a much faster and sec= ure mechanism. Agreed, this is another viable method to sync up the Primary and Backup PCE= s. Here, the PCC will only need to send PCRpt messages to the Primary PCE,= which would offload the PCC (it would only have to send PCRpt messages to = the Primary PCE). After a switchover, the new Primary PCE and the PCC sti= ll need to sync up, though (race conditions, messages in transfer, etc.). We described what we think is the simplest possible mechanism that makes no= assumption on how PCEs are related to each other or communicate with each = other. But we agree that it can be just a starting point for a more detaile= d discussion. 5. Wrt to delegation, PCE updates LSP parameters and send PcUpd to PCC= , if PCC apply Make-Before-Break policy where new applying new parameters = has failed, it=92s important for PCC to send PCRpt stating that LSP is up b= ut without updating the new parameters as suggested by PCE in PCUpd. Agreed. We'll add it to the text. 6. Wrt to section 6.1, ERO is used to carry the path as specified by PC= E, RRO is also used if LSP is setup along the path. I am not sure why you n= eed both ERO and RRO, can you give a use case? If the PCE specifies a loose route, i.e. the ERO does not contain all hops,= the PCC will use local CSPF to route the LSP. The PCC can report to the PC= E how the LSP got routed (if route recording is enabled on the LSP). Similarly am not sure what is the purpose of IRO in PCUpd? If the PCE specifies a loose route, it may still want the PCC's local CSPF = to route the LSP through a set of nodes specified in the IRO object. Sorry for nit-picking I guess! :D Really good points, thanks for bringing them up. Also few things that should be considered =96 1) Synchronization Vector: If PCC request some LSP to be computed toge= ther I think this relationship should continue in Statefull PCE so PCRpt an= d PCUpd should continue to support that We don't need the Synchronization Vector for LSPs delegated to a PCE. The P= CE not only computes the paths for delegated LSPs, but also decides when to= set up each LSP. The PCE can synchronize LSP setups within a single PCC, o= r between PCCs. Basically, delegated LSPs are under the control of the PCE. Also, a PCC mus= t not request a path computation on a delegated LSP (Section 5.6.2; basical= ly, an LSP is either under PCE's control or under local control, never both= ). We don't need synchronization for LSP State Reporting =96 while synchroniza= tion is required for path computations/requests, state reporting is by defi= nition asynchronous (events on LSPs occur asynchronously, LSP setups may fi= nish out of order even for synchronized LSPs, etc.) 2) Statefull PCE becoming Bottleneck: This needs to clearly specified,= mechanism like Overload PCE notification should be enhanced to handle Stat= efull PCE, Right now we are relying on message-level flow control built into PCEP (bas= ically, TCP :-) ). If a PCE is overloaded and can't process one or more PCR= pt messages from a PCC, it will loose state and state resynchronization mus= t follow. The simplest method to resync is to drop the PCEP session with th= e PCC and re-establish it when the overload condition disappears. We think = that's a good starting point, but we may want to come up with more sophisti= cated flow control mechanisms (Robert Raszuk brought up this point as well)= . we can explore option of PCE-PCE communication (intradomain scope) to handl= e Primary Statefull PCE failure/overload conditions. The clear benefit woul= d be only 2 entity (Primary PCE and Backup PCE) will be involved, otherwise= all PCC in the system must send PCRpt with Delegate=3D1 for all LSP. Good point =96 we should discuss this further. Hope we have a fruitful discussion in Taipei. Looking forward to it. Regards, Dhruv ***************************************************************************= ************ Dhruv Dhody, Senior Technical Leader, Huawei Technologies, Bangalore, India= , Ph. +91-9845062422 This e-mail and attachments contain confidential information from HUAWEI, w= hich is intended only for the person or entity whose address is listed abov= e. Any use of the information contained herein in any way (including, but n= ot limited to, total or partial disclosure, reproduction, or dissemination)= by persons other than the intended recipient's) is prohibited. If you rece= ive this e-mail in error, please notify the sender by phone or email immedi= ately and delete it! From jmedved@juniper.net Wed Nov 2 17:18:21 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2909B11E80B6 for ; Wed, 2 Nov 2011 17:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.253 X-Spam-Level: X-Spam-Status: No, score=-6.253 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCHoJJNz93JL for ; Wed, 2 Nov 2011 17:18:20 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 61E7B11E80AB for ; Wed, 2 Nov 2011 17:18:20 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Wed, 02 Nov 2011 17:18:20 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 2 Nov 2011 17:15:16 -0700 From: Jan Medved To: "tang.kexin@zte.com.cn" , "edc@google.com" , Robert Varga Date: Wed, 2 Nov 2011 17:15:15 -0700 Thread-Topic: =?utf-8?B?562U5aSNOiBSZTogW1BjZV0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv?= =?utf-8?B?ciBkcmFmdC1jcmFiYmUtcGNlLXN0YXRlZnVsLXBjZS0wMS50eHQ=?= Thread-Index: AcyZvanH2lAwccztR0amQyh3qtNNLQ== Message-ID: In-Reply-To: <201111020649.pA26nke1062724@mse01.zte.com.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "pce@ietf.org" Subject: Re: [Pce] =?utf-8?b?562U5aSNOiBSZTogIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv?= =?utf-8?q?n_for_draft-crabbe-pce-stateful-pce-01=2Etxt?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 00:18:21 -0000 SGkgS2V4aW4sDQoNClRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLCBwbGVhc2Ugc2VlIGJlbG93Lg0K DQoNCi9KYW4NCg0KDQpPbiAxMS8xLzExIDExOjQ4IFBNLCAidGFuZy5rZXhpbkB6dGUuY29tLmNu IiA8dGFuZy5rZXhpbkB6dGUuY29tLmNuPiB3cm90ZToNCg0KDQo+SSB0aGluayB0aGUgb2JqZWN0 aXZlIG9mIHRoZSB0d28gZHJhZnQgYXJlIHRoZSBzYW1lIHRoYXQgc3RhdGVmdWwgUENFDQo+c3lu Y2hyb25pemVkIHdpdGggdGhlIHN0YXRlIG9mIExTUHMgYWx0aG91Z2ggYnkgZGlmZmVyZW50IG1l Y2hhbmlzbS4NCg0KVGhlIG9iamVjdGl2ZXMgb2YgZHJhZnQtY3JhYmJlLXBjZS1zdGF0ZWZ1bC1w Y2UgYXJlIHR3b2ZvbGQ6DQoNCiogS2VlcCBhIHN0YXRlZnVsIFBDRSBzeW5jaHJvbml6ZWQgd2l0 aCB0aGUgc3RhdGUgb2YgTFNQcyBpbiBhIFBDQzsgdGhpcw0Kb2JqZWN0aXZlIGlzIHRoZSBzYW1l IGFzIHRoZSBvYmplY3RpdmUgb2YgZHJhZnQtdGFuZy1wY2Utc3RhdGVmdWwtcGNlLg0KKiBBbGxv dyBhIHN0YXRlZnVsIFBDRSB0byBkZXRlcm1pbmUgdGhlIHRpbWluZyBvZiBMU1Agc2V0dXAgaW4g dGhlIG5ldHdvcmsNCihpbiBhZGRpdGlvbiB0byBkZXRlcm1pbmluZyB0aGUgTFNQIHBhdGhzIHRo cm91Z2ggdGhlIG5ldHdvcmspLg0KDQpXZSBjYWxsIHRoZSBQQ0UgdGhhdCBvbmx5IHdpc2hlcyB0 byBrbm93IHRoZSBMU1Agc3RhdGUgdGhlICdwYXNzaXZlDQpzdGF0ZWZ1bCBQQ0UnLiBXZSBjYWxs IHRoZSBQQ0UgdGhhdCBjb250cm9scyB0aGUgdGltaW5nIG9mIExTUCBzZXR1cHMgaW4NCnRoZSBu ZXR3b3JrIHRoZSAnYWN0aXZlIHN0YXRlZnVsIFBDRScuDQoNCj4NCj5Zb3UgZGVmaW5lZCB0d28g bmV3IFBDRVAgbWVzc2FnZXMgKFBDUnB0IGFuZCBQQ1VwZCksIHdoaWxlIHdlIGV4dGVuZGVkDQo+ dGhlIGV4aXN0aW5nIFBDTnRmIG1lc3NhZ2UuDQoNCldlIGNvbnNpZGVyZWQgZXh0ZW5kaW5nIHRo ZSBQQ050ZiBtZXNzYWdlLCBidXQgaW4gdGhlIGVuZCBkZWNpZGVkIHRvIHRvDQpkZWZpbmUgYSBu ZXcgbWVzc2FnZSBmb3IgTFNQIFN0YXRlIFJlcG9ydGluZyAoUENScHQpLiBXZSBkZWZpbmVkIHRo ZSBQQ1VwZA0KbWVzc2FnZSB0byBzYXRpc2Z5IHRoZSBvdGhlciBvYmplY3RpdmUgb2YgZHJhZnQt Y3JhYmJlLXBjZS1zdGF0ZWZ1bC1wY2Ugwq0NCnRoZSBhY3RpdmUgY29udHJvbCBvZiBMU1BzIGJ5 IGEgUENFLg0KDQpUaGVyZSBhcmUgZ29vZCByZWFzb25zIHRvIGRlZmluZSBhIG5ldyBtZXNzYWdl IGZvciBMU1AgU3RhdGUgUmVwb3J0aW5nLiAgSQ0KdGhpbmsgd2UgYXJlIGJvdGggYWdyZWVtZW50 IHRoYXQgYW4gTFNQIHN0YXRlIHJlcG9ydC9ub3RpZmljYXRpb24gbXVzdA0KY2FycnkgYSBzZXQg b2YgTFNQIGF0dHJpYnV0ZXMgdGhhdCBkZXNjcmliZSB0aGUgTFNQJ3Mgc3RhdGUuIE5vdywgaWYg d2UNCndhbnQgdG8gcmUtdXNlIHRoZSBQQ050ZiBtZXNzYWdlIGZvciBMU1Agc3RhdGUgcmVwb3J0 cyAvIG5vdGlmaWNhdGlvbnMsIHdlDQpjYW4gZWl0aGVyIGRlZmluZSBpbiB0aGUgTk9USUZJQ0FU SU9OIE9iamVjdCBhIHNldCBvZiBvcHRpb25hbCBUTFZzIHRoYXQNCmNhbiBjYXJyeSB0aGUgTFNQ IGF0dHJpYnV0ZXMsIG9yIHJlZGVmaW5lIHRoZSBQQ050ZiBtZXNzYWdlIGl0c2VsZiB0byB1c2UN CmFscmVhZHkgZGVmaW5lZCBQQ0VQIE9iamVjdHMgdG8gY2FycnkgTFNQIGF0dHJpYnV0ZXMuDQoN ClRoZSBUTFYgYXBwcm9hY2ggaXMgbm90IGlkZWFsOiB3ZSBhbHJlYWR5IGhhdmUgYSBzZXQgb2Yg UENFUCBPYmplY3RzIHRoYXQNCmNhbiBjYXJyeSB0aGUgTFNQIGF0dHJpYnV0ZXMsIG5vdyB3ZSB3 b3VsZCBoYXZlIHRvIGRlZmluZSBhbGwgb2YgdGhlbSBhcw0KVExWcyBhcyB3ZWxsLiBBbmQgaWYg bmV3IExTUCBhdHRyaWJ1dGVzIGFyZSBpbnRyb2R1Y2VkIHRvIHRoZSBQQ0VQDQpwcm90b2NvbCBp biB0aGUgZnV0dXJlLCB0aGUgbWF5IGhhdmUgdG8gYmUgZGVmaW5lZCBib3RoIGluIFBDRVAgT2Jq ZWN0cw0KYW5kIGluIE5PVElGSUNBVElPTiBUTFZzLg0KDQpUaGUgYXBwcm9hY2ggd2hlcmUgdGhl IFBDTnRmIG1lc3NhZ2UgaXMgcmVkZWZpbmVkIGlzIG5vdCBpZGVhbCBlaXRoZXIuIEZvcg0Kb25l LCB3ZSBtYXkgYmUgYnJlYWtpbmcgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIGJlY2F1c2Ugd2Ug YXJlIHJlZGVmaW5pbmcNCnRoZSBtZXNzYWdlIGFuZCBub3QgdXNpbmcgb3B0aW9uYWwgVExWcyB0 byBkZWZpbmUgbmV3IGZ1bmN0aW9uYWxpdHkuDQooTm90ZSB0aGF0IHdpdGggYSBuZXcgbWVzc2Fn ZSB3ZSBhcmUgbm90IGJyZWFraW5nIGV4aXN0aW5nDQppbXBsZW1lbnRhdGlvbnMsIGJlY2F1c2Ug bmV3IG1lc3NhZ2VzIGFyZSBvbmx5IHVzZWQgaWYgc3RhdGVmdWwNCmNhcGFiaWxpdGllcyBhcmUg bmVnb3RpYXRlZCBiZXR3ZWVuIFBDRVAgU3BlYWtlcnMpLiBTZWNvbmQsIHRoZSBQQ050Zg0KbWVz c2FnZSBhcyBjdXJyZW50bHkgZGVmaW5lZCBpbiBQQ0VQIHNlZW1zIHRvIGJlIGRlc2lnbmVkIGZv ciBQQ0VQIGV2ZW50cw0KKFBDRSBjb25nZXN0aW9uLCBjYW5jZWxsYXRpb24gb2YgUGVuZGluZyBS ZXF1ZXN0cywgxaApLCBhbmQgY2hhbmdpbmcgaXRzDQpzZW1hbnRpY3MgdG8gY2FycnkgYm90aCBQ Q0VQIGV2ZW50cyBhbmQgTFNQIHN0YXRlIGRvZXMgbm90IHNlZW0gdG8gYmUgdGhlDQpyaWdodCB0 aGluZyB0byBkby4gRmluYWxseSwgcmVkZWZpbmluZyB0aGUgUENOdGYgbWVzc2FnZSBjaGFuZ2Vz IGl0cw0Kc3RydWN0dXJlIHRvIGEgcG9pbnQgd2hlcmUgd2UgbWF5IGFzIHdlbGwgZGVmaW5lIGEg bmV3IG1lc3NhZ2UsIGFuZCBsZXQNCmVhY2ggbWVzc2FnZSBwZXJmb3JtIGp1c3Qgb25lIGZ1bmN0 aW9uIHdlbGwuDQoNCg0KPg0KDQo= From julien.meuric@orange.com Fri Nov 4 02:01:47 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A10721F8BF7 for ; Fri, 4 Nov 2011 02:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlTg2Xi+xhxp for ; Fri, 4 Nov 2011 02:01:46 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 1E01521F8BF4 for ; Fri, 4 Nov 2011 02:01:46 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 45551B58007 for ; Fri, 4 Nov 2011 10:11:49 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 40AE2858001 for ; Fri, 4 Nov 2011 10:11:49 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Nov 2011 10:01:45 +0100 Received: from [10.193.71.201] ([10.193.71.201]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Nov 2011 10:01:45 +0100 Message-ID: <4EB3A9F8.40305@orange.com> Date: Fri, 04 Nov 2011 10:01:44 +0100 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: pce@ietf.org References: <4E9C25D9.3070609@orange.com> In-Reply-To: <4E9C25D9.3070609@orange.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 04 Nov 2011 09:01:45.0075 (UTC) FILETIME=[608ED430:01CC9AD0] Subject: Re: [Pce] Building the PCE Agenda X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 09:01:47 -0000 Dear WG. The draft agenda for the PCE meeting in Taipei is on line: http://www.ietf.org/proceedings/82/agenda/pce.html You will notice we have a tight schedule. Presenters will be asked to stick to their time slots while keeping in mind that questions (and answers) are part of the slots. If you have any comment, please contact both chairs and secretary. Thank you, JP & Julien Le 17/10/2011 14:55, Julien Meuric a écrit : > Hi PCE WG. > > If you intend to present during our meeting in Taipei, please send a > message to _both_ chairs and secretary not later than Monday 31st > October. Include the I-D/presentation title, the estimated duration > and the (forecast) presenter's name. > > Like last time, please keep in mind that individual I-Ds which have > not been publicly discussed _on list_ since their previous > presentation will be disregarded for the agenda. > > Thank you, > > JP & Julien > > _______________________________________________ Pce mailing list > Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce > From daniel@olddog.co.uk Fri Nov 4 10:50:30 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673ED21F8BE5 for ; Fri, 4 Nov 2011 10:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.199 X-Spam-Level: X-Spam-Status: No, score=-102.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3h5gnQJ2xs8H for ; Fri, 4 Nov 2011 10:50:30 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 978E321F8BA6 for ; Fri, 4 Nov 2011 10:50:29 -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 pA4HoPOt024512 for ; Fri, 4 Nov 2011 17:50:26 GMT Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id pA4HoOsP024502 for ; Fri, 4 Nov 2011 17:50:25 GMT From: "Daniel King" To: Date: Fri, 4 Nov 2011 17:50:19 -0000 Message-ID: <00d201cc9b1a$387ca6d0$a975f470$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcybGZ/cymxcmqxyS/Kef7Wf+XoKyw== Content-Language: en-gb Subject: Re: [Pce] Building the PCE Agenda [Presentation Slides] X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 17:50:30 -0000 Hi All, Please send me, CC'ing our co-chairs, your slides for IETF 82 no later = than Monday, 14 November . =20 This will allow us to upload the slides before the WG session. This is especially useful for our non-native English speakers to review and = print out the slides before our session, and for remote participants (Jabber, = et al.) to follow the presentation/discussions during the session. See you in Taipei! =09 Br, Dan.=20 -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of = Julien Meuric Sent: 04 November 2011 09:02 To: pce@ietf.org Subject: Re: [Pce] Building the PCE Agenda Dear WG. The draft agenda for the PCE meeting in Taipei is on line:=20 http://www.ietf.org/proceedings/82/agenda/pce.html You will notice we have a tight schedule. Presenters will be asked to = stick to their time slots while keeping in mind that questions (and answers) are part of the slots. If you have any comment, please contact both chairs and secretary. Thank you, JP & Julien Le 17/10/2011 14:55, Julien Meuric a =E9crit : > Hi PCE WG. > > If you intend to present during our meeting in Taipei, please send a = > message to _both_ chairs and secretary not later than Monday 31st =20 > October. Include the I-D/presentation title, the estimated duration =20 > and the (forecast) presenter's name. > > Like last time, please keep in mind that individual I-Ds which have =20 > not been publicly discussed _on list_ since their previous =20 > presentation will be disregarded for the agenda. > > Thank you, > > JP & Julien > > _______________________________________________ Pce mailing list =20 > Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From jmedved@juniper.net Fri Nov 4 18:00:57 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C9121F8888 for ; Fri, 4 Nov 2011 18:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.461 X-Spam-Level: X-Spam-Status: No, score=-6.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58JTBHG++yPD for ; Fri, 4 Nov 2011 18:00:56 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 00C4A21F8880 for ; Fri, 4 Nov 2011 18:00:55 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Fri, 04 Nov 2011 18:00:56 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 4 Nov 2011 17:58:51 -0700 From: Jan Medved To: Ina Minei , "pce@ietf.org" , Edward Crabbe , Robert Varga Date: Fri, 4 Nov 2011 17:58:47 -0700 Thread-Topic: Comments on the capability negotiation in draft-crabbe-pce-stateful-pce-01.txt Thread-Index: AcybVhUpRjRfT9DIQRSIURsY7KwDAA== Message-ID: In-Reply-To: <189716C74BBB9C4095FE8CA503B1FC3A571DD18DF3@EMBX02-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Pce] Comments on the capability negotiation in draft-crabbe-pce-stateful-pce-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 01:00:57 -0000 Hi Ina, Thanks for the suggestion, good point. We will incorporate it in the next revision of the document. /Jan On 10/31/11 4:27 PM, "Ina Minei" wrote: >All,=20 > > >Some thoughts around the extensibility of the stateful PCE capability >negotiation mechanism defined in this draft. Stateful PCE capability is >currently advertised as a single bit in the PCE capability TLV. This >works well under two assumptions: 1) all implementations of the draft >support setting the attributes currently defined, and 2) no new >attributes (or support for vendor-specific attributes) will be added in >the future.=20 > >In the event more attributes need to be supported in the future, there >needs to be a way to ensure that the PCC and the PCE can agree on what is >supported by each end. One way to accomplish this is by sending error >messages when a request comes in for an unsupported attribute, and >another is by explicitly advertising the supported attributes and >agreeing on a common set (or closing the session if this is >unacceptable).=20 > >I believe explicit negotiation gives more flexibility and cleaner >implementation. Here is strawman proposal: > >* Capabilities are advertised at the time the session is set up, in a >capabilities tlv, with sub-tlvs for every attribute supported. >* When receiving the advertisement, each end has to decide if they like >what the other end supports, and may choose to close the session and send >an error message if it doesn't like the capabilities supported by the >other end.=20 >* After the advertisements, it is assumed that each end will honor what >the other end advertised. However, if this is not the case, the request >is ignored and an error sent. For example, if capability A, B were >advertised, but PCE sets A, B, C, then the entire request is ignored and >error sent (this would be the result of a software bug). > >Thank you,=20 > >Ina=20 > From tang.kexin@zte.com.cn Fri Nov 4 18:18:49 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71A51F0C50 for ; Fri, 4 Nov 2011 18:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.755 X-Spam-Level: X-Spam-Status: No, score=-98.755 tagged_above=-999 required=5 tests=[AWL=1.883, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_53=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9w0rfoxYEyh for ; Fri, 4 Nov 2011 18:18:48 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 1A32C1F0C4F for ; Fri, 4 Nov 2011 18:18:47 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 566901441414862; Sat, 5 Nov 2011 09:09:13 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 20387.1441414862; Sat, 5 Nov 2011 09:18:36 +0800 (CST) Received: (from root@localhost) by mse01.zte.com.cn id pA51Ia6c050781 for ; Sat, 5 Nov 2011 09:18:36 +0800 (GMT-8) (envelope-from tang.kexin@zte.com.cn) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id pA4ADcpc075316; Fri, 4 Nov 2011 18:13:38 +0800 (GMT-8) (envelope-from tang.kexin@zte.com.cn) Message-Id: <201111050118.pA51Ia6c050781@mse01.zte.com.cn> In-Reply-To: To: Jan Medved MIME-Version: 1.0 X-KeepSent: 548A5DD8:CB728D6D-4825793E:00347282; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 From: tang.kexin@zte.com.cn Date: Fri, 4 Nov 2011 18:13:25 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-11-04 18:13:40, Serialize complete at 2011-11-04 18:13:40 Content-Type: multipart/alternative; boundary="=_alternative 0038713E4825793E_=" X-MAIL: mse01.zte.com.cn pA51Ia6c050781 X-MSS: AUDITRELEASE@mse01.zte.com.cn Cc: pce-bounces@ietf.org, "pce@ietf.org" , Robert Varga Subject: Re: [Pce] New Version Notification for draft-crabbe-pce-stateful-pce-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 01:18:49 -0000 This is a multipart message in MIME format. --=_alternative 0038713E4825793E_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgSmFuLA0KDQpUaGFua3MgZm9yIHlvdXIgcmVwbHkseW91IG1lbnRpb25lZCB5b3VyIG9iamVj dGl2ZXMgYXMgZm9sbG93czoNCg0KICAgIFRoZSBvYmplY3RpdmVzIG9mIGRyYWZ0LWNyYWJiZS1w Y2Utc3RhdGVmdWwtcGNlIGFyZSB0d29mb2xkOg0KDQogICAgKiBLZWVwIGEgc3RhdGVmdWwgUENF IHN5bmNocm9uaXplZCB3aXRoIHRoZSBzdGF0ZSBvZiBMU1BzIGluIGEgUENDOyANCnRoaXMNCiAg ICBvYmplY3RpdmUgaXMgdGhlIHNhbWUgYXMgdGhlIG9iamVjdGl2ZSBvZiBkcmFmdC10YW5nLXBj ZS1zdGF0ZWZ1bC1wY2UuDQogICAgKiBBbGxvdyBhIHN0YXRlZnVsIFBDRSB0byBkZXRlcm1pbmUg dGhlIHRpbWluZyBvZiBMU1Agc2V0dXAgaW4gdGhlIA0KbmV0d29yaw0KICAgIChpbiBhZGRpdGlv biB0byBkZXRlcm1pbmluZyB0aGUgTFNQIHBhdGhzIHRocm91Z2ggdGhlIG5ldHdvcmspLg0KDQpU aGUgMXN0IG9iamVjdGl2ZSBpcyBjb21tb24gZm9yIGJvdGggZHJhZnRzLCB3aGljaCBjb25zaXN0 ZW50IHdpdGggdGhlIA0KZGVmaW5pdGlvbiBvZiBzdGF0ZWZ1bCBQQ0UgZGVzY3JpYmVkIGluIFJG QzQ2NTUsIA0KYW5kIEkgdGhpbmsgaXQgaXMgdGhlIG1haW4gcHJvYmxlbSB0byByZWFsaXplIHN0 YXRlZnVsIFBDRSBJIHRoaW5rLg0KDQpBcyB0byB0aGUgMm5kIG9iamVjdGl2ZSB5b3UgZGVzY3Jp YmVkICwgSSB3YXMgbm90IHN1cmUgYWJvdXQgdGhlIG1haW4gdXNlIA0KY2FzZXMgb2YgYWN0aXZl IHN0YXRlZnVsIFBDRS4NCklzIGl0IHdoZW4gdGhlIFBDRSBjYW4gbm90IGNvbXB1dGUgYSBwYXRo IGZvciB0aGUgdXBjb21pbmcgTFNQLHRoZW4gdGhlIA0KUENFIGNoYW5nZSB0aGUgZXhpc3Rpbmcg InBlbmRpbmciTFNQIHRvICJkb3duIiwNCnNvIGFzIHRvIG1heGltaXplIHRoZSBuZXR3b3JrIHJl c291cmVjZSB1dGlsaXphdGlvbiBvciBmb3Igb3RoZXIgDQpvcHRpbWl6YXRpb24gb2JqZWN0aXZl LGFjY29yZGluZyB0byBzb21lIHBvbGljeT8NCg0KVGhhbmtzLA0KS2V4aW4NCg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpLZXhpbiBUYW5n DQpDb250cm9sIFBsYW5lIEVuZ2luZWVyDQpaVEUgQ29ycG9yYXRpb24gDQoNCmFkZHJlc3M6IE5v LjUwIFNvZnR3YXJlIEF2ZW51ZSwgWXVodWF0YWkgRGlzdHJpY3QsDQogICAgICAgICBOYW5qaW5n LEppYW5nc3UsIFAuUi5DaGluYSwyMTAwMTINCnBob25lOiAgIDEzODE1ODcxMjA2DQplbWFpbDog ICB0YW5nLmtleGluQHp0ZS5jb20uY24NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCkhpIEtleGluLA0KDQpUaGFua3MgZm9yIHRoZSBj b21tZW50cywgcGxlYXNlIHNlZSBiZWxvdy4NCg0KDQovSmFuDQoNCg0KT24gMTEvMS8xMSAxMTo0 OCBQTSwgInRhbmcua2V4aW5AenRlLmNvbS5jbiIgPHRhbmcua2V4aW5AenRlLmNvbS5jbj4gDQp3 cm90ZToNCg0KDQo+SSB0aGluayB0aGUgb2JqZWN0aXZlIG9mIHRoZSB0d28gZHJhZnQgYXJlIHRo ZSBzYW1lIHRoYXQgc3RhdGVmdWwgUENFDQo+c3luY2hyb25pemVkIHdpdGggdGhlIHN0YXRlIG9m IExTUHMgYWx0aG91Z2ggYnkgZGlmZmVyZW50IG1lY2hhbmlzbS4NCg0KVGhlIG9iamVjdGl2ZXMg b2YgZHJhZnQtY3JhYmJlLXBjZS1zdGF0ZWZ1bC1wY2UgYXJlIHR3b2ZvbGQ6DQoNCiogS2VlcCBh IHN0YXRlZnVsIFBDRSBzeW5jaHJvbml6ZWQgd2l0aCB0aGUgc3RhdGUgb2YgTFNQcyBpbiBhIFBD QzsgdGhpcw0Kb2JqZWN0aXZlIGlzIHRoZSBzYW1lIGFzIHRoZSBvYmplY3RpdmUgb2YgZHJhZnQt dGFuZy1wY2Utc3RhdGVmdWwtcGNlLg0KKiBBbGxvdyBhIHN0YXRlZnVsIFBDRSB0byBkZXRlcm1p bmUgdGhlIHRpbWluZyBvZiBMU1Agc2V0dXAgaW4gdGhlIG5ldHdvcmsNCihpbiBhZGRpdGlvbiB0 byBkZXRlcm1pbmluZyB0aGUgTFNQIHBhdGhzIHRocm91Z2ggdGhlIG5ldHdvcmspLg0KDQpXZSBj YWxsIHRoZSBQQ0UgdGhhdCBvbmx5IHdpc2hlcyB0byBrbm93IHRoZSBMU1Agc3RhdGUgdGhlICdw YXNzaXZlDQpzdGF0ZWZ1bCBQQ0UnLiBXZSBjYWxsIHRoZSBQQ0UgdGhhdCBjb250cm9scyB0aGUg dGltaW5nIG9mIExTUCBzZXR1cHMgaW4NCnRoZSBuZXR3b3JrIHRoZSAnYWN0aXZlIHN0YXRlZnVs IFBDRScuDQoNCj4NCj5Zb3UgZGVmaW5lZCB0d28gbmV3IFBDRVAgbWVzc2FnZXMgKFBDUnB0IGFu ZCBQQ1VwZCksIHdoaWxlIHdlIGV4dGVuZGVkDQo+dGhlIGV4aXN0aW5nIFBDTnRmIG1lc3NhZ2Uu DQoNCldlIGNvbnNpZGVyZWQgZXh0ZW5kaW5nIHRoZSBQQ050ZiBtZXNzYWdlLCBidXQgaW4gdGhl IGVuZCBkZWNpZGVkIHRvIHRvDQpkZWZpbmUgYSBuZXcgbWVzc2FnZSBmb3IgTFNQIFN0YXRlIFJl cG9ydGluZyAoUENScHQpLiBXZSBkZWZpbmVkIHRoZSBQQ1VwZA0KbWVzc2FnZSB0byBzYXRpc2Z5 IHRoZSBvdGhlciBvYmplY3RpdmUgb2YgZHJhZnQtY3JhYmJlLXBjZS1zdGF0ZWZ1bC1wY2Ugwq0N CnRoZSBhY3RpdmUgY29udHJvbCBvZiBMU1BzIGJ5IGEgUENFLg0KDQpUaGVyZSBhcmUgZ29vZCBy ZWFzb25zIHRvIGRlZmluZSBhIG5ldyBtZXNzYWdlIGZvciBMU1AgU3RhdGUgUmVwb3J0aW5nLiAg SQ0KdGhpbmsgd2UgYXJlIGJvdGggYWdyZWVtZW50IHRoYXQgYW4gTFNQIHN0YXRlIHJlcG9ydC9u b3RpZmljYXRpb24gbXVzdA0KY2FycnkgYSBzZXQgb2YgTFNQIGF0dHJpYnV0ZXMgdGhhdCBkZXNj cmliZSB0aGUgTFNQJ3Mgc3RhdGUuIE5vdywgaWYgd2UNCndhbnQgdG8gcmUtdXNlIHRoZSBQQ050 ZiBtZXNzYWdlIGZvciBMU1Agc3RhdGUgcmVwb3J0cyAvIG5vdGlmaWNhdGlvbnMsIHdlDQpjYW4g ZWl0aGVyIGRlZmluZSBpbiB0aGUgTk9USUZJQ0FUSU9OIE9iamVjdCBhIHNldCBvZiBvcHRpb25h bCBUTFZzIHRoYXQNCmNhbiBjYXJyeSB0aGUgTFNQIGF0dHJpYnV0ZXMsIG9yIHJlZGVmaW5lIHRo ZSBQQ050ZiBtZXNzYWdlIGl0c2VsZiB0byB1c2UNCmFscmVhZHkgZGVmaW5lZCBQQ0VQIE9iamVj dHMgdG8gY2FycnkgTFNQIGF0dHJpYnV0ZXMuDQoNClRoZSBUTFYgYXBwcm9hY2ggaXMgbm90IGlk ZWFsOiB3ZSBhbHJlYWR5IGhhdmUgYSBzZXQgb2YgUENFUCBPYmplY3RzIHRoYXQNCmNhbiBjYXJy eSB0aGUgTFNQIGF0dHJpYnV0ZXMsIG5vdyB3ZSB3b3VsZCBoYXZlIHRvIGRlZmluZSBhbGwgb2Yg dGhlbSBhcw0KVExWcyBhcyB3ZWxsLiBBbmQgaWYgbmV3IExTUCBhdHRyaWJ1dGVzIGFyZSBpbnRy b2R1Y2VkIHRvIHRoZSBQQ0VQDQpwcm90b2NvbCBpbiB0aGUgZnV0dXJlLCB0aGUgbWF5IGhhdmUg dG8gYmUgZGVmaW5lZCBib3RoIGluIFBDRVAgT2JqZWN0cw0KYW5kIGluIE5PVElGSUNBVElPTiBU TFZzLg0KDQpUaGUgYXBwcm9hY2ggd2hlcmUgdGhlIFBDTnRmIG1lc3NhZ2UgaXMgcmVkZWZpbmVk IGlzIG5vdCBpZGVhbCBlaXRoZXIuIEZvcg0Kb25lLCB3ZSBtYXkgYmUgYnJlYWtpbmcgZXhpc3Rp bmcgaW1wbGVtZW50YXRpb25zIGJlY2F1c2Ugd2UgYXJlIHJlZGVmaW5pbmcNCnRoZSBtZXNzYWdl IGFuZCBub3QgdXNpbmcgb3B0aW9uYWwgVExWcyB0byBkZWZpbmUgbmV3IGZ1bmN0aW9uYWxpdHku DQooTm90ZSB0aGF0IHdpdGggYSBuZXcgbWVzc2FnZSB3ZSBhcmUgbm90IGJyZWFraW5nIGV4aXN0 aW5nDQppbXBsZW1lbnRhdGlvbnMsIGJlY2F1c2UgbmV3IG1lc3NhZ2VzIGFyZSBvbmx5IHVzZWQg aWYgc3RhdGVmdWwNCmNhcGFiaWxpdGllcyBhcmUgbmVnb3RpYXRlZCBiZXR3ZWVuIFBDRVAgU3Bl YWtlcnMpLiBTZWNvbmQsIHRoZSBQQ050Zg0KbWVzc2FnZSBhcyBjdXJyZW50bHkgZGVmaW5lZCBp biBQQ0VQIHNlZW1zIHRvIGJlIGRlc2lnbmVkIGZvciBQQ0VQIGV2ZW50cw0KKFBDRSBjb25nZXN0 aW9uLCBjYW5jZWxsYXRpb24gb2YgUGVuZGluZyBSZXF1ZXN0cywgxaApLCBhbmQgY2hhbmdpbmcg aXRzDQpzZW1hbnRpY3MgdG8gY2FycnkgYm90aCBQQ0VQIGV2ZW50cyBhbmQgTFNQIHN0YXRlIGRv ZXMgbm90IHNlZW0gdG8gYmUgdGhlDQpyaWdodCB0aGluZyB0byBkby4gRmluYWxseSwgcmVkZWZp bmluZyB0aGUgUENOdGYgbWVzc2FnZSBjaGFuZ2VzIGl0cw0Kc3RydWN0dXJlIHRvIGEgcG9pbnQg d2hlcmUgd2UgbWF5IGFzIHdlbGwgZGVmaW5lIGEgbmV3IG1lc3NhZ2UsIGFuZCBsZXQNCmVhY2gg bWVzc2FnZSBwZXJmb3JtIGp1c3Qgb25lIGZ1bmN0aW9uIHdlbGwuDQoNCg0KPg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUGNlIG1haWxpbmcgbGlz dA0KUGNlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bj ZQ0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0 aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5k ZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlh bC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3Jl Y3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlz IGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5z bWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0 aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJl c3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90 aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGlu IHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBt ZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGkt U3BhbSBzeXN0ZW0uDQo= --=_alternative 0038713E4825793E_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEphbiw8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyBmb3IgeW91ciByZXBs eSx5b3UgbWVudGlvbmVkDQp5b3VyIG9iamVjdGl2ZXMgYXMgZm9sbG93czo8L2ZvbnQ+DQo8YnI+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mbmJzcDsgJm5ic3A7IFRoZSBvYmplY3RpdmVzIG9mIGRy YWZ0LWNyYWJiZS1wY2Utc3RhdGVmdWwtcGNlDQphcmUgdHdvZm9sZDo8YnI+DQo8YnI+DQogJm5i c3A7ICZuYnNwOyogS2VlcCBhIHN0YXRlZnVsIFBDRSBzeW5jaHJvbml6ZWQgd2l0aCB0aGUgc3Rh dGUgb2YgTFNQcw0KaW4gYSBQQ0M7IHRoaXM8YnI+DQogJm5ic3A7ICZuYnNwO29iamVjdGl2ZSBp cyB0aGUgc2FtZSBhcyB0aGUgb2JqZWN0aXZlIG9mIGRyYWZ0LXRhbmctcGNlLXN0YXRlZnVsLXBj ZS48YnI+DQogJm5ic3A7ICZuYnNwOyogQWxsb3cgYSBzdGF0ZWZ1bCBQQ0UgdG8gZGV0ZXJtaW5l IHRoZSB0aW1pbmcgb2YgTFNQIHNldHVwDQppbiB0aGUgbmV0d29yazxicj4NCiAmbmJzcDsgJm5i c3A7KGluIGFkZGl0aW9uIHRvIGRldGVybWluaW5nIHRoZSBMU1AgcGF0aHMgdGhyb3VnaCB0aGUg bmV0d29yaykuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5UaGUgMXN0 IG9iamVjdGl2ZSBpcyBjb21tb24gZm9yIGJvdGggZHJhZnRzLCB3aGljaA0KY29uc2lzdGVudCB3 aXRoIHRoZSBkZWZpbml0aW9uIG9mIHN0YXRlZnVsIFBDRSBkZXNjcmliZWQgaW4gUkZDNDY1NSwg PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5hbmQgSSB0aGluayBpdCBpcyB0aGUg bWFpbiBwcm9ibGVtIHRvIHJlYWxpemUgc3RhdGVmdWwNClBDRSBJIHRoaW5rLjwvZm9udD48L3R0 Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+QXMgdG8gdGhlIDJuZCBvYmplY3RpdmUgeW91 IGRlc2NyaWJlZCAsIEkgd2FzIG5vdA0Kc3VyZSBhYm91dCB0aGUgbWFpbiB1c2UgY2FzZXMgb2Yg YWN0aXZlIHN0YXRlZnVsIFBDRS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPklz IGl0IHdoZW4gdGhlIFBDRSBjYW4gbm90IGNvbXB1dGUgYSBwYXRoIGZvciB0aGUNCnVwY29taW5n IExTUCx0aGVuIHRoZSBQQ0UgY2hhbmdlIHRoZSBleGlzdGluZyAmcXVvdDtwZW5kaW5nJnF1b3Q7 TFNQIHRvDQomcXVvdDtkb3duJnF1b3Q7LDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+c28gYXMgdG8gbWF4aW1pemUgdGhlIG5ldHdvcmsgcmVzb3VyZWNlIHV0aWxpemF0aW9uDQpv ciBmb3Igb3RoZXIgb3B0aW1pemF0aW9uIG9iamVjdGl2ZSxhY2NvcmRpbmcgdG8gc29tZSBwb2xp Y3k/PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5UaGFua3MsPC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5LZXhpbjwvZm9udD48L3R0Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpLZXhpbiBUYW5nPGJyPg0KQ29udHJv bCBQbGFuZSBFbmdpbmVlcjxicj4NClpURSBDb3Jwb3JhdGlvbiA8YnI+DQo8YnI+DQphZGRyZXNz OiBOby41MCBTb2Z0d2FyZSBBdmVudWUsIFl1aHVhdGFpIERpc3RyaWN0LDxicj4NCiAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgTmFuamluZyxKaWFuZ3N1LCBQLlIuQ2hpbmEsMjEwMDEyPGJy Pg0KcGhvbmU6ICZuYnNwOyAxMzgxNTg3MTIwNjxicj4NCmVtYWlsOiAmbmJzcDsgdGFuZy5rZXhp bkB6dGUuY29tLmNuPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ SGkgS2V4aW4sPGJyPg0KPGJyPg0KVGhhbmtzIGZvciB0aGUgY29tbWVudHMsIHBsZWFzZSBzZWUg YmVsb3cuPGJyPg0KPGJyPg0KPGJyPg0KL0phbjxicj4NCjxicj4NCjxicj4NCk9uIDExLzEvMTEg MTE6NDggUE0sICZxdW90O3Rhbmcua2V4aW5AenRlLmNvbS5jbiZxdW90OyAmbHQ7dGFuZy5rZXhp bkB6dGUuY29tLmNuJmd0Ow0Kd3JvdGU6PGJyPg0KPGJyPg0KPGJyPg0KJmd0O0kgdGhpbmsgdGhl IG9iamVjdGl2ZSBvZiB0aGUgdHdvIGRyYWZ0IGFyZSB0aGUgc2FtZSB0aGF0IHN0YXRlZnVsIFBD RTxicj4NCiZndDtzeW5jaHJvbml6ZWQgd2l0aCB0aGUgc3RhdGUgb2YgTFNQcyBhbHRob3VnaCBi eSBkaWZmZXJlbnQgbWVjaGFuaXNtLjxicj4NCjxicj4NClRoZSBvYmplY3RpdmVzIG9mIGRyYWZ0 LWNyYWJiZS1wY2Utc3RhdGVmdWwtcGNlIGFyZSB0d29mb2xkOjxicj4NCjxicj4NCiogS2VlcCBh IHN0YXRlZnVsIFBDRSBzeW5jaHJvbml6ZWQgd2l0aCB0aGUgc3RhdGUgb2YgTFNQcyBpbiBhIFBD QzsgdGhpczxicj4NCm9iamVjdGl2ZSBpcyB0aGUgc2FtZSBhcyB0aGUgb2JqZWN0aXZlIG9mIGRy YWZ0LXRhbmctcGNlLXN0YXRlZnVsLXBjZS48YnI+DQoqIEFsbG93IGEgc3RhdGVmdWwgUENFIHRv IGRldGVybWluZSB0aGUgdGltaW5nIG9mIExTUCBzZXR1cCBpbiB0aGUgbmV0d29yazxicj4NCihp biBhZGRpdGlvbiB0byBkZXRlcm1pbmluZyB0aGUgTFNQIHBhdGhzIHRocm91Z2ggdGhlIG5ldHdv cmspLjxicj4NCjxicj4NCldlIGNhbGwgdGhlIFBDRSB0aGF0IG9ubHkgd2lzaGVzIHRvIGtub3cg dGhlIExTUCBzdGF0ZSB0aGUgJ3Bhc3NpdmU8YnI+DQpzdGF0ZWZ1bCBQQ0UnLiBXZSBjYWxsIHRo ZSBQQ0UgdGhhdCBjb250cm9scyB0aGUgdGltaW5nIG9mIExTUCBzZXR1cHMgaW48YnI+DQp0aGUg bmV0d29yayB0aGUgJ2FjdGl2ZSBzdGF0ZWZ1bCBQQ0UnLjxicj4NCjxicj4NCiZndDs8YnI+DQom Z3Q7WW91IGRlZmluZWQgdHdvIG5ldyBQQ0VQIG1lc3NhZ2VzIChQQ1JwdCBhbmQgUENVcGQpLCB3 aGlsZSB3ZSBleHRlbmRlZDxicj4NCiZndDt0aGUgZXhpc3RpbmcgUENOdGYgbWVzc2FnZS48YnI+ DQo8YnI+DQpXZSBjb25zaWRlcmVkIGV4dGVuZGluZyB0aGUgUENOdGYgbWVzc2FnZSwgYnV0IGlu IHRoZSBlbmQgZGVjaWRlZCB0byB0bzxicj4NCmRlZmluZSBhIG5ldyBtZXNzYWdlIGZvciBMU1Ag U3RhdGUgUmVwb3J0aW5nIChQQ1JwdCkuIFdlIGRlZmluZWQgdGhlIFBDVXBkPGJyPg0KbWVzc2Fn ZSB0byBzYXRpc2Z5IHRoZSBvdGhlciBvYmplY3RpdmUgb2YgZHJhZnQtY3JhYmJlLXBjZS1zdGF0 ZWZ1bC1wY2UNCsKtPGJyPg0KdGhlIGFjdGl2ZSBjb250cm9sIG9mIExTUHMgYnkgYSBQQ0UuPGJy Pg0KPGJyPg0KVGhlcmUgYXJlIGdvb2QgcmVhc29ucyB0byBkZWZpbmUgYSBuZXcgbWVzc2FnZSBm b3IgTFNQIFN0YXRlIFJlcG9ydGluZy4NCiZuYnNwO0k8YnI+DQp0aGluayB3ZSBhcmUgYm90aCBh Z3JlZW1lbnQgdGhhdCBhbiBMU1Agc3RhdGUgcmVwb3J0L25vdGlmaWNhdGlvbiBtdXN0PGJyPg0K Y2FycnkgYSBzZXQgb2YgTFNQIGF0dHJpYnV0ZXMgdGhhdCBkZXNjcmliZSB0aGUgTFNQJ3Mgc3Rh dGUuIE5vdywgaWYgd2U8YnI+DQp3YW50IHRvIHJlLXVzZSB0aGUgUENOdGYgbWVzc2FnZSBmb3Ig TFNQIHN0YXRlIHJlcG9ydHMgLyBub3RpZmljYXRpb25zLA0Kd2U8YnI+DQpjYW4gZWl0aGVyIGRl ZmluZSBpbiB0aGUgTk9USUZJQ0FUSU9OIE9iamVjdCBhIHNldCBvZiBvcHRpb25hbCBUTFZzIHRo YXQ8YnI+DQpjYW4gY2FycnkgdGhlIExTUCBhdHRyaWJ1dGVzLCBvciByZWRlZmluZSB0aGUgUENO dGYgbWVzc2FnZSBpdHNlbGYgdG8gdXNlPGJyPg0KYWxyZWFkeSBkZWZpbmVkIFBDRVAgT2JqZWN0 cyB0byBjYXJyeSBMU1AgYXR0cmlidXRlcy48YnI+DQo8YnI+DQpUaGUgVExWIGFwcHJvYWNoIGlz IG5vdCBpZGVhbDogd2UgYWxyZWFkeSBoYXZlIGEgc2V0IG9mIFBDRVAgT2JqZWN0cyB0aGF0PGJy Pg0KY2FuIGNhcnJ5IHRoZSBMU1AgYXR0cmlidXRlcywgbm93IHdlIHdvdWxkIGhhdmUgdG8gZGVm aW5lIGFsbCBvZiB0aGVtIGFzPGJyPg0KVExWcyBhcyB3ZWxsLiBBbmQgaWYgbmV3IExTUCBhdHRy aWJ1dGVzIGFyZSBpbnRyb2R1Y2VkIHRvIHRoZSBQQ0VQPGJyPg0KcHJvdG9jb2wgaW4gdGhlIGZ1 dHVyZSwgdGhlIG1heSBoYXZlIHRvIGJlIGRlZmluZWQgYm90aCBpbiBQQ0VQIE9iamVjdHM8YnI+ DQphbmQgaW4gTk9USUZJQ0FUSU9OIFRMVnMuPGJyPg0KPGJyPg0KVGhlIGFwcHJvYWNoIHdoZXJl IHRoZSBQQ050ZiBtZXNzYWdlIGlzIHJlZGVmaW5lZCBpcyBub3QgaWRlYWwgZWl0aGVyLg0KRm9y PGJyPg0Kb25lLCB3ZSBtYXkgYmUgYnJlYWtpbmcgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIGJl Y2F1c2Ugd2UgYXJlIHJlZGVmaW5pbmc8YnI+DQp0aGUgbWVzc2FnZSBhbmQgbm90IHVzaW5nIG9w dGlvbmFsIFRMVnMgdG8gZGVmaW5lIG5ldyBmdW5jdGlvbmFsaXR5Ljxicj4NCihOb3RlIHRoYXQg d2l0aCBhIG5ldyBtZXNzYWdlIHdlIGFyZSBub3QgYnJlYWtpbmcgZXhpc3Rpbmc8YnI+DQppbXBs ZW1lbnRhdGlvbnMsIGJlY2F1c2UgbmV3IG1lc3NhZ2VzIGFyZSBvbmx5IHVzZWQgaWYgc3RhdGVm dWw8YnI+DQpjYXBhYmlsaXRpZXMgYXJlIG5lZ290aWF0ZWQgYmV0d2VlbiBQQ0VQIFNwZWFrZXJz KS4gU2Vjb25kLCB0aGUgUENOdGY8YnI+DQptZXNzYWdlIGFzIGN1cnJlbnRseSBkZWZpbmVkIGlu IFBDRVAgc2VlbXMgdG8gYmUgZGVzaWduZWQgZm9yIFBDRVAgZXZlbnRzPGJyPg0KKFBDRSBjb25n ZXN0aW9uLCBjYW5jZWxsYXRpb24gb2YgUGVuZGluZyBSZXF1ZXN0cywgxaApLCBhbmQgY2hhbmdp bmcgaXRzPGJyPg0Kc2VtYW50aWNzIHRvIGNhcnJ5IGJvdGggUENFUCBldmVudHMgYW5kIExTUCBz dGF0ZSBkb2VzIG5vdCBzZWVtIHRvIGJlIHRoZTxicj4NCnJpZ2h0IHRoaW5nIHRvIGRvLiBGaW5h bGx5LCByZWRlZmluaW5nIHRoZSBQQ050ZiBtZXNzYWdlIGNoYW5nZXMgaXRzPGJyPg0Kc3RydWN0 dXJlIHRvIGEgcG9pbnQgd2hlcmUgd2UgbWF5IGFzIHdlbGwgZGVmaW5lIGEgbmV3IG1lc3NhZ2Us IGFuZCBsZXQ8YnI+DQplYWNoIG1lc3NhZ2UgcGVyZm9ybSBqdXN0IG9uZSBmdW5jdGlvbiB3ZWxs Ljxicj4NCjxicj4NCjxicj4NCiZndDs8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClBjZSBtYWlsaW5nIGxpc3Q8YnI+DQpQY2VA aWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjZTxi cj4NCjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24m bmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNw O2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVs eSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2Fu aXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZu YnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZu YnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5 Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtk aXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29t bXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5k Jm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZu YnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29s ZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRp dmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5i c3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3Jl Y2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFz ZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZu YnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZu YnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3Ro ZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hh cyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZu YnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwv cHJlPg== --=_alternative 0038713E4825793E_=-- From jmedved@juniper.net Sat Nov 5 21:32:02 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42AAE1F0C38 for ; Sat, 5 Nov 2011 21:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.881 X-Spam-Level: X-Spam-Status: No, score=-5.881 tagged_above=-999 required=5 tests=[AWL=-0.482, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71LUyiHkq9If for ; Sat, 5 Nov 2011 21:32:01 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0681F0C36 for ; Sat, 5 Nov 2011 21:32:00 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Sat, 05 Nov 2011 21:32:01 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Sat, 5 Nov 2011 21:29:27 -0700 From: Jan Medved To: "tang.kexin@zte.com.cn" Date: Sat, 5 Nov 2011 21:29:25 -0700 Thread-Topic: [Pce] Re:New Version Notification for draft-crabbe-pce-stateful-pce-01.txt Thread-Index: AcycPKsW6U1KU/yVQRefcI+KFtlrdQ== Message-ID: In-Reply-To: <201111050118.pA51IcnO050816@mse01.zte.com.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "pce@ietf.org" , Robert Varga Subject: Re: [Pce] New Version Notification for draft-crabbe-pce-stateful-pce-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2011 04:32:02 -0000 SGkgS2V4aW4NCg0KVGhhbmtzIGZvciB0aGUgY29tbWVudHMsIHBsZWFzZSBzZWUgaW5saW5lLg0K DQoNCi9KYW4NCg0KDQpPbiAxMS80LzExIDM6MTMgQU0sICJ0YW5nLmtleGluQHp0ZS5jb20uY24i IDx0YW5nLmtleGluQHp0ZS5jb20uY24+IHdyb3RlOg0KDQoNCj4NCj5IaSBKYW4sDQo+DQo+VGhh bmtzIGZvciB5b3VyIHJlcGx5LHlvdSBtZW50aW9uZWQNCj55b3VyIG9iamVjdGl2ZXMgYXMgZm9s bG93czoNCj4NCj4gICAgVGhlIG9iamVjdGl2ZXMgb2YgZHJhZnQtY3JhYmJlLXBjZS1zdGF0ZWZ1 bC1wY2UgYXJlIHR3b2ZvbGQ6DQo+DQo+ICAgICogS2VlcCBhIHN0YXRlZnVsIFBDRSBzeW5jaHJv bml6ZWQgd2l0aCB0aGUgc3RhdGUgb2YgTFNQcyBpbiBhIFBDQzsNCj50aGlzDQo+ICAgIG9iamVj dGl2ZSBpcyB0aGUgc2FtZSBhcyB0aGUgb2JqZWN0aXZlIG9mIGRyYWZ0LXRhbmctcGNlLXN0YXRl ZnVsLXBjZS4NCj4gICAgKiBBbGxvdyBhIHN0YXRlZnVsIFBDRSB0byBkZXRlcm1pbmUgdGhlIHRp bWluZyBvZiBMU1Agc2V0dXAgaW4gdGhlDQo+bmV0d29yaw0KPiAgICAoaW4gYWRkaXRpb24gdG8g ZGV0ZXJtaW5pbmcgdGhlIExTUCBwYXRocyB0aHJvdWdoIHRoZSBuZXR3b3JrKS4NCj4NCj5UaGUg MXN0IG9iamVjdGl2ZSBpcyBjb21tb24gZm9yIGJvdGggZHJhZnRzLA0KDQpBZ3JlZWQuDQoNCj5X aGljaCBjb25zaXN0ZW50IHdpdGggdGhlIGRlZmluaXRpb24gb2Ygc3RhdGVmdWwgUENFIGRlc2Ny aWJlZA0KPmluIFJGQzQ2NTUsIGFuZCBJIHRoaW5rIGl0IGlzIHRoZSBtYWluIHByb2JsZW0gdG8g cmVhbGl6ZSBzdGF0ZWZ1bA0KPlBDRSBJIHRoaW5rLg0KPg0KPkFzIHRvIHRoZSAybmQgb2JqZWN0 aXZlIHlvdSBkZXNjcmliZWQgLCBJIHdhcyBub3QNCj5zdXJlIGFib3V0IHRoZSBtYWluIHVzZSBj YXNlcyBvZiBhY3RpdmUgc3RhdGVmdWwgUENFLg0KPklzIGl0IHdoZW4gdGhlIFBDRSBjYW4gbm90 IGNvbXB1dGUgYSBwYXRoIGZvciB0aGUNCj51cGNvbWluZyBMU1AsdGhlbiB0aGUgUENFIGNoYW5n ZSB0aGUgZXhpc3RpbmcgInBlbmRpbmciTFNQIHRvDQo+ImRvd24iLCBzbyBhcyB0byBtYXhpbWl6 ZSB0aGUgbmV0d29yayByZXNvdXJlY2UgdXRpbGl6YXRpb24NCj5vciBmb3Igb3RoZXIgb3B0aW1p emF0aW9uIG9iamVjdGl2ZSxhY2NvcmRpbmcgdG8gc29tZSBwb2xpY3k/DQoNClllcywgdGhhdCBj b3VsZCBiZSBvbmUgb2YgdGhlIHVzZSBjYXNlcyB0b28uDQoNClRoZSBwcmltYXJ5IG1vdGl2YXRp b24gZm9yIHRoZSBzZWNvbmQgb2JqZWN0aXZlIGlzIHRvIGdpdmUgYSBQQ0UgdGhlDQpjb250cm9s IG92ZXIgdGhlIHNlcXVlbmNlIGFuZCB0aW1pbmcgaW4gYWx0ZXJpbmcgTFNQIHBhdGggY2hhcmFj dGVyaXN0aWNzDQp3aXRoaW4gYW5kIGFjcm9zcyBQQ0VQIHNlc3Npb25zIChpbiBvdGhlciB3b3Jk cywgY29vcmRpbmF0ZSBMU1AgbW9kaWZpZXMNCmFjcm9zcyBtdWx0aXBsZSBQQ0NzKS4gSW4gdGhl IGRyYWZ0IHdlIGdpdmUgbXVsdGlwbGUgcmVhbC13b3JsZCBleGFtcGxlcw0KdGhhdCBkZW1vbnN0 cmF0ZSB0aGUgbmVlZCBmb3Igc3VjaCBjYXBhYmlsaXR5Lg0KDQo+DQo+VGhhbmtzLA0KPktleGlu DQo+DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+S2V4aW4gVGFuZw0KPkNvbnRyb2wgUGxhbmUgRW5naW5lZXINCj5aVEUgQ29ycG9yYXRp b24gDQo+DQo+YWRkcmVzczogTm8uNTAgU29mdHdhcmUgQXZlbnVlLCBZdWh1YXRhaSBEaXN0cmlj dCwNCj4gICAgICAgICBOYW5qaW5nLEppYW5nc3UsIFAuUi5DaGluYSwyMTAwMTINCj5waG9uZTog ICAxMzgxNTg3MTIwNg0KPmVtYWlsOiAgIHRhbmcua2V4aW5AenRlLmNvbS5jbg0KPi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0KPg0KPkhp IEtleGluLA0KPg0KPlRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLCBwbGVhc2Ugc2VlIGJlbG93Lg0K Pg0KPg0KPi9KYW4NCj4NCj4NCj5PbiAxMS8xLzExIDExOjQ4IFBNLCAidGFuZy5rZXhpbkB6dGUu Y29tLmNuIiA8dGFuZy5rZXhpbkB6dGUuY29tLmNuPg0KPndyb3RlOg0KPg0KPg0KPj5JIHRoaW5r IHRoZSBvYmplY3RpdmUgb2YgdGhlIHR3byBkcmFmdCBhcmUgdGhlIHNhbWUgdGhhdCBzdGF0ZWZ1 bCBQQ0UNCj4+c3luY2hyb25pemVkIHdpdGggdGhlIHN0YXRlIG9mIExTUHMgYWx0aG91Z2ggYnkg ZGlmZmVyZW50IG1lY2hhbmlzbS4NCj4NCj5UaGUgb2JqZWN0aXZlcyBvZiBkcmFmdC1jcmFiYmUt cGNlLXN0YXRlZnVsLXBjZSBhcmUgdHdvZm9sZDoNCj4NCj4qIEtlZXAgYSBzdGF0ZWZ1bCBQQ0Ug c3luY2hyb25pemVkIHdpdGggdGhlIHN0YXRlIG9mIExTUHMgaW4gYSBQQ0M7IHRoaXMNCj5vYmpl Y3RpdmUgaXMgdGhlIHNhbWUgYXMgdGhlIG9iamVjdGl2ZSBvZiBkcmFmdC10YW5nLXBjZS1zdGF0 ZWZ1bC1wY2UuDQo+KiBBbGxvdyBhIHN0YXRlZnVsIFBDRSB0byBkZXRlcm1pbmUgdGhlIHRpbWlu ZyBvZiBMU1Agc2V0dXAgaW4gdGhlIG5ldHdvcmsNCj4oaW4gYWRkaXRpb24gdG8gZGV0ZXJtaW5p bmcgdGhlIExTUCBwYXRocyB0aHJvdWdoIHRoZSBuZXR3b3JrKS4NCj4NCj5XZSBjYWxsIHRoZSBQ Q0UgdGhhdCBvbmx5IHdpc2hlcyB0byBrbm93IHRoZSBMU1Agc3RhdGUgdGhlICdwYXNzaXZlDQo+ c3RhdGVmdWwgUENFJy4gV2UgY2FsbCB0aGUgUENFIHRoYXQgY29udHJvbHMgdGhlIHRpbWluZyBv ZiBMU1Agc2V0dXBzIGluDQo+dGhlIG5ldHdvcmsgdGhlICdhY3RpdmUgc3RhdGVmdWwgUENFJy4N Cj4NCj4+DQo+PllvdSBkZWZpbmVkIHR3byBuZXcgUENFUCBtZXNzYWdlcyAoUENScHQgYW5kIFBD VXBkKSwgd2hpbGUgd2UgZXh0ZW5kZWQNCj4+dGhlIGV4aXN0aW5nIFBDTnRmIG1lc3NhZ2UuDQo+ DQo+V2UgY29uc2lkZXJlZCBleHRlbmRpbmcgdGhlIFBDTnRmIG1lc3NhZ2UsIGJ1dCBpbiB0aGUg ZW5kIGRlY2lkZWQgdG8gdG8NCj5kZWZpbmUgYSBuZXcgbWVzc2FnZSBmb3IgTFNQIFN0YXRlIFJl cG9ydGluZyAoUENScHQpLiBXZSBkZWZpbmVkIHRoZSBQQ1VwZA0KPm1lc3NhZ2UgdG8gc2F0aXNm eSB0aGUgb3RoZXIgb2JqZWN0aXZlIG9mIGRyYWZ0LWNyYWJiZS1wY2Utc3RhdGVmdWwtcGNlDQo+ wq0NCj50aGUgYWN0aXZlIGNvbnRyb2wgb2YgTFNQcyBieSBhIFBDRS4NCj4NCj5UaGVyZSBhcmUg Z29vZCByZWFzb25zIHRvIGRlZmluZSBhIG5ldyBtZXNzYWdlIGZvciBMU1AgU3RhdGUgUmVwb3J0 aW5nLg0KPiBJDQo+dGhpbmsgd2UgYXJlIGJvdGggYWdyZWVtZW50IHRoYXQgYW4gTFNQIHN0YXRl IHJlcG9ydC9ub3RpZmljYXRpb24gbXVzdA0KPmNhcnJ5IGEgc2V0IG9mIExTUCBhdHRyaWJ1dGVz IHRoYXQgZGVzY3JpYmUgdGhlIExTUCdzIHN0YXRlLiBOb3csIGlmIHdlDQo+d2FudCB0byByZS11 c2UgdGhlIFBDTnRmIG1lc3NhZ2UgZm9yIExTUCBzdGF0ZSByZXBvcnRzIC8gbm90aWZpY2F0aW9u cywNCj53ZQ0KPmNhbiBlaXRoZXIgZGVmaW5lIGluIHRoZSBOT1RJRklDQVRJT04gT2JqZWN0IGEg c2V0IG9mIG9wdGlvbmFsIFRMVnMgdGhhdA0KPmNhbiBjYXJyeSB0aGUgTFNQIGF0dHJpYnV0ZXMs IG9yIHJlZGVmaW5lIHRoZSBQQ050ZiBtZXNzYWdlIGl0c2VsZiB0byB1c2UNCj5hbHJlYWR5IGRl ZmluZWQgUENFUCBPYmplY3RzIHRvIGNhcnJ5IExTUCBhdHRyaWJ1dGVzLg0KPg0KPlRoZSBUTFYg YXBwcm9hY2ggaXMgbm90IGlkZWFsOiB3ZSBhbHJlYWR5IGhhdmUgYSBzZXQgb2YgUENFUCBPYmpl Y3RzIHRoYXQNCj5jYW4gY2FycnkgdGhlIExTUCBhdHRyaWJ1dGVzLCBub3cgd2Ugd291bGQgaGF2 ZSB0byBkZWZpbmUgYWxsIG9mIHRoZW0gYXMNCj5UTFZzIGFzIHdlbGwuIEFuZCBpZiBuZXcgTFNQ IGF0dHJpYnV0ZXMgYXJlIGludHJvZHVjZWQgdG8gdGhlIFBDRVANCj5wcm90b2NvbCBpbiB0aGUg ZnV0dXJlLCB0aGUgbWF5IGhhdmUgdG8gYmUgZGVmaW5lZCBib3RoIGluIFBDRVAgT2JqZWN0cw0K PmFuZCBpbiBOT1RJRklDQVRJT04gVExWcy4NCj4NCj5UaGUgYXBwcm9hY2ggd2hlcmUgdGhlIFBD TnRmIG1lc3NhZ2UgaXMgcmVkZWZpbmVkIGlzIG5vdCBpZGVhbCBlaXRoZXIuDQo+Rm9yDQo+b25l LCB3ZSBtYXkgYmUgYnJlYWtpbmcgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIGJlY2F1c2Ugd2Ug YXJlIHJlZGVmaW5pbmcNCj50aGUgbWVzc2FnZSBhbmQgbm90IHVzaW5nIG9wdGlvbmFsIFRMVnMg dG8gZGVmaW5lIG5ldyBmdW5jdGlvbmFsaXR5Lg0KPihOb3RlIHRoYXQgd2l0aCBhIG5ldyBtZXNz YWdlIHdlIGFyZSBub3QgYnJlYWtpbmcgZXhpc3RpbmcNCj5pbXBsZW1lbnRhdGlvbnMsIGJlY2F1 c2UgbmV3IG1lc3NhZ2VzIGFyZSBvbmx5IHVzZWQgaWYgc3RhdGVmdWwNCj5jYXBhYmlsaXRpZXMg YXJlIG5lZ290aWF0ZWQgYmV0d2VlbiBQQ0VQIFNwZWFrZXJzKS4gU2Vjb25kLCB0aGUgUENOdGYN Cj5tZXNzYWdlIGFzIGN1cnJlbnRseSBkZWZpbmVkIGluIFBDRVAgc2VlbXMgdG8gYmUgZGVzaWdu ZWQgZm9yIFBDRVAgZXZlbnRzDQo+KFBDRSBjb25nZXN0aW9uLCBjYW5jZWxsYXRpb24gb2YgUGVu ZGluZyBSZXF1ZXN0cywgxaApLCBhbmQgY2hhbmdpbmcgaXRzDQo+c2VtYW50aWNzIHRvIGNhcnJ5 IGJvdGggUENFUCBldmVudHMgYW5kIExTUCBzdGF0ZSBkb2VzIG5vdCBzZWVtIHRvIGJlIHRoZQ0K PnJpZ2h0IHRoaW5nIHRvIGRvLiBGaW5hbGx5LCByZWRlZmluaW5nIHRoZSBQQ050ZiBtZXNzYWdl IGNoYW5nZXMgaXRzDQo+c3RydWN0dXJlIHRvIGEgcG9pbnQgd2hlcmUgd2UgbWF5IGFzIHdlbGwg ZGVmaW5lIGEgbmV3IG1lc3NhZ2UsIGFuZCBsZXQNCj5lYWNoIG1lc3NhZ2UgcGVyZm9ybSBqdXN0 IG9uZSBmdW5jdGlvbiB3ZWxsLg0KPg0KPg0KPj4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPlBjZSBtYWlsaW5nIGxpc3QNCj5QY2VAaWV0Zi5v cmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjZQ0KPg0KPg0KPi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ WlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBpbiB0aGlzIG1haWwNCj5pcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2Fu aXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24NCj5pcyBjb25maWRlbnRpYWwuIFJlY2lw aWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5DQo+YW5k IGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11 bmljYXRpb24gdG8NCj5vdGhlcnMuDQo+VGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0 dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQNCj5pbnRlbmRlZCBzb2xlbHkgZm9yIHRo ZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUNCj5hZGRy ZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5v dGlmeSB0aGUNCj5vcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2Vk IGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2UNCj5vZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQo+ VGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRF IEFudGktU3BhbQ0KPnN5c3RlbS4NCg0K From leonidas@netmode.ntua.gr Mon Nov 7 03:46:48 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFFA821F8531 for ; Mon, 7 Nov 2011 03:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.159 X-Spam-Level: X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1P9OJ4o5lLvM for ; Mon, 7 Nov 2011 03:46:48 -0800 (PST) Received: from achilles.noc.ntua.gr (achilles.noc.ntua.gr [IPv6:2001:648:2000:de::210]) by ietfa.amsl.com (Postfix) with ESMTP id 1252621F8496 for ; Mon, 7 Nov 2011 03:46:47 -0800 (PST) Received: from netmode.ece.ntua.gr ([IPv6:2001:648:2000:d:21d:9ff:fe05:33c7]) by achilles.noc.ntua.gr (8.14.4/8.14.4) with ESMTP id pA7BkgYE060597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Nov 2011 13:46:42 +0200 (EET) (envelope-from leonidas@netmode.ntua.gr) Received: from dhcp-71.netmode.ece.ntua.gr (dhcp-71.netmode.ece.ntua.gr [147.102.13.71]) by netmode.ece.ntua.gr (8.14.4/8.14.3) with ESMTP id pA7Bkf4l021796; Mon, 7 Nov 2011 13:46:42 +0200 (EET) (envelope-from leonidas@netmode.ntua.gr) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Date: Mon, 07 Nov 2011 13:45:42 +0200 To: pce@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Leonidas Lymberopoulos" Message-ID: User-Agent: Opera Mail/11.50 (Linux) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (achilles.noc.ntua.gr [IPv6:2001:648:2000:de::210]); Mon, 07 Nov 2011 13:46:42 +0200 (EET) X-Virus-Scanned: clamav-milter 0.97 at achilles.noc.ntua.gr X-Virus-Status: Clean Subject: [Pce] (CFP) IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 11:46:48 -0000 ----------------------------------------------------------------------------------------------------- Please accept our apologies if you receive multiple copies of this CfP ----------------------------------------------------------------------------------------------------- IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) ================================================================================== 16 April 2012 Maui, Hawaii, USA http://www.manfi.org CALL FOR PAPERS --------------- The Fourth IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) will be held in conjunction with IEEE/IFIP NOMS 2012 in Maui, Hawaii, USA, from April 16-20, 2012. The workshop is sponsored by the IEEE Communications Society (ComSoc) and supported by POSTECH ITCE, Ghent University-IBBT, NEC, and Ericsson LM. The workshop is endorsed by the Technical Committee on Network Operations and Management (CNOM). It is widely agreed that, despite its many successes, the current Internet also has a set of systemic problems, ranging from an upcoming shortage of IP addresses to insufficient security. However, the lack of scalable and agile manageability is arguably more important, as without management, it is impossible to build systems that adapt the services and resources offered in a context-dependent manner. In either case (clean slate vs. evolution vs. revolution) we must consider the manageability of the Future Internet from the beginning. Following the success of the three previous editions of this workshop, held in conjunction with IM 2009, NOMS 2010 and IM 2011, ManFI 2012 aims at providing an international forum for researchers in these and similar areas. ManFI 2012 will combine original full paper presentations with a motivating keynote, quick hot topic presentations and a panel discussion to thoroughly explore this challenging topic. Topics of interest ------------------ Authors are invited to submit papers that fall into or are related to the topic areas listed below: - Architectural Issues * Advantages and disadvantages of revolutionary, evolutionary, and other approaches to managing the Future Internet * Separation of data, control, and management planes * Design of architectural building blocks for managing the Future Internet * Advances in measurement, management, security, accounting, mobility, and other functions * Virtualization of resources and services * Dynamic composition of management and operational functionality * Mechanisms for managing interconnected computational infrastructures (e.g. elastic clouds, federated clouds) in the Future Internet * Implications of social network success on the Future Internet architecture - Design and Implementation Issues * Abstractions for programmable network elements * Accommodating context-awareness in management * Applying situation awareness to network management * Federation between administrative domains and support of all constituencies * The role of models, ontologies, and other knowledge abstractions in the Future Internet * Uncertainty and probabilistic approaches to management of the Future Internet * Approaches for the organization of management data, data analytics and visualization * Experience reports from Future Internet experimental facilities set-up and results - Economic Issues * Economic aspects driving the deployment of Future Internet management technology * Economic opportunities and challenges for management technology * Experience reports from management in test beds Paper submission ---------------- Paper submissions must present original, research or experiences. Late-breaking advances and work-in-progress reports from ongoing research are also encouraged. Only original papers that have not been published or submitted for publication elsewhere can be submitted. Each submission must be written in English, accompanied by a 75 to 200 word abstract that clearly outlines the scope and contributions of the paper, and a list of up to 5 key words. There is a length limitation of 6 pages (including title, abstract, all figures, tables, and references) for regular conference papers, and 4 pages for short papers. Submissions must be in IEEE 2-column style. Papers exceeding these limits, multiple submissions, and self-plagiarized papers will be rejected without further review. Authors should submit their papers in PDF, postscript, or Word formats via JEMS: (https://submissoes.sbc.org.br/). Proceedings ----------- Papers accepted for ManFI 2012 will be included in the conference proceedings, IEEE Xplore, and EI Index. The IEEE reserves the right to remove any paper from IEEE Xplore if the paper is not presented at the workshop. Awards will be presented to the best paper and to the best student paper at the workshop. Furthermore, we plan to work with a leading journal, such as JNSM, TNSM and IJNM, to solicit extended versions of the best papers of ManFI 2012 to be submitted for review. Workshop Co-Chairs ------------------ - Prof. James Won-Ki Hong, POSTECH, Korea - Prof. Filip De Turck, Ghent University - IBBT, Belgium - Dr. Yoshiaki Kiriha, NEC, Japan - Dr. Sven van der Meer, Ericsson LM, Ireland Publicity Co-Chairs ------------------- - Leonidas Lymberopoulos, National Technical University of Athens, Greece - Cathryn Peoples, University of Ulster, UK Important dates --------------- - Abstract registration deadline: December 14, 2011 - Paper submission: December 20, 2011 - Notification of acceptance: January 31, 2012 - Final version of papers due: February 15, 2012 - Workshop date: April 16, 2012 For more information, please contact one of the Workshop Co-Chairs at tpcchairs@manfi2012.org From cyril.margaria@nsn.com Tue Nov 8 07:07:33 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D5721F8CDE for ; Tue, 8 Nov 2011 07:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.303 X-Spam-Level: X-Spam-Status: No, score=-5.303 tagged_above=-999 required=5 tests=[AWL=-0.563, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KsHuBbX8lPo for ; Tue, 8 Nov 2011 07:07:32 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 4A01E21F8CC5 for ; Tue, 8 Nov 2011 07:07:32 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pA8F7U2O007031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Nov 2011 16:07:30 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pA8F7RlE006741; Tue, 8 Nov 2011 16:07:30 +0100 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Nov 2011 16:07:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Nov 2011 16:07:26 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-crabbe-pce-stateful-pce-01 Thread-Index: AcyeKCBpjaoxediGSUi8Ki3h6eVBPg== From: "Margaria, Cyril (NSN - DE/Munich)" To: , X-OriginalArrivalTime: 08 Nov 2011 15:07:27.0813 (UTC) FILETIME=[2119EF50:01CC9E28] Cc: "Margaria, Cyril \(NSN - DE/Munich\)" Subject: [Pce] Comments on draft-crabbe-pce-stateful-pce-01 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 15:07:33 -0000 Hi,=20 I find this document very interesting,=20 Please find my few comments below: Section 2. Regarding Restoration and Path Protection : Wording is not aligned = with GMPLS (RFC4427) : protection here seems used for pre-planned = restoration and restoration for dynamic source reroute. In addition its not clear why the term "global" is used. Section 3.1.3. : I do not think the document should restrict the set of parameters to = consider, the set of parameters should be IMHO be negotiated and should depend on local policy (at PCC = or PCE level)=20 You state that the PCEP extension propose a common state representation, = but it seems that its currently signaled or not signaled.=20 Section 5.1 In the PCEP protocol (defined in [RFC5440]), LSP state and operation = are under the control of the PCC, the received attributes from the PCE = are subject to PCC local policy. The extensions defined in this document do not change this behavior.=20 Section 5.4. - Mechanism from RFC3623 could be used in the OPEN sequence in order = not to do a full resynchronization if the state on PCC did not change = (and the PCE did keep the previous state) - LSP delegation : I think its obvious, but the delegation is stopped if = the PCEP session is closed. Section 5.5. and section 5.5.4. You require that the PCC is aware of the PCE role (active/backup) one = another solution could be to allow the PCC to tell all the PCEs that he = want to have the LSP state delegated,=20 The first one to send an update wins,=20 It stated that only one PCE may have control of an LSP, but I do think = that the following should be allowed :=20 - PCC or PCE requesting LSP state delegation : several delegation to = several PCE MAY be accepted - Upon reception of a PCUpd with delegate=3D1, the PCC MUST send a = PCRpt, Delegate=3D0 to the other PCE The background of that is that the PCE is redundant and the = architecture chosen use one PCEP session per PCE instance, one instance = is active at a time. Section 5.6.1. I think that the following mechanism should be added :=20 Prior to the PCReq the PCC send a PCRpt for the LSP with state pending = (no path then)=20 Upon the PCReq the PCE can already consider the resources used. This would allow a PCC to cover the case where it intend to establish = the LSP after getting the PCRep (so the resources computed will be = marked as pending in the PCE already) or signal it later. Section 5.6.2. You state that the PCC MUST NOT send a path computation for a delegated = PCE, but section 5.1 indicate that the LSP state is owned by the PCC, so = for example the PCC MAY delegate the setup/holding priority to the PCC = but not the protection behavior (for example if the behavior is not = supported by the PCE), in which can the PCC need to send path = computation request. Section 5.7.=20 The protection control by PCE MAY be desired, but I do not think it's = a must. ( I do think about GMPLS where FRR might not be supported at = all)=20 I do not think that the document should mandate a minimum set of = behavior from the PCE. This might be subject to another document.=20 Section 6.1. One motivation you mentioned on the list was to allow different objects = than the PCEP one, however you are using the one from PCEP (I would = suggest to take into account=20 draft-ietf-pce-gmpls-pcep-extensions and RFC6006 in that case) =09 - backup-path-list: in case p2mp is used this could be a problem - Missing PPRO for backup LSPs=20 - Missing association between LSPs (one case mentioned is 2 = unidirectional LSPs, the other case are rfc4872 and rfc4873 for = instance)=20 =09 For a given LSP there is several path, but there is no statement = indicating if the resources on those path are :=20 - Reserved : i.e signaled - Shared :reserved and shared between LSPs (for instance as in RFC4872)=20 - "Planned" : not signaled, only exist in the PCC. The provisioning state of the LSP is only state in the O bit of the LSP, = but the state pending up down are not clearly identified. =09 Section 6.2. Third paragraph : the paragraph state the LSP State report instead of = LSP Update, moreover the primary (and backup) path are optional . The statement "If the LSP specified the Update Request is already up, = it will be torn down and re-signaled." Indicate that the PCC must use = break-before-make, which is contradicting with the next sentence. I do = think this should be configurable, similarly with GCO. I do also think that GCO could be leverage by the PCE to indicate to the = PCC which LSP he could re-optimize, it could be done for example by Indicate in the PCUpd that a set of LSP could be reoptimized using GCO = (and providing the GC object). This can be independent of the Delegation = for those LSPs, and would be an application of bullet 3 of section = 3.1.2.6. Section 7.2. PROTECTION-ATTRIBUTE TLV from draft-ietf-pce-gmpls-pcep-extensions = could also be considered to report the protection and signaling state. In order to fulfill the objective "Allow a PCE to specify protection / = restoration settings for all LSPs that have been delegated to it." I = think that the following is necessary to be added :=20 - ASSOCIATION=20 - PROTECTION-ATTRIBUTE in LSPA Section 7.2.2. - The tunnel sender id is missing (There is no guarantee that one = PCC is managing only one node) - From Tunnel ID you seem to imply that what is considered by the = state full PCE is more a call than just an LSP. As association can be = between LSPs having difference session and sender template (RFC4873), I = do think that this simplification may cause problem.=20 Looking forward to discussing this in Taipei. Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria Nokia Siemens Networks GmbH & Co. KG NWS DWDM RD St.Martin-Str. 76 D-81541 M=FCnchen Germany mailto:cyril.margaria@nsn.com Phone: +49-89-5159-16934 Fax: +49-89-5159-44-16934 ---------------------------------------------------------------- Nokia Siemens Networks GmbH & Co. KG=20 Sitz der Gesellschaft: M=FCnchen / Registered office: Munich=20 Registergericht: M=FCnchen / Commercial registry: Munich, HRA 88537=20 WEEE-Reg.-Nr.: DE 52984304=20 Pers=F6nlich haftende Gesellschafterin / General Partner: Nokia Siemens = Networks Management GmbH=20 Gesch=E4ftsleitung / Board of Directors: Dr. Hermann Rodler, Lydia = Sommer, Olaf Horsthemke=20 Vorsitzender des Aufsichtsrats / Chairman of supervisory board: Herbert = Merz=20 Sitz der Gesellschaft: M=FCnchen / Registered office: Munich=20 Registergericht: M=FCnchen / Commercial registry: Munich, HRB 163416=20 From jmedved@juniper.net Tue Nov 8 23:28:36 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F4911E80B1 for ; Tue, 8 Nov 2011 23:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.421 X-Spam-Level: X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32EsMDTXouir for ; Tue, 8 Nov 2011 23:28:35 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id D6FF911E808B for ; Tue, 8 Nov 2011 23:28:34 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTroriTqAYmRSXpsVTKdt3PecpXxiTNPM@postini.com; Tue, 08 Nov 2011 23:28:34 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 8 Nov 2011 23:25:25 -0800 From: Jan Medved To: "Margaria, Cyril (NSN - DE/Munich)" , "draft-crabbe-pce-stateful-pce@tools.ietf.org" , "pce@ietf.org" Date: Tue, 8 Nov 2011 23:25:22 -0800 Thread-Topic: [Pce] Comments on draft-crabbe-pce-stateful-pce-01 Thread-Index: AcyesL/sBIn0U43vRIK/Z+z+S37D6w== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Pce] Comments on draft-crabbe-pce-stateful-pce-01 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 07:28:36 -0000 Hi Cyril, Thanks a lot for the comments, please see inline. /Jan On 11/8/11 7:07 AM, "Margaria, Cyril (NSN - DE/Munich)" wrote: >Hi,=20 > >I find this document very interesting, >Please find my few comments below: > >Section 2. > Regarding Restoration and Path Protection : Wording is not aligned >with GMPLS (RFC4427) : protection here seems used for pre-planned >restoration and restoration for dynamic source reroute. >In addition its not clear why the term "global" is used. We used terminology proposed for MPLS Traffic Engineering in "Network Recovery: Protection and Restoration of Optical, SONET SDH, IP, and MPLS". WE chose it because it contains a precise description of protection use cases that we think should be covered by stateful PCEP. Do you think we should rather align the terminology with rfc4427? > >Section 3.1.3. : > > I do not think the document should restrict the set of parameters to >consider, the set of parameters should be IMHO be negotiated and should >depend on local policy (at PCC or PCE level) Agreed. We will need to introduce capability / parameter negotiation into the document.=20 > >You state that the PCEP extension propose a common state representation, >but it seems that its currently signaled or not signaled. > >Section 5.1 >In the PCEP protocol (defined in [RFC5440]), LSP state and operation are >under the control of the PCC, the received attributes from the PCE are >subject to PCC local policy. >The extensions defined in this document do not change this behavior. Yes. We'll add this text to the document. > >Section 5.4. > - Mechanism from RFC3623 could be used in the OPEN sequence in order >not to do a full resynchronization if the state on PCC did not change >(and the PCE did keep the previous state) Hmmm, that's a good idea. We should discuss in more detail. >- LSP delegation : I think its obvious, but the delegation is stopped if >the PCEP session is closed. Correct. We'll add this to the document too. > >Section 5.5. and section 5.5.4. > >You require that the PCC is aware of the PCE role (active/backup) one >another solution could be to allow the PCC to tell all the PCEs that he >want to have the LSP state delegated, >The first one to send an update wins, That's a possibility. The PCC would then revoke LSP delegation from the other PCE. Another possibility would be to advertise the preferred active PCE in IS-IS or OSPF. We should define extensions to RFCs 5088 and 5089 for advertising of stateful PCEs; additional PCE attributes, such as preferred active PCE, could be advertised at the same time. =20 > > It stated that only one PCE may have control of an LSP, but I do think >that the following should be allowed : >- PCC or PCE requesting LSP state delegation : several delegation to >several PCE MAY be accepted You're right that the protocol itself should not restrict LSP delegation to a single PCE - that should be under control of an operator-defined policy. I think most of the time the policy should be defined such that an LSP is delegated to a single PCE. But, point taken. We'll update the text. =20 >- Upon reception of a PCUpd with delegate=3D1, the PCC MUST send a PCRpt, >Delegate=3D0 to the other PCE If a PCE attempts to update an LSP that is not delegated to it, the PCC MUST send back a PCErr with a TBD error code. > >The background of that is that the PCE is redundant and the architecture >chosen use one PCEP session per PCE instance, one instance is active at a >time. Yes, that's the most common use case. > >Section 5.6.1. >I think that the following mechanism should be added : > Prior to the PCReq the PCC send a PCRpt for the LSP with state pending >(no path then)=20 > Upon the PCReq the PCE can already consider the resources used. > >This would allow a PCC to cover the case where it intend to establish the >LSP after getting the PCRep (so the resources computed will be marked as >pending in the PCE already) or signal it later. Ah, I see what you mean. I like it :-) > >Section 5.6.2. > You state that the PCC MUST NOT send a path computation for a delegated >PCE, but section 5.1 indicate that the LSP state is owned by the PCC, so >for example the PCC MAY delegate the setup/holding priority to the PCC >but not the protection behavior (for example if the behavior is not >supported by the PCE), in which can the PCC need to send path computation >request. Hm, we did not think of partial delegation. For simplicity, we would like to keep it all-or-nothing, unless there are compelling reasons to do something more powerful (and complex). WE should discuss, though, it's an interesting idea. The statement about LSP state ownership is related to the fact that the PCC can revoke the delegation at any time. It can decide whether to delegate or not, and to whom to delegate. Also, the PCC has to cleanup the LSP state if the connection to the PCE is terminated. But the assumption was that once an LSP is delegated, the PCE has full control of the LSP, =20 > >Section 5.7.=20 > The protection control by PCE MAY be desired, but I do not think it's >a must. ( I do think about GMPLS where FRR might not be supported at all) > I do not think that the document should mandate a minimum set of >behavior from the PCE. This might be subject to another document. Agreed on all points. Protection requires its own document. We had to put some info into this document in order to be able to define the PCRpt and PCUpd messages. > >Section 6.1. > One motivation you mentioned on the list was to allow different objects >than the PCEP one, however you are using the one from PCEP (I would >suggest to take into account >draft-ietf-pce-gmpls-pcep-extensions and RFC6006 in that case) > > =09 >- backup-path-list: in case p2mp is used this could be a problem >- Missing PPRO for backup LSPs >- Missing association between LSPs (one case mentioned is 2 >unidirectional LSPs, the other case are rfc4872 and rfc4873 for instance) >=09 >For a given LSP there is several path, but there is no statement >indicating if the resources on those path are : >- Reserved : i.e signaled >- Shared :reserved and shared between LSPs (for instance as in RFC4872) >- "Planned" : not signaled, only exist in the PCC. > >The provisioning state of the LSP is only state in the O bit of the LSP, >but the state pending up down are not clearly identified. Good points. > >=09 >Section 6.2. > Third paragraph : the paragraph state the LSP State report instead of >LSP Update, moreover the primary (and backup) path are optional . >The statement "If the LSP specified the Update Request is already up, >it will be torn down and re-signaled." Indicate that the PCC must use >break-before-make, which is contradicting with the next sentence. I do >think this should be configurable, similarly with GCO. Yes, good point. > >I do also think that GCO could be leverage by the PCE to indicate to the >PCC which LSP he could re-optimize, it could be done for example by >Indicate in the PCUpd that a set of LSP could be reoptimized using GCO >(and providing the GC object). This can be independent of the Delegation >for those LSPs, and would be an application of bullet 3 of section >3.1.2.6. Yes. Good point. > >Section 7.2. >PROTECTION-ATTRIBUTE TLV from draft-ietf-pce-gmpls-pcep-extensions could >also be considered to report the protection and signaling state. >In order to fulfill the objective "Allow a PCE to specify protection / >restoration settings for all LSPs that have been delegated to it." I >think that the following is necessary to be added : >- ASSOCIATION=20 >- PROTECTION-ATTRIBUTE in LSPA > > >Section 7.2.2. > - The tunnel sender id is missing (There is no guarantee that one >PCC is managing only one node) Hm, ok. But then we also need to somehow add the sender id to the PCUpd messages too. > - From Tunnel ID you seem to imply that what is considered by the state >full PCE is more a call than just an LSP. As association can be between >LSPs having difference session and sender template (RFC4873), I do think >that this simplification may cause problem. > >Looking forward to discussing this in Taipei. Really looking forward to talking to you too. > > >Mit freundlichen Gr=FC=DFen / Best Regards >Cyril Margaria > >Nokia Siemens Networks GmbH & Co. KG >NWS DWDM RD >St.Martin-Str. 76 >D-81541 M=FCnchen >Germany >mailto:cyril.margaria@nsn.com >Phone: +49-89-5159-16934 >Fax: +49-89-5159-44-16934 >---------------------------------------------------------------- >Nokia Siemens Networks GmbH & Co. KG >Sitz der Gesellschaft: M=FCnchen / Registered office: Munich >Registergericht: M=FCnchen / Commercial registry: Munich, HRA 88537 >WEEE-Reg.-Nr.: DE 52984304 >Pers=F6nlich haftende Gesellschafterin / General Partner: Nokia Siemens >Networks Management GmbH >Gesch=E4ftsleitung / Board of Directors: Dr. Hermann Rodler, Lydia Sommer, >Olaf Horsthemke=20 >Vorsitzender des Aufsichtsrats / Chairman of supervisory board: Herbert >Merz=20 >Sitz der Gesellschaft: M=FCnchen / Registered office: Munich >Registergericht: M=FCnchen / Commercial registry: Munich, HRB 163416 > > >_______________________________________________ >Pce mailing list >Pce@ietf.org >https://www.ietf.org/mailman/listinfo/pce From tang.kexin@zte.com.cn Wed Nov 9 20:58:38 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5264A21F84DC for ; Wed, 9 Nov 2011 20:58:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.238 X-Spam-Level: X-Spam-Status: No, score=-103.238 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPxF0R-bT5XZ for ; Wed, 9 Nov 2011 20:58:36 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD7621F84DD for ; Wed, 9 Nov 2011 20:58:35 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 417131441414862; Thu, 10 Nov 2011 12:53:24 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 20387.1441414862; Thu, 10 Nov 2011 12:58:18 +0800 (CST) Received: (from root@localhost) by mse01.zte.com.cn id pAA4wB5x060899 for ; Thu, 10 Nov 2011 12:58:11 +0800 (GMT-8) (envelope-from tang.kexin@zte.com.cn) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id pAA4vIWZ060194; Thu, 10 Nov 2011 12:57:18 +0800 (GMT-8) (envelope-from tang.kexin@zte.com.cn) Message-Id: <201111100458.pAA4wB5x060899@mse01.zte.com.cn> In-Reply-To: To: Jan Medved MIME-Version: 1.0 X-KeepSent: 7AB58A34:DF130113-48257944:001A8170; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 From: tang.kexin@zte.com.cn Date: Thu, 10 Nov 2011 12:57:07 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-11-10 12:57:19, Serialize complete at 2011-11-10 12:57:19 Content-Type: multipart/alternative; boundary="=_alternative 001B7DD048257944_=" X-MAIL: mse01.zte.com.cn pAA4wB5x060899 X-MSS: AUDITRELEASE@mse01.zte.com.cn Cc: pce-bounces@ietf.org, "draft-crabbe-pce-stateful-pce@tools.ietf.org" , "pce@ietf.org" , "Margaria, Cyril \(NSN - DE/Munich\)" Subject: Re: [Pce] Comments on draft-crabbe-pce-stateful-pce-01 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 04:58:38 -0000 This is a multipart message in MIME format. --=_alternative 001B7DD048257944_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgSmFuLA0KDQpJbiB5b3VyIGxldHRlciB5b3Ugd3JvdGU6DQo+DQo+U2VjdGlvbiA1LjUuIGFu ZCBzZWN0aW9uIDUuNS40Lg0KPg0KPllvdSByZXF1aXJlIHRoYXQgdGhlIFBDQyBpcyBhd2FyZSBv ZiB0aGUgUENFIHJvbGUgKGFjdGl2ZS9iYWNrdXApIG9uZQ0KPmFub3RoZXIgc29sdXRpb24gY291 bGQgYmUgdG8gYWxsb3cgdGhlIFBDQyB0byB0ZWxsIGFsbCB0aGUgUENFcyB0aGF0IGhlDQo+d2Fu dCB0byBoYXZlIHRoZSBMU1Agc3RhdGUgZGVsZWdhdGVkLA0KPlRoZSBmaXJzdCBvbmUgdG8gc2Vu ZCBhbiB1cGRhdGUgd2lucywNCg0KVGhhdCdzIGEgcG9zc2liaWxpdHkuIFRoZSBQQ0Mgd291bGQg dGhlbiByZXZva2UgTFNQIGRlbGVnYXRpb24gZnJvbSB0aGUNCm90aGVyIFBDRS4gQW5vdGhlciBw b3NzaWJpbGl0eSB3b3VsZCBiZSB0byBhZHZlcnRpc2UgdGhlIHByZWZlcnJlZCBhY3RpdmUNClBD RSBpbiBJUy1JUyBvciBPU1BGLiBXZSBzaG91bGQgZGVmaW5lIGV4dGVuc2lvbnMgdG8gUkZDcyA1 MDg4IGFuZCA1MDg5DQpmb3IgYWR2ZXJ0aXNpbmcgb2Ygc3RhdGVmdWwgUENFczsgYWRkaXRpb25h bCBQQ0UgYXR0cmlidXRlcywgc3VjaCBhcw0KcHJlZmVycmVkIGFjdGl2ZSBQQ0UsIGNvdWxkIGJl IGFkdmVydGlzZWQgYXQgdGhlIHNhbWUgdGltZS4NCg0KDQo8S2V4aW4+OkkgcHJlZmVyIHRoZSBm b3JtZXIgdGhhdCBDeXJpbCB3cm90ZSwgc2luY2UgaXQgaXMgbW9yZSBzaW1wbGUuIFRoZSANCmxh dHRlciBwb3NzaWJpbGl0eSB5b3UgZGVzY3JpYmVkIG5lZWRzIGV4dHJhIGluZm9ybWF0aW9uIGlu IFBDRSBEaXNjb3ZlcnkgDQphZHZlcnRpc2VtZW50LA0KICAgICAgICBhbmQgd2l0aCB0aGUgbmV3 bHkgY2hhbmdlIG9mIGFjdGl2ZSBQQ0UsIHRoaXMgYWR2ZXJ0aXNlbWVudCBjb3VsZCANCmJlIGZy ZXF1ZW50bHkuIA0KICAgICAgICBJbmRlZWQsdG8gaW50cm9kdWNlIHN0YXRlZnVsIFBDRXMsIGV4 dGVudGlvbnMgdG8gUENFIERpc2NvdmVyeSANCihSRkM1MDg4LFJGQzUwODkpIGlzIG5lZWRlZCx0 byBhZHZlcnRpc2UgdGhlIHN0YXRlZnVsIFBDRXMgYXMgeW91IHNhaWQgDQphYm92ZS4gDQogICAg ICAgIEhvd2V2ZXIsIFBDRSBEaXNjb3ZlcnkgYWR2ZXJ0aXNlbWVudCBpcyBub3QgbmVlZGVkIHVu bGVzcyB0aGUgDQpsb2NhdGlvbiBvciBjYXBhYmlsaXR5IG9mIGEgUENFIGlzIGNoYW5nZWQuDQog DQpCZXN0IFJlZ2FyZHMsDQpLZXhpbg0KDQoNCg0KSmFuIE1lZHZlZCA8am1lZHZlZEBqdW5pcGVy Lm5ldD4gDQogIHBjZS1ib3VuY2VzQGlldGYub3JnDQoyMDExLTExLTA5IDE1OjI1DQoNCuaUtuS7 tuS6ug0KIk1hcmdhcmlhLCBDeXJpbCAoTlNOIC0gREUvTXVuaWNoKSIgPGN5cmlsLm1hcmdhcmlh QG5zbi5jb20+LCANCiJkcmFmdC1jcmFiYmUtcGNlLXN0YXRlZnVsLXBjZUB0b29scy5pZXRmLm9y ZyIgDQo8ZHJhZnQtY3JhYmJlLXBjZS1zdGF0ZWZ1bC1wY2VAdG9vbHMuaWV0Zi5vcmc+LCAicGNl QGlldGYub3JnIiANCjxwY2VAaWV0Zi5vcmc+DQrmioTpgIENCg0K5Li76aKYDQpSZTogW1BjZV0g Q29tbWVudHMgb24gZHJhZnQtY3JhYmJlLXBjZS1zdGF0ZWZ1bC1wY2UtMDENCg0KDQoNCg0KDQoN CkhpIEN5cmlsLA0KDQpUaGFua3MgYSBsb3QgZm9yIHRoZSBjb21tZW50cywgcGxlYXNlIHNlZSBp bmxpbmUuDQoNCg0KDQovSmFuDQoNCk9uIDExLzgvMTEgNzowNyBBTSwgIk1hcmdhcmlhLCBDeXJp bCAoTlNOIC0gREUvTXVuaWNoKSINCjxjeXJpbC5tYXJnYXJpYUBuc24uY29tPiB3cm90ZToNCg0K PkhpLCANCj4NCj5JIGZpbmQgdGhpcyBkb2N1bWVudCB2ZXJ5IGludGVyZXN0aW5nLA0KPlBsZWFz ZSBmaW5kIG15IGZldyBjb21tZW50cyBiZWxvdzoNCj4NCj5TZWN0aW9uIDIuDQo+ICAgUmVnYXJk aW5nICBSZXN0b3JhdGlvbiBhbmQgUGF0aCBQcm90ZWN0aW9uIDogIFdvcmRpbmcgaXMgbm90IGFs aWduZWQNCj53aXRoIEdNUExTIChSRkM0NDI3KSA6IHByb3RlY3Rpb24gaGVyZSBzZWVtcyB1c2Vk IGZvciBwcmUtcGxhbm5lZA0KPnJlc3RvcmF0aW9uIGFuZCByZXN0b3JhdGlvbiBmb3IgZHluYW1p YyBzb3VyY2UgcmVyb3V0ZS4NCj5JbiBhZGRpdGlvbiAgaXRzIG5vdCBjbGVhciB3aHkgdGhlIHRl cm0gImdsb2JhbCIgaXMgdXNlZC4NCg0KV2UgdXNlZCB0ZXJtaW5vbG9neSBwcm9wb3NlZCBmb3Ig TVBMUyBUcmFmZmljIEVuZ2luZWVyaW5nIGluICJOZXR3b3JrDQpSZWNvdmVyeTogUHJvdGVjdGlv biBhbmQgUmVzdG9yYXRpb24gb2YgT3B0aWNhbCwgU09ORVQgU0RILCBJUCwgYW5kIE1QTFMiLg0K V0UgY2hvc2UgaXQgYmVjYXVzZSBpdCBjb250YWlucyBhIHByZWNpc2UgZGVzY3JpcHRpb24gb2Yg cHJvdGVjdGlvbiB1c2UNCmNhc2VzIHRoYXQgd2UgdGhpbmsgc2hvdWxkIGJlIGNvdmVyZWQgYnkg c3RhdGVmdWwgUENFUC4gRG8geW91IHRoaW5rIHdlDQpzaG91bGQgcmF0aGVyIGFsaWduIHRoZSB0 ZXJtaW5vbG9neSB3aXRoIHJmYzQ0Mjc/DQoNCj4NCj5TZWN0aW9uIDMuMS4zLiA6DQo+DQo+IEkg ZG8gbm90IHRoaW5rIHRoZSBkb2N1bWVudCBzaG91bGQgcmVzdHJpY3QgdGhlIHNldCBvZiBwYXJh bWV0ZXJzIHRvDQo+Y29uc2lkZXIsIHRoZSBzZXQgb2YgcGFyYW1ldGVycyBzaG91bGQgYmUgSU1I TyBiZSBuZWdvdGlhdGVkIGFuZCBzaG91bGQNCj5kZXBlbmQgb24gbG9jYWwgcG9saWN5IChhdCBQ Q0Mgb3IgUENFIGxldmVsKQ0KDQpBZ3JlZWQuIFdlIHdpbGwgbmVlZCB0byBpbnRyb2R1Y2UgY2Fw YWJpbGl0eSAvIHBhcmFtZXRlciBuZWdvdGlhdGlvbiBpbnRvDQp0aGUgZG9jdW1lbnQuIA0KDQo+ DQo+WW91IHN0YXRlIHRoYXQgdGhlIFBDRVAgZXh0ZW5zaW9uIHByb3Bvc2UgYSBjb21tb24gc3Rh dGUgcmVwcmVzZW50YXRpb24sDQo+YnV0IGl0IHNlZW1zIHRoYXQgaXRzIGN1cnJlbnRseSBzaWdu YWxlZCBvciBub3Qgc2lnbmFsZWQuDQo+DQo+U2VjdGlvbiA1LjENCj5JbiB0aGUgUENFUCBwcm90 b2NvbCAoZGVmaW5lZCBpbiBbUkZDNTQ0MF0pLCBMU1Agc3RhdGUgIGFuZCBvcGVyYXRpb24gYXJl DQo+dW5kZXIgdGhlIGNvbnRyb2wgb2YgdGhlIFBDQywgdGhlIHJlY2VpdmVkIGF0dHJpYnV0ZXMg ZnJvbSB0aGUgUENFIGFyZQ0KPnN1YmplY3QgdG8gUENDIGxvY2FsIHBvbGljeS4NCj5UaGUgZXh0 ZW5zaW9ucyBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgZG8gbm90IGNoYW5nZSB0aGlzIGJlaGF2 aW9yLg0KDQpZZXMuIFdlJ2xsIGFkZCB0aGlzIHRleHQgdG8gdGhlIGRvY3VtZW50Lg0KDQo+DQo+ U2VjdGlvbiA1LjQuDQo+IC0gIE1lY2hhbmlzbSBmcm9tIFJGQzM2MjMgY291bGQgYmUgdXNlZCBp biB0aGUgT1BFTiBzZXF1ZW5jZSBpbiBvcmRlcg0KPm5vdCB0byBkbyBhIGZ1bGwgcmVzeW5jaHJv bml6YXRpb24gaWYgdGhlIHN0YXRlIG9uIFBDQyBkaWQgbm90IGNoYW5nZQ0KPihhbmQgdGhlIFBD RSBkaWQga2VlcCB0aGUgcHJldmlvdXMgc3RhdGUpDQoNCkhtbW0sIHRoYXQncyBhIGdvb2QgaWRl YS4gV2Ugc2hvdWxkIGRpc2N1c3MgaW4gbW9yZSBkZXRhaWwuDQoNCj4tIExTUCBkZWxlZ2F0aW9u IDogSSB0aGluayBpdHMgb2J2aW91cywgYnV0IHRoZSBkZWxlZ2F0aW9uIGlzIHN0b3BwZWQgaWYN Cj50aGUgUENFUCBzZXNzaW9uIGlzIGNsb3NlZC4NCg0KQ29ycmVjdC4gV2UnbGwgYWRkIHRoaXMg dG8gdGhlIGRvY3VtZW50IHRvby4NCg0KPg0KPlNlY3Rpb24gNS41LiBhbmQgc2VjdGlvbiA1LjUu NC4NCj4NCj5Zb3UgcmVxdWlyZSB0aGF0IHRoZSBQQ0MgaXMgYXdhcmUgb2YgdGhlIFBDRSByb2xl IChhY3RpdmUvYmFja3VwKSBvbmUNCj5hbm90aGVyIHNvbHV0aW9uIGNvdWxkIGJlIHRvIGFsbG93 IHRoZSBQQ0MgdG8gdGVsbCBhbGwgdGhlIFBDRXMgdGhhdCBoZQ0KPndhbnQgdG8gaGF2ZSB0aGUg TFNQIHN0YXRlIGRlbGVnYXRlZCwNCj5UaGUgZmlyc3Qgb25lIHRvIHNlbmQgYW4gdXBkYXRlIHdp bnMsDQoNClRoYXQncyBhIHBvc3NpYmlsaXR5LiBUaGUgUENDIHdvdWxkIHRoZW4gcmV2b2tlIExT UCBkZWxlZ2F0aW9uIGZyb20gdGhlDQpvdGhlciBQQ0UuIEFub3RoZXIgcG9zc2liaWxpdHkgd291 bGQgYmUgdG8gYWR2ZXJ0aXNlIHRoZSBwcmVmZXJyZWQgYWN0aXZlDQpQQ0UgaW4gSVMtSVMgb3Ig T1NQRi4gV2Ugc2hvdWxkIGRlZmluZSBleHRlbnNpb25zIHRvIFJGQ3MgNTA4OCBhbmQgNTA4OQ0K Zm9yIGFkdmVydGlzaW5nIG9mIHN0YXRlZnVsIFBDRXM7IGFkZGl0aW9uYWwgUENFIGF0dHJpYnV0 ZXMsIHN1Y2ggYXMNCnByZWZlcnJlZCBhY3RpdmUgUENFLCBjb3VsZCBiZSBhZHZlcnRpc2VkIGF0 IHRoZSBzYW1lIHRpbWUuDQogDQo+DQo+ICBJdCBzdGF0ZWQgdGhhdCBvbmx5IG9uZSBQQ0UgbWF5 IGhhdmUgY29udHJvbCBvZiBhbiBMU1AsIGJ1dCBJIGRvIHRoaW5rDQo+dGhhdCB0aGUgZm9sbG93 aW5nIHNob3VsZCBiZSBhbGxvd2VkIDoNCj4tICAgICAgICAgICAgICAgUENDIG9yIFBDRSByZXF1 ZXN0aW5nIExTUCBzdGF0ZSBkZWxlZ2F0aW9uIDogc2V2ZXJhbCANCmRlbGVnYXRpb24gdG8NCj5z ZXZlcmFsIFBDRSBNQVkgYmUgYWNjZXB0ZWQNCg0KWW91J3JlIHJpZ2h0IHRoYXQgdGhlIHByb3Rv Y29sIGl0c2VsZiBzaG91bGQgbm90IHJlc3RyaWN0IExTUCBkZWxlZ2F0aW9uDQp0byBhIHNpbmds ZSBQQ0UgLSB0aGF0IHNob3VsZCBiZSB1bmRlciBjb250cm9sIG9mIGFuIG9wZXJhdG9yLWRlZmlu ZWQNCnBvbGljeS4gSSB0aGluayBtb3N0IG9mIHRoZSB0aW1lIHRoZSBwb2xpY3kgc2hvdWxkIGJl IGRlZmluZWQgc3VjaCB0aGF0IGFuDQpMU1AgaXMgZGVsZWdhdGVkIHRvIGEgc2luZ2xlIFBDRS4g QnV0LCBwb2ludCB0YWtlbi4gV2UnbGwgdXBkYXRlIHRoZSB0ZXh0Lg0KIA0KDQo+LSAgICAgICAg ICAgICAgIFVwb24gcmVjZXB0aW9uIG9mIGEgUENVcGQgd2l0aCBkZWxlZ2F0ZT0xLCB0aGUgUEND ICBNVVNUIA0Kc2VuZCBhIFBDUnB0LA0KPkRlbGVnYXRlPTAgdG8gdGhlIG90aGVyIFBDRQ0KDQpJ ZiBhIFBDRSBhdHRlbXB0cyB0byB1cGRhdGUgYW4gTFNQIHRoYXQgaXMgbm90IGRlbGVnYXRlZCB0 byBpdCwgdGhlIFBDQw0KTVVTVCBzZW5kIGJhY2sgYSBQQ0VyciB3aXRoIGEgVEJEIGVycm9yIGNv ZGUuDQoNCj4NCj5UaGUgYmFja2dyb3VuZCBvZiB0aGF0IGlzIHRoYXQgdGhlIFBDRSBpcyAgcmVk dW5kYW50IGFuZCB0aGUgYXJjaGl0ZWN0dXJlDQo+Y2hvc2VuIHVzZSBvbmUgUENFUCBzZXNzaW9u IHBlciBQQ0UgaW5zdGFuY2UsIG9uZSBpbnN0YW5jZSBpcyBhY3RpdmUgYXQgYQ0KPnRpbWUuDQoN ClllcywgdGhhdCdzIHRoZSBtb3N0IGNvbW1vbiB1c2UgY2FzZS4NCg0KPg0KPlNlY3Rpb24gNS42 LjEuDQo+SSB0aGluayB0aGF0ICB0aGUgZm9sbG93aW5nIG1lY2hhbmlzbSBzaG91bGQgYmUgYWRk ZWQgOg0KPiAgUHJpb3IgdG8gdGhlIFBDUmVxIHRoZSBQQ0Mgc2VuZCBhIFBDUnB0IGZvciB0aGUg TFNQIHdpdGggc3RhdGUgcGVuZGluZw0KPihubyBwYXRoIHRoZW4pIA0KPiAgVXBvbiB0aGUgUENS ZXEgdGhlIFBDRSBjYW4gYWxyZWFkeSBjb25zaWRlciB0aGUgcmVzb3VyY2VzIHVzZWQuDQo+DQo+ VGhpcyB3b3VsZCBhbGxvdyBhIFBDQyB0byBjb3ZlciB0aGUgY2FzZSB3aGVyZSBpdCBpbnRlbmQg dG8gZXN0YWJsaXNoIHRoZQ0KPkxTUCBhZnRlciBnZXR0aW5nIHRoZSBQQ1JlcCAoc28gdGhlIHJl c291cmNlcyBjb21wdXRlZCB3aWxsIGJlIG1hcmtlZCBhcw0KPnBlbmRpbmcgaW4gdGhlIFBDRSBh bHJlYWR5KSAgb3Igc2lnbmFsIGl0IGxhdGVyLg0KDQpBaCwgSSBzZWUgd2hhdCB5b3UgbWVhbi4g SSBsaWtlIGl0IDotKQ0KDQo+DQo+U2VjdGlvbiA1LjYuMi4NCj4gWW91IHN0YXRlIHRoYXQgdGhl IFBDQyBNVVNUIE5PVCBzZW5kIGEgcGF0aCBjb21wdXRhdGlvbiBmb3IgYSBkZWxlZ2F0ZWQNCj5Q Q0UsIGJ1dCBzZWN0aW9uIDUuMSBpbmRpY2F0ZSB0aGF0IHRoZSBMU1Agc3RhdGUgaXMgb3duZWQg YnkgdGhlIFBDQywgc28NCj5mb3IgZXhhbXBsZSB0aGUgUENDIE1BWSBkZWxlZ2F0ZSB0aGUgc2V0 dXAvaG9sZGluZyBwcmlvcml0eSB0byB0aGUgIFBDQw0KPmJ1dCBub3QgdGhlIHByb3RlY3Rpb24g IGJlaGF2aW9yIChmb3IgZXhhbXBsZSBpZiB0aGUgYmVoYXZpb3IgaXMgbm90DQo+c3VwcG9ydGVk IGJ5IHRoZSBQQ0UpLCBpbiB3aGljaCBjYW4gdGhlIFBDQyBuZWVkIHRvIHNlbmQgcGF0aCBjb21w dXRhdGlvbg0KPnJlcXVlc3QuDQoNCkhtLCB3ZSBkaWQgbm90IHRoaW5rIG9mIHBhcnRpYWwgZGVs ZWdhdGlvbi4gRm9yIHNpbXBsaWNpdHksIHdlIHdvdWxkIGxpa2UNCnRvIGtlZXAgaXQgYWxsLW9y LW5vdGhpbmcsIHVubGVzcyB0aGVyZSBhcmUgY29tcGVsbGluZyByZWFzb25zIHRvIGRvDQpzb21l dGhpbmcgbW9yZSBwb3dlcmZ1bCAoYW5kIGNvbXBsZXgpLiBXRSBzaG91bGQgZGlzY3VzcywgdGhv dWdoLCBpdCdzIGFuDQppbnRlcmVzdGluZyBpZGVhLg0KDQpUaGUgc3RhdGVtZW50IGFib3V0IExT UCBzdGF0ZSBvd25lcnNoaXAgaXMgcmVsYXRlZCB0byB0aGUgZmFjdCB0aGF0IHRoZQ0KUENDIGNh biByZXZva2UgdGhlIGRlbGVnYXRpb24gYXQgYW55IHRpbWUuIEl0IGNhbiBkZWNpZGUgd2hldGhl ciB0bw0KZGVsZWdhdGUgb3Igbm90LCBhbmQgdG8gd2hvbSB0byBkZWxlZ2F0ZS4gQWxzbywgdGhl IFBDQyBoYXMgdG8gY2xlYW51cCB0aGUNCkxTUCBzdGF0ZSBpZiB0aGUgY29ubmVjdGlvbiB0byB0 aGUgUENFIGlzIHRlcm1pbmF0ZWQuIEJ1dCB0aGUgYXNzdW1wdGlvbg0Kd2FzIHRoYXQgb25jZSBh biBMU1AgaXMgZGVsZWdhdGVkLCB0aGUgUENFIGhhcyBmdWxsIGNvbnRyb2wgb2YgdGhlIExTUCwN CiANCj4NCj5TZWN0aW9uIDUuNy4gDQo+ICAgVGhlIHByb3RlY3Rpb24gY29udHJvbCBieSBQQ0Ug TUFZIGJlIGRlc2lyZWQsIGJ1dCBJIGRvIG5vdCB0aGluayBpdCdzDQo+YSBtdXN0LiAoIEkgZG8g dGhpbmsgYWJvdXQgR01QTFMgd2hlcmUgRlJSIG1pZ2h0IG5vdCBiZSBzdXBwb3J0ZWQgYXQgYWxs KQ0KPiAgIEkgZG8gbm90ICB0aGluayB0aGF0IHRoZSBkb2N1bWVudCBzaG91bGQgbWFuZGF0ZSBh IG1pbmltdW0gc2V0IG9mDQo+YmVoYXZpb3IgZnJvbSB0aGUgUENFLiBUaGlzIG1pZ2h0IGJlIHN1 YmplY3QgdG8gYW5vdGhlciBkb2N1bWVudC4NCg0KQWdyZWVkIG9uIGFsbCBwb2ludHMuIFByb3Rl Y3Rpb24gcmVxdWlyZXMgaXRzIG93biBkb2N1bWVudC4gV2UgaGFkIHRvIHB1dA0Kc29tZSBpbmZv IGludG8gdGhpcyBkb2N1bWVudCBpbiBvcmRlciB0byBiZSBhYmxlIHRvIGRlZmluZSB0aGUgUENS cHQgYW5kDQpQQ1VwZCBtZXNzYWdlcy4NCg0KPg0KPlNlY3Rpb24gNi4xLg0KPiAgICAgICAgICAg ICAgICBPbmUgbW90aXZhdGlvbiB5b3UgbWVudGlvbmVkIG9uIHRoZSBsaXN0IHdhcyB0byBhbGxv dyANCmRpZmZlcmVudCBvYmplY3RzDQo+dGhhbiB0aGUgUENFUCBvbmUsIGhvd2V2ZXIgeW91IGFy ZSB1c2luZyB0aGUgb25lIGZyb20gUENFUCAoSSB3b3VsZA0KPnN1Z2dlc3QgdG8gdGFrZSBpbnRv IGFjY291bnQNCj5kcmFmdC1pZXRmLXBjZS1nbXBscy1wY2VwLWV4dGVuc2lvbnMgYW5kIFJGQzYw MDYgaW4gdGhhdCBjYXNlKQ0KPg0KPiANCj4tICAgICAgICAgICAgICAgYmFja3VwLXBhdGgtbGlz dDogaW4gY2FzZSBwMm1wIGlzIHVzZWQgdGhpcyBjb3VsZCBiZSBhIA0KcHJvYmxlbQ0KPi0gICAg ICAgICAgICAgICBNaXNzaW5nIFBQUk8gZm9yIGJhY2t1cCBMU1BzDQo+LSAgICAgICAgICAgICAg IE1pc3NpbmcgYXNzb2NpYXRpb24gYmV0d2VlbiBMU1BzIChvbmUgY2FzZSBtZW50aW9uZWQgaXMg Mg0KPnVuaWRpcmVjdGlvbmFsIExTUHMsIHRoZSBvdGhlciBjYXNlIGFyZSByZmM0ODcyIGFuZCBy ZmM0ODczIGZvciBpbnN0YW5jZSkNCj4gDQo+Rm9yIGEgZ2l2ZW4gTFNQIHRoZXJlIGlzIHNldmVy YWwgcGF0aCwgYnV0IHRoZXJlIGlzIG5vIHN0YXRlbWVudA0KPmluZGljYXRpbmcgaWYgdGhlIHJl c291cmNlcyBvbiB0aG9zZSBwYXRoIGFyZSA6DQo+LSAgICAgICAgICAgICAgIFJlc2VydmVkIDog aS5lIHNpZ25hbGVkDQo+LSAgICAgICAgICAgICAgIFNoYXJlZCA6cmVzZXJ2ZWQgYW5kIHNoYXJl ZCBiZXR3ZWVuIExTUHMgKGZvciBpbnN0YW5jZSBhcyANCmluIFJGQzQ4NzIpDQo+LSAgICAgICAg ICAgICAgICJQbGFubmVkIiAgOiBub3Qgc2lnbmFsZWQsIG9ubHkgZXhpc3QgaW4gdGhlIFBDQy4N Cj4NCj5UaGUgcHJvdmlzaW9uaW5nIHN0YXRlIG9mIHRoZSBMU1AgaXMgb25seSBzdGF0ZSBpbiB0 aGUgTyBiaXQgb2YgdGhlIExTUCwNCj5idXQgdGhlIHN0YXRlIHBlbmRpbmcgdXAgZG93biBhcmUg bm90IGNsZWFybHkgaWRlbnRpZmllZC4NCg0KR29vZCBwb2ludHMuDQoNCj4NCj4gDQo+U2VjdGlv biA2LjIuDQo+IFRoaXJkIHBhcmFncmFwaCA6IHRoZSBwYXJhZ3JhcGggc3RhdGUgdGhlIExTUCBT dGF0ZSByZXBvcnQgaW5zdGVhZCBvZg0KPkxTUCBVcGRhdGUsIG1vcmVvdmVyIHRoZSBwcmltYXJ5 IChhbmQgYmFja3VwKSBwYXRoIGFyZSBvcHRpb25hbCAuDQo+VGhlIHN0YXRlbWVudCAiSWYgdGhl IExTUCBzcGVjaWZpZWQgdGhlIFVwZGF0ZSBSZXF1ZXN0ICAgaXMgYWxyZWFkeSB1cCwNCj5pdCB3 aWxsIGJlIHRvcm4gZG93biBhbmQgcmUtc2lnbmFsZWQuIiBJbmRpY2F0ZSB0aGF0IHRoZSBQQ0Mg bXVzdCB1c2UNCj5icmVhay1iZWZvcmUtbWFrZSwgd2hpY2ggaXMgY29udHJhZGljdGluZyB3aXRo IHRoZSBuZXh0IHNlbnRlbmNlLiAgSSBkbw0KPnRoaW5rIHRoaXMgc2hvdWxkIGJlIGNvbmZpZ3Vy YWJsZSwgc2ltaWxhcmx5IHdpdGggR0NPLg0KDQpZZXMsIGdvb2QgcG9pbnQuDQoNCj4NCj5JIGRv IGFsc28gdGhpbmsgdGhhdCBHQ08gY291bGQgYmUgbGV2ZXJhZ2UgYnkgdGhlIFBDRSB0byBpbmRp Y2F0ZSB0byB0aGUNCj5QQ0Mgd2hpY2ggTFNQIGhlIGNvdWxkIHJlLW9wdGltaXplLCBpdCBjb3Vs ZCBiZSBkb25lIGZvciBleGFtcGxlIGJ5DQo+SW5kaWNhdGUgaW4gdGhlIFBDVXBkIHRoYXQgYSBz ZXQgb2YgTFNQIGNvdWxkIGJlIHJlb3B0aW1pemVkIHVzaW5nIEdDTw0KPihhbmQgcHJvdmlkaW5n IHRoZSBHQyBvYmplY3QpLiBUaGlzIGNhbiBiZSBpbmRlcGVuZGVudCBvZiB0aGUgRGVsZWdhdGlv bg0KPmZvciB0aG9zZSBMU1BzLCBhbmQgd291bGQgYmUgYW4gYXBwbGljYXRpb24gb2YgYnVsbGV0 IDMgb2Ygc2VjdGlvbg0KPjMuMS4yLjYuDQoNClllcy4gR29vZCBwb2ludC4NCg0KPg0KPlNlY3Rp b24gNy4yLg0KPlBST1RFQ1RJT04tQVRUUklCVVRFIFRMViBmcm9tIGRyYWZ0LWlldGYtcGNlLWdt cGxzLXBjZXAtZXh0ZW5zaW9ucyAgY291bGQNCj5hbHNvIGJlIGNvbnNpZGVyZWQgdG8gcmVwb3J0 IHRoZSBwcm90ZWN0aW9uIGFuZCBzaWduYWxpbmcgc3RhdGUuDQo+SW4gb3JkZXIgdG8gZnVsZmls bCB0aGUgb2JqZWN0aXZlICJBbGxvdyBhIFBDRSB0byBzcGVjaWZ5IHByb3RlY3Rpb24gLw0KPnJl c3RvcmF0aW9uIHNldHRpbmdzIGZvciBhbGwgIExTUHMgdGhhdCBoYXZlIGJlZW4gZGVsZWdhdGVk IHRvIGl0LiIgSQ0KPnRoaW5rIHRoYXQgdGhlIGZvbGxvd2luZyBpcyBuZWNlc3NhcnkgdG8gYmUg YWRkZWQgOg0KPi0gICAgICAgICAgICAgICBBU1NPQ0lBVElPTiANCj4tICAgICAgICAgICAgICAg UFJPVEVDVElPTi1BVFRSSUJVVEUgaW4gTFNQQQ0KPg0KPg0KPlNlY3Rpb24gNy4yLjIuDQo+IC0g ICBUaGUgdHVubmVsIHNlbmRlciBpZCBpcyAgbWlzc2luZyAgKFRoZXJlIGlzIG5vIGd1YXJhbnRl ZSB0aGF0IG9uZQ0KPlBDQyBpcyBtYW5hZ2luZyBvbmx5IG9uZSBub2RlKQ0KDQpIbSwgb2suIEJ1 dCB0aGVuIHdlIGFsc28gbmVlZCB0byBzb21laG93IGFkZCB0aGUgc2VuZGVyIGlkIHRvIHRoZSBQ Q1VwZA0KbWVzc2FnZXMgdG9vLg0KDQo+IC0gIEZyb20gVHVubmVsIElEIHlvdSBzZWVtIHRvIGlt cGx5IHRoYXQgd2hhdCBpcyBjb25zaWRlcmVkIGJ5IHRoZSBzdGF0ZQ0KPmZ1bGwgUENFIGlzIG1v cmUgYSBjYWxsIHRoYW4ganVzdCBhbiBMU1AuIEFzIGFzc29jaWF0aW9uIGNhbiBiZSBiZXR3ZWVu DQo+TFNQcyBoYXZpbmcgZGlmZmVyZW5jZSBzZXNzaW9uIGFuZCBzZW5kZXIgdGVtcGxhdGUgKFJG QzQ4NzMpLCBJIGRvIHRoaW5rDQo+dGhhdCB0aGlzIHNpbXBsaWZpY2F0aW9uIG1heSAgY2F1c2Ug cHJvYmxlbS4NCj4NCj5Mb29raW5nIGZvcndhcmQgdG8gZGlzY3Vzc2luZyB0aGlzIGluIFRhaXBl aS4NCg0KUmVhbGx5IGxvb2tpbmcgZm9yd2FyZCB0byB0YWxraW5nIHRvIHlvdSB0b28uDQoNCj4N Cj4NCj5NaXQgZnJldW5kbGljaGVuIEdyw7zDn2VuIC8gQmVzdCBSZWdhcmRzDQo+Q3lyaWwgTWFy Z2FyaWENCj4NCj5Ob2tpYSBTaWVtZW5zIE5ldHdvcmtzIEdtYkggJiBDby4gS0cNCj5OV1MgRFdE TSBSRA0KPlN0Lk1hcnRpbi1TdHIuIDc2DQo+RC04MTU0MSBNw7xuY2hlbg0KPkdlcm1hbnkNCj5t YWlsdG86Y3lyaWwubWFyZ2FyaWFAbnNuLmNvbQ0KPlBob25lOiArNDktODktNTE1OS0xNjkzNA0K PkZheDogICArNDktODktNTE1OS00NC0xNjkzNA0KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj5Ob2tpYSBTaWVtZW5zIE5l dHdvcmtzIEdtYkggJiBDby4gS0cNCj5TaXR6IGRlciBHZXNlbGxzY2hhZnQ6IE3DvG5jaGVuIC8g UmVnaXN0ZXJlZCBvZmZpY2U6IE11bmljaA0KPlJlZ2lzdGVyZ2VyaWNodDogTcO8bmNoZW4gLyBD b21tZXJjaWFsIHJlZ2lzdHJ5OiBNdW5pY2gsIEhSQSA4ODUzNw0KPldFRUUtUmVnLi1Oci46IERF IDUyOTg0MzA0DQo+UGVyc8O2bmxpY2ggaGFmdGVuZGUgR2VzZWxsc2NoYWZ0ZXJpbiAvIEdlbmVy YWwgUGFydG5lcjogTm9raWEgU2llbWVucw0KPk5ldHdvcmtzIE1hbmFnZW1lbnQgR21iSA0KPkdl c2Now6RmdHNsZWl0dW5nIC8gQm9hcmQgb2YgRGlyZWN0b3JzOiBEci4gSGVybWFubiBSb2RsZXIs IEx5ZGlhIFNvbW1lciwNCj5PbGFmIEhvcnN0aGVta2UgDQo+Vm9yc2l0emVuZGVyIGRlcyBBdWZz aWNodHNyYXRzIC8gQ2hhaXJtYW4gb2Ygc3VwZXJ2aXNvcnkgYm9hcmQ6IEhlcmJlcnQNCj5NZXJ6 IA0KPlNpdHogZGVyIEdlc2VsbHNjaGFmdDogTcO8bmNoZW4gLyBSZWdpc3RlcmVkIG9mZmljZTog TXVuaWNoDQo+UmVnaXN0ZXJnZXJpY2h0OiBNw7xuY2hlbiAvIENvbW1lcmNpYWwgcmVnaXN0cnk6 IE11bmljaCwgSFJCIDE2MzQxNg0KPg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+UGNlIG1haWxpbmcgbGlzdA0KPlBjZUBpZXRmLm9yZw0KPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNlDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpQY2UgbWFpbGluZyBsaXN0DQpQY2VA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNlDQoNCg0K DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mg b3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJl Y2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFu ZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21t dW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRl ZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVz ZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQu IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0 aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlz IG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2Fn ZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0g c3lzdGVtLg0K --=_alternative 001B7DD048257944_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEphbiw8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkluIHlvdXIgbGV0dGVyIHlvdSB3 cm90ZTo8L2ZvbnQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7PGJyPg0KJmd0O1NlY3Rpb24g NS41LiBhbmQgc2VjdGlvbiA1LjUuNC48YnI+DQomZ3Q7PGJyPg0KJmd0O1lvdSByZXF1aXJlIHRo YXQgdGhlIFBDQyBpcyBhd2FyZSBvZiB0aGUgUENFIHJvbGUgKGFjdGl2ZS9iYWNrdXApIG9uZTxi cj4NCiZndDthbm90aGVyIHNvbHV0aW9uIGNvdWxkIGJlIHRvIGFsbG93IHRoZSBQQ0MgdG8gdGVs bCBhbGwgdGhlIFBDRXMgdGhhdA0KaGU8YnI+DQomZ3Q7d2FudCB0byBoYXZlIHRoZSBMU1Agc3Rh dGUgZGVsZWdhdGVkLDxicj4NCiZndDtUaGUgZmlyc3Qgb25lIHRvIHNlbmQgYW4gdXBkYXRlIHdp bnMsPGJyPg0KPGJyPg0KVGhhdCdzIGEgcG9zc2liaWxpdHkuIFRoZSBQQ0Mgd291bGQgdGhlbiBy ZXZva2UgTFNQIGRlbGVnYXRpb24gZnJvbSB0aGU8YnI+DQpvdGhlciBQQ0UuIEFub3RoZXIgcG9z c2liaWxpdHkgd291bGQgYmUgdG8gYWR2ZXJ0aXNlIHRoZSBwcmVmZXJyZWQgYWN0aXZlPGJyPg0K UENFIGluIElTLUlTIG9yIE9TUEYuIFdlIHNob3VsZCBkZWZpbmUgZXh0ZW5zaW9ucyB0byBSRkNz IDUwODggYW5kIDUwODk8YnI+DQpmb3IgYWR2ZXJ0aXNpbmcgb2Ygc3RhdGVmdWwgUENFczsgYWRk aXRpb25hbCBQQ0UgYXR0cmlidXRlcywgc3VjaCBhczxicj4NCnByZWZlcnJlZCBhY3RpdmUgUENF LCBjb3VsZCBiZSBhZHZlcnRpc2VkIGF0IHRoZSBzYW1lIHRpbWUuPC9mb250PjwvdHQ+DQo8YnI+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZsdDtLZXhpbiZndDs6 SSBwcmVmZXIgdGhlIGZvcm1lciB0aGF0DQpDeXJpbCB3cm90ZSwgc2luY2UgaXQgaXMgbW9yZSBz aW1wbGUuIFRoZSBsYXR0ZXIgcG9zc2liaWxpdHkgeW91IGRlc2NyaWJlZA0KbmVlZHMgZXh0cmEg aW5mb3JtYXRpb24gaW4gUENFIERpc2NvdmVyeSBhZHZlcnRpc2VtZW50LDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IGFuZCB3aXRoDQp0aGUgbmV3bHkgY2hhbmdlIG9mIGFjdGl2ZSBQQ0UsIHRoaXMgYWR2ZXJ0aXNl bWVudCBjb3VsZCBiZSBmcmVxdWVudGx5Lg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSW5kZWVkLHRvDQppbnRy b2R1Y2Ugc3RhdGVmdWwgUENFcywgZXh0ZW50aW9ucyB0byBQQ0UgRGlzY292ZXJ5IChSRkM1MDg4 LFJGQzUwODkpDQppcyBuZWVkZWQsdG8gYWR2ZXJ0aXNlIHRoZSBzdGF0ZWZ1bCBQQ0VzIGFzIHlv dSBzYWlkIGFib3ZlLiAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyA8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBIb3dldmVyLA0KUENFIERpc2NvdmVyeSBhZHZlcnRpc2VtZW50IGlzIG5vdCBuZWVk ZWQgdW5sZXNzIHRoZSBsb2NhdGlvbiBvciBjYXBhYmlsaXR5DQpvZiBhIFBDRSBpcyBjaGFuZ2Vk LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+QmVzdCBSZWdhcmRzLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+S2V4aW48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+PGI+SmFuIE1lZHZlZCAmbHQ7am1lZHZlZEBqdW5pcGVyLm5ldCZndDs8L2I+DQo8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyBwY2UtYm91bmNlc0Bp ZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDExLTEx LTA5IDE1OjI1PC9mb250Pg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRy IHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj7mlLbku7bkuro8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPiZxdW90O01hcmdhcmlhLCBDeXJpbCAoTlNOIC0gREUvTXVuaWNoKSZxdW90 Ow0KJmx0O2N5cmlsLm1hcmdhcmlhQG5zbi5jb20mZ3Q7LCAmcXVvdDtkcmFmdC1jcmFiYmUtcGNl LXN0YXRlZnVsLXBjZUB0b29scy5pZXRmLm9yZyZxdW90Ow0KJmx0O2RyYWZ0LWNyYWJiZS1wY2Ut c3RhdGVmdWwtcGNlQHRvb2xzLmlldGYub3JnJmd0OywgJnF1b3Q7cGNlQGlldGYub3JnJnF1b3Q7 DQombHQ7cGNlQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRp diBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+5oqE6YCBPC9mb250 PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7kuLvpopg8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbUGNlXSBDb21tZW50cyBvbiBkcmFmdC1j cmFiYmUtcGNlLXN0YXRlZnVsLXBjZS0wMTwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0K PHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0K PGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SGkgQ3lyaWwsPGJyPg0KPGJyPg0KVGhhbmtzIGEg bG90IGZvciB0aGUgY29tbWVudHMsIHBsZWFzZSBzZWUgaW5saW5lLjxicj4NCjxicj4NCjxicj4N Cjxicj4NCi9KYW48YnI+DQo8YnI+DQpPbiAxMS84LzExIDc6MDcgQU0sICZxdW90O01hcmdhcmlh LCBDeXJpbCAoTlNOIC0gREUvTXVuaWNoKSZxdW90Ozxicj4NCiZsdDtjeXJpbC5tYXJnYXJpYUBu c24uY29tJmd0OyB3cm90ZTo8YnI+DQo8YnI+DQomZ3Q7SGksIDxicj4NCiZndDs8YnI+DQomZ3Q7 SSBmaW5kIHRoaXMgZG9jdW1lbnQgdmVyeSBpbnRlcmVzdGluZyw8YnI+DQomZ3Q7UGxlYXNlIGZp bmQgbXkgZmV3IGNvbW1lbnRzIGJlbG93Ojxicj4NCiZndDs8YnI+DQomZ3Q7U2VjdGlvbiAyLjxi cj4NCiZndDsgJm5ic3A7IFJlZ2FyZGluZyAmbmJzcDtSZXN0b3JhdGlvbiBhbmQgUGF0aCBQcm90 ZWN0aW9uIDogJm5ic3A7V29yZGluZw0KaXMgbm90IGFsaWduZWQ8YnI+DQomZ3Q7d2l0aCBHTVBM UyAoUkZDNDQyNykgOiBwcm90ZWN0aW9uIGhlcmUgc2VlbXMgdXNlZCBmb3IgcHJlLXBsYW5uZWQ8 YnI+DQomZ3Q7cmVzdG9yYXRpb24gYW5kIHJlc3RvcmF0aW9uIGZvciBkeW5hbWljIHNvdXJjZSBy ZXJvdXRlLjxicj4NCiZndDtJbiBhZGRpdGlvbiAmbmJzcDtpdHMgbm90IGNsZWFyIHdoeSB0aGUg dGVybSAmcXVvdDtnbG9iYWwmcXVvdDsgaXMNCnVzZWQuPGJyPg0KPGJyPg0KV2UgdXNlZCB0ZXJt aW5vbG9neSBwcm9wb3NlZCBmb3IgTVBMUyBUcmFmZmljIEVuZ2luZWVyaW5nIGluICZxdW90O05l dHdvcms8YnI+DQpSZWNvdmVyeTogUHJvdGVjdGlvbiBhbmQgUmVzdG9yYXRpb24gb2YgT3B0aWNh bCwgU09ORVQgU0RILCBJUCwgYW5kIE1QTFMmcXVvdDsuPGJyPg0KV0UgY2hvc2UgaXQgYmVjYXVz ZSBpdCBjb250YWlucyBhIHByZWNpc2UgZGVzY3JpcHRpb24gb2YgcHJvdGVjdGlvbiB1c2U8YnI+ DQpjYXNlcyB0aGF0IHdlIHRoaW5rIHNob3VsZCBiZSBjb3ZlcmVkIGJ5IHN0YXRlZnVsIFBDRVAu IERvIHlvdSB0aGluayB3ZTxicj4NCnNob3VsZCByYXRoZXIgYWxpZ24gdGhlIHRlcm1pbm9sb2d5 IHdpdGggcmZjNDQyNz88YnI+DQo8YnI+DQomZ3Q7PGJyPg0KJmd0O1NlY3Rpb24gMy4xLjMuIDo8 YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIGRvIG5vdCB0aGluayB0aGUgZG9jdW1lbnQgc2hvdWxkIHJl c3RyaWN0IHRoZSBzZXQgb2YgcGFyYW1ldGVycw0KdG88YnI+DQomZ3Q7Y29uc2lkZXIsIHRoZSBz ZXQgb2YgcGFyYW1ldGVycyBzaG91bGQgYmUgSU1ITyBiZSBuZWdvdGlhdGVkIGFuZCBzaG91bGQ8 YnI+DQomZ3Q7ZGVwZW5kIG9uIGxvY2FsIHBvbGljeSAoYXQgUENDIG9yIFBDRSBsZXZlbCk8YnI+ DQo8YnI+DQpBZ3JlZWQuIFdlIHdpbGwgbmVlZCB0byBpbnRyb2R1Y2UgY2FwYWJpbGl0eSAvIHBh cmFtZXRlciBuZWdvdGlhdGlvbiBpbnRvPGJyPg0KdGhlIGRvY3VtZW50LiA8YnI+DQo8YnI+DQom Z3Q7PGJyPg0KJmd0O1lvdSBzdGF0ZSB0aGF0IHRoZSBQQ0VQIGV4dGVuc2lvbiBwcm9wb3NlIGEg Y29tbW9uIHN0YXRlIHJlcHJlc2VudGF0aW9uLDxicj4NCiZndDtidXQgaXQgc2VlbXMgdGhhdCBp dHMgY3VycmVudGx5IHNpZ25hbGVkIG9yIG5vdCBzaWduYWxlZC48YnI+DQomZ3Q7PGJyPg0KJmd0 O1NlY3Rpb24gNS4xPGJyPg0KJmd0O0luIHRoZSBQQ0VQIHByb3RvY29sIChkZWZpbmVkIGluIFtS RkM1NDQwXSksIExTUCBzdGF0ZSAmbmJzcDthbmQgb3BlcmF0aW9uDQphcmU8YnI+DQomZ3Q7dW5k ZXIgdGhlIGNvbnRyb2wgb2YgdGhlIFBDQywgdGhlIHJlY2VpdmVkIGF0dHJpYnV0ZXMgZnJvbSB0 aGUgUENFDQphcmU8YnI+DQomZ3Q7c3ViamVjdCB0byBQQ0MgbG9jYWwgcG9saWN5Ljxicj4NCiZn dDtUaGUgZXh0ZW5zaW9ucyBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgZG8gbm90IGNoYW5nZSB0 aGlzIGJlaGF2aW9yLjxicj4NCjxicj4NClllcy4gV2UnbGwgYWRkIHRoaXMgdGV4dCB0byB0aGUg ZG9jdW1lbnQuPGJyPg0KPGJyPg0KJmd0Ozxicj4NCiZndDtTZWN0aW9uIDUuNC48YnI+DQomZ3Q7 IC0gJm5ic3A7TWVjaGFuaXNtIGZyb20gUkZDMzYyMyBjb3VsZCBiZSB1c2VkIGluIHRoZSBPUEVO IHNlcXVlbmNlDQppbiBvcmRlcjxicj4NCiZndDtub3QgdG8gZG8gYSBmdWxsIHJlc3luY2hyb25p emF0aW9uIGlmIHRoZSBzdGF0ZSBvbiBQQ0MgZGlkIG5vdCBjaGFuZ2U8YnI+DQomZ3Q7KGFuZCB0 aGUgUENFIGRpZCBrZWVwIHRoZSBwcmV2aW91cyBzdGF0ZSk8YnI+DQo8YnI+DQpIbW1tLCB0aGF0 J3MgYSBnb29kIGlkZWEuIFdlIHNob3VsZCBkaXNjdXNzIGluIG1vcmUgZGV0YWlsLjxicj4NCjxi cj4NCiZndDstIExTUCBkZWxlZ2F0aW9uIDogSSB0aGluayBpdHMgb2J2aW91cywgYnV0IHRoZSBk ZWxlZ2F0aW9uIGlzIHN0b3BwZWQNCmlmPGJyPg0KJmd0O3RoZSBQQ0VQIHNlc3Npb24gaXMgY2xv c2VkLjxicj4NCjxicj4NCkNvcnJlY3QuIFdlJ2xsIGFkZCB0aGlzIHRvIHRoZSBkb2N1bWVudCB0 b28uPGJyPg0KPGJyPg0KJmd0Ozxicj4NCiZndDtTZWN0aW9uIDUuNS4gYW5kIHNlY3Rpb24gNS41 LjQuPGJyPg0KJmd0Ozxicj4NCiZndDtZb3UgcmVxdWlyZSB0aGF0IHRoZSBQQ0MgaXMgYXdhcmUg b2YgdGhlIFBDRSByb2xlIChhY3RpdmUvYmFja3VwKSBvbmU8YnI+DQomZ3Q7YW5vdGhlciBzb2x1 dGlvbiBjb3VsZCBiZSB0byBhbGxvdyB0aGUgUENDIHRvIHRlbGwgYWxsIHRoZSBQQ0VzIHRoYXQN CmhlPGJyPg0KJmd0O3dhbnQgdG8gaGF2ZSB0aGUgTFNQIHN0YXRlIGRlbGVnYXRlZCw8YnI+DQom Z3Q7VGhlIGZpcnN0IG9uZSB0byBzZW5kIGFuIHVwZGF0ZSB3aW5zLDxicj4NCjxicj4NClRoYXQn cyBhIHBvc3NpYmlsaXR5LiBUaGUgUENDIHdvdWxkIHRoZW4gcmV2b2tlIExTUCBkZWxlZ2F0aW9u IGZyb20gdGhlPGJyPg0Kb3RoZXIgUENFLiBBbm90aGVyIHBvc3NpYmlsaXR5IHdvdWxkIGJlIHRv IGFkdmVydGlzZSB0aGUgcHJlZmVycmVkIGFjdGl2ZTxicj4NClBDRSBpbiBJUy1JUyBvciBPU1BG LiBXZSBzaG91bGQgZGVmaW5lIGV4dGVuc2lvbnMgdG8gUkZDcyA1MDg4IGFuZCA1MDg5PGJyPg0K Zm9yIGFkdmVydGlzaW5nIG9mIHN0YXRlZnVsIFBDRXM7IGFkZGl0aW9uYWwgUENFIGF0dHJpYnV0 ZXMsIHN1Y2ggYXM8YnI+DQpwcmVmZXJyZWQgYWN0aXZlIFBDRSwgY291bGQgYmUgYWR2ZXJ0aXNl ZCBhdCB0aGUgc2FtZSB0aW1lLjxicj4NCiA8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDtJdCBz dGF0ZWQgdGhhdCBvbmx5IG9uZSBQQ0UgbWF5IGhhdmUgY29udHJvbCBvZiBhbiBMU1AsIGJ1dA0K SSBkbyB0aGluazxicj4NCiZndDt0aGF0IHRoZSBmb2xsb3dpbmcgc2hvdWxkIGJlIGFsbG93ZWQg Ojxicj4NCiZndDstICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsNClBDQyBvciBQQ0UgcmVxdWVzdGluZyBMU1Agc3RhdGUgZGVsZWdhdGlvbiA6 IHNldmVyYWwgZGVsZWdhdGlvbiB0bzxicj4NCiZndDtzZXZlcmFsIFBDRSBNQVkgYmUgYWNjZXB0 ZWQ8YnI+DQo8YnI+DQpZb3UncmUgcmlnaHQgdGhhdCB0aGUgcHJvdG9jb2wgaXRzZWxmIHNob3Vs ZCBub3QgcmVzdHJpY3QgTFNQIGRlbGVnYXRpb248YnI+DQp0byBhIHNpbmdsZSBQQ0UgLSB0aGF0 IHNob3VsZCBiZSB1bmRlciBjb250cm9sIG9mIGFuIG9wZXJhdG9yLWRlZmluZWQ8YnI+DQpwb2xp Y3kuIEkgdGhpbmsgbW9zdCBvZiB0aGUgdGltZSB0aGUgcG9saWN5IHNob3VsZCBiZSBkZWZpbmVk IHN1Y2ggdGhhdA0KYW48YnI+DQpMU1AgaXMgZGVsZWdhdGVkIHRvIGEgc2luZ2xlIFBDRS4gQnV0 LCBwb2ludCB0YWtlbi4gV2UnbGwgdXBkYXRlIHRoZSB0ZXh0Ljxicj4NCiAmbmJzcDs8YnI+DQo8 YnI+DQomZ3Q7LSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7DQpVcG9uIHJlY2VwdGlvbiBvZiBhIFBDVXBkIHdpdGggZGVsZWdhdGU9MSwgdGhl IFBDQyAmbmJzcDtNVVNUIHNlbmQgYSBQQ1JwdCw8YnI+DQomZ3Q7RGVsZWdhdGU9MCB0byB0aGUg b3RoZXIgUENFPGJyPg0KPGJyPg0KSWYgYSBQQ0UgYXR0ZW1wdHMgdG8gdXBkYXRlIGFuIExTUCB0 aGF0IGlzIG5vdCBkZWxlZ2F0ZWQgdG8gaXQsIHRoZSBQQ0M8YnI+DQpNVVNUIHNlbmQgYmFjayBh IFBDRXJyIHdpdGggYSBUQkQgZXJyb3IgY29kZS48YnI+DQo8YnI+DQomZ3Q7PGJyPg0KJmd0O1Ro ZSBiYWNrZ3JvdW5kIG9mIHRoYXQgaXMgdGhhdCB0aGUgUENFIGlzICZuYnNwO3JlZHVuZGFudCBh bmQgdGhlIGFyY2hpdGVjdHVyZTxicj4NCiZndDtjaG9zZW4gdXNlIG9uZSBQQ0VQIHNlc3Npb24g cGVyIFBDRSBpbnN0YW5jZSwgb25lIGluc3RhbmNlIGlzIGFjdGl2ZQ0KYXQgYTxicj4NCiZndDt0 aW1lLjxicj4NCjxicj4NClllcywgdGhhdCdzIHRoZSBtb3N0IGNvbW1vbiB1c2UgY2FzZS48YnI+ DQo8YnI+DQomZ3Q7PGJyPg0KJmd0O1NlY3Rpb24gNS42LjEuPGJyPg0KJmd0O0kgdGhpbmsgdGhh dCAmbmJzcDt0aGUgZm9sbG93aW5nIG1lY2hhbmlzbSBzaG91bGQgYmUgYWRkZWQgOjxicj4NCiZn dDsgJm5ic3A7UHJpb3IgdG8gdGhlIFBDUmVxIHRoZSBQQ0Mgc2VuZCBhIFBDUnB0IGZvciB0aGUg TFNQIHdpdGggc3RhdGUNCnBlbmRpbmc8YnI+DQomZ3Q7KG5vIHBhdGggdGhlbikgPGJyPg0KJmd0 OyAmbmJzcDtVcG9uIHRoZSBQQ1JlcSB0aGUgUENFIGNhbiBhbHJlYWR5IGNvbnNpZGVyIHRoZSBy ZXNvdXJjZXMgdXNlZC48YnI+DQomZ3Q7PGJyPg0KJmd0O1RoaXMgd291bGQgYWxsb3cgYSBQQ0Mg dG8gY292ZXIgdGhlIGNhc2Ugd2hlcmUgaXQgaW50ZW5kIHRvIGVzdGFibGlzaA0KdGhlPGJyPg0K Jmd0O0xTUCBhZnRlciBnZXR0aW5nIHRoZSBQQ1JlcCAoc28gdGhlIHJlc291cmNlcyBjb21wdXRl ZCB3aWxsIGJlIG1hcmtlZA0KYXM8YnI+DQomZ3Q7cGVuZGluZyBpbiB0aGUgUENFIGFscmVhZHkp ICZuYnNwO29yIHNpZ25hbCBpdCBsYXRlci48YnI+DQo8YnI+DQpBaCwgSSBzZWUgd2hhdCB5b3Ug bWVhbi4gSSBsaWtlIGl0IDotKTxicj4NCjxicj4NCiZndDs8YnI+DQomZ3Q7U2VjdGlvbiA1LjYu Mi48YnI+DQomZ3Q7IFlvdSBzdGF0ZSB0aGF0IHRoZSBQQ0MgTVVTVCBOT1Qgc2VuZCBhIHBhdGgg Y29tcHV0YXRpb24gZm9yIGEgZGVsZWdhdGVkPGJyPg0KJmd0O1BDRSwgYnV0IHNlY3Rpb24gNS4x IGluZGljYXRlIHRoYXQgdGhlIExTUCBzdGF0ZSBpcyBvd25lZCBieSB0aGUgUENDLA0Kc288YnI+ DQomZ3Q7Zm9yIGV4YW1wbGUgdGhlIFBDQyBNQVkgZGVsZWdhdGUgdGhlIHNldHVwL2hvbGRpbmcg cHJpb3JpdHkgdG8gdGhlDQombmJzcDtQQ0M8YnI+DQomZ3Q7YnV0IG5vdCB0aGUgcHJvdGVjdGlv biAmbmJzcDtiZWhhdmlvciAoZm9yIGV4YW1wbGUgaWYgdGhlIGJlaGF2aW9yDQppcyBub3Q8YnI+ DQomZ3Q7c3VwcG9ydGVkIGJ5IHRoZSBQQ0UpLCBpbiB3aGljaCBjYW4gdGhlIFBDQyBuZWVkIHRv IHNlbmQgcGF0aCBjb21wdXRhdGlvbjxicj4NCiZndDtyZXF1ZXN0Ljxicj4NCjxicj4NCkhtLCB3 ZSBkaWQgbm90IHRoaW5rIG9mIHBhcnRpYWwgZGVsZWdhdGlvbi4gRm9yIHNpbXBsaWNpdHksIHdl IHdvdWxkIGxpa2U8YnI+DQp0byBrZWVwIGl0IGFsbC1vci1ub3RoaW5nLCB1bmxlc3MgdGhlcmUg YXJlIGNvbXBlbGxpbmcgcmVhc29ucyB0byBkbzxicj4NCnNvbWV0aGluZyBtb3JlIHBvd2VyZnVs IChhbmQgY29tcGxleCkuIFdFIHNob3VsZCBkaXNjdXNzLCB0aG91Z2gsIGl0J3MNCmFuPGJyPg0K aW50ZXJlc3RpbmcgaWRlYS48YnI+DQo8YnI+DQpUaGUgc3RhdGVtZW50IGFib3V0IExTUCBzdGF0 ZSBvd25lcnNoaXAgaXMgcmVsYXRlZCB0byB0aGUgZmFjdCB0aGF0IHRoZTxicj4NClBDQyBjYW4g cmV2b2tlIHRoZSBkZWxlZ2F0aW9uIGF0IGFueSB0aW1lLiBJdCBjYW4gZGVjaWRlIHdoZXRoZXIg dG88YnI+DQpkZWxlZ2F0ZSBvciBub3QsIGFuZCB0byB3aG9tIHRvIGRlbGVnYXRlLiBBbHNvLCB0 aGUgUENDIGhhcyB0byBjbGVhbnVwDQp0aGU8YnI+DQpMU1Agc3RhdGUgaWYgdGhlIGNvbm5lY3Rp b24gdG8gdGhlIFBDRSBpcyB0ZXJtaW5hdGVkLiBCdXQgdGhlIGFzc3VtcHRpb248YnI+DQp3YXMg dGhhdCBvbmNlIGFuIExTUCBpcyBkZWxlZ2F0ZWQsIHRoZSBQQ0UgaGFzIGZ1bGwgY29udHJvbCBv ZiB0aGUgTFNQLDxicj4NCiA8YnI+DQomZ3Q7PGJyPg0KJmd0O1NlY3Rpb24gNS43LiA8YnI+DQom Z3Q7ICZuYnNwOyBUaGUgcHJvdGVjdGlvbiBjb250cm9sIGJ5IFBDRSBNQVkgYmUgZGVzaXJlZCwg YnV0IEkgZG8gbm90DQp0aGluayBpdCdzPGJyPg0KJmd0O2EgbXVzdC4gKCBJIGRvIHRoaW5rIGFi b3V0IEdNUExTIHdoZXJlIEZSUiBtaWdodCBub3QgYmUgc3VwcG9ydGVkIGF0DQphbGwpPGJyPg0K Jmd0OyAmbmJzcDsgSSBkbyBub3QgJm5ic3A7dGhpbmsgdGhhdCB0aGUgZG9jdW1lbnQgc2hvdWxk IG1hbmRhdGUgYSBtaW5pbXVtDQpzZXQgb2Y8YnI+DQomZ3Q7YmVoYXZpb3IgZnJvbSB0aGUgUENF LiBUaGlzIG1pZ2h0IGJlIHN1YmplY3QgdG8gYW5vdGhlciBkb2N1bWVudC48YnI+DQo8YnI+DQpB Z3JlZWQgb24gYWxsIHBvaW50cy4gUHJvdGVjdGlvbiByZXF1aXJlcyBpdHMgb3duIGRvY3VtZW50 LiBXZSBoYWQgdG8gcHV0PGJyPg0Kc29tZSBpbmZvIGludG8gdGhpcyBkb2N1bWVudCBpbiBvcmRl ciB0byBiZSBhYmxlIHRvIGRlZmluZSB0aGUgUENScHQgYW5kPGJyPg0KUENVcGQgbWVzc2FnZXMu PGJyPg0KPGJyPg0KJmd0Ozxicj4NCiZndDtTZWN0aW9uIDYuMS48YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCk9uZSBtb3Rp dmF0aW9uIHlvdSBtZW50aW9uZWQgb24gdGhlIGxpc3Qgd2FzIHRvIGFsbG93IGRpZmZlcmVudCBv YmplY3RzPGJyPg0KJmd0O3RoYW4gdGhlIFBDRVAgb25lLCBob3dldmVyIHlvdSBhcmUgdXNpbmcg dGhlIG9uZSBmcm9tIFBDRVAgKEkgd291bGQ8YnI+DQomZ3Q7c3VnZ2VzdCB0byB0YWtlIGludG8g YWNjb3VudDxicj4NCiZndDtkcmFmdC1pZXRmLXBjZS1nbXBscy1wY2VwLWV4dGVuc2lvbnMgYW5k IFJGQzYwMDYgaW4gdGhhdCBjYXNlKTxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0KJmd0 Oy0gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Ow0KYmFja3VwLXBhdGgtbGlzdDogaW4gY2FzZSBwMm1wIGlzIHVzZWQgdGhpcyBjb3VsZCBiZSBh IHByb2JsZW08YnI+DQomZ3Q7LSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7DQpNaXNzaW5nIFBQUk8gZm9yIGJhY2t1cCBMU1BzPGJyPg0KJmd0 Oy0gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Ow0KTWlzc2luZyBhc3NvY2lhdGlvbiBiZXR3ZWVuIExTUHMgKG9uZSBjYXNlIG1lbnRpb25lZCBp cyAyPGJyPg0KJmd0O3VuaWRpcmVjdGlvbmFsIExTUHMsIHRoZSBvdGhlciBjYXNlIGFyZSByZmM0 ODcyIGFuZCByZmM0ODczIGZvciBpbnN0YW5jZSk8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCjxicj4NCiZndDtGb3IgYSBn aXZlbiBMU1AgdGhlcmUgaXMgc2V2ZXJhbCBwYXRoLCBidXQgdGhlcmUgaXMgbm8gc3RhdGVtZW50 PGJyPg0KJmd0O2luZGljYXRpbmcgaWYgdGhlIHJlc291cmNlcyBvbiB0aG9zZSBwYXRoIGFyZSA6 PGJyPg0KJmd0Oy0gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KUmVzZXJ2ZWQgOiBpLmUgc2lnbmFsZWQ8YnI+DQomZ3Q7LSAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpTaGFyZWQgOnJl c2VydmVkIGFuZCBzaGFyZWQgYmV0d2VlbiBMU1BzIChmb3IgaW5zdGFuY2UgYXMgaW4gUkZDNDg3 Mik8YnI+DQomZ3Q7LSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQomcXVvdDtQbGFubmVkJnF1b3Q7ICZuYnNwOzogbm90IHNpZ25hbGVkLCBv bmx5IGV4aXN0IGluIHRoZSBQQ0MuPGJyPg0KJmd0Ozxicj4NCiZndDtUaGUgcHJvdmlzaW9uaW5n IHN0YXRlIG9mIHRoZSBMU1AgaXMgb25seSBzdGF0ZSBpbiB0aGUgTyBiaXQgb2YgdGhlDQpMU1As PGJyPg0KJmd0O2J1dCB0aGUgc3RhdGUgcGVuZGluZyB1cCBkb3duIGFyZSBub3QgY2xlYXJseSBp ZGVudGlmaWVkLjxicj4NCjxicj4NCkdvb2QgcG9pbnRzLjxicj4NCjxicj4NCiZndDs8YnI+DQom Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCjxicj4NCiZndDtTZWN0aW9uIDYuMi48YnI+DQomZ3Q7IFRoaXJkIHBhcmFncmFwaCA6IHRo ZSBwYXJhZ3JhcGggc3RhdGUgdGhlIExTUCBTdGF0ZSByZXBvcnQgaW5zdGVhZA0Kb2Y8YnI+DQom Z3Q7TFNQIFVwZGF0ZSwgbW9yZW92ZXIgdGhlIHByaW1hcnkgKGFuZCBiYWNrdXApIHBhdGggYXJl IG9wdGlvbmFsIC48YnI+DQomZ3Q7VGhlIHN0YXRlbWVudCAmcXVvdDtJZiB0aGUgTFNQIHNwZWNp ZmllZCB0aGUgVXBkYXRlIFJlcXVlc3QgJm5ic3A7DQppcyBhbHJlYWR5IHVwLDxicj4NCiZndDtp dCB3aWxsIGJlIHRvcm4gZG93biBhbmQgcmUtc2lnbmFsZWQuJnF1b3Q7IEluZGljYXRlIHRoYXQg dGhlIFBDQyBtdXN0DQp1c2U8YnI+DQomZ3Q7YnJlYWstYmVmb3JlLW1ha2UsIHdoaWNoIGlzIGNv bnRyYWRpY3Rpbmcgd2l0aCB0aGUgbmV4dCBzZW50ZW5jZS4gJm5ic3A7SQ0KZG88YnI+DQomZ3Q7 dGhpbmsgdGhpcyBzaG91bGQgYmUgY29uZmlndXJhYmxlLCBzaW1pbGFybHkgd2l0aCBHQ08uPGJy Pg0KPGJyPg0KWWVzLCBnb29kIHBvaW50Ljxicj4NCjxicj4NCiZndDs8YnI+DQomZ3Q7SSBkbyBh bHNvIHRoaW5rIHRoYXQgR0NPIGNvdWxkIGJlIGxldmVyYWdlIGJ5IHRoZSBQQ0UgdG8gaW5kaWNh dGUgdG8NCnRoZTxicj4NCiZndDtQQ0Mgd2hpY2ggTFNQIGhlIGNvdWxkIHJlLW9wdGltaXplLCBp dCBjb3VsZCBiZSBkb25lIGZvciBleGFtcGxlIGJ5PGJyPg0KJmd0O0luZGljYXRlIGluIHRoZSBQ Q1VwZCB0aGF0IGEgc2V0IG9mIExTUCBjb3VsZCBiZSByZW9wdGltaXplZCB1c2luZw0KR0NPPGJy Pg0KJmd0OyhhbmQgcHJvdmlkaW5nIHRoZSBHQyBvYmplY3QpLiBUaGlzIGNhbiBiZSBpbmRlcGVu ZGVudCBvZiB0aGUgRGVsZWdhdGlvbjxicj4NCiZndDtmb3IgdGhvc2UgTFNQcywgYW5kIHdvdWxk IGJlIGFuIGFwcGxpY2F0aW9uIG9mIGJ1bGxldCAzIG9mIHNlY3Rpb248YnI+DQomZ3Q7My4xLjIu Ni48YnI+DQo8YnI+DQpZZXMuIEdvb2QgcG9pbnQuPGJyPg0KPGJyPg0KJmd0Ozxicj4NCiZndDtT ZWN0aW9uIDcuMi48YnI+DQomZ3Q7UFJPVEVDVElPTi1BVFRSSUJVVEUgVExWIGZyb20gZHJhZnQt aWV0Zi1wY2UtZ21wbHMtcGNlcC1leHRlbnNpb25zDQombmJzcDtjb3VsZDxicj4NCiZndDthbHNv IGJlIGNvbnNpZGVyZWQgdG8gcmVwb3J0IHRoZSBwcm90ZWN0aW9uIGFuZCBzaWduYWxpbmcgc3Rh dGUuPGJyPg0KJmd0O0luIG9yZGVyIHRvIGZ1bGZpbGwgdGhlIG9iamVjdGl2ZSAmcXVvdDtBbGxv dyBhIFBDRSB0byBzcGVjaWZ5IHByb3RlY3Rpb24NCi88YnI+DQomZ3Q7cmVzdG9yYXRpb24gc2V0 dGluZ3MgZm9yIGFsbCAmbmJzcDtMU1BzIHRoYXQgaGF2ZSBiZWVuIGRlbGVnYXRlZCB0bw0KaXQu JnF1b3Q7IEk8YnI+DQomZ3Q7dGhpbmsgdGhhdCB0aGUgZm9sbG93aW5nIGlzIG5lY2Vzc2FyeSB0 byBiZSBhZGRlZCA6PGJyPg0KJmd0Oy0gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KQVNTT0NJQVRJT04gPGJyPg0KJmd0Oy0gJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KUFJPVEVDVElP Ti1BVFRSSUJVVEUgaW4gTFNQQTxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0O1NlY3Rpb24g Ny4yLjIuPGJyPg0KJmd0OyAtICZuYnNwOyBUaGUgdHVubmVsIHNlbmRlciBpZCBpcyAmbmJzcDtt aXNzaW5nICZuYnNwOyhUaGVyZSBpcyBubw0KZ3VhcmFudGVlIHRoYXQgb25lPGJyPg0KJmd0O1BD QyBpcyBtYW5hZ2luZyBvbmx5IG9uZSBub2RlKTxicj4NCjxicj4NCkhtLCBvay4gQnV0IHRoZW4g d2UgYWxzbyBuZWVkIHRvIHNvbWVob3cgYWRkIHRoZSBzZW5kZXIgaWQgdG8gdGhlIFBDVXBkPGJy Pg0KbWVzc2FnZXMgdG9vLjxicj4NCjxicj4NCiZndDsgLSAmbmJzcDtGcm9tIFR1bm5lbCBJRCB5 b3Ugc2VlbSB0byBpbXBseSB0aGF0IHdoYXQgaXMgY29uc2lkZXJlZCBieQ0KdGhlIHN0YXRlPGJy Pg0KJmd0O2Z1bGwgUENFIGlzIG1vcmUgYSBjYWxsIHRoYW4ganVzdCBhbiBMU1AuIEFzIGFzc29j aWF0aW9uIGNhbiBiZSBiZXR3ZWVuPGJyPg0KJmd0O0xTUHMgaGF2aW5nIGRpZmZlcmVuY2Ugc2Vz c2lvbiBhbmQgc2VuZGVyIHRlbXBsYXRlIChSRkM0ODczKSwgSSBkbw0KdGhpbms8YnI+DQomZ3Q7 dGhhdCB0aGlzIHNpbXBsaWZpY2F0aW9uIG1heSAmbmJzcDtjYXVzZSBwcm9ibGVtLjxicj4NCiZn dDs8YnI+DQomZ3Q7TG9va2luZyBmb3J3YXJkIHRvIGRpc2N1c3NpbmcgdGhpcyBpbiBUYWlwZWku PGJyPg0KPGJyPg0KUmVhbGx5IGxvb2tpbmcgZm9yd2FyZCB0byB0YWxraW5nIHRvIHlvdSB0b28u PGJyPg0KPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7TWl0IGZyZXVuZGxpY2hlbiBHcsO8 w59lbiAvIEJlc3QgUmVnYXJkczxicj4NCiZndDtDeXJpbCBNYXJnYXJpYTxicj4NCiZndDs8YnI+ DQomZ3Q7Tm9raWEgU2llbWVucyBOZXR3b3JrcyBHbWJIICZhbXA7IENvLiBLRzxicj4NCiZndDtO V1MgRFdETSBSRDxicj4NCiZndDtTdC5NYXJ0aW4tU3RyLiA3Njxicj4NCiZndDtELTgxNTQxIE3D vG5jaGVuPGJyPg0KJmd0O0dlcm1hbnk8YnI+DQomZ3Q7bWFpbHRvOmN5cmlsLm1hcmdhcmlhQG5z bi5jb208YnI+DQomZ3Q7UGhvbmU6ICs0OS04OS01MTU5LTE2OTM0PGJyPg0KJmd0O0ZheDogJm5i c3A7ICs0OS04OS01MTU5LTQ0LTE2OTM0PGJyPg0KJmd0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7Tm9raWEg U2llbWVucyBOZXR3b3JrcyBHbWJIICZhbXA7IENvLiBLRzxicj4NCiZndDtTaXR6IGRlciBHZXNl bGxzY2hhZnQ6IE3DvG5jaGVuIC8gUmVnaXN0ZXJlZCBvZmZpY2U6IE11bmljaDxicj4NCiZndDtS ZWdpc3RlcmdlcmljaHQ6IE3DvG5jaGVuIC8gQ29tbWVyY2lhbCByZWdpc3RyeTogTXVuaWNoLCBI UkEgODg1Mzc8YnI+DQomZ3Q7V0VFRS1SZWcuLU5yLjogREUgNTI5ODQzMDQ8YnI+DQomZ3Q7UGVy c8O2bmxpY2ggaGFmdGVuZGUgR2VzZWxsc2NoYWZ0ZXJpbiAvIEdlbmVyYWwgUGFydG5lcjogTm9r aWEgU2llbWVuczxicj4NCiZndDtOZXR3b3JrcyBNYW5hZ2VtZW50IEdtYkg8YnI+DQomZ3Q7R2Vz Y2jDpGZ0c2xlaXR1bmcgLyBCb2FyZCBvZiBEaXJlY3RvcnM6IERyLiBIZXJtYW5uIFJvZGxlciwg THlkaWEgU29tbWVyLDxicj4NCiZndDtPbGFmIEhvcnN0aGVta2UgPGJyPg0KJmd0O1ZvcnNpdHpl bmRlciBkZXMgQXVmc2ljaHRzcmF0cyAvIENoYWlybWFuIG9mIHN1cGVydmlzb3J5IGJvYXJkOiBI ZXJiZXJ0PGJyPg0KJmd0O01lcnogPGJyPg0KJmd0O1NpdHogZGVyIEdlc2VsbHNjaGFmdDogTcO8 bmNoZW4gLyBSZWdpc3RlcmVkIG9mZmljZTogTXVuaWNoPGJyPg0KJmd0O1JlZ2lzdGVyZ2VyaWNo dDogTcO8bmNoZW4gLyBDb21tZXJjaWFsIHJlZ2lzdHJ5OiBNdW5pY2gsIEhSQiAxNjM0MTY8YnI+ DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCiZndDtQY2UgbWFpbGluZyBsaXN0PGJyPg0KJmd0O1BjZUBp ZXRmLm9yZzxicj4NCiZndDtodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bj ZTxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KUGNlIG1haWxpbmcgbGlzdDxicj4NClBjZUBpZXRmLm9yZzxicj4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNlPGJyPg0KPGJyPg0KPC9mb250PjwvdHQ+ DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5i c3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7 aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkm bmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1Ro aXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFs LiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2Js aWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDth cmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhl Jm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7 dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtm aWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29u ZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJz cDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZu YnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRy ZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlz Jm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5i c3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJz cDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21l c3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVh bCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNw O3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5 Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 001B7DD048257944_=-- From cyril.margaria@nsn.com Sun Nov 13 22:17:30 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BEE811E8095 for ; Sun, 13 Nov 2011 22:17:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.704 X-Spam-Level: X-Spam-Status: No, score=-4.704 tagged_above=-999 required=5 tests=[AWL=-1.106, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vR64D8QXf72N for ; Sun, 13 Nov 2011 22:17:29 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 67B1311E8094 for ; Sun, 13 Nov 2011 22:17:28 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pAE6HQql001349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Nov 2011 07:17:26 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pAE6HQdD009701; Mon, 14 Nov 2011 07:17:26 +0100 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Nov 2011 07:17:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCA295.146DA719" Date: Mon, 14 Nov 2011 07:17:26 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] [PCE] Request comments on draft-he-pce-pcep-associated-lsp-extensions-00 Thread-Index: AcyTB9421c9f5AC9SUCqSx7bnTQjWQPiNjTA References: From: "Margaria, Cyril (NSN - DE/Munich)" To: , X-OriginalArrivalTime: 14 Nov 2011 06:17:26.0692 (UTC) FILETIME=[14A27640:01CCA295] Subject: Re: [Pce] [PCE] Request comments on draft-he-pce-pcep-associated-lsp-extensions-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 06:17:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCA295.146DA719 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Wenjuan,=20 =20 I do think that if the concern is encoding efficiency one point would be = to state it in the objective in the document, but=20 I think that introducing new objects to optimize one type of request is = increasing the complexity of the protocol for a corner case. A more general optimization would be to bundle the common Request = parameters only once, then the requests, there is certainly several = possibility,=20 One that come to my mind (just for example) is to defined a new type = of endpoint, that would indicate that the objects in the requests are = applicable to the other requests (it could be all requests if no SVEC is = present, all request in the SVEC, ..etc) this would be more general, = apply to any future extension and solve the requirement. =20 For sharing within requests of the SVEC, the IRO cannot be used as-is, = because the node and links are not known in advance by the PCC, the = objective is to say : reuse the links you are calculating for the other = request, so a kind of IRO containing the other request id, but this need = more consideration.=20 =20 As pointed out for the stateful PCE, an association object could be = considered, it might also be possible to use this association and state = that resource reuse between LSP having the same association is desired. =20 =20 Best regards / Mit freundlichen Gr=FC=DFen Cyril Margaria =20 From: ext he.wenjuan1@zte.com.cn [mailto:he.wenjuan1@zte.com.cn]=20 Sent: Tuesday, October 25, 2011 7:12 PM To: Margaria, Cyril (NSN - DE/Munich); pce@ietf.org Subject: Re: [Pce] [PCE] Request comments on = draft-he-pce-pcep-associated-lsp-extensions-00 =20 Hi cyril,=20 Thanks for your comments, you catch the essence immediately. :-)=20 For the first comment,-Yeah, the SVEC object can be used to synchronize = the request about the forward and backward LSPs, and it is a more = general method.=20 As to the second comment, I also agree that GENERALIZED-BANDWIDTH with = forward and reverse bandwidth and the "B" bit set in the RP object can = be used since associated or co-routed is the same in the data plane.=20 But consider the usecase that only the forward and backward's bandwidths = is specified, and there is no need to limit them to be co-routed. I = think another bit "A" defined in the RP ojbect will be useful, for the = encoding efficiency will be higher than using the method based on the = "SVEC" object. What do you think?=20 The third comment,=20 -If we want to support the sharing of links,node, SRLG for synchronized = requests, this can be realized by two methods:=20 a)the IRO object can be used to carry the same link or node, but the = SRLG is not supported;=20 b)extend one tlv to specify the sharing link,node or SRLG in the SVEC = object.=20 Just my two comments, do you think there are requirements or usecases = about supporting the sharing SRLG?=20 Your comments on this are most welcome.=20 Thanks=20 Wenjuan=20 > Hi all, Hi,=20 > We've submitted a draft for the extensions of PCEP to support=20 > associated bidirectional lsp, below is the link:=20 > = http://tools.ietf.org/html/draft-he-pce-pcep-associated-lsp-extensions-00= . > The MPLS-TP requirements [RFC5654] and control plane framework = documents=20 > [RFC6373]describe that MPLS-TP MUST support associated bidirectional=20 > point-to-point LSPs. Path Computation Element (PCE), see [RFC4655],=20 > may be used for path computation of a GMPLS LSP,and consequently an=20 > associated bidirectional LSP, across domains and in a single domain. > As described in http://tools.ietf.org/html/ > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-02, the associated > bidirectional LSP can be deployed by Single Sided Provisioning model = or > Double Sided Provisioning model.For the double sided provisioning, the > path computation of the forward and the backward LSP are submitted by=20 > the head-end and the tail-end separately.For the single sided=20 > provisioning, the path computation can be realized by the concurrent = or=20 > successive computation. The concurrent computation means that the=20 > head-end submits the computation request for both two directional LSPs = > concurrently. As to the successive computation, the head-end and the=20 > tail-end send the forward LSP and backward LSP computation requests=20 > separately. > > We have extended PCEP protocol to support the Concurrent computation > for Single Sided Provisioning model. Concurrent computation can ensure > that the paths for the associated bidirectional LSP is optimal, as=20 > described in > http://tools.ietf.org/html/rfc5557. > In this draft, an A-bit is added to the flag bits of the RP object to > indicate the request is about an associated bidirectional LSP or not. > futhermore,REVERSE_LSP object is added in a PCReq message to specify = the > information of the reverse LSP. > > Please provide comments and feedback. Hi,=20 According to [RFC5654],=20 "Associated bidirectional path: A path that supports traffic flow in both directions but that is constructed from a pair of unidirectional paths (one for each direction) that are associated with one another at the path's ingress/egress points. The forward and backward directions are setup, monitored, and protected independently. As a consequence, they may or may not follow the same route (links and nodes) across the network." >From PCEP protocol point the Concurrent computation for Single Sided Provisioning model can be achieved with the following options:=20 - SVEC request containing one request for the forward direction and=20 one request for the reverse direction (forward and reverse path MAY be different)=20 - One bidirectional request using GENERALIZED-BANDWIDTH with forward=20 and reverse bandwidth if both direction must follow the same path=20 and have same other properties =20 This cover the requirements you are describing, I do not see the need = for PCEP extensions. One thing that could be considered (As far as I remember it was also = raised=20 for backup ingress and egress draft) is that the SVEC only allows to = compute diverse route but there is no indication that one desire sharing of = links, node (SRLGS?) for synchronized requests. BR=20 > > Thanks > Wenjuan=20 ------_=_NextPart_001_01CCA295.146DA719 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Wenjuan,

 

I do think that if the concern is encoding efficiency one = point would be to state it in the objective in the document, but =

=A0I think that introducing new objects to optimize one = type of request is increasing the complexity of the protocol for a corner = case.

=A0A more general optimization would be to bundle the = common Request parameters only once, then the requests, there is certainly = several possibility,

=A0 One that come to my mind =A0(just for example) is to = defined a new type of endpoint, that would indicate that the objects in the = requests are applicable to the other requests (it could be all requests if no SVEC is present, all request in the SVEC, ..etc) this would be more general, = apply to any future extension and solve the requirement.

 

For sharing within requests of the SVEC, the IRO cannot = be used as-is, because the node and links are not known in advance by the PCC, = the objective is to say : reuse the links you are calculating for the other request, so a kind of IRO containing the other request id, but this need = more consideration.

 

As pointed out for the stateful PCE, an association = object could be considered, it might also be possible to use this association and = state that resource reuse between LSP having the same association is = desired.

 

 <= /p>

Best regards / = Mit freundlichen Gr=FC=DFen

Cyril = Margaria

 

From:= ext he.wenjuan1@zte.com.cn [mailto:he.wenjuan1@zte.com.cn]
Sent: Tuesday, October 25, 2011 7:12 PM
To: Margaria, Cyril (NSN - DE/Munich); pce@ietf.org
Subject: Re: [Pce] [PCE] Request comments on draft-he-pce-pcep-associated-lsp-extensions-00

 


Hi = cyril,

Thanks = for your comments, you catch the essence immediately. :-)

For = the first comment,-Yeah, the SVEC object can be used to synchronize the request = about the forward and backward LSPs, and it is a more general method.

As to = the second comment, I also agree that GENERALIZED-BANDWIDTH with forward and reverse bandwidth and the "B" bit set in the = RP object can be used since associated or co-routed is the same in the data = plane.

But consider the usecase that only = the forward and backward's bandwidths is specified, and there is no need to = limit them to be co-routed. I think another bit "A" defined in the = RP ojbect will be useful, for the encoding efficiency will be higher than = using the method based on the "SVEC" object. What do you = think?

The = third comment,
-If we = want to support the sharing of links,node, SRLG for synchronized requests, this = can be realized by two methods:
  = a)the IRO object can be used to carry the same link or node, but the SRLG is = not supported;
  = b)extend one tlv to specify the sharing link,node or SRLG in the SVEC = object.
Just = my two comments, do you think there are requirements or usecases about = supporting the sharing SRLG?


Your = comments on this are most welcome.

Thanks

Wenjuan





> Hi all,

Hi,

> We've submitted a draft for the extensions of PCEP to support =
> associated bidirectional lsp, below is the link:
> http://tools.ietf.org/html/draft-he-pce-pcep-associated-lsp-extensions-00= .
> The MPLS-TP requirements [RFC5654] and control plane framework documents
> [RFC6373]describe that MPLS-TP MUST support associated = bidirectional
> point-to-point LSPs.  Path Computation Element (PCE), see [RFC4655],
> may be used for path computation of a GMPLS LSP,and = consequently an
> associated bidirectional LSP, across domains and in a single = domain.

> As described in http://tools.ietf.org/html/
> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-02, the = associated
> bidirectional LSP can be deployed by Single Sided Provisioning = model or
> Double Sided Provisioning model.For the double sided = provisioning, the
> path computation of the forward and the backward LSP are = submitted by
> the head-end and the tail-end separately.For the single sided =
> provisioning, the path computation can be realized by the = concurrent or
> successive computation. The concurrent computation means that = the
> head-end submits the computation request for both two = directional LSPs
> concurrently.  As to the successive computation, the = head-end and the
> tail-end send the forward LSP and backward LSP computation = requests
> separately.
>
> We have extended PCEP protocol to support the Concurrent = computation
> for Single Sided Provisioning model. Concurrent computation can = ensure
> that the paths for the associated bidirectional LSP is optimal, = as
> described in > http://tools.ietf.org/html/rfc5557.
> In this draft, an A-bit is added to the flag bits of the RP = object to
> indicate the request is about an associated bidirectional LSP = or not.
> futhermore,REVERSE_LSP object is added in a PCReq message to = specify the
> information of the reverse LSP.
>
> Please provide comments and feedback.
Hi,

According to [RFC5654],
"Associated bidirectional path: A path that supports traffic = flow in
both directions but that is constructed from a pair of = unidirectional
paths (one for each direction) that are associated with one = another
at the path's ingress/egress points.  The forward and = backward
directions are setup, monitored, and protected independently. =  As a
consequence, they may or may not follow the same route (links = and
nodes) across the network."

From PCEP protocol point the Concurrent computation for Single = Sided
Provisioning model can be achieved with the following options: =
 - SVEC request containing one request for the forward = direction and
   one request for the reverse direction (forward and = reverse path MAY
   be different)
 - One bidirectional request using GENERALIZED-BANDWIDTH with = forward
   and reverse bandwidth if both direction must follow the = same path
   and have same other properties
   
This cover the requirements you are describing, I do not see the = need for
PCEP extensions.

One thing that could be considered (As far as I remember it was also = raised
for backup ingress and egress draft) is that the SVEC only allows to compute
diverse route but there is no indication that one desire sharing of = links,
node (SRLGS?) for synchronized requests.

BR

>
> Thanks
> Wenjuan

------_=_NextPart_001_01CCA295.146DA719-- From ogondio@tid.es Mon Nov 14 22:39:43 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16EEC1F0DCD for ; Mon, 14 Nov 2011 22:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.527 X-Spam-Level: *** X-Spam-Status: No, score=3.527 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZzed+5xOVy8 for ; Mon, 14 Nov 2011 22:39:40 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 879571F0DCE for ; Mon, 14 Nov 2011 22:39:39 -0800 (PST) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUO00I07VU11T@tid.hi.inet> for pce@ietf.org; Tue, 15 Nov 2011 07:39:37 +0100 (MET) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 25.B9.03802.4B612CE4; Tue, 15 Nov 2011 08:37:24 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LUO00I03VU01T@tid.hi.inet> for pce@ietf.org; Tue, 15 Nov 2011 07:39:36 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad1.hi.inet ([192.168.0.1]) with mapi; Tue, 15 Nov 2011 07:39:37 +0100 Date: Tue, 15 Nov 2011 07:39:33 +0100 From: =?iso-8859-1?Q?Oscar_Gonz=E1lez_de_Dios?= To: "pce@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_IpW1jGW4RDHh3YFTC5rMgA)" Content-language: es-ES Accept-Language: es-ES, en-US Thread-topic: Comments on draft-crabbe-pce-stateful-pce-01.txt Thread-index: AcyjV0PLh0MaS3t/T5CLvA91YW6cyg== acceptlanguage: es-ES, en-US X-AuditID: 0a5f4068-b7ff26d000000eda-dc-4ec216b4949b X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNKsWRmVeSWpSXmKPExsXCFe/ApbtF7JCfwcW1uhZN92+wOzB6LFny kymAMYrLJiU1J7MstUjfLoErY+GefvaCl/EVix9vYG9gXB3cxcjJISFgIjHnxxQ2CFtM4sK9 9UA2F4eQwAZGiYebD7FCON8YJVb8msEO4TQySmz/9Z8ZpIVFQFXix7O5jCA2m4CDxLpFvWCj hAUsJSZv/wBmiwgoSny/sRrM5hXwlDg96RYThC0o8WPyPRYQm1kgV+LOrL/MELa4xJxfE1lB bEYBWYmV508DzecAmmMnceRsJsRIPYm7FyHKGQVkJP4v38sC8YGAxJI955khbFGJl4//sU5g FJ6FZNssJNtmIdkGYetJ3Jg6hQ3C1pZYtvA1VI2uxIx/h1iQxRcwsq9iFCtOKspMzyjJTczM STcw1MvI1MvMSy3ZxAiJl4wdjMt3qhxiFOBgVOLhbUg46CfEmlhWXJl7iFGSg0lJlHcB2yE/ Ib6k/JTKjMTijPii0pzU4kOMEhzMSiK8HSeBynlTEiurUovyYVIyHBxKEryfOYDaBItS01Mr 0jJzgEkBJs3EwQnSzgPUvgKkhre4IDG3ODMdIn+KUZtj3ZXm04wcrTfaTjMKseTl56VKifOu ASkVACnNKM2Dm/aKURzobGFeHZAsDzDFwc15BbSCCWjF2oMHQFaUJCKkpBoYzT+KpbGaPF4f 5P9/Vgj7JcHsd0s7BByfKOyp6PZK/7Xy48onb6ZPOL396dsZCnamG9zNHjql7Ly/IzFx9my5 +rffuU9zp8z+UX1G+rn8l+lH/fvcuF1nb5A/ce7ueyWN2oiSaSelr9z98pAj6XQYU+SkOx7B PIZ1zhlX1L5cMyk/e2VzyrUX55VYijMSDbWYi4oTAYnGDF4uAwAA Subject: [Pce] Comments on draft-crabbe-pce-stateful-pce-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 06:39:43 -0000 --Boundary_(ID_IpW1jGW4RDHh3YFTC5rMgA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Dear authors of draft-crabbe-pce-stateful-pce-01, please find bellow my com= ments and questions on the draft, First of all, thanks for the valuable work on the stateful PCE topic and ra= ising the discussions. Regarding delegation. What happens if the PCE-PCC connection is lost / clos= ed? Do we have to assume that delegation is only possible with persistent = connections? Do we assume that if connection is lost all delegations are re= voked? Also, regarding delegation, can you elaborate more on what can and what can= not be done in the PCE when a LSP is delegated? In the case or restoration, if the PCC had delegated the LSP, who is respon= sible for starting the re-routing? Will the PCE be aware of the failed elem= ent, and then proactively compute an alternative path, and proactively info= rm the PCC that it needs to update the path of the LSP? Regarding LSP information in the PCE, same issue . What happens if the PCE-= PCC connection is lost / closed? Is the LSP info deleted after some time o= f not receiving news? Section 7.2 LSP-ID is local to the PCE-PCC session. If you use multiple PCE= s, the LSP Object would only work in the correct PCE. Can the IDs overlap = between different PCE-PCC sessions? Or must they be different? Section 5.5.4 Redundant PCEs: You put the focus on the delegation. However,= in case of redundant PCE, I would rather imaging the second PCE having a r= eplica of the primary PCE. But, looking at the draft, it looks that in case= of changing PCE, the second one will have to learn everything regarding st= ate from scratch. That may imply that the second PCE will take some time t= o be fully operative... Thus, correct me if I am wrong, seems that the state has only sense in a gi= ven PCE-PCC session. True? Regarding the use cases, please considerer also another suggestion: LSP gro= ups. When a LSP is created, it is typically associated to a group of circui= ts with whom some specific common behavior is needed. One example is to mai= ntain a group of LSPs that you want to keep disjoint as much as possible. C= urrently, you can request a SVEC computation or add a list of exclusions, b= ut you need to include all the details from the PCC. Having the state of ea= ch LSP in the PCE would simply this kind of operation. Moreover, in any lat= er changes to the LSP, or in the event of restoration, if the group of LSPs= has suffered modifications, in the case of the stateful PCE, it is straigh= tforward to keep track of the changes. Otherwise, the PCC must keep track o= f them. Best Regards, =D3scar ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx --Boundary_(ID_IpW1jGW4RDHh3YFTC5rMgA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

Dear autho= rs of draft-crabbe-pce-stateful-pce-01, please find bellow my comments and = questions on the draft,

 = ;

First of a= ll, thanks for the valuable work on the stateful PCE topic and raising the = discussions.

 = ;

Regarding = delegation. What happens if the PCE-PCC connection is lost / closed?  = Do we have to assume that delegation is only possible with persistent connections? Do we assume that if connection is lost all delegations are r= evoked?

 = ;

Also, rega= rding delegation, can you elaborate more on what can and what cannot be don= e in the PCE when a LSP is delegated?

 = ;

In the cas= e or restoration, if the PCC had delegated the LSP, who is responsible for = starting the re-routing? Will the PCE be aware of the failed element, and then proactively compute an alternative path, and proactively= inform the PCC that it needs to update the path of the LSP?

 = ;

Regarding = LSP information in the PCE, same issue . What happens if the PCE-PCC connec= tion is lost / closed?  Is the LSP info deleted after some time of not receiving news?

 = ;

Section 7.= 2 LSP-ID is local to the PCE-PCC session. If you use multiple PCEs, the LSP= Object would only work in the correct PCE.  Can the IDs overlap between different PCE-PCC sessions? Or must they be different?<= /span>

 = ;

Section 5.= 5.4 Redundant PCEs: You put the focus on the delegation. However, in case o= f redundant PCE, I would rather imaging the second PCE having a replica of the primary PCE. But, looking at the draft, it looks that in = case of changing PCE, the second one will have to learn everything regardin= g state from scratch. That  may imply that the second PCE will take so= me time to be fully operative…

 = ;

Thus, corr= ect me if I am wrong, seems that the state has only sense in a given PCE-PC= C session. True?

 = ;

Regarding = the use cases, please considerer also another suggestion: LSP groups. When = a LSP is created, it is typically associated to a group of circuits with whom some specific common behavior is needed. One example is= to maintain a group of LSPs that you want to keep disjoint as much as poss= ible. Currently, you can request a SVEC computation or add a list of exclus= ions, but you need to include all the details from the PCC. Having the state of each LSP in the PCE would si= mply this kind of operation. Moreover, in any later changes to the LSP, or = in the event of restoration, if the group of LSPs has suffered modification= s, in the case of the stateful PCE, it is straightforward to keep track of the changes. Otherwise, the PCC mus= t keep track of them.

 = ;

 = ;

Best Regar= ds,

 = ;

 &nbs= p;  =D3scar


Este mensaje se dirige exclu= sivamente a su destinatario. Puede consultar nuestra pol=EDtica de env=EDo = y recepci=F3n de correo electr=F3nico en el enlace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
 --Boundary_(ID_IpW1jGW4RDHh3YFTC5rMgA)-- From jmedved@juniper.net Wed Nov 16 21:01:05 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A12611E80F8 for ; Wed, 16 Nov 2011 21:01:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.308 X-Spam-Level: X-Spam-Status: No, score=-4.308 tagged_above=-999 required=5 tests=[AWL=-1.975, BAYES_00=-2.599, FRT_BELOW2=2.154, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3ccoNjnQHFu for ; Wed, 16 Nov 2011 21:01:02 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id E4A6D11E80F6 for ; Wed, 16 Nov 2011 21:01:01 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTsSVCuuI8fjPXUwUaRCpGqaKKkTKSe9N@postini.com; Wed, 16 Nov 2011 21:01:01 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 16 Nov 2011 20:55:19 -0800 From: Jan Medved To: =?Windows-1252?Q?Oscar_Gonz=E1lez_de_Dios?= , "pce@ietf.org" Date: Wed, 16 Nov 2011 20:55:10 -0800 Thread-Topic: [Pce] Comments on draft-crabbe-pce-stateful-pce-01.txt Thread-Index: Acyk5RpQWRWQOASvQiO2J/PNnYbavQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Pce] Comments on draft-crabbe-pce-stateful-pce-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 05:01:05 -0000 Hi Oscar, Thanks a lot for the comments, please see inline. /Jan On 11/14/11 10:39 PM, "Oscar Gonz=E1lez de Dios" > wrote: Dear authors of draft-crabbe-pce-stateful-pce-01, please find bellow my com= ments and questions on the draft, First of all, thanks for the valuable work on the stateful PCE topic and ra= ising the discussions. Regarding delegation. What happens if the PCE-PCC connection is lost / clos= ed? Good point. If the PCC-PCE connection is lost or closed, delegation is auto= matically revoked. Do we have to assume that delegation is only possible with persistent conne= ctions? Correct. We stated in the draft the PCE-PCC connection must be persistent. Do we assume that if connection is lost all delegations are revoked? Yes. Also, regarding delegation, can you elaborate more on what can and what can= not be done in the PCE when a LSP is delegated? A PCE can basically ask the PCC to set up and LSP (with parameters provide= d on the Update request), or tear down an LSP. A PCE can not add or delete = an LSP =96 LSP addition/deletion is done locally at the PCC. In the case or restoration, if the PCC had delegated the LSP, who is respon= sible for starting the re-routing? The PCE. Will the PCE be aware of the failed element, and then proactively compute a= n alternative path, and proactively inform the PCC that it needs to update = the path of the LSP? Yes, the PCE will be aware of a failed LSP. The PCC must send a status upda= te whenever there is a state change on the LSP, such as an LSP goes down, a= protection event happens (a switchover to secondary or FRR), =85 Regarding LSP information in the PCE, same issue . What happens if the PCE-= PCC connection is lost / closed? Is the LSP info deleted after some time of not receiving news? Good points. Delegation is revoked immediately. What happens to an LSP is a matter of local PCC configuration: * The LSP may get delegated to a different PCE * The PCC may wait for a certain time and then tear the LSP down * The PCC may wait for a certain time and then turn the LSP to local CSP= F/autobandwidth control We do not want to specify the local PCC behavior in the protocol specificat= ion document. Section 7.2 LSP-ID is local to the PCE-PCC session. If you use multiple PCE= s, the LSP Object would only work in the correct PCE. Can the IDs overlap = between different PCE-PCC sessions? Or must they be different? Session-local ID's can overlap. We introduced a symbolic name for each LSP,= which must be unique, and it can be an ASCII name. Te symbolic name may al= so be persistent, i.e it may have to survive PCC restarts (a PCE needs an L= SP identifier for the entire lifetime of the LSP, which may span across PCC= restarts). It's too much overhead to carry an ASCII name on each LSP Repo= rt or Update, so we introduced the session-internal 32-bit ID. The first LS= P State Report from the PCC to the PCE will establish the relationship betw= een the LSP symbolic name and the session-internal LSP ID. Section 5.5.4 Redundant PCEs: You put the focus on the delegation. However,= in case of redundant PCE, I would rather imaging the second PCE having a r= eplica of the primary PCE. But, looking at the draft, it looks that in case= of changing PCE, the second one will have to learn everything regarding st= ate from scratch. That may imply that the second PCE will take some time t= o be fully operative=85 Primary and backup PCEs can certainly sync up between themselves. But we as= sume that LSP status reports go to both the primary and the backup during t= he PCC session. So there is no need to sync up the LSP state after a switch= over. After a switchover, the PCC only needs to delegate the LSPs to the ne= wly active PCE. Thus, correct me if I am wrong, seems that the state has only sense in a gi= ven PCE-PCC session. True? Not sure what you mean. A PCE may consider itself synced with a PCC only if= there is an active session between the PCE and the PCC. Regarding the use cases, please considerer also another suggestion: LSP gro= ups. When a LSP is created, it is typically associated to a group of circui= ts with whom some specific common behavior is needed. One example is to mai= ntain a group of LSPs that you want to keep disjoint as much as possible. C= urrently, you can request a SVEC computation or add a list of exclusions, b= ut you need to include all the details from the PCC. Having the state of ea= ch LSP in the PCE would simply this kind of operation. Moreover, in any lat= er changes to the LSP, or in the event of restoration, if the group of LSPs= has suffered modifications, in the case of the stateful PCE, it is straigh= tforward to keep track of the changes. Otherwise, the PCC must keep track o= f them. We thought about this, but we think the concept of groups can be contained = to the PCE. SVECs are required with a stateless PCE to keep it stateless wh= en a PCC needs orchestration among multiple LSPs. But with the active state= ful PCE, the PCE itelf is the orchestrator and it can groups LSPs whichever= way it wants. Best Regards, =D3scar ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx From edc@google.com Wed Nov 16 22:43:53 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD1511E80A0 for ; Wed, 16 Nov 2011 22:43:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.152 X-Spam-Level: X-Spam-Status: No, score=-101.152 tagged_above=-999 required=5 tests=[AWL=1.824, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1thDYAUTbXhQ for ; Wed, 16 Nov 2011 22:43:52 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id AD97E11E8083 for ; Wed, 16 Nov 2011 22:43:52 -0800 (PST) Received: by yenq4 with SMTP id q4so746694yen.31 for ; Wed, 16 Nov 2011 22:43:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record; bh=1CpusfhnlSD3mK+gevIDg1XXwb99ShJWNPBvkIrIo3w=; b=REQcR0CS9XSjZhcQpMQU60rPxaE4hZa8dKvOhtM8ilh72Yprze/SUcDQiPtcw0h+t6 KIBVidUEwUnPMLx6YoMA== Received: by 10.236.161.103 with SMTP id v67mr6807906yhk.87.1321512231254; Wed, 16 Nov 2011 22:43:51 -0800 (PST) Received: by 10.236.161.103 with SMTP id v67mr6807899yhk.87.1321512231115; Wed, 16 Nov 2011 22:43:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.230.1 with HTTP; Wed, 16 Nov 2011 22:43:31 -0800 (PST) From: Edward Crabbe Date: Thu, 17 Nov 2011 14:43:31 +0800 Message-ID: To: pce@ietf.org Content-Type: multipart/alternative; boundary=20cf3040ee1c1a1b2704b1e88be3 X-System-Of-Record: true Subject: [Pce] draft-crabbe-pce-stateful-pce-01 presentation X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 06:43:53 -0000 --20cf3040ee1c1a1b2704b1e88be3 Content-Type: text/plain; charset=ISO-8859-1 PCE-ers, An older version of our stateful PCE presentation was used in the PCE meeting today ( we were late in submitting our final deck update to Daniel, sorry :P.) The most recent version can be found here: http://goo.gl/NGVHV best, -ed --20cf3040ee1c1a1b2704b1e88be3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable PCE-ers,

An older version of our stateful PCE presentati= on was used in the PCE meeting today ( we were late in submitting our final= deck update to Daniel, sorry :P.)

The most recent= version can be found here: =A0


best,

=A0 -ed
--20cf3040ee1c1a1b2704b1e88be3-- From leonidas@netmode.ntua.gr Fri Nov 25 03:35:07 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830BC21F8C3F for ; Fri, 25 Nov 2011 03:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xu71Y0iTYVnY for ; Fri, 25 Nov 2011 03:35:07 -0800 (PST) Received: from diomedes.noc.ntua.gr (diomedes.noc.ntua.gr [IPv6:2001:648:2000:de::220]) by ietfa.amsl.com (Postfix) with ESMTP id A744721F8C2A for ; Fri, 25 Nov 2011 03:35:06 -0800 (PST) Received: from netmode.ece.ntua.gr ([IPv6:2001:648:2000:d:21d:9ff:fe05:33c7]) by diomedes.noc.ntua.gr (8.14.4/8.14.4) with ESMTP id pAPBZ4jg068461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 25 Nov 2011 13:35:04 +0200 (EET) (envelope-from leonidas@netmode.ntua.gr) Received: from dhcp-71.netmode.ece.ntua.gr (dhcp-71.netmode.ece.ntua.gr [147.102.13.71]) by netmode.ece.ntua.gr (8.14.4/8.14.3) with ESMTP id pAPBZ4r2041502; Fri, 25 Nov 2011 13:35:04 +0200 (EET) (envelope-from leonidas@netmode.ntua.gr) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes References: Date: Fri, 25 Nov 2011 13:34:04 +0200 To: pce@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Leonidas Lymberopoulos" Message-ID: In-Reply-To: User-Agent: Opera Mail/11.50 (Linux) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (diomedes.noc.ntua.gr [IPv6:2001:648:2000:de::220]); Fri, 25 Nov 2011 13:35:04 +0200 (EET) X-Virus-Scanned: clamav-milter 0.97 at diomedes.noc.ntua.gr X-Virus-Status: Clean Subject: [Pce] (CFP) IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 11:35:07 -0000 ----------------------------------------------------------------------------------------------------- Please accept our apologies if you receive multiple copies of this CfP ----------------------------------------------------------------------------------------------------- IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) ================================================================================== 16 April 2012 Maui, Hawaii, USA http://www.manfi.org CALL FOR PAPERS --------------- The Fourth IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) will be held in conjunction with IEEE/IFIP NOMS 2012 in Maui, Hawaii, USA, from April 16-20, 2012. The workshop is sponsored by the IEEE Communications Society (ComSoc) and supported by POSTECH ITCE, Ghent University-IBBT, NEC, and Ericsson LM. The workshop is endorsed by the Technical Committee on Network Operations and Management (CNOM). It is widely agreed that, despite its many successes, the current Internet also has a set of systemic problems, ranging from an upcoming shortage of IP addresses to insufficient security. However, the lack of scalable and agile manageability is arguably more important, as without management, it is impossible to build systems that adapt the services and resources offered in a context-dependent manner. In either case (clean slate vs. evolution vs. revolution) we must consider the manageability of the Future Internet from the beginning. Following the success of the three previous editions of this workshop, held in conjunction with IM 2009, NOMS 2010 and IM 2011, ManFI 2012 aims at providing an international forum for researchers in these and similar areas. ManFI 2012 will combine original full paper presentations with a motivating keynote, quick hot topic presentations and a panel discussion to thoroughly explore this challenging topic. Topics of interest ------------------ Authors are invited to submit papers that fall into or are related to the topic areas listed below: - Architectural Issues * Advantages and disadvantages of revolutionary, evolutionary, and other approaches to managing the Future Internet * Separation of data, control, and management planes * Design of architectural building blocks for managing the Future Internet * Advances in measurement, management, security, accounting, mobility, and other functions * Virtualization of resources and services * Dynamic composition of management and operational functionality * Mechanisms for managing interconnected computational infrastructures (e.g. elastic clouds, federated clouds) in the Future Internet * Implications of social network success on the Future Internet architecture - Design and Implementation Issues * Abstractions for programmable network elements * Accommodating context-awareness in management * Applying situation awareness to network management * Federation between administrative domains and support of all constituencies * The role of models, ontologies, and other knowledge abstractions in the Future Internet * Uncertainty and probabilistic approaches to management of the Future Internet * Approaches for the organization of management data, data analytics and visualization * Experience reports from Future Internet experimental facilities set-up and results - Economic Issues * Economic aspects driving the deployment of Future Internet management technology * Economic opportunities and challenges for management technology * Experience reports from management in test beds Paper submission ---------------- Paper submissions must present original, research or experiences. Late-breaking advances and work-in-progress reports from ongoing research are also encouraged. Only original papers that have not been published or submitted for publication elsewhere can be submitted. Each submission must be written in English, accompanied by a 75 to 200 word abstract that clearly outlines the scope and contributions of the paper, and a list of up to 5 key words. There is a length limitation of 6 pages (including title, abstract, all figures, tables, and references) for regular conference papers, and 4 pages for short papers. Submissions must be in IEEE 2-column style. Papers exceeding these limits, multiple submissions, and self-plagiarized papers will be rejected without further review. Authors should submit their papers in PDF, postscript, or Word formats via JEMS: (https://submissoes.sbc.org.br/). Proceedings ----------- Papers accepted for ManFI 2012 will be included in the conference proceedings, IEEE Xplore, and EI Index. The IEEE reserves the right to remove any paper from IEEE Xplore if the paper is not presented at the workshop. Awards will be presented to the best paper and to the best student paper at the workshop. Furthermore, we plan to work with a leading journal, such as JNSM, TNSM and IJNM, to solicit extended versions of the best papers of ManFI 2012 to be submitted for review. Workshop Co-Chairs ------------------ - Prof. James Won-Ki Hong, POSTECH, Korea - Prof. Filip De Turck, Ghent University - IBBT, Belgium - Dr. Yoshiaki Kiriha, NEC, Japan - Dr. Sven van der Meer, Ericsson LM, Ireland Publicity Co-Chairs ------------------- - Leonidas Lymberopoulos, National Technical University of Athens, Greece - Cathryn Peoples, University of Ulster, UK Important dates --------------- - Abstract registration deadline: December 14, 2011 - Paper submission: December 20, 2011 - Notification of acceptance: January 31, 2012 - Final version of papers due: February 15, 2012 - Workshop date: April 16, 2012 For more information, please contact one of the Workshop Co-Chairs at tpcchairs@manfi2012.org From daniel@olddog.co.uk Tue Nov 29 11:37:59 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661731F0C9E for ; Tue, 29 Nov 2011 11:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.298 X-Spam-Level: X-Spam-Status: No, score=-101.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9E2rI09bT7RE for ; Tue, 29 Nov 2011 11:37:58 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4521F0C8D for ; Tue, 29 Nov 2011 11:37:58 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id pATJbs0H000592; Tue, 29 Nov 2011 19:37:54 GMT Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id pATJbrl4000573; Tue, 29 Nov 2011 19:37:54 GMT From: "Daniel King" To: Date: Tue, 29 Nov 2011 19:37:51 -0000 Message-ID: <019701ccaece$62243da0$266cb8e0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0198_01CCAECE.6224D9E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcyuzhAnuvSEXwmURiWwUYUEwGPBsg== Content-Language: en-gb Cc: jpv@cisco.com Subject: [Pce] IETF 82 Minutes are Availible X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 19:37:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0198_01CCAECE.6224D9E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi All, Our IETF 82 PCE session minutes are online: http://www.ietf.org/proceedings/82/minutes/pce.htm If you have any corrections or updates please email them to me, and CC the chairs, by Friday, 9th December. Br, Dan. ------=_NextPart_000_0198_01CCAECE.6224D9E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All, =

 

Our IETF 82 PCE session minutes are =  online:

 

http://www.ie= tf.org/proceedings/82/minutes/pce.htm

 

If you have = any corrections or updates please email them to me, and CC the chairs, = by Friday, 9th December.

 

Br, Dan. =

 

 

 

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p; 

------=_NextPart_000_0198_01CCAECE.6224D9E0--