From nobody Mon Apr 1 00:34:34 2019 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 B48B9120073 for ; Mon, 1 Apr 2019 00:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9cX0YvjAfyB for ; Mon, 1 Apr 2019 00:34:30 -0700 (PDT) Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0759E120046 for ; Mon, 1 Apr 2019 00:34:29 -0700 (PDT) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id x317YROg016076 for ; Mon, 1 Apr 2019 08:34:27 +0100 Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B6A7422040 for ; Mon, 1 Apr 2019 08:34:27 +0100 (BST) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs1.iomartmail.com (Postfix) with ESMTPS id A12E22203C for ; Mon, 1 Apr 2019 08:34:27 +0100 (BST) Received: from LAPTOPK7AS653V ([147.83.201.128]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id x317YQsR007191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 1 Apr 2019 08:34:27 +0100 Reply-To: From: "Adrian Farrel" To: Date: Mon, 1 Apr 2019 08:34:26 +0100 Organization: Old Dog Consulting Message-ID: <00a101d4e85d$5604ba60$020e2f20$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdToXVRLoyfOlXZ6TDqnuH3mTuwpuA== Content-Language: en-gb X-Originating-IP: 147.83.201.128 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24524.005 X-TM-AS-Result: No--15.981-10.0-31-10 X-imss-scan-details: No--15.981-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24524.005 X-TMASE-Result: 10--15.980700-10.000000 X-TMASE-MatchedRID: sWvLI8uCRos/9d9Rtcc0Q6kVfngvx/3Fh8Ytn75ClDOxc8+mZZl8FX/2 0wqGUabS545k976poTn1ej67Eiww8c5/oVSv8cmRF6z9HGHKwNsHmzHO3TfA+Ba6DRt6Sf/fSd1 i2iwDAvglpVclvjJJDN7sUBFeE6Z/hdUss4Ved7P6YdEve7M6Ipl/lu28zzkBYN2xAZjUPjsyyr wwS5mwS7kQM6i/xWlxU4j6yvLF4rzvXvInwhwK28K1Ib9JAALxdZPoD9V2prSbKItl61J/ycnjL TA/UDoAMwyzN4BmnMl0HSe131POnuJGF26G8SWy5yM0c1ktj9M= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: [Pce] Reminder: Working Group last call on draft-ietf-pce-stateful-hpce-06 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 07:34:33 -0000 So far you have all been very quiet. Thanks, Adrian -----Original Message----- From: Pce On Behalf Of Adrian Farrel Sent: 13 March 2019 22:01 To: pce@ietf.org Subject: [Pce] Working Group last call on draft-ietf-pce-stateful-hpce-06 Hi working group, This email starts a working group last call for draft-ietf-pce-stateful-hpce-06. I would like to hear messages of support or concern about this draft. If you support its progression towards publication as an RFC, please let us know that you have read the latest revision, and explain why you think the work is important. Indications of implementation would also be welcome - although this document is informational, I believe some people may have built stateful hierarchical PCEs for experimentation or deployment. If you are opposed to the progression or have concerns please articulate them. As always, review comments and nits are most welcome. Because of the effort that is going in to preparing for IETF-104 and because of the time spent away, this last call will run for three weeks and end on April 4th. Thanks, Adrian _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From nobody Mon Apr 1 00:39:05 2019 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 CA70B120075 for ; Mon, 1 Apr 2019 00:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SY7KyDWTDddO for ; Mon, 1 Apr 2019 00:39:02 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 002F0120073 for ; Mon, 1 Apr 2019 00:39:01 -0700 (PDT) Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id B47033DDC175C8E25DE0 for ; Mon, 1 Apr 2019 08:38:59 +0100 (IST) Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 1 Apr 2019 08:38:59 +0100 Received: from DGGEML511-MBX.china.huawei.com ([169.254.1.130]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0415.000; Mon, 1 Apr 2019 15:38:55 +0800 From: "Zhenghaomian (Zhenghaomian, Optical Technology Research Dept)" To: "adrian@olddog.co.uk" , "pce@ietf.org" Thread-Topic: [Pce] Working Group last call on draft-ietf-pce-stateful-hpce-06 Thread-Index: AdTZ53y9WbWjgHFiTrWATWWbUpSffQOadjhg Date: Mon, 1 Apr 2019 07:38:55 +0000 Message-ID: References: <02a601d4d9e8$4def3770$e9cda650$@olddog.co.uk> In-Reply-To: <02a601d4d9e8$4def3770$e9cda650$@olddog.co.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.57.78.212] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Pce] =?gb2312?b?tPC4tDogIFdvcmtpbmcgR3JvdXAgbGFzdCBjYWxsIG9u?= =?gb2312?b?IGRyYWZ0LWlldGYtcGNlLXN0YXRlZnVsLWhwY2UtMDY=?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 07:39:05 -0000 SGksIFdHLCANCg0KSSBoYXZlIHJlYWQgdGhpcyBkb2N1bWVudCBhbmQgYmVsaWV2ZSB0aGlzIHdv cmsgaXMgdmVyeSB1c2VmdWwuIFN0YXRlZnVsIEgtUENFIHdpbGwgZW5hYmxlIGEgbW9yZSBlZmZp Y2llbnQgd2F5IHRvIGRvIHRoZSBjb21wdXRhdGlvbiB3aXRoIGEgZ3JvdXAgb2YgUENFcy4gVGhl IGRvY3VtZW50IGlzIGluIGEgZ29vZCBzaGFwZSBhcyB3ZWxsLiANCg0KSSBzdXBwb3J0IHRvIG1v dmUgZm9yd2FyZCBvbiB0aGlzIGRvY3VtZW50LCBzb21lIG1pbm9yIGNvbW1lbnRzIGFyZSBwcm92 aWRlZCB0byBiZSBmaXhlZCBhZnRlciB0aGUgTEM6IA0KLSBUaGUgcGFnZSBudW1iZXIgaW4gVG9D IGlzIG5vdCBjb25zaXN0ZW50LCBtYXliZSBhbiB1cGRhdGUgb24gd29yZCB3b3VsZCBiZSBuZWVk ZWQ7IA0KLSBQQ0VQIHN0YXRlZnVsIGV4dGVuc2lvbiBpbiBSRkM4MjMxLCBhbmQgUENFUCBpbml0 aWF0aW9uIGV4dGVuc2lvbiBpbiBSRkM4MjgxLCBhcmUgdXN1YWxseSBjb25zaWRlcmVkIGFzIHR3 byBzZXBhcmF0ZSB3b3Jrcy4gR2l2ZW4gdGhlIGZhY3Qgd2UgaGF2ZSBtZXJnZWQgdGhlIGdtcGxz IGV4dGVuc2lvbiB3aXRoIHR3byBmZWF0dXJlcywgaXQgaXMgcmVhc29uYWJsZSB0byBoYXZlIHRo ZXNlIHR3byBmZWF0dXJlcyBpbiB0aGUgaC1wY2Ugd29yayBhcyB3ZWxsLiBJIG5vdGljZWQgdGhl cmUgaXMgY29ycmVzcG9uZGluZyBkZXNjcmlwdGlvbnMgaW4gc2VjdGlvbiAzLjMsIGFuZCBJIHRo aW5rIGl0IHdvdWxkIGJlIHVzZWZ1bCBpZiBvbmUgc2VudGVuY2UgY2FuIGJlIHN1bW1hcml6ZWQg aW4gdGhlIGFic3RyYWN0LiANCg0KT0xEOiANCiAgIEEgU3RhdGVmdWwgUGF0aCBDb21wdXRhdGlv biBFbGVtZW50IChQQ0UpIG1haW50YWlucyBpbmZvcm1hdGlvbiBvbg0KICAgdGhlIGN1cnJlbnQg bmV0d29yayBzdGF0ZSwgaW5jbHVkaW5nOiBjb21wdXRlZCBMYWJlbCBTd2l0Y2hlZCBQYXRoDQog ICAoTFNQcyksIHJlc2VydmVkIHJlc291cmNlcyB3aXRoaW4gdGhlIG5ldHdvcmssIGFuZCBwZW5k aW5nIHBhdGgNCiAgIGNvbXB1dGF0aW9uIHJlcXVlc3RzLiBUaGlzIGluZm9ybWF0aW9uIG1heSB0 aGVuIGJlIGNvbnNpZGVyZWQgd2hlbg0KICAgY29tcHV0aW5nIG5ldyB0cmFmZmljIGVuZ2luZWVy ZWQgTFNQcywgYW5kIGZvciBhc3NvY2lhdGVkDQogICBhbmQgZGVwZW5kZW50IExTUHMsIHJlY2Vp dmVkIGZyb20gUGF0aCBDb21wdXRhdGlvbiBDbGllbnRzIChQQ0NzKS4NCk5FVzoNCiAgIEEgU3Rh dGVmdWwgUGF0aCBDb21wdXRhdGlvbiBFbGVtZW50IChQQ0UpIG1haW50YWlucyBpbmZvcm1hdGlv biBvbg0KICAgdGhlIGN1cnJlbnQgbmV0d29yayBzdGF0ZSwgaW5jbHVkaW5nOiBjb21wdXRlZCBM YWJlbCBTd2l0Y2hlZCBQYXRoDQogICAoTFNQcyksIHJlc2VydmVkIHJlc291cmNlcyB3aXRoaW4g dGhlIG5ldHdvcmssIGFuZCBwZW5kaW5nIHBhdGgNCiAgIGNvbXB1dGF0aW9uIHJlcXVlc3RzLiBU aGlzIGluZm9ybWF0aW9uIG1heSB0aGVuIGJlIGNvbnNpZGVyZWQgd2hlbg0KICAgY29tcHV0aW5n IG5ldyB0cmFmZmljIGVuZ2luZWVyZWQgTFNQcywgYW5kIGZvciBhc3NvY2lhdGVkDQogICBhbmQg ZGVwZW5kZW50IExTUHMsIHJlY2VpdmVkIGZyb20gUGF0aCBDb21wdXRhdGlvbiBDbGllbnRzIChQ Q0NzKS4gDQogICBJbml0aWFsaXplIHRoZSByZXN1bHQgb2YgcGF0aCBjb21wdXRhdGlvbiBmcm9t IFBDRSBpcyBhbHNvIGhlbHBmdWwgZm9yIA0KICAgdGhlIFBDQyB0byBncmFjZWZ1bGx5IGVzdGFi bGlzaCB0aGUgY29tcHV0ZWQgTFNQLiANCg0KLSBBcyBtZW50aW9uZWQgaW4gSUVURiAxMDQgUENF IFdHIHNlc3Npb24gKGRyYWZ0LWlldGYtcGNlLWVuaGFuY2VkLWVycm9ycyksIGVycm9yIGhhbmRs aW5nIGlzc3VlcyBuZWVkIHRvIGJlIG1lbnRpb25lZCBmb3IgaW50ZXItcGNlIHdvcmtzLCBhbmQg dGhpcyB3b3JrIGV4YWN0bHkgZml0cyBpbnRvIHRoZSBzY29wZS4gSXQgaXMgc3VnZ2VzdGVkIHRv IGFkZCBvbmUgc21hbGwgc2VjdGlvbiBhYm91dCB0aGlzLiBIb3cgYWJvdXQgdGhlIGZvbGxvd2lu Zz8gDQoNCjcuNy4gIEVycm9yIEhhbmRsaW5nIGJldHdlZW4gUENFcw0KRXJyb3IgdHlwZXMgc3Bl Y2lmaWVkIGluIFBDRVAgc2hvdWxkIGJlIHByb3Blcmx5IHByb3BhZ2F0ZSBiZXR3ZWVuIHBhcmVu dCBhbmQgY2hpbGQgUENFcy4gVGhlIHByb3BhZ2F0aW9uLCBub3RpZmljYXRpb24gYW5kIGNyaXRp Y2FsaXR5IGxldmVsIGRlZmluZWQgaW4gW0ktRC4gaWV0Zi1wY2UtZW5oYW5jZWQtZXJyb3JzXSBh cmUgcmVjb21tZW5kZWQuIA0KDQotIFRoZSBpZG5pdHMgcmVwb3J0IGFuIHVudXNlZCByZWZlcmVu Y2UgJ3BjZXAteWFuZycsIHByb2JhYmx5IGJlY2F1c2Ugb2YgdGhlIGxpbmUgaW4gc2VjdGlvbiA3 LjIgZm9yIGNpdGF0aW9uIGlzIG5vdCBwcm9wZXJseSBicm9rZW4gaW4gdGhlIG1pZGRsZS4gRWRp dGluZyB3aWxsIGJlIGhlbHBmdWwgdG8gZml4IGl0LiANCg0KV2UgYXJlIGxvb2tpbmcgZm9yd2Fy ZCB0byBzZWUgdGhlIGltcHJvdmVtZW50IGFmdGVyIHRoZSBXRyBMQywgdGhhbmsgeW91LiANCg0K QmVzdCB3aXNoZXMsDQpIYW9taWFuDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBQY2Ug W21haWx0bzpwY2UtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBBZHJpYW4gRmFycmVsDQq3osvNyrG8 5DogMjAxOcTqM9TCMTTI1SA2OjAxDQrK1bz+yMs6IHBjZUBpZXRmLm9yZw0K1vfM4jogW1BjZV0g V29ya2luZyBHcm91cCBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwtaHBjZS0w Ng0KDQpIaSB3b3JraW5nIGdyb3VwLA0KDQpUaGlzIGVtYWlsIHN0YXJ0cyBhIHdvcmtpbmcgZ3Jv dXAgbGFzdCBjYWxsIGZvciBkcmFmdC1pZXRmLXBjZS1zdGF0ZWZ1bC1ocGNlLTA2Lg0KDQpJIHdv dWxkIGxpa2UgdG8gaGVhciBtZXNzYWdlcyBvZiBzdXBwb3J0IG9yIGNvbmNlcm4gYWJvdXQgdGhp cyBkcmFmdC4NCg0KSWYgeW91IHN1cHBvcnQgaXRzIHByb2dyZXNzaW9uIHRvd2FyZHMgcHVibGlj YXRpb24gYXMgYW4gUkZDLCBwbGVhc2UgbGV0IHVzIGtub3cgdGhhdCB5b3UgaGF2ZSByZWFkIHRo ZSBsYXRlc3QgcmV2aXNpb24sIGFuZCBleHBsYWluIHdoeSB5b3UgdGhpbmsgdGhlIHdvcmsgaXMg aW1wb3J0YW50LiBJbmRpY2F0aW9ucyBvZiBpbXBsZW1lbnRhdGlvbiB3b3VsZCBhbHNvIGJlIHdl bGNvbWUgLSBhbHRob3VnaCB0aGlzIGRvY3VtZW50IGlzIGluZm9ybWF0aW9uYWwsIEkgYmVsaWV2 ZSBzb21lIHBlb3BsZSBtYXkgaGF2ZSBidWlsdCBzdGF0ZWZ1bCBoaWVyYXJjaGljYWwgUENFcyBm b3IgZXhwZXJpbWVudGF0aW9uIG9yIGRlcGxveW1lbnQuDQoNCklmIHlvdSBhcmUgb3Bwb3NlZCB0 byB0aGUgcHJvZ3Jlc3Npb24gb3IgaGF2ZSBjb25jZXJucyBwbGVhc2UgYXJ0aWN1bGF0ZSB0aGVt Lg0KDQpBcyBhbHdheXMsIHJldmlldyBjb21tZW50cyBhbmQgbml0cyBhcmUgbW9zdCB3ZWxjb21l Lg0KDQpCZWNhdXNlIG9mIHRoZSBlZmZvcnQgdGhhdCBpcyBnb2luZyBpbiB0byBwcmVwYXJpbmcg Zm9yIElFVEYtMTA0IGFuZCBiZWNhdXNlIG9mIHRoZSB0aW1lIHNwZW50IGF3YXksIHRoaXMgbGFz dCBjYWxsIHdpbGwgcnVuIGZvciB0aHJlZSB3ZWVrcyBhbmQgZW5kIG9uIEFwcmlsIDR0aC4NCg0K VGhhbmtzLA0KQWRyaWFuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpQY2UgbWFpbGluZyBsaXN0DQpQY2VAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNlDQo= From nobody Mon Apr 1 00:46:37 2019 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 890EB120091 for ; Mon, 1 Apr 2019 00:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0pOIJACR2Xk for ; Mon, 1 Apr 2019 00:46:30 -0700 (PDT) Received: from mx01.puc.rediris.es (outbound1mad.lav.puc.rediris.es [130.206.19.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B245120086 for ; Mon, 1 Apr 2019 00:46:30 -0700 (PDT) Received: from leo.cttc.es (leo.cttc.es [84.88.62.208]) by mx01.puc.rediris.es with ESMTP id x317kSS8027093-x317kSSA027093 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=CAFAIL) for ; Mon, 1 Apr 2019 09:46:28 +0200 Received: from [192.168.102.57] (unknown [192.168.102.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by leo.cttc.es (Postfix) with ESMTPSA id 0245E2014A for ; Mon, 1 Apr 2019 09:46:27 +0200 (CEST) To: pce@ietf.org References: <00a101d4e85d$5604ba60$020e2f20$@olddog.co.uk> From: Ramon Casellas Message-ID: <22dbb622-39e3-03bd-852f-f66d0880b1ad@cttc.es> Date: Mon, 1 Apr 2019 09:46:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <00a101d4e85d$5604ba60$020e2f20$@olddog.co.uk> Content-Type: multipart/alternative; boundary="------------F7446E80C1AE4E629AC627EE" Content-Language: en-US Archived-At: Subject: Re: [Pce] Reminder: Working Group last call on draft-ietf-pce-stateful-hpce-06 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 07:46:35 -0000 This is a multi-part message in MIME format. --------------F7446E80C1AE4E629AC627EE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi all Apologies for the delay in my response. I have read the draft, and I support its progression. In the framework of several research projects, we have been considering, implementing and testing stateful hierarchical PCE for optical networks and this draft describes the general considerations for the applicability of stateful HPCE in a multi-domain network. I also think it is a good companion document to the work on ACTN being done in the TEAS WG Best regards Ramon On 01/04/2019 9:34, Adrian Farrel wrote: > So far you have all been very quiet. > > Thanks, > Adrian > > -----Original Message----- > From: Pce On Behalf Of Adrian Farrel > Sent: 13 March 2019 22:01 > To: pce@ietf.org > Subject: [Pce] Working Group last call on draft-ietf-pce-stateful-hpce-06 > > Hi working group, > > This email starts a working group last call for > draft-ietf-pce-stateful-hpce-06. > > I would like to hear messages of support or concern about this draft. > > If you support its progression towards publication as an RFC, please let us > know that you have read the latest revision, and explain why you think the > work is important. Indications of implementation would also be welcome - > although this document is informational, I believe some people may have > built stateful hierarchical PCEs for experimentation or deployment. > > If you are opposed to the progression or have concerns please articulate > them. > > As always, review comments and nits are most welcome. > > Because of the effort that is going in to preparing for IETF-104 and because > of the time spent away, this last call will run for three weeks and end on > April 4th. > > Thanks, > Adrian > > _______________________________________________ > 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 -- Ramon Casellas, Ph.D. -- Senior Research Associate -- Networks Division Optical Networks and Systems Department -- http://networks.cttc.es/ons CTTC - Centre Tecnològic de Telecomunicacions de Catalunya Parc Mediterrani de la Tecnologia (PMT) - Edifici B4 Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain Tel.: +34 93 645 29 00 ext 2168-- Fax. +34 93 645 29 01 --------------F7446E80C1AE4E629AC627EE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi all

Apologies for the delay in my response.

I have read the draft, and I support its progression. In the framework of several research projects, we have been considering, implementing and testing stateful hierarchical PCE for optical networks and this draft describes the general considerations for the applicability of stateful HPCE in a multi-domain network.

I also think it is a good companion document to the work on ACTN being done in the TEAS WG

Best regards

Ramon


On 01/04/2019 9:34, Adrian Farrel wrote:
So far you have all been very quiet.

Thanks,
Adrian

-----Original Message-----
From: Pce <pce-bounces@ietf.org> On Behalf Of Adrian Farrel
Sent: 13 March 2019 22:01
To: pce@ietf.org
Subject: [Pce] Working Group last call on draft-ietf-pce-stateful-hpce-06

Hi working group,

This email starts a working group last call for
draft-ietf-pce-stateful-hpce-06.

I would like to hear messages of support or concern about this draft.

If you support its progression towards publication as an RFC, please let us
know that you have read the latest revision, and explain why you think the
work is important. Indications of implementation would also be welcome -
although this document is informational, I believe some people may have
built stateful hierarchical PCEs for experimentation or deployment.

If you are opposed to the progression or have concerns please articulate
them.

As always, review comments and nits are most welcome.

Because of the effort that is going in to preparing for IETF-104 and because
of the time spent away, this last call will run for three weeks and end on
April 4th.

Thanks,
Adrian

_______________________________________________
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

-- 
Ramon Casellas, Ph.D. -- Senior Research Associate -- Networks Division
Optical Networks and Systems Department -- http://networks.cttc.es/ons
CTTC - Centre Tecnològic de Telecomunicacions de Catalunya
Parc Mediterrani de la Tecnologia (PMT) - Edifici B4
Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain
Tel.: +34 93 645 29 00 ext 2168-- Fax. +34 93 645 29 01
--------------F7446E80C1AE4E629AC627EE-- From nobody Mon Apr 1 00:48:38 2019 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 8E82D12008B for ; Mon, 1 Apr 2019 00:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWReGTy_lnWY for ; Mon, 1 Apr 2019 00:48:33 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on0604.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0e::604]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0093120086 for ; Mon, 1 Apr 2019 00:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KbHMxvwFFb1io5R4I8iUpS89qRAuc/9qtPZqrkwquxo=; b=Iagnj4kB7mLw82Vvd0ojOq2AzGFHdGMQQmU0fhPMlDMOPBN/m8UaoDB2mVaMSJP5lzQpPozvP2yk8hb1GtH51Mr1Kwg9qaA7HSFEiAncFDE2sCEsa2c4DVB2oho9YkXnIKte5GVRtkXz6ArZL5aHkJqQ+9LZP7kV59chPjC8QIk= Received: from VI1PR07MB5040.eurprd07.prod.outlook.com (20.177.203.20) by VI1PR07MB3072.eurprd07.prod.outlook.com (10.175.242.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.6; Mon, 1 Apr 2019 07:48:30 +0000 Received: from VI1PR07MB5040.eurprd07.prod.outlook.com ([fe80::1152:d74:3cb2:5537]) by VI1PR07MB5040.eurprd07.prod.outlook.com ([fe80::1152:d74:3cb2:5537%2]) with mapi id 15.20.1771.011; Mon, 1 Apr 2019 07:48:30 +0000 From: Daniele Ceccarelli To: Ramon Casellas , "pce@ietf.org" Thread-Topic: [Pce] Reminder: Working Group last call on draft-ietf-pce-stateful-hpce-06 Thread-Index: AdToXVRLoyfOlXZ6TDqnuH3mTuwpuAAAa4UAAAAOuVA= Date: Mon, 1 Apr 2019 07:48:30 +0000 Message-ID: References: <00a101d4e85d$5604ba60$020e2f20$@olddog.co.uk> <22dbb622-39e3-03bd-852f-f66d0880b1ad@cttc.es> In-Reply-To: <22dbb622-39e3-03bd-852f-f66d0880b1ad@cttc.es> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [93.57.48.226] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a79f4f5c-75f0-4453-51c7-08d6b6766eff x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR07MB3072; x-ms-traffictypediagnostic: VI1PR07MB3072: x-microsoft-antispam-prvs: x-forefront-prvs: 0994F5E0C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(39860400002)(376002)(396003)(136003)(13464003)(189003)(199004)(12213003)(53754006)(7736002)(486006)(66574012)(2906002)(8676002)(6436002)(81156014)(99936001)(7696005)(81166006)(106356001)(110136005)(478600001)(229853002)(3846002)(236005)(9686003)(25786009)(105586002)(6116002)(446003)(53936002)(91966014)(53546011)(26005)(6506007)(8936002)(6246003)(44832011)(11346002)(99286004)(102836004)(54896002)(55016002)(33656002)(256004)(790700001)(186003)(14444005)(606006)(5660300002)(86362001)(97736004)(316002)(6306002)(68736007)(76176011)(66066001)(966005)(52536014)(476003)(6346003)(14454004)(2501003)(74316002)(71200400001)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3072; H:VI1PR07MB5040.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: vNIW4PBoXbcciPoVuxcEXyyox/PRtVtP9ALvUH8g4nSJdOzAwIaMV15+tN/qLxYVNNCtNedx4Uf1ll0o1NbXhxm5ig5Tnb9NDiAEMvPmXY9B1aHLi61kIZpJ13dU0sQx0ocNtBxlpRbO1+KenS8MCpl/2LPQ0JES/sc2Ow3+Ux/5BfYJB68NbeSh+Ixi7UE1uWDRtWjjcjBWBjLyM/38TnWzy+MlI4hsK3Sm7xig4QXttN4VChDxMUqF6qNVR7FgyHtli+9ZBbXfJB8/YI3PyZLCo57vrSx3T5q6ydl4dUOZ8+UWSPALPNjqvuD+sjavxFqE+aadjokR3vuLnwkiiLPXwBnyLEhxDY9AXOmeM5s5tmdVel4KP7PhSoIHJKm4GxFVKOdq1CFJgAR4Np4sBnObxbvvR0LZYn2bm2DNeFA= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0016_01D4E870.0C16A9A0" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: a79f4f5c-75f0-4453-51c7-08d6b6766eff X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2019 07:48:30.3075 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3072 Archived-At: Subject: Re: [Pce] Reminder: Working Group last call on draft-ietf-pce-stateful-hpce-06 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 07:48:37 -0000 ------=_NextPart_000_0016_01D4E870.0C16A9A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0017_01D4E870.0C16A9A0" ------=_NextPart_001_0017_01D4E870.0C16A9A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Same here...and I couldn=E2=80=99t explain it better than Ramon. =20 BR =20 Daniele =20 =20 From: Pce On Behalf Of Ramon Casellas Sent: den 1 april 2019 09:46 To: pce@ietf.org Subject: Re: [Pce] Reminder: Working Group last call on = draft-ietf-pce-stateful-hpce-06 =20 Hi all Apologies for the delay in my response.=20 I have read the draft, and I support its progression. In the framework = of several research projects, we have been considering, implementing and = testing stateful hierarchical PCE for optical networks and this draft = describes the general considerations for the applicability of stateful = HPCE in a multi-domain network.=20 I also think it is a good companion document to the work on ACTN being = done in the TEAS WG Best regards Ramon =20 On 01/04/2019 9:34, Adrian Farrel wrote: So far you have all been very quiet. =20 Thanks, Adrian =20 -----Original Message----- From: Pce On = Behalf Of Adrian Farrel Sent: 13 March 2019 22:01 To: pce@ietf.org =20 Subject: [Pce] Working Group last call on = draft-ietf-pce-stateful-hpce-06 =20 Hi working group, =20 This email starts a working group last call for draft-ietf-pce-stateful-hpce-06. =20 I would like to hear messages of support or concern about this draft. =20 If you support its progression towards publication as an RFC, please let = us know that you have read the latest revision, and explain why you think = the work is important. Indications of implementation would also be welcome - although this document is informational, I believe some people may have built stateful hierarchical PCEs for experimentation or deployment. =20 If you are opposed to the progression or have concerns please articulate them. =20 As always, review comments and nits are most welcome. =20 Because of the effort that is going in to preparing for IETF-104 and = because of the time spent away, this last call will run for three weeks and end = on April 4th. =20 Thanks, Adrian =20 _______________________________________________ Pce mailing list Pce@ietf.org =20 https://www.ietf.org/mailman/listinfo/pce =20 _______________________________________________ Pce mailing list Pce@ietf.org =20 https://www.ietf.org/mailman/listinfo/pce --=20 Ramon Casellas, Ph.D. -- Senior Research Associate -- Networks Division Optical Networks and Systems Department -- http://networks.cttc.es/ons CTTC - Centre Tecnol=C3=B2gic de Telecomunicacions de Catalunya Parc Mediterrani de la Tecnologia (PMT) - Edifici B4 Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain Tel.: +34 93 645 29 00 ext 2168-- Fax. +34 93 645 29 01 ------=_NextPart_001_0017_01D4E870.0C16A9A0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Same here...and I = couldn=E2=80=99t explain it better than Ramon.

 

BR

 

Daniele=C2=A0

 

From: Pce = <pce-bounces@ietf.org> On Behalf Of Ramon = Casellas
Sent: den 1 april 2019 09:46
To: = pce@ietf.org
Subject: Re: [Pce] Reminder: Working Group last = call on = draft-ietf-pce-stateful-hpce-06

 

Hi = all

Apologies for the delay in my response. =

I have read the draft, and I support its progression. = In the framework of several research projects, we have been considering, = implementing and testing stateful hierarchical PCE for optical networks = and this draft describes the general considerations for the = applicability of stateful HPCE in a multi-domain network. =

I also think it is a good companion document to the = work on ACTN being done in the TEAS WG

Best = regards

Ramon

 

On 01/04/2019 9:34, Adrian Farrel = wrote:

So far you have all =
been very =
quiet.
 
Thanks,
Adrian
 
-----=
Original Message-----
From: Pce <pce-bounces@ietf.org> On =
Behalf Of Adrian Farrel
Sent: 13 March 2019 =
22:01
To: pce@ietf.org
Subjec=
t: [Pce] Working Group last call on =
draft-ietf-pce-stateful-hpce-06
 
Hi working =
group,
 
This email =
starts a working group last call =
for
draft-ietf-pce-stateful-hpce-06.
 
I would like to hear messages of =
support or concern about this =
draft.
 
If you support =
its progression towards publication as an RFC, please let =
us
know that you have read the latest revision, and =
explain why you think the
work is important. =
Indications of implementation would also be welcome =
-
although this document is informational, I =
believe some people may have
built stateful =
hierarchical PCEs for experimentation or =
deployment.
 
If you are =
opposed to the progression or have concerns please =
articulate
them.
 
As always, review comments and nits are most =
welcome.
 
Because of the =
effort that is going in to preparing for IETF-104 and =
because
of the time spent away, this last call will =
run for three weeks and end on
April =
4th.
 
Thanks,<=
/pre>
Adrian
 
_______=
________________________________________
Pce =
mailing list
Pce@ietf.org
https://www.ietf.org/m=
ailman/listinfo/pce
 
=
_______________________________________________
Pce =
mailing list
Pce@ietf.org
https://www.ietf.org/m=
ailman/listinfo/pce
-- =

Ramon Casellas, Ph.D. -- Senior Research Associate =
-- Networks Division
Optical Networks and Systems =
Department -- http://networks.cttc.es/ons=

CTTC - Centre Tecnol=C3=B2gic de Telecomunicacions de =
Catalunya
Parc Mediterrani de la Tecnologia (PMT) - =
Edifici B4
Av. Carl Friedrich Gauss, 7 - 08860 =
Castelldefels (Barcelona) - Spain
Tel.: +34 93 645 =
29 00 ext 2168-- Fax. +34 93 645 29 =
01
------=_NextPart_001_0017_01D4E870.0C16A9A0-- ------=_NextPart_000_0016_01D4E870.0C16A9A0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVeTCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIGCjCCA/KgAwIBAgIQ PmzwpRtLuvapASEIDcQbUjANBgkqhkiG9w0BAQsFADBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMTIy MTMwMzAxWhcNMjAxMTIyMTMwMzAwWjByMREwDwYDVQQKDAhFcmljc3NvbjEbMBkGA1UEAwwSRGFu aWVsZSBDZWNjYXJlbGxpMS4wLAYJKoZIhvcNAQkBFh9kYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nz b24uY29tMRAwDgYDVQQFEwdxZGFuY2VjMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 0iZOZirmwPeV3dhVB/mEPJ1V1ihyztfLo3jkAt7NGg1SuJX1/mRcLbPsyl7gxTHAMXmaoIIHeOQQ hTcty19TnKIWO+5Vbt3tD0MdxCWiGR0FeHHyOZP97jqerlnCD2fuZny3/ne02QUy8VVFSReQitgp JRcbTWlo0zfAVRNPIuQtWUxAqznJqc3l5qXIHtP/eEv7mKaaXo00f7heN9wLHtRoX6oz/NFrWLjD V4aqciCdWAVoIpuKFsDm7skNVTmwYmdVdBCekeKmv3CJyb/g0qV3pMPH+mtBRV0EnH+6BpSIXwFH Qa/PsBn3YoUzc/yMJyUqbGY/aTT/ozrOvYAgTwIDAQABo4IBxTCCAcEwSAYDVR0fBEEwPzA9oDug OYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNy bDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEu Y29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29u bmxpbmRpdmlkdWFsY2F2My5jZXIwKgYDVR0RBCMwIYEfZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNz c29uLmNvbTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD BAYIKwYBBQUHAwIwHQYDVR0OBBYEFJ9SlCYOzjRVet6CA+roouqVzccUMB8GA1UdIwQYMBaAFBx7 GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEAyvE+ 6J+2LkiZ/ea8iQoubcyS/aKpuzcx/NxJPUvkJysvid/CPpvemTxZTXrEPGRX+4Qze0Jk4Fo2GUHD nnO1j+Gk7jmSXNS41HTIDgH3Hnc1cpSpNUxfWRqZvII2T6hh5COy3hY1qk1P9TnGsBmbW6WsZiR0 JWh2xgDKRXe91ciTaEZK2Nz5niQxJmQjN0i9q2eEQx9FXpXAHQua5SPrN6dTZpjaN5fR32VRpKYr Pom2jcPmGW4BDob7+tOcraqqpQULKRR8sE0V4vA/l3ZLkwypfA0Ase7dQI8gTHhyraQW3nigUjOH EFmUEVQfxdowx6hwxfGMuwi9Rakp67eW3WNOdvVjgt48kk4qk3I3iWmcVeUokYKUoDgeGsh0gIZE 2M+IbtZjCpIsiowKptMRI9q+Fnh8gAyo7+m8URaDq7aYzp5OmiPgb7whGYAdsbHJEFNkGLF+xyaE kmcRXdHyu9EAQZQmIRpTdPwCDsCXrzc5n4jLmMo2wa5CcXGcZTkg2xBh11YV3LDQK+BLGBD7JUFx 6wV47wO1AtRTV23cpuzK9hFgE560RSKI+cDLNcKW8NAc7tVKonz2dp5H82FO3oavo/HSKesqtQsx KVFpzq6s69I1+biH1iVWq+wmMfZhZT6Z044ErPFOTlMfedD2WKY/gUCvGROWVkvdOg7JPIowggbC MIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0 NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYD VQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8A MIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5v u5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ub ppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmbNJ7o 58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PVtO57 HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBsbpWI XwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUOxSqw 1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT9rOd gdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx5Yd1 c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0dHA6 Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9zaXRv cnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB /wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0 cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6g PIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYx LmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1Ud DgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gT EjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q 1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8O UWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw9 6AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0rI0Ro GzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+i5CC KEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GITb/i 7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5mdZ+R zPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeCaPKk veBJzqgb8ToH7WLoOzmPRCmPlpAxggMCMIIC/gIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQK DAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQPmzwpRtL uvapASEIDcQbUjAJBgUrDgMCGgUAoIIBfDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xOTA0MDEwNzQ4MjNaMCMGCSqGSIb3DQEJBDEWBBRJVMUQBUqEbuwYCfu1DX88 DLchtTBDBgkqhkiG9w0BCQ8xNjA0MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCGjBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQK DAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQPmzwpRtL uvapASEIDcQbUjBsBgsqhkiG9w0BCRACCzFdoFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhA+bPClG0u69qkB IQgNxBtSMA0GCSqGSIb3DQEBAQUABIIBAHqGVxEuFgGSx7kvaN+CV4YVUn4u4pXbhaktPzzt9KY2 Obn/hgN+qT90X6ETNyG7XS2gBW5P9pX5hScnq3WhYDivmb5s8XlLbsYCgPTH8yPx17uqG4t82gw2 IvAGrai9EH6glZqxZ+Zj96fcq+Ajikzsvs4tPYKf0yyd8UgydV/Z3blkMygI9oZOkZ8md5cG5bQG vmm2ZA6kwT99nTS33klDnW3zx7Hlgg73BP5SnQXxYbqEIciy/8aRlA0ZV3p97oUMe+lyuhsOs30L po50DmzpjsCotnSTW9qqgH2LHGlL6fXc7nRQ3KNR4UOstYP2T9FISs7PAmT13WqVpM7zJ7UAAAAA AAA= ------=_NextPart_000_0016_01D4E870.0C16A9A0-- From nobody Mon Apr 1 01:40:29 2019 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 14CE31200CE for ; Mon, 1 Apr 2019 01:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhKmyG0BCQ7T for ; Mon, 1 Apr 2019 01:40:25 -0700 (PDT) Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44BAD1200C3 for ; Mon, 1 Apr 2019 01:40:25 -0700 (PDT) Received: by mail-it1-x131.google.com with SMTP id n78so2957988itb.4 for ; Mon, 01 Apr 2019 01:40:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TTRgW6WrdHTzLV7mghp/O5zQa32vA+mhR16lwkkjZD4=; b=BKzX3Xu2rom/A5qVNYADJz7f267WSfA5a/DNGdLhsEhhyC3eajx/zKZFb7ryDDqgIp DYBr5f7xoteHMiI0IoaGZuTmbXq5I5wyvYt4+fim9pzMGpWqmPozOy8NUjiYJ92jpQdc 9ufQGZQlNR0B6Cfsht6FehIO6adOkjiLh4OFtGLCRiV/xtICZBiLLvWExaGIisixwdw0 79lk0+wOiKuEHuNcQhg1cBR6zm+g1tiiVqA/PcdvPkIwEJxQm4tu+hf4o6Npvj7skQTb Mzgc4VjV6DGbBXi6LCYfHbmAUIsX1aKnQahk1uaEQzwHO6zi21CLCwZTPCKPAdnZTrpf r5Fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TTRgW6WrdHTzLV7mghp/O5zQa32vA+mhR16lwkkjZD4=; b=nQFZTSk25QxCB3FvibvVtKGFpZ69kuhNIsaA2iVH0Gzf/Pgce2JSKBsERX2E94rBcE AfjuuJQ34H4nK2f/41Q4a8vJ5utDgAzdpDljKbdPYlsZ8oA7K5wZV2gwnGhbnuoKMAdv 32l3oZwyP6ibo8Xp21TfyUYmLfpLMyQJ7Qn9kJ5+HpxeKoqwHymsLSRniww8LjoAdNTl mMlZ4sUTyeQKmosgsdJwl6iN4/LlOulGFR48anvZgSbOhhJV6+oUWKs/rIZv41hLXZDi aeQDXPg+VEhjk64hjb4CS8R6CdEvjeE3SiGGC2CDn0u5oeqahUbN63oC0pO/uLB7SGZ6 LcVQ== X-Gm-Message-State: APjAAAXlQtRCgiH33Of53QDn6b1IXahaXvz9B9cYGLDO80GW4SKHM+E0 JCkHCJz/v3WX2FMG13jPCdKudhzLnnZfOOvibok= X-Google-Smtp-Source: APXvYqxk/C2PIbdzwh43goiNEJ0x7PU1mp/r5jIsVNJThPIcNSV3O9EERODUuXIH3AmWfoA1ORwaRJarI0tn428Bdq0= X-Received: by 2002:a02:938f:: with SMTP id z15mr7080497jah.108.1554108024519; Mon, 01 Apr 2019 01:40:24 -0700 (PDT) MIME-Version: 1.0 References: <02a601d4d9e8$4def3770$e9cda650$@olddog.co.uk> In-Reply-To: <02a601d4d9e8$4def3770$e9cda650$@olddog.co.uk> From: Satish K Date: Mon, 1 Apr 2019 14:10:13 +0530 Message-ID: To: adrian@olddog.co.uk Cc: pce@ietf.org Content-Type: multipart/alternative; boundary="000000000000be7f2c058573f8be" Archived-At: Subject: Re: [Pce] Working Group last call on draft-ietf-pce-stateful-hpce-06 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 08:40:27 -0000 --000000000000be7f2c058573f8be Content-Type: text/plain; charset="UTF-8" Hi WG, We have implemented H-PCE in our ACTN Solution and implemented few features of it in IETF-97 Hackathon. Also the E2E solution of ACTN using H-PCE is showcased during Bits-n-Bytes as well. So i am very much interested and looking forward to see this draft is getting published. Thanks & Regards, Satish Karunanithi On Thu, Mar 14, 2019 at 3:31 AM Adrian Farrel wrote: > Hi working group, > > This email starts a working group last call for > draft-ietf-pce-stateful-hpce-06. > > I would like to hear messages of support or concern about this draft. > > If you support its progression towards publication as an RFC, please let us > know that you have read the latest revision, and explain why you think the > work is important. Indications of implementation would also be welcome - > although this document is informational, I believe some people may have > built stateful hierarchical PCEs for experimentation or deployment. > > If you are opposed to the progression or have concerns please articulate > them. > > As always, review comments and nits are most welcome. > > Because of the effort that is going in to preparing for IETF-104 and > because > of the time spent away, this last call will run for three weeks and end on > April 4th. > > Thanks, > Adrian > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > --000000000000be7f2c058573f8be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi WG,

We have implemented H= -PCE in our ACTN Solution and implemented few features of it in IETF-97 Hac= kathon.
Also the E2E solution of ACTN using H-PCE is showcased du= ring Bits-n-Bytes as well.

So i am very much inter= ested and looking forward to see this draft is getting published.

Thanks & Regards,
Satish Karunanithi

On Thu, Mar 14, 2019 at 3:31 AM Adrian Farrel <adrian@olddog.co.uk> wrote:
Hi working group,

This email starts a working group last call for
draft-ietf-pce-stateful-hpce-06.

I would like to hear messages of support or concern about this draft.

If you support its progression towards publication as an RFC, please let us=
know that you have read the latest revision, and explain why you think the<= br> work is important. Indications of implementation would also be welcome - although this document is informational, I believe some people may have
built stateful hierarchical PCEs for experimentation or deployment.

If you are opposed to the progression or have concerns please articulate them.

As always, review comments and nits are most welcome.

Because of the effort that is going in to preparing for IETF-104 and becaus= e
of the time spent away, this last call will run for three weeks and end on<= br> April 4th.

Thanks,
Adrian

_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
--000000000000be7f2c058573f8be-- From nobody Mon Apr 1 02:43:26 2019 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 F07BB1200D7 for ; Mon, 1 Apr 2019 02:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yky_5byjnvBl for ; Mon, 1 Apr 2019 02:43:23 -0700 (PDT) Received: from mx01.puc.rediris.es (outbound1mad.lav.puc.rediris.es [130.206.19.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDADC1200CE for ; Mon, 1 Apr 2019 02:43:22 -0700 (PDT) Received: from leo.cttc.es (leo.cttc.es [84.88.62.208]) by mx01.puc.rediris.es with ESMTP id x319hJTQ026367-x319hJTS026367 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=CAFAIL) for ; Mon, 1 Apr 2019 11:43:19 +0200 Received: from [10.1.16.59] (pcrvilalta.cttc.es [10.1.16.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by leo.cttc.es (Postfix) with ESMTPSA id 1412F2014A for ; Mon, 1 Apr 2019 11:43:19 +0200 (CEST) To: pce@ietf.org References: <00a101d4e85d$5604ba60$020e2f20$@olddog.co.uk> From: Ricard Vilalta Message-ID: <27999814-413e-66aa-2917-aeb2ad8034fd@cttc.es> Date: Mon, 1 Apr 2019 11:43:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <00a101d4e85d$5604ba60$020e2f20$@olddog.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Pce] Reminder: Working Group last call on draft-ietf-pce-stateful-hpce-06 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 09:43:25 -0000 Hi Adrian, Sorry for being late. This draft has been useful when implementing ACTN framework in some demonstrations. I think that this draft should go to the next level. BR, Ricard On 01/04/2019 9:34, Adrian Farrel wrote: > So far you have all been very quiet. > > Thanks, > Adrian > > -----Original Message----- > From: Pce On Behalf Of Adrian Farrel > Sent: 13 March 2019 22:01 > To: pce@ietf.org > Subject: [Pce] Working Group last call on draft-ietf-pce-stateful-hpce-06 > > Hi working group, > > This email starts a working group last call for > draft-ietf-pce-stateful-hpce-06. > > I would like to hear messages of support or concern about this draft. > > If you support its progression towards publication as an RFC, please let us > know that you have read the latest revision, and explain why you think the > work is important. Indications of implementation would also be welcome - > although this document is informational, I believe some people may have > built stateful hierarchical PCEs for experimentation or deployment. > > If you are opposed to the progression or have concerns please articulate > them. > > As always, review comments and nits are most welcome. > > Because of the effort that is going in to preparing for IETF-104 and because > of the time spent away, this last call will run for three weeks and end on > April 4th. > > Thanks, > Adrian > > _______________________________________________ > 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 From nobody Mon Apr 1 05:53:54 2019 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 394F0120116 for ; Mon, 1 Apr 2019 05:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.291 X-Spam-Level: X-Spam-Status: No, score=-0.291 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 898Crtk0P6nD for ; Mon, 1 Apr 2019 05:53:51 -0700 (PDT) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDA4F12010E for ; Mon, 1 Apr 2019 05:53:50 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 44Xsj85w5kzCrYr; Mon, 1 Apr 2019 14:53:48 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.54]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 44Xsj853rKzDq8S; Mon, 1 Apr 2019 14:53:48 +0200 (CEST) Received: from OPEXCLILM32.corporate.adroot.infra.ftgroup (10.114.31.32) by OPEXCAUBM7D.corporate.adroot.infra.ftgroup (10.114.13.54) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 1 Apr 2019 14:53:48 +0200 Received: from [10.193.71.160] (10.168.234.2) by OPEXCLILM32.corporate.adroot.infra.ftgroup (10.114.31.32) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 1 Apr 2019 14:53:48 +0200 From: Organization: Orange To: "pce@ietf.org" Message-ID: <18687_1554123228_5CA209DC_18687_381_1_e8b79741-bd6b-8007-2c03-34fd9203a4d0@orange.com> Date: Mon, 1 Apr 2019 14:53:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [10.168.234.2] Archived-At: Subject: [Pce] New PCE Secretary X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 12:53:52 -0000 Dear PCE WG, With Dhruv becoming a co-chair of the WG, we had an empty secretary position. The call for volunteers was successful and we appreciate the interest expressed for the WG. Among these, the chairs have decided to appoint Hariharan Ananthakrishnan from Netflix as a secretary of the PCE WG. Those of you who were on Etherpad during the Prague session may have noticed he was already taking care of the minutes. Please welcome Hari to this position! Cheers, Adrian, Dhruv & Julien _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Mon Apr 1 09:39:50 2019 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 31ABA12042C for ; Mon, 1 Apr 2019 09:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpuHAzCRoy_F for ; Mon, 1 Apr 2019 09:39:44 -0700 (PDT) Received: from mail-it1-x12a.google.com (mail-it1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB7BE120421 for ; Mon, 1 Apr 2019 09:39:44 -0700 (PDT) Received: by mail-it1-x12a.google.com with SMTP id 139so78236ita.4 for ; Mon, 01 Apr 2019 09:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=r5zFCh3+2mGebZX0Mq9oOvuj3rPizYHzWa1ykUixRjY=; b=eojKKrjIgi2S5d5WJQ2go0yUPm5J6jjwnmWAnMEZyKYm/WsnnlggGFXnxzgLyZzNno NJpaY4KdLyMgtYFzOGWVxim3qBMhI8p/6wut21TGwwHDRo3K0syM7wIh88Hjhe8Q6tI9 embO+rU3+cbvtjo3s+HHTyz2a2dhYVt3+s8ZcFZsg0JKKPso19FCiqwILWFVn9y9f9gC v5SSFKLdqodBtLBG1+DZpxIyrDIGUSUoksJbQKt746Z59dfSKY3AEJDV1dENPdGoXOne NnFvqPwiJ56NfStYne2TMhOpBnrkkmxbKfh5OQeW7oN8K1kv7G0BzkGu0797fM/7U2t6 O2ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=r5zFCh3+2mGebZX0Mq9oOvuj3rPizYHzWa1ykUixRjY=; b=dBwpNPaTWsjesQ8RRQ7u0vmiiDFv8hZ+l4Tt2RrUDis/v/xJMmCEsKHJqrFDGHlDwK 4kHPjuDuhxRodmAb2toZRZxkLMUrDUx9Xzu8NFvQeu4Bq5jxc3edY/ddAPq2csIdFSoJ TpeXBdVCuLiabkZEzwiEdvcHYkGL0+BviNlqH7SDt1woiBbwhL0Tgl5IjDDaQs7PP6k3 nKDOqqfqF/m3FFCQOjEH+qOZnkz2d18aOzxMowTx57lpw63Fz2gpcbd03lPlt0Fw4V1V tDS88I5ky0aqQHG1nXMsvz3ZPS31GOgn58ksT+x0sYPJzdZDnBWRiQyfnI68Gef/PvWK fbyA== X-Gm-Message-State: APjAAAUqHgQQUjF8Q4AiR0Zm3JXmTzNLRv6uToNO6Z01SExUzJnNEbZa j+mXE4Qbq9U6EfdCyVrW4EXNGkZmYt5FjgBRVpoUhF41frg= X-Google-Smtp-Source: APXvYqx07ZmCuPwj/8fSa+3z89ZdeiuPVTC+kp8N9JxNaOVgDCeCMklKkZFe9GQvY+fj1dHFCf5cymq9+5BN2uVylD0= X-Received: by 2002:a24:8d03:: with SMTP id w3mr437731itd.103.1554136783574; Mon, 01 Apr 2019 09:39:43 -0700 (PDT) MIME-Version: 1.0 From: Dhruv Dhody Date: Mon, 1 Apr 2019 22:09:07 +0530 Message-ID: To: pce@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Pce] PCE WG Minutes X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 16:39:47 -0000 Hi WG, The PCE WG minutes are posted - https://datatracker.ietf.org/doc/minutes-104-pce/ Thanks Hari for taking the notes. If you have any corrections, please reach out to pce-chairs@ietf.org. Thanks! Dhruv From nobody Mon Apr 1 12:51:41 2019 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69DE81204CD; Mon, 1 Apr 2019 12:51:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: dhruv.ietf@gmail.com, db3546@att.com, Dhruv Dhody , draft-ietf-pce-hierarchy-extensions@ietf.org, pce@ietf.org, pce-chairs@ietf.org Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <155414829935.17044.4432455406015358101.idtracker@ietfa.amsl.com> Date: Mon, 01 Apr 2019 12:51:39 -0700 Archived-At: Subject: [Pce] Last Call: (Extensions to Path Computation Element Communication Protocol (PCEP) for Hierarchical Path Computation Elements (PCE)) to Proposed Standard X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 19:51:39 -0000 The IESG has received a request from the Path Computation Element WG (pce) to consider the following document: - 'Extensions to Path Computation Element Communication Protocol (PCEP) for Hierarchical Path Computation Elements (PCE)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-04-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Hierarchical Path Computation Element (H-PCE) architecture is defined in RFC 6805. It provides a mechanism to derive an optimum end-to-end path in a multi-domain environment by using a hierarchical relationship between domains to select the optimum sequence of domains and optimum paths across those domains. This document defines extensions to the Path Computation Element Protocol (PCEP) to support Hierarchical PCE procedures. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-pce-hierarchy-extensions/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-pce-hierarchy-extensions/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3422/ From nobody Mon Apr 1 13:01:10 2019 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 585BD1204D6; Mon, 1 Apr 2019 13:01:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Yingzhen Qu via Datatracker To: Cc: draft-ietf-pce-applicability-actn.all@ietf.org, pce@ietf.org, rtg-ads@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Yingzhen Qu Message-ID: <155414886827.17190.2656925435521918458@ietfa.amsl.com> Date: Mon, 01 Apr 2019 13:01:08 -0700 Archived-At: Subject: [Pce] Rtgdir last call review of draft-ietf-pce-applicability-actn-10 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 20:01:09 -0000 Reviewer: Yingzhen Qu Review result: Has Nits Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: https://datatracker.ietf.org/doc/draft-ietf-pce-applicability-actn/ Reviewer: Yingzhen Qu Review Date: 1 April 2019 IETF LC End Date: 23 February 2019 Intended Status: Informational Summary: An informational RFC is being requested by this document. This document examines the applicability of PCE to ACTN framework. Comments: This document is clearly written and easy to understand. I have only a few nitty comments that should be considered prior to publication.. Major Issues: No major issues found. Minor Issues: No minor issues found. Nits: 1. Page 7, section 3, why is NETCONF not included? 2. page 11. “need PCE as a important function.” Should be “need PCE as an important function.” 3. page 13. The paths from A to C, why is B31-B34 not there? 4. page 14. Section “VN Protection”, “need to applied to” should be “need to be applied to” 5. page 14. “In case PNC generates an abstract topology to the MDSC, the PCInitiate/PCUpd messages from the MDSC to a PNC will contain a path with abstract nodes and links.” Should it be “from the MDSC to a PNC” or “from the MDSC to the PNC”? Thanks, Yingzhen From nobody Tue Apr 2 05:17:59 2019 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 73FA4120187 for ; Tue, 2 Apr 2019 05:17:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155420747746.6349.15566757175689709871.idtracker@ietfa.amsl.com> Date: Tue, 02 Apr 2019 05:17:57 -0700 From: IETF Secretariat Archived-At: Subject: [Pce] Milestones changed for pce WG X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 12:17:58 -0000 Changed milestone "Submit inter-area/AS applicability statement to the IESG as an informational RFC", resolved as "Done", added draft-ietf-pce-inter-area-as-applicability to milestone. URL: https://datatracker.ietf.org/wg/pce/about/ From nobody Tue Apr 2 05:19:00 2019 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A948112018B for ; Tue, 2 Apr 2019 05:18:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155420753868.6242.12986457803562008836.idtracker@ietfa.amsl.com> Date: Tue, 02 Apr 2019 05:18:58 -0700 From: IETF Secretariat Archived-At: Subject: [Pce] Milestones changed for pce WG X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 12:18:59 -0000 Changed milestone "Submit extensions for hierarchical model to the IESG to be considered as a Proposed Standard", resolved as "Done", added draft-ietf-pce-hierarchy-extensions to milestone. URL: https://datatracker.ietf.org/wg/pce/about/ From nobody Thu Apr 4 09:14:48 2019 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2385812010D; Thu, 4 Apr 2019 09:14:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-pce-gmpls-pcep-extensions@ietf.org, Julien Meuric , pce-chairs@ietf.org, julien.meuric@orange.com, pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <155439447813.31004.11097266516711242039.idtracker@ietfa.amsl.com> Date: Thu, 04 Apr 2019 09:14:38 -0700 Archived-At: Subject: [Pce] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-pce-gmpls-pcep-extensions-13=3A_=28with_COMMENT=29?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 16:14:38 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-pce-gmpls-pcep-extensions-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-pcep-extensions/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Purely editorial comment: I would recommend to move most of the gap analysis of section 1 (actually most of the text of the whole section) into the appendix and only summarise the extensions specified in this doc instead. nit: sec 6: s/In order to protect against against the malicious PCE case/In order to protect against the malicious PCE case/ -> 2x against From nobody Thu Apr 4 09:44:19 2019 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DF41200C7; Thu, 4 Apr 2019 09:44:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-pce-stateful-pce-p2mp@ietf.org, Adrian Farrel , pce-chairs@ietf.org, adrian@olddog.co.uk, pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <155439625812.30874.11556397385069015051.idtracker@ietfa.amsl.com> Date: Thu, 04 Apr 2019 09:44:18 -0700 Archived-At: Subject: [Pce] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-pce-stateful-pce-p2mp-12=3A_=28with_COMMENT=29?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 16:44:18 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-pce-stateful-pce-p2mp-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-p2mp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Just a quick clarification question on fragmentation: I'm wondering if it is really necessary to define a fragmentation mechanism/bit for each object separately (e.g also RFC8306) or if it would be more appropriate to allocate one bit in the common header? Just asking as I'm really not an expert here... From nobody Thu Apr 4 11:08:26 2019 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 8ED1412011F; Thu, 4 Apr 2019 11:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxXz0MJvHr6e; Thu, 4 Apr 2019 11:08:15 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE345120110; Thu, 4 Apr 2019 11:08:12 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id d201so2794424iof.7; Thu, 04 Apr 2019 11:08:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5Glo7Sy/uAyZ2Uywt2uTiRHYSGuK+njdPdXPrX7bbgU=; b=OIKjghGS26IGqXF9+ou4tAnliEAGN24MAURWxkaBDTKctKCNxUs24dvDCMuiKWqvBl dIrHYvCU3t6TK+TrgV51pUezrTs1wSaI19gTGqy8ywb6NHe1xtC6ywwso6tq3iAqZQ5G 7FbyaiygVG58VUEq9CG7REB9eoYwkny0s3MCYaR5YLOz5M2L2tbIc47wwpwJ5ceEmPZE X7hljmO61+Lomy2EdIc8REcB/3UuJgtO68ZVf3SI+24abYs8mr1Z0imUig2EJ09TtMEK HS0jo8g6gMo8tOK9zhhmkkXePQTtvy0M/JjoJcnzZbS00GtMYK9Ethf2r83EeHY1V+zM ZBUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=5Glo7Sy/uAyZ2Uywt2uTiRHYSGuK+njdPdXPrX7bbgU=; b=m1Lh10BahkKr+ase4nZwdBn+xBwhKDZtfkv/zgiRXVRUOl32DuGjW+eISmDqwILuZk wsuEQccgAMxelEu4JX+CQyPYG4bm+TApi1B2AiaUptqm3+svTm4R68oJZ0KOv2DKSLJu AWGMiPnyehnQE0AYQ5W4zbAE755I3sN+cFStILZUWyERypPj0wVJ6fX9wiNIyWtRM2va CQTGTJA9dUVcEHXsoRb8uN6uyPkHJnZvOZdeffqxLRxjKBYl6vbfOaJ4ecb1ZbZb/NnP Sbq8wIqFUw/YVb/IdXIYaY/ARfVxiDBD9uKCGAFLaC4tF/WHE2q5IglmIL8RBgoGw666 n2rw== X-Gm-Message-State: APjAAAXMQgdxFwdnwPUEPePz9K4NRmfo5GcQQEvu6tsDRwy/HVoQSYDC T5YUzo2yKA6dJy83636EsFJjA10WPvbHCggw8aA= X-Google-Smtp-Source: APXvYqyCanIrr6ZkUSRhSOT/B0jMAu5a4Gwsu7bkq0ZBtJcF24hVtG0VD2oHEoHhJCI4LFeZq2KahZuG9Vn9VZMr2bI= X-Received: by 2002:a6b:fa0b:: with SMTP id p11mr2732849ioh.36.1554401291791; Thu, 04 Apr 2019 11:08:11 -0700 (PDT) MIME-Version: 1.0 References: <155439625812.30874.11556397385069015051.idtracker@ietfa.amsl.com> In-Reply-To: <155439625812.30874.11556397385069015051.idtracker@ietfa.amsl.com> From: Dhruv Dhody Date: Thu, 4 Apr 2019 23:37:35 +0530 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: The IESG , draft-ietf-pce-stateful-pce-p2mp@ietf.org, Adrian Farrel , pce-chairs@ietf.org, pce@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Pce] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-pce-stateful-pce-p2mp-12=3A_=28with_COMMENT=29?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 18:08:18 -0000 Hi Mirja, On Thu, Apr 4, 2019 at 10:14 PM Mirja K=C3=BChlewind via Datatracker wrote: > > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-pce-stateful-pce-p2mp-12: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-p2mp/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Just a quick clarification question on fragmentation: I'm wondering if it= is > really necessary to define a fragmentation mechanism/bit for each object > separately (e.g also RFC8306) or if it would be more appropriate to alloc= ate > one bit in the common header? Just asking as I'm really not an expert her= e... > > The need for fragmentation was found when the support for P2MP TE was introduced in RFC6006. At that time only two PCEP message were susceptible to fragmentation (PCReq & PCRep) and the choice was made to add a flag in a RP object. The choice made at that time was that the other messages should not be fragmented. Later PCEP added more messages to support stateful operation. And with this I-D we extend support to P2MP LSP where fragmentation handling was required (we added the flag in the LSP object). You are correct! We could have used the PCEP common message header and said that the flag is applicable for the subset of messages. But the design choice here was to keep consistent with technique already in place. Fragmentation flag in 2 objects isn't all that bad. Thanks for your review! Dhruv From nobody Fri Apr 5 12:55:41 2019 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 19407120605; Fri, 5 Apr 2019 12:55:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: pce@ietf.org Message-ID: <155449414001.10103.16997405095154068267@ietfa.amsl.com> Date: Fri, 05 Apr 2019 12:55:40 -0700 Archived-At: Subject: [Pce] I-D Action: draft-ietf-pce-gmpls-pcep-extensions-14.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 19:55:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : PCEP extensions for GMPLS Authors : Cyril Margaria Oscar Gonzalez de Dios Fatai Zhang Filename : draft-ietf-pce-gmpls-pcep-extensions-14.txt Pages : 40 Date : 2019-04-05 Abstract: The Path Computation Element (PCE) provides path computation functions for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Additional requirements for GMPLS are identified in RFC7025. This memo provides extensions to the Path Computation Element communication Protocol (PCEP) for the support of the GMPLS control plane to address those requirements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-pcep-extensions/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-gmpls-pcep-extensions-14 https://datatracker.ietf.org/doc/html/draft-ietf-pce-gmpls-pcep-extensions-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-gmpls-pcep-extensions-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 5 12:59:18 2019 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 1EEFA1205FB for ; Fri, 5 Apr 2019 12:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.337 X-Spam-Level: X-Spam-Status: No, score=-1.337 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVgTSmdSMwkI for ; Fri, 5 Apr 2019 12:59:13 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25CC4120617 for ; Fri, 5 Apr 2019 12:59:07 -0700 (PDT) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x35JrhUt013651 for ; Fri, 5 Apr 2019 12:59:05 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=HuNRhpVMds1D62ZD/HI5W9wyKUeKc0otehHJmvvZXyg=; b=QFqaITCGUoUlB+VJwGQt7NYuf/1f916jAfy8Hc3bv1nHsJCO98G0vyfw7ULJAM6kweLo 0shoCvRODcKVpRwTZfhpWPwSk2ZqbNsJ5XLrcTWo3vx9oMasR4ixro09akZ7np+C5+31 2l+7ZhM8Pqo4oAy5XDJ9TTbUzJU38Kaffizi7yS17YPoaojSGSEadGVe46mNnLgEP+dm xk1ZurrfIPhLExi9fHRz0ZGuJSO7HHL0hvKSmTVC5xP2i0gbN6rassKV+X2lQZ5YCzsb LygBc3KBGCeohCxGJRYqvq9yp4Nnc2h6lggTc8W0XB3YXuuCjvqikA5blkDHhRck1tCn mA== Received: from nam01-by2-obe.outbound.protection.outlook.com (mail-by2nam01lp2053.outbound.protection.outlook.com [104.47.34.53]) by mx0b-00273201.pphosted.com with ESMTP id 2rpa140cwf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Fri, 05 Apr 2019 12:59:05 -0700 Received: from CY4PR0501MB3698.namprd05.prod.outlook.com (52.132.97.154) by CY4PR0501MB3858.namprd05.prod.outlook.com (52.132.100.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.7; Fri, 5 Apr 2019 19:59:03 +0000 Received: from CY4PR0501MB3698.namprd05.prod.outlook.com ([fe80::35d3:730c:34b0:bf29]) by CY4PR0501MB3698.namprd05.prod.outlook.com ([fe80::35d3:730c:34b0:bf29%4]) with mapi id 15.20.1771.011; Fri, 5 Apr 2019 19:59:02 +0000 From: Cyril Margaria To: "pce@ietf.org" Thread-Topic: Updates on draft-ietf-pce-gmpls-pcep-extensions-14.txt Thread-Index: AQHU6+miABgRsLwfAEqwa1BCd9KUkQ== Date: Fri, 5 Apr 2019 19:59:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.13] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b343d1f2-57d4-41bf-decd-08d6ba0126e5 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:CY4PR0501MB3858; x-ms-traffictypediagnostic: CY4PR0501MB3858: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0998671D02 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(396003)(376002)(366004)(346002)(199004)(189003)(7696005)(8676002)(2501003)(2906002)(55016002)(3846002)(68736007)(6916009)(105586002)(486006)(6116002)(99286004)(5660300002)(236005)(106356001)(52536014)(476003)(9686003)(71190400001)(478600001)(54896002)(26005)(86362001)(558084003)(6306002)(66066001)(71200400001)(966005)(606006)(14454004)(413944005)(97736004)(256004)(25786009)(6436002)(5640700003)(102836004)(81166006)(316002)(8936002)(186003)(53936002)(7736002)(74316002)(105004)(1730700003)(33656002)(81156014)(6506007)(2351001)(19627405001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR0501MB3858; H:CY4PR0501MB3698.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: WsEJjlbCA6v638ZNFtWineyNVGhukJzuU4c1mEwn2zg8ruBeSta8BWnaqIW/s3xQosNKQIk+uINvQ5n4HPAqGSjV/xjFEtuTH5G0WZtIKZhIBPSJ0IOdVs7ZfuIZMQZa9RqVNaOjdqDSvlSwgH6MgP60gN61Se1ZM8Og+4Br8N5b9iGlAQTjzkKn/jLt5rxck4VKCrUHiqJ/dj4PP1sEbhmNQfyQgdnMQElGzv/7u4xeE2AkROku+jf/9yIaEx+WCaw0dzUt6ujcv0/hyGRgrGa7dT1POTcDpIzOjT+5oEhI30ZRgr3F8VF2Lz4bZcGec9OhaI8sxxS+NzWDvru2igIdhhTukn71pubX8e4FSIbYNt/rYJ3YtP2R2HyPRWibhQjx9GiCAF86Rn6852N8fSow0tXDYm61WfLAmjDq7+o= Content-Type: multipart/alternative; boundary="_000_CY4PR0501MB36984175056BBBA4A2A80E04B5510CY4PR0501MB3698_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: b343d1f2-57d4-41bf-decd-08d6ba0126e5 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2019 19:59:02.8167 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0501MB3858 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-05_15:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=759 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904050133 Archived-At: Subject: [Pce] Updates on draft-ietf-pce-gmpls-pcep-extensions-14.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 19:59:15 -0000 --_000_CY4PR0501MB36984175056BBBA4A2A80E04B5510CY4PR0501MB3698_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear PCEers, A new version of the drat has been posted, it contains a few edits noted by= our new chair (Dhruv). Those edits are made to align with issues raied by = IESG during the review of https://tools.ietf.org/html/draft-ietf-pce-wson-r= wa-ext-17. Thanks, Cyril --_000_CY4PR0501MB36984175056BBBA4A2A80E04B5510CY4PR0501MB3698_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear PCEers,


A new version of the drat has been posted, it contains a few edits noted by= our new chair (Dhruv). Those edits are made to align with issues raied by = IESG during the review of https://tools.ietf.org/html/draft-ietf-pce-wson-= rwa-ext-17.


Thanks,
Cyril
--_000_CY4PR0501MB36984175056BBBA4A2A80E04B5510CY4PR0501MB3698_-- From nobody Fri Apr 5 17:55:40 2019 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 F0777120278 for ; Fri, 5 Apr 2019 17:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=venaas-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koc7Wp6mhlSz for ; Fri, 5 Apr 2019 17:55:29 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A290212028B for ; Fri, 5 Apr 2019 17:55:29 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id s16so6995309edr.3 for ; Fri, 05 Apr 2019 17:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venaas-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=tFSm0FUMEYwyLlg1gh91Y4H9f2ThuPX7jazd6FamHpM=; b=tP7e+u/2av9VNmsbNmHM/9Xcc8LczB5HBaC6A/ipYwMmeRM0JUW5zj1VuP5wX1pVdT 6GRr/OZe/S8v0wWtxo+Q6N5c0UBorsOuitOZqyDL3DyIZK6ZXBRZt/6UH3iDbD2+RZVW MimnHg9pGRFCuGwaeUfKWUT3mE6PowQRlmMtf30fgil7/3TNR0aXQbFiNpyHn2yM6mxe auqDtyJNljbZN1k7HYEmzWN+h3uDsuLo1WoPJE4uHihnS31sv/Hq01IGp64w5uA3bzvr 8G4BCPUX+nceMhOCQETG6Eozcy/76VXZOLT+qHjyKVLDD3jPOSoXcp4UN3PqlIR5M7ip 2YWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=tFSm0FUMEYwyLlg1gh91Y4H9f2ThuPX7jazd6FamHpM=; b=XzAgqdvXjdUC4tWZoXFviiEDGHzR6PZghcHh5R8h4KvLLr/J12uMScNgZXtFMcq2dt fplJrLTAPdOha1BKKdYtQV9VmtkZlwCSrz4uaRzI5SPgGFRTZfiEkiy7YnlPTf04a/hO S/p6j0pvEagZYts0ryYIUs4tsi78AemBSM2QrCd9sJh12bNJklTFMyHj597H7LUCDlPR lzHVhDuO+sSCJ7JjShP/9ctPpBQTh8ZooDAXhqrP9S9igOAAiMYpqJ6SxNfDFnPt1/AP czS/cZ3pg7qUMbaAb/I5LK7WaY0DiBw8ma2Fc4x0mDiB7nhTmnvSyDCg68KggJMbtQSw KDwA== X-Gm-Message-State: APjAAAXAR8MGJU3UmcZah4JCym/5D5cPTTCcs83PcqdL458OVHUf1xEi 2XumkZP2DYT/dG5xllZJUlER9F++rocEyJ6HjNIM1w== X-Google-Smtp-Source: APXvYqywKQEqzKDdCoA40Ksiq8GBxmf14JndhgsxM0Dd1+qrYYBvmI/d9Vtg7QlkON9s+Lrg5vjh7dqI7AWagQIAs2g= X-Received: by 2002:a17:906:6c0d:: with SMTP id j13mr8989688ejr.249.1554512128089; Fri, 05 Apr 2019 17:55:28 -0700 (PDT) MIME-Version: 1.0 From: Stig Venaas Date: Fri, 5 Apr 2019 17:55:17 -0700 Message-ID: To: "" Cc: rtg-dir@ietf.org, draft-ietf-pce-association-group.all@ietf.org, pce@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Pce] RtgDir review: draft-ietf-pce-association-group-08 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 00:55:33 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-pce-association-group-08.txt Reviewer: Stig Venaas Review Date: April 5th 2019 IETF LC End Date: April 5th 2019 Intended Status: Standards Track Summary: This document is basically ready for publication, but has nits that should be considered prior to publication. Comments: The document is in good shape and fairly easy to read. There are some grammar errors and some language that could be improved somewhat. I'm sure the RFC editor will help with that, but I've added some comments below. Major Issues: No major issues found. Minor Issues: No minor issues found. Nits: In Introduction first paragraph Typo: Generalzied In section 3.2: can either be dependent or independent. The SVEC object identify the Should be identifies ^^^^^^^^ The motivation behind the association group defined in this document and the SVEC object are quite different, though some use case may overlap. The PCEP extensions that defines new association type should clarify the relationship between SVEC object and association type, if any. A few issues here. Perhaps it should be The motivation behind the association group defined in this document and the SVEC object are quite different, though some use cases may overlap. PCEP extensions that define a new association type should clarify the relationship between the SVEC object and the association type, if any. In section 3.3: For the operator-configured association, the association parameters such as the association identifier, association type, as well as the association source IP address is manually configured by the operator. The last line should perhaps be association source IP address, are manually configured by the operator. Right below: This line the association identifier is allocated dynamically by the PCEP should perhaps be the association identifier, are allocated dynamically by the PCEP Also, right below: operator-configured association are known to the PCEP peer before Should be "is known". In this paragraph: The associations are properties of the LSP and thus could be stored in the LSP state database. The dynamic association exist as long as the LSP state. In case of PCEP session termination, the LSP state clean-up MUST also take care of associations. the sentence "The dynamic association exist as long as the LSP state." should perhaps be "The dynamic association exists as long as the LSP state exists"? In 3.4: A range of association identifier for each Association type identifiers ^^^^^ In 6.1: association type are defined in separate documents. ^^^^^^^^^ In 6.3.1: ::= [] Should there be a space here? ^^^^^ In 6.3.2: ::= [] Space here? ^^^^^ In 6.3.3 ::=[] Space here? ^^^^^ In 6.4: attached to LSP state and the association exist till there is an exists ^^^^^^^ in [RFC5440]. If a PCEP speaker understand the ASSOCIATION object understands ^^^^^^^^^^^ a new associations, it MUST return a PCErr message with Error-Type 26 ^^^^^^^^^^^ In 7.2: 31 (Early Extended Association Id [This.I-D] I think it should say ID ^^^^ If you agree, then this should also be fixed in the IANA registry. It currently says Id. In 7.4: There are no association type specified in this document, future types ^^^^^^ Regards, Stig From nobody Sat Apr 6 05:31:19 2019 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E94DB12001A; Sat, 6 Apr 2019 05:31:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: pce@ietf.org Message-ID: <155455387787.21940.2991067095789706757@ietfa.amsl.com> Date: Sat, 06 Apr 2019 05:31:17 -0700 Archived-At: Subject: [Pce] I-D Action: draft-ietf-pce-association-group-09.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 12:31:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : PCEP Extensions for Establishing Relationships Between Sets of LSPs Authors : Ina Minei Edward Crabbe Siva Sivabalan Hariharan Ananthakrishnan Dhruv Dhody Yosuke Tanaka Filename : draft-ietf-pce-association-group-09.txt Pages : 29 Date : 2019-04-06 Abstract: This document introduces a generic mechanism to create a grouping of Label Switched Paths (LSPs) in the context of a Path Computation Element (PCE). This grouping can then be used to define associations between sets of LSPs or between a set of LSPs and a set of attributes (such as configuration parameters or behaviors), and is equally applicable to the stateful PCE (active and passive modes) as well as the stateless PCE. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-association-group/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-association-group-09 https://datatracker.ietf.org/doc/html/draft-ietf-pce-association-group-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-association-group-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Apr 6 05:34:10 2019 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 04ED7120049; Sat, 6 Apr 2019 05:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-EofQ9Yyuwf; Sat, 6 Apr 2019 05:33:59 -0700 (PDT) Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4173012001A; Sat, 6 Apr 2019 05:33:59 -0700 (PDT) Received: by mail-it1-x136.google.com with SMTP id k64so13905983itb.5; Sat, 06 Apr 2019 05:33:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=v6xP8xj4Ek9na4aaXguRURwXd0/T9XAg2F5D3j3SWP4=; b=JnIiRg7GZW7PtVHYpymUyxU/noLRf9ZfXGHZSbwYjNgTVK0euSLta5r5FRmIdqRAcd 3YJdcmtmluJkh/jY9DIZEm+Mx6mVw1hOtLvCxv6uMA79ejo/4cLfQboX2plaD/kA49G0 WT635AZMFfc5FPplrYTURVOyeCAbDc8yG/S3SPWgkWQW+sLWKxtffmAQiIsF6OrnvVHP t11lwFFdZg8ih//eEgyz66RBN5jFJKe4wwRU7UYsyljkfku6O+OM9ufvJqHe9tNY37/N 8BiHLMkMNL/o9wmZpFPQ1rQp1wKl4k48/lX7IWSuxqg2cLQNglfmUt1f9Izi9WIZSI2t ltwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=v6xP8xj4Ek9na4aaXguRURwXd0/T9XAg2F5D3j3SWP4=; b=okvxHmzXIyDCRUZv356Pgz/54C+4GgIpNKZVGXKMSHq/Qjcn1ayxcBWlye/3UdNBYl 5cREN3qkFvNtrKw/a6UFEr2exVScxkP7EBaxTExnYBbl9/yu6E4VskKh44wgQsXZBA12 9b1pwAcB0EyONGKar7GJ+MTxZHZl4iEtXWltYg0X2nW4zYRQ5QTXuKfHKS4LueeYVIva KqEjfkmBLOtL2dZJehTgharFOncf+3aY0Zxuqinrp9LvW/b8kI+gmbIrVH8nRkgfZUPA TRWod6ZFe+7uHTMuXL5yQoB580ABLm0+/W6SHpRvz79+vQpYrL4nFjKj689+ZTDb2oth /S0w== X-Gm-Message-State: APjAAAXmM+Lp7jzTztfdS+35DeBiGpEhtUEPVteOjXFIz/SSb2gAq3vp WbqxLpq7oNJ5/xeienk4QfcWddhVZwxyqJcHdXk= X-Google-Smtp-Source: APXvYqwpalwH/09y+pr6WBQHzdy0oDK3/ddWfuWUBo3QkrL6PEAqlrykjJYJlubMXyoHL6Ky+RuU9CLsXZKyqhefA9g= X-Received: by 2002:a24:1789:: with SMTP id 131mr13269538ith.36.1554554038413; Sat, 06 Apr 2019 05:33:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dhruv Dhody Date: Sat, 6 Apr 2019 18:03:22 +0530 Message-ID: To: Stig Venaas Cc: "" , rtg-dir@ietf.org, draft-ietf-pce-association-group.all@ietf.org, pce@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Pce] RtgDir review: draft-ietf-pce-association-group-08 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 12:34:01 -0000 Hi Stig, Thank you for your review, especially for providing clear suggestions to fix the text, much appreciated! I have fixed them all, except - > In 6.3.1: > ::= [] > Should there be a space here? ^^^^^ > > In 6.3.2: > ::= [] > Space here? ^^^^^ > > In 6.3.3 > ::=[] > Space here? ^^^^^ > While I agree the space would have been nice, but keeping it consistent with existing PCEP RFCs (where the space is not used, such as RFC8231, RFC5440) is also important. Thus I am leaving this as it is. See diff - https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-association-group-09 Regards, Dhruv From nobody Sat Apr 6 05:57:27 2019 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A6687120026; Sat, 6 Apr 2019 05:57:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: pce@ietf.org Message-ID: <155455543860.21759.9640965086199446437@ietfa.amsl.com> Date: Sat, 06 Apr 2019 05:57:18 -0700 Archived-At: Subject: [Pce] I-D Action: draft-ietf-pce-applicability-actn-11.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 12:57:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : Applicability of the Path Computation Element (PCE) to the Abstraction and Control of TE Networks (ACTN) Authors : Dhruv Dhody Young Lee Daniele Ceccarelli Filename : draft-ietf-pce-applicability-actn-11.txt Pages : 21 Date : 2019-04-06 Abstract: Abstraction and Control of TE Networks (ACTN) refers to the set of virtual network (VN) operations needed to orchestrate, control and manage large-scale multi-domain TE networks so as to facilitate network programmability, automation, efficient resource sharing, and end-to-end virtual service aware connectivity and network function virtualization services. The Path Computation Element (PCE) is a component, application, or network node that is capable of computing a network path or route based on a network graph and applying computational constraints. The PCE serves requests from Path Computation Clients (PCCs) that communicate with it over a local API or using the Path Computation Element Communication Protocol (PCEP). This document examines the applicability of PCE to the ACTN framework. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-applicability-actn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-applicability-actn-11 https://datatracker.ietf.org/doc/html/draft-ietf-pce-applicability-actn-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-applicability-actn-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Apr 6 05:59:06 2019 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 9AC80120026; Sat, 6 Apr 2019 05:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkp7FjpHLkVa; Sat, 6 Apr 2019 05:59:03 -0700 (PDT) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C083F12008C; Sat, 6 Apr 2019 05:59:00 -0700 (PDT) Received: by mail-it1-x133.google.com with SMTP id v8so13064807itf.0; Sat, 06 Apr 2019 05:59:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=fWWOmk16zmIYaFUYDyATSC/ovO3oXu2JqKCnC6xiD5Q=; b=hQYcjew9M2AzI7+cne4n8TXDTKvdHUzNEQf7H2xsu8u5Q0iKHGHi00s/2uFSkmz7tK KQgQ3/AYjeLqOFlB7Pb+QhZvnoAKJS4AjRRBQ7ksTRh9fg7/bzFjDCb7ZXQZ6WoPSIOj IsRh5vi4nXzp1WdpLmwIavGmOQJ6cd68vsGG67aVpQZqqZiSZ6vYRaK28QQP16XnH4P7 Xts2wqEXeE8diedgRkZTpPozJmpzXA+2/iDVuJWexbygPYbvWCEirL8mynM1Guu/bFdD X1hNF2mIi4hODOH/B4Z7QPKndjV6//Fy0kurFvVLQk9vEFjEn1X3R4LiDHHzdfI8J2u3 0ciw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=fWWOmk16zmIYaFUYDyATSC/ovO3oXu2JqKCnC6xiD5Q=; b=WW2qal2d36+9LfQOBs4BpOtUFoz6i8DXKzTnR1vw4Q7M62KBiFkqGFeMGx/G0pcOJl y2JZ4e4q2Yv9Pa9C7J2Es9nZ6XexTvD0l3LpIYHMOQkMQA8gzqMsxk9YAkgVX7M1lbbf w25zyoHQaLFw8yQnj0ULjycVaA9N3A4lMkSynTnLUt6V1yoGkLRD2472WXDmsk3mFfyb IDdLkVGFEvdnWO0qmdoECKolOdYdmCaIGXniWTs+xR0OnfhMLZIxVzuSPnOflaHYO6c3 ETK3eh91m8H9byNpzHH1F4H+9uxRl4eeKr+U0XdpaH1uTydylDGVZW4KNKetiqfsP7aB NUUQ== X-Gm-Message-State: APjAAAVMdrhHlZfnNQpWXyx1277OfbbebN2KZ1W3k3Sc3tK9lXeW2uXh YoegJBt+prEBnvt2fQlkPBi1VKp/FtOLsa7V4tQ= X-Google-Smtp-Source: APXvYqw8HFt6XOXAWeI3ux40Zqs0IDSzzoxlMHZrrQ1vjCw2881c/b4bjHbbC9fBXcvfDAF4RxkObkRvv4YZzJiWIUY= X-Received: by 2002:a24:58c:: with SMTP id 134mr975961itl.103.1554555540001; Sat, 06 Apr 2019 05:59:00 -0700 (PDT) MIME-Version: 1.0 References: <155414886827.17190.2656925435521918458@ietfa.amsl.com> In-Reply-To: <155414886827.17190.2656925435521918458@ietfa.amsl.com> From: Dhruv Dhody Date: Sat, 6 Apr 2019 18:28:24 +0530 Message-ID: To: Yingzhen Qu Cc: rtg-dir@ietf.org, draft-ietf-pce-applicability-actn.all@ietf.org, pce@ietf.org, rtg-ads@tools.ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Pce] Rtgdir last call review of draft-ietf-pce-applicability-actn-10 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 12:59:06 -0000 Hi Yingzhen, Thanks for your review. I have done the fix. Regarding your last comment - > 5. page 14. > =E2=80=9CIn case PNC generates an abstract topology to the MDSC, the > PCInitiate/PCUpd messages from the MDSC to a PNC will contain a > path with abstract nodes and links.=E2=80=9D > Should it be =E2=80=9Cfrom the MDSC to a PNC=E2=80=9D or =E2=80=9Cfrom t= he MDSC to the PNC=E2=80=9D? > "From the MDSC to a PNC" reads fine to me, as there are multiple PNCs involved (one of many rule for the use of a/an)! See diff - https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-applicability= -actn-11 Thanks! Dhruv From nobody Sun Apr 7 21:05:51 2019 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5B7120280; Sun, 7 Apr 2019 21:05:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: pce@ietf.org Message-ID: <155469634305.18338.16502897312749362274@ietfa.amsl.com> Date: Sun, 07 Apr 2019 21:05:43 -0700 Archived-At: Subject: [Pce] I-D Action: draft-ietf-pce-segment-routing-ipv6-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 04:05:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : PCEP Extensions for Segment Routing leveraging the IPv6 data plane Authors : Mahendra Singh Negi Cheng Li Siva Sivabalan Prejeeth Kaladharan Yongqing Zhu Filename : draft-ietf-pce-segment-routing-ipv6-01.txt Pages : 22 Date : 2019-04-07 Abstract: The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. SR enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by Link- State IGPs. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Since SR can be applied to both MPLS and IPv6 forwarding plane, a PCE should be able to compute SR-Path for both MPLS and IPv6 forwarding plane. This document describes the extensions required for SR support for IPv6 data plane in Path Computation Element communication Protocol (PCEP). The PCEP extension and mechanism to support SR-MPLS is described in [I-D.ietf-pce-segment-routing]. This document extends it to support SRv6 (SR over IPv6). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-ipv6/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-segment-routing-ipv6-01 https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-ipv6-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-segment-routing-ipv6-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Apr 7 21:25:59 2019 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F2712017D; Sun, 7 Apr 2019 21:25:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: pce@ietf.org Message-ID: <155469755810.18250.1359855505282242745@ietfa.amsl.com> Date: Sun, 07 Apr 2019 21:25:58 -0700 Archived-At: Subject: [Pce] I-D Action: draft-ietf-pce-segment-routing-ipv6-02.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 04:25:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : PCEP Extensions for Segment Routing leveraging the IPv6 data plane Authors : Mahendra Singh Negi Cheng Li Siva Sivabalan Prejeeth Kaladharan Yongqing Zhu Filename : draft-ietf-pce-segment-routing-ipv6-02.txt Pages : 22 Date : 2019-04-07 Abstract: The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. SR enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by Link- State IGPs. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Since SR can be applied to both MPLS and IPv6 forwarding plane, a PCE should be able to compute SR-Path for both MPLS and IPv6 forwarding plane. This document describes the extensions required for SR support for IPv6 data plane in Path Computation Element communication Protocol (PCEP). The PCEP extension and mechanism to support SR-MPLS is described in [I-D.ietf-pce-segment-routing]. This document extends it to support SRv6 (SR over IPv6). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-ipv6/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-segment-routing-ipv6-02 https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-ipv6-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-segment-routing-ipv6-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Apr 7 22:01:06 2019 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 A8B24120071 for ; Sun, 7 Apr 2019 22:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhZeNbzb5Hqr for ; Sun, 7 Apr 2019 22:01:02 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 142EA1203A6 for ; Sun, 7 Apr 2019 22:01:02 -0700 (PDT) Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id A809C5D2EC1183D37C8D for ; Mon, 8 Apr 2019 06:00:59 +0100 (IST) Received: from DGGEMI423-HUB.china.huawei.com (10.1.199.152) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 8 Apr 2019 06:00:59 +0100 Received: from DGGEMI532-MBX.china.huawei.com ([169.254.7.210]) by dggemi423-hub.china.huawei.com ([10.1.199.152]) with mapi id 14.03.0415.000; Mon, 8 Apr 2019 13:00:49 +0800 From: Mahendra Singh Negi To: "pce@ietf.org" Thread-Topic: [Pce] I-D Action: draft-ietf-pce-segment-routing-ipv6-02.txt Thread-Index: AQHU7cM6fVaZd6QZDk6S1KR0LclIU6Yxr5Eg Date: Mon, 8 Apr 2019 05:00:48 +0000 Message-ID: References: <155469755810.18250.1359855505282242745@ietfa.amsl.com> In-Reply-To: <155469755810.18250.1359855505282242745@ietfa.amsl.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.153.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pce] I-D Action: draft-ietf-pce-segment-routing-ipv6-02.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 05:01:05 -0000 Hi All, Thanks for the valuable suggestions/comments. We have fixed all the comment= s received, difference link goes below:=20 Diff: https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-pce-segment-routing-ip= v6-00&url2=3Ddraft-ietf-pce-segment-routing-ipv6-02 Please do reach out to us in case you have comments/suggestions. Regards, Mahendra -----Original Message----- From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.o= rg Sent: 08 April 2019 09:56 To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-segment-routing-ipv6-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Path Computation Element WG of the IETF. Title : PCEP Extensions for Segment Routing leveraging th= e IPv6 data plane Authors : Mahendra Singh Negi Cheng Li Siva Sivabalan Prejeeth Kaladharan Yongqing Zhu Filename : draft-ietf-pce-segment-routing-ipv6-02.txt Pages : 22 Date : 2019-04-07 Abstract: The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. SR enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by Link- State IGPs. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Since SR can be applied to both MPLS and IPv6 forwarding plane, a PCE should be able to compute SR-Path for both MPLS and IPv6 forwarding plane. This document describes the extensions required for SR support for IPv6 data plane in Path Computation Element communication Protocol (PCEP). The PCEP extension and mechanism to support SR-MPLS is described in [I-D.ietf-pce-segment-routing]. This document extends it to support SRv6 (SR over IPv6). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-ipv6/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-segment-routing-ipv6-02 https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-ipv6-0= 2 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-segment-routing-ipv6-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From nobody Tue Apr 9 05:53:03 2019 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 481EB1207F3; Tue, 9 Apr 2019 05:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXfsrd67TOzr; Tue, 9 Apr 2019 05:52:58 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C76201207FE; Tue, 9 Apr 2019 05:52:54 -0700 (PDT) Received: from [172.20.4.169] (unknown [46.218.58.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id CAACB33F5AF; Tue, 9 Apr 2019 14:52:52 +0200 (CEST) To: "pce@ietf.org" , draft-xiong-pce-pcep-extension-sr-tp@ietf.org From: Loa Andersson Message-ID: <3e5c5691-856c-4cbe-d0ed-4e83a62569cd@pi.nu> Date: Tue, 9 Apr 2019 14:52:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Pce] SR-MPLS-TP: Question on draft-xiong-pce-pcep-extension-sr-tp X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 12:53:01 -0000 Authors, Working Group, MPLS-TP is defined as a network that: "It MUST be possible to operate and configure the MPLS-TP data plane without any IP forwarding capability in the MPLS-TP data plane. (RFC 5654, section 2.3, requirement 36.)" ... "It MUST be possible to provide protection for the MPLS-TP data plane without any IP forwarding capability in the MPLS-TP data plane. (RFC 5654, section 2.5.1.1, requirement 63.)" In fact most MPLS-TP networks are deployed without IP in the data plane. SR-MPLS on the other hand is a technology that is defined to USE IGPs to distribute MPLS-labels, and thus requires IP in the data plane. PCEP also runs over TCP/IP. The draft does not discuss this. I think this is needed, do you have plans to do so? /Loa -- Loa Andersson email: loa@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Tue Apr 9 07:06:07 2019 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 C257A120098 for ; Tue, 9 Apr 2019 07:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.291 X-Spam-Level: X-Spam-Status: No, score=-0.291 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojtVcw0XkwB2 for ; Tue, 9 Apr 2019 07:06:01 -0700 (PDT) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 509FD1200F5 for ; Tue, 9 Apr 2019 07:06:00 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 44dpwk36Bmz8snm for ; Tue, 9 Apr 2019 16:05:58 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.104]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 44dpwk2L5Qz2xCM for ; Tue, 9 Apr 2019 16:05:58 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup (10.114.31.59) by OPEXCAUBM5F.corporate.adroot.infra.ftgroup (10.114.13.104) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 9 Apr 2019 16:05:58 +0200 Received: from [10.193.71.81] (10.168.234.6) by OPEXCLILM43.corporate.adroot.infra.ftgroup (10.114.31.59) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 9 Apr 2019 16:05:57 +0200 From: Organization: Orange To: "pce@ietf.org" Message-ID: <23743_1554818758_5CACA6C6_23743_383_1_70372f0e-4531-b398-6d3a-af97c7d7f40e@orange.com> Date: Tue, 9 Apr 2019 16:05:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [10.168.234.6] Archived-At: Subject: [Pce] WG LC for draft-ietf-pce-association-diversity and draft-ietf-pce-stateful-path-protection X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 14:06:07 -0000 Hi all, This message initiates a bulk WG Last Call for both draft-ietf-pce-association-diversity-06 and draft-ietf-pce-stateful-path-protection-04. Please review these documents and share your feedback using the PCE mailing list. If you have an implementation of any of them, you may let the chairs know privately. This double LC will last for 3 weeks and will end on Tuesday April 30. Thanks, Adrian, Dhruv & Julien _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Tue Apr 9 09:32:20 2019 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 CA905120876 for ; Tue, 9 Apr 2019 09:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QD-bG1ipShll for ; Tue, 9 Apr 2019 09:32:15 -0700 (PDT) Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F4237120892 for ; Tue, 9 Apr 2019 09:32:09 -0700 (PDT) Received: by mail-it1-x136.google.com with SMTP id y134so5931750itc.5 for ; Tue, 09 Apr 2019 09:32:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=z8+vSaegv8t94fjFt/YK2yCjp23wsuklEW2a+AaPQqk=; b=EAUOGcj1CHmWhxWZgyNkLVUupnxH6oa05c8JDESx8Aa9ychd2p5uQbsR9bYadJUSds N9lFyquyRLq1ULQVG8N+cY7I87e6coZeb4ICNs4V/YxP2dD1iwooKnD6KLEzsSBZzwIR /3tYL5s7A/pQLe1/8pjB6Lo1VsC8L//pXtWfa1PyIJ3FHYuWAbYd6fOA2ObZ91dWlPUS 5Lw9Y2IJxVpPU9jlv/CJ4bKorWEcfBRvEQ8oBNzdfe+2y53PYps2LzNzc589fSzKu/1D Mfl1hdx22pTVhqauJxmYzuXGh9NJI+6fzJ8pcKCokiK9exs8icb9Rx6G486YWuLyNRxU VrIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=z8+vSaegv8t94fjFt/YK2yCjp23wsuklEW2a+AaPQqk=; b=XDxbriGjaswW74GUw7k72uKR827wqHfP1odfz+g1LdsO+Df1rVoIjBIc2tgzEvV3iI sbqaEALkUUG2lLN5y3jLGAlJ+A5SV9IgVkfQGKFXQ4FUNzg6TGB7yE1M/yIocwH3QWb/ 6fw7806WlY0Kw9tU8hNnoAPXubSTEaKjI0gtBv6H7BduwMUFK4+h+UumuweIWxPe+vIq Uu33avuK8N6WKkvar0b8Ci/XhIDynndGv9jqPFX6YFOcipHvxreAcobF+gRpNwxDBgwf 7s892vPaHNqIhw5QyKCShma+trh7peEIJCpJfCUHYEGEN6MuKzxLMLFzC/ghApY0xDUy CP0w== X-Gm-Message-State: APjAAAVsRQejFVvWaPpBQQbvRp6GXCE3GmPvYIhuIMNhBUbwS82VnC14 4PFzD7+OU3JRADhi7SEOqniixDI9uBiZbw/EbTM/EAFP710= X-Google-Smtp-Source: APXvYqwpBiwY6hJblfT95aRFyZe+L1bx1duPGgTSxdwfWNTPAPauaXCkUuk7exl5ac7cv9NWhWf6If/Qi0sapxRocEI= X-Received: by 2002:a24:3d4a:: with SMTP id n71mr26211258itn.55.1554827528751; Tue, 09 Apr 2019 09:32:08 -0700 (PDT) MIME-Version: 1.0 From: Dhruv Dhody Date: Tue, 9 Apr 2019 22:01:32 +0530 Message-ID: To: pce@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Pce] Proposed Implementation Policy for PCE WG X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 16:32:18 -0000 Hi WG, In discussion with our ADs and with other WG chairs in the Routing Area, the PCE chairs have decided that it would be good for the working group to have a stated policy about what implementation is needed, desired, or required before a draft can advance for publication as an RFC. The full range of options is available from "no implementation required" up to "multiple independent and inter-operable implementations required". The purposes are to help ensure quality and implementable RFCs, to make sure that our work is truly relevant and needed, and to understand the relative priorities of our work. The chairs briefly mentioned this at the IETF 104 PCE WG meeting, and we promised to start a discussion on what 'Implementation Policy' to set for the PCE WG. This is a subject for the WG to decide through the usual rough consensus, but the chairs would like to start the discussion with a proposal as follows - "All WG I-Ds are required to include an 'Implementation Status' Section (as per RFC7942) to document known existing or planned implementations. The chairs can make exceptions on a per-document basis." Please raise any concern with the proposed implementation policy by 24th April 2019. Thanks! Adrian, Dhruv & Julien From nobody Tue Apr 9 11:07:55 2019 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFFB1200EA; Tue, 9 Apr 2019 11:07:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan via Datatracker To: "The IESG" Cc: draft-ietf-pce-stateful-pce-p2mp@ietf.org, Adrian Farrel , pce-chairs@ietf.org, adrian@olddog.co.uk, pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Suresh Krishnan Message-ID: <155483327430.19630.5640428050752441340.idtracker@ietfa.amsl.com> Date: Tue, 09 Apr 2019 11:07:54 -0700 Archived-At: Subject: [Pce] Suresh Krishnan's No Objection on draft-ietf-pce-stateful-pce-p2mp-12: (with COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 18:07:54 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-pce-stateful-pce-p2mp-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-p2mp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Section 7.2. "The special value of all zeros for this TLV is used to refer to all paths pertaining to a particular PLSP-ID." Can you clarify what fields are all zero? What would the length be? From nobody Tue Apr 9 11:23:56 2019 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 5EA40120145; Tue, 9 Apr 2019 11:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0cUzAmvDHoX; Tue, 9 Apr 2019 11:23:52 -0700 (PDT) Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 189F01200FA; Tue, 9 Apr 2019 11:23:52 -0700 (PDT) Received: by mail-io1-xd43.google.com with SMTP id p23so14559765iol.13; Tue, 09 Apr 2019 11:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VsIHJzGuGAIvNjkVoAY/WeEeqWC+jKCzWbJEiWSYRe8=; b=PrVCYxX9Jwtb/HENTKZORNVijEHlfRbRGYJ4W/3THk6kgk2FDelj0nlgN+IPF5qDnB 5lz7mKjv19z+eSFGbAqW7AjXICi9HzRpRsxb9BB6RaDw5jG74wn+UqVf3qf/bG9T1x6T YgY5mUEp59anZkE808UInhpaiFxqLLq85L9QMd4OOtqLvjWGcCfdy4R11edhu0hCfTtK 9HSFPOKa2rLptcbMAauJyVhqwoXVXhMiYWWgvKijCW8nuAizKmIM+V0T7IgXOjcuY9ew zTv0YZko2hiMJ9yUKWTcECDdsSab4CSlfiJ2zhIiwgyInX2t8hZbT/1J38lmhtB7sudU khaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VsIHJzGuGAIvNjkVoAY/WeEeqWC+jKCzWbJEiWSYRe8=; b=A4P8iPzcAlXEBAsMACZBw/YRmoZBo7BxHu4DE94w1QBh9+VjDSWT/RJXKaOY5cTqbc cW666CrNEOKQ2MjMHbnqqo/R0vo19VW27AHkliyBaL/wLx6C7mVT2JrlGEj0TTDUoGhs V/oAvsMROvkErBUM13CQW7zbtNXHILCk7wMIRa6xkPkCq+fJRnSLnWXNkFnAKj5cCJWW NsdfgYDJmjEl3ImPMh+WdVndDm0MmKszSBBXHlejbCG45+H48AqtMSB27n3abq+4fQIX sSvE9SrCX4exbiyPGz0jVNVB+YzsGgAvZ8l8Rib1beWprDvF0rapSOxkWaR4gz/ZgF2q i2RQ== X-Gm-Message-State: APjAAAU7phIgdLBZFjF8FH1L3Atz6i5HRBVvjP9Sc4iYI+zkAfn8/qSt pLvrat3KP6+POJjJCtldiJ/6f3E7SxQD1/zPhFk= X-Google-Smtp-Source: APXvYqzAqwziiKnoxrLsCdzNtV7eZPe7b83nlPmgdTE60qDTq8HPY9kIC54ulKXhDPtHiqz9/B9R9CGgEy8DaE+3E2M= X-Received: by 2002:a5d:8b55:: with SMTP id c21mr24414807iot.188.1554834231168; Tue, 09 Apr 2019 11:23:51 -0700 (PDT) MIME-Version: 1.0 References: <155483327430.19630.5640428050752441340.idtracker@ietfa.amsl.com> In-Reply-To: <155483327430.19630.5640428050752441340.idtracker@ietfa.amsl.com> From: Dhruv Dhody Date: Tue, 9 Apr 2019 23:53:13 +0530 Message-ID: To: Suresh Krishnan Cc: The IESG , draft-ietf-pce-stateful-pce-p2mp@ietf.org, Adrian Farrel , pce-chairs@ietf.org, pce@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Pce] Suresh Krishnan's No Objection on draft-ietf-pce-stateful-pce-p2mp-12: (with COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 18:23:54 -0000 Hi Suresh, Thanks for your review! On Tue, Apr 9, 2019 at 11:37 PM Suresh Krishnan via Datatracker wrote: > > Suresh Krishnan has entered the following ballot position for > draft-ietf-pce-stateful-pce-p2mp-12: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-p2mp/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > * Section 7.2. > > "The special value of all zeros for this TLV is used to refer to all paths > pertaining to a particular PLSP-ID." > > Can you clarify what fields are all zero? What would the length be? > > All fields of the value portion of the TLV are set to zero. The TLVs has a fixed length of 16 and 40 for IPv4 and IPv6 respectively. RFC8231 (section 7.3.1) also uses similar language for the TLV defined there. Do you see a need to update text and be explicit? Thanks! Dhruv From nobody Tue Apr 9 11:40:58 2019 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C36F1201CB; Tue, 9 Apr 2019 11:40:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan via Datatracker To: "The IESG" Cc: draft-ietf-pce-gmpls-pcep-extensions@ietf.org, Julien Meuric , pce-chairs@ietf.org, julien.meuric@orange.com, pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Suresh Krishnan Message-ID: <155483525704.19587.9035104742869837510.idtracker@ietfa.amsl.com> Date: Tue, 09 Apr 2019 11:40:57 -0700 Archived-At: Subject: [Pce] Suresh Krishnan's No Objection on draft-ietf-pce-gmpls-pcep-extensions-14: (with COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 18:40:57 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-pce-gmpls-pcep-extensions-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-pcep-extensions/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Section 2.5.2 "In this object type the order of the TLVs MUST be followed according to the object type definition." Not sure what this means. Can you clarify? * Section 2.7 "C-Type (8 bits): the C-Type of the included Label Object as defined in [RFC3471]." I could not find any references to C-Types in RFC3471. Shouldn't you be referring to RFC3473 instead? I have a similar comment for the Label field. From nobody Tue Apr 9 15:44:13 2019 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 03BF912043D; Tue, 9 Apr 2019 15:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kaloom.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqwT4uhlBaWp; Tue, 9 Apr 2019 15:44:01 -0700 (PDT) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670130.outbound.protection.outlook.com [40.107.67.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF6BA12042C; Tue, 9 Apr 2019 15:44:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaloom.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PLoJP1pl2+tX1Qstlcfufp7XNZfkWfwVKcnj9gpOZAE=; b=on1RQRhxcDm7VVW+WGie/4ePDidTZ+sn0oypzmLvfHAjHOcJSYSNaXD5Tgz3Pnbkn5rYLal6L6+DOjljTni8inQp3o6GydxjZUVfc67ZZzPwpbHpzI8PkkSgYRehdU1Xhz8Eqov0HDBanfgjPHeNO5XkWLTMrOZ6ezKpqIP1e/A= Received: from YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM (52.132.44.159) by YTOPR0101MB1001.CANPRD01.PROD.OUTLOOK.COM (52.132.47.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.16; Tue, 9 Apr 2019 22:43:58 +0000 Received: from YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM ([fe80::7d75:b044:39b8:d47e]) by YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM ([fe80::7d75:b044:39b8:d47e%5]) with mapi id 15.20.1771.016; Tue, 9 Apr 2019 22:43:58 +0000 From: Suresh Krishnan To: Dhruv Dhody CC: The IESG , "draft-ietf-pce-stateful-pce-p2mp@ietf.org" , Adrian Farrel , "pce-chairs@ietf.org" , "pce@ietf.org" Thread-Topic: Suresh Krishnan's No Objection on draft-ietf-pce-stateful-pce-p2mp-12: (with COMMENT) Thread-Index: AQHU7wFj7W+HyZv7q0KsImVYbppkgaY0bXsA Date: Tue, 9 Apr 2019 22:43:58 +0000 Message-ID: References: <155483327430.19630.5640428050752441340.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Suresh@kaloom.com; x-originating-ip: [45.19.110.76] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ac51b0dd-9f93-4821-d0d1-08d6bd3cdadc x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:YTOPR0101MB1001; x-ms-traffictypediagnostic: YTOPR0101MB1001: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 000227DA0C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(39840400004)(366004)(376002)(396003)(199004)(189003)(106356001)(14444005)(68736007)(6512007)(76176011)(11346002)(80792005)(66066001)(3846002)(83716004)(256004)(71200400001)(25786009)(6116002)(71190400001)(53546011)(966005)(33656002)(14454004)(72206003)(508600001)(97736004)(6506007)(305945005)(7736002)(4326008)(6246003)(102836004)(105586002)(86362001)(316002)(54906003)(81156014)(446003)(81166006)(8936002)(99286004)(6306002)(6436002)(8676002)(2616005)(82746002)(2906002)(5660300002)(6916009)(6486002)(476003)(229853002)(186003)(486006)(36756003)(26005)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:YTOPR0101MB1001; H:YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: kaloom.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: dZT3V1KIAR/QSjxr6zAsB1EyWp5b07z/V4XkJlcNRwLqRqTi7jAAUs/TLQ8guQZX/gjpYvb47/0ZHjezhPGfzyGwgyrBNuKcFnR7g76QkdMU3euXasqwzLiyQOM8BSO5PcaV2lPtGe19LKUEJAn9Y60/iXhh8TjgavxutIbW77vckBiGcWSVRxvh9QFtN+45Bo7zkiZBHQweYxHUYrOOgqWghlZq1Hlw/Id6SvVx2nJZxKcEqA3ztasShN60hMlvz2v7gH484AWKn+b8J5wXsJgM0Cg7mcFVbb/jftcvqgM/7UJBtvH6F2QkJbGBiRYy2+znFHZxuxwhlj7qVTH98/Wy4M/Bf/Es4smi8b6sBMHKR9qQ+tNM0DvqznkAg1TuVjN0X/wzj+3NnN6jyLOJo15q3i2a/lpiM1sJ1g6ePyk= Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: kaloom.com X-MS-Exchange-CrossTenant-Network-Message-Id: ac51b0dd-9f93-4821-d0d1-08d6bd3cdadc X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2019 22:43:58.6505 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 47d58e26-f796-48e8-ac40-1c365c204513 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB1001 Archived-At: Subject: Re: [Pce] Suresh Krishnan's No Objection on draft-ietf-pce-stateful-pce-p2mp-12: (with COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 22:44:03 -0000 Hi Dhruv, > On Apr 9, 2019, at 2:23 PM, Dhruv Dhody wrote: >=20 > Hi Suresh, >=20 > Thanks for your review! >=20 > On Tue, Apr 9, 2019 at 11:37 PM Suresh Krishnan via Datatracker > wrote: >>=20 >> Suresh Krishnan has entered the following ballot position for >> draft-ietf-pce-stateful-pce-p2mp-12: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htm= l >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-p2mp/ >>=20 >>=20 >>=20 >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >>=20 >> * Section 7.2. >>=20 >> "The special value of all zeros for this TLV is used to refer to all pat= hs >> pertaining to a particular PLSP-ID." >>=20 >> Can you clarify what fields are all zero? What would the length be? >>=20 >>=20 >=20 > All fields of the value portion of the TLV are set to zero. The TLVs > has a fixed length of 16 and 40 for IPv4 and IPv6 respectively. > RFC8231 (section 7.3.1) also uses similar language for the TLV defined > there. Do you see a need to update text and be explicit? It would be nice to add but I will leave it to your discretion.=20 Thanks Suresh From nobody Tue Apr 9 18:48:25 2019 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F3412013F; Tue, 9 Apr 2019 18:48:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-pce-stateful-pce-p2mp@ietf.org, Adrian Farrel , pce-chairs@ietf.org, adrian@olddog.co.uk, pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <155486089608.19649.9617345506233285248.idtracker@ietfa.amsl.com> Date: Tue, 09 Apr 2019 18:48:16 -0700 Archived-At: Subject: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-stateful-pce-p2mp-12: (with DISCUSS and COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 01:48:16 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-pce-stateful-pce-p2mp-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-p2mp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is a comparatively minor point, but I don't think some of the message layout is quite fully specified. In particular, Section 7.2 discusses some new TLVs (in a confusing way, referring to the class of two TLVs as a single nonexistent TLV) but does not always say which object the TLVs are allowed to appear within. (The first paragraph seems to talk of the TLV appearing in a PCRpt, which is a message and as such would contain only objects and not TLVs directly.) The second paragraph does mention the LSP object, which leads the reader to infer that this TLV is only intended to appear in the LSP object, and only in the PCRpt and PCUpd messages explicitly mentioned, but we probably shouldn't force readers to make that leap. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I've made a lot of comments about grammar nits (tagged as such), but there are also some more substantial comments to look for. Section 1 [RFC4875] describes how to set up point-to-multipoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The PCE has been identified as a suitable application for the computation of paths for P2MP TE LSPs ([RFC5671]). nit: some readers might wonder who has done this identification. Section 3.1 [RFC8051] presents several use cases, demonstrating scenarios that benefit from the deployment of a stateful PCE including optimization, recovery, etc., which are equally applicable to P2MP TE LSPs. [RFC8231] defines the extensions to PCEP for P2P TE LSPs. [...] nit: maybe "the extensions to PCEP needed for stateful operation of P2P TE LSPs"? Just "the extensions" is pretty generic. Section 5.1 Path Computation State Report (PCRpt): Each P2MP TE LSP State Report in a PCRpt message can contain actual P2MP TE LSP path attributes, Is this "can contain" or just "contains"? Section 5.6.3.1 The Instantiation operation of P2MP TE LSPs is same as defined in nit: "the same as" section 5.3 of [RFC8281] including handling of PLSP-ID, SYMBOLIC- nit: comma after "[RFC8281]" PATH-NAME TLV etc. Rules of processing and error codes remains nit: comma after TLV unchanged. The N (P2MP) flag (Section 7.1) MUST be set in LSP object nit: "The rules for processing and use of error codes remain unchanged." nit: "in the LSP object" in PCInitiate message by PCE to specify the instantiation is for P2MP nit: "PCInitiate messages by the PCE to specify that the instantiation" TE LSPs. Like the PLSP-ID as per [RFC8281], the P2MP-LSP-IDENTIFIERS nit: parentheses around "as per [RFC8281]" TLV SHOULD NOT be included in the LSP object in PCIntiitate message nit: "PCInitiate messages" (as it is generated by PCC and carried in PCRpt message instead) and MUST be ignored on receipt. Section 6.1 Was it a conscious decision to depart from RFC 8231 and inline objects in the definition of (as opposed to keeping the intermediate construction)? The P2MP END-POINTS object defined in [RFC8306] is mandatory for specifying address of P2MP leaves grouped based on leaf types. nit: "addresses of P2MP leaves, grouped by leaf type" When reporting the status of a P2MP TE LSP, the destinations MUST be grouped in END-POINTS object based on the operational status (O field in S2LS object) and leaf type (in END-POINTS). This way, leaves of the same type that share the same operational status are grouped together. [...] Does this mean that it's an error for a PCRpt message to include more than one END-POINTS object with a given value of leaf-type? If so, it may be worth stating that explicitly. For a delegated P2MP TE LSP configuration changes are reported via PCRpt message. For example, adding of new leaves END-POINTS (leaf- type = 1) is used where as removing of old leaves (leaf-type = 2) is used. nit: "is used, and removing of old leaves (leaf-type = 2) is used". Note that the compatibility with the [RFC8231] definition of is preserved. At least one instance of MUST be present in this message for P2MP LSP. Interestingly, RFC 8231 does not spell the structure of the PCRpt message using an object. Section 6.2 Note that the compatibility with the [RFC8231] definition of is preserved. If I'm reading this right, compatibility is only preserved when is omitted (and the list only has a single endpoint/path pair). Perhaps some more text could be added about the nature of the provided (and needed) compatibility? Section 6.6.2 The LSP State Report message is sent by a PCC to report or delegate the P2MP TE LSPs. An example of a PCRpt message for a delegated P2MP TE LSPs is described below to add new leaves to an existing P2MP TE nit: "TE LSP" It might be handy to mention inline "for leaf type 1 (add)" and "leaf type 2 (remove)" just to refresh the reader's memory. Section 7.1 The flags defined in this section (N, F, E flags) are used in PCRpt, PCUpd, or PCInitiate message. In case of PCReq and PCRep message, these flags have no meaning and thus MUST be ignored. The corresponding flags in the RP (Request Parameters) object are used as described in [RFC8231]. I'm not really finding much discussion of RP flags in RFC 8231 (as opposed to SRP, in Section 7.2 thereof). RFC 5440 does define a few flags for the RP object, though. Section 7.2 I strongly suggest changing the initial language to make it clear that there is not a single P2MP-LSP-IDENTIFIER TLV, but rather a class of two related TLVs that serve to identify P2MP LSPs, e.g., by referring to "P2MP LSP Identification TLVs" (without hyphenation or all-caps). If the N bit is set on a PCRpt but the P2MP-LSP-IDENTIFIER TLV is nit: the bit is set in the LSP object within the PCRpt, right? The P2MP-LSP-IDENTIFIERS TLV MAY be included in the LSP object in the PCUpd message for P2MP TE LSPs. The special value of all zeros for this TLV is used to refer to all paths pertaining to a particular PLSP-ID. Given that we haven't specialized into the IP version-specific TLVs yet, I agree with the previous comments that we need greater clarity on what the "value of all zeros" means, here. Additionally, is that special value supposed to be restricted to the given IP version or literally all paths, so that there are two functionally equivalent encodings for these semantics? Section 9 The PCEP extensions described in this document for stateful PCEs with P2MP capability MUST NOT be used if PCE has not advertised its stateful capability with P2MP as per Section 5.2. If the PCEP Speaker on the PCC supports the extensions of this draft (understands the P2MP flag in the LSP object) but did not advertise this capability, then upon receipt of PCUpd message from the PCE, it SHOULD generate a PCErr with error-type 19 ("Invalid Operation"), error-value 12 (early allocated by IANA) ("Attempted LSP Update Request for P2MP if active stateful PCE capability for P2MP was not advertised") and terminate the PCEP session. If the PCEP Speaker on the PCE supports the extensions of this draft (understands the P2MP flag in the LSP object) but did not advertise this capability, then We should probably disambiguate these two "P2MP flag"s to "M flag" and "N flag", respectively. ("P flags" is used below.) If a Stateful PCE receives a P2MP TE LSP report message and the PCE does not understand the P2MP flag in the LSP object, and therefore the PCEP extensions described in this document, then the Stateful PCE would act as per [RFC8231]. Without a section reference, it's a little annoying to figure out exactly what that behavior would be. Section 14.2 One could perhaps argue that RFCs 4875, 7525, and 8253 should be normative references. From nobody Tue Apr 9 19:57:33 2019 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 98340120143 for ; Tue, 9 Apr 2019 19:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netflix.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HlWXEHGfhej for ; Tue, 9 Apr 2019 19:57:23 -0700 (PDT) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4EC7120104 for ; Tue, 9 Apr 2019 19:57:23 -0700 (PDT) Received: by mail-ua1-x92c.google.com with SMTP id h4so284982uaj.9 for ; Tue, 09 Apr 2019 19:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=rg47KYPcbWNoEXLp1OPc3rEH89qyQ1bOzq138JYnP8c=; b=TCUcsjHTenrp4KeMDD1ktYuMB0LErBJRotYhKlAdG4EvEI/WF5m7s83r2UbqlsNke8 rEijPf0JJAYVqqXC1sICYTNRUH2Rbxl4X0ut88mNcO2LVXwDO4cyE2n6GygnjcsgMDoI k3ZQEyEO3GIkGZkQFgm4CwSJDFDlF0Bhh4CpY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=rg47KYPcbWNoEXLp1OPc3rEH89qyQ1bOzq138JYnP8c=; b=pHMiAktQh7uZHrN9qd86mV+/3WkQiv0Hfzr8rAFxEhyUQMrObZvHXDqYL/1EYPUKNv 96GatBFTgiHTtpa3ZCRD+8bFarID9K00NOZ7gY2JX3X1FsX984Oj+8OfEEfP89NMpgwr IumL2ngCxxXrsK2Jjasjwn+0a9Xan6FMjy/VdWOhrjnfD64ve1cI8KlwgsH/P3RPvggY gF9x89w1j23cdWwikTXvvMZBWKcQpEI0pXSHLBHpfmFn5sj7RvWQP08x2vFRS8gjgqVL UdRpX5jarwTeggbXCbo1ZaZp8iDwQ+m+Cj9mZAWIIYrL6iEHs8rPS4MGvoaTMqpUbBsN zlPA== X-Gm-Message-State: APjAAAXrwv8zasLb3JyLHptWqxvNScXz0oleWk+E8Sv8hKf/NcAREdzP jmt6hoIvEHNh7X6zdly0K1IVw02iCivhW143phYFyw== X-Google-Smtp-Source: APXvYqymXX8d+4+xcz3sXize2OpdOoy1KJqI/MGuzwgQC4fSnlOgbF5mEe2JWlJWpjY6laYAm1L6pNTfkrht+KdUu0U= X-Received: by 2002:ab0:274a:: with SMTP id c10mr20006680uap.107.1554865042401; Tue, 09 Apr 2019 19:57:22 -0700 (PDT) MIME-Version: 1.0 From: Hariharan Ananthakrishnan Date: Tue, 9 Apr 2019 19:57:11 -0700 Message-ID: To: draft-ietf-pce-association-diversity@ietf.org Cc: pce@ietf.org Content-Type: multipart/alternative; boundary="00000000000086e9670586243a23" Archived-At: Subject: [Pce] IPR poll on draft-ietf-pce-association-diversity X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 02:57:26 -0000 --00000000000086e9670586243a23 Content-Type: text/plain; charset="UTF-8" Hi authors, In preparation for Working Group last call on this draft, I'd like all authors and contributors to confirm on the list that they are in compliance with IETF IPR rules. Please respond (copying the mailing list) to say one of: I am not aware of any IPR applicable to this draft that should be disclosed in accordance with IETF IPR rules. I am aware of IPR applicable to this draft, and it has already been disclosed to the IETF. I am aware of IPR applicable to this draft, but that has not yet been disclosed to the IETF. I will work to ensure that it will be disclosed in a timely manner. Thanks, - Hari --00000000000086e9670586243a23 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
Hi authors,

In preparation for Working Group last call on this draft, I'd like all
authors and contributors to confirm on the list that they are in compliance
with IETF IPR rules.

Please respond (copying the mailing list) to say one of:

I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.

I am aware of IPR applicable to this draft, and it has already been
disclosed to the IETF.

I am aware of IPR applicable to this draft, but that has not yet been
disclosed to the IETF. I will work to ensure that it will be disclosed in a
timely manner.

Thanks,
- Hari
--00000000000086e9670586243a23-- From nobody Tue Apr 9 19:57:39 2019 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 D71FA12051B for ; Tue, 9 Apr 2019 19:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netflix.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLvBugk3vdwz for ; Tue, 9 Apr 2019 19:57:25 -0700 (PDT) Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D925212009C for ; Tue, 9 Apr 2019 19:57:24 -0700 (PDT) Received: by mail-ua1-x933.google.com with SMTP id d5so288385uan.6 for ; Tue, 09 Apr 2019 19:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=1wuxjymOrL+UXklXX0ny/Yk5Bbsh+GQBDtDXiBEQoYc=; b=mD6uUMpjaFXeNSY7SBjNRLCU349WEwGiSNgrWYiZ7JpGgxifq85d4dsfYzJBH78+L/ KIJ0ctSZLqKoj62lsa9lwJr/INEppiJV4HQdYwuaS/REeOOHh8MQ+lqzUTYjfGur21lC UAjp94/UjFMRmN+Hb3QBPmNMhTlVraa3shPCo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=1wuxjymOrL+UXklXX0ny/Yk5Bbsh+GQBDtDXiBEQoYc=; b=IxmEYJ8ZUpnf6wf+wPnIxz6jpy5ZoczDHu3KGmgArE3Sv55gWkdn87anVg+b7AsFKJ pWXAdjdKnjLRdsnl0NmyoDwH+WOSjsQi92qH6TDeoMyCue4QvNWOvEJve+vimGEHDQsh k4zifvIJlABKICXBX7imcjv0blwgbzcvq2h6uKYupNHYsvguRYzjS9NRenOWYBq0zIyH lmViht2A0nW2fX/MnIJ9Nc3mnhJ7CJLL3YX9fBBngQvzZlFwRI399IGWMIszUA2PwukE oNWqQJq64iAr7CyFchDvcPRYm5DZBXsmxk9Y3cz7ULZN5Mc8N9Cp6BxbTKnRPq338lkq VZDg== X-Gm-Message-State: APjAAAUYNZx99d0qAf1AxQEt9zbw6XDvlnna5clUFGjdObzXs4TLBbc6 GuvJgWKhnTD8kXxtNS023Ese3FpO59Xag8/jH5FQt96+HGk5Bg== X-Google-Smtp-Source: APXvYqyhC8N3WOdvVBbTEHj+6dpdEjSstKEBwMF9qrbYLk8WQDQzPJsiH5MnPI/sbROrmbXhxWjMN8+vr5HXc4nl6SM= X-Received: by 2002:ab0:73d3:: with SMTP id m19mr21523722uaq.46.1554865043830; Tue, 09 Apr 2019 19:57:23 -0700 (PDT) MIME-Version: 1.0 From: Hariharan Ananthakrishnan Date: Tue, 9 Apr 2019 19:57:13 -0700 Message-ID: To: draft-ietf-pce-stateful-path-protection@ietf.org Cc: pce@ietf.org Content-Type: multipart/alternative; boundary="0000000000009cbcec0586243a6d" Archived-At: Subject: [Pce] IPR poll on draft-ietf-pce-stateful-path-protection X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 02:57:28 -0000 --0000000000009cbcec0586243a6d Content-Type: text/plain; charset="UTF-8" Hi authors, In preparation for Working Group last call on this draft, I'd like all authors and contributors to confirm on the list that they are in compliance with IETF IPR rules. Please respond (copying the mailing list) to say one of: I am not aware of any IPR applicable to this draft that should be disclosed in accordance with IETF IPR rules. I am aware of IPR applicable to this draft, and it has already been disclosed to the IETF. I am aware of IPR applicable to this draft, but that has not yet been disclosed to the IETF. I will work to ensure that it will be disclosed in a timely manner. Thanks, - Hari --0000000000009cbcec0586243a6d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
Hi authors,

In preparation for Working Group last call on this draft, I'd like all
authors and contributors to confirm on the list that they are in compliance
with IETF IPR rules.

Please respond (copying the mailing list) to say one of:

I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.

I am aware of IPR applicable to this draft, and it has already been
disclosed to the IETF.

I am aware of IPR applicable to this draft, but that has not yet been
disclosed to the IETF. I will work to ensure that it will be disclosed in a
timely manner.

Thanks,
- Hari
--0000000000009cbcec0586243a6d-- From nobody Tue Apr 9 23:16:37 2019 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 D02BF120149; Tue, 9 Apr 2019 23:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCcJXyT8iwFy; Tue, 9 Apr 2019 23:16:32 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCF9C120048; Tue, 9 Apr 2019 23:16:31 -0700 (PDT) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id C53F5A95A4600ADA3CB5; Wed, 10 Apr 2019 07:16:29 +0100 (IST) Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 10 Apr 2019 07:16:29 +0100 Received: from BLREML503-MBS.china.huawei.com ([169.254.12.125]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0439.000; Wed, 10 Apr 2019 11:46:17 +0530 From: Dhruv Dhody To: Benjamin Kaduk , The IESG CC: "draft-ietf-pce-stateful-pce-p2mp@ietf.org" , "pce@ietf.org" , "pce-chairs@ietf.org" Thread-Topic: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-stateful-pce-p2mp-12: (with DISCUSS and COMMENT) Thread-Index: AQHU7z+M60F99Nqc4U2m/TB9hOh6m6Y03ROw Date: Wed, 10 Apr 2019 06:16:17 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8DA0F235@BLREML503-MBS.china.huawei.com> References: <155486089608.19649.9617345506233285248.idtracker@ietfa.amsl.com> In-Reply-To: <155486089608.19649.9617345506233285248.idtracker@ietfa.amsl.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.149.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-stateful-pce-p2mp-12: (with DISCUSS and COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 06:16:35 -0000 Hi Benjamin,=20 Thank you for your review.=20 Working Copy: https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/mast= er/draft-ietf-pce-stateful-pce-p2mp-13.txt Diff: https://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-pce-stateful-pce-p2m= p-12&url2=3Dhttps://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master= /draft-ietf-pce-stateful-pce-p2mp-13.txt More inline...=20 > -----Original Message----- > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Benjamin Kaduk via > Datatracker > Sent: 10 April 2019 07:18 > To: The IESG > Cc: draft-ietf-pce-stateful-pce-p2mp@ietf.org; pce@ietf.org; pce- > chairs@ietf.org > Subject: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-stateful-pce- > p2mp-12: (with DISCUSS and COMMENT) >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-pce-stateful-pce-p2mp-12: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-p2mp/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > This is a comparatively minor point, but I don't think some of the messag= e > layout is quite fully specified. In particular, Section 7.2 discusses > some new TLVs (in a confusing way, referring to the class of two TLVs as = a > single nonexistent TLV) but does not always say which object the TLVs are > allowed to appear within. (The first paragraph seems to talk of the TLV > appearing in a PCRpt, which is a message and as such would contain only > objects and not TLVs directly.) The second paragraph does mention the LS= P > object, which leads the reader to infer that this TLV is only intended to > appear in the LSP object, and only in the PCRpt and PCUpd messages > explicitly mentioned, but we probably shouldn't force readers to make tha= t > leap. >=20 >=20 [[Dhruv Dhody]] I have made following changes -=20 - Made 7.2 (P2MP-LSP-IDENTIFIERS TLV) as a sub-section of 7.1, making it cl= ear that it is part of LSP object - Added this text at the start=20 [RFC8231] specify the LSP-IDENTIFIERS TLVs to be included in the LSP object. For P2MP TE LSP, this document defines P2MP-LSP-IDENTIFIERS TLVs for the LSP object. There are two P2MP-LSP-IDENTIFIERS TLVs, one for IPv4 and one for IPv6. - I further clarified=20 The P2MP-LSP-IDENTIFIERS TLV MUST be included in the LSP object in PCRpt message for P2MP TE LSPs. If the N bit is set in the LSP object in the PCRpt message but the P2MP-LSP- IDENTIFIER TLV is absent, the PCE MUST respond with a PCErr message carrying error-type 6 ("mandatory object missing") and error-value 14 (early allocated by IANA) ("P2MP-LSP-IDENTIFIER TLV missing") and close the PCEP session. The P2MP-LSP-IDENTIFIERS TLV MAY be included in the LSP object in the PCUpd message for P2MP TE LSPs. The special value of all zeros for all the fields in the value portion of the TLV is used to refer to all paths pertaining to a particular PLSP-ID. The length of the TLV remains fixed based on the IP version.=20 The P2MP-LSP-IDENTIFIERS TLV SHOULD NOT be used in PCInitiate (see Section 5.6.3.1) and MAY optionally be included in the LSP object in the PCReq and the PCRep message for P2MP TE LSP. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I've made a lot of comments about grammar nits (tagged as such), but ther= e > are also some more substantial comments to look for. >=20 > Section 1 >=20 > [RFC4875] describes how to set up point-to-multipoint (P2MP) Traffic > Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol > Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The > PCE has been identified as a suitable application for the computation > of paths for P2MP TE LSPs ([RFC5671]). >=20 > nit: some readers might wonder who has done this identification. >=20 [[Dhruv Dhody]] Reworded=20 [RFC5671] examines the applicability of PCE for the path computation for P2MP TE LSPs. >=20 > Section 6.1 >=20 > Was it a conscious decision to depart from RFC 8231 and inline objects in > the definition of (as opposed to keeping the > intermediate construction)? >=20 [[Dhruv Dhody]] Fixed Section 6.1 > When reporting the status of a P2MP TE LSP, the destinations MUST be > grouped in END-POINTS object based on the operational status (O field > in S2LS object) and leaf type (in END-POINTS). This way, leaves of > the same type that share the same operational status are grouped > together. [...] >=20 > Does this mean that it's an error for a PCRpt message to include more tha= n > one END-POINTS object with a given value of leaf-type? If so, it may be > worth stating that explicitly. [[Dhruv Dhody]] No, one can have more than one END-POINTS object with the s= ame leaf-type. There is no such restriction.=20 >=20 > Note that the compatibility with the [RFC8231] definition of report> is preserved. At least one instance of MUST be > present in this message for P2MP LSP. >=20 > Interestingly, RFC 8231 does not spell the structure of the PCRpt message > using an object. >=20 > Section 6.2 >=20 > Note that the compatibility with the [RFC8231] definition of request> is preserved. >=20 > If I'm reading this right, compatibility is only preserved when POINTS> is omitted (and the list only has a single endpoint/path pair). > Perhaps some more text could be added about the nature of the provided > (and needed) compatibility? >=20 [[Dhruv Dhody]] The compatibility is in the fact that a P2P TE LSP encoded = as per RFC8231, would pass the above RBNF check. The same wording is used i= n RFC 8306 (section 3.4).=20 > Section 6.6.2 >=20 > The LSP State Report message is sent by a PCC to report or delegate > the P2MP TE LSPs. An example of a PCRpt message for a delegated P2MP > TE LSPs is described below to add new leaves to an existing P2MP TE >=20 > nit: "TE LSP" >=20 > It might be handy to mention inline "for leaf type 1 (add)" and "leaf typ= e > 2 (remove)" just to refresh the reader's memory. >=20 [[Dhruv Dhody]] I have added this instead -=20 The leaves of the P2MP TE LSP are grouped in the END-POINTS object based on the operational status and the leaf-type. > Section 7.1 >=20 > The flags defined in this section (N, F, E flags) are used in PCRpt, > PCUpd, or PCInitiate message. In case of PCReq and PCRep message, > these flags have no meaning and thus MUST be ignored. The > corresponding flags in the RP (Request Parameters) object are used as > described in [RFC8231]. >=20 > I'm not really finding much discussion of RP flags in RFC 8231 (as oppose= d > to SRP, in Section 7.2 thereof). RFC 5440 does define a few flags for th= e > RP object, though. >=20 [[Dhruv Dhody]] It should be RFC8306, thanks for spotting this mixup.=20 > Section 7.2 >=20 > I strongly suggest changing the initial language to make it clear that > there is not a single P2MP-LSP-IDENTIFIER TLV, but rather a class of two > related TLVs that serve to identify P2MP LSPs, e.g., by referring to "P2M= P > LSP Identification TLVs" (without hyphenation or all-caps). >=20 [[Dhruv Dhody]] I want to avoid making this change to remain consistent wit= h RFC8231 (Section 7.3.1. LSP-IDENTIFIERS TLVs) but I have added clarifying= text (see DISCUSS). >=20 > The P2MP-LSP-IDENTIFIERS TLV MAY be included in the LSP object in the > PCUpd message for P2MP TE LSPs. The special value of all zeros for > this TLV is used to refer to all paths pertaining to a particular > PLSP-ID. >=20 > Given that we haven't specialized into the IP version-specific TLVs yet, = I > agree with the previous comments that we need greater clarity on what the > "value of all zeros" means, here. Additionally, is that special value > supposed to be restricted to the given IP version or literally all paths, > so that there are two functionally equivalent encodings for these > semantics? >=20 [[Dhruv Dhody]] Updated text is -=20 7.1.1. P2MP-LSP-IDENTIFIERS TLV [RFC8231] specify the LSP-IDENTIFIERS TLVs to be included in the LSP object. For P2MP TE LSP, this document defines P2MP-LSP-IDENTIFIERS TLVs for the LSP object. There are two P2MP-LSP-IDENTIFIERS TLVs, one for IPv4 and one for IPv6. The P2MP-LSP-IDENTIFIERS TLV MUST be included in the LSP object in PCRpt message for P2MP TE LSPs. If the N bit is set in the LSP object in the PCRpt message but the P2MP-LSP- IDENTIFIER TLV is absent, the PCE MUST respond with a PCErr message carrying error-type 6 ("mandatory object missing") and error-value 14 (early allocated by IANA) ("P2MP-LSP-IDENTIFIER TLV missing") and close the PCEP session. The P2MP-LSP-IDENTIFIERS TLV MAY be included in the LSP object in the PCUpd message for P2MP TE LSPs. The special value of all zeros for all the fields in the value portion of the TLV is used to refer to all paths pertaining to a particular PLSP-ID. The length of the TLV remains fixed based on the IP version. Since I have moved the text introducing the two TLVs to the first para, I h= ope this is enough to clear up any confusion. =20 Thanks again for your detailed review.=20 Thanks!=20 Dhruv From nobody Wed Apr 10 00:47:33 2019 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 39BFE12013C; Wed, 10 Apr 2019 00:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLDEWOwXBS3z; Wed, 10 Apr 2019 00:47:27 -0700 (PDT) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0884A12012A; Wed, 10 Apr 2019 00:47:26 -0700 (PDT) Received: from mxct.zte.com.cn (unknown [192.168.164.217]) by Forcepoint Email with ESMTPS id 0948CFA1ED6F93DAE370; Wed, 10 Apr 2019 15:47:25 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Forcepoint Email with ESMTPS id E620E8E4891A938B259A; Wed, 10 Apr 2019 15:47:24 +0800 (CST) Received: from njxapp03.zte.com.cn ([10.41.132.202]) by mse01.zte.com.cn with SMTP id x3A7lKnV034845; Wed, 10 Apr 2019 15:47:20 +0800 (GMT-8) (envelope-from xiong.quan@zte.com.cn) Received: from mapi (njxapp05[null]) by mapi (Zmail) with MAPI id mid201; Wed, 10 Apr 2019 15:47:21 +0800 (CST) Date: Wed, 10 Apr 2019 15:47:21 +0800 (CST) X-Zmail-TransId: 2afd5cad9f8978527182 X-Mailer: Zmail v1.0 Message-ID: <201904101547214513821@zte.com.cn> In-Reply-To: <3e5c5691-856c-4cbe-d0ed-4e83a62569cd@pi.nu> References: 3e5c5691-856c-4cbe-d0ed-4e83a62569cd@pi.nu Mime-Version: 1.0 From: To: Cc: , , Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse01.zte.com.cn x3A7lKnV034845 Archived-At: Subject: [Pce] =?utf-8?b?562U5aSNOiBTUi1NUExTLVRQOiBRdWVzdGlvbiBvbiBkcmFm?= =?utf-8?q?t-xiong-pce-pcep-extension-sr-tp?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 07:47:31 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgTG9hLA0KDQoNCg0KDQoNCg0KVGhhbmtzIGZvciB5b3VyIHJldmlldyBhbmQgaW5zcGlyZWQg Y29tbWVudCEgSXQgaXMgdmVyeSBpbXBvcnRhbnQgYW5kIG11Y2ggYXBwcmVjaWF0ZWQuDQoNCg0K DQoNCg0KUmVmZXIgdG8geW91ciBxdWVzdGlvbiwgd2UgcHJvcG9zZWQgdGhlIHRlcm1pbm9sb2d5 IG9mIHRoZSAiU1ItTVBMUy1UUCIgaW4gdGhlIGZvbGxvd2luZyB1c2UgY2FzZSBkcmFmdC4NCg0K aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaHUtbXBscy1zci1pbnRlci1k b21haW4tdXNlLWNhc2VzLyANCg0KDQoNCg0KV2UgcGxhbiB0byB3b3JrIG9uIHRoZSBkZWZpbml0 aW9uIGFuZCBzY29wZSBvZiBTUi1NUExTLVRQIGFuZCBzdGFydCBkaXNjdXNzaW9uIGluIE1QTFMg YW5kIFNQUklORyB3b3JraW5nIGdyb3VwIG5leHQgd2Vlay4NCg0KDQpXZWxjb21lIHRvIHJldmll dyBhbmQgZGlzY3VzcyBhYm91dCB0aGF0IGRyYWZ0IGFuZCBwcm92aWRlIHN1Z2dlc3Rpb25zIGZv ciBTUi1NUExTLVRQIQ0KDQoNCg0KDQpCZXN0IFJlZ2FyZHMsDQoNClF1YW4NCg0KDQoNCg0KDQoN Cg0KDQoNCuWOn+Wni+mCruS7tg0KDQoNCg0K5Y+R5Lu25Lq677yaTG9hQW5kZXJzc29uIDxsb2FA cGkubnU+DQrmlLbku7bkurrvvJpwY2VAaWV0Zi5vcmcgPHBjZUBpZXRmLm9yZz47ZHJhZnQteGlv bmctcGNlLXBjZXAtZXh0ZW5zaW9uLXNyLXRwQGlldGYub3JnIDxkcmFmdC14aW9uZy1wY2UtcGNl cC1leHRlbnNpb24tc3ItdHBAaWV0Zi5vcmc+Ow0K5pelIOacnyDvvJoyMDE55bm0MDTmnIgxMOaX pSAwMzo1NQ0K5Li7IOmimCDvvJpTUi1NUExTLVRQOiBRdWVzdGlvbiBvbiBkcmFmdC14aW9uZy1w Y2UtcGNlcC1leHRlbnNpb24tc3ItdHANCg0KDQpBdXRob3JzLCBXb3JraW5nIEdyb3VwLA0KDQpN UExTLVRQIGlzIGRlZmluZWQgYXMgYSBuZXR3b3JrIHRoYXQ6DQoNCiAgICJJdCBNVVNUIGJlIHBv c3NpYmxlIHRvIG9wZXJhdGUgYW5kIGNvbmZpZ3VyZSB0aGUgTVBMUy1UUCBkYXRhDQogICAgcGxh bmUgd2l0aG91dCBhbnkgSVAgZm9yd2FyZGluZyBjYXBhYmlsaXR5IGluIHRoZSBNUExTLVRQIGRh dGENCiAgICBwbGFuZS4gKFJGQyA1NjU0LCBzZWN0aW9uIDIuMywgcmVxdWlyZW1lbnQgMzYuKSIN Cg0KICAgIC4uLg0KDQogICJJdCBNVVNUIGJlIHBvc3NpYmxlIHRvIHByb3ZpZGUgcHJvdGVjdGlv biBmb3IgdGhlIE1QTFMtVFAgZGF0YQ0KICAgcGxhbmUgd2l0aG91dCBhbnkgSVAgZm9yd2FyZGlu ZyBjYXBhYmlsaXR5IGluIHRoZSBNUExTLVRQIGRhdGENCiAgIHBsYW5lLiAoUkZDIDU2NTQsIHNl Y3Rpb24gMi41LjEuMSwgcmVxdWlyZW1lbnQgNjMuKSINCg0KSW4gZmFjdCBtb3N0IE1QTFMtVFAg bmV0d29ya3MgYXJlIGRlcGxveWVkIHdpdGhvdXQgSVAgaW4gdGhlIGRhdGENCnBsYW5lLg0KDQpT Ui1NUExTIG9uIHRoZSBvdGhlciBoYW5kIGlzIGEgdGVjaG5vbG9neSB0aGF0IGlzIGRlZmluZWQg dG8gVVNFDQpJR1BzIHRvIGRpc3RyaWJ1dGUgTVBMUy1sYWJlbHMsIGFuZCB0aHVzIHJlcXVpcmVz IElQIGluIHRoZSBkYXRhDQpwbGFuZS4NCg0KUENFUCBhbHNvIHJ1bnMgb3ZlciBUQ1AvSVAuDQoN ClRoZSBkcmFmdCBkb2VzIG5vdCBkaXNjdXNzIHRoaXMuIEkgdGhpbmsgdGhpcyBpcyBuZWVkZWQs IGRvIHlvdQ0KaGF2ZSBwbGFucyB0byBkbyBzbz8NCg0KL0xvYQ0KLS0gDQoNCg0KTG9hIEFuZGVy c3NvbiAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOiBsb2FAcGkubnUNClNlbmlvciBNUExT IEV4cGVydA0KQnJvbnplIERyYWdvbiBDb25zdWx0aW5nICAgICAgICAgICAgIHBob25lOiArNDYg NzM5IDgxIDIxIDY0 --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZh bWlseTphcmlhbDsiPjxicj48L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToxNHB4O2ZvbnQtZmFtaWx5 OmFyaWFsOyI+SGkgTG9hLDwvcD48cCBzdHlsZT0iZm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6 YXJpYWw7Ij48YnI+PC9wPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZhbWlseTphcmlh bDsiPlRoYW5rcyBmb3IgeW91ciByZXZpZXcgYW5kJm5ic3A7aW5zcGlyZWQgY29tbWVudCEmbmJz cDs8c3BhbiBzdHlsZT0ibGluZS1oZWlnaHQ6IDIxcHg7Ij5JdCZuYnNwO2lzJm5ic3A7dmVyeSZu YnNwO2ltcG9ydGFudCZuYnNwO2FuZCBtdWNoJm5ic3A7YXBwcmVjaWF0ZWQuPC9zcGFuPjwvcD48 cCBzdHlsZT0iZm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6YXJpYWw7Ij48c3BhbiBzdHlsZT0i bGluZS1oZWlnaHQ6IDIxcHg7Ij48YnI+PC9zcGFuPjwvcD48cD5SZWZlciB0byB5b3VyJm5ic3A7 cXVlc3Rpb24sIHdlIHByb3Bvc2VkIHRoZSZuYnNwO3Rlcm1pbm9sb2d5IG9mIHRoZSAiU1ItTVBM Uy1UUCIgaW4gdGhlIGZvbGxvd2luZyB1c2UgY2FzZSBkcmFmdC48L3A+PHA+PGEgaHJlZj0iaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaHUtbXBscy1zci1pbnRlci1kb21h aW4tdXNlLWNhc2VzLyI+PC9hPjxhIHRhcmdldD0iX2JsYW5rIiBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1odS1tcGxzLXNyLWludGVyLWRvbWFpbi11c2UtY2Fz ZXMvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1odS1tcGxzLXNyLWlu dGVyLWRvbWFpbi11c2UtY2FzZXMvPC9hPiA8L3A+PHA+PGJyPjwvcD48cD5XZSBwbGFuIHRvIHdv cmsgb24gdGhlIGRlZmluaXRpb24gYW5kIHNjb3BlIG9mIFNSLU1QTFMtVFAgYW5kIHN0YXJ0IGRp c2N1c3Npb24gaW4gTVBMUyBhbmQgU1BSSU5HIHdvcmtpbmcgZ3JvdXAgbmV4dCB3ZWVrLjxicj48 L3A+PHA+V2VsY29tZSB0byByZXZpZXcgYW5kIGRpc2N1c3MgYWJvdXQgdGhhdCBkcmFmdCBhbmQg cHJvdmlkZSBzdWdnZXN0aW9ucyBmb3IgU1ItTVBMUy1UUCE8L3A+PHA+PGJyPjwvcD48cD5CZXN0 IFJlZ2FyZHMsPC9wPjxwPlF1YW48L3A+PHA+PGJyPjwvcD48cD48YnI+PC9wPjxkaXY+PGRpdiBj bGFzcz0iemhpc3RvcnlSb3ciIHN0eWxlPSJkaXNwbGF5OmJsb2NrIj48ZGl2IGNsYXNzPSJ6aGlz dG9yeURlcyIgc3R5bGU9IndpZHRoOiAxMDAlOyBoZWlnaHQ6IDI4cHg7IGxpbmUtaGVpZ2h0OiAy OHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiAjRTBFNUU5OyBjb2xvcjogIzEzODhGRjsgdGV4dC1hbGln bjogY2VudGVyOyIgbGFuZ3VhZ2UtZGF0YT0iSGlzdG9yeU9yZ1R4dCI+5Y6f5aeL6YKu5Lu2PC9k aXY+PGRpdiBpZD0iendyaXRlSGlzdG9yeUNvbnRhaW5lciI+PGRpdiBjbGFzcz0iY29udHJvbC1n cm91cCB6aGlzdG9yeVBhbmVsIj48ZGl2IGNsYXNzPSJ6aGlzdG9yeUhlYWRlciIgc3R5bGU9InBh ZGRpbmc6IDhweDsgYmFja2dyb3VuZC1jb2xvcjogI0Y1RjZGODsiPjxkaXY+PHN0cm9uZyBsYW5n dWFnZS1kYXRhPSJIaXN0b3J5U2VuZGVyVHh0Ij7lj5Hku7bkurrvvJo8L3N0cm9uZz48c3BhbiBj bGFzcz0ienJlYWRVc2VyTmFtZSI+TG9hQW5kZXJzc29uICZsdDtsb2FAcGkubnUmZ3Q7PC9zcGFu PjwvZGl2PjxkaXY+PHN0cm9uZyBsYW5ndWFnZS1kYXRhPSJIaXN0b3J5VE9UeHQiPuaUtuS7tuS6 uu+8mjwvc3Ryb25nPjxzcGFuIGNsYXNzPSJ6cmVhZFVzZXJOYW1lIiBzdHlsZT0iZGlzcGxheTog aW5saW5lOyI+cGNlQGlldGYub3JnICZsdDtwY2VAaWV0Zi5vcmcmZ3Q7Ozwvc3Bhbj48c3BhbiBj bGFzcz0ienJlYWRVc2VyTmFtZSIgc3R5bGU9ImRpc3BsYXk6IGlubGluZTsiPmRyYWZ0LXhpb25n LXBjZS1wY2VwLWV4dGVuc2lvbi1zci10cEBpZXRmLm9yZyAmbHQ7ZHJhZnQteGlvbmctcGNlLXBj ZXAtZXh0ZW5zaW9uLXNyLXRwQGlldGYub3JnJmd0Ozs8L3NwYW4+PC9kaXY+PGRpdj48c3Ryb25n IGxhbmd1YWdlLWRhdGE9Ikhpc3RvcnlEYXRlVHh0Ij7ml6Ug5pyfIO+8mjwvc3Ryb25nPjxzcGFu IGNsYXNzPSIiPjIwMTnlubQwNOaciDEw5pelIDAzOjU1PC9zcGFuPjwvZGl2PjxkaXY+PHN0cm9u ZyBsYW5ndWFnZS1kYXRhPSJIaXN0b3J5U3ViamVjdFR4dCI+5Li7IOmimCDvvJo8L3N0cm9uZz48 c3BhbiBjbGFzcz0ienJlYWRUaXRsZSI+PHN0cm9uZz5TUi1NUExTLVRQOiBRdWVzdGlvbiBvbiBk cmFmdC14aW9uZy1wY2UtcGNlcC1leHRlbnNpb24tc3ItdHA8L3N0cm9uZz48L3NwYW4+PC9kaXY+ PC9kaXY+PGRpdiBjbGFzcz0iemhpc3RvcnlDb250ZW50Ij48ZGl2PkF1dGhvcnMsJm5ic3A7V29y a2luZyZuYnNwO0dyb3VwLDxicj48YnI+TVBMUy1UUCZuYnNwO2lzJm5ic3A7ZGVmaW5lZCZuYnNw O2FzJm5ic3A7YSZuYnNwO25ldHdvcmsmbmJzcDt0aGF0Ojxicj48YnI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Ikl0Jm5ic3A7TVVTVCZuYnNwO2JlJm5ic3A7cG9zc2libGUmbmJzcDt0byZuYnNwO29wZXJh dGUmbmJzcDthbmQmbmJzcDtjb25maWd1cmUmbmJzcDt0aGUmbmJzcDtNUExTLVRQJm5ic3A7ZGF0 YTxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwbGFuZSZuYnNwO3dpdGhvdXQmbmJzcDthbnkm bmJzcDtJUCZuYnNwO2ZvcndhcmRpbmcmbmJzcDtjYXBhYmlsaXR5Jm5ic3A7aW4mbmJzcDt0aGUm bmJzcDtNUExTLVRQJm5ic3A7ZGF0YTxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwbGFuZS4m bmJzcDsoUkZDJm5ic3A7NTY1NCwmbmJzcDtzZWN0aW9uJm5ic3A7Mi4zLCZuYnNwO3JlcXVpcmVt ZW50Jm5ic3A7MzYuKSI8YnI+PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy4uLjxicj48YnI+ Jm5ic3A7Jm5ic3A7Ikl0Jm5ic3A7TVVTVCZuYnNwO2JlJm5ic3A7cG9zc2libGUmbmJzcDt0byZu YnNwO3Byb3ZpZGUmbmJzcDtwcm90ZWN0aW9uJm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7TVBMUy1U UCZuYnNwO2RhdGE8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7cGxhbmUmbmJzcDt3aXRob3V0Jm5ic3A7 YW55Jm5ic3A7SVAmbmJzcDtmb3J3YXJkaW5nJm5ic3A7Y2FwYWJpbGl0eSZuYnNwO2luJm5ic3A7 dGhlJm5ic3A7TVBMUy1UUCZuYnNwO2RhdGE8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7cGxhbmUuJm5i c3A7KFJGQyZuYnNwOzU2NTQsJm5ic3A7c2VjdGlvbiZuYnNwOzIuNS4xLjEsJm5ic3A7cmVxdWly ZW1lbnQmbmJzcDs2My4pIjxicj48YnI+SW4mbmJzcDtmYWN0Jm5ic3A7bW9zdCZuYnNwO01QTFMt VFAmbmJzcDtuZXR3b3JrcyZuYnNwO2FyZSZuYnNwO2RlcGxveWVkJm5ic3A7d2l0aG91dCZuYnNw O0lQJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtkYXRhPGJyPnBsYW5lLjxicj48YnI+U1ItTVBMUyZu YnNwO29uJm5ic3A7dGhlJm5ic3A7b3RoZXImbmJzcDtoYW5kJm5ic3A7aXMmbmJzcDthJm5ic3A7 dGVjaG5vbG9neSZuYnNwO3RoYXQmbmJzcDtpcyZuYnNwO2RlZmluZWQmbmJzcDt0byZuYnNwO1VT RTxicj5JR1BzJm5ic3A7dG8mbmJzcDtkaXN0cmlidXRlJm5ic3A7TVBMUy1sYWJlbHMsJm5ic3A7 YW5kJm5ic3A7dGh1cyZuYnNwO3JlcXVpcmVzJm5ic3A7SVAmbmJzcDtpbiZuYnNwO3RoZSZuYnNw O2RhdGE8YnI+cGxhbmUuPGJyPjxicj5QQ0VQJm5ic3A7YWxzbyZuYnNwO3J1bnMmbmJzcDtvdmVy Jm5ic3A7VENQL0lQLjxicj48YnI+VGhlJm5ic3A7ZHJhZnQmbmJzcDtkb2VzJm5ic3A7bm90Jm5i c3A7ZGlzY3VzcyZuYnNwO3RoaXMuJm5ic3A7SSZuYnNwO3RoaW5rJm5ic3A7dGhpcyZuYnNwO2lz Jm5ic3A7bmVlZGVkLCZuYnNwO2RvJm5ic3A7eW91PGJyPmhhdmUmbmJzcDtwbGFucyZuYnNwO3Rv Jm5ic3A7ZG8mbmJzcDtzbz88YnI+PGJyPi9Mb2E8YnI+LS0mbmJzcDs8YnI+PGJyPjxicj5Mb2Em bmJzcDtBbmRlcnNzb24mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtlbWFpbDombmJzcDts b2FAcGkubnU8YnI+U2VuaW9yJm5ic3A7TVBMUyZuYnNwO0V4cGVydDxicj5Ccm9uemUmbmJzcDtE cmFnb24mbmJzcDtDb25zdWx0aW5nJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cGhvbmU6Jm5ic3A7KzQ2 Jm5ic3A7NzM5Jm5ic3A7ODEmbmJzcDsyMSZuYnNwOzY0PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+ PC9kaXY+PC9kaXY+PHA+PGJyPjwvcD48L2Rpdj4= --=====_003_next=====-- --=====_002_next=====-- --=====_001_next=====-- From nobody Wed Apr 10 03:26:51 2019 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 BEAD21200E6; Wed, 10 Apr 2019 03:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5z7fEfi0IyrL; Wed, 10 Apr 2019 03:26:40 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F690120099; Wed, 10 Apr 2019 03:26:40 -0700 (PDT) Received: from [172.22.5.136] (unknown [46.218.58.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 2EAD533F5AF; Wed, 10 Apr 2019 12:26:38 +0200 (CEST) To: xiong.quan@zte.com.cn Cc: pce@ietf.org, draft-xiong-pce-pcep-extension-sr-tp@ietf.org, gregory.mirsky@ztetx.com, "mpls@ietf.org" , "spring@ietf.org" References: <201904101547214513821@zte.com.cn> From: Loa Andersson Message-ID: Date: Wed, 10 Apr 2019 12:26:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <201904101547214513821@zte.com.cn> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Pce] =?utf-8?b?562U5aSNOiBTUi1NUExTLVRQOiBRdWVzdGlvbiBvbiBkcmFm?= =?utf-8?q?t-xiong-pce-pcep-extension-sr-tp?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 10:26:43 -0000 Quan, I think you are right that this discussion will be of interest for the SPRING and MPLS working group. I have copied the working group mailing lists. On 2019-04-10 09:47, xiong.quan@zte.com.cn wrote: > > Hi Loa, > > > Thanks for your review and inspired comment! It is very important and > much appreciated. > > > Refer to your question, we proposed the terminology of the "SR-MPLS-TP" > in the following use case draft. > > https://datatracker.ietf.org/doc/draft-hu-mpls-sr-inter-domain-use-cases/ > > > > We plan to work on the definition and scope of SR-MPLS-TP and start > discussion in MPLS and SPRING working group next week. > > Welcome to review and discuss about that draft and provide suggestions > for SR-MPLS-TP! > > > Best Regards, > > Quan > > > > 原始邮件 > *发件人：*LoaAndersson > *收件人：*pce@ietf.org > ;draft-xiong-pce-pcep-extension-sr-tp@ietf.org > ; > *日 期 ：*2019年04月10日 03:55 > *主 题 ：**SR-MPLS-TP: Question on draft-xiong-pce-pcep-extension-sr-tp* > Authors, Working Group, > > MPLS-TP is defined as a network that: > >    "It MUST be possible to operate and configure the MPLS-TP data >     plane without any IP forwarding capability in the MPLS-TP data >     plane. (RFC 5654, section 2.3, requirement 36.)" > >     ... > >   "It MUST be possible to provide protection for the MPLS-TP data >    plane without any IP forwarding capability in the MPLS-TP data >    plane. (RFC 5654, section 2.5.1.1, requirement 63.)" > > In fact most MPLS-TP networks are deployed without IP in the data > plane. > > SR-MPLS on the other hand is a technology that is defined to USE > IGPs to distribute MPLS-labels, and thus requires IP in the data > plane. > > PCEP also runs over TCP/IP. > > The draft does not discuss this. I think this is needed, do you > have plans to do so? > > /Loa > -- > > > Loa Andersson                        email: loa@pi.nu > Senior MPLS Expert > Bronze Dragon Consulting             phone: +46 739 81 21 64 > > -- Loa Andersson email: loa@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Wed Apr 10 05:47:41 2019 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8957912038D; Wed, 10 Apr 2019 05:47:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Elwyn Davies via Datatracker To: Cc: draft-ietf-pce-gmpls-pcep-extensions.all@ietf.org, pce@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Elwyn Davies Message-ID: <155490045947.22938.5359257333272095316@ietfa.amsl.com> Date: Wed, 10 Apr 2019 05:47:39 -0700 Archived-At: Subject: [Pce] Genart telechat review of draft-ietf-pce-gmpls-pcep-extensions-14 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 12:47:40 -0000 Reviewer: Elwyn Davies Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-pce-gmpls-pcep-extensions-14 Reviewer: Elwyn Davies Review Date: 2019-04-10 IETF LC End Date: 2018-10-29 IESG Telechat date: 2019-04-11 Summary: Almost ready, but with a large collection of nits in language and non-expansion of abbreviations. I am also concerned about the specification of behaviour in case PCC/PCEs with and without the extensions attempt to interact. The requirements and behaviour are rather woolly, and are not fully covered by capability negotiations as the negotation capability itself is not in the original PCEP specification. Major issues: None Minor issues: Interacting with PCCs that do not support these GMPLS extensions: The draft is not very clear on interactions between PCCs that do support the extensions and ones that do not. It is unclear whether a PCC that proposes to use the extensions must support the RFC 5088 or 5089 capability negotiation extensions and use them to determine if a PCEP exchange can use the extensions. The text in para 1 of s2.1.2 appears to require that a node that does not support RFC 5088 or 5089 still has to understand that it has received the GMPLS-CAPABILITY type indicator and indicate a mismatch. It seems to me that some additional explanation is needed to describe how mismatched PCC/PCEs understand the problem and deal with cases where a message with the new extensions is received (and presumably rejected) by a node that does not implement the extensions. s9.2, RFC7025: Given the references to the requirements document for this work, I would consider RFC 7025 to be normative. Nits/editorial comments: General: s/e.g. /e.g., /g Abstract: s/The Path Computation Element (PCE)/A Path Computation Element (PCE)/ s1: Expand abbreviations OTN (Optical Transport Networks) and WSON (Wavelength Switched Optical Networks). s1, para 2: s/considered/addressed/, s/those application/these applications/ s1.2, para 1: s/PCEP extension/PCEP extensions/, s/broken down in/broken down into/ s1.2: Expand following acronyms/abbreviations on first occurrence: LSP, TE-LSP, L2SC, TDM, SONET, SDH, LSC [Query: Is LSC different from L2SC?], PCC, ERO s1.2, bullet 2: A reference for the G.709 standard is needed. s1.2 and s1.3.1, items (4) and (5): There doesn't seem to be a definition of Concatenation Number in any of the documents mentioned here or anywhere on the web. I suspect it is supposed to be the number of streams that are concatenated but this needs to be properly defined or a reference provided. s1.2, bullet 5: s/Label restriction/label restriction/. I take it this refers to the use of Label Set objects as described in RFC 3473. If so please add a reference. If not lease provide the appropriate reference. s1.3.1: Expand following acronyms/abbreviations on first occurrence: TE-LSP, ODU, IRO, XRO, RRO, LSPA s1.3.1, item (4): s/Its scoped/It is scoped/ [English language note: 'Its' is the possessive pronoun derived from the third person singular impersonal pronoun 'it', whereas "It's" is a contraction of 'it is' that is not normally used in formal documents.] s1.3.1, item (4): > related to the BANDWIDTH object in MPLS networks I assume this relates to the BANDWIDTH object in RFC 5440 - please add a reference. s1.3.2, item (1): The previous two comments on s.1.3.1, item (4) apply also to this item. s1.4: OLD: 1.4 GMPLS Support and Limitation of Base PCEP Objects The support for requirements [RFC7025] is summarized in Table 1 and Table 2 NEW: 1.4 Existng Support for GMPLS in Base PCEP Objects and its Limitations The support provided by specifications in [RFC8282] and [RFC5440] for the requirements listed in [RFC7025] is summarized in Table 1 and Table 2. In some cases the support may not be complete, as noted, and additional support need to be provided in this specification. ENDS s1.4, RFC 5440 bullets, ERO: A reference for the RSVP specification covering ERO is needed. s1.4, XRO object. 1st bullet: Expand SRLG. s1.4, SWITCH-LAYER bullet: s/address/addresses/ s1.4, list of coverage gaps: Expand NVC. s1.4, added functionality needed: s/to cover the gap/to cover the gaps/ s2: Expand PCReq and PCRep message names to reflect names in RFC 5440. s2.1.2: > Moreover, in case that the PCC does not receive the > GMPLS-CAPABILITY TLV it is RECOMMENDED that the PCC does not make use > of the objects and TLVs defined in this document. I would have thought this ought to have been a MUST (when communicating with the PCC that didn't support the extensions. s2.1.2: s/OPEN message/Open message/ in (at least) 3 places - for consistency and to match RFC 5440 s2.1.2, GMPS-CAPABILITY TLV spec > IANA has allocated value TBA-1 from the "PCEP TLV Type Indicators" > sub-registry, as documented in Section 5.3 ("New PCEP TLVs"). The > description is "GMPLS-CAPABILITY". Its format is shown in the > following figure. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type=14 | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Flags | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Should 'Type=14' in the diagram be 'Type=TBA-1'? s2.2: > Depending > on policies or switching layer, it can be necessary for the PCC to > use explicit label control or expect explicit link, ^^^^^^^^^^^^^^^^^^^^^^^ I cannot parse the marked phrase 'or expect explicit link'. Please clarify. s2.2, next to last para: s/requested route granularity/requested routing granularity/ s2.3, para 1: s/to allow to express/to allow the object to express/, s/set of encoding/set of encodings/ s2.3, para at top of page 12: s/The Bw Spec Type correspond to/The Bw Spec Type corresponds to/ s2.3, Table 4:Expand MEF, SSON on first occurrence. s2.3, next to last para: OLD: The Object Type TBA-3 MAY be used instead of object type 2 to indicate the existing TE-LSP bandwidth. A PCC that requested a path with a BANDWIDTH object of object type 1 SHOULD use object type 2 to represent the existing TE-LSP BANDWIDTH. NEW: The Object Type TBA-3 MAY be used instead of the previously specified object type 2 to indicate the existing TE-LSP bandwidth originally specified with object type TBA-2. A PCC that requested a path with a BANDWIDTH object of object type 1 SHOULD use object type 2 to represent the existing TE-LSP BANDWIDTH. ENDS It is not clear to me why this is a SHOULD and not a MUST. s2.4, para below the format: s/MAY also include TLV different from the PCEP TLVs./MAY also include TLVs different from the basic PCEP TLVs./ s2.4, para at top of page 14: > The encoding of the fields Min Bandwidth Spec and Min Reverse > Bandwidth Spec is the same as in RSVP-TE SENDER_TSPEC object, it can > be found in Table 4 from Section 2.3. Might be helpful to add (after Section 2.3) 'of this document' - the use of RSVP-TE immediately before this got me thinking this is in some RSVP-TE document. s2.5, last bullet on page 14: s/constraints in/constraints on/ s2.5.1, para 7 (one after bullet #5): s/This TLVs express/These TLVs express/ (probably, but could be 'This TLV expresses' as I think this applies to just the Label set TLV.) s2.5.1, para 7: s/label set allows to indicate which label/label set allows indication of which labels/ s2.5.1, para 7: s/restricting then in GMPLS the possible label ranges on the interface/consequently restricting the possible label ranges on the interface in GMPLS/ s2.5.1: Expand P2MP on first occurrence. s2.5.1, para after Table 5: s/Value TBD/Value TBA-14/ s2.5.1, page 17, para after generalized-endpoint-tlvs grammar: Suggest OLD: For endpoint type Point-to-Multipoint, several endpoint objects MAY be present in the message and each represents a leave, exact meaning depend on the endpoint type defined of the object. NEW: For endpoint type Point-to-Multipoint, several endpoint objects MAY be present in the message and each represents a leaf of the P2MP tree, with the exact meaning depending on the endpoint type defined for the object. ENDS s2.5.1, last para on page 17: For consistency, the (new) vlaue of the Type 4 error should be specified here (TBA-15, i think). s2.5.2.x, last para in each case: s/responded/returned/ s2.5.2.3, para 1 s/as follow/as follows/ s2.5.2.4, paa 1: s/The LABEL-REQUEST TLV use/The LABEL-REQUEST TLV uses/ s2.5.2.4, para 1: Suggest using fully expanded name of G-PID - Generalized Payload Identifier. s2.5.2.4, para 2: Suggest adding reference(s) for where the definitions of Tspec and FlowSpec can be found. s2.5.2.5, para 1: s/Those TLV/These TLVs/, s/responded/returned/, s/as follow/as follows/ s2.5.2.5, first bullet: s/set of label/set of labels/ s2.5.2.5, para after diagram: s/Those parameters/These parameters/ s2.5.2.5: There are two more or less equivalent descriptions of the functions of the U, O and L flag bits. For avadance of error, it would be better if the first summary was removed and the reader referred to the full description after the diagram. This would mean adding the text 'following the semantic of SUGGESTED_LABEL defined by [RFC3471]' to the full description. s2.5.2.5, last para on page 20: > At most 2 LABEL_SET TLVs MUST be present with > the O bit set, at most one with the U bit set and at most one with > the U bit cleared. Since all LABEL_SET TLVs contain a U bit field, I read the above text as limiting the number of LABEL_SETs to two (it isn't clear that the U constraint is a sub-constraint after the O constraint). I think what is meant is > At most 2 LABEL_SET TLVs MAY be present with > the O bit set, with at most one of these having the U bit set and > at most one of these having the U bit cleared. s2.5.2.5, last 3 paras: For consistency the new error values TBA-x should be specified. s2.6, para 1: s/allows to include label definition/allows the inclusion of a label definition/ s2.7, para 1: s/allows to exclude labels/allows the exclusion of certan labels/ s2.7: More information about U, C-Type and Label is allegedly found in RFC 3471. I can't find a reference to C-Type in that document, and it is unclear which part of the document has the Label info. Is this a miatake? s2.8, para 1: s/fulfill/fulfil/ s2.8: Pointers to the relevant sections in RFC 4872 and 4873 would help. s2.9: s/The NO-PATH object MAY carries/The NO-PATH object MAY carry/, s/like/such as/, s/Few/Several/, s/and no/but no/ s3, para 1: s/few error/several error/, s/Error- values/Error-values/ s3, para 2: s/but not path found/but the PCe is unable to find a path/, s/NO-PATH is to be used/the NO-PATH error is to be used/ s4.1, last para: s/Those parameters configuration are/The configuration of the above parameters is/ s4.2: s/This document does not introduces new ERO sub object,/This document does not introduce any new ERO sub objects, so that the/ s4.4: s/should be covered by/should satisfy/ s5: It would be worth adding a note to IANA that TBA-11 is not used (assuming this is not a bug). s5.1 and s5.3: s/(section /(/ (removing duplicate word 'section') in several places s5.2, para 2: s/qualities/attributes/ s6, para 1: s/amount/volume/ s6, first bullet: s/The answer can make that the LSP traverses/The resulting LSP might be arranged to traverse/ s6, first bullet: s/the answer can omit/the rsulting LSP can omit/, s/the answer can lead to provide a LSP/the result can lead to the creation of an LSP/ From nobody Wed Apr 10 07:30:09 2019 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56699120021; Wed, 10 Apr 2019 07:30:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-pce-stateful-pce-p2mp@ietf.org, Adrian Farrel , pce-chairs@ietf.org, adrian@olddog.co.uk, pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <155490660734.22896.13528098840634992626.idtracker@ietfa.amsl.com> Date: Wed, 10 Apr 2019 07:30:07 -0700 Archived-At: Subject: [Pce] Roman Danyliw's Discuss on draft-ietf-pce-stateful-pce-p2mp-12: (with DISCUSS) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 14:30:07 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-pce-stateful-pce-p2mp-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-p2mp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The Security Considerations section has numerous helpful and appropriate references. Thanks for tracking them down. However, explicit, additional text is required to help identify, de-duplicate and deconflict the “relevant guidance” provided by them. (1) Per “it is important that implementations conform to the relevant security requirements of [RFC5440], [RFC8306] and [RFC8231], and [RFC8281]”: ** [RFC8231] says “RECOMMENDED that these PCEP extensions only be activated on authenticated and encrypted sessions across PCEs and PCCs belonging to the same administrative authority, using Transport Layer Security (TLS) [PCEPS], as per the recommendations and best current practices in [RFC7525]”. Good language. This draft again re-states “Securing the PCEP session using Transport Layer Security (TLS) [RFC8253], as per the recommendations and best current practices in [RFC7525], is RECOMMENDED.” Why say that twice? Is there something new there? ** Per Section 10.4 of RFC5440 from 2009, IPSec is a MAY and Section 10.2 makes TCP-MD5 a MUST. The more recent (2017) RFC8306 and RFC8253 reference TLS and TCP-AO, no IPSec. RFC8306 explicitly says don’t use TCP-MD5. What is the RECOMMENDED approach today? (2) Per “[s]ecuring the PCEP session using Transport Layer Security (TLS) [RFC8253], as per the recommendations and best current practices in [RFC7525], is RECOMMENDED”, how should the guidance on both of these drafts be synthesized? Specifically, this sentence is unclear on whether the the robust TLS 1.2 requirements in Section 3.4 of RFC8253 are RECOMMENDED, and/or whether the Security Considerations/Section 7 of RFC8253, which undermine these robust requirements by saying administrators MAY allow the usage weak ciphersuites, apply. This sentence also cites RFC7525 which makes statements that weak (NULL) cipher suites MUST NOT be negotiated in contradiction to the RFC8253 Section 7 guidance. Given the discussion of TLs, some additional treatment of TLS v1.3 is needed, recognizing that RFC7525 does recommend “v1.2+” Again, there is helpful guidance across all of the references. Please provide more textually narrative about which specific sections apply on the references. From nobody Wed Apr 10 10:07:50 2019 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF601200EB; Wed, 10 Apr 2019 10:07:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-pce-gmpls-pcep-extensions@ietf.org, Julien Meuric , pce-chairs@ietf.org, julien.meuric@orange.com, pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <155491606036.9448.18221638774778675073.idtracker@ietfa.amsl.com> Date: Wed, 10 Apr 2019 10:07:40 -0700 Archived-At: Subject: [Pce] Alissa Cooper's No Objection on draft-ietf-pce-gmpls-pcep-extensions-14: (with COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 17:07:41 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-pce-gmpls-pcep-extensions-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-pcep-extensions/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think Section 2.1.2 needs to better explain what happens when a PCC sends extensions but the recipient does not support them. Please respond to the Gen-ART review. From nobody Wed Apr 10 10:08:53 2019 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 80120120106; Wed, 10 Apr 2019 10:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=J+o6kROa; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Bvu8Q2Nd Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIbAKY3d9Rpg; Wed, 10 Apr 2019 10:08:37 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2A2F1200EB; Wed, 10 Apr 2019 10:08:36 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 1FE33213CA; Wed, 10 Apr 2019 13:08:36 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 10 Apr 2019 13:08:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=m FiejhroVlMm1QLGcAXOWywMv97hjpY3tYM0fb1Y/+Q=; b=J+o6kROaZocN3RPFf Jb6Z8OFqTjcZM2OSqfzMXhsDWmmYuW8TOlGg4TawKodIFUtLswDkvyG0Z0xuTYpV OJ/UPH/sPmxPK9r3fCviE3WCrpQY+mGxkihkIlxV2n5IdpJdye55GAih83xcozv8 UF1/ss8YvkuICejZqxQk9MW/iBcZiPnNSJZkHqvFUd7pJwQPMM6f0+vCXlaUs2dZ Z1ba/TtB+EWwfVVm8WFcLOnnlOKlD/N2AIhP/JIGYrdVd4cj0JiKmzI/fOmz+VFZ J8bUbO7koA8AgqfR5js4Yz9nuM8B7XkFJQrGNzfC8FQvWV/kQP8PN2wUvR0UUG9M dsg9A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=mFiejhroVlMm1QLGcAXOWywMv97hjpY3tYM0fb1Y/ +Q=; b=Bvu8Q2Ndz2sSS7Y1W0V7Bi9ERSpjo/K1fqNvFmYfC1CWKZYB71xmUNDcP 6DF5JBn8tI1meeDqwYvHKOBW6L9EMTYGA6WkCe9QbKNy/X0UokGbomdRVDicscZj g28qhRLIqkqi+AwelgOfitEKpsFv+Fh4D1bWu5dgQKGxpQ1NawPx+f51r/GcsWjz Wr3HfuTj1WQXYpURj7uEilY6z8T5upWjhbqs3R8A3DY2wwD/I8ybY+FKu0NucwwS nQZoOCQjj3SzUcOdivgHoR8TDlRRlfg7GAg+R/e5CNi0o+Rnk2DVT9DcoEck0sw+ wcDY82EUYfRxXXlc5ebUC+tJE+BxA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudejgdduudduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepihgvthhfrdhorhhgnecukfhppedujeefrdefkedruddujedrkeejnecurfgrrhgr mhepmhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhnnecuvehluhhsth gvrhfuihiivgeptd X-ME-Proxy: Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.87]) by mail.messagingengine.com (Postfix) with ESMTPA id 1D3DB10380; Wed, 10 Apr 2019 13:08:35 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <155490045947.22938.5359257333272095316@ietfa.amsl.com> Date: Wed, 10 Apr 2019 13:08:33 -0400 Cc: gen-art@ietf.org, draft-ietf-pce-gmpls-pcep-extensions.all@ietf.org, pce@ietf.org, ietf@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1BA0250E-16D7-4326-9247-2A4D7AA4C5E2@cooperw.in> References: <155490045947.22938.5359257333272095316@ietfa.amsl.com> To: Elwyn Davies X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Pce] [Gen-art] Genart telechat review of draft-ietf-pce-gmpls-pcep-extensions-14 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 17:08:41 -0000 Thanks Elwyn. I entered a No Objection ballot and pointed to your = review. Alissa > On Apr 10, 2019, at 8:47 AM, Elwyn Davies via Datatracker = wrote: >=20 > Reviewer: Elwyn Davies > Review result: Almost Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-pce-gmpls-pcep-extensions-14 > Reviewer: Elwyn Davies > Review Date: 2019-04-10 > IETF LC End Date: 2018-10-29 > IESG Telechat date: 2019-04-11 >=20 > Summary: > Almost ready, but with a large collection of nits in language and = non-expansion > of abbreviations. I am also concerned about the specification of = behaviour in > case PCC/PCEs with and without the extensions attempt to interact. = The > requirements and behaviour are rather woolly, and are not fully = covered by > capability negotiations as the negotation capability itself is not in = the > original PCEP specification. >=20 > Major issues: > None >=20 > Minor issues: > Interacting with PCCs that do not support these GMPLS extensions: The = draft is > not very clear on interactions between PCCs that do support the = extensions and > ones that do not. It is unclear whether a PCC that proposes to use = the > extensions must support the RFC 5088 or 5089 capability negotiation = extensions > and use them to determine if a PCEP exchange can use the extensions. = The text > in para 1 of s2.1.2 appears to require that a node that does not = support RFC > 5088 or 5089 still has to understand that it has received the = GMPLS-CAPABILITY > type indicator and indicate a mismatch. It seems to me that some = additional > explanation is needed to describe how mismatched PCC/PCEs understand = the > problem and deal with cases where a message with the new extensions is = received > (and presumably rejected) by a node that does not implement the = extensions. >=20 > s9.2, RFC7025: Given the references to the requirements document for = this work, > I would consider RFC 7025 to be normative. >=20 > Nits/editorial comments: > General: s/e.g. /e.g., /g >=20 > Abstract: s/The Path Computation Element (PCE)/A Path Computation = Element (PCE)/ >=20 > s1: Expand abbreviations OTN (Optical Transport Networks) and WSON = (Wavelength > Switched Optical Networks). >=20 > s1, para 2: s/considered/addressed/, s/those application/these = applications/ >=20 > s1.2, para 1: s/PCEP extension/PCEP extensions/, s/broken down = in/broken down > into/ >=20 > s1.2: Expand following acronyms/abbreviations on first occurrence: = LSP, TE-LSP, > L2SC, TDM, SONET, SDH, LSC [Query: Is LSC different from L2SC?], PCC, = ERO >=20 > s1.2, bullet 2: A reference for the G.709 standard is needed. >=20 > s1.2 and s1.3.1, items (4) and (5): There doesn't seem to be a = definition of > Concatenation Number in any of the documents mentioned here or = anywhere on the > web. I suspect it is supposed to be the number of streams that are > concatenated but this needs to be properly defined or a reference = provided. >=20 > s1.2, bullet 5: s/Label restriction/label restriction/. I take it = this refers > to the use of Label Set objects as described in RFC 3473. If so = please add a > reference. If not lease provide the appropriate reference. >=20 > s1.3.1: Expand following acronyms/abbreviations on first occurrence: = TE-LSP, > ODU, IRO, XRO, RRO, LSPA >=20 > s1.3.1, item (4): s/Its scoped/It is scoped/ [English language note: = 'Its' is > the possessive pronoun derived from the third person singular = impersonal > pronoun 'it', whereas "It's" is a contraction of 'it is' that is not = normally > used in formal documents.] >=20 > s1.3.1, item (4): >=20 >> related to the BANDWIDTH object in MPLS networks > I assume this relates to the BANDWIDTH object in RFC 5440 - please add = a > reference. >=20 > s1.3.2, item (1): The previous two comments on s.1.3.1, item (4) = apply also to > this item. >=20 > s1.4: >=20 > OLD: >=20 > 1.4 GMPLS Support and Limitation of Base PCEP Objects >=20 > The support for requirements [RFC7025] is summarized in Table 1 and > Table 2 >=20 > NEW: >=20 > 1.4 Existng Support for GMPLS in Base PCEP Objects and its = Limitations >=20 > The support provided by specifications in [RFC8282] and [RFC5440] = for the > requirements listed in [RFC7025] is summarized in Table 1 and Table = 2. In > some cases the support may not be complete, as noted, and additional = support > need to be provided in this specification. >=20 > ENDS >=20 > s1.4, RFC 5440 bullets, ERO: A reference for the RSVP specification = covering > ERO is needed. >=20 > s1.4, XRO object. 1st bullet: Expand SRLG. >=20 > s1.4, SWITCH-LAYER bullet: s/address/addresses/ >=20 > s1.4, list of coverage gaps: Expand NVC. >=20 > s1.4, added functionality needed: s/to cover the gap/to cover the = gaps/ >=20 > s2: Expand PCReq and PCRep message names to reflect names in RFC 5440. >=20 > s2.1.2: >=20 >> Moreover, in case that the PCC does not receive the >> GMPLS-CAPABILITY TLV it is RECOMMENDED that the PCC does not make = use >> of the objects and TLVs defined in this document. > I would have thought this ought to have been a MUST (when = communicating with > the PCC that didn't support the extensions. >=20 > s2.1.2: s/OPEN message/Open message/ in (at least) 3 places - for = consistency > and to match RFC 5440 >=20 > s2.1.2, GMPS-CAPABILITY TLV spec >=20 >> IANA has allocated value TBA-1 from the "PCEP TLV Type Indicators" >> sub-registry, as documented in Section 5.3 ("New PCEP TLVs"). The >> description is "GMPLS-CAPABILITY". Its format is shown in the >> following figure. >>=20 >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type=3D14 | Length = | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Flags | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Should 'Type=3D14' in the diagram be 'Type=3DTBA-1'? >=20 > s2.2: >=20 >> Depending >> on policies or switching layer, it can be necessary for the PCC to >> use explicit label control or expect explicit link, > = ^^^^^^^^^^^^^^^^^^^^^^^ >=20 > I cannot parse the marked phrase 'or expect explicit link'. Please = clarify. >=20 > s2.2, next to last para: s/requested route granularity/requested = routing > granularity/ >=20 > s2.3, para 1: s/to allow to express/to allow the object to express/, = s/set of > encoding/set of encodings/ >=20 > s2.3, para at top of page 12: s/The Bw Spec Type correspond to/The Bw = Spec Type > corresponds to/ >=20 > s2.3, Table 4:Expand MEF, SSON on first occurrence. >=20 > s2.3, next to last para: >=20 > OLD: >=20 > The Object Type TBA-3 MAY be used instead of object type 2 > to indicate the existing TE-LSP bandwidth. A PCC that requested a > path with a BANDWIDTH object of object type 1 SHOULD use object type > 2 to represent the existing TE-LSP BANDWIDTH. >=20 > NEW: >=20 > The Object Type TBA-3 MAY be used instead of the previously = specified object > type 2 to indicate the existing TE-LSP bandwidth originally = specified with > object type TBA-2. A PCC that requested a path with a BANDWIDTH = object of > object type 1 SHOULD use object type 2 to represent the existing = TE-LSP > BANDWIDTH. >=20 > ENDS >=20 > It is not clear to me why this is a SHOULD and not a MUST. >=20 > s2.4, para below the format: s/MAY also include TLV different from the = PCEP > TLVs./MAY also include TLVs different from the basic PCEP TLVs./ >=20 > s2.4, para at top of page 14: >=20 >> The encoding of the fields Min Bandwidth Spec and Min Reverse >> Bandwidth Spec is the same as in RSVP-TE SENDER_TSPEC object, it = can >> be found in Table 4 from Section 2.3. > Might be helpful to add (after Section 2.3) 'of this document' - the = use of > RSVP-TE immediately before this got me thinking this is in some = RSVP-TE > document. >=20 > s2.5, last bullet on page 14: s/constraints in/constraints on/ >=20 > s2.5.1, para 7 (one after bullet #5): s/This TLVs express/These TLVs = express/ > (probably, but could be 'This TLV expresses' as I think this applies = to just > the Label set TLV.) >=20 > s2.5.1, para 7: s/label set allows to indicate which label/label set = allows > indication of which labels/ >=20 > s2.5.1, para 7: s/restricting then in GMPLS the possible label ranges = on the > interface/consequently restricting the possible label ranges on the = interface > in GMPLS/ >=20 > s2.5.1: Expand P2MP on first occurrence. >=20 > s2.5.1, para after Table 5: s/Value TBD/Value TBA-14/ >=20 > s2.5.1, page 17, para after generalized-endpoint-tlvs grammar: Suggest >=20 > OLD: >=20 > For endpoint type Point-to-Multipoint, several endpoint objects MAY > be present in the message and each represents a leave, exact meaning > depend on the endpoint type defined of the object. >=20 > NEW: >=20 > For endpoint type Point-to-Multipoint, several endpoint objects MAY > be present in the message and each represents a leaf of the P2MP = tree, > with the exact meaning depending on the endpoint type defined for = the object. > ENDS >=20 > s2.5.1, last para on page 17: For consistency, the (new) vlaue of the = Type 4 > error should be specified here (TBA-15, i think). >=20 > s2.5.2.x, last para in each case: s/responded/returned/ >=20 > s2.5.2.3, para 1 s/as follow/as follows/ >=20 > s2.5.2.4, paa 1: s/The LABEL-REQUEST TLV use/The LABEL-REQUEST TLV = uses/ >=20 > s2.5.2.4, para 1: Suggest using fully expanded name of G-PID - = Generalized > Payload Identifier. >=20 > s2.5.2.4, para 2: Suggest adding reference(s) for where the = definitions of > Tspec and FlowSpec can be found. >=20 > s2.5.2.5, para 1: s/Those TLV/These TLVs/, s/responded/returned/, s/as > follow/as follows/ >=20 > s2.5.2.5, first bullet: s/set of label/set of labels/ >=20 > s2.5.2.5, para after diagram: s/Those parameters/These parameters/ >=20 > s2.5.2.5: There are two more or less equivalent descriptions of the = functions > of the U, O and L flag bits. For avadance of error, it would be = better if the > first summary was removed and the reader referred to the full = description after > the diagram. This would mean adding the text 'following the semantic = of > SUGGESTED_LABEL defined by [RFC3471]' to the full description. >=20 > s2.5.2.5, last para on page 20: >=20 >> At most 2 LABEL_SET TLVs MUST be present with >> the O bit set, at most one with the U bit set and at most one with >> the U bit cleared. > Since all LABEL_SET TLVs contain a U bit field, I read the above text = as > limiting the number of LABEL_SETs to two (it isn't clear that the U = constraint > is a sub-constraint after the O constraint). I think what is meant is >=20 >> At most 2 LABEL_SET TLVs MAY be present with >> the O bit set, with at most one of these having the U bit set and >> at most one of these having the U bit cleared. > s2.5.2.5, last 3 paras: For consistency the new error values TBA-x = should be > specified. >=20 > s2.6, para 1: s/allows to include label definition/allows the = inclusion of a > label definition/ >=20 > s2.7, para 1: s/allows to exclude labels/allows the exclusion of = certan labels/ >=20 > s2.7: More information about U, C-Type and Label is allegedly found in = RFC > 3471. I can't find a reference to C-Type in that document, and it is = unclear > which part of the document has the Label info. Is this a miatake? >=20 > s2.8, para 1: s/fulfill/fulfil/ >=20 > s2.8: Pointers to the relevant sections in RFC 4872 and 4873 would = help. >=20 > s2.9: s/The NO-PATH object MAY carries/The NO-PATH object MAY carry/, > s/like/such as/, s/Few/Several/, s/and no/but no/ >=20 > s3, para 1: s/few error/several error/, s/Error- values/Error-values/ >=20 > s3, para 2: s/but not path found/but the PCe is unable to find a = path/, > s/NO-PATH is to be used/the NO-PATH error is to be used/ >=20 > s4.1, last para: s/Those parameters configuration are/The = configuration of the > above parameters is/ >=20 > s4.2: s/This document does not introduces new ERO sub object,/This = document > does not introduce any new ERO sub objects, so that the/ >=20 > s4.4: s/should be covered by/should satisfy/ >=20 > s5: It would be worth adding a note to IANA that TBA-11 is not used = (assuming > this is not a bug). >=20 > s5.1 and s5.3: s/(section /(/ (removing duplicate word 'section') in = several > places >=20 > s5.2, para 2: s/qualities/attributes/ >=20 > s6, para 1: s/amount/volume/ >=20 > s6, first bullet: s/The answer can make that the LSP traverses/The = resulting > LSP might be arranged to traverse/ >=20 > s6, first bullet: s/the answer can omit/the rsulting LSP can omit/, = s/the > answer can lead to provide a LSP/the result can lead to the creation = of an LSP/ >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Apr 10 15:13:07 2019 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 84C7A1202EE; Wed, 10 Apr 2019 15:12:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-pce-gmpls-pcep-extensions@ietf.org, Julien Meuric , pce-chairs@ietf.org, julien.meuric@orange.com, pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <155493437653.22640.5917609495933403034.idtracker@ietfa.amsl.com> Date: Wed, 10 Apr 2019 15:12:56 -0700 Archived-At: Subject: [Pce] Roman Danyliw's Discuss on draft-ietf-pce-gmpls-pcep-extensions-14: (with DISCUSS and COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 22:12:57 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-pce-gmpls-pcep-extensions-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-pcep-extensions/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) Section 6, Per “The answer can make that the LSP traverses some geographical place known to the attacker where some sniffing devices could be installed”, this is a concern. Good that it is here. However, it seems like the consequences could be even more expansive – confidentiality (sniffing), integrity (modifying the traffic) or availability (choose to drop it). (2) Section 6, [RFC8253] is mentioned a few times as having a variety of capabilities to mitigate the described threats. This is the right reference. However, the current text doesn’t explicitly state whether and how this guidance should be followed (should, must, is recommended?) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) Section 2.3, Nit (missing commas and periods), s/(SDH/SONET, G.709, ATM, MEF etc)/ (SDH/SONET, G.709, ATM, MEF, etc.)/ (2) In a few section. Typo (duplicate “section Section”). Recommend global s/section Section/Section/g (3) Section 6. Duplicate word. s/against against/against/ From nobody Wed Apr 10 21:51:59 2019 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 F0672120375; Wed, 10 Apr 2019 21:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1isO-sQ0JzE; Wed, 10 Apr 2019 21:51:47 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E843212027F; Wed, 10 Apr 2019 21:51:46 -0700 (PDT) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 5652B41713F227D7E900; Thu, 11 Apr 2019 05:51:44 +0100 (IST) Received: from lhreml708-chm.china.huawei.com (10.201.108.57) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 11 Apr 2019 05:51:43 +0100 Received: from lhreml708-chm.china.huawei.com (10.201.108.57) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 11 Apr 2019 05:51:43 +0100 Received: from BLREML406-HUB.china.huawei.com (10.20.4.43) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Thu, 11 Apr 2019 05:51:43 +0100 Received: from BLREML503-MBS.china.huawei.com ([169.254.12.125]) by BLREML406-HUB.china.huawei.com ([10.20.4.43]) with mapi id 14.03.0439.000; Thu, 11 Apr 2019 10:21:30 +0530 From: Dhruv Dhody To: Roman Danyliw , The IESG CC: "draft-ietf-pce-stateful-pce-p2mp@ietf.org" , "pce@ietf.org" , "pce-chairs@ietf.org" Thread-Topic: [Pce] Roman Danyliw's Discuss on draft-ietf-pce-stateful-pce-p2mp-12: (with DISCUSS) Thread-Index: AQHU76nyCsWoE0MHi0yeSlcow6ss6aY2XksA Date: Thu, 11 Apr 2019 04:51:30 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8DA107E0@BLREML503-MBS.china.huawei.com> References: <155490660734.22896.13528098840634992626.idtracker@ietfa.amsl.com> In-Reply-To: <155490660734.22896.13528098840634992626.idtracker@ietfa.amsl.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.149.39] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pce] Roman Danyliw's Discuss on draft-ietf-pce-stateful-pce-p2mp-12: (with DISCUSS) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 04:51:50 -0000 SGkgUmFtb24sIA0KDQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3LiANCg0KSGVyZSBpcyB0aGUgcHJv cG9zZWQgdXBkYXRlIC0gDQoNCjEyLiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KICAgVGhl IHN0YXRlZnVsIG9wZXJhdGlvbnMgb24gUDJNUCBURSBMU1BzIGFyZSBtb3JlIENQVS1pbnRlbnNp dmUgYW5kDQogICBhbHNvIHV0aWxpemUgbW9yZSBiYW5kd2lkdGggb24gd2lyZSAoaW4gY29tcGFy aXNvbiB0byBQMlAgVEUgTFNQcykuDQogICBJZiBhIHJvZ3VlIFBDQyB3ZXJlIGFibGUgdG8gcmVx dWVzdCB1bmF1dGhvcml6ZWQgc3RhdGVmdWwgUENFDQogICBvcGVyYXRpb25zIHRoZW4gaXQgbWF5 IGJlIGFibGUgdG8gbW91bnQgYSBEb1MgYXR0YWNrIGFnYWluc3QgYSBQQ0UsDQogICB3aGljaCB3 b3VsZCBkaXNydXB0IHRoZSBuZXR3b3JrIGFuZCBkZW55IHNlcnZpY2UgdG8gb3RoZXIgUENDcy4N CiAgIFNpbWlsYXJseSBhbiBhdHRhY2tlciBtYXkgZmxvb2QgdGhlIFBDQyB3aXRoIFBDVXBkIG1l c3NhZ2VzIGF0IGEgcmF0ZQ0KICAgdGhhdCBleGNlZWRzIGVpdGhlciB0aGUgUENDJ3MgYWJpbGl0 eSB0byBwcm9jZXNzIHRoZW0gb3IgdGhlDQogICBuZXR3b3JrJ3MgYWJpbGl0eSB0byBzaWduYWwg dGhlIGNoYW5nZXMsIGJ5IGVpdGhlciBzcG9vZmluZyBtZXNzYWdlcw0KICAgb3IgY29tcHJvbWlz aW5nIHRoZSBQQ0UgaXRzZWxmLg0KDQogICBDb25zZXF1ZW50bHksIGl0IGlzIGltcG9ydGFudCB0 aGF0IGltcGxlbWVudGF0aW9ucyBjb25mb3JtIHRvIHRoZQ0KICAgcmVsZXZhbnQgc2VjdXJpdHkg cmVxdWlyZW1lbnRzIGFzIGxpc3RlZCBiZWxvdyAtDQoNCiAgIG8gIEFzIHBlciBbUkZDODIzMV0s IGl0IGlzIFJFQ09NTUVOREVEIHRoYXQgdGhlc2UgUENFUCBleHRlbnNpb25zDQogICAgICBvbmx5 IGJlIGFjdGl2YXRlZCBvbiBhdXRoZW50aWNhdGVkIGFuZCBlbmNyeXB0ZWQgc2Vzc2lvbnMgYWNy b3NzDQogICAgICBQQ0VzIGFuZCBQQ0NzIGJlbG9uZ2luZyB0byB0aGUgc2FtZSBhZG1pbmlzdHJh dGl2ZSBhdXRob3JpdHksDQogICAgICB1c2luZyBUcmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkgKFRM UykgW1JGQzgyNTNdLCBhcyBwZXIgdGhlDQogICAgICByZWNvbW1lbmRhdGlvbnMgYW5kIGJlc3Qg Y3VycmVudCBwcmFjdGljZXMgaW4gW1JGQzc1MjVdICh1bmxlc3MNCiAgICAgIGV4cGxpY2l0bHkg c2V0IGFzaWRlIGluIFtSRkM4MjUzXSkuDQoNCiAgIG8gIFNlY3VyaXR5IGNvbnNpZGVyYXRpb25z IGZvciBwYXRoIGNvbXB1dGF0aW9uIHJlcXVlc3RzIGFuZA0KICAgICAgcmVzcG9uc2VzIGFyZSBh cyBwZXIgW1JGQzgzMDZdLg0KDQogICBvICBTZWN1cml0eSBjb25zaWRlcmF0aW9ucyBmb3Igc3Rh dGVmdWwgb3BlcmF0aW9ucyAoc3VjaCBhcyBzdGF0ZQ0KICAgICAgcmVwb3J0LCBzeW5jaHJvbml6 YXRpb24sIGRlbGVnYXRpb24sIHVwZGF0ZSwgZXRjLikgYXJlIGFzIHBlcg0KICAgICAgW1JGQzgy MzFdLg0KDQogICBvICBTZWN1cml0eSBjb25zaWRlcmF0aW9ucyBmb3IgTFNQIGluc3RhbnRpYXRp b24gbWVjaGFuaXNtIGFyZSBhcyBwZXINCiAgICAgIFtSRkM4MjMxXS4NCg0KICAgbyAgU2VjdXJp dHkgY29uc2lkZXJhdGlvbnMgYXMgc3RhdGVkIGluIFNlY3Rpb24gMTAuMSwgU2VjdGlvbiAxMC42 LA0KICAgICAgYW5kIFNlY3Rpb24gMTAuNyBvZiBbUkZDNTQ0MF0gY29udGludWUgdG8gYXBwbHku DQoNCg0KTW9yZSBpbmxpbmUgLSANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBQY2UgW21haWx0bzpwY2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvbWFu IERhbnlsaXcgdmlhDQo+IERhdGF0cmFja2VyDQo+IFNlbnQ6IDEwIEFwcmlsIDIwMTkgMjA6MDAN Cj4gVG86IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KPiBDYzogZHJhZnQtaWV0Zi1wY2Utc3Rh dGVmdWwtcGNlLXAybXBAaWV0Zi5vcmc7IHBjZUBpZXRmLm9yZzsgcGNlLQ0KPiBjaGFpcnNAaWV0 Zi5vcmcNCj4gU3ViamVjdDogW1BjZV0gUm9tYW4gRGFueWxpdydzIERpc2N1c3Mgb24gZHJhZnQt aWV0Zi1wY2Utc3RhdGVmdWwtcGNlLQ0KPiBwMm1wLTEyOiAod2l0aCBESVNDVVNTKQ0KPiANCj4g Um9tYW4gRGFueWxpdyBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBm b3INCj4gZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwtcGNlLXAybXAtMTI6IERpc2N1c3MNCj4gDQo+ IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5k IHJlcGx5IHRvIGFsbA0KPiBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBD QyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcw0KPiBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBo LCBob3dldmVyLikNCj4gDQo+IA0KPiBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+IGZvciBtb3JlIGluZm9y bWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+IA0KPiAN Cj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBi ZSBmb3VuZCBoZXJlOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLXBjZS1zdGF0ZWZ1bC1wY2UtcDJtcC8NCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiBESVNDVVNTOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBUaGUgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMgc2VjdGlvbiBoYXMgbnVtZXJvdXMgaGVscGZ1bCBhbmQgYXBwcm9wcmlhdGUNCj4gcmVm ZXJlbmNlcy4gIFRoYW5rcyBmb3IgdHJhY2tpbmcgdGhlbSBkb3duLiAgSG93ZXZlciwgZXhwbGlj aXQsIGFkZGl0aW9uYWwNCj4gdGV4dCBpcyByZXF1aXJlZCB0byBoZWxwIGlkZW50aWZ5LCBkZS1k dXBsaWNhdGUgYW5kIGRlY29uZmxpY3QgdGhlDQo+IOKAnHJlbGV2YW50IGd1aWRhbmNl4oCdIHBy b3ZpZGVkIGJ5IHRoZW0uDQo+IA0KPiAoMSkgUGVyIOKAnGl0IGlzIGltcG9ydGFudCB0aGF0IGlt cGxlbWVudGF0aW9ucyBjb25mb3JtIHRvIHRoZSByZWxldmFudA0KPiBzZWN1cml0eSByZXF1aXJl bWVudHMgb2YgW1JGQzU0NDBdLCBbUkZDODMwNl0gYW5kIFtSRkM4MjMxXSwgYW5kDQo+IFtSRkM4 MjgxXeKAnToNCj4gDQo+ICoqIFtSRkM4MjMxXSBzYXlzIOKAnFJFQ09NTUVOREVEIHRoYXQgdGhl c2UgUENFUCBleHRlbnNpb25zIG9ubHkgYmUNCj4gYWN0aXZhdGVkIG9uIGF1dGhlbnRpY2F0ZWQg YW5kIGVuY3J5cHRlZCBzZXNzaW9ucyBhY3Jvc3MgUENFcyBhbmQgUENDcw0KPiBiZWxvbmdpbmcg dG8gdGhlIHNhbWUgYWRtaW5pc3RyYXRpdmUgYXV0aG9yaXR5LCB1c2luZyBUcmFuc3BvcnQgTGF5 ZXINCj4gU2VjdXJpdHkgKFRMUykgW1BDRVBTXSwgYXMgcGVyIHRoZSByZWNvbW1lbmRhdGlvbnMg YW5kIGJlc3QgY3VycmVudA0KPiBwcmFjdGljZXMgaW4gW1JGQzc1MjVd4oCdLiAgR29vZCBsYW5n dWFnZS4NCj4gVGhpcyBkcmFmdCBhZ2FpbiByZS1zdGF0ZXMg4oCcU2VjdXJpbmcgdGhlIFBDRVAg c2Vzc2lvbiB1c2luZyBUcmFuc3BvcnQNCj4gTGF5ZXIgU2VjdXJpdHkgKFRMUykgW1JGQzgyNTNd LCBhcyBwZXIgdGhlIHJlY29tbWVuZGF0aW9ucyBhbmQgYmVzdA0KPiBjdXJyZW50IHByYWN0aWNl cyBpbiBbUkZDNzUyNV0sIGlzIFJFQ09NTUVOREVELuKAnSAgV2h5IHNheSB0aGF0IHR3aWNlPyAg SXMNCj4gdGhlcmUgc29tZXRoaW5nIG5ldyB0aGVyZT8NCj4gDQoNCltbRGhydXYgRGhvZHldXSBV c2VkIHRoZSB0ZXh0IGZyb20gUkZDODIzMS4gDQoNCj4gKiogUGVyIFNlY3Rpb24gMTAuNCBvZiBS RkM1NDQwIGZyb20gMjAwOSwgSVBTZWMgaXMgYSBNQVkgYW5kIFNlY3Rpb24gMTAuMg0KPiBtYWtl cw0KPiBUQ1AtTUQ1IGEgTVVTVC4gIFRoZSBtb3JlIHJlY2VudCAoMjAxNykgUkZDODMwNiBhbmQg UkZDODI1MyByZWZlcmVuY2UgVExTDQo+IGFuZCBUQ1AtQU8sIG5vIElQU2VjLiAgUkZDODMwNiBl eHBsaWNpdGx5IHNheXMgZG9u4oCZdCB1c2UgVENQLU1ENS4gIFdoYXQgaXMNCj4gdGhlIFJFQ09N TUVOREVEIGFwcHJvYWNoIHRvZGF5Pw0KPiANCj4gKDIpIFBlciDigJxbc11lY3VyaW5nIHRoZSBQ Q0VQIHNlc3Npb24gdXNpbmcgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChUTFMpDQo+IFtSRkM4 MjUzXSwgYXMgcGVyIHRoZSByZWNvbW1lbmRhdGlvbnMgYW5kIGJlc3QgY3VycmVudCBwcmFjdGlj ZXMgaW4NCj4gW1JGQzc1MjVdLCBpcyBSRUNPTU1FTkRFROKAnSwgaG93IHNob3VsZCB0aGUgZ3Vp ZGFuY2Ugb24gYm90aCBvZiB0aGVzZQ0KPiBkcmFmdHMgYmUgc3ludGhlc2l6ZWQ/ICAJDQoNCltb RGhydXYgRGhvZHldXSBBZGRlZCAiKHVubGVzcyBleHBsaWNpdGx5IHNldCBhc2lkZSBpbiBbUkZD ODI1M10pIi4gDQoNCj4gU3BlY2lmaWNhbGx5LCB0aGlzIHNlbnRlbmNlIGlzIHVuY2xlYXIgb24g d2hldGhlcg0KPiB0aGUgdGhlIHJvYnVzdCBUTFMgMS4yIHJlcXVpcmVtZW50cyBpbiBTZWN0aW9u IDMuNCBvZiBSRkM4MjUzIGFyZQ0KPiBSRUNPTU1FTkRFRCwgYW5kL29yIHdoZXRoZXIgdGhlIFNl Y3VyaXR5IENvbnNpZGVyYXRpb25zL1NlY3Rpb24gNyBvZg0KPiBSRkM4MjUzLCB3aGljaCB1bmRl cm1pbmUgdGhlc2Ugcm9idXN0IHJlcXVpcmVtZW50cyBieSBzYXlpbmcNCj4gYWRtaW5pc3RyYXRv cnMgTUFZIGFsbG93IHRoZSB1c2FnZSB3ZWFrIGNpcGhlcnN1aXRlcywgYXBwbHkuICANCg0KW1tE aHJ1diBEaG9keV1dIFNlY3Rpb24gMy40IG9mIFJGQzgyNTMgc2F5cyAtIA0KDQogICAgICAgKiAg TmVnb3RpYXRpb24gb2YgYSBjaXBoZXJzdWl0ZSBwcm92aWRpbmcgZm9yIGNvbmZpZGVudGlhbGl0 eSBpcw0KICAgICAgICAgIFJFQ09NTUVOREVELg0KDQpUaGVuLCBTZWN0aW9uIDcgc2F5cyAtIA0K DQogICBTb21lIFRMUyBjaXBoZXJzdWl0ZXMgb25seSBwcm92aWRlIGludGVncml0eSB2YWxpZGF0 aW9uIG9mIHRoZWlyDQogICBwYXlsb2FkIGFuZCBwcm92aWRlIG5vIGVuY3J5cHRpb247IHN1Y2gg Y2lwaGVyc3VpdGVzIFNIT1VMRCBOT1QgYmUNCiAgIHVzZWQgYnkgZGVmYXVsdC4gIEFkbWluaXN0 cmF0b3JzIE1BWSBhbGxvdyB0aGUgdXNhZ2Ugb2YgdGhlc2UNCiAgIGNpcGhlcnN1aXRlcyBhZnRl ciBjYXJlZnVsIHdlaWdodGluZyBvZiB0aGUgcmlzayBvZiByZWxldmFudCBpbnRlcm5hbA0KICAg ZGF0YSBsZWFrYWdlIHRoYXQgY2FuIG9jY3VyIGluIHN1Y2ggYSBjYXNlLCBhcyBleHBsaWNpdGx5 IHN0YXRlZCBieQ0KICAgW1JGQzY5NTJdLg0KDQpUaGUgJ01BWScgaW4gdGhlIGFib3ZlIHRleHQg aXMgdG8gb3B0aW9uYWxseSBhbGxvdyBnb2luZyBhZ2FpbnN0IHNvbWV0aGluZyB0aGF0IGlzICdS RUNPTU1FTkRFRCcgd2l0aCBhIHN1aXRhYmxlIGd1aWRhbmNlLiBJbiBteSByZWFkaW5nIHRoYXQg aXMgb2theS4gQW0gSSBtaXNzaW5nIHNvbWV0aGluZz8gIA0KDQo+IFRoaXMNCj4gc2VudGVuY2Ug YWxzbyBjaXRlcyBSRkM3NTI1IHdoaWNoIG1ha2VzIHN0YXRlbWVudHMgdGhhdCB3ZWFrDQo+IChO VUxMKSBjaXBoZXIgc3VpdGVzIE1VU1QgTk9UIGJlIG5lZ290aWF0ZWQgaW4gY29udHJhZGljdGlv biB0byB0aGUNCj4gUkZDODI1MyBTZWN0aW9uIDcgZ3VpZGFuY2UuDQo+IA0KW1tEaHJ1diBEaG9k eV1dIFRoaXMgaXMgdGFrZW4gY2FyZSBieSAiKHVubGVzcyBleHBsaWNpdGx5IHNldCBhc2lkZSBp biBbUkZDODI1M10pIiBpbiB0aGUgcHJvcG9zZWQgdXBkYXRlLiANCg0KPiBHaXZlbiB0aGUgZGlz Y3Vzc2lvbiBvZiBUTHMsIHNvbWUgYWRkaXRpb25hbCB0cmVhdG1lbnQgb2YgVExTIHYxLjMgaXMN Cj4gbmVlZGVkLCByZWNvZ25pemluZyB0aGF0IFJGQzc1MjUgZG9lcyByZWNvbW1lbmQg4oCcdjEu MivigJ0NCj4gDQpbW0RocnV2IERob2R5XV0gQm90aCBSRkM4MjUzIGFuZCBSRkM3NTI1IHNheSBU TFMxLjIgb3IgbGF0ZXI7IG5vdCBzdXJlIGlmIHdlIG5lZWQgdG8gc2F5IG1vcmUgaW4gdGhpcyBJ LUQgKGEgdmVyeSBzcGVjaWZpYyBQMk1QIGV4dGVuc2lvbikuIA0KDQo+IEFnYWluLCB0aGVyZSBp cyBoZWxwZnVsIGd1aWRhbmNlIGFjcm9zcyBhbGwgb2YgdGhlIHJlZmVyZW5jZXMuICBQbGVhc2UN Cj4gcHJvdmlkZSBtb3JlIHRleHR1YWxseSBuYXJyYXRpdmUgYWJvdXQgd2hpY2ggc3BlY2lmaWMg c2VjdGlvbnMgYXBwbHkgb24NCj4gdGhlIHJlZmVyZW5jZXMuDQo+IA0KPiANCltbRGhydXYgRGhv ZHldXSBTZWUgcHJvcG9zZWQgdGV4dC4gDQoNCklmIHRoZSBuZXcgdGV4dCBuZWVkcyBmdXJ0aGVy IGNoYW5nZXMsIGl0IHdvdWxkIGJlIHZlcnkgaGVscGZ1bCBpZiB5b3UgY291bGQgaW5jbHVkZSB0 aGUgY2hhbmdlcyB5b3Ugd291bGQgbGlrZSB0byBzZWUuICANCg0KVGhhbmtzIGZvciB5b3VyIHJl dmlldyEgDQoNClJlZ2FyZHMhIA0KRGhydXYNCg0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFBjZSBtYWlsaW5nIGxpc3QNCj4gUGNl QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNlDQo= From nobody Thu Apr 11 04:28:10 2019 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE141201C7; Thu, 11 Apr 2019 04:27:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Vigoureux via Datatracker To: "The IESG" Cc: draft-ietf-pce-gmpls-pcep-extensions@ietf.org, Julien Meuric , pce-chairs@ietf.org, julien.meuric@orange.com, pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Martin Vigoureux Message-ID: <155498207568.12802.3705482162496355990.idtracker@ietfa.amsl.com> Date: Thu, 11 Apr 2019 04:27:55 -0700 Archived-At: Subject: [Pce] Martin Vigoureux's Discuss on draft-ietf-pce-gmpls-pcep-extensions-14: (with DISCUSS) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 11:28:02 -0000 Martin Vigoureux has entered the following ballot position for draft-ietf-pce-gmpls-pcep-extensions-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-pcep-extensions/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi, thanks for this document. I have a discuss point that shouldn't be difficult to resolve: Why do you define a flag field in the GMPLS-CAPABILITY TLV if you don't have any flag? I guess the easy answer is that there might be some in the future. If so, I tend to think that creating a registry for that field would be a good thing to do now. -m From nobody Thu Apr 11 04:46:07 2019 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 701BE120048; Thu, 11 Apr 2019 04:45:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-pce-gmpls-pcep-extensions@ietf.org, Julien Meuric , pce-chairs@ietf.org, julien.meuric@orange.com, pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <155498315544.12722.1073746104492266680.idtracker@ietfa.amsl.com> Date: Thu, 11 Apr 2019 04:45:55 -0700 Archived-At: Subject: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-gmpls-pcep-extensions-14: (with DISCUSS and COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 11:45:56 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-pce-gmpls-pcep-extensions-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-pcep-extensions/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This document makes some well-needed extensions to existing PCEP concepts such as bandwidth, but I'm not convinced that the way they interact with existing PCEP functionality is sufficiently well specified to admit interoperable implementation. Specifically, we introduce the generalized bandwidth structures and reuse that encoding for the generalized load balancing structures, which includes a notion of "minimum bandwidth specification". But now that the bandwidth specification is a compound data structure instead of a scalar type, it's not guaranteed that we have a strict linear ordering with well-defined minimum. If we consider the specific case of Intserv, do I insist upon all three of the minimum bucket rate, minimum bucket size, and minimum peak data rate? Or perhaps I only care about the peak data rate and not the bucket size/rate. We need more text in order to specify what "minimum" actually means/measures. Similarly, I'm not sure all the referenced generalized bandwidth types/traffic parameters in Section 2.3 clearly indicate which structures/fields we are to incorporate by reference (see COMMENT). Section 2.1.2 says: GMPLS-CAPABILITY TLV it is RECOMMENDED that the PCC does not make use of the objects and TLVs defined in this document. Why is this not "the PCC MUST NOT make use of the objects and TLVs defined in this document"? Ignoring the peer's (non-)advertisement and plowing ahead seems like a recipe for non-interoperability. Section 2.5.1 notes that: ::= [] [ []]... For endpoint type Point-to-Multipoint, several endpoint objects MAY be present in the message and each represents a leave, exact meaning depend on the endpoint type defined of the object. If all s represent leaves, then how is the head node specified? I couldn't find a full spcification for some of the fields in the XRO Label subobject (Section 2.7) by chasing the indicated references (see COMMENT). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1 Please expand OTN and WSON on first use. Section 1.4 It's very unclear to me what kind of support, from/by what entities/data structures, under what conditions, these tables are attempting to indicate. We should probably be consistent whether we talk about just "FOO" or "FOO object" as the hanging text for these bulleted lists. From [RFC8282]: o SWITCH-LAYER: address requirements (1, 2 and 3) for the TE-LSP and indicates which layer(s) should be considered, can be used to represent the RSVP-TE generalized label request. [...] nit: this looks like a comma splice. The PCEP extensions defined later in this document to cover the gap are: Two new object types are introduced for the BANDWIDTH object (Generalized bandwidth, Generalized bandwidth of existing TE-LSP for which a reoptimization is requested). I'm confused by this language "new object types are introduced for the BANDWIDTH object". My understanding was that objects did not nest: that is, objects have a given structure and can sometimes contain TLVs, but do not contain other objects. So, my current understanding is that new objects are introduced that can appear where the BANDWIDTH object would previously have appeared, but they are separate object (type)s from the RFC 5440 BANDWIDTH objects. (This language is used in the next couple items as well.) To be clear, this is at most an editorial consideration, essentially whether to use "introduced for" or something like "introduced akin to". Section 2.1.2 If the PCE does not include the GMPLS-CAPABILITY TLV in the OPEN message and the PCC does include the TLV, it is RECOMMENDED that the PCC indicates a mismatch of capabilities. Moreover, in case that the PCC does not receive the Indicate how, to whom? Section 2.2 This granularity applies to all links in the path, right? So I can't request label-level granularity for one hop and indicate that I only care about node-level granularity for the other hops? Section 2.3 [similar comments apply here to what I mentioned at the end of Section 1.4] The Bw Spec Type correspond to the RSVP-TE SENDER_TSPEC (Object Class 12) C-Types Should we ask IANA to update the SENDER_TSPEC registry to note that it is used for PCEP as well as RSVP? The encoding of the fields Generalized Bandwidth and Reverse Generalized Bandwidth is the same as the Traffic Parameters carried in RSVP-TE, it can be found in the following references. Object Type Name Reference 2 Intserv [RFC2210] 4 SONET/SDH [RFC4606] 5 G.709 [RFC4328] 6 Ethernet [RFC6003] 7 OTN-TDM [RFC7139] 8 SSON [RFC7792] It's quite confusing to have the table heading be just "object type" when this is the value in the field named "Bw Spec Type" and corresponds to class type values in the SENDER_TSPEC registry. Also, I looked up the Intserv case, and RFC 2210 doesn't really give me a clear picture of what I'm supposed to encode as the "transport parameters". I think it's supposed to be the 12-octet assembly consisting of the token bucket rate, token bucket size, and peak data rate, but I have very low confidence in that assessment. On the other hand, RFC 4606 has a very nice data structure layout in Section 2.1, "SONET/SDH Traffic Parameters". On the gripping hand, there's not a clear "bandwidth" number in that structure that I can apply a comparison to for load-balancing purposes. It doesn't look like I'll have time to check the other four cases right now, but that will need to be done before final publication. Section 2.4 I'm having trouble parsing: The LOAD-BALANCING object [RFC5440] is used to request a set of maximum Max-LSP TE-LSP having in total the bandwidth specified in BANDWIDTH, each TE-LSP having a minimum of bandwidth. Is it intended to read: The LOAD-BALANCING object [RFC5440] is used to request allocation of a set of at most Max-LSP TE-LSPs, having in total the bandwidth specified in BANDWIDTH, with each TE-LSP having at least a specified minimum bandwidth. ? [similar comments apply here to what I mentioned at the end of Section 1.4] Bandwidth Spec Length (16 bits): the total length of the Min Bandwidth Spec field. It is to be noted that the RSVP-TE traffic specification MAY also include TLV different from the PCEP TLVs. The length MUST be strictly greater than 0. It's not entirely clear to me why the note about different TLVs in RSVP-TE and PCEP belongs here. Section 2.5.1 Endpoints label restriction may not be part of the RRO or IRO, they can be included when following [RFC4003] in signaling for egress endpoint, but ingress endpoint properties can be local to the PCC and not signaled. [...] nit: the first comma looks like a comma splice. A PCE not supporting a given Endpoint Type SHOULD respond with a PCErr with Error Type 4, Value TBD "Unsupported endpoint type in END-POINTS Generalized Endpoint object type". [...] s/TBD/TBA-15/ The TLVs present in the request object body MUST follow the following [RFC5511] grammar: It feels a bit like a type error to use RBNF to describe the layout of TLVs within a TLV block, as RBNF acts on objects. Section 2.5.2.4 The LABEL-REQUEST TLV indicates the switching capability and encoding type of the following label restriction list for the endpoint. Its format and encoding is the same as described in [RFC3471] Section 3.1 Generalized label request. [...] Presumably the "Its" refers to just the value portion of the TLV? That should probably be stated explicitly. Section 2.5.2.5 Is there any reason for the section title to not be "LABEL-SET TLV" for consistency with the other sections? A LABEL-SET TLV represents a set of possible labels that can be used on an interface. If the L bit is cleared, the label allocated on the first endpoint MUST be within the label set range. [...] Is this MUST binding on the PCC that generates a request, or on the computed LSP returned by the PCE? A LABEL-SET TLV with the O and L bit set MUST trigger a PCErr message with error type="Reception of an invalid object" error value="Wrong LABEL-SET TLV present with O and L bit set". A LABEL-SET TLV with the O bit set and an Action Field not set to 0 (Inclusive list) or containing more than one subchannel MUST trigger a PCErr message with error type="Reception of an invalid object" error value="Wrong LABEL-SET TLV present with O bit and wrong format". If a LABEL-SET TLV is present with O bit set, the R bit of the RP object MUST be set, otherwise a PCErr message MUST be sent with error type="Reception of an invalid object" error value="LABEL-SET TLV present with O bit set but without R bit set in RP". nit: I don't know if it makes more sense to use the TBA-25, TBA-26, and TBA-24 values in these descriptions. Section 2.6 The IRO as defined in [RFC5440] is used to include specific objects in the path. RSVP-TE allows to include label definition, in order to fulfill requirement 13 of [RFC7025] the IRO needs to support the new subobject type as defined in [RFC3473]: nit: this looks like a comma splice. (A similar construction appears in Section 2.7 as well.) Section 2.7 U (1 bit): see [RFC3471]. C-Type (8 bits): the C-Type of the included Label Object as defined in [RFC3471]. Label: see [RFC3471]. Sorry, where exactly in RFC 3471? I do not see discussion of a U bit or C-Type therein. (Perhaps RFC 3473 was intended? Though, RFC 3473 seems to refer back to 3471 for the U parameter, again without section reference.) Section 6 It seems that a malicious PCC might be able to effect a denial of service attack on the PCE by attempting to make many requests that consume lots of resources (whether on the PCE itself or in the managed network elements). In addition Technology specific data plane mechanism can be used (following [RFC5920] Section 5.8) to verify the data plane connectivity and deviation from constraints. nit: "In addition, technology-specific" Appendix A It's not entirely clear to me why this specific group of examples was chosen and no others. (The appendix does not seem to be referenced from elsewhere in the document, so it appears fairly random to a reader making it that far.) From nobody Thu Apr 11 05:01:19 2019 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 7D380120131; Thu, 11 Apr 2019 05:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKfGs503a2jW; Thu, 11 Apr 2019 05:01:06 -0700 (PDT) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6464D120048; Thu, 11 Apr 2019 05:01:06 -0700 (PDT) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3BC14fd021631; Thu, 11 Apr 2019 13:01:04 +0100 Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 004922203D; Thu, 11 Apr 2019 13:01:04 +0100 (BST) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS id E5E992203B; Thu, 11 Apr 2019 13:01:03 +0100 (BST) Received: from LAPTOPK7AS653V ([87.114.253.143]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3BC12b5026106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Apr 2019 13:01:03 +0100 Reply-To: From: "Adrian Farrel" To: "'Martin Vigoureux'" , "'The IESG'" Cc: , "'Julien Meuric'" , , References: <155498207568.12802.3705482162496355990.idtracker@ietfa.amsl.com> In-Reply-To: <155498207568.12802.3705482162496355990.idtracker@ietfa.amsl.com> Date: Thu, 11 Apr 2019 13:01:03 +0100 Organization: Old Dog Consulting Message-ID: <045201d4f05e$3cddfc00$b699f400$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQHOSuRYJrQnCtmOG6vq75PF1vNWxqZEJkng X-Originating-IP: 87.114.253.143 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24544.007 X-TM-AS-Result: No--5.265-10.0-31-10 X-imss-scan-details: No--5.265-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24544.007 X-TMASE-Result: 10--5.265500-10.000000 X-TMASE-MatchedRID: QW5G6BKkLTrxIbpQ8BhdbL0dPFETpBAH56ZiKymUcU7b6Y+fnTZUL34M 2QICXpHjMXEn4M+GcWvPDExIjNkthnnEICAqqFlBlVHM/F6YkvSsBP5mv7Dua4KwF4K/wIz9MC0 ++gksI5BXlG+b8fa+cOuPA2P8B67NwpNb3yM/DA3N+qWlu2ZxaKwxCUEjPydtd6RFRE7vKfHvjh geV9O8lNeiPxhabPECyvkBV2KfhrWqYtZoSKdB4fi9hrAKwILaC3HuWcgyQCZaW2Ktn+I8/lN/2 7EBZW0V585VzGMOFzCWc/0wwBlx2lOm2gN+nomsxEHRux+uk8jHUU+U0ACZwE51q2/dMDfIWAbK 7E5/iE7wE5GOLkKW7tmUWd2JR9wxnqg/VrSZEiM= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Pce] Martin Vigoureux's Discuss on draft-ietf-pce-gmpls-pcep-extensions-14: (with DISCUSS) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 12:01:10 -0000 Hi Martin, It was a general policy during the development of PCEP to make space for = flags in the various objects, and this has turned out to be useful in = some cases. So, I think the authors were continuing that approach. But I agree, if you make the field, you should make the registry. Thanks, Adrian -----Original Message----- From: Martin Vigoureux via Datatracker =20 Sent: 11 April 2019 12:28 To: The IESG Cc: draft-ietf-pce-gmpls-pcep-extensions@ietf.org; Julien Meuric = ; pce-chairs@ietf.org; = julien.meuric@orange.com; pce@ietf.org Subject: Martin Vigoureux's Discuss on = draft-ietf-pce-gmpls-pcep-extensions-14: (with DISCUSS) Martin Vigoureux has entered the following ballot position for draft-ietf-pce-gmpls-pcep-extensions-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-pcep-extensions/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi, thanks for this document. I have a discuss point that shouldn't be = difficult to resolve: Why do you define a flag field in the GMPLS-CAPABILITY TLV if you don't = have any flag? I guess the easy answer is that there might be some in the future. If so, I tend to think that creating a registry for that field would be = a good thing to do now. -m From nobody Thu Apr 11 05:14:25 2019 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 AAAE9120131; Thu, 11 Apr 2019 05:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eWhZthK1bKq; Thu, 11 Apr 2019 05:14:21 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81C51120048; Thu, 11 Apr 2019 05:14:21 -0700 (PDT) Received: from ewa_guest_internet_sthlm_nat2.ericsson.net ([192.176.1.97] helo=[10.148.125.253]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hEYaw-0002bh-C0; Thu, 11 Apr 2019 14:14:18 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Mirja Kuehlewind In-Reply-To: Date: Thu, 11 Apr 2019 14:14:17 +0200 Cc: draft-ietf-pce-stateful-pce-p2mp@ietf.org, Adrian Farrel , pce@ietf.org, The IESG , pce-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <155439625812.30874.11556397385069015051.idtracker@ietfa.amsl.com> To: Dhruv Dhody X-Mailer: Apple Mail (2.3445.104.8) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1554984861;5d81a5f8; X-HE-SMSGID: 1hEYaw-0002bh-C0 Archived-At: Subject: Re: [Pce] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-pce-stateful-pce-p2mp-12=3A_=28with_COMMENT=29?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 12:14:24 -0000 Hi Dhruv, Sorry for my late reply. So your reply actually concerns me a bit. = Initially you said you've put it in object because there was no = expectation that is may be needed by other objects. Now you have a = second object and you defined it again object-specifically because you = say it=E2=80=99s too much overhead to define a generic mechanisms for = just one more. Will you say the same thing again with the next object = that needs fragmentation? Maybe it=E2=80=99s the right time now to add = this more generically to common header. I mean it should be a very = short, straight-forward draft. What=E2=80=99s the argument for not just = doing it now? mirja > On 4. Apr 2019, at 20:07, Dhruv Dhody wrote: >=20 > Hi Mirja, >=20 > On Thu, Apr 4, 2019 at 10:14 PM Mirja K=C3=BChlewind via Datatracker > wrote: >>=20 >> Mirja K=C3=BChlewind has entered the following ballot position for >> draft-ietf-pce-stateful-pce-p2mp-12: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-p2mp/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Just a quick clarification question on fragmentation: I'm wondering = if it is >> really necessary to define a fragmentation mechanism/bit for each = object >> separately (e.g also RFC8306) or if it would be more appropriate to = allocate >> one bit in the common header? Just asking as I'm really not an expert = here... >>=20 >>=20 >=20 > The need for fragmentation was found when the support for P2MP TE was > introduced in RFC6006. At that time only two PCEP message were > susceptible to fragmentation (PCReq & PCRep) and the choice was made > to add a flag in a RP object. The choice made at that time was that > the other messages should not be fragmented. >=20 > Later PCEP added more messages to support stateful operation. And with > this I-D we extend support to P2MP LSP where fragmentation handling > was required (we added the flag in the LSP object). >=20 > You are correct! We could have used the PCEP common message header and > said that the flag is applicable for the subset of messages. But the > design choice here was to keep consistent with technique already in > place. Fragmentation flag in 2 objects isn't all that bad. >=20 > Thanks for your review! > Dhruv >=20 >=20 From nobody Thu Apr 11 05:23:52 2019 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 6ABEF1201B6; Thu, 11 Apr 2019 05:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6t0pTvN5QXh; Thu, 11 Apr 2019 05:23:41 -0700 (PDT) Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4392C120048; Thu, 11 Apr 2019 05:23:41 -0700 (PDT) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3BCNdC7031314; Thu, 11 Apr 2019 13:23:39 +0100 Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0B1532203B; Thu, 11 Apr 2019 13:23:39 +0100 (BST) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS id E89EA2203A; Thu, 11 Apr 2019 13:23:38 +0100 (BST) Received: from LAPTOPK7AS653V ([87.114.253.143]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3BCNbvc020471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Apr 2019 13:23:38 +0100 Reply-To: From: "Adrian Farrel" To: "'Benjamin Kaduk'" , "'The IESG'" Cc: , "'Julien Meuric'" , , References: <155498315544.12722.1073746104492266680.idtracker@ietfa.amsl.com> In-Reply-To: <155498315544.12722.1073746104492266680.idtracker@ietfa.amsl.com> Date: Thu, 11 Apr 2019 13:23:37 +0100 Organization: Old Dog Consulting Message-ID: <046301d4f061$646ee470$2d4cad50$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQLjbMya9KIUXpvroOm89DLIlSeuhaQZ4yHg X-Originating-IP: 87.114.253.143 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24544.007 X-TM-AS-Result: No--12.954-10.0-31-10 X-imss-scan-details: No--12.954-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24544.007 X-TMASE-Result: 10--12.953700-10.000000 X-TMASE-MatchedRID: 8HTFlOrbAtHxIbpQ8BhdbLmR+C0l9vjVbv16+gil4jdUvqB5o/LqcwOH les/nBwnPSz3UIYGf5YMRAbYkwYIMt1ZJprSJcwwolVO7uyOCDVkBDPLxNH5Bs2mvbig5LjG9Ae 1UPqORDqv/Ay/72VS232H7OZFch3LOwJSwPuUvbji3aa5wOREESAlP9kQvLsD/zIkW73uAA77mC X2MGw8T8D5B07Z27le7qXXLN2XZ6orYPqmZqtV//jQkA7rdCuFojQrbrPpzzoUtdRZTmEaIbnkY fvqNCbtMjmV2idDT8LVnq+mUKhlXzzqOmsIGhM5EzEoOqAAVLP/qP1IyFxdAvgnJH5vm2+gemFa kW6csIt1h0VOhvUGwjKDg69ZJ4iN6xj9tplxe1oD2WXLXdz+AdFqG4/BpDVaW+jwVKpqvlJUITS Wh/2uxY3B9y7Ns2wnojJ0zxEA8bctDNSffoghltF8NCC76P7lSuH+GfgmQGfIvQIyugvKdQaTal M8C773ohp6CgYAhBrPhkN609qlO/YPX5V+UcdXsaPcs3T4TL00AKed0u9fB/2dkkg+0fIUmZ+Ey 9Yt270FWd4E/YuCICg3Vg6lnJwSuHCiSIvAnFtNCH0Dib0S0WEF8bGZ0cKC+a3bC2tdCMz02CyY vwGr2IGuFtNUrTVW3Hkd7jZc2igy67nSqhVBaHNpNmoJ1zd8QKuv8uQBDjpBDVeC8J7uwdbTjEj F1TReYdxIZqBw1x0JU1gmbw7RVCbkA69Y/24Er3X9gdfSLWVa4WbtOovh4UU3JOzc5wT/YLw3qz 78ACgMqzG+4JMJw42q4c2PilaNB85Y5vI5GEWeAiCmPx4NwFkMvWAuahr8sQhKhYApN4wMyrfP9 j+C1SAHAopEd76vtbCMSUcS4h+JoaSyQZPvS53hgVcg0OkHg4Fc0oMvPdrKNF+bjC0xoQ== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-gmpls-pcep-extensions-14: (with DISCUSS and COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 12:23:43 -0000 As a general response, Ben, I would say that PCEP is only catching up = with GMPLS in this document. Thus, everything it is doing wrt bandwidth = has been built for some while in GMPLS RSVP-TE implementations. It is probable that more careful references to the GMPLS signalling RFCs = would address some of your points. Specifically RFC 3473 and RFC 7025. = But I think section 2.3 already does this, so I'm not quite sure where = to make this clarification. FWIW, I have never heard of anyone applying Intserv approaches to GMPLS. = Reservations are not statistical, and in most cases the resources are = physical quantities and assigned directly. Cheers, Adrian -------------- This document makes some well-needed extensions to existing PCEP concepts such as bandwidth, but I'm not convinced that the way they interact with existing PCEP functionality is sufficiently well specified to admit interoperable implementation. Specifically, we introduce the generalized bandwidth structures and reuse that encoding for the generalized load balancing structures, which includes a notion of "minimum bandwidth specification". But now that the bandwidth specification is a compound data structure instead of a scalar type, it's not guaranteed that we have a strict linear ordering with well-defined minimum. If we consider the specific case of Intserv, do I insist upon all three of the minimum bucket rate, minimum bucket size, and minimum peak data rate? Or perhaps I only care about the peak data rate and not the bucket size/rate. We need more text in order to specify what "minimum" actually means/measures. Similarly, I'm not sure all the referenced generalized bandwidth types/traffic parameters in Section 2.3 clearly indicate which structures/fields we are to incorporate by reference (see COMMENT). Section 2.1.2 says: GMPLS-CAPABILITY TLV it is RECOMMENDED that the PCC does not make use of the objects and TLVs defined in this document. Why is this not "the PCC MUST NOT make use of the objects and TLVs defined in this document"? Ignoring the peer's (non-)advertisement and plowing ahead seems like a recipe for non-interoperability. Section 2.5.1 notes that: ::=3D [] [ []]... For endpoint type Point-to-Multipoint, several endpoint objects MAY be present in the message and each represents a leave, exact meaning depend on the endpoint type defined of the object. If all s represent leaves, then how is the head node specified? I couldn't find a full spcification for some of the fields in the XRO Label subobject (Section 2.7) by chasing the indicated references (see COMMENT). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1 Please expand OTN and WSON on first use. Section 1.4 It's very unclear to me what kind of support, from/by what entities/data structures, under what conditions, these tables are attempting to indicate. We should probably be consistent whether we talk about just "FOO" or "FOO object" as the hanging text for these bulleted lists. From [RFC8282]: o SWITCH-LAYER: address requirements (1, 2 and 3) for the TE-LSP and indicates which layer(s) should be considered, can be used to represent the RSVP-TE generalized label request. [...] nit: this looks like a comma splice. The PCEP extensions defined later in this document to cover the gap are: Two new object types are introduced for the BANDWIDTH object (Generalized bandwidth, Generalized bandwidth of existing TE-LSP for which a reoptimization is requested). I'm confused by this language "new object types are introduced for the BANDWIDTH object". My understanding was that objects did not nest: that is, objects have a given structure and can sometimes contain TLVs, but do not contain other objects. So, my current understanding is that new objects are introduced that can appear where the BANDWIDTH object would previously have appeared, but they are separate object (type)s from the RFC 5440 BANDWIDTH objects. (This language is used in the next couple items as well.) To be clear, this is at most an editorial consideration, essentially whether to use "introduced for" or something like "introduced akin to". Section 2.1.2 If the PCE does not include the GMPLS-CAPABILITY TLV in the OPEN message and the PCC does include the TLV, it is RECOMMENDED that the PCC indicates a mismatch of capabilities. Moreover, in case that the PCC does not receive the Indicate how, to whom? Section 2.2 This granularity applies to all links in the path, right? So I can't request label-level granularity for one hop and indicate that I only care about node-level granularity for the other hops? Section 2.3 [similar comments apply here to what I mentioned at the end of Section 1.4] The Bw Spec Type correspond to the RSVP-TE SENDER_TSPEC (Object Class 12) C-Types Should we ask IANA to update the SENDER_TSPEC registry to note that it is used for PCEP as well as RSVP? The encoding of the fields Generalized Bandwidth and Reverse Generalized Bandwidth is the same as the Traffic Parameters carried in RSVP-TE, it can be found in the following references. Object Type Name Reference 2 Intserv [RFC2210] 4 SONET/SDH [RFC4606] 5 G.709 [RFC4328] 6 Ethernet [RFC6003] 7 OTN-TDM [RFC7139] 8 SSON [RFC7792] It's quite confusing to have the table heading be just "object type" when this is the value in the field named "Bw Spec Type" and corresponds to class type values in the SENDER_TSPEC registry. Also, I looked up the Intserv case, and RFC 2210 doesn't really give me a clear picture of what I'm supposed to encode as the "transport parameters". I think it's supposed to be the 12-octet assembly consisting of the token bucket rate, token bucket size, and peak data rate, but I have very low confidence in that assessment. On the other hand, RFC 4606 has a very nice data structure layout in Section 2.1, "SONET/SDH Traffic Parameters". On the gripping hand, there's not a clear "bandwidth" number in that structure that I can apply a comparison to for load-balancing purposes. It doesn't look like I'll have time to check the other four cases right now, but that will need to be done before final publication. Section 2.4 I'm having trouble parsing: The LOAD-BALANCING object [RFC5440] is used to request a set of maximum Max-LSP TE-LSP having in total the bandwidth specified in BANDWIDTH, each TE-LSP having a minimum of bandwidth. Is it intended to read: The LOAD-BALANCING object [RFC5440] is used to request allocation of = a set of at most Max-LSP TE-LSPs, having in total the bandwidth specified in BANDWIDTH, with each TE-LSP having at least a specified minimum = bandwidth. ? [similar comments apply here to what I mentioned at the end of Section 1.4] Bandwidth Spec Length (16 bits): the total length of the Min Bandwidth Spec field. It is to be noted that the RSVP-TE traffic specification MAY also include TLV different from the PCEP TLVs. The length MUST be strictly greater than 0. It's not entirely clear to me why the note about different TLVs in RSVP-TE and PCEP belongs here. Section 2.5.1 Endpoints label restriction may not be part of the RRO or IRO, they can be included when following [RFC4003] in signaling for egress endpoint, but ingress endpoint properties can be local to the PCC and not signaled. [...] nit: the first comma looks like a comma splice. A PCE not supporting a given Endpoint Type SHOULD respond with a PCErr with Error Type 4, Value TBD "Unsupported endpoint type in END-POINTS Generalized Endpoint object type". [...] s/TBD/TBA-15/ The TLVs present in the request object body MUST follow the following [RFC5511] grammar: It feels a bit like a type error to use RBNF to describe the layout of TLVs within a TLV block, as RBNF acts on objects. Section 2.5.2.4 The LABEL-REQUEST TLV indicates the switching capability and encoding type of the following label restriction list for the endpoint. Its format and encoding is the same as described in [RFC3471] Section 3.1 Generalized label request. [...] Presumably the "Its" refers to just the value portion of the TLV? That should probably be stated explicitly. Section 2.5.2.5 Is there any reason for the section title to not be "LABEL-SET TLV" for consistency with the other sections? A LABEL-SET TLV represents a set of possible labels that can be used on an interface. If the L bit is cleared, the label allocated on the first endpoint MUST be within the label set range. [...] Is this MUST binding on the PCC that generates a request, or on the computed LSP returned by the PCE? A LABEL-SET TLV with the O and L bit set MUST trigger a PCErr message with error type=3D"Reception of an invalid object" error = value=3D"Wrong LABEL-SET TLV present with O and L bit set". A LABEL-SET TLV with the O bit set and an Action Field not set to 0 (Inclusive list) or containing more than one subchannel MUST trigger a PCErr message with error type=3D"Reception of an invalid object" error value=3D"Wrong LABEL-SET TLV present with O bit and wrong format". If a LABEL-SET TLV is present with O bit set, the R bit of the RP object MUST be set, otherwise a PCErr message MUST be sent with error type=3D"Reception of an invalid object" error value=3D"LABEL-SET TLV present with O bit set but without R bit set in RP". nit: I don't know if it makes more sense to use the TBA-25, TBA-26, and TBA-24 values in these descriptions. Section 2.6 The IRO as defined in [RFC5440] is used to include specific objects in the path. RSVP-TE allows to include label definition, in order to fulfill requirement 13 of [RFC7025] the IRO needs to support the new subobject type as defined in [RFC3473]: nit: this looks like a comma splice. (A similar construction appears in Section 2.7 as well.) Section 2.7 U (1 bit): see [RFC3471]. C-Type (8 bits): the C-Type of the included Label Object as defined in [RFC3471]. Label: see [RFC3471]. Sorry, where exactly in RFC 3471? I do not see discussion of a U bit or C-Type therein. (Perhaps RFC 3473 was intended? Though, RFC 3473 seems to refer back to 3471 for the U parameter, again without section reference.) Section 6 It seems that a malicious PCC might be able to effect a denial of service attack on the PCE by attempting to make many requests that consume lots of resources (whether on the PCE itself or in the managed network elements). In addition Technology specific data plane mechanism can be used (following [RFC5920] Section 5.8) to verify the data plane connectivity and deviation from constraints. nit: "In addition, technology-specific" Appendix A It's not entirely clear to me why this specific group of examples was chosen and no others. (The appendix does not seem to be referenced from elsewhere in the document, so it appears fairly random to a reader making it that far.) From nobody Thu Apr 11 05:56:27 2019 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 82F061200D8; Thu, 11 Apr 2019 05:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=NAZgXZIY; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=H7/92J/C Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXk2yZEgzqKK; Thu, 11 Apr 2019 05:56:08 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36D6812017B; Thu, 11 Apr 2019 05:56:08 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 537E025F2D; Thu, 11 Apr 2019 08:56:07 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 11 Apr 2019 08:56:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=4 qh0ED2fTNYmWn2kbYJt4nD0KCacjZ1AUtSqm6wro20=; b=NAZgXZIYFsBWf01G1 Qwb9IK9R1fVI2xz2oLscD3Lu54d96ureHjf58pHP95Yqikn3kmcwuCLDlqmTEOHZ kZV0EAj1RtAqnUhrAhApdyQu1HwOK3gOiBJ3cdsl4U6B24IgW1nCGaq9jQFf/Wms +geVf6qcKE6ch0Fx98E1FN8kksiJBysj+eWf8wskXH5s9HRLablfuneZSBMFtIBX 2oGHC9nXYBtKINQCh/wCXuU54GKI3RT2isGGG3QftxTtgrnanEzdQzvNPLuyBwQH ZXeDRxZ3N9uFVW4sSvPv2iY9osaBUw1pjCUj6TeVNOH3GRZMOaDSeSwBecMj9D68 vxPdQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=4qh0ED2fTNYmWn2kbYJt4nD0KCacjZ1AUtSqm6wro 20=; b=H7/92J/C6GJZA5dI65thLNU0+aMcToQMsmcWyrsG4KFLs82cm4ZGifxl5 ojL1gicTGzBCX3e05U9X5+yIhzzbdx0CrPhj5njfpWFm0leUnMhTxc9kHChjbJ0s MEy2sY2e9E7r6oloK52fsykNjYYJ4oxtxjiwovgeORZdgmljioK/cpmNDuvbqPGg DRzqIlgyC5RlSty6EbzFoOCfc6vBbP1nkrAycQmQqyb1o8t2CY1MNf4sZfOBtD2Q dvuz42e937daYnLAI0KTsVHuprQdhVMnwK6dGa/fq63dwwyxQV3TAqFF+x+bTgwI E6YoxiBpePTW0UpCgviKpOchLa3hw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudelgdehlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrdekjeenucfrrghrrghm pehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhushhtvg hrufhiiigvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.87]) by mail.messagingengine.com (Postfix) with ESMTPA id 32928E40FF; Thu, 11 Apr 2019 08:56:06 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <00e701d4d929$326fa0d0$974ee270$@olddog.co.uk> Date: Thu, 11 Apr 2019 08:56:04 -0400 Cc: General Area Review Team , pce@ietf.org, "" , draft-ietf-pce-stateful-pce-p2mp.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <65B74EBD-3D62-458C-91AF-3CC535640EA6@cooperw.in> References: <155242920449.5606.4649488327500115063@ietfa.amsl.com> <00e701d4d929$326fa0d0$974ee270$@olddog.co.uk> To: Adrian Farrel , David Schinazi via Datatracker X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Pce] [Gen-art] Genart last call review of draft-ietf-pce-stateful-pce-p2mp-12 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 12:56:11 -0000 David, thanks for your review. Adrian, thanks for your response. I = entered a No Objection ballot. Alissa > On Mar 12, 2019, at 7:13 PM, Adrian Farrel = wrote: >=20 > Thanks David, >=20 > Subject experts we have. Your review of readability etc. was most = welcome. >=20 > Adrian >=20 > -----Original Message----- > From: David Schinazi via Datatracker =20 > Sent: 12 March 2019 22:20 > To: gen-art@ietf.org > Cc: pce@ietf.org; ietf@ietf.org; = draft-ietf-pce-stateful-pce-p2mp.all@ietf.org > Subject: Genart last call review of = draft-ietf-pce-stateful-pce-p2mp-12 >=20 > Reviewer: David Schinazi > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-pce-stateful-pce-p2mp-12 > Reviewer: David Schinazi > Review Date: 2019-03-12 > IETF LC End Date: 2019-03-20 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: I am not knowledgeable in this domain so this review > only focused on style. Document reads nicely, is well ordered > and defines its terminology clearly. Looks great from a form = perspective. >=20 > Major issues: None >=20 > Minor issues: None >=20 > Nits/editorial comments: None >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Thu Apr 11 07:21:52 2019 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 DB8851200B8; Thu, 11 Apr 2019 07:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snM_F6Oy1Axk; Thu, 11 Apr 2019 07:21:43 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDBFA120033; Thu, 11 Apr 2019 07:21:42 -0700 (PDT) Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id C31CDE420D40A6CFB3AF; Thu, 11 Apr 2019 15:21:40 +0100 (IST) Received: from BLREML405-HUB.china.huawei.com (10.20.4.41) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 11 Apr 2019 15:21:40 +0100 Received: from BLREML503-MBS.china.huawei.com ([169.254.12.125]) by BLREML405-HUB.china.huawei.com ([10.20.4.41]) with mapi id 14.03.0439.000; Thu, 11 Apr 2019 19:51:31 +0530 From: Dhruv Dhody To: Mirja Kuehlewind , Dhruv Dhody CC: "draft-ietf-pce-stateful-pce-p2mp@ietf.org" , "pce@ietf.org" , The IESG , "pce-chairs@ietf.org" Thread-Topic: =?utf-8?B?W1BjZV0gIE1pcmphIEvDvGhsZXdpbmQncyBObyBPYmplY3Rpb24gb24gZHJh?= =?utf-8?B?ZnQtaWV0Zi1wY2Utc3RhdGVmdWwtcGNlLXAybXAtMTI6ICh3aXRoIENPTU1F?= =?utf-8?Q?NT)?= Thread-Index: AQHU6xFvipGui7PqN0CHr83dtl+i56Y2jdSAgAB2D5A= Date: Thu, 11 Apr 2019 14:21:30 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8DA11248@BLREML503-MBS.china.huawei.com> References: <155439625812.30874.11556397385069015051.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.76.252] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pce] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-pce-stateful-pce-p2mp-12=3A_=28with_COMMENT=29?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 14:21:45 -0000 SGkgTWlyamEsIA0KDQpUaGUgZnJhZ21lbnRhdGlvbiBpcyBmb3IgdGhlIFBDRVAgbWVzc2FnZSBh bmQgbm90IGVhY2ggb2JqZWN0LiBSRkM2MDA2IChhbmQgUkZDODMwNikgaW1wbGVtZW50ZWQgdGhp cyB3aXRoIGEgZmxhZyBpbiB0aGUgUlAgb2JqZWN0ICh3aGljaCBpcyBhIE1VU1Qgb2JqZWN0IGlu IHR3byBtZXNzYWdlcyB0aGF0IGFyZSBzdXNjZXB0aWJsZSB0byBmcmFnbWVudGF0aW9uKS4gSW4g dGhpcyBkb2N1bWVudCB3ZSBhZGQgZmxhZyBpbiB0aGUgTFNQIG9iamVjdCAod2hpY2ggaXMgYSBN VVNUIG9iamVjdCBpbiBhbGwgdGhlIDMgbWVzc2FnZXMgdGhhdCBhcmUgc3VzY2VwdGlibGUgdG8g ZnJhZ21lbnRhdGlvbikuICANCg0KU28sIFBDRVAgaGFzIDEzIG1lc3NhZ2VzLCBvZiB3aGljaCA1 IGFyZSBzdXNjZXB0aWJsZSB0byBmcmFnbWVudGF0aW9uLCBhbmQgdGhpcyBpcyBoYW5kbGVkIGJ5 IGZsYWcgaW4gMiBvYmplY3RzLiBFdmVuIGlmIHdlIGNhbWUgdXAgd2l0aCBuZXcgbWVzc2FnZXMg KGFuZCB0aGVyZSBhcmUgbm9uZSBwcm9wb3NlZCBhcyBvZiBub3cpLCBJIGRvbuKAmXQgc2VlIHVz IGFkZGluZyB0aGlzIGZsYWcgaW4gbW9yZSBvYmplY3RzIGFueXRpbWUgaW4gdGhlIG5lYXIgZnV0 dXJlLg0KDQpJIHdpbGwgd2FpdCBmb3Igc2hlcGhlcmQvQUQgZ3VpZGFuY2Ugb24gdGhpcy4gDQoN ClRoYW5rcyEgDQpEaHJ1dg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IFBjZSBbbWFpbHRvOnBjZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWlyamEgS3Vl aGxld2luZA0KPiBTZW50OiAxMSBBcHJpbCAyMDE5IDE3OjQ0DQo+IFRvOiBEaHJ1diBEaG9keSA8 ZGhydXYuaWV0ZkBnbWFpbC5jb20+DQo+IENjOiBkcmFmdC1pZXRmLXBjZS1zdGF0ZWZ1bC1wY2Ut cDJtcEBpZXRmLm9yZzsgcGNlQGlldGYub3JnOyBUaGUgSUVTRw0KPiA8aWVzZ0BpZXRmLm9yZz47 IHBjZS1jaGFpcnNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtQY2VdIE1pcmphIEvDvGhsZXdp bmQncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1wY2UtDQo+IHN0YXRlZnVsLXBjZS1wMm1w LTEyOiAod2l0aCBDT01NRU5UKQ0KPiANCj4gSGkgRGhydXYsDQo+IA0KPiBTb3JyeSBmb3IgbXkg bGF0ZSByZXBseS4gU28geW91ciByZXBseSBhY3R1YWxseSBjb25jZXJucyBtZSBhIGJpdC4NCj4g SW5pdGlhbGx5IHlvdSBzYWlkIHlvdSd2ZSBwdXQgaXQgaW4gb2JqZWN0IGJlY2F1c2UgdGhlcmUg d2FzIG5vDQo+IGV4cGVjdGF0aW9uIHRoYXQgaXMgbWF5IGJlIG5lZWRlZCBieSBvdGhlciBvYmpl Y3RzLiBOb3cgeW91IGhhdmUgYSBzZWNvbmQNCj4gb2JqZWN0IGFuZCB5b3UgZGVmaW5lZCBpdCBh Z2FpbiBvYmplY3Qtc3BlY2lmaWNhbGx5IGJlY2F1c2UgeW91IHNheSBpdOKAmXMNCj4gdG9vIG11 Y2ggb3ZlcmhlYWQgdG8gZGVmaW5lIGEgZ2VuZXJpYyBtZWNoYW5pc21zIGZvciBqdXN0IG9uZSBt b3JlLiBXaWxsDQo+IHlvdSBzYXkgdGhlIHNhbWUgdGhpbmcgYWdhaW4gd2l0aCB0aGUgbmV4dCBv YmplY3QgdGhhdCBuZWVkcw0KPiBmcmFnbWVudGF0aW9uPyBNYXliZSBpdOKAmXMgdGhlIHJpZ2h0 IHRpbWUgbm93IHRvIGFkZCB0aGlzIG1vcmUgZ2VuZXJpY2FsbHkNCj4gdG8gY29tbW9uIGhlYWRl ci4gSSBtZWFuIGl0IHNob3VsZCBiZSBhIHZlcnkgc2hvcnQsIHN0cmFpZ2h0LWZvcndhcmQNCj4g ZHJhZnQuIFdoYXTigJlzIHRoZSBhcmd1bWVudCBmb3Igbm90IGp1c3QgZG9pbmcgaXQgbm93Pw0K PiANCj4gbWlyamENCj4gDQo+IA0KPiANCj4gPiBPbiA0LiBBcHIgMjAxOSwgYXQgMjA6MDcsIERo cnV2IERob2R5IDxkaHJ1di5pZXRmQGdtYWlsLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiBIaSBNaXJq YSwNCj4gPg0KPiA+IE9uIFRodSwgQXByIDQsIDIwMTkgYXQgMTA6MTQgUE0gTWlyamEgS8O8aGxl d2luZCB2aWEgRGF0YXRyYWNrZXINCj4gPiA8bm9yZXBseUBpZXRmLm9yZz4gd3JvdGU6DQo+ID4+ DQo+ID4+IE1pcmphIEvDvGhsZXdpbmQgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3Qg cG9zaXRpb24gZm9yDQo+ID4+IGRyYWZ0LWlldGYtcGNlLXN0YXRlZnVsLXBjZS1wMm1wLTEyOiBO byBPYmplY3Rpb24NCj4gPj4NCj4gPj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUg c3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQo+ID4+IGVtYWlsIGFkZHJlc3Nl cyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dA0KPiA+ PiB0aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiA+Pg0KPiA+Pg0KPiA+ PiBQbGVhc2UgcmVmZXIgdG8NCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1l bnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+ID4+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0 IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+ID4+DQo+ID4+DQo+ID4+IFRo ZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91 bmQgaGVyZToNCj4gPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1wY2Utc3RhdGVmdWwtcGNlLXAybXAvDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiA+PiAtDQo+ID4+IENPTU1FTlQ6DQo+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+PiAtDQo+ ID4+DQo+ID4+IEp1c3QgYSBxdWljayBjbGFyaWZpY2F0aW9uIHF1ZXN0aW9uIG9uIGZyYWdtZW50 YXRpb246IEknbSB3b25kZXJpbmcNCj4gPj4gaWYgaXQgaXMgcmVhbGx5IG5lY2Vzc2FyeSB0byBk ZWZpbmUgYSBmcmFnbWVudGF0aW9uIG1lY2hhbmlzbS9iaXQgZm9yDQo+ID4+IGVhY2ggb2JqZWN0 IHNlcGFyYXRlbHkgKGUuZyBhbHNvIFJGQzgzMDYpIG9yIGlmIGl0IHdvdWxkIGJlIG1vcmUNCj4g Pj4gYXBwcm9wcmlhdGUgdG8gYWxsb2NhdGUgb25lIGJpdCBpbiB0aGUgY29tbW9uIGhlYWRlcj8g SnVzdCBhc2tpbmcgYXMNCj4gSSdtIHJlYWxseSBub3QgYW4gZXhwZXJ0IGhlcmUuLi4NCj4gPj4N Cj4gPj4NCj4gPg0KPiA+IFRoZSBuZWVkIGZvciBmcmFnbWVudGF0aW9uIHdhcyBmb3VuZCB3aGVu IHRoZSBzdXBwb3J0IGZvciBQMk1QIFRFIHdhcw0KPiA+IGludHJvZHVjZWQgaW4gUkZDNjAwNi4g QXQgdGhhdCB0aW1lIG9ubHkgdHdvIFBDRVAgbWVzc2FnZSB3ZXJlDQo+ID4gc3VzY2VwdGlibGUg dG8gZnJhZ21lbnRhdGlvbiAoUENSZXEgJiBQQ1JlcCkgYW5kIHRoZSBjaG9pY2Ugd2FzIG1hZGUN Cj4gPiB0byBhZGQgYSBmbGFnIGluIGEgUlAgb2JqZWN0LiBUaGUgY2hvaWNlIG1hZGUgYXQgdGhh dCB0aW1lIHdhcyB0aGF0DQo+ID4gdGhlIG90aGVyIG1lc3NhZ2VzIHNob3VsZCBub3QgYmUgZnJh Z21lbnRlZC4NCj4gPg0KPiA+IExhdGVyIFBDRVAgYWRkZWQgbW9yZSBtZXNzYWdlcyB0byBzdXBw b3J0IHN0YXRlZnVsIG9wZXJhdGlvbi4gQW5kIHdpdGgNCj4gPiB0aGlzIEktRCB3ZSBleHRlbmQg c3VwcG9ydCB0byBQMk1QIExTUCB3aGVyZSBmcmFnbWVudGF0aW9uIGhhbmRsaW5nDQo+ID4gd2Fz IHJlcXVpcmVkICh3ZSBhZGRlZCB0aGUgZmxhZyBpbiB0aGUgTFNQIG9iamVjdCkuDQo+ID4NCj4g PiBZb3UgYXJlIGNvcnJlY3QhIFdlIGNvdWxkIGhhdmUgdXNlZCB0aGUgUENFUCBjb21tb24gbWVz c2FnZSBoZWFkZXIgYW5kDQo+ID4gc2FpZCB0aGF0IHRoZSBmbGFnIGlzIGFwcGxpY2FibGUgZm9y IHRoZSBzdWJzZXQgb2YgbWVzc2FnZXMuIEJ1dCB0aGUNCj4gPiBkZXNpZ24gY2hvaWNlIGhlcmUg d2FzIHRvIGtlZXAgY29uc2lzdGVudCB3aXRoIHRlY2huaXF1ZSBhbHJlYWR5IGluDQo+ID4gcGxh Y2UuIEZyYWdtZW50YXRpb24gZmxhZyBpbiAyIG9iamVjdHMgaXNuJ3QgYWxsIHRoYXQgYmFkLg0K PiA+DQo+ID4gVGhhbmtzIGZvciB5b3VyIHJldmlldyENCj4gPiBEaHJ1dg0KPiA+DQo+ID4NCj4g DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFBj ZSBtYWlsaW5nIGxpc3QNCj4gUGNlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcGNlDQo= From nobody Thu Apr 11 09:48:51 2019 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 E4AFB1206B1; Thu, 11 Apr 2019 09:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeTkxQ1DwkCj; Thu, 11 Apr 2019 09:48:40 -0700 (PDT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2DC61203B7; Thu, 11 Apr 2019 09:48:40 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id z9so3767932pgu.10; Thu, 11 Apr 2019 09:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7xF/ZNz5ehbcptZZ/ZwXlO0JCR1NvDkhRISvvWwPFjk=; b=K+NqTf4adgRpHgu1J+gcrgiH/gLMleR0jwQEjnGd7aLECYSzmoK4y9aMsIVOPfVoVu FXJM/YPSE71x+T6VL16ja3k42uy/CVzA9PDTPNTSG+a6SntDXRcpn2xuAVFWwTZnhQF0 thM7MnFuPr8D24t1UtzNxcgZleXYUDsbd0wZPKD4J8drWbZTQh+TPYRdGIDvj5W4lLjl vf5Day5/1/YGNui6Ty3OgqSrUgOfTQZPSSrCFqpQqJ7nT9pOHh57YxXkW81HcvwfXSfj ESxD89kBnXG80RHV7KDZ4/kP7MzTnqs1ZAeOyW6THulQA7/DCh//Et9RHtuU2TWIbRw5 RbJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=7xF/ZNz5ehbcptZZ/ZwXlO0JCR1NvDkhRISvvWwPFjk=; b=sofiKZNsRdlBcXuFqyC8GnRJTmWOKjIZoA1RueTtbCvF8cWOeuDQVsmpM7MaV2YZNY JcJ42ZswVT140sX2s/YfBhG1S5eI2/TL4BqG2H0MTTj+15dqfyVCL58xdtTdj6a9TJem 7CRUNS6MxxCAseGCbavgCV5K5mLvDlmrHobXW9rx9cvgzS34hKa7H4rzltEjj2M1V2/5 8yasadwweTTzA6rFCpGOTdNKYYXTXfwT335187L8MCG/AuOGwLYUXaHkor1wKAZg6vlH X6wTsSAp+L5z9hZe5/qQr+KzpZ3ogmKvbqe12KkwkLZOZOSwNZmjmJ2QyKBRCYaypbgE E1WQ== X-Gm-Message-State: APjAAAW2WPExt8wwMX/7n7qRcjgVV6Et3KAyfHIpb9p1VXGTfpkOw65k gLhwtRPc29CI1TNzC+L4Rnal5Eqc X-Google-Smtp-Source: APXvYqyxNsdTPPMK0rueq3PRVl2z2+ommSmbaAy9zw1pLVvM71j2RRgUJ5GF+dRzrEE5LKS/ZLBGVg== X-Received: by 2002:a63:2015:: with SMTP id g21mr47148013pgg.226.1555001320173; Thu, 11 Apr 2019 09:48:40 -0700 (PDT) Received: from cbarth-mbp.jnpr.net ([66.129.241.14]) by smtp.gmail.com with ESMTPSA id 17sm53110965pgz.52.2019.04.11.09.48.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Apr 2019 09:48:39 -0700 (PDT) From: Colby Barth Message-Id: <1EE97E79-AF23-4A38-94F1-A76814CF7BE4@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_74E842B4-F389-4D17-A6E0-34D118C8A5CD" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Thu, 11 Apr 2019 12:48:36 -0400 In-Reply-To: Cc: draft-ietf-pce-stateful-path-protection@ietf.org, pce@ietf.org To: Hariharan Ananthakrishnan References: X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Pce] IPR poll on draft-ietf-pce-stateful-path-protection X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 16:48:49 -0000 --Apple-Mail=_74E842B4-F389-4D17-A6E0-34D118C8A5CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am not aware of any IPR applicable to this draft that should be = disclosed in accordance with IETF IPR rules. -Colby > On Apr 9, 2019, at 10:57 PM, Hariharan Ananthakrishnan = wrote: >=20 > Hi authors, >=20 > In preparation for Working Group last call on this draft, I'd like all > authors and contributors to confirm on the list that they are in = compliance > with IETF IPR rules. >=20 > Please respond (copying the mailing list) to say one of: >=20 > I am not aware of any IPR applicable to this draft that should be = disclosed > in accordance with IETF IPR rules. >=20 > I am aware of IPR applicable to this draft, and it has already been > disclosed to the IETF. >=20 > I am aware of IPR applicable to this draft, but that has not yet been > disclosed to the IETF. I will work to ensure that it will be disclosed = in a > timely manner. >=20 > Thanks, > - Hari > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce --Apple-Mail=_74E842B4-F389-4D17-A6E0-34D118C8A5CD Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii 
I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.
-Colby

On Apr 9, 2019, at 10:57 PM, Hariharan Ananthakrishnan <hari=40netflix.com@dmarc.ietf.org> wrote:

Hi authors,

In preparation for Working Group last call on this draft, I'd like all
authors and contributors to confirm on the list that they are in compliance
with IETF IPR rules.

Please respond (copying the mailing list) to say one of:

I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.

I am aware of IPR applicable to this draft, and it has already been
disclosed to the IETF.

I am aware of IPR applicable to this draft, but that has not yet been
disclosed to the IETF. I will work to ensure that it will be disclosed in a
timely manner.

Thanks,
- Hari
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

--Apple-Mail=_74E842B4-F389-4D17-A6E0-34D118C8A5CD-- From nobody Thu Apr 11 11:49:12 2019 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 6682712030F; Thu, 11 Apr 2019 11:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JZWKEOV5Wsy; Thu, 11 Apr 2019 11:48:48 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BB83120366; Thu, 11 Apr 2019 11:48:47 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x3BImgfD016025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Apr 2019 14:48:45 -0400 Date: Thu, 11 Apr 2019 13:48:42 -0500 From: Benjamin Kaduk To: Adrian Farrel Cc: "'The IESG'" , draft-ietf-pce-gmpls-pcep-extensions@ietf.org, "'Julien Meuric'" , pce-chairs@ietf.org, pce@ietf.org Message-ID: <20190411184842.GN18549@kduck.mit.edu> References: <155498315544.12722.1073746104492266680.idtracker@ietfa.amsl.com> <046301d4f061$646ee470$2d4cad50$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <046301d4f061$646ee470$2d4cad50$@olddog.co.uk> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-gmpls-pcep-extensions-14: (with DISCUSS and COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 18:48:52 -0000 On Thu, Apr 11, 2019 at 01:23:37PM +0100, Adrian Farrel wrote: > As a general response, Ben, I would say that PCEP is only catching up with GMPLS in this document. Thus, everything it is doing wrt bandwidth has been built for some while in GMPLS RSVP-TE implementations. > > It is probable that more careful references to the GMPLS signalling RFCs would address some of your points. Specifically RFC 3473 and RFC 7025. But I think section 2.3 already does this, so I'm not quite sure where to make this clarification. (I only see it referencing 7025 but not 3473.) And it looks like only the LOAD-BALANCING object, that tries to enforce that the component TE-LSPs each contribute some minmium bandwidth, is going to require much thinking. Any other text changes on this point ought to be fairly mechanical. > FWIW, I have never heard of anyone applying Intserv approaches to GMPLS. Reservations are not statistical, and in most cases the resources are physical quantities and assigned directly. My main complaint here is that we're going from a scalar bandwidth number, that can use regular arithmetic comparisons (trichotomy) and have a clear sense of whether a minimum threshold value is achieved, to a more complicated structure (a mathematician might think of it as a vector space), where we no longer have a single clear metric or trichotomy comparison between different vectors in the space. If we said that, even though the generalized bandwidth structure is this larger "vector" thing, the load-balancing object was going to still just use a single scalar for minimum bandwidth (and we defined how to compute the scalar bandwidth from a given generalized bandwidth structure/vector), this issue would evaporate. The problem arises when we take the same generalized bandwidth structure and try to use it (the structure/vector) as the minimum threshold value. Do I compare the components piece by piece and require each individual component to surpass the stated minimum? That is well-defined in a procedural sense but may not make practical sense for all the generalized bandwidth structures defined now or in the future. -Ben > Cheers, > Adrian > > -------------- > > This document makes some well-needed extensions to existing PCEP > concepts such as bandwidth, but I'm not convinced that the way they > interact with existing PCEP functionality is sufficiently well specified > to admit interoperable implementation. Specifically, we introduce the > generalized bandwidth structures and reuse that encoding for the > generalized load balancing structures, which includes a notion of > "minimum bandwidth specification". But now that the bandwidth > specification is a compound data structure instead of a scalar type, > it's not guaranteed that we have a strict linear ordering with > well-defined minimum. If we consider the specific case of Intserv, do I > insist upon all three of the minimum bucket rate, minimum bucket size, > and minimum peak data rate? Or perhaps I only care about the peak data > rate and not the bucket size/rate. We need more text in order to > specify what "minimum" actually means/measures. > > Similarly, I'm not sure all the referenced generalized bandwidth > types/traffic parameters in Section 2.3 clearly indicate which > structures/fields we are to incorporate by reference (see COMMENT). > > Section 2.1.2 says: > > GMPLS-CAPABILITY TLV it is RECOMMENDED that the PCC does not make use > of the objects and TLVs defined in this document. > > Why is this not "the PCC MUST NOT make use of the objects and TLVs > defined in this document"? Ignoring the peer's (non-)advertisement and > plowing ahead seems like a recipe for non-interoperability. > > Section 2.5.1 notes that: > > ::= > [] > [ []]... > > > For endpoint type Point-to-Multipoint, several endpoint objects MAY > be present in the message and each represents a leave, exact meaning > depend on the endpoint type defined of the object. > > If all s represent leaves, then how is the head node > specified? > > I couldn't find a full spcification for some of the fields in the XRO > Label subobject (Section 2.7) by chasing the indicated references (see > COMMENT). > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 1 > > Please expand OTN and WSON on first use. > > Section 1.4 > > It's very unclear to me what kind of support, from/by what entities/data > structures, under what conditions, these tables are attempting to > indicate. > > We should probably be consistent whether we talk about just "FOO" or > "FOO object" as the hanging text for these bulleted lists. > > From [RFC8282]: > > o SWITCH-LAYER: address requirements (1, 2 and 3) for the TE-LSP and > indicates which layer(s) should be considered, can be used to > represent the RSVP-TE generalized label request. [...] > > nit: this looks like a comma splice. > > The PCEP extensions defined later in this document to cover the gap > are: > > Two new object types are introduced for the BANDWIDTH object > (Generalized bandwidth, Generalized bandwidth of existing TE-LSP > for which a reoptimization is requested). > > I'm confused by this language "new object types are introduced for the > BANDWIDTH object". My understanding was that objects did not nest: that > is, objects have a given structure and can sometimes contain TLVs, but > do not contain other objects. So, my current understanding is that new > objects are introduced that can appear where the BANDWIDTH object would > previously have appeared, but they are separate object (type)s from the > RFC 5440 BANDWIDTH objects. (This language is used in the next couple > items as well.) To be clear, this is at most an editorial > consideration, essentially whether to use "introduced for" or something > like "introduced akin to". > > Section 2.1.2 > > If the PCE does not > include the GMPLS-CAPABILITY TLV in the OPEN message and the PCC does > include the TLV, it is RECOMMENDED that the PCC indicates a mismatch > of capabilities. Moreover, in case that the PCC does not receive the > > Indicate how, to whom? > > Section 2.2 > > This granularity applies to all links in the path, right? So I can't > request label-level granularity for one hop and indicate that I only > care about node-level granularity for the other hops? > > Section 2.3 > > [similar comments apply here to what I mentioned at the end of Section > 1.4] > > The Bw Spec Type correspond to the RSVP-TE SENDER_TSPEC (Object Class > 12) C-Types > > Should we ask IANA to update the SENDER_TSPEC registry to note that it > is used for PCEP as well as RSVP? > > The encoding of the fields Generalized Bandwidth and Reverse > Generalized Bandwidth is the same as the Traffic Parameters carried > in RSVP-TE, it can be found in the following references. > > Object Type Name Reference > > 2 Intserv [RFC2210] > 4 SONET/SDH [RFC4606] > 5 G.709 [RFC4328] > 6 Ethernet [RFC6003] > 7 OTN-TDM [RFC7139] > 8 SSON [RFC7792] > > It's quite confusing to have the table heading be just "object type" > when this is the value in the field named "Bw Spec Type" and corresponds > to class type values in the SENDER_TSPEC registry. > > Also, I looked up the Intserv case, and RFC 2210 doesn't really give me > a clear picture of what I'm supposed to encode as the "transport > parameters". I think it's supposed to be the 12-octet assembly > consisting of the token bucket rate, token bucket size, and peak data > rate, but I have very low confidence in that assessment. On the other > hand, RFC 4606 has a very nice data structure layout in Section 2.1, > "SONET/SDH Traffic Parameters". On the gripping hand, there's not a > clear "bandwidth" number in that structure that I can apply a comparison > to for load-balancing purposes. It doesn't look like I'll have time to > check the other four cases right now, but that will need to be done > before final publication. > > Section 2.4 > > I'm having trouble parsing: > > The LOAD-BALANCING object [RFC5440] is used to request a set of > maximum Max-LSP TE-LSP having in total the bandwidth specified in > BANDWIDTH, each TE-LSP having a minimum of bandwidth. > > Is it intended to read: > > The LOAD-BALANCING object [RFC5440] is used to request allocation of a set of > at most Max-LSP TE-LSPs, having in total the bandwidth specified in > BANDWIDTH, with each TE-LSP having at least a specified minimum bandwidth. > > ? > > [similar comments apply here to what I mentioned at the end of Section > 1.4] > > Bandwidth Spec Length (16 bits): the total length of the Min > Bandwidth Spec field. It is to be noted that the RSVP-TE traffic > specification MAY also include TLV different from the PCEP TLVs. The > length MUST be strictly greater than 0. > > It's not entirely clear to me why the note about different TLVs in > RSVP-TE and PCEP belongs here. > > Section 2.5.1 > > Endpoints label restriction may not be part of the RRO or > IRO, they can be included when following [RFC4003] in signaling for > egress endpoint, but ingress endpoint properties can be local to the > PCC and not signaled. [...] > > nit: the first comma looks like a comma splice. > > A PCE not supporting a given Endpoint Type SHOULD > respond with a PCErr with Error Type 4, Value TBD "Unsupported > endpoint type in END-POINTS Generalized Endpoint object type". [...] > > s/TBD/TBA-15/ > > The TLVs present in the > request object body MUST follow the following [RFC5511] grammar: > > It feels a bit like a type error to use RBNF to describe the layout > of TLVs within a TLV block, as RBNF acts on objects. > > Section 2.5.2.4 > > The LABEL-REQUEST TLV indicates the switching capability and encoding > type of the following label restriction list for the endpoint. Its > format and encoding is the same as described in [RFC3471] Section 3.1 > Generalized label request. [...] > > Presumably the "Its" refers to just the value portion of the TLV? > That should probably be stated explicitly. > > Section 2.5.2.5 > > Is there any reason for the section title to not be "LABEL-SET TLV" for > consistency with the other sections? > > A LABEL-SET TLV represents a set of possible labels that can be used > on an interface. If the L bit is cleared, the label allocated on the > first endpoint MUST be within the label set range. [...] > > Is this MUST binding on the PCC that generates a request, or on the > computed LSP returned by the PCE? > > A LABEL-SET TLV with the O and L bit set MUST trigger a PCErr message > with error type="Reception of an invalid object" error value="Wrong > LABEL-SET TLV present with O and L bit set". > > A LABEL-SET TLV with the O bit set and an Action Field not set to 0 > (Inclusive list) or containing more than one subchannel MUST trigger > a PCErr message with error type="Reception of an invalid object" > error value="Wrong LABEL-SET TLV present with O bit and wrong > format". > > If a LABEL-SET TLV is present with O bit set, the R bit of the RP > object MUST be set, otherwise a PCErr message MUST be sent with error > type="Reception of an invalid object" error value="LABEL-SET TLV > present with O bit set but without R bit set in RP". > > nit: I don't know if it makes more sense to use the TBA-25, TBA-26, and > TBA-24 values in these descriptions. > > Section 2.6 > > The IRO as defined in [RFC5440] is used to include specific objects > in the path. RSVP-TE allows to include label definition, in order to > fulfill requirement 13 of [RFC7025] the IRO needs to support the new > subobject type as defined in [RFC3473]: > > nit: this looks like a comma splice. (A similar construction appears in > Section 2.7 as well.) > > Section 2.7 > > U (1 bit): see [RFC3471]. > > C-Type (8 bits): the C-Type of the included Label Object as > defined in [RFC3471]. > > Label: see [RFC3471]. > > Sorry, where exactly in RFC 3471? I do not see discussion of a U bit > or C-Type therein. (Perhaps RFC 3473 was intended? Though, RFC 3473 > seems to refer back to 3471 for the U parameter, again without section > reference.) > > Section 6 > > It seems that a malicious PCC might be able to effect a denial of > service attack on the PCE by attempting to make many requests that > consume lots of resources (whether on the PCE itself or in the managed > network elements). > > In addition Technology specific data plane mechanism > can be used (following [RFC5920] Section 5.8) to verify the data > plane connectivity and deviation from constraints. > > nit: "In addition, technology-specific" > > Appendix A > > It's not entirely clear to me why this specific group of examples was > chosen and no others. (The appendix does not seem to be referenced from > elsewhere in the document, so it appears fairly random to a reader > making it that far.) > > From nobody Thu Apr 11 12:50:57 2019 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 0A1ED120603; Thu, 11 Apr 2019 12:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EeEw6jGhCmQN; Thu, 11 Apr 2019 12:50:47 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1748B120183; Thu, 11 Apr 2019 12:50:46 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x3BJobMY008534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Apr 2019 15:50:39 -0400 Date: Thu, 11 Apr 2019 14:50:36 -0500 From: Benjamin Kaduk To: Dhruv Dhody Cc: The IESG , "draft-ietf-pce-stateful-pce-p2mp@ietf.org" , "pce@ietf.org" , "pce-chairs@ietf.org" Message-ID: <20190411195036.GU18549@kduck.mit.edu> References: <155486089608.19649.9617345506233285248.idtracker@ietfa.amsl.com> <23CE718903A838468A8B325B80962F9B8DA0F235@BLREML503-MBS.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23CE718903A838468A8B325B80962F9B8DA0F235@BLREML503-MBS.china.huawei.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-stateful-pce-p2mp-12: (with DISCUSS and COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 19:50:50 -0000 On Wed, Apr 10, 2019 at 06:16:17AM +0000, Dhruv Dhody wrote: > Hi Benjamin, > > Thank you for your review. > > Working Copy: https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-stateful-pce-p2mp-13.txt > Diff: https://tools.ietf.org/rfcdiff?url1=draft-ietf-pce-stateful-pce-p2mp-12&url2=https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-stateful-pce-p2mp-13.txt > > More inline... > > > -----Original Message----- > > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Benjamin Kaduk via > > Datatracker > > Sent: 10 April 2019 07:18 > > To: The IESG > > Cc: draft-ietf-pce-stateful-pce-p2mp@ietf.org; pce@ietf.org; pce- > > chairs@ietf.org > > Subject: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-stateful-pce- > > p2mp-12: (with DISCUSS and COMMENT) > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-pce-stateful-pce-p2mp-12: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-p2mp/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > This is a comparatively minor point, but I don't think some of the message > > layout is quite fully specified. In particular, Section 7.2 discusses > > some new TLVs (in a confusing way, referring to the class of two TLVs as a > > single nonexistent TLV) but does not always say which object the TLVs are > > allowed to appear within. (The first paragraph seems to talk of the TLV > > appearing in a PCRpt, which is a message and as such would contain only > > objects and not TLVs directly.) The second paragraph does mention the LSP > > object, which leads the reader to infer that this TLV is only intended to > > appear in the LSP object, and only in the PCRpt and PCUpd messages > > explicitly mentioned, but we probably shouldn't force readers to make that > > leap. > > > > > [[Dhruv Dhody]] I have made following changes - I read the linked diff; these changes are very helpful and will resolve my DISCUSS point -- thank you! > - Made 7.2 (P2MP-LSP-IDENTIFIERS TLV) as a sub-section of 7.1, making it clear that it is part of LSP object > - Added this text at the start > > [RFC8231] specify the LSP-IDENTIFIERS TLVs to be included in the LSP > object. For P2MP TE LSP, this document defines P2MP-LSP-IDENTIFIERS > TLVs for the LSP object. There are two P2MP-LSP-IDENTIFIERS TLVs, > one for IPv4 and one for IPv6. > > - I further clarified > The P2MP-LSP-IDENTIFIERS TLV MUST be > included in the LSP object in PCRpt message for P2MP TE LSPs. If the > N bit is set in the LSP object in the PCRpt message but the P2MP-LSP- > IDENTIFIER TLV is absent, the PCE MUST respond with a PCErr message > carrying error-type 6 ("mandatory object missing") and error-value 14 > (early allocated by IANA) ("P2MP-LSP-IDENTIFIER TLV missing") and > close the PCEP session. > > The P2MP-LSP-IDENTIFIERS TLV MAY be included in the LSP object in the > PCUpd message for P2MP TE LSPs. The special value of all zeros for > all the fields in the value portion of the TLV is used to refer to > all paths pertaining to a particular PLSP-ID. The length of the TLV > remains fixed based on the IP version. > > The P2MP-LSP-IDENTIFIERS TLV SHOULD NOT be used in PCInitiate (see > Section 5.6.3.1) and MAY optionally be included in the LSP object in > the PCReq and the PCRep message for P2MP TE LSP. > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I've made a lot of comments about grammar nits (tagged as such), but there > > are also some more substantial comments to look for. > > > > Section 1 > > > > [RFC4875] describes how to set up point-to-multipoint (P2MP) Traffic > > Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol > > Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The > > PCE has been identified as a suitable application for the computation > > of paths for P2MP TE LSPs ([RFC5671]). > > > > nit: some readers might wonder who has done this identification. > > > [[Dhruv Dhody]] Reworded > > [RFC5671] examines the applicability of PCE for the path computation > for P2MP TE LSPs. > > > > > > Section 6.1 > > > > Was it a conscious decision to depart from RFC 8231 and inline objects in > > the definition of (as opposed to keeping the > > intermediate construction)? > > > > [[Dhruv Dhody]] Fixed > > Section 6.1 > > When reporting the status of a P2MP TE LSP, the destinations MUST be > > grouped in END-POINTS object based on the operational status (O field > > in S2LS object) and leaf type (in END-POINTS). This way, leaves of > > the same type that share the same operational status are grouped > > together. [...] > > > > Does this mean that it's an error for a PCRpt message to include more than > > one END-POINTS object with a given value of leaf-type? If so, it may be > > worth stating that explicitly. > > [[Dhruv Dhody]] No, one can have more than one END-POINTS object with the same leaf-type. There is no such restriction. Maybe I am misunderstanding something, but the "are grouped together" implied to me that it was always the case. Is this just an optional thing for efficiency, in which case "can be grouped together" might be more appropriate? > > > > > Note that the compatibility with the [RFC8231] definition of > report> is preserved. At least one instance of MUST be > > present in this message for P2MP LSP. > > > > Interestingly, RFC 8231 does not spell the structure of the PCRpt message > > using an object. > > > > Section 6.2 > > > > Note that the compatibility with the [RFC8231] definition of > request> is preserved. > > > > If I'm reading this right, compatibility is only preserved when > POINTS> is omitted (and the list only has a single endpoint/path pair). > > Perhaps some more text could be added about the nature of the provided > > (and needed) compatibility? > > > [[Dhruv Dhody]] The compatibility is in the fact that a P2P TE LSP encoded as per RFC8231, would pass the above RBNF check. The same wording is used in RFC 8306 (section 3.4). Okay, thanks. (I think I had not quite internalized everything by this point in the document, when I was reading.) > > > Section 6.6.2 > > > > The LSP State Report message is sent by a PCC to report or delegate > > the P2MP TE LSPs. An example of a PCRpt message for a delegated P2MP > > TE LSPs is described below to add new leaves to an existing P2MP TE > > > > nit: "TE LSP" > > > > It might be handy to mention inline "for leaf type 1 (add)" and "leaf type > > 2 (remove)" just to refresh the reader's memory. > > > [[Dhruv Dhody]] I have added this instead - > > The leaves of the P2MP TE LSP are grouped in the > END-POINTS object based on the operational status and the leaf-type. Sorry, I don't think I conveyed my point very well. I was suggesting that the examples would look like: Common Header LSP with P2MP flag set END-POINTS for leaf type 1 (add) S2LS (O=DOWN) ERO list (empty) But maybe everyone who is going to read this already knows that and it's not worth the bother of changing. > > Section 7.1 > > > > The flags defined in this section (N, F, E flags) are used in PCRpt, > > PCUpd, or PCInitiate message. In case of PCReq and PCRep message, > > these flags have no meaning and thus MUST be ignored. The > > corresponding flags in the RP (Request Parameters) object are used as > > described in [RFC8231]. > > > > I'm not really finding much discussion of RP flags in RFC 8231 (as opposed > > to SRP, in Section 7.2 thereof). RFC 5440 does define a few flags for the > > RP object, though. > > > [[Dhruv Dhody]] It should be RFC8306, thanks for spotting this mixup. > > > Section 7.2 > > > > I strongly suggest changing the initial language to make it clear that > > there is not a single P2MP-LSP-IDENTIFIER TLV, but rather a class of two > > related TLVs that serve to identify P2MP LSPs, e.g., by referring to "P2MP > > LSP Identification TLVs" (without hyphenation or all-caps). > > > [[Dhruv Dhody]] I want to avoid making this change to remain consistent with RFC8231 (Section 7.3.1. LSP-IDENTIFIERS TLVs) but I have added clarifying text (see DISCUSS). Okay. With the clarifying text you added there is much less chance of confusion. > > > > The P2MP-LSP-IDENTIFIERS TLV MAY be included in the LSP object in the > > PCUpd message for P2MP TE LSPs. The special value of all zeros for > > this TLV is used to refer to all paths pertaining to a particular > > PLSP-ID. > > > > Given that we haven't specialized into the IP version-specific TLVs yet, I > > agree with the previous comments that we need greater clarity on what the > > "value of all zeros" means, here. Additionally, is that special value > > supposed to be restricted to the given IP version or literally all paths, > > so that there are two functionally equivalent encodings for these > > semantics? > > > [[Dhruv Dhody]] Updated text is - > > 7.1.1. P2MP-LSP-IDENTIFIERS TLV > > [RFC8231] specify the LSP-IDENTIFIERS TLVs to be included in the LSP > object. For P2MP TE LSP, this document defines P2MP-LSP-IDENTIFIERS > TLVs for the LSP object. There are two P2MP-LSP-IDENTIFIERS TLVs, > one for IPv4 and one for IPv6. The P2MP-LSP-IDENTIFIERS TLV MUST be > included in the LSP object in PCRpt message for P2MP TE LSPs. If the > N bit is set in the LSP object in the PCRpt message but the P2MP-LSP- > IDENTIFIER TLV is absent, the PCE MUST respond with a PCErr message > carrying error-type 6 ("mandatory object missing") and error-value 14 > (early allocated by IANA) ("P2MP-LSP-IDENTIFIER TLV missing") and > close the PCEP session. > > The P2MP-LSP-IDENTIFIERS TLV MAY be included in the LSP object in the > PCUpd message for P2MP TE LSPs. The special value of all zeros for > all the fields in the value portion of the TLV is used to refer to > all paths pertaining to a particular PLSP-ID. The length of the TLV > remains fixed based on the IP version. > > Since I have moved the text introducing the two TLVs to the first para, I hope this is enough to clear up any confusion. That's a big help, yes. I'm still not sure whether there's any practical impact (other than message size!) of using an all-zeroes IPv4 TLV vs. an all-zeros IPv6 TLV, but that may be too nit-picky to worry about. Thanks again, Ben > > > Thanks again for your detailed review. > > Thanks! > Dhruv > From nobody Thu Apr 11 13:59:43 2019 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 7B1B7120198; Thu, 11 Apr 2019 13:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzv9ENB6YG1f; Thu, 11 Apr 2019 13:59:33 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20137.outbound.protection.outlook.com [40.107.2.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF1C71206E4; Thu, 11 Apr 2019 13:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VG7uvTf4N+FHwl9636v5CLIMamr/w8f9BvDu6jUTe8o=; b=FgxhKWB9NduE3259ahr/qVTE7Ew4dRmwnfLk3VEy3+8kmNsTILa85QR/3doT6YIDh3BicAJ3z1V42oA7ovy7lhnpbZLmY/pT9WNUZItBWk0SFq/Ec/erbXZq5VaPj88lJxKJTfHHjztfq9um5j02jAYqqj0pCZIeE/U4bABEAvs= Received: from DB7PR07MB4999.eurprd07.prod.outlook.com (20.177.193.88) by DB7PR07MB4732.eurprd07.prod.outlook.com (52.135.136.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.10; Thu, 11 Apr 2019 20:59:30 +0000 Received: from DB7PR07MB4999.eurprd07.prod.outlook.com ([fe80::ac3e:c6bf:1d97:41a1]) by DB7PR07MB4999.eurprd07.prod.outlook.com ([fe80::ac3e:c6bf:1d97:41a1%2]) with mapi id 15.20.1792.009; Thu, 11 Apr 2019 20:59:25 +0000 From: "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" To: "adrian@olddog.co.uk" , "draft-ietf-pce-gmpls-pcep-extensions@ietf.org" CC: 'The IESG' , 'Julien Meuric' , "pce-chairs@ietf.org" , "pce@ietf.org" Thread-Topic: Martin Vigoureux's Discuss on draft-ietf-pce-gmpls-pcep-extensions-14: (with DISCUSS) Thread-Index: AQHU8KlxzRMVzm0OKU+NdCj0zEhNuQ== Date: Thu, 11 Apr 2019 20:59:25 +0000 Message-ID: <6f7c6b53-ea84-0662-95ad-5e9a7c3f8d79@nokia.com> References: <155498207568.12802.3705482162496355990.idtracker@ietfa.amsl.com> <045201d4f05e$3cddfc00$b699f400$@olddog.co.uk> In-Reply-To: <045201d4f05e$3cddfc00$b699f400$@olddog.co.uk> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.228.2.20] user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 x-clientproxiedby: PR2PR09CA0020.eurprd09.prod.outlook.com (2603:10a6:101:16::32) To DB7PR07MB4999.eurprd07.prod.outlook.com (2603:10a6:10:5d::24) authentication-results: spf=none (sender IP is ) smtp.mailfrom=martin.vigoureux@nokia.com; x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7e7de625-97c6-4826-4966-08d6bec09415 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:DB7PR07MB4732; x-ms-traffictypediagnostic: DB7PR07MB4732: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 00046D390F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(39860400002)(346002)(136003)(396003)(199004)(189003)(13464003)(105586002)(2616005)(486006)(476003)(25786009)(71190400001)(6512007)(99286004)(11346002)(446003)(5660300002)(106356001)(53546011)(6506007)(386003)(97736004)(316002)(31686004)(102836004)(54906003)(110136005)(52116002)(58126008)(76176011)(66066001)(2906002)(6116002)(186003)(65806001)(3846002)(65956001)(26005)(64126003)(6306002)(53936002)(229853002)(7736002)(2501003)(86362001)(305945005)(65826007)(14454004)(4326008)(966005)(36756003)(6246003)(478600001)(6486002)(6436002)(256004)(8676002)(81156014)(81166006)(68736007)(31696002)(8936002)(71200400001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7PR07MB4732; H:DB7PR07MB4999.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: GE/ZMih5RMOTBajWy+IIbxp+0rH248RD7T5wndRh2/HNYiBhwwO5Zfv2zVcdIeoMAV0/ULcT35mxP2fiq2GS6YfQCz618Ay/DoGNFjn0tY4o83eLu5boRXC/C+jjafgcpxHjgxdB0Q2ceT1xWU8UfHszVdYSR+vx0+zSxoKjoKHINx+ZrsBB37itPfYoHB63MqKQpYuVooCXt3MC+riJtP1bY+6FtRm+IcDt42eRIEWTki/W4WJI4WVlzPIzrDnWJVMGsdOf20Of3MbLCScqEd8HJo+qG9ZqcGqp2jEZXDwJ7PVF6ZP7m4EdYu9h6i8tS8zmgtDPURkEg5BhIO0i4fgEaU88VetsHVtLWrlYMIC9YlnCwaHe8XCybgCPJTAHQttKzzHIZ4C+MMQDL49Ew9Cy2hTzEng18qLucOi+c6o= Content-Type: text/plain; charset="utf-8" Content-ID: <2A18B28CB43028478F26034270B45468@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7e7de625-97c6-4826-4966-08d6bec09415 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2019 20:59:25.0607 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4732 Archived-At: Subject: Re: [Pce] Martin Vigoureux's Discuss on draft-ietf-pce-gmpls-pcep-extensions-14: (with DISCUSS) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 20:59:36 -0000 VGhhbmsgeW91IEFkcmlhbiwNCg0KSSdtIHRodXMgY2xlYXJpbmcgdGhpcyBESVNDVVNTLg0KDQot bQ0KDQpMZSAyMDE5LTA0LTExIMOgIDE0OjAxLCBBZHJpYW4gRmFycmVsIGEgw6ljcml0wqA6DQo+ IEhpIE1hcnRpbiwNCj4gDQo+IEl0IHdhcyBhIGdlbmVyYWwgcG9saWN5IGR1cmluZyB0aGUgZGV2 ZWxvcG1lbnQgb2YgUENFUCB0byBtYWtlIHNwYWNlIGZvciBmbGFncyBpbiB0aGUgdmFyaW91cyBv YmplY3RzLCBhbmQgdGhpcyBoYXMgdHVybmVkIG91dCB0byBiZSB1c2VmdWwgaW4gc29tZSBjYXNl cy4NCj4gU28sIEkgdGhpbmsgdGhlIGF1dGhvcnMgd2VyZSBjb250aW51aW5nIHRoYXQgYXBwcm9h Y2guDQo+IA0KPiBCdXQgSSBhZ3JlZSwgaWYgeW91IG1ha2UgdGhlIGZpZWxkLCB5b3Ugc2hvdWxk IG1ha2UgdGhlIHJlZ2lzdHJ5Lg0KPiANCj4gVGhhbmtzLA0KPiBBZHJpYW4NCj4gDQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1hcnRpbiBWaWdvdXJldXggdmlhIERhdGF0 cmFja2VyIDxub3JlcGx5QGlldGYub3JnPg0KPiBTZW50OiAxMSBBcHJpbCAyMDE5IDEyOjI4DQo+ IFRvOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4gQ2M6IGRyYWZ0LWlldGYtcGNlLWdtcGxz LXBjZXAtZXh0ZW5zaW9uc0BpZXRmLm9yZzsgSnVsaWVuIE1ldXJpYyA8anVsaWVuLm1ldXJpY0Bv cmFuZ2UuY29tPjsgcGNlLWNoYWlyc0BpZXRmLm9yZzsganVsaWVuLm1ldXJpY0BvcmFuZ2UuY29t OyBwY2VAaWV0Zi5vcmcNCj4gU3ViamVjdDogTWFydGluIFZpZ291cmV1eCdzIERpc2N1c3Mgb24g ZHJhZnQtaWV0Zi1wY2UtZ21wbHMtcGNlcC1leHRlbnNpb25zLTE0OiAod2l0aCBESVNDVVNTKQ0K PiANCj4gTWFydGluIFZpZ291cmV1eCBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBw b3NpdGlvbiBmb3INCj4gZHJhZnQtaWV0Zi1wY2UtZ21wbHMtcGNlcC1leHRlbnNpb25zLTE0OiBE aXNjdXNzDQo+IA0KPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxp bmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCj4gZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGlu IHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMNCj4gaW50cm9kdWN0 b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBz Oi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPiBm b3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRp b25zLg0KPiANCj4gDQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9z aXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi1wY2UtZ21wbHMtcGNlcC1leHRlbnNpb25zLw0KPiANCj4gDQo+IA0K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+IERJU0NVU1M6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IEhpLA0K PiANCj4gdGhhbmtzIGZvciB0aGlzIGRvY3VtZW50LiBJIGhhdmUgYSBkaXNjdXNzIHBvaW50IHRo YXQgc2hvdWxkbid0IGJlIGRpZmZpY3VsdCB0byByZXNvbHZlOg0KPiANCj4gV2h5IGRvIHlvdSBk ZWZpbmUgYSBmbGFnIGZpZWxkIGluIHRoZSBHTVBMUy1DQVBBQklMSVRZIFRMViBpZiB5b3UgZG9u J3QgaGF2ZSBhbnkgZmxhZz8NCj4gSSBndWVzcyB0aGUgZWFzeSBhbnN3ZXIgaXMgdGhhdCB0aGVy ZSBtaWdodCBiZSBzb21lIGluIHRoZSBmdXR1cmUuDQo+IElmIHNvLCBJIHRlbmQgdG8gdGhpbmsg dGhhdCBjcmVhdGluZyBhIHJlZ2lzdHJ5IGZvciB0aGF0IGZpZWxkIHdvdWxkIGJlIGEgZ29vZCB0 aGluZyB0byBkbyBub3cuDQo+IA0KPiAtbQ0KPiANCj4gDQo+IA0KPiANCj4gDQo= From nobody Thu Apr 11 14:00:13 2019 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B39D1206E4; Thu, 11 Apr 2019 14:00:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Vigoureux via Datatracker To: "The IESG" Cc: draft-ietf-pce-gmpls-pcep-extensions@ietf.org, Julien Meuric , pce-chairs@ietf.org, julien.meuric@orange.com, pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Martin Vigoureux Message-ID: <155501640610.14137.6017664307609827477.idtracker@ietfa.amsl.com> Date: Thu, 11 Apr 2019 14:00:06 -0700 Archived-At: Subject: [Pce] Martin Vigoureux's No Objection on draft-ietf-pce-gmpls-pcep-extensions-14: (with COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 21:00:06 -0000 Martin Vigoureux has entered the following ballot position for draft-ietf-pce-gmpls-pcep-extensions-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-pcep-extensions/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, thanks for this document. I have a discuss point that shouldn't be difficult to resolve: Why do you define a flag field in the GMPLS-CAPABILITY TLV if you don't have any flag? I guess the easy answer is that there might be some in the future. If so, I tend to think that creating a registry for that field would be a good thing to do now. -m From nobody Thu Apr 11 23:05:28 2019 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D88120184; Thu, 11 Apr 2019 23:05:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: pce@ietf.org Message-ID: <155504912608.13797.7682968450188477614@ietfa.amsl.com> Date: Thu, 11 Apr 2019 23:05:26 -0700 Archived-At: Subject: [Pce] I-D Action: draft-ietf-pce-stateful-pce-p2mp-13.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 06:05:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : Path Computation Element (PCE) Protocol Extensions for Stateful PCE usage for Point-to-Multipoint Traffic Engineering Label Switched Paths Authors : Udayasree Palle Dhruv Dhody Yosuke Tanaka Vishnu Pavan Beeram Filename : draft-ietf-pce-stateful-pce-p2mp-13.txt Pages : 34 Date : 2019-04-11 Abstract: The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point- to-multipoint (P2MP) TE Label Switched Paths (LSPs). This document provides extensions required for Path Computation Element Communication Protocol (PCEP) so as to enable the usage of a stateful PCE capability in supporting P2MP TE LSPs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-p2mp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-p2mp-13 https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-pce-p2mp-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-pce-p2mp-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 11 23:06:31 2019 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 8D17C120043; Thu, 11 Apr 2019 23:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id co3wcdCXyNc0; Thu, 11 Apr 2019 23:06:21 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31DA012002E; Thu, 11 Apr 2019 23:06:21 -0700 (PDT) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 10D4F5056623F1B46769; Fri, 12 Apr 2019 07:06:19 +0100 (IST) Received: from BLREML701-CAH.china.huawei.com (10.20.4.170) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 12 Apr 2019 07:06:18 +0100 Received: from BLREML503-MBS.china.huawei.com ([169.254.12.125]) by blreml701-cah.china.huawei.com ([::1]) with mapi id 14.03.0439.000; Fri, 12 Apr 2019 11:36:11 +0530 From: Dhruv Dhody To: Benjamin Kaduk CC: The IESG , "draft-ietf-pce-stateful-pce-p2mp@ietf.org" , "pce@ietf.org" , "pce-chairs@ietf.org" Thread-Topic: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-stateful-pce-p2mp-12: (with DISCUSS and COMMENT) Thread-Index: AQHU7z+M60F99Nqc4U2m/TB9hOh6m6Y03ROwgAIn4wCAAQJ4cA== Date: Fri, 12 Apr 2019 06:06:11 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8DA11BB0@BLREML503-MBS.china.huawei.com> References: <155486089608.19649.9617345506233285248.idtracker@ietfa.amsl.com> <23CE718903A838468A8B325B80962F9B8DA0F235@BLREML503-MBS.china.huawei.com> <20190411195036.GU18549@kduck.mit.edu> In-Reply-To: <20190411195036.GU18549@kduck.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.149.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-stateful-pce-p2mp-12: (with DISCUSS and COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 06:06:23 -0000 Hi Ben,=20 I think we have converged and I have posted a new version -13.=20 > > Section 6.1 > > > When reporting the status of a P2MP TE LSP, the destinations MUST > be > > > grouped in END-POINTS object based on the operational status (O > field > > > in S2LS object) and leaf type (in END-POINTS). This way, leaves o= f > > > the same type that share the same operational status are grouped > > > together. [...] > > > > > > Does this mean that it's an error for a PCRpt message to include > > > more than one END-POINTS object with a given value of leaf-type? If > > > so, it may be worth stating that explicitly. > > > > [[Dhruv Dhody]] No, one can have more than one END-POINTS object with > the same leaf-type. There is no such restriction. >=20 > Maybe I am misunderstanding something, but the "are grouped together" > implied to me that it was always the case. Is this just an optional thin= g > for efficiency, in which case "can be grouped together" might be more > appropriate? >=20 [[Dhruv Dhody]] Agreed.=20 =20 > Sorry, I don't think I conveyed my point very well. I was suggesting tha= t > the examples would look like: >=20 > Common Header > LSP with P2MP flag set > END-POINTS for leaf type 1 (add) > S2LS (O=3DDOWN) > ERO list (empty) >=20 > But maybe everyone who is going to read this already knows that and it's > not worth the bother of changing. [[Dhruv Dhody]] I have updated the examples.=20 Thanks!=20 Dhruv From nobody Fri Apr 12 05:29:03 2019 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 31E2C1202C5; Fri, 12 Apr 2019 05:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ivMUb0hBkWo; Fri, 12 Apr 2019 05:28:51 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 350CF1201B2; Fri, 12 Apr 2019 05:28:50 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x3CCSeSK014882; Fri, 12 Apr 2019 08:28:40 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x3CCSeSK014882 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1555072121; bh=ZZrlRSY0i6CZBUo9LwdLQhoIKvcN43p+zqRr3YkdJRg=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=OaOd+cmHVdzos8cPzstj2eRzc4+uFuGqbXDMkeCPIfnZoSMaOBdn9rapYpIJ9VQ78 Crk9T77l9E65wcOmhZw1X8Zc6NgdxR9SiEkEaLyjYYm8MNkJuZTIjEZpwnXmOTZtOG RHMb4pKDQbwwAXufpimD/BVykICe0jCVROc8FSZU= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x3CCSVch003614; Fri, 12 Apr 2019 08:28:31 -0400 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0435.000; Fri, 12 Apr 2019 08:28:30 -0400 From: Roman Danyliw To: Dhruv Dhody , The IESG CC: "draft-ietf-pce-stateful-pce-p2mp@ietf.org" , "pce@ietf.org" , "pce-chairs@ietf.org" Thread-Topic: [Pce] Roman Danyliw's Discuss on draft-ietf-pce-stateful-pce-p2mp-12: (with DISCUSS) Thread-Index: AQHU76ntQr0ahYBHQUivFIUWFCvqGKY2qC8AgAHOpMA= Date: Fri, 12 Apr 2019 12:28:29 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B332A3B7@marchand> References: <155490660734.22896.13528098840634992626.idtracker@ietfa.amsl.com> <23CE718903A838468A8B325B80962F9B8DA107E0@BLREML503-MBS.china.huawei.com> In-Reply-To: <23CE718903A838468A8B325B80962F9B8DA107E0@BLREML503-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Pce] Roman Danyliw's Discuss on draft-ietf-pce-stateful-pce-p2mp-12: (with DISCUSS) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 12:28:54 -0000 SGkhDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRGhydXYgRGhvZHkg W21haWx0bzpkaHJ1di5kaG9keUBodWF3ZWkuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgQXByaWwg MTEsIDIwMTkgMTI6NTIgQU0NCj4gVG86IFJvbWFuIERhbnlsaXcgPHJkZEBjZXJ0Lm9yZz47IFRo ZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KPiBDYzogZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwtcGNl LXAybXBAaWV0Zi5vcmc7IHBjZUBpZXRmLm9yZzsgcGNlLQ0KPiBjaGFpcnNAaWV0Zi5vcmcNCj4g U3ViamVjdDogUkU6IFtQY2VdIFJvbWFuIERhbnlsaXcncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYt cGNlLXN0YXRlZnVsLXBjZS0NCj4gcDJtcC0xMjogKHdpdGggRElTQ1VTUykNCj4gDQo+IEhpIFJh bW9uLA0KPiANCj4gVGhhbmtzIGZvciB5b3VyIHJldmlldy4NCj4gDQo+IEhlcmUgaXMgdGhlIHBy b3Bvc2VkIHVwZGF0ZSAtDQo+IA0KPiAxMi4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQo+IA0K PiAgICBUaGUgc3RhdGVmdWwgb3BlcmF0aW9ucyBvbiBQMk1QIFRFIExTUHMgYXJlIG1vcmUgQ1BV LWludGVuc2l2ZSBhbmQNCj4gICAgYWxzbyB1dGlsaXplIG1vcmUgYmFuZHdpZHRoIG9uIHdpcmUg KGluIGNvbXBhcmlzb24gdG8gUDJQIFRFIExTUHMpLg0KPiAgICBJZiBhIHJvZ3VlIFBDQyB3ZXJl IGFibGUgdG8gcmVxdWVzdCB1bmF1dGhvcml6ZWQgc3RhdGVmdWwgUENFDQo+ICAgIG9wZXJhdGlv bnMgdGhlbiBpdCBtYXkgYmUgYWJsZSB0byBtb3VudCBhIERvUyBhdHRhY2sgYWdhaW5zdCBhIFBD RSwNCj4gICAgd2hpY2ggd291bGQgZGlzcnVwdCB0aGUgbmV0d29yayBhbmQgZGVueSBzZXJ2aWNl IHRvIG90aGVyIFBDQ3MuDQo+ICAgIFNpbWlsYXJseSBhbiBhdHRhY2tlciBtYXkgZmxvb2QgdGhl IFBDQyB3aXRoIFBDVXBkIG1lc3NhZ2VzIGF0IGEgcmF0ZQ0KPiAgICB0aGF0IGV4Y2VlZHMgZWl0 aGVyIHRoZSBQQ0MncyBhYmlsaXR5IHRvIHByb2Nlc3MgdGhlbSBvciB0aGUNCj4gICAgbmV0d29y aydzIGFiaWxpdHkgdG8gc2lnbmFsIHRoZSBjaGFuZ2VzLCBieSBlaXRoZXIgc3Bvb2ZpbmcgbWVz c2FnZXMNCj4gICAgb3IgY29tcHJvbWlzaW5nIHRoZSBQQ0UgaXRzZWxmLg0KPiANCj4gICAgQ29u c2VxdWVudGx5LCBpdCBpcyBpbXBvcnRhbnQgdGhhdCBpbXBsZW1lbnRhdGlvbnMgY29uZm9ybSB0 byB0aGUNCj4gICAgcmVsZXZhbnQgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIGFzIGxpc3RlZCBiZWxv dyAtDQo+IA0KPiAgICBvICBBcyBwZXIgW1JGQzgyMzFdLCBpdCBpcyBSRUNPTU1FTkRFRCB0aGF0 IHRoZXNlIFBDRVAgZXh0ZW5zaW9ucw0KPiAgICAgICBvbmx5IGJlIGFjdGl2YXRlZCBvbiBhdXRo ZW50aWNhdGVkIGFuZCBlbmNyeXB0ZWQgc2Vzc2lvbnMgYWNyb3NzDQo+ICAgICAgIFBDRXMgYW5k IFBDQ3MgYmVsb25naW5nIHRvIHRoZSBzYW1lIGFkbWluaXN0cmF0aXZlIGF1dGhvcml0eSwNCj4g ICAgICAgdXNpbmcgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChUTFMpIFtSRkM4MjUzXSwgYXMg cGVyIHRoZQ0KPiAgICAgICByZWNvbW1lbmRhdGlvbnMgYW5kIGJlc3QgY3VycmVudCBwcmFjdGlj ZXMgaW4gW1JGQzc1MjVdICh1bmxlc3MNCj4gICAgICAgZXhwbGljaXRseSBzZXQgYXNpZGUgaW4g W1JGQzgyNTNdKS4NCj4gDQo+ICAgIG8gIFNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGZvciBwYXRo IGNvbXB1dGF0aW9uIHJlcXVlc3RzIGFuZA0KPiAgICAgICByZXNwb25zZXMgYXJlIGFzIHBlciBb UkZDODMwNl0uDQo+IA0KPiAgICBvICBTZWN1cml0eSBjb25zaWRlcmF0aW9ucyBmb3Igc3RhdGVm dWwgb3BlcmF0aW9ucyAoc3VjaCBhcyBzdGF0ZQ0KPiAgICAgICByZXBvcnQsIHN5bmNocm9uaXph dGlvbiwgZGVsZWdhdGlvbiwgdXBkYXRlLCBldGMuKSBhcmUgYXMgcGVyDQo+ICAgICAgIFtSRkM4 MjMxXS4NCj4gDQo+ICAgIG8gIFNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGZvciBMU1AgaW5zdGFu dGlhdGlvbiBtZWNoYW5pc20gYXJlIGFzIHBlcg0KPiAgICAgICBbUkZDODIzMV0uDQo+IA0KPiAg ICBvICBTZWN1cml0eSBjb25zaWRlcmF0aW9ucyBhcyBzdGF0ZWQgaW4gU2VjdGlvbiAxMC4xLCBT ZWN0aW9uIDEwLjYsDQo+ICAgICAgIGFuZCBTZWN0aW9uIDEwLjcgb2YgW1JGQzU0NDBdIGNvbnRp bnVlIHRvIGFwcGx5Lg0KDQpUaGlzIHRleHQgaXMgdmVyeSBjbGVhciBhbmQgYWRkcmVzc2VzIG15 IGNvbmNlcm5zLiAgSSBzZWUgdGhhdCBpdCBpcyBpbiAtMTMgc28gSSdsbCBjbGVhciB0aGUgRElT Q1VTUy4NCg0KVGhhbmsgeW91IGZvciB0aGlzIGNoYW5nZS4NCg0KUm9tYW4NCg0KPiANCj4gTW9y ZSBpbmxpbmUgLQ0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206 IFBjZSBbbWFpbHRvOnBjZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9tYW4gRGFu eWxpdyB2aWENCj4gPiBEYXRhdHJhY2tlcg0KPiA+IFNlbnQ6IDEwIEFwcmlsIDIwMTkgMjA6MDAN Cj4gPiBUbzogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQo+ID4gQ2M6IGRyYWZ0LWlldGYtcGNl LXN0YXRlZnVsLXBjZS1wMm1wQGlldGYub3JnOyBwY2VAaWV0Zi5vcmc7IHBjZS0NCj4gPiBjaGFp cnNAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBbUGNlXSBSb21hbiBEYW55bGl3J3MgRGlzY3VzcyBv biBkcmFmdC1pZXRmLXBjZS1zdGF0ZWZ1bC1wY2UtDQo+ID4gcDJtcC0xMjogKHdpdGggRElTQ1VT UykNCj4gPg0KPiA+IFJvbWFuIERhbnlsaXcgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxs b3QgcG9zaXRpb24gZm9yDQo+ID4gZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwtcGNlLXAybXAtMTI6 IERpc2N1c3MNCj4gPg0KPiA+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1Ympl Y3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KPiA+IGVtYWlsIGFkZHJlc3NlcyBpbmNs dWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dA0KPiA+IHRoaXMg aW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+ID4NCj4gPg0KPiA+IFBsZWFzZSBy ZWZlciB0bw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3Mt Y3JpdGVyaWEuaHRtbA0KPiA+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VT UyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+ID4NCj4gPg0KPiA+IFRoZSBkb2N1bWVudCwgYWxv bmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gPiBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXBjZS1zdGF0ZWZ1bC1w Y2UtcDJtcC8NCj4gPg0KPiA+DQo+ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gRElTQ1VTUzoN Cj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4NCj4gPiBUaGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMg c2VjdGlvbiBoYXMgbnVtZXJvdXMgaGVscGZ1bCBhbmQNCj4gPiBhcHByb3ByaWF0ZSByZWZlcmVu Y2VzLiAgVGhhbmtzIGZvciB0cmFja2luZyB0aGVtIGRvd24uICBIb3dldmVyLA0KPiA+IGV4cGxp Y2l0LCBhZGRpdGlvbmFsIHRleHQgaXMgcmVxdWlyZWQgdG8gaGVscCBpZGVudGlmeSwgZGUtZHVw bGljYXRlDQo+ID4gYW5kIGRlY29uZmxpY3QgdGhlIOKAnHJlbGV2YW50IGd1aWRhbmNl4oCdIHBy b3ZpZGVkIGJ5IHRoZW0uDQo+ID4NCj4gPiAoMSkgUGVyIOKAnGl0IGlzIGltcG9ydGFudCB0aGF0 IGltcGxlbWVudGF0aW9ucyBjb25mb3JtIHRvIHRoZSByZWxldmFudA0KPiA+IHNlY3VyaXR5IHJl cXVpcmVtZW50cyBvZiBbUkZDNTQ0MF0sIFtSRkM4MzA2XSBhbmQgW1JGQzgyMzFdLCBhbmQNCj4g PiBbUkZDODI4MV3igJ06DQo+ID4NCj4gPiAqKiBbUkZDODIzMV0gc2F5cyDigJxSRUNPTU1FTkRF RCB0aGF0IHRoZXNlIFBDRVAgZXh0ZW5zaW9ucyBvbmx5IGJlDQo+ID4gYWN0aXZhdGVkIG9uIGF1 dGhlbnRpY2F0ZWQgYW5kIGVuY3J5cHRlZCBzZXNzaW9ucyBhY3Jvc3MgUENFcyBhbmQgUENDcw0K PiA+IGJlbG9uZ2luZyB0byB0aGUgc2FtZSBhZG1pbmlzdHJhdGl2ZSBhdXRob3JpdHksIHVzaW5n IFRyYW5zcG9ydCBMYXllcg0KPiA+IFNlY3VyaXR5IChUTFMpIFtQQ0VQU10sIGFzIHBlciB0aGUg cmVjb21tZW5kYXRpb25zIGFuZCBiZXN0IGN1cnJlbnQNCj4gPiBwcmFjdGljZXMgaW4gW1JGQzc1 MjVd4oCdLiAgR29vZCBsYW5ndWFnZS4NCj4gPiBUaGlzIGRyYWZ0IGFnYWluIHJlLXN0YXRlcyDi gJxTZWN1cmluZyB0aGUgUENFUCBzZXNzaW9uIHVzaW5nIFRyYW5zcG9ydA0KPiA+IExheWVyIFNl Y3VyaXR5IChUTFMpIFtSRkM4MjUzXSwgYXMgcGVyIHRoZSByZWNvbW1lbmRhdGlvbnMgYW5kIGJl c3QNCj4gPiBjdXJyZW50IHByYWN0aWNlcyBpbiBbUkZDNzUyNV0sIGlzIFJFQ09NTUVOREVELuKA nSAgV2h5IHNheSB0aGF0IHR3aWNlPw0KPiA+IElzIHRoZXJlIHNvbWV0aGluZyBuZXcgdGhlcmU/ DQo+ID4NCj4gDQo+IFtbRGhydXYgRGhvZHldXSBVc2VkIHRoZSB0ZXh0IGZyb20gUkZDODIzMS4N Cj4gDQo+ID4gKiogUGVyIFNlY3Rpb24gMTAuNCBvZiBSRkM1NDQwIGZyb20gMjAwOSwgSVBTZWMg aXMgYSBNQVkgYW5kIFNlY3Rpb24NCj4gPiAxMC4yIG1ha2VzDQo+ID4gVENQLU1ENSBhIE1VU1Qu ICBUaGUgbW9yZSByZWNlbnQgKDIwMTcpIFJGQzgzMDYgYW5kIFJGQzgyNTMNCj4gcmVmZXJlbmNl DQo+ID4gVExTIGFuZCBUQ1AtQU8sIG5vIElQU2VjLiAgUkZDODMwNiBleHBsaWNpdGx5IHNheXMg ZG9u4oCZdCB1c2UgVENQLU1ENS4NCj4gPiBXaGF0IGlzIHRoZSBSRUNPTU1FTkRFRCBhcHByb2Fj aCB0b2RheT8NCj4gPg0KPiA+ICgyKSBQZXIg4oCcW3NdZWN1cmluZyB0aGUgUENFUCBzZXNzaW9u IHVzaW5nIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eQ0KPiA+IChUTFMpIFtSRkM4MjUzXSwgYXMg cGVyIHRoZSByZWNvbW1lbmRhdGlvbnMgYW5kIGJlc3QgY3VycmVudCBwcmFjdGljZXMNCj4gPiBp biBbUkZDNzUyNV0sIGlzIFJFQ09NTUVOREVE4oCdLCBob3cgc2hvdWxkIHRoZSBndWlkYW5jZSBv biBib3RoIG9mDQo+IHRoZXNlDQo+ID4gZHJhZnRzIGJlIHN5bnRoZXNpemVkPw0KPiANCj4gW1tE aHJ1diBEaG9keV1dIEFkZGVkICIodW5sZXNzIGV4cGxpY2l0bHkgc2V0IGFzaWRlIGluIFtSRkM4 MjUzXSkiLg0KPiANCj4gPiBTcGVjaWZpY2FsbHksIHRoaXMgc2VudGVuY2UgaXMgdW5jbGVhciBv biB3aGV0aGVyIHRoZSB0aGUgcm9idXN0IFRMUw0KPiA+IDEuMiByZXF1aXJlbWVudHMgaW4gU2Vj dGlvbiAzLjQgb2YgUkZDODI1MyBhcmUgUkVDT01NRU5ERUQsIGFuZC9vcg0KPiA+IHdoZXRoZXIg dGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zL1NlY3Rpb24gNyBvZiBSRkM4MjUzLCB3aGljaA0K PiA+IHVuZGVybWluZSB0aGVzZSByb2J1c3QgcmVxdWlyZW1lbnRzIGJ5IHNheWluZyBhZG1pbmlz dHJhdG9ycyBNQVkgYWxsb3cNCj4gPiB0aGUgdXNhZ2Ugd2VhayBjaXBoZXJzdWl0ZXMsIGFwcGx5 Lg0KPiANCj4gW1tEaHJ1diBEaG9keV1dIFNlY3Rpb24gMy40IG9mIFJGQzgyNTMgc2F5cyAtDQo+ IA0KPiAgICAgICAgKiAgTmVnb3RpYXRpb24gb2YgYSBjaXBoZXJzdWl0ZSBwcm92aWRpbmcgZm9y IGNvbmZpZGVudGlhbGl0eSBpcw0KPiAgICAgICAgICAgUkVDT01NRU5ERUQuDQo+IA0KPiBUaGVu LCBTZWN0aW9uIDcgc2F5cyAtDQo+IA0KPiAgICBTb21lIFRMUyBjaXBoZXJzdWl0ZXMgb25seSBw cm92aWRlIGludGVncml0eSB2YWxpZGF0aW9uIG9mIHRoZWlyDQo+ICAgIHBheWxvYWQgYW5kIHBy b3ZpZGUgbm8gZW5jcnlwdGlvbjsgc3VjaCBjaXBoZXJzdWl0ZXMgU0hPVUxEIE5PVCBiZQ0KPiAg ICB1c2VkIGJ5IGRlZmF1bHQuICBBZG1pbmlzdHJhdG9ycyBNQVkgYWxsb3cgdGhlIHVzYWdlIG9m IHRoZXNlDQo+ICAgIGNpcGhlcnN1aXRlcyBhZnRlciBjYXJlZnVsIHdlaWdodGluZyBvZiB0aGUg cmlzayBvZiByZWxldmFudCBpbnRlcm5hbA0KPiAgICBkYXRhIGxlYWthZ2UgdGhhdCBjYW4gb2Nj dXIgaW4gc3VjaCBhIGNhc2UsIGFzIGV4cGxpY2l0bHkgc3RhdGVkIGJ5DQo+ICAgIFtSRkM2OTUy XS4NCj4gDQo+IFRoZSAnTUFZJyBpbiB0aGUgYWJvdmUgdGV4dCBpcyB0byBvcHRpb25hbGx5IGFs bG93IGdvaW5nIGFnYWluc3Qgc29tZXRoaW5nDQo+IHRoYXQgaXMgJ1JFQ09NTUVOREVEJyB3aXRo IGEgc3VpdGFibGUgZ3VpZGFuY2UuIEluIG15IHJlYWRpbmcgdGhhdCBpcw0KPiBva2F5LiBBbSBJ IG1pc3Npbmcgc29tZXRoaW5nPw0KPiANCj4gPiBUaGlzDQo+ID4gc2VudGVuY2UgYWxzbyBjaXRl cyBSRkM3NTI1IHdoaWNoIG1ha2VzIHN0YXRlbWVudHMgdGhhdCB3ZWFrDQo+ID4gKE5VTEwpIGNp cGhlciBzdWl0ZXMgTVVTVCBOT1QgYmUgbmVnb3RpYXRlZCBpbiBjb250cmFkaWN0aW9uIHRvIHRo ZQ0KPiA+IFJGQzgyNTMgU2VjdGlvbiA3IGd1aWRhbmNlLg0KPiA+DQo+IFtbRGhydXYgRGhvZHld XSBUaGlzIGlzIHRha2VuIGNhcmUgYnkgIih1bmxlc3MgZXhwbGljaXRseSBzZXQgYXNpZGUgaW4N Cj4gW1JGQzgyNTNdKSIgaW4gdGhlIHByb3Bvc2VkIHVwZGF0ZS4NCj4gDQo+ID4gR2l2ZW4gdGhl IGRpc2N1c3Npb24gb2YgVExzLCBzb21lIGFkZGl0aW9uYWwgdHJlYXRtZW50IG9mIFRMUyB2MS4z IGlzDQo+ID4gbmVlZGVkLCByZWNvZ25pemluZyB0aGF0IFJGQzc1MjUgZG9lcyByZWNvbW1lbmQg 4oCcdjEuMivigJ0NCj4gPg0KPiBbW0RocnV2IERob2R5XV0gQm90aCBSRkM4MjUzIGFuZCBSRkM3 NTI1IHNheSBUTFMxLjIgb3IgbGF0ZXI7IG5vdCBzdXJlIGlmDQo+IHdlIG5lZWQgdG8gc2F5IG1v cmUgaW4gdGhpcyBJLUQgKGEgdmVyeSBzcGVjaWZpYyBQMk1QIGV4dGVuc2lvbikuDQo+IA0KPiA+ IEFnYWluLCB0aGVyZSBpcyBoZWxwZnVsIGd1aWRhbmNlIGFjcm9zcyBhbGwgb2YgdGhlIHJlZmVy ZW5jZXMuICBQbGVhc2UNCj4gPiBwcm92aWRlIG1vcmUgdGV4dHVhbGx5IG5hcnJhdGl2ZSBhYm91 dCB3aGljaCBzcGVjaWZpYyBzZWN0aW9ucyBhcHBseQ0KPiA+IG9uIHRoZSByZWZlcmVuY2VzLg0K PiA+DQo+ID4NCj4gW1tEaHJ1diBEaG9keV1dIFNlZSBwcm9wb3NlZCB0ZXh0Lg0KPiANCj4gSWYg dGhlIG5ldyB0ZXh0IG5lZWRzIGZ1cnRoZXIgY2hhbmdlcywgaXQgd291bGQgYmUgdmVyeSBoZWxw ZnVsIGlmIHlvdSBjb3VsZA0KPiBpbmNsdWRlIHRoZSBjaGFuZ2VzIHlvdSB3b3VsZCBsaWtlIHRv IHNlZS4NCj4gDQo+IFRoYW5rcyBmb3IgeW91ciByZXZpZXchDQo+IA0KPiBSZWdhcmRzIQ0KPiBE aHJ1dg0KPiANCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPiBQY2UgbWFpbGluZyBsaXN0DQo+ID4gUGNlQGlldGYub3JnDQo+ ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wY2UNCg== From nobody Fri Apr 12 07:32:10 2019 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8F71207A1; Fri, 12 Apr 2019 07:32:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: pce@ietf.org, ipr-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155507952061.16732.3453608719793394260@ietfa.amsl.com> Date: Fri, 12 Apr 2019 07:32:00 -0700 Archived-At: Subject: [Pce] IPR Disclosure Huawei Technologies Co.,Ltd' s Statement about IPR related to draft-ietf-pce-association-diversity X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 14:32:01 -0000 Dear Stephane Litkowski, Siva Sivabalan, Colby Barth, Mahendra Singh Negi: An IPR disclosure that pertains to your Internet-Draft entitled "Path Computation Element communication Protocol (PCEP) extension for signaling LSP diversity constraint" (draft-ietf-pce-association-diversity) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/3493/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-pce-association-diversity" Thank you IETF Secretariat From nobody Fri Apr 12 09:06:27 2019 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 3F62A12012E for ; Fri, 12 Apr 2019 09:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netflix.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6ArN6-UWsOc for ; Fri, 12 Apr 2019 09:06:23 -0700 (PDT) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F9501202BD for ; Fri, 12 Apr 2019 09:06:23 -0700 (PDT) Received: by mail-vs1-xe29.google.com with SMTP id e2so5818610vsc.13 for ; Fri, 12 Apr 2019 09:06:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Lzlp4OQWvkiyzlKtGM6KWLLlFibJFiIUZDGDltkbLIo=; b=OIo87xX84RRpbMVJK1ZBFHo85BPRYECR1mOC3iyz737tkjvZ10es65+kwvq2o6Y5SY 5lxfU99Dg6upBEU5M0td+JzW/NLouHIPGZtI4fkaIct+NHB5gyOM+TuHJQ3PPhCmGGjP jWVhWOO/P9Wu+jb2vuPS54WiBzh5JbJmbXJuI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Lzlp4OQWvkiyzlKtGM6KWLLlFibJFiIUZDGDltkbLIo=; b=FMpjcoehHIM2BJQe89cBCgukT4f6Fac6RaYJUIlCiet03h5woF63jiomyviIjpO6w5 7gNeizpDzPG2cD9Q/HnQ7VgZobGAT8yrszRkCRAvp+zBBdd+S10Y/FHNZ5igdid4hwsO 6nQ/xQdJAoJhpH2DJJ5+w8YzrsMJpyQDbiz7zmrft52Gkn6k51qMTDqYeJ20IA/T5/kk Bv1kXtiNyrghWG26mQgCFmul9j1xCj/drRbl0NXCy7RPOSaypwr/TBOgVVadmDNP6dAv TPEPNMw2udw8xJbZrutR6OP2+caEuqsJk/jS760WrksxNqqfng/Xg7FA7Sbaqk4kEP6d 2/Yg== X-Gm-Message-State: APjAAAXbKTICGAtmfd4TIWUvmt2gc4cjC8rudzE/F6f3bq6HA6L0AkA8 UNdWnLULHf4GoTTV86IR4Tsb2zZDVq2b+QL/UVYKtw== X-Google-Smtp-Source: APXvYqy4nnfkFqCxkW34GpkU6ti+jZ3YSFHKI/sfntaxYAdIKdI89B7aa1ncyTkeJn2kP4XNiHTGGDp3DQvgIiCMGGY= X-Received: by 2002:a67:cf09:: with SMTP id y9mr32380367vsl.141.1555085182402; Fri, 12 Apr 2019 09:06:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Hariharan Ananthakrishnan Date: Fri, 12 Apr 2019 09:06:10 -0700 Message-ID: To: draft-ietf-pce-stateful-path-protection@ietf.org Cc: pce@ietf.org Content-Type: multipart/alternative; boundary="000000000000e4b5be0586577b29" Archived-At: Subject: Re: [Pce] IPR poll on draft-ietf-pce-stateful-path-protection X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 16:06:25 -0000 --000000000000e4b5be0586577b29 Content-Type: text/plain; charset="UTF-8" I am not aware of any IPR applicable to this draft that should be disclosed in accordance with IETF IPR rules. - Hari On Tue, Apr 9, 2019 at 7:57 PM Hariharan Ananthakrishnan wrote: > Hi authors, > > In preparation for Working Group last call on this draft, I'd like all > authors and contributors to confirm on the list that they are in compliance > with IETF IPR rules. > > Please respond (copying the mailing list) to say one of: > > I am not aware of any IPR applicable to this draft that should be disclosed > in accordance with IETF IPR rules. > > I am aware of IPR applicable to this draft, and it has already been > disclosed to the IETF. > > I am aware of IPR applicable to this draft, but that has not yet been > disclosed to the IETF. I will work to ensure that it will be disclosed in a > timely manner. > > Thanks, > - Hari > > --000000000000e4b5be0586577b29 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
I am not aware of any IPR app=
licable to this draft that should be disclosed
in accordance with IETF IPR rules.
- Hari

On Tue, Apr 9, 2019 at 7:57 PM Hariharan Ananthakrishnan &l= t;hari@netflix.com> wrote:
Hi authors,

In preparation for Working Group last call on this draft, I'd like all
authors and contributors to confirm on the list that they are in compliance
with IETF IPR rules.

Please respond (copying the mailing list) to say one of:

I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.

I am aware of IPR applicable to this draft, and it has already been
disclosed to the IETF.

I am aware of IPR applicable to this draft, but that has not yet been
disclosed to the IETF. I will work to ensure that it will be disclosed in a
timely manner.

Thanks,
- Hari
--000000000000e4b5be0586577b29-- From nobody Fri Apr 12 13:32:49 2019 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 67041120145; Fri, 12 Apr 2019 13:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gfUX2ZAQYgO; Fri, 12 Apr 2019 13:32:46 -0700 (PDT) Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FD351200EF; Fri, 12 Apr 2019 13:32:45 -0700 (PDT) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3CKWiKe017954; Fri, 12 Apr 2019 21:32:44 +0100 Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 130BF2203B; Fri, 12 Apr 2019 21:32:44 +0100 (BST) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS id F27312203A; Fri, 12 Apr 2019 21:32:43 +0100 (BST) Received: from LAPTOPK7AS653V ([87.114.253.143]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3CKWgHg003213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 Apr 2019 21:32:43 +0100 Reply-To: From: "Adrian Farrel" To: Cc: Date: Fri, 12 Apr 2019 21:32:42 +0100 Organization: Old Dog Consulting Message-ID: <073401d4f16e$e20286e0$a60794a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AdTxbfVlQVO4D4p4T7C2ys8s0Jlx6A== X-Originating-IP: 87.114.253.143 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24548.002 X-TM-AS-Result: No--1.783-10.0-31-10 X-imss-scan-details: No--1.783-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24548.002 X-TMASE-Result: 10--1.783400-10.000000 X-TMASE-MatchedRID: WEo0otch/L8txeejojcKf0hEDfw/93BuO1K5iM8Q6KAKXKtfi06bFKPF jJEFr+olfeZdJ1Xsorh2UXf6mQxxtFOm2gN+nomsNtDyE2Cl4w1FejkC5P45SHnN0DN7HnFmUaL vL3VRrsTygmrUeTuMAxgoQ+EClk6K7/T5FNnLwPhrBsP/c6vKBgkCnkA3h/n1D701dfVAizuSL9 OvtUca/e6+D482nHhrftwZ3X11IV0= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: [Pce] Working Group last call completed: draft-ietf-pce-stateful-hpce-06 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 20:32:48 -0000 Authors, There were no objections to progressing this draft, but there were comments received (Haomian, me) that need to be addressed before I can advance the draft. Thanks, Adrian From nobody Fri Apr 12 22:12:55 2019 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 ABC3F12008A; Fri, 12 Apr 2019 22:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.632 X-Spam-Level: X-Spam-Status: No, score=-3.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, INVALID_MSGID=0.568, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLpeMlqx-XeR; Fri, 12 Apr 2019 22:12:51 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DBFF120046; Fri, 12 Apr 2019 22:12:51 -0700 (PDT) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 43D0CFBCC0EC3D2E6D54; Sat, 13 Apr 2019 06:12:49 +0100 (IST) Received: from dggeme702-chm.china.huawei.com (10.1.199.98) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sat, 13 Apr 2019 06:12:48 +0100 Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme702-chm.china.huawei.com (10.1.199.98) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Sat, 13 Apr 2019 13:12:46 +0800 Received: from dggeme754-chm.china.huawei.com ([10.6.80.77]) by dggeme754-chm.china.huawei.com ([10.6.80.77]) with mapi id 15.01.1591.008; Sat, 13 Apr 2019 13:12:46 +0800 From: Mahendra Singh Negi To: Hariharan Ananthakrishnan , "draft-ietf-pce-stateful-path-protection@ietf.org" CC: "pce@ietf.org" Thread-Topic: IPR poll on draft-ietf-pce-stateful-path-protection Thread-Index: AQHU70ksebpWx3iN4U6g75ohIR+LnKY5kH12 Date: Sat, 13 Apr 2019 05:12:46 +0000 Message-ID: 085E033C-452F-4FB0-BD86-B4CD43F70BE1 References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_085E033C452F4FB0BD86B4CD43F70BE1_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pce] IPR poll on draft-ietf-pce-stateful-path-protection X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2019 05:12:54 -0000 --_000_085E033C452F4FB0BD86B4CD43F70BE1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am not aware of any IPR applicable to this draft that should be disclosed in accordance with IETF IPR rules. Thanks, Mahendra From:Hariharan Ananthakrishnan To:draft-ietf-pce-stateful-path-protection@ietf.org Cc:pce@ietf.org Date:2019-04-10 08:27:46 Subject:IPR poll on draft-ietf-pce-stateful-path-protection Hi authors, In preparation for Working Group last call on this draft, I'd like all authors and contributors to confirm on the list that they are in compliance with IETF IPR rules. Please respond (copying the mailing list) to say one of: I am not aware of any IPR applicable to this draft that should be disclosed in accordance with IETF IPR rules. I am aware of IPR applicable to this draft, and it has already been disclosed to the IETF. I am aware of IPR applicable to this draft, but that has not yet been disclosed to the IETF. I will work to ensure that it will be disclosed in a timely manner. Thanks, - Hari --_000_085E033C452F4FB0BD86B4CD43F70BE1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am not aware of any IPR applicable to this draft that should be disclosed=
in accordance with IETF IPR rules.

Thanks,
Mahendra
From:Hariharan Ananthakrishnan &= lt;hari@netflix.com>
To:draft-ietf-pce-stateful-path-= protection@ietf.org <draft-ietf-pce-stateful-path-protection@ietf.org>= ;
Cc:pce@ietf.org <pce@ietf.org= >
Date:2019-04-10 08:27:46
Subject:IPR poll on draft-ietf-p= ce-stateful-path-protection

Hi authors,

In preparation for Working Group last call on this draft, I'd like all
authors and contributors to confirm on the list that they are in compliance
with IETF IPR rules.

Please respond (copying the mailing list) to say one of:

I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.

I am aware of IPR applicable to this draft, and it has already been
disclosed to the IETF.

I am aware of IPR applicable to this draft, but that has not yet been
disclosed to the IETF. I will work to ensure that it will be disclosed in a
timely manner.

Thanks,
- Hari
--_000_085E033C452F4FB0BD86B4CD43F70BE1_-- From nobody Fri Apr 12 22:16:25 2019 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 CF3EC12008A; Fri, 12 Apr 2019 22:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.632 X-Spam-Level: X-Spam-Status: No, score=-3.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, INVALID_MSGID=0.568, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNM9K14PB2gp; Fri, 12 Apr 2019 22:16:21 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3489E120046; Fri, 12 Apr 2019 22:16:21 -0700 (PDT) Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 62E5040BDDEB59C15782; Sat, 13 Apr 2019 06:16:19 +0100 (IST) Received: from dggeme702-chm.china.huawei.com (10.1.199.98) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sat, 13 Apr 2019 06:16:18 +0100 Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme702-chm.china.huawei.com (10.1.199.98) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Sat, 13 Apr 2019 13:16:16 +0800 Received: from dggeme754-chm.china.huawei.com ([10.6.80.77]) by dggeme754-chm.china.huawei.com ([10.6.80.77]) with mapi id 15.01.1591.008; Sat, 13 Apr 2019 13:16:16 +0800 From: Mahendra Singh Negi To: Hariharan Ananthakrishnan , "draft-ietf-pce-association-diversity@ietf.org" CC: "pce@ietf.org" Thread-Topic: IPR poll on draft-ietf-pce-association-diversity Thread-Index: AQHU70kpNAWKDGRGpU283CkmopkwKKY5kXep Date: Sat, 13 Apr 2019 05:16:16 +0000 Message-ID: 7294C4CE-34A8-4475-B20D-EBCE4939092B References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7294C4CE34A84475B20DEBCE4939092B_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pce] IPR poll on draft-ietf-pce-association-diversity X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2019 05:16:23 -0000 --_000_7294C4CE34A84475B20DEBCE4939092B_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am aware of IPR applicable to this draft, and it has already been disclos= ed to the IETF. Thanks, Mahendra From:Hariharan Ananthakrishnan To:draft-ietf-pce-association-diversity@ietf.org Cc:pce@ietf.org Date:2019-04-10 08:27:41 Subject:IPR poll on draft-ietf-pce-association-diversity Hi authors, In preparation for Working Group last call on this draft, I'd like all authors and contributors to confirm on the list that they are in compliance with IETF IPR rules. Please respond (copying the mailing list) to say one of: I am not aware of any IPR applicable to this draft that should be disclosed in accordance with IETF IPR rules. I am aware of IPR applicable to this draft, and it has already been disclosed to the IETF. I am aware of IPR applicable to this draft, but that has not yet been disclosed to the IETF. I will work to ensure that it will be disclosed in a timely manner. Thanks, - Hari --_000_7294C4CE34A84475B20DEBCE4939092B_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I am aware of IPR applicable to this draft, and it has already been di= sclosed to the IETF.

Thanks,
Mahendra
From:Hariharan Ananthakrishnan &= lt;hari@netflix.com>
To:draft-ietf-pce-association-di= versity@ietf.org <draft-ietf-pce-association-diversity@ietf.org>
Cc:pce@ietf.org <pce@ietf.org= >
Date:2019-04-10 08:27:41
Subject:IPR poll on draft-ietf-p= ce-association-diversity

Hi authors,

In preparation for Working Group last call on this draft, I'd like all
authors and contributors to confirm on the list that they are in compliance
with IETF IPR rules.

Please respond (copying the mailing list) to say one of:

I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.

I am aware of IPR applicable to this draft, and it has already been
disclosed to the IETF.

I am aware of IPR applicable to this draft, but that has not yet been
disclosed to the IETF. I will work to ensure that it will be disclosed in a
timely manner.

Thanks,
- Hari
--_000_7294C4CE34A84475B20DEBCE4939092B_-- From nobody Sun Apr 14 03:42:38 2019 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F0A120612; Sun, 14 Apr 2019 03:42:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Roni Even via Datatracker To: Cc: draft-ietf-pce-hierarchy-extensions.all@ietf.org, pce@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roni Even Message-ID: <155523854346.29675.15877330669814773282@ietfa.amsl.com> Date: Sun, 14 Apr 2019 03:42:23 -0700 Archived-At: Subject: [Pce] Genart last call review of draft-ietf-pce-hierarchy-extensions-10 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2019 10:42:24 -0000 Reviewer: Roni Even Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-pce-hierarchy-extensions-?? Reviewer: Roni Even Review Date: 2019-04-14 IETF LC End Date: 2019-04-15 IESG Telechat date: Not scheduled for a telechat Summary: The document is almost ready for publication as a standard track RFC. Major issues: Minor issues: 1. In section 1.1 last bullet does it mean that you MUST NOT use H-PCEP on the internet? 2. In section 3.2.1 or section 4.1 if the originator sends PCC or PCE sends an open with P flag =0 can the response open be sent with a P flag =1 and if yes what should be the action of the originator. I did not see any text about this case. Nits/editorial comments: 1. in section 1 "achild" should be " a child" 2. Section 2.4 repeat some of the text from RFC6805 1.3.2.2 but using different sentence structure. Is there a reason to change the wording. From nobody Mon Apr 15 01:57:01 2019 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 F2BE712015D; Mon, 15 Apr 2019 01:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyHSecBoQrY0; Mon, 15 Apr 2019 01:56:57 -0700 (PDT) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC62A12015C; Mon, 15 Apr 2019 01:56:56 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 44jMnM0Rl4zBrWp; Mon, 15 Apr 2019 10:56:55 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.54]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 44jMnL6m4CzCrL4; Mon, 15 Apr 2019 10:56:54 +0200 (CEST) Received: from OPEXCAUBMA3.corporate.adroot.infra.ftgroup ([fe80::90fe:7dc1:fb15:a02b]) by OPEXCAUBM7D.corporate.adroot.infra.ftgroup ([fe80::bcfe:4850:e646:f223%21]) with mapi id 14.03.0439.000; Mon, 15 Apr 2019 10:56:54 +0200 From: To: Hariharan Ananthakrishnan , "draft-ietf-pce-association-diversity@ietf.org" CC: "pce@ietf.org" Thread-Topic: [Pce] IPR poll on draft-ietf-pce-association-diversity Thread-Index: AQHU70knufMnKXvtW0aLjqXHlD1WrqY886yg Date: Mon, 15 Apr 2019 08:56:53 +0000 Message-ID: <12867_1555318614_5CB44756_12867_96_1_9E32478DFA9976438E7A22F69B08FF924C1EC3DD@OPEXCAUBMA3.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF924C1EC3DDOPEXCAUBMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Pce] IPR poll on draft-ietf-pce-association-diversity X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 08:56:59 -0000 --_000_9E32478DFA9976438E7A22F69B08FF924C1EC3DDOPEXCAUBMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCknigJltIG5vdCBhd2FyZSBvZiBhbnkgbm9uIGFscmVhZHkgZGlzY2xvc2VkIElQUi4N Cg0KDQpGcm9tOiBQY2UgW21haWx0bzpwY2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEhhcmloYXJhbiBBbmFudGhha3Jpc2huYW4NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMTAsIDIw MTkgMDQ6NTcNClRvOiBkcmFmdC1pZXRmLXBjZS1hc3NvY2lhdGlvbi1kaXZlcnNpdHlAaWV0Zi5v cmcNCkNjOiBwY2VAaWV0Zi5vcmcNClN1YmplY3Q6IFtQY2VdIElQUiBwb2xsIG9uIGRyYWZ0LWll dGYtcGNlLWFzc29jaWF0aW9uLWRpdmVyc2l0eQ0KDQoNCkhpIGF1dGhvcnMsDQoNCg0KDQpJbiBw cmVwYXJhdGlvbiBmb3IgV29ya2luZyBHcm91cCBsYXN0IGNhbGwgb24gdGhpcyBkcmFmdCwgSSdk IGxpa2UgYWxsDQoNCmF1dGhvcnMgYW5kIGNvbnRyaWJ1dG9ycyB0byBjb25maXJtIG9uIHRoZSBs aXN0IHRoYXQgdGhleSBhcmUgaW4gY29tcGxpYW5jZQ0KDQp3aXRoIElFVEYgSVBSIHJ1bGVzLg0K DQoNCg0KUGxlYXNlIHJlc3BvbmQgKGNvcHlpbmcgdGhlIG1haWxpbmcgbGlzdCkgdG8gc2F5IG9u ZSBvZjoNCg0KDQoNCkkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFIgYXBwbGljYWJsZSB0byB0aGlz IGRyYWZ0IHRoYXQgc2hvdWxkIGJlIGRpc2Nsb3NlZA0KDQppbiBhY2NvcmRhbmNlIHdpdGggSUVU RiBJUFIgcnVsZXMuDQoNCg0KDQpJIGFtIGF3YXJlIG9mIElQUiBhcHBsaWNhYmxlIHRvIHRoaXMg ZHJhZnQsIGFuZCBpdCBoYXMgYWxyZWFkeSBiZWVuDQoNCmRpc2Nsb3NlZCB0byB0aGUgSUVURi4N Cg0KDQoNCkkgYW0gYXdhcmUgb2YgSVBSIGFwcGxpY2FibGUgdG8gdGhpcyBkcmFmdCwgYnV0IHRo YXQgaGFzIG5vdCB5ZXQgYmVlbg0KDQpkaXNjbG9zZWQgdG8gdGhlIElFVEYuIEkgd2lsbCB3b3Jr IHRvIGVuc3VyZSB0aGF0IGl0IHdpbGwgYmUgZGlzY2xvc2VkIGluIGENCg0KdGltZWx5IG1hbm5l ci4NCg0KDQoNClRoYW5rcywNCg0KLSBIYXJpDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMg cGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVu dGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1 c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXog cmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBl ZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBt ZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9y YW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0 ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0 aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0 cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg YW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1h eSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZl IGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= --_000_9E32478DFA9976438E7A22F69B08FF924C1EC3DDOPEXCAUBMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VmVyZGFuYTsNCglwYW5vc2Ut MToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29O b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4u SFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ cmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTE5 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SeKAmW0gbm90IGF3YXJlIG9mIGFueSBub24gYWxyZWFkeSBkaXNjbG9zZWQgSVBSLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFBjZSBbbWFpbHRvOnBjZS1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5IYXJpaGFyYW4gQW5hbnRoYWtyaXNobmFuPGJyPg0KPGI+U2Vu dDo8L2I+IFdlZG5lc2RheSwgQXByaWwgMTAsIDIwMTkgMDQ6NTc8YnI+DQo8Yj5Ubzo8L2I+IGRy YWZ0LWlldGYtcGNlLWFzc29jaWF0aW9uLWRpdmVyc2l0eUBpZXRmLm9yZzxicj4NCjxiPkNjOjwv Yj4gcGNlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtQY2VdIElQUiBwb2xsIG9uIGRy YWZ0LWlldGYtcGNlLWFzc29jaWF0aW9uLWRpdmVyc2l0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIxMjUyOSI+SGkgYXV0aG9ycyw8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjEyNTI5Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Zl cmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjEyNTI5Ij5JbiBwcmVw YXJhdGlvbiBmb3IgV29ya2luZyBHcm91cCBsYXN0IGNhbGwgb24gdGhpcyBkcmFmdCwgSSdkIGxp a2UgYWxsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIx MjUyOSI+YXV0aG9ycyBhbmQgY29udHJpYnV0b3JzIHRvIGNvbmZpcm0gb24gdGhlIGxpc3QgdGhh dCB0aGV5IGFyZSBpbiBjb21wbGlhbmNlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzIxMjUyOSI+d2l0aCBJRVRGIElQUiBydWxlcy48bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjEyNTI5Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Zl cmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjEyNTI5Ij5QbGVhc2Ug cmVzcG9uZCAoY29weWluZyB0aGUgbWFpbGluZyBsaXN0KSB0byBzYXkgb25lIG9mOjxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMTI1MjkiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMTI1MjkiPkkg YW0gbm90IGF3YXJlIG9mIGFueSBJUFIgYXBwbGljYWJsZSB0byB0aGlzIGRyYWZ0IHRoYXQgc2hv dWxkIGJlIGRpc2Nsb3NlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMyMTI1MjkiPmluIGFjY29yZGFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcy48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Zl cmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjEyNTI5Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjEyNTI5Ij5J IGFtIGF3YXJlIG9mIElQUiBhcHBsaWNhYmxlIHRvIHRoaXMgZHJhZnQsIGFuZCBpdCBoYXMgYWxy ZWFkeSBiZWVuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzIxMjUyOSI+ZGlzY2xvc2VkIHRvIHRoZSBJRVRGLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMTI1MjkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMTI1MjkiPkkgYW0gYXdhcmUgb2YgSVBSIGFw cGxpY2FibGUgdG8gdGhpcyBkcmFmdCwgYnV0IHRoYXQgaGFzIG5vdCB5ZXQgYmVlbjxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMTI1MjkiPmRpc2Nsb3Nl ZCB0byB0aGUgSUVURi4gSSB3aWxsIHdvcmsgdG8gZW5zdXJlIHRoYXQgaXQgd2lsbCBiZSBkaXNj bG9zZWQgaW4gYTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMyMTI1MjkiPnRpbWVseSBtYW5uZXIuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzIxMjUyOSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIxMjUyOSI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMTI1MjkiPi0gSGFyaTwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6IzIxMjUyOSI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8UFJFPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2lu dGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3Ug cHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9p dGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVz c2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBs ZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxl Y3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGlu ZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3Jt ZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1h eSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVz ZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUg dGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJl ZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlm aWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91Lgo8L1BSRT48L2JvZHk+DQo8L2h0 bWw+DQo= --_000_9E32478DFA9976438E7A22F69B08FF924C1EC3DDOPEXCAUBMA3corp_-- From nobody Mon Apr 15 13:17:35 2019 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB641203DD; Mon, 15 Apr 2019 13:17:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kyle Rose via Datatracker To: Cc: draft-ietf-pce-hierarchy-extensions.all@ietf.org, pce@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Kyle Rose Message-ID: <155535945259.10773.14556389726269462856@ietfa.amsl.com> Date: Mon, 15 Apr 2019 13:17:32 -0700 Archived-At: Subject: [Pce] Secdir last call review of draft-ietf-pce-hierarchy-extensions-10 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 20:17:33 -0000 Reviewer: Kyle Rose Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. For background, Wikipedia has the following to say about PCE: q( Routing can be subject to a set of constraints, such as Quality of Service (QoS), policy, or price. Constraint-based path computation is a strategic component of traffic engineering in MPLS, GMPLS and Segment Routing networks. It is used to determine the path through the network that traffic should follow, and provides the route for each Label Switched Path (LSP) that is set up. Path computation has previously been performed either in a management system or at the head end of each LSP. But path computation in large, multi-domain networks may be very complex and may require more computational power and network information than is typically available at a network element, yet may still need to be more dynamic than can be provided by a management system. Thus, a PCE is an entity capable of computing paths for a single or set of services. A PCE might be a network node, network management station, or dedicated computational platform that is resource-aware and has the ability to consider multiple constraints for sophisticated path computation. PCE applications compute label switched paths for MPLS and GMPLS traffic engineering. ) The document is nearly ready. In addition to numerous grammatical errors throughout, I see one minor but substantive issue. In section 6.1.2, the last sentence reads: q( This means that a parent PCE must be configured with the identities and security credentials of all of its child PCEs, or there must be some form of shared secret that allows an unknown child PCE to be authorized by the parent PCE. ) A secret shared by more than two parties cannot be used to establish identity. If there are two, then assuming exfiltration and reflection attacks are not part of your threat model, each party knows it is talking to the single other legitimate possessor of the shared secret. If there are more than two, this is no longer the case. That said, in this case it's not clear you need to identify individual child PCEs, and so (notwithstanding potential impersonation attacks in a shared secret scheme) you may wish to shorten this sentence to: q( This means that a parent PCE MUST* be able to cryptographically authenticate requests from child PCEs. ) The choice of authentication scheme can then be left to implementors, or recommendations to a different document. You might add a sentence to the security considerations section suggesting that multi-party shared key authentication schemes are not recommended for inter-domain relationships because of the potential for impersonation and repudiation and for the operational difficulties should revocation be required. *Whether this "MUST" should be BCP 14 language or not is unclear to me. From vijayc@hcl.com Mon Apr 15 23:58:11 2019 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 90DB612003E for ; Mon, 15 Apr 2019 23:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hcl.com header.b=abZIh6ta; dkim=pass (1024-bit key) header.d=hcl.com header.b=abZIh6ta Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pg0vsu1Gp_M7 for ; Mon, 15 Apr 2019 23:58:06 -0700 (PDT) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-eopbgr1320129.outbound.protection.outlook.com [40.107.132.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AF57120134 for ; Mon, 15 Apr 2019 23:58:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=HCL.COM; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=88d4e0splG/ZV5q0q5JXYEUF7B4cmQa2inSbHhWwc1k=; b=abZIh6ta+x1QCXzln0AsjVSeJG8YRBUxLUHH4/zVoNauhhTtp3rmGzhsE6j/fzY4P1OWoM9v2qD8gweqLwL8gg6ElN9xQCh3wa2bRMLSC/3ZlxO4PT3X9AIBPy1IK6M9IwaSJpvfs6HElv94Lex10NklAxIRc1EWiI6IwwKM+mg= Received: from PU1PR04CA0003.apcprd04.prod.outlook.com (2603:1096:803:29::15) by PU1PR04MB2293.apcprd04.prod.outlook.com (2603:1096:803:2d::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.19; Tue, 16 Apr 2019 06:58:03 +0000 Received: from HK2APC01FT048.eop-APC01.prod.protection.outlook.com (2a01:111:f400:7ebc::201) by PU1PR04CA0003.outlook.office365.com (2603:1096:803:29::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1813.11 via Frontend Transport; Tue, 16 Apr 2019 06:58:03 +0000 Authentication-Results: spf=pass (sender IP is 192.8.186.137) smtp.mailfrom=hcl.com; ietf.org; dkim=pass (signature was verified) header.d=HCL.COM;ietf.org; dmarc=pass action=none header.from=hcl.com; Received-SPF: Pass (protection.outlook.com: domain of hcl.com designates 192.8.186.137 as permitted sender) receiver=protection.outlook.com; client-ip=192.8.186.137; helo=transportedge.hcl.com; Received: from transportedge.hcl.com (192.8.186.137) by HK2APC01FT048.mail.protection.outlook.com (10.152.249.200) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1771.16 via Frontend Transport; Tue, 16 Apr 2019 06:58:02 +0000 Received: from CHN-CORP-HT02.CORP.HCL.IN (10.249.2.34) by transportedge.hcl.com (10.249.1.160) with Microsoft SMTP Server (TLS) id 14.3.339.0; Tue, 16 Apr 2019 17:52:24 +0530 Received: from CHN-CORP-EDGE1.CORP.HCL.COM (10.249.1.159) by CHN-CORP-HT02.CORP.HCL.IN (10.249.2.34) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 16 Apr 2019 12:26:00 +0530 Received: from APC01-SG2-obe.outbound.protection.outlook.com (104.47.125.55) by transportedge.hcl.com (10.249.1.159) with Microsoft SMTP Server (TLS) id 14.3.339.0; Tue, 16 Apr 2019 17:50:23 +0530 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=HCL.COM; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=88d4e0splG/ZV5q0q5JXYEUF7B4cmQa2inSbHhWwc1k=; b=abZIh6ta+x1QCXzln0AsjVSeJG8YRBUxLUHH4/zVoNauhhTtp3rmGzhsE6j/fzY4P1OWoM9v2qD8gweqLwL8gg6ElN9xQCh3wa2bRMLSC/3ZlxO4PT3X9AIBPy1IK6M9IwaSJpvfs6HElv94Lex10NklAxIRc1EWiI6IwwKM+mg= Received: from SG2PR0401MB2014.apcprd04.prod.outlook.com (10.170.134.145) by SG2PR0401MB2190.apcprd04.prod.outlook.com (10.170.132.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.19; Tue, 16 Apr 2019 06:22:53 +0000 Received: from SG2PR0401MB2014.apcprd04.prod.outlook.com ([fe80::14bf:9c19:6d57:ec4]) by SG2PR0401MB2014.apcprd04.prod.outlook.com ([fe80::14bf:9c19:6d57:ec4%2]) with mapi id 15.20.1792.018; Tue, 16 Apr 2019 06:22:53 +0000 From: "Vijayanand C - ERS, HCL Tech" To: "pce@ietf.org" Thread-Topic: algorithm for CSPF in WDM networks Thread-Index: AdT0HH+X2+gXvztEQ4KzU1ZIsp3M0w== Date: Tue, 16 Apr 2019 06:22:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL2hjbCIsImlkIjoiMDgzNDYyODktN2JiZi00NTI3LWEwOTQtNTZmMGJiYjM3YmNjIiwicHJvcHMiOlt7Im4iOiJDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoibnVsbCJ9XX1dfSwiU3ViamVjdExhYmVscyI6W10sIlRNQ1ZlcnNpb24iOiIxOC40LjE4NDMuMTIzIiwiVHJ1c3RlZExhYmVsSGFzaCI6ImpXTXNDaWR3bFV2b3U2ajk5MFhPR3NZYXFOb1BmaUk1ZnlcL2JEbGNJUHo1MHBxMEE5SUw2SWFHN3hPTVhIU3cxIn0= Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=vijayc@hcl.com; x-originating-ip: [117.193.156.46] x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: 2dafae76-1ba8-45a0-417c-08d6c238deb0 X-Microsoft-Antispam-Untrusted: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(711020)(4605104)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:SG2PR0401MB2190; X-MS-TrafficTypeDiagnostic: SG2PR0401MB2190:|PU1PR04MB2293: X-Microsoft-Antispam-PRVS: x-forefront-prvs: 000947967F X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10019020)(396003)(136003)(376002)(346002)(39860400002)(366004)(189003)(199004)(53754006)(38564003)(14454004)(66066001)(6916009)(102836004)(5024004)(2906002)(26005)(256004)(6506007)(14444005)(55236004)(86362001)(7696005)(7736002)(74316002)(99286004)(186003)(486006)(6116002)(6436002)(25786009)(71200400001)(54896002)(5660300002)(316002)(55016002)(9686003)(6306002)(2351001)(8676002)(52536014)(790700001)(8936002)(81166006)(106356001)(2501003)(81156014)(33656002)(5640700003)(71190400001)(53936002)(97736004)(3846002)(476003)(68736007)(105586002)(1730700003)(478600001)(579124003); DIR:OUT; SFP:1102; SCL:1; SRVR:SG2PR0401MB2190; H:SG2PR0401MB2014.apcprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: hcl.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info-Original: jrzb7VIhLtGxUt1BgB/2SMZZWk+nGdv4ExfpR+imIIoITcEl/1TxzddM+SKcxuBsFr+Ng7wkktzlmCu+gJ0nQVT0ry3nJS4jp7tiqmSAJICP+tnKwy5tFCdDpuuoD/f/tBCW+e/lXcRmoOwZnA0b534XuWkcxKQr8pfMK95IVOhkLL3lRLguMy5J2xPmYQZQ2h3V0n/cmKWPpyPol59JGZQEqYa78vHUKp/6lepa4R2Wf8nve89RPbS96nVLqLVaJMICCUkmCPMY8gvpv3uzChaUe2g+ekc7VIhrKsDx5MwYyXxXFT2kXtGlYrPPbgFsUDWC1XilBIUSe3/UQSeEzTyG+al5tsR2evAe/6a8n8LgkdqbYtGE1ih1WbckcUw4HdoolDfsm6+NivipCW4J7y8fcMnkHoLblYPHSsRepLc= Content-Type: multipart/alternative; boundary="_000_SG2PR0401MB20149B68694F8BC4EE43232EDC240SG2PR0401MB2014_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2PR0401MB2190 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: HK2APC01FT048.eop-APC01.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:192.8.186.137; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(346002)(136003)(39860400002)(376002)(396003)(2980300002)(53754006)(38564003)(199004)(189003)(16586007)(6306002)(6916009)(2501003)(316002)(106002)(74316002)(55016002)(54896002)(81166006)(356004)(68736007)(336012)(5660300002)(5640700003)(81156014)(1730700003)(61614004)(6506007)(7696005)(7736002)(71190400001)(53936002)(99286004)(102836004)(9686003)(25786009)(2351001)(26005)(33656002)(186003)(8676002)(26826003)(76130400001)(106466001)(8936002)(86362001)(84326002)(14444005)(790700001)(486006)(52536014)(3846002)(476003)(126002)(6116002)(5024004)(478600001)(66066001)(2906002)(97736004)(14454004)(579124003); DIR:OUT; SFP:1102; SCL:1; SRVR:PU1PR04MB2293; H:transportedge.hcl.com; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-MS-Office365-Filtering-Correlation-Id-Prvs: c5512864-faee-4eb1-8b18-08d6c233f557 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(710020)(711020)(4605104)(4709054)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:PU1PR04MB2293; X-Forefront-PRVS: 000947967F X-Microsoft-Antispam-Message-Info: 5wX5bknWCC4r7Vr301FD05wigpIGlQT03qNyKC26ztBCJWa0XJ0U8onfQmiZYPjN/L39za+0gYhoffvrWOUWAWdVjoe4IfGggANYRJKG0BbOvgMw8D5ciRXC7CQbzcTOs986Wp3VTt0CHFLraNkveBhB/lnrkvOuH3r7sUkY+19x4pHOC6U69dUrO1jczk6OE4VI1Bp+9F4joE8XaM6zF2HxLJKU1f2L1d/4pRT2IQYOAmfocw2pqKk/0x7TLq15iP3ZMay42cZRIdokOrBUe1NXaQH3Ia1+zSj8mJ4OfZXpZxkBiYrKXy9nYDVoYE78XI+PrNp+DPJGQW0XAO6C9iPVNUcsPGLAhcDzKGSwCDwipywKz2r0DQ4kqchSVXj60CBmZASmhV3LPaf79Wl/+tv4vL36cxZEVBAx8lg4drA= X-OriginatorOrg: HCL.COM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Apr 2019 06:58:02.7732 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2dafae76-1ba8-45a0-417c-08d6c238deb0 X-MS-Exchange-CrossTenant-Id: 189de737-c93a-4f5a-8b68-6f4ca9941912 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=189de737-c93a-4f5a-8b68-6f4ca9941912; Ip=[192.8.186.137]; Helo=[transportedge.hcl.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1PR04MB2293 Archived-At: Subject: [Pce] algorithm for CSPF in WDM networks X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 07:32:29 -0000 --_000_SG2PR0401MB20149B68694F8BC4EE43232EDC240SG2PR0401MB2014_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable hello all, I have a question. I would like to know what algorithm is recommended for path computation acr= oss WDM network by a PCE. Will it be a modified version of dijkstra - with = one run to check for optical constraints at every hop included into the SPF= tree and find shortest path by metric , or the K-th shortest path algorith= m to continuously explore many paths and check optical constraints( such as= wavelength continuity, ROADM directionality constraint etc) on each of the= paths one by one Please give your suggestions/experience. Regards Vijay ::DISCLAIMER:: ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ----------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and inte= nded for the named recipient(s) only. E-mail transmission is not guaranteed= to be secure or error-free as information could be intercepted, corrupted,= lost, destroyed, arrive late or incomplete, or may contain viruses in tran= smission. The e mail and its contents (with or without referred errors) sha= ll therefore not attach any liability on the originator or HCL or its affil= iates. Views or opinions, if any, presented in this email are solely those = of the author and may not necessarily reflect the views or opinions of HCL = or its affiliates. Any form of reproduction, dissemination, copying, disclo= sure, modification, distribution and / or publication of this message witho= ut the prior written consent of authorized representative of HCL is strictl= y prohibited. If you have received this email in error please delete it and= notify the sender immediately. Before opening any email and/or attachments= , please check them for viruses and other defects. ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ----------------------------------------------------- --_000_SG2PR0401MB20149B68694F8BC4EE43232EDC240SG2PR0401MB2014_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

hello a= ll, 

I have = a question.<= /span>

 

I would lik= e to know what algorithm is recommended for path computation across WDM net= work by a PCE. Will it be a modified version of dijkstra - with one run to check for optical constraints at every hop i= ncluded into the SPF tree and find shortest path by metric , or the K-th sh= ortest path algorithm to continuously explore many paths and check optical = constraints( such as wavelength continuity, ROADM directionality constraint etc) on each of the paths one = by one

 =

Please give= your suggestions/experience.

&n= bsp;

Regards=
Vijay

 

 

::DISCLAIMER::
---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= -----------------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and inte= nded for the named recipient(s) only. E-mail transmission is not guaranteed= to be secure or error-free as information could be intercepted, corrupted,= lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its con= tents (with or without referred errors) shall therefore not attach any liab= ility on the originator or HCL or its affiliates. Views or opinions, if any= , presented in this email are solely those of the author and may not necessarily reflect the views or opinions = of HCL or its affiliates. Any form of reproduction, dissemination, copying,= disclosure, modification, distribution and / or publication of this messag= e without the prior written consent of authorized representative of HCL is strictly prohibited. If you have re= ceived this email in error please delete it and notify the sender immediate= ly. Before opening any email and/or attachments, please check them for viru= ses and other defects.
---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ----------------------------------------------------- --_000_SG2PR0401MB20149B68694F8BC4EE43232EDC240SG2PR0401MB2014_-- From nobody Wed Apr 17 13:52:43 2019 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 8753012043A; Wed, 17 Apr 2019 13:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8IxKslAuOTh; Wed, 17 Apr 2019 13:52:39 -0700 (PDT) Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09DA2120436; Wed, 17 Apr 2019 13:52:38 -0700 (PDT) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3HKqa46014853; Wed, 17 Apr 2019 21:52:36 +0100 Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9D7C92203B; Wed, 17 Apr 2019 21:52:36 +0100 (BST) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS id 8866B2203A; Wed, 17 Apr 2019 21:52:36 +0100 (BST) Received: from LAPTOPK7AS653V ([103.3.123.228]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3HKqW3H010927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 17 Apr 2019 21:52:35 +0100 Reply-To: From: "Adrian Farrel" To: Cc: Date: Wed, 17 Apr 2019 21:52:31 +0100 Organization: Old Dog Consulting Message-ID: <037201d4f55f$7c1a65b0$744f3110$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdT1Xx4OjKOFd1C9TdSS/Ex9pK51mw== Content-Language: en-gb X-Originating-IP: 103.3.123.228 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24558.001 X-TM-AS-Result: No--5.155-10.0-31-10 X-imss-scan-details: No--5.155-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24558.001 X-TMASE-Result: 10--5.155200-10.000000 X-TMASE-MatchedRID: pTq0mT1IyRYX8+K+77XxXRes/RxhysDbu5JZGDTd7j4tuWsgnp67iyf+ fye9oWdYWJ6/1ccMUdfIEdWXReluJmMNX/9K+QfeKWuiyZLRI4ALitYSIrUiBzpPoMRMO7SyqJl o5lQZWaoDhYUBRNwT+h9l1zPMOb+6TX7PJ/OU3vL+xOhjarOnHpNiK8T6rXI23n8eBZjGmUzkwj HXXC/4I7I7zVffJqTzkKP4Gj9+uSGQUtAsWML5OHo7IOKn+OOt75vSGNSgzs7MZRnrEC3q/n7cG d19dSFd X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: [Pce] IPR Disclosed During WG Last Call on draft-ietf-pce-association-diversity X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 20:52:42 -0000 Hi WG, We currently have a working group last call on draft-ietf-pce-association-diversity that will expire on 4/30. During this last call we received notification of an IPR disclosure. You can find this at https://datatracker.ietf.org/ipr/3493/ As part of the last call, the chairs request that, as individuals, you all consider this IPR and its licence terms. Please don't enter into a discussion on the mailing list about the IPR, its relevance, or the licence terms. But please factor into your last call considerations whether you are willing to have the draft advance in its current state, whether you want to see modifications to the draft, or you think the WG should abandon the draft. The absence of comments on this topic will mean that we carry on as normal. Thanks, Adrian (for the PCE chairs) From nobody Wed Apr 17 13:59:37 2019 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 AC0E31203E7 for ; Wed, 17 Apr 2019 13:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrZs3gbU8uWa for ; Wed, 17 Apr 2019 13:59:33 -0700 (PDT) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D777B12002F for ; Wed, 17 Apr 2019 13:59:32 -0700 (PDT) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3HKv8J7017923; Wed, 17 Apr 2019 21:59:31 +0100 Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 724532203B; Wed, 17 Apr 2019 21:57:08 +0100 (BST) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS id 5C8702203A; Wed, 17 Apr 2019 21:57:08 +0100 (BST) Received: from LAPTOPK7AS653V ([103.3.123.228]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3HKv4Ss016156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 17 Apr 2019 21:57:06 +0100 Reply-To: From: "Adrian Farrel" To: "'Vijayanand C - ERS, HCL Tech'" Cc: References: In-Reply-To: Date: Wed, 17 Apr 2019 21:57:03 +0100 Organization: Old Dog Consulting Message-ID: <037801d4f560$1e216e80$5a644b80$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0379_01D4F568.7FE5D680" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKlVSQwdQD7JRT15Fy1TqRqYcVT4aSgFG/Q Content-Language: en-gb X-Originating-IP: 103.3.123.228 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24558.001 X-TM-AS-Result: No--27.570-10.0-31-10 X-imss-scan-details: No--27.570-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24558.001 X-TMASE-Result: 10--27.569900-10.000000 X-TMASE-MatchedRID: 8HTFlOrbAtHxIbpQ8BhdbOPEkNSS7Y82UAjrAJWsTe+Qp4MBBY/CMfSD rEkaBHA7dwvRxvSoxhznb+MY8K3ln+Rtngz40hbxSEQN/D/3cG5RwfT2oEaYdMWkDW4kV3Warhb YM4baEt2vMdF01x7FjAE+V7uuiHSoE2ZRbV2rc3HpnOP6QxEGtiHRyYscnjAYw62uSG5kL1ZG+J JNYSOR1264FCeAp6h4LJRk5VZOf3Tgs0cK/2puyb50lYduDghOBGvINcfHqhccXmBZ3mI5SYWWR 6RfoVX6JaVXJb4ySQx7aKUDRbhLKIEfH1ylpBDOq4QhBU51QA/8vWy4J4eAKeMHX2e+FnuNyDeF o9hA/rg7AMSG8qYX2TuBVsb8V9kaBuA1FNX1rpqpvjJtAL8lc+/PojcyF5jzUZA0M/8CmKioKCK keJEujngehhF9nCQTNCY0GHysXmRa6A8uGqEyv6mukiZOfPi2R1J8k5XcAcSabNoYojBQdks0bH XPJdwe5tUpPQ+IUHfapj84rS3NVgVnfa7xoeysGCW3KaLghNUuz+MqIXgImCw8GaCddlLXOzkcl RoxuAedDxzrKc5ZsEmlX2scVfePArfIDVjQDX7BtFDYGmaWKuq/uWzz2rh3+TdKNkxxkWSoBV9s c+TYx+I+Ja+Fp+EYrBBSnn/GVMan+dP7GcjVHbqQyAveNtg6Mx981lgKTcP7n73d09vr91H/zAu GbtqkUk2JdCKdaTMkw19B3BcLFoIiDu0n/+6xi+m1DDPm2yI5LRtPnepd1ZIC4CO/S0X+LFlXZd 2HA7ARFZK/o5ioWLm0dKX3HvBN6QVVIQvF5sSeAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyLr8uVzX avvg4QViJlGwPJ1sPyrDAKWKAVVmVDAM/mJfJL5c5EZ9/HBwREJSAgAYtGTDgRuVPVRow== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Pce] algorithm for CSPF in WDM networks X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 20:59:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0379_01D4F568.7FE5D680 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Vijay, =20 The thing about central computation is that you can use any algorithm = you like. You could use a CSPF modification of Dijkstra. You could use = AI. You could do modified random walk. =20 Unlike a distributed computation that needs to be consistent across the = network to avoid looping, a central algorithm only has to be internally = consistent. =20 Of course, least cost (or shortest path) is only one of the = considerations in a WDM network. There are wavelength continuity = concerns, optical impairments, future blocking considerations, power = consumption thoughts, interference with other established light paths = (which is kind of another take on optical impairments), and so on and so = on. Many PhD hours have been expended =F0=9F=98=8A =20 Cheers, Adrian =20 PS There are books on this topic. Ask Igor Bryskin if he knows a good = one. =20 From: Pce On Behalf Of Vijayanand C - ERS, HCL = Tech Sent: 16 April 2019 07:23 To: pce@ietf.org Subject: [Pce] algorithm for CSPF in WDM networks =20 hello all,=20 I have a question. =20 I would like to know what algorithm is recommended for path computation = across WDM network by a PCE. Will it be a modified version of dijkstra - = with one run to check for optical constraints at every hop included into = the SPF tree and find shortest path by metric , or the K-th shortest = path algorithm to continuously explore many paths and check optical = constraints( such as wavelength continuity, ROADM directionality = constraint etc) on each of the paths one by one =20 Please give your suggestions/experience. =20 Regards Vijay =20 =20 ::DISCLAIMER:: -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= ----------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and = intended for the named recipient(s) only. E-mail transmission is not = guaranteed to be secure or error-free as information could be = intercepted, corrupted, lost, destroyed, arrive late or incomplete, or = may contain viruses in transmission. The e mail and its contents (with = or without referred errors) shall therefore not attach any liability on = the originator or HCL or its affiliates. Views or opinions, if any, = presented in this email are solely those of the author and may not = necessarily reflect the views or opinions of HCL or its affiliates. Any = form of reproduction, dissemination, copying, disclosure, modification, = distribution and / or publication of this message without the prior = written consent of authorized representative of HCL is strictly = prohibited. If you have received this email in error please delete it = and notify the sender immediately. Before opening any email and/or = attachments, please check them for viruses and other defects. -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -----------------------------------------------------------=20 ------=_NextPart_000_0379_01D4F568.7FE5D680 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi = Vijay,

 

The thing = about central computation is that you can use any algorithm you like. = You could use a CSPF modification of Dijkstra. You could use AI. You = could do modified random walk.

 

Unlike a = distributed computation that needs to be consistent across the network = to avoid looping, a central algorithm only has to be internally = consistent.

 

Of course, = least cost (or shortest path) is only one of the considerations in a WDM = network. There are wavelength continuity concerns, optical impairments, = future blocking considerations, power consumption thoughts, interference = with other established light paths (which is kind of another take on = optical impairments), and so on and so on. Many PhD hours have been = expended 😊

 

Cheers,

Adrian

 

PS There = are books on this topic. Ask Igor Bryskin if he knows a good = one.

 

From: Pce = <pce-bounces@ietf.org> On Behalf Of Vijayanand C - ERS, HCL = Tech
Sent: 16 April 2019 07:23
To: = pce@ietf.org
Subject: [Pce] algorithm for CSPF in WDM = networks

 

hello all, 

I have a question.

 

I would like to know what algorithm is recommended = for path computation across WDM network by a PCE. Will it be a modified = version of dijkstra - with one run to check for optical constraints at = every hop included into the SPF tree and find shortest path by metric , = or the K-th shortest path algorithm to continuously explore many paths = and check optical constraints( such as wavelength continuity, ROADM = directionality constraint etc) on each of the paths one by = one

 

Please give your suggestions/experience.

 

Regards
Vijay

 

 

::DISCLAIMER::
------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -----------------
The contents of this e-mail and any attachment(s) = are confidential and intended for the named recipient(s) only. E-mail = transmission is not guaranteed to be secure or error-free as information = could be intercepted, corrupted, lost, destroyed, arrive late or = incomplete, or may contain viruses in transmission. The e mail and its = contents (with or without referred errors) shall therefore not attach = any liability on the originator or HCL or its affiliates. Views or = opinions, if any, presented in this email are solely those of the author = and may not necessarily reflect the views or opinions of HCL or its = affiliates. Any form of reproduction, dissemination, copying, = disclosure, modification, distribution and / or publication of this = message without the prior written consent of authorized representative = of HCL is strictly prohibited. If you have received this email in error = please delete it and notify the sender immediately. Before opening any = email and/or attachments, please check them for viruses and other = defects.
-------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= ----------------------------------------------------------------------- =

------=_NextPart_000_0379_01D4F568.7FE5D680-- From nobody Wed Apr 17 20:03:58 2019 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 39D5E1200CE; Wed, 17 Apr 2019 20:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvdS1UlzCJTh; Wed, 17 Apr 2019 20:03:53 -0700 (PDT) Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 561521202B2; Wed, 17 Apr 2019 20:03:50 -0700 (PDT) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3I33mOn010434; Thu, 18 Apr 2019 04:03:48 +0100 Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 133072203A; Thu, 18 Apr 2019 04:03:48 +0100 (BST) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs3.iomartmail.com (Postfix) with ESMTPS id F21A722032; Thu, 18 Apr 2019 04:03:47 +0100 (BST) Received: from LAPTOPK7AS653V ([223.71.64.254]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3I33h5O015887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 18 Apr 2019 04:03:46 +0100 Reply-To: From: "Adrian Farrel" To: Cc: Date: Thu, 18 Apr 2019 04:03:42 +0100 Organization: Old Dog Consulting Message-ID: <004301d4f593$56e8ec10$04bac430$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AdT1kyzTVLsrTLJlQvSfZ/+wP9ISSw== X-Originating-IP: 223.71.64.254 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24558.001 X-TM-AS-Result: No--16.438-10.0-31-10 X-imss-scan-details: No--16.438-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24558.001 X-TMASE-Result: 10--16.438100-10.000000 X-TMASE-MatchedRID: fr/TTUtmA4MtxeejojcKf1t3XMydUaMXI7OxeNfmD+wM74Nf6tTB9j0J SifQ1MZ5e0e6LoLPel6Mg7WKQmz2Z91T2WisFf195gCHftmwEMIPRI8ISSLxYtMDJ7q5Av0D2P1 3j4ZncXCR0k5ZRkYy/YYMbWVHfEpWsb2wceClASiEJ5wBUYI5/VV+08YFNHSuMMn1rcqKQagsES mzvABfMt2twJN7QDfVMfkNBEF0H78bZUQXhYPYzEM/y5EMs/JmgHzgwy8qV5rLuEdMBn2IDBdqS cXR1M30N9XZd6eriH0sNBMhvcCRJ0gMxOkBoMP0fxzygoxuBhgsleOknNBI0w5SzgJNSArLEz15 s9uoqMua8V8pK2dHWmG3DUUIXNicpFgBaw7b8+xwUSK4/EeOxSlayzmQ9QV0Fp7kniXxovPJJmH lkMf/d7ezBTuf/LXdxeqaE5xFvprKb+cHmQ4jTWA/V00XWjDtoKO8hENbdctb8pv4L0h+IiZ+zl rjgR1nlRWka3+UM5OURY6cPY9DAxUItuET49IlCmEn+y8Sa8Yk80hXoYXyaxtDdc/8nLiy9Tvad hXG9g1U7al7gYl2kxm20HYf5Ey/k1qm3fDyMGTGpnII6axD806O6aa3icn3rrmlNXieXJSkN49f piuFteLzNWBegCW2XC3N7C7YzrfQqQhSw0x2VN0H8LFZNFG7JQhrLH5KSJ0= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: [Pce] Shepherd review of draft-ietf-pce-stateful-pce-auto-bandwidth-08 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 03:03:56 -0000 Hello authors, Sorry about the clunk as this draft shifted between shepherd. I have some fairly minor review comments (below). Could you please address these in a new revision. Meanwhile, I will start on the shepherd write-up ready to move ahead as quickly as possible. Thanks, Adrian --- Odd leading space on 4th line of Abstract --- Abstract para 2 s/Automatic bandwidth/Automatic bandwidth adjustment/ ?? --- 2.3 Down-Adjustment-Interval s/lesser/less/ --- I found the definition of Maximum Average Bandwidth and the definitions of Up/Down-Adjustment-Interval to be circular. Unless, perhaps, the definition of Adjustment-Interval is missing. That is, Maximum Average Bandwidth is defined as max {Bandwidth-Sample(i)} for each sample interval i in the Adjustment-Internal But Up/Down-Adjustment-Interval both appear to be dependent on Maximum Average Bandwidth. --- 3. s/the PCC, the LSP that/the PCC, which LSPs/ --- 4.1 OLD Auto-Bandwidth feature allows automatic and dynamic adjustment of the reserved bandwidth of an LSP over time, i.e. without network operator intervention to accommodate the varying traffic demand of the LSP. NEW The Auto-Bandwidth feature allows automatic and dynamic adjustment of the reserved bandwidth of an LSP over time (i.e., without network operator intervention) to accommodate the varying traffic demand of the LSP. END --- 4.1 has... The bandwidth adjustment uses the make-before-break (MBB) signaling method so that there is no disruption to the traffic flow carried by the LSP. I think this should be... Bandwidth adjustment must not cause disruption to the traffic flow carried by the LSP. One way to achieve this is to use the make- before-break (MBB) signaling method. This is the softest way I can think of saying what you don't want to say which is that RSVP-TE signaling supports in-place bandwidth adjustmnt simply by sending a new Path message. (Noting that failure to make the adjustment can be seen either in a non-fatal PathErr or in a Resv with unchanged bandwidth.) Similarly in 4.3 maybe... OLD It should be noted that any bandwidth change requires re-signaling of an LSP in a make-before-break fashion, which can further trigger preemption of lower priority LSPs in the network. NEW It should be noted that any bandwidth change requires re-signaling of an LSP, which can further trigger preemption of lower priority LSPs in the network. END --- 4.2 has... When the Auto-Bandwidth feature is enabled, the measured traffic rate is periodically sampled at each Sample-Interval (which can be configured by an operator and the default value as 5 minutes) by the PCC which is the head-end node of the LSP. As you know, in the PCE architecture, the PCC is not necessarily the head-end LSR. You need either to restrict this function to only operating when the PCC *is* the head-end LSR, or you need to re-word slightly. Either works for me. --- I wonder whether you intend that Section 4 (in particular Section 4.2) is normative in this document. It could be that you are just describing the procedures in a general way - in which case a one line statement of that would address my concern. Or it could be that you intend to define how auto-bandwidth adjustment must be implemented. That is, the document claims to describe changes to PCEP to support auto-bandwidth, but this section appears to be describing how auto- bandwidth must be implemented, and I don't think I agree that the description is completely wise. For example... The PCC, in-charge of calculating the bandwidth to be adjusted, will adjust the bandwidth of the LSP to the highest traffic rate sample (MaxAvgBw) amongst the set of bandwidth samples collected over the adjustment-interval period (in the Up or Down direction). ...means that a single spike in a potentially very small window over a potentially very large period (defaults are 5 minutes in 24 hours) could see a readjustment of the LSP's bandwidth. But such a spike could easily be a freak and it seems unwise to take bandwidth out of the network for it without allowing the application of operator policy. More generally, if this document is defining auto-bandwidth as an MPLS-TE function, it belongs in TEAS (or possibly MPLS), while if it is defining PCEP extensions, it is fine where it is. --- 5.2 s/PCEP peer the/PCEP peer of the/ --- Section 5.2 There are various MUSTs and MUST NOTs for the attribute values, there is a need to include a description of the error processing when these conditions are not met. -- Section 5.2 Since the AUTO-BANDWIDTH-ATTRIBUTES TLV is a MUST for all LSPs with Auto-BW feature, do we want to encode all the sub-TLVs every-time in all PCEP messages? Instead, could we say that sub-TLV is only included if there is a change between the last information and now? The default values for missing sub-TLVs apply for the first PCEP message for the LSP? -- --- 5.2.1 You might explain that 604800 seconds is 7 days. --- 5.2.3 s/PCEP peer the/PCEP peer of the/ --- 5.2.3 Is it worth noting that regardless of how the threshold are set, the adjustment will not be made until at least one sample-interval simply because no sample will be made on which to base a comparison with a threshold? --- 5.2.3.1 If the difference between the current MaxAvgBw and the current bandwidth reservation is greater than or less than or equal to the threshold value, the LSP bandwidth is adjusted to the current bandwidth demand (MaxAvgBw). "greater than or less than or equal to" You mean regardless of the setting of this threshold value, the LSP bandwidth is adjusted? No, you don't mean that! How about... If the modulus of difference between the current MaxAvgBw and the current bandwidth reservation is greater than or equal to the threshold value, the LSP bandwidth is adjusted to the current bandwidth demand (MaxAvgBw). --- 6. Security Considerations Please expand this section a little. You should certainly include RFC8281 as reference. Also include more on TLS use. -- 8.3. AUTO-BANDWIDTH-ATTRIBUTES Sub-TLV Consider making a **few** code points for experiments into this sub-TLV range? - It says that "AUTO-BANDWIDTH-ATTRIBUTES Sub-TLV Types" is a sub-registry in the "PCEP TLV Type Indicators", which is not the case. OLD: This document specifies the AUTO-BANDWIDTH-ATTRIBUTES Sub-TLVs. IANA is requested to create an "AUTO-BANDWIDTH-ATTRIBUTES Sub-TLV Types" sub-registry in the "PCEP TLV Type Indicators" for the sub-TLVs carried in the AUTO-BANDWIDTH-ATTRIBUTES TLV. New sub-TLV are assigned by Standards Action [RFC8126]. NEW: This document specifies the AUTO-BANDWIDTH-ATTRIBUTES Sub-TLVs. IANA is requested to create an "AUTO-BANDWIDTH-ATTRIBUTES Sub-TLV Types" sub-registry within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the type indicator space for sub-TLVs of the AUTO-BANDWIDTH-ATTRIBUTES TLV. New sub-TLV are assigned by Standards Action [RFC8126]. The valid range of values in the registry is 0-65535. IANA is requested to initialize the registry with the following values. All other values in the registry should be marked as "Unassigned". END -- Nits expand RBNF, LSPA From nobody Fri Apr 19 19:45:09 2019 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D970120096; Fri, 19 Apr 2019 19:45:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: db3546@att.com, Adrian Farrel , draft-ietf-pce-applicability-actn@ietf.org, pce@ietf.org, pce-chairs@ietf.org, adrian@olddog.co.uk Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <155572830712.5507.16328677539735365933.idtracker@ietfa.amsl.com> Date: Fri, 19 Apr 2019 19:45:07 -0700 Archived-At: Subject: [Pce] Last Call: (Applicability of the Path Computation Element (PCE) to the Abstraction and Control of TE Networks (ACTN)) to Informational RFC X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2019 02:45:07 -0000 The IESG has received a request from the Path Computation Element WG (pce) to consider the following document: - 'Applicability of the Path Computation Element (PCE) to the Abstraction and Control of TE Networks (ACTN)' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-05-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Abstraction and Control of TE Networks (ACTN) refers to the set of virtual network (VN) operations needed to orchestrate, control and manage large-scale multi-domain TE networks so as to facilitate network programmability, automation, efficient resource sharing, and end-to-end virtual service aware connectivity and network function virtualization services. The Path Computation Element (PCE) is a component, application, or network node that is capable of computing a network path or route based on a network graph and applying computational constraints. The PCE serves requests from Path Computation Clients (PCCs) that communicate with it over a local API or using the Path Computation Element Communication Protocol (PCEP). This document examines the applicability of PCE to the ACTN framework. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-pce-applicability-actn/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-pce-applicability-actn/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Apr 22 11:00:06 2019 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 9C0981202F5 for ; Mon, 22 Apr 2019 11:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvT6sXdAeeFp for ; Mon, 22 Apr 2019 11:00:03 -0700 (PDT) Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25C2E120077 for ; Mon, 22 Apr 2019 11:00:03 -0700 (PDT) Received: by mail-it1-x134.google.com with SMTP id a190so19086251ite.4 for ; Mon, 22 Apr 2019 11:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=tg0as3TTYWxv99jSY+9fxsPL8LZSmW2Aw1dVas/RvDk=; b=DuBnkKKXKcQMlMP/FxA/MyHv+LCNv0XTnmTjkfPdPjhZEqVwiddkGSclGZyuIWYld8 lfwGoKr3e5bgLMfsK72cBsRYXu4bAOuaHERmrPnYgAHduJiN9I+aLfwLpM6RRwQ1l/xa CpTyyzdG8gvvTJqCurCLA3yej102lKbzgRB/wpjIOV9a2zpKrGq18hq3Xzk49XDCRrAY zD2USzNDp6ngKTVR7r8zGhpnp4C8PJOJ4jnnXlB7+s+d1NWTBtHHsnlbrUALLsabLbpE Gpt8hKI+7sUaVn+yoIy/bKP8nJcFSsEc53LdTuk2NqAmi0A3A9yVsOra+voAVBVN8Zzy z/ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=tg0as3TTYWxv99jSY+9fxsPL8LZSmW2Aw1dVas/RvDk=; b=LJt7HFcIA/zIVe6pCPhNcIkCxyhj7JSN/+5NNOvWrKib9BCMcBBEStcvma/icNMs43 CCkNBJrb1qXn6iKRnF8WZpoLklMxZMKV84o3wrRd8eauHSUtN91NA+X8ZjDJn9HyKIr9 sLtH7dyT+DqpFwbl7bFPTGqqOK0fmEsxWEQPFZq+GTSRRGxIb03X461XJqA+yY294Ml9 vzUhmhWTXPHWJonFfVi2jsaht32cVTbxpFoHOqMvDrGZQD9xvmfXEMqQb96dDcWywzkg qvCTQF3NErAFd8QPnRJ2s1AttsctUYKPt7hS4om0MBV1b3nkkxi8LsOTSDGDlJwNJtO6 m5sg== X-Gm-Message-State: APjAAAXr1jaeztN47//D/3JoaWzW43nzwglQ2Mxy70tbKbyaRO6RPbnr 1OylcDIBpUVBf2FyCWuds5lHk8cO7NOkS8alTGEWoA== X-Google-Smtp-Source: APXvYqyVMxGNjyzVcSWNWFzRPkAd62i/0Knc1oEayW+X0z/aOiUbwaGBZQcinYdw8HhQcSTgBEy36q6FDDXInq4DJKE= X-Received: by 2002:a24:1d15:: with SMTP id 21mr14385263itj.164.1555956001943; Mon, 22 Apr 2019 11:00:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dhruv Dhody Date: Mon, 22 Apr 2019 23:29:25 +0530 Message-ID: To: pce@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Pce] Proposed Implementation Policy for PCE WG X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2019 18:00:05 -0000 Hi WG, You still have a few days (till 24th) to raise any concerns with the proposed implementation policy! Thanks! PCE Chairs On Tue, Apr 9, 2019 at 10:01 PM Dhruv Dhody wrote: > > Hi WG, > > In discussion with our ADs and with other WG chairs in the Routing > Area, the PCE chairs have decided that it would be good for the > working group to have a stated policy about what implementation is > needed, desired, or required before a draft can advance for > publication as an RFC. The full range of options is available from "no > implementation required" up to "multiple independent and > inter-operable implementations required". The purposes are to help > ensure quality and implementable RFCs, to make sure that our work is > truly relevant and needed, and to understand the relative priorities > of our work. > > The chairs briefly mentioned this at the IETF 104 PCE WG meeting, and > we promised to start a discussion on what 'Implementation Policy' to > set for the PCE WG. > > This is a subject for the WG to decide through the usual rough > consensus, but the chairs would like to start the discussion with a > proposal as follows - > > "All WG I-Ds are required to include an 'Implementation Status' > Section (as per RFC7942) to document known existing or planned > implementations. The chairs can make exceptions on a per-document > basis." > > Please raise any concern with the proposed implementation policy by > 24th April 2019. > > Thanks! > Adrian, Dhruv & Julien From nobody Mon Apr 22 21:32:38 2019 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 4AC3612001E; Mon, 22 Apr 2019 21:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFrmgBoYE35r; Mon, 22 Apr 2019 21:32:34 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 194281201EB; Mon, 22 Apr 2019 21:32:33 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id p23so11376538iol.13; Mon, 22 Apr 2019 21:32:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TS8yMbzU25WG2KtseNy+GjG5DI1B6Jaw+TRC3CLmXtQ=; b=goxKRkuAqoGDY3jOwposPegFqJkQ852NcqQ+nswXbCLxa86h2ad7N5vKHo0XhufwJE MhGq3C0k+LVVD9V3OjYL6TkbCOWIRL2vOEWmllcc2pwh/HHz23NXWOIXd1Sd3aow9Tes acXSjW8KGia1OsDW+5AhrcU7+yiERYUGMMjtvqZRyXgvwluuURQcqNihecogWVbhE0dS NfdG7R3lk8n4TMRHIDEU7qJHIh3foQH1VhzJFMygjbljxYTVyfUJnl/hGsQJJR+KG96J tSnx8ffy4pLKluTC6d/Gle4gH5di8JOLZKDLpmsSuyuLNBkgjvJrJ+XqPleS4cFFoW5I juHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TS8yMbzU25WG2KtseNy+GjG5DI1B6Jaw+TRC3CLmXtQ=; b=qeRD718VpNLVE5tav1Nzxce6u25Mdh1rurr1aZC+u6KdCB0LQG32HKkbm8U5sh88ZE ziMj6jTxlxkI97pOMY22tTLA9FaiBIAcYpcCrxfYkOs9CU6zvU09LYEbC/OiJYmjYdSR 5hyPLddQNDkPF8Ic8h5b7gLqCRwbCGcZP82Uz6WSwEbdW9i4W1WVlnYG0/4verxBLsOc 2Cem3megq2d4JkKmJNsdEvr/5f1UbRcil/RF+hP9n0u7FVScqxjylCIcz8ttXIAsXmyG L282zB/aCRhMz38iDR4tepeFvofwQfJvOdTvZLm3xY1jwpmVxT1QFkCtY707ukqzlIZ+ yoRQ== X-Gm-Message-State: APjAAAWKeb+WmFk5/VF2GaxQDRHHF5aSyBE2e1I11zeJpMvq+j5Ozb8b jmjEIlwiPEuRvA6wSzNF8aAqGgoLlH7MMNT3qns8/zIe X-Google-Smtp-Source: APXvYqxymjcSMQqOHIlG5Lqre7V6Fb852cQugCpCzC3vGLFcIBC8u2kP9GBGSa+b2ATk038iBpBfeFvpqqUza4XyWQA= X-Received: by 2002:a6b:c382:: with SMTP id t124mr1013739iof.158.1555993953078; Mon, 22 Apr 2019 21:32:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dhruv Dhody Date: Tue, 23 Apr 2019 10:01:57 +0530 Message-ID: To: Hariharan Ananthakrishnan Cc: draft-ietf-pce-stateful-path-protection@ietf.org, pce@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Pce] IPR poll on draft-ietf-pce-stateful-path-protection X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 04:32:36 -0000 I am not aware of any IPR applicable to this draft that should be disclosed in accordance with IETF IPR rules. Thanks! Dhruv (contributor) On Wed, Apr 10, 2019 at 8:27 AM Hariharan Ananthakrishnan wrote: > > Hi authors, > > In preparation for Working Group last call on this draft, I'd like all > authors and contributors to confirm on the list that they are in compliance > with IETF IPR rules. > > Please respond (copying the mailing list) to say one of: > > I am not aware of any IPR applicable to this draft that should be disclosed > in accordance with IETF IPR rules. > > I am aware of IPR applicable to this draft, and it has already been > disclosed to the IETF. > > I am aware of IPR applicable to this draft, but that has not yet been > disclosed to the IETF. I will work to ensure that it will be disclosed in a > timely manner. > > Thanks, > - Hari > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From nobody Mon Apr 22 21:35:07 2019 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 54B461202F3; Mon, 22 Apr 2019 21:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fqefF40zA_t; Mon, 22 Apr 2019 21:35:02 -0700 (PDT) Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2DBC120305; Mon, 22 Apr 2019 21:35:02 -0700 (PDT) Received: by mail-it1-x132.google.com with SMTP id y204so21348761itf.3; Mon, 22 Apr 2019 21:35:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8DTpj+e9eg3C6vmWIExkrARHpDlX8rP+TbBAff5YMO8=; b=fH07FLq7YmTEV/sSboS1vpFfCOemLZPVw6YO9QTidmqgPrvSTZrsI06m4itwbnUyLF V4grT4hRxPpzf5ZCvKn0GhjgZ38GwZd34uazo8n+cNk7Tq3c6mHqd0Tc3ayvRcQYjHEx lsCt1dJfQ5LeCEAVjNFnBN0a0bnVPA777P5bgrxFqf7SpBN1430oi5Eikym00fdgyUct rfITJ1/Eqvu+Wg3V0tXO9B06RmetOQDzWfi7sLHQkqkd1oWGXiCYTJh6iSN3iCQ7IrXf jmS0vzoV6gVoOOymX9dWB5OIjhEuEjIJb0UFA2D6ZzM5Pmm2YyI6CxI8pYo4+wFr9Vrx dnuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8DTpj+e9eg3C6vmWIExkrARHpDlX8rP+TbBAff5YMO8=; b=tQQzfHww+8EGUw5FfUekP16p7xjjvg5GjlhTEvCexV6J2T4XABkDVnDxxgR+D329o+ kbx0/Z8oWUR7BeskoyPR1zKst28p9e6Dxj1GsWHlfR9gV6U6lctvwXi5g/XE4eFco4Ar fxJWS77A/dmH/tPcT/nwdOfZ2jKePb3oGsjMZ5n+LzvIMpdupW6RqenzCqnrviwgtF+w qc8UG1WdQDUQaoXHeowULgj4C3Vos0kggvmdHZkY/9Cqrw5+Swbb458rK1I2uCU782sv QShGpV/W3pVgsvSbJmFT1W/6OAKr+YaWbVozsEfMs32MuSN1NRJglIHMYUbKFlvCWpIC Vlpw== X-Gm-Message-State: APjAAAU58WTzUi/8TqQSgWlDB/VDL0lX5cmgKQziPC4gItT8sXlxbAC4 i7/nDat4eLxme0YasfO+wGjfaPiMyWwEoF16GaGhWXVI X-Google-Smtp-Source: APXvYqzskr/JuyaccfBDaf0bMXiEtGh2vjy1RCBu6NukgvIzHP1gUGVG7pMiaAjtgN2W1hI8aHXzluYa7bzVU3SiqYM= X-Received: by 2002:a02:80e:: with SMTP id 14mr14551117jac.71.1555994101796; Mon, 22 Apr 2019 21:35:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dhruv Dhody Date: Tue, 23 Apr 2019 10:04:25 +0530 Message-ID: To: Hariharan Ananthakrishnan Cc: draft-ietf-pce-association-diversity@ietf.org, pce@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Pce] IPR poll on draft-ietf-pce-association-diversity X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 04:35:06 -0000 I am aware of IPR applicable to this draft, and it has already been disclosed to the IETF. Thanks! Dhruv (Contributor) On Wed, Apr 10, 2019 at 8:27 AM Hariharan Ananthakrishnan wrote: > > Hi authors, > > In preparation for Working Group last call on this draft, I'd like all > authors and contributors to confirm on the list that they are in compliance > with IETF IPR rules. > > Please respond (copying the mailing list) to say one of: > > I am not aware of any IPR applicable to this draft that should be disclosed > in accordance with IETF IPR rules. > > I am aware of IPR applicable to this draft, and it has already been > disclosed to the IETF. > > I am aware of IPR applicable to this draft, but that has not yet been > disclosed to the IETF. I will work to ensure that it will be disclosed in a > timely manner. > > Thanks, > - Hari > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From nobody Mon Apr 22 21:50:04 2019 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 39F7C120334 for ; Mon, 22 Apr 2019 21:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netflix.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtQ3oulSzTxv for ; Mon, 22 Apr 2019 21:50:01 -0700 (PDT) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C1C212026B for ; Mon, 22 Apr 2019 21:50:01 -0700 (PDT) Received: by mail-vs1-xe2f.google.com with SMTP id g127so7514757vsd.6 for ; Mon, 22 Apr 2019 21:50:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DalCKnGb3wRdI84/HWOIk1wGjEipNtGRGx/0LPot3Sc=; b=W5/bpi8waDfrrx7+kAqVpN8GS5trWYxj5YSPWoBM0xT828DdKeF7TL5sF29Q2abmDl HVmm7UTXOS5iss8y3u2elkV+eDTgxDBxJkn27tSeZyrtpUu/RJYPvcosLpjoLhjpaFV9 V9sXs5acJ/7egOMSXcBaMCPlpYxrBfxqVmKKw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DalCKnGb3wRdI84/HWOIk1wGjEipNtGRGx/0LPot3Sc=; b=Z81riWwKuDkK4EqdkDGBd8ITvSPnztsegOhVI+c8LES7qIeH2VVUkG7eQFu/1eQ2X7 TcMxbUmx2AI3STe09ZOjfe73SZy9nFGQ1ZaZ0cgX2FXcpyRwbKbg+0pfI9HaKdgwayk+ yUg0fTYj+kYALqiCZd+hcx46Xy8rTqejcDVkjWTZV6CVCtTe7I/+JIDUR8X12nj5XA9r DCD3CqOK0ckPzof9EmItcKOVD0CE7N5Vsi6gB7oDLVi5YDY2w36wmIAkfqmvGy1RDlFG 5rN3q+NvEO7IIEVDXiihEzonav/qj/TH0e/CkDcjgEHSdAknkXbhagy6XVO+P0pZr7ec 7akg== X-Gm-Message-State: APjAAAVoeGuvFaMejTSwFHS+eHq0qUjo9qDQMJ2Abrxl6Kh/whYmXL7X 99iITgN2/U0bHd9WrH6awI/oYOjY6T/riEimcYsxBNlp X-Google-Smtp-Source: APXvYqxnZjK2K53WB1SsyUZFeAYzi6jJrHEDDv8cBfqHqx5CxT+cAZpXM/xV0AHoqtwbQUn44gpBH96RSl995RC/G5s= X-Received: by 2002:a67:f414:: with SMTP id p20mr12054441vsn.94.1555995000381; Mon, 22 Apr 2019 21:50:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Hariharan Ananthakrishnan Date: Mon, 22 Apr 2019 21:49:49 -0700 Message-ID: To: draft-ietf-pce-association-diversity@ietf.org Cc: pce@ietf.org Content-Type: multipart/alternative; boundary="00000000000045540505872b513a" Archived-At: Subject: Re: [Pce] IPR poll on draft-ietf-pce-association-diversity X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 04:50:03 -0000 --00000000000045540505872b513a Content-Type: text/plain; charset="UTF-8" Hi Authors, Please respond ASAP if you have not already done so. The WC LC runs till 4/30. - Hari On Tue, Apr 9, 2019 at 7:57 PM Hariharan Ananthakrishnan wrote: > Hi authors, > > In preparation for Working Group last call on this draft, I'd like all > authors and contributors to confirm on the list that they are in compliance > with IETF IPR rules. > > Please respond (copying the mailing list) to say one of: > > I am not aware of any IPR applicable to this draft that should be disclosed > in accordance with IETF IPR rules. > > I am aware of IPR applicable to this draft, and it has already been > disclosed to the IETF. > > I am aware of IPR applicable to this draft, but that has not yet been > disclosed to the IETF. I will work to ensure that it will be disclosed in a > timely manner. > > Thanks, > - Hari > > --00000000000045540505872b513a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Authors,

Please respond ASAP if you have not already done so. The WC LC runs till = 4/30.

- Hari

On Tue, Apr 9, 2019 = at 7:57 PM Hariharan Ananthakrishnan <hari@netflix.com> wrote:
Hi authors,

In preparation for Working Group last call on this draft, I'd like all
authors and contributors to confirm on the list that they are in compliance
with IETF IPR rules.

Please respond (copying the mailing list) to say one of:

I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.

I am aware of IPR applicable to this draft, and it has already been
disclosed to the IETF.

I am aware of IPR applicable to this draft, but that has not yet been
disclosed to the IETF. I will work to ensure that it will be disclosed in a
timely manner.

Thanks,
- Hari
--00000000000045540505872b513a-- From nobody Mon Apr 22 21:50:21 2019 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 C3ABD12033A for ; Mon, 22 Apr 2019 21:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netflix.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nuxIERYpFPt for ; Mon, 22 Apr 2019 21:50:14 -0700 (PDT) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A4D012026B for ; Mon, 22 Apr 2019 21:50:14 -0700 (PDT) Received: by mail-vs1-xe2f.google.com with SMTP id s11so7537160vsn.0 for ; Mon, 22 Apr 2019 21:50:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YvXqVIcQ3zWgto6uw7sB2e3z4Lr+g2wE4oCQgpNzSL0=; b=KVxlA5R+JykebaWauNiX9281PN2MMby/+fqCUjS9nZu0hGoEn8Js8SdrolDzOim4s7 1vKYWaKl09fm5hXBHyI+vwUbPlfweuaVfe4sbKUlgcRazQVyuNniK4B9dQX4RzVYYk5i wTDFc/RJqY0Ze2DtWpUccjURrSLaRe0EUyTq0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YvXqVIcQ3zWgto6uw7sB2e3z4Lr+g2wE4oCQgpNzSL0=; b=FWHLX9Nm2xuUf5KIAfZiv3mhGS0QRPPfpS7MO8C+r4CpiaUDOk2XdPQQN1EjIbhwft XzTUMZlQBjYLOlU2MlF/AGm/CwM++Sb4kAKxJ//p6dL05E879uDea/y8dc0KdBCtfSvX rKQdfeELH/LJWmvdOkWQfAGnIoe6JVG3YABzWn+76eHqzOt67E5WkcPWczmohNvlqP2j 6mgeftelIF63PEzCIODc+5dv4pvUUbrKZD2hUYIe828QF1Rr1l8jcYqtkl/fLs5Hz3am pVxLKNX/8nCONUQWvkYWfg7KDe21MyfXy6bzkmxY/7Tp9+RPQ+cmQci6dnlKHfmmCWaL S3Gw== X-Gm-Message-State: APjAAAXKpSTQszZiwN2CN+JA5mJYxITTmwADWP8do6CG4VcDdYVyKwKO 2HshmfKRwCzbRuoTXJRImWxttKP2YLAeqwJeHyxA7g== X-Google-Smtp-Source: APXvYqxpeZu4JpdbGqZ+uT0r+pYWzlkvSddEnOcBOpYqAZpVxC6I6wRcuueHG6TPnx8z8A1RmNWPJxvuVZkXIAsknAQ= X-Received: by 2002:a05:6102:3cc:: with SMTP id n12mr11792644vsq.58.1555995013356; Mon, 22 Apr 2019 21:50:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Hariharan Ananthakrishnan Date: Mon, 22 Apr 2019 21:50:02 -0700 Message-ID: To: draft-ietf-pce-stateful-path-protection@ietf.org Cc: pce@ietf.org Content-Type: multipart/alternative; boundary="0000000000000b4eff05872b52ae" Archived-At: Subject: Re: [Pce] IPR poll on draft-ietf-pce-stateful-path-protection X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 04:50:20 -0000 --0000000000000b4eff05872b52ae Content-Type: text/plain; charset="UTF-8" Hi Authors, Please respond ASAP if you have not already done so. The WC LC runs till 4/30. - Hari On Tue, Apr 9, 2019 at 7:57 PM Hariharan Ananthakrishnan wrote: > Hi authors, > > In preparation for Working Group last call on this draft, I'd like all > authors and contributors to confirm on the list that they are in compliance > with IETF IPR rules. > > Please respond (copying the mailing list) to say one of: > > I am not aware of any IPR applicable to this draft that should be disclosed > in accordance with IETF IPR rules. > > I am aware of IPR applicable to this draft, and it has already been > disclosed to the IETF. > > I am aware of IPR applicable to this draft, but that has not yet been > disclosed to the IETF. I will work to ensure that it will be disclosed in a > timely manner. > > Thanks, > - Hari > > --0000000000000b4eff05872b52ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Authors,
<= div class=3D"gmail_default">
Please r= espond ASAP if you have not already done so. The WC LC runs till 4/30.

- Hari=

On Tue, Apr 9, 2019 at 7:57 PM Hariharan Ananthakrishnan <hari@netflix.com> wrote:
= 
Hi authors,

In preparation for Working Group last call on this draft, I'd like all
authors and contributors to confirm on the list that they are in compliance
with IETF IPR rules.

Please respond (copying the mailing list) to say one of:

I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.

I am aware of IPR applicable to this draft, and it has already been
disclosed to the IETF.

I am aware of IPR applicable to this draft, but that has not yet been
disclosed to the IETF. I will work to ensure that it will be disclosed in a
timely manner.

Thanks,
- Hari
--0000000000000b4eff05872b52ae-- From nobody Mon Apr 22 21:59:02 2019 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF6F12036E; Mon, 22 Apr 2019 21:59:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: dhruv.ietf@gmail.com, pce@ietf.org, db3546@att.com, pce-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155599554057.21060.8006190108779176561.idtracker@ietfa.amsl.com> Date: Mon, 22 Apr 2019 21:59:00 -0700 Archived-At: Subject: [Pce] pce - New Meeting Session Request for IETF 105 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 04:59:01 -0000 A new meeting session request has just been submitted by Dhruv Dhody, a Chair of the pce working group. --------------------------------------------------------- Working Group Name: Path Computation Element Area Name: Routing Area Session Requester: Dhruv Dhody Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: spring mpls teas ccamp Second Priority: idr lsr rtgarea detnet Third Priority: bier bess netconf netmod sfc rtgwg pals opsawg panrg People who must be present: Deborah Brungard Julien Meuric Dhruv Dhody Resources Requested: Special Requests: Do not schedule against RTG area BOF (if any) --------------------------------------------------------- From nobody Tue Apr 23 01:52:35 2019 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 EFAAA12023C for ; Tue, 23 Apr 2019 01:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.29 X-Spam-Level: X-Spam-Status: No, score=-0.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FiaH5y479XJv for ; Tue, 23 Apr 2019 01:52:32 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1DA21200A2 for ; Tue, 23 Apr 2019 01:52:32 -0700 (PDT) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 44pHJZ5hScz8sv2 for ; Tue, 23 Apr 2019 10:52:30 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.38]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 44pHJZ51Dzz5vP4 for ; Tue, 23 Apr 2019 10:52:30 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup (10.114.31.59) by OPEXCAUBM5C.corporate.adroot.infra.ftgroup (10.114.13.38) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 23 Apr 2019 10:52:30 +0200 Received: from [10.193.71.81] (10.168.234.6) by OPEXCLILM43.corporate.adroot.infra.ftgroup (10.114.31.59) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 23 Apr 2019 10:52:30 +0200 From: To: References: <23743_1554818758_5CACA6C6_23743_383_1_70372f0e-4531-b398-6d3a-af97c7d7f40e@orange.com> Organization: Orange Message-ID: <6722_1556009550_5CBED24E_6722_135_1_e06df694-1cd9-7190-793a-5628e57be427@orange.com> Date: Tue, 23 Apr 2019 10:52:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <23743_1554818758_5CACA6C6_23743_383_1_70372f0e-4531-b398-6d3a-af97c7d7f40e@orange.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [10.168.234.6] Archived-At: Subject: Re: [Pce] WG LC for draft-ietf-pce-association-diversity and draft-ietf-pce-stateful-path-protection X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 08:52:34 -0000 Hi all, Only one week left to review: no reason to wait for the last minute, do not be shy to share your comments and/or implementation status. Thanks, Adrian, Dhruv & Julien On 09/04/2019 16:05, julien.meuric@orange.com wrote: > Hi all, > > This message initiates a bulk WG Last Call for both > draft-ietf-pce-association-diversity-06 and > draft-ietf-pce-stateful-path-protection-04. Please review these > documents and share your feedback using the PCE mailing list. > > If you have an implementation of any of them, you may let the chairs > know privately. > > This double LC will last for 3 weeks and will end on Tuesday April 30. > > Thanks, > > Adrian, Dhruv & Julien _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Tue Apr 23 18:26:30 2019 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 6400D120026; Tue, 23 Apr 2019 18:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T_F04iaNK31f; Tue, 23 Apr 2019 18:26:25 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 909F0120172; Tue, 23 Apr 2019 18:26:24 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id k2so986938lje.10; Tue, 23 Apr 2019 18:26:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BNfIQsWJbdxb49KDESgdFAqE8lDHOCTrGp+EbGWHjoc=; b=G9Vn4BW7w0uPp6qrWdy08LhJOoUWXHzZut5FKk4DsL6I5PGEbg9iqRRZRdnyUUvV6E sXMQ7HNBaOjZCckQyOPItnMgVMFA01B9Br356ExdiAg7TCGy977v4v9Sx7VY/rNJtxew z0lbNKzzAgzgzmpxSBdhqfBc+HXWHpaBLR/VxwmDlGi4+ZNM+PDNwPq88cO0IVz89A9t icg4Wzwc2Auh5KD0+EevrNhpEfabKrBm4LhFLo0eX0ZqEabF3LQGxvzsoSNqd4pLdFot mJUyr2rxeQwiWJyr06u6J0LgvEF/vc76d7jfjkOf7joMR/16Ktk8uaXE4+63qfK0QzAk zkxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BNfIQsWJbdxb49KDESgdFAqE8lDHOCTrGp+EbGWHjoc=; b=DHm3sBesGXV/6Nt83Y2K72TXsnRIQewUfc/CzcEUPaJ1D0VQgpvXBU/07/0bhVffhT C4Zg/m6ZBJiuiaWuIs2C7WUhrMcLkwWRL2A48V9P/MRZ8m+QWQ9nHVUzrX5OGxyQqKAK A3VO1ACtHHvaKZzJZoBRQyXBSJGzP8U+2peNEl0FlcWSxLdokr+igZ9Qn5tZsBsxmLNu hfxCtDJW6yO68+thxDLdu9Z6+mxuzQNfsKY79XVlsFiY8nJ5cjf67C3rl17/uHRE3hox Ip6CHDwq1Pip2RyVGffnC+9kynKFpA/vSken7HLl1BhXCkJRUZlLHWqJVagYYYVClHkM WWsA== X-Gm-Message-State: APjAAAWpVjXp5kAD2TfH0wwRop0rgAynPMjRGJO1yfZYe17Hks2GaAkz QlBJXZMw1VkLlYbWh/lLb8vyJvAo0qkzmhhYEg== X-Google-Smtp-Source: APXvYqxChhos8hR0IAWqDgTwZAmwcamsVIHAFKD87ByNm5rc88qmpKhwV1FwHokBS50uvywPbwK5C65lx7fCCOKxdrc= X-Received: by 2002:a2e:309:: with SMTP id 9mr16345695ljd.114.1556069182690; Tue, 23 Apr 2019 18:26:22 -0700 (PDT) MIME-Version: 1.0 References: <004301d4f593$56e8ec10$04bac430$@olddog.co.uk> In-Reply-To: <004301d4f593$56e8ec10$04bac430$@olddog.co.uk> From: Rakesh Gandhi Date: Tue, 23 Apr 2019 21:26:11 -0400 Message-ID: To: adrian@olddog.co.uk Cc: draft-ietf-pce-stateful-pce-auto-bandwidth@ietf.org, pce@ietf.org Content-Type: multipart/alternative; boundary="000000000000e15bb505873c9607" Archived-At: Subject: Re: [Pce] Shepherd review of draft-ietf-pce-stateful-pce-auto-bandwidth-08 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 01:26:28 -0000 --000000000000e15bb505873c9607 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Adrian for the detailed review and suggestions. Please see replies inline with ... On 2019-04-17, 11:03 PM, "Adrian Farrel" wrote: Hello authors, Sorry about the clunk as this draft shifted between shepherd. I have some fairly minor review comments (below). Could you please address these in a new revision. Meanwhile, I will start on the shepherd write-up ready to move ahead as quickly as possible. Thanks, Adrian --- Odd leading space on 4th line of Abstract Fixed. --- Abstract para 2 s/Automatic bandwidth/Automatic bandwidth adjustment/ ?? Added =E2=80=93 =E2=80=9CThe automatic bandwidth feature=E2=80=9D --- 2.3 Down-Adjustment-Interval s/lesser/less/ Fixed. --- I found the definition of Maximum Average Bandwidth and the definitions of Up/Down-Adjustment-Interval to be circular. Unless, perhaps, the definition of Adjustment-Interval is missing. That is, Maximum Average Bandwidth is defined as max {Bandwidth-Sample(i)} for each sample interval i in the Adjustment-Internal But Up/Down-Adjustment-Interval both appear to be dependent on Maximum Average Bandwidth. Removed the Adjustment-Interval from the Max Average Bandwidth definition. That should remove the circular dependency. --- 3. s/the PCC, the LSP that/the PCC, which LSPs/ Fixed. --- 4.1 OLD Auto-Bandwidth feature allows automatic and dynamic adjustment of th= e reserved bandwidth of an LSP over time, i.e. without network operato= r intervention to accommodate the varying traffic demand of the LSP. NEW The Auto-Bandwidth feature allows automatic and dynamic adjustment o= f the reserved bandwidth of an LSP over time (i.e., without network operator intervention) to accommodate the varying traffic demand of the LSP. END Fixed. --- 4.1 has... The bandwidth adjustment uses the make-before-break (MBB) signaling method so that there is no disruption to the traffic flow carried by the LSP. I think this should be... Bandwidth adjustment must not cause disruption to the traffic flow carried by the LSP. One way to achieve this is to use the make- before-break (MBB) signaling method. This is the softest way I can think of saying what you don't want to say which is that RSVP-TE signaling supports in-place bandwidth adjustmnt simply by sending a new Path message. (Noting that failure to make the adjustment can be seen either in a non-fatal PathErr or in a Resv with unchanged bandwidth.) Fixed. Similarly in 4.3 maybe... OLD It should be noted that any bandwidth change requires re-signaling o= f an LSP in a make-before-break fashion, which can further trigger preemption of lower priority LSPs in the network. NEW It should be noted that any bandwidth change requires re-signaling o= f an LSP, which can further trigger preemption of lower priority LSPs in the network. END Fixed. --- 4.2 has... When the Auto-Bandwidth feature is enabled, the measured traffic rat= e is periodically sampled at each Sample-Interval (which can be configured by an operator and the default value as 5 minutes) by the PCC which is the head-end node of the LSP. As you know, in the PCE architecture, the PCC is not necessarily the head-end LSR. You need either to restrict this function to only operating when the PCC *is* the head-end LSR, or you need to re-word slightly. Either works for me. Updated. =E2=80=9Cby the PCC, when the PCC is the head-end node of the= LSP.=E2=80=9D --- I wonder whether you intend that Section 4 (in particular Section 4.2) is normative in this document. It could be that you are just describing the procedures in a general way - in which case a one line statement of that would address my concern. Or it could be that you intend to define how auto-bandwidth adjustment must be implemented. That is, the document claims to describe changes to PCEP to support auto-bandwidth, but this section appears to be describing how auto- bandwidth must be implemented, and I don't think I agree that the description is completely wise. Added =E2=80=93 =E2=80=9CThis section describes the Auto-Bandwidth fea= ture in a general way.=E2=80=9D For example... The PCC, in-charge of calculating the bandwidth to be adjusted, will adjust the bandwidth of the LSP to the highest traffic rate sample (MaxAvgBw) amongst the set of bandwidth samples collected over the adjustment-interval period (in the Up or Down direction). ...means that a single spike in a potentially very small window over a potentially very large period (defaults are 5 minutes in 24 hours) could see a readjustment of the LSP's bandwidth. But such a spike could easily be a freak and it seems unwise to take bandwidth out of the network for it without allowing the application of operator policy. Reworded the sentence. =E2=80=9CThe PCC, in-charge of calculating the bandwidth to be adjusted, can decide to adjust the bandwidth of the LSP to the highest traffic rate sample depending on the operator policy= =E2=80=9D More generally, if this document is defining auto-bandwidth as an MPLS-TE function, it belongs in TEAS (or possibly MPLS), while if it is defining PCEP extensions, it is fine where it is. --- 5.2 s/PCEP peer the/PCEP peer of the/ Added. --- Section 5.2 There are various MUSTs and MUST NOTs for the attribute values, there i= s a need to include a description of the error processing when these conditions are not met. Added =E2=80=93 =E2=80=9C The adjustment-interval parameter MUST NOT be less than the sample-interval, otherwise the Sub-TLV MUST be ignored and the previous value is maintained.=E2=80=9D -- Section 5.2 Since the AUTO-BANDWIDTH-ATTRIBUTES TLV is a MUST for all LSPs with Auto-BW feature, do we want to encode all the sub-TLVs every-time in al= l PCEP messages? Instead, could we say that sub-TLV is only included if there is a chang= e between the last information and now? The default values for missing sub-TLVs apply for the first PCEP message for the LSP? -- Added. --- 5.2.1 You might explain that 604800 seconds is 7 days. Added. --- 5.2.3 s/PCEP peer the/PCEP peer of the/ Fixed. --- 5.2.3 Is it worth noting that regardless of how the threshold are set, the adjustment will not be made until at least one sample-interval simply because no sample will be made on which to base a comparison with a threshold? Added. --- 5.2.3.1 If the difference between the current MaxAvgBw and the current bandwidth reservation is greater than or less than or equal to the threshold value, the LSP bandwidth is adjusted to the current bandwidth demand (MaxAvgBw). "greater than or less than or equal to" You mean regardless of the setting of this threshold value, the LSP bandwidth is adjusted? No, you don't mean that! How about... If the modulus of difference between the current MaxAvgBw and the current bandwidth reservation is greater than or equal to the threshold value, the LSP bandwidth is adjusted to the current bandwidth demand (MaxAvgBw). Updated. --- 6. Security Considerations Please expand this section a little. You should certainly include RFC8281 as reference. Also include more on TLS use. Updated. -- 8.3. AUTO-BANDWIDTH-ATTRIBUTES Sub-TLV Consider making a **few** code points for experiments into this sub-TLV range? Added. - It says that "AUTO-BANDWIDTH-ATTRIBUTES Sub-TLV Types" is a sub-registry in the "PCEP TLV Type Indicators", which is not the case. OLD: This document specifies the AUTO-BANDWIDTH-ATTRIBUTES Sub-TLVs. IAN= A is requested to create an "AUTO-BANDWIDTH-ATTRIBUTES Sub-TLV Types" sub-registry in the "PCEP TLV Type Indicators" for the sub-TLVs carried in the AUTO-BANDWIDTH-ATTRIBUTES TLV. New sub-TLV are assigned by Standards Action [RFC8126]. NEW: This document specifies the AUTO-BANDWIDTH-ATTRIBUTES Sub-TLVs. IAN= A is requested to create an "AUTO-BANDWIDTH-ATTRIBUTES Sub-TLV Types" sub-registry within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the type indicator space for sub-TLVs of the AUTO-BANDWIDTH-ATTRIBUTES TLV. New sub-TLV are assigned by Standards Action [RFC8126]. The valid range of values in the registr= y is 0-65535. IANA is requested to initialize the registry with the following values. All other values in the registry should be marked as "Unassigned". END Updated. -- Nits expand RBNF, LSPA Fixed. Thanks, Rakesh --000000000000e15bb505873c9607 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

=C2=A0Thanks Adrian for the detailed review= and suggestions.=C2=A0 Please see replies inline with <RG>...=

=C2=A0

On 2019-04-17, 11:03 PM, "Adrian Farrel"= ; <adrian@olddog.co.uk> wrot= e:

=C2=A0

=C2=A0=C2=A0=C2=A0 Hello authors,

=C2=A0=C2=A0 =C2=A0

=C2=A0=C2=A0=C2=A0 Sorry about the clunk as this draft shifted between shepherd.

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 I have some fairly minor review comments (below). Could you please address=

=C2=A0=C2=A0=C2=A0 these in a new revision.

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 Meanwhile, I will start on the shepherd write-up ready to move ahead as

=C2=A0=C2=A0=C2=A0 quickly as possible.

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 Thanks,

=C2=A0=C2=A0=C2=A0 Adrian

=C2=A0=C2=A0=C2=A0 ---<= /p>

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 Odd leading space on 4th line of Abstract

=C2=A0

<RG> Fixed.

=C2=A0=C2=A0=C2=A0 ---<= /p>

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 Abstract para 2

=C2=A0=C2=A0=C2=A0 s/Automatic bandwidth/Automatic bandwidth adjustment/ ??

=C2=A0=C2=A0=C2=A0

=C2=A0

<RG> Added =E2=80=93 =E2=80=9CThe automatic= bandwidth feature=E2=80=9D

=C2=A0=C2=A0=C2=A0 ---<= /p>

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 2.3<= /p>

=C2=A0=C2=A0=C2=A0 Down-Adjustment-Interval

=C2=A0=C2=A0=C2=A0 s/lesser/less/

=C2=A0=C2=A0=C2=A0

<RG> Fixed.

=C2=A0=C2=A0=C2=A0 ---<= /p>

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 I found the definition of Maximum Average Bandwidth and the definitions

=C2=A0=C2=A0=C2=A0 of Up/Down-Adjustment-Interval to be circular. Unless, perhaps, the

=C2=A0=C2=A0=C2=A0 definition of Adjustment-Interval is missing.

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 That is, Maximum Average Bandwidth is defined as

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 max {Bandwidth-Sample(i)} for each sample interval i in the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Adjustment-Internal

=C2=A0=C2=A0=C2=A0 But Up/Down-Adjustment-Interval both appear to be dependent on Maximum

=C2=A0=C2=A0=C2=A0 Average Bandwidth.

=C2=A0

<RG> Removed the Adjustment-Interval from t= he Max Average Bandwidth definition. That should remove the circular dependency.

=C2=A0=C2=A0=C2=A0 ---<= /p>

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 3.

=C2=A0=C2=A0=C2=A0 s/the PCC, the LSP that/the PCC, which LSPs/

=C2=A0=C2=A0=C2=A0

<RG> Fixed.

=C2=A0=C2=A0=C2=A0 ---<= /p>

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 4.1<= /p>

=C2=A0=C2=A0=C2=A0 OLD<= /p>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Auto-Bandwidth feature allows automatic and dynamic adjustment of th= e

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 reserved bandwidth of an LSP over time, i.e. without network operator

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 intervention to accommodate the varying traffic demand of the LSP.

=C2=A0=C2=A0=C2=A0 NEW<= /p>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The Auto-Bandwidth feature allows automatic and dynamic adjustment of

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the reserved bandwidth of an LSP over time (i.e., without network

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 operator intervention) to accommodate the varying traffic demand of

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the LSP.

=C2=A0=C2=A0=C2=A0 END<= /p>

=C2=A0=C2=A0=C2=A0

<RG> Fixed.

=C2=A0=C2=A0=C2=A0 ---<= /p>

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 4.1 has...<= /span>

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The bandwidth

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 adjustment uses the make-before-break (MBB) signaling method so that

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 there is no disruption to the traffic flow carried by the LSP.

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 I think this should be...

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Bandwidth adjustment must not cause disruption to the traffic flow

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 carried by the LSP.=C2=A0 One way to achieve this is to use the make-

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 before-break (MBB) signaling method.

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 This is the softest way I can think of saying what you don't want to

=C2=A0=C2=A0=C2=A0 say which is that RSVP-TE signaling supports in-place bandwidth

=C2=A0=C2=A0=C2=A0 adjustmnt simply by sending a new Path message. (Noting that failure to<= /p>

=C2=A0=C2=A0=C2=A0 make the adjustment can be seen either in a non-fatal PathErr or in a

=C2=A0=C2=A0=C2=A0 Resv with unchanged bandwidth.)

=C2=A0

<RG> Fixed.

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 Similarly in 4.3 maybe...

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 OLD<= /p>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 It should be noted that any bandwidth change requires re-signaling of

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 an LSP in a make-before-break fashion, which can further trigger

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 preemption of lower priority LSPs in the network.

=C2=A0=C2=A0=C2=A0 NEW<= /p>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 It should be noted that any bandwidth change requires re-signaling of

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 an LSP, which can further trigger preemption of lower priority LSPs

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in the network.

=C2=A0=C2=A0=C2=A0 END<= /p>

=C2=A0

<RG> Fixed.

=C2=A0=C2=A0=C2=A0 ---<= /p>

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 4.2 has...<= /span>

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 When the Auto-Bandwidth feature is enabled, the measured traffic rate

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is periodically sampled at each Sample-Interval (which can be

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 configured by an operator and the default value as 5 minutes) by the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 PCC which is the head-end node of the LSP.

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 As you know, in the PCE architecture, the PCC is not necessarily the

=C2=A0=C2=A0=C2=A0 head-end LSR. You need either to restrict this function to only

=C2=A0=C2=A0=C2=A0 operating when the PCC *is* the head-end LSR, or you need to re-word

=C2=A0=C2=A0=C2=A0 slightly.= =C2=A0 Either works for me.

=C2=A0

<RG> Updated. =E2=80=9Cby the PCC, when the= PCC is the head-end node of the LSP.=E2=80=9D

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 ---<= /p>

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 I wonder whether you intend that Section 4 (in particular Section 4.2)<= /p>

=C2=A0=C2=A0=C2=A0 is normative in this document. It could be that you are just describing

=C2=A0=C2=A0=C2=A0 the procedures in a general way - in which case a one line statement of

=C2=A0=C2=A0=C2=A0 that would address my concern. Or it could be that you intend to define

=C2=A0=C2=A0=C2=A0 how auto-bandwidth adjustment must be implemented.

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 That is, the document claims to describe changes to PCEP to support

=C2=A0=C2=A0=C2=A0 auto-bandwidth, but this section appears to be describing how auto-

=C2=A0=C2=A0=C2=A0 bandwidth must be implemented, and I don't think I agree that the

=C2=A0=C2=A0=C2=A0 description is completely wise.

=C2=A0=C2=A0=C2=A0

<RG> Added =E2=80=93 =E2=80=9CThis section = describes the Auto-Bandwidth feature in a general way.=E2=80=9D

=C2=A0

=C2=A0

=C2=A0=C2=A0=C2=A0 For example...

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 PCC, in-charge of calculating the bandwidth to be adjusted, will

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 adjust the bandwidth of the LSP to the highest traffic rate sample

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (MaxAvgBw) amongst the set of bandwidth samples collected over the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 adjustment-interval period (in the Up or Down direction).

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 ...means that a single spike in a potentially very small window over

=C2=A0=C2=A0=C2=A0 a potentially very large period (defaults are 5 minutes in 24 hours)

=C2=A0=C2=A0=C2=A0 coul= d see a readjustment of the LSP's bandwidth. But such a spike could

=C2=A0=C2=A0=C2=A0 easily be a freak and it seems unwise to take bandwidth out of the

=C2=A0=C2=A0=C2=A0 network for it without allowing the application of operator policy.

=C2=A0=C2=A0=C2=A0

=C2=A0

<RG> Reworded the sentence.=C2=A0 =E2=80=9CThe PCC, in-charge of calculating the

=C2=A0=C2=A0 bandwidth to be adjusted, can decide to adjust the bandwidth of the

=C2=A0=C2=A0 LSP to the highest traffic rate sample depending on the operator policy=E2=80=9D=

=C2=A0

=C2=A0

=C2=A0=C2=A0=C2=A0 More generally, if this document is defining auto-bandwidth as an

=C2=A0=C2=A0=C2=A0 MPLS-TE function, it belongs in TEAS (or possibly MPLS), while if it is

=C2=A0=C2=A0=C2=A0 defining PCEP extensions, it is fine where it is.

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 ---<= /p>

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 5.2<= /p>

=C2=A0=C2=A0=C2=A0 s/PCEP peer the/PCEP peer of the/

=C2=A0

<RG> Added.

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 ---<= /p>

=C2=A0=C2=A0=C2=A0 Section 5.2=

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 There are various MUSTs and MUST NOTs for the attribute values, there is

=C2=A0=C2=A0=C2=A0 a need to include a description of the error processing when these

=C2=A0=C2=A0=C2=A0 conditions<= /span>

=C2=A0=C2=A0=C2=A0 are not met.

=C2=A0=C2=A0=C2=A0

<RG> Added =E2=80=93

=E2=80=9C The adjustment-interval parameter MUST = NOT be less than the

sample-interval, otherwise the Sub-TLV MUST be ig= nored and the

previous value is maintained.=E2=80=9D

=C2=A0

=C2=A0

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

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 Section 5.2=

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 Since the AUTO-BANDWIDTH-ATTRIBUTES TLV is a MUST for all LSPs with

=C2=A0=C2=A0=C2=A0 Auto-BW feature, do we want to encode all the sub-TLVs every-time in all

=C2=A0=C2=A0=C2=A0 PCEP messages?

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 Instead, could we say that sub-TLV is only included if there is a change

=C2=A0=C2=A0=C2=A0 between the last information and now? The default values for missing

=C2=A0=C2=A0=C2=A0 sub-TLVs apply for the first PCEP message for the LSP?

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 -- <= /p>

<RG> Added.

=C2=A0=C2=A0=C2=A0 ---<= /p>

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 5.2.1

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 You might explain that 604800 seconds is 7 days.

=C2=A0=C2=A0=C2=A0

<RG> Added.

=C2=A0=C2=A0=C2=A0 ---<= /p>

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 5.2.3

=C2=A0=C2=A0=C2=A0 s/PCEP peer the/PCEP peer of the/

=C2=A0

<RG> Fixed.

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 ---<= /p>

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 5.2.3

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 Is it worth noting that regardless of how the threshold are set, the

=C2=A0=C2=A0=C2=A0 adjustment will not be made until at least one sample-interval simply

=C2=A0=C2=A0=C2=A0 because no sample will be made on which to base a comparison with a

=C2=A0=C2=A0=C2=A0 threshold?<= /span>

=C2=A0=C2=A0=C2=A0

<RG> Added.

=C2=A0=C2=A0=C2=A0 ---<= /p>

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 5.2.3.1

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If the difference between the current MaxAvgBw and the current

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 bandwidth reservation is greater than or less than or equal to the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 threshold value, the LSP bandwidth is adjusted to the current

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 bandwidth demand (MaxAvgBw).

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 "greater than or less than or equal to"

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 You mean regardless of the setting of this threshold value, the LSP

=C2=A0=C2=A0=C2=A0 bandwidth is adjusted?

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 No, you don't mean that!

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 How about...

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If the modulus of difference between the current MaxAvgBw and the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 current bandwidth reservation is greater than or equal to the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 threshold value, the LSP bandwidth is adjusted to the current

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 bandwidth demand (MaxAvgBw).

=C2=A0

<RG> Updated.

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 ---<= /p>

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 6.=C2=A0 Security Considerations

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 Please expand this section a little.=C2=A0 You should certainly include RFC8281

=C2=A0=C2=A0=C2=A0 as reference. Also include more on TLS use.

=C2=A0

<RG> Updated.

=C2=A0=C2=A0 =C2=A0

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

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 8.3. AUTO-BANDWIDTH-ATTRIBUTES Sub-TLV

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 Consider making a **few** code points for experiments into this sub-TLV

=C2=A0=C2=A0=C2=A0 range?

=C2=A0=C2=A0=C2=A0

<RG> Added.

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

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 It says that "AUTO-BANDWIDTH-ATTRIBUTES Sub-TLV Types"

=C2=A0=C2=A0=C2=A0 is a sub-registry in the "PCEP TLV Type Indicators", which is not the case.

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 OLD:=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This document specifies the AUTO-BANDWIDTH-ATTRIBUTES Sub-TLVs.=C2=A0 IANA

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is requested to create an "AUTO-BANDWIDTH-ATTRIBUTES Sub-TLV Types"

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sub-registry in the "PCEP TLV Type Indicators" for the sub-TLVs

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 carried in the AUTO-BANDWIDTH-ATTRIBUTES TLV.=C2=A0 New sub-TLV are

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 assigned by Standards Action [RFC8126].

=C2=A0=C2=A0=C2=A0 NEW:=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This document specifies the AUTO-BANDWIDTH-ATTRIBUTES Sub-TLVs.=C2=A0 IANA

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is requested to create an "AUTO-BANDWIDTH-ATTRIBUTES Sub-TLV Types"

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sub-registry within the "Path Computation Element Protocol (PCEP)

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Numbers" registry to manage the type indicator space for sub-TL= Vs of

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the AUTO-BANDWIDTH-ATTRIBUTES TLV.=C2=A0 New sub-TLV are assigned by

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Standards Action [RFC8126]. The valid range of values in the registry

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is 0-65535.=C2=A0 IANA is requested to initialize the registry with the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 following values.=C2=A0 All other values in the registry should be marked

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 as "Unassigned".

=C2=A0=C2=A0=C2=A0 END<= /p>

=C2=A0

<RG> Updated.

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

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 Nits=

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 expand RBNF, LSPA

=C2=A0=C2=A0=C2=A0

<RG> Fixed.

=C2=A0

Thanks,

Rakesh


--000000000000e15bb505873c9607-- From nobody Tue Apr 23 18:39:27 2019 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3828A120026; Tue, 23 Apr 2019 18:39:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: pce@ietf.org Message-ID: <155606996414.32549.597116614169993812@ietfa.amsl.com> Date: Tue, 23 Apr 2019 18:39:24 -0700 Archived-At: Subject: [Pce] I-D Action: draft-ietf-pce-stateful-pce-auto-bandwidth-09.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 01:39:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : PCEP Extensions for MPLS-TE LSP Automatic Bandwidth Adjustment with Stateful PCE Authors : Dhruv Dhody Udayasree Palle Ravi Singh Rakesh Gandhi Luyuan Fang Filename : draft-ietf-pce-stateful-pce-auto-bandwidth-09.txt Pages : 31 Date : 2019-04-23 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. The Stateful PCE extensions allow stateful control of Multi-Protocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs) using PCEP. The automatic bandwidth feature allows automatic and dynamic adjustment of the TE LSP bandwidth reservation based on the volume of traffic flowing through the LSP. This document describes PCEP extensions for automatic bandwidth adjustment when employing an Active Stateful PCE for both PCE-Initiated and PCC-Initiated LSPs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-auto-bandwidth/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-auto-bandwidth-09 https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-pce-auto-bandwidth-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-pce-auto-bandwidth-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 24 12:51:27 2019 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB831203C9; Wed, 24 Apr 2019 12:51:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: pce@ietf.org Message-ID: <155613547749.31981.13401892649924214035@ietfa.amsl.com> Date: Wed, 24 Apr 2019 12:51:17 -0700 Archived-At: Subject: [Pce] I-D Action: draft-ietf-pce-stateful-hpce-07.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 19:51:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : Hierarchical Stateful Path Computation Element (PCE). Authors : Dhruv Dhody Young Lee Daniele Ceccarelli Jongyoon Shin Daniel King Oscar Gonzalez de Dios Filename : draft-ietf-pce-stateful-hpce-07.txt Pages : 23 Date : 2019-04-24 Abstract: A Stateful Path Computation Element (PCE) maintains information on the current network state, including: computed Label Switched Path (LSPs), reserved resources within the network, and pending path computation requests. This information may then be considered when computing new traffic engineered LSPs, and for associated and dependent LSPs, received from Path Computation Clients (PCCs). The Hierarchical Path Computation Element (H-PCE) architecture, provides an architecture to allow the optimum sequence of inter-connected domains to be selected, and network policy to be applied if applicable, via the use of a hierarchical relationship between PCEs. Combining the capabilities of Stateful PCE and the Hierarchical PCE would be advantageous. This document describes general considerations and use cases for the deployment of Stateful PCE(s) using the Hierarchical PCE architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-hpce/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-stateful-hpce-07 https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-hpce-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-hpce-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 24 13:02:39 2019 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 7E65112031B for ; Wed, 24 Apr 2019 13:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=danielking-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMNQcsWcg2iz for ; Wed, 24 Apr 2019 13:02:34 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06F43120052 for ; Wed, 24 Apr 2019 13:02:34 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id 4so6176820wmf.1 for ; Wed, 24 Apr 2019 13:02:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielking-net.20150623.gappssmtp.com; s=20150623; h=sender:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=fi6J9MnEqaXErbK/cYtPApKgBFZoZMR1xvgC19+WBWQ=; b=0gp4gqKICPuzQ9j1+V5KalsyOvryBxyCPOWjXCkU12TnAkDZufSd1jm93lQPPlJqDE lP9bG1JcW3sPbKA1bNSc28Af/hLhR0JHnpjJln+WrPJU/lSEqEnzs/3ixZSMWX2ywcLG ct0R7AmyIVLAfG3oBv/PHNE1EYKuc+BY3pEu1qhQPH2JPMznZnD2a//IAwuL2bOWCfmL 8O7jjoawL0C0+oR84q9hs48VSix6qGV6yp5fSuW6oEARGoT7N0z3xh9/xtDmk2D96jwE qIofSBYHs3E8eTkCQZLdMmqympq5kq0xUpDsmrh217BqNM3nZ51cv3Z4e7XIzS8SzpHP Oxfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=fi6J9MnEqaXErbK/cYtPApKgBFZoZMR1xvgC19+WBWQ=; b=dMcep4GZ609lNB7CZxq+QvjfSpdjJPzxC3bjMD63vgUgxc69EQdvctpDs/5wCEHwAL kN/j7/oqNGmpKVL9+K1PDdsfB9uHVzbaB6mzBpLL8+RVQDF0HGDTYSyPS5c/ZZ7mRmT1 o+XnOkxm6FedcxhWc1wjONz4DpAEGk9RtQOIHAOyak1rrphpgfOCAAQ08Y0JYPuW8wS3 CILCqfCrRWCcMtivABxJd4BmvSCLPcq9I7ehB366N5w42+nt2mcsvY1s1q3H8Zg2raxc J1eY6R3Rju8bgIeTe1FTGgB1lvOyXM+tTNGEIU29J26pTU+0dGEqA+KWfVGOOgJLBVrr 9YOw== X-Gm-Message-State: APjAAAW6jYvbONxUclDaU2RvDx49a6GZc3WIr7zP1ddB9to8U5Aphr3F blVPJnL0BzQCgffoQO+/yM725w88OPTwLQ== X-Google-Smtp-Source: APXvYqyWlVOo8wnBOkxN6wWPElNQmIgkV7RZkWsAy3Dka1htz6Zv1b5H8mUfZOk2dZLWjVXZ7EL0MA== X-Received: by 2002:a7b:cbd6:: with SMTP id n22mr582730wmi.57.1556136151817; Wed, 24 Apr 2019 13:02:31 -0700 (PDT) Received: from CIPHER (host86-159-26-25.range86-159.btcentralplus.com. [86.159.26.25]) by smtp.gmail.com with ESMTPSA id x84sm24750986wmg.13.2019.04.24.13.02.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Apr 2019 13:02:30 -0700 (PDT) Sender: Daniel King X-Google-Original-Sender: "Daniel King" From: To: References: <155613547749.31981.13401892649924214035@ietfa.amsl.com> In-Reply-To: <155613547749.31981.13401892649924214035@ietfa.amsl.com> Date: Wed, 24 Apr 2019 21:02:27 +0100 Message-ID: <001a01d4fad8$a4dace30$ee906a90$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQH7NtypIV5hm1fQPS7TaYvBa7ke26X/QboA Content-Language: en-gb Archived-At: Subject: Re: [Pce] I-D Action: draft-ietf-pce-stateful-hpce-07.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 20:02:38 -0000 Hi All, We received a number of comments from the PCE document shepherd and also during WG Last Call for this I-D. The recently submitted (07) version of the I-D addresses a number of those comments, including: - Inclusion of use-cases and applicability of hierarchical stateful PCE - Updated references - General nits Our plan is to submit another update soon [1], which addresses the remaining open issues. BR, Dan. [1] https://tools.ietf.org/html/draft-farrel-soon-05 -----Original Message----- From: I-D-Announce On Behalf Of internet-drafts@ietf.org Sent: 24 April 2019 20:51 To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: I-D Action: draft-ietf-pce-stateful-hpce-07.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : Hierarchical Stateful Path Computation Element (PCE). Authors : Dhruv Dhody Young Lee Daniele Ceccarelli Jongyoon Shin Daniel King Oscar Gonzalez de Dios Filename : draft-ietf-pce-stateful-hpce-07.txt Pages : 23 Date : 2019-04-24 Abstract: A Stateful Path Computation Element (PCE) maintains information on the current network state, including: computed Label Switched Path (LSPs), reserved resources within the network, and pending path computation requests. This information may then be considered when computing new traffic engineered LSPs, and for associated and dependent LSPs, received from Path Computation Clients (PCCs). The Hierarchical Path Computation Element (H-PCE) architecture, provides an architecture to allow the optimum sequence of inter-connected domains to be selected, and network policy to be applied if applicable, via the use of a hierarchical relationship between PCEs. Combining the capabilities of Stateful PCE and the Hierarchical PCE would be advantageous. This document describes general considerations and use cases for the deployment of Stateful PCE(s) using the Hierarchical PCE architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-hpce/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-stateful-hpce-07 https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-hpce-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-hpce-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Thu Apr 25 01:54:59 2019 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 4952D120075 for ; Thu, 25 Apr 2019 01:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8dX7CSkHGE4 for ; Thu, 25 Apr 2019 01:54:56 -0700 (PDT) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1A401200D7 for ; Thu, 25 Apr 2019 01:54:55 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id k92so18421134edc.12 for ; Thu, 25 Apr 2019 01:54:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LnXO9uNvQVgqXcS9iPyZ57JpuiGsq4RJCebXFEp2DpA=; b=stWSch7fBQCSHhABMcQHa0T8I/2l4hYN9SWXnxgyynYZY1m+vyAHUJL9f5foTatc1j 1lPTBnavYoiY2PzSGzYiM5aYzt5/UG74fYqLtHXw0/SgzMjY963JVaGTiqwjj9lFG5Cq XBGI20aCkbILR0z5x6yohBs8V3w6+29+caxbsRhQIgzR2X7gxMq1DZz+wqUe9pdsmgQ/ qJqwuMDKsvFRVYfSs8pnM/ZqfXtFKoQYSkKGPWzh7p9yUfGnOr90Fko2jcGqx3DPQtHk NpI+wKWpoAdS88jW2+Q1l+IrB7l5ueJ9h+SatlHred6Q/ahSaST6fGPxFvSn6MNsNJY7 1pqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LnXO9uNvQVgqXcS9iPyZ57JpuiGsq4RJCebXFEp2DpA=; b=IqbjoKotHXZicsrbSlCydH/qr6NQw7XGZnWFuzRAjo21tmDj5C60ToUoyU/c5DEOqy 1aL53QqLLkFz4Yl2Jg9jY2QQeDqcXwcdtuzyhu8stPrtw5LQwAH4pTFboU5SrUyJ1NEq A+RYUJ+OrPMe+wwbBCWp4Cd+RbNoJnjHWYz0hEjIjuC7gHAG5F9PIX8DoqiW2dfKsgJo IJuoMpBgkK4/nIVTkfwlww2czoSZjaU07i099ekQtTg0WfNscivSkAUj2wg8E6dzqvwU inHmOX8Xgeq3tth4gV/4S8FU3es9i0cowTCf4cOVt3nZIO/L8w1YHDvrk2bH+wXxf8n8 9Jrw== X-Gm-Message-State: APjAAAXXot5t+91u6HATlHpTXLeTogD8Cd9s6G2Jezkr/3B6EsWHWVgT tp7ychXbxjRnnetnzhEnQN/Hhkcan0ooE2772Z3f4A== X-Google-Smtp-Source: APXvYqzRL6HGOhKARfYGVLZgddytWknbLHTHaATlHl2g6Y0odgKXSom5jvxgeEip+7AQ+ADweW6QlUqJdqbFrjyhZbg= X-Received: by 2002:a50:89f6:: with SMTP id h51mr23641225edh.131.1556182493843; Thu, 25 Apr 2019 01:54:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ina Minei Date: Thu, 25 Apr 2019 10:54:42 +0200 Message-ID: To: Hariharan Ananthakrishnan Cc: draft-ietf-pce-stateful-path-protection@ietf.org, pce Content-Type: multipart/alternative; boundary="000000000000c0af8f058756f876" Archived-At: Subject: Re: [Pce] IPR poll on draft-ietf-pce-stateful-path-protection X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 08:54:57 -0000 --000000000000c0af8f058756f876 Content-Type: text/plain; charset="UTF-8" I am not aware of any IPR applicable to this draft that should be disclosed in accordance with IETF IPR rules. Ina On Tue, Apr 23, 2019 at 6:50 AM Hariharan Ananthakrishnan wrote: > Hi Authors, > > Please respond ASAP if you have not already done so. The WC LC runs till > 4/30. > > - Hari > > On Tue, Apr 9, 2019 at 7:57 PM Hariharan Ananthakrishnan > wrote: > >> Hi authors, >> >> In preparation for Working Group last call on this draft, I'd like all >> authors and contributors to confirm on the list that they are in compliance >> with IETF IPR rules. >> >> Please respond (copying the mailing list) to say one of: >> >> I am not aware of any IPR applicable to this draft that should be disclosed >> in accordance with IETF IPR rules. >> >> I am aware of IPR applicable to this draft, and it has already been >> disclosed to the IETF. >> >> I am aware of IPR applicable to this draft, but that has not yet been >> disclosed to the IETF. I will work to ensure that it will be disclosed in a >> timely manner. >> >> Thanks, >> - Hari >> >> --000000000000c0af8f058756f876 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 


I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.
Ina

On Tue, Apr 23, 2019 at 6:50 AM Hariharan Ananthakrishnan <hari@netflix.com> wrote:
Hi Authors,

Please respond ASAP if you have not= already done so. The WC LC runs till 4/30.

- Hari

On Tue, Apr 9, = 2019 at 7:57 PM Hariharan Ananthakrishnan <hari@netflix.com> wrote:
Hi authors,

In preparation for Working Group last call on this draft, I'd like all
authors and contributors to confirm on the list that they are in compliance
with IETF IPR rules.

Please respond (copying the mailing list) to say one of:

I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.

I am aware of IPR applicable to this draft, and it has already been
disclosed to the IETF.

I am aware of IPR applicable to this draft, but that has not yet been
disclosed to the IETF. I will work to ensure that it will be disclosed in a
timely manner.

Thanks,
- Hari
--000000000000c0af8f058756f876-- From nobody Thu Apr 25 03:23:58 2019 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 19641120220; Thu, 25 Apr 2019 03:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVMpl3tpKZeT; Thu, 25 Apr 2019 03:23:51 -0700 (PDT) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2F7D1201B9; Thu, 25 Apr 2019 03:23:50 -0700 (PDT) Received: by mail-ot1-x32c.google.com with SMTP id d24so16200863otl.11; Thu, 25 Apr 2019 03:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Sw20EWO+PhlihRAMQJe1cgcSD6PMXK6ItZoU4Tqf6qE=; b=bb0OF6kwymrSIWA4pF5X9hTl1F2OpEcldzZPiFnPOCOrZvDGXx3rQSsShc32vXDnFO S921NmxpreHmi3IBM6bJnIgQtPuhkNA+Se3i2POt9vUqYCHqMHnrwqarMIbSfo2xMRy0 maLd2mg9UwLba4mSUoQtdJJp4BFqXwjxlqiIpaMOx/FMbBrMVrL0JHw4lXl48JIvOSeZ BM7ONTvD99bZ4ZHKH2Y6V8ryQs+JjJYx1dD73N9sr3p6JLMBhhLb7CCeEp+dqfSUA0us IPfP3NvP9dRlitJPcrVSF0FHOE55YufN4XLGor3evrai+V81YfZ0kaeKqeZXLyzlxDvS ut+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Sw20EWO+PhlihRAMQJe1cgcSD6PMXK6ItZoU4Tqf6qE=; b=VNr9rgu8qI1Glagu1tfSh9ZMKh9BVFXrXcxoeHVZBB+W2MBALRvZQ/kMW74qsSpftI F740HzBjr+35DaaCYq8kqZiC4hJDnosvkyYvHiWHewrDHD1dkWSU3YPVb1w4udua1pNF DEVH6MpjRySPIFsFDf4EulVFicmd3CBG+/BWBvL6OT5BxDjuNH2wv5wd+X/QGY5RkKRV CPuaMslQ5wK87kri9jazMK8tTMraSzLKX68eUi/krVQIRG77h3tykktqbw0ov5Pbv2MC X04kYAqX2uDEhnpiWNIxlCZnr+XOB1+0CQBWvwby0xV8jbCzNovCXDSbay7itcDqaCCv KRng== X-Gm-Message-State: APjAAAW/GeAvl0qwAFOK8eLbOq1Zz/DuslEoQWAst9JqVUDTF30fpvty 2hObd5N9pLGzGo3EpP3g+kMXfFdPkmjb5uvD3UM= X-Google-Smtp-Source: APXvYqw+l6p/amFAAh35RpaeSvxWWyWdvvcKNhsyIfBfh5dPiGC0qQQARTLZxMz2yvjl6IfTtxjK7WRvC15JzhPqTW4= X-Received: by 2002:a9d:5e90:: with SMTP id f16mr22297820otl.86.1556187829780; Thu, 25 Apr 2019 03:23:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Edward Date: Thu, 25 Apr 2019 18:23:35 +0800 Message-ID: To: Hariharan Ananthakrishnan Cc: draft-ietf-pce-stateful-path-protection@ietf.org, pce@ietf.org Content-Type: multipart/alternative; boundary="000000000000cc47e10587583616" Archived-At: Subject: Re: [Pce] IPR poll on draft-ietf-pce-stateful-path-protection X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 10:23:57 -0000 --000000000000cc47e10587583616 Content-Type: text/plain; charset="UTF-8" I am not aware of any IPR applicable to this draft that should be disclosed in accordance with IETF IPR rules. On Tue, Apr 23, 2019, 12:50 PM Hariharan Ananthakrishnan wrote: > Hi Authors, > > Please respond ASAP if you have not already done so. The WC LC runs till > 4/30. > > - Hari > > On Tue, Apr 9, 2019 at 7:57 PM Hariharan Ananthakrishnan > wrote: > >> Hi authors, >> >> In preparation for Working Group last call on this draft, I'd like all >> authors and contributors to confirm on the list that they are in compliance >> with IETF IPR rules. >> >> Please respond (copying the mailing list) to say one of: >> >> I am not aware of any IPR applicable to this draft that should be disclosed >> in accordance with IETF IPR rules. >> >> I am aware of IPR applicable to this draft, and it has already been >> disclosed to the IETF. >> >> I am aware of IPR applicable to this draft, but that has not yet been >> disclosed to the IETF. I will work to ensure that it will be disclosed in a >> timely manner. >> >> Thanks, >> - Hari >> >> --000000000000cc47e10587583616 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
I am not aware of any IPR applicable to this draft that should be disc=
losed in accordance with IETF IPR rules.

On Tue, Apr 23, 2019, 12:50 PM Hariharan = Ananthakrishnan <hari@netflix.com> wrote:
Hi = Authors,

Please respond ASAP if you have not already done so. The WC LC runs = till 4/30.

- Hari

On Tue, Apr 9, 2019 at 7:57 PM Hariharan Anantha= krishnan <hari@netflix.com> wrote:
Hi authors,

In preparation for Working Group last call on this draft, I'd like all
authors and contributors to confirm on the list that they are in compliance
with IETF IPR rules.

Please respond (copying the mailing list) to say one of:

I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.

I am aware of IPR applicable to this draft, and it has already been
disclosed to the IETF.

I am aware of IPR applicable to this draft, but that has not yet been
disclosed to the IETF. I will work to ensure that it will be disclosed in a
timely manner.

Thanks,
- Hari
--000000000000cc47e10587583616-- From nobody Thu Apr 25 04:30:59 2019 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 144761200FE; Thu, 25 Apr 2019 04:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Z6Npe75l; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=jR2SgMVm Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygwHJxaiTODU; Thu, 25 Apr 2019 04:30:55 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 819A3120072; Thu, 25 Apr 2019 04:30:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11950; q=dns/txt; s=iport; t=1556191855; x=1557401455; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=pASM+lpsi8WIsKdl6Nij2rKnHx9s8u4lGstsU774mCc=; b=Z6Npe75l284ftdzDviVU7FWXhYhY76GoXMzmjQH8cLnU0EWuV1nW+kyl 2s7pCiEwbiYYoleJn5kg/MoNw/OnWE3wzAEk/3emqwz5tsuLBxfzAIxEm 2fXWNnC/qfDxxKqThj/FxyfPVbrEn8xkwexow356Z2SAe4NDQ1axA4J5X A=; IronPort-PHdr: =?us-ascii?q?9a23=3AUvt6MxwLC3LnVAPXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YRyN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZuAEkzlJdbhbjcxG4JJU1o2t3w=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAADLmcFc/xDFo0hmGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ4vUANoVSAECygKhAWDRwOEUoo3gle?= =?us-ascii?q?SUYRMgS6BJANUDgEBLYRAAheGGSM0CQ4BAwEBBAEBAgECbRwMhUoBAQEBAxI?= =?us-ascii?q?RChMBASwLAQ8CAQgOAwQBASgDAgICMBQJCAIEAQ0FCBqDAYEdTAMcAQKeOQK?= =?us-ascii?q?BNYhfcYEvgnkBAQWFBhiCDQmBMgGLSBeBf4FXgkw+hEYVH4JUMYImjTGEP4d?= =?us-ascii?q?ujHwJAoIIkkWCC4YpjGCLLglNkReDJAIEAgQFAg4BAQWBTziBVnAVO4Jsgg+?= =?us-ascii?q?Db4pTcoEpjigBgSABAQ?= X-IronPort-AV: E=Sophos;i="5.60,393,1549929600"; d="scan'208,217";a="547301933" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Apr 2019 11:30:52 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by bgl-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x3PBUb8Q007401 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 25 Apr 2019 11:30:47 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 25 Apr 2019 06:30:37 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 25 Apr 2019 06:30:37 -0500 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 25 Apr 2019 06:30:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pASM+lpsi8WIsKdl6Nij2rKnHx9s8u4lGstsU774mCc=; b=jR2SgMVmT15PmdRnRV/MMFB+pVJF9XNwQAH5JnwYIeQT204Lie0zimMRQZc2Z22zifXjypPlq+ZFTdveEeOtvhHInqgR9YqHspN07plBvWfjjYctmYIQn6I4PP+HUJ4TwvdrOwj9mrzUjxvVI9xR6kn0SmIboQ4lv0v0fyu9qDQ= Received: from BN8PR11MB3682.namprd11.prod.outlook.com (20.178.220.33) by BN8PR11MB3762.namprd11.prod.outlook.com (20.178.221.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.16; Thu, 25 Apr 2019 11:30:35 +0000 Received: from BN8PR11MB3682.namprd11.prod.outlook.com ([fe80::d5f4:febe:124e:490a]) by BN8PR11MB3682.namprd11.prod.outlook.com ([fe80::d5f4:febe:124e:490a%2]) with mapi id 15.20.1835.010; Thu, 25 Apr 2019 11:30:35 +0000 From: "Siva Sivabalan (msiva)" To: Hariharan Ananthakrishnan , "draft-ietf-pce-stateful-path-protection@ietf.org" CC: "pce@ietf.org" Thread-Topic: IPR poll on draft-ietf-pce-stateful-path-protection Thread-Index: AQHU70kxQN1EC3huMk28cOh65zp+PaY4tLcAgBQhKeA= Date: Thu, 25 Apr 2019 11:30:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=msiva@cisco.com; x-originating-ip: [173.38.117.85] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7e146998-ff11-4f65-d8ea-08d6c9716f34 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:BN8PR11MB3762; x-ms-traffictypediagnostic: BN8PR11MB3762: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 0018A2705B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(136003)(39860400002)(396003)(376002)(199004)(189003)(81166006)(53546011)(66066001)(316002)(73956011)(486006)(76176011)(5660300002)(8936002)(64756008)(6506007)(476003)(102836004)(66476007)(52536014)(66556008)(66946007)(86362001)(11346002)(26005)(66446008)(76116006)(186003)(68736007)(256004)(7696005)(446003)(14444005)(8676002)(81156014)(4326008)(99286004)(6436002)(2906002)(9686003)(2501003)(6306002)(7736002)(97736004)(54896002)(71200400001)(229853002)(33656002)(110136005)(3846002)(14454004)(55016002)(53936002)(25786009)(478600001)(6246003)(6116002)(236005)(74316002)(790700001)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR11MB3762; H:BN8PR11MB3682.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: K3yGpxtkre4AQR0b3k7ToXMimHUJFars24pOe4OiLfq/a3FxwNomQ/h8SQVkDBF4hYW10/Uk1K7c7k7z42l/4wNea52xlkE1HB5PBbVzWmXgxVZT5KCaRsRTJiFJ8LqPL1D6Yu+ZJsP2w4uQYT7MW507dwdp7UYBNqh1YFByMCWOCogIGI26+6ZJNW6ya1p7sz4LfxgXbHwx5hJlVFf1FkK9gLiQo7xmluCjHbQOuW/UFmjkhesd1Bj4R9RYG8nIqOAJjYlRmXgMAPDsSnrCRJdKfcNTZzS9LqGtKBtlOOgJuvpJUzJnPtFNVN3mK/TKFNbQ9zjoqscjT1D+qU/fU70htG4JQdVt0HLc9d+JM+yTiIbixKilyiQYMRBWaADf2xhWJV8ao9HepLpyw62R8gBoIvruOlXPnkg+aGBIquE= Content-Type: multipart/alternative; boundary="_000_BN8PR11MB3682B49BE16706A95ACD0D78A03D0BN8PR11MB3682namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7e146998-ff11-4f65-d8ea-08d6c9716f34 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2019 11:30:35.2474 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3762 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.24, xch-rcd-014.cisco.com X-Outbound-Node: bgl-core-1.cisco.com Archived-At: Subject: Re: [Pce] IPR poll on draft-ietf-pce-stateful-path-protection X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 11:30:58 -0000 --_000_BN8PR11MB3682B49BE16706A95ACD0D78A03D0BN8PR11MB3682namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiBhcHBsaWNhYmxlIHRvIHRoaXMgZHJhZnQgdGhhdCBz aG91bGQgYmUgZGlzY2xvc2VkIGluIGFjY29yZGFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcy4NCg0K DQoNClRoYW5rcywNCg0KU2l2YQ0KDQpGcm9tOiBIYXJpaGFyYW4gQW5hbnRoYWtyaXNobmFuIDxo YXJpQG5ldGZsaXguY29tPg0KU2VudDogRnJpZGF5LCBBcHJpbCAxMiwgMjAxOSAxMjowNiBQTQ0K VG86IGRyYWZ0LWlldGYtcGNlLXN0YXRlZnVsLXBhdGgtcHJvdGVjdGlvbkBpZXRmLm9yZw0KQ2M6 IHBjZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IElQUiBwb2xsIG9uIGRyYWZ0LWlldGYtcGNlLXN0 YXRlZnVsLXBhdGgtcHJvdGVjdGlvbg0KDQoNCkkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFIgYXBw bGljYWJsZSB0byB0aGlzIGRyYWZ0IHRoYXQgc2hvdWxkIGJlIGRpc2Nsb3NlZA0KDQppbiBhY2Nv cmRhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMuDQoNCi0gSGFyaQ0KDQpPbiBUdWUsIEFwciA5LCAy MDE5IGF0IDc6NTcgUE0gSGFyaWhhcmFuIEFuYW50aGFrcmlzaG5hbiA8aGFyaUBuZXRmbGl4LmNv bTxtYWlsdG86aGFyaUBuZXRmbGl4LmNvbT4+IHdyb3RlOg0KDQpIaSBhdXRob3JzLA0KDQoNCg0K SW4gcHJlcGFyYXRpb24gZm9yIFdvcmtpbmcgR3JvdXAgbGFzdCBjYWxsIG9uIHRoaXMgZHJhZnQs IEknZCBsaWtlIGFsbA0KDQphdXRob3JzIGFuZCBjb250cmlidXRvcnMgdG8gY29uZmlybSBvbiB0 aGUgbGlzdCB0aGF0IHRoZXkgYXJlIGluIGNvbXBsaWFuY2UNCg0Kd2l0aCBJRVRGIElQUiBydWxl cy4NCg0KDQoNClBsZWFzZSByZXNwb25kIChjb3B5aW5nIHRoZSBtYWlsaW5nIGxpc3QpIHRvIHNh eSBvbmUgb2Y6DQoNCg0KDQpJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIGFwcGxpY2FibGUgdG8g dGhpcyBkcmFmdCB0aGF0IHNob3VsZCBiZSBkaXNjbG9zZWQNCg0KaW4gYWNjb3JkYW5jZSB3aXRo IElFVEYgSVBSIHJ1bGVzLg0KDQoNCg0KSSBhbSBhd2FyZSBvZiBJUFIgYXBwbGljYWJsZSB0byB0 aGlzIGRyYWZ0LCBhbmQgaXQgaGFzIGFscmVhZHkgYmVlbg0KDQpkaXNjbG9zZWQgdG8gdGhlIElF VEYuDQoNCg0KDQpJIGFtIGF3YXJlIG9mIElQUiBhcHBsaWNhYmxlIHRvIHRoaXMgZHJhZnQsIGJ1 dCB0aGF0IGhhcyBub3QgeWV0IGJlZW4NCg0KZGlzY2xvc2VkIHRvIHRoZSBJRVRGLiBJIHdpbGwg d29yayB0byBlbnN1cmUgdGhhdCBpdCB3aWxsIGJlIGRpc2Nsb3NlZCBpbiBhDQoNCnRpbWVseSBt YW5uZXIuDQoNCg0KDQpUaGFua3MsDQoNCi0gSGFyaQ0K --_000_BN8PR11MB3682B49BE16706A95ACD0D78A03D0BN8PR11MB3682namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K cC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUt bmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZv cm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWls U3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHByZT48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMy MTI1MjkiPkkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFIgYXBwbGljYWJsZSB0byB0aGlzIGRyYWZ0 IHRoYXQgc2hvdWxkIGJlIGRpc2Nsb3NlZCBpbiBhY2NvcmRhbmNlIHdpdGggSUVURiBJUFIgcnVs ZXMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojMjEy NTI5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNv bG9yOiMyMTI1MjkiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImNvbG9yOiMyMTI1MjkiPlNpdmE8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBIYXJpaGFyYW4gQW5hbnRoYWty aXNobmFuICZsdDtoYXJpQG5ldGZsaXguY29tJmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRh eSwgQXByaWwgMTIsIDIwMTkgMTI6MDYgUE08YnI+DQo8Yj5Ubzo8L2I+IGRyYWZ0LWlldGYtcGNl LXN0YXRlZnVsLXBhdGgtcHJvdGVjdGlvbkBpZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4gcGNlQGll dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBJUFIgcG9sbCBvbiBkcmFmdC1pZXRmLXBj ZS1zdGF0ZWZ1bC1wYXRoLXByb3RlY3Rpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHByZT48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMyMTI1MjkiPkkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFIgYXBwbGljYWJsZSB0byB0aGlz IGRyYWZ0IHRoYXQgc2hvdWxkIGJlIGRpc2Nsb3NlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMyMTI1MjkiPmluIGFjY29yZGFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcy48L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMyMTI1MjkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZSBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdyYXA7Ym94LXNpemluZzpib3JkZXItYm94O21h cmdpbi1ib3R0b206MXJlbTtvdmVyZmxvdzphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMTI1MjkiPi0gSGFyaTwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6IzIxMjUyOSI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgQXByIDksIDIwMTkg YXQgNzo1NyBQTSBIYXJpaGFyYW4gQW5hbnRoYWtyaXNobmFuICZsdDs8YSBocmVmPSJtYWlsdG86 aGFyaUBuZXRmbGl4LmNvbSI+aGFyaUBuZXRmbGl4LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJi b3gtc2l6aW5nOmJvcmRlci1ib3g7bWFyZ2luLWJvdHRvbToxcmVtO3doaXRlLXNwYWNlOnByZS13 cmFwO292ZXJmbG93OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5h JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIxMjUyOSI+SGkgYXV0aG9ycyw8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjEyNTI5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMjEyNTI5Ij5JbiBwcmVwYXJhdGlvbiBmb3IgV29ya2luZyBHcm91 cCBsYXN0IGNhbGwgb24gdGhpcyBkcmFmdCwgSSdkIGxpa2UgYWxsPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzIxMjUyOSI+YXV0aG9ycyBhbmQgY29udHJpYnV0b3JzIHRvIGNv bmZpcm0gb24gdGhlIGxpc3QgdGhhdCB0aGV5IGFyZSBpbiBjb21wbGlhbmNlPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5h JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIxMjUyOSI+d2l0aCBJRVRGIElQUiBydWxlcy48bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjEyNTI5Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRh bmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjEyNTI5Ij5QbGVhc2UgcmVzcG9uZCAoY29weWlu ZyB0aGUgbWFpbGluZyBsaXN0KSB0byBzYXkgb25lIG9mOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMyMTI1MjkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMyMTI1MjkiPkkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFIgYXBwbGljYWJsZSB0byB0 aGlzIGRyYWZ0IHRoYXQgc2hvdWxkIGJlIGRpc2Nsb3NlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMyMTI1MjkiPmluIGFjY29yZGFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcy48 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjEyNTI5Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Zl cmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjEyNTI5Ij5JIGFtIGF3YXJlIG9mIElQUiBh cHBsaWNhYmxlIHRvIHRoaXMgZHJhZnQsIGFuZCBpdCBoYXMgYWxyZWFkeSBiZWVuPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJk YW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIxMjUyOSI+ZGlzY2xvc2VkIHRvIHRoZSBJRVRG LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMTI1MjkiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMTI1MjkiPkkgYW0gYXdhcmUgb2YgSVBS IGFwcGxpY2FibGUgdG8gdGhpcyBkcmFmdCwgYnV0IHRoYXQgaGFzIG5vdCB5ZXQgYmVlbjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMTI1MjkiPmRpc2Nsb3NlZCB0byB0aGUg SUVURi4gSSB3aWxsIHdvcmsgdG8gZW5zdXJlIHRoYXQgaXQgd2lsbCBiZSBkaXNjbG9zZWQgaW4g YTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMTI1MjkiPnRpbWVseSBtYW5u ZXIuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIxMjUyOSI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIxMjUyOSI+VGhhbmtzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMTI1MjkiPi0gSGFyaTwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6IzIxMjUyOSI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN8PR11MB3682B49BE16706A95ACD0D78A03D0BN8PR11MB3682namp_-- From nobody Thu Apr 25 04:34:20 2019 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 14BCB120096; Thu, 25 Apr 2019 04:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=SCGs2HIh; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=A36t7s2E Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUrmvhVVYeQg; Thu, 25 Apr 2019 04:34:17 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB589120045; Thu, 25 Apr 2019 04:34:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1418; q=dns/txt; s=iport; t=1556192057; x=1557401657; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=NdCvPOwTBK+L5X0EytVfHaRa5B2dl+nygVWYk3mWZ/o=; b=SCGs2HIhkkT8xBmZtLqodUlYNsIf7UiQMvmnUlLOBG+nKceEffnLHxcA 1REP2q786HJz1w8QWFA9NgeLb+7VZJ4xZCyO2mUYCjxpoKUdsptG+qqLW sljpzR+fQLkfqxWFsXS/5Za7tCnfBFAc0yYkiPpOt8+eaZJEBZdDgy7Zm o=; IronPort-PHdr: =?us-ascii?q?9a23=3Aa0v+bxwyrNbqrE7XCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YRyN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZuAEkzlJdbhbjcxG4JJU1o2t3w=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIAAB2msFc/xTLJq1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBPVADaFUgBAsoCoQFg0cDhFKKN0qCDZcdgS6?= =?us-ascii?q?BJANUDgEBGAsKhEACF4YZIzQJDgEDAQEEAQECAQJtHAyFSgEBAQEDAQEQERE?= =?us-ascii?q?MAQEsDA8CAQgYAgImAgICJQsVEAIEARIIGoMBgWkDHAECDJ4tAoE1iF9xgS+?= =?us-ascii?q?CeQEBBYUGGIINAwaBCycBi0gXgX+BV4JMPoJhAQECgWGDCDGCJo0xmSkJAoI?= =?us-ascii?q?IkkWCC4YpjGCLLglNlDsCBAIEBQIOAQEFgU84gVZwFTuCbIIPg2+FFIU/cgG?= =?us-ascii?q?BKI4oAYEgAQE?= X-IronPort-AV: E=Sophos;i="5.60,393,1549929600"; d="scan'208";a="264602396" Received: from aer-core-3.cisco.com ([173.38.203.20]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Apr 2019 11:34:15 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x3PBY6en008929 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 25 Apr 2019 11:34:11 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 25 Apr 2019 06:34:05 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 25 Apr 2019 06:34:04 -0500 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 25 Apr 2019 06:34:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NdCvPOwTBK+L5X0EytVfHaRa5B2dl+nygVWYk3mWZ/o=; b=A36t7s2Ej+M9l73OF5xmW0uwbFtW5DXg4b4JrxunEv3s0KhyqhBxLkxIoGIeRcUdizi2tdtrkXjhd2rj4RnU+LPJYETUUiTzfHTXhliDrUuk7DCcJKN53p0bKfpsSDEPaxgYs0kqKmLtCz6BB0ElWMIBMAk9GrNKMFQaG9q0Syo= Received: from BN8PR11MB3682.namprd11.prod.outlook.com (20.178.220.33) by BN8PR11MB3603.namprd11.prod.outlook.com (20.178.219.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.12; Thu, 25 Apr 2019 11:34:03 +0000 Received: from BN8PR11MB3682.namprd11.prod.outlook.com ([fe80::d5f4:febe:124e:490a]) by BN8PR11MB3682.namprd11.prod.outlook.com ([fe80::d5f4:febe:124e:490a%2]) with mapi id 15.20.1835.010; Thu, 25 Apr 2019 11:34:03 +0000 From: "Siva Sivabalan (msiva)" To: "draft-ietf-pce-association-diversity@ietf.org" , "pce@ietf.org" Thread-Topic: [Pce] IPR poll on draft-ietf-pce-association-diversity Thread-Index: AQHU70kxUaTgpBoe5kO5yXBG9zYEk6ZJPRaAgAOZq2A= Date: Thu, 25 Apr 2019 11:34:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=msiva@cisco.com; x-originating-ip: [173.38.117.85] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 100791bf-ae69-4ade-f349-08d6c971eb78 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:BN8PR11MB3603; x-ms-traffictypediagnostic: BN8PR11MB3603: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0018A2705B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(396003)(136003)(346002)(376002)(199004)(189003)(229853002)(966005)(8936002)(8676002)(14454004)(81156014)(81166006)(68736007)(6436002)(25786009)(9686003)(478600001)(7696005)(186003)(256004)(14444005)(26005)(316002)(110136005)(97736004)(66446008)(55016002)(486006)(476003)(99286004)(450100002)(102836004)(6506007)(53546011)(11346002)(446003)(76176011)(4744005)(53936002)(2501003)(2906002)(305945005)(6306002)(7736002)(74316002)(66946007)(66476007)(6116002)(66556008)(33656002)(73956011)(3846002)(66066001)(52536014)(5660300002)(86362001)(71190400001)(71200400001)(64756008)(6246003)(76116006); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR11MB3603; H:BN8PR11MB3682.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: lMkQv+QyrvEoBAPo2ew9P8oQ9HbDLaijL4AFEAZCEyrahn+8jVyk+ljDWBWit/jsxlJOKz363cHJXKnbtRPgAGREEeqR63jgT5vsMkfYZACbfnQdtWtS+z8h7LA5BzuPeUnrvg1zVSPY6ocEJxciWGEkjTQh8FG7UtkxLpiDMY6zcoZSCXd3ztZUv7NKBpzEJ9kIcKRDST4LQoHEW701HGKsCE9AhtPuKrbL5iEgnTRaJBOp0SeDXpo6cLvPVelPly979yBl3G5bxqFp08E9SXRRqU00bebGjy4u0+7ChCn0Fhhja5+OBKRWjAIOGu6fB2Pdqn5E5Ut0I6woNUX3k3tmAEYEeZb3BgMyxsn6F5IUbN6kWZ2/eTqn+mawhUUz+CLMd4XsGO8YVRl/xilIpM9NS5C87eC9wUJTYZqDUOM= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 100791bf-ae69-4ade-f349-08d6c971eb78 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2019 11:34:03.6632 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3603 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.22, xch-aln-012.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Pce] IPR poll on draft-ietf-pce-association-diversity X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 11:34:19 -0000 SSBhbSBhd2FyZSBvZiBJUFIgYXBwbGljYWJsZSB0byB0aGlzIGRyYWZ0LCBhbmQgaXQgaGFzIGFs cmVhZHkgYmVlbiBkaXNjbG9zZWQgdG8gdGhlIElFVEYuDQoNClRoYW5rcywNClNpdmENCg0KDQpP biBXZWQsIEFwciAxMCwgMjAxOSBhdCA4OjI3IEFNIEhhcmloYXJhbiBBbmFudGhha3Jpc2huYW4g PGhhcmk9NDBuZXRmbGl4LmNvbUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQo+DQo+IEhpIGF1dGhv cnMsDQo+DQo+IEluIHByZXBhcmF0aW9uIGZvciBXb3JraW5nIEdyb3VwIGxhc3QgY2FsbCBvbiB0 aGlzIGRyYWZ0LCBJJ2QgbGlrZSBhbGwgDQo+IGF1dGhvcnMgYW5kIGNvbnRyaWJ1dG9ycyB0byBj b25maXJtIG9uIHRoZSBsaXN0IHRoYXQgdGhleSBhcmUgaW4gDQo+IGNvbXBsaWFuY2Ugd2l0aCBJ RVRGIElQUiBydWxlcy4NCj4NCj4gUGxlYXNlIHJlc3BvbmQgKGNvcHlpbmcgdGhlIG1haWxpbmcg bGlzdCkgdG8gc2F5IG9uZSBvZjoNCj4NCj4gSSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiBhcHBs aWNhYmxlIHRvIHRoaXMgZHJhZnQgdGhhdCBzaG91bGQgYmUgDQo+IGRpc2Nsb3NlZCBpbiBhY2Nv cmRhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMuDQo+DQo+IEkgYW0gYXdhcmUgb2YgSVBSIGFwcGxp Y2FibGUgdG8gdGhpcyBkcmFmdCwgYW5kIGl0IGhhcyBhbHJlYWR5IGJlZW4gDQo+IGRpc2Nsb3Nl ZCB0byB0aGUgSUVURi4NCj4NCj4gSSBhbSBhd2FyZSBvZiBJUFIgYXBwbGljYWJsZSB0byB0aGlz IGRyYWZ0LCBidXQgdGhhdCBoYXMgbm90IHlldCBiZWVuIA0KPiBkaXNjbG9zZWQgdG8gdGhlIElF VEYuIEkgd2lsbCB3b3JrIHRvIGVuc3VyZSB0aGF0IGl0IHdpbGwgYmUgZGlzY2xvc2VkIA0KPiBp biBhIHRpbWVseSBtYW5uZXIuDQo+DQo+IFRoYW5rcywNCj4gLSBIYXJpDQo+DQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFBjZSBtYWlsaW5nIGxp c3QNCj4gUGNlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcGNlDQo= From nobody Thu Apr 25 04:38:58 2019 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 0EDAE120091; Thu, 25 Apr 2019 04:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCUGfWTgkEsM; Thu, 25 Apr 2019 04:38:56 -0700 (PDT) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 074F7120072; Thu, 25 Apr 2019 04:38:55 -0700 (PDT) Received: by mail-pf1-x432.google.com with SMTP id i17so11030526pfo.6; Thu, 25 Apr 2019 04:38:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=bmT15dnNaxua1O206IDkkbQokWhUk4osJIB7RS2Hqq4=; b=oHU66bIvAzXATcnZjK63U1J6a7K6W8TQNY8bsboPT7Ethga6VD5THJii4xSP/lhNUs jr55HRh4Rvy7OHiECLdAq4NwSQ35/9P/tiF4Zbxy9nxfedXu3NMmAeqr+lS/4/QUIRJd t8Kcx7bOnZHAbWiY+aZT9pfi6Fj96TzcmpbmHlJMwlB0S4joR+lz+MelpBc4ohkmUIek mtA3Dy9Y/uHyOCDOxMLG5R0UxgV4pmYFC+33cv7yl5kW/ibgMTavsOXGsAvCl06IDQhX sLQzfwI/32Oyd4gJjNEV8hc8W/Gz3hOKsXCVWq4e0BMbvEB+kJjbZ3ziLqphZzavY1CI hF/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=bmT15dnNaxua1O206IDkkbQokWhUk4osJIB7RS2Hqq4=; b=fVerf2SN//keiCaA88mU2LlxtDb62VQHFP5hAy1l2ZOC1U2IZXhWIAdCbb6G4NGQe2 /vlWbmdnnfrs9q9zNYeMjFj9sDW4oENEzurLACvq6qUtY80kwwxEKoBikMGtKY6Tas48 xntd7YOoNzX564i8Y5lBB7H95zPBXYYgSVCXp7WiSeYRJYI89DM3ngKEKi5TOXdsYWNY TrMYNTfXAMCM94nLHxAa9gcbP5OYN6MWk6aHI5mjwpq5IjVO+oiuVgXKWVuwQiejnC9C DvJu7Rw/QfyxafGVPdfUWrYSDvBjQ69YL5Rn5zxQ2VIQgLO+AL7rT3KvIYrtj2M04iBa MRHg== X-Gm-Message-State: APjAAAW/d1YFD26ELOPJmQbqAeBeFGvK57IAhO+XyKw8fVaM2pBIPbeP GTVImKxqltmA/hR513TjidAEJhvR X-Google-Smtp-Source: APXvYqzgl2YYLOgZoYiVuLsUnhFiWr7BE093+3/uU7QNY3s9Oq0Fv+3dKjzdg6zDDwHPJu6ppEWHsg== X-Received: by 2002:a63:c10e:: with SMTP id w14mr17022396pgf.206.1556192335379; Thu, 25 Apr 2019 04:38:55 -0700 (PDT) Received: from cbarth-mbp.jnpr.net ([66.129.241.10]) by smtp.gmail.com with ESMTPSA id s19sm28141429pfe.74.2019.04.25.04.38.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Apr 2019 04:38:54 -0700 (PDT) From: Colby Barth Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Thu, 25 Apr 2019 07:38:52 -0400 References: To: "draft-ietf-pce-association-diversity@ietf.org" , "pce@ietf.org" In-Reply-To: Message-Id: <2ACEAB68-1508-438F-8FF7-0DC0D65D38F9@gmail.com> X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Pce] IPR poll on draft-ietf-pce-association-diversity X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 11:38:58 -0000 >> I am not aware of any IPR applicable to this draft that should be=20 >> disclosed in accordance with IETF IPR rules. =E2=80=94Colby > On Apr 25, 2019, at 7:34 AM, Siva Sivabalan (msiva) = wrote: >=20 > I am aware of IPR applicable to this draft, and it has already been = disclosed to the IETF. >=20 > Thanks, > Siva >=20 >=20 > On Wed, Apr 10, 2019 at 8:27 AM Hariharan Ananthakrishnan = wrote: >>=20 >> Hi authors, >>=20 >> In preparation for Working Group last call on this draft, I'd like = all=20 >> authors and contributors to confirm on the list that they are in=20 >> compliance with IETF IPR rules. >>=20 >> Please respond (copying the mailing list) to say one of: >>=20 >> I am not aware of any IPR applicable to this draft that should be=20 >> disclosed in accordance with IETF IPR rules. >>=20 >> I am aware of IPR applicable to this draft, and it has already been=20= >> disclosed to the IETF. >>=20 >> I am aware of IPR applicable to this draft, but that has not yet been=20= >> disclosed to the IETF. I will work to ensure that it will be = disclosed=20 >> in a timely manner. >>=20 >> Thanks, >> - Hari >>=20 >> _______________________________________________ >> 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 From nobody Sun Apr 28 16:31:30 2019 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6493A1201B3; Sun, 28 Apr 2019 16:31:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rifaat Shekh-Yusef via Datatracker To: Cc: draft-ietf-pce-applicability-actn.all@ietf.org, pce@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Rifaat Shekh-Yusef Message-ID: <155649428231.20950.16409989782111070284@ietfa.amsl.com> Date: Sun, 28 Apr 2019 16:31:22 -0700 Archived-At: Subject: [Pce] Secdir last call review of draft-ietf-pce-applicability-actn-11 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2019 23:31:23 -0000 Reviewer: Rifaat Shekh-Yusef Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. RFC8453 is an informational document that defines a Framework for Abstraction and Control of TE Networks (ACTN), with a well defined security considerations section. This is an informational document that examines the applicability of Path Computation Element (PCE) to the ACTN, by adding PCE to the PNC and MDSC controllers. The security considerations section seems to be aligned with the security of the ACTN framework, and the addition of PCE to the existing controllers does not introduce new security concerns beyond what is already covered by the framework. Regards, Rifaat From nobody Mon Apr 29 10:38:37 2019 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 F33CB120436; Mon, 29 Apr 2019 10:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.337 X-Spam-Level: X-Spam-Status: No, score=-1.337 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VF1gs-lSeie1; Mon, 29 Apr 2019 10:38:33 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BBB3120025; Mon, 29 Apr 2019 10:38:33 -0700 (PDT) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x3THYTfH029711; Mon, 29 Apr 2019 10:38:32 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=2XqDNiu5FYlwfJsx3gXmDIc3fsZhnt1vkM4X/12jnZA=; b=rZ22RLZX1wI2djYWRnJMAEgywt48js4QON3OyuZ2SpS6KfGmxW1hQsDgxkx20dkJDJyV gZdx6844EmjMBnF7fBepyCaeXU7JnfzCKjVM3OVouP7lzIl5pX/9veGt7TqpbTDDMKgg KfVODQwV0aNEIbJ/0OReFGrb4kx9ywoAyfvNdepgadPTal3o3dyKG9cFRxj+x5KZGZob nvKH2tuZpeP+WFqydxZ2g6Vwc8bhNBpS/IYgZvNg57MxWHNKgOx0z7J+78N6UciMwTQn puxAEexElZvsvs8FUw6DpJyIukHmBI+T84XTokSzAGuRZn9Jx7C1/6un3jv2UeWSWHvp ZA== Received: from nam01-by2-obe.outbound.protection.outlook.com (mail-by2nam01lp2057.outbound.protection.outlook.com [104.47.34.57]) by mx0a-00273201.pphosted.com with ESMTP id 2s62syga6e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 29 Apr 2019 10:38:32 -0700 Received: from SN6PR05MB5213.namprd05.prod.outlook.com (20.177.252.83) by SN6PR05MB3968.namprd05.prod.outlook.com (52.132.125.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.9; Mon, 29 Apr 2019 17:38:30 +0000 Received: from SN6PR05MB5213.namprd05.prod.outlook.com ([fe80::ddb1:4301:7dea:eb77]) by SN6PR05MB5213.namprd05.prod.outlook.com ([fe80::ddb1:4301:7dea:eb77%7]) with mapi id 15.20.1856.008; Mon, 29 Apr 2019 17:38:30 +0000 From: Raveendra Torvi To: Hariharan Ananthakrishnan , "draft-ietf-pce-stateful-path-protection@ietf.org" CC: "pce@ietf.org" Thread-Topic: IPR poll on draft-ietf-pce-stateful-path-protection Thread-Index: AQHU70knor+f03Uov0yE0lZBGxbZnaZTQxOA Date: Mon, 29 Apr 2019 17:38:29 +0000 Message-ID: <2D457AD9-888A-4648-ABE6-ACEFC43ED797@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.18.0.190414 x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9d0ca01e-4726-4d77-6752-08d6ccc97e6d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:SN6PR05MB3968; x-ms-traffictypediagnostic: SN6PR05MB3968: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0022134A87 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(366004)(376002)(136003)(39860400002)(199004)(189003)(478600001)(25786009)(6436002)(6486002)(26005)(76176011)(99286004)(14454004)(186003)(6506007)(33656002)(6246003)(53936002)(68736007)(102836004)(11346002)(53546011)(6512007)(446003)(486006)(476003)(54896002)(6306002)(229853002)(2616005)(5660300002)(2501003)(4326008)(81156014)(2906002)(36756003)(81166006)(8936002)(82746002)(8676002)(7736002)(97736004)(86362001)(6116002)(3846002)(66446008)(73956011)(316002)(256004)(14444005)(83716004)(71190400001)(66476007)(110136005)(66066001)(76116006)(91956017)(66946007)(66556008)(64756008)(58126008)(71200400001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR05MB3968; H:SN6PR05MB5213.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: a5UkvMyOli9MKvICpRwbsb5BY44wyfrMUSsIVIdeuDUxx3BMjyaT3kp5HIkOUWLUg09IRnIk95RmXtDKFrCUztxjKGsAC3KnUqraZjfZPW6YX01cnuFSMi2Iz6lZULqzXdtYIwA7UV5VJxwe4H+9YUUKIV1K53KOfTQ3aEWsIw0r9zQauoHE4qZSJmeTx3f24+hvsnPFwM0aJJ46Y1/KNqM4RmPhqUbrdl9uu2QgSGW4CROXbSqLr/gBXSBTLuNMoDrEHk6LY5WTE8XJwT+4VMxIniNyJrzGyuRvQrSn0kVtx/hCd6IqvWr5IlJyTCjg0YhpOsAEhPMMAr+AupCXeC+aifJuAB/uAHN2yWopnwe7erpehfWPpilm8afHo5RA8Gi/0CNO/aB98cfLb5ydE5eeIuQjBvyhISBXysM2uu8= Content-Type: multipart/alternative; boundary="_000_2D457AD9888A4648ABE6ACEFC43ED797junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 9d0ca01e-4726-4d77-6752-08d6ccc97e6d X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2019 17:38:29.9406 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR05MB3968 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-29_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904290120 Archived-At: Subject: Re: [Pce] IPR poll on draft-ietf-pce-stateful-path-protection X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 17:38:35 -0000 --_000_2D457AD9888A4648ABE6ACEFC43ED797junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiBhcHBsaWNhYmxlIHRvIHRoaXMgZHJhZnQgdGhhdCBz aG91bGQgYmUgZGlzY2xvc2VkDQppbiBhY2NvcmRhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMuDQoN ClJlZ2FyZHMsDQpSYXZpDQoNCkZyb206IEhhcmloYXJhbiBBbmFudGhha3Jpc2huYW4gPGhhcmlA bmV0ZmxpeC5jb20+DQpEYXRlOiBUdWVzZGF5LCBBcHJpbCA5LCAyMDE5IGF0IDEwOjU3IFBNDQpU bzogImRyYWZ0LWlldGYtcGNlLXN0YXRlZnVsLXBhdGgtcHJvdGVjdGlvbkBpZXRmLm9yZyIgPGRy YWZ0LWlldGYtcGNlLXN0YXRlZnVsLXBhdGgtcHJvdGVjdGlvbkBpZXRmLm9yZz4NCkNjOiAicGNl QGlldGYub3JnIiA8cGNlQGlldGYub3JnPg0KU3ViamVjdDogSVBSIHBvbGwgb24gZHJhZnQtaWV0 Zi1wY2Utc3RhdGVmdWwtcGF0aC1wcm90ZWN0aW9uDQpSZXNlbnQtRnJvbTogPGFsaWFzLWJvdW5j ZXNAaWV0Zi5vcmc+DQpSZXNlbnQtVG86IDxoYXJpQG5ldGZsaXguY29tPiwgPG1zaXZhQGNpc2Nv LmNvbT4sIDxydG9ydmlAanVuaXBlci5uZXQ+LCA8aW5hbWluZWlAZ29vZ2xlLmNvbT4sIDxlZHdh cmQuY3JhYmJlQGdtYWlsLmNvbT4sIDxtYWhlbmRyYXNpbmdoQGh1YXdlaS5jb20+DQpSZXNlbnQt RGF0ZTogVHVlc2RheSwgQXByaWwgOSwgMjAxOSBhdCAxMDo1NyBQTQ0KDQoNCkhpIGF1dGhvcnMs DQoNCg0KDQpJbiBwcmVwYXJhdGlvbiBmb3IgV29ya2luZyBHcm91cCBsYXN0IGNhbGwgb24gdGhp cyBkcmFmdCwgSSdkIGxpa2UgYWxsDQoNCmF1dGhvcnMgYW5kIGNvbnRyaWJ1dG9ycyB0byBjb25m aXJtIG9uIHRoZSBsaXN0IHRoYXQgdGhleSBhcmUgaW4gY29tcGxpYW5jZQ0KDQp3aXRoIElFVEYg SVBSIHJ1bGVzLg0KDQoNCg0KUGxlYXNlIHJlc3BvbmQgKGNvcHlpbmcgdGhlIG1haWxpbmcgbGlz dCkgdG8gc2F5IG9uZSBvZjoNCg0KDQoNCkkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFIgYXBwbGlj YWJsZSB0byB0aGlzIGRyYWZ0IHRoYXQgc2hvdWxkIGJlIGRpc2Nsb3NlZA0KDQppbiBhY2NvcmRh bmNlIHdpdGggSUVURiBJUFIgcnVsZXMuDQoNCg0KDQpJIGFtIGF3YXJlIG9mIElQUiBhcHBsaWNh YmxlIHRvIHRoaXMgZHJhZnQsIGFuZCBpdCBoYXMgYWxyZWFkeSBiZWVuDQoNCmRpc2Nsb3NlZCB0 byB0aGUgSUVURi4NCg0KDQoNCkkgYW0gYXdhcmUgb2YgSVBSIGFwcGxpY2FibGUgdG8gdGhpcyBk cmFmdCwgYnV0IHRoYXQgaGFzIG5vdCB5ZXQgYmVlbg0KDQpkaXNjbG9zZWQgdG8gdGhlIElFVEYu IEkgd2lsbCB3b3JrIHRvIGVuc3VyZSB0aGF0IGl0IHdpbGwgYmUgZGlzY2xvc2VkIGluIGENCg0K dGltZWx5IG1hbm5lci4NCg0KDQoNClRoYW5rcywNCg0KLSBIYXJpDQo= --_000_2D457AD9888A4648ABE6ACEFC43ED797junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <80F9709B23B8834DACBC8CE715C80112@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7 DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIFwoQm9keSBDU1wpIjsNCglwYW5vc2UtMToyIDIgNiAzIDUg NCA1IDIgMyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3Nl LTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5I VE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFBy ZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjAN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IlZlcmRhbmEi LHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQt c3R5bGU6bm9ybWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMjEyNTI5Ij5JIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIGFwcGxpY2FibGUgdG8gdGhp cyBkcmFmdCB0aGF0IHNob3VsZCBiZSBkaXNjbG9zZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIxMjUyOSI+aW4gYWNj b3JkYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMjEyNTI5 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlJlZ2FyZHMsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+UmF2 aTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOmJsYWNrIj5IYXJpaGFyYW4gQW5hbnRoYWtyaXNobmFuICZsdDtoYXJpQG5ldGZsaXgu Y29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCBBcHJpbCA5LCAyMDE5IGF0IDEwOjU3 IFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtkcmFmdC1pZXRmLXBjZS1zdGF0ZWZ1bC1wYXRoLXBy b3RlY3Rpb25AaWV0Zi5vcmcmcXVvdDsgJmx0O2RyYWZ0LWlldGYtcGNlLXN0YXRlZnVsLXBhdGgt cHJvdGVjdGlvbkBpZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O3BjZUBpZXRmLm9y ZyZxdW90OyAmbHQ7cGNlQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5JUFIgcG9s bCBvbiBkcmFmdC1pZXRmLXBjZS1zdGF0ZWZ1bC1wYXRoLXByb3RlY3Rpb248YnI+DQo8Yj5SZXNl bnQtRnJvbTogPC9iPiZsdDthbGlhcy1ib3VuY2VzQGlldGYub3JnJmd0Ozxicj4NCjxiPlJlc2Vu dC1UbzogPC9iPiZsdDtoYXJpQG5ldGZsaXguY29tJmd0OywgJmx0O21zaXZhQGNpc2NvLmNvbSZn dDssICZsdDtydG9ydmlAanVuaXBlci5uZXQmZ3Q7LCAmbHQ7aW5hbWluZWlAZ29vZ2xlLmNvbSZn dDssICZsdDtlZHdhcmQuY3JhYmJlQGdtYWlsLmNvbSZndDssICZsdDttYWhlbmRyYXNpbmdoQGh1 YXdlaS5jb20mZ3Q7PGJyPg0KPGI+UmVzZW50LURhdGU6IDwvYj5UdWVzZGF5LCBBcHJpbCA5LCAy MDE5IGF0IDEwOjU3IFBNPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHByZSBzdHlsZT0iYm94LXNpemluZzpib3JkZXItYm94O21hcmdpbi1ib3R0b206MXJl bTt3aGl0ZS1zcGFjZTpwcmUtd3JhcDtvdmVyZmxvdzphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMTI1MjkiPkhpIGF1 dGhvcnMsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIxMjUyOSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIxMjUyOSI+SW4gcHJlcGFyYXRp b24gZm9yIFdvcmtpbmcgR3JvdXAgbGFzdCBjYWxsIG9uIHRoaXMgZHJhZnQsIEknZCBsaWtlIGFs bDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMTI1MjkiPmF1dGhvcnMgYW5k IGNvbnRyaWJ1dG9ycyB0byBjb25maXJtIG9uIHRoZSBsaXN0IHRoYXQgdGhleSBhcmUgaW4gY29t cGxpYW5jZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMTI1MjkiPndpdGgg SUVURiBJUFIgcnVsZXMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIxMjUy OSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIxMjUyOSI+UGxl YXNlIHJlc3BvbmQgKGNvcHlpbmcgdGhlIG1haWxpbmcgbGlzdCkgdG8gc2F5IG9uZSBvZjo8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjEyNTI5Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRh bmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjEyNTI5Ij5JIGFtIG5vdCBhd2FyZSBvZiBhbnkg SVBSIGFwcGxpY2FibGUgdG8gdGhpcyBkcmFmdCB0aGF0IHNob3VsZCBiZSBkaXNjbG9zZWQ8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjEyNTI5Ij5pbiBhY2NvcmRhbmNlIHdp dGggSUVURiBJUFIgcnVsZXMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIx MjUyOSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIxMjUyOSI+ SSBhbSBhd2FyZSBvZiBJUFIgYXBwbGljYWJsZSB0byB0aGlzIGRyYWZ0LCBhbmQgaXQgaGFzIGFs cmVhZHkgYmVlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMTI1MjkiPmRp c2Nsb3NlZCB0byB0aGUgSUVURi48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MjEyNTI5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjEyNTI5 Ij5JIGFtIGF3YXJlIG9mIElQUiBhcHBsaWNhYmxlIHRvIHRoaXMgZHJhZnQsIGJ1dCB0aGF0IGhh cyBub3QgeWV0IGJlZW48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjEyNTI5 Ij5kaXNjbG9zZWQgdG8gdGhlIElFVEYuIEkgd2lsbCB3b3JrIHRvIGVuc3VyZSB0aGF0IGl0IHdp bGwgYmUgZGlzY2xvc2VkIGluIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MjEyNTI5Ij50aW1lbHkgbWFubmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMyMTI1MjkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMTI1 MjkiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjEyNTI5Ij4t IEhhcmk8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMyMTI1MjkiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_2D457AD9888A4648ABE6ACEFC43ED797junipernet_-- From nobody Tue Apr 30 11:41:53 2019 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 032B5120300; Tue, 30 Apr 2019 11:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.237 X-Spam-Level: X-Spam-Status: No, score=-1.237 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DHDqVUExkDq; Tue, 30 Apr 2019 11:41:43 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09EF41200F4; Tue, 30 Apr 2019 11:41:43 -0700 (PDT) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x3UISead027784; Tue, 30 Apr 2019 14:41:39 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049295.ppops.net-00191d01. with ESMTP id 2s6u169qk1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Apr 2019 14:41:38 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x3UIfa6L021564; Tue, 30 Apr 2019 14:41:37 -0400 Received: from zlp27128.vci.att.com (zlp27128.vci.att.com [135.66.87.50]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x3UIfUUB021411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 30 Apr 2019 14:41:30 -0400 Received: from zlp27128.vci.att.com (zlp27128.vci.att.com [127.0.0.1]) by zlp27128.vci.att.com (Service) with ESMTP id 9295D4039343; Tue, 30 Apr 2019 18:41:30 +0000 (GMT) Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (unknown [130.9.129.152]) by zlp27128.vci.att.com (Service) with ESMTPS id 794324039341; Tue, 30 Apr 2019 18:41:30 +0000 (GMT) Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.184]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0439.000; Tue, 30 Apr 2019 14:41:30 -0400 From: "BRUNGARD, DEBORAH A" To: Dhruv Dhody , Mirja Kuehlewind , Dhruv Dhody CC: "draft-ietf-pce-stateful-pce-p2mp@ietf.org" , "pce@ietf.org" , The IESG , "pce-chairs@ietf.org" Thread-Topic: =?utf-8?B?W1BjZV0gIE1pcmphIEvDvGhsZXdpbmQncyBObyBPYmplY3Rpb24gb24gZHJh?= =?utf-8?B?ZnQtaWV0Zi1wY2Utc3RhdGVmdWwtcGNlLXAybXAtMTI6ICh3aXRoIENPTU1F?= =?utf-8?Q?NT)?= Thread-Index: AQHU6xFo8QESWuIeUEeLEg4h3/NEP6Y3LRaAgAAjiwCAHeEQcA== Date: Tue, 30 Apr 2019 18:41:29 +0000 Message-ID: References: <155439625812.30874.11556397385069015051.idtracker@ietfa.amsl.com> <23CE718903A838468A8B325B80962F9B8DA11248@BLREML503-MBS.china.huawei.com> In-Reply-To: <23CE718903A838468A8B325B80962F9B8DA11248@BLREML503-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.197.34] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-30_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904300110 Archived-At: Subject: Re: [Pce] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-pce-stateful-pce-p2mp-12=3A_=28with_COMMENT=29?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 18:41:45 -0000 SGksDQoNClRoYW5rcyBEaHJ1diBmb3IgdGhlIGNsYXJpZmljYXRpb24uIEFzIHRoZSB3b3JraW5n IGdyb3VwIHN1cHBvcnRzIHRoaXMgYXBwcm9hY2gsIEkgc3VwcG9ydCBhbHNvLg0KDQpJbiB0aGUg ZnV0dXJlLCB3ZSBjYW4gY29uc2lkZXIgTWlyamEncyBzdWdnZXN0aW9uIGlmIHdlIHNlZSB0aGlz IGJlY29taW5nIG1vcmUgcG9wdWxhci4NCg0KVGhhbmtzIGV2ZXJ5b25lLQ0KRGVib3JhaA0KDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpZXNnIDxpZXNnLWJvdW5jZXNAaWV0 Zi5vcmc+IE9uIEJlaGFsZiBPZiBEaHJ1diBEaG9keQ0KU2VudDogVGh1cnNkYXksIEFwcmlsIDEx LCAyMDE5IDEwOjIyIEFNDQpUbzogTWlyamEgS3VlaGxld2luZCA8aWV0ZkBrdWVobGV3aW5kLm5l dD47IERocnV2IERob2R5IDxkaHJ1di5pZXRmQGdtYWlsLmNvbT4NCkNjOiBkcmFmdC1pZXRmLXBj ZS1zdGF0ZWZ1bC1wY2UtcDJtcEBpZXRmLm9yZzsgcGNlQGlldGYub3JnOyBUaGUgSUVTRyA8aWVz Z0BpZXRmLm9yZz47IHBjZS1jaGFpcnNAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbUGNlXSBNaXJq YSBLw7xobGV3aW5kJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtcGNlLXN0YXRlZnVsLXBj ZS1wMm1wLTEyOiAod2l0aCBDT01NRU5UKQ0KDQpIaSBNaXJqYSwgDQoNClRoZSBmcmFnbWVudGF0 aW9uIGlzIGZvciB0aGUgUENFUCBtZXNzYWdlIGFuZCBub3QgZWFjaCBvYmplY3QuIFJGQzYwMDYg KGFuZCBSRkM4MzA2KSBpbXBsZW1lbnRlZCB0aGlzIHdpdGggYSBmbGFnIGluIHRoZSBSUCBvYmpl Y3QgKHdoaWNoIGlzIGEgTVVTVCBvYmplY3QgaW4gdHdvIG1lc3NhZ2VzIHRoYXQgYXJlIHN1c2Nl cHRpYmxlIHRvIGZyYWdtZW50YXRpb24pLiBJbiB0aGlzIGRvY3VtZW50IHdlIGFkZCBmbGFnIGlu IHRoZSBMU1Agb2JqZWN0ICh3aGljaCBpcyBhIE1VU1Qgb2JqZWN0IGluIGFsbCB0aGUgMyBtZXNz YWdlcyB0aGF0IGFyZSBzdXNjZXB0aWJsZSB0byBmcmFnbWVudGF0aW9uKS4gIA0KDQpTbywgUENF UCBoYXMgMTMgbWVzc2FnZXMsIG9mIHdoaWNoIDUgYXJlIHN1c2NlcHRpYmxlIHRvIGZyYWdtZW50 YXRpb24sIGFuZCB0aGlzIGlzIGhhbmRsZWQgYnkgZmxhZyBpbiAyIG9iamVjdHMuIEV2ZW4gaWYg d2UgY2FtZSB1cCB3aXRoIG5ldyBtZXNzYWdlcyAoYW5kIHRoZXJlIGFyZSBub25lIHByb3Bvc2Vk IGFzIG9mIG5vdyksIEkgZG9u4oCZdCBzZWUgdXMgYWRkaW5nIHRoaXMgZmxhZyBpbiBtb3JlIG9i amVjdHMgYW55dGltZSBpbiB0aGUgbmVhciBmdXR1cmUuDQoNCkkgd2lsbCB3YWl0IGZvciBzaGVw aGVyZC9BRCBndWlkYW5jZSBvbiB0aGlzLiANCg0KVGhhbmtzISANCkRocnV2DQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUGNlIFttYWlsdG86cGNlLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBNaXJqYSBLdWVobGV3aW5kDQo+IFNlbnQ6IDExIEFwcmlsIDIw MTkgMTc6NDQNCj4gVG86IERocnV2IERob2R5IDxkaHJ1di5pZXRmQGdtYWlsLmNvbT4NCj4gQ2M6 IGRyYWZ0LWlldGYtcGNlLXN0YXRlZnVsLXBjZS1wMm1wQGlldGYub3JnOyBwY2VAaWV0Zi5vcmc7 IFRoZSBJRVNHIA0KPiA8aWVzZ0BpZXRmLm9yZz47IHBjZS1jaGFpcnNAaWV0Zi5vcmcNCj4gU3Vi amVjdDogUmU6IFtQY2VdIE1pcmphIEvDvGhsZXdpbmQncyBObyBPYmplY3Rpb24gb24gZHJhZnQt aWV0Zi1wY2UtDQo+IHN0YXRlZnVsLXBjZS1wMm1wLTEyOiAod2l0aCBDT01NRU5UKQ0KPiANCj4g SGkgRGhydXYsDQo+IA0KPiBTb3JyeSBmb3IgbXkgbGF0ZSByZXBseS4gU28geW91ciByZXBseSBh Y3R1YWxseSBjb25jZXJucyBtZSBhIGJpdC4NCj4gSW5pdGlhbGx5IHlvdSBzYWlkIHlvdSd2ZSBw dXQgaXQgaW4gb2JqZWN0IGJlY2F1c2UgdGhlcmUgd2FzIG5vIA0KPiBleHBlY3RhdGlvbiB0aGF0 IGlzIG1heSBiZSBuZWVkZWQgYnkgb3RoZXIgb2JqZWN0cy4gTm93IHlvdSBoYXZlIGEgDQo+IHNl Y29uZCBvYmplY3QgYW5kIHlvdSBkZWZpbmVkIGl0IGFnYWluIG9iamVjdC1zcGVjaWZpY2FsbHkg YmVjYXVzZSB5b3UgDQo+IHNheSBpdOKAmXMgdG9vIG11Y2ggb3ZlcmhlYWQgdG8gZGVmaW5lIGEg Z2VuZXJpYyBtZWNoYW5pc21zIGZvciBqdXN0IG9uZSANCj4gbW9yZS4gV2lsbCB5b3Ugc2F5IHRo ZSBzYW1lIHRoaW5nIGFnYWluIHdpdGggdGhlIG5leHQgb2JqZWN0IHRoYXQgDQo+IG5lZWRzIGZy YWdtZW50YXRpb24/IE1heWJlIGl04oCZcyB0aGUgcmlnaHQgdGltZSBub3cgdG8gYWRkIHRoaXMg bW9yZSANCj4gZ2VuZXJpY2FsbHkgdG8gY29tbW9uIGhlYWRlci4gSSBtZWFuIGl0IHNob3VsZCBi ZSBhIHZlcnkgc2hvcnQsIA0KPiBzdHJhaWdodC1mb3J3YXJkIGRyYWZ0LiBXaGF04oCZcyB0aGUg YXJndW1lbnQgZm9yIG5vdCBqdXN0IGRvaW5nIGl0IG5vdz8NCj4gDQo+IG1pcmphDQo+IA0KPiAN Cj4gDQo+ID4gT24gNC4gQXByIDIwMTksIGF0IDIwOjA3LCBEaHJ1diBEaG9keSA8ZGhydXYuaWV0 ZkBnbWFpbC5jb20+IHdyb3RlOg0KPiA+DQo+ID4gSGkgTWlyamEsDQo+ID4NCj4gPiBPbiBUaHUs IEFwciA0LCAyMDE5IGF0IDEwOjE0IFBNIE1pcmphIEvDvGhsZXdpbmQgdmlhIERhdGF0cmFja2Vy IA0KPiA+IDxub3JlcGx5QGlldGYub3JnPiB3cm90ZToNCj4gPj4NCj4gPj4gTWlyamEgS8O8aGxl d2luZCBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gPj4g ZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwtcGNlLXAybXAtMTI6IE5vIE9iamVjdGlvbg0KPiA+Pg0K PiA+PiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0 IGFuZCByZXBseSB0byANCj4gPj4gYWxsIGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUg VG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIA0KPiA+PiBjdXQgdGhpcyBpbnRyb2R1Y3Rv cnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4gPj4NCj4gPj4NCj4gPj4gUGxlYXNlIHJlZmVyIHRv DQo+ID4+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z QV9fd3d3LmlldGYub3JnX2kNCj4gPj4gZXNnX3N0YXRlbWVudF9kaXNjdXNzLTJEY3JpdGVyaWEu aHRtbCZkPUR3SUdhUSZjPUxGWVotbzlfSFVNZU1UU1FpYw0KPiA+PiB2aklnJnI9LXVmTHFPbnR0 NkxlakxNVGJOM1FwallIeHNPYnhtUEtSaGlGM0ZubW9JMCZtPWhOR0R3SzNmYVlPcmZwDQo+ID4+ IHFjc1IxTW9JQ0hiSE9iMGE5SWlwUGZrVXMtRG93JnM9QmppQ2JHQms3cXRrMlNxNEdOYmU0R25h RWh4dEpvOXNIVWYNCj4gPj4gaGp6a2tUZ1EmZT0gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQg SUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIA0KPiA+PiBwb3NpdGlvbnMuDQo+ID4+DQo+ID4+DQo+ ID4+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4g YmUgZm91bmQgaGVyZToNCj4gPj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5pZQ0KPiA+PiB0Zi5vcmdfZG9jX2RyYWZ0LTJE aWV0Zi0yRHBjZS0yRHN0YXRlZnVsLTJEcGNlLTJEcDJtcF8mZD1Ed0lHYVEmYz1MDQo+ID4+IEZZ Wi1vOV9IVU1lTVRTUWljdmpJZyZyPS11ZkxxT250dDZMZWpMTVRiTjNRcGpZSHhzT2J4bVBLUmhp RjNGbm1vSTANCj4gPj4gJm09aE5HRHdLM2ZhWU9yZnBxY3NSMU1vSUNIYkhPYjBhOUlpcFBma1Vz LURvdyZzPU9rWE1uUWFSTkxqZE9jc0lqYQ0KPiA+PiB1ZTN5RVk3NG1hczJjQ18zUVNGLVBKcDJN JmU9DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4gLS0NCj4gPj4gLQ0K PiA+PiBDT01NRU5UOg0KPiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+IC0tDQo+ID4+IC0NCj4gPj4NCj4g Pj4gSnVzdCBhIHF1aWNrIGNsYXJpZmljYXRpb24gcXVlc3Rpb24gb24gZnJhZ21lbnRhdGlvbjog SSdtIHdvbmRlcmluZyANCj4gPj4gaWYgaXQgaXMgcmVhbGx5IG5lY2Vzc2FyeSB0byBkZWZpbmUg YSBmcmFnbWVudGF0aW9uIG1lY2hhbmlzbS9iaXQgDQo+ID4+IGZvciBlYWNoIG9iamVjdCBzZXBh cmF0ZWx5IChlLmcgYWxzbyBSRkM4MzA2KSBvciBpZiBpdCB3b3VsZCBiZSANCj4gPj4gbW9yZSBh cHByb3ByaWF0ZSB0byBhbGxvY2F0ZSBvbmUgYml0IGluIHRoZSBjb21tb24gaGVhZGVyPyBKdXN0 IA0KPiA+PiBhc2tpbmcgYXMNCj4gSSdtIHJlYWxseSBub3QgYW4gZXhwZXJ0IGhlcmUuLi4NCj4g Pj4NCj4gPj4NCj4gPg0KPiA+IFRoZSBuZWVkIGZvciBmcmFnbWVudGF0aW9uIHdhcyBmb3VuZCB3 aGVuIHRoZSBzdXBwb3J0IGZvciBQMk1QIFRFIA0KPiA+IHdhcyBpbnRyb2R1Y2VkIGluIFJGQzYw MDYuIEF0IHRoYXQgdGltZSBvbmx5IHR3byBQQ0VQIG1lc3NhZ2Ugd2VyZSANCj4gPiBzdXNjZXB0 aWJsZSB0byBmcmFnbWVudGF0aW9uIChQQ1JlcSAmIFBDUmVwKSBhbmQgdGhlIGNob2ljZSB3YXMg bWFkZSANCj4gPiB0byBhZGQgYSBmbGFnIGluIGEgUlAgb2JqZWN0LiBUaGUgY2hvaWNlIG1hZGUg YXQgdGhhdCB0aW1lIHdhcyB0aGF0IA0KPiA+IHRoZSBvdGhlciBtZXNzYWdlcyBzaG91bGQgbm90 IGJlIGZyYWdtZW50ZWQuDQo+ID4NCj4gPiBMYXRlciBQQ0VQIGFkZGVkIG1vcmUgbWVzc2FnZXMg dG8gc3VwcG9ydCBzdGF0ZWZ1bCBvcGVyYXRpb24uIEFuZCANCj4gPiB3aXRoIHRoaXMgSS1EIHdl IGV4dGVuZCBzdXBwb3J0IHRvIFAyTVAgTFNQIHdoZXJlIGZyYWdtZW50YXRpb24gDQo+ID4gaGFu ZGxpbmcgd2FzIHJlcXVpcmVkICh3ZSBhZGRlZCB0aGUgZmxhZyBpbiB0aGUgTFNQIG9iamVjdCku DQo+ID4NCj4gPiBZb3UgYXJlIGNvcnJlY3QhIFdlIGNvdWxkIGhhdmUgdXNlZCB0aGUgUENFUCBj b21tb24gbWVzc2FnZSBoZWFkZXIgDQo+ID4gYW5kIHNhaWQgdGhhdCB0aGUgZmxhZyBpcyBhcHBs aWNhYmxlIGZvciB0aGUgc3Vic2V0IG9mIG1lc3NhZ2VzLiBCdXQgDQo+ID4gdGhlIGRlc2lnbiBj aG9pY2UgaGVyZSB3YXMgdG8ga2VlcCBjb25zaXN0ZW50IHdpdGggdGVjaG5pcXVlIGFscmVhZHkg DQo+ID4gaW4gcGxhY2UuIEZyYWdtZW50YXRpb24gZmxhZyBpbiAyIG9iamVjdHMgaXNuJ3QgYWxs IHRoYXQgYmFkLg0KPiA+DQo+ID4gVGhhbmtzIGZvciB5b3VyIHJldmlldyENCj4gPiBEaHJ1dg0K PiA+DQo+ID4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IFBjZSBtYWlsaW5nIGxpc3QNCj4gUGNlQGlldGYub3JnDQo+IGh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21h aWwNCj4gbWFuX2xpc3RpbmZvX3BjZSZkPUR3SUdhUSZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcm cj0tdWZMcU9udHQ2TGVqTE1UYg0KPiBOM1FwallIeHNPYnhtUEtSaGlGM0ZubW9JMCZtPWhOR0R3 SzNmYVlPcmZwcWNzUjFNb0lDSGJIT2IwYTlJaXBQZmtVcy1EDQo+IG93JnM9TEk1dENqeGtGR2I4 aE9ObFIxMzdkaWJJOE13QWZTWVd1eGREaFBQWjlHcyZlPQ0K From nobody Tue Apr 30 12:04:22 2019 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2FF120331; Tue, 30 Apr 2019 12:04:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , db3546@att.com, draft-ietf-pce-stateful-pce-p2mp@ietf.org, Adrian Farrel , pce@ietf.org, pce-chairs@ietf.org, adrian@olddog.co.uk, rfc-editor@rfc-editor.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <155665105463.7536.13017681873594707505.idtracker@ietfa.amsl.com> Date: Tue, 30 Apr 2019 12:04:14 -0700 Archived-At: Subject: [Pce] Protocol Action: 'Path Computation Element (PCE) Protocol Extensions for Stateful PCE usage for Point-to-Multipoint Traffic Engineering Label Switched Paths' to Proposed Standard (draft-ietf-pce-stateful-pce-p2mp-13.txt) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 19:04:15 -0000 The IESG has approved the following document: - 'Path Computation Element (PCE) Protocol Extensions for Stateful PCE usage for Point-to-Multipoint Traffic Engineering Label Switched Paths' (draft-ietf-pce-stateful-pce-p2mp-13.txt) as Proposed Standard This document is the product of the Path Computation Element Working Group. The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-p2mp/ Technical Summary The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE Label Switched Paths (LSPs). This document provides extensions required for Path Computation Element Communication Protocol (PCEP) so as to enable the usage of a stateful PCE capability in supporting P2MP TE LSPs. Working Group Summary The working group process has been uneventful. The author team comes from vendors and operators who ship and deploy P2MP RSVP-TE and so have a very strong interest in these PCE extensions. Document Quality This document received only moderate review during its time in the working group. P2MP function is somewhat fringe, and so only a small group of people worked on it. As a result, WG last call was quiet. The document shepherd (Adrian Farrel) and the out-going chair (Jon Hardwick) made detailed reviews that led to a number of minor changes. Implementation status is not known, but it is believed that two vendors have roadmap plans. Personnel Who is the Document Shepherd for this document? Adrian Farrel Who is the Responsible Area Director? Deborah Brungard IANA Note IANA Early code point allocation was made for the code points needed by this work.