From julien.meuric@orange.com Mon Feb 3 08:48:51 2014 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 39C131A0165 for ; Mon, 3 Feb 2014 08:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.535, 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 XntNbeRRJxB2 for ; Mon, 3 Feb 2014 08:48:50 -0800 (PST) Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1C21A0122 for ; Mon, 3 Feb 2014 08:48:50 -0800 (PST) Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 881AEDE4004 for ; Mon, 3 Feb 2014 17:50:33 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.orange.com (Postfix) with ESMTP id 7FBF2DE4002 for ; Mon, 3 Feb 2014 17:50:33 +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, 3 Feb 2014 17:48:48 +0100 Received: from [10.193.71.94] ([10.193.71.94]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Feb 2014 17:48:48 +0100 Message-ID: <52EFC86F.1080300@orange.com> Date: Mon, 03 Feb 2014 17:48:47 +0100 From: Julien Meuric Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "pce@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Feb 2014 16:48:48.0864 (UTC) FILETIME=[CF982E00:01CF20FF] Subject: [Pce] Building London Agenda X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Julien Meuric , 'JP Vasseur' , Daniel King List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 16:48:51 -0000 Hi all. The _preliminary_ agenda for IETF 89 is on line. PCE WG meeting is currently scheduled on Tuesday, March 4, at 9 AM. If you believe you could use a presentation slot during that meeting, please contact the chairs and secretary, including: - the topic or the I-D title, - the requested duration, - the expected presenter, - the reasons to ask for a face to face discussion, as opposed to using the mailing list. Thank you, JP & Julien From julien.meuric@orange.com Mon Feb 3 09:03:37 2014 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 304141A0123 for ; Mon, 3 Feb 2014 09:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.535, 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 hp0tu8cDjx5K for ; Mon, 3 Feb 2014 09:03:36 -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 4C1621A0122 for ; Mon, 3 Feb 2014 09:03:36 -0800 (PST) Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C89B5E30116 for ; Mon, 3 Feb 2014 18:08:06 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.orange.com (Postfix) with ESMTP id C201CE30115 for ; Mon, 3 Feb 2014 18:08:06 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Feb 2014 18:03:35 +0100 Received: from [10.193.71.94] ([10.193.71.94]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Feb 2014 18:03:35 +0100 Message-ID: <52EFCBE6.60309@orange.com> Date: Mon, 03 Feb 2014 18:03:34 +0100 From: Julien Meuric Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "pce@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Feb 2014 17:03:35.0272 (UTC) FILETIME=[DFEF4E80:01CF2101] Subject: [Pce] WG Last Call of draft-ietf-pce-wson-routing-wavelength-10 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, 03 Feb 2014 17:03:37 -0000 Hi all. Since many of you are going to dedicate some time to IETF matters over the upcoming days, here comes some homework. This message ignites a 2-week WG last call on draft-ietf-pce-wson-routing-wavelength-10. It will end on Monday, February 17, 11:59 PM (UTC-12). Thanks, JP & Julien From y-iizawa@cd.jp.nec.com Wed Feb 5 22:01:23 2014 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 7049E1A0034 for ; Wed, 5 Feb 2014 22:01:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.693 X-Spam-Level: X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-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 SrZ6cMKwNvjz for ; Wed, 5 Feb 2014 22:01:17 -0800 (PST) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by ietfa.amsl.com (Postfix) with ESMTP id 203651A0030 for ; Wed, 5 Feb 2014 22:01:17 -0800 (PST) Received: from mailgate3.nec.co.jp ([10.7.69.195]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id s1661FpI026323 for ; Thu, 6 Feb 2014 15:01:15 +0900 (JST) Received: from mailsv3.nec.co.jp (imss63.nec.co.jp [10.7.69.158]) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) with ESMTP id s1661FZ06415 for ; Thu, 6 Feb 2014 15:01:15 +0900 (JST) Received: from mail01b.kamome.nec.co.jp (mail01b.kamome.nec.co.jp [10.25.43.2]) by mailsv3.nec.co.jp (8.13.8/8.13.4) with ESMTP id s1661E0F029661 for ; Thu, 6 Feb 2014 15:01:15 +0900 (JST) Received: from bpxc99gp.gisp.nec.co.jp ([10.38.151.131] [10.38.151.131]) by mail02.kamome.nec.co.jp with ESMTP id BT-MMP-657458; Thu, 6 Feb 2014 15:00:59 +0900 Received: from BPXM02GP.gisp.nec.co.jp ([169.254.1.234]) by BPXC03GP.gisp.nec.co.jp ([10.38.151.131]) with mapi id 14.02.0328.011; Thu, 6 Feb 2014 15:00:59 +0900 From: Yohei Iizawa To: "pce@ietf.org" Thread-Topic: iPOP2014 Paper Submission Deadline Extended Thread-Index: Ac8jAJuIDk8srEZ+SEq/X/aZ7HJWfw== Date: Thu, 6 Feb 2014 06:00:59 +0000 Message-ID: <6D8CC8EB7FE4C444B73DF64E761A0DCC1D54F711@BPXM02GP.gisp.nec.co.jp> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.56.47.179] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Pce] iPOP2014 Paper Submission Deadline Extended 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, 06 Feb 2014 06:01:23 -0000 (Apologies if you received multiple copies of this message.) Dear PCE subscribers, The paper submission deadline of iPOP2014 has been extended to February 20t= h, 2014. Best Regards, =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Oh behalf of Kohei Shiomoto, Eiji Oki, iPOP2014 TPC Co-chairs http://www.pilab.jp/ipop2014/ Yohei Iizawa, iPOP2014 TPC Secretary --------------------------------------------------------------------- Call for Presentation 10th International Conference on IP + Optical Network (iPOP 2014) May 22-23, 2014 NTT R&D center Musashino, Tokyo, Japan http://www.pilab.jp/ipop2014/ The conference is intended to share among the industry and the academia, the knowledge, new findings, and experience on the state-of-the art of IP and optical networking technologies. It features technical sessions and planned exhibitions. The opportunity to participate is open to all. Important Dates: Submission deadline of one-page abstract: February 20, 2014=20 Notification of acceptance: March 24, 2014 Submission deadline of final presentation slides: April 11, 2014 The Technical Program Committee for iPOP 2014 is soliciting presentation=20 proposals for this conference. Protocol design, experiment, theory,=20 implementation, and operational experiences are solicited. The topics of the conference will include but not be limited to the followi= ng: - Photonic network for NxGN and NwGN - Multi-Layer Network (MLN)/Multi-Region Network (MRN) - Inter-area/inter-AS network - Software Defined Networking (SDN) - Software Defined Optics (SDO) and its network application - SDN network services and monetization=20 - Open Source Software (OSS) activities for SDN - Network virtualization=20 - Data center and WAN orchestration - Path Computation Element (PCE) and traffic engineering - GMPLS/ASON technologies - Application with high-bandwidth demand - L0-L3 Virtual Private Network (VPN) - MPLS and Ethernet networking for inter-data center connectivity for cloud computing - Carrier Ethernet and MPLS-TP for backhauling - Optical networking/switching for cloud services - Testbed, field trial If you wish to submit a topic for consideration, please send an Extended=20 Abstracts of 400 words and a maximum of 1 page, including figures and=20 diagrams, speaker's name, affiliation, and contact information=20 to the Technical Program Committee at ipop2014-CFP@pilab.jp. Please see http://www.pilab.jp/ipop2014/ for more details. ---------------------------------------------------------------------------= ---- From diego@tid.es Thu Feb 6 00:45:03 2014 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 EC9071A00AE for ; Thu, 6 Feb 2014 00:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 qLMvxCV5Efv3 for ; Thu, 6 Feb 2014 00:45:00 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 51B2D1A006A for ; Thu, 6 Feb 2014 00:44:59 -0800 (PST) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0N0K00BUAGAEB9@tid.hi.inet> for pce@ietf.org; Thu, 06 Feb 2014 09:44:56 +0100 (MET) Received: from dequeue_removeroute (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id E0.4F.03314.88B43F25; Thu, 06 Feb 2014 09:44:56 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0N0K00BXYGAWB9@tid.hi.inet> for pce@ietf.org; Thu, 06 Feb 2014 09:44:56 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.159]) by EX10-HTCAS7-MAD.hi.inet ([::1]) with mapi id 14.03.0158.001; Thu, 06 Feb 2014 09:44:40 +0100 Date: Thu, 06 Feb 2014 08:44:39 +0000 From: "Diego R. Lopez" In-reply-to: <07b801cf1534$bec46b60$3c4d4220$@olddog.co.uk> X-Originating-IP: [10.95.64.115] To: Farrel Adrian Message-id: <4698EB6C-9BEC-4E76-8291-FBCA51753950@tid.es> Content-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, es-ES Thread-topic: [Pce] Use of TCP AO and TLS in PCEP Thread-index: Ac8VNFeRvCG6i4qyTfiGqoE+7Nwh2wN2xWYA X-AuditID: 0a5f4068-b7fe58e000000cf2-d8-52f34b8886e2 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42Lhinfg0u3w/hxkcOemlUXT/RvsDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKmLxiPXPBBK+KPTOnszcwzvHoYuTkkBAwkZj3fDoLhC0mceHe erYuRi4OIYEDjBJLX2xlBUkICXxllGg8JQCRmMkocf7eVLAOFgFViZNz9jKD2GxA9qPm3+wg trCAgcSM9c/YQGxOAWuJdb//MUNsUJD4c+4xUC8Hh4iAusTT3WogYWYBJ4krd36BlfAKWEqc 6dzJCBE3kzi5eh8rRFxQ4sfke2CtzECtU6bkQpSISzS33mSBsBUlpi1qAGtlFJCVeDd/Plir iIChxPG2SywQtpHE+57PTBDXCEgs2XMe6jJRiZeP/0G9ayVxdM96xgmMErOQXDELyRWzEK6Y heSKWUiuWMDIuopRrDipKDM9oyQ3MTMn3cBQLyNTLzMvtWQTIyTiMnYwLt+pcohRgINRiYd3 w/pPQUKsiWXFlbmHGCU4mJVEeLeafw4S4k1JrKxKLcqPLyrNSS0+xMjEwSnVwGjWwv/Y+P2c e55rnKuk6sTmPGsqPZjBVnLy90JZrbn1TBZOQoe9+Rn1Nk37n/Pn/9bEg3ffybovyTXqNTud JaIePbvGb1epmqJD+pV5beppPDWXzQtE9fv+Zf97O4v3o3Rz6f1Dv8rmeh+WWrqgpHTfPV5Z ow0bHBQ+T7jG08ez8oGdjMu9NiWW4oxEQy3mouJEACdNUtuWAgAA References: <07b801cf1534$bec46b60$3c4d4220$@olddog.co.uk> Cc: "pce@ietf.org" , "touch@ISI.EDU" Subject: Re: [Pce] Use of TCP AO and TLS in PCEP 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, 06 Feb 2014 08:45:04 -0000 SGkgQWRyaWFuLCBKb2UsDQoNClRoYW5rcyBmb3IgdGhlIHJldmlldy4gSXQgd2lsbCByZWFsbHkg aGVscCBpbiBwdXR0aW5nIHRoZSBkcmFmdCBpbiBhIGJldHRlciBzaGFwZS4gV2UgYXJlIHByZXBh cmluZyBhIG5ldyB2ZXJzaW9uIGFuZCB0aGUgcmVwbGllcyBiZWxvdyB3aWxsIGJlIHJlZmxlY3Rl ZCB0aGVyZS4NCg0KT24gMTkgSmFuIDIwMTQsIGF0IDE3OjM3ICwgQWRyaWFuIEZhcnJlbCA8YWRy aWFuQG9sZGRvZy5jby51az4gd3JvdGU6DQo+Pj4gVGhlIFBDRSBXRyBoYXMgaHR0cDovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1sb3Blei1wY2UtcGNlcHMvIHdoaWNoDQo+Pj4gaXMg YWJvdXQgcnVubmluZyBQQ0VQICh0aGUgUENFIHByb3RvY29sLCBhIFRDUC11c2luZyBwcm90b2Nv bCkgdXNpbmcgVExTIGFuZA0KPj4+IFRDUC1BTy4NCj4+Pg0KPj4+IFdlIGNvdWxkIGxvb2sgYXQg dGhlIHdvcmsgZG9uZSBpbiBLQVJQIChSRkMgNjk1MikgYnV0IHRoYXQgaXMgaGFyZGx5DQo+IGNv bmNsdXNpdmUuDQo+Pg0KPj4gVGhhdCB3b3JrIHdhcyBkcml2ZW4gbGFyZ2VseSBieSB0aGF0IFdH J3MgY29uY2VybiB3aXRoIHRoZSBsYWNrIG9mDQo+PiBhdmFpbGFiaWxpdHkgb2YgYSBUQ1AtQU8g aW1wbGVtZW50YXRpb24gaW4gZW5kLXN5c3RlbSBPU2VzIChMaW51eCBvcg0KPj4gRnJlZUJTRCku IFRoZXkgc3BlbnQgYW4gaW5vcmRpbmF0ZSBhbW91bnQgb2YgdGltZSBjb21wbGFpbmluZyBhYm91 dA0KPj4gdGhhdCwgdGltZSB0aGF0IGNvdWxkIGVhc2lseSBoYXZlIGJlZW4gdXNlZCB0byBpbXBs ZW1lbnQgdGhlIHByb3RvY29sDQo+PiByYXRoZXIgdGhhbiB3b3JyeWluZyBhYm91dCBhbHRlcm5h dGUgaW50ZXJpbSBzb2x1dGlvbnMuDQoNCkluIGZhY3QsIGEgZmlyc3Qgc2V0IG9mIGlkZWFzIG9u IHRoaXMgZHJhZnQgd2FzIGRpc2N1c3NlZCBhdCB0aGUgS0FSUCBtZWV0aW5nIGluIEJlcmxpbi4g VGhlIHJlZmVyZW5jZSB0byBUQ1AtQU8gaXMgZGVyaXZlZCBmcm9tIHRoYXQgZGlzY3Vzc2lvbiwg YXMgdGhlcmUgc2VlbWVkIHRvIGJlIGEgZ2VuZXJhbCBjb25zZW5zdXMgYW1vbmcgdGhlIGdyb3Vw IHRoYXQgVENQLUFPIHNob3VsZCBiZSBjb25zaWRlcmVkLiBBZnRlciB0aGlzIGlucHV0IGZyb20g eW91IGFuZCBzb21lIG90aGVyIGRpc2N1c3Npb25zIEkgYW5kIHRoZSBvdGhlciBjby1hdXRob3Jz IGhhdmUgaGFkIGFyb3VuZCwgd2Ugd2lsbCBmb2N1cyB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgVExT IGFzcGVjdHMsIGFuZCBtZW50aW9uIFRDUCBwcm90ZWN0aW9uIGluIGdlbmVyYWwgYW5kIFRDUC1B TyBpbiBwYXJ0aWN1bGFyIGluIHRoZSAiU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMiIHNlY3Rpb24u IE5vIGludGVyYWN0aW9uIGJldHdlZW4gVExTIGFuZCBUQ1AtQU8gd2lsbCBiZSBtZW50aW9uZWQu DQoNCj4+PiAyLjEuICBUQ1AgcG9ydHMNCj4+Pg0KPj4+ICAgVGhlIGRlZmF1bHQgZGVzdGluYXRp b24gcG9ydCBudW1iZXIgZm9yIFBDRVBTIGlzIFRDUC9YWFhYLg0KPj4+DQo+Pj4gICBOT1RFOiBU aGlzIHBvcnQgaGFzIHRvIGJlIGFncmVlZCBhbmQgcmVnaXN0ZXJlZCBhcyBQQ0VQUyB3aXRoIElB TkEuDQo+Pg0KPj4gUENFUCBhbHJlYWR5IGlzIGFzc2lnbmVkIHRvIHBvcnQgNDE4OS4gUkZDNTQ0 MCBhbHJlYWR5IHBlcm1pdHMgUENFUA0KPj4gY29ubmVjdGlvbnMgdG8gdXNlIGVpdGhlciBUQ1Ag TUQ1IG9yIFRDUC1BTywgYnV0IGF0IHRoZSB0aW1lIG9mIHRoYXQNCj4+IGRvY3VtZW50IHRoZXJl IHdhcyBubyBUQ1AtQU8gdG8gcmVmZXJlbmNlLg0KPj4NCj4+IEFzIGEgcmVzdWx0IGl0IHNob3Vs ZCBiZSB0cml2aWFsIGZvciBhIFBDRVAgc2VydmVyIHRvIGRpZmZlcmVudGlhdGUgcGNlcA0KPj4g dnMuIHBjZXBzIGNvbm5lY3Rpb25zOg0KPj4NCj4+ICAgICAgTUQ1IG11c3QgYmUgcGNlcCwgYW5k IGFscmVhZHkgZG9uJ3QgdXNlIFRMUw0KPj4NCj4+ICAgICAgVENQLUFPIG11c3QgYmUgcGNlcHMs IGFuZCB0aHVzIG11c3QgaW5jbHVkZSBUTFMNCj4+DQo+PiAgICAgIGNvbm5lY3Rpb25zIHVzaW5n IG5laXRoZXIgTUQ1IG5vciBUQ1AtQU8gbXVzdCBiZSBwY2VwcywNCj4+ICAgICAgYW5kIHRodXMg bXVzdCBpbmNsdWRlIFRMUw0KPj4NCj4+IEkgZG9uJ3Qgc2VlIGEgcmF0aW9uYWxlIGZvciBuZWVk aW5nIGEgc2VwYXJhdGUgcG9ydC4NCg0KVGhlIHJhdGlvbmFsZSBpcyB0aGUgY29tbW9uIHByYWN0 aWNlIGRlcml2ZWQgZnJvbSB0aGUgVExTIGxheWVyZWQgYXBwcm9hY2gsIHNvIGEgY2xpZW50IGtu b3dzIGhvdyBhbmQgd2hlbiByZXF1aXJlIHRoZSBzZXJ2ZXIgdG8gc3RhcnQgYSBUTFMgY29ubmVj dGlvbiwgYW5kIHRoZSBzZXJ2ZXIga25vd3MgaW4gYWR2YW5jZSB3aGF0IHRoZSBjbGllbnQgaXMg cmVxdWlyaW5nIGFuZCBtYXRjaCBpdCBhZ2FpbnN0IGl0cyBwb2xpY3kuIFRoZSB1c2Ugb2YgVENQ IHByb3RlY3Rpb24gbXVzdCBiZSBvcnRob2dvbmFsIHRvIHRoZSB1c2Ugb2YgVExTLCBzbyBpdCBj YW4gbm90IGJlIHVzZWQgZm9yIHRoZSBzZXJ2ZXIgbWFraW5nIGEgZ3Vlc3Mgb2YgdGhlIHByb3Rv Y29sIHNlY3VyaXR5IGVuY2Fwc3VsYXRpb24uDQoNCkVpdGhlciB3ZSBoYXZlIGEgcHJvdG9jb2wt c3BlY2lmaWMgbWVjaGFuaXNtIChhLWxhLVNUQVJUVExTKSBvciB3ZSB1c2UgYSBzcGVjaWZpYyBw b3J0LiBUaGUgbGF0dGVyIGltcGxpZXMgbm8gY2hhbmdlcyBhdCBhbGwgdG8gdGhlIHByb3RvY29s LCB3aGljaCBpcyBpbmNsdWRlZCBhcyBvbmUgb2YgdGhlIHJlcXVpcmVtZW50cyBmb3Igc2VjdXJl IFBDRVAgZXhjaGFuZ2VzLiBJZiBhZGRpbmcgc3VjaCBhIG1lY2hhbmlzbSB3b3VsZCBiZSBhY2Nl cHRhYmxlLCB3ZSBjb3VsZCBnbyBmb3IgdGhlIGZpcnN0IG9wdGlvbi4gVGhpcyBpcyBzb21ldGhp bmcgdGhhdCBzaG91bGQgYmUgZGVjaWRlZCBieSB0aGUgV0cuIEknbGwgdXBkYXRlIHRoZSBkcmFm dCBub3RpbmcgdGhpcyBwb2ludCBhbmQgaGlnaGxpZ2h0IGl0IHRvIHRoZSBXRyBmb3IgZGlzY3Vz c2lvbi4NCg0KPj4NCj4+PiAyLjIuICBUTFMgQ29ubmVjdGlvbiBFc3RhYmxpc2htZW50DQo+PiAu Li4NCj4+PiAgIE5PVEU6IFdlIGhhdmUgdG8gY29uc2lkZXIgcG90ZW50aWFsIGludGVyYWN0aW9u cyBiZXR3ZWVuIFRMUyByZS0NCj4+PiAgIG5lZ290aWF0aW9uIGFuZCBUQ1AtQU8gTUtUDQo+Pg0K Pj4gSSBkb24ndCB1bmRlcnN0YW5kIHRoaXMgc3RhdGVtZW50LiBUTFMgaGFzIG5vdGhpbmcgdG8g ZG8gd2l0aCBUQ1AtQU87DQo+PiBUQ1AtQU8ncyBwcm90ZWN0aW9uIGRvZXMgbm90IG1vZGlmeSB0 aGUgYXBwbGljYXRpb24gKFRMUykgdmlldyBvZiBUQ1AgYXQNCj4+IGFsbCAoZXZlbiBpZiBrZXlz IGNoYW5nZSBkdXJpbmcgYSBjb25uZWN0aW9uKS4NCj4+DQo+PiBUaGVyZSBzaG91bGQgYmUgbm8g aW50ZXJhY3Rpb24uDQoNCkdvb2QgcG9pbnQuIEFzIHNhaWQgYWJvdmUsIHRoaXMgd2lsbCBiZSBt b3ZlZCB0byB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiBhbmQgdGhlIFRDUC1B TyBkZWVtZWQgb3V0LW9mLXNjb3BlLCBiZWluZyBpbmRlcGVuZGVudCBvZiB0aGUgVExTIHVzYWdl Lg0KDQoNCj4+DQo+Pj4gMi4zLiAgVENQLUFPIEFwcGxpY2F0aW9uDQo+Pj4NCj4+PiAgIFBDRVBT IGltcGxlbWVudGF0aW9ucyBNQVkgaW4gYWRkaXRpb24gYXBwbHkgdGhlIG1lY2hhbmlzbXMgZGVz Y3JpYmVkDQo+Pj4gICBieSB0aGUgVENQIEF1dGhlbnRpY2F0aW9uIE9wdGlvbiAoVENQLUFPLCBk ZXNjcmliZWQgaW4gW1JGQzU5MjVdIHRvDQo+Pj4gICBwcm92aWRlIGFuIGFkZGl0aW9uYWwgbGV2 ZWwgb2YgcHJvdGVjdGlvbiB3aXRoIHJlc3BlY3QgdG8gYXR0YWNrcw0KPj4+ICAgc3BlY2lmaWNh bGx5IGFkZHJlc3NlZCB0byBmb3JnaW5nIHRoZSBUQ1AgY29ubmVjdGlvbiB1bmRlcnBpbm5pbmcN Cj4+PiAgIFRMUy4gIFRDUC1BTyBpcyBmdWxseSBjb21wYXRpYmxlIHdpdGggYW5kIGRlZW1lZCBh cyBjb21wbGVtZW50YXJ5IHRvDQo+Pj4gICBUTFMsIHNvIGl0cyB1c2FnZSBpcyB0byBiZSBjb25z aWRlcmVkIGFzIGEgc2VjdXJpdHkgZW5oYW5jZW1lbnQNCj4+PiAgIHdoZW5ldmVyIGFueSBvZiB0 aGUgUENFUFMgcGVlcnMgcmVxdWlyZSBpdC4nDQo+Pg0KPj4gSSBkb24ndCB1bmRlcnN0YW5kIHRo ZSByYXRpb25hbCBmb3IgdGhlIHByb3RlY3Rpb24gZGVmaW5lZCBieSBQQ0VQUyB2cyBQQ0VQLg0K Pj4NCj4+IFBDRVAgPSAqcmVxdWlyZXMqIFRDUCBwcm90ZWN0aW9uIChlaXRoZXIgVENQIE1ENSBv ciBJUHNlYyksIGJ1dCBhbGxvd3MNCj4+IHByaXZhY3kgdG8gYmUgb3B0aW9uYWwgKGUuZy4sIHdo ZW4gdXNpbmcgVENQIE1ENSk7IHJlZ2FyZGxlc3Mgb2YgdGhlDQo+PiBmb3J3YXJkIHBvaW50ZXIg dG8gVENQLUFPLCB0aGVyZSB3YXMgbm8gc3BlY2lmaWNhdGlvbiB0byBjaXRlLCB0aHVzIGl0DQo+ PiBjYW5ub3QgYmUgcmVxdWlyZWQuDQo+Pg0KPj4gUENFUFMgPSAqcmVxdWlyZXMqIHByaXZhY3kg YnkgVExTLCBidXQgbGVhdmVzIFRDUCBwcm90ZWN0aW9uIGFzIG9wdGlvbmFsLg0KPj4NCj4+IFRo aXMgbWFrZXMgbm8gc2Vuc2UgdG8gbWUuIElNTywgVENQIHByb3RlY3Rpb24gKm11c3QqIGJlIG1h bmRhdG9yeSwgb3INCj4+IFJGQzU0NDAgbmVlZHMgdG8gYmUgdXBkYXRlZCBiZWZvcmUgUENFUFMg c2hvdWxkIHByb2NlZWQuDQo+Pg0KPj4+ICAgSW1wbGVtZW50YXRpb25zIGluY2x1ZGluZyBzdXBw b3J0IGZvciBUQ1AtQU8gTVVTVCBwcm92aWRlIG1lY2hhbmlzbXMNCj4+PiAgIHRvIGNvbmZpZ3Vy ZSB0aGUgcmVxdWlyZW1lbnRzIHRvIHVzZSBUQ1AtQU8sIGFzIHdlbGwgYXMgdGhlDQo+Pj4gICBh c3NvY2lhdGlvbiBvZiBhIFRDUC1BTyBNYXN0ZXIgS2V5IFR1cGxlIChNS1QpIHdpdGggYSBwYXJ0 aWN1bGFyDQo+Pj4gICBwZWVyLg0KPj4NCj4+IFRoZSBhYm92ZSBpcyBhIHN0cmFuZ2Ugd2F5IHRv IHNheSAiaW1wbGVtZW50YXRpb25zIHN1cHBvcnRpbmcgVENQLUFPDQo+PiBNVVNUIHN1cHBvcnQg VENQLUFPIiwgd2hpY2ggaXMgYSB0YXV0b2xvZ3kgdGhhdCBuZWVkIG5vdCBiZSBzdGF0ZWQuDQo+ Pg0KPj4+IFdoZXRoZXIgdGhlc2UgbWVjaGFuaXNtcyBhcmUgcHJvdmlkZWQgYnkgdGhlIGFkbWlu aXN0cmF0aXZlDQo+Pj4gICBpbnRlcmZhY2Ugb3IgcmVseSBvbiB0aGUgVExTIGhhbmRzaGFrZSBh Y2NvcmRpbmcgdG8gcHJvY2VkdXJlcw0KPj4+ICAgc2ltaWxhciB0byB0aG9zZSBkZXNjcmliZWQg aW4gW1JGQzUyMTZdIGFuZCBbUkZDNTcwNV0gaXMgb3V0c2lkZSB0aGUNCj4+PiAgIHNjb3BlIG9m IHRoaXMgZG9jdW1lbnQuDQo+Pg0KPj4gVExTIGNhbm5vdCBiZSB1c2VkIHRvIHByb3RlY3QgVENQ LUFPIHNlc3Npb25zLiBGb3IgYSBnaXZlbiBjb25uZWN0aW9uLA0KPj4gVENQLUFPIG11c3QgYmUg c3RhcnRlZCBhdCBjb25uZWN0aW9uIGVzdGFibGlzaG1lbnQsIHdoaWNoIGlzIHByaW9yIHRvDQo+ PiBUTFMgbmVnb3RpYXRpb24uDQoNCkFncmVlZC4gVGhlIGludGVydHdpbmluZyBvZiBUTFMgYW5k IFRDUCBwcm90ZWN0aW9uIHdpbGwgYmUgZWxpbWluYXRlZC4NCg0KPj4NCj4+PiA0LiAgQmFja3dh cmQgQ29tcGF0aWJpbGl0eQ0KPj4+DQo+Pj4gICBTaW5jZSB0aGUgcHJvY2VkdXJlIGRlc2NyaWJl ZCBpbiB0aGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIHNlY3VyaXR5DQo+Pj4gICBjb250YWluZXIg Zm9yIHRoZSB0cmFuc3BvcnQgb2YgUENFUCByZXF1ZXN0cyBhbmQgcmVwbGllcyBjYXJyaWVkIG9u IGENCj4+PiAgIG5ld2x5IGFsbG9jYXRlZCBUQ1AgcG9ydCB0aGVyZSB3aWxsIGJlIG5vIGltcGFj dCBvbiB0aGUgYmFzZSBQQ0VQDQo+Pj4gICBhbmQvb3IgYW55IGZ1cnRoZXIgZXh0ZW5zaW9ucy4N Cj4+DQo+PiBTZWUgbXkgY29tbWVudCBhYm92ZTsgSSBhZ3JlZSwgYnV0IG5vdCBiZWNhdXNlIGEg bmV3IHBvcnQgaXMgbmVlZGVkLg0KDQpBcyBzYWlkIGFib3ZlLCBub3QgdXNpbmcgYSBkaWZmZXJl bnQgcG9ydCB3b3VsZCB0cmFuc2xhdGUgaW4gcmVxdWlyaW5nIGFuIGFkZGl0aW9uYWwgcHJvdG9j b2wgZWxlbWVudCwgc28gY2xpZW50cyBjb3VsZCBleHByZXNzIHRoZWlyIHJlcXVlc3QgdG8gc3Rh cnQgYSBUTFMgY29ubmVjdGlvbi4gR29pbmcgZm9yIGFuYWx5emluZyBhIGNvbWJpbmF0aW9uIG9m IHRoZSBUQ1AgcHJvdGVjdGlvbiBtZWNoYW5pc21zIHdvdWxkIGltcGx5IHRoZSBpbnRlcnR3aW5p bmcgd2UgYXJlIHRyeWluZyB0byBhdm9pZCwgdGhhdCB0cmFuc2xhdGVzIGluIHRoZSBpbmNvbnNp c3RlbmNpZXMgeW91IG5vdGVkIGFib3ZlLg0KDQpCZSBnb29kZSwNCg0KLS0NCiJFc3RhIHZleiBu byBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVybm8iDQoNCkRyIERpZWdvIFIuIExvcGV6DQpUZWxl Zm9uaWNhIEkrRA0KaHR0cDovL3Blb3BsZS50aWQuZXMvZGllZ28ubG9wZXovDQoNCmUtbWFpbDog ZGllZ29AdGlkLmVzDQpUZWw6ICAgICszNCA5MTMgMTI5IDA0MQ0KTW9iaWxlOiArMzQgNjgyIDA1 MSAwOTENCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRXN0ZSBtZW5zYWplIHNlIGRpcmlnZSBl eGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpby4gUHVlZGUgY29uc3VsdGFyIG51ZXN0cmEg cG9sw610aWNhIGRlIGVudsOtbyB5IHJlY2VwY2nDs24gZGUgY29ycmVvIGVsZWN0csOzbmljbyBl biBlbCBlbmxhY2Ugc2l0dWFkbyBtw6FzIGFiYWpvLg0KVGhpcyBtZXNzYWdlIGlzIGludGVuZGVk IGV4Y2x1c2l2ZWx5IGZvciBpdHMgYWRkcmVzc2VlLiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUg ZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0Og0KaHR0cDovL3d3dy50 aWQuZXMvRVMvUEFHSU5BUy9kaXNjbGFpbWVyLmFzcHgNCg== From internet-drafts@ietf.org Thu Feb 6 01:23:16 2014 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 800131A036C; Thu, 6 Feb 2014 01:23:16 -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 IxW_BcGg7GM8; Thu, 6 Feb 2014 01:23:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5651A0083; Thu, 6 Feb 2014 01:23:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140206092308.32112.92854.idtracker@ietfa.amsl.com> Date: Thu, 06 Feb 2014 01:23:08 -0800 Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-pcep-mib-07.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: Thu, 06 Feb 2014 09:23:17 -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 Working Group of the IETF. Title : Path Computation Element Protocol (PCEP) Management Information Base Authors : A S Kiran Koushik Emile Stephan Quintin Zhao Daniel King Jonathan Hardwick Filename : draft-ietf-pce-pcep-mib-07.txt Pages : 48 Date : 2014-02-06 Abstract: This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Path Computation Element communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-pcep-mib-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-mib-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 Jonathan.Hardwick@metaswitch.com Thu Feb 6 01:42:03 2014 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 634381A00A9 for ; Thu, 6 Feb 2014 01:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 Foj0ghMueeS2 for ; Thu, 6 Feb 2014 01:42:01 -0800 (PST) Received: from ENFICSETS1.metaswitch.com (enficsets1.metaswitch.com [192.91.191.38]) by ietfa.amsl.com (Postfix) with ESMTP id 065961A036B for ; Thu, 6 Feb 2014 01:41:40 -0800 (PST) Received: from ENFICSCAS1.datcon.co.uk (172.18.4.13) by ENFICSETS1.metaswitch.com (172.18.4.18) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 6 Feb 2014 09:41:32 +0000 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFICSCAS1.datcon.co.uk ([fe80::3d12:12a9:26af:c7%11]) with mapi id 14.03.0174.001; Thu, 6 Feb 2014 09:41:37 +0000 From: Jonathan Hardwick To: 'Juergen Schoenwaelder' , "Julien Meuric" , "JP Vasseur (jvasseur)" Thread-Topic: [Pce] I-D Action: draft-ietf-pce-pcep-mib-07.txt Thread-Index: AQHPIx0USiPbZeDN1kGn/AIecYXNVZqn9iFA Date: Thu, 6 Feb 2014 09:41:38 +0000 Message-ID: <09CE6C3BE5E1EA40B987BF5F25D8DDBAE133D4F6@ENFICSMBX1.datcon.co.uk> References: <20140206092308.32112.92854.idtracker@ietfa.amsl.com> In-Reply-To: <20140206092308.32112.92854.idtracker@ietfa.amsl.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.72.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pce@ietf.org" , Quintin Zhao Subject: Re: [Pce] I-D Action: draft-ietf-pce-pcep-mib-07.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: Thu, 06 Feb 2014 09:42:03 -0000 Juergen, many thanks for your input on the PCEP MIB draft. Here is a new ve= rsion which should address all of your comments. Please let me know if you = have any further comments. PCE WG chairs: we believe that this document is now ready for WG last call. Best regards PCEP MIB authors -----Original Message----- From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.o= rg Sent: 06 February 2014 09:23 To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-pcep-mib-07.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 Working Group of= the IETF. Title : Path Computation Element Protocol (PCEP) Manageme= nt Information Base Authors : A S Kiran Koushik Emile Stephan Quintin Zhao Daniel King Jonathan Hardwick Filename : draft-ietf-pce-pcep-mib-07.txt Pages : 48 Date : 2014-02-06 Abstract: This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Path Computation Element communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-pcep-mib-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-pcep-mib-07 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 j.schoenwaelder@jacobs-university.de Thu Feb 6 02:37:36 2014 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 AB8C61A0358 for ; Thu, 6 Feb 2014 02:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.785 X-Spam-Level: X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] 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 DGPsvjqwv6RU for ; Thu, 6 Feb 2014 02:37:32 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 19AF51A00C2 for ; Thu, 6 Feb 2014 02:37:32 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8A26D20123; Thu, 6 Feb 2014 11:37:30 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zBwh1_29QA3k; Thu, 6 Feb 2014 11:37:30 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 919D3200DC; Thu, 6 Feb 2014 11:37:29 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A16D92B12A9B; Thu, 6 Feb 2014 11:37:27 +0100 (CET) Date: Thu, 6 Feb 2014 11:37:26 +0100 From: Juergen Schoenwaelder To: Jonathan Hardwick Message-ID: <20140206103726.GA49052@elstar.local> References: <20140206092308.32112.92854.idtracker@ietfa.amsl.com> <09CE6C3BE5E1EA40B987BF5F25D8DDBAE133D4F6@ENFICSMBX1.datcon.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09CE6C3BE5E1EA40B987BF5F25D8DDBAE133D4F6@ENFICSMBX1.datcon.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Thu, 06 Feb 2014 02:54:03 -0800 Cc: "pce@ietf.org" , Quintin Zhao Subject: Re: [Pce] I-D Action: draft-ietf-pce-pcep-mib-07.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 10:37:36 -0000 Hi, thanks for the update. All my comments have been addressed. I am happy with draft-ietf-pce-pcep-mib-07.txt. /js On Thu, Feb 06, 2014 at 09:41:38AM +0000, Jonathan Hardwick wrote: > Juergen, many thanks for your input on the PCEP MIB draft. Here is a new version which should address all of your comments. Please let me know if you have any further comments. > > PCE WG chairs: we believe that this document is now ready for WG last call. > > Best regards > PCEP MIB authors > > -----Original Message----- > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: 06 February 2014 09:23 > To: i-d-announce@ietf.org > Cc: pce@ietf.org > Subject: [Pce] I-D Action: draft-ietf-pce-pcep-mib-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 Working Group of the IETF. > > Title : Path Computation Element Protocol (PCEP) Management Information Base > Authors : A S Kiran Koushik > Emile Stephan > Quintin Zhao > Daniel King > Jonathan Hardwick > Filename : draft-ietf-pce-pcep-mib-07.txt > Pages : 48 > Date : 2014-02-06 > > Abstract: > This memo defines a portion of the Management Information Base for > use with network management protocols in the Internet community. In > particular, it describes managed objects for modeling of Path > Computation Element communication Protocol (PCEP) for communications > between a Path Computation Client (PCC) and a Path Computation > Element (PCE), or between two PCEs. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-mib/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-pce-pcep-mib-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-mib-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/ > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From internet-drafts@ietf.org Thu Feb 6 03:22:22 2014 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 8F2301A0398; Thu, 6 Feb 2014 03:22:22 -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 KxpRw5bouI5c; Thu, 6 Feb 2014 03:22:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 136FF1A037C; Thu, 6 Feb 2014 03:22:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140206112220.911.91885.idtracker@ietfa.amsl.com> Date: Thu, 06 Feb 2014 03:22:20 -0800 Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-questions-02.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: Thu, 06 Feb 2014 11:22:22 -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 Working Group of the IETF. Title : Unanswered Questions in the Path Computation Element Architecture Authors : Adrian Farrel Daniel King Filename : draft-ietf-pce-questions-02.txt Pages : 25 Date : 2014-02-06 Abstract: The Path Computation Element (PCE) architecture is set out in RFC 4655. The architecture is extended for multi-layer networking with the introduction of the Virtual Network Topology Manager in RFC 5623, and generalized to Hierarchical PCE in RFC 6805. These three architectural views of PCE deliberately leave some key questions unanswered especially with respect to the interactions between architectural components. This document draws out those questions and discusses them in an architectural context with reference to other architectural components, existing protocols, and recent IETF work efforts. This document does not update the architecture documents and does not define how protocols or components must be used. It does, however, suggest how the architectural components might be combined to provide advanced PCE function. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-questions/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-questions-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-questions-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 adrian@olddog.co.uk Thu Feb 6 03:30:30 2014 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 BEEE71A00E6 for ; Thu, 6 Feb 2014 03:30:30 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 lwRjSQLUILS5 for ; Thu, 6 Feb 2014 03:30:28 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2FA1A00E3 for ; Thu, 6 Feb 2014 03:30:28 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s16BUP9j024120 for ; Thu, 6 Feb 2014 11:30:25 GMT Received: from 950129200 (idanet5.ida.ing.tu-bs.de [134.169.115.102]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s16BUJob024071 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 6 Feb 2014 11:30:24 GMT From: "Adrian Farrel" To: References: <20140206112220.911.91885.idtracker@ietfa.amsl.com> In-Reply-To: <20140206112220.911.91885.idtracker@ietfa.amsl.com> Date: Thu, 6 Feb 2014 11:29:50 -0000 Message-ID: <013e01cf232e$d24a0d90$76de28b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNBTAKt13E+qb+7zl793QfaTCZ0wZfDxOHQ Content-Language: en-gb Subject: Re: [Pce] I-D Action: draft-ietf-pce-questions-02.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 11:30:30 -0000 Hi, We cleaned up a couple of typos. No other questions for immediate answer having been raised, the authors think this work is complete and suggest that it is time to last call it and requst publication. Thanks, Adrian > -----Original Message----- > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: 06 February 2014 11:22 > To: i-d-announce@ietf.org > Cc: pce@ietf.org > Subject: [Pce] I-D Action: draft-ietf-pce-questions-02.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 Working Group of the > IETF. > > Title : Unanswered Questions in the Path Computation Element > Architecture > Authors : Adrian Farrel > Daniel King > Filename : draft-ietf-pce-questions-02.txt > Pages : 25 > Date : 2014-02-06 > > Abstract: > The Path Computation Element (PCE) architecture is set out in RFC > 4655. The architecture is extended for multi-layer networking with > the introduction of the Virtual Network Topology Manager in RFC > 5623, and generalized to Hierarchical PCE in RFC 6805. > > These three architectural views of PCE deliberately leave some key > questions unanswered especially with respect to the interactions > between architectural components. This document draws out those > questions and discusses them in an architectural context with > reference to other architectural components, existing protocols, and > recent IETF work efforts. > > This document does not update the architecture documents and does not > define how protocols or components must be used. It does, however, > suggest how the architectural components might be combined to provide > advanced PCE function. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-pce-questions/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-pce-questions-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-questions-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/ > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From dhruv.ietf@gmail.com Thu Feb 6 04:21:55 2014 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 1F3551A03C3 for ; Thu, 6 Feb 2014 04:21:55 -0800 (PST) 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, 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 LvD8zQhxpY9E for ; Thu, 6 Feb 2014 04:21:52 -0800 (PST) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 51DFA1A03B7 for ; Thu, 6 Feb 2014 04:21:52 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id to1so592325ieb.0 for ; Thu, 06 Feb 2014 04:21:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=EXJLo9Jnkcm3c7mdOVR8BgHL7zygwbSxOX0oXgHzjqk=; b=lpaTvCHjJI+Bo9e7eH0FbViw2zbr8C4oWQ0RfUOTT9DHJbM+KNQNHzeq8pWsZ8P4yS EDYoWHxJeOiosgyooYF5pMkg9JKMxQMHXii2SZHtZXolhtdA/vx7s7Jui8DWy1mjE8T6 Q8kb0hylMo44/OlKMhLB5z2LRf1JmBbaEP5vTTHcyNxvzfwd+mv5MCqbykzVol5f/SsX EzAffI5Xrah5ut4nXq6aO4UySsVGjPFl7aZ57x3ON8iRjrkBOBFnRGUhqJc6RAZoES2j +i3JDlu9LQucKgzmB82KHsYpAEpGPKdhbOjvMWbsliYl0Mx2ySoXrRlOeFst/61QDkTn WSJQ== MIME-Version: 1.0 X-Received: by 10.50.176.137 with SMTP id ci9mr32761801igc.31.1391689311179; Thu, 06 Feb 2014 04:21:51 -0800 (PST) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.160.231 with HTTP; Thu, 6 Feb 2014 04:21:50 -0800 (PST) In-Reply-To: <013e01cf232e$d24a0d90$76de28b0$@olddog.co.uk> References: <20140206112220.911.91885.idtracker@ietfa.amsl.com> <013e01cf232e$d24a0d90$76de28b0$@olddog.co.uk> Date: Thu, 6 Feb 2014 17:51:50 +0530 X-Google-Sender-Auth: zqCFCUTRoHKV5K9AFywhwRw0f7A Message-ID: From: Dhruv Dhody To: Farrel Adrian Content-Type: multipart/alternative; boundary=089e0111e0da07ddae04f1bbebca Cc: "pce@ietf.org" Subject: Re: [Pce] I-D Action: draft-ietf-pce-questions-02.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: Thu, 06 Feb 2014 12:21:55 -0000 --089e0111e0da07ddae04f1bbebca Content-Type: text/plain; charset=ISO-8859-1 Hi Adrian, There are a few comments that i made during the WG adoption call. [http://www.ietf.org/mail-archive/web/pce/current/msg03168.html]. Most of them have been handled in -01 version. I have listed some that i would like your opinion on. * Sec 3. How Is Topology Information Gathered? Another issue faced when using IGP to fed TED is the area-scope issue. Since IGP-TE flooding scope is per area, an multi-area or AS-scope PCE must have an IGP peer for all the areas. Also I think we can augment this section to include 'How PCE learn about Boundary Nodes?'. * Sec 5. How Do I Select Between PCEs? Along with capability, you can also mention the PCE's preference for each computation scope as carried in the PATH-SCOPE subtlv. * Sec 13. What are Sticky Resources? OLD: This can result in LSP setup failures are there is contention for resources. NEW: This can result in LSP setup failures if there is contention for resources. * Sec 20. Comparison of Stateless and Stateful PCE Can you have a re look at this wrt draft-ietf-pce-pce-initiated-lsp-00 is now a WG draft. Regards, Dhruv On Thu, Feb 6, 2014 at 4:59 PM, Adrian Farrel wrote: > Hi, > > We cleaned up a couple of typos. > > No other questions for immediate answer having been raised, the authors > think > this work is complete and suggest that it is time to last call it and > requst > publication. > > Thanks, > Adrian > > > -----Original Message----- > > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > > Sent: 06 February 2014 11:22 > > To: i-d-announce@ietf.org > > Cc: pce@ietf.org > > Subject: [Pce] I-D Action: draft-ietf-pce-questions-02.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 Working Group > of > the > > IETF. > > > > Title : Unanswered Questions in the Path Computation > Element > > Architecture > > Authors : Adrian Farrel > > Daniel King > > Filename : draft-ietf-pce-questions-02.txt > > Pages : 25 > > Date : 2014-02-06 > > > > Abstract: > > The Path Computation Element (PCE) architecture is set out in RFC > > 4655. The architecture is extended for multi-layer networking with > > the introduction of the Virtual Network Topology Manager in RFC > > 5623, and generalized to Hierarchical PCE in RFC 6805. > > > > These three architectural views of PCE deliberately leave some key > > questions unanswered especially with respect to the interactions > > between architectural components. This document draws out those > > questions and discusses them in an architectural context with > > reference to other architectural components, existing protocols, and > > recent IETF work efforts. > > > > This document does not update the architecture documents and does not > > define how protocols or components must be used. It does, however, > > suggest how the architectural components might be combined to provide > > advanced PCE function. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-pce-questions/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-pce-questions-02 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-questions-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/ > > > > _______________________________________________ > > 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 > --089e0111e0da07ddae04f1bbebca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Adrian,= =A0

There are a few c= omments that i made during the WG adoption call.=A0
[http://www.ietf.org/mail-archive/web/pce/current/msg0316= 8.html].=A0

Most of them have= been handled in -01 version.=A0
I have listed some that i would like your opinion on.=A0

* Sec 3.  How Is Topology Information Gathered?  =20
Another issue faced when using IGP to fed TED is the area-scope issue. Sinc=
e
IGP-TE flooding scope is per area, an multi-area or AS-scope PCE must have =
an IGP peer
for all the areas.=A0
Also I think we can augment th=
is section to include 'How PCE learn about
Boundary Nodes?'.=20

* Sec 5.  How Do I Select Between PCEs?
Along with capability, you can also mention the PCE's preference for ea=
ch
computation scope as carried in the PATH-SCOPE subtlv.
* Sec 13.  What are Sticky Resources?
OLD:
This can result in LSP setup failures are there is contention for
resources.
NEW:
This can result in LSP setup failures if there is contention for
resources.
* Sec 20.  Comparison of Stateless and Stateful PCE
Can you have a re look at this wrt draft-ietf-pce-pce-initiated-lsp-00 is n=
ow a WG draft. 
Regards,


Dhruv

On Thu, Feb 6, 2014 at 4:59 PM, Adrian Farrel <adrian@olddog.co.uk&g= t; wrote:
Hi,

We cleaned up a couple of typos.

No other questions for immediate answer having been raised, the authors thi= nk
this work is complete and suggest that it is time to last call it and requs= t
publication.

Thanks,
Adrian

> -----Original Message-----
> From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
> Sent: 06 February 2014 11:22
> To: i-d-ann= ounce@ietf.org
> Cc: pce@ietf.org=
> Subject: [Pce] I-D Action: draft-ietf-pce-questions-02.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> =A0This draft is a work item of the Path Computation Element Working G= roup of
the
> IETF.
>
> =A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Unanswered Questions in th= e Path Computation Element
> Architecture
> =A0 =A0 =A0 =A0 Authors =A0 =A0 =A0 =A0 : Adrian Farrel
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Daniel King
> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-pce-questions-02.txt<= br> > =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 25
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-02-06
>
> Abstract:
> =A0 =A0The Path Computation Element (PCE) architecture is set out in R= FC
> =A0 =A04655. The architecture is extended for multi-layer networking w= ith
> =A0 =A0the introduction of the Virtual Network Topology Manager in RFC=
> =A0 =A05623, and generalized to Hierarchical PCE in RFC 6805.
>
> =A0 =A0These three architectural views of PCE deliberately leave some = key
> =A0 =A0questions unanswered especially with respect to the interaction= s
> =A0 =A0between architectural components. =A0This document draws out th= ose
> =A0 =A0questions and discusses them in an architectural context with > =A0 =A0reference to other architectural components, existing protocols= , and
> =A0 =A0recent IETF work efforts.
>
> =A0 =A0This document does not update the architecture documents and do= es not
> =A0 =A0define how protocols or components must be used. =A0It does, ho= wever,
> =A0 =A0suggest how the architectural components might be combined to p= rovide
> =A0 =A0advanced PCE function.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-pce-question= s/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-pce-questions-02 >
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-qu= estions-02
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> 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

_______________________________________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce

--089e0111e0da07ddae04f1bbebca-- From touch@isi.edu Thu Feb 6 13:42:29 2014 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 9223F1A015B for ; Thu, 6 Feb 2014 13:42:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 D7K4OK4d9ePX for ; Thu, 6 Feb 2014 13:42:28 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id E48081A0133 for ; Thu, 6 Feb 2014 13:42:27 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s16Lfr17007417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 6 Feb 2014 13:41:54 -0800 (PST) Message-ID: <52F401A1.7040209@isi.edu> Date: Thu, 06 Feb 2014 13:41:53 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Diego R. Lopez" , Farrel Adrian References: <07b801cf1534$bec46b60$3c4d4220$@olddog.co.uk> <4698EB6C-9BEC-4E76-8291-FBCA51753950@tid.es> In-Reply-To: <4698EB6C-9BEC-4E76-8291-FBCA51753950@tid.es> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Fri, 07 Feb 2014 01:26:49 -0800 Cc: "pce@ietf.org" Subject: Re: [Pce] Use of TCP AO and TLS in PCEP 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, 06 Feb 2014 21:42:29 -0000 Hi, Diego, Some responses below to some specific points: On 2/6/2014 12:44 AM, Diego R. Lopez wrote: > Hi Adrian, Joe, > > Thanks for the review. It will really help in putting the draft in a better shape. We are preparing a new version and the replies below will be reflected there. ... >>>> 2.1. TCP ports >>>> >>>> The default destination port number for PCEPS is TCP/XXXX. >>>> >>>> NOTE: This port has to be agreed and registered as PCEPS with IANA. >>> >>> PCEP already is assigned to port 4189. RFC5440 already permits PCEP >>> connections to use either TCP MD5 or TCP-AO, but at the time of that >>> document there was no TCP-AO to reference. >>> >>> As a result it should be trivial for a PCEP server to differentiate pcep >>> vs. pceps connections: >>> >>> MD5 must be pcep, and already don't use TLS >>> >>> TCP-AO must be pceps, and thus must include TLS >>> >>> connections using neither MD5 nor TCP-AO must be pceps, >>> and thus must include TLS >>> >>> I don't see a rationale for needing a separate port. > > The rationale is the common practice derived from the TLS layered > approach, so a client knows how and when require the server to start a > TLS connection, and the server knows in advance what the client is > requiring and match it against its policy. That is common when there is no other way to determine whether a connection uses TLS or not (and even then is at best a performance optimization). > The use of TCP protection must be orthogonal to the use of TLS, so it > can not be used for the server making a guess of the protocol > security encapsulation. TCP protection isn't orthogonal to TLS for pcep as currently specified; see the table above. The only connections that can use TLS would be those that do not use TCP MD5 (see the list of cases above). > Either we have a protocol-specific mechanism (a-la-STARTTLS) or we > usea specific port. ... For every connection, you already know the mode before the connection starts. If the connection is configured to require TCP MD5, then there is no TLS. If not, then there must be TLS. There are no protocol changes required to make this happen; you just need to use the information you already have. ... >>>> 4. Backward Compatibility >>>> >>>> Since the procedure described in this document describes a security >>>> container for the transport of PCEP requests and replies carried on a >>>> newly allocated TCP port there will be no impact on the base PCEP >>>> and/or any further extensions. >>> >>> See my comment above; I agree, but not because a new port is needed. > > As said above, not using a different port would translate in > requiring an additional protocol element, so clients could express > their request to start a TLS connection. That information isn't needed; you already have to know in advance whether you require them to use TCP MD5 or not. That's enough information to know whether it's TLS or not too. Joe From dhruv.ietf@gmail.com Sat Feb 8 00:08:25 2014 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 D4C761ADF22 for ; Sat, 8 Feb 2014 00:08:25 -0800 (PST) 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, 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 k5-2yxt4BI-9 for ; Sat, 8 Feb 2014 00:08:21 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 958951A05C0 for ; Sat, 8 Feb 2014 00:08:21 -0800 (PST) Received: by mail-ig0-f179.google.com with SMTP id c10so3536019igq.0 for ; Sat, 08 Feb 2014 00:08:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=kCgzQUA5ICXEPSHBKGbL9Z7KFwgXNIlZCXVFqR4jOiU=; b=aSqLlsfztPE1poTFCASzwCy68NT2dioAplkR8GhPPYMSwRKN+Hd423gMhB6sqR7cYD n6hpJoyP7n7fqD5Ppg6g9/tw8ZhXwwA2JbfEfuGPh7x6q/7C5ivD/ktzEk4nfmwXZkac aLj4UIj77B1m5o8kjys3hGQbq2/JL20ImQaKSDAO/N+/h/xThHF+h8aeltlSLafIbRrN PAM91ATNTjou052bFUYNrDTQy45vxbLc/3QKWlvc7ogzFs8DqHVHDlzExyBTJn4b+Wm9 FWdiLX/MscUDaG2Lk+Spi7CO7504VkHRw9vU9XDK9daqKzt51jWnOfy2AjO53dgCUbTB 8YiA== MIME-Version: 1.0 X-Received: by 10.50.61.101 with SMTP id o5mr3999914igr.31.1391846901158; Sat, 08 Feb 2014 00:08:21 -0800 (PST) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.160.231 with HTTP; Sat, 8 Feb 2014 00:08:21 -0800 (PST) In-Reply-To: References: Date: Sat, 8 Feb 2014 13:38:21 +0530 X-Google-Sender-Auth: GO15sueR-VEkz276v_KLBYZEfyQ Message-ID: From: Dhruv Dhody To: "pce@ietf.org" Content-Type: multipart/alternative; boundary=001a11360350201a1904f1e09cd3 Subject: Re: [Pce] Suggestion in draft-wu-pce-pcep-link-bw-utilization regarding MRUP calculation 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: Sat, 08 Feb 2014 08:08:26 -0000 --001a11360350201a1904f1e09cd3 Content-Type: text/plain; charset=ISO-8859-1 Hi WG, Here is the update to the I.D. with the correction made to Link Reserved Bandwidth Utilization (LRBU) calculation and its respective objective function Maximum Reserved Under-Utilized Path (MRUP). Regards, Dhruv A new version of I-D, draft-wu-pce-pcep-link-bw-utilization-02.txt > has been successfully submitted by Dhruv Dhody and posted to the > IETF repository. > Name: draft-wu-pce-pcep-link-bw-utilization > Revision: 02 > Title: Extensions to Path Computation Element Communication > Protocol (PCEP) for handling Link Bandwidth Utilization > Document date: 2014-02-07 > Group: Individual Submission > Pages: 15 > URL: http://www.ietf.org/internet- > drafts/draft-wu-pce-pcep-link-bw-utilization-02.txt > Status: https://datatracker.ietf.org/ > doc/draft-wu-pce-pcep-link-bw-utilization/ > Htmlized: http://tools.ietf.org/html/ > draft-wu-pce-pcep-link-bw-utilization-02 > Diff: http://www.ietf.org/rfcdiff? > url2=draft-wu-pce-pcep-link-bw-utilization-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. > Link bandwidth utilization considering the total bandwidth of a link > in current use for the forwarding is an important factor to consider > during path computation. This document describes extensions to PCEP > to consider them as new constraints during path computation. > > > > 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. > The IETF Secretariat On Fri, Jan 24, 2014 at 6:29 PM, Dhruv Dhody wrote: > Hi PCErs, > > Authors have received a following suggestion to change the description for > the new objective function > Maximum Reserved Under-Utilized Path (MRUP) [ > http://tools.ietf.org/html/draft-wu-pce-pcep-link-bw-utilization-01#section-6.2 > ]. > > We agree that the use of Maximum reservable bandwidth R(L) would be the > correct way. We plan to make this change in the next revision. > > Name: Maximum Reserved Under-Utilized Path (MRUP) > > > > Description: Find a path P such that (Min {(R(Lpi)- ru(Lpi)) / > > R(Lpi), i=1...K } ) is maximized. > > Regards, > Dhruv > > ---------- Forwarded message ---------- > From: Avantika > Date: Fri, Jan 24, 2014 at 12:11 PM > Subject: Suggestion in draft-wu-pce-pcep-link-bw-utilization regarding > MRUP calculation > To: Dhruv Dhody , Qin Wu , " > sprevidi@cisco.com" > Cc: Udayasree palle , "dhruv.ietf@gmail.com" < > dhruv.ietf@gmail.com> > > > Hi Authors! > > > > I have a suggestion regarding the formula used for optimization using > objective function MRUP in draft-wu-pce-pcep-link-bw-utilization. > > > > As per the draft, > > > > Name: Maximum Reserved Under-Utilized Path (MRUP) > > > > Description: Find a path P such that (Min {(c(Lpi)- ru(Lpi)) / > > c(Lpi), i=1...K } ) is maximized. > > > > > > Let me take the example of below topology, > > > > 100(max reservable BW on each link) > > > > Source Destination > > A------------------------C > > | | > > | | > > | | > > | | > > B------------------------D > > > > LSP1 : BW 20 > > LSP2 : BW 20 > > LSP3 : BW 40 > > > > Every time a LSP is established path A-C, the RSVP-traffic flowing through > them, let's say, is approximately 60% of the current reserved. > > > > After each LSP is established, the output of the formula ((c(Lpi)- > ru(Lpi)) / c(Lpi)) > > Consider link A-C > > LSP1: (20 - 12)/20 > > LSP2: (40 - 24)/40 > > LSP3: (80 - 48)/80 > > > > Always remains as 0.4. > > > > In my opinion, if instead of using Current Reserved bandwidth, c(L) in the above formula, if we use Maximum reservable bandwidth on link L, denoted R(L). > > > > Name: Maximum Reserved Under-Utilized Path (MRUP) > > > > Description: Find a path P such that (Min {(R(Lpi)- ru(Lpi)) / > > R(Lpi), i=1...K } ) is maximized. > > > > > > Consider link A-C > > LSP1 : (100 - 12)/100 = 0.88 > > LSP2 : (100 - 24)/100 = 0.76 > > LSP3 : (100 - 48)/100 = 0.52 > > > > This gives a much clearer reserved utilization for the link. > > > > Also, now if the OF MRUP is used for the path computation: > > > > LSP1 : A-C > > LSP2 : A-B-D-C > > LSP3 : A-C > > > > Hence we get a more diversified path using MRUP OF. > > > > Please let me know your opinion regarding the same. > > > > Regards, > > Avantika > > > > > > > > --001a11360350201a1904f1e09cd3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi WG,

Here is the update
to the I.D.
with the correction made to Link Rese= rved Bandwidth Utilization
(LRBU)
calculatio= n and its respective objective function
Maximum Reserved Under-Utilized Path
(MRUP).

Regards,
Dhruv


A new version of I-D, draft= -wu-pce-pcep-link-bw-utilization-02.txt
has been successfully submitted by Dhruv Dhody = and posted to the
IETF repository. Name:           draft-wu-pce-= pcep-link-bw-utilization
Revision:       02
Title:          Extensions to Pa= th Computation Element Communication Protocol (PCEP) for handling Link Band= width Utilization
Document date:  2014-02-07
Group:          Individual Submiss= ion
Pages:          15
= URL:            <= /span>http://www.ietf.org/internet-drafts/draft-wu-pce-pcep-link= -bw-utilization-02.txt
Status:         https:= //datatracker.ietf.org/doc/draft-wu-pce-pcep-link-bw-utilization= /
Htmlized:       http://tools= .ietf.org/html/draft-wu-pce-pcep-link-bw-utilization-02
Diff:           <= font face=3D"arial, sans-serif">htt= p://www.ietf.org/rfcdiff?url2=3Ddraft-wu-pce-pcep-link-bw-utiliz= ation-02
Abstract:
   = The Path Computation Element Communication Protocol (PCEP) provides
   mechanisms for Path Computation El= ements (PCEs) to perform path
   c= omputations in response to Path Computation Clients (PCCs) requests.=
   Link bandwidth utilization considering th= e total bandwidth of a link
   in = current use for the forwarding is an important factor to consider
   during path computation.  Thi= s document describes extensions to PCEP
&nbs= p;  to consider them as new constraints during path computation.



Please note that it may take a couple of minutes from = the time of submission
until the htmlized ve= rsion and diff are available at tools.ietf.org.
The IETF Secretariat


On Fri, Jan 24,= 2014 at 6:29 PM, Dhruv Dhody <dhruv.ietf@gmail.com> wrot= e:
Hi PCEr= s,

Authors have received a following suggestion to change = the description for the new objective function 
Maximum= Reserved Under-Utilized Path (MRUP) [http://tools.ietf.org/html/draft-wu-pce-pcep-link-bw-utilization-01#se= ction-6.2].

We agree that the = use of Maximum reservable bandwidth R= (L) would be the correct way. We pl= an to make this change in the next revision. 

Name: Maximum Reserved Under-Utilized Path (MRUP)

 

Descriptio= n: Find a path P such that (Min {(R(Lpi)- ru(Lpi)) /

R(Lpi), i= =3D1...K } ) is maximized.


Regards,
Dhruv

---------- Forwarded message ----------
F= rom: Avantika <avantika.su= shilkumar@huawei.com>
Date: Fri, Jan 24, 2014 at 12:11 PM
Subject: Suggestion in draft-wu-pce-= pcep-link-bw-utilization regarding MRUP calculation
To: Dhruv Dhody <dhruv.dhody@huawei.com>, Qin Wu <bill.wu@huawei.com>, "sprevidi@cisco.com= " <sprevidi= @cisco.com>
Cc: Udayasree palle <udayasree.palle@huawei.com>, "dhruv.ietf@gmail.com" <dhruv.ietf@gmail.co= m>


Hi Authors!

 

I have a suggestion regarding the formula used for optimizatio= n using objective function MRUP in draft-wu-pce-pcep-link-bw-utilization.

 

As per the draft,

 

Name: Maximum Reserved Under-Utiliz= ed Path (MRUP)

 

Description: Find a path P such tha= t (Min {(c(Lpi)- ru(Lpi)) /

c(Lpi), i=3D1...K } ) is maximized.=

 

 <= /span>

Let me take the example of below topology,

 

  100(max reservable BW on each link)

 

Source         &n= bsp;         Destination 

A------------------------C

|           =             &nb= sp;|

|           =             &nb= sp;|

|           =             &nb= sp;|

|           =             &nb= sp;|

B------------------------D

 

LSP1 : BW 20

LSP2 : BW 20

LSP3 : BW 40

 

Every time a LSP is established path A-C, the RSVP-traffic flo= wing through them, let’s say, is approximately 60% of the current res= erved.

 

After each LSP is established, the output of the formula ((c(L= pi)- ru(Lpi)) / c(Lpi))

Consider link A-C

LSP1: (20 – 12)/20

LSP2: (40 – 24)/40

LSP3: (80 – 48)/80

 

Always remains as 0.4.

 

In my opinion, if instead of using Current Reserved bandwidth, c=
(L) in the above formula, if we use Maximum reservable bandwidth on link L,=
 denoted R(L). =

 

Name: Maximum Reserved Under-Utiliz= ed Path (MRUP)

 

Description: Find a path P such tha= t (Min {(R(Lpi)- ru(Lpi)) /

R(Lpi), i=3D1...K } ) is maximized.= 

 

 

Consider link A-C

LSP1 : (100 – 12)/100 =3D 0.88
LSP2 : (100 – 24)/100 =3D 0.76
LSP3 : (100 – 48)/100 =3D 0.52
 
This gives a much clearer reserved utilization for the link. =

 

Also, now if the OF MRUP is used for the path computation:

 

LSP1 : A-C

LSP2 : A-B-D-C

LSP3 : A-C

 

Hence we get a more diversified path using MRUP OF.<= /u>

 

Please let me know your opinion regarding the same.<= /u>

 

Regards,

Avantika

 

 <= /span>

 <= /span>



--001a11360350201a1904f1e09cd3-- From dhruv.ietf@gmail.com Mon Feb 10 01:50:51 2014 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 9CE701A07D8 for ; Mon, 10 Feb 2014 01:50:51 -0800 (PST) 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, 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 IgBwzs9s4xb8 for ; Mon, 10 Feb 2014 01:50:49 -0800 (PST) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 22D641A06BB for ; Mon, 10 Feb 2014 01:50:49 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id at1so3342058iec.22 for ; Mon, 10 Feb 2014 01:50:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=611wLlwA0sYowryjfZIbPRBc31Q6UaK1r2oGZ61cUFk=; b=u8vap2fzNTJntiabRXtIksZXS0O5e17jxggQgqR+GqIZkXY0eH/gWF6lSILZPb7mXI I5KMC86Yirhj52xDZSQW+lMsJnkkCrD5wz8SX4fHDfqBxPD8P8kol9mfYo9AIPgybsny Aj9drSSLdgdr11t2+KM1ZUjq81BCS4Sp4tyFtzzDHlNtxgtF0mh4rEB6m5XXJqKBHtWo Zu8xefA3RcYSQPFjW48B/wecxZy15iLAq4XKII3Wk/6BG9MI428BblfAt3+GW4HwrsKI gHEMCyFVKp9hB4jlV24CYpOjMLdQ27eRR5S4tw/Ld9W8InpGWnffIqYNc8U1iLi0GjYP bmug== MIME-Version: 1.0 X-Received: by 10.50.117.5 with SMTP id ka5mr13001578igb.3.1392025848992; Mon, 10 Feb 2014 01:50:48 -0800 (PST) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.160.231 with HTTP; Mon, 10 Feb 2014 01:50:48 -0800 (PST) In-Reply-To: <20140210092608.11248.74608.idtracker@ietfa.amsl.com> References: <20140210092608.11248.74608.idtracker@ietfa.amsl.com> Date: Mon, 10 Feb 2014 15:20:48 +0530 X-Google-Sender-Auth: Fh_Ge3aApQt2a5k8CanJty2W3Xk Message-ID: From: Dhruv Dhody To: "pce@ietf.org" Content-Type: multipart/alternative; boundary=089e013a10e43f589704f20a4642 Subject: [Pce] Fwd: New Version Notification for draft-dhody-pce-recv-srlg-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: Mon, 10 Feb 2014 09:50:51 -0000 --089e013a10e43f589704f20a4642 Content-Type: text/plain; charset=ISO-8859-1 Hi WG, Please find an update to the I.D. for receiving SRLG during path computation. Based on the comments, the draft name has been changed (this has been also updated in the datatracker) along with other changes. Please find the difference here: http://tools.ietf.org//rfcdiff?url1=draft-dhody-pce-srlg-collection-00&url2=draft-dhody-pce-recv-srlg-01 Regards, Dhruv (on behalf of the authors) ---------- Forwarded message ---------- From: Date: Mon, Feb 10, 2014 at 2:56 PM Subject: New Version Notification for draft-dhody-pce-recv-srlg-01.txt To: Fatai Zhang , Oscar Gonzalez de Dios < ogondio@tid.es>, Victor Lopez , Dhruv Dhody < dhruv.ietf@gmail.com>, Xian Zhang A new version of I-D, draft-dhody-pce-recv-srlg-01.txt has been successfully submitted by Dhruv Dhody and posted to the IETF repository. Name: draft-dhody-pce-recv-srlg Revision: 01 Title: PCEP Extensions for Receiving SRLG Information Document date: 2014-02-10 Group: Individual Submission Pages: 11 URL: http://www.ietf.org/internet-drafts/draft-dhody-pce-recv-srlg-01.txt Status: https://datatracker.ietf.org/doc/draft-dhody-pce-recv-srlg/ Htmlized: http://tools.ietf.org/html/draft-dhody-pce-recv-srlg-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-dhody-pce-recv-srlg-01 Abstract: The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in networks controlled by Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS). This document provides extensions for the Path Computation Element Protocol (PCEP) to receive Shared Risk Link Group (SRLG) information during path computation via encoding this information in the path computation reply message. 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. The IETF Secretariat --089e013a10e43f589704f20a4642 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi WG,

Please find an update to the I.D= . for receiving SRLG during path computation.=A0
Based on the com= ments, the draft name has been changed (this has been also updated in the d= atatracker) along with other changes.=A0

Please find the difference here:

Regards,
Dhruv (on behalf of the authors)=A0<= br>
---------- Forwarded message ----------From: <internet-drafts@ietf.org> Date: Mon, Feb 10, 2014 at 2:56 PM
Subject: New Version Notification for= draft-dhody-pce-recv-srlg-01.txt
To: Fatai Zhang <zhangfatai@huawei.com>, Oscar Gonzalez de Dio= s <ogondio@tid.es>, Victor Lope= z <vlopez@tid.es>, Dhruv Dhody &= lt;dhruv.ietf@gmail.com>, Xi= an Zhang <zhang.xian@huawei.com= >



A new version of I-D, draft-dhody-pce-recv-srlg-01.txt
has been successfully submitted by Dhruv Dhody and posted to the
IETF repository.

Name: =A0 =A0 =A0 =A0 =A0 draft-dhody-pce-recv-srlg
Revision: =A0 =A0 =A0 01
Title: =A0 =A0 =A0 =A0 =A0PCEP Extensions for Receiving SRLG Information Document date: =A02014-02-10
Group: =A0 =A0 =A0 =A0 =A0Individual Submission
Pages: =A0 =A0 =A0 =A0 =A011
URL: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/int= ernet-drafts/draft-dhody-pce-recv-srlg-01.txt
Status: =A0 =A0 =A0 =A0 https://datatracker.ietf.org/doc/dra= ft-dhody-pce-recv-srlg/
Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/draft-dhody-pce= -recv-srlg-01
Diff: =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/rfcdiff?ur= l2=3Ddraft-dhody-pce-recv-srlg-01

Abstract:
=A0 =A0The Path Computation Element (PCE) provides functions of path
=A0 =A0computation in support of traffic engineering in networks controlled=
=A0 =A0by Multi-Protocol Label Switching (MPLS) and Generalized MPLS
=A0 =A0(GMPLS).

=A0 =A0This document provides extensions for the Path Computation Element =A0 =A0Protocol (PCEP) to receive Shared Risk Link Group (SRLG) information=
=A0 =A0during path computation via encoding this information in the path =A0 =A0computation reply message.




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.

The IETF Secretariat


--089e013a10e43f589704f20a4642-- From dhruv.ietf@gmail.com Mon Feb 10 01:57:28 2014 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 E4D561A07DF for ; Mon, 10 Feb 2014 01:57:28 -0800 (PST) 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, 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 ug9EKU3F1sDn for ; Mon, 10 Feb 2014 01:57:27 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 393061A07DA for ; Mon, 10 Feb 2014 01:57:27 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id uy17so6223220igb.4 for ; Mon, 10 Feb 2014 01:57:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=opCH/KWWAScLmmmVwEzG1glR1ZQXWTNQc28YK0XGc3U=; b=ceZjUvjBL/r8uPqn0wt93eunCCqoaXjennbD/jxY90w4J3aQyPeHAuBIgdHtpOxxMF v1c+w+d2bt6cBK2antRRbCpaVzWRYkKQlramPm9MxvjeoUQ7WZC+R+Dc1qCqeJ46Ve4Z o+V3c3rZATRciHJKZ9o3uGVfJBqICShnz1diw5wclLtiGjwue+DBPYK6uxL1ysAxtkcj SfdeL/sWlsec3LlqqmpxtNtz2R+juyc/W9zpRYARul+s/QU2K7EG7VEc+T1skH7Z12p2 WAWHqCrCMAxRJ60ElIWsmd0huMpFUMNegO4pMuWErSKdCPWnrx3pszeaCdeMHiDvc2aT uwww== MIME-Version: 1.0 X-Received: by 10.43.49.1 with SMTP id uy1mr831659icb.48.1392026247156; Mon, 10 Feb 2014 01:57:27 -0800 (PST) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.160.231 with HTTP; Mon, 10 Feb 2014 01:57:27 -0800 (PST) In-Reply-To: <20140206140839.8646.52088.idtracker@ietfa.amsl.com> References: <20140206140839.8646.52088.idtracker@ietfa.amsl.com> Date: Mon, 10 Feb 2014 15:27:27 +0530 X-Google-Sender-Auth: ZPlxzMgLjgFl3MK0nos9wCfxYr4 Message-ID: From: Dhruv Dhody To: "pce@ietf.org" Content-Type: multipart/alternative; boundary=bcaec529a023fad90d04f20a5d26 Subject: [Pce] Fwd: New Version Notification for draft-dhody-pce-pcep-pathkey-mib-07.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, 10 Feb 2014 09:57:29 -0000 --bcaec529a023fad90d04f20a5d26 Content-Type: text/plain; charset=ISO-8859-1 Hi WG, With this update we have aligned to the recent changes made in the PCEP base MIB: draft-ietf-pce-pcep-mib-07. We feel the draft is in good shape for WG adoption. Regards, Dhruv ---------- Forwarded message ---------- From: Date: Thu, Feb 6, 2014 at 7:38 PM Subject: New Version Notification for draft-dhody-pce-pcep-pathkey-mib-07.txt To: Daniel King , Udayasree Palle < udayasree.palle@huawei.com>, Dhruv Dhody , Quintin Zhao A new version of I-D, draft-dhody-pce-pcep-pathkey-mib-07.txt has been successfully submitted by Dhruv Dhody and posted to the IETF repository. Name: draft-dhody-pce-pcep-pathkey-mib Revision: 07 Title: Management Information Base (MIB) for the PCE Communications Protocol (PCEP) for Path-Key based Confidentiality in Inter-Domain Path Computation. Document date: 2014-02-06 Group: Individual Submission Pages: 22 URL: http://www.ietf.org/internet-drafts/draft-dhody-pce-pcep-pathkey-mib-07.txt Status: https://datatracker.ietf.org/doc/draft-dhody-pce-pcep-pathkey-mib/ Htmlized: http://tools.ietf.org/html/draft-dhody-pce-pcep-pathkey-mib-07 Diff: http://www.ietf.org/rfcdiff?url2=draft-dhody-pce-pcep-pathkey-mib-07 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of the Path Computation Element communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs when path-key-based confidentiality in inter-domain path computation is requested. 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. The IETF Secretariat --bcaec529a023fad90d04f20a5d26 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi WG,

With this update we have aligned to th= e recent changes made in the PCEP base MIB: draft-ietf-pce-pcep-mib-07. We feel the draft is in good shape for WG adoption.

Regards,
Dh= ruv
=A0
---------- Forwarded message ----------From: <internet-drafts@ietf.org>Date: Thu, Feb 6, 2014 at 7:38 PM
Subject: New Version Notification for draft-dhody-pce-pcep-pathkey-mib-07.t= xt
To: Daniel King <daniel@old= dog.co.uk>, Udayasree Palle <udayasree.palle@huawei.com>, Dhruv Dhody <dhruv.ietf@gmail.com>, Quintin Zhao <<= a href=3D"mailto:quintin.zhao@huawei.com">quintin.zhao@huawei.com>


A new version of I-D, draft-dhody-pce-pcep-pathkey-mib-07.txt
has been successfully submitted by Dhruv Dhody and posted to the
IETF repository.

Name: =A0 =A0 =A0 =A0 =A0 draft-dhody-pce-pcep-pathkey-mib
Revision: =A0 =A0 =A0 07
Title: =A0 =A0 =A0 =A0 =A0Management Information Base (MIB) for the PCE Com= munications Protocol (PCEP) for Path-Key based Confidentiality in Inter-Dom= ain Path Computation.
Document date: =A02014-02-06
Group: =A0 =A0 =A0 =A0 =A0Individual Submission
Pages: =A0 =A0 =A0 =A0 =A022
URL: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.= org/internet-drafts/draft-dhody-pce-pcep-pathkey-mib-07.txt
Status: =A0 =A0 =A0 =A0 https://datatracker.ietf.org/= doc/draft-dhody-pce-pcep-pathkey-mib/
Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/draft-dh= ody-pce-pcep-pathkey-mib-07
Diff: =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/rfc= diff?url2=3Ddraft-dhody-pce-pcep-pathkey-mib-07

Abstract:
=A0 =A0This memo defines a portion of the Management Information Base (MIB)=
=A0 =A0for use with network management protocols in the Internet community.=
=A0 =A0In particular, it describes managed objects for modeling of the Path=
=A0 =A0Computation Element communication Protocol (PCEP) for communications=
=A0 =A0between a Path Computation Client (PCC) and a Path Computation
=A0 =A0Element (PCE), or between two PCEs when path-key-based
=A0 =A0confidentiality in inter-domain path computation is requested.




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.

The IETF Secretariat


--bcaec529a023fad90d04f20a5d26-- From julien.meuric@orange.com Mon Feb 10 05:17:59 2014 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 6F26B1A02A7 for ; Mon, 10 Feb 2014 05:17:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.432 X-Spam-Level: X-Spam-Status: No, score=-1.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.548, 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 vGPBNc8AZKdw for ; Mon, 10 Feb 2014 05:17:58 -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 D9F4F1A06D5 for ; Mon, 10 Feb 2014 05:17:57 -0800 (PST) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E5EBF5D8C7A for ; Mon, 10 Feb 2014 14:17:56 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.orange.com (Postfix) with ESMTP id DE2175D8C52 for ; Mon, 10 Feb 2014 14:17:56 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Feb 2014 14:17:56 +0100 Received: from [10.193.71.94] ([10.193.71.94]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Feb 2014 14:17:56 +0100 Message-ID: <52F8D183.7050202@orange.com> Date: Mon, 10 Feb 2014 14:17:55 +0100 From: Julien Meuric Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "pce@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Feb 2014 13:17:56.0584 (UTC) FILETIME=[8323B680:01CF2662] Subject: [Pce] I-D Cut-Off 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, 10 Feb 2014 13:17:59 -0000 Hi all. Please be aware that the deadline for posting your drafts before IETF 89 is next *Friday*, not a Monday as usual. (Thanks Adrian for the warning.) JP & Julien From julien.meuric@orange.com Mon Feb 10 06:19:41 2014 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 239711A02FA for ; Mon, 10 Feb 2014 06:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.432 X-Spam-Level: X-Spam-Status: No, score=-1.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.548, 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 4bpOvLK11C2m for ; Mon, 10 Feb 2014 06:19:39 -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 A21771A084C for ; Mon, 10 Feb 2014 06:05:05 -0800 (PST) Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4B65CE3011B for ; Mon, 10 Feb 2014 15:09:42 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.orange.com (Postfix) with ESMTP id 42BF3E3011A for ; Mon, 10 Feb 2014 15:09:42 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Feb 2014 15:05:03 +0100 Received: from [10.193.71.94] ([10.193.71.94]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Feb 2014 15:05:03 +0100 Message-ID: <52F8DC8F.8010607@orange.com> Date: Mon, 10 Feb 2014 15:05:03 +0100 From: Julien Meuric Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: pce@ietf.org References: <52F8D183.7050202@orange.com> In-Reply-To: <52F8D183.7050202@orange.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Feb 2014 14:05:03.0373 (UTC) FILETIME=[18097BD0:01CF2669] Subject: Re: [Pce] I-D Cut-Off 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, 10 Feb 2014 14:19:41 -0000 Hi again! Before a controversy attract the RFC Editor into the thread, allow me to rephrase: - cut-off is *not* a Monday but a Friday (14th), - reference information is on http://www.ietf.org/meeting/important-dates-2014.html#IETF89 Julien Feb. 10, 2014 - Julien Meuric: > Hi all. > > Please be aware that the deadline for posting your drafts before IETF > 89 is next *Friday*, not a Monday as usual. (Thanks Adrian for the > warning.) > > JP & Julien From udayasree.palle@huawei.com Tue Feb 11 03:46:30 2014 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 228751A07E9 for ; Tue, 11 Feb 2014 03:46:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 898CEsoHd2AS for ; Tue, 11 Feb 2014 03:46:28 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3CC1A07E4 for ; Tue, 11 Feb 2014 03:46:27 -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 BAZ81175; Tue, 11 Feb 2014 11:46:26 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Feb 2014 11:45:29 +0000 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Feb 2014 11:46:25 +0000 Received: from szxeml561-mbx.china.huawei.com ([169.254.5.101]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.03.0158.001; Tue, 11 Feb 2014 19:45:35 +0800 From: Udayasree palle To: Dorian Davis Thread-Topic: Regd draft-avantika-pce-multi-src-dest Thread-Index: AQHPJwU3yDVJZ2rRR0ud8+pFQrPdVJqv7HnA Date: Tue, 11 Feb 2014 11:45:34 +0000 Message-ID: References: <8D0F518C13EAEED-1B98-1E1C7@webmail-d169.sysops.aol.com> In-Reply-To: <8D0F518C13EAEED-1B98-1E1C7@webmail-d169.sysops.aol.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "pce@ietf.org" Subject: Re: [Pce] Regd draft-avantika-pce-multi-src-dest 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, 11 Feb 2014 11:46:30 -0000 Hi, Dorian asked a question about how much benefit do we get from draft-avantik= a-pce-multi-src-dest.=20 I am CCing WG as well (hope that's okay!). Considering an example of path request where 4 requests need to be encoded = (from 2 sources to 2 destinations with the exact same constraints). This figure illustrates the existing mechanism of carrying multiple request= s in single PCReq message (as per RFC 5440): +--------------+ +--------------+ +--------------+ +-------------= -+ |RP | |RP | |RP | |RP = | +-------+ |END-POINTS(8) | |END-POINTS | |END-POINTS | |END-POINTS = | |COMMON |+|BANDWIDTH |+|BANDWIDTH |+|BANDWIDTH |+|BANDWIDTH = |=3D148 Bytes |HEADER | |METRIC | |METRIC | |METRIC | |METRIC = | +-------+ |METRIC | |METRIC | |METRIC | |METRIC = | =20 +--------------+ +--------------+ +--------------+ +-------------= -+ 4 Bytes 36 Bytes 36 Bytes 36 Bytes 36 Bytes = =20 = =20 Combining multiple requests into a single request by using MP2MP END-POINTS= object: +--------------+ |RP | +-------+ |END-POINTS(20)| |COMMON |+|BANDWIDTH | =3D 54 Bytes |HEADER | |METRIC | +-------+ |METRIC | +--------------+ 4 Bytes 48 Bytes =20 There is message size reduction of 64% in this illustration.=20 Thus we feel that this simple extension to PCEP END-POINTS object can be us= eful.=20 Regards, Udaya --------- From: Dorian Davis [mailto:davis.dorian@aim.com]=20 Sent: 11 February 2014 13:47 To: draft-avantika-pce-multi-src-dest.all@tools.ietf.org Subject: Regd draft-avantika-pce-multi-src-dest Hi Authors,=20 I read your document but I wonder how much benefit are you getting from thi= s? D ------------------ Dorian Davis davis.dorian@aim.com From diego@tid.es Tue Feb 11 06:26:17 2014 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 8D2831A03E6 for ; Tue, 11 Feb 2014 06:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.85 X-Spam-Level: X-Spam-Status: No, score=-2.85 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 83BxBNZOH8Ks for ; Tue, 11 Feb 2014 06:26:13 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 238691A03CC for ; Tue, 11 Feb 2014 06:26:13 -0800 (PST) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0N0U003JM5FITU@tid.hi.inet> for pce@ietf.org; Tue, 11 Feb 2014 15:26:09 +0100 (MET) Received: from dequeue_removeroute (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 9F.28.03314.1033AF25; Tue, 11 Feb 2014 15:26:09 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0N0U003JQ5FKTU@tid.hi.inet> for pce@ietf.org; Tue, 11 Feb 2014 15:26:08 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.159]) by EX10-HTCAS6-MAD.hi.inet ([::1]) with mapi id 14.03.0158.001; Tue, 11 Feb 2014 15:26:08 +0100 Date: Tue, 11 Feb 2014 14:26:08 +0000 From: "Diego R. Lopez" In-reply-to: <52F401A1.7040209@isi.edu> X-Originating-IP: [10.95.64.115] To: Joe Touch Message-id: Content-id: <29C2FA48B1A2C84C8719E123DF55BF41@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, es-ES Thread-topic: [Pce] Use of TCP AO and TLS in PCEP Thread-index: Ac8VNFeRvCG6i4qyTfiGqoE+7Nwh2wN2xWYAABscN4AA7CRfAA== X-AuditID: 0a5f4068-b7fe58e000000cf2-82-52fa330148d5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42Lhinfg0mU0/hVk8PQ/q0XT/RvsDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK2HlBuGCaasXGFR2MDYxzVLoYOTkkBEwkXl47wQphi0lcuLee rYuRi0NI4ACjxPzF3UwQzldGiZkHjjBDODMZJSb0bWYGaWERUJV4u+YpC4jNBmQ/av7NDmIL CxhIzFj/jA3E5hRQl5hzcBo7xAoFiT/nHoPViwjISjz48wYszizgJvF37l+wel4BS4knC3cw QcTNJObe38kEEReU+DH5HlAvB1BcXWLKlFyIEnGJ5tabLBC2osS0RQ2MIDYj0Ph38+ezQqwy lDjedglqrZPEo8kfGCHOEZBYsuc8M4QtKvHy8T9WiB9bGSUuXDjHPoFRYhaSM2YhOWMWwhmz kJwxC8kZCxhZVzGKFScVZaZnlOQmZuakGxjqZWTqZeallmxihERdxg7G5TtVDjEKcDAq8fBq fP0RJMSaWFZcmXuIUYKDWUmEV03tV5AQb0piZVVqUX58UWlOavEhRiYOTqkGxh12xfOem3/a zOVSqXXIZP5uhUDx2HN5mrEsrpwtOyJN5aTvCk7OLuM4yJ34mUPiJBeDyOtW1iv9p17VzP9s Gfd2WwjPxy3dmrsiSh7JBsbXX5QNqfx574LPE0enWY/PPmBvqZeRztHL6j/qtf3sIR2LnD3N fkc8psuLuxsWsEu47rM1fflfiaU4I9FQi7moOBEApA8wX5gCAAA= References: <07b801cf1534$bec46b60$3c4d4220$@olddog.co.uk> <4698EB6C-9BEC-4E76-8291-FBCA51753950@tid.es> <52F401A1.7040209@isi.edu> Cc: "pce@ietf.org" Subject: Re: [Pce] Use of TCP AO and TLS in PCEP 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, 11 Feb 2014 14:26:17 -0000 SGkgSm9lLA0KDQpUb28gbXVjaCB0cmF2ZWwgbWFraW5nIG15IGVtYWlsIGJhY2tsb2cgZ3Jvdywg SSdtIGFmcmFpZC4uLg0KDQpPbiA2IEZlYiAyMDE0LCBhdCAyMjo0MSAsIEpvZSBUb3VjaCA8dG91 Y2hAaXNpLmVkdT4gd3JvdGU6DQo+PiBUaGUgcmF0aW9uYWxlIGlzIHRoZSBjb21tb24gcHJhY3Rp Y2UgZGVyaXZlZCBmcm9tIHRoZSBUTFMgbGF5ZXJlZA0KPj4gYXBwcm9hY2gsIHNvIGEgY2xpZW50 IGtub3dzIGhvdyBhbmQgd2hlbiByZXF1aXJlIHRoZSBzZXJ2ZXIgdG8gc3RhcnQgYQ0KPj4gVExT IGNvbm5lY3Rpb24sIGFuZCB0aGUgc2VydmVyIGtub3dzIGluIGFkdmFuY2Ugd2hhdCB0aGUgY2xp ZW50IGlzDQo+PiByZXF1aXJpbmcgYW5kIG1hdGNoIGl0IGFnYWluc3QgaXRzIHBvbGljeS4NCj4N Cj4gVGhhdCBpcyBjb21tb24gd2hlbiB0aGVyZSBpcyBubyBvdGhlciB3YXkgdG8gZGV0ZXJtaW5l IHdoZXRoZXIgYSBjb25uZWN0aW9uIHVzZXMgVExTIG9yIG5vdCAoYW5kIGV2ZW4gdGhlbiBpcyBh dCBiZXN0IGEgcGVyZm9ybWFuY2Ugb3B0aW1pemF0aW9uKS4NCg0KSSdkIHNheSBpcyBub3Qgb25s eSBwZXJmb3JtYW5jZSwgYnV0IGEgc2VjdXJpdHkgb3B0aW1pemF0aW9uLiBVbmxlc3MgdGhlIHNl cnZlciBpcyBzdXJlIHRoYXQgc3RhcnRpbmcgYSBUTFMgc2Vzc2lvbiBpcyBleHBsaWNpdGx5IHJl cXVpcmVkIGJ5IHRoZSBjbGllbnQsIGhvdyBjYW4gYSBzZXJ2ZXIga25vdyB3aGV0aGVyIHRoZXJl IGhhcyBiZWVuIGFuIGludGVudGlvbmFsIGRvd25ncmFkZSBieSBhIG1hbi1pbi10aGUtbWlkZGxl PyBGdXJ0aGVybW9yZSwgdGhlIGNsaWVudCBhbmQgc2VydmVyIGNvZGVzIGJlY29tZSBjb21wbGV0 ZWx5IGluZGVwZW5kZW50IG9mIHdoYXQgaGFwcGVucyBhdCB0aGUgVENQIGxheWVyLCBhbmQgSSB0 aGluayB0aGlzIGlzIGluIGdlbmVyYWwgYSBnb29kIGRlc2lnbiBwcmFjdGljZS4NCg0KQW5kIGV2 ZW4gaWYgeW91IGZpbmQgY291bnRlcmFyZ3VtZW50cyB0byB0aGUgdHdvIHJlYXNvbnMgYWJvdmUs IHRoZSBjb21tb24gcHJhY3RpY2UgaXMgdGhlIHVzZSBvZiBlaXRoZXIgYSBkZWRpY2F0ZWQgcG9y dCBvciBhIGRlZGljYXRlZCBjb21tYW5kLiBBbmQgdGhhdCBpbXBsaWVzIHRoYXQgZGV2ZWxvcGVy cyB3aWxsIGZpbmQgcGxlbnR5IG9mIGNob2ljZXMgdG8gaW1wbGVtZW50IHRoaXMsIHdpZGVseSB2 YWxpZGF0ZWQgYW5kIHVuZGVyc3Rvb2QgYnkgdGhlIGNvbW11bml0eS4gQW5kIHdoZW4gaXQgY29t ZXMgdG8gc2VjdXJpdHksIHRoaXMgaXMgb2YgZ3JlYXQgdmFsdWUsIG1vc3RseSB3aGVuIFBDRVAg cGVlciBkZXZlbG9wZXJzIHdpbGwgbm90IHVzdWFsbHkgYmUgc2VjdXJpdHkgZXhwZXJ0cy4NCg0K PiBUaGUgdXNlIG9mIFRDUCBwcm90ZWN0aW9uIG11c3QgYmUgb3J0aG9nb25hbCB0byB0aGUgdXNl IG9mIFRMUywgc28gaXQNCj4+IGNhbiBub3QgYmUgdXNlZCBmb3IgdGhlIHNlcnZlciBtYWtpbmcg YSBndWVzcyBvZiB0aGUgcHJvdG9jb2wNCj4+IHNlY3VyaXR5IGVuY2Fwc3VsYXRpb24uDQo+DQo+ IFRDUCBwcm90ZWN0aW9uIGlzbid0IG9ydGhvZ29uYWwgdG8gVExTIGZvciBwY2VwIGFzIGN1cnJl bnRseSBzcGVjaWZpZWQ7IHNlZSB0aGUgdGFibGUgYWJvdmUuIFRoZSBvbmx5IGNvbm5lY3Rpb25z IHRoYXQgY2FuIHVzZSBUTFMgd291bGQgYmUgdGhvc2UgdGhhdCBkbyBub3QgdXNlIFRDUCBNRDUg KHNlZSB0aGUgbGlzdCBvZiBjYXNlcyBhYm92ZSkuDQo+DQo+PiBFaXRoZXIgd2UgaGF2ZSBhIHBy b3RvY29sLXNwZWNpZmljIG1lY2hhbmlzbSAoYS1sYS1TVEFSVFRMUykgb3Igd2UNCj4+IHVzZWEg c3BlY2lmaWMgcG9ydC4NCj4gLi4uDQo+DQo+IEZvciBldmVyeSBjb25uZWN0aW9uLCB5b3UgYWxy ZWFkeSBrbm93IHRoZSBtb2RlIGJlZm9yZSB0aGUgY29ubmVjdGlvbiBzdGFydHMuIElmIHRoZSBj b25uZWN0aW9uIGlzIGNvbmZpZ3VyZWQgdG8gcmVxdWlyZSBUQ1AgTUQ1LCB0aGVuIHRoZXJlIGlz IG5vIFRMUy4gSWYgbm90LCB0aGVuIHRoZXJlIG11c3QgYmUgVExTLg0KDQpXaGF0IEkgY2Fubm90 IHNlZSBpcyB3aHkgdGhlIGNvbWJpbmF0aW9uIG9mIFRDUCBNRDUgd2l0aCBUTFMgY291bGQgbm90 IGhhcHBlbiwgb3IgdGhlIGNvbWJpbmF0aW9uIG9mIFRDUCBBTyB3aXRob3V0IFRMUy4gV2UgYXJl IHRhbGtpbmcgYWJvdXQgaW5kZXBlbmRlbnQgbGF5ZXJzLCBvciBhbSBJIG1pc3Npbmcgc29tZXRo aW5nPyBGV0lXLCB5b3UgY291bGQgdXNlIGFueSBvZiB0aGVtIG9uIGFuIElQc2VjIGNvbm5lY3Rp b24gYXMgd2VsbC4uLg0KDQo+IFRoZXJlIGFyZSBubyBwcm90b2NvbCBjaGFuZ2VzIHJlcXVpcmVk IHRvIG1ha2UgdGhpcyBoYXBwZW47IHlvdSBqdXN0IG5lZWQgdG8gdXNlIHRoZSBpbmZvcm1hdGlv biB5b3UgYWxyZWFkeSBoYXZlLg0KDQpCeSBub3QgaGF2aW5nIFRDUCBwcm90ZWN0aW9uIGFuZCBU TFMgb3J0aG9nb25hbCB3ZSBhcmUgbWl4aW5nIHNlY3VyaXR5IG1lY2hhbmlzbXMgYXQgdHdvIGRp ZmZlcmVudCBsYXllcnMsIGFuZCBhc3N1bWluZyB0aGVyZSBpcyBzb21lIGtpbmQgb2YgY3Jvc3Mt bGF5ZXIgZXhjaGFuZ2UgdGhhdCBtYXkgbm90IG5lY2Vzc2FyaWx5IGhhcHBlbiBiZWNhdXNlIGlz IG91dCBvZiB0aGUgY29tbW9uIHByYWN0aWNlLCBhbmQgdGhhdCBpcyBhIHJlY2lwZSBmb3Igc2Vj dXJpdHkgaG9sZXMuDQoNCk1heWJlIHRoYXQgdGhlIGN1cnJlbnQgd3JpdGluZyBvZiB0aGUgUENF UFMgZHJhZnQgaXMgbm90IGNsZWFyIGVub3VnaCBpbiB0aGF0IHJlc3BlY3QuIFdlIHdvdWxkIHJl YWxseSBhcHByZWNpYXRlIGFueSBzdWdnZXN0aW9uIGluIGltcHJvdmluZyBpdC4NCg0KQmUgZ29v ZGUsDQoNCi0tDQoiRXN0YSB2ZXogbm8gZmFsbGFyZW1vcywgRG9jdG9yIEluZmllcm5vIg0KDQpE ciBEaWVnbyBSLiBMb3Bleg0KVGVsZWZvbmljYSBJK0QNCmh0dHA6Ly9wZW9wbGUudGlkLmVzL2Rp ZWdvLmxvcGV6Lw0KDQplLW1haWw6IGRpZWdvQHRpZC5lcw0KVGVsOiAgICArMzQgOTEzIDEyOSAw NDENCk1vYmlsZTogKzM0IDY4MiAwNTEgMDkxDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkVz dGUgbWVuc2FqZSBzZSBkaXJpZ2UgZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8uIFB1 ZWRlIGNvbnN1bHRhciBudWVzdHJhIHBvbMOtdGljYSBkZSBlbnbDrW8geSByZWNlcGNpw7NuIGRl IGNvcnJlbyBlbGVjdHLDs25pY28gZW4gZWwgZW5sYWNlIHNpdHVhZG8gbcOhcyBhYmFqby4NClRo aXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBleGNsdXNpdmVseSBmb3IgaXRzIGFkZHJlc3NlZS4gV2Ug b25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0 IG91dCBhdDoNCmh0dHA6Ly93d3cudGlkLmVzL0VTL1BBR0lOQVMvZGlzY2xhaW1lci5hc3B4DQo= From touch@isi.edu Tue Feb 11 06:53:11 2014 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 04F611A03E6 for ; Tue, 11 Feb 2014 06:53:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 Loxouii8jCVB for ; Tue, 11 Feb 2014 06:53:08 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 074E21A042A for ; Tue, 11 Feb 2014 06:52:54 -0800 (PST) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s1BEqBBG013201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 11 Feb 2014 06:52:15 -0800 (PST) Message-ID: <52FA391E.5010000@isi.edu> Date: Tue, 11 Feb 2014 06:52:14 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Diego R. Lopez" References: <07b801cf1534$bec46b60$3c4d4220$@olddog.co.uk> <4698EB6C-9BEC-4E76-8291-FBCA51753950@tid.es> <52F401A1.7040209@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Tue, 11 Feb 2014 07:17:36 -0800 Cc: "pce@ietf.org" Subject: Re: [Pce] Use of TCP AO and TLS in PCEP 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, 11 Feb 2014 14:53:11 -0000 On 2/11/2014 6:26 AM, Diego R. Lopez wrote: > Hi Joe, > > Too much travel making my email backlog grow, I'm afraid... > > On 6 Feb 2014, at 22:41 , Joe Touch wrote: >>> The rationale is the common practice derived from the TLS layered >>> approach, so a client knows how and when require the server to start a >>> TLS connection, and the server knows in advance what the client is >>> requiring and match it against its policy. >> >> That is common when there is no other way to determine whether a connection uses TLS or not (and even then is at best a performance optimization). > > I'd say is not only performance, but a security optimization. Unless > the server is sure that starting a TLS session is explicitly required by > the client, how can a server know whether there has been an intentional > downgrade by a man-in-the-middle? It cannot, but let's look at the case where there are different ports. The MITM in that case can rewrite packets to the different port. Same problem. The conclusion is that the server cannot know about the downgrade until the connection fails because the MITM can't spoof the server's TLS credentials back to the client. > Furthermore, the client and server > codes become completely independent of what happens at the TCP layer, > and I think this is in general a good design practice. Ports are a critical global community resource, not a programming convenience. > And even if you find counterarguments to the two reasons above, the > common practice is the use of either a dedicated port or a dedicated > command. We should be aiming for best practice, not common practice. > And that implies that developers will find plenty of choices to > implement this, widely validated and understood by the community. And > when it comes to security, this is of great value, mostly when PCEP peer > developers will not usually be security experts. Agreed, but they need to be protocol experts or they won't get the protocols right. If they do get the protocols right, then they can trivially determine the type of connection - at connection start - simply from the configuration of keys. >> The use of TCP protection must be orthogonal to the use of TLS, so it >>> can not be used for the server making a guess of the protocol >>> security encapsulation. >> >> TCP protection isn't orthogonal to TLS for pcep as currently specified; see the table above. The only connections that can use TLS would be those that do not use TCP MD5 (see the list of cases above). >> >>> Either we have a protocol-specific mechanism (a-la-STARTTLS) or we >>> usea specific port. >> ... >> >> For every connection, you already know the mode before the >> connectionstarts. If the connection is configured to require TCP MD5, then there >> is no TLS. If not, then there must be TLS. > > What I cannot see is why the combination of TCP MD5 with TLS could > nothappen, It isn't specified, therefore you can say that if it happens you can cancel the connection attempt. > or the combination of TCP AO without TLS. Same thing. > We are talking about > independent layers, or am I missing something? FWIW, you could use any > of them on an IPsec connection as well... You could, but they should all fail except the ones that you specify. That's a basic tenet of security design. This is why I concluded that the protocol specifications - existing and the one currently under review - are easily distinguished. Ports are assigned for current use, not potential future use. So unless you're proposing to revise the doc to include these other cases, they're irrelevant. And if you are, we can then talk about whether it's good security design to consider so may alternatives without specific use cases in mind. >> There are no protocol changes required to make this happen; you >> just need to use the information you already have. > > By not having TCP protection and TLS orthogonal we are mixing > securitymechanisms at two different layers, and assuming there is some kind of > cross-layer exchange that may not necessarily happen because is out of > the common practice, and that is a recipe for security holes. TCP is - and needs to be - aware of both TCP and TLS protection. It has to have all the information needed anyway. (yes, if we throw in other protocol layers here, that might not be true, but again we're talking about what has been proposed, not what might be). > Maybe that the current writing of the PCEPS draft is not clear > enough in that respect. We would really appreciate any suggestion in improving it. If you intend the protections to be orthogonal, you need to say that, and you need to justify why all possible combinations are needed. At that point I would argue against that set of combinations. Joe From diego@tid.es Wed Feb 12 03:07:30 2014 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 AF89D1A0951 for ; Wed, 12 Feb 2014 03:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.75 X-Spam-Level: X-Spam-Status: No, score=-4.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 4tAmeL5Uj5Yx for ; Wed, 12 Feb 2014 03:07:24 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id DCAC21A0942 for ; Wed, 12 Feb 2014 03:07:22 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0N0V00FD9QW8I2@tid.hi.inet> for pce@ietf.org; Wed, 12 Feb 2014 12:07:20 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 9B.5D.05896.8E55BF25; Wed, 12 Feb 2014 12:07:20 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0N0V00FD4QW8I2@tid.hi.inet> for pce@ietf.org; Wed, 12 Feb 2014 12:07:20 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.159]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.03.0158.001; Wed, 12 Feb 2014 12:06:48 +0100 Date: Wed, 12 Feb 2014 11:06:48 +0000 From: "Diego R. Lopez" In-reply-to: <52FA391E.5010000@isi.edu> X-Originating-IP: [10.95.64.115] To: Joe Touch Message-id: <64DDC060-5BFA-4BFD-B784-2C36E7FD6D39@tid.es> Content-id: <425873ED10BFDC4C85BAB3EBE1868565@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, es-ES Thread-topic: [Pce] Use of TCP AO and TLS in PCEP Thread-index: Ac8VNFeRvCG6i4qyTfiGqoE+7Nwh2wN2xWYAABscN4AA7CRfAAABAhcAACpztwA= X-AuditID: 0a5f4e69-b7f778e000001708-c3-52fb55e8e18b X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42Lhivcz1H0R+jvIoHWBvkXT/RvsDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKeLVrHkvBLsuKq9MvMDYw/jHvYuTkkBAwkdj16TM7hC0mceHe erYuRi4OIYFtjBL/7n5mhnC+MUpsO7YBKjOTUWLVj4UsIC0sAqoSO5+9YgWx2YDsR82/wUYJ CxhIzFj/jA3E5hRQl/h/cg4zxAoFiT/nHoP1igjISjz48wasnlnATeLv3L9g9bwClhJTFx5j gYibSbza+YsVIi4o8WPyPaA4B1BcXWLKlFyIEnGJ5tabUOWKEtMWNTCC2IxA49/Nn88KscpQ 4njbJai1fhIbzjZDfSwgsWTPeajTRCVePv7HCvHjBUaJpa37mCYwSsxCcsYsJGfMQjhjFpIz ZiE5YwEj6ypGseKkosz0jJLcxMycdAMjvYxMvcy81JJNjJC4y9zBuHynyiFGAQ5GJR5eBs9f QUKsiWXFlbmHGCU4mJVEeN8H/g4S4k1JrKxKLcqPLyrNSS0+xMjEwSnVwDjTZ1/Z5OT/PSJL XzE13ePSUvkQ6Cvn/7X1bmSIcOZfD+6ljCE/rt/LyzPffj3gi9b6B1zz+/ZtEmj/rnbvwy7O udZ2Vzxkb3h+nrhb4pWUqQ8r64+uJdOdCp245lWunHrO6+ruBJMpLXPb9q26I1Gum3r71X/7 j1M0U4Kat1a2rxcWPHJLgUmJpTgj0VCLuag4EQDcy3/3mQIAAA== References: <07b801cf1534$bec46b60$3c4d4220$@olddog.co.uk> <4698EB6C-9BEC-4E76-8291-FBCA51753950@tid.es> <52F401A1.7040209@isi.edu> <52FA391E.5010000@isi.edu> Cc: "pce@ietf.org" Subject: Re: [Pce] Use of TCP AO and TLS in PCEP 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: Wed, 12 Feb 2014 11:07:30 -0000 DQpPbiAxMSBGZWIgMjAxNCwgYXQgMTU6NTIgLCBKb2UgVG91Y2ggPHRvdWNoQGlzaS5lZHU+IHdy b3RlOg0KPj4gSSdkIHNheSBpcyBub3Qgb25seSBwZXJmb3JtYW5jZSwgYnV0IGEgc2VjdXJpdHkg b3B0aW1pemF0aW9uLiBVbmxlc3MNCj4+IHRoZSBzZXJ2ZXIgaXMgc3VyZSB0aGF0IHN0YXJ0aW5n IGEgVExTIHNlc3Npb24gaXMgZXhwbGljaXRseSByZXF1aXJlZCBieQ0KPj4gdGhlIGNsaWVudCwg aG93IGNhbiBhIHNlcnZlciBrbm93IHdoZXRoZXIgdGhlcmUgaGFzIGJlZW4gYW4gaW50ZW50aW9u YWwNCj4+IGRvd25ncmFkZSBieSBhIG1hbi1pbi10aGUtbWlkZGxlPw0KPg0KPiBJdCBjYW5ub3Qs IGJ1dCBsZXQncyBsb29rIGF0IHRoZSBjYXNlIHdoZXJlIHRoZXJlIGFyZSBkaWZmZXJlbnQgcG9y dHMuIFRoZSBNSVRNIGluIHRoYXQgY2FzZSBjYW4gcmV3cml0ZSBwYWNrZXRzIHRvIHRoZSBkaWZm ZXJlbnQgcG9ydC4gU2FtZSBwcm9ibGVtLg0KPg0KPiBUaGUgY29uY2x1c2lvbiBpcyB0aGF0IHRo ZSBzZXJ2ZXIgY2Fubm90IGtub3cgYWJvdXQgdGhlIGRvd25ncmFkZSB1bnRpbCB0aGUgY29ubmVj dGlvbiBmYWlscyBiZWNhdXNlIHRoZSBNSVRNIGNhbid0IHNwb29mIHRoZSBzZXJ2ZXIncyBUTFMg Y3JlZGVudGlhbHMgYmFjayB0byB0aGUgY2xpZW50Lg0KDQpHcmFudGVkLiBCdXQgcmVsYXlpbmcg YSBzZWN1cml0eSBkZWNpc2lvbiBhdCBvbmUgbGF5ZXIgb2YgdGhlIGNvbWJpbmF0aW9uIG9mIG90 aGVyIHVucmVsYXRlZCBvcHRpb25zIGF0IGFub3RoZXIgc3VwcG9ydGluZyBsYXllciBzZWVtcyBh biB1bm5lY2Vzc2FyeSBjb21wbGljYXRpb24sIGFuZCB0aGF0IGlzIGFnYWluc3QgZ29vZCBzZWN1 cml0eSBwcmFjdGljZS4NCg0KPiA+IEZ1cnRoZXJtb3JlLCB0aGUgY2xpZW50IGFuZCBzZXJ2ZXIN Cj4+IGNvZGVzIGJlY29tZSBjb21wbGV0ZWx5IGluZGVwZW5kZW50IG9mIHdoYXQgaGFwcGVucyBh dCB0aGUgVENQIGxheWVyLA0KPj4gYW5kIEkgdGhpbmsgdGhpcyBpcyBpbiBnZW5lcmFsIGEgZ29v ZCBkZXNpZ24gcHJhY3RpY2UuDQo+DQo+IFBvcnRzIGFyZSBhIGNyaXRpY2FsIGdsb2JhbCBjb21t dW5pdHkgcmVzb3VyY2UsIG5vdCBhIHByb2dyYW1taW5nIGNvbnZlbmllbmNlLg0KDQpJZiB0aGlz IHRoZSBnaXN0IG9mIHlvdXIgYXJndW1lbnQgb24gdGhlIGFkZGl0aW9uYWwgcG9ydCBpc3N1ZSwg SSBjYW4gdW5kZXJzdGFuZCBpdC4gQW5kIGlmIHJlc3RyaWN0aW5nIHRoZSBhbGxvY2F0aW9uIG9m IHNwZWNpZmljIHBvcnRzIGlzIGEgY29tbW9uIHZpZXcgd2l0aGluIHRoZSBjb21tdW5pdHkgd2Ug Y291bGQgYWRkcmVzcyB0aGUgc29sdXRpb24gYmFzZWQgb24gYSBzcGVjaWZpYyBjb21tYW5kLg0K DQo+PiBBbmQgZXZlbiBpZiB5b3UgZmluZCBjb3VudGVyYXJndW1lbnRzIHRvIHRoZSB0d28gcmVh c29ucyBhYm92ZSwgdGhlDQo+PiBjb21tb24gcHJhY3RpY2UgaXMgdGhlIHVzZSBvZiBlaXRoZXIg YSBkZWRpY2F0ZWQgcG9ydCBvciBhIGRlZGljYXRlZA0KPj4gY29tbWFuZC4NCj4NCj4gV2Ugc2hv dWxkIGJlIGFpbWluZyBmb3IgYmVzdCBwcmFjdGljZSwgbm90IGNvbW1vbiBwcmFjdGljZS4NCg0K SSBhbSBhZnJhaWQgSSBkbyBub3Qgc2VlIHdoeSBpbnRlcnR3aW5uaW5nIHR3byBsYXllcnMgaXMg YSBiZXN0IHByYWN0aWNlLi4uDQoNCg0KPj4gIEFuZCB0aGF0IGltcGxpZXMgdGhhdCBkZXZlbG9w ZXJzIHdpbGwgZmluZCBwbGVudHkgb2YgY2hvaWNlcyB0bw0KPj4gaW1wbGVtZW50IHRoaXMsIHdp ZGVseSB2YWxpZGF0ZWQgYW5kIHVuZGVyc3Rvb2QgYnkgdGhlIGNvbW11bml0eS4gQW5kDQo+PiB3 aGVuIGl0IGNvbWVzIHRvIHNlY3VyaXR5LCB0aGlzIGlzIG9mIGdyZWF0IHZhbHVlLCBtb3N0bHkg d2hlbiBQQ0VQIHBlZXINCj4+IGRldmVsb3BlcnMgd2lsbCBub3QgdXN1YWxseSBiZSBzZWN1cml0 eSBleHBlcnRzLg0KPg0KPiBBZ3JlZWQsIGJ1dCB0aGV5IG5lZWQgdG8gYmUgcHJvdG9jb2wgZXhw ZXJ0cyBvciB0aGV5IHdvbid0IGdldCB0aGUgcHJvdG9jb2xzIHJpZ2h0LiBJZiB0aGV5IGRvIGdl dCB0aGUgcHJvdG9jb2xzIHJpZ2h0LCB0aGVuIHRoZXkgY2FuIHRyaXZpYWxseSBkZXRlcm1pbmUg dGhlIHR5cGUgb2YgY29ubmVjdGlvbiAtIGF0IGNvbm5lY3Rpb24gc3RhcnQgLSBzaW1wbHkgZnJv bSB0aGUgY29uZmlndXJhdGlvbiBvZiBrZXlzLg0KDQpGcm9tIGluZm9ybWF0aW9uIGRlcml2ZWQg ZnJvbSBhbm90aGVyIGxheWVyIHRoZXkgc2hvdWxkIG5vdCBiZSBjb25jZXJuZWQgd2l0aC4gSWYg dGhlcmUgd2VyZSBubyBvdGhlciBmZWFzaWJsZSBjaG9pY2VzLCBJJ2QgZ28gZm9yIGl0LiBCdXQg dGhlcmUgYXJlLCB3aXRoIHdpZGUgc3VwcG9ydCBhbmQgdGhvcm91Z2ggc2Nhbm5pbmcgZm9yIHNl Y3VyaXR5IGZsYXdzLg0KDQo+PiBXZSBhcmUgdGFsa2luZyBhYm91dA0KPj4gaW5kZXBlbmRlbnQg bGF5ZXJzLCBvciBhbSBJIG1pc3Npbmcgc29tZXRoaW5nPyBGV0lXLCB5b3UgY291bGQgdXNlIGFu eQ0KPj4gb2YgdGhlbSBvbiBhbiBJUHNlYyBjb25uZWN0aW9uIGFzIHdlbGwuLi4NCj4NCj4gWW91 IGNvdWxkLCBidXQgdGhleSBzaG91bGQgYWxsIGZhaWwgZXhjZXB0IHRoZSBvbmVzIHRoYXQgeW91 IHNwZWNpZnkuIFRoYXQncyBhIGJhc2ljIHRlbmV0IG9mIHNlY3VyaXR5IGRlc2lnbi4NCj4NCj4g VGhpcyBpcyB3aHkgSSBjb25jbHVkZWQgdGhhdCB0aGUgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbnMg LSBleGlzdGluZyBhbmQgdGhlIG9uZSBjdXJyZW50bHkgdW5kZXIgcmV2aWV3IC0gYXJlIGVhc2ls eSBkaXN0aW5ndWlzaGVkLiBQb3J0cyBhcmUgYXNzaWduZWQgZm9yIGN1cnJlbnQgdXNlLCBub3Qg cG90ZW50aWFsIGZ1dHVyZSB1c2UuDQo+DQo+IFNvIHVubGVzcyB5b3UncmUgcHJvcG9zaW5nIHRv IHJldmlzZSB0aGUgZG9jIHRvIGluY2x1ZGUgdGhlc2Ugb3RoZXIgY2FzZXMsIHRoZXkncmUgaXJy ZWxldmFudC4gQW5kIGlmIHlvdSBhcmUsIHdlIGNhbiB0aGVuIHRhbGsgYWJvdXQgd2hldGhlciBp dCdzIGdvb2Qgc2VjdXJpdHkgZGVzaWduIHRvIGNvbnNpZGVyIHNvIG1heSBhbHRlcm5hdGl2ZXMg d2l0aG91dCBzcGVjaWZpYyB1c2UgY2FzZXMgaW4gbWluZC4NCg0KVGhlIGRvY3VtZW50IGlzIHJl dmlzZWQgKGluIHZlcnNpb24gLTAxKSB0byBzYXkgdGhhdCBUQ1AgcHJvdGVjdGlvbiBtZWNoYW5p c21zIGFuZCBUTFMgdXNhZ2UgYXJlIG9ydGhvZ29uYWwsIHNvIEkgZG9uJ3Qgc2VlIHRoZSBuZWVk IHRvIGNvbnNpZGVyIGFsbCBvciBhbnkgb2YgdGhlIGFsdGVybmF0aXZlcyB0aGF0IGFyaXNlIGZy b20gdGhlaXIgY29tYmluYXRpb24NCg0KPj4+IFRoZXJlIGFyZSBubyBwcm90b2NvbCBjaGFuZ2Vz IHJlcXVpcmVkIHRvIG1ha2UgdGhpcyBoYXBwZW47IHlvdQ0KPj4+IGp1c3QgIG5lZWQgdG8gdXNl IHRoZSBpbmZvcm1hdGlvbiB5b3UgYWxyZWFkeSBoYXZlLg0KPj4NCj4+IEJ5IG5vdCBoYXZpbmcg VENQIHByb3RlY3Rpb24gYW5kIFRMUyBvcnRob2dvbmFsIHdlIGFyZSBtaXhpbmcNCj4+IHNlY3Vy aXR5bWVjaGFuaXNtcyBhdCB0d28gZGlmZmVyZW50IGxheWVycywgYW5kIGFzc3VtaW5nIHRoZXJl IGlzIHNvbWUga2luZCBvZg0KPj4gY3Jvc3MtbGF5ZXIgZXhjaGFuZ2UgdGhhdCBtYXkgbm90IG5l Y2Vzc2FyaWx5IGhhcHBlbiBiZWNhdXNlIGlzIG91dCBvZg0KPj4gdGhlIGNvbW1vbiBwcmFjdGlj ZSwgYW5kIHRoYXQgaXMgYSByZWNpcGUgZm9yIHNlY3VyaXR5IGhvbGVzLg0KPg0KPiBUQ1AgaXMg LSBhbmQgbmVlZHMgdG8gYmUgLSBhd2FyZSBvZiBib3RoIFRDUCBhbmQgVExTIHByb3RlY3Rpb24u IEl0IGhhcyB0byBoYXZlIGFsbCB0aGUgaW5mb3JtYXRpb24gbmVlZGVkIGFueXdheS4NCg0KVENQ IHNob3VsZCBiZSB0b3RhbGx5IG9ibGl2aW91cyB0byB0aGUgZmFjdCBUTFMgaXMgdXNlZCBhYm92 ZSBpdCwgaW4gdGhlIHNhbWUgc2Vuc2UgdGhhdCBUTFMgaXMgb2JsaXZpb3VzIHRvIHRoZSBwYXJ0 aWN1bGFyIFRDUCBvcHRpb25zIGluIHVzZS4gQW5kIHRoZSBzYW1lIGhhcHBlbnMgd2l0aCBQQ0VQ IHdpdGggcmVzcGVjdCB0byBib3RoIG9mIHRoZW0uDQoNCj4+IE1heWJlIHRoYXQgdGhlIGN1cnJl bnQgd3JpdGluZyBvZiB0aGUgUENFUFMgZHJhZnQgaXMgbm90IGNsZWFyDQo+PiBlbm91Z2ggIGlu IHRoYXQgcmVzcGVjdC4gV2Ugd291bGQgcmVhbGx5IGFwcHJlY2lhdGUgYW55IHN1Z2dlc3Rpb24g aW4NCj4gaW1wcm92aW5nIGl0Lg0KPg0KPiBJZiB5b3UgaW50ZW5kIHRoZSBwcm90ZWN0aW9ucyB0 byBiZSBvcnRob2dvbmFsLCB5b3UgbmVlZCB0byBzYXkgdGhhdCwgYW5kIHlvdSBuZWVkIHRvIGp1 c3RpZnkgd2h5IGFsbCBwb3NzaWJsZSBjb21iaW5hdGlvbnMgYXJlIG5lZWRlZC4gQXQgdGhhdCBw b2ludCBJIHdvdWxkIGFyZ3VlIGFnYWluc3QgdGhhdCBzZXQgb2YgY29tYmluYXRpb25zLg0KDQpB cyBJIHNhaWQgYmVmb3JlLCBpbiB2ZXJzaW9uIC0wMSBvcnRob2dvbmFsaXR5IGlzIGRlY2xhcmVk LiBBbmQgc2luY2UgdGhleSBhcmUgZGVjbGFyZWQgb3J0aG9nb25hbCBJIGRvbid0IHNlZSB0aGUg bmVlZCBmb3IgYW5hbHl6aW5nIHRoZSBkaWZmZXJlbnQgY29tYmluYXRpb25zLCBmb3IgdGhlIHNh bWUgcmVhc29uIEkgZG9uJ3Qgc2VlIHRoZSBuZWVkIG9mIGRpc2N1c3NpbmcgYWJvdXQgcnVubmlu ZyBQQ0VQUyBvbiBwdWJsaWMgb3IgcHJpdmF0ZSBJUCBhZGRyZXNzaW5nLCB0byBnaXZlIGFuIGV4 YW1wbGUuDQoNCkJlIGdvb2RlLA0KDQotLQ0KIkVzdGEgdmV6IG5vIGZhbGxhcmVtb3MsIERvY3Rv ciBJbmZpZXJubyINCg0KRHIgRGllZ28gUi4gTG9wZXoNClRlbGVmb25pY2EgSStEDQpodHRwOi8v cGVvcGxlLnRpZC5lcy9kaWVnby5sb3Blei8NCg0KZS1tYWlsOiBkaWVnb0B0aWQuZXMNClRlbDog ICAgKzM0IDkxMyAxMjkgMDQxDQpNb2JpbGU6ICszNCA2ODIgMDUxIDA5MQ0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KDQpFc3RlIG1lbnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEgc3Ug ZGVzdGluYXRhcmlvLiBQdWVkZSBjb25zdWx0YXIgbnVlc3RyYSBwb2zDrXRpY2EgZGUgZW52w61v IHkgcmVjZXBjacOzbiBkZSBjb3JyZW8gZWxlY3Ryw7NuaWNvIGVuIGVsIGVubGFjZSBzaXR1YWRv IG3DoXMgYWJham8uDQpUaGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkgZm9yIGl0 cyBhZGRyZXNzZWUuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMg b2YgdGhlIHRlcm1zIHNldCBvdXQgYXQ6DQpodHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJTkFTL2Rp c2NsYWltZXIuYXNweA0K From touch@isi.edu Wed Feb 12 07:55:41 2014 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 F0CAE1A0545 for ; Wed, 12 Feb 2014 07:55:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 qfMyCGpxl6Xg for ; Wed, 12 Feb 2014 07:55:39 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 725FC1A0547 for ; Wed, 12 Feb 2014 07:55:39 -0800 (PST) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s1CFtAUS013853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 12 Feb 2014 07:55:13 -0800 (PST) Message-ID: <52FB9962.1040200@isi.edu> Date: Wed, 12 Feb 2014 07:55:14 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Diego R. Lopez" References: <07b801cf1534$bec46b60$3c4d4220$@olddog.co.uk> <4698EB6C-9BEC-4E76-8291-FBCA51753950@tid.es> <52F401A1.7040209@isi.edu> <52FA391E.5010000@isi.edu> <64DDC060-5BFA-4BFD-B784-2C36E7FD6D39@tid.es> In-Reply-To: <64DDC060-5BFA-4BFD-B784-2C36E7FD6D39@tid.es> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Wed, 12 Feb 2014 08:27:21 -0800 Cc: "pce@ietf.org" Subject: Re: [Pce] Use of TCP AO and TLS in PCEP 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: Wed, 12 Feb 2014 15:55:41 -0000 On 2/12/2014 3:06 AM, Diego R. Lopez wrote: >> Ports are a critical global community resource, not a programming convenience. > > If this the gist of your argument on the additional port issue, I can > understand it. FWIW, it is. Joe > And if restricting the allocation of specific ports is > a common view within the community we could address the solution > based on a specific command. From adrian@olddog.co.uk Thu Feb 13 04:07:11 2014 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 738401A0208 for ; Thu, 13 Feb 2014 04:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.217 X-Spam-Level: X-Spam-Status: No, score=0.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77] 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 a_b0cNBJbg_j for ; Thu, 13 Feb 2014 04:07:09 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id C313C1A020A for ; Thu, 13 Feb 2014 04:07:08 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s1DC75o8006506; Thu, 13 Feb 2014 12:07:05 GMT Received: from 950129200 (108.26.90.92.rev.sfr.net [92.90.26.108]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s1DC72P1006471 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Feb 2014 12:07:04 GMT From: "Adrian Farrel" To: Date: Thu, 13 Feb 2014 12:07:01 -0000 Message-ID: <08fc01cf28b4$1bb980c0$532c8240$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8otAzR5+agsJk2SAm+aKc50HaWKQ== Content-Language: en-gb Cc: draft-farrkingel-pce-abno-architecture@tools.ietf.org Subject: [Pce] Last chance for PCE review of draft-farrkingel-pce-abno-architecture X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 12:07:11 -0000 Hi PCE, Dan and I think that this draft is almost ready to be published as an RFC so we are calling for review and input. Comments on the list or direct to the authors at draft-farrkingel-pce-abno-architecture@tools.ietf.org Thanks! Adrian > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: 13 February 2014 11:50 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-farrkingel-pce-abno-architecture-07.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : A PCE-based Architecture for Application-based Network > Operations > Authors : Daniel King > Adrian Farrel > Filename : draft-farrkingel-pce-abno-architecture-07.txt > Pages : 62 > Date : 2014-02-13 > > Abstract: > Services such as content distribution, distributed databases, or > inter-data center connectivity place a set of new requirements on the > operation of networks. They need on-demand and application-specific > reservation of network connectivity, reliability, and resources (such > as bandwidth) in a variety of network applications (such as point-to- > point connectivity, network virtualization, or mobile back-haul) and > in a range of network technologies from packet (IP/MPLS) down to > optical. An environment that operates to meet this type of > requirement is said to have Application-Based Network Operations > (ABNO). > > ABNO brings together many existing technologies for gathering > information about the resources available in a network, for > consideration of topologies and how those topologies map to > underlying network resources, for requesting path computation, and > for provisioning or reserving network resources. Thus, ABNO may be > seen as the use of a toolbox of existing components enhanced with a > few new elements. The key component within an ABNO is the Path > Computation Element (PCE), which can be used for computing paths and > is further extended to provide policy enforcement capabilities for > ABNO. > > This document describes an architecture and framework for ABNO > showing how these components fit together. It provides a cookbook of > existing technologies to satisfy the architecture and meet the needs > of the applications. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-farrkingel-pce-abno-architecture/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-farrkingel-pce-abno-architecture-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-farrkingel-pce-abno-architecture-07 From vlopez@tid.es Thu Feb 13 08:02:48 2014 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 0CF1E1A0311 for ; Thu, 13 Feb 2014 08:02:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.75 X-Spam-Level: X-Spam-Status: No, score=-4.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 dF16NoNQMqIH for ; Thu, 13 Feb 2014 08:02:45 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id A1D9E1A0300 for ; Thu, 13 Feb 2014 08:02:44 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0N0X00HMSZ8G2M@tid.hi.inet> for pce@ietf.org; Thu, 13 Feb 2014 17:02:42 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id F0.AE.05896.2ACECF25; Thu, 13 Feb 2014 17:02:42 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0N0X00HMZZ8H2M@tid.hi.inet> for pce@ietf.org; Thu, 13 Feb 2014 17:02:42 +0100 (MET) Received: from EX10-MB1-MAD.hi.inet ([169.254.1.201]) by EX10-HTCAS6-MAD.hi.inet ([::1]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 17:02:42 +0100 Date: Thu, 13 Feb 2014 16:02:40 +0000 From: Victor Lopez In-reply-to: <20140212195836.25824.39777.idtracker@ietfa.amsl.com> X-Originating-IP: [10.95.64.115] To: Pce Message-id: Content-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: es-ES Content-transfer-encoding: quoted-printable Accept-Language: es-ES, en-US Thread-topic: New Version Notification for draft-lopez-pce-hpce-ted-01.txt Thread-index: AQHPKCzWusNPig0OzUaWZ7HCGfboG5qzWa+A user-agent: Microsoft-MacOutlook/14.3.9.131030 X-AuditID: 0a5f4e69-b7f778e000001708-5e-52fceca22d27 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsXCFe9nqLvozZ8gg47VYhZN92+wOzB6LFny kymAMYrLJiU1J7MstUjfLoErY8GzfUwFx0Qq5r1qZG1gPCvQxcjJISFgItG35jMjhC0mceHe ejYQW0hgG6PE79V8XYxcQPY3RokdC2+xQTgzGSX2vuhg72Lk4GARUJXY/cYSpIFNQEliw7Y9 YM3CAp4S6353gA3lFHCS2Hr2DBvEAgWJP+ces4C0igAta//qAjKSWWAWo8TVxQuYQWp4BbQk Vj66DmYzC5hJPN/6jwUiLijxY/I9Foi4jkTv929QNeISc35NZIWwtSWevLsAZjMKyEqsPH8a 7AYRAS+JG0fXMUPYRhKPX/4Du0dUQE/i3qO5LBC3CUgs2XOeGcIWlXj5+B8rJCAcJf42Xmae wCg5C8lJs5CcNAvJSbOQnDQLyUkLGFlXMYoVJxVlpmeU5CZm5qQbGOllZOpl5qWWbGKERGPm DsblO1UOMQpwMCrx8Ho8+BMkxJpYVlyZe4hRgoNZSYQ3/AhQiDclsbIqtSg/vqg0J7X4ECMT B6dUAyN/ku68erXzoSe/7+Hmdk8W3/Ps4nJBttC9+WyZb0Of3Y+48a2jV/rEyqSLC7V2tmgL BNW6fA5pfXErqIFB4s7P250LxDqn3S/U+Hj8hav0R8bbJYtqMtoFGjJsFGezLPJLtGvge/ZD ofhtzZuHxmvuCCjlWR3j2X5j2YOqsBpRkdlK2y50iSuxFGckGmoxFxUnAgB574OQpAIAAA== References: <20140212195836.25824.39777.idtracker@ietfa.amsl.com> Subject: [Pce] FW: New Version Notification for draft-lopez-pce-hpce-ted-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: Thu, 13 Feb 2014 16:02:48 -0000 Dear all, We have updated the draft with the feedback we received from the PCE Mailing list. Moreover, as proposed by the PCE WG, we will distribute the draft in the IDR mailing list to know the opinion of the working group. Comments are welcome Victor, Oscar, Daniel and Stefano El 12/02/14 20:58, "internet-drafts@ietf.org" escribi=F3: > >A new version of I-D, draft-lopez-pce-hpce-ted-01.txt >has been successfully submitted by Victor Lopez and posted to the >IETF repository. > >Name: draft-lopez-pce-hpce-ted >Revision: 01 >Title: Traffic Engineering Database dissemination for Hierarchical= PCE >scenarios >Document date: 2014-02-11 >Group: Individual Submission >Pages: 11 >URL: >http://www.ietf.org/internet-drafts/draft-lopez-pce-hpce-ted-01.txt >Status: https://datatracker.ietf.org/doc/draft-lopez-pce-hpce-ted/ >Htmlized: http://tools.ietf.org/html/draft-lopez-pce-hpce-ted-01 >Diff: >http://www.ietf.org/rfcdiff?url2=3Ddraft-lopez-pce-hpce-ted-01 > >Abstract: > The PCE architecture is well-defined and may be used to compute the > optimal path for LSPS across domains in MPLS-TE and GMPLS networks. > The Hierarchical Path Computation Element (H-PCE) [RFC6805] was > developed to provide an optimal path when the sequence of domains is > not known in advance. The procedure and mechanism for populating the > Traffic Engineering Database (TED) with domain topology and link > information used in H-PCE-based path computations is open to > interpretation. This informational document describes how topology > dissemination mechanisms may be used to provide TE information > between Parent and Child PCEs (within the H-PCE context). In > particular, it describes how BGP-LS might be used to provide inter- > domain connectivity. This document is not intended to define new > extensions, it demonstrates how existing procedures and mechanisms > may be used. > > > > > >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. > >The IETF Secretariat > ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx From nobody Thu Feb 13 14:48:26 2014 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 020081A044D for ; Thu, 13 Feb 2014 14:48:23 -0800 (PST) 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, 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 qWbJTfYLiey1 for ; Thu, 13 Feb 2014 14:48:19 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 479101A04E4 for ; Thu, 13 Feb 2014 14:48:19 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-3a-52fd4bb22092 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id D2.7E.11484.2BB4DF25; Thu, 13 Feb 2014 23:48:18 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0387.000; Thu, 13 Feb 2014 17:48:17 -0500 From: Uma Chunduri To: Victor Lopez , Pce Thread-Topic: [Pce] FW: New Version Notification for draft-lopez-pce-hpce-ted-01.txt Thread-Index: AQHPKCzWusNPig0OzUaWZ7HCGfboG5qzWa+AgABuNkA= Date: Thu, 13 Feb 2014 22:48:16 +0000 Message-ID: <1B502206DFA0C544B7A60469152008633F1AF800@eusaamb105.ericsson.se> References: <20140212195836.25824.39777.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyuXRPrO4m779BBrf7LC2a7t9gt5jR5eLA 5LFkyU8mjyd/tzAHMEVx2aSk5mSWpRbp2yVwZRzp3c5c8F26Ynffb9YGxhtiXYycHBICJhKz 21cwQ9hiEhfurWfrYuTiEBI4wiix49UpdghnOaPEodvbWUGq2AT0JD5O/ckOYosAde95M5sJ xBYWCJXo/XyTBSIeJrGlcSOUbSWx9vlHMJtFQFXi9I1ZYNt4BXwlLv5rALOFBJIk3sy9ywhi cwpoS0zePAEszgh00fdTa8DmMwuIS9x6Mp8J4lIBiSV7zkNdLSrx8vE/VghbSWLS0nOsEPV6 EjemTmGDsLUlli18DbVXUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnFyFFanFqWm25kuIkR GA3HJNgcdzAu+GR5iFGag0VJnPfLW+cgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYw6Ak1V tVoK6ze2rNp/rX1GZPe7B2Lapc//3bNffEFaImmOX0jAyr1ByQ6b56femX9z+ye5wLs8h3I2 9V820GqK99WveD7zp3VlhRf7nVKuJydE5+iqO4dcqPB9yiC0NO3Lp/oLiucXP1hx90xe9qMf 1s/ma35TDnH90NnF/vAmZ6Py7Y/b355QYinOSDTUYi4qTgQAm4aEF1QCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/pce/zEFQgupfoNKpW_Xv793tDo3pGnI Subject: Re: [Pce] FW: New Version Notification for draft-lopez-pce-hpce-ted-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: Thu, 13 Feb 2014 22:48:23 -0000 Dear Authors, Is it possible that TED may not be shared between 2 providers (even with BG= P-LS and with restricted policy, for security reasons) and=20 you still might have to resort to PCEP notification message? So essentially single provide with multiple areas/ASes can have a controlle= r (with pPCE) and=20 need hybrid model as specified above to solve inter controller communicatio= n ? Do you have plans to extend this document to cover this or the model repres= ented in this document already covered this case? Can you comment? -- Uma C. -----Original Message----- From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Victor Lopez Sent: Thursday, February 13, 2014 8:03 AM To: Pce Subject: [Pce] FW: New Version Notification for draft-lopez-pce-hpce-ted-01= .txt Dear all, We have updated the draft with the feedback we received from the PCE Mailin= g list. Moreover, as proposed by the PCE WG, we will distribute the draft i= n the IDR mailing list to know the opinion of the working group. Comments are welcome Victor, Oscar, Daniel and Stefano El 12/02/14 20:58, "internet-drafts@ietf.org" escribi=F3: > >A new version of I-D, draft-lopez-pce-hpce-ted-01.txt has been=20 >successfully submitted by Victor Lopez and posted to the IETF=20 >repository. > >Name: draft-lopez-pce-hpce-ted >Revision: 01 >Title: Traffic Engineering Database dissemination for Hierarchical= PCE >scenarios >Document date: 2014-02-11 >Group: Individual Submission >Pages: 11 >URL: >http://www.ietf.org/internet-drafts/draft-lopez-pce-hpce-ted-01.txt >Status: https://datatracker.ietf.org/doc/draft-lopez-pce-hpce-ted/ >Htmlized: http://tools.ietf.org/html/draft-lopez-pce-hpce-ted-01 >Diff: >http://www.ietf.org/rfcdiff?url2=3Ddraft-lopez-pce-hpce-ted-01 > >Abstract: > The PCE architecture is well-defined and may be used to compute the > optimal path for LSPS across domains in MPLS-TE and GMPLS networks. > The Hierarchical Path Computation Element (H-PCE) [RFC6805] was > developed to provide an optimal path when the sequence of domains is > not known in advance. The procedure and mechanism for populating the > Traffic Engineering Database (TED) with domain topology and link > information used in H-PCE-based path computations is open to > interpretation. This informational document describes how topology > dissemination mechanisms may be used to provide TE information > between Parent and Child PCEs (within the H-PCE context). In > particular, it describes how BGP-LS might be used to provide inter- > domain connectivity. This document is not intended to define new > extensions, it demonstrates how existing procedures and mechanisms > may be used. > > > > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at=20 >tools.ietf.org. > >The IETF Secretariat > ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From nobody Thu Feb 13 16:40:37 2014 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 D3EEF1A0007; Thu, 13 Feb 2014 16:40:32 -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 9uXM9TfD95v1; Thu, 13 Feb 2014 16:40:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0923F1A0031; Thu, 13 Feb 2014 16:40:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214004030.19264.75953.idtracker@ietfa.amsl.com> Date: Thu, 13 Feb 2014 16:40:30 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/qTGQeS68N8ovYj8fKzi-v9RrdLg Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-gmpls-pcep-extensions-09.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: Fri, 14 Feb 2014 00:40:33 -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 Working Group of the IETF. Title : PCEP extensions for GMPLS Authors : Cyril Margaria Oscar Gonzalez de Dios Fatai Zhang Filename : draft-ietf-pce-gmpls-pcep-extensions-09.txt Pages : 35 Date : 2014-02-13 Abstract: This memo provides extensions for the Path Computation Element communication Protocol (PCEP) for the support of GMPLS control plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-pcep-extensions/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-gmpls-pcep-extensions-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-gmpls-pcep-extensions-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 Thu Feb 13 18:44:13 2014 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 336531A0033 for ; Thu, 13 Feb 2014 18:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.748 X-Spam-Level: X-Spam-Status: No, score=-3.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 SqG4BzNAaEnp for ; Thu, 13 Feb 2014 18:44:10 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DCFCD1A002D for ; Thu, 13 Feb 2014 18:44:09 -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 BBC33157; Fri, 14 Feb 2014 02:44:08 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Feb 2014 02:42:54 +0000 Received: from lggeml407-hub.china.huawei.com (10.72.61.85) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Feb 2014 02:43:12 +0000 Received: from HTIPL8571 (10.195.42.142) by lggeml407-hub.china.huawei.com (10.72.61.85) with Microsoft SMTP Server id 14.3.158.1; Fri, 14 Feb 2014 10:43:07 +0800 From: Dhruv Dhody To: Date: Fri, 14 Feb 2014 08:13:00 +0530 Message-ID: <010b01cf292e$7bd70fc0$73852f40$@dhody@huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_010C_01CF295C.958F4BC0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8pLnmaXe8VSvXsSMCb1ruZ24RGGQ== Content-Language: en-us X-Originating-IP: [10.195.42.142] X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pce/gzcRmNu9ljnr2U5HaezXiYZJVy4 Subject: [Pce] Update in Stateful PCE P2MP drafts. 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, 14 Feb 2014 02:44:13 -0000 ------=_NextPart_000_010C_01CF295C.958F4BC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi WG, We have uploaded an updated version to the Stateful PCE P2MP drafts based on discussions. - Co-authors from NTT - Clarify the role of PLSP-ID in P2MP - The format for P2MP LSP IDENTIFIERS TLV are updated - A new S2L object - PCRpt message format to include S2L object along with END-POINTS - Grouping of leaves based on operational status and END-POINT's leaf-type. - Add/pruning of leaves for PCE-Initiated P2MP LSP Please continue to provide us with your feedback and comments. Name: draft-palle-pce-stateful-pce-p2mp Revision: 02 Title: Path Computation Element (PCE) Protocol Extensions for Stateful PCE usage for Point-to-Multipoint Traffic Engineering Label Switched Paths Document date: 2014-02-14 Group: Individual Submission Pages: 20 URL: http://www.ietf.org/internet-drafts/draft-palle-pce-stateful-pce-p2mp-02.txt Status: https://datatracker.ietf.org/doc/draft-palle-pce-stateful-pce-p2mp/ Htmlized: http://tools.ietf.org/html/draft-palle-pce-stateful-pce-p2mp-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-palle-pce-stateful-pce-p2mp-02 Name: draft-palle-pce-stateful-pce-initiated-p2mp-lsp Revision: 01 Title: PCEP Extensions for PCE-initiated Point-to-Multipoint LSP Setup in a Stateful PCE Model Document date: 2014-02-14 Group: Individual Submission Pages: 11 URL: http://www.ietf.org/internet-drafts/draft-palle-pce-stateful-pce-initiated-p 2mp-lsp-01.txt Status: https://datatracker.ietf.org/doc/draft-palle-pce-stateful-pce-initiated-p2mp -lsp/ Htmlized: http://tools.ietf.org/html/draft-palle-pce-stateful-pce-initiated-p2mp-lsp-0 1 Diff: http://www.ietf.org/rfcdiff?url2=draft-palle-pce-stateful-pce-initiated-p2mp -lsp-01 Regards, Dhruv ------=_NextPart_000_010C_01CF295C.958F4BC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = WG,

 

We have uploaded an = updated version to the Stateful PCE P2MP drafts based on = discussions.

 

-    Co-authors from = NTT

-    Clarify the role of = PLSP-ID in P2MP

-    The format for P2MP = LSP IDENTIFIERS TLV are updated

-    A new S2L object =

-    PCRpt message = format to include S2L object along with = END-POINTS

-    Grouping of leaves = based on operational status and END-POINT’s leaf-type. =

-    Add/pruning of = leaves for PCE-Initiated P2MP LSP

 

Please continue to = provide us with your feedback and comments.

 

Name:     =       draft-palle-pce-stateful-pce-p2mp
Revision: =       02
Title:          Path = Computation Element (PCE) Protocol Extensions for Stateful PCE usage for = Point-to-Multipoint Traffic Engineering Label Switched Paths
Document = date:  2014-02-14
Group:         =  Individual Submission
Pages:         =  20
URL:            http://www.ietf.org/internet-drafts/draft-palle-pce-sta= teful-pce-p2mp-02.txt
Status:         https://datatracker.ietf.org/doc/draft-palle-pce-statef= ul-pce-p2mp/
Htmlized:       http://tools.ietf.org/html/draft-palle-pce-stateful-pce= -p2mp-02
Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-palle-pce-stat= eful-pce-p2mp-02

 

Name:     =       = draft-palle-pce-stateful-pce-initiated-p2mp-lsp
Revision:   =     01
Title:          PCEP = Extensions for PCE-initiated Point-to-Multipoint LSP Setup in a Stateful = PCE Model
Document date:  2014-02-14
Group:     =      Individual Submission
Pages:       =    11
URL:            http://www.ietf.org/internet-drafts/draft-palle-pce-sta= teful-pce-initiated-p2mp-lsp-01.txt
Status:       =   https://datatracker.ietf.org/doc/draft-palle-pce-statef= ul-pce-initiated-p2mp-lsp/
Htmlized:       http://tools.ietf.org/html/draft-palle-pce-stateful-pce= -initiated-p2mp-lsp-01
Diff:           = http://www.ietf.org/rfcdiff?url2=3Ddraft-palle-pce-stat= eful-pce-initiated-p2mp-lsp-01

 

Regards,

Dhruv

------=_NextPart_000_010C_01CF295C.958F4BC0-- From nobody Fri Feb 14 01:05:31 2014 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 27FFD1A01AD for ; Fri, 14 Feb 2014 01:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 cb9Jj6o0xZTM for ; Fri, 14 Feb 2014 01:05:27 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1D61A011E for ; Fri, 14 Feb 2014 01:05:26 -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 BBD00641; Fri, 14 Feb 2014 09:05:24 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Feb 2014 09:04:49 +0000 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Feb 2014 09:05:08 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Fri, 14 Feb 2014 17:05:00 +0800 From: Qin Wu To: "pce@ietf.org" Thread-Topic: I-D Action: draft-wu-pce-traffic-steering-sfc-03.txt Thread-Index: AQHPKWLY8ErCKRAdCUuJJZZhyojtdZq0c5nQ Date: Fri, 14 Feb 2014 09:04:58 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pce/0e5ZajxvneHe069MzFvLVDGc4zg Subject: [Pce] FW: I-D Action: draft-wu-pce-traffic-steering-sfc-03.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: Fri, 14 Feb 2014 09:05:29 -0000 Hi, folks: Here is a new draft. http://tools.ietf.org/html/draft-wu-pce-traffic-steering-sfc-03 This draft specifies extensions to the Path Computation Element Protocol (PCEP) that allow a stateful PCE to compute and instantiate Service Function Paths (SFP). We appreciate it if you spend some time to review this draft. Regards! -Qin -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Friday, February 14, 2014 4:58 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-wu-pce-traffic-steering-sfc-03.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : PCEP Extensions for traffic steering support in S= ervice Function Chaining Authors : Qin Wu Dhruv Dhody Mohamed Boucadair Christian Jacquenet Jeff Tantsura Filename : draft-wu-pce-traffic-steering-sfc-03.txt Pages : 10 Date : 2014-02-14 Abstract: This document provides an overview of the usage of Path Computation Element (PCE) with Service Function Chaining (SFC); which is described as the definition and instantiation of an ordered set of such service functions (such as firewalls, load balancers), and the subsequent "steering" of traffic flows through those service functions. Further this document specifies extensions to the Path Computation Element Protocol (PCEP) that allow a stateful PCE to compute and instantiate Service Function Paths (SFP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-wu-pce-traffic-steering-sfc/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-wu-pce-traffic-steering-sfc-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-wu-pce-traffic-steering-sfc-03 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/ _______________________________________________ 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 Fri Feb 14 02:23:24 2014 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 5CCA51A0202 for ; Fri, 14 Feb 2014 02:23:23 -0800 (PST) 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, 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 9n615VvuQe6G for ; Fri, 14 Feb 2014 02:23:21 -0800 (PST) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id B195A1A01C3 for ; Fri, 14 Feb 2014 02:23:20 -0800 (PST) Received: by mail-we0-f178.google.com with SMTP id q59so8694370wes.9 for ; Fri, 14 Feb 2014 02:23:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=6HxAcG9xtvRI5fJlyTV9LeHbZfHhzLMm3jcjzaQVQws=; b=rXZhfIsRqjBzYh78vcmSx/522hJ6CWJtF569BRz4ZM4b0q4M6SbJKYY2Id+ryesINh gaXnOzYvRb8xgGvARJnoYSpGbWpiPInzUEwo2waG5955bDdCRWSrxUPoW/0ahVgZmXtr 3lJ5ZbR8r5JzaWzEpbqTuxH6i8mCoGmjfFKeADoLVLFGPzrJlkhvHo9O3piChkEJ50CR JkcmbO1YocY7g7ESyoceeJMYQOqYN4bD6+pae/0b6KVtwkdgviS7EHzAOadGY5s5k91b 343OViy3PMqTeSjKQMV22Y8jvIgrNMksLrwZATxD5DmKtdO2GyXFpqdPonRPPPhpfftW 2HWQ== MIME-Version: 1.0 X-Received: by 10.194.85.168 with SMTP id i8mr85307wjz.81.1392373398817; Fri, 14 Feb 2014 02:23:18 -0800 (PST) Received: by 10.216.61.12 with HTTP; Fri, 14 Feb 2014 02:23:18 -0800 (PST) Date: Fri, 14 Feb 2014 11:23:18 +0100 Message-ID: From: Cyril Margaria To: "pce@ietf.org" Content-Type: multipart/alternative; boundary=089e010d7efcd4cff704f25b312e Archived-At: http://mailarchive.ietf.org/arch/msg/pce/1aEnDehpMEB5N0u-iz6rNVBluA0 Subject: [Pce] Calling for PCE WG review, draft-ietf-pce-gmpls-pcep-extensions-09.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: Fri, 14 Feb 2014 10:23:23 -0000 --089e010d7efcd4cff704f25b312e Content-Type: text/plain; charset=ISO-8859-1 Hi PCErs, The Authors think that this document is ready for last call. We are calling for review and comments. This revision addressed all the comments raised since the document is stable. Those can be summarized as follows: - RG flag semantic allowing easier checks and verifications. - Remove the need of extra object definition for GMPLS Bw encoding - Simplify object presence rules for asymmetric bandwidth - GMPLS extension can be negotiated on session opening, for early detection. Comments are welcomed on the list or to the authors: draft-ietf-pce-gmpls-pcep-extensions@tools.ietf.org Best Regards, ---------- Forwarded message ---------- From: Date: 14 February 2014 01:40 Subject: I-D Action: draft-ietf-pce-gmpls-pcep-extensions-09.txt To: i-d-announce@ietf.org Cc: pce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : PCEP extensions for GMPLS Authors : Cyril Margaria Oscar Gonzalez de Dios Fatai Zhang Filename : draft-ietf-pce-gmpls-pcep-extensions-09.txt Pages : 35 Date : 2014-02-13 Abstract: This memo provides extensions for the Path Computation Element communication Protocol (PCEP) for the support of GMPLS control plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-pcep-extensions/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-gmpls-pcep-extensions-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-gmpls-pcep-extensions-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/ _______________________________________________ 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 --089e010d7efcd4cff704f25b312e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi PCErs,

The Autho= rs think that this document is ready for last call. We are calling for revi= ew and comments.

This revision addressed all the comments rais= ed since the document is stable. Those can be summarized as follows:

=A0- RG flag semantic allowing easier checks and verificatio= ns.
=A0- Remove the need of extra object definition for GMPLS Bw e= ncoding
=A0- Simplify object presence rules for asymmetric bandwid= th
=A0- GMPLS extension can be negotiated on session opening, for early = detection.


Comments are welcomed o= n the list or to the authors:
draft-ietf-pce-gmpls-pcep-extensions@tools.iet= f.org

Best Regards,


---------- Forwarded message ----------
Fr= om: <internet-drafts@ietf.org>
Date: 14 February 2014 01:40
Subject: I-D Action: draft-ietf-pce-gmpls-p= cep-extensions-09.txt
To: i-d-a= nnounce@ietf.org
Cc: pce@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Path Computation Element Working Group = of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : PCEP extensions for GMPLS
=A0 =A0 =A0 =A0 Authors =A0 =A0 =A0 =A0 : Cyril Margaria
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Oscar Gonzalez de Dios<= br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fatai Zhang
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-pce-gmpls-pcep-extensi= ons-09.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 35
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-02-13

Abstract:
=A0 =A0This memo provides extensions for the Path Computation Element
=A0 =A0communication Protocol (PCEP) for the support of GMPLS control plane= .


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-g= mpls-pcep-extensions/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-pce-gmpls-pcep-= extensions-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf= -pce-gmpls-pcep-extensions-09


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/

_______________________________________________
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

--089e010d7efcd4cff704f25b312e-- From nobody Fri Feb 14 07:48:07 2014 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 777481A02D2; Fri, 14 Feb 2014 07:48:01 -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 Ljy3VIbD0dcT; Fri, 14 Feb 2014 07:47:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F241A02C3; Fri, 14 Feb 2014 07:47:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214154757.13468.81640.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 07:47:57 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/xi6habmJb4x4kBGWnN7Pt1oqiXc Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-stateful-pce-08.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: Fri, 14 Feb 2014 15:48:02 -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 Working Group of the IETF. Title : PCEP Extensions for Stateful PCE Authors : Edward Crabbe Jan Medved Ina Minei Robert Varga Filename : draft-ietf-pce-stateful-pce-08.txt Pages : 47 Date : 2014-02-13 Abstract: The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-pce-08 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 Feb 14 08:27:16 2014 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 3A0041A02CC for ; Fri, 14 Feb 2014 08:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, 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 3A5pnDpfA1FC for ; Fri, 14 Feb 2014 08:27:11 -0800 (PST) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 6CAD71A02D7 for ; Fri, 14 Feb 2014 08:27:11 -0800 (PST) Received: by mail-oa0-f42.google.com with SMTP id i7so14903907oag.29 for ; Fri, 14 Feb 2014 08:27:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=N5mO0URitblUP5Ayt4efkymCFygJpnVDDfXkM456u4Q=; b=ARqFA9DasafSdZZ7VzbW1CdloxBfURtzXNY3igj+oyOFtpJD/eYXkyFA1aJCVsPHNp 6bNskvqQVi/+QqQN9xx7B9H8oUUFYyvRsTP2bVv6gRIqeP3oXYCAfYguFkjjIrLyy4rL 11ED/ksOf4OZAITnuth/C5dOV3pf9vBwiEMxnRGgnlCDD0fcl4D4i2qnHT5f1pSgrxUG edlnIj+NmML6JPiF3G+NFlwQzykBZ2DIh0NsDHVRlTTd+6RP3sqVLbNzo3IhVQCT/nuw 26xwgnOxIemR7ZK2d2p6M9oPKTDYUziGRkhht4Xs/aE+EzjNSteo9JYtf/d7hgHHH/af JD1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=N5mO0URitblUP5Ayt4efkymCFygJpnVDDfXkM456u4Q=; b=C686mV0y5RLz6Gb6kYTvzvtWcMag6aZpghqRypps3AhyWnJZkNJ8/+HgNNnOZr/pAK uo5m2wH1qpeoKzk95yjDaBUsIi3QJGxWRr2/HUbkyTOHRnGpoT09hBppBtMHsW+yomHY 2BSCit1XeChFt13zJ+OA7rwGJzKtRAI3VnYHHttVrA0M3k+7V2XOjjUtN12zWPHKDplO 6HAfD3RMUQwx3pkeaQ2aNv3zd6e3c6H2JvcPWcmVfGAUIecLrow4jc6Jorvx7GTV36Yq gMT9W82q+Qp+mKCE8yldhR80gOWE63gdrbTQH8nsI3wYHogsXECU616WyTj4WZG1Zhnm /gkQ== X-Gm-Message-State: ALoCoQlTi6zARjG1eKCC405pkUxxwuzV5uWJ5JTSLHQX4cAZ6EdD0jZf+F8w567sLlAUHgHR/5CtDeyyFuDBbzooqq9BA/qjjkRGw2VKczO6HtuFb6JYNJ9ZiljvAC0CZfzX32n9WmZ6sqRvkZyO1k4bXuBUe/wFSOPbdc90ZRwWU5gqsH0CswqzTOQOFkjOTivHS+c9Lzn8 MIME-Version: 1.0 X-Received: by 10.182.243.138 with SMTP id wy10mr1110536obc.83.1392395229724; Fri, 14 Feb 2014 08:27:09 -0800 (PST) Received: by 10.182.80.106 with HTTP; Fri, 14 Feb 2014 08:27:09 -0800 (PST) Date: Fri, 14 Feb 2014 08:27:09 -0800 Message-ID: From: Ina Minei To: pce Content-Type: multipart/alternative; boundary=001a11c2a1200e176004f26047bf Archived-At: http://mailarchive.ietf.org/arch/msg/pce/KVmnSBIn7pDZHgdihF0PnVIf4B8 Subject: [Pce] Please send review/comments on draft-ietf-pce-stateful-pce-08.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: Fri, 14 Feb 2014 16:27:14 -0000 --001a11c2a1200e176004f26047bf Content-Type: text/plain; charset=UTF-8 Dear working group, The authors believe this draft is stable and almost ready for last call, and would like to solicit last input/review from the working group. The changes in version 08 are mostly editorial/cleanup. This document contains the core functionality for stateful PCE, which has now been stable for a while and is implemented by multiple vendors. Other extensions and optimizations are defined in other documents, which can progress independently. Please send your review/comments to the list or directly to the authors, we would like to progress this document. Given that many of you have commented on this functionality in the past, we will assume silence to mean agreement. Thank you, Ina, Ed, Jan and Robert On Fri, Feb 14, 2014 at 7:47 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Path Computation Element Working Group > of the IETF. > > Title : PCEP Extensions for Stateful PCE > Authors : Edward Crabbe > Jan Medved > Ina Minei > Robert Varga > Filename : draft-ietf-pce-stateful-pce-08.txt > Pages : 47 > Date : 2014-02-13 > > Abstract: > The Path Computation Element Communication Protocol (PCEP) provides > mechanisms for Path Computation Elements (PCEs) to perform path > computations in response to Path Computation Clients (PCCs) requests. > > Although PCEP explicitly makes no assumptions regarding the > information available to the PCE, it also makes no provisions for PCE > control of timing and sequence of path computations within and across > PCEP sessions. This document describes a set of extensions to PCEP > to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-08 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-pce-08 > > > 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/ > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > --001a11c2a1200e176004f26047bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Dear working group,=C2=A0

The aut= hors believe this draft is stable and almost ready for last call, and would= like to solicit last input/review from the working group.=C2=A0

The changes= in version 08 are mostly editorial/cleanup. This document contains the cor= e functionality for stateful PCE, which has now been stable for a while and= is implemented by multiple vendors. Other extensions and optimizations are= defined in other documents, which can progress independently.

Please send= your review/comments to the list or directly to the authors, we would like= to progress this document. Given that many of you have commented on this f= unctionality in the past, we will assume silence to mean agreement.=C2=A0

Thank you,= =C2=A0

Ina, Ed, Jan and Robert

On Fri, Feb 14, = 2014 at 7:47 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Path Computation Element Working Gro= up of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PCEP= Extensions for Stateful PCE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Edward Cr= abbe
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Jan Medved
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Ina Minei
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Robert Varga
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-iet= f-pce-stateful-pce-08.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 47 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2014-02-13

Abstract:
=C2=A0 =C2=A0The Path Computation Element Communication Protocol (PCEP) pro= vides
=C2=A0 =C2=A0mechanisms for Path Computation Elements (PCEs) to perform pat= h
=C2=A0 =C2=A0computations in response to Path Computation Clients (PCCs) re= quests.

=C2=A0 =C2=A0Although PCEP explicitly makes no assumptions regarding the =C2=A0 =C2=A0information available to the PCE, it also makes no provisions = for PCE
=C2=A0 =C2=A0control of timing and sequence of path computations within and= across
=C2=A0 =C2=A0PCEP sessions. =C2=A0This document describes a set of extensio= ns to PCEP
=C2=A0 =C2=A0to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP.=



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-p= ce/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-08<= br>
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-stat= eful-pce-08


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
htt= ps://www.ietf.org/mailman/listinfo/pce

--001a11c2a1200e176004f26047bf-- From nobody Fri Feb 14 10:29:59 2014 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 AA7001A033C; Fri, 14 Feb 2014 10:29:54 -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 Zwnhb6aekBOZ; Fri, 14 Feb 2014 10:29:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA171A020B; Fri, 14 Feb 2014 10:29:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214182951.22892.71325.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 10:29:51 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/BKgAJCyD_le5cfJ9uz1EwG1D71w Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-pcep-service-aware-03.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: Fri, 14 Feb 2014 18:29:55 -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 Working Group of the IETF. Title : Extensions to the Path Computation Element Communication Protocol (PCEP) to compute service aware Label Switched Path (LSP). Authors : Dhruv Dhody Vishwas Manral Zafar Ali George Swallow Kenji Kumaki Filename : draft-ietf-pce-pcep-service-aware-03.txt Pages : 18 Date : 2014-02-14 Abstract: In certain networks like financial information network (stock/ commodity trading) and enterprises using cloud based applications, Latency (delay), Latency-Variation (jitter) and Packet Loss is becoming a key requirement for path computation along with other constraints and metrics. Latency, Latency-Variation and Packet Loss is associated with the Service Level Agreement (SLA) between customers and service providers. [OSPF-TE-EXPRESS] and [ISIS-TE-EXPRESS] describes mechanisms with which network performance information is distributed via OSPF and ISIS respectively. 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. This document describes the extension to PCEP to carry Latency, Latency-Variation and Packet Loss as constraints for end to end path computation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-service-aware/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-pcep-service-aware-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-service-aware-03 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 Feb 14 10:35:12 2014 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 F08741A020B for ; Fri, 14 Feb 2014 10:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, 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 WbFZIcRGLTAh for ; Fri, 14 Feb 2014 10:35:07 -0800 (PST) Received: from ENFIRHETS1.metaswitch.com (enfirhets1.metaswitch.com [192.91.191.166]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2C81A0267 for ; Fri, 14 Feb 2014 10:35:07 -0800 (PST) Received: from ENFICSCAS1.datcon.co.uk (172.18.4.13) by ENFIRHETS1.metaswitch.com (172.18.209.22) with Microsoft SMTP Server (TLS) id 14.3.174.1; Fri, 14 Feb 2014 18:34:58 +0000 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFICSCAS1.datcon.co.uk ([fe80::3d12:12a9:26af:c7%11]) with mapi id 14.03.0174.001; Fri, 14 Feb 2014 18:35:04 +0000 From: Jonathan Hardwick To: "draft-minei-pce-stateful-sync-optimizations@tools.ietf.org" Thread-Topic: Comments on draft-minei-pce-stateful-sync-optimizations-01 Thread-Index: Ac8ps3n6I0/p/UTJSj24UQQcD8tDLA== Date: Fri, 14 Feb 2014 18:35:04 +0000 Message-ID: <09CE6C3BE5E1EA40B987BF5F25D8DDBAE13416C9@ENFICSMBX1.datcon.co.uk> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.34.170] Content-Type: multipart/alternative; boundary="_000_09CE6C3BE5E1EA40B987BF5F25D8DDBAE13416C9ENFICSMBX1datco_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/rboiHSDDjaE2E2scYs4N1s4ki90 Cc: "pce@ietf.org" Subject: [Pce] Comments on draft-minei-pce-stateful-sync-optimizations-01 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, 14 Feb 2014 18:35:11 -0000 --_000_09CE6C3BE5E1EA40B987BF5F25D8DDBAE13416C9ENFICSMBX1datco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi there I have reviewed this draft - here are my comments. Best regards Jon Section 3.2 Figure 2, I think the "sync done" PCRpt should have SYNC=3D0, not SYNC=3D1. Section 5.2 If a PCC has to force full LSP DB synchronization due to reasons including but not limited: (1) local policy configured at the PCC; (2) no sufficient LSP state caches for incremental update, the PCC can set the D flag to 0. Perhaps I have misunderstood, but I think case (2) above doesn't work. The= PCC does not know that it has "no sufficient LSP state caches" until it re= ceives the OPEN from the PCE and sees what DBv the PCE has sent. By then, = the PCC has already sent its OPEN so it is too late to set D=3D0. To cover= case (2) the draft needs a mechanism for the PCC to change its mind and te= ll the PCE that it is going to send a full snapshot, not a replay of the mi= ssing database updates. The simplest thing is probably for the PCC to brin= g the session down and then bring it back up again with D=3D0. Section 4 talks about the PCE having to mark its LSP database as stale, and= then remove any stale LSPs at the end of the synchronization process. I a= ssume that this does not apply in section 5. To avoid confusion, I think s= ection 5 should state that the PCE does not mark its LSP database as stale = if both it and the PCC have set D=3D1. In figure 7, I may have misunderstood section 4, but I don't think this is = how the T bit is specified. I don't think T=3D1 forces the PCC to wait for= a PCUpd before sending the initial snapshot as you have shown. I don't th= ink this substantially changes anything about section 5, so I suggest remov= ing the discussion of the T bit from section 5. --_000_09CE6C3BE5E1EA40B987BF5F25D8DDBAE13416C9ENFICSMBX1datco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi there

 

I have reviewed this draft – here are my comme= nts.

 

Best regards

Jon

 

Section 3.2

Figure 2, I think the “sync done” PCRpt = should have SYNC=3D0, not SYNC=3D1.

 

Section 5.2

   If a PCC has to force full LSP DB<= /span>

   synchronization due to reasons including but = not limited: (1) local

   policy configured at the PCC; (2) no sufficie= nt LSP state caches for

   incremental update, the PCC can set the D fla= g to 0.

 

Perhaps I have misunderstood, but I think case (2) a= bove doesn’t work.  The PCC does not know that it has “no = sufficient LSP state caches” until it receives the OPEN from the PCE = and sees what DBv the PCE has sent.  By then, the PCC has already sent its OPEN so it is too late to set D=3D0.  To cover case = (2) the draft needs a mechanism for the PCC to change its mind and tell the= PCE that it is going to send a full snapshot, not a replay of the missing = database updates.  The simplest thing is probably for the PCC to bring the session down and then bring it back up a= gain with D=3D0.

 

Section 4 talks about the PCE having to mark its LSP= database as stale, and then remove any stale LSPs at the end of the synchr= onization process.  I assume that this does not apply in section 5.&nb= sp; To avoid confusion, I think section 5 should state that the PCE does not mark its LSP database as stale if both it and = the PCC have set D=3D1.

 

In figure 7, I may have misunderstood section 4, but= I don’t think this is how the T bit is specified.  I don’= t think T=3D1 forces the PCC to wait for a PCUpd before sending the initial= snapshot as you have shown.  I don’t think this substantially changes anything about section 5, so I suggest removing the discussion of = the T bit from section 5.

--_000_09CE6C3BE5E1EA40B987BF5F25D8DDBAE13416C9ENFICSMBX1datco_-- From nobody Fri Feb 14 11:21:38 2014 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 172431A02E9 for ; Fri, 14 Feb 2014 11:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.431 X-Spam-Level: X-Spam-Status: No, score=-1.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, 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 iRnlwAp3SeO0 for ; Fri, 14 Feb 2014 11:21:33 -0800 (PST) Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 94B921A0045 for ; Fri, 14 Feb 2014 11:21:32 -0800 (PST) Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3DC06DE4004 for ; Fri, 14 Feb 2014 20:23:14 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.orange.com (Postfix) with ESMTP id 31FA8DE4002 for ; Fri, 14 Feb 2014 20:23:14 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Feb 2014 20:21:27 +0100 Received: from renot.local ([10.193.116.12]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Feb 2014 20:21:28 +0100 Message-ID: <52FE6CB7.3030905@orange.com> Date: Fri, 14 Feb 2014 20:21:27 +0100 From: Olivier Dugeon Organization: France Telecom R&D User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "pce@ietf.org" References: <20140214191300.5423.83278.idtracker@ietfa.amsl.com> In-Reply-To: <20140214191300.5423.83278.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140214191300.5423.83278.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------020006070708050206050203" X-OriginalArrivalTime: 14 Feb 2014 19:21:29.0048 (UTC) FILETIME=[F6089580:01CF29B9] Archived-At: http://mailarchive.ietf.org/arch/msg/pce/kYRbgFZL34CRJEGARltdmhelJUc Subject: [Pce] Fwd: New Version Notification for draft-dugeon-pce-ted-reqs-03.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: Fri, 14 Feb 2014 19:21:35 -0000 This is a multi-part message in MIME format. --------------020006070708050206050203 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, We have update the draft with comments we received from PCEr's Main change are: - Take into various comments about the domain/foreign/neighbour terminology. Finally choose 'remote' to federate the different cases - Update figure and add an example for Grey-Box model - Add more reference to BGP-LS - Add new reference to draft-farrel-interconnected-te-info-exchange-02.txt for TE exchange at inter-domain - Add new section about operational & synchronisation issue with reference to draft-clemm-netmod-yang-network-topo-01.txt for the database model. Comments are welcome Olivier et al. -------- Message original -------- Sujet: New Version Notification for draft-dugeon-pce-ted-reqs-03.txt Date : Fri, 14 Feb 2014 11:13:00 -0800 De : Pour : Oscar Gonzalez de Dios , Julien Meuric , Richard Douville , Olivier Dugeon , Olivier Dugeon , Oscar Gonzalez de Dios , Ramon Casellas , Richard Douville , Ramon Casellas , Julien Meuric A new version of I-D, draft-dugeon-pce-ted-reqs-03.txt has been successfully submitted by Olivier Dugeon and posted to the IETF repository. Name: draft-dugeon-pce-ted-reqs Revision: 03 Title: Path Computation Element (PCE) Database Requirements Document date: 2014-02-14 Group: Individual Submission Pages: 18 URL: http://www.ietf.org/internet-drafts/draft-dugeon-pce-ted-reqs-03.txt Status: https://datatracker.ietf.org/doc/draft-dugeon-pce-ted-reqs/ Htmlized: http://tools.ietf.org/html/draft-dugeon-pce-ted-reqs-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-dugeon-pce-ted-reqs-03 Abstract: The Path Computation Element (PCE) working group (WG) has produced a set of RFCs to standardize the behavior of the Path Computation Element as a tool to help MPLS-TE and GMPLS LSP tunnels placement. In the PCE architecture, a main assumption has been done concerning the information that the PCE needs to perform its computation. In a fist approach, the PCE embeds a Traffic Engineering Database (TED) containing all pertinent and suitable information regarding the network that is in the scope of a PCE. Nevertheless, the TED requirements as well as the TED information have not yet been formalized. In addition, some recent RFC (like the Backward Recursive Path Computation procedure or PCE Hierarchy) or WG draft (like draft-ietf-pce-stateful-pce ...) suffer from a lack of information in the TED, leading to a non optimal result or to some difficulties to deploy them. This memo tries to identify some Database, at large, requirements for the PCE. It is split in two main sections: the identification of the specific information to be stored in the PCE Database and how it may be populated. 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. The IETF Secretariat --------------020006070708050206050203 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear all,

We have update the draft with comments we received from PCEr's

Main change are:
=C2=A0- Take into various comments about the domain/foreign/neighbo= ur terminology. Finally choose 'remote' to federate the different cases
=C2=A0- Update figure and add an example for Grey-Box model
=C2=A0- Add more reference to BGP-LS
=C2=A0- Add new reference to draft-farrel-interconnected-te-info-exchange-02.txt for TE exchange at inter-domain
=C2=A0- Add new section about operational & synchronisation iss= ue with reference to draft-clemm-netmod-yang-network-topo-01.txt for the database model.

Comments are welcome

Olivier et al.

-------- Message original --------
Suj= et: New Version Notification for draft-dugeon-pce-ted-reqs-03.txt
Dat= e=C2=A0: Fri, 14 Feb 2014 11:13:00 -0800
De=C2= =A0: <internet-drafts@ietf.org>
Pou= r=C2=A0: Oscar Gonzalez de Dios <ogondio@tid.es>, Julien Meuric <julien.meuric@orange.com>, Richard Dou= ville <richard.douville@alcatel-lucent.com>, Olivier Dugeon <olivier.dugeon@orange.com>, Olivier D= ugeon <olivier.dugeon@orange.com>, Oscar Gonzalez d= e Dios <ogondio@tid.es>, Ramon Casellas <ramon.casellas@cttc.es>, Richard Douville <richard.douville@alcatel-lucent.com>, Ramon Casellas <ramon.casellas@cttc.es>, Julien Meuric= <julien.meuric@orange.com> 


A new version of I-D, draft-dugeon-pce-ted-reqs-03.txt
has been successfully submitted by Olivier Dugeon and posted to the
IETF repository.

Name:		draft-dugeon-pce-ted-reqs
Revision:	03
Title:		Path Computation Element (PCE) Database Requirements
Document date:	2014-02-14
Group:		Individual Submission
Pages:		18
URL:            http://www.ietf.o=
rg/internet-drafts/draft-dugeon-pce-ted-reqs-03.txt
Status:         https://datatracker.ietf.o=
rg/doc/draft-dugeon-pce-ted-reqs/
Htmlized:       http://tools.ietf.org/html/dra=
ft-dugeon-pce-ted-reqs-03
Diff:           http://www.ietf.org/rf=
cdiff?url2=3Ddraft-dugeon-pce-ted-reqs-03

Abstract:
   The Path Computation Element (PCE) working group (WG) has produced a
   set of RFCs to standardize the behavior of the Path Computation
   Element as a tool to help MPLS-TE and GMPLS LSP tunnels placement.
   In the PCE architecture, a main assumption has been done concerning
   the information that the PCE needs to perform its computation.  In a
   fist approach, the PCE embeds a Traffic Engineering Database (TED)
   containing all pertinent and suitable information regarding the
   network that is in the scope of a PCE.  Nevertheless, the TED
   requirements as well as the TED information have not yet been
   formalized.  In addition, some recent RFC (like the Backward
   Recursive Path Computation procedure or PCE Hierarchy) or WG draft
   (like draft-ietf-pce-stateful-pce ...) suffer from a lack of
   information in the TED, leading to a non optimal result or to some
   difficulties to deploy them.  This memo tries to identify some
   Database, at large, requirements for the PCE.  It is split in two
   main sections: the identification of the specific information to be
   stored in the PCE Database and how it may be populated.


                                                                         =
        =20


Please note that it may take a couple of minutes from the time of submiss=
ion
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--------------020006070708050206050203-- From nobody Fri Feb 14 13:37:01 2014 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 60CF41A0357; Fri, 14 Feb 2014 13:36:57 -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 jCND9XtmMwQV; Fri, 14 Feb 2014 13:36:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C31D41A0342; Fri, 14 Feb 2014 13:36:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214213654.2926.32891.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 13:36:54 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/4W0fUCpg1hF3F0kX8nTghiXuq04 Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-hierarchy-extensions-01.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: Fri, 14 Feb 2014 21:36:57 -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 Working Group of the IETF. Title : Extensions to Path Computation Element Communication Protocol (PCEP) for Hierarchical Path Computation Elements (PCE) Authors : Fatai Zhang Quintin Zhao Oscar Gonzalez de Dios Ramon Casellas Daniel King Filename : draft-ietf-pce-hierarchy-extensions-01.txt Pages : 14 Date : 2014-02-14 Abstract: The Hierarchical Path Computation Element (H-PCE) architecture, provides a mechanism to allow the optimum sequence of domains to be selected,and the optimum end-to-end path to be derived through the use of a hierarchical relationship between domains. This document defines the Path Computation Element Protocol (PCEP) extensions for the purpose of implementing Hierarchical PCE procedures which are described in the aforementioned document. These extensions are experimental and published for examination, discussion, implementation, and evaluation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-hierarchy-extensions/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-hierarchy-extensions-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-hierarchy-extensions-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 Fri Feb 14 13:50:31 2014 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 6272B1A0449 for ; Fri, 14 Feb 2014 13:50:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_FILL_THIS_FORM_SHORT=0.01] 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 jmv15GuXOb_R for ; Fri, 14 Feb 2014 13:50:18 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id F07D31A0448 for ; Fri, 14 Feb 2014 13:50:05 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s1ELnoiR009851; Fri, 14 Feb 2014 21:49:50 GMT Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s1ELnne7009845 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Feb 2014 21:49:49 GMT From: "Daniel King" To: References: <20140214213654.2926.32891.idtracker@ietfa.amsl.com> In-Reply-To: <20140214213654.2926.32891.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 21:49:48 -0000 Message-ID: <070101cf29ce$af39b430$0dad1c90$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQLBH+jl7uQU0LRuhuLB1l2D5kj7x5jRWiBg Content-Language: en-ca Archived-At: http://mailarchive.ietf.org/arch/msg/pce/cs8L3hE0xBCf2UxwYqN2k_exQGE Cc: 'Quintin zhao' Subject: Re: [Pce] I-D Action: draft-ietf-pce-hierarchy-extensions-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: Fri, 14 Feb 2014 21:50:21 -0000 Hi All, A few discussion points for the H-PCE extensions I-D: 1. New OF: common transit domain diversity. Known as Minimize the number of Common Transit Domains (MCTD). Useful? The actual description/proposal is documented in http://tools.ietf.org/html/draft-dwpz-pce-domain-diverse-00#section-4.3. The authors are suggesting it might be more efficient to include directly into the H-PCE extensions I-D. 2. Implementation Experience? We are planning to add an "Implementation Experience" section, as per RFC6982. If you are prototyping/implementing it would be great if you can send me any details of implementation that you wish to share (via the I-D). Per RFC6982, the information I could use, includes: >> o The organization responsible for the implementation, if any. o The implementation's name and/or a link to a web page describing the implementation. o A brief general description. o The implementation's level of maturity: research, prototype, alpha, beta, production, widely used, etc. o Coverage: which parts of the protocol specification are implemented and which versions of the Internet-Draft were implemented. o Licensing: the terms under which the implementation can be used. For example: proprietary, royalty licensing, freely distributable with acknowledgement (BSD style), freely distributable with requirement to redistribute source (General Public License (GPL) style), and other (specify). o Implementation experience: any useful information the implementers want to share with the community. o Contact information: ideally a person's name and email address, but possibly just a URL or mailing list. In addition, this section can contain information about the interoperability of any or all of the implementations, including references to test-case descriptions and interoperability reports, when such exist. << Br, Dan & Authors -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: February 14, 2014 9:37 PM To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: I-D Action: draft-ietf-pce-hierarchy-extensions-01.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 Working Group of the IETF. Title : Extensions to Path Computation Element Communication Protocol (PCEP) for Hierarchical Path Computation Elements (PCE) Authors : Fatai Zhang Quintin Zhao Oscar Gonzalez de Dios Ramon Casellas Daniel King Filename : draft-ietf-pce-hierarchy-extensions-01.txt Pages : 14 Date : 2014-02-14 Abstract: The Hierarchical Path Computation Element (H-PCE) architecture, provides a mechanism to allow the optimum sequence of domains to be selected,and the optimum end-to-end path to be derived through the use of a hierarchical relationship between domains. This document defines the Path Computation Element Protocol (PCEP) extensions for the purpose of implementing Hierarchical PCE procedures which are described in the aforementioned document. These extensions are experimental and published for examination, discussion, implementation, and evaluation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-hierarchy-extensions/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-hierarchy-extensions-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-hierarchy-extensions-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/ _______________________________________________ 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 Sun Feb 16 20:09:36 2014 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 9E4191A0031 for ; Sun, 16 Feb 2014 20:09:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 GeqaHYJjtTr6 for ; Sun, 16 Feb 2014 20:09:24 -0800 (PST) Received: from mgw020.noc.ntt.com (mgw020.noc.ntt.com [210.160.55.2]) by ietfa.amsl.com (Postfix) with ESMTP id 367F81A0337 for ; Sun, 16 Feb 2014 20:09:24 -0800 (PST) Received: from c0044i0.coe.ntt.com (unknown [10.18.161.13]) by mgw020.noc.ntt.com (NTT Com MailSV) with ESMTP id C69ED4460637 for ; Mon, 17 Feb 2014 13:09:20 +0900 (JST) Received: from C0147I0.coe.ntt.com (10.18.160.111) by c0044i0.coe.ntt.com (10.18.161.13) with Microsoft SMTP Server (TLS) id 14.1.438.0; Mon, 17 Feb 2014 13:09:20 +0900 Received: from C0007I0.coe.ntt.com ([169.254.1.138]) by C0147I0.coe.ntt.com ([10.18.160.111]) with mapi id 14.01.0438.000; Mon, 17 Feb 2014 13:09:20 +0900 From: Yosuke Tanaka To: "pce@ietf.org" Thread-Topic: New Version Notification for draft-tanaka-pce-stateful-pce-data-ctrl-02.txt Thread-Index: AQHPKVlE1rL+zPays0ySLJyBHOkx+Jq40mpw Date: Mon, 17 Feb 2014 04:09:19 +0000 Message-ID: <4382467A240ADE4C8552523C24D51B5758043559@C0007I0.coe.ntt.com> References: <20140214074913.14643.84918.idtracker@ietfa.amsl.com> In-Reply-To: <20140214074913.14643.84918.idtracker@ietfa.amsl.com> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ccmail-original-to: pce@ietf.org x-originating-ip: [10.14.150.155] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/R2Kk6nJIg9wELUack_oUkIuqB08 Subject: [Pce] FW: New Version Notification for draft-tanaka-pce-stateful-pce-data-ctrl-02.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, 17 Feb 2014 04:09:28 -0000 SGkgUENFIFdHLA0KDQpXZSBoYXZlIHVwZGF0ZWQgZHJhZnQtdGFuYWthLXBjZS1zdGF0ZWZ1bC1w Y2UtZGF0YS1jdHJsLTAyIHdpdGggc29tZSBjaGFuZ2VzIGFzIGZvbGxvd3MuDQoNCk1haW4gY2hh bmdlcw0KIC0gRGhydXYgam9pbmVkIHRoaXMgZHJhZnQuDQogLSBBZGRlZCBMU1AtREFUQVNXSVRD SE9WRVItQkFMQU5DRS1DQVBBQklMSVRZIEZsYWcgaW4gT3BlbiBtZXNzYWdlLg0KIC0gQWRkZWQg cG9saWNpbmcgb3B0aW9ucyBpbiBzd2l0Y2hvdmVyL2xvYWQtYmFsYW5jaW5nLg0KIC0gQWRkZWQg YSBsb2FkLWJhbGFuY2Ugb3BlcmF0aW9uIGV4YW1wbGUuDQogLSBDaGFuZ2VkIHRoZSBBc3NvY2lh dGlvbi1Hcm91cCBJRCBsZW5ndGggZnJvbSAyIG9jdGV0cyB0byAzIG9jdGV0cy4NCg0KV2Ugd291 bGQgbGlrZSB0byBzb2xpY2l0IHJldmlld3MgZm9yIHRoaXMgZHJhZnQgYW5kIGZlZWRiYWNrcyBm cm9tIHRoZSBXRy4NCg0KUmVnYXJkcywNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZ10gDQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDE0LCAyMDE0IDQ6NDkgUE0NClN1YmplY3Q6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtdGFuYWthLXBjZS1zdGF0ZWZ1bC1w Y2UtZGF0YS1jdHJsLTAyLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC10YW5h a2EtcGNlLXN0YXRlZnVsLXBjZS1kYXRhLWN0cmwtMDIudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IFlvc3VrZSBUYW5ha2EgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBv c2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtdGFuYWthLXBjZS1zdGF0ZWZ1bC1wY2UtZGF0YS1jdHJs DQpSZXZpc2lvbjoJMDINClRpdGxlOgkJU3RhdGVmdWwgUENFIEV4dGVuc2lvbnMgZm9yIERhdGEg UGxhbmUgU3dpdGNob3ZlciBhbmQgQmFsYW5jaW5nDQpEb2N1bWVudCBkYXRlOgkyMDE0LTAyLTEz DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxOQ0KVVJMOiAgICAgICAg ICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXRhbmFrYS1wY2Ut c3RhdGVmdWwtcGNlLWRhdGEtY3RybC0wMi50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10YW5ha2EtcGNlLXN0YXRlZnVsLXBjZS1kYXRh LWN0cmwvDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt dGFuYWthLXBjZS1zdGF0ZWZ1bC1wY2UtZGF0YS1jdHJsLTAyDQpEaWZmOiAgICAgICAgICAgaHR0 cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtdGFuYWthLXBjZS1zdGF0ZWZ1bC1w Y2UtZGF0YS1jdHJsLTAyDQoNCkFic3RyYWN0Og0KICAgU3RhdGVmdWwgUGF0aCBDb21wdXRhdGlv biBFbGVtZW50IChQQ0UpIGFuZCBpdHMgY29ycmVzcG9uZGluZw0KICAgcHJvdG9jb2wgZXh0ZW5z aW9ucyBwcm92aWRlIGEgbWVjaGFuaXNtIHRoYXQgZW5hYmxlcyBQQ0UgdG8gZG8NCiAgIHN0YXRl ZnVsIGNvbnRyb2wgb2YgTXVsdGlwcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcgKE1QTFMpIFRyYWZm aWMNCiAgIEVuZ2luZWVyaW5nIExhYmVsIFN3aXRjaGVkIFBhdGhzIChURSBMU1ApLiAgT25lIGFw cGxpY2F0aW9uIHRoYXQNCiAgIHN0YXRlZnVsIFBDRSBjYW4gcmVhbGl6ZSBpcyBkYXRhIHRyYWZm aWMgcmVvcHRpbWl6YXRpb24gYW1vbmcgdGhlDQogICBMU1BzLiAgRGF0YSB0cmFmZmljIHRyYXZl cnNlZCBpbiBhIExTUCBjYW4gYmUgc3dpdGNoZWQgdG8gYW5vdGhlcg0KICAgUENFLWluaXRpYXRl ZCBMU1AuICBNb3Jlb3ZlciwgZGF0YSB0cmFmZmljIGNhbiBiZSBiYWxhbmNlZCB0bw0KICAgbXVs dGlwbGUgUENFLWluaXRpYXRlZCBMU1BzIGFuZCBtYXkgYWxzbyBiZSBwb2xpY2VkIGJhc2VkIG9u IGENCiAgIHNpZ25hbGluZyBiYW5kd2lkdGggb2YgYSBQQ0UtSW5pdGlhdGVkIExTUCB1c2luZyBz dGF0ZWZ1bCBQQ0UuDQoNCiAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHRoZSBleHRlbnNpb25z IHRvIFBhdGggQ29tcHV0YXRpb24gRWxlbWVudA0KICAgUHJvdG9jb2wgKFBDRVApIHRoYXQgYWxs b3cgYSBzdGF0ZWZ1bCBQQ0UgdG8gZG8gc3dpdGNob3ZlciwgYmFsYW5jaW5nDQogICBhbmQgcG9s aWNpbmcgb2YgZGF0YSB0cmFmZmljIHdpdGggUENFLWluaXRpYXRlZCBMU1BzLiAgVGhpcyBkb2N1 bWVudA0KICAgYWxzbyBzcGVjaWZpZXMgdGhlIGV4dGVuc2lvbnMsIHVzYWdlIGFuZCBoYW5kbGlu ZyBvZiBzdGF0ZWZ1bCBQQ0VQDQogICBtZXNzYWdlcyBhbmQgdGhlIGV4cGVjdGVkIGJlaGF2aW9y IG9mIFBDQyBhcyB0aGUgUlNWUC1URSBoZWFkZW5kLg0KDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVz IGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNy ZXRhcmlhdA0KDQo= From nobody Tue Feb 18 01:51:26 2014 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 118F01A0614 for ; Tue, 18 Feb 2014 01:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 Qf3ufJDcU0hh for ; Tue, 18 Feb 2014 01:51:22 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CB3981A0615 for ; Tue, 18 Feb 2014 01:51:21 -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 BDR98433; Tue, 18 Feb 2014 09:51:18 +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, 18 Feb 2014 09:51:00 +0000 Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 18 Feb 2014 09:51:08 +0000 Received: from SZXEMA504-MBX.china.huawei.com ([169.254.7.191]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Tue, 18 Feb 2014 17:51:01 +0800 From: Zhenghaomian To: "pce@ietf.org" Thread-Topic: New Version Notification for draft-zheng-pce-for-sdn-transport-00.txt Thread-Index: AQHPKaEaF6kfw9qC7k64hpfW7f6chZq6yjhQ Date: Tue, 18 Feb 2014 09:51:00 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.53.113] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pce/O3FQvy55NV-pO3E95SkAcLx2RzQ Subject: [Pce] FW: New Version Notification for draft-zheng-pce-for-sdn-transport-00.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, 18 Feb 2014 09:51:24 -0000 RGVhciBQQ0VycywNCg0KV2UgaGF2ZSB1cGxvYWRlZCBhIG5ldyBkcmFmdCB3aXRoIGRpc2N1c3Np b24gb24gdHJhbnNwb3J0IFNETiBhbmQgY3VycmVudCBQQ0UvUENFUC4gQSBmZXcgdHJhbnNwb3J0 IHVzZSBjYXNlcyBmb3IgU0ROIGFyZSBhbmFseXplZCBhbmQgaXQgaXMgZGVtb25zdHJhdGVkIHRo YXQgY3VycmVudCBQQ0UvUENFUCBjYW4gaGFuZGxlIHRoZSByZXF1aXJlbWVudHMgaW4gc3VjaCBh cHBsaWNhdGlvbnMuIFRoZSB1c2UgY2FzZXMgaW5jbHVkZToNCiAtIE9wdGljYWwgRW50ZXJwcmlz ZSBOZXR3b3JrOw0KIC0gVmlydHVhbGl6ZWQgVHJhbnNwb3J0IE5ldHdvcms7DQogLSBEYXRhIENl bnRlciBJbnRlcmNvbm5lY3Rpb247DQogLSBQYWNrZXQtb3B0aWNhbCBJbnRlZ3JhdGlvbi4NCg0K Q29tbWVudHMgYXJlIHdlbGNvbWVkLCB3ZSBhcmUgbG9va2luZyBmb3J3YXJkIHRvIGhlYXJpbmcg ZnJvbSB5b3UsIHRoYW5rcyBhIGxvdC4NCg0KQmVzdCB3aXNoZXMsDQpIYW9taWFuDQoNCi0tLS0t 6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFtt YWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANCuWPkemAgeaXtumXtDogMjAxNOW5tDLm nIgxNeaXpSAwOjE3DQrmlLbku7bkuro6IFpoYW5neGlhbiAoWGlhbik7IFpoZW5naGFvbWlhbjsg Wmhhbmd4aWFuIChYaWFuKTsgWmhlbmdoYW9taWFuDQrkuLvpopg6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtemhlbmctcGNlLWZvci1zZG4tdHJhbnNwb3J0LTAwLnR4dA0KDQoN CkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC16aGVuZy1wY2UtZm9yLXNkbi10cmFuc3BvcnQt MDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEhhb21pYW4gWmhlbmcg YW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtemhlbmct cGNlLWZvci1zZG4tdHJhbnNwb3J0DQpSZXZpc2lvbjoJMDANClRpdGxlOgkJUGF0aCBDb21wdXRh dGlvbiBFbGVtZW50IHRvIFN1cHBvcnQgU29mdHdhcmUtRGVmaW5lZCBUcmFuc3BvcnQgTmV0d29y a3MgQ29udHJvbA0KRG9jdW1lbnQgZGF0ZToJMjAxNC0wMi0xNA0KR3JvdXA6CQlJbmRpdmlkdWFs IFN1Ym1pc3Npb24NClBhZ2VzOgkJMTINClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC16aGVuZy1wY2UtZm9yLXNkbi10cmFuc3BvcnQtMDAu dHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtemhlbmctcGNlLWZvci1zZG4tdHJhbnNwb3J0Lw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoZW5nLXBjZS1mb3Itc2RuLXRyYW5zcG9ydC0wMA0K DQoNCkFic3RyYWN0Og0KICAgVGhpcyBkcmFmdCBkZXNjcmliZXMgUENFIGFyY2hpdGVjdHVyZSBh bmQgcHJvdG9jb2wgaW4gU0ROLWJhc2VkDQogICB0cmFuc3BvcnQgbmV0d29yay4gSXQgaXMgZGVt b25zdHJhdGVkIHRoYXQgUENFIGNhbiBmaXQgaW4gdGhlDQogICB0cmFuc3BvcnQgU0ROIGFyY2hp dGVjdHVyZSBhbmQgY29tcGxldGUgY29ycmVzcG9uZGluZyByZXF1ZXN0cy4gVGhlDQogICBQQ0Ug YW5kIGl0cyBwcm90b2NvbCBjYW4gc2F0aXNmeSB0aGUgZnVuY3Rpb25hbCByZXF1aXJlbWVudCBp bg0KICAgc2V2ZXJhbCB0cmFuc3BvcnQgU0ROIGFwcGxpY2F0aW9ucy4NCg0KDQoNCg0KUGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg b2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZh aWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Tue Feb 18 08:28:31 2014 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 7CD8F1A06C2 for ; Tue, 18 Feb 2014 08:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.432 X-Spam-Level: X-Spam-Status: No, score=-1.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.548, 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 V2MyY8xWMCjQ for ; Tue, 18 Feb 2014 08:28:26 -0800 (PST) Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 43B7B1A069B for ; Tue, 18 Feb 2014 08:28:26 -0800 (PST) Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D41B6410229 for ; Tue, 18 Feb 2014 17:28:22 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.orange.com (Postfix) with ESMTP id CF246410224 for ; Tue, 18 Feb 2014 17:28:22 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Feb 2014 17:28:21 +0100 Received: from [10.193.71.94] ([10.193.71.94]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Feb 2014 17:28:22 +0100 Message-ID: <53038A25.4090506@orange.com> Date: Tue, 18 Feb 2014 17:28:21 +0100 From: Julien Meuric Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: pce@ietf.org References: <52EFCBE6.60309@orange.com> In-Reply-To: <52EFCBE6.60309@orange.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Feb 2014 16:28:22.0362 (UTC) FILETIME=[70BD13A0:01CF2CC6] Archived-At: http://mailarchive.ietf.org/arch/msg/pce/mNJEh2GFtxZMOwUCveTP41-yGfo Subject: Re: [Pce] WG Last Call of draft-ietf-pce-wson-routing-wavelength-10 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, 18 Feb 2014 16:28:28 -0000 Hi all. This last call has ended. We have not seen many reviews. The chairs' will come soon. JP & Julien Feb. 03, 2014 - Julien Meuric: > Hi all. > > Since many of you are going to dedicate some time to IETF matters over > the upcoming days, here comes some homework. > > This message ignites a 2-week WG last call on > draft-ietf-pce-wson-routing-wavelength-10. It will end on Monday, > February 17, 11:59 PM (UTC-12). > > Thanks, > > JP & Julien > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > From nobody Tue Feb 18 08:40:44 2014 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 4AA5A1A06BB for ; Tue, 18 Feb 2014 08:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.032 X-Spam-Level: X-Spam-Status: No, score=-0.032 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.548, 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 MqRyOtlYb0uW for ; Tue, 18 Feb 2014 08:40:41 -0800 (PST) Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 2814B1A0073 for ; Tue, 18 Feb 2014 08:40:41 -0800 (PST) Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D3B36DE4003; Tue, 18 Feb 2014 17:42:21 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.orange.com (Postfix) with ESMTP id C1C19DE4001; Tue, 18 Feb 2014 17:42:21 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Feb 2014 17:40:36 +0100 Received: from [10.193.71.94] ([10.193.71.94]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Feb 2014 17:40:31 +0100 Message-ID: <53038CFE.40003@orange.com> Date: Tue, 18 Feb 2014 17:40:30 +0100 From: Julien Meuric Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: draft-ietf-pce-wson-routing-wavelength@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Feb 2014 16:40:31.0626 (UTC) FILETIME=[2369EEA0:01CF2CC8] Archived-At: http://mailarchive.ietf.org/arch/msg/pce/kfo10Tgy2wIIWbHvd1fMOpEajPk Cc: "pce@ietf.org" Subject: [Pce] Last IPR Check on draft-ietf-pce-wson-routing-wavelength 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, 18 Feb 2014 16:40:42 -0000 Dear authors of the aforementioned document, Has all IPR that applies to draft-ietf-pce-wson-routing-wavelength been disclosed in compliance with IETF IPR rules? (see RFCs 3979, 4879, 3669 and 5378 for more details) Note that an associated IPR was disclosed in September 2010. A response from each of you is expected. Regards, JP & Julien From nobody Tue Feb 18 12:26:15 2014 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 43E671A0254 for ; Tue, 18 Feb 2014 12:26:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 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.548, 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 NghPJWxO_976 for ; Tue, 18 Feb 2014 12:26:09 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE231A0276 for ; Tue, 18 Feb 2014 12:26:09 -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 BBG58069; Tue, 18 Feb 2014 20:26:05 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 18 Feb 2014 20:25:52 +0000 Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 18 Feb 2014 20:26:02 +0000 Received: from DFWEML706-CHM.china.huawei.com ([169.254.8.193]) by dfweml705-chm.china.huawei.com ([169.254.7.245]) with mapi id 14.03.0158.001; Tue, 18 Feb 2014 12:25:51 -0800 From: Leeyoung To: "pce@ietf.org" Thread-Topic: New Version Notification for draft-lee-pce-app-oriented-arch-01.txt Thread-Index: AQHPKbo0PwE5TH1VxEyfsFnAJaIbTpq7e3Ng Date: Tue, 18 Feb 2014 20:25:51 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729BBB685@dfweml706-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.144] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pce/CGB-sbEO6bBsI4VpVLT9hd9RIdM Subject: [Pce] FW: New Version Notification for draft-lee-pce-app-oriented-arch-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, 18 Feb 2014 20:26:12 -0000 SGksDQoNCldlIGhhdmUgdXBkYXRlZCBBcHBsaWNhdGlvbi1vcmllbnRlZCBQQ0UgYXJjaGl0ZWN0 dXJlIGRyYWZ0ICgwMSkuIA0KDQpZb3VyIGNvbW1lbnQgd291bGQgYmUgYXBwcmVjaWF0ZWQuDQoN CkJlc3QgUmVnYXJkcywNCllvdW5nDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmddIA0KU2VudDogRnJpZGF5LCBGZWJydWFyeSAxNCwgMjAxNCAxOjIyIFBNDQpUbzogWmhlbmdo YW9taWFuOyBMZWV5b3VuZzsgWmhhbmd4aWFuIChYaWFuKTsgWmhhbmd4aWFuIChYaWFuKTsgR3Vv eWluZyBaaGFuZzsgTGVleW91bmc7IFpoZW5naGFvbWlhbjsgR3VveWluZyBaaGFuZw0KU3ViamVj dDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1sZWUtcGNlLWFwcC1vcmllbnRl ZC1hcmNoLTAxLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1sZWUtcGNlLWFw cC1vcmllbnRlZC1hcmNoLTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBZb3VuZyBMZWUgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJ ZHJhZnQtbGVlLXBjZS1hcHAtb3JpZW50ZWQtYXJjaA0KUmV2aXNpb246CTAxDQpUaXRsZToJCUFw cGxpY2F0aW9uLW9yaWVudGVkIFN0YXRlZnVsIFBDRSBBcmNoaXRlY3R1cmUgYW5kIFVzZS1jYXNl cyBmb3IgVHJhbnNwb3J0IE5ldHdvcmtzDQpEb2N1bWVudCBkYXRlOgkyMDE0LTAyLTE0DQpHcm91 cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxMg0KVVJMOiAgICAgICAgICAgIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxlZS1wY2UtYXBwLW9yaWVu dGVkLWFyY2gtMDEudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtbGVlLXBjZS1hcHAtb3JpZW50ZWQtYXJjaC8NCkh0bWxpemVkOiAgICAg ICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sZWUtcGNlLWFwcC1vcmllbnRlZC1h cmNoLTAxDQpEaWZmOiAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtbGVlLXBjZS1hcHAtb3JpZW50ZWQtYXJjaC0wMQ0KDQpBYnN0cmFjdDoNCiAgIFRoaXMg ZHJhZnQgcHJlc2VudHMgYW4gYXBwbGljYXRpb24tb3JpZW50ZWQgc3RhdGVmdWwgUENFDQogICBh cmNoaXRlY3R1cmUgZm9yIHRyYW5zcG9ydCBuZXR3b3Jrcy4gVW5kZXIgdGhpcyBhcmNoaXRlY3R1 cmUsDQogICBzZXZlcmFsIHVzZSBjYXNlcyBhcmUgZGVzY3JpYmVkLg0KDQoNCg0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0K DQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Tue Feb 18 23:23:56 2014 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 4A1521A043A for ; Tue, 18 Feb 2014 23:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] 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 zesYXdi8q7Xu for ; Tue, 18 Feb 2014 23:23:52 -0800 (PST) Received: from smtp201-outgoing.stejtech.net (smtp201.stejtech.net [IPv6:2001:9b0:1:704::5201]) by ietfa.amsl.com (Postfix) with ESMTP id DFB331A042D for ; Tue, 18 Feb 2014 23:23:51 -0800 (PST) X-Spam-STAY-ID: _CMAETAG_ Received: from mail.acreo.se (unknown [217.151.196.13]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp201.stejtech.net (Postfix) with ESMTPSA id 5A4D43C6475; Wed, 19 Feb 2014 08:23:47 +0100 (CET) Received: from ACREOEXC02.ad.acreo.se ([::1]) by ACREOEXC02.ad.acreo.se ([::1]) with mapi id 14.03.0158.001; Wed, 19 Feb 2014 08:23:47 +0100 From: =?iso-8859-1?Q?Jonas_M=E5rtensson?= To: Julien Meuric , "draft-ietf-pce-wson-routing-wavelength@tools.ietf.org" Thread-Topic: [Pce] Last IPR Check on draft-ietf-pce-wson-routing-wavelength Thread-Index: AQHPLMguo8K40txwAUeewcubZYi28pq8LJ2Q Date: Wed, 19 Feb 2014 07:23:46 +0000 Message-ID: <7ECED07E132D4B4F89DCC0FDA683C6C24270E9@ACREOEXC02.ad.acreo.se> References: <53038CFE.40003@orange.com> In-Reply-To: <53038CFE.40003@orange.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.144.180] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/FxdKDc75tc-gV183sFiRb7vx9Ug Cc: "pce@ietf.org" Subject: Re: [Pce] Last IPR Check on draft-ietf-pce-wson-routing-wavelength 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: Wed, 19 Feb 2014 07:23:54 -0000 Hi, I am not aware of any IPR that applies to this draft. Regards, Jonas > -----Original Message----- > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Julien Meuric > Sent: den 18 februari 2014 17:41 > To: draft-ietf-pce-wson-routing-wavelength@tools.ietf.org > Cc: pce@ietf.org > Subject: [Pce] Last IPR Check on draft-ietf-pce-wson-routing-wavelength >=20 > Dear authors of the aforementioned document, >=20 > Has all IPR that applies to draft-ietf-pce-wson-routing-wavelength been > disclosed in compliance with IETF IPR rules? (see RFCs 3979, 4879, 3669 > and 5378 for more details) >=20 > Note that an associated IPR was disclosed in September 2010. >=20 > A response from each of you is expected. >=20 > Regards, >=20 > JP & Julien >=20 > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From nobody Wed Feb 19 02:47:04 2014 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 2C91A1A057D for ; Wed, 19 Feb 2014 02:46:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 NCXm74ZPPgFs for ; Wed, 19 Feb 2014 02:46:54 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F1BD91A046F for ; Wed, 19 Feb 2014 02:46:53 -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 BDT03223; Wed, 19 Feb 2014 10:46:50 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 19 Feb 2014 10:46:37 +0000 Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 19 Feb 2014 10:46:49 +0000 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.167]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Wed, 19 Feb 2014 18:46:42 +0800 From: "Zhangxian (Xian)" To: "pce@ietf.org" Thread-Topic: New Version Notification for draft-zhang-pce-resource-sharing-00.txt Thread-Index: AQHPKU8lVmrKcn2Avk6RyK6r/gpUxpq8a+Pg Date: Wed, 19 Feb 2014 10:46:41 +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 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/J55X0UoqdRgH4EGAyPeNZnOP7NU Subject: [Pce] FW: New Version Notification for draft-zhang-pce-resource-sharing-00.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: Wed, 19 Feb 2014 10:46:57 -0000 SGksIERlYXIgYWxsLCANCg0KICAgV2Ugc3VibWl0dGVkIGEgbmV3IGRyYWZ0IGVuYWJsaW5nIHRo ZSBQQ0UgdG8gcGVyZm9ybSByZXNvdXJjZS1zaGFyaW5nLWJhc2VkIHBhdGggY29tcHV0YXRpb24u IEFueSBjb21tZW50cyBhbmQgZmVlZGJhY2tzIGFyZSB3ZWxjb21lLiANCg0KICAgV2UgYXJlIGFs c28gbG9va2luZyBmb3IgY28tYXV0aG9ycywgaWYgeW91IGFyZSBpbnRlcmVzdGVkLCBwbGVhc2Ug bGV0IHVzIGtub3cuIA0KDQpSZWdhcmRzLA0KWGlhbiAob24gYmVoYWxmIG9mIGFsbCBhdXRob3Jz KQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGll dGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IDIwMTTlubQy 5pyIMTTml6UgMTQ6MzcNClRvOiBPc2NhciBHb256YWxleiBkZSBEaW9zOyBaaGVuZ2hhb21pYW47 IFZpY3RvciBMb3BlejsgWmhhbmd4aWFuIChYaWFuKTsgWmhhbmd4aWFuIChYaWFuKTsgT3NjYXIg R29uemFsZXogZGUgRGlvczsgVmljdG9yIExvcGV6OyBaaGVuZ2hhb21pYW4NClN1YmplY3Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtemhhbmctcGNlLXJlc291cmNlLXNoYXJp bmctMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXpoYW5nLXBjZS1yZXNv dXJjZS1zaGFyaW5nLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBY aWFuIFpoYW5nIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlk cmFmdC16aGFuZy1wY2UtcmVzb3VyY2Utc2hhcmluZw0KUmV2aXNpb246CTAwDQpUaXRsZToJCUV4 dGVuc2lvbnMgdG8gUGF0aCBDb21wdXRhdGlvbiBFbGVtZW50IFByb3RvY29sIChQQ0VQKSB0byBT dXBwb3J0IFJlc291cmNlIFNoYXJpbmctYmFzZWQgUGF0aCBDb21wdXRhdGlvbg0KRG9jdW1lbnQg ZGF0ZToJMjAxNC0wMi0xNA0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJ MTQNClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC16aGFuZy1wY2UtcmVzb3VyY2Utc2hhcmluZy0wMC50eHQNClN0YXR1czogICAgICAgICBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aGFuZy1wY2UtcmVzb3VyY2Ut c2hhcmluZy8NCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC16aGFuZy1wY2UtcmVzb3VyY2Utc2hhcmluZy0wMA0KDQoNCkFic3RyYWN0Og0KICAgUmVzb3Vy Y2Ugc2hhcmluZyBpbiBhIG5ldHdvcmsgbWVhbnMgdHdvIG9yIG1vcmUgTGFiZWwgU3dpdGNoZWQg UGF0aHMNCiAgIChMU1BzKSB1c2UgY29tbW9uIHBpZWNlKHMpIG9mIHJlc291cmNlIGFsb25nIHRo ZWlyIHBhdGhzLiBUaGlzIGNhbg0KICAgaGVscCBzYXZlIG5ldHdvcmsgcmVzb3VyY2UgYW5kIHVz ZWZ1bCBpbiBzY2VuYXJpb3Mgc3VjaCBhcyBMU1ANCiAgIHJlY292ZXJ5IG9yIHR3byBMU1BzIGRv IG5vdCBuZWVkIHRvIGJlIGFjdGl2ZSBhdCB0aGUgc2FtZSB0aW1lLiBBDQogICBQYXRoIENvbXB1 dGF0aW9uIEVsZW1lbnQgKFBDRSkgaXMgYSBjZW50cmFsaXplZCBlbnRpdHksIHJlc3BvbnNpYmxl DQogICBmb3IgcGF0aCBjYWxjdWxhdGlvbi4gR2l2ZW4gdGhpcyBmZWF0dXJlIGFuZCBpdHMgYWNj ZXNzIHRvIHRoZQ0KICAgbmV0d29yayByZXNvdXJjZSBpbmZvcm1hdGlvbiBhbmQgcG9zc2libHkg YWN0aXZlIExTUHMgaW5mb3JtYXRpb24sDQogICBpdCBjYW4gYmUgdXNlZCB0byBzdXBwb3J0IHJl c291cmNlLXNoYXJpbmctYmFzZWQgcGF0aCBjb21wdXRhdGlvbg0KICAgd2l0aCBiZXR0ZXIgZWZm aWNpZW5jeS4NCg0KICAgVGhpcyBkb2N1bWVudCBleHRlbmRzIHRoZSBQYXRoIENvbXB1dGF0aW9u IEVsZW1lbnQgUHJvdG9jb2wgKFBDRVApDQogICBpbiBvcmRlciB0byBzdXBwb3J0IHJlc291cmNl IHNoYXJpbmctYmFzZWQgcGF0aCBjb21wdXRhdGlvbi4NCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRl cyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNl Y3JldGFyaWF0DQoNCg== From nobody Wed Feb 19 09:40:39 2014 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 6437F1A05C7 for ; Wed, 19 Feb 2014 09:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 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.548, 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 3mAaN63LK7hU for ; Wed, 19 Feb 2014 09:40:36 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 690231A0599 for ; Wed, 19 Feb 2014 09:40:35 -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 BBH46122; Wed, 19 Feb 2014 17:40:31 +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; Wed, 19 Feb 2014 17:40:06 +0000 Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 19 Feb 2014 17:40:17 +0000 Received: from DFWEML706-CHM.china.huawei.com ([169.254.8.193]) by dfweml704-chm.china.huawei.com ([169.254.6.202]) with mapi id 14.03.0158.001; Wed, 19 Feb 2014 09:40:11 -0800 From: Leeyoung To: Julien Meuric , "draft-ietf-pce-wson-routing-wavelength@tools.ietf.org" Thread-Topic: [Pce] Last IPR Check on draft-ietf-pce-wson-routing-wavelength Thread-Index: AQHPLMgutIaahvuEL0+d7/kFZfGRC5q82YIQ Date: Wed, 19 Feb 2014 17:40:11 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729BBBC26@dfweml706-chm.china.huawei.com> References: <53038CFE.40003@orange.com> In-Reply-To: <53038CFE.40003@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.144] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pce/ZJR8Kcost3toYyKC0ZFehgxGyG4 Cc: "pce@ietf.org" Subject: Re: [Pce] Last IPR Check on draft-ietf-pce-wson-routing-wavelength 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: Wed, 19 Feb 2014 17:40:38 -0000 Hi, Yes, I'm aware of IPR that applies to this draft & the IPR has been disclos= ed in compliance with IETF IPR rules as follows: http://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddraft= -ietf-pce-wson-routing-wavelength Regards, Young -----Original Message----- From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Julien Meuric Sent: Tuesday, February 18, 2014 10:41 AM To: draft-ietf-pce-wson-routing-wavelength@tools.ietf.org Cc: pce@ietf.org Subject: [Pce] Last IPR Check on draft-ietf-pce-wson-routing-wavelength Dear authors of the aforementioned document, Has all IPR that applies to draft-ietf-pce-wson-routing-wavelength been dis= closed in compliance with IETF IPR rules? (see RFCs 3979, 4879, 3669 and 53= 78 for more details) Note that an associated IPR was disclosed in September 2010. A response from each of you is expected. Regards, JP & Julien _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From nobody Wed Feb 19 10:00:36 2014 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 6990D1A01CF for ; Wed, 19 Feb 2014 10:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.449 X-Spam-Level: X-Spam-Status: No, score=-4.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 pmIC_MMJOoYi for ; Wed, 19 Feb 2014 10:00:33 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 47A811A00B8 for ; Wed, 19 Feb 2014 10:00:33 -0800 (PST) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0N1900FQ08OFAH@tid.hi.inet> for pce@ietf.org; Wed, 19 Feb 2014 19:00:29 +0100 (MET) Received: from dequeue_removeroute (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id A1.2B.03314.D31F4035; Wed, 19 Feb 2014 19:00:29 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0N1900FRK8OTAH@tid.hi.inet> for pce@ietf.org; Wed, 19 Feb 2014 19:00:29 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.23]) by EX10-HTCAS6-MAD.hi.inet ([::1]) with mapi id 14.03.0158.001; Wed, 19 Feb 2014 19:00:29 +0100 Date: Wed, 19 Feb 2014 18:00:28 +0000 From: =?utf-8?B?T3NjYXIgR29uesOhbGV6IGRlIERpb3M=?= In-reply-to: <53038CFE.40003@orange.com> To: Julien Meuric Message-id: <77F11A25-BD97-4E69-BACE-E037D5E46111@tid.es> Content-id: <7F764421D239B140A88753D8DBF2C627@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: es-ES Content-transfer-encoding: base64 Accept-Language: es-ES, en-US Thread-topic: [Pce] Last IPR Check on draft-ietf-pce-wson-routing-wavelength Thread-index: AQHPLMg08LS2NIdyUEmFR5R7n74FJpq8zCSA X-AuditID: 0a5f4068-b7fe58e000000cf2-de-5304f13de43f X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsXCFe/ApWv7kSXY4O5BFYum+zfYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsaJ3BnvBOp6Kh98fsTYwtvB0MXJySAiYSDR8/80CYYtJXLi3 nq2LkYtDSOAAo8TJjglQzldGicc/T7FAONMYJT4evckE0sIioCqxZvo5RhCbTcBZ4sGxJiCb g0NYwFvi5lFJkDCngIZE75NWVhBbREBH4vz7M+wgc5hB5rSunAzWyytgKfFuxyY2EJtZwEyi +9Qsdoi4oMSPyfdYQGYyC6hLTJmSC1EiLjHn10RWCFtRYtqiBrAxjAKyEivPn2aE2OUjMXni Bai9RhI3JvawQ3wpILFkz3lmCFtU4uXjf2A1QkDjD3TNZJrAKD4LyRWzkFwxC+GKWUiumIXk igWMrKsYxYqTijLTM0pyEzNz0g0M9TIy9TLzUks2MUKiK2MH4/KdKocYBTgYlXh4PV4wBwux JpYVV+YeYpTgYFYS4b39jiVYiDclsbIqtSg/vqg0J7X4ECMTB6dUA+Om1MfPLp1udJ7+/lig 8PLP7zYUPjjT+kPw3/GjSmfKHvXk3z6TeKrS2GXez0NvJ0otFVvsHmtyY/Hji6fUTuUfU7pj cChEeIaXyv/7Lo98c9d3/H75hzs/OPdd0mIRTZPia+G/3m+O1L7+VoFp24wv6e7TGYt467h4 +JXlAyy+qDh5NPz0ev1EiaU4I9FQi7moOBEAxpY9P4wCAAA= References: <53038CFE.40003@orange.com> Archived-At: http://mailarchive.ietf.org/arch/msg/pce/5D7_VsoxB8S34vtFhgBg5-dzv0o Cc: "pce@ietf.org" , "draft-ietf-pce-wson-routing-wavelength@tools.ietf.org" Subject: Re: [Pce] Last IPR Check on draft-ietf-pce-wson-routing-wavelength 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: Wed, 19 Feb 2014 18:00:36 -0000 RGVhciBXRyBjaGFpcnMsDQoNCiAgICBZZXMuIEkgYW0gbm90IGF3YXJlIG9mIGFueSBvdGhlciBJ UFIsIHNhdmUgdGhlIG9uZSBhbHJlYWR5IGRpc2Nsb3NlZCBieSBIdWF3ZWkgaW4gU2VwdGVtYmVy IDIwMTAuDQoNCkJlc3QgUmVnYXJkcywNCg0KICAgT3NjYXINCg0KRW52aWFkbyBkZXNkZSBtaSBp UGFkDQoNCj4gRWwgMTgvMDIvMjAxNCwgYSBsYXMgMTc6NDAsICJKdWxpZW4gTWV1cmljIiA8anVs aWVuLm1ldXJpY0BvcmFuZ2UuY29tPiBlc2NyaWJpw7M6DQo+DQo+IERlYXIgYXV0aG9ycyBvZiB0 aGUgYWZvcmVtZW50aW9uZWQgZG9jdW1lbnQsDQo+DQo+IEhhcyBhbGwgSVBSIHRoYXQgYXBwbGll cyB0byBkcmFmdC1pZXRmLXBjZS13c29uLXJvdXRpbmctd2F2ZWxlbmd0aCBiZWVuIGRpc2Nsb3Nl ZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXM/IChzZWUgUkZDcyAzOTc5LCA0ODc5 LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpDQo+DQo+IE5vdGUgdGhhdCBhbiBhc3Nv Y2lhdGVkIElQUiB3YXMgZGlzY2xvc2VkIGluIFNlcHRlbWJlciAyMDEwLg0KPg0KPiBBIHJlc3Bv bnNlIGZyb20gZWFjaCBvZiB5b3UgaXMgZXhwZWN0ZWQuDQo+DQo+IFJlZ2FyZHMsDQo+DQo+IEpQ ICYgSnVsaWVuDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IFBjZSBtYWlsaW5nIGxpc3QNCj4gUGNlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNlDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQoNCkVzdGUgbWVuc2FqZSBzZSBkaXJpZ2UgZXhjbHVzaXZhbWVudGUgYSBzdSBk ZXN0aW5hdGFyaW8uIFB1ZWRlIGNvbnN1bHRhciBudWVzdHJhIHBvbMOtdGljYSBkZSBlbnbDrW8g eSByZWNlcGNpw7NuIGRlIGNvcnJlbyBlbGVjdHLDs25pY28gZW4gZWwgZW5sYWNlIHNpdHVhZG8g bcOhcyBhYmFqby4NClRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBleGNsdXNpdmVseSBmb3IgaXRz IGFkZHJlc3NlZS4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBv ZiB0aGUgdGVybXMgc2V0IG91dCBhdDoNCmh0dHA6Ly93d3cudGlkLmVzL0VTL1BBR0lOQVMvZGlz Y2xhaW1lci5hc3B4DQo= From nobody Thu Feb 20 16:04:57 2014 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 208E11A0368 for ; Thu, 20 Feb 2014 16:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.059 X-Spam-Level: X-Spam-Status: No, score=0.059 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-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 YTW8NeCUYqP8 for ; Thu, 20 Feb 2014 16:04:53 -0800 (PST) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by ietfa.amsl.com (Postfix) with ESMTP id 0022D1A035E for ; Thu, 20 Feb 2014 16:04:52 -0800 (PST) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama500.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id s1L04kub007352; Fri, 21 Feb 2014 09:04:46 +0900 Received: from mfs5.rdh.ecl.ntt.co.jp (localhost.localdomain [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 82A93E011A; Fri, 21 Feb 2014 09:04:46 +0900 (JST) Received: from imail2.m.ecl.ntt.co.jp (imail2.m.ecl.ntt.co.jp [129.60.5.247]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 6D81BE0119; Fri, 21 Feb 2014 09:04:46 +0900 (JST) Received: from [IPv6:::1] (panasonic.nslab.ecl.ntt.co.jp [129.60.85.25]) by imail2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id s1L04euv032653; Fri, 21 Feb 2014 09:04:46 +0900 Message-ID: <53069859.7060401@lab.ntt.co.jp> Date: Fri, 21 Feb 2014 09:05:45 +0900 From: Tomonori Takeda User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ja-JP; rv:1.9.2.15) Gecko/20110323 Lanikai/3.1.9 MIME-Version: 1.0 References: <53038CFE.40003@orange.com> In-Reply-To: <53038CFE.40003@orange.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To: Julien Meuric X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/pce/CajsvKiJ231NicH-Vu0GCdQkClU Cc: "pce@ietf.org" , draft-ietf-pce-wson-routing-wavelength@tools.ietf.org Subject: Re: [Pce] Last IPR Check on draft-ietf-pce-wson-routing-wavelength 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, 21 Feb 2014 00:04:55 -0000 Hi, I am not aware of any IPR that applies to this draft (other than the one already disclosed). Thank you, Tomonori Takeda (2014/02/19 1:40), Julien Meuric wrote: > Dear authors of the aforementioned document, > > Has all IPR that applies to draft-ietf-pce-wson-routing-wavelength been disclosed in > compliance with IETF IPR rules? (see RFCs 3979, 4879, 3669 and 5378 for more details) > > Note that an associated IPR was disclosed in September 2010. > > A response from each of you is expected. > > Regards, > > JP & Julien > From nobody Fri Feb 21 01:44:23 2014 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 D51821A002D for ; Fri, 21 Feb 2014 01:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 s2_DgBHBJoOz for ; Fri, 21 Feb 2014 01:44:19 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F1B7B1A0452 for ; Fri, 21 Feb 2014 01:44:18 -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 BBI93348; Fri, 21 Feb 2014 09:44:14 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 21 Feb 2014 09:43:39 +0000 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 21 Feb 2014 09:43:57 +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, 21 Feb 2014 17:43:46 +0800 From: Qin Wu To: "pce@ietf.org" Thread-Topic: I-D Action: draft-wu-pce-discovery-pceps-support-00.txt Thread-Index: AQHPJlDwycXon90GxkOpooXGS60HDZq/hYow Date: Fri, 21 Feb 2014 09:43:45 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pce/dlRfDLb_su90S2voBYXq1yWnOSg Subject: [Pce] FW: I-D Action: draft-wu-pce-discovery-pceps-support-00.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: Fri, 21 Feb 2014 09:44:22 -0000 Hi, all: We submitted a new draft to discuss IGP extension for PCEP security capabil= ity support in the PCE discovery http://tools.ietf.org/html/draft-wu-pce-discovery-pceps-support-00 In this draft, we propose new capability flag bits for PCE-CAP-FLAGS sub- TLV that can be announced as attribute in the IGP advertisement to distribute PCEP security support information. Your comments and suggestions are welcome! Regards! -Qin -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Monday, February 10, 2014 7:12 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-wu-pce-discovery-pceps-support-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : IGP extension for PCEP security capability suppor= t in the PCE discovery Authors : Diego R. Lopez Qin Wu Dhruv Dhody Daniel King Filename : draft-wu-pce-discovery-pceps-support-00.txt Pages : 12 Date : 2014-02-10 Abstract: When a Path Computation Element(PCE) is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating in IGP, its presence and path computation capabilities can be advertised using IGP flooding. [RFC5088] and [RFC5089] define a method to advertise path computation capabilities using IGP flooding for OSPF and ISIS respectively. However [RFC5088] and [RFC5089] lacks a method to advertise PCEP security (e.g., Transport Layer Security(TLS)) support capability. This document proposes new capability flag bit for PCE-CAP-FLAGS sub- TLV that can be announced as attribute in the IGP advertisement (defined in [RFC5088] and [RFC5089]) to distribute PCEP security support information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-wu-pce-discovery-pceps-support/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-wu-pce-discovery-pceps-support-00 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/ _______________________________________________ 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 Fri Feb 21 04:09:43 2014 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 7832C1A0524 for ; Fri, 21 Feb 2014 04:09:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.06 X-Spam-Level: X-Spam-Status: No, score=0.06 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.548, SPF_PASS=-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 Kdw03Pi0murQ for ; Fri, 21 Feb 2014 04:09:40 -0800 (PST) Received: from zen.kddilabs.jp (zen.kddilabs.jp [IPv6:2001:200:601:12::31]) by ietfa.amsl.com (Postfix) with ESMTP id D25E81A00AE for ; Fri, 21 Feb 2014 04:09:39 -0800 (PST) Received: from localhost (zen.kddilabs.jp [127.0.0.1]) by zen.kddilabs.jp (Postfix) with ESMTP id 9C1CA1748345; Fri, 21 Feb 2014 21:09:35 +0900 (JST) X-Virus-Scanned: amavisd-new at kddilabs.jp Received: from zen.kddilabs.jp ([127.0.0.1]) by localhost (zen.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTi1Rn-YRvvi; Fri, 21 Feb 2014 21:09:25 +0900 (JST) Received: from localhost (pink.lan.kddilabs.jp [172.19.98.9]) by zen.kddilabs.jp (Postfix) with ESMTP id 814DE17482C3; Fri, 21 Feb 2014 21:09:25 +0900 (JST) Received: from [172.19.110.229] (dhcp229.wlan.kddilabs.jp [172.19.110.229]) by localhost (Postfix) with ESMTP id 6DD6734E812F; Fri, 21 Feb 2014 21:09:25 +0900 (JST) Message-ID: <530741F5.2090309@kddilabs.jp> Date: Fri, 21 Feb 2014 21:09:25 +0900 From: Takehiro Tsuritani User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Julien Meuric , draft-ietf-pce-wson-routing-wavelength@tools.ietf.org References: <53038CFE.40003@orange.com> In-Reply-To: <53038CFE.40003@orange.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/pce/fTcE1YbaOAem6s_ocUKHX8MO29M Cc: "pce@ietf.org" Subject: Re: [Pce] Last IPR Check on draft-ietf-pce-wson-routing-wavelength 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, 21 Feb 2014 12:09:41 -0000 Hi, I am not aware of any IPR that applies to this draft. Regards, Takehiro (2014/02/19 1:40), Julien Meuric wrote: > Dear authors of the aforementioned document, > > Has all IPR that applies to draft-ietf-pce-wson-routing-wavelength > been disclosed in compliance with IETF IPR rules? (see RFCs 3979, > 4879, 3669 and 5378 for more details) > > Note that an associated IPR was disclosed in September 2010. > > A response from each of you is expected. > > Regards, > > JP & Julien > > From nobody Fri Feb 21 23:33:11 2014 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 2EDD11A0358 for ; Fri, 21 Feb 2014 23:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 nMsKcC4W9bgH for ; Fri, 21 Feb 2014 23:33:05 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1604C1A028B for ; Fri, 21 Feb 2014 23:33:03 -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 BBJ64221; Sat, 22 Feb 2014 07:32:58 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 22 Feb 2014 07:32:37 +0000 Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 22 Feb 2014 07:32:39 +0000 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.167]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Sat, 22 Feb 2014 15:32:36 +0800 From: "Zhangxian (Xian)" To: Jonathan Hardwick Thread-Topic: Comments on draft-minei-pce-stateful-sync-optimizations-01 Thread-Index: Ac8ps3n6I0/p/UTJSj24UQQcD8tDLAF5aSuA Date: Sat, 22 Feb 2014 07:32:36 +0000 Message-ID: References: <09CE6C3BE5E1EA40B987BF5F25D8DDBAE13416C9@ENFICSMBX1.datcon.co.uk> In-Reply-To: <09CE6C3BE5E1EA40B987BF5F25D8DDBAE13416C9@ENFICSMBX1.datcon.co.uk> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.104.209] Content-Type: multipart/alternative; boundary="_000_C636AF2FA540124E9B9ACB5A6BECCE6B301FF0AESZXEMA512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pce/SlyR5rHtVEoE7_DmHV0AQz0lmqo Cc: "draft-minei-pce-stateful-sync-optimizations@tools.ietf.org" , "pce@ietf.org" Subject: Re: [Pce] Comments on draft-minei-pce-stateful-sync-optimizations-01 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: Sat, 22 Feb 2014 07:33:09 -0000 --_000_C636AF2FA540124E9B9ACB5A6BECCE6B301FF0AESZXEMA512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIEpvbiwNCg0KICAgVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgdGhlIGNvbnN0cnVjdGl2ZSBj b21tZW50cy4gIFBsZWFzZSBzZWUgbXkgcmVwbHkgaW5saW5lLCBtYXJrZWQgd2l0aCBbWGlhbl06 DQpGcm9tOiBQY2UgW21haWx0bzpwY2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpv bmF0aGFuIEhhcmR3aWNrDQpTZW50OiAyMDE0xOoy1MIxNcjVIDI6MzUNClRvOiBkcmFmdC1taW5l aS1wY2Utc3RhdGVmdWwtc3luYy1vcHRpbWl6YXRpb25zQHRvb2xzLmlldGYub3JnDQpDYzogcGNl QGlldGYub3JnDQpTdWJqZWN0OiBbUGNlXSBDb21tZW50cyBvbiBkcmFmdC1taW5laS1wY2Utc3Rh dGVmdWwtc3luYy1vcHRpbWl6YXRpb25zLTAxDQoNCkhpIHRoZXJlDQoNCkkgaGF2ZSByZXZpZXdl ZCB0aGlzIGRyYWZ0IKhDIGhlcmUgYXJlIG15IGNvbW1lbnRzLg0KDQpCZXN0IHJlZ2FyZHMNCkpv bg0KDQpTZWN0aW9uIDMuMg0KRmlndXJlIDIsIEkgdGhpbmsgdGhlIKGwc3luYyBkb25lobEgUENS cHQgc2hvdWxkIGhhdmUgU1lOQz0wLCBub3QgU1lOQz0xLg0KW1hpYW5dOiBJbmRlZWQuIFRoYW5r IHlvdSBmb3Igc3BvdHRpbmcgdGhpcyB0eXBvLg0KDQpTZWN0aW9uIDUuMg0KICAgSWYgYSBQQ0Mg aGFzIHRvIGZvcmNlIGZ1bGwgTFNQIERCDQogICBzeW5jaHJvbml6YXRpb24gZHVlIHRvIHJlYXNv bnMgaW5jbHVkaW5nIGJ1dCBub3QgbGltaXRlZDogKDEpIGxvY2FsDQogICBwb2xpY3kgY29uZmln dXJlZCBhdCB0aGUgUENDOyAoMikgbm8gc3VmZmljaWVudCBMU1Agc3RhdGUgY2FjaGVzIGZvcg0K ICAgaW5jcmVtZW50YWwgdXBkYXRlLCB0aGUgUENDIGNhbiBzZXQgdGhlIEQgZmxhZyB0byAwLg0K DQpQZXJoYXBzIEkgaGF2ZSBtaXN1bmRlcnN0b29kLCBidXQgSSB0aGluayBjYXNlICgyKSBhYm92 ZSBkb2VzbqGvdCB3b3JrLiAgVGhlIFBDQyBkb2VzIG5vdCBrbm93IHRoYXQgaXQgaGFzIKGwbm8g c3VmZmljaWVudCBMU1Agc3RhdGUgY2FjaGVzobEgdW50aWwgaXQgcmVjZWl2ZXMgdGhlIE9QRU4g ZnJvbSB0aGUgUENFIGFuZCBzZWVzIHdoYXQgREJ2IHRoZSBQQ0UgaGFzIHNlbnQuICBCeSB0aGVu LCB0aGUgUENDIGhhcyBhbHJlYWR5IHNlbnQgaXRzIE9QRU4gc28gaXQgaXMgdG9vIGxhdGUgdG8g c2V0IEQ9MC4gIFRvIGNvdmVyIGNhc2UgKDIpIHRoZSBkcmFmdCBuZWVkcyBhIG1lY2hhbmlzbSBm b3IgdGhlIFBDQyB0byBjaGFuZ2UgaXRzIG1pbmQgYW5kIHRlbGwgdGhlIFBDRSB0aGF0IGl0IGlz IGdvaW5nIHRvIHNlbmQgYSBmdWxsIHNuYXBzaG90LCBub3QgYSByZXBsYXkgb2YgdGhlIG1pc3Np bmcgZGF0YWJhc2UgdXBkYXRlcy4gIFRoZSBzaW1wbGVzdCB0aGluZyBpcyBwcm9iYWJseSBmb3Ig dGhlIFBDQyB0byBicmluZyB0aGUgc2Vzc2lvbiBkb3duIGFuZCB0aGVuIGJyaW5nIGl0IGJhY2sg dXAgYWdhaW4gd2l0aCBEPTAuDQoNCltYaWFuXTogIEl0IGFjdHVhbGx5IGRlcGVuZHMsIElNSE8u IElmIGl0IGlzIGR1ZSB0byB0aGUgMXN0IHJlYXNvbiBsaXN0ZWQgYWJvdmUsIHRoZW4sIGl0IGNh biBkZWNpZGUgYmVmb3JlIHNlbmRpbmcgT1BFTiBhbmQgc2V0IEQ9MC4gVGhlIGNhc2VzIGFzIGEg cmVzdWx0IG9mIHRoZSAybmQgcmVhc29uIG1pZ2h0IGJlIG1vcmUgY29tcGxpY2F0ZWQuIFlvdXIg YW5hbHlzaXMgd291bGQgYmUgb25lIG9mIHRoZSBjYXNlcywgaW4gd2hpY2ggYSBQQ0MgY2FuIGRl dGVjdCB0aGUgaW5zdWZmaWNpZW50IExTUCBzdGF0ZSBjYWNoZXMgT05MWSBhZnRlciBpdCBnZXRz IHRoZSBEQiB2ZXJzaW9uIGluZm9ybWF0aW9uIGZyb20gdGhlIG90aGVyIHBhcnR5LiBCdXQgaWYg YSBQQ0MgaGFzIG5vIExTUCBzdGF0ZSBjYWNoZXMgb3IgaW5jb21wbGV0ZSAobWlzc2luZyBxdWl0 ZSBzb21lIExTUCBzdGF0ZSBvciB0aG9zZSBvZiB0aGUgREIgdmVyc2lvbiBpbiBiZXR3ZWVuKSwg SSB0aGluayBpdCBpcyBwb3NzaWJsZSB0aGF0IGl0IGNhbiBkZWNpZGUgd2l0aG91dCBldmVuIGNo ZWNraW5nIHRoZSBEQnYgZnJvbSB0aGUgb3RoZXIgcGFydHkuIERvZXMgdGhpcyBjbGFyaWZ5Pw0K DQpUbyBpbmNsdWRlIHRoZSBjYXNlIHlvdSBkZXNjcmliZWQsIGhvdyBhYm91dCB3ZSB1cGRhdGUg dGhlIHRleHQgIGFzIGJlbG93Pw0KDQpPTEQ6DQogICBJZiBhIFBDQyBoYXMgdG8gZm9yY2UgZnVs bCBMU1AgREINCiAgIHN5bmNocm9uaXphdGlvbiBkdWUgdG8gcmVhc29ucyBpbmNsdWRpbmcgYnV0 IG5vdCBsaW1pdGVkOiAoMSkgbG9jYWwNCiAgIHBvbGljeSBjb25maWd1cmVkIGF0IHRoZSBQQ0M7 ICgyKSBubyBzdWZmaWNpZW50IExTUCBzdGF0ZSBjYWNoZXMgZm9yDQogICBpbmNyZW1lbnRhbCB1 cGRhdGUsIHRoZSBQQ0MgY2FuIHNldCB0aGUgRCBmbGFnIHRvIDAuDQoNCltERF0gTkVXOg0KICAg SWYgYSBQQ0MgbWF5IGhhdmUgdG8gZm9yY2UgZnVsbCBMU1AgREINCiAgIHN5bmNocm9uaXphdGlv biBkdWUgdG8gcmVhc29ucyBpbmNsdWRpbmcgYnV0IG5vdCBsaW1pdGVkOiAoMSkgbG9jYWwNCiAg IHBvbGljeSBjb25maWd1cmVkIGF0IHRoZSBQQ0M7ICgyKSBubyBzdWZmaWNpZW50IExTUCBzdGF0 ZSBjYWNoZXMgZm9yDQogICBpbmNyZW1lbnRhbCB1cGRhdGUsIHRoZSBQQ0MgY2FuIHNldCB0aGUg RCBmbGFnIHRvIDAuIE5vdGUgYSBQQ0MgbWF5IGhhdmUgdG8gYnJpbmcNCiBkb3duIHRoZSBjdXJy ZW50IHNlc3Npb24gYW5kICBmb3JjZSBhIGZ1bGwgTFNQREIgc3luY2hyb25pemF0aW9uIHdpdGgg RCBmbGFnIHNldCB0bw0KMCBpbiB0aGUgIHN1YnNlcXVlbnQgb3BlbiBtZXNzYWdlLg0KDQpTZWN0 aW9uIDQgdGFsa3MgYWJvdXQgdGhlIFBDRSBoYXZpbmcgdG8gbWFyayBpdHMgTFNQIGRhdGFiYXNl IGFzIHN0YWxlLCBhbmQgdGhlbiByZW1vdmUgYW55IHN0YWxlIExTUHMgYXQgdGhlIGVuZCBvZiB0 aGUgc3luY2hyb25pemF0aW9uIHByb2Nlc3MuICBJIGFzc3VtZSB0aGF0IHRoaXMgZG9lcyBub3Qg YXBwbHkgaW4gc2VjdGlvbiA1LiAgVG8gYXZvaWQgY29uZnVzaW9uLCBJIHRoaW5rIHNlY3Rpb24g NSBzaG91bGQgc3RhdGUgdGhhdCB0aGUgUENFIGRvZXMgbm90IG1hcmsgaXRzIExTUCBkYXRhYmFz ZSBhcyBzdGFsZSBpZiBib3RoIGl0IGFuZCB0aGUgUENDIGhhdmUgc2V0IEQ9MS4NCltYaWFuXTog U3VyZS4gIEkgdGhpbmsgd2UgaGF2ZSBhbHJlYWR5IGV4cGxhaW5lZCBpbiBTZWN0aW9uIDUuIFRo ZSBsYXN0IHNlbnRlbmNlIG9mIHRoZSBwYXJhZ3JhcGggYmVsb3cgRmlndXJlIDcgc2F5czogobBO b3RlIHRoYXQgdGhlIFBDRSBzaG91bGQgbm90IG1hcmsgdGhlIGV4aXN0aW5nIExTUHMgYXMgc3Rh bGUgZm9yIGluY3JlbWVudGFsIHN0YXRlIHN5bmNocm9uaXNhdGlvbqGxLg0KDQpJbiBmaWd1cmUg NywgSSBtYXkgaGF2ZSBtaXN1bmRlcnN0b29kIHNlY3Rpb24gNCwgYnV0IEkgZG9uoa90IHRoaW5r IHRoaXMgaXMgaG93IHRoZSBUIGJpdCBpcyBzcGVjaWZpZWQuICBJIGRvbqGvdCB0aGluayBUPTEg Zm9yY2VzIHRoZSBQQ0MgdG8gd2FpdCBmb3IgYSBQQ1VwZCBiZWZvcmUgc2VuZGluZyB0aGUgaW5p dGlhbCBzbmFwc2hvdCBhcyB5b3UgaGF2ZSBzaG93bi4gIEkgZG9uoa90IHRoaW5rIHRoaXMgc3Vi c3RhbnRpYWxseSBjaGFuZ2VzIGFueXRoaW5nIGFib3V0IHNlY3Rpb24gNSwgc28gSSBzdWdnZXN0 IHJlbW92aW5nIHRoZSBkaXNjdXNzaW9uIG9mIHRoZSBUIGJpdCBmcm9tIHNlY3Rpb24gNS4NCltY aWFuXaO6U2VjdGlvbiA0IGRlc2NyaWJlcyBob3cgYSBQQ0UgY2FuIGZvcmNlIHJlLXN5bmNocm9u aXphdGlvbiBhZnRlciB0aGUgaW5pdGlhbCBMU1AtREIgc3luY2hyb25pemF0aW9uIGhhcyBiZWVu IGRvbmUuIFNlY3Rpb24gNSB0YWxrcyBhYm91dCBhbiBhbHRlcm5hdGl2ZSBtZXRob2QgZm9yIHRo ZSBpbml0aWFsIExTUC1EQiBzeW5jLiAoaS5lLiwgaW5jcmVtZW50YWwgd2F5KS4gIFRoZSBpZGVh IGhlcmUgaXMgYWxsb3cgUENFIHRvIGNvbnRyb2wgdGhlIHNlcXVlbmNlIG9mIGluY3JlbWVudGFs IHN5bmMuLCB0aGUgYXV0aG9ycyBkbyBzZWUgdGhlIHZhbHVlLiBIb3dldmVyLCB5b3UgY2FuIHNl ZSBmcm9tIHRoZSBleHBsYW5hdGlvbiBvZiBTZWN0aW9uIDUsIHNldHRpbmcgdGhlIFQ9MSBpcyBO T1QgYSBtYW5kYXRlIG9wZXJhdGlvbiB0byBlbmFibGUgaW5jcmVtZW50YWwgc3luYy4sIGJ1dCBh IGZlYXR1cmUgb3B0aWNhbCBhbmQgbm90IGNvdmVyZWQgYnkgU2VjdGlvbiA0LiBUaGUgZmlndXJl IGlzIGRyYXduIGFzIHNob3duIGJlY2F1c2Ugd2UgaW50ZW5kcyB0byBjYXB0dXJlIGJvdGggZmVh dHVyZXMuIERvZXMgdGhpcyBjbGFyaWZ5IHlvdXIgZG91YnQ/DQoNClJlZ2FyZHMsDQpYaWFuDQo= --_000_C636AF2FA540124E9B9ACB5A6BECCE6B301FF0AESZXEMA512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Jon,

 

   Thank you very much for the constructive comments.&n= bsp; Please see my reply inline, marked with [Xian]:

From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Jonathan Hardwick
Sent: 2014=C4=EA2=D4=C215=C8= =D5 2:35
To: draft-minei-pce-stateful-sync-optimizations@tools.ietf.org
Cc: pce@ietf.org
Subject: [Pce] Comments on draft-minei-pce-stateful-sync-optimizatio= ns-01

 

Hi there

 

I have reviewed this draft =A8C= here are my comments.

 

Best regards<= /p>

Jon

 

Section 3.2

Figure 2, I think the =A1=B0syn= c done=A1=B1 PCRpt should have SYNC=3D0, not SYNC=3D1.

[Xian]: Indeed. Thank you for spotting this typo.

 

Section 5.2

   If a PCC has to force full LSP= DB

   synchronization due to reasons= including but not limited: (1) local

   policy configured at the PCC; = (2) no sufficient LSP state caches for

   incremental update, the PCC ca= n set the D flag to 0.

 

Perhaps I have misunderstood, b= ut I think case (2) above doesn=A1=AFt work.  The PCC does not know th= at it has =A1=B0no sufficient LSP state caches=A1=B1 until it receives the = OPEN from the PCE and sees what DBv the PCE has sent.  By then, the PCC has already sent its OPEN so it is too late to set D=3D0.&nb= sp; To cover case (2) the draft needs a mechanism for the PCC to change its= mind and tell the PCE that it is going to send a full snapshot, not a repl= ay of the missing database updates.  The simplest thing is probably for the PCC to bring the session down and then = bring it back up again with D=3D0.

 

[Xian]:  It actually depends, IMHO. If it is due to the 1st = reason listed above, then, it can decide before sending OPEN and set D=3D0.= The cases as a result of the 2nd reason might be more complicated. Your analysis would be one of the cases, in which a P= CC can detect the insufficient LSP state caches ONLY after it gets the DB v= ersion information from the other party. But if a PCC has no LSP state cach= es or incomplete (missing quite some LSP state or those of the DB version in between), I think it is possi= ble that it can decide without even checking the DBv from the other party. = Does this clarify?

 

To include the case you described, how about we update the text&n= bsp; as below?

 

OLD:

   If a PCC has to force full LSP DB<= /p>

   synchronization due to reasons including but not lim= ited: (1) local

   policy configured at the PCC; (2) no sufficient LSP = state caches for

   incremental update, the PCC can set the D flag to 0.=

 

[DD] NEW:

   If a PCC may have to force full LSP DB

   synchronization due to reasons including but not lim= ited: (1) local

   policy configured at the PCC; (2) no sufficient LSP = state caches for

   incremental update, the PCC can set the D flag to 0. Note a PC= C may have to bring

 down the current session and  force a full LSPDB syn= chronization with D flag set to

0 in the  subsequent open message.=

 

Section 4 talks about the PCE h= aving to mark its LSP database as stale, and then remove any stale LSPs at = the end of the synchronization process.  I assume that this does not a= pply in section 5.  To avoid confusion, I think section 5 should state that the PCE does not mark its LSP database a= s stale if both it and the PCC have set D=3D1.

[Xian]:= Sure.  I think we have already explained in Section 5. The last sente= nce of the paragraph below Figure 7 says: =A1=B0Note that the PCE should no= t mark the existing LSPs as stale for incremental state synchronisation=A1=B1.

 

In figure 7, I may have misunde= rstood section 4, but I don=A1=AFt think this is how the T bit is specified= .  I don=A1=AFt think T=3D1 forces the PCC to wait for a PCUpd before = sending the initial snapshot as you have shown.  I don=A1=AFt think this substantially changes anything about section 5, so I suggest re= moving the discussion of the T bit from section 5.

[Xian]=A3=BASection 4 describes how a PCE can force re-synchronization after the initial LSP-DB synchronization has been done.= Section 5 talks about an alternative method for the initial LSP-DB sync. (= i.e., incremental way).  The idea here is allow PCE to control the seq= uence of incremental sync., the authors do see the value. However, you can see from the explanation of Section 5, = setting the T=3D1 is NOT a mandate operation to enable incremental sync., b= ut a feature optical and not covered by Section 4. The figure is drawn as s= hown because we intends to capture both features. Does this clarify your doubt?

 

Regards,

Xian

--_000_C636AF2FA540124E9B9ACB5A6BECCE6B301FF0AESZXEMA512MBSchi_-- From nobody Sun Feb 23 20:03:23 2014 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 045171A07E8 for ; Sun, 23 Feb 2014 20:03:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.038 X-Spam-Level: X-Spam-Status: No, score=-2.038 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] 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 uFSPKixtQ640 for ; Sun, 23 Feb 2014 20:03:19 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D313C1A02E2 for ; Sun, 23 Feb 2014 20:03:18 -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 BBL00111; Mon, 24 Feb 2014 04:03:17 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 24 Feb 2014 04:03:11 +0000 Received: from SZXEML450-HUB.china.huawei.com (10.82.67.193) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 24 Feb 2014 04:03:14 +0000 Received: from szxeml556-mbs.china.huawei.com ([169.254.4.34]) by szxeml450-hub.china.huawei.com ([10.82.67.193]) with mapi id 14.03.0158.001; Mon, 24 Feb 2014 12:03:06 +0800 From: Dhruv Dhody To: Daniel King , "pce@ietf.org" Thread-Topic: [Pce] I-D Action: draft-ietf-pce-hierarchy-extensions-01.txt Thread-Index: AQHPKcz22KFguJiPJkmJmY6ov8/eKZq0w6YAgA8RUsA= Date: Mon, 24 Feb 2014 04:03:05 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B7554345A@szxeml556-mbs.china.huawei.com> References: <20140214213654.2926.32891.idtracker@ietfa.amsl.com> <070101cf29ce$af39b430$0dad1c90$@olddog.co.uk> In-Reply-To: <070101cf29ce$af39b430$0dad1c90$@olddog.co.uk> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.146.248] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pce/pGeJcixJWJfZz0AwhVac6IY4LDc Cc: Quintin zhao Subject: Re: [Pce] I-D Action: draft-ietf-pce-hierarchy-extensions-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: Mon, 24 Feb 2014 04:03:22 -0000 Hi Dan and All, > -----Original Message----- > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Daniel King > Subject: Re: [Pce] I-D Action: draft-ietf-pce-hierarchy-extensions-01.txt >=20 > Hi All, >=20 > A few discussion points for the H-PCE extensions I-D: >=20 > 1. New OF: common transit domain diversity. Known as Minimize the number = of > Common Transit Domains (MCTD). Useful? >=20 > The actual description/proposal is documented in > http://tools.ietf.org/html/draft-dwpz-pce-domain-diverse-00#section-4.3. = The > authors are suggesting it might be more efficient to include directly int= o > the H-PCE extensions I-D. [DD] IMO along with OF, the domain-diverse bit in SVEC object is also suita= ble for the WG's H-PCE extn document.=20 http://tools.ietf.org/html/draft-dwpz-pce-domain-diverse-00#section-4.1 >=20 > 2. Implementation Experience? >=20 > We are planning to add an "Implementation Experience" section, as per RFC= 6982. > If you are prototyping/implementing it would be great if you can send me = any > details of implementation that you wish to share (via the I-D). > Per RFC6982, the information I could use, includes: >=20 > >> > o The organization responsible for the implementation, if any. [DD] Huawei >=20 > o The implementation's name and/or a link to a web page describing > the implementation. [DD] n/a >=20 > o A brief general description. [DD] Hierarchical PCE (Parent) is used when the domain-sequence is unknown. >=20 > o The implementation's level of maturity: research, prototype, > alpha, beta, production, widely used, etc. [DD] Prototype >=20 > o Coverage: which parts of the protocol specification are > implemented and which versions of the Internet-Draft were > implemented. [DD] OPEN, RP, Domain-ID TLV etc. Parent PCE determine domain-sequence. Parent PCE computes end to end path. >=20 > o Licensing: the terms under which the implementation can be used. > For example: proprietary, royalty licensing, freely distributable > with acknowledgement (BSD style), freely distributable with > requirement to redistribute source (General Public License (GPL) > style), and other (specify). [DD] Proprietary >=20 > o Implementation experience: any useful information the implementers > want to share with the community. [DD] Used PCEP protocol itself to find the destination domain when unknown. >=20 > o Contact information: ideally a person's name and email address, > but possibly just a URL or mailing list. [DD] Dhruv Dhody [dhruv.dhody@huawei.com] Regards, Dhruv >=20 > In addition, this section can contain information about the > interoperability of any or all of the implementations, including > references to test-case descriptions and interoperability reports, > when such exist. > << >=20 > Br, Dan & Authors >=20 > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: February 14, 2014 9:37 PM > To: i-d-announce@ietf.org > Cc: pce@ietf.org > Subject: I-D Action: draft-ietf-pce-hierarchy-extensions-01.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Path Computation Element Working Group = of > the IETF. >=20 > Title : Extensions to Path Computation Element > Communication Protocol (PCEP) for Hierarchical Path Computation Elements > (PCE) > Authors : Fatai Zhang > Quintin Zhao > Oscar Gonzalez de Dios > Ramon Casellas > Daniel King > Filename : draft-ietf-pce-hierarchy-extensions-01.txt > Pages : 14 > Date : 2014-02-14 >=20 > Abstract: > The Hierarchical Path Computation Element (H-PCE) architecture, > provides a mechanism to allow the optimum sequence of domains to be > selected,and the optimum end-to-end path to be derived through the > use of a hierarchical relationship between domains. >=20 > This document defines the Path Computation Element Protocol (PCEP) > extensions for the purpose of implementing Hierarchical PCE > procedures which are described in the aforementioned document. These > extensions are experimental and published for examination, > discussion, implementation, and evaluation. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-pce-hierarchy-extensions/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-pce-hierarchy-extensions-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-hierarchy-extensions-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From nobody Mon Feb 24 01:32:02 2014 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 492251A0225 for ; Fri, 21 Feb 2014 10:00:36 -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 Sr__spb8ve-S for ; Fri, 21 Feb 2014 10:00:34 -0800 (PST) Received: from smtp.webfaction.com (mail6.webfaction.com [74.55.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA111A01D5 for ; Fri, 21 Feb 2014 10:00:34 -0800 (PST) Received: from [192.168.0.124] (c-67-170-243-110.hsd1.ca.comcast.net [67.170.243.110]) by smtp.webfaction.com (Postfix) with ESMTP id AE073225C388; Fri, 21 Feb 2014 18:00:29 +0000 (UTC) Message-ID: <5307943A.6060808@grotto-networking.com> Date: Fri, 21 Feb 2014 10:00:26 -0800 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Julien Meuric , draft-ietf-pce-wson-routing-wavelength@tools.ietf.org References: <53038CFE.40003@orange.com> In-Reply-To: <53038CFE.40003@orange.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/pce/jduM36gm3BoYsnQ39i3nFkjy1yw X-Mailman-Approved-At: Mon, 24 Feb 2014 01:31:59 -0800 Cc: "pce@ietf.org" Subject: Re: [Pce] Last IPR Check on draft-ietf-pce-wson-routing-wavelength 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, 21 Feb 2014 18:00:36 -0000 Yes, I'm aware of IPR that applies to this draft & the IPR has been disclosed in compliance with IETF IPR rules as follows: http://datatracker.ietf.org/ipr/search/?option=document_search&id=draft-ietf-pce-wson-routing-wavelength Regards, Greg Bernstein On 2/18/2014 8:40 AM, Julien Meuric wrote: > Dear authors of the aforementioned document, > > Has all IPR that applies to draft-ietf-pce-wson-routing-wavelength > been disclosed in compliance with IETF IPR rules? (see RFCs 3979, > 4879, 3669 and 5378 for more details) > > Note that an associated IPR was disclosed in September 2010. > > A response from each of you is expected. > > Regards, > > JP & Julien > > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From nobody Mon Feb 24 17:53:07 2014 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 49FF91A0235 for ; Mon, 24 Feb 2014 17:53:06 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 rBwEVFNtzkYL for ; Mon, 24 Feb 2014 17:53:03 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id CDF1F1A0224 for ; Mon, 24 Feb 2014 17:53:02 -0800 (PST) Received: from mail97-tx2-R.bigfish.com (10.9.14.241) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.22; Tue, 25 Feb 2014 01:53:01 +0000 Received: from mail97-tx2 (localhost [127.0.0.1]) by mail97-tx2-R.bigfish.com (Postfix) with ESMTP id 9E2F8C00FB for ; Tue, 25 Feb 2014 01:53:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(zzc85dhec9I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h8275bh18c673h1de097hz2fh109h2a8h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1fe8h1ff5h209eh20f0h2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh24c1m1155h) Received-SPF: pass (mail97-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=hanantha@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(164054003)(37854004)(199002)(189002)(83072002)(90146001)(36756003)(83322001)(65816001)(80022001)(87936001)(86362001)(56816005)(93516002)(74706001)(85852003)(74876001)(47736001)(49866001)(4396001)(80976001)(2656002)(59766001)(76796001)(87266001)(76786001)(77982001)(81342001)(81542001)(85306002)(76176001)(66066001)(79102001)(69226001)(95416001)(50986001)(63696002)(31966008)(95666003)(56776001)(47446002)(74662001)(74366001)(81816001)(53806001)(46102001)(54356001)(54316002)(81686001)(83506001)(16236675002)(51856001)(76482001)(47976001)(74502001)(93136001)(94316002)(92726001)(94946001)(92566001)(94096001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB775; H:BY2PR05MB774.namprd05.prod.outlook.com; CLIP:66.129.239.13; FPR:EAA2FED4.AF13B02A.1DF7BDBB.6E4B10B.202EA; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail97-tx2 (localhost.localdomain [127.0.0.1]) by mail97-tx2 (MessageSwitch) id 1393293178982691_3660; Tue, 25 Feb 2014 01:52:58 +0000 (UTC) Received: from TX2EHSMHS001.bigfish.com (unknown [10.9.14.231]) by mail97-tx2.bigfish.com (Postfix) with ESMTP id DC6F038006B for ; Tue, 25 Feb 2014 01:52:58 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS001.bigfish.com (10.9.99.101) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 25 Feb 2014 01:52:58 +0000 Received: from BY2PR05MB775.namprd05.prod.outlook.com (10.141.224.152) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.411.0; Tue, 25 Feb 2014 01:52:57 +0000 Received: from BY2PR05MB774.namprd05.prod.outlook.com (10.141.224.143) by BY2PR05MB775.namprd05.prod.outlook.com (10.141.224.152) with Microsoft SMTP Server (TLS) id 15.0.883.10; Tue, 25 Feb 2014 01:52:55 +0000 Received: from BY2PR05MB774.namprd05.prod.outlook.com ([10.141.224.143]) by BY2PR05MB774.namprd05.prod.outlook.com ([10.141.224.143]) with mapi id 15.00.0883.010; Tue, 25 Feb 2014 01:52:56 +0000 From: Hariharan Ananthakrishnan To: "pce@ietf.org" Thread-Topic: comments draft-ietf-pce-stateful-pce-08.txt Thread-Index: AQHPMcxNobG2doiZKUqv4mIrhOE3bA== Date: Tue, 25 Feb 2014 01:52:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.239.13] x-forefront-prvs: 01334458E5 Content-Type: multipart/alternative; boundary="_000_CF31377651DChananthajunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/pce/Y9glZ3rc6o2ebmvlQ36kKt-ooUU Subject: [Pce] comments draft-ietf-pce-stateful-pce-08.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, 25 Feb 2014 01:53:06 -0000 --_000_CF31377651DChananthajunipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Authors, Couple of comments: [1] section 5.6.2 - Active Stateful PCE LSP Update " For each LSP, it sends an LSP State Report carried on PCRpt message = to the PCE, indicating that the LSP's status is 'Pending'. " [Hari] What is the "Pending" status corresponds to in LSP Object ? Is it LS= P Operational bits (0-7) ? Does state 'Pending' corresponds to GOING-DOWN(3= ) or GOING-UP(4) ? [2] section 6.2 - The PCUpd Message "A PCC May respond with multiple LSP State Reports to report LSP setup prog= ress of a single LSP. In that case, the SRP-ID-number MUST be included for = the first message, for subsequent messages the reserved value 0x00000000 SH= OULD be used". [Hari] A PCC implementation may send a PCRpt immediately after receiving a= PCUpdate (without waiting for RSVP completion). Later it sends a PCRpt, wh= en it receives updates from RSVP. Putting this behavior in the above conte= xt, could you please clarify the if the below behavior is correct: PCUpdate (SRP-ID 100) -----> PCC PCE <----------- PCRpt (SRP-ID 100, LSP Operational =3D GOING-UP) [ Without= waiting for RSVP signaling ] PCE <----------- PCRpt (SRP-ID 0x0000000, LSP Operational bit =3D UP ] [Aft= er receiving successful RSVP setup ] [3] section 7.2 (SRP Object) "An SRP-ID-number is considered unacknowledged and cannot be reused until = a PCErr or PCRpt arrives with an SRP-ID-number equal or higher for the same= LSP. A PCRpt with state "Pending" is not considered as an acknowledgement.= " [Hari] Per section 6.2, the first message (PCRpt) will have the SRP-ID and = status as "Pending" since the LSP hasn't been signaled. In this case, does = the SRP-ID in PCRpt considered unacknowledged ? It would be great if the S= RP-ID could be explained with an example especially for the PCUpdate cases = from PCC perspective. [4] Section 7.3.1. [Hari] Shouldn't the IPV4-LSP-IDENTIFIERES-TLV length be 16 ? Similar chan= ges for IPV6-LSP-IDENTIFIER-TLV. [5] General Comment. Will the "Type=3D[TBD]" in 7.xx sections be updated wi= th the proposed values in section 8.x. Thanks, Hari --_000_CF31377651DChananthajunipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Authors,

Couple of comments:

[1] section 5.6.2 – Active Statef= ul PCE LSP Update
     “ = For each LSP, it sends an LSP State Report carried on PCRpt message to the = PCE, indicating that the LSP’s status is ‘Pending’. “

[Hari] What is the “Pending”= ; status corresponds to in LSP Object ? Is it LSP Operational bits (0-7) ? = Does state ‘Pending’ corresponds to GOING-DOWN(3) or GOING-UP(4= ) ?

[2] section 6.2 – The PCUpd Messa= ge

“A PCC May respond with multiple = LSP State Reports to report LSP setup progress of a single LSP. In that cas= e, the SRP-ID-number MUST be included for the first message, for subsequent= messages the reserved value 0x00000000 SHOULD be used”.

[Hari] A PCC implementation  = may send a PCRpt immediately after receiving a PCUpdate (without waiting fo= r RSVP completion). Later it sends a PCRpt, when it receives updates from R= SVP.  Putting this behavior in the above context, could you please clarify the if the below behavior is correct:

PCUpdate (SRP-ID 100) ——= 212;——> PCC
PCE <————= 212;—————— PCRpt (SRP-ID 100, LSP Opera= tional =3D GOING-UP) [ Without waiting for RSVP signaling ]
PCE <————= 212;—————— PCRpt (SRP-ID 0x0000000, LSP= Operational bit =3D UP ] [After receiving successful RSVP setup ]

[3] section 7.2 (SRP Object) 

 “An SRP-ID-number is considered unacknowledged and cannot = be reused until a PCErr or PCRpt arrives with an SRP-ID-number equal or hig= her for the same LSP. A PCRpt with state "P= ending” is not considered as an acknowledgement.”

[Hari] Per section 6.2, the first messa= ge (PCRpt) will have the SRP-ID and status as “Pending” since t= he LSP hasn’t been signaled. In this case, does the SRP-ID in PCRpt c= onsidered unacknowledged ?  It would be great if the SRP-ID could be explained with an example especially for the PCUpdate case= s from PCC perspective.


[4] Section 7.3.1.
   
[Hari] Shouldn’t the IPV4-LSP-IDE= NTIFIERES-TLV length be 16 ?  Similar changes for IPV6-LSP-IDENTI= FIER-TLV.

[5] General Comment. Will the “Ty= pe=3D[TBD]” in 7.xx sections be updated with the proposed values in s= ection 8.x.

Thanks,
Hari

--_000_CF31377651DChananthajunipernet_-- From nobody Tue Feb 25 02:13:30 2014 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 EED4A1A067A for ; Tue, 25 Feb 2014 02:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 iZuuuA785wK8 for ; Tue, 25 Feb 2014 02:13:26 -0800 (PST) Received: from navarro.puc.rediris.es (navarro.puc.rediris.es [IPv6:2001:720:418:ca01::131]) by ietfa.amsl.com (Postfix) with ESMTP id 1E05D1A0688 for ; Tue, 25 Feb 2014 02:13:26 -0800 (PST) Received: from [84.88.62.208] (helo=leo) by navarro.puc.rediris.es with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1WIF0u-0002Fi-2H for pce@ietf.org; Tue, 25 Feb 2014 11:13:24 +0100 Received: from [84.88.61.50] (unknown [84.88.61.50]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id 533661FDFD for ; Tue, 25 Feb 2014 11:13:20 +0100 (CET) X-Envelope-From: ramon.casellas@cttc.es Message-ID: <530C6CC1.7020606@cttc.es> Date: Tue, 25 Feb 2014 11:13:21 +0100 From: Ramon Casellas User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: pce@ietf.org References: <52EFCBE6.60309@orange.com> In-Reply-To: <52EFCBE6.60309@orange.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spamina-Bogosity: Ham Archived-At: http://mailarchive.ietf.org/arch/msg/pce/qDkgfN5Sv3rMiUDpS9_SZtQf5HM Subject: Re: [Pce] WG Last Call of draft-ietf-pce-wson-routing-wavelength-10 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, 25 Feb 2014 10:13:29 -0000 El 03/02/2014 18:03, Julien Meuric escribió: > Hi all. > > Since many of you are going to dedicate some time to IETF matters over > the upcoming days, here comes some homework. > This message ignites a 2-week WG last call on > draft-ietf-pce-wson-routing-wavelength-10. It will end on Monday, > February 17, 11:59 PM (UTC-12). Dear all, A (late) short, fast review of the document below. Feel free to accept/discard at your discretion R. General Comments: * In general, requirements are stated in terms of messages (e.g. PCReq and PCRep) rather than in terms of PCEP requests and responses. IMHO, given that PCReq messages contain svec lists, lists of requests, etc. I would suggest the requirements using the request/response RBNF constructs. For example: OLD The PCReq Message MUST include the path computation type. NEW A PCEP request [for a lighpath within a PCReq message] MUST include the path computation type. Section 2.1.1 ========================== I would move the first bullet "1" out of 2.1.1 which is focused on RWA. Requirement "1" is to specify R or RWA Section 2.1.1 then focuses on RWA OLD When the PCReq Message is RWA path computation type, the PCReq Message MUST further ... NEW When the request is a RWA path computation type, the request MUST further include ... - (ii) Non-Explicit labels in the form of Label Sets (This will allow Distributed WA at a node level where each node would select the wavelength from the Label Sets) I am not sure of what Non-Explicit implies here. Maybe change to "a set of recommended labels"... I am confused here. If the path computation type is RWA, the Distributed WA does not apply, does it? A new requirement could be added: is a requirement that when the R path computation type is selected the PCE MAY provide a Label Set ? NEW 2.b In case of a R computation type, the response MAY provide [Non-Explicit ?] labels in the form of Label Sets. This will allow Distributed WA at a node level where each node would select the wavelength from the Label Sets. OLD 3. The PCRep Message MUST include the route, wavelengths assigned to the route and indication of which wavelength assignment option has been applied (ELC or Label Sets). NEW 3. In case of a RWA computation type, the response MUST include the wavelength(s) assigned to the route and an indication of which label assignment option has been applied (ELC or Label Sets). Rationale: the route is implicit by RFC5440 OLD 4. In the case where a valid path is not found, the PCRep Message MUST include why the path is not found (e.g., no route, wavelength not found, optical quality check failed, etc.) NEW 4. In the case where a valid path is not found, the reponse MUST include why the path is not found (e.g., no route, wavelength not found, optical quality check failed, etc.) Section 2.1.2 ============= [Q] Is the possibliity of requesting R bulk requests not a requirement? or is it assumed that existing mechanisms are enough? Section 2.1.3 ============== OLD 1. For a re-optimization request, the PCReq Message MUST provide the path to be re-optimized and include the following options NEW 1. For a re-optimization request, the request MUST provide both the route and current wavelength to be re-optimized and MAY include the following options: a. b. [c is implicit by not including options] Section 2.1.4 ============== OLD For any PCReq Message that is associated with a request for wavelength assignment the requester (PCC) MUST be able to specify a restriction on the wavelengths to be used. Note that the requestor (PCC) is NOT required to furnish any range restrictions. NEW? For any RWA computation type request, the requester (PCC) MAY specify a restriction on the wavelengths to be used. Rationale: "MUST be able but is NOT required" Section 2.1.5 =============== OLD The PCReq Message May include specific operator's policy information for WA (E.g., random assignment, descending order, ascending order, etc.) NEW A RWA computation type request MAY include the requestor preference for WA (E.g., random assignment, descending order, ascending order, etc.). A response SHOULD follow the requestor preference unless operator's policy. Rationale: Change wording? OLD The PCReq Message SHOULD be able to request, when requesting a 1+1 connection (e.g. link disjoint paths), that both paths use the same wavelength. -> It is not clear to me how to request a 1+1 connection. I think this is an important requirement in itself. In general, what are the requirements regarding protection in PCEP? what about other protection types? OLD The PCReq Message SHOULD be able to request, when performing 3R, that wavelength may change or not NEW In a network with wavelength conversion capabilities (e.g. sparse 3R regenerators), a request SHOULD be able to indicate whether a single, contiguous wavelength should be allocated or not. In other words, the requesting PCC SHOULD be able to constrain the wavelength continuity even if wavelength conversion is available. Rationale: the initial requirement is a bit vague. I am not sure if the intent of he requirement is that? Section 2.1.6 =============== OLD The PCReq Message MUST be able to specify restrictions for signal compatibility either on the endpoint or any given link. The following signal processing capability should be supported at a minimum: "A request MUST be able to ..." s/on the endpoint/on the endpoints ? s/capability/capabilities ? Notes: Not sure about the "any given link". It may be good to be more verbose on this requirement. Relationship with IRO? Section 3 =============== 3. Manageability Considerations Nothing is said regarding session parameters on a PCE: o Policy regarding WA algorithms: first-fit, random... o Whether to use Explicit Label Control or not ... Final comments =============== - Nothing is said about bidirectional LSPs. It seems that being able to compute a bi-directional LSP with the additional constraint of having the same upstream and downtream wavelength would be IMHO a requirement. From nobody Tue Feb 25 05:03:56 2014 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 F116E1A03F2 for ; Tue, 25 Feb 2014 05:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, SPF_PASS=-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 42PgJWUhzP14 for ; Tue, 25 Feb 2014 05:03:53 -0800 (PST) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 84F561A0070 for ; Tue, 25 Feb 2014 05:03:52 -0800 (PST) Received: by mail-we0-f174.google.com with SMTP id w61so357491wes.19 for ; Tue, 25 Feb 2014 05:03:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ImqyCpb2Ayx9qKz3v+g0C5rDFs8doznuJSUraTfWqdU=; b=hD9QIGSFz1XZGNd51gUwE/Ih4/q83caMax6gV4365fCLRWoN8h3BNleBZiLJjOx2Uu J5BslLKOS63M/+YNQODt4Bnm3hg5k0gvFDNwX02k2v64FrhzN2RmZ7OfnyyespJckp+3 70mBWSZ7ZMmxfYbz1QXycHIqdmYBLkk3QtlbchaMAWneDiwoKIcymbvN5/y+ZccFFPqk HU4vHBm5rbI7Nhq+Hp5nLDqp03uJm2SZ+elgwwu4q23dWm0z91Pr74IOuakQ9q2T+1uH u4yCZW6h3ZQZ+J5YR+vkasGZsTcZy+aFnBc+IGukJcBRuSV4UeA5KYsMfFrNDolco99d WI2A== MIME-Version: 1.0 X-Received: by 10.194.84.144 with SMTP id z16mr24675951wjy.23.1393333431267; Tue, 25 Feb 2014 05:03:51 -0800 (PST) Received: by 10.216.61.12 with HTTP; Tue, 25 Feb 2014 05:03:51 -0800 (PST) In-Reply-To: <53038A25.4090506@orange.com> References: <52EFCBE6.60309@orange.com> <53038A25.4090506@orange.com> Date: Tue, 25 Feb 2014 14:03:51 +0100 Message-ID: From: Cyril Margaria To: Julien Meuric Content-Type: multipart/alternative; boundary=089e0102ddae3976ac04f33ab86c Archived-At: http://mailarchive.ietf.org/arch/msg/pce/Y5boM_bISKkn1oLCyl6_94BsJ1U Cc: "pce@ietf.org" Subject: Re: [Pce] WG Last Call of draft-ietf-pce-wson-routing-wavelength-10 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, 25 Feb 2014 13:03:55 -0000 --089e0102ddae3976ac04f33ab86c Content-Type: text/plain; charset=ISO-8859-1 Hi PCErs, I have a few comments on the document: Section 1.1 : Strange indentation indentation: ============ The indentation of the following section is not consistent: Section 1.1 Section 2.1 Section 2.1.1 Section 3.1 Section 3.2 ... Section 2.1.1 ============= Is there a requierement for RWA-capable PCE discovery? IGP-based discovery is addressed in section 3.5, but OPEN extension could also be covered. A PCC expecting RWA-capable PCE will only be able to detect a non RWA capable upon request. It is likely that request are not very frequent in WSON networks, so a misconfiguration may be discovered quite late. OPEN extension would allow a faster detection. Req 2) : I believe ii) is not only for D-RWA, but also covers RWA. OLD: (i) Explicit Label Control (ELC) [RFC4003] (ii) Non-Explicit labels in the form of Label Sets (This will allow Distributed WA at a node level where each node would select the wavelength from the Label Sets) NEW: (i) Explicit Label Control (ELC) [RFC4003]. (ii) Non-Explicit labels in the form of Label Sets. The PCC can select the label based on local policy. Note that option ii) may also be used in R+WA or DWA. Section 2.1.2 ============= Is it possible to mix in a bulk request, R and RWA requests? Section 2.1.4 ============= OLD For any PCReq Message that is associated with a request for wavelength assignment the requester (PCC) MUST be able to specify a restriction on the wavelengths to be used. NEW For a RWA request, the request MUST be able to specify an option for a restriction on the wavelengths to be used. The requester MAY use this option to restrict the assigned wavelenght for Explict Label or Label Sets. -- This is more in line with the rest of the document. The req being on the protocol, not involving the PCC is better. OLD Note that the requestor (PCC) is NOT required to furnish any range restrictions. This restriction is to be interpreted by the PCE as a constraint on the tuning ability of the origination laser transmitter. NEW Note that the requestor is NOT required to furnish any range restrictions. This restriction may for example come from the tuning ability of a laser transmitter, any optical element, or an policy based restriction. -- The PCE should not interpret the restriction, just apply it. Section 2.1.5 ============= in "The PCReq Message May include specific operator's policy", do you mean MAY? The section could be renamed "Wavelength assignement policy constraints" The explicit label versus Label set could also fit in this section, or section 2.1.1 req 2 should refer to this section. OLD The PCReq Message SHOULD be able to request, when requesting a 1+1 connection (e.g. link disjoint paths), that both paths use the same wavelength. NEW A request for 2 or more path MUST be able to specify an option constraining the path to have the same wavelength(s) assigned. -- Computing a 1+1 path is one use case, but this may apply for other protection type. This can be achieved by removing the protection aspect. Section 2.1.6 ============= NEW o OIC list -- draft-ietf-ccamp-rwa-info-21 defines the concept of OIC, PCEP should be able to transport the same kind of info Best regards, Cyril On 18 February 2014 17:28, Julien Meuric wrote: > Hi all. > > This last call has ended. We have not seen many reviews. The chairs' will > come soon. > > JP & Julien > > > Feb. 03, 2014 - Julien Meuric: > > Hi all. >> >> Since many of you are going to dedicate some time to IETF matters over >> the upcoming days, here comes some homework. >> >> This message ignites a 2-week WG last call on draft-ietf-pce-wson-routing-wavelength-10. >> It will end on Monday, February 17, 11:59 PM (UTC-12). >> >> Thanks, >> >> JP & Julien >> >> _______________________________________________ >> 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 > --089e0102ddae3976ac04f33ab86c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi PCErs,

I have a few commen= ts on the document:


Section 1.1 : Strange indentation
<= br>
indentation:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The indentat= ion of the following section is not consistent:

Section 1.1
Section 2.1
Section 2.1.1
Section 3.1
= Section 3.2
...=A0



Section 2.1.1
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

Is there a requierement for RWA-capable PCE= discovery?
IGP-based discovery is addressed in section 3.5, but OPEN e= xtension could also be covered.
A PCC expecting RWA-capable PCE will only be able to detect a no= n RWA capable upon request.
It is likely that request are no= t very frequent in WSON networks, so a misconfiguration may be discovered q= uite late.
OPEN extension would allow a faster detection.



Req 2) : I believe ii) is not only for D-RWA, but also covers RWA.=
OLD:
=A0=A0=A0=A0 (i) Explicit Label Control (ELC) [RFC4003]

= =A0=A0=A0=A0 (ii)=A0=A0=A0 Non-Explicit labels in the form of Label Sets (T= his will
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 allow Distributed WA at a node level wher= e each node would
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 select the wavelengt= h from the Label Sets)

NEW:
=A0=A0=A0=A0 (i)=A0 Explicit Label Co= ntrol (ELC) [RFC4003].

=A0=A0=A0=A0 (ii) Non-Explicit labels in the = form of Label Sets. The PCC can select the label based on local policy.

=A0=A0 Note that option ii) may also be used in R+WA or DWA.

Section 2.1.2
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=A0 Is it = possible to mix in a bulk request, R and RWA requests?

Section 2.1.4=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


OLD
=A0=A0 For any PCReq Message that is associated with a request for=A0=A0 wavelength assignment the requester (PCC) MUST be able to specify = a
=A0=A0 restriction on the wavelengths to be used.
NEW
=A0=A0 For= a RWA request, the request MUST be able to specify an option for
=A0=A0 a restriction on the wavelengths to be used.
=A0=A0 The requester= MAY use this option to restrict the assigned wavelenght for
=A0=A0 Expl= ict Label or Label Sets.

--
=A0This is more in line with the rest= of the document. The req being on the protocol, not involving the PCC is b= etter.

OLD
=A0=A0 Note that the requestor (PCC) is NOT required to furnish = any range
=A0=A0 restrictions. This restriction is to be interpreted by = the PCE as a
=A0=A0 constraint on the tuning ability of the origination = laser
=A0=A0 transmitter.

NEW
=A0=A0 Note that the requestor is NOT req= uired to furnish any range
=A0=A0 restrictions. This restriction may for= example come from the tuning
=A0=A0 ability of a laser transmitter, any= optical element, or an policy based restriction.

--
=A0The PCE should not interpret the restriction, just apply it.
Section 2.1.5
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

in &q= uot;The PCReq Message May include specific operator's policy", do = you mean MAY?

The section could be renamed "Wavelength assignem= ent policy constraints"

The explicit label versus Label set could also fit in this section, or = section 2.1.1 req 2 should refer to this section.

OLD
=A0 The PCR= eq Message SHOULD be able to request, when requesting a 1+1
=A0 connecti= on (e.g. link disjoint paths), that both paths use the same
=A0 wavelength.
NEW
=A0 A request for 2 or more path MUST be able to = specify an option constraining the path to have the same wavelength(s) assi= gned.


--
=A0Computing a 1+1 path is one use case, but this ma= y apply for other protection type. This can be achieved by removing the pro= tection aspect.

Section 2.1.6
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

NEW
= =A0=A0=A0=A0=A0 o OIC list

--

draft-ietf-ccamp-rwa-info-21 de= fines the concept of OIC, PCEP should be able to transport the same kind of= info


Best regards,
Cyril



On 18 February 2014 17:28, Julien Meuric <= julien.meuric@orange.com> wrote:
Hi all.

This last call has ended. We have not seen many reviews. The chairs' wi= ll come soon.

JP & Julien


Feb. 03, 2014 - Julien Meuric:

Hi all.

Since many of you are going to dedicate some time to IETF matters over the = upcoming days, here comes some homework.

This message ignites a 2-week WG last call on draft-ietf-pce-wson-routing-<= u>wavelength-10. It will end on Monday, February 17, 11:59 PM (UTC-12).=

Thanks,

JP & Julien

_______________________________________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce



_______________________________________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce

--089e0102ddae3976ac04f33ab86c-- From nobody Tue Feb 25 09:06:29 2014 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 7BFD61A00EA for ; Tue, 25 Feb 2014 08:59:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 IhDECckCh7Ck for ; Tue, 25 Feb 2014 08:59:39 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 9405E1A0074 for ; Tue, 25 Feb 2014 08:59:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2558; q=dns/txt; s=iport; t=1393347579; x=1394557179; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Tv8jLB3w8EdcZZ9tivJ7Ycx/WM6eVSonlLK9pSOEy18=; b=kQ3WptpFO74IqRjDjPWkveFHeZtjGFHFl8Ty1tk09pH27B0pZ9LHtZRw Hk6ySucciwlas3C2t2oEEvs8rsfJJdIuAddb6ONzqFL89UjQmQmR7YDVY Hn7biogUrKjII1cDThkviCY9N3VkBb3vZqEuhwnPMYmVrB+8574r+018s E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAM/LDFOtJV2c/2dsb2JhbABZgwY7UQbBUYEYFnSCJQEBAQR3AgwGAQgRAwECYR0IAgQBDQUJh3wIBccCF44AAhEBHTMHBoQyBJg0gTKQdYFvgT6BaAkXIg X-IronPort-AV: E=Sophos;i="4.97,541,1389744000"; d="scan'208";a="23060523" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP; 25 Feb 2014 16:59:38 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1PGxcTh007542 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 16:59:38 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.212]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 10:59:37 -0600 From: "Zafar Ali (zali)" To: Cyril Margaria , "pce@ietf.org" Thread-Topic: New Version Notification for draft-ali-pce-remote-initiated-gmpls-lsp-03.txt Thread-Index: AQHPKd59iZM6sxUaDkKOcXzCdt5wmJrGU8uA Date: Tue, 25 Feb 2014 16:59:37 +0000 Message-ID: In-Reply-To: <20140214234254.26934.85981.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.86.246.242] Content-Type: text/plain; charset="Windows-1252" Content-ID: <00ECF299CE236E4F9592D7C00802E1AC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/YSTDvsESd3Gk6G1gxTvIpUY62Fo X-Mailman-Approved-At: Tue, 25 Feb 2014 09:06:26 -0800 Cc: Robert Varga , "Clarence Filsfils \(cfilsfil\)" , "Siva Sivabalan \(msiva\)" Subject: Re: [Pce] New Version Notification for draft-ali-pce-remote-initiated-gmpls-lsp-03.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, 25 Feb 2014 16:59:41 -0000 Dear Cyril and the WG: Please note that in the latest version of the draft-ali-pce-remote-initiated-gmpls-lsp-03.txt, we have addressed all comments received. Please advise of any additional comments. Thanks Regards =8A Zafar (on Behalf of co-authors). -----Original Message----- From: "internet-drafts@ietf.org" Date: Friday, February 14, 2014 6:42 PM To: zali , Oscar de Dios , "Siva Sivabalan (msiva)" , "Siva Sivabalan (msiva)" , VICTOR ALVAREZ , Xian Zhang , Robert Varga , "Clarence Filsfils (cfilsfil)" , zali , Oscar de Dios , Xian Zhang , VICTOR ALVAREZ , "Clarence Filsfils (cfilsfil)" Subject: New Version Notification for draft-ali-pce-remote-initiated-gmpls-lsp-03.txt > >A new version of I-D, draft-ali-pce-remote-initiated-gmpls-lsp-03.txt >has been successfully submitted by Zafar Ali and posted to the >IETF repository. > >Name: draft-ali-pce-remote-initiated-gmpls-lsp >Revision: 03 >Title: Path Computation Element Communication Protocol (PCEP) Extensions >for remote-initiated GMPLS LSP Setup >Document date: 2014-02-14 >Group: Individual Submission >Pages: 9 >URL: =20 >http://www.ietf.org/internet-drafts/draft-ali-pce-remote-initiated-gmpls-l >sp-03.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-ali-pce-remote-initiated-gmpls-lsp/ >Htmlized: =20 >http://tools.ietf.org/html/draft-ali-pce-remote-initiated-gmpls-lsp-03 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-ali-pce-remote-initiated-gmpls-ls= p- >03 > >Abstract: > Draft [I-D. draft-crabbe-pce-pce-initiated-lsp] specifies > procedures that can be used for creation and deletion of PCE- > initiated LSPs in the active stateful PCE model. However, this > specification focuses on MPLS networks, and does not cover remote > instantiation of paths in GMPLS-controlled networks. This document > complements [I-D. draft-crabbe-pce-pce-initiated-lsp] by addressing > the requirements for remote-initiated GMPLS LSPs. > > > =20 > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > From nobody Tue Feb 25 18:21:46 2014 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 6CE7E1A0369 for ; Tue, 25 Feb 2014 18:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 zSlPRDmXvrBB for ; Tue, 25 Feb 2014 18:21:42 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id F34D51A02D7 for ; Tue, 25 Feb 2014 18:21:41 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id va2so140991obc.37 for ; Tue, 25 Feb 2014 18:21:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=x7Ejm649DzJlmKCu6o1NiVwuWkMiqn2mU9I0G9N+NtM=; b=ioSOVQn63v9iMhZmHyCuGOpDUeMj1SrjdKXSpcPUcosMk2S1fJ7wR3njj9rWR6EKZW kAx2JxGtkxFoTvMH/UePZG8drXSmadu2h4zYYRTe6PNtirxLTrCqacMuQ1dVv070pVYj U4SYoUEScK4su8cNUTohodQB9lVX+oP4rK6WuOb4Yr+mybkX1zvZoU3zbAOOP5im9tIX cE4zrWuNF73KgzajYTH6o3J+40NiCpaHvys4d9Ll1tASnWQTtsvg03OpD2EIFmZU4Qx1 X7S/xdekxlTOoHR7N0nApkJ34ubAHzqf2mcTcBJGfHMpQlLr2aIkST8S3scLr1+wyLGc QrnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=x7Ejm649DzJlmKCu6o1NiVwuWkMiqn2mU9I0G9N+NtM=; b=a3p35Rl4GyfARfLO7UqHrmfEUES0rWKKga/8E424FM7TvU/Gp4zWt9pRYDPKag/AX8 +vwxpEj3mA+IV6HcERYZSKMb2h8oXebFQ/ilnPKmRiD6QG8w4oR+hI3S8UkgVEQh6UwV S00J43XnB7QK3x2D8H5pojEaFZ4ACt9ERbVZoHsQu4+D1bBXCWmtcbBcC5lAxvPI7h89 b5/k/Tol5u8/sEhLhsqRllWUoq3029Xqh4duKN1CIjFLvkKHLIr8Fmc18YrkVGxDv5On N+sM1Izgmh6Z3iQoiL6IdUu1I7cBz1C1VqLDJaPnoSRCS+C4Rd3amTkHla0g9EnooHeq vQxw== X-Gm-Message-State: ALoCoQlaqWmcNMlRqDQTs+3XlirRbvAQmgC0CjpmxxZar2Ux4gsN4CH7oprnXGCOa3GJVgTT11vM5fzkfituQ+AIh+jxSfAATkpO3oxahN1zmM6J7p2UQ+VK+imb7gXSvCwpryKaQWpGJ21lLFjY7lYyDrOEeXhxgmpyh5uuCVYiLi9rzu0dM8lN6Mq8DYWOXNVigXdOCHIL MIME-Version: 1.0 X-Received: by 10.60.51.230 with SMTP id n6mr4284599oeo.35.1393381300709; Tue, 25 Feb 2014 18:21:40 -0800 (PST) Received: by 10.182.80.106 with HTTP; Tue, 25 Feb 2014 18:21:40 -0800 (PST) In-Reply-To: References: Date: Tue, 25 Feb 2014 18:21:40 -0800 Message-ID: From: Ina Minei To: Hariharan Ananthakrishnan Content-Type: multipart/alternative; boundary=001a11c30c7c7744eb04f345ddbc Archived-At: http://mailarchive.ietf.org/arch/msg/pce/adKodhvfcW8i4Ls_N4fP3B7bNMc Cc: "pce@ietf.org" Subject: Re: [Pce] comments draft-ietf-pce-stateful-pce-08.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: Wed, 26 Feb 2014 02:21:44 -0000 --001a11c30c7c7744eb04f345ddbc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hari, Thank you for the review, please find answers inline, marked [ina] On Mon, Feb 24, 2014 at 5:52 PM, Hariharan Ananthakrishnan < hanantha@juniper.net> wrote: > Hi Authors, > > Couple of comments: > > [1] section 5.6.2 =E2=80=93 Active Stateful PCE LSP Update > =E2=80=9C For each LSP, it sends an LSP State Report carried on PCRp= t message > to the PCE, indicating that the LSP=E2=80=99s status is =E2=80=98Pending= =E2=80=99. =E2=80=9C > > [Hari] What is the =E2=80=9CPending=E2=80=9D status corresponds to in LS= P Object ? Is it > LSP Operational bits (0-7) ? Does state =E2=80=98Pending=E2=80=99 corresp= onds to > GOING-DOWN(3) or GOING-UP(4) ?\ > [ina] Yes, will clean up the text. "Pending" is a leftover from much earlier incarnations of this draft. > > [2] section 6.2 =E2=80=93 The PCUpd Message > > =E2=80=9CA PCC May respond with multiple LSP State Reports to report LSP= setup > progress of a single LSP. In that case, the SRP-ID-number MUST be include= d > for the first message, for subsequent messages the reserved value > 0x00000000 SHOULD be used=E2=80=9D. > > [Hari] A PCC implementation may send a PCRpt immediately after > receiving a PCUpdate (without waiting for RSVP completion). Later it send= s > a PCRpt, when it receives updates from RSVP. Putting this behavior in th= e > above context, could you please clarify the if the below behavior is > correct: > > PCUpdate (SRP-ID 100) =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94> PCC > PCE <=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94 PCRpt (SRP-ID 100, LSP Operational =3D GO= ING-UP) [ Without > waiting for RSVP signaling ] > PCE <=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94 PCRpt (SRP-ID 0x0000000, LSP Operational = bit =3D UP ] > [After receiving successful RSVP setup ] > > [ina] Yes > [3] section 7.2 (SRP Object) > > =E2=80=9CAn SRP-ID-number is considered unacknowledged and cannot be re= used > until a PCErr or PCRpt arrives with an SRP-ID-number equal or higher for > the same LSP.* A PCRpt with state "Pending=E2=80=9D is not considered as = an > acknowledgement.*=E2=80=9D > [ina] This text is not applicable, it is left over from earlier discussions on the SRP, thank you for pointing this out. > > [Hari] Per section 6.2, the first message (PCRpt) will have the SRP-ID > and status as =E2=80=9CPending=E2=80=9D since the LSP hasn=E2=80=99t been= signaled. In this case, > does the SRP-ID in PCRpt considered unacknowledged ? It would be great i= f > the SRP-ID could be explained with an example especially for the PCUpdate > cases from PCC perspective. > > > [4] Section 7.3.1. > > [Hari] Shouldn=E2=80=99t the IPV4-LSP-IDENTIFIERES-TLV length be 16 ? Si= milar > changes for IPV6-LSP-IDENTIFIER-TLV. > [ina] Yes, thank you for catching, the TLV was changed in version 07 but the length was not updated at that time :-( > > [5] General Comment. Will the =E2=80=9CType=3D[TBD]=E2=80=9D in 7.xx sec= tions be updated > with the proposed values in section 8.x. > [ina] Yes. > > Thanks, > Hari > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > --001a11c30c7c7744eb04f345ddbc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hari,=C2=A0

Thank you for the review, p= lease find answers inline, marked [ina]


On Mon, Feb 24, 2014 at 5:52 PM,= Hariharan Ananthakrishnan <hanantha@juniper.net> wrote:<= br>
Hi Authors,

Couple of comments:

[1] section 5.6.2 =E2=80=93 Active Stateful PCE LSP Update
=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9C For each LSP, it sends = an LSP State Report carried on PCRpt message to the PCE, indicating that th= e LSP=E2=80=99s status is =E2=80=98Pending=E2=80=99. =E2=80=9C

[Hari] What is the =E2=80=9CPending=E2=80=9D status corresponds = to in LSP Object ? Is it LSP Operational bits (0-7) ? Does state =E2=80=98P= ending=E2=80=99 corresponds to GOING-DOWN(3) or GOING-UP(4) ?\
<= /blockquote>

[ina] Yes, will clean up the text. "Pending" is a leftover f= rom much earlier incarnations of this draft.=C2=A0

[2] section 6.2 =E2=80=93 The PCUpd Message

=E2=80=9CA PCC May respond with multiple LSP State Reports to re= port LSP setup progress of a single LSP. In that case, the SRP-ID-number MU= ST be included for the first message, for subsequent messages the reserved = value 0x00000000 SHOULD be used=E2=80=9D.

[Hari] A PCC implementation=C2=A0=C2=A0may send a PCRpt immediat= ely after receiving a PCUpdate (without waiting for RSVP completion). Later= it sends a PCRpt, when it receives updates from RSVP.=C2=A0=C2=A0Putting t= his behavior in the above context, could you please clarify the if the below behavior is correct:

PCUpdate (SRP-ID 100) =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94> PCC
PCE <=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 PCRpt (SRP-ID 100, LSP Operat= ional =3D GOING-UP) [ Without waiting for RSVP signaling ]
PCE <=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 PCRpt (SRP-ID 0x0000000, LSP = Operational bit =3D UP ] [After receiving successful RSVP setup ]

[ina] Yes=C2=A0
=C2= =A0
[3] section 7.2 (SRP Object)=C2=A0

=C2=A0=E2=80=9CAn SRP-ID-number is considered unacknowledged and canno= t be reused until a PCErr or PCRpt arrives with an SRP-ID-number equal or h= igher for the same LSP. A PCRpt with state "= ;Pending=E2=80=9D is not considered as an acknowledgement.=E2=80= =9D

[ina] This text is not applicable, i= t is left over from earlier discussions on the SRP, thank you for pointing = this out.=C2=A0

[Hari] Per section 6.2, the first message (PCRpt) will have the = SRP-ID and status as =E2=80=9CPending=E2=80=9D since the LSP hasn=E2=80=99t= been signaled. In this case, does the SRP-ID in PCRpt considered unacknowl= edged ? =C2=A0It would be great if the SRP-ID could be explained with an example especially for the PCUpdate case= s from PCC perspective.


[4] Section 7.3.1.
=C2=A0=C2=A0=C2=A0
[Hari] Shouldn=E2=80=99t the IPV4-LSP-IDENTIFIERES-TLV length be= 16 ?=C2=A0=C2=A0Similar changes for IPV6-LSP-IDENTIFIER-TLV.

[ina] Yes, thank you for catching, the TLV w= as changed in version 07 but the length was not updated at that time :-(=C2= =A0

[5] General Comment. Will the =E2=80=9CType=3D[TBD]=E2=80=9D in = 7.xx sections be updated with the proposed values in section 8.x.

[ina] Yes. =C2=A0

Thanks,
Hari


_______________________________________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce


--001a11c30c7c7744eb04f345ddbc-- From nobody Tue Feb 25 19:01:39 2014 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 73C6E1A03B1 for ; Tue, 25 Feb 2014 19:01:38 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 dL4b6l7CZRGx for ; Tue, 25 Feb 2014 19:01:35 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED7A1A03AC for ; Tue, 25 Feb 2014 19:01:35 -0800 (PST) Received: from mail203-tx2-R.bigfish.com (10.9.14.225) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.22; Wed, 26 Feb 2014 03:01:34 +0000 Received: from mail203-tx2 (localhost [127.0.0.1]) by mail203-tx2-R.bigfish.com (Postfix) with ESMTP id F107290034F; Wed, 26 Feb 2014 03:01:33 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: VPS-19(zz98dI9371Ic85dhec9I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz8275ch1de098h1033IL8275bh8275dh18c673h1de097h186068hz2fh109h2a8h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h209eh20f0h2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch24c1m1155h) Received-SPF: pass (mail203-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=hanantha@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(164054003)(377454003)(24454002)(189002)(199002)(37854004)(31966008)(79102001)(81686001)(47446002)(74502001)(94316002)(90146001)(56816005)(74662001)(81816001)(49866001)(47976001)(47736001)(94946001)(4396001)(76796001)(76786001)(36756003)(63696002)(50986001)(92566001)(92726001)(74366001)(74876001)(85852003)(83072002)(53806001)(83506001)(54316002)(54356001)(56776001)(81542001)(51856001)(76482001)(86362001)(69226001)(74706001)(93516002)(46102001)(77982001)(93136001)(59766001)(95666003)(80976001)(81342001)(83322001)(19580395003)(19580405001)(95416001)(87266001)(16236675002)(87936001)(2656002)(15975445006)(66066001)(80022001)(65816001)(85306002)(94096001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB776; H:BY2PR05MB774.namprd05.prod.outlook.com; CLIP:66.129.239.12; FPR:E866FDD4.AC10B0EE.1DF5BD8B.6E4B10F.20428; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail203-tx2 (localhost.localdomain [127.0.0.1]) by mail203-tx2 (MessageSwitch) id 1393383691865025_19819; Wed, 26 Feb 2014 03:01:31 +0000 (UTC) Received: from TX2EHSMHS025.bigfish.com (unknown [10.9.14.252]) by mail203-tx2.bigfish.com (Postfix) with ESMTP id CEF8B2000A4; Wed, 26 Feb 2014 03:01:31 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS025.bigfish.com (10.9.99.125) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 26 Feb 2014 03:01:31 +0000 Received: from BY2PR05MB776.namprd05.prod.outlook.com (10.141.224.154) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.411.0; Wed, 26 Feb 2014 03:01:30 +0000 Received: from BY2PR05MB774.namprd05.prod.outlook.com (10.141.224.143) by BY2PR05MB776.namprd05.prod.outlook.com (10.141.224.154) with Microsoft SMTP Server (TLS) id 15.0.883.10; Wed, 26 Feb 2014 03:01:29 +0000 Received: from BY2PR05MB774.namprd05.prod.outlook.com ([10.141.224.143]) by BY2PR05MB774.namprd05.prod.outlook.com ([10.141.224.143]) with mapi id 15.00.0888.003; Wed, 26 Feb 2014 03:01:29 +0000 From: Hariharan Ananthakrishnan To: Ina Minei Thread-Topic: [Pce] comments draft-ietf-pce-stateful-pce-08.txt Thread-Index: AQHPMcxNobG2doiZKUqv4mIrhOE3bJrGz14A//+FAYA= Date: Wed, 26 Feb 2014 03:01:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.239.12] x-forefront-prvs: 0134AD334F Content-Type: multipart/alternative; boundary="_000_CF32981F5246hananthajunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/pce/3Jze1w0zVFGtjBV6Ao2ZBfKScSc Cc: "pce@ietf.org" Subject: Re: [Pce] comments draft-ietf-pce-stateful-pce-08.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: Wed, 26 Feb 2014 03:01:38 -0000 --_000_CF32981F5246hananthajunipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Ina. Another followup question. Can a PCC use PCReq with an 'active = stateful PCE' ? The PCE could respond with a PCUpdate in return or PCErr. = This will be useful for a PCC to trigger a path (re)computation based on 'l= ocal event' that a PCE might not be aware of. - Hari From: Ina Minei > Date: Tuesday, February 25, 2014 at 6:21 PM To: Hariharan Ananthakrishnan > Cc: "pce@ietf.org" > Subject: Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt Hari, Thank you for the review, please find answers inline, marked [ina] On Mon, Feb 24, 2014 at 5:52 PM, Hariharan Ananthakrishnan > wrote: Hi Authors, Couple of comments: [1] section 5.6.2 - Active Stateful PCE LSP Update " For each LSP, it sends an LSP State Report carried on PCRpt message = to the PCE, indicating that the LSP's status is 'Pending'. " [Hari] What is the "Pending" status corresponds to in LSP Object ? Is it LS= P Operational bits (0-7) ? Does state 'Pending' corresponds to GOING-DOWN(3= ) or GOING-UP(4) ?\ [ina] Yes, will clean up the text. "Pending" is a leftover from much earlie= r incarnations of this draft. [2] section 6.2 - The PCUpd Message "A PCC May respond with multiple LSP State Reports to report LSP setup prog= ress of a single LSP. In that case, the SRP-ID-number MUST be included for = the first message, for subsequent messages the reserved value 0x00000000 SH= OULD be used". [Hari] A PCC implementation may send a PCRpt immediately after receiving a= PCUpdate (without waiting for RSVP completion). Later it sends a PCRpt, wh= en it receives updates from RSVP. Putting this behavior in the above conte= xt, could you please clarify the if the below behavior is correct: PCUpdate (SRP-ID 100) -----> PCC PCE <----------- PCRpt (SRP-ID 100, LSP Operational =3D GOING-UP) [ Without= waiting for RSVP signaling ] PCE <----------- PCRpt (SRP-ID 0x0000000, LSP Operational bit =3D UP ] [Aft= er receiving successful RSVP setup ] [ina] Yes [3] section 7.2 (SRP Object) "An SRP-ID-number is considered unacknowledged and cannot be reused until = a PCErr or PCRpt arrives with an SRP-ID-number equal or higher for the same= LSP. A PCRpt with state "Pending" is not considered as an acknowledgement.= " [ina] This text is not applicable, it is left over from earlier discussions= on the SRP, thank you for pointing this out. [Hari] Per section 6.2, the first message (PCRpt) will have the SRP-ID and = status as "Pending" since the LSP hasn't been signaled. In this case, does = the SRP-ID in PCRpt considered unacknowledged ? It would be great if the S= RP-ID could be explained with an example especially for the PCUpdate cases = from PCC perspective. [4] Section 7.3.1. [Hari] Shouldn't the IPV4-LSP-IDENTIFIERES-TLV length be 16 ? Similar chan= ges for IPV6-LSP-IDENTIFIER-TLV. [ina] Yes, thank you for catching, the TLV was changed in version 07 but th= e length was not updated at that time :-( [5] General Comment. Will the "Type=3D[TBD]" in 7.xx sections be updated wi= th the proposed values in section 8.x. [ina] Yes. Thanks, Hari _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --_000_CF32981F5246hananthajunipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Thanks Ina. Another followup question. Can a PCC use PCReq with an = 216;active stateful PCE’ ? The PCE could respond with a PCUpdate in r= eturn or PCErr.  This will be useful for a PCC to trigger a path (re)c= omputation based on ‘local event’ that a PCE might not be aware of.

- Hari

From: Ina Minei <inaminei@google.com>
Date: Tuesday, February 25, 2014 at= 6:21 PM
To: Hariharan Ananthakrishnan <<= a href=3D"mailto:hanantha@juniper.net">hanantha@juniper.net>
Cc: "pce@ietf.org" <pce@ietf.= org>
Subject: Re: [Pce] comments draft-i= etf-pce-stateful-pce-08.txt

Hari, 

Thank you for the review, please find answers inline, marked [ina]


On Mon, Feb 24, 2014 at 5:52 PM, Hariharan Anant= hakrishnan <hanantha@juniper.net> wrote:
Hi Authors,

Couple of comments:

[1] section 5.6.2 – Active Stateful PCE LSP Update
     “ For each LSP, it sen= ds an LSP State Report carried on PCRpt message to the PCE, indicating that= the LSP’s status is ‘Pending’. “

[Hari] What is the “Pending” status corresponds= to in LSP Object ? Is it LSP Operational bits (0-7) ? Does state ‘Pe= nding’ corresponds to GOING-DOWN(3) or GOING-UP(4) ?\

[ina] Yes, will clean up the text. "Pending" is a leftover f= rom much earlier incarnations of this draft. 

[2] section 6.2 – The PCUpd Message

“A PCC May respond with multiple LSP State Reports to= report LSP setup progress of a single LSP. In that case, the SRP-ID-number= MUST be included for the first message, for subsequent messages the reserv= ed value 0x00000000 SHOULD be used”.

[Hari] A PCC implementation  may send a PCRpt imm= ediately after receiving a PCUpdate (without waiting for RSVP completion). = Later it sends a PCRpt, when it receives updates from RSVP.  Putt= ing this behavior in the above context, could you please clarify the if the below behavior is correct:

PCUpdate (SRP-ID 100) —————&g= t; PCC
PCE <———————&#= 8212;——— PCRpt (SRP-ID 100, LSP Operational =3D GOING-UP)= [ Without waiting for RSVP signaling ]
PCE <———————&#= 8212;——— PCRpt (SRP-ID 0x0000000, LSP Operational bit =3D= UP ] [After receiving successful RSVP setup ]

[ina] Yes 
 
[3] section 7.2 (SRP Object) 

 “An SRP-ID-number is considered unacknowledged and cannot = be reused until a PCErr or PCRpt arrives with an SRP-ID-number equal or hig= her for the same LSP. A PCRpt with state "P= ending” is not considered as an acknowledgement.”

[ina] This text is not applicable, it is left over from earlier discus= sions on the SRP, thank you for pointing this out. 

[Hari] Per section 6.2, the first message (PCRpt) will have= the SRP-ID and status as “Pending” since the LSP hasn’t = been signaled. In this case, does the SRP-ID in PCRpt considered unacknowle= dged ?  It would be great if the SRP-ID could be explained with an example especially for the PCUpdate cases from PCC perspective.


[4] Section 7.3.1.
   
[Hari] Shouldn’t the IPV4-LSP-IDENTIFIERES-TLV length= be 16 ?  Similar changes for IPV6-LSP-IDENTIFIER-TLV.

[ina] Yes, thank you for catching, the TLV was changed in version 07 b= ut the length was not updated at that time :-( 

[5] General Comment. Will the “Type=3D[TBD]” in= 7.xx sections be updated with the proposed values in section 8.x.

[ina] Yes.  

Thanks,
Hari


_______________________________________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce


--_000_CF32981F5246hananthajunipernet_-- From nobody Tue Feb 25 20:17:22 2014 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 5F6991A03DA for ; Tue, 25 Feb 2014 20:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 ODnth26huJbJ for ; Tue, 25 Feb 2014 20:17:15 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 75ACC1A0279 for ; Tue, 25 Feb 2014 20:17:14 -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 BDZ28650; Wed, 26 Feb 2014 04:17:11 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 26 Feb 2014 04:17:02 +0000 Received: from SZXEML452-HUB.china.huawei.com (10.82.67.195) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 26 Feb 2014 04:17:10 +0000 Received: from szxeml556-mbs.china.huawei.com ([169.254.4.34]) by szxeml452-hub.china.huawei.com ([10.82.67.195]) with mapi id 14.03.0158.001; Wed, 26 Feb 2014 12:17:06 +0800 From: Dhruv Dhody To: Hariharan Ananthakrishnan , Ina Minei Thread-Topic: [Pce] comments draft-ietf-pce-stateful-pce-08.txt Thread-Index: AQHPMcxNobG2doiZKUqv4mIrhOE3bJrGSUIAgAALHgCAAJidcA== Date: Wed, 26 Feb 2014 04:17:05 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B75543CA4@szxeml556-mbs.china.huawei.com> References: 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.146.248] Content-Type: multipart/alternative; boundary="_000_23CE718903A838468A8B325B80962F9B75543CA4szxeml556mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pce/8GwEWhpYf0CTIwPASj-32f_Zym4 Cc: "pce@ietf.org" Subject: Re: [Pce] comments draft-ietf-pce-stateful-pce-08.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: Wed, 26 Feb 2014 04:17:19 -0000 --_000_23CE718903A838468A8B325B80962F9B75543CA4szxeml556mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Hari, Apologies for butting in, but... From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Hariharan Ananthakrish= nan Subject: Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt Thanks Ina. Another followup question. Can a PCC use PCReq with an 'active = stateful PCE' ? The PCE could respond with a PCUpdate in return or PCErr. = This will be useful for a PCC to trigger a path (re)computation based on 'l= ocal event' that a PCE might not be aware of. [DD] A "local events" can simply be reported to the active stateful PCE via= PCRpt for a delegated LSP... Do you have any specific event in mind that would require PCReq instead? Dhruv - Hari From: Ina Minei > Date: Tuesday, February 25, 2014 at 6:21 PM To: Hariharan Ananthakrishnan > Cc: "pce@ietf.org" > Subject: Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt Hari, Thank you for the review, please find answers inline, marked [ina] On Mon, Feb 24, 2014 at 5:52 PM, Hariharan Ananthakrishnan > wrote: Hi Authors, Couple of comments: [1] section 5.6.2 - Active Stateful PCE LSP Update " For each LSP, it sends an LSP State Report carried on PCRpt message = to the PCE, indicating that the LSP's status is 'Pending'. " [Hari] What is the "Pending" status corresponds to in LSP Object ? Is it LS= P Operational bits (0-7) ? Does state 'Pending' corresponds to GOING-DOWN(3= ) or GOING-UP(4) ?\ [ina] Yes, will clean up the text. "Pending" is a leftover from much earlie= r incarnations of this draft. [2] section 6.2 - The PCUpd Message "A PCC May respond with multiple LSP State Reports to report LSP setup prog= ress of a single LSP. In that case, the SRP-ID-number MUST be included for = the first message, for subsequent messages the reserved value 0x00000000 SH= OULD be used". [Hari] A PCC implementation may send a PCRpt immediately after receiving a= PCUpdate (without waiting for RSVP completion). Later it sends a PCRpt, wh= en it receives updates from RSVP. Putting this behavior in the above conte= xt, could you please clarify the if the below behavior is correct: PCUpdate (SRP-ID 100) -----> PCC PCE <----------- PCRpt (SRP-ID 100, LSP Operational =3D GOING-UP) [ Without= waiting for RSVP signaling ] PCE <----------- PCRpt (SRP-ID 0x0000000, LSP Operational bit =3D UP ] [Aft= er receiving successful RSVP setup ] [ina] Yes [3] section 7.2 (SRP Object) "An SRP-ID-number is considered unacknowledged and cannot be reused until = a PCErr or PCRpt arrives with an SRP-ID-number equal or higher for the same= LSP. A PCRpt with state "Pending" is not considered as an acknowledgement.= " [ina] This text is not applicable, it is left over from earlier discussions= on the SRP, thank you for pointing this out. [Hari] Per section 6.2, the first message (PCRpt) will have the SRP-ID and = status as "Pending" since the LSP hasn't been signaled. In this case, does = the SRP-ID in PCRpt considered unacknowledged ? It would be great if the S= RP-ID could be explained with an example especially for the PCUpdate cases = from PCC perspective. [4] Section 7.3.1. [Hari] Shouldn't the IPV4-LSP-IDENTIFIERES-TLV length be 16 ? Similar chan= ges for IPV6-LSP-IDENTIFIER-TLV. [ina] Yes, thank you for catching, the TLV was changed in version 07 but th= e length was not updated at that time :-( [5] General Comment. Will the "Type=3D[TBD]" in 7.xx sections be updated wi= th the proposed values in section 8.x. [ina] Yes. Thanks, Hari _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --_000_23CE718903A838468A8B325B80962F9B75543CA4szxeml556mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Hari,

 <= /p>

Apologies for butting in,= but…

 <= /p>

From: Pce [mai= lto:pce-bounces@ietf.org] On Behalf Of Hariharan Ananthakrishnan
Subject: Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt<= /o:p>

 

Thanks Ina. Another followup= question. Can a PCC use PCReq with an ‘active stateful PCE’ ? = The PCE could respond with a PCUpdate in return or PCErr.  This will be useful for a PCC to trigger a path (re)computation based on ‘loca= l event’ that a PCE might not be aware of.

[DD] A ”local= events” can simply be reported to the active stateful PCE via PCRpt = for a delegated LSP…

Do you have any spe= cific event in mind that would require PCReq instead?=

 

Dhruv

 

- Hari

 

From: Ina Minei <inaminei@google.com>
Date: Tuesday, February 25, 2014 at 6:21 PM
To: Hariharan Ananthakrishnan <hanantha@juniper.net>
Cc: "pce@ietf.org" <= ;pce@ietf.org>
Subject: Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt<= /o:p>

 

Hari, 

 

Thank you for the review, pl= ease find answers inline, marked [ina]

 

 

On Mon, Feb 24, 2014 at 5:52= PM, Hariharan Ananthakrishnan <hanantha@juniper.net> wrote:

Hi Authors,

 

Couple of comments:

 

[1] section 5.6.2 – Ac= tive Stateful PCE LSP Update

     = 220; For each LSP, it sends an LSP State Report carried on PCRpt message to= the PCE, indicating that the LSP’s status is ‘Pending’. “

 

[Hari] What is the “Pe= nding” status corresponds to in LSP Object ? Is it LSP Operational bi= ts (0-7) ? Does state ‘Pending’ corresponds to GOING-DOWN(3) or= GOING-UP(4) ?\

 

[ina] Yes, will clean up the= text. "Pending" is a leftover from much earlier incarnations of = this draft. 

 

[2] section 6.2 – The = PCUpd Message

 

“A PCC May respond wit= h multiple LSP State Reports to report LSP setup progress of a single LSP. = In that case, the SRP-ID-number MUST be included for the first message, for subsequent messages the reserved value 0x00000000 SHOULD be u= sed”.

 

[Hari] A PCC implementation&= nbsp; may send a PCRpt immediately after receiving a PCUpdate (without= waiting for RSVP completion). Later it sends a PCRpt, when it receives updates from RSVP.  Putting this behavior in the above context, = could you please clarify the if the below behavior is correct:

 

PCUpdate (SRP-ID 100) —= ;————> PCC

PCE <———= ;———————— PCRpt (SRP-ID 100= , LSP Operational =3D GOING-UP) [ Without waiting for RSVP signaling ]=

PCE <———= ;———————— PCRpt (SRP-ID 0x0= 000000, LSP Operational bit =3D UP ] [After receiving successful RSVP setup= ]

 

[ina] Yes 

 

[3] section 7.2 (SRP Object)=  

 

 “An SRP-ID-numbe= r is considered unacknowledged and cannot be reused until a PCErr or PCRpt = arrives with an SRP-ID-number equal or higher for the same LSP. A PCRpt with state "Pending” is not considered as an acknowledg= ement.”

 

[ina] This text is not appli= cable, it is left over from earlier discussions on the SRP, thank you for p= ointing this out. 

 

[Hari] Per section 6.2, the = first message (PCRpt) will have the SRP-ID and status as “PendingR= 21; since the LSP hasn’t been signaled. In this case, does the SRP-ID in PCRpt considered unacknowledged ?  It would be great if the SRP-ID= could be explained with an example especially for the PCUpdate cases from = PCC perspective.

 

 

[4] Section 7.3.1.

   

[Hari] Shouldn’t the I= PV4-LSP-IDENTIFIERES-TLV length be 16 ?  Similar changes for IPV6= -LSP-IDENTIFIER-TLV.

 

[ina] Yes, thank you for cat= ching, the TLV was changed in version 07 but the length was not updated at = that time :-( 

 

[5] General Comment. Will th= e “Type=3D[TBD]” in 7.xx sections be updated with the proposed = values in section 8.x.

 

[ina] Yes.  =

 

Thanks,

Hari

 


_______________________________________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce

 

--_000_23CE718903A838468A8B325B80962F9B75543CA4szxeml556mbschi_-- From nobody Wed Feb 26 01:12:20 2014 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 891491A002F for ; Wed, 26 Feb 2014 01:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.253 X-Spam-Level: X-Spam-Status: No, score=0.253 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 eQPgxQg2DOfU for ; Wed, 26 Feb 2014 01:12:08 -0800 (PST) Received: from ENFICSETS1.metaswitch.com (enficsets1.metaswitch.com [192.91.191.38]) by ietfa.amsl.com (Postfix) with ESMTP id 8133E1A0155 for ; Wed, 26 Feb 2014 01:12:07 -0800 (PST) Received: from ENFIRHCAS1.datcon.co.uk (172.18.209.38) by ENFICSETS1.metaswitch.com (172.18.4.18) with Microsoft SMTP Server (TLS) id 14.3.174.1; Wed, 26 Feb 2014 09:12:01 +0000 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFIRHCAS1.datcon.co.uk ([fe80::85a7:aa4e:2516:c2ad%11]) with mapi id 14.03.0174.001; Wed, 26 Feb 2014 09:12:05 +0000 From: Jonathan Hardwick To: "Zhangxian (Xian)" Thread-Topic: Comments on draft-minei-pce-stateful-sync-optimizations-01 Thread-Index: Ac8ps3n6I0/p/UTJSj24UQQcD8tDLAF5aSuAAM1O1KA= Date: Wed, 26 Feb 2014 09:12:05 +0000 Message-ID: <09CE6C3BE5E1EA40B987BF5F25D8DDBAE1355A2B@ENFICSMBX1.datcon.co.uk> References: <09CE6C3BE5E1EA40B987BF5F25D8DDBAE13416C9@ENFICSMBX1.datcon.co.uk> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.34.180] Content-Type: multipart/alternative; boundary="_000_09CE6C3BE5E1EA40B987BF5F25D8DDBAE1355A2BENFICSMBX1datco_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/PcNVcOw6GQBHklqoF2bYjx7RN40 Cc: "draft-minei-pce-stateful-sync-optimizations@tools.ietf.org" , "pce@ietf.org" Subject: Re: [Pce] Comments on draft-minei-pce-stateful-sync-optimizations-01 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: Wed, 26 Feb 2014 09:12:16 -0000 --_000_09CE6C3BE5E1EA40B987BF5F25D8DDBAE1355A2BENFICSMBX1datco_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi Xian, please see [Jon] below... From: Zhangxian (Xian) [mailto:zhang.xian@huawei.com] Sent: 22 February 2014 07:33 To: Jonathan Hardwick Cc: pce@ietf.org; draft-minei-pce-stateful-sync-optimizations@tools.ietf.or= g Subject: RE: Comments on draft-minei-pce-stateful-sync-optimizations-01 Hi, Jon, Thank you very much for the constructive comments. Please see my reply = inline, marked with [Xian]: From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Jonathan Hardwick Sent: 2014=1B$BG/=1B(B2=1B$B7n=1B(B15=1B$BF|=1B(B 2:35 To: draft-minei-pce-stateful-sync-optimizations@tools.ietf.org Cc: pce@ietf.org Subject: [Pce] Comments on draft-minei-pce-stateful-sync-optimizations-01 Hi there I have reviewed this draft - here are my comments. Best regards Jon Section 3.2 Figure 2, I think the =1B$B!H=1B(Bsync done=1B$B!I=1B(B PCRpt should have S= YNC=3D0, not SYNC=3D1. [Xian]: Indeed. Thank you for spotting this typo. Section 5.2 If a PCC has to force full LSP DB synchronization due to reasons including but not limited: (1) local policy configured at the PCC; (2) no sufficient LSP state caches for incremental update, the PCC can set the D flag to 0. Perhaps I have misunderstood, but I think case (2) above doesn=1B$B!G=1B(Bt= work. The PCC does not know that it has =1B$B!H=1B(Bno sufficient LSP sta= te caches=1B$B!I=1B(B until it receives the OPEN from the PCE and sees what= DBv the PCE has sent. By then, the PCC has already sent its OPEN so it is= too late to set D=3D0. To cover case (2) the draft needs a mechanism for = the PCC to change its mind and tell the PCE that it is going to send a full= snapshot, not a replay of the missing database updates. The simplest thin= g is probably for the PCC to bring the session down and then bring it back = up again with D=3D0. [Xian]: It actually depends, IMHO. If it is due to the 1st reason listed a= bove, then, it can decide before sending OPEN and set D=3D0. The cases as a= result of the 2nd reason might be more complicated. Your analysis would be= one of the cases, in which a PCC can detect the insufficient LSP state cac= hes ONLY after it gets the DB version information from the other party. But= if a PCC has no LSP state caches or incomplete (missing quite some LSP sta= te or those of the DB version in between), I think it is possible that it c= an decide without even checking the DBv from the other party. Does this cla= rify? To include the case you described, how about we update the text as below? OLD: If a PCC has to force full LSP DB synchronization due to reasons including but not limited: (1) local policy configured at the PCC; (2) no sufficient LSP state caches for incremental update, the PCC can set the D flag to 0. [DD] NEW: If a PCC may have to force full LSP DB synchronization due to reasons including but not limited: (1) local policy configured at the PCC; (2) no sufficient LSP state caches for incremental update, the PCC can set the D flag to 0. Note a PCC may have= to bring down the current session and force a full LSPDB synchronization with D fl= ag set to 0 in the subsequent open message. [Jon] Looks good to me. Section 4 talks about the PCE having to mark its LSP database as stale, and= then remove any stale LSPs at the end of the synchronization process. I a= ssume that this does not apply in section 5. To avoid confusion, I think s= ection 5 should state that the PCE does not mark its LSP database as stale = if both it and the PCC have set D=3D1. [Xian]: Sure. I think we have already explained in Section 5. The last sen= tence of the paragraph below Figure 7 says: =1B$B!H=1B(BNote that the PCE s= hould not mark the existing LSPs as stale for incremental state synchronisa= tion=1B$B!I=1B(B. [Jon] Apologies, I missed that. In figure 7, I may have misunderstood section 4, but I don=1B$B!G=1B(Bt thi= nk this is how the T bit is specified. I don=1B$B!G=1B(Bt think T=3D1 forc= es the PCC to wait for a PCUpd before sending the initial snapshot as you h= ave shown. I don=1B$B!G=1B(Bt think this substantially changes anything ab= out section 5, so I suggest removing the discussion of the T bit from secti= on 5. [Xian]=1B$B!'=1B(BSection 4 describes how a PCE can force re-synchronizatio= n after the initial LSP-DB synchronization has been done. Section 5 talks a= bout an alternative method for the initial LSP-DB sync. (i.e., incremental = way). The idea here is allow PCE to control the sequence of incremental sy= nc., the authors do see the value. However, you can see from the explanatio= n of Section 5, setting the T=3D1 is NOT a mandate operation to enable incr= emental sync., but a feature optical and not covered by Section 4. The figu= re is drawn as shown because we intends to capture both features. Does this= clarify your doubt? [Jon] I=1B$B!G=1B(Bm still unsure how triggered synchronizations are used b= y section 5.2. Here is the text that is confusing me: A stateful PCE MAY choose to control the LSP-DB synchronization process. To allow PCE to do so, PCEP speakers MUST set T bit to 1 to indicate this (as described in Section 4). If the LSP-DB Vers= ion is mis-matched, it can send a PCUpd message with PLSP-ID =3D 0 and SYNC =3D 1 in order to trigger the LSP-DB synchronization process. The final sentence says that the PCE =1B$B!H=1B(Bcan send a PCUpd=1B$B!I=1B= (B. It is not clear under what circumstances the PCC MUST wait for the PCE= to trigger the initial synchronization. Please could you clarify? Do you= mean that the PCE MUST trigger the initial synchronization any time the PC= C and PCE have both set the T bit in their Open messages? Does that also a= pply in section 4? My understanding from section 4.1 is that this mechanis= m is intended to allow the PCE to sanity check the LSPDB and recover from i= nternal errors after the initial session is established, not to trigger the= initial synchronization: [...] it can be beneficial to be able to resynchronize this state even after the session has been established. The PCE may use this approach to continuously sanity check its state against the network, or to recover from error conditions without having to tear down sessions. Regards, Xian --_000_09CE6C3BE5E1EA40B987BF5F25D8DDBAE1355A2BENFICSMBX1datco_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Hi Xian, please see [J= on] below...

 

From: Zhangxian (Xian) [mailto:zhang.xian@huawei.com]
Sent: 22 February 2014 07:33
To: Jonathan Hardwick
Cc: pce@ietf.org; draft-minei-pce-stateful-sync-optimizations@tools.= ietf.org
Subject: RE: Comments on draft-minei-pce-stateful-sync-optimizations= -01

 

Hi, Jon,

 

   Thank you very much for the constructive comments.&n= bsp; Please see my reply inline, marked with [Xian]:

 

From: Pce [mailto:p= ce-bounces@ietf.org] On Behalf Of Jonathan Hardwick
Sent: 2014=1B$BG/=1B(B2=1B$B7n=1B(B<= /span>15=1B$BF|=1B(B 2:35
To: draft-minei-pce-stateful-sync-optimizations@tools.ietf.org
Cc: pce@ietf.org
Subject: [Pce] Comments on draft-minei-pce-stateful-sync-optimizatio= ns-01

 

Hi there

 

I have reviewed this draft – here are my comme= nts.

 

Best regards

Jon

 

Section 3.2

Figure 2, I think the =1B$B!H=1B(Bsync done=1B$B!I= =1B(B PCRpt should have SYNC=3D0, not SYNC=3D1.

[Xian= ]: Indeed. Thank you for spotting this typo.

=  

Section 5.2

   If a PCC has to force full LSP DB<= /span>

   synchronization due to reasons including but = not limited: (1) local

   policy configured at the PCC; (2) no sufficie= nt LSP state caches for

   incremental update, the PCC can set the D fla= g to 0.

 

Perhaps I have misunderstood, but I think case (2) a= bove doesn=1B$B!G=1B(Bt work.  The PCC does not know that it has =1B$B= !H=1B(Bno sufficient LSP state caches=1B$B!I=1B(B until it receives the OPE= N from the PCE and sees what DBv the PCE has sent.  By then, the PCC h= as already sent its OPEN so it is too late to set D=3D0.  To cover case = (2) the draft needs a mechanism for the PCC to change its mind and tell the= PCE that it is going to send a full snapshot, not a replay of the missing = database updates.  The simplest thing is probably for the PCC to bring the session down and then bring it back up a= gain with D=3D0.

=  

[Xian= ]:  It actually depends, IMHO. If it is due to the 1st reason listed a= bove, then, it can decide before sending OPEN and set D=3D0. The cases as a= result of the 2nd reason might be more complicated. Your analysis would be one of the cases, in which a PCC can detect the ins= ufficient LSP state caches ONLY after it gets the DB version information fr= om the other party. But if a PCC has no LSP state caches or incomplete (mis= sing quite some LSP state or those of the DB version in between), I think it is possible that it can decide w= ithout even checking the DBv from the other party. Does this clarify?

=  

To in= clude the case you described, how about we update the text  as below?<= o:p>

=  

OLD:<= o:p>

 = ;  If a PCC has to force full LSP DB

 = ;  synchronization due to reasons including but not limited: (1) local=

 = ;  policy configured at the PCC; (2) no sufficient LSP state caches fo= r

 = ;  incremental update, the PCC can set the D flag to 0.

=  

[DD] = NEW:

 = ;  If a PCC may have to force full LSP DB

 = ;  synchronization due to reasons including but not limited: (1) local=

 = ;  policy configured at the PCC; (2) no sufficient LSP state caches fo= r

 = ;  incremental update, the PCC can set the D flag to 0. Note a PCC may have to b= ring

 do= wn the current session and  force a full LSPDB synchronization wi= th D flag set to

0 in the  subsequent open message.

 

[Jon] Looks good to me= .

 

Section 4 talks about the PCE having to mark its LSP= database as stale, and then remove any stale LSPs at the end of the synchr= onization process.  I assume that this does not apply in section 5.&nb= sp; To avoid confusion, I think section 5 should state that the PCE does not mark its LSP database as stale if both it and = the PCC have set D=3D1.

[Xian]: Sure.  I = think we have already explained in Section 5. The last sentence of the para= graph below Figure 7 says: =1B$B!H=1B(BNote that the PCE should not mark th= e existing LSPs as stale for incremental state synchronisation=1B$B!I=1B(B.=

=  

[Jon] Apologies, I mis= sed that.

 

In figure 7, I may have misunderstood section 4, but= I don=1B$B!G=1B(Bt think this is how the T bit is specified.  I don= =1B$B!G=1B(Bt think T=3D1 forces the PCC to wait for a PCUpd before sending= the initial snapshot as you have shown.  I don=1B$B!G=1B(Bt think thi= s substantially changes anything about section 5, so I suggest removing the discussion of = the T bit from section 5.

[Xian= ]=1B$B!'=1B(BSection 4 describes how a PCE can force re-synchronization after the initial LSP-DB synchronization has been done. Section 5 talks ab= out an alternative method for the initial LSP-DB sync. (i.e., incremental w= ay).  The idea here is allow PCE to control the sequence of incrementa= l sync., the authors do see the value. However, you can see from the explanation of Section 5, setting the T=3D1 = is NOT a mandate operation to enable incremental sync., but a feature optic= al and not covered by Section 4. The figure is drawn as shown because we in= tends to capture both features. Does this clarify your doubt?

=  

[Jon] I=1B$B!G=1B(Bm s= till unsure how triggered synchronizations are used by section 5.2.  H= ere is the text that is confusing me:

 

   A stateful PCE MAY choose to control the LSP-= DB synchronization

   process.  To allow PCE to do so, PCEP sp= eakers MUST set T bit to 1 to

   indicate this (as described in Section 4).  If the LSP-DB Version is

   mis-matched, it can send a PCUpd message with= PLSP-ID =3D 0 and SYNC =3D

   1 in order to trigger the LSP-DB synchronizat= ion process.

 

The final sentence say= s that the PCE =1B$B!H=1B(Bcan send a PCUpd=1B$B!I=1B(B.  It is not cl= ear under what circumstances the PCC MUST wait for the PCE to trigger the i= nitial synchronization.  Please could you clarify?  Do you mean that the PCE MUST trigger the initial synchronization any time the PCC and= PCE have both set the T bit in their Open messages?  Does that also a= pply in section 4?  My understanding from section 4.1 is that this mec= hanism is intended to allow the PCE to sanity check the LSPDB and recover from internal errors after the initial session= is established, not to trigger the initial synchronization:

 

   [...] it can be beneficial to be able to resy= nchronize this

   state even after the session has been establi= shed.  The PCE may use

   this approach to continuously sanity check it= s state against the

   network, or to recover from error conditions = without having to tear

   down sessions.

 

Regar= ds,

Xian<= o:p>

--_000_09CE6C3BE5E1EA40B987BF5F25D8DDBAE1355A2BENFICSMBX1datco_-- From nobody Wed Feb 26 09:36:19 2014 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 2CA681A06D4 for ; Wed, 26 Feb 2014 09:36:08 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 ZqU69kEply_v for ; Wed, 26 Feb 2014 09:35:58 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2581A070B for ; Wed, 26 Feb 2014 09:35:55 -0800 (PST) Received: from mail53-co9-R.bigfish.com (10.236.132.240) by CO9EHSOBE014.bigfish.com (10.236.130.77) with Microsoft SMTP Server id 14.1.225.22; Wed, 26 Feb 2014 17:35:54 +0000 Received: from mail53-co9 (localhost [127.0.0.1]) by mail53-co9-R.bigfish.com (Postfix) with ESMTP id B3440A4028D; Wed, 26 Feb 2014 17:35:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: VPS-19(zz98dI9371Ic85dhec9I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz8275ch1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1c8fb4h1de097h186068hz2fh109h2a8h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h209eh20f0h2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25cch24c1m1155h) Received-SPF: pass (mail53-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=hanantha@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(199002)(164054003)(189002)(377454003)(37854004)(24454002)(80022001)(87266001)(90146001)(63696002)(66066001)(15975445006)(95666003)(56816005)(74876001)(77982001)(65816001)(85852003)(87936001)(85306002)(15202345003)(83072002)(59766001)(2656002)(83506001)(79102001)(56776001)(54316002)(92566001)(31966008)(83322001)(19580405001)(19580395003)(69226001)(46102001)(4396001)(80976001)(54356001)(76482001)(51856001)(53806001)(16236675002)(76786001)(76796001)(92726001)(93136001)(36756003)(18717965001)(50986001)(81342001)(94946001)(81816001)(94316002)(74706001)(93516002)(74366001)(95416001)(19300405004)(81542001)(47976001)(74502001)(74662001)(47736001)(86362001)(49866001)(81686001)(47446002)(94096001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB776; H:BY2PR05MB774.namprd05.prod.outlook.com; CLIP:66.129.239.12; FPR:E866FDE4.AC10B0EE.DDF1BDBB.6E5B133.2049C; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail53-co9 (localhost.localdomain [127.0.0.1]) by mail53-co9 (MessageSwitch) id 1393436152944650_22487; Wed, 26 Feb 2014 17:35:52 +0000 (UTC) Received: from CO9EHSMHS005.bigfish.com (unknown [10.236.132.231]) by mail53-co9.bigfish.com (Postfix) with ESMTP id E2055B40047; Wed, 26 Feb 2014 17:35:52 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS005.bigfish.com (10.236.130.15) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 26 Feb 2014 17:35:51 +0000 Received: from BY2PR05MB776.namprd05.prod.outlook.com (10.141.224.154) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.423.0; Wed, 26 Feb 2014 17:35:50 +0000 Received: from BY2PR05MB774.namprd05.prod.outlook.com (10.141.224.143) by BY2PR05MB776.namprd05.prod.outlook.com (10.141.224.154) with Microsoft SMTP Server (TLS) id 15.0.888.9; Wed, 26 Feb 2014 17:35:47 +0000 Received: from BY2PR05MB774.namprd05.prod.outlook.com ([10.141.224.143]) by BY2PR05MB774.namprd05.prod.outlook.com ([10.141.224.143]) with mapi id 15.00.0888.003; Wed, 26 Feb 2014 17:35:47 +0000 From: Hariharan Ananthakrishnan To: Dhruv Dhody , Ina Minei Thread-Topic: [Pce] comments draft-ietf-pce-stateful-pce-08.txt Thread-Index: AQHPMcxNobG2doiZKUqv4mIrhOE3bJrGz14A//+FAYCAAJs+gIAAWQuA Date: Wed, 26 Feb 2014 17:35:47 +0000 Message-ID: References: <23CE718903A838468A8B325B80962F9B75543CA4@szxeml556-mbs.china.huawei.com> In-Reply-To: <23CE718903A838468A8B325B80962F9B75543CA4@szxeml556-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.239.12] x-forefront-prvs: 0134AD334F Content-Type: multipart/alternative; boundary="_000_CF3365025266hananthajunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/pce/VRqzmHNgAEPVgNf7Klq3p673b0Y Cc: "pce@ietf.org" Subject: Re: [Pce] comments draft-ietf-pce-stateful-pce-08.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: Wed, 26 Feb 2014 17:36:08 -0000 --_000_CF3365025266hananthajunipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Inline.. From: Dhruv Dhody > Date: Tuesday, February 25, 2014 at 8:17 PM To: Hariharan Ananthakrishnan >, Ina Minei > Cc: "pce@ietf.org" > Subject: RE: [Pce] comments draft-ietf-pce-stateful-pce-08.txt Hi Hari, Apologies for butting in, but... From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Hariharan Ananthakrish= nan Subject: Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt Thanks Ina. Another followup question. Can a PCC use PCReq with an 'active = stateful PCE' ? The PCE could respond with a PCUpdate in return or PCErr. = This will be useful for a PCC to trigger a path (re)computation based on 'l= ocal event' that a PCE might not be aware of. [DD] A "local events" can simply be reported to the active stateful PCE via= PCRpt for a delegated LSP... Do you have any specific event in mind that would require PCReq instead? [Hari] The local event could be a timer event say re-optimize timer.. Dhruv - Hari From: Ina Minei > Date: Tuesday, February 25, 2014 at 6:21 PM To: Hariharan Ananthakrishnan > Cc: "pce@ietf.org" > Subject: Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt Hari, Thank you for the review, please find answers inline, marked [ina] On Mon, Feb 24, 2014 at 5:52 PM, Hariharan Ananthakrishnan > wrote: Hi Authors, Couple of comments: [1] section 5.6.2 - Active Stateful PCE LSP Update " For each LSP, it sends an LSP State Report carried on PCRpt message = to the PCE, indicating that the LSP's status is 'Pending'. " [Hari] What is the "Pending" status corresponds to in LSP Object ? Is it LS= P Operational bits (0-7) ? Does state 'Pending' corresponds to GOING-DOWN(3= ) or GOING-UP(4) ?\ [ina] Yes, will clean up the text. "Pending" is a leftover from much earlie= r incarnations of this draft. [2] section 6.2 - The PCUpd Message "A PCC May respond with multiple LSP State Reports to report LSP setup prog= ress of a single LSP. In that case, the SRP-ID-number MUST be included for = the first message, for subsequent messages the reserved value 0x00000000 SH= OULD be used". [Hari] A PCC implementation may send a PCRpt immediately after receiving a= PCUpdate (without waiting for RSVP completion). Later it sends a PCRpt, wh= en it receives updates from RSVP. Putting this behavior in the above conte= xt, could you please clarify the if the below behavior is correct: PCUpdate (SRP-ID 100) -----> PCC PCE <----------- PCRpt (SRP-ID 100, LSP Operational =3D GOING-UP) [ Without= waiting for RSVP signaling ] PCE <----------- PCRpt (SRP-ID 0x0000000, LSP Operational bit =3D UP ] [Aft= er receiving successful RSVP setup ] [ina] Yes [3] section 7.2 (SRP Object) "An SRP-ID-number is considered unacknowledged and cannot be reused until = a PCErr or PCRpt arrives with an SRP-ID-number equal or higher for the same= LSP. A PCRpt with state "Pending" is not considered as an acknowledgement.= " [ina] This text is not applicable, it is left over from earlier discussions= on the SRP, thank you for pointing this out. [Hari] Per section 6.2, the first message (PCRpt) will have the SRP-ID and = status as "Pending" since the LSP hasn't been signaled. In this case, does = the SRP-ID in PCRpt considered unacknowledged ? It would be great if the S= RP-ID could be explained with an example especially for the PCUpdate cases = from PCC perspective. [4] Section 7.3.1. [Hari] Shouldn't the IPV4-LSP-IDENTIFIERES-TLV length be 16 ? Similar chan= ges for IPV6-LSP-IDENTIFIER-TLV. [ina] Yes, thank you for catching, the TLV was changed in version 07 but th= e length was not updated at that time :-( [5] General Comment. Will the "Type=3D[TBD]" in 7.xx sections be updated wi= th the proposed values in section 8.x. [ina] Yes. Thanks, Hari _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --_000_CF3365025266hananthajunipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <876E5018572AA34CA7745A1AD6C93030@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Inline..

From: Dhruv Dhody <dhruv.dhody@huawei.com>
Date: Tuesday, February 25, 2014 at= 8:17 PM
To: Hariharan Ananthakrishnan <<= a href=3D"mailto:hanantha@juniper.net">hanantha@juniper.net>, Ina Mi= nei <inaminei@google.com><= br> Cc: "pce@ietf.org" <pce@ietf.= org>
Subject: RE: [Pce] comments draft-i= etf-pce-stateful-pce-08.txt

Hi Hari,

 

Apologies for butting in, but…= ;

 

From: Pce [mailt= o:pce-bounces@ietf.org] On Behalf Of Hariharan Ananthakrishnan
Subject: Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt<= /o:p>

 

Thanks Ina. Another followup question. Can a = PCC use PCReq with an ‘active stateful PCE’ ? The PCE could res= pond with a PCUpdate in return or PCErr.  This will be useful for a PCC to trigger a path (re)computation based on ‘loca= l event’ that a PCE might not be aware of.

[DD] A ”local events= 221; can simply be reported to the active stateful PCE via PCRpt for a dele= gated LSP…

Do you have any specific even= t in mind that would require PCReq instead?

[Hari] The local event could be a timer event say re-optimize timer.. =  

 <= /b>

Dhruv

 

- Hari

 

From: Ina Minei <inami= nei@google.com>
Date: Tuesday, February 25, 2014 at 6:21 PM
To: Hariharan Ananthakrishnan <hanantha@juniper.net>
Cc: "pce@ietf.org" <= ;pce@ietf.org>
Subject: Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt<= /o:p>

 

Hari, 

 

Thank you for the review, please find answers= inline, marked [ina]

 

 

On Mon, Feb 24, 2014 at 5:52 PM, Hariharan An= anthakrishnan <hanantha@juniper.net> wrote:

Hi Authors,

 

Couple of comments:

 

[1] section 5.6.2 – Active Stateful PCE= LSP Update

     “ For each LSP= , it sends an LSP State Report carried on PCRpt message to the PCE, indicat= ing that the LSP’s status is ‘Pending’. “

 

[Hari] What is the “Pending” stat= us corresponds to in LSP Object ? Is it LSP Operational bits (0-7) ? Does s= tate ‘Pending’ corresponds to GOING-DOWN(3) or GOING-UP(4) ?\

 

[ina] Yes, will clean up the text. "Pend= ing" is a leftover from much earlier incarnations of this draft. =

 

[2] section 6.2 – The PCUpd Message

 

“A PCC May respond with multiple LSP St= ate Reports to report LSP setup progress of a single LSP. In that case, the= SRP-ID-number MUST be included for the first message, for subsequent messages the reserved value 0x00000000 SHOULD be u= sed”.

 

[Hari] A PCC implementation  may se= nd a PCRpt immediately after receiving a PCUpdate (without waiting for RSVP= completion). Later it sends a PCRpt, when it receives updates from RSVP.  Putting this behavior in the above = context, could you please clarify the if the below behavior is correct:

 

PCUpdate (SRP-ID 100) ———&#= 8212;—> PCC

PCE <—————&#= 8212;————— PCRpt (SRP-ID 100, LSP Operational= =3D GOING-UP) [ Without waiting for RSVP signaling ]

PCE <—————&#= 8212;————— PCRpt (SRP-ID 0x0000000, LSP Opera= tional bit =3D UP ] [After receiving successful RSVP setup ]

 

[ina] Yes 

 

[3] section 7.2 (SRP Object) =

 

 “An SRP-ID-number is considered u= nacknowledged and cannot be reused until a PCErr or PCRpt arrives with an S= RP-ID-number equal or higher for the same LSP. A PCRpt with state "Pending” is not considered as an acknowledg= ement.”

 

[ina] This text is not applicable, it is left= over from earlier discussions on the SRP, thank you for pointing this out.=  

 

[Hari] Per section 6.2, the first message (PC= Rpt) will have the SRP-ID and status as “Pending” since the LSP= hasn’t been signaled. In this case, does the SRP-ID in PCRpt considered unacknowledged ?  It would be great if the SRP-ID= could be explained with an example especially for the PCUpdate cases from = PCC perspective.

 

 

[4] Section 7.3.1.

   

[Hari] Shouldn’t the IPV4-LSP-IDENTIFIE= RES-TLV length be 16 ?  Similar changes for IPV6-LSP-IDENTIFIER-T= LV.

 

[ina] Yes, thank you for catching, the TLV wa= s changed in version 07 but the length was not updated at that time :-(&nbs= p;

 

[5] General Comment. Will the “Type=3D[= TBD]” in 7.xx sections be updated with the proposed values in section= 8.x.

 

[ina] Yes.  

 

Thanks,

Hari

 


_______________________________________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce

 

 --_000_CF3365025266hananthajunipernet_-- From nobody Wed Feb 26 10:07:23 2014 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 07C301A075C for ; Wed, 26 Feb 2014 10:07:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 M3UVkD85b16c for ; Wed, 26 Feb 2014 10:07:15 -0800 (PST) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCD01A076B for ; Wed, 26 Feb 2014 10:07:15 -0800 (PST) Received: by mail-ob0-f171.google.com with SMTP id vb8so1158836obc.2 for ; Wed, 26 Feb 2014 10:07:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VEurxRlOlrXqXzMD34Ozb//89DzZqhaQ56dwIqp2F6E=; b=icr5UVlGc66KEgvBFQ/GQHn8/V5Gl3Cku1bRfg0EknK/V3OL0vyPjEuJQ+oa+piEOr 1yZzH8G/+vEaHpJtIaaCvOydSEZy4a2OPUgc5o1+Nxl/p92GvNpkb8eciUQW6JLjREGs whb6tBVRoBgdHhqRVIv36Gq8Jkgamj0qDAwZ3+FAB+gsmIslQJQRqGswsRXhn+MfvQy2 DG9mbZ08DOSW2Tf6FeLK2lhRFVCutl9tNzfOcCI203+vmmXFEzfKINxEkqwIq6+ga+EY cn4zzdBvafWvI37ufaIGPVNcPy7xqn+T++0e0iRW7gY1/I2l5rvez3mB/Vjc/MdO/fxJ zuyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VEurxRlOlrXqXzMD34Ozb//89DzZqhaQ56dwIqp2F6E=; b=ejaMhP8w9MS+RqCeOdHs735J2DlWefzOWIQXm2A6js16ugLchHN1hTeYq4o/RwpdIS IFFJiiptjJgW5DWKWZgtB953vOf4iCGoP769DkFPexgApfB0Od+4Pu/CTtVcT0PFFiSQ 9Wtfk5U8/LfItDlA9S+jlTr6rjg/YOWhnRpJH9qH16n/eJrPjMyGxVMaNprVfVkN4sNM EDtsKfS0chr0lqpjU5ocMqeWd5oTb1+MQj0U0ry9yQqMd9eEYgFWiemTo7rktpp0xS6k gCldiUo6IrxqeauOnEOb1r679An3riaZtMj718ALW6knjs7gnrBNxHtRI0PgZ0hrifeq huYg== X-Gm-Message-State: ALoCoQlS6C8LKcmF0p+xWtzqu8q8fHkWqA9FTd4iIojTTD2IWMAHMK9YdSUx8Ub1lzQZMt9rl7iJJi1WXIyAfkwakW3zN7RjsyjPjVpxIh3EhqL1SdUpdNiiE+B5wORXjZ31MHWruXbMiVvM7Ev454Exw3msvvW3p/+rFqYEr2srwdAAJZ+/61NXAF5I9QYRnZJHnuwRAXJr MIME-Version: 1.0 X-Received: by 10.182.102.7 with SMTP id fk7mr4007543obb.28.1393438033951; Wed, 26 Feb 2014 10:07:13 -0800 (PST) Received: by 10.182.80.106 with HTTP; Wed, 26 Feb 2014 10:07:13 -0800 (PST) In-Reply-To: References: <23CE718903A838468A8B325B80962F9B75543CA4@szxeml556-mbs.china.huawei.com> Date: Wed, 26 Feb 2014 10:07:13 -0800 Message-ID: From: Ina Minei To: Hariharan Ananthakrishnan Content-Type: multipart/alternative; boundary=089e015369f008963804f353130a Archived-At: http://mailarchive.ietf.org/arch/msg/pce/dhOH2cCKR9XXnahsqsnHu-jaF08 Cc: "pce@ietf.org" Subject: Re: [Pce] comments draft-ietf-pce-stateful-pce-08.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: Wed, 26 Feb 2014 18:07:19 -0000 --089e015369f008963804f353130a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hari, The short answer is that sending a path computation request as per 5440 is not precluded in the draft, although this rather breaks the delegation concept. What is not available today is to send the LSP object in the PCReq, but for your scenario that is not needed. However, the model of operation where the PCC sends PCReq should be carefully considered, because now the control is split between PCC and PCE. A cleaner solution is for the PCE to be made aware of the local trigger and take the decision to act on it, or the PCC to revoke the delegation, change the LSP then delegate again. This is a case-by-case evaluation. Ina On Wed, Feb 26, 2014 at 9:35 AM, Hariharan Ananthakrishnan < hanantha@juniper.net> wrote: > Inline.. > > From: Dhruv Dhody > Date: Tuesday, February 25, 2014 at 8:17 PM > To: Hariharan Ananthakrishnan , Ina Minei < > inaminei@google.com> > Cc: "pce@ietf.org" > Subject: RE: [Pce] comments draft-ietf-pce-stateful-pce-08.txt > > Hi Hari, > > > > Apologies for butting in, but=E2=80=A6 > > > > *From:* Pce [mailto:pce-bounces@ietf.org ] *On > Behalf Of *Hariharan Ananthakrishnan > *Subject:* Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt > > > > Thanks Ina. Another followup question. Can a PCC use PCReq with an =E2=80= =98active > stateful PCE=E2=80=99 ? The PCE could respond with a PCUpdate in return o= r PCErr. > This will be useful for a PCC to trigger a path (re)computation based on > =E2=80=98local event=E2=80=99 that a PCE might not be aware of. > > *[DD] A =E2=80=9Dlocal events=E2=80=9D can simply be reported to the acti= ve stateful PCE > via PCRpt for a delegated LSP=E2=80=A6 * > > *Do you have any specific event in mind that would require PCReq instead?= * > > [Hari] The local event could be a timer event say re-optimize timer.. > > > > *Dhruv* > > > > - Hari > > > > *From: *Ina Minei > *Date: *Tuesday, February 25, 2014 at 6:21 PM > *To: *Hariharan Ananthakrishnan > *Cc: *"pce@ietf.org" > *Subject: *Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt > > > > Hari, > > > > Thank you for the review, please find answers inline, marked [ina] > > > > > > On Mon, Feb 24, 2014 at 5:52 PM, Hariharan Ananthakrishnan < > hanantha@juniper.net> wrote: > > Hi Authors, > > > > Couple of comments: > > > > [1] section 5.6.2 =E2=80=93 Active Stateful PCE LSP Update > > =E2=80=9C For each LSP, it sends an LSP State Report carried on PCRp= t message > to the PCE, indicating that the LSP=E2=80=99s status is =E2=80=98Pending= =E2=80=99. =E2=80=9C > > > > [Hari] What is the =E2=80=9CPending=E2=80=9D status corresponds to in LSP= Object ? Is it > LSP Operational bits (0-7) ? Does state =E2=80=98Pending=E2=80=99 corresp= onds to > GOING-DOWN(3) or GOING-UP(4) ?\ > > > > [ina] Yes, will clean up the text. "Pending" is a leftover from much > earlier incarnations of this draft. > > > > [2] section 6.2 =E2=80=93 The PCUpd Message > > > > =E2=80=9CA PCC May respond with multiple LSP State Reports to report LSP = setup > progress of a single LSP. In that case, the SRP-ID-number MUST be include= d > for the first message, for subsequent messages the reserved value > 0x00000000 SHOULD be used=E2=80=9D. > > > > [Hari] A PCC implementation may send a PCRpt immediately after receiving > a PCUpdate (without waiting for RSVP completion). Later it sends a PCRpt, > when it receives updates from RSVP. Putting this behavior in the above > context, could you please clarify the if the below behavior is correct: > > > > PCUpdate (SRP-ID 100) =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94> PCC > > PCE <=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94 PCRpt (SRP-ID 100, LSP Operational =3D GO= ING-UP) [ Without > waiting for RSVP signaling ] > > PCE <=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94 PCRpt (SRP-ID 0x0000000, LSP Operational = bit =3D UP ] > [After receiving successful RSVP setup ] > > > > [ina] Yes > > > > [3] section 7.2 (SRP Object) > > > > =E2=80=9CAn SRP-ID-number is considered unacknowledged and cannot be reu= sed until > a PCErr or PCRpt arrives with an SRP-ID-number equal or higher for the sa= me > LSP.* A PCRpt with state "Pending=E2=80=9D is not considered as an > acknowledgement.*=E2=80=9D > > > > [ina] This text is not applicable, it is left over from earlier > discussions on the SRP, thank you for pointing this out. > > > > [Hari] Per section 6.2, the first message (PCRpt) will have the SRP-ID an= d > status as =E2=80=9CPending=E2=80=9D since the LSP hasn=E2=80=99t been sig= naled. In this case, does > the SRP-ID in PCRpt considered unacknowledged ? It would be great if the > SRP-ID could be explained with an example especially for the PCUpdate cas= es > from PCC perspective. > > > > > > [4] Section 7.3.1. > > > > [Hari] Shouldn=E2=80=99t the IPV4-LSP-IDENTIFIERES-TLV length be 16 ? Si= milar > changes for IPV6-LSP-IDENTIFIER-TLV. > > > > [ina] Yes, thank you for catching, the TLV was changed in version 07 but > the length was not updated at that time :-( > > > > [5] General Comment. Will the =E2=80=9CType=3D[TBD]=E2=80=9D in 7.xx sect= ions be updated > with the proposed values in section 8.x. > > > > [ina] Yes. > > > > Thanks, > > Hari > > > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > > --089e015369f008963804f353130a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hari,=C2=A0

The short answer is that se= nding a path computation request as per 5440 is not precluded in the draft,= although this rather breaks the delegation concept. What is not available = today is to send the LSP object in the PCReq, but for your scenario that is= not needed.=C2=A0

However, the model of operation where the PCC sends PCR= eq should be carefully considered, because now the control is split between= PCC and PCE. A cleaner solution is for the PCE to be made aware of the loc= al trigger and take the decision to act on it, or the PCC to revoke the del= egation, change the LSP then delegate again. This is a case-by-case evaluat= ion.=C2=A0

Ina=C2=A0



<= /div>


On= Wed, Feb 26, 2014 at 9:35 AM, Hariharan Ananthakrishnan = <hanantha@juni= per.net> wrote:
Inline..

From: Dhruv Dhody <dhruv.dhody@huawei.com&g= t;
Date: Tuesday, February 25, 2014 at= 8:17 PM
To: Hariharan Ananthakrishnan <<= a href=3D"mailto:hanantha@juniper.net" target=3D"_blank">hanantha@juniper.n= et>, Ina Minei <inaminei@google.com>
Cc: "pce@ietf.org" <pce@ietf.org>
Subject: RE: [Pce] comments draft-i= etf-pce-stateful-pce-08.txt

Hi Hari,

=C2=A0

Apologies for butting in, but=E2=80=A6

=C2=A0

From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Hariharan Ananthakrishnan
Subject: Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt

=C2=A0

Thanks Ina. Another followup question. Can a PCC use PCReq with = an =E2=80=98active stateful PCE=E2=80=99 ? The PCE could respond with a PCU= pdate in return or PCErr. =C2=A0This will be useful for a PCC to trigger a path (re)computation based on =E2=80=98lo= cal event=E2=80=99 that a PCE might not be aware of.

[DD] A =E2=80=9Dlocal events=E2=80=9D = can simply be reported to the active stateful PCE via PCRpt for a delegated= LSP=E2=80=A6

Do you have any specific event in mind= that would require PCReq instead?

[Hari] The local event could be a timer event say re-optimize timer.. = =C2=A0

=C2=A0

Dhruv

=C2=A0

- Hari

=C2=A0

From: In= a Minei <inamin= ei@google.com>
Date: Tuesday, February 25, 2014 at 6:21 PM
To: Hariharan Ananthakrishnan <hanantha@juniper.net>
Cc: "pce@ietf= .org" <pce@ie= tf.org>
Subject: Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt

=C2=A0

Hari,=C2=A0

=C2=A0

Thank you for the review, please find answers inline, marked [in= a]

=C2=A0

=C2=A0

On Mon, Feb 24, 2014 at 5:52 PM, Hariharan Ananthakrishnan <<= a href=3D"mailto:hanantha@juniper.net" target=3D"_blank">hanantha@juniper.n= et> wrote:

Hi Authors,

=C2=A0

Couple of comments:

=C2=A0

[1] section 5.6.2 =E2=80=93 Active Stateful PCE LSP Update

=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9C For each LSP, it sends an LSP= State Report carried on PCRpt message to the PCE, indicating that the LSP= =E2=80=99s status is =E2=80=98Pending=E2=80=99. =E2=80=9C

=C2=A0

[Hari] What is the =E2=80=9CPending=E2=80=9D status corresponds = to in LSP Object ? Is it LSP Operational bits (0-7) ? Does state =E2=80=98P= ending=E2=80=99 corresponds to GOING-DOWN(3) or GOING-UP(4) ?\

=C2=A0

[ina] Yes, will clean up the text. "Pending" is a left= over from much earlier incarnations of this draft.=C2=A0

=C2=A0

[2] section 6.2 =E2=80=93 The PCUpd Message=

=C2=A0

=E2=80=9CA PCC May respond with multiple LSP State Reports to re= port LSP setup progress of a single LSP. In that case, the SRP-ID-number MU= ST be included for the first message, for subsequent messages the reserved value 0x00000000 SHOULD be u= sed=E2=80=9D.

=C2=A0

[Hari] A PCC implementation=C2=A0=C2=A0may send a PCRpt immediat= ely after receiving a PCUpdate (without waiting for RSVP completion). Later= it sends a PCRpt, when it receives updates from RSVP.=C2=A0=C2=A0Putting this behavior in the above = context, could you please clarify the if the below behavior is correct:<= /u>

=C2=A0

PCUpdate (SRP-ID 100) =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94> PCC

PCE <=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 PCRpt (SRP-ID 100, LSP Operat= ional =3D GOING-UP) [ Without waiting for RSVP signaling ]

PCE <=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 PCRpt (SRP-ID 0x0000000, LSP = Operational bit =3D UP ] [After receiving successful RSVP setup ]=

=C2=A0

[ina] Yes=C2=A0

=C2=A0

[3] section 7.2 (SRP Object)=C2=A0

=C2=A0

=C2=A0=E2=80=9CAn SRP-ID-number is considered unacknowledged and= cannot be reused until a PCErr or PCRpt arrives with an SRP-ID-number equa= l or higher for the same LSP. A PCRpt with state "Pending=E2=80=9D is not considered as an acknowle= dgement.=E2=80=9D

=C2=A0

[ina] This text is not applicable, it is left over from earlier = discussions on the SRP, thank you for pointing this out.=C2=A0

=C2=A0

[Hari] Per section 6.2, the first message (PCRpt) will have the = SRP-ID and status as =E2=80=9CPending=E2=80=9D since the LSP hasn=E2=80=99t= been signaled. In this case, does the SRP-ID in PCRpt considered unacknowledged ? =C2=A0It would be great if the SRP-ID= could be explained with an example especially for the PCUpdate cases from = PCC perspective.

=C2=A0

=C2=A0

[4] Section 7.3.1.

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

[Hari] Shouldn=E2=80=99t the IPV4-LSP-IDENTIFIERES-TLV length be= 16 ?=C2=A0=C2=A0Similar changes for IPV6-LSP-IDENTIFIER-TLV.=

=C2=A0

[ina] Yes, thank you for catching, the TLV was changed in versio= n 07 but the length was not updated at that time :-(=C2=A0

=C2=A0

[5] General Comment. Will the =E2=80=9CType=3D[TBD]=E2=80=9D in = 7.xx sections be updated with the proposed values in section 8.x.=

=C2=A0

[ina] Yes. =C2=A0

=C2=A0

Thanks,

Hari

=C2=A0


_______________________________________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce

=C2=A0

--089e015369f008963804f353130a-- From nobody Wed Feb 26 18:44:09 2014 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 9ADAA1A039A for ; Wed, 26 Feb 2014 18:43:59 -0800 (PST) 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, 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 fbxBH7T56yxY for ; Wed, 26 Feb 2014 18:43:53 -0800 (PST) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1FE1A036F for ; Wed, 26 Feb 2014 18:43:52 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id as1so1049096iec.17 for ; Wed, 26 Feb 2014 18:43:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=+ruj2AwyPlwJcYlkEVu+FU7IYdMCK7Inh0p19XSaMys=; b=Puxs9NTQ5GwiimMhEFSWx/k8N610LZTx2RoYhp+MjILwZ6xTxWc6+1tYOlRTLNcr6O GEvr7K87K2ysJo8ml8bUc35bezZY5E1u4+6XI0ofRFFuGGpRBE72tJQRGjNEQoTP2jmf a0Xz3F+Kjl1ZrwrAeq/3nZDNITmMdBmIiPl2JWYVSHqz4fGVvAdJYeZYeAqtGsAYBuc9 cvl6VOtbDwhmSSuBwv88nSebI3oH5gwcwVIx+Oqbi83zNTGFWEtNIuTYWiLkLz0KRTpN nGI91saH30EDFBgoIiR2fX4dG/oDoq7pXwklflGLgWCI7JtV73/Sn7U7r4TWVVsfY+iO MS3Q== MIME-Version: 1.0 X-Received: by 10.43.51.65 with SMTP id vh1mr3001006icb.24.1393469031598; Wed, 26 Feb 2014 18:43:51 -0800 (PST) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.160.231 with HTTP; Wed, 26 Feb 2014 18:43:51 -0800 (PST) In-Reply-To: References: <23CE718903A838468A8B325B80962F9B75543CA4@szxeml556-mbs.china.huawei.com> Date: Thu, 27 Feb 2014 08:13:51 +0530 X-Google-Sender-Auth: t5L7fZLodZcoCr31N7kfoZubiRk Message-ID: From: Dhruv Dhody To: Ina Minei Content-Type: multipart/alternative; boundary=bcaec5299ad7a24f3704f35a4ac6 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/ZFrwM_4WJvMewWuvtTzcKEInABc Cc: "pce@ietf.org" Subject: Re: [Pce] comments draft-ietf-pce-stateful-pce-08.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: Thu, 27 Feb 2014 02:43:59 -0000 --bcaec5299ad7a24f3704f35a4ac6 Content-Type: text/plain; charset=ISO-8859-1 Hi Ina, Hari, I agree with Ina that this would break the delegation process, once you have given control over to the PCE, it should be remain with PCE. > What is not available today is to send the LSP object in the PCReq, Ina since you bring this up, IMO LSP object in PCReq for passive stateful PCE can be useful in case of re-optimization, exclusion etc. Some extensions to PCEP are needed to do that, but the first step would be to identify an LSP in PCReq message. This has an added advantage for P2MP LSP (which are much bigger in size and option to not encode a full P2MP LSP would be good). Regards, Dhruv On Wed, Feb 26, 2014 at 11:37 PM, Ina Minei wrote: > Hari, > > The short answer is that sending a path computation request as per 5440 is > not precluded in the draft, although this rather breaks the delegation > concept. What is not available today is to send the LSP object in the > PCReq, but for your scenario that is not needed. > > However, the model of operation where the PCC sends PCReq should be > carefully considered, because now the control is split between PCC and PCE. > A cleaner solution is for the PCE to be made aware of the local trigger and > take the decision to act on it, or the PCC to revoke the delegation, change > the LSP then delegate again. This is a case-by-case evaluation. > > Ina > > > > > > On Wed, Feb 26, 2014 at 9:35 AM, Hariharan Ananthakrishnan < > hanantha@juniper.net> wrote: > >> Inline.. >> >> From: Dhruv Dhody >> Date: Tuesday, February 25, 2014 at 8:17 PM >> To: Hariharan Ananthakrishnan , Ina Minei < >> inaminei@google.com> >> Cc: "pce@ietf.org" >> Subject: RE: [Pce] comments draft-ietf-pce-stateful-pce-08.txt >> >> Hi Hari, >> >> >> >> Apologies for butting in, but... >> >> >> >> *From:* Pce [mailto:pce-bounces@ietf.org ] *On >> Behalf Of *Hariharan Ananthakrishnan >> *Subject:* Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt >> >> >> >> Thanks Ina. Another followup question. Can a PCC use PCReq with an >> 'active stateful PCE' ? The PCE could respond with a PCUpdate in return or >> PCErr. This will be useful for a PCC to trigger a path (re)computation >> based on 'local event' that a PCE might not be aware of. >> >> *[DD] A "local events" can simply be reported to the active stateful PCE >> via PCRpt for a delegated LSP... * >> >> *Do you have any specific event in mind that would require PCReq instead?* >> >> [Hari] The local event could be a timer event say re-optimize timer.. >> >> >> >> *Dhruv* >> >> >> >> - Hari >> >> >> >> *From: *Ina Minei >> *Date: *Tuesday, February 25, 2014 at 6:21 PM >> *To: *Hariharan Ananthakrishnan >> *Cc: *"pce@ietf.org" >> *Subject: *Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt >> >> >> >> Hari, >> >> >> >> Thank you for the review, please find answers inline, marked [ina] >> >> >> >> >> >> On Mon, Feb 24, 2014 at 5:52 PM, Hariharan Ananthakrishnan < >> hanantha@juniper.net> wrote: >> >> Hi Authors, >> >> >> >> Couple of comments: >> >> >> >> [1] section 5.6.2 - Active Stateful PCE LSP Update >> >> " For each LSP, it sends an LSP State Report carried on PCRpt >> message to the PCE, indicating that the LSP's status is 'Pending'. " >> >> >> >> [Hari] What is the "Pending" status corresponds to in LSP Object ? Is it >> LSP Operational bits (0-7) ? Does state 'Pending' corresponds to >> GOING-DOWN(3) or GOING-UP(4) ?\ >> >> >> >> [ina] Yes, will clean up the text. "Pending" is a leftover from much >> earlier incarnations of this draft. >> >> >> >> [2] section 6.2 - The PCUpd Message >> >> >> >> "A PCC May respond with multiple LSP State Reports to report LSP setup >> progress of a single LSP. In that case, the SRP-ID-number MUST be included >> for the first message, for subsequent messages the reserved value >> 0x00000000 SHOULD be used". >> >> >> >> [Hari] A PCC implementation may send a PCRpt immediately after receiving >> a PCUpdate (without waiting for RSVP completion). Later it sends a PCRpt, >> when it receives updates from RSVP. Putting this behavior in the above >> context, could you please clarify the if the below behavior is correct: >> >> >> >> PCUpdate (SRP-ID 100) ----------> PCC >> >> PCE <---------------------- PCRpt (SRP-ID 100, LSP Operational = GOING-UP) [ Without >> waiting for RSVP signaling ] >> >> PCE <---------------------- PCRpt (SRP-ID 0x0000000, LSP Operational bit = UP ] >> [After receiving successful RSVP setup ] >> >> >> >> [ina] Yes >> >> >> >> [3] section 7.2 (SRP Object) >> >> >> >> "An SRP-ID-number is considered unacknowledged and cannot be reused >> until a PCErr or PCRpt arrives with an SRP-ID-number equal or higher for >> the same LSP.* A PCRpt with state "Pending" is not considered as an >> acknowledgement.*" >> >> >> >> [ina] This text is not applicable, it is left over from earlier >> discussions on the SRP, thank you for pointing this out. >> >> >> >> [Hari] Per section 6.2, the first message (PCRpt) will have the SRP-ID >> and status as "Pending" since the LSP hasn't been signaled. In this case, >> does the SRP-ID in PCRpt considered unacknowledged ? It would be great if >> the SRP-ID could be explained with an example especially for the PCUpdate >> cases from PCC perspective. >> >> >> >> >> >> [4] Section 7.3.1. >> >> >> >> [Hari] Shouldn't the IPV4-LSP-IDENTIFIERES-TLV length be 16 ? Similar >> changes for IPV6-LSP-IDENTIFIER-TLV. >> >> >> >> [ina] Yes, thank you for catching, the TLV was changed in version 07 but >> the length was not updated at that time :-( >> >> >> >> [5] General Comment. Will the "Type=[TBD]" in 7.xx sections be updated >> with the proposed values in section 8.x. >> >> >> >> [ina] Yes. >> >> >> >> Thanks, >> >> Hari >> >> >> >> >> _______________________________________________ >> 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 > > --bcaec5299ad7a24f3704f35a4ac6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ina, Hari,

I agree with Ina that this would break the delegation process, once you hav= e given control over to the PCE, it should be remain with PCE. 
<= div class=3D"gmail_default" style=3D"font-family:'courier new',mono= space">
> What is not available today is to send the LSP= object in the PCReq,
Ina since you bring this up, IMO LSP object in PCReq for passive st= ateful PCE can be useful in case of re-optimization, exclusion etc. 
Some extensions to PCEP are needed to do that, but the first step would be = to identify an LSP in PCReq message. 

This has an added advantage for P2MP LSP (which are much bigger in size and= option to not encode a full P2MP LSP would be good). 
Regards,
Dhruv
    
  

=


On Wed, Feb 26, 2014 at 11:37 PM, Ina Minei = <inaminei@google.com> wrote:
Hari, 

The short answer is that se= nding a path computation request as per 5440 is not precluded in the draft,= although this rather breaks the delegation concept. What is not available = today is to send the LSP object in the PCReq, but for your scenario that is= not needed. 

However, the model of operation where the PCC sends PCR= eq should be carefully considered, because now the control is split between= PCC and PCE. A cleaner solution is for the PCE to be made aware of the loc= al trigger and take the decision to act on it, or the PCC to revoke the del= egation, change the LSP then delegate again. This is a case-by-case evaluat= ion. 

Ina 



<= /div>


On Wed, Feb 26, 2014 at= 9:35 AM, Hariharan Ananthakrishnan <hanantha@juniper.net> wrote:
Inline..

From: Dhruv Dhody <dhruv.dhody@huawei.com&g= t;
Date: Tuesday, February 25, 2014 at= 8:17 PM
To: Hariharan Ananthakrishnan <<= a href=3D"mailto:hanantha@juniper.net" target=3D"_blank">hanantha@juniper.n= et>, Ina Minei <inaminei@google.com>
Cc: "pce@ietf.org" <pce@ietf.org>
Subject: RE: [Pce] comments draft-i= etf-pce-stateful-pce-08.txt

Hi Hari,

 

Apologies for butting in, but…=

 

From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Hariharan Ananthakrishnan
Subject: Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt

 

Thanks Ina. Another followup question. Can a PCC use PCReq with = an ‘active stateful PCE’ ? The PCE could respond with a PCUpdat= e in return or PCErr.  This will be useful for a PCC to trigger a path (re)computation based on ‘loca= l event’ that a PCE might not be aware of.

[DD] A ”local events” can = simply be reported to the active stateful PCE via PCRpt for a delegated LSP= …

Do you have any specific event in mind= that would require PCReq instead?

[Hari] The local event could be a timer event say re-optimize timer.. =  

 

Dhruv

 

- Hari

 

From: In= a Minei <inamin= ei@google.com>
Date: Tuesday, February 25, 2014 at 6:21 PM
To: Hariharan Ananthakrishnan <hanantha@juniper.net>
Cc: "pce@ietf= .org" <pce@ie= tf.org>
Subject: Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt

 

Hari, 

 

Thank you for the review, please find answers inline, marked [in= a]

 

 

On Mon, Feb 24, 2014 at 5:52 PM, Hariharan Ananthakrishnan <<= a href=3D"mailto:hanantha@juniper.net" target=3D"_blank">hanantha@juniper.n= et> wrote:

Hi Authors,

 

Couple of comments:

 

[1] section 5.6.2 – Active Stateful PCE LSP Update<= u>

     “ For each LSP, it sends an LSP S= tate Report carried on PCRpt message to the PCE, indicating that the LSP&rs= quo;s status is ‘Pending’. “

 

[Hari] What is the “Pending” status corresponds to i= n LSP Object ? Is it LSP Operational bits (0-7) ? Does state ‘Pending= ’ corresponds to GOING-DOWN(3) or GOING-UP(4) ?\

 

[ina] Yes, will clean up the text. "Pending" is a left= over from much earlier incarnations of this draft. 

 

[2] section 6.2 – The PCUpd Message

 

“A PCC May respond with multiple LSP State Reports to repo= rt LSP setup progress of a single LSP. In that case, the SRP-ID-number MUST= be included for the first message, for subsequent messages the reserved value 0x00000000 SHOULD be u= sed”.

 

[Hari] A PCC implementation  may send a PCRpt immediat= ely after receiving a PCUpdate (without waiting for RSVP completion). Later= it sends a PCRpt, when it receives updates from RSVP.  Putting this behavior in the above = context, could you please clarify the if the below behavior is correct:<= /u>

 

PCUpdate (SRP-ID 100) —————> PC= C

PCE <————————= ——— PCRpt (SRP-ID 100, LSP Operational =3D GOING-UP) [ Wi= thout waiting for RSVP signaling ]

PCE <————————= ——— PCRpt (SRP-ID 0x0000000, LSP Operational bit =3D UP ]= [After receiving successful RSVP setup ]

 

[ina] Yes 

 

[3] section 7.2 (SRP Object) 

 

 “An SRP-ID-number is considered unacknowledged and c= annot be reused until a PCErr or PCRpt arrives with an SRP-ID-number equal = or higher for the same LSP. A PCRpt with state "Pending” is not considered as an acknowledg= ement.”

 

[ina] This text is not applicable, it is left over from earlier = discussions on the SRP, thank you for pointing this out. 

 

[Hari] Per section 6.2, the first message (PCRpt) will have the = SRP-ID and status as “Pending” since the LSP hasn’t been = signaled. In this case, does the SRP-ID in PCRpt considered unacknowledged ?  It would be great if the SRP-ID= could be explained with an example especially for the PCUpdate cases from = PCC perspective.

 

 

[4] Section 7.3.1.

   

[Hari] Shouldn’t the IPV4-LSP-IDENTIFIERES-TLV length be 1= 6 ?  Similar changes for IPV6-LSP-IDENTIFIER-TLV.

 

[ina] Yes, thank you for catching, the TLV was changed in versio= n 07 but the length was not updated at that time :-( 

 

[5] General Comment. Will the “Type=3D[TBD]” in 7.xx= sections be updated with the proposed values in section 8.x.=

 

[ina] Yes.  

 

Thanks,

Hari

 


_______________________________________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce

 


_______________________________________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce


--bcaec5299ad7a24f3704f35a4ac6-- From nobody Wed Feb 26 22:40:13 2014 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 62B5B1A06EE for ; Wed, 26 Feb 2014 22:40:11 -0800 (PST) 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, HTML_MESSAGE=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 YtDViikYwRRb for ; Wed, 26 Feb 2014 22:40:09 -0800 (PST) Received: from rudy.puc.rediris.es (rudy.puc.rediris.es [IPv6:2001:720:418:ca01::132]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE841A0450 for ; Wed, 26 Feb 2014 22:40:09 -0800 (PST) Received: from [84.88.62.208] (helo=leo) by rudy.puc.rediris.es with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1WIuda-0002uQ-Kp for pce@ietf.org; Thu, 27 Feb 2014 07:40:06 +0100 Received: from [84.88.61.50] (unknown [84.88.61.50]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id 94E4A1FF6C for ; Thu, 27 Feb 2014 07:40:03 +0100 (CET) X-Envelope-From: ramon.casellas@cttc.es Message-ID: <530EDDC0.8000206@cttc.es> Date: Thu, 27 Feb 2014 07:40:00 +0100 From: Ramon Casellas User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: pce@ietf.org References: <23CE718903A838468A8B325B80962F9B75543CA4@szxeml556-mbs.china.huawei.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010807000905000003060400" X-Spamina-Bogosity: Ham Archived-At: http://mailarchive.ietf.org/arch/msg/pce/RG8ETwdSfkaHCuzg5oCUOReDgKg Subject: Re: [Pce] comments draft-ietf-pce-stateful-pce-08.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: Thu, 27 Feb 2014 06:40:11 -0000 This is a multi-part message in MIME format. --------------010807000905000003060400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit El 27/02/2014 3:43, Dhruv Dhody escribió: > > > > What is not available today is to send the LSP object in the PCReq, > Ina since you bring this up, IMO LSP object in PCReq for passive > stateful PCE can be useful in case of re-optimization, exclusion etc. > Some extensions to PCEP are needed to do that, but the first step > would be to identify an LSP in PCReq message. Dhruv, Ina, all TL&DR +1. Just fwiw, in one of our use cases, a "front-end" stateful PCE may delegate a complex (e.g. optical) computation/re-optimization/defragmentation to a "back-end" PCE, and both the TED and LSPDB are shared between the pool of PCEs. In previous versions of the draft, we used the LSP object that was included within a PCEP request. There was the issue about the plspid, our approach was based on using a dummy plspid and refer to the LSP entry in the database by its symbolic name (primary key). In short, we did find it useful to be able to "refer" to an LSP within the db when requesting computations between collaborating PCEs. Indeed, much like Dhruv's, for this specific use case, the backend is stateful but passive. The alternative is to provide the RRO, but the db contains other relevant information that cannot be conveyed in a "rfc5440" re-optimization Thanks Ramon --------------010807000905000003060400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
El 27/02/2014 3:43, Dhruv Dhody escribió:


> What is not available today is to send the LSP object in the PCReq,
Ina since you bring this up, IMO LSP object in PCReq for passive stateful PCE can be useful in case of re-optimization, exclusion etc. 
Some extensions to PCEP are needed to do that, but the first step would be to identify an LSP in PCReq message. 

Dhruv, Ina, all

TL&DR +1. Just fwiw, in one of our use cases, a "front-end" stateful PCE may delegate a complex (e.g. optical) computation/re-optimization/defragmentation to a "back-end" PCE, and both the TED and LSPDB are shared between the pool of PCEs. In previous versions of the draft, we used the LSP object that was included within a PCEP request. There was the issue about the plspid, our approach was based on using a dummy plspid and refer to the LSP entry in the database by its symbolic name (primary key).

In short, we did find it useful to be able to "refer" to an LSP within the db when requesting computations between collaborating PCEs. Indeed, much like Dhruv's, for this specific use case, the backend is stateful but passive. The alternative is to provide the RRO, but the db contains other relevant information that cannot be conveyed in a "rfc5440" re-optimization

Thanks
Ramon
--------------010807000905000003060400-- From nobody Thu Feb 27 00:43:45 2014 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 598FB1A0773 for ; Thu, 27 Feb 2014 00:43:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_22=0.6, SPF_PASS=-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 b42vDK7_eq8K for ; Thu, 27 Feb 2014 00:43:41 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBAA1A00CF for ; Thu, 27 Feb 2014 00:43:41 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id bs8so340013wib.4 for ; Thu, 27 Feb 2014 00:43:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fMq5e97rdalcVeYnp53QBQN9+8nx62+IDAoPpCMaz78=; b=NmL0tJJi/D5GjDB4TzX2ofEEUxswvfQDzODnUrY9Cbq3xWR3izi9ktsNFElpgN5+qI GyX9/k8fa3s1Nyu+SMBVNM1tlU4VVb3BtZLl9Me65hKXIaH5kVlFNR7yzbT8opPN0eYG LnxEKnJbrBXiB4YIs+fTg/aKUkT5Rh19v56JQGp1S1uEFf0CmLdtj1zKDDFow0CwCdB3 BInW6WqLHN9nOKXxXScAq2Iq7mTI8UWVTAmte7f/az4re9gT+E2ApueE9xUMvtwRI2xP P+ih1gXjWhXLwLl2/7D12cfjO2i7aBweCEyiaPe3eR6sxNjsRFZiHxl+28MZort+McSs lCKw== MIME-Version: 1.0 X-Received: by 10.180.77.74 with SMTP id q10mr11519640wiw.39.1393490619489; Thu, 27 Feb 2014 00:43:39 -0800 (PST) Received: by 10.216.61.12 with HTTP; Thu, 27 Feb 2014 00:43:39 -0800 (PST) In-Reply-To: <530EDDC0.8000206@cttc.es> References: <23CE718903A838468A8B325B80962F9B75543CA4@szxeml556-mbs.china.huawei.com> <530EDDC0.8000206@cttc.es> Date: Thu, 27 Feb 2014 09:43:39 +0100 Message-ID: From: Cyril Margaria To: Ramon Casellas Content-Type: multipart/alternative; boundary=f46d043bdf6a5f654c04f35f51f4 Archived-At: http://mailarchive.ietf.org/arch/msg/pce/Bma-t07u27sw7SD_mu5OksH1gs8 Cc: "pce@ietf.org" Subject: Re: [Pce] comments draft-ietf-pce-stateful-pce-08.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: Thu, 27 Feb 2014 08:43:43 -0000 --f46d043bdf6a5f654c04f35f51f4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi I agree with Ramon and Druv. In addition to those use case, the LSP object in PCReq/PCRep is also applicable for non-delegated LSP in an active stateful PCE case. One example can be the rerouting after a failure, this may affect delegated and non delegated LSPs, the Stateful PCE would be benefit from knowing which non delegated LSP is to be rerouted. BR, Cyril. On 27 February 2014 07:40, Ramon Casellas wrote: > El 27/02/2014 3:43, Dhruv Dhody escribi=F3: > > > > > What is not available today is to send the LSP object in the PCReq, > Ina since you bring this up, IMO LSP object in PCReq for passive stateful > PCE can be useful in case of re-optimization, exclusion etc. > Some extensions to PCEP are needed to do that, but the first step would > be to identify an LSP in PCReq message. > > > Dhruv, Ina, all > > TL&DR +1. Just fwiw, in one of our use cases, a "front-end" stateful PCE > may delegate a complex (e.g. optical) > computation/re-optimization/defragmentation to a "back-end" PCE, and both > the TED and LSPDB are shared between the pool of PCEs. In previous versio= ns > of the draft, we used the LSP object that was included within a PCEP > request. There was the issue about the plspid, our approach was based on > using a dummy plspid and refer to the LSP entry in the database by its > symbolic name (primary key). > > In short, we did find it useful to be able to "refer" to an LSP within th= e > db when requesting computations between collaborating PCEs. Indeed, much > like Dhruv's, for this specific use case, the backend is stateful but > passive. The alternative is to provide the RRO, but the db contains other > relevant information that cannot be conveyed in a "rfc5440" re-optimizati= on > > Thanks > Ramon > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > --f46d043bdf6a5f654c04f35f51f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi

I agree with Ramon and Druv.
In addition to those use case, the LSP object in PCReq/PCRep is= also applicable for non-delegated LSP in an active stateful PCE case.
One example can be the rerouting after a failure, this may affec= t delegated and non delegated LSPs, the Stateful PCE would be benefit from = knowing which non delegated LSP is to be rerouted.


BR,
Cyril.

On 27 February 2014 07:40, Ramon Casellas <ramon.casellas@cttc.es> wrote:
=20 =20 =20
El 27/02/2014 3:43, Dhruv Dhody escribi=F3:


>=A0What is not available today is to send the LSP object in the PCReq,
Ina since you bring this up, IMO LSP o= bject in PCReq for passive stateful PCE can be useful in case of re-optimization, exclusion etc.=A0
Some extensions to PCEP are needed to do that, but the first step would be to identify an LSP in PCReq message.=A0

Dhruv, Ina, all

TL&DR +1. Just fwiw, in one of our use cases, a "front-end&quo= t; stateful PCE may delegate a complex (e.g. optical) computation/re-optimization/defragmentation to a "back-end" P= CE, and both the TED and LSPDB are shared between the pool of PCEs. In previous versions of the draft, we used the LSP object that was included within a PCEP request. There was the issue about the plspid, our approach was based on using a dummy plspid and refer to the LSP entry in the database by its symbolic name (primary key).

In short, we did find it useful to be able to "refer" to an L= SP within the db when requesting computations between collaborating PCEs. Indeed, much like Dhruv's, for this specific use case, the backend is stateful but passive. The alternative is to provide the RRO, but the db contains other relevant information that cannot be conveyed in a "rfc5440" re-optimization

Thanks
Ramon

_______________________________________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce


--f46d043bdf6a5f654c04f35f51f4-- From nobody Thu Feb 27 18:18:40 2014 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 B294E1A0699 for ; Thu, 27 Feb 2014 18:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.403 X-Spam-Level: X-Spam-Status: No, score=0.403 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 ON_XIWot6bZT for ; Thu, 27 Feb 2014 18:18:34 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 499FF1A0698 for ; Thu, 27 Feb 2014 18:18:33 -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 BEB21639; Fri, 28 Feb 2014 02:18:30 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 28 Feb 2014 02:18:14 +0000 Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 28 Feb 2014 02:18:15 +0000 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.22]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Fri, 28 Feb 2014 10:18:10 +0800 From: "Zhangxian (Xian)" To: Jonathan Hardwick Thread-Topic: Comments on draft-minei-pce-stateful-sync-optimizations-01 Thread-Index: Ac8ps3n6I0/p/UTJSj24UQQcD8tDLAF5aSuAAM1O1KAAIeemIA== Date: Fri, 28 Feb 2014 02:18:09 +0000 Message-ID: References: <09CE6C3BE5E1EA40B987BF5F25D8DDBAE13416C9@ENFICSMBX1.datcon.co.uk> <09CE6C3BE5E1EA40B987BF5F25D8DDBAE1355A2B@ENFICSMBX1.datcon.co.uk> In-Reply-To: <09CE6C3BE5E1EA40B987BF5F25D8DDBAE1355A2B@ENFICSMBX1.datcon.co.uk> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.104.209] Content-Type: multipart/alternative; boundary="_000_C636AF2FA540124E9B9ACB5A6BECCE6B3020CB84SZXEMA512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pce/PKLwohJusLVnLlbY1EbXkBPQFSY Cc: "draft-minei-pce-stateful-sync-optimizations@tools.ietf.org" , "pce@ietf.org" Subject: Re: [Pce] Comments on draft-minei-pce-stateful-sync-optimizations-01 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, 28 Feb 2014 02:18:39 -0000 --_000_C636AF2FA540124E9B9ACB5A6BECCE6B3020CB84SZXEMA512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIEpvbiwNCg0KICAgICAgICAgR2xhZCB0byBzZWUgdGhlIGZpcnN0IHR3byBwb2ludHMgYXJl IG5vdyBjbGVhcmVkLiAgUGxlYXNlIHNlZSBteSBleHBsYW5hdGlvbiB0byB0aGUgbGFzdCBwb2lu dCBpbmxpbmUsIG1hcmtlZCB3aXRoIFtYaWFuMl06DQoNCkZyb206IEpvbmF0aGFuIEhhcmR3aWNr IFttYWlsdG86Sm9uYXRoYW4uSGFyZHdpY2tAbWV0YXN3aXRjaC5jb21dDQpTZW50OiAyMDE0xOoy 1MIyNsjVIDE3OjEyDQpUbzogWmhhbmd4aWFuIChYaWFuKQ0KQ2M6IHBjZUBpZXRmLm9yZzsgZHJh ZnQtbWluZWktcGNlLXN0YXRlZnVsLXN5bmMtb3B0aW1pemF0aW9uc0B0b29scy5pZXRmLm9yZw0K U3ViamVjdDogUkU6IENvbW1lbnRzIG9uIGRyYWZ0LW1pbmVpLXBjZS1zdGF0ZWZ1bC1zeW5jLW9w dGltaXphdGlvbnMtMDENCg0KSGkgWGlhbiwgcGxlYXNlIHNlZSBbSm9uXSBiZWxvdy4uLg0KDQpG cm9tOiBaaGFuZ3hpYW4gKFhpYW4pIFttYWlsdG86emhhbmcueGlhbkBodWF3ZWkuY29tXQ0KU2Vu dDogMjIgRmVicnVhcnkgMjAxNCAwNzozMw0KVG86IEpvbmF0aGFuIEhhcmR3aWNrDQpDYzogcGNl QGlldGYub3JnOyBkcmFmdC1taW5laS1wY2Utc3RhdGVmdWwtc3luYy1vcHRpbWl6YXRpb25zQHRv b2xzLmlldGYub3JnDQpTdWJqZWN0OiBSRTogQ29tbWVudHMgb24gZHJhZnQtbWluZWktcGNlLXN0 YXRlZnVsLXN5bmMtb3B0aW1pemF0aW9ucy0wMQ0KDQpIaSwgSm9uLA0KDQogICBUaGFuayB5b3Ug dmVyeSBtdWNoIGZvciB0aGUgY29uc3RydWN0aXZlIGNvbW1lbnRzLiAgUGxlYXNlIHNlZSBteSBy ZXBseSBpbmxpbmUsIG1hcmtlZCB3aXRoIFtYaWFuXToNCg0KRnJvbTogUGNlIFttYWlsdG86cGNl LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb25hdGhhbiBIYXJkd2ljaw0KU2VudDog MjAxNMTqMtTCMTXI1SAyOjM1DQpUbzogZHJhZnQtbWluZWktcGNlLXN0YXRlZnVsLXN5bmMtb3B0 aW1pemF0aW9uc0B0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtbWluZWktcGNlLXN0YXRlZnVs LXN5bmMtb3B0aW1pemF0aW9uc0B0b29scy5pZXRmLm9yZz4NCkNjOiBwY2VAaWV0Zi5vcmc8bWFp bHRvOnBjZUBpZXRmLm9yZz4NClN1YmplY3Q6IFtQY2VdIENvbW1lbnRzIG9uIGRyYWZ0LW1pbmVp LXBjZS1zdGF0ZWZ1bC1zeW5jLW9wdGltaXphdGlvbnMtMDENCg0KSGkgdGhlcmUNCg0KSSBoYXZl IHJldmlld2VkIHRoaXMgZHJhZnQgqEMgaGVyZSBhcmUgbXkgY29tbWVudHMuDQoNCkJlc3QgcmVn YXJkcw0KSm9uDQoNClNlY3Rpb24gMy4yDQpGaWd1cmUgMiwgSSB0aGluayB0aGUgobBzeW5jIGRv bmWhsSBQQ1JwdCBzaG91bGQgaGF2ZSBTWU5DPTAsIG5vdCBTWU5DPTEuDQpbWGlhbl06IEluZGVl ZC4gVGhhbmsgeW91IGZvciBzcG90dGluZyB0aGlzIHR5cG8uDQoNClNlY3Rpb24gNS4yDQogICBJ ZiBhIFBDQyBoYXMgdG8gZm9yY2UgZnVsbCBMU1AgREINCiAgIHN5bmNocm9uaXphdGlvbiBkdWUg dG8gcmVhc29ucyBpbmNsdWRpbmcgYnV0IG5vdCBsaW1pdGVkOiAoMSkgbG9jYWwNCiAgIHBvbGlj eSBjb25maWd1cmVkIGF0IHRoZSBQQ0M7ICgyKSBubyBzdWZmaWNpZW50IExTUCBzdGF0ZSBjYWNo ZXMgZm9yDQogICBpbmNyZW1lbnRhbCB1cGRhdGUsIHRoZSBQQ0MgY2FuIHNldCB0aGUgRCBmbGFn IHRvIDAuDQoNClBlcmhhcHMgSSBoYXZlIG1pc3VuZGVyc3Rvb2QsIGJ1dCBJIHRoaW5rIGNhc2Ug KDIpIGFib3ZlIGRvZXNuoa90IHdvcmsuICBUaGUgUENDIGRvZXMgbm90IGtub3cgdGhhdCBpdCBo YXMgobBubyBzdWZmaWNpZW50IExTUCBzdGF0ZSBjYWNoZXOhsSB1bnRpbCBpdCByZWNlaXZlcyB0 aGUgT1BFTiBmcm9tIHRoZSBQQ0UgYW5kIHNlZXMgd2hhdCBEQnYgdGhlIFBDRSBoYXMgc2VudC4g IEJ5IHRoZW4sIHRoZSBQQ0MgaGFzIGFscmVhZHkgc2VudCBpdHMgT1BFTiBzbyBpdCBpcyB0b28g bGF0ZSB0byBzZXQgRD0wLiAgVG8gY292ZXIgY2FzZSAoMikgdGhlIGRyYWZ0IG5lZWRzIGEgbWVj aGFuaXNtIGZvciB0aGUgUENDIHRvIGNoYW5nZSBpdHMgbWluZCBhbmQgdGVsbCB0aGUgUENFIHRo YXQgaXQgaXMgZ29pbmcgdG8gc2VuZCBhIGZ1bGwgc25hcHNob3QsIG5vdCBhIHJlcGxheSBvZiB0 aGUgbWlzc2luZyBkYXRhYmFzZSB1cGRhdGVzLiAgVGhlIHNpbXBsZXN0IHRoaW5nIGlzIHByb2Jh Ymx5IGZvciB0aGUgUENDIHRvIGJyaW5nIHRoZSBzZXNzaW9uIGRvd24gYW5kIHRoZW4gYnJpbmcg aXQgYmFjayB1cCBhZ2FpbiB3aXRoIEQ9MC4NCg0KW1hpYW5dOiAgSXQgYWN0dWFsbHkgZGVwZW5k cywgSU1ITy4gSWYgaXQgaXMgZHVlIHRvIHRoZSAxc3QgcmVhc29uIGxpc3RlZCBhYm92ZSwgdGhl biwgaXQgY2FuIGRlY2lkZSBiZWZvcmUgc2VuZGluZyBPUEVOIGFuZCBzZXQgRD0wLiBUaGUgY2Fz ZXMgYXMgYSByZXN1bHQgb2YgdGhlIDJuZCByZWFzb24gbWlnaHQgYmUgbW9yZSBjb21wbGljYXRl ZC4gWW91ciBhbmFseXNpcyB3b3VsZCBiZSBvbmUgb2YgdGhlIGNhc2VzLCBpbiB3aGljaCBhIFBD QyBjYW4gZGV0ZWN0IHRoZSBpbnN1ZmZpY2llbnQgTFNQIHN0YXRlIGNhY2hlcyBPTkxZIGFmdGVy IGl0IGdldHMgdGhlIERCIHZlcnNpb24gaW5mb3JtYXRpb24gZnJvbSB0aGUgb3RoZXIgcGFydHku IEJ1dCBpZiBhIFBDQyBoYXMgbm8gTFNQIHN0YXRlIGNhY2hlcyBvciBpbmNvbXBsZXRlIChtaXNz aW5nIHF1aXRlIHNvbWUgTFNQIHN0YXRlIG9yIHRob3NlIG9mIHRoZSBEQiB2ZXJzaW9uIGluIGJl dHdlZW4pLCBJIHRoaW5rIGl0IGlzIHBvc3NpYmxlIHRoYXQgaXQgY2FuIGRlY2lkZSB3aXRob3V0 IGV2ZW4gY2hlY2tpbmcgdGhlIERCdiBmcm9tIHRoZSBvdGhlciBwYXJ0eS4gRG9lcyB0aGlzIGNs YXJpZnk/DQoNClRvIGluY2x1ZGUgdGhlIGNhc2UgeW91IGRlc2NyaWJlZCwgaG93IGFib3V0IHdl IHVwZGF0ZSB0aGUgdGV4dCAgYXMgYmVsb3c/DQoNCk9MRDoNCiAgIElmIGEgUENDIGhhcyB0byBm b3JjZSBmdWxsIExTUCBEQg0KICAgc3luY2hyb25pemF0aW9uIGR1ZSB0byByZWFzb25zIGluY2x1 ZGluZyBidXQgbm90IGxpbWl0ZWQ6ICgxKSBsb2NhbA0KICAgcG9saWN5IGNvbmZpZ3VyZWQgYXQg dGhlIFBDQzsgKDIpIG5vIHN1ZmZpY2llbnQgTFNQIHN0YXRlIGNhY2hlcyBmb3INCiAgIGluY3Jl bWVudGFsIHVwZGF0ZSwgdGhlIFBDQyBjYW4gc2V0IHRoZSBEIGZsYWcgdG8gMC4NCg0KW0REXSBO RVc6DQogICBJZiBhIFBDQyBtYXkgaGF2ZSB0byBmb3JjZSBmdWxsIExTUCBEQg0KICAgc3luY2hy b25pemF0aW9uIGR1ZSB0byByZWFzb25zIGluY2x1ZGluZyBidXQgbm90IGxpbWl0ZWQ6ICgxKSBs b2NhbA0KICAgcG9saWN5IGNvbmZpZ3VyZWQgYXQgdGhlIFBDQzsgKDIpIG5vIHN1ZmZpY2llbnQg TFNQIHN0YXRlIGNhY2hlcyBmb3INCiAgIGluY3JlbWVudGFsIHVwZGF0ZSwgdGhlIFBDQyBjYW4g c2V0IHRoZSBEIGZsYWcgdG8gMC4gTm90ZSBhIFBDQyBtYXkgaGF2ZSB0byBicmluZw0KIGRvd24g dGhlIGN1cnJlbnQgc2Vzc2lvbiBhbmQgIGZvcmNlIGEgZnVsbCBMU1BEQiBzeW5jaHJvbml6YXRp b24gd2l0aCBEIGZsYWcgc2V0IHRvDQowIGluIHRoZSAgc3Vic2VxdWVudCBvcGVuIG1lc3NhZ2Uu DQoNCltKb25dIExvb2tzIGdvb2QgdG8gbWUuDQoNClNlY3Rpb24gNCB0YWxrcyBhYm91dCB0aGUg UENFIGhhdmluZyB0byBtYXJrIGl0cyBMU1AgZGF0YWJhc2UgYXMgc3RhbGUsIGFuZCB0aGVuIHJl bW92ZSBhbnkgc3RhbGUgTFNQcyBhdCB0aGUgZW5kIG9mIHRoZSBzeW5jaHJvbml6YXRpb24gcHJv Y2Vzcy4gIEkgYXNzdW1lIHRoYXQgdGhpcyBkb2VzIG5vdCBhcHBseSBpbiBzZWN0aW9uIDUuICBU byBhdm9pZCBjb25mdXNpb24sIEkgdGhpbmsgc2VjdGlvbiA1IHNob3VsZCBzdGF0ZSB0aGF0IHRo ZSBQQ0UgZG9lcyBub3QgbWFyayBpdHMgTFNQIGRhdGFiYXNlIGFzIHN0YWxlIGlmIGJvdGggaXQg YW5kIHRoZSBQQ0MgaGF2ZSBzZXQgRD0xLg0KW1hpYW5dOiBTdXJlLiAgSSB0aGluayB3ZSBoYXZl IGFscmVhZHkgZXhwbGFpbmVkIGluIFNlY3Rpb24gNS4gVGhlIGxhc3Qgc2VudGVuY2Ugb2YgdGhl IHBhcmFncmFwaCBiZWxvdyBGaWd1cmUgNyBzYXlzOiChsE5vdGUgdGhhdCB0aGUgUENFIHNob3Vs ZCBub3QgbWFyayB0aGUgZXhpc3RpbmcgTFNQcyBhcyBzdGFsZSBmb3IgaW5jcmVtZW50YWwgc3Rh dGUgc3luY2hyb25pc2F0aW9uobEuDQoNCltKb25dIEFwb2xvZ2llcywgSSBtaXNzZWQgdGhhdC4N Cg0KSW4gZmlndXJlIDcsIEkgbWF5IGhhdmUgbWlzdW5kZXJzdG9vZCBzZWN0aW9uIDQsIGJ1dCBJ IGRvbqGvdCB0aGluayB0aGlzIGlzIGhvdyB0aGUgVCBiaXQgaXMgc3BlY2lmaWVkLiAgSSBkb26h r3QgdGhpbmsgVD0xIGZvcmNlcyB0aGUgUENDIHRvIHdhaXQgZm9yIGEgUENVcGQgYmVmb3JlIHNl bmRpbmcgdGhlIGluaXRpYWwgc25hcHNob3QgYXMgeW91IGhhdmUgc2hvd24uICBJIGRvbqGvdCB0 aGluayB0aGlzIHN1YnN0YW50aWFsbHkgY2hhbmdlcyBhbnl0aGluZyBhYm91dCBzZWN0aW9uIDUs IHNvIEkgc3VnZ2VzdCByZW1vdmluZyB0aGUgZGlzY3Vzc2lvbiBvZiB0aGUgVCBiaXQgZnJvbSBz ZWN0aW9uIDUuDQpbWGlhbl2julNlY3Rpb24gNCBkZXNjcmliZXMgaG93IGEgUENFIGNhbiBmb3Jj ZSByZS1zeW5jaHJvbml6YXRpb24gYWZ0ZXIgdGhlIGluaXRpYWwgTFNQLURCIHN5bmNocm9uaXph dGlvbiBoYXMgYmVlbiBkb25lLiBTZWN0aW9uIDUgdGFsa3MgYWJvdXQgYW4gYWx0ZXJuYXRpdmUg bWV0aG9kIGZvciB0aGUgaW5pdGlhbCBMU1AtREIgc3luYy4gKGkuZS4sIGluY3JlbWVudGFsIHdh eSkuICBUaGUgaWRlYSBoZXJlIGlzIGFsbG93IFBDRSB0byBjb250cm9sIHRoZSBzZXF1ZW5jZSBv ZiBpbmNyZW1lbnRhbCBzeW5jLiwgdGhlIGF1dGhvcnMgZG8gc2VlIHRoZSB2YWx1ZS4gSG93ZXZl ciwgeW91IGNhbiBzZWUgZnJvbSB0aGUgZXhwbGFuYXRpb24gb2YgU2VjdGlvbiA1LCBzZXR0aW5n IHRoZSBUPTEgaXMgTk9UIGEgbWFuZGF0ZSBvcGVyYXRpb24gdG8gZW5hYmxlIGluY3JlbWVudGFs IHN5bmMuLCBidXQgYSBmZWF0dXJlIG9wdGljYWwgYW5kIG5vdCBjb3ZlcmVkIGJ5IFNlY3Rpb24g NC4gVGhlIGZpZ3VyZSBpcyBkcmF3biBhcyBzaG93biBiZWNhdXNlIHdlIGludGVuZHMgdG8gY2Fw dHVyZSBib3RoIGZlYXR1cmVzLiBEb2VzIHRoaXMgY2xhcmlmeSB5b3VyIGRvdWJ0Pw0KDQpbSm9u XSBJoa9tIHN0aWxsIHVuc3VyZSBob3cgdHJpZ2dlcmVkIHN5bmNocm9uaXphdGlvbnMgYXJlIHVz ZWQgYnkgc2VjdGlvbiA1LjIuICBIZXJlIGlzIHRoZSB0ZXh0IHRoYXQgaXMgY29uZnVzaW5nIG1l Og0KDQogICBBIHN0YXRlZnVsIFBDRSBNQVkgY2hvb3NlIHRvIGNvbnRyb2wgdGhlIExTUC1EQiBz eW5jaHJvbml6YXRpb24NCiAgIHByb2Nlc3MuICBUbyBhbGxvdyBQQ0UgdG8gZG8gc28sIFBDRVAg c3BlYWtlcnMgTVVTVCBzZXQgVCBiaXQgdG8gMSB0bw0KICAgaW5kaWNhdGUgdGhpcyAoYXMgZGVz Y3JpYmVkIGluIFNlY3Rpb24gNDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1taW5l aS1wY2Utc3RhdGVmdWwtc3luYy1vcHRpbWl6YXRpb25zLTAxI3NlY3Rpb24tND4pLiAgSWYgdGhl IExTUC1EQiBWZXJzaW9uIGlzDQogICBtaXMtbWF0Y2hlZCwgaXQgY2FuIHNlbmQgYSBQQ1VwZCBt ZXNzYWdlIHdpdGggUExTUC1JRCA9IDAgYW5kIFNZTkMgPQ0KICAgMSBpbiBvcmRlciB0byB0cmln Z2VyIHRoZSBMU1AtREIgc3luY2hyb25pemF0aW9uIHByb2Nlc3MuDQoNClRoZSBmaW5hbCBzZW50 ZW5jZSBzYXlzIHRoYXQgdGhlIFBDRSChsGNhbiBzZW5kIGEgUENVcGShsS4gIEl0IGlzIG5vdCBj bGVhciB1bmRlciB3aGF0IGNpcmN1bXN0YW5jZXMgdGhlIFBDQyBNVVNUIHdhaXQgZm9yIHRoZSBQ Q0UgdG8gdHJpZ2dlciB0aGUgaW5pdGlhbCBzeW5jaHJvbml6YXRpb24uICBQbGVhc2UgY291bGQg eW91IGNsYXJpZnk/DQpbWGlhbjJdOiBUaGUgbW90aXZhdGlvbiBiZWhpbmQgYWxsb3dpbmcgUENF IHRvIHRyaWdnZXIgaW5pdGlhbCBMU1AgcmUtc3luY2hyb25pemF0aW9uIHRvIGF2b2lkIG92ZXIg Zmxvb2RpbmcgdGhlIFBDRS4gSWYgdGhpcyBjYXBhYmlsaXR5IGlzIGVuYWJsZWQsIFBDQ3Mgd29u oa90IHN0YXJ0IHRoZSBzeW5jaHJvbml6YXRpb24gcHJvY2VzcyB1bnRpbCB0aGUgUENFIHNlbmRz IGEgUENVcGQuDQpEbyB5b3UgbWVhbiB0aGF0IHRoZSBQQ0UgTVVTVCB0cmlnZ2VyIHRoZSBpbml0 aWFsIHN5bmNocm9uaXphdGlvbiBhbnkgdGltZSB0aGUgUENDIGFuZCBQQ0UgaGF2ZSBib3RoIHNl dCB0aGUgVCBiaXQgaW4gdGhlaXIgT3BlbiBtZXNzYWdlcz8NCltYaWFuMl06IE5PLiBPbmx5IHdo ZW4gUENFIHdhbnRzIHRvIGhhdmUgdGhlIGNhcGFiaWxpdHkgdG8gdHJpZ2dlciB0aGUgdGltaW5n IG9mIHdoZW4gYSBQQ0Mgc2hvdWxkIHJlcG9ydCB0aGUgTFNQIHN0YXRlIGR1cmluZyBpbml0aWFs IHJlLXN5bmNocm9uaXphdGlvbi4gQW5kIGl0IGlzIHB1cmVseSBvcHRpb25hbC4NCkRvZXMgdGhh dCBhbHNvIGFwcGx5IGluIHNlY3Rpb24gND8gIE15IHVuZGVyc3RhbmRpbmcgZnJvbSBzZWN0aW9u IDQuMSBpcyB0aGF0IHRoaXMgbWVjaGFuaXNtIGlzIGludGVuZGVkIHRvIGFsbG93IHRoZSBQQ0Ug dG8gc2FuaXR5IGNoZWNrIHRoZSBMU1BEQiBhbmQgcmVjb3ZlciBmcm9tIGludGVybmFsIGVycm9y cyBhZnRlciB0aGUgaW5pdGlhbCBzZXNzaW9uIGlzIGVzdGFibGlzaGVkLCBub3QgdG8gdHJpZ2dl ciB0aGUgaW5pdGlhbCBzeW5jaHJvbml6YXRpb246DQpbWGlhbjJdOiBOby4gU2VjdGlvbiA0IGlu ZGVlZCBvbmx5IGRlc2NyaWJlcyB0aGUgZnVuY3Rpb24gYXMgeW91IHVuZGVyc3RhbmQgYW5kIHdy aXR0ZW4gYWJvdmUuIFNvLCB0aGUgcHVycG9zZSBvZiB0aGVzZSB0d28gU2VjdGlvbnMgKHNlY3Rp b24gNCBhbmQgU2VjdGlvbiA1LjIpIGlzIGRpZmZlcmVudCAob25lIGlzIHRvIHVzZSBpbiBzYW5p dHkgY2hlY2sgYWZ0ZXIgdGhlIGluaXRpYWwgc3luY2hyb25pemF0aW9uIGhhcyBiZWVuIGZpbmlz aGVkLCBhbmQgdGhlIG90aGVyIGlzIHVzZWQgZHVyaW5nIGluaXRpYWwgc3luY2hyb25pemF0aW9u KS4gQnV0IGZyb20gcHJvdG9jb2wgZXh0ZW5zaW9uIHBvaW50IG9mIHZpZXcsIFNlY3Rpb24gNSBk b2VzIG5vdCBhc2sgYW55IGV4dGVuc2lvbnMsIGJ1dCByZS11c2Ugd2hhdCBhbHJlYWR5IGRlZmlu ZWQgaW4gU2VjdGlvbiA0LjEuIEhvcGUgdGhpcyBjbGFyaWZpZXMuDQoNClJlZ2FyZHMsDQpYaWFu DQoNCiAgIFsuLi5dIGl0IGNhbiBiZSBiZW5lZmljaWFsIHRvIGJlIGFibGUgdG8gcmVzeW5jaHJv bml6ZSB0aGlzDQogICBzdGF0ZSBldmVuIGFmdGVyIHRoZSBzZXNzaW9uIGhhcyBiZWVuIGVzdGFi bGlzaGVkLiAgVGhlIFBDRSBtYXkgdXNlDQogICB0aGlzIGFwcHJvYWNoIHRvIGNvbnRpbnVvdXNs eSBzYW5pdHkgY2hlY2sgaXRzIHN0YXRlIGFnYWluc3QgdGhlDQogICBuZXR3b3JrLCBvciB0byBy ZWNvdmVyIGZyb20gZXJyb3IgY29uZGl0aW9ucyB3aXRob3V0IGhhdmluZyB0byB0ZWFyDQogICBk b3duIHNlc3Npb25zLg0KDQoNClJlZ2FyZHMsDQpYaWFuDQo= --_000_C636AF2FA540124E9B9ACB5A6BECCE6B3020CB84SZXEMA512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Jon,

 

         Glad to see the first= two points are now cleared.  Please see my explanation to the last po= int inline, marked with [Xian2]:

 

From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitc= h.com]
Sent: 2014=C4=EA2=D4=C226=C8= =D5 17:12
To: Zhangxian (Xian)
Cc: pce@ietf.org; draft-minei-pce-stateful-sync-optimizations@tools.= ietf.org
Subject: RE: Comments on draft-minei-pce-stateful-sync-optimizations= -01

 

Hi Xian= , please see [Jon] below...

&n= bsp;

From: Zhangxian (Xian) [mailto:zhang.xian@huawei.com]
Sent: 22 February 2014 07:33
To: Jonathan Hardwick
Cc: pce@ietf.org; draft-minei-pce-stateful-sync-optimizations@tools.= ietf.org
Subject: RE: Comments on draft-minei-pce-stateful-sync-optimizations= -01

 

Hi, Jon,

 

   Thank you very much for the constructive comments.&n= bsp; Please see my reply inline, marked with [Xian]:

 

From: Pce [mailto:p= ce-bounces@ietf.org] On Behalf Of Jonathan Hardwick
Sent: 2014=C4=EA2=D4=C215=C8= =D5 2:35
To: draft-minei-pce-stateful-sync-optimizations@tools.ietf.org
Cc: pce@ietf.org
Subject: [Pce] Comments on draft-minei-pce-stateful-sync-optimizatio= ns-01

 

Hi there

 

I have reviewed this draft =A8C= here are my comments.

 

Best regards<= /p>

Jon

 

Section 3.2

Figure 2, I think the =A1=B0syn= c done=A1=B1 PCRpt should have SYNC=3D0, not SYNC=3D1.

[Xian]: Indeed. Thank you for spotting this typo.

 

Section 5.2

   If a PCC has to force full LSP= DB

   synchronization due to reasons= including but not limited: (1) local

   policy configured at the PCC; = (2) no sufficient LSP state caches for

   incremental update, the PCC ca= n set the D flag to 0.

 

Perhaps I have misunderstood, b= ut I think case (2) above doesn=A1=AFt work.  The PCC does not know th= at it has =A1=B0no sufficient LSP state caches=A1=B1 until it receives the = OPEN from the PCE and sees what DBv the PCE has sent.  By then, the PCC has already sent its OPEN so it is too late to set D=3D0.&nb= sp; To cover case (2) the draft needs a mechanism for the PCC to change its= mind and tell the PCE that it is going to send a full snapshot, not a repl= ay of the missing database updates.  The simplest thing is probably for the PCC to bring the session down and then = bring it back up again with D=3D0.

 

[Xian]:  It actually depends, IMHO. If it is due to the 1st = reason listed above, then, it can decide before sending OPEN and set D=3D0.= The cases as a result of the 2nd reason might be more complicated. Your analysis would be one of the cases, in which a P= CC can detect the insufficient LSP state caches ONLY after it gets the DB v= ersion information from the other party. But if a PCC has no LSP state cach= es or incomplete (missing quite some LSP state or those of the DB version in between), I think it is possi= ble that it can decide without even checking the DBv from the other party. = Does this clarify?

 

To include the case you described, how about we update the text&n= bsp; as below?

 

OLD:

   If a PCC has to force full LSP DB<= /p>

   synchronization due to reasons including but not lim= ited: (1) local

   policy configured at the PCC; (2) no sufficient LSP = state caches for

   incremental update, the PCC can set the D flag to 0.=

 

[DD] NEW:

   If a PCC may have to force full LSP DB

   synchronization due to reasons including but not lim= ited: (1) local

   policy configured at the PCC; (2) no sufficient LSP = state caches for

   incremental update, the PCC can set the D flag to 0. Note a PC= C may have to bring

 down the current session and  force a full LSPDB syn= chronization with D flag set to

0 in the  subsequent open message.=

&n= bsp;

[Jon] L= ooks good to me.

&n= bsp;

Section 4 talks about the PCE h= aving to mark its LSP database as stale, and then remove any stale LSPs at = the end of the synchronization process.  I assume that this does not a= pply in section 5.  To avoid confusion, I think section 5 should state that the PCE does not mark its LSP database a= s stale if both it and the PCC have set D=3D1.

[Xian]:= Sure.  I think we have already explained in Section 5. The last sente= nce of the paragraph below Figure 7 says: =A1=B0Note that the PCE should no= t mark the existing LSPs as stale for incremental state synchronisation=A1=B1.

 

[Jon] A= pologies, I missed that.

&n= bsp;

In figure 7, I may have misunde= rstood section 4, but I don=A1=AFt think this is how the T bit is specified= .  I don=A1=AFt think T=3D1 forces the PCC to wait for a PCUpd before = sending the initial snapshot as you have shown.  I don=A1=AFt think this substantially changes anything about section 5, so I suggest re= moving the discussion of the T bit from section 5.

[Xian]=A3=BASection 4 describes how a PCE can force re-synchronization after the initial LSP-DB synchronization has been done.= Section 5 talks about an alternative method for the initial LSP-DB sync. (= i.e., incremental way).  The idea here is allow PCE to control the seq= uence of incremental sync., the authors do see the value. However, you can see from the explanation of Section 5, = setting the T=3D1 is NOT a mandate operation to enable incremental sync., b= ut a feature optical and not covered by Section 4. The figure is drawn as s= hown because we intends to capture both features. Does this clarify your doubt?

 

[Jon] I= =A1=AFm still unsure how triggered synchronizations are used by section 5.2= .  Here is the text that is confusing me:

&n= bsp;

   A stateful PCE MAY choose to c= ontrol the LSP-DB synchronization

   process.  To allow PCE to= do so, PCEP speakers MUST set T bit to 1 to

   indicate this (as described in Section 4).  If the LSP-DB Version is

   mis-matched, it can send a PCU= pd message with PLSP-ID =3D 0 and SYNC =3D

   1 in order to trigger the LSP-= DB synchronization process.

&n= bsp;

The fin= al sentence says that the PCE =A1=B0can send a PCUpd=A1=B1.  It is not= clear under what circumstances the PCC MUST wait for the PCE to trigger th= e initial synchronization.  Please could you clarify? 

[Xian2]: <= /span>The motiva= tion behind allowing PCE to trigger initial LSP re-synchronization to avoid= over flooding the PCE. If this capability is enabled, PCCs won=A1=AFt start the synchronization process until the PC= E sends a PCUpd.

Do you = mean that the PCE MUST trigger the initial synchronization any time the PCC= and PCE have both set the T bit in their Open messages? 

[Xian2]: NO. Only when PCE wants to have the capability to trigger t= he timing of when a PCC should report the LSP state during initial re-synch= ronization. And it is purely optional.

Does th= at also apply in section 4?  My understanding from section 4.1 is that= this mechanism is intended to allow the PCE to sanity check the LSPDB and = recover from internal errors after the initial session is established, not to trigger the initial synchronization:

[Xian2]: No. Section 4 indeed only describes the function as you und= erstand and written above. So, the purpose of these two Sections (section 4= and Section 5.2) is different (one is to use in sanity check after the initial synchronization has been finished= , and the other is used during initial synchronization). But from protocol = extension point of view, Section 5 does not ask any extensions, but re-use = what already defined in Section 4.1. Hope this clarifies.

 

Regards,

Xian

&n= bsp;

   [...] it can be beneficial to = be able to resynchronize this

   state even after the session h= as been established.  The PCE may use

   this approach to continuously = sanity check its state against the

   network, or to recover from er= ror conditions without having to tear

   down sessions.

&n= bsp;

 

Regards,

Xian

--_000_C636AF2FA540124E9B9ACB5A6BECCE6B3020CB84SZXEMA512MBSchi_-- From nobody Thu Feb 27 22:32:46 2014 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 A858F1A0411 for ; Thu, 27 Feb 2014 22:32:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 U21Oxd89Uol7 for ; Thu, 27 Feb 2014 22:32:40 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D2C7A1A02D3 for ; Thu, 27 Feb 2014 22:32:38 -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 BEB35953; Fri, 28 Feb 2014 06:32:35 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 28 Feb 2014 06:32:20 +0000 Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 28 Feb 2014 06:32:34 +0000 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.22]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Fri, 28 Feb 2014 14:32:32 +0800 From: "Zhangxian (Xian)" To: Cyril Margaria , Ramon Casellas Thread-Topic: [Pce] comments draft-ietf-pce-stateful-pce-08.txt Thread-Index: AQHPMcxNobG2doiZKUqv4mIrhOE3bJrGSUIAgAALHgCAAJidcIAAW6uAgAAIyYCAAJBYgIAAQfsAgAAijICAAfCqIA== Date: Fri, 28 Feb 2014 06:32:31 +0000 Message-ID: References: <23CE718903A838468A8B325B80962F9B75543CA4@szxeml556-mbs.china.huawei.com> <530EDDC0.8000206@cttc.es> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.104.209] Content-Type: multipart/alternative; boundary="_000_C636AF2FA540124E9B9ACB5A6BECCE6B3020CC0BSZXEMA512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pce/iwMDEhBR9yLBFeTTqWJbESTyFLs Cc: "pce@ietf.org" Subject: Re: [Pce] comments draft-ietf-pce-stateful-pce-08.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: Fri, 28 Feb 2014 06:32:43 -0000 --_000_C636AF2FA540124E9B9ACB5A6BECCE6B3020CC0BSZXEMA512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIEFsbCwNCg0KICAgICBJIGFsc28gc3VwcG9ydCBhZGRpbmcgdGhpcyBmdW5jdGlvbi4gSSBy ZW1lbWJlciBwcmV2aW91cyB2ZXJzaW9uIG9mIHRoaXMgZHJhZnQgKHY2KSBkb2VzIHN1cHBvcnQg dGhpcyAoc2VlOiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXBjZS1zdGF0 ZWZ1bC1wY2UtMDYjc2VjdGlvbi02LjQpLiBJdCB3b3VsZCBiZSBnb29kIHRvIGV4cGxhaW4gd2h5 IGl0IGlzIHJlbW92ZWQgaW4gdGhlIGN1cnJlbnQgdmVyc2lvbiBpZiBub3QgYmVmb3JlLiBBbHNv LCBob3cgdGhlIGZvbGxvd2luZyBzY2VuYXJpb3MgbWVudGlvbmVkIGJ5IEN5cmlsLCBSYW1vbiAm IERocnV2IGNvdWxkIGJlIGFkZHJlc3NlZCBpZiB2OCBpcyB1c2VkLiBUaGF0IHdvdWxkIGhlbHAg dG8gc2VlIGlmIHRoaXMgZnVuY3Rpb24gaXMgaW5kZWVkIHVzZWZ1bC4NCg0KUmVnYXJkcywNClhp YW4NCg0KRnJvbTogUGNlIFttYWlsdG86cGNlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBDeXJpbCBNYXJnYXJpYQ0KU2VudDogMjAxNMTqMtTCMjfI1SAxNjo0NA0KVG86IFJhbW9uIENh c2VsbGFzDQpDYzogcGNlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1BjZV0gY29tbWVudHMgZHJh ZnQtaWV0Zi1wY2Utc3RhdGVmdWwtcGNlLTA4LnR4dA0KDQpIaQ0KSSBhZ3JlZSB3aXRoIFJhbW9u IGFuZCBEcnV2Lg0KSW4gYWRkaXRpb24gdG8gdGhvc2UgdXNlIGNhc2UsIHRoZSBMU1Agb2JqZWN0 IGluIFBDUmVxL1BDUmVwIGlzIGFsc28gYXBwbGljYWJsZSBmb3Igbm9uLWRlbGVnYXRlZCBMU1Ag aW4gYW4gYWN0aXZlIHN0YXRlZnVsIFBDRSBjYXNlLg0KT25lIGV4YW1wbGUgY2FuIGJlIHRoZSBy ZXJvdXRpbmcgYWZ0ZXIgYSBmYWlsdXJlLCB0aGlzIG1heSBhZmZlY3QgZGVsZWdhdGVkIGFuZCBu b24gZGVsZWdhdGVkIExTUHMsIHRoZSBTdGF0ZWZ1bCBQQ0Ugd291bGQgYmUgYmVuZWZpdCBmcm9t IGtub3dpbmcgd2hpY2ggbm9uIGRlbGVnYXRlZCBMU1AgaXMgdG8gYmUgcmVyb3V0ZWQuDQoNCkJS LA0KQ3lyaWwuDQoNCk9uIDI3IEZlYnJ1YXJ5IDIwMTQgMDc6NDAsIFJhbW9uIENhc2VsbGFzIDxy YW1vbi5jYXNlbGxhc0BjdHRjLmVzPG1haWx0bzpyYW1vbi5jYXNlbGxhc0BjdHRjLmVzPj4gd3Jv dGU6DQpFbCAyNy8wMi8yMDE0IDM6NDMsIERocnV2IERob2R5IGVzY3JpYmmorjoNCg0KDQo+IFdo YXQgaXMgbm90IGF2YWlsYWJsZSB0b2RheSBpcyB0byBzZW5kIHRoZSBMU1Agb2JqZWN0IGluIHRo ZSBQQ1JlcSwNCkluYSBzaW5jZSB5b3UgYnJpbmcgdGhpcyB1cCwgSU1PIExTUCBvYmplY3QgaW4g UENSZXEgZm9yIHBhc3NpdmUgc3RhdGVmdWwgUENFIGNhbiBiZSB1c2VmdWwgaW4gY2FzZSBvZiBy ZS1vcHRpbWl6YXRpb24sIGV4Y2x1c2lvbiBldGMuDQpTb21lIGV4dGVuc2lvbnMgdG8gUENFUCBh cmUgbmVlZGVkIHRvIGRvIHRoYXQsIGJ1dCB0aGUgZmlyc3Qgc3RlcCB3b3VsZCBiZSB0byBpZGVu dGlmeSBhbiBMU1AgaW4gUENSZXEgbWVzc2FnZS4NCg0KRGhydXYsIEluYSwgYWxsDQoNClRMJkRS ICsxLiBKdXN0IGZ3aXcsIGluIG9uZSBvZiBvdXIgdXNlIGNhc2VzLCBhICJmcm9udC1lbmQiIHN0 YXRlZnVsIFBDRSBtYXkgZGVsZWdhdGUgYSBjb21wbGV4IChlLmcuIG9wdGljYWwpIGNvbXB1dGF0 aW9uL3JlLW9wdGltaXphdGlvbi9kZWZyYWdtZW50YXRpb24gdG8gYSAiYmFjay1lbmQiIFBDRSwg YW5kIGJvdGggdGhlIFRFRCBhbmQgTFNQREIgYXJlIHNoYXJlZCBiZXR3ZWVuIHRoZSBwb29sIG9m IFBDRXMuIEluIHByZXZpb3VzIHZlcnNpb25zIG9mIHRoZSBkcmFmdCwgd2UgdXNlZCB0aGUgTFNQ IG9iamVjdCB0aGF0IHdhcyBpbmNsdWRlZCB3aXRoaW4gYSBQQ0VQIHJlcXVlc3QuIFRoZXJlIHdh cyB0aGUgaXNzdWUgYWJvdXQgdGhlIHBsc3BpZCwgb3VyIGFwcHJvYWNoIHdhcyBiYXNlZCBvbiB1 c2luZyBhIGR1bW15IHBsc3BpZCBhbmQgcmVmZXIgdG8gdGhlIExTUCBlbnRyeSBpbiB0aGUgZGF0 YWJhc2UgYnkgaXRzIHN5bWJvbGljIG5hbWUgKHByaW1hcnkga2V5KS4NCg0KSW4gc2hvcnQsIHdl IGRpZCBmaW5kIGl0IHVzZWZ1bCB0byBiZSBhYmxlIHRvICJyZWZlciIgdG8gYW4gTFNQIHdpdGhp biB0aGUgZGIgd2hlbiByZXF1ZXN0aW5nIGNvbXB1dGF0aW9ucyBiZXR3ZWVuIGNvbGxhYm9yYXRp bmcgUENFcy4gSW5kZWVkLCBtdWNoIGxpa2UgRGhydXYncywgZm9yIHRoaXMgc3BlY2lmaWMgdXNl IGNhc2UsIHRoZSBiYWNrZW5kIGlzIHN0YXRlZnVsIGJ1dCBwYXNzaXZlLiBUaGUgYWx0ZXJuYXRp dmUgaXMgdG8gcHJvdmlkZSB0aGUgUlJPLCBidXQgdGhlIGRiIGNvbnRhaW5zIG90aGVyIHJlbGV2 YW50IGluZm9ybWF0aW9uIHRoYXQgY2Fubm90IGJlIGNvbnZleWVkIGluIGEgInJmYzU0NDAiIHJl LW9wdGltaXphdGlvbg0KDQpUaGFua3MNClJhbW9uDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpQY2UgbWFpbGluZyBsaXN0DQpQY2VAaWV0Zi5vcmc8 bWFpbHRvOlBjZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcGNlDQoNCg== --_000_C636AF2FA540124E9B9ACB5A6BECCE6B3020CC0BSZXEMA512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, All,

 = ;

 &nbs= p;   I also support adding this function. I remember previous ver= sion of this draft (v6) does support this (see: http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-06#section-6.= 4). It would be good to explain why it is removed in the current versio= n if not before. Also, how the following scenarios mentioned by Cyril, Ramon & Dhruv could be addressed if v8 i= s used. That would help to see if this function is indeed useful.  

 = ;

Regards,

Xian<= /o:p>

 = ;

From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Cyril Margaria
Sent: 2014=C4=EA2=D4=C227=C8= =D5 16:44
To: Ramon Casellas
Cc: pce@ietf.org
Subject: Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt<= /o:p>

 

= Hi

I agree with Ramon and Druv.

In addition to those use case, = the LSP object in PCReq/PCRep is also applicable for non-delegated LSP in a= n active stateful PCE case.

= One example can be the rerouting after a failure, this may affect delegated= and non delegated LSPs, the Stateful PCE would be benefit from knowing whi= ch non delegated LSP is to be rerouted.

BR,

Cyril.

=  

On 27 February 2014 07:40, Ramo= n Casellas <= ramon.casellas@cttc.es> wrote:

El 27/02/2014 3:43, Dhruv Dhody= escribi=A8=AE:

 

 

> What is not available today is to send the LSP object in the PCR= eq,

Ina since you bring this up, IM= O LSP object in PCReq for passive stateful PCE can be useful in case of re-= optimization, exclusion etc. 

Some extensions to PCEP are nee= ded to do that, but the first step would be to identify an LSP in PCReq mes= sage. 

 

Dhruv, Ina, all

TL&DR +1. Just fwiw, in one of our use cases, a "front-end&quo= t; stateful PCE may delegate a complex (e.g. optical) computation/re-optimi= zation/defragmentation to a "back-end" PCE, and both the TED and = LSPDB are shared between the pool of PCEs. In previous versions of the draft, we used the LSP object that was included within a PCEP reque= st. There was the issue about the plspid, our approach was based on using a= dummy plspid and refer to the LSP entry in the database by its symbolic na= me (primary key).

In short, we did find it useful to be able to "refer" to an LSP w= ithin the db when requesting computations between collaborating PCEs. Indee= d, much like Dhruv's, for this specific use case, the backend is stateful b= ut passive. The alternative is to provide the RRO, but the db contains other relevant information that cannot be con= veyed in a "rfc5440" re-optimization

Thanks
Ramon

=
_______________________________________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce

 

--_000_C636AF2FA540124E9B9ACB5A6BECCE6B3020CC0BSZXEMA512MBSchi_-- From nobody Fri Feb 28 01:06:23 2014 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 8D2951A077E for ; Fri, 28 Feb 2014 01:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.269 X-Spam-Level: * X-Spam-Status: No, score=1.269 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.547, 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 8Fv-Q0t0bHyw for ; Fri, 28 Feb 2014 01:06:20 -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 311CB1A0184 for ; Fri, 28 Feb 2014 01:06:20 -0800 (PST) Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B762BE3011C for ; Fri, 28 Feb 2014 10:11:14 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.orange.com (Postfix) with ESMTP id B25BDE3011B for ; Fri, 28 Feb 2014 10:11:14 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 28 Feb 2014 10:06:17 +0100 Received: from [10.193.71.94] ([10.193.71.94]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 28 Feb 2014 10:06:17 +0100 Message-ID: <53105188.70201@orange.com> Date: Fri, 28 Feb 2014 10:06:16 +0100 From: Julien Meuric Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "pce@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Feb 2014 09:06:17.0491 (UTC) FILETIME=[56D07630:01CF3464] Archived-At: http://mailarchive.ietf.org/arch/msg/pce/1giAMobRvCIJ_gCin-R0C_0BR0U Subject: [Pce] Slides from PCE Presenters X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Julien Meuric , 'JP Vasseur' , Daniel King List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 09:06:21 -0000 Hi all. Please note that the PCE WG is meeting on Tuesday morning, i.e. rather early in the week. We have a tight agenda. Presenters, if you do not want to loose the slot(s) you may have (https://datatracker.ietf.org/meeting/89/agenda/pce), please send your slides to the chairs _and_ secretary by Sunday 2nd. Thanks, JP & Julien From nobody Fri Feb 28 01:24:47 2014 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 659A51A0184 for ; Fri, 28 Feb 2014 01:24:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 nW3vAPQBNpft for ; Fri, 28 Feb 2014 01:24:42 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8391A0102 for ; Fri, 28 Feb 2014 01:24:41 -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 BEB50254; Fri, 28 Feb 2014 09:24:38 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 28 Feb 2014 09:24:20 +0000 Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 28 Feb 2014 09:24:36 +0000 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.22]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Fri, 28 Feb 2014 17:24:26 +0800 From: "Zhangxian (Xian)" To: "pce@ietf.org" Thread-Topic: The status of two WG drafts not presented during IETF89 Thread-Index: Ac80Zt4/LIbGokqCQ3WSw80bRurzSQ== Date: Fri, 28 Feb 2014 09:24:25 +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: multipart/alternative; boundary="_000_C636AF2FA540124E9B9ACB5A6BECCE6B3020CD5ESZXEMA512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pce/Us5ztd7Ezsn_oWBNMSuOLh0NSGI Cc: "draft-ietf-pce-pcep-stateful-pce-gmpls@tools.ietf.org" , "draft-ietf-pce-stateful-pce-app@tools.ietf.org" Subject: [Pce] The status of two WG drafts not presented during IETF89 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, 28 Feb 2014 09:24:44 -0000 --_000_C636AF2FA540124E9B9ACB5A6BECCE6B3020CD5ESZXEMA512MBSchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Dear all, The following two WG drafts won't be presented during IETF89, but we woul= d like to let everyone know their status. As always, we encourage more revi= ew/comments to these two drafts in order to move them forward. 1) Draft-ietf-pce-stateful-pce-app Currently, we are working on a update to address the following issues: =FC The comments received among co-authors, mostly editorial; =FC A use case to be added and wait for text to be provided; A new version is expected to come out before next IETF. So, please review i= f you would like to see more use cases added or other comments on descripti= on of existing use cases. 2) Draft-ietf-pce-pcep-stateful-gmpls Just one comment received recently (i.e., whether PCRpt needs to include object), we will work on that to see if it is a generic issue or= particular to GMPLS. Probably, this draft is subject to change as a result= of the updates made to draft-ietf-pce-gmpls-pcep-extensions. Please have a review of this draft to see if you have comments/suggestions. Best regards, Xian ( on behalf of all authors/contributors) --_000_C636AF2FA540124E9B9ACB5A6BECCE6B3020CD5ESZXEMA512MBSchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi, Dear all,

 

  The following two WG dra= fts won’t be presented during IETF89, but we would like to let everyo= ne know their status. As always, we encourage more review/comments to these= two drafts in order to move them forward.

 

1= )   &= nbsp;  Draft-ietf-pce-stateful= -pce-app

= Currently, we are working on a update to address the f= ollowing issues:

<= span style=3D"mso-list:Ignore">=FC  The comments received a= mong co-authors, mostly editorial;

<= span style=3D"mso-list:Ignore">=FC  A use case to be added = and wait for text to be provided;

 

A = new version is expected to come out before next IETF. So, please review if = you would like to see more use cases added or other comments on description= of existing use cases.

=  

2= )   &= nbsp;  Draft-ietf-pce-pcep-sta= teful-gmpls

= Just one comment received recently (i.e., whether PCRp= t needs to include <END-POINTS> object), we will work on that to see = if it is a generic issue or particular to GMPLS. Probably, this draft is subject to change as a result of the updates made = to draft-ietf-pce-gmpls-pcep-extensions= .

=  

= Please have a review of this draft to see if you have = comments/suggestions.

 

Best regards,=

Xian ( on behalf of all authors= /contributors)

--_000_C636AF2FA540124E9B9ACB5A6BECCE6B3020CD5ESZXEMA512MBSchi_-- From nobody Fri Feb 28 17:05:18 2014 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 35CCE1A032A for ; Fri, 28 Feb 2014 17:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.325 X-Spam-Level: X-Spam-Status: No, score=-1.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RP_MATCHES_RCVD=-0.547, SPF_PASS=-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 0wxYvSgc6vu8 for ; Fri, 28 Feb 2014 17:05:04 -0800 (PST) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 83B5F1A01CB for ; Fri, 28 Feb 2014 17:05:04 -0800 (PST) Received: by mail-ob0-f176.google.com with SMTP id wp18so3063767obc.35 for ; Fri, 28 Feb 2014 17:05:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zkwCkuA5zcDbFpFSXpwTwX6aV7/VRu9twztnC7tMSyQ=; b=H5pnNML15FRzRv94EOLB6n6e05VgXACFkl4zn/2PXBHDOasCF8ZWbmkxhEyw3P3yOm VWkyhHbS0jtQ5XVybglp5Uh6Nwq2JhS7qL7Xmo0/28SDFGgHBQxCLtQX/RPABM6fIXZs nOeGT1q+9lgu2M2UuHccJvqvSKO2yh9Hn2qAtilD+giGMGfCqZE0DlNEbKd/+sF5XqcB EFrXBN+hWnbiYd6TJnOCrksbA+GPfaEEb5CUj0EoQS1Jzel/RUa2PvG35ftF4Qrm+z/p Hgu6seiobQ9PTRuph0/rpC6gFUUBzzAiz2U/kvJ5Cqm4jzmQD2l8uwwxzvX5t7hHNuYj G8JA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zkwCkuA5zcDbFpFSXpwTwX6aV7/VRu9twztnC7tMSyQ=; b=Frwaft842TalB3XcfEG+dThm89vaEUXblkrW+sqjoIjetoXSKa2B5pHVSvguOnuZ/8 k4eRVbzabvYYy9l7OhVtqmO8tl3X9A2PAh1rLA59Jo7ar3WRLBvBrNgza9+rFB+9v2ts zLqmVXTsqW6jFTjc8xKi5Gd+yY5ieNKuRqbB+ol3ndZGEsqRwjBY9ghLDqPqAuMAMqJ2 EMOmF954kRQucv5lP/+cW6lL4WFtwwbQBVqZPMMpCouwuw4kYmRi4p4mPNsKaAv5RMPI oYSG93fywvdSQ3Lh/2gFV3ArQd1uQYFlerx9utPEIdrLUhSR6gZrMB4Cgs17ZgUkEQ2N 96Pw== X-Gm-Message-State: ALoCoQmVCQ2wC8PwB/UfV8IvDj4qRPcrnNk1l0Uj4zRdJ9hFuY6duaTLkMloHrIDwS/pkz1hxYER1ujHLJXGjB3gyu1ilxahPhIYKqagzitorf/+63oL+j4nY7l5xNh0a5HSNuBiuui5v2WOmqjyU+pCtCBiIx2FrIb1az9tNxgRPSSGDrmQQeOj+nwGBQcXPQ77wD54VjMa MIME-Version: 1.0 X-Received: by 10.182.53.72 with SMTP id z8mr16650382obo.36.1393635902233; Fri, 28 Feb 2014 17:05:02 -0800 (PST) Received: by 10.182.80.106 with HTTP; Fri, 28 Feb 2014 17:05:02 -0800 (PST) In-Reply-To: References: <23CE718903A838468A8B325B80962F9B75543CA4@szxeml556-mbs.china.huawei.com> <530EDDC0.8000206@cttc.es> Date: Fri, 28 Feb 2014 17:05:02 -0800 Message-ID: From: Ina Minei To: "Zhangxian (Xian)" Content-Type: multipart/alternative; boundary=f46d0447f0eee6364104f381245b Archived-At: http://mailarchive.ietf.org/arch/msg/pce/2xQywdcigJFS4yVkfkpnC0NvwsE Cc: "pce@ietf.org" , Cyril Margaria Subject: Re: [Pce] comments draft-ietf-pce-stateful-pce-08.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: Sat, 01 Mar 2014 01:05:06 -0000 --f46d0447f0eee6364104f381245b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable All, To Xian's question, as we explained in the wg meeting, the LSP object in PCReq and PCRep was removed because: a) there was no further mention anywhere in the document on the use in those messages, or of the LSP object in those messages, or of the values of its fields (as can be seen from this thread, different people used them differently). b) no use cases were specified in the applicability document for this use. I think specifying the use cases and the accompanying operation would make for a very good separate document. Ina On Thu, Feb 27, 2014 at 10:32 PM, Zhangxian (Xian) w= rote: > Hi, All, > > > > I also support adding this function. I remember previous version of > this draft (v6) does support this (see: > http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-06#section-6.4). > It would be good to explain why it is removed in the current version if n= ot > before. Also, how the following scenarios mentioned by Cyril, Ramon & Dhr= uv > could be addressed if v8 is used. That would help to see if this function > is indeed useful. > > > > Regards, > > Xian > > > > *From:* Pce [mailto:pce-bounces@ietf.org] *On Behalf Of *Cyril Margaria > *Sent:* 2014=E5=B9=B42=E6=9C=8827=E6=97=A5 16:44 > *To:* Ramon Casellas > *Cc:* pce@ietf.org > > *Subject:* Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt > > > > Hi > > I agree with Ramon and Druv. > > In addition to those use case, the LSP object in PCReq/PCRep is also > applicable for non-delegated LSP in an active stateful PCE case. > > One example can be the rerouting after a failure, this may affect > delegated and non delegated LSPs, the Stateful PCE would be benefit from > knowing which non delegated LSP is to be rerouted. > > BR, > > Cyril. > > > > On 27 February 2014 07:40, Ramon Casellas wrote: > > El 27/02/2014 3:43, Dhruv Dhody escribi=C3=B3: > > > > > > > What is not available today is to send the LSP object in the PCReq, > > Ina since you bring this up, IMO LSP object in PCReq for passive stateful > PCE can be useful in case of re-optimization, exclusion etc. > > Some extensions to PCEP are needed to do that, but the first step would b= e > to identify an LSP in PCReq message. > > > > Dhruv, Ina, all > > TL&DR +1. Just fwiw, in one of our use cases, a "front-end" stateful PCE > may delegate a complex (e.g. optical) > computation/re-optimization/defragmentation to a "back-end" PCE, and both > the TED and LSPDB are shared between the pool of PCEs. In previous versio= ns > of the draft, we used the LSP object that was included within a PCEP > request. There was the issue about the plspid, our approach was based on > using a dummy plspid and refer to the LSP entry in the database by its > symbolic name (primary key). > > In short, we did find it useful to be able to "refer" to an LSP within th= e > db when requesting computations between collaborating PCEs. Indeed, much > like Dhruv's, for this specific use case, the backend is stateful but > passive. The alternative is to provide the RRO, but the db contains other > relevant information that cannot be conveyed in a "rfc5440" re-optimizati= on > > Thanks > Ramon > > > _______________________________________________ > 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 > > --f46d0447f0eee6364104f381245b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,=C2=A0

To Xian's question, as we explained in the wg meeti= ng, the LSP object in PCReq and PCRep was removed because:
a) the= re was no further mention anywhere in the document on the use in those mess= ages, or of the LSP object in those messages, or of the values of its field= s (as can be seen from this thread, different people used them differently)= .
b) no use cases were specified in the applicability document for this = use.=C2=A0

I think specifying the use cases and th= e accompanying operation would make for a very good separate document.=C2= =A0

Ina=C2=A0




On Thu, Feb 27, 2= 014 at 10:32 PM, Zhangxian (Xian) <zhang.xian@huawei.com> wrote:

Hi, All,

=C2= =A0

=C2=A0=C2= =A0=C2=A0=C2=A0 I also support adding this function. I remember previous ve= rsion of this draft (v6) does support this (see: http://tools.ietf.org/html/draft-ietf-pce-stateful= -pce-06#section-6.4). It would be good to explain why it is removed in = the current version if not before. Also, how the following scenarios mentioned by Cyril, Ramon & Dhruv could be addressed if v8 i= s used. That would help to see if this function is indeed useful. =C2=A0=

=C2= =A0

Regards,

Xian

=C2= =A0

From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Cyril Margaria
Sent: 2014=E5=B9=B42=E6=9C=8827=E6=97=A5 16:44
To: Ramon Casellas
Cc: pce@ietf.org


Subject: Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt

=C2=A0

= Hi

I agree with Ramon and Druv.=

In addition to those use case, = the LSP object in PCReq/PCRep is also applicable for non-delegated LSP in a= n active stateful PCE case.

= One example can be the rerouting after a failure, this may affect delegated= and non delegated LSPs, the Stateful PCE would be benefit from knowing whi= ch non delegated LSP is to be rerouted.

BR,

Cyril.

= =C2=A0

On 27 February 2014 07:40, Ramo= n Casellas <= ramon.casellas@cttc.es> wrote:

El 27/02/2014 3:43, Dhruv Dhody= escribi=C3=B3:

=C2=A0

=C2=A0

>=C2=A0What is not available today is to send the LSP object in the PCR= eq,

Ina since you bring this up, IM= O LSP object in PCReq for passive stateful PCE can be useful in case of re-= optimization, exclusion etc.=C2=A0

Some extensions to PCEP are nee= ded to do that, but the first step would be to identify an LSP in PCReq mes= sage.=C2=A0

=C2=A0

Dhruv, Ina, all

TL&DR +1. Just fwiw, in one of our use cases, a "front-end" s= tateful PCE may delegate a complex (e.g. optical) computation/re-optimizati= on/defragmentation to a "back-end" PCE, and both the TED and LSPD= B are shared between the pool of PCEs. In previous versions of the draft, we used the LSP object that was included within a PCEP reque= st. There was the issue about the plspid, our approach was based on using a= dummy plspid and refer to the LSP entry in the database by its symbolic na= me (primary key).

In short, we did find it useful to be able to "refer" to an LSP w= ithin the db when requesting computations between collaborating PCEs. Indee= d, much like Dhruv's, for this specific use case, the backend is statef= ul but passive. The alternative is to provide the RRO, but the db contains other relevant information that cannot be con= veyed in a "rfc5440" re-optimization

Thanks
Ramon

=
_______________________________________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce

=C2=A0


_______________________________________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce


--f46d0447f0eee6364104f381245b--