From julien.meuric@orange.com Mon Dec 2 05:47:50 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E201AE47D for ; Mon, 2 Dec 2013 05:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.885 X-Spam-Level: X-Spam-Status: No, score=-0.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXSv3xC643cl for ; Mon, 2 Dec 2013 05:47:49 -0800 (PST) Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id CEF721AE476 for ; Mon, 2 Dec 2013 05:47:48 -0800 (PST) Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A8564E30115 for ; Mon, 2 Dec 2013 14:51:10 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.orange.com (Postfix) with ESMTP id A36FEE3010F for ; Mon, 2 Dec 2013 14:51:10 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Dec 2013 14:47:45 +0100 Received: from [10.193.71.94] ([10.193.71.94]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Dec 2013 14:47:45 +0100 Message-ID: <529C8F80.7060207@orange.com> Date: Mon, 02 Dec 2013 14:47:44 +0100 From: Julien Meuric Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "pce@ietf.org" References: <528237BE.5040307@orange.com> In-Reply-To: <528237BE.5040307@orange.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Dec 2013 13:47:45.0284 (UTC) FILETIME=[145F2C40:01CEEF65] Subject: Re: [Pce] Poll for Adoption of draft-crabbe-pce-pce-initiated-lsp-03 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 13:47:50 -0000 Hi. The support looks clear. Authors, you may publish the document as draft-ietf-pce-pce-initiated-lsp-00. Thanks, JP & Julien Nov. 12, 2013 - Julien Meuric: > Hi all. > > Following the opposition expressed on merging MPLS and GMPLS documents > for stateful PCE, the sense of the room was in favor of adopting the > aforementionned I-D. > Now we would like to get the feedback of the mailing list: do you > support draft-crabbe-pce-pce-initiated-lsp-03 to become a foundation for > a PCE WG document? > > As usual, reasons for your preference are welcome (not to say mandatory > in case of opposition). > > Thanks, > > JP & Julien > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > From julien.meuric@orange.com Mon Dec 2 05:49:25 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A5F1AE47F for ; Mon, 2 Dec 2013 05:49:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.885 X-Spam-Level: X-Spam-Status: No, score=-0.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbTNIpA31I-2 for ; Mon, 2 Dec 2013 05:49:24 -0800 (PST) Received: from r-mail2.rd.orange.com (r-mail2.rd.orange.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 647771AE47D for ; Mon, 2 Dec 2013 05:49:24 -0800 (PST) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0F0835D89B9 for ; Mon, 2 Dec 2013 14:49:21 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.orange.com (Postfix) with ESMTP id 0694F5D8997 for ; Mon, 2 Dec 2013 14:49:21 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Dec 2013 14:49:20 +0100 Received: from [10.193.71.94] ([10.193.71.94]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Dec 2013 14:49:20 +0100 Message-ID: <529C8FE0.3090408@orange.com> Date: Mon, 02 Dec 2013 14:49:20 +0100 From: Julien Meuric Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "pce@ietf.org" References: <5282388A.7080904@orange.com> In-Reply-To: <5282388A.7080904@orange.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Dec 2013 13:49:20.0630 (UTC) FILETIME=[4D33D160:01CEEF65] Subject: Re: [Pce] Poll for Adoption of draft-zhang-pce-pcep-stateful-pce-gmpls-03 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 13:49:25 -0000 Hi again. The support looks clear. Authors, you may publish the document as draft-ietf-pce-pcep-stateful-pce-gmpls-00. Thanks, JP & Julien Nov. 12, 2013 - Julien Meuric: > Hi again. > > Following the support expressed in the room during our meeting in > Vancouver, we would like to get the feedback of the mailing list: do you > support draft-zhang-pce-pcep-stateful-pce-gmpls-03 to become a > foundation for a PCE WG document? > > As usual, reasons for your preference are welcome (not to say mandatory > in case of opposition). > > Thanks, > > JP & Julien > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > From zhang.xian@huawei.com Mon Dec 2 17:53:43 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5741AE026 for ; Mon, 2 Dec 2013 17:53:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iU6eFzftWyiw for ; Mon, 2 Dec 2013 17:53:41 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 982DE1AE020 for ; Mon, 2 Dec 2013 17:53:40 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYO14448; Tue, 03 Dec 2013 01:53:37 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Dec 2013 01:52:48 +0000 Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Dec 2013 01:53:35 +0000 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.189]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Tue, 3 Dec 2013 09:53:24 +0800 From: "Zhangxian (Xian)" To: "pce@ietf.org" Thread-Topic: New Version Notification for draft-minei-pce-stateful-sync-optimizations-01.txt Thread-Index: AQHO78kGcCEHgGrcp0utwlS3PbDi9ZpBtK9A Date: Tue, 3 Dec 2013 01:53:23 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.104.209] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Pce] FW: New Version Notification for draft-minei-pce-stateful-sync-optimizations-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 01:53:43 -0000 RGVhciBQQ0VycywNCg0KICBUaGlzIGRyYWZ0IHByb3Bvc2VzIHRocmVlIGZ1bmN0aW9ucyB0aGF0 IGNhbiBoZWxwIHRvIG9wdGltaXplIHRoZSBMU1AgREIgU3luY2hyb25pemF0aW9uIHByb2Nlc3Mg Zm9yIHN0YXRlZnVsIFBDRXMuIEl0IG1lcmdlcyBzb21lIGNvbnRlbnQgZnJvbSBkcmFmdC1pZXRm LXBjZS1zdGF0ZWZ1bC1wY2UgYW5kIHRoZSBkcmFmdCBkcmFmdC16aHgtcGNlLXN0YXRlZnVsLWxz cC1zeW5jLTAwLiANCg0KICBUaGlzIG5ldyB2ZXJzaW9uIGhhdmUgYWRkcmVzc2VkIHRoZSBjb21t ZW50cyByZWNlaXZlZCB3aXRoIHJlZ2FyZCB0byBib3RoIHBhcnRzLiBQbGVhc2UgcmV2aWV3IHRo aXMgdmVyc2lvbiBhbmQgYW55IGNvbW1lbnRzL3N1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lLiANCg0K QmVzdCBSZWdhcmRzLA0KWGlhbiAob24gYmVoYWxmIG9mIGFsbCBhdXRob3JzKQ0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWls dG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IDIwMTPlubQxMuaciDPml6UgOTo0 Mg0KVG86IEphbiBNZWR2ZWQ7IERocnV2IERob2R5OyBJbmEgTWluZWk7IFpoYW5neGlhbiAoWGlh bik7IFJvYmVydCBWYXJnYTsgRWR3YXJkIENyYWJiZQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1taW5laS1wY2Utc3RhdGVmdWwtc3luYy1vcHRpbWl6YXRpb25z LTAxLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1taW5laS1wY2Utc3RhdGVm dWwtc3luYy1vcHRpbWl6YXRpb25zLTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p dHRlZCBieSBFZHdhcmQgQ3JhYmJlIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnku DQoNCkZpbGVuYW1lOgkgZHJhZnQtbWluZWktcGNlLXN0YXRlZnVsLXN5bmMtb3B0aW1pemF0aW9u cw0KUmV2aXNpb246CSAwMQ0KVGl0bGU6CQkgT3B0aW1pemF0aW9ucyBvZiBMYWJlbCBTd2l0Y2hl ZCBQYXRoIFN0YXRlIFN5bmNocm9uaXphdGlvbiBQcm9jZWR1cmVzIGZvciBhIFN0YXRlZnVsIFBD RQ0KQ3JlYXRpb24gZGF0ZToJIDIwMTMtMTItMDINCkdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlz c2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAxOQ0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1taW5laS1wY2Utc3RhdGVmdWwtc3luYy1vcHRp bWl6YXRpb25zLTAxLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LW1pbmVpLXBjZS1zdGF0ZWZ1bC1zeW5jLW9wdGltaXphdGlvbnMNCkh0 bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWluZWktcGNl LXN0YXRlZnVsLXN5bmMtb3B0aW1pemF0aW9ucy0wMQ0KRGlmZjogICAgICAgICAgICBodHRwOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1taW5laS1wY2Utc3RhdGVmdWwtc3luYy1v cHRpbWl6YXRpb25zLTAxDQoNCkFic3RyYWN0Og0KICAgQSBzdGF0ZWZ1bCBQYXRoIENvbXB1dGF0 aW9uIEVsZW1lbnQgKFBDRSkgaGFzIGFjY2VzcyB0byBub3Qgb25seSB0aGUNCiAgIGluZm9ybWF0 aW9uIGRpc3NlbWluYXRlZCBieSB0aGUgbmV0d29yaydzIEludGVyaW9yIEdhdGV3YXkgUHJvdG9j b2wNCiAgIChJR1ApLCBidXQgYWxzbyB0aGUgc2V0IG9mIGFjdGl2ZSBwYXRocyBhbmQgdGhlaXIg cmVzZXJ2ZWQgcmVzb3VyY2VzDQogICBmb3IgaXRzIGNvbXB1dGF0aW9uLiAgVGhlIGFkZGl0aW9u YWwgTGFiZWwgU3dpdGNoZWQgUGF0aCAoTFNQKSBzdGF0ZQ0KICAgaW5mb3JtYXRpb24gYWxsb3dz IHRoZSBQQ0UgdG8gY29tcHV0ZSBjb25zdHJhaW5lZCBwYXRocyB3aGlsZQ0KICAgY29uc2lkZXJp bmcgaW5kaXZpZHVhbCBMU1BzIGFuZCB0aGVpciBpbnRlcmFjdGlvbnMuICBUaGlzIHJlcXVpcmVz IGENCiAgIHJlbGlhYmxlIHN0YXRlIHN5bmNocm9uaXphdGlvbiBtZWNoYW5pc20gYmV0d2VlbiB0 aGUgUENFIGFuZCB0aGUNCiAgIG5ldHdvcmssIFBDRSBhbmQgcGF0aCBjb21wdXRhdGlvbiBjbGll bnRzIChQQ0NzKSwgYW5kIGJldHdlZW4NCiAgIGNvb3BlcmF0aW5nIFBDRXMuICBUaGUgYmFzaWMg bWVjaGFuaXNtIGZvciBzdGF0ZSBzeW5jaHJvbml6YXRpb24gaXMNCiAgIHBhcnQgb2YgdGhlIHN0 YXRlZnVsIFBDRSBzcGVjaWZpY2F0aW9uLiAgVGhpcyBkcmFmdCBwcmVzZW50cw0KICAgbW90aXZh dGlvbnMgZm9yIG9wdGltaXphdGlvbnMgdG8gdGhlIGJhc2Ugc3RhdGUgc3luY2hyb25pemF0aW9u DQogICBwcm9jZWR1cmUgYW5kIHNwZWNpZmllcyB0aGUgcmVxdWlyZWQgUGF0aCBDb21wdXRhdGlv biBFbGVtZW50DQogICBDb21tdW5pY2F0aW9uIFByb3RvY29sIChQQ0VQKSBleHRlbnNpb25zLg0K DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1h eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1 bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xz LmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From internet-drafts@ietf.org Tue Dec 3 23:53:27 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60D11AE081; Tue, 3 Dec 2013 23:53:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 CAnw4cqw83qC; Tue, 3 Dec 2013 23:53:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D918E1AE03C; Tue, 3 Dec 2013 23:53:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131204075324.17362.38455.idtracker@ietfa.amsl.com> Date: Tue, 03 Dec 2013 23:53:24 -0800 Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-pce-initiated-lsp-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 07:53:28 -0000 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 Working Group of= the IETF. Title : PCEP Extensions for PCE-initiated LSP Setup in a Statefu= l PCE Model Author(s) : Edward Crabbe Ina Minei Siva Sivabalan Robert Varga Filename : draft-ietf-pce-pce-initiated-lsp-00.txt Pages : 17 Date : 2013-12-02 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 extensions described in [I-D.ietf-pce-stateful-pce] provide stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSP) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the creation and deletion of PCE- initiated LSPs under the stateful PCE model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pce-initiated-lsp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Dec 4 00:06:27 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21DD01AE0A9; Wed, 4 Dec 2013 00:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 WjcNyl4O31i8; Wed, 4 Dec 2013 00:06:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8AC1AE081; Wed, 4 Dec 2013 00:06:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131204080625.16099.44157.idtracker@ietfa.amsl.com> Date: Wed, 04 Dec 2013 00:06:25 -0800 Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-pcep-stateful-pce-gmpls-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 08:06:27 -0000 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 Working Group of= the IETF. Title : Path Computation Element (PCE) Protocol Extensions for S= tateful PCE Usage in GMPLS-controlled Networks Author(s) : Xian Zhang Young Lee Fatai Zhang Ramon Casellas Oscar Gonzalez de Dios Zafar Ali Filename : draft-ietf-pce-pcep-stateful-pce-gmpls-00.txt Pages : 15 Date : 2013-12-04 Abstract: The Path Computation Element (PCE) facilitates Traffic Engineering (TE) based path calculation in large, multi-domain, multi-region, or multi-layer networks. [Stateful-PCE] provides the fundamental PCE communication Protocol (PCEP) extensions needed to support stateful PCE functions, without specifying the technology-specific extensions. This memo provides extensions required for PCEP so as to enable the usage of a stateful PCE capability in GMPLS-controlled networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-stateful-pce-gmpls There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-pcep-stateful-pce-gmpls-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bill.wu@huawei.com Thu Dec 5 22:55:16 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5D01AE2F4 for ; Thu, 5 Dec 2013 22:55:16 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M_qDlj7aOkf5 for ; Thu, 5 Dec 2013 22:55:13 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B50F11AE063 for ; Thu, 5 Dec 2013 22:55:12 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBB60631; Fri, 06 Dec 2013 06:55:07 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Dec 2013 06:54:14 +0000 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Dec 2013 06:55:05 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Fri, 6 Dec 2013 14:55:00 +0800 From: Qin Wu To: "pce@ietf.org" Thread-Topic: [Pce] [dnssd] Solicit feedback to draft-wu-pce-dns-pce-discovery-03 Thread-Index: AQHO8lAVEgNY0YZF7UKbGy7pXjS3Nw== Date: Fri, 6 Dec 2013 06:55:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43C692E3nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Pce] [dnssd] Solicit feedback to draft-wu-pce-dns-pce-discovery-03 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 06:55:16 -0000 --_000_B8F9A780D330094D99AF023C5877DABA43C692E3nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 2. For TXT record, it seems you split it into multiple records, and put eac= h key/value pair into a different record. This is not necessary. [Qin]: can multiple records be carried in one DNS message? In addition, per RFC 6763, the key should not be more than 9 character long= , and no space should be used in key, unless it's really necessary. [Qin]: RFC1464 also defines the format of key/value pair that is carried in= TXT record. Per RFC1464, "less than 9 character long" restriction is not applied to the= attribute name. The attribute name is equivalent to key described in RFC67= 63. --_000_B8F9A780D330094D99AF023C5877DABA43C692E3nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

2. For TXT record, it se= ems you split it into multiple records, and put each key/value pair into a = different record. This is not necessary.

=  

[Qin]= : can multiple records be carried in one DNS message?

=  

In addition, per RFC 676= 3, the key should not be more than 9 character long, and no space should be= used in key, unless it's really necessary.

=  

[Qin]= : RFC1464 also defines the format of key/value pair that is carried in TXT = record.

Per R= FC1464, “less than 9 character long” restriction is not applied= to the attribute name. The attribute name is equivalent to key described i= n RFC6763.

--_000_B8F9A780D330094D99AF023C5877DABA43C692E3nkgeml501mbschi_-- From wwwrun@rfc-editor.org Wed Dec 4 21:03:55 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22C21ADFA7 for ; Wed, 4 Dec 2013 21:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jf_UMdekhsKX for ; Wed, 4 Dec 2013 21:03:54 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:126c::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 814E01AE239 for ; Wed, 4 Dec 2013 21:03:54 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 9884B726002; Wed, 4 Dec 2013 21:03:13 -0800 (PST) To: qzhao@huawei.com, daniel@olddog.co.uk, fabien.verhaeghe@gmail.com, takeda.tomonori@lab.ntt.co.jp, zali@cisco.com, julien.meuric@orange-ftgroup.com, stbryant@cisco.com, adrian@olddog.co.uk, jpv@cisco.com, julien.meuric@orange.com From: RFC Errata System Message-Id: <20131205050313.9884B726002@rfc-editor.org> Date: Wed, 4 Dec 2013 21:03:13 -0800 (PST) X-Mailman-Approved-At: Fri, 06 Dec 2013 01:41:01 -0800 Cc: pce@ietf.org, rfc-editor@rfc-editor.org Subject: [Pce] [Editorial Errata Reported] RFC6006 (3819) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 05:03:56 -0000 The following errata report has been submitted for RFC6006, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6006&eid=3819 -------------------------------------- Type: Editorial Reported by: Udayasree Section: 3.13.2 Original Text ------------- Each message sent to the PCE, except the last one, will have the F-bit set in the RP object to signify that the response has been fragmented into multiple messages. Corrected Text -------------- Each message sent by the PCE, except the last one, will have the F-bit set in the RP object to signify that the response has been fragmented into multiple messages. Notes ----- This section is about response, and response messages are sent *by* the PCE. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6006 (draft-ietf-pce-pcep-p2mp-extensions-11) -------------------------------------- Title : Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths Publication Date : September 2010 Author(s) : Q. Zhao, Ed., D. King, Ed., F. Verhaeghe, T. Takeda, Z. Ali, J. Meuric Category : PROPOSED STANDARD Source : Path Computation Element Area : Routing Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Thu Dec 5 16:22:18 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FD71AE21C; Thu, 5 Dec 2013 16:22:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgZWbsB4vSCT; Thu, 5 Dec 2013 16:22:16 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 85C6D1AE20D; Thu, 5 Dec 2013 16:22:16 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id BEC647FC383; Thu, 5 Dec 2013 16:22:12 -0800 (PST) To: udayasree.palle@huawei.com, qzhao@huawei.com, daniel@olddog.co.uk, fabien.verhaeghe@gmail.com, takeda.tomonori@lab.ntt.co.jp, zali@cisco.com, julien.meuric@orange-ftgroup.com From: RFC Errata System Message-Id: <20131206002212.BEC647FC383@rfc-editor.org> Date: Thu, 5 Dec 2013 16:22:12 -0800 (PST) X-Mailman-Approved-At: Fri, 06 Dec 2013 01:41:02 -0800 Cc: pce@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [Pce] [Errata Verified] RFC6006 (3819) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 00:22:18 -0000 The following errata report has been verified for RFC6006, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6006&eid=3819 -------------------------------------- Status: Verified Type: Editorial Reported by: Udayasree Date Reported: 2013-12-04 Verified by: Adrian Farrel (IESG) Section: 3.13.2 Original Text ------------- Each message sent to the PCE, except the last one, will have the F-bit set in the RP object to signify that the response has been fragmented into multiple messages. Corrected Text -------------- Each message sent by the PCE, except the last one, will have the F-bit set in the RP object to signify that the response has been fragmented into multiple messages. Notes ----- This section is about response, and response messages are sent *by* the PCE. -------------------------------------- RFC6006 (draft-ietf-pce-pcep-p2mp-extensions-11) -------------------------------------- Title : Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths Publication Date : September 2010 Author(s) : Q. Zhao, Ed., D. King, Ed., F. Verhaeghe, T. Takeda, Z. Ali, J. Meuric Category : PROPOSED STANDARD Source : Path Computation Element Area : Routing Stream : IETF Verifying Party : IESG From udayasree.palle@huawei.com Tue Dec 10 02:08:22 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A49C1AD944 for ; Tue, 10 Dec 2013 02:08:22 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9Rz24FzCDxs for ; Tue, 10 Dec 2013 02:08:18 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 94C8C1ACCDF for ; Tue, 10 Dec 2013 02:08:16 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYV34866; Tue, 10 Dec 2013 10:08:11 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Dec 2013 10:08:03 +0000 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Dec 2013 10:08:09 +0000 Received: from szxeml561-mbx.china.huawei.com ([169.254.5.101]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.03.0158.001; Tue, 10 Dec 2013 18:08:01 +0800 From: Udayasree palle To: "draft-ietf-pce-pcep-p2mp-extensions@tools.ietf.org" Thread-Topic: Posasible Errata regarding draft-ietf-pce-pcep-p2mp-extensions Thread-Index: Ac71j7Shy4jy+c4oQP6emJhLO/eNCw== Date: Tue, 10 Dec 2013 10:08:01 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.147.110] Content-Type: multipart/alternative; boundary="_000_EFF3DD5FFB75AC4D89158F068C24F4BB39DB1F31szxeml561mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "pce@ietf.org" , "jpv@cisco.com" Subject: [Pce] Posasible Errata regarding draft-ietf-pce-pcep-p2mp-extensions X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 10:08:22 -0000 --_000_EFF3DD5FFB75AC4D89158F068C24F4BB39DB1F31szxeml561mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, 3.15. P2MP PCEP-ERROR Objects and Types Error-Type=3D18; Error-Value=3D1: if a PCE has not received the last piece of the fragmented message, it should send an error message to the sender to signal that it has received an incomplete message (i.e., "Fragmented request failure"). The PCE MUST send a PCErr message with a PCEP-ERROR object (Error-Type=3D18) and an Error-Value (Error-Value=3D1). The fragmentation is done for both request and reply messages, but it looks= like the error value is defined only for request. Suggested Text: Make it generic - Remove the word 'request' - Replace PCE with PCEP speaker - Update IANA Error-Type=3D18; Error-Value=3D1: if a PCEP speaker has not received the la= st piece of the fragmented message, it should send an error message to the sender to signal that it has received an incomplete message (i.e., "Fragmented failure"). The PCEP speaker MUST send a PCErr message with a PCEP-ERROR object (Error-Type=3D18) and an Error-Value (Error-Value=3D1). Or Add a new Error-Value! How to handle this? Regards, Udayasree --_000_EFF3DD5FFB75AC4D89158F068C24F4BB39DB1F31szxeml561mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

3.15.  P2MP PCEP-ERROR Objects and Types

 

Error-Type=3D18; Error-Value=3D1: if a PCE has not receive= d the last

   piece of the fragmented message, it should se= nd an error message to

   the sender to signal that it has received an = incomplete message

   (i.e., "Fragmented request failure"= ).  The PCE MUST send a PCErr

   message with a PCEP-ERROR object (Error-Type= =3D18) and an Error-Value

   (Error-Value=3D1).

 

The fragmentation is done for both request and reply= messages, but it looks like the error value is defined only for request.

 

Suggested Text:

        &nbs= p;      Make it generic

-       = ; Remove the word ‘request’

-       = ; Replace PCE with PCEP speaker

-       = ; Update IANA

 

Error-Type=3D18; Error-Value= =3D1: if a PCEP speaker has not received the last

   piece of the fra= gmented message, it should send an error message to

   the sender to si= gnal that it has received an incomplete message

   (i.e., "Fra= gmented failure").  The PCEP speaker MUST send a PCErr=

   message with a P= CEP-ERROR object (Error-Type=3D18) and an Error-Value

   (Error-Value=3D1= ).

 

Or

 

Add a new Error-Value!<= o:p>

 

How to handle this?

 

Regards,

Udayasree

 

--_000_EFF3DD5FFB75AC4D89158F068C24F4BB39DB1F31szxeml561mbxchi_-- From wwwrun@rfc-editor.org Tue Dec 10 01:58:04 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 526021A8032 for ; Tue, 10 Dec 2013 01:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJhivFwVwT6O for ; Tue, 10 Dec 2013 01:58:02 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF151A1F3D for ; Tue, 10 Dec 2013 01:58:02 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 9A3167FC155; Tue, 10 Dec 2013 01:57:53 -0800 (PST) To: qzhao@huawei.com, daniel@olddog.co.uk, fabien.verhaeghe@gmail.com, takeda.tomonori@lab.ntt.co.jp, zali@cisco.com, julien.meuric@orange-ftgroup.com, stbryant@cisco.com, adrian@olddog.co.uk, jpv@cisco.com, julien.meuric@orange.com From: RFC Errata System Message-Id: <20131210095756.9A3167FC155@rfc-editor.org> Date: Tue, 10 Dec 2013 01:57:53 -0800 (PST) X-Mailman-Approved-At: Tue, 10 Dec 2013 02:09:37 -0800 Cc: pce@ietf.org, rfc-editor@rfc-editor.org Subject: [Pce] [Editorial Errata Reported] RFC6006 (3830) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 09:58:04 -0000 The following errata report has been submitted for RFC6006, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6006&eid=3830 -------------------------------------- Type: Editorial Reported by: Udayasree Section: 3.15 Original Text ------------- To indicate P2MP message fragmentation errors associated with a P2MP path request, a new Error-Type (17) and subsequent error-values are defined as follows for inclusion in the PCEP-ERROR object: Corrected Text -------------- To indicate P2MP message fragmentation errors associated with a P2MP path request, a new Error-Type (18) and subsequent error-values are defined as follows for inclusion in the PCEP-ERROR object: Notes ----- 17 P2MP END-POINTS Error 18 P2MP Fragmentation Error It should be 18 in this statement Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6006 (draft-ietf-pce-pcep-p2mp-extensions-11) -------------------------------------- Title : Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths Publication Date : September 2010 Author(s) : Q. Zhao, Ed., D. King, Ed., F. Verhaeghe, T. Takeda, Z. Ali, J. Meuric Category : PROPOSED STANDARD Source : Path Computation Element Area : Routing Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Fri Dec 13 01:29:28 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C449F1ADFD4 for ; Fri, 13 Dec 2013 01:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXu9DlMLN-Jq for ; Fri, 13 Dec 2013 01:29:26 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id E6CB01A802A for ; Fri, 13 Dec 2013 01:29:25 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 917B37FC390; Fri, 13 Dec 2013 01:29:19 -0800 (PST) To: qzhao@huawei.com, daniel@olddog.co.uk, fabien.verhaeghe@gmail.com, takeda.tomonori@lab.ntt.co.jp, zali@cisco.com, julien.meuric@orange-ftgroup.com, stbryant@cisco.com, adrian@olddog.co.uk, jpv@cisco.com, julien.meuric@orange.com From: RFC Errata System Message-Id: <20131213092919.917B37FC390@rfc-editor.org> Date: Fri, 13 Dec 2013 01:29:19 -0800 (PST) X-Mailman-Approved-At: Fri, 13 Dec 2013 02:46:14 -0800 Cc: pce@ietf.org, rfc-editor@rfc-editor.org Subject: [Pce] [Editorial Errata Reported] RFC6006 (3836) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 09:29:29 -0000 The following errata report has been submitted for RFC6006, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6006&eid=3836 -------------------------------------- Type: Editorial Reported by: Udayasree Section: 3.13 Original Text ------------- The F-bit is used in the RP object header to signal that the initial request or response was too large to fit into a single message and will be fragmented into multiple messages. Corrected Text -------------- The F-bit is used in the RP object to signal that the initial request or response was too large to fit into a single message and will be fragmented into multiple messages. Notes ----- F-bit is used in the RP object body but not the object header Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6006 (draft-ietf-pce-pcep-p2mp-extensions-11) -------------------------------------- Title : Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths Publication Date : September 2010 Author(s) : Q. Zhao, Ed., D. King, Ed., F. Verhaeghe, T. Takeda, Z. Ali, J. Meuric Category : PROPOSED STANDARD Source : Path Computation Element Area : Routing Stream : IETF Verifying Party : IESG From udayasree.palle@huawei.com Fri Dec 13 04:40:05 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDEA1ADFC4 for ; Fri, 13 Dec 2013 04:40:05 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Wnzh_tpzMOr for ; Fri, 13 Dec 2013 04:40:02 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C957F1AE24B for ; Fri, 13 Dec 2013 04:39:59 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBJ18746; Fri, 13 Dec 2013 12:39:52 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 13 Dec 2013 12:39:35 +0000 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 13 Dec 2013 12:39:49 +0000 Received: from szxeml561-mbx.china.huawei.com ([169.254.5.101]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Fri, 13 Dec 2013 20:39:45 +0800 From: Udayasree palle To: "draft-ietf-pce-pcep-p2mp-extensions@tools.ietf.org" Thread-Topic: Possible Errata regarding RFC6006 Thread-Index: AQHO+ABnc5dvcNPul0CCR9Xt0cYYsg== Date: Fri, 13 Dec 2013 12:39:45 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.147.110] Content-Type: multipart/alternative; boundary="_000_EFF3DD5FFB75AC4D89158F068C24F4BB39DB2217szxeml561mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "pce@ietf.org" , "jpv@cisco.com" Subject: [Pce] Possible Errata regarding RFC6006 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 12:40:05 -0000 --_000_EFF3DD5FFB75AC4D89158F068C24F4BB39DB2217szxeml561mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, Please check and let me know your suggestion Regards, Udayasree From: Udayasree palle Sent: 10 December 2013 15:38 To: 'draft-ietf-pce-pcep-p2mp-extensions@tools.ietf.org' Cc: julien.meuric@orange.com; jpv@cisco.com; adrian@olddog.co.uk; pce@ietf.= org Subject: Posasible Errata regarding draft-ietf-pce-pcep-p2mp-extensions Hi All, 3.15. P2MP PCEP-ERROR Objects and Types Error-Type=3D18; Error-Value=3D1: if a PCE has not received the last piece of the fragmented message, it should send an error message to the sender to signal that it has received an incomplete message (i.e., "Fragmented request failure"). The PCE MUST send a PCErr message with a PCEP-ERROR object (Error-Type=3D18) and an Error-Value (Error-Value=3D1). The fragmentation is done for both request and reply messages, but it looks= like the error value is defined only for request. Suggested Text: Make it generic - Remove the word 'request' - Replace PCE with PCEP speaker - Update IANA Error-Type=3D18; Error-Value=3D1: if a PCEP speaker has not received the la= st piece of the fragmented message, it should send an error message to the sender to signal that it has received an incomplete message (i.e., "Fragmented failure"). The PCEP speaker MUST send a PCErr message with a PCEP-ERROR object (Error-Type=3D18) and an Error-Value (Error-Value=3D1). Or Add a new Error-Value! How to handle this? Regards, Udayasree --_000_EFF3DD5FFB75AC4D89158F068C24F4BB39DB2217szxeml561mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

   &nbs= p;           Please check= and let me know your suggestion

 

Regards,

Udayasree

 

 

From: Udayasre= e palle
Sent: 10 December 2013 15:38
To: 'draft-ietf-pce-pcep-p2mp-extensions@tools.ietf.org'
Cc: julien.meuric@orange.com; jpv@cisco.com; adrian@olddog.co.uk; pc= e@ietf.org
Subject: Posasible Errata regarding draft-ietf-pce-pcep-p2mp-extensi= ons

 

Hi All,

 

3.15.  P2MP PCEP-ERROR Objects and Types

 

Error-Type=3D18; Error-Value=3D1: if a PCE has not receive= d the last

   piece of the fragmented message, it should se= nd an error message to

   the sender to signal that it has received an = incomplete message

   (i.e., "Fragmented request failure"= ).  The PCE MUST send a PCErr

   message with a PCEP-ERROR object (Error-Type= =3D18) and an Error-Value

   (Error-Value=3D1).

 

The fragmentation is done for both request and reply= messages, but it looks like the error value is defined only for request.

 

Suggested Text:

        &nbs= p;      Make it generic

-       = ; Remove the word ‘request’

-       = ; Replace PCE with PCEP speaker

-       = ; Update IANA

 

Error-Type=3D18; Error-Value= =3D1: if a PCEP speaker has not received the last

   piece of the fra= gmented message, it should send an error message to

   the sender to si= gnal that it has received an incomplete message

   (i.e., "Fra= gmented failure").  The PCEP speaker MUST send a PCErr=

   message with a P= CEP-ERROR object (Error-Type=3D18) and an Error-Value

   (Error-Value=3D1= ).

 

Or

 

Add a new Error-Value!<= o:p>

 

How to handle this?

 

Regards,

Udayasree

 

--_000_EFF3DD5FFB75AC4D89158F068C24F4BB39DB2217szxeml561mbxchi_-- From quintin.zhao@huawei.com Fri Dec 13 10:45:44 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7948D1AE39A for ; Fri, 13 Dec 2013 10:45:44 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHwdlEyssd5F for ; Fri, 13 Dec 2013 10:45:40 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECEF1ADF85 for ; Fri, 13 Dec 2013 10:45:38 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBJ42873; Fri, 13 Dec 2013 18:45:31 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 13 Dec 2013 18:45:11 +0000 Received: from SJCEML401-HUB.china.huawei.com (10.212.94.42) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 13 Dec 2013 18:45:28 +0000 Received: from SJCEML501-MBS.china.huawei.com ([169.254.2.165]) by sjceml401-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Fri, 13 Dec 2013 10:45:16 -0800 From: Quintin zhao To: Udayasree palle , "draft-ietf-pce-pcep-p2mp-extensions@tools.ietf.org" Thread-Topic: Possible Errata regarding RFC6006 Thread-Index: AQHO+ABnc5dvcNPul0CCR9Xt0cYYsppSbqzw Date: Fri, 13 Dec 2013 18:45:15 +0000 Message-ID: <11208E03C9803E4CB4C3D898F153D6C0306F0961@sjceml501-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.11] Content-Type: multipart/alternative; boundary="_000_11208E03C9803E4CB4C3D898F153D6C0306F0961sjceml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "pce@ietf.org" , "jpv@cisco.com" Subject: Re: [Pce] Possible Errata regarding RFC6006 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 18:45:44 -0000 --_000_11208E03C9803E4CB4C3D898F153D6C0306F0961sjceml501mbschi_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Udayasree, The fragmentation is only for the request message only, see section 3.3.1 = of RFC 6006: =93The F-bit is added to the flag bits of the RP object to indicate to the receiver that the request is part of a fragmented request, or is not a fragmented request.=94 There is no fragmentation function supported in reply message, so there is = no need to have a error code for the reply message. Regards, Quintin From: Udayasree palle [mailto:udayasree.palle@huawei.com] Sent: 2013?12?13? 7:40 To: draft-ietf-pce-pcep-p2mp-extensions@tools.ietf.org Cc: julien.meuric@orange.com; jpv@cisco.com; adrian@olddog.co.uk; pce@ietf.= org Subject: Possible Errata regarding RFC6006 Hi All, Please check and let me know your suggestion Regards, Udayasree From: Udayasree palle Sent: 10 December 2013 15:38 To: 'draft-ietf-pce-pcep-p2mp-extensions@tools.ietf.org' Cc: julien.meuric@orange.com; jpv@cisco.co= m; adrian@olddog.co.uk; p= ce@ietf.org Subject: Posasible Errata regarding draft-ietf-pce-pcep-p2mp-extensions Hi All, 3.15. P2MP PCEP-ERROR Objects and Types Error-Type=3D18; Error-Value=3D1: if a PCE has not received the last piece of the fragmented message, it should send an error message to the sender to signal that it has received an incomplete message (i.e., "Fragmented request failure"). The PCE MUST send a PCErr message with a PCEP-ERROR object (Error-Type=3D18) and an Error-Value (Error-Value=3D1). The fragmentation is done for both request and reply messages, but it looks= like the error value is defined only for request. Suggested Text: Make it generic - Remove the word =91request=92 - Replace PCE with PCEP speaker - Update IANA Error-Type=3D18; Error-Value=3D1: if a PCEP speaker has not received the la= st piece of the fragmented message, it should send an error message to the sender to signal that it has received an incomplete message (i.e., "Fragmented failure"). The PCEP speaker MUST send a PCErr message with a PCEP-ERROR object (Error-Type=3D18) and an Error-Value (Error-Value=3D1). Or Add a new Error-Value! How to handle this? Regards, Udayasree --_000_11208E03C9803E4CB4C3D898F153D6C0306F0961sjceml501mbschi_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Udayasree,<= /span>

 

The fragmentation is o= nly for the request message only,  see section 3.3.1 of RFC 6006：

 

=93The F-bit is added to the flag bits of the RP object to indicate to

  = the receiver that the request is part of a fragmented request, or is

  = not a fragmented request.=94

 

 

There is no fragmentat= ion function supported in reply message, so there is no need to have a erro= r code for the reply message.

 

Regards,

Quintin

 

From: Udayasre= e palle [mailto:udayasree.palle@huawei.com]
Sent: 2013年= 12月13日 7:40
To: draft-ietf-pce-pcep-p2mp-extensions@tools.ietf.org
Cc: julien.meuric@orange.com; jpv@cisco.com; adrian@olddog.co.uk; pc= e@ietf.org
Subject: Possible Errata regarding RFC6006

 

Hi All,

   &nbs= p;           Please check= and let me know your suggestion

 

Regards,

Udayasree

 

 

From: Udayasre= e palle
Sent: 10 December 2013 15:38
To: 'draft-ietf-pce-pcep-p2mp-extensions@tools.ietf.org'
Cc: julien.meuric@orange= .com; jpv@cisco.com; adrian@olddog.co.uk; pce@ietf.org Subject: Posasible Errata regarding draft-ietf-pce-pcep-p2mp-extensi= ons

 

Hi All,

 

3.15.  P2MP PCEP-ERROR Objects and Types

 

Error-Type=3D18; Error-Value=3D1: if a PCE has not receive= d the last

   piece of the fragmented message, it should se= nd an error message to

   the sender to signal that it has received an = incomplete message

   (i.e., "Fragmented request failure"= ).  The PCE MUST send a PCErr

   message with a PCEP-ERROR object (Error-Type= =3D18) and an Error-Value

   (Error-Value=3D1).

 

The fragmentation is done for both request and reply= messages, but it looks like the error value is defined only for request.

 

Suggested Text:

        &nbs= p;      Make it generic

-       = ; Remove the word =91request=92

-       = ; Replace PCE with PCEP speaker

-       = ; Update IANA

 =

Error-Type=3D18; Error-Value=3D= 1: if a PCEP speaker has not received the last

   piece of the fragm= ented message, it should send an error message to

   the sender to sign= al that it has received an incomplete message

   (i.e., "Fragm= ented failure").  The PCEP speaker MUST send a PCErr

   message with a PCE= P-ERROR object (Error-Type=3D18) and an Error-Value

   (Error-Value=3D1).=

 

Or

 

Add a new Error-Value!

 

How to handle this?

 

Regards,

Udayasree

 

--_000_11208E03C9803E4CB4C3D898F153D6C0306F0961sjceml501mbschi_-- From rjsparks@nostrum.com Fri Dec 13 11:42:46 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD71A1AE3DA; Fri, 13 Dec 2013 11:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.035 X-Spam-Level: X-Spam-Status: No, score=-1.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAVBnln9SUhd; Fri, 13 Dec 2013 11:42:45 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id BD2341AE3D9; Fri, 13 Dec 2013 11:42:44 -0800 (PST) Received: from unnumerable.local (pool-173-71-10-88.dllstx.fios.verizon.net [173.71.10.88]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rBDJgaZx006041 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Fri, 13 Dec 2013 13:42:36 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <52AB632D.60104@nostrum.com> Date: Fri, 13 Dec 2013 13:42:37 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: General Area Review Team , pce@ietf.org, draft-ietf-pce-vendor-constraints@tools.ietf.org References: <52950B49.4040209@nostrum.com> <52950DBE.7060303@nostrum.com> In-Reply-To: <52950DBE.7060303@nostrum.com> Content-Type: multipart/alternative; boundary="------------050108060608090503000903" Received-SPF: pass (shaman.nostrum.com: 173.71.10.88 is authenticated by a trusted mechanism) Subject: [Pce] Gen-art Telechat review: draft-ietf-pce-vendor-constraints-11 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 19:42:47 -0000 This is a multi-part message in MIME format. --------------050108060608090503000903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-pce-vendor-constraints-11 Reviewer: Robert Sparks Review Date: 13-Dec-2013 IETF LC End Date: 9-Dec-2013 IESG Telechat date: 19-Dec-2013 Summary: Ready Adrian responded to my LC comments on this version of the draft, but only copied the authors and the pce wg. If you're curious, and not already on that wg list, his response is here: > -------- Original Message -------- > Subject: Gen-art last call review: draft-ietf-pce-vendor-constraints-11 > Date: Tue, 26 Nov 2013 14:57:45 -0600 > From: Robert Sparks > To: pce@ietf.org, draft-ietf-pce-vendor-constraints@tools.ietf.org > > > > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > . > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-pce-vendor-constraints-11 > Reviewer: Robert Sparks > Review Date: 26 Nov 2013 > IETF LC End Date: 9 Dec 2013 > IESG Telechat date: not yet scheduled > > Summary: Ready (but I have a couple of comments for consideration) > > Given a quick scan of the list history for this document, I'm surprised > there's not more discussion about the potential for creating islands of > non-interoperable equipment, and some recommendation for when to define > and how to deploy a standard version of a constraint when a common thing > is found among vendor specific variants of the constraint (are there > implications if an element include both the standard and vendor specific > variants?) > > This is probably bigger than this document, and take it for what it's > worth, but the practice of relisting the definition of when > you add objects doesn't seem to be working well. For instance, had XRO > or GC been defined later, you're probably ok with them being used with > these objects too, right? As it is, I'm having a hard time seeing the > value in redefining the grammar this way each time you add a new thing. > It leads to odd artifacts like _this_ document not providing a good > reference to what XRO and GC are (you have to chase through the > registry, or look at 5557 or 5521, neither of which are referenced here. > > > > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art --------------050108060608090503000903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-pce-vendor-constraints-11
Reviewer: Robert Sparks
Review Date: 13-Dec-2013
IETF LC End Date: 9-Dec-2013
IESG Telechat date: 19-Dec-2013

Summary: Ready

Adrian responded to my LC comments on this version of the draft, but only copied the authors and the pce wg.
If you're curious, and not already on that wg list, his response is here:
<http://www.ietf.org/mail-archive/web/pce/current/msg03487.html>

-------- Original Message --------
Subject: Gen-art last call review: draft-ietf-pce-vendor-constraints-11
Date: Tue, 26 Nov 2013 14:57:45 -0600
From: Robert Sparks <rjsparks@nostrum.com>
To: pce@ietf.org, draft-ietf-pce-vendor-constraints@tools.ietf.org 


I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-pce-vendor-constraints-11
Reviewer: Robert Sparks
Review Date: 26 Nov 2013
IETF LC End Date: 9 Dec 2013
IESG Telechat date: not yet scheduled

Summary: Ready (but I have a couple of comments for consideration)

Given a quick scan of the list history for this document, I'm surprised 
there's not more discussion about the potential for creating islands of 
non-interoperable equipment, and some recommendation for when to define 
and how to deploy a standard version of a constraint when a common thing 
is found among vendor specific variants of the constraint (are there 
implications if an element include both the standard and vendor specific 
variants?)

This is probably bigger than this document, and take it for what it's 
worth, but the practice of relisting the definition of <svec-list> when 
you add objects doesn't seem to be working well. For instance, had XRO 
or GC been defined later, you're probably ok with them being used with 
these objects too, right? As it is, I'm having a hard time seeing the 
value in redefining the grammar this way each time you add a new thing. 
It leads to odd artifacts like _this_ document not providing a good 
reference to what XRO and GC are (you have to chase through the 
registry, or look at 5557 or 5521, neither of which are referenced here.






_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

--------------050108060608090503000903-- From rjsparks@nostrum.com Fri Dec 13 14:21:27 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAFEF1AE01D; Fri, 13 Dec 2013 14:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.035 X-Spam-Level: X-Spam-Status: No, score=-1.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tK-NEsxkitap; Fri, 13 Dec 2013 14:21:25 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0601AE082; Fri, 13 Dec 2013 14:21:21 -0800 (PST) Received: from unnumerable.local (pool-173-71-10-88.dllstx.fios.verizon.net [173.71.10.88]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rBDMLErJ012143 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Fri, 13 Dec 2013 16:21:14 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <52AB885B.9080501@nostrum.com> Date: Fri, 13 Dec 2013 16:21:15 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: General Area Review Team , pce@ietf.org, draft-ietf-pce-vendor-constraints@tools.ietf.org References: <52950B49.4040209@nostrum.com> <52950DBE.7060303@nostrum.com> <52AB632D.60104@nostrum.com> In-Reply-To: <52AB632D.60104@nostrum.com> Content-Type: multipart/alternative; boundary="------------040602020006060206000401" Received-SPF: pass (shaman.nostrum.com: 173.71.10.88 is authenticated by a trusted mechanism) Subject: Re: [Pce] [Gen-art] Gen-art Telechat review: draft-ietf-pce-vendor-constraints-11 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 22:21:28 -0000 This is a multi-part message in MIME format. --------------040602020006060206000401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/13/13 1:42 PM, Robert Sparks wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-ietf-pce-vendor-constraints-11 > Reviewer: Robert Sparks > Review Date: 13-Dec-2013 > IETF LC End Date: 9-Dec-2013 > IESG Telechat date: 19-Dec-2013 > > Summary: Ready > > Adrian responded to my LC comments on this version of the draft, but > only copied the authors and the pce wg. ... and that's because he reply-all'ed to the addresses I originally sent the review to, as the To header below shows. Totally my fumble that kept his original reply from making it to the gen-art list. Apologies. > If you're curious, and not already on that wg list, his response is here: > > >> -------- Original Message -------- >> Subject: Gen-art last call review: draft-ietf-pce-vendor-constraints-11 >> Date: Tue, 26 Nov 2013 14:57:45 -0600 >> From: Robert Sparks >> To: pce@ietf.org, draft-ietf-pce-vendor-constraints@tools.ietf.org >> >> >> >> I am the assigned Gen-ART reviewer for this draft. For background on >> Gen-ART, please see the FAQ at >> >> . >> >> Please resolve these comments along with any other Last Call comments >> you may receive. >> >> Document: draft-ietf-pce-vendor-constraints-11 >> Reviewer: Robert Sparks >> Review Date: 26 Nov 2013 >> IETF LC End Date: 9 Dec 2013 >> IESG Telechat date: not yet scheduled >> >> Summary: Ready (but I have a couple of comments for consideration) >> >> Given a quick scan of the list history for this document, I'm surprised >> there's not more discussion about the potential for creating islands of >> non-interoperable equipment, and some recommendation for when to define >> and how to deploy a standard version of a constraint when a common thing >> is found among vendor specific variants of the constraint (are there >> implications if an element include both the standard and vendor specific >> variants?) >> >> This is probably bigger than this document, and take it for what it's >> worth, but the practice of relisting the definition of when >> you add objects doesn't seem to be working well. For instance, had XRO >> or GC been defined later, you're probably ok with them being used with >> these objects too, right? As it is, I'm having a hard time seeing the >> value in redefining the grammar this way each time you add a new thing. >> It leads to odd artifacts like _this_ document not providing a good >> reference to what XRO and GC are (you have to chase through the >> registry, or look at 5557 or 5521, neither of which are referenced here. >> >> >> >> >> >> _______________________________________________ >> Gen-art mailing list >> Gen-art@ietf.org >> https://www.ietf.org/mailman/listinfo/gen-art > > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art --------------040602020006060206000401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 12/13/13 1:42 PM, Robert Sparks wrote:
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-pce-vendor-constraints-11
Reviewer: Robert Sparks
Review Date: 13-Dec-2013
IETF LC End Date: 9-Dec-2013
IESG Telechat date: 19-Dec-2013

Summary: Ready

Adrian responded to my LC comments on this version of the draft, but only copied the authors and the pce wg.
... and that's because he reply-all'ed to the addresses I originally sent the review to, as the To header below shows.
Totally my fumble that kept his original reply from making it to the gen-art list. Apologies.

If you're curious, and not already on that wg list, his response is here:
<http://www.ietf.org/mail-archive/web/pce/current/msg03487.html>

-------- Original Message --------
Subject: Gen-art last call review: draft-ietf-pce-vendor-constraints-11
Date: Tue, 26 Nov 2013 14:57:45 -0600
From: Robert Sparks <rjsparks@nostrum.com>
To: pce@ietf.org, draft-ietf-pce-vendor-constraints@tools.ietf.org 


I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-pce-vendor-constraints-11
Reviewer: Robert Sparks
Review Date: 26 Nov 2013
IETF LC End Date: 9 Dec 2013
IESG Telechat date: not yet scheduled

Summary: Ready (but I have a couple of comments for consideration)

Given a quick scan of the list history for this document, I'm surprised 
there's not more discussion about the potential for creating islands of 
non-interoperable equipment, and some recommendation for when to define 
and how to deploy a standard version of a constraint when a common thing 
is found among vendor specific variants of the constraint (are there 
implications if an element include both the standard and vendor specific 
variants?)

This is probably bigger than this document, and take it for what it's 
worth, but the practice of relisting the definition of <svec-list> when 
you add objects doesn't seem to be working well. For instance, had XRO 
or GC been defined later, you're probably ok with them being used with 
these objects too, right? As it is, I'm having a hard time seeing the 
value in redefining the grammar this way each time you add a new thing. 
It leads to odd artifacts like _this_ document not providing a good 
reference to what XRO and GC are (you have to chase through the 
registry, or look at 5557 or 5521, neither of which are referenced here.






_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art




_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

--------------040602020006060206000401-- From wwwrun@rfc-editor.org Fri Dec 13 14:18:38 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10B51ADF8B; Fri, 13 Dec 2013 14:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OskWom2HI8eJ; Fri, 13 Dec 2013 14:18:37 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFF41AD694; Fri, 13 Dec 2013 14:18:37 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id A1ED07FC157; Fri, 13 Dec 2013 14:18:30 -0800 (PST) To: udayasree.palle@huawei.com, qzhao@huawei.com, daniel@olddog.co.uk, fabien.verhaeghe@gmail.com, takeda.tomonori@lab.ntt.co.jp, zali@cisco.com, julien.meuric@orange-ftgroup.com From: RFC Errata System Message-Id: <20131213221830.A1ED07FC157@rfc-editor.org> Date: Fri, 13 Dec 2013 14:18:30 -0800 (PST) X-Mailman-Approved-At: Mon, 16 Dec 2013 01:24:23 -0800 Cc: pce@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [Pce] [Errata Verified] RFC6006 (3830) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 22:18:39 -0000 The following errata report has been verified for RFC6006, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6006&eid=3830 -------------------------------------- Status: Verified Type: Editorial Reported by: Udayasree Date Reported: 2013-12-10 Verified by: Adrian Farrel (IESG) Section: 3.15 Original Text ------------- To indicate P2MP message fragmentation errors associated with a P2MP path request, a new Error-Type (17) and subsequent error-values are defined as follows for inclusion in the PCEP-ERROR object: Corrected Text -------------- To indicate P2MP message fragmentation errors associated with a P2MP path request, a new Error-Type (18) and subsequent error-values are defined as follows for inclusion in the PCEP-ERROR object: Notes ----- 17 P2MP END-POINTS Error 18 P2MP Fragmentation Error It should be 18 in this statement -------------------------------------- RFC6006 (draft-ietf-pce-pcep-p2mp-extensions-11) -------------------------------------- Title : Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths Publication Date : September 2010 Author(s) : Q. Zhao, Ed., D. King, Ed., F. Verhaeghe, T. Takeda, Z. Ali, J. Meuric Category : PROPOSED STANDARD Source : Path Computation Element Area : Routing Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Fri Dec 13 14:18:58 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22991ADFD6; Fri, 13 Dec 2013 14:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N57RE_I_1nGG; Fri, 13 Dec 2013 14:18:56 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE661AE042; Fri, 13 Dec 2013 14:18:56 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 0E6A77FC157; Fri, 13 Dec 2013 14:18:50 -0800 (PST) To: udayasree.palle@huawei.com, qzhao@huawei.com, daniel@olddog.co.uk, fabien.verhaeghe@gmail.com, takeda.tomonori@lab.ntt.co.jp, zali@cisco.com, julien.meuric@orange-ftgroup.com From: RFC Errata System Message-Id: <20131213221850.0E6A77FC157@rfc-editor.org> Date: Fri, 13 Dec 2013 14:18:50 -0800 (PST) X-Mailman-Approved-At: Mon, 16 Dec 2013 01:24:26 -0800 Cc: pce@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [Pce] [Errata Held for Document Update] RFC6006 (3836) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 22:18:58 -0000 The following errata report has been held for document update for RFC6006, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6006&eid=3836 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Udayasree Date Reported: 2013-12-13 Held by: Adrian Farrel (IESG) Section: 3.13 Original Text ------------- The F-bit is used in the RP object header to signal that the initial request or response was too large to fit into a single message and will be fragmented into multiple messages. Corrected Text -------------- The F-bit is used in the RP object to signal that the initial request or response was too large to fit into a single message and will be fragmented into multiple messages. Notes ----- F-bit is used in the RP object body but not the object header -------------------------------------- RFC6006 (draft-ietf-pce-pcep-p2mp-extensions-11) -------------------------------------- Title : Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths Publication Date : September 2010 Author(s) : Q. Zhao, Ed., D. King, Ed., F. Verhaeghe, T. Takeda, Z. Ali, J. Meuric Category : PROPOSED STANDARD Source : Path Computation Element Area : Routing Stream : IETF Verifying Party : IESG From jari.arkko@piuha.net Tue Dec 17 02:35:31 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D441AE148; Tue, 17 Dec 2013 02:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6HozQFq3t7j; Tue, 17 Dec 2013 02:35:28 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 5B94D1AE142; Tue, 17 Dec 2013 02:35:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 602492CCC1; Tue, 17 Dec 2013 12:35:26 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbkWfCe8HcGs; Tue, 17 Dec 2013 12:35:25 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 13D2E2CC48; Tue, 17 Dec 2013 12:35:24 +0200 (EET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jari Arkko In-Reply-To: <52AB885B.9080501@nostrum.com> Date: Tue, 17 Dec 2013 05:35:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2C987894-CE08-4ADA-B568-EAED2EA6EED9@piuha.net> References: <52950B49.4040209@nostrum.com> <52950DBE.7060303@nostrum.com> <52AB632D.60104@nostrum.com> <52AB885B.9080501@nostrum.com> To: Robert Sparks , Adrian Farrel X-Mailer: Apple Mail (2.1510) Cc: draft-ietf-pce-vendor-constraints@tools.ietf.org, General Area Review Team , pce@ietf.org Subject: Re: [Pce] [Gen-art] Gen-art Telechat review: draft-ietf-pce-vendor-constraints-11 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 10:35:31 -0000 Thanks for your review, Robert! I have balloted no-objection for this draft on the upcoming IESG = telechat. #begin non-blocking-comment For what it is worth, I agree with Robert's comment that some = highlighting of the interoperability challenges of vendor-specific = options might have been useful. I don't think it is a big problem in = this case (and this seems to be confirmed by Adrian's reply) but some = similar RFCs have talked about it. If you want to take a look at what = has been done in the past, there's text in RFC 5094 Section 1 last two = paragraphs, RFC 4243 Section 3 last paragraph, RFC 3588 Section 11.1.1 = two last sentences, for instance. The general thrust is emphasising the = local applicability of vendor information, encouraging documentation of = vendor's information elements, and recommending standardisation when = there's more general interest for the information in question. Jari From internet-drafts@ietf.org Mon Dec 23 14:19:11 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216751AE307; Mon, 23 Dec 2013 14:19:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 frRukAcUwY3F; Mon, 23 Dec 2013 14:19:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB631AE2FC; Mon, 23 Dec 2013 14:19:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131223221909.1855.63410.idtracker@ietfa.amsl.com> Date: Mon, 23 Dec 2013 14:19:09 -0800 Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-wson-routing-wavelength-10.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 22:19:11 -0000 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 Working Group of= the IETF. Title : PCEP Requirements for WSON Routing and Wavelength= Assignment Authors : Young Lee Greg Bernstein Jonas Martensson Tomonori Takeda Takehiro Tsuritani Oscar Gonzalez de Dios Filename : draft-ietf-pce-wson-routing-wavelength-10.txt Pages : 13 Date : 2013-12-23 Abstract: This memo provides application-specific requirements for the Path Computation Element communication Protocol (PCEP) for the support of Wavelength Switched Optical Networks (WSON). Lightpath provisioning in WSONs requires a routing and wavelength assignment (RWA) process. From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical light path computation. Requirements for Optical impairments will be addressed in a separate document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-wson-routing-wavelength/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-wson-routing-wavelength-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-wson-routing-wavelength-10 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 leeyoung@huawei.com Mon Dec 23 14:22:20 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F581AE316 for ; Mon, 23 Dec 2013 14:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kan-zITqnzL for ; Mon, 23 Dec 2013 14:22:16 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1BD1AE2FF for ; Mon, 23 Dec 2013 14:22:15 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZH67282; Mon, 23 Dec 2013 22:22:11 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 23 Dec 2013 22:21:22 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 23 Dec 2013 22:22:09 +0000 Received: from DFWEML510-MBX.china.huawei.com ([fe80::a55a:d832:7869:d6a6]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0158.001; Mon, 23 Dec 2013 14:22:02 -0800 From: Leeyoung To: "'JP Vasseur'" , Julien Meuric Thread-Topic: New Version Notification for draft-ietf-pce-wson-routing-wavelength-10.txt Thread-Index: AQHPAC0E/ujNEZySB0ucqFbO+felBppiWb+g Date: Mon, 23 Dec 2013 22:22:02 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729BA5060@dfweml510-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.215] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "pce@ietf.org" Subject: [Pce] FW: New Version Notification for draft-ietf-pce-wson-routing-wavelength-10.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 22:22:21 -0000 SGkgSlAgYW5kIEp1aWVuLA0KDQpUaGVyZSBpcyBubyBjaGFuZ2UgdG8gdGhlIGNvbnRlbnQgdG8g dGhpcyB1cGRhdGUgKHYuMTApIG9mIFBDRVAgcmVxdWlyZW1lbnQuIEFzIGRpc2N1c3NlZCBhbmQg YWdyZWVkIGluIFZhbmNvdXZlciwgdGhpcyBkcmFmdCBpcyByZWFkeSBmb3IgV0cgTEMuIEknZCBh cHByZWNpYXRlIHlvdXIgcHJvY2VlZGluZyB0aGlzIGRyYWZ0IHRvIFdHIExDLiANCg0KQmVzdCBy ZWdhcmRzLA0KWW91bmcNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpT ZW50OiBNb25kYXksIERlY2VtYmVyIDIzLCAyMDEzIDQ6MTkgUE0NClRvOiBHcmVnIEJlcm5zdGVp bjsgT3NjYXIgR29uemFsZXogZGUgRGlvczsgVG9tb25vcmkgVGFrZWRhOyBMZWV5b3VuZzsgVGFr ZWhpcm8gVHN1cml0YW5pOyBKb25hcyBNYXJ0ZW5zc29uOyBPc2NhciBHb256YWxleiBkZSBEaW9z OyBUb21vbm9yaSBUYWtlZGE7IExlZXlvdW5nOyBKb25hcyBNYXJ0ZW5zc29uOyBUYWtlaGlybyBU c3VyaXRhbmk7IEdyZWcgQmVybnN0ZWluDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LWlldGYtcGNlLXdzb24tcm91dGluZy13YXZlbGVuZ3RoLTEwLnR4dA0KDQoN CkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLXBjZS13c29uLXJvdXRpbmctd2F2ZWxl bmd0aC0xMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWW91bmcgTGVl IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWlldGYt cGNlLXdzb24tcm91dGluZy13YXZlbGVuZ3RoDQpSZXZpc2lvbjoJMTANClRpdGxlOgkJUENFUCBS ZXF1aXJlbWVudHMgZm9yIFdTT04gUm91dGluZyBhbmQgV2F2ZWxlbmd0aCBBc3NpZ25tZW50DQpE b2N1bWVudCBkYXRlOgkyMDEzLTEyLTIzDQpHcm91cDoJCXBjZQ0KUGFnZXM6CQkxMw0KVVJMOiAg ICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYt cGNlLXdzb24tcm91dGluZy13YXZlbGVuZ3RoLTEwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcGNlLXdzb24tcm91dGluZy13 YXZlbGVuZ3RoLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtcGNlLXdzb24tcm91dGluZy13YXZlbGVuZ3RoLTEwDQpEaWZmOiAgICAgICAgICAg aHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1wY2Utd3Nvbi1yb3V0 aW5nLXdhdmVsZW5ndGgtMTANCg0KQWJzdHJhY3Q6DQogICBUaGlzIG1lbW8gcHJvdmlkZXMgYXBw bGljYXRpb24tc3BlY2lmaWMgcmVxdWlyZW1lbnRzIGZvciB0aGUgUGF0aA0KICAgQ29tcHV0YXRp b24gRWxlbWVudCBjb21tdW5pY2F0aW9uIFByb3RvY29sIChQQ0VQKSBmb3IgdGhlIHN1cHBvcnQg b2YNCiAgIFdhdmVsZW5ndGggU3dpdGNoZWQgT3B0aWNhbCBOZXR3b3JrcyAoV1NPTikuIExpZ2h0 cGF0aCBwcm92aXNpb25pbmcNCiAgIGluIFdTT05zIHJlcXVpcmVzIGEgcm91dGluZyBhbmQgd2F2 ZWxlbmd0aCBhc3NpZ25tZW50IChSV0EpIHByb2Nlc3MuDQogICBGcm9tIGEgcGF0aCBjb21wdXRh dGlvbiBwZXJzcGVjdGl2ZSwgd2F2ZWxlbmd0aCBhc3NpZ25tZW50IGlzIHRoZQ0KICAgcHJvY2Vz cyBvZiBkZXRlcm1pbmluZyB3aGljaCB3YXZlbGVuZ3RoIGNhbiBiZSB1c2VkIG9uIGVhY2ggaG9w IG9mIGENCiAgIHBhdGggYW5kIGZvcm1zIGFuIGFkZGl0aW9uYWwgcm91dGluZyBjb25zdHJhaW50 IHRvIG9wdGljYWwgbGlnaHQNCiAgIHBhdGggY29tcHV0YXRpb24uIFJlcXVpcmVtZW50cyBmb3Ig T3B0aWNhbCBpbXBhaXJtZW50cyB3aWxsIGJlDQogICBhZGRyZXNzZWQgaW4gYSBzZXBhcmF0ZSBk b2N1bWVudC4NCg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBu b3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9m IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K