From nobody Mon May 1 06:08:37 2017 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603DC129B2C for ; Mon, 1 May 2017 06:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=danielking-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mcWiB-QOo6P for ; Mon, 1 May 2017 06:08:33 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CF43126D05 for ; Mon, 1 May 2017 06:05:48 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id e64so37207003pfd.1 for ; Mon, 01 May 2017 06:05:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielking-net.20150623.gappssmtp.com; s=20150623; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=xbw2UrGU9BbJs34ws00HVFO7PzpXxPPae9FFwdZG6uk=; b=Q04zcbYeoUDECRk1hr6MMaZGZijPMyrrLgQeQtBOcCPtr6MAQA5VkAIqb0GS44Htde SpZzRQlGL/bpEEA8KjsKpPsWTZtq700gX41jSN4wYm4wsdanOJmEA6Cpv9nDI/MQHWGd 5pGjpbSuDFbHsTwUb4zn4bgNz4OVSVK5920F2RkVXgMvqV/nTuAc73wjlCbh6g84dOas UPuO+5evzdl17IHfXubzx9ZijNvTFc2+4GgqIPKtPbsZ1Spva3ZZVe+RdNrYxSUjsefj 3sb6vtCiEfVv23BLon51HS2nFQgKxR7/8BqpbRzkn64gNOMSfaxSkH0WV4J5hLxeSZPa aX/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=xbw2UrGU9BbJs34ws00HVFO7PzpXxPPae9FFwdZG6uk=; b=sFo2lsh8MKGKjrNoRCOJA8L6jgGnABeL9RDuVZLucOkQY2SnyOe1/Lhw2NYZufvjvc YVIaxL923PT8PazLt/QD2cyWumqHI14RSJPhpTWrxg7dpGJZy6o9WpISBs3Ow+DwSy/3 tyeHGDu5N0p+ET19VFC+oDhi+4BhtkudCahR1vHDVEJ3gswWw/aN5F3lYd+8R2f4hsTr SiMbiXEjgyjrLYDW7WjDmpLwj34dXM/c/p7AT2VAcnq4WEsuBs1RsMPJaEKqxsIXA2e6 CxHnpuXpKRjFIBa6fDn/rFnJz8gWown3zFIDXAjQyu8JeQxj7f3Y4meeehvQQBWA92cl TQ8w== X-Gm-Message-State: AN3rC/4krKar8f/kKeUuvC3AMWppkuWYBQM1RD0N3pLX25zWG4Q3ysbT 6UMAk8Ij+ZnfaT+YNVQ= X-Received: by 10.84.174.197 with SMTP id r63mr33926893plb.67.1493643947361; Mon, 01 May 2017 06:05:47 -0700 (PDT) Received: from INARA (e2.27.caa1.ip4.static.sl-reverse.com. [161.202.39.226]) by smtp.gmail.com with ESMTPSA id k196sm24036142pgc.0.2017.05.01.06.05.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 May 2017 06:05:46 -0700 (PDT) Sender: Daniel King X-Google-Original-Sender: "Daniel King" From: To: "'Dhruv Dhody'" , "'Jonathan Hardwick'" , Cc: References: <23CE718903A838468A8B325B80962F9B8CACDD44@blreml501-mbb> In-Reply-To: <23CE718903A838468A8B325B80962F9B8CACDD44@blreml501-mbb> Date: Mon, 1 May 2017 21:05:31 +0800 Message-ID: <00e801d2c27b$a8252be0$f86f83a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQI14FHoQspWQLTjNDuhXmbjJOhz2wG9wTukoQtILhA= Content-Language: en-gb Archived-At: Subject: Re: [Pce] IPR on draft-ietf-pce-rfc6006bis X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 13:08:35 -0000 Hi Chairs, Yes, I am also aware of IPR. This has been specifically disclosed and highlighted previously. Thanks, Dan. -----Original Message----- From: Dhruv Dhody [mailto:dhruv.dhody@huawei.com] Sent: 24 April 2017 23:38 To: Jonathan Hardwick ; draft-ietf-pce-rfc6006bis@ietf.org Cc: pce@ietf.org Subject: RE: IPR on draft-ietf-pce-rfc6006bis Hi, Yes, I am aware of IPR and has been disclosed and updated in the IPR system= From nobody Mon May 1 21:26:37 2017 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29829129601; Mon, 1 May 2017 21:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAYAYDWc6WGr; Mon, 1 May 2017 21:26:32 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 257BE128A32; Mon, 1 May 2017 21:24:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DMC14262; Tue, 02 May 2017 04:24:10 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 2 May 2017 05:24:09 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.200]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Tue, 2 May 2017 12:23:57 +0800 From: Sureshbr To: "Zhangxian (Xian)" , Jonathan Hardwick , "pce@ietf.org" CC: "draft-dhody-pce-applicability-actn@ietf.org" , "pce-chairs@ietf.org" Thread-Topic: Poll for adoption: draft-dhody-pce-applicability-actn-02 Thread-Index: AdK93+3TJZfELqyvTWC3nigRVLBVewASQ+aAAAdml8A= Date: Tue, 2 May 2017 04:23:56 +0000 Message-ID: <14A81F29DC91904A8FBB7B3BE4CFF64E702F65CC@NKGEML515-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.244.231] Content-Type: multipart/alternative; boundary="_000_14A81F29DC91904A8FBB7B3BE4CFF64E702F65CCNKGEML515MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.590809EB.0122, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.200, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c1805f8b8363c3b98e2eb3f1f0289c1f Archived-At: Subject: Re: [Pce] Poll for adoption: draft-dhody-pce-applicability-actn-02 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 04:26:35 -0000 --_000_14A81F29DC91904A8FBB7B3BE4CFF64E702F65CCNKGEML515MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U3VwcG9ydC4NCg0KRnJvbTogUGNlIFttYWlsdG86cGNlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBaaGFuZ3hpYW4gKFhpYW4pDQpTZW50OiAyNiBBcHJpbCAyMDE3IDA5OjA0DQpUbzog Sm9uYXRoYW4gSGFyZHdpY2s7IHBjZUBpZXRmLm9yZw0KQ2M6IGRyYWZ0LWRob2R5LXBjZS1hcHBs aWNhYmlsaXR5LWFjdG5AaWV0Zi5vcmc7IHBjZS1jaGFpcnNAaWV0Zi5vcmcNClN1YmplY3Q6IFtQ Y2VdILTwuLQ6IFBvbGwgZm9yIGFkb3B0aW9uOiBkcmFmdC1kaG9keS1wY2UtYXBwbGljYWJpbGl0 eS1hY3RuLTAyDQoNCnllcy9zdXBwb3J0Lg0KDQpSZWdhcmRzLA0KWGlhbg0KDQq3orz+yMs6IFBj ZSBbbWFpbHRvOnBjZS1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEpvbmF0aGFuIEhhcmR3aWNrDQq3 osvNyrG85DogMjAxN8TqNNTCMjbI1SAwOjI2DQrK1bz+yMs6IHBjZUBpZXRmLm9yZzxtYWlsdG86 cGNlQGlldGYub3JnPg0Ks63LzTogZHJhZnQtZGhvZHktcGNlLWFwcGxpY2FiaWxpdHktYWN0bkBp ZXRmLm9yZzxtYWlsdG86ZHJhZnQtZGhvZHktcGNlLWFwcGxpY2FiaWxpdHktYWN0bkBpZXRmLm9y Zz47IHBjZS1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOnBjZS1jaGFpcnNAaWV0Zi5vcmc+DQrW98zi OiBbUGNlXSBQb2xsIGZvciBhZG9wdGlvbjogZHJhZnQtZGhvZHktcGNlLWFwcGxpY2FiaWxpdHkt YWN0bi0wMg0KDQpBbGwsDQoNClRoaXMgaXMgdGhlIHN0YXJ0IG9mIGEgdHdvIHdlZWsgcG9sbCBv biBtYWtpbmcgZHJhZnQtZGhvZHktcGNlLWFwcGxpY2FiaWxpdHktYWN0bi0wMiBhIFBDRSB3b3Jr aW5nIGdyb3VwIGRvY3VtZW50Lg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtZGhvZHktcGNlLWFwcGxpY2FiaWxpdHktYWN0bi8NCg0KDQpQbGVhc2UgcmV2aWV3IHRoZSBk cmFmdCBhbmQgc2VuZCBhbiBlbWFpbCB0byB0aGUgbGlzdCBpbmRpY2F0aW5nIKGweWVzL3N1cHBv cnShsSBvciChsG5vL2RvIG5vdCBzdXBwb3J0obEuICBJZiBpbmRpY2F0aW5nIG5vLCBwbGVhc2Ug c3RhdGUgeW91ciByZWFzb25zLiAgSWYgeWVzLCBwbGVhc2UgYWxzbyBmZWVsIGZyZWUgdG8gcHJv dmlkZSBjb21tZW50cyB5b3UnZCBsaWtlIHRvIHNlZSBhZGRyZXNzZWQgb25jZSB0aGUgZG9jdW1l bnQgaXMgYSBXRyBkb2N1bWVudC4NCg0KDQoNClRoZSBwb2xsIGVuZHMgb24gVHVlc2RheSwgTWF5 IDkuDQoNCg0KDQpNYW55IHRoYW5rcywNCkpvbg0KDQoNCg== --_000_14A81F29DC91904A8FBB7B3BE4CFF64E702F65CCNKGEML515MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Support.

 

From: Pce [mai= lto:pce-bounces@ietf.org] On Behalf Of Zhangxian (Xian)
Sent: 26 April 2017 09:04
To: Jonathan Hardwick; pce@ietf.org
Cc: draft-dhody-pce-applicability-actn@ietf.org; pce-chairs@ietf.org=
Subject: [Pce] =B4=F0=B8=B4: Poll for adopti= on: draft-dhody-pce-applicability-actn-02

 

yes/support.

 

Regards,

Xian

=  

=B7=A2=BC=FE=C8=CB: Pce [mailto:pce-bounces@ietf.org] =B4=FA=B1=ED Jonathan Hardwick
=B7=A2=CB=CD=CA=B1=BC=E4: 2017=C4=EA4=D4=C226=C8=D5 0:26
=CA=D5=BC=FE=C8=CB: pce@ietf.org
=B3=AD=CB=CD: draft-dhody-pce-applicability-actn@ietf.org; pce-chairs@ietf.org
=D6=F7=CC=E2: [Pce] Poll for adoption: d= raft-dhody-pce-applicability-actn-02

 

All,

 

This is the start of a two week= poll on making draft-dhody-pce-applicability-actn-02 a PCE working group d= ocument.

https://datatracker.ietf.= org/doc/draft-dhody-pce-applicability-actn/

 

Please review the draft and = send an email to the list indicating =A1=B0yes/support=A1=B1 or =A1=B0no/do= not support=A1=B1.  If indicating no, please state your reasons. = ; If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document.

 

The poll ends on Tuesday, Ma= y 9.

 

Many thanks,

Jon

 

 

--_000_14A81F29DC91904A8FBB7B3BE4CFF64E702F65CCNKGEML515MBSchi_-- From nobody Mon May 1 22:41:31 2017 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3B7129AFA; Mon, 1 May 2017 22:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KE8zuOHSpu9p; Mon, 1 May 2017 22:41:27 -0700 (PDT) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E53911293DB; Mon, 1 May 2017 22:39:10 -0700 (PDT) Received: by mail-pg0-x241.google.com with SMTP id s62so7617517pgc.0; Mon, 01 May 2017 22:39:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :mime-version; bh=z4ZrbAwpeYtvyMDgRUkox2+N90dUv1pMiXu1b9MCclI=; b=lVdkxkN6ab9pCHryj7lgp2jUUTikVzeTJg8FP7zOw3Imyn08v5QRZSYkYv+wzkJKGM T7IxhgCt3pLBf4iQqCOwsLXSGxcZE+JR9CCDK0+kZMYuN5hMcEg/VIa276U5WDZbAjDy SjbKA3rbRKqFLpnU8bz1lGnXnQe7tlsLkKv+ChZykrW3sn2k+7UymkBaD0g+Zg5PrIlJ BCvNvcDyDmOXbf/WrU/jQLX9RkL6B/xERgHzdKy02vSaZ/mskcPnH+rDmorllvFVwUCy ZWHLQCHzc8liS/a9Dci9EXDUSeiYbCqMZfG5RyL4inqV3OmAw7v3XF65oplQePK1b843 kZNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:mime-version; bh=z4ZrbAwpeYtvyMDgRUkox2+N90dUv1pMiXu1b9MCclI=; b=YTwAJHBR6vOqDlmeG92tOHRFRgd3a8zLkrBByk+ku2x2Jcdh3ggcIva9GLOIPW93eG BGxFels45okdFSAcCJyuMWM+28BamwGZcoUpUzh8fj0/hnqTlfWzogNL6L6keSQWY9Km iksWghrdUmmkg5eqnP6cA+Xl/+M04P+5vVYf0qls0D4GjZg4vvk4Jx6i8h1/RK54fB0j oWFGwE2tnEKbegsekaXasuwFYcJfpc/aur+6K3jRa91nq7lv9ya27aQMUojNLNy0oJP6 22kf0BLrrROuiHFsonz2Q4iGFoa0JZ+bLL7llhGLfiTTRi89pwfAGeQrxeZw5fMsMzqi VywA== X-Gm-Message-State: AN3rC/4kYGZZikllfbcYEUoBixlEwnjWxgH/FAu8qtRvROuOOioRwDT4 F8yjNzNOeC6BSA== X-Received: by 10.99.67.133 with SMTP id q127mr30801846pga.156.1493703550548; Mon, 01 May 2017 22:39:10 -0700 (PDT) Received: from [192.168.1.2] ([76.126.247.72]) by smtp.gmail.com with ESMTPSA id i15sm33898703pfj.51.2017.05.01.22.39.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 May 2017 22:39:09 -0700 (PDT) User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Mon, 01 May 2017 22:39:08 -0700 From: Jeff Tantsura To: Sureshbr , "Zhangxian (Xian)" , Jonathan Hardwick , "pce@ietf.org" CC: "draft-dhody-pce-applicability-actn@ietf.org" , "pce-chairs@ietf.org" Message-ID: <05D77926-4F44-409B-AE83-9D936F1173DD@gmail.com> Thread-Topic: [Pce] Poll for adoption: draft-dhody-pce-applicability-actn-02 Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3576523150_202047622" Archived-At: Subject: Re: [Pce] Poll for adoption: draft-dhody-pce-applicability-actn-02 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 05:41:30 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3576523150_202047622 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable yes/support =20 Cheers, Jeff =20 =20 From: Pce on behalf of Sureshbr Date: Monday, May 1, 2017 at 21:23 To: "Zhangxian (Xian)" , Jonathan Hardwick , "pce@ietf.org" Cc: "draft-dhody-pce-applicability-actn@ietf.org" , "pce-chairs@ietf.org" Subject: Re: [Pce] Poll for adoption: draft-dhody-pce-applicability-actn-02 =20 Support. =20 From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Zhangxian (Xian) Sent: 26 April 2017 09:04 To: Jonathan Hardwick; pce@ietf.org Cc: draft-dhody-pce-applicability-actn@ietf.org; pce-chairs@ietf.org Subject: [Pce] =E7=AD=94=E5=A4=8D: Poll for adoption: draft-dhody-pce-applicability-act= n-02 =20 yes/support. =20 Regards, Xian =20 =E5=8F=91=E4=BB=B6=E4=BA=BA: Pce [mailto:pce-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Jonathan Hardwick =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B44=E6=9C=8826=E6=97=A5 0:26 =E6=94=B6=E4=BB=B6=E4=BA=BA: pce@ietf.org =E6=8A=84=E9=80=81: draft-dhody-pce-applicability-actn@ietf.org; pce-chairs@ietf.org =E4=B8=BB=E9=A2=98: [Pce] Poll for adoption: draft-dhody-pce-applicability-actn-02 =20 All, =20 This is the start of a two week poll on making draft-dhody-pce-applicabilit= y-actn-02 a PCE working group document. https://datatracker.ietf.org/doc/draft-dhody-pce-applicability-actn/ =20 Please review the draft and send an email to the list indicating =E2=80=9Cyes/sup= port=E2=80=9D or =E2=80=9Cno/do not support=E2=80=9D. If indicating no, please state your rea= sons. If yes, please also feel free to provide comments you'd like to see a= ddressed once the document is a WG document. =20 The poll ends on Tuesday, May 9. =20 Many thanks, Jon =20 =20 _______________________________________________ Pce mailing list Pce@ietf.o= rg https://www.ietf.org/mailman/listinfo/pce=20 --B_3576523150_202047622 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

yes/support

 =

Cheers,

Jeff

&n= bsp;

 

From: Pce <pce-bounces@ietf.org> on behalf of Suresh= br <Suresh.b.r@huawei.com>
Date: Monday, May 1, 2017 at 21:2= 3
To: "Zhangxian (Xian)" <zhang.xian@huawei.com>, = Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com>, "pce@ietf.o= rg" <pce@ietf.org>
Cc: "draft-dhody-pce-applicabil= ity-actn@ietf.org" <draft-dhody-pce-applicability-actn@ietf.org>,= "pce-chairs@ietf.org" <pce-chairs@ietf.org>
Subject: = Re: [Pce] Poll for adoption: draft-dhody-pce-applicability-actn-02

 

Support.

 <= /span>

= From: Pce [mailto:pce-bounces@ietf.org= ] On Behalf Of Zhangxian (Xian)
Sent: 26 April 2017 09:04To: Jonathan Hardwick; pce@ietf.org
Cc: draft-dhody-pce-a= pplicability-actn@ietf.org; pce-chairs@ietf.org
Subject: [Pce] =E7=AD=94=E5=A4=8D: Poll for adoption: draft-dhody-pce-applicability-actn-02

 

yes/sup= port.

 

Regards,

Xian

 

=E5=8F=91=E4=BB=B6=E4=BA=BA: Pce [mailto:pce-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Jonathan Hardwick
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B44=E6=9C=8826=E6=97=A5 0:26
=E6=94=B6=E4=BB=B6=E4=BA=BA: pce@ietf.org
=E6=8A=84=E9=80=81: draft-dhody-pce-applicabilit= y-actn@ietf.org; pce-chairs@ietf.or= g
=E4=B8=BB=E9=A2=98:<= span style=3D'font-family:=E5=BE=AE=E8=BD=AF=E9=9B=85=E9=BB=91'> [Pce] Poll for adoption: draft-dhody-= pce-applicability-actn-02

 

All,

 

This is the start o= f a two week poll on making draft-dhody-pce-applicability-actn-02 a PCE work= ing group document.

https://datatracker.ietf.org/doc/draft-dhody-pc= e-applicability-actn/

 

Please review the draft and = send an email to the list indicating “yes/support” or “no/= do not support”.  If indicating no, please state your reasons.&nb= sp; If yes, please also feel free to provide comments you'd like to see addr= essed once the document is a WG document.

 <= /p>

The poll = ends on Tuesday, May 9.

 

Many thanks,

Jon

 

 

____= ___________________________________________ Pce mailing list Pce@ietf.org ht= tps://www.ietf.org/mailman/listinfo/pce

<= /html> --B_3576523150_202047622-- From nobody Tue May 2 01:25:13 2017 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C3813148E for ; Tue, 2 May 2017 01:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.835 X-Spam-Level: X-Spam-Status: No, score=-0.835 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MuEc_TeqM5R for ; Tue, 2 May 2017 01:25:10 -0700 (PDT) Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id A8B861314A6 for ; Tue, 2 May 2017 01:20:11 -0700 (PDT) Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E3A18A440E4 for ; Tue, 2 May 2017 10:20:09 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail1.rd.orange.com (Postfix) with ESMTP id D1146A440D9 for ; Tue, 2 May 2017 10:20:08 +0200 (CEST) Received: from [10.193.71.226] (10.193.71.226) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.319.2; Tue, 2 May 2017 10:20:08 +0200 To: "pce@ietf.org" From: Julien Meuric Organization: Orange Message-ID: <039fda74-e8e4-18a5-326c-c36b7242bf01@orange.com> Date: Tue, 2 May 2017 10:20:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Archived-At: Subject: [Pce] WG Last Call of draft-ietf-pce-lsp-setup-type-04 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 08:25:12 -0000 Dear all, The aforementioned I-D has been stable for a while. This message initiates a 2-week WG Last Call on draft-ietf-pce-lsp-setup-type-04. Please send your comments to the PCE mailing list by May 15. Thanks, Jon, JP & Julien From nobody Tue May 2 02:52:08 2017 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3D2131464; Tue, 2 May 2017 02:52:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Cc: pce@ietf.org, db3546@att.com, pce-chairs@ietf.org, julien.meuric@orange.com X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149371872587.9991.10206434277104696962.idtracker@ietfa.amsl.com> Date: Tue, 02 May 2017 02:52:05 -0700 Archived-At: Subject: [Pce] pce - New Meeting Session Request for IETF 99 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.22 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 09:52:06 -0000 A new meeting session request has just been submitted by Julien Meuric, a Chair of the pce working group. --------------------------------------------------------- Working Group Name: Path Computation Element Area Name: Routing Area Session Requester: Julien Meuric Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: ccamp mpls teas Second Priority: isis ospf idr spring rtgarea Third Priority: sfc pals detnet rtgwg People who must be present: Deborah Brungard Julien Meuric Jonathan Hardwick Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue May 2 12:40:18 2017 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E4C12E054; Tue, 2 May 2017 12:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1Kfn7lSNrC5; Tue, 2 May 2017 12:40:14 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB7B91294E9; Tue, 2 May 2017 12:37:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DMD54801; Tue, 02 May 2017 19:37:53 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 2 May 2017 20:37:52 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.233]) by SJCEML703-CHM.china.huawei.com ([169.254.5.195]) with mapi id 14.03.0235.001; Tue, 2 May 2017 12:37:36 -0700 From: Quintin zhao To: "daniel@olddog.co.uk" , Dhruv Dhody , "'Jonathan Hardwick'" , "draft-ietf-pce-rfc6006bis@ietf.org" CC: "pce@ietf.org" Thread-Topic: IPR on draft-ietf-pce-rfc6006bis Thread-Index: AQI14FHoQspWQLTjNDuhXmbjJOhz2wG9wTukoQtILhCAAf9VgA== Date: Tue, 2 May 2017 19:37:36 +0000 Message-ID: <11208E03C9803E4CB4C3D898F153D6C03AF7F89F@SJCEML702-CHM.china.huawei.com> References: <23CE718903A838468A8B325B80962F9B8CACDD44@blreml501-mbb> <00e801d2c27b$a8252be0$f86f83a0$@olddog.co.uk> In-Reply-To: <00e801d2c27b$a8252be0$f86f83a0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.65] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.5908E012.00CD, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.233, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 55e1bd8a5c994c21eb474f91df097255 Archived-At: Subject: Re: [Pce] IPR on draft-ietf-pce-rfc6006bis X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 19:40:17 -0000 Hello Chairs,=20 Yes, I am also aware of IPR which has been disclosed and updated in the IPR= system. Thanks, Quintin =20 -----Original Message----- From: Daniel King [mailto:dk@danielking.net] On Behalf Of daniel@olddog.co.= uk Sent: Monday, May 01, 2017 6:06 AM To: Dhruv Dhody; 'Jonathan Hardwick'; draft-ietf-pce-rfc6006bis@ietf.org Cc: pce@ietf.org Subject: RE: IPR on draft-ietf-pce-rfc6006bis Hi Chairs,=20 Yes, I am also aware of IPR. This has been specifically disclosed and highlighted previously.=20 Thanks, Dan. =20 -----Original Message----- From: Dhruv Dhody [mailto:dhruv.dhody@huawei.com]=20 Sent: 24 April 2017 23:38 To: Jonathan Hardwick ; draft-ietf-pce-rfc6006bis@ietf.org Cc: pce@ietf.org Subject: RE: IPR on draft-ietf-pce-rfc6006bis Hi, Yes, I am aware of IPR and has been disclosed and updated in the IPR system= =3D From nobody Wed May 3 06:50:10 2017 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E678129AE5 for ; Wed, 3 May 2017 06:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.835 X-Spam-Level: X-Spam-Status: No, score=-0.835 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXqRdAx_b3H0 for ; Wed, 3 May 2017 06:50:07 -0700 (PDT) Received: from r-mail2.rd.orange.com (r-mail2.rd.orange.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 45C77129B30 for ; Wed, 3 May 2017 06:47:11 -0700 (PDT) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6731E5D8A6D for ; Wed, 3 May 2017 15:47:09 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail2.rd.orange.com (Postfix) with ESMTP id 552905D8A6C for ; Wed, 3 May 2017 15:47:09 +0200 (CEST) Received: from [10.193.71.226] (10.193.71.226) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.319.2; Wed, 3 May 2017 15:47:09 +0200 To: References: <039fda74-e8e4-18a5-326c-c36b7242bf01@orange.com> From: Julien Meuric Organization: Orange Message-ID: <677b1c6d-86aa-a431-d6e9-35b29ec139fa@orange.com> Date: Wed, 3 May 2017 15:47:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <039fda74-e8e4-18a5-326c-c36b7242bf01@orange.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Pce] WG Last Call of draft-ietf-pce-lsp-setup-type-04 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 13:50:09 -0000 [Chair hat off] Authors of draft-ietf-pce-lsp-setup-type, Reading the I-D, it looks to me that a (small) piece is missing. Let us assume that I want my PCEP peers to advertise they are both SR-capable and RSVP-TE-capable over a given session: the SR-PCE-CAPABILITY TLV is defined in the SR I-D, but where is the RSVP-TE counterpart? I feel we should add a 4-byte RSVP-TE-CAPABILITY TLV, with length = 0 and recommended omission in case of RSVP-TE only. My 50 cents, Julien May. 02, 2017 - Julien Meuric: > Dear all, > > The aforementioned I-D has been stable for a while. This message > initiates a 2-week WG Last Call on draft-ietf-pce-lsp-setup-type-04. > Please send your comments to the PCE mailing list by May 15. > > Thanks, > > Jon, JP & Julien > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > From nobody Wed May 3 07:25:47 2017 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2465F129504 for ; Wed, 3 May 2017 07:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dexn9By7ZvFN for ; Wed, 3 May 2017 07:25:43 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E64F6129666 for ; Wed, 3 May 2017 07:23:17 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id q66so13427698pfi.3 for ; Wed, 03 May 2017 07:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:cc:message-id:date:user-agent :mime-version:in-reply-to; bh=IAvAq0rTDHN2VuKezpdljvePzjYu7A60aodSyU5H/5g=; b=SvBiuBItf5IgFJVafEToAOd60udIzNKDamMUrIEebQNcTVaBov/yZ8EzvXC4LtLbre LbVi9uC+As1Sm/09VslzzLeyv3BHBj5RT0Oofa68DCh0rLq7jyUkkvSIe9+8VVX9LodO xfU/c6pCaqW5zI50LJw01kdO4IdEQBJ5z//E2TLzwDF6x9tSCnlaZEROC5XLTUFy4hXW CrB64WN+fTVIrSvuBCGUU+LIZohtURS2wNQheiZjKroD8nbTM5PI8tIKVLUaMWshnOb2 JLw6hAyzztuO/PZJFqn8SvITOye9FXe+5GU9tZ7pP47PhIAUhLiFLr6J4Rnx4/MAxu+B wDRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:cc:message-id:date :user-agent:mime-version:in-reply-to; bh=IAvAq0rTDHN2VuKezpdljvePzjYu7A60aodSyU5H/5g=; b=NklKfziwGfb9uiHjW6TpK/aQA23Y5f5SddNCjCKT2/XW9jVs7uNPGcxCfRW2qWU1qf 42ekcv6l5q8mURxRQxAy3zBmi0Q1EAnEzeu6DYmZRGDb8vKO+bhDIPya/F5NbLhkiJOB 0tSj7R1vhtrle7V/uoaJRMQ2R/PdcipYi3lKyHvJBekSmfZQ2AP62sdxIpyPenRNM1P1 8V3WX1M9INIUxudSm3L4om0P85FNdG/9cwPK39RrLkRqWzLfzBQ8VVlI7GYBKB3MTmgX tuNVH+ohz6asHySmZdpDylSxcVEOTEy1+YRNk2q/b/YOrJN3Evvaxp35TBb4fmn0HDaa ooLg== X-Gm-Message-State: AN3rC/7iv9o5/F2qdSt0hxdwx565L8z57tRO8Fx8QiFEw8bG5Ynf+Uhe u9IhVyRt+W5bnQ== X-Received: by 10.84.229.15 with SMTP id b15mr13360144plk.14.1493821397591; Wed, 03 May 2017 07:23:17 -0700 (PDT) Received: from [192.168.0.105] ([122.172.39.142]) by smtp.gmail.com with ESMTPSA id d123sm19856424pga.61.2017.05.03.07.23.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 May 2017 07:23:17 -0700 (PDT) From: Dhruv Dhody To: Julien Meuric References: <039fda74-e8e4-18a5-326c-c36b7242bf01@orange.com> <677b1c6d-86aa-a431-d6e9-35b29ec139fa@orange.com> Cc: "pce@ietf.org" Message-ID: Date: Wed, 3 May 2017 19:53:13 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <677b1c6d-86aa-a431-d6e9-35b29ec139fa@orange.com> Content-Type: multipart/alternative; boundary="------------1B77A8DC9B118FF39C744215" Archived-At: Subject: Re: [Pce] WG Last Call of draft-ietf-pce-lsp-setup-type-04 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 14:25:45 -0000 This is a multi-part message in MIME format. --------------1B77A8DC9B118FF39C744215 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Julien, In my understanding, PCEP sessions are always RSVP-TE capable. One may not want any LSP to be signaled by RSVP-TE, in which case PATH-SETUP-TYPE TLV would be encoded per LSP (in case of SR, this is MUST anyways by SR I-D). Also, isnt this, what we have always done with stateless to stateful PCE or P2P to P2MP extensions and so on, should we consider path-setup-type to be different? Just some thoughts, lets see what the authors/WG think... Regards, Dhruv On Wed, May 3, 2017 at 7:17 PM, Julien Meuric > wrote: [Chair hat off] Authors of draft-ietf-pce-lsp-setup-type, Reading the I-D, it looks to me that a (small) piece is missing. Let us assume that I want my PCEP peers to advertise they are both SR-capable and RSVP-TE-capable over a given session: the SR-PCE-CAPABILITY TLV is defined in the SR I-D, but where is the RSVP-TE counterpart? I feel we should add a 4-byte RSVP-TE-CAPABILITY TLV, with length = 0 and recommended omission in case of RSVP-TE only. My 50 cents, Julien May. 02, 2017 - Julien Meuric: > Dear all, > > The aforementioned I-D has been stable for a while. This message > initiates a 2-week WG Last Call on draft-ietf-pce-lsp-setup-type-04. > Please send your comments to the PCE mailing list by May 15. > > Thanks, > > Jon, 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 --------------1B77A8DC9B118FF39C744215 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Julien, 

In my understanding, PCEP sessions are always RSVP-TE capable. 
One may not want any LSP to be signaled by RSVP-TE, in which case PATH-SETUP-TYPE TLV would be encoded per LSP (in case of SR, this is MUST anyways by SR I-D).   

Also, isnt this, what we have always done with stateless to stateful PCE or P2P to P2MP extensions and so on, should we consider path-setup-type to be different?  

Just some thoughts, lets see what the authors/WG think...

Regards,
Dhruv
 

On Wed, May 3, 2017 at 7:17 PM, Julien Meuric <julien.meuric@orange.com> wrote:
[Chair hat off]

Authors of draft-ietf-pce-lsp-setup-type,

Reading the I-D, it looks to me that a (small) piece is missing. Let us
assume that I want my PCEP peers to advertise they are both SR-capable
and RSVP-TE-capable over a given session: the SR-PCE-CAPABILITY TLV is
defined in the SR I-D, but where is the RSVP-TE counterpart? I feel we
should add a 4-byte RSVP-TE-CAPABILITY TLV, with length = 0 and
recommended omission in case of RSVP-TE only.

My 50 cents,

Julien


May. 02, 2017 - Julien Meuric:
> Dear all,
>
> The aforementioned I-D has been stable for a while. This message
> initiates a 2-week WG Last Call on draft-ietf-pce-lsp-setup-type-04.
> Please send your comments to the PCE mailing list by May 15.
>
> Thanks,
>
> Jon, 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

--------------1B77A8DC9B118FF39C744215-- From nobody Wed May 3 08:19:55 2017 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E4E129503 for ; Wed, 3 May 2017 08:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.235 X-Spam-Level: X-Spam-Status: No, score=-0.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpzK2iWvjNWW for ; Wed, 3 May 2017 08:19:51 -0700 (PDT) Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [161.106.1.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE6C129436 for ; Wed, 3 May 2017 08:17:53 -0700 (PDT) Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8ED9F410258; Wed, 3 May 2017 17:17:52 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail1.rd.orange.com (Postfix) with ESMTP id 834E0410257; Wed, 3 May 2017 17:17:52 +0200 (CEST) Received: from [10.193.71.226] (10.193.71.226) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.319.2; Wed, 3 May 2017 17:17:52 +0200 To: Dhruv Dhody References: <039fda74-e8e4-18a5-326c-c36b7242bf01@orange.com> <677b1c6d-86aa-a431-d6e9-35b29ec139fa@orange.com> CC: "pce@ietf.org" From: Julien Meuric Organization: Orange Message-ID: <8b15e046-5bb7-e583-2555-7eaf7e95dadb@orange.com> Date: Wed, 3 May 2017 17:17:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Pce] WG Last Call of draft-ietf-pce-lsp-setup-type-04 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 15:19:53 -0000 Hi Dhruv, Thank you for your feedback, this is valuable. I fully agree with your first statement: so far, any PCEP peer is assumed as RSVP-TE-compliant. When no path setup type is explicitly expressed, this must remain the assumption, I am not questioning the default. However, I believe there will be some networks (e.g. SR-enabled) where: - multiple PCEs may support different capabilities while, in the current I-D, the only way for a PCC to identify that RSVP-TE is not supported would be to send a PCReq and get a session-closing "Unsupported path setup type" error; - some PCCs are not actually RSVP-TE-capable, thus PCE-initiated TE-LSPs will also face a session-closing "Unsupported path setup type" error (by the way, I feel we should not close the session in this case). I see two ways to address this case with a reasonable effort: - assume that when path setup types are explicitly expressed (which remains optional), there is no implicit assumption, thus the RSVP-TE capability advertisement proposed below; - stick with this implicit RSVP-TE support by default, which would require an RSVP-TE-NON-SUPPORT TLV some time. Assuming we can agree on the requirement, I prefer to add TLVs to express capabilities rather than disable them. If you believe otherwise, I wonder if the latter proposal would be an acceptable trade-off. Cheers, Julien May. 03, 2017 - dhruv.ietf@gmail.com: > Hi Julien, > > In my understanding, PCEP sessions are always RSVP-TE capable. > One may not want any LSP to be signaled by RSVP-TE, in which case > PATH-SETUP-TYPE TLV would be encoded per LSP (in case of SR, this is > MUST anyways by SR I-D). > > Also, isnt this, what we have always done with stateless to stateful > PCE or P2P to P2MP extensions and so on, should we consider > path-setup-type to be different? > > Just some thoughts, lets see what the authors/WG think... > > Regards, > Dhruv > > > On Wed, May 3, 2017 at 7:17 PM, Julien Meuric > > wrote: > > [Chair hat off] > > Authors of draft-ietf-pce-lsp-setup-type, > > Reading the I-D, it looks to me that a (small) piece is missing. > Let us > assume that I want my PCEP peers to advertise they are both SR-capable > and RSVP-TE-capable over a given session: the SR-PCE-CAPABILITY TLV is > defined in the SR I-D, but where is the RSVP-TE counterpart? I feel we > should add a 4-byte RSVP-TE-CAPABILITY TLV, with length = 0 and > recommended omission in case of RSVP-TE only. > > My 50 cents, > > Julien > > > May. 02, 2017 - Julien Meuric: > > Dear all, > > > > The aforementioned I-D has been stable for a while. This message > > initiates a 2-week WG Last Call on draft-ietf-pce-lsp-setup-type-04. > > Please send your comments to the PCE mailing list by May 15. > > > > Thanks, > > > > Jon, 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 > > > From nobody Wed May 3 09:50:24 2017 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE4C126CD6 for ; Wed, 3 May 2017 09:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQT2izFyFV35 for ; Wed, 3 May 2017 09:50:21 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABFEE126C2F for ; Wed, 3 May 2017 09:48:27 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id q66so15274556pfi.3 for ; Wed, 03 May 2017 09:48:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=F7waXFBM7ae+qH0x1EFh9Le8fcSF7Rbh0RMCHA857qo=; b=ml4h39Rvbg51/hNI3aP2tPskg8LlG559KQ8bMMUymkd80O4W7tLgwJPdUTYuzQ8aJs VWM8Wu+qRvv9awT5rp0YFYyNd4QJWWjOWX0qGxguEpN108w2Z3uEfXkkkVnC6MugVVp1 0u1VKb1yzUeBDcoEHWlGBsc1VHLL4Wl52gG90729/vjZSzw0cZNilENCPJA2E0yCjuRl YMDhVTMJeT6P8BB35fYrG4NrMhM/h9NmxpV5znOVKqRLgzEQyV6aYzKqJZbdOby5Aq4l Qxl5C3cEITdZjkj+rhORlrRuG5/JFREeHLYq0Vw7y6RWL1jSIQLFW3C41XNUbtmITY2I LCOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=F7waXFBM7ae+qH0x1EFh9Le8fcSF7Rbh0RMCHA857qo=; b=DF/fsGX/MCbVlsJPlo1e9DthfVi2rlMGG29/dV8OlbnT/CWq2FgjaIovEbvS6mZ/5T oA6JX7xU23GoHC5IhACT9MlqUrOyiLDg8ZEUu/FuzvCfHTAqiS3HojozeCfP992LJFV2 EVqHM5MgAQA78Lj3xzReOXlZWVNYtX3EMNDazEY9s5m59Dk4oFlk1L9UCVb8g8jrWxwA Hc6fElXUJ8JfBtLxO3xja+qNzpdiKylzegInzYPmULpUHTVnxCKKNGeTQvC+W5/EhBIl PlPGOtvG+IrlfBNbHYAfaJIv6FY/a0AULx6pSJ5BeOAnmi0fB/O48Dc59sZpzGK6dvnS QnWg== X-Gm-Message-State: AN3rC/7wWsOT+fuIGhf43qKtA4apTkR3d5ItVAh4iP8WVDTZfLcL2E3c XIBWCeQDzUVejw== X-Received: by 10.99.225.83 with SMTP id h19mr40684945pgk.38.1493830107230; Wed, 03 May 2017 09:48:27 -0700 (PDT) Received: from [192.168.0.105] ([122.172.39.142]) by smtp.gmail.com with ESMTPSA id 194sm9652105pgf.62.2017.05.03.09.48.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 May 2017 09:48:26 -0700 (PDT) To: Julien Meuric References: <039fda74-e8e4-18a5-326c-c36b7242bf01@orange.com> <677b1c6d-86aa-a431-d6e9-35b29ec139fa@orange.com> <8b15e046-5bb7-e583-2555-7eaf7e95dadb@orange.com> Cc: "pce@ietf.org" From: Dhruv Dhody Message-ID: Date: Wed, 3 May 2017 22:18:22 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8b15e046-5bb7-e583-2555-7eaf7e95dadb@orange.com> Content-Type: multipart/alternative; boundary="------------0730689273011A60CC45DA8D" Archived-At: Subject: Re: [Pce] WG Last Call of draft-ietf-pce-lsp-setup-type-04 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 16:50:23 -0000 This is a multi-part message in MIME format. --------------0730689273011A60CC45DA8D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Julien, This helps me understand your point of view. I agree that there could be some PCC that would not support RSVP-TE and would be "SR-only". In my reading, I assumed that theerror-codes would not hit for RSVP-TE in those cases. On re-reading i am not sure that is the case. So it could be good to clarify that from authors for - Regardless of whether PATH-SETUP-TYPE TLV is used or not, if the PCE does not support the intended path setup type it MUST send PCErr with Error-Type = TBD (Traffic engineering path setup error) (recommended value is 21) and Error-Value = 1 (Unsupported path setup type) and close the PCEP session. I was thinking that the behavior would be similar to "RSVP-TE being not enabled on the PCC", and thus the signaling failed in that case. The reason being, from the point of view of the protocol, even SR-only peer must understand RSVP-TE semantics i.e. RFC5440 and other stateful extensions. From the discussion it is clear we should handle this explicitly in the draft to avoid any confusion, i see two ways - (1) If the authors intended closing the session for the SR-only peer, then I think your suggestion should be followed. (2) If the authors intended that all implementation understand (support?) RSVP-TE, they have just not enabled RSVP-TE for SR-only case, then that can also be stated in the draft to avoid confusion. I hope WG could converge on this quickly. Thanks! Dhruv On Wednesday 03 May 2017 08:47 PM, Julien Meuric wrote: > Hi Dhruv, > > Thank you for your feedback, this is valuable. > > I fully agree with your first statement: so far, any PCEP peer is > assumed as RSVP-TE-compliant. When no path setup type is explicitly > expressed, this must remain the assumption, I am not questioning the > default. > However, I believe there will be some networks (e.g. SR-enabled) where: > - multiple PCEs may support different capabilities while, in the current > I-D, the only way for a PCC to identify that RSVP-TE is not supported > would be to send a PCReq and get a session-closing "Unsupported path > setup type" error; > - some PCCs are not actually RSVP-TE-capable, thus PCE-initiated TE-LSPs > will also face a session-closing "Unsupported path setup type" error (by > the way, I feel we should not close the session in this case). > > I see two ways to address this case with a reasonable effort: > - assume that when path setup types are explicitly expressed (which > remains optional), there is no implicit assumption, thus the RSVP-TE > capability advertisement proposed below; > - stick with this implicit RSVP-TE support by default, which would > require an RSVP-TE-NON-SUPPORT TLV some time. > > Assuming we can agree on the requirement, I prefer to add TLVs to > express capabilities rather than disable them. If you believe otherwise, > I wonder if the latter proposal would be an acceptable trade-off. > > Cheers, > > Julien > > > May. 03, 2017 - dhruv.ietf@gmail.com: >> Hi Julien, >> >> In my understanding, PCEP sessions are always RSVP-TE capable. >> One may not want any LSP to be signaled by RSVP-TE, in which case >> PATH-SETUP-TYPE TLV would be encoded per LSP (in case of SR, this is >> MUST anyways by SR I-D). >> >> Also, isnt this, what we have always done with stateless to stateful >> PCE or P2P to P2MP extensions and so on, should we consider >> path-setup-type to be different? >> >> Just some thoughts, lets see what the authors/WG think... >> >> Regards, >> Dhruv >> >> >> On Wed, May 3, 2017 at 7:17 PM, Julien Meuric >> > wrote: >> >> [Chair hat off] >> >> Authors of draft-ietf-pce-lsp-setup-type, >> >> Reading the I-D, it looks to me that a (small) piece is missing. >> Let us >> assume that I want my PCEP peers to advertise they are both SR-capable >> and RSVP-TE-capable over a given session: the SR-PCE-CAPABILITY TLV is >> defined in the SR I-D, but where is the RSVP-TE counterpart? I feel we >> should add a 4-byte RSVP-TE-CAPABILITY TLV, with length = 0 and >> recommended omission in case of RSVP-TE only. >> >> My 50 cents, >> >> Julien >> >> >> May. 02, 2017 - Julien Meuric: >> > Dear all, >> > >> > The aforementioned I-D has been stable for a while. This message >> > initiates a 2-week WG Last Call on draft-ietf-pce-lsp-setup-type-04. >> > Please send your comments to the PCE mailing list by May 15. >> > >> > Thanks, >> > >> > Jon, 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 >> >> >> --------------0730689273011A60CC45DA8D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Julien,

This helps me understand your point of view. I agree that there could be some PCC that would not support RSVP-TE and would be "SR-only". 

In my reading, I assumed that the error-codes would not hit for RSVP-TE in those cases. On re-reading i am not sure that is the case. So it could be good to clarify that from authors for -  

   Regardless of whether PATH-SETUP-TYPE TLV is used or not, if the PCE
   does not support the intended path setup type it MUST send PCErr with
   Error-Type = TBD (Traffic engineering path setup error) (recommended
   value is 21) and Error-Value = 1 (Unsupported path setup type) and
   close the PCEP session. 


I was thinking that the behavior would be similar to "RSVP-TE being not enabled on the PCC", and thus the signaling failed in that case. 
The reason being, from the point of view of the protocol, even SR-only peer must understand RSVP-TE semantics i.e. RFC5440 and other stateful extensions. 

>From the discussion it is clear we should handle this explicitly in the draft to avoid any confusion, i see two ways -   

(1) If the authors intended closing the session for the SR-only peer, then I think your suggestion should be followed. 
(2) If the authors intended that all implementation understand (support?) RSVP-TE, they have just not enabled RSVP-TE for SR-only case, then that can also be stated in the draft to avoid confusion.  

I hope WG could converge on this quickly. 

Thanks! 
Dhruv


On Wednesday 03 May 2017 08:47 PM, Julien Meuric wrote:
Hi Dhruv,

Thank you for your feedback, this is valuable.

I fully agree with your first statement: so far, any PCEP peer is
assumed as RSVP-TE-compliant. When no path setup type is explicitly
expressed, this must remain the assumption, I am not questioning the
default.
However, I believe there will be some networks (e.g. SR-enabled) where:
- multiple PCEs may support different capabilities while, in the current
I-D, the only way for a PCC to identify that RSVP-TE is not supported
would be to send a PCReq and get a session-closing "Unsupported path
setup type" error;
- some PCCs are not actually RSVP-TE-capable, thus PCE-initiated TE-LSPs
will also face a session-closing "Unsupported path setup type" error (by
the way, I feel we should not close the session in this case).

I see two ways to address this case with a reasonable effort:
- assume that when path setup types are explicitly expressed (which
remains optional), there is no implicit assumption, thus the RSVP-TE
capability advertisement proposed below;
- stick with this implicit RSVP-TE support by default, which would
require an RSVP-TE-NON-SUPPORT TLV some time.

Assuming we can agree on the requirement, I prefer to add TLVs to
express capabilities rather than disable them. If you believe otherwise,
I wonder if the latter proposal would be an acceptable trade-off.

Cheers,

Julien


May. 03, 2017 - dhruv.ietf@gmail.com:

Hi Julien, 

In my understanding, PCEP sessions are always RSVP-TE capable. 
One may not want any LSP to be signaled by RSVP-TE, in which case
PATH-SETUP-TYPE TLV would be encoded per LSP (in case of SR, this is
MUST anyways by SR I-D).   

Also, isnt this, what we have always done with stateless to stateful
PCE or P2P to P2MP extensions and so on, should we consider
path-setup-type to be different?  

Just some thoughts, lets see what the authors/WG think...

Regards,
Dhruv
 

On Wed, May 3, 2017 at 7:17 PM, Julien Meuric
<julien.meuric@orange.com <mailto:julien.meuric@orange.com>> wrote:

    [Chair hat off]

    Authors of draft-ietf-pce-lsp-setup-type,

    Reading the I-D, it looks to me that a (small) piece is missing.
    Let us
    assume that I want my PCEP peers to advertise they are both SR-capable
    and RSVP-TE-capable over a given session: the SR-PCE-CAPABILITY TLV is
    defined in the SR I-D, but where is the RSVP-TE counterpart? I feel we
    should add a 4-byte RSVP-TE-CAPABILITY TLV, with length = 0 and
    recommended omission in case of RSVP-TE only.

    My 50 cents,

    Julien


    May. 02, 2017 - Julien Meuric:
    > Dear all,
    >
    > The aforementioned I-D has been stable for a while. This message
    > initiates a 2-week WG Last Call on draft-ietf-pce-lsp-setup-type-04.
    > Please send your comments to the PCE mailing list by May 15.
    >
    > Thanks,
    >
    > Jon, JP & Julien
    >
    > _______________________________________________
    > Pce mailing list
    > Pce@ietf.org <mailto:Pce@ietf.org>
    > https://www.ietf.org/mailman/listinfo/pce
    <https://www.ietf.org/mailman/listinfo/pce>
    >

    _______________________________________________
    Pce mailing list
    Pce@ietf.org <mailto:Pce@ietf.org>
    https://www.ietf.org/mailman/listinfo/pce
    <https://www.ietf.org/mailman/listinfo/pce>




    

    

  


--------------0730689273011A60CC45DA8D--


From nobody Thu May  4 10:14:34 2017
Return-Path: 
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6A812944F; Thu,  4 May 2017 10:14:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level: 
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQTKOZpirFIk; Thu,  4 May 2017 10:14:30 -0700 (PDT)
Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7DC3128E19; Thu,  4 May 2017 10:14:29 -0700 (PDT)
Received: by mail-io0-x235.google.com with SMTP id p80so29615265iop.3; Thu, 04 May 2017 10:14:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QJjGJyj40+3PE1lUaCbJ3866krrXRizTGMgCIzryTRE=; b=tPf66pVqE3Cz58OdMpI4Liuq5Os/0ZcS7rtdqyJ824VXkyu8WJ5wOP8KddNB33Q1UK zYlDLORhY4GnSfGbZt3Q9BTwtH+pHyP5Pktvg629IUpKfaK0VJ9hSEqDb7ou7DVh5Olg tm6V4IutvixJVNaF4D7TeT4dv4tezzpZ99TewJtxr0tlgiiP3+AkMJ4jHbmcU1YK2e9M bUW8Yh35hR7Y6viMcRXczOuzhGsODEoW8+MvO6x2TvQgOGqCxe/L0Akt+8ujgTikaMhk OU16xwqcOu24vcGSu04erasZYxJw7k4uxnZeVMxPRcZOrUm0Bwe8HbbmBPul2qkBxbv2 xW8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QJjGJyj40+3PE1lUaCbJ3866krrXRizTGMgCIzryTRE=; b=MSgUO/xvtA0wqC/nLH7ApAYqjgWGfJ+25neVqNZXjYH7tfcYrAQ6hYyCAw8Wduzf9m 0MP3WC2jEDSj7JzWXFjoZx1hJdO4rBTgxzEbiOsogkgCv1PRE7MmUzM3kbP37Jqa+Peh qIycyXOUyWe8aIuCPBqMhZgCYNUhpRtABaDMEZSrytpDAkjQxWujrPpAU+8j1KWzPNrJ xPBPomfQvdl4q7Y+Z5Kmxsgnu/PtwZjIIl5n+QZ3NeDDE27aCWaU4vHT4OvyFqtrRtIt JikfgKKjaz1c729ckyyOMIApc8pHHGj1A8cU/yyb3FnGx3j55T1BL8TZ+zqM0J9V3dmX A4NA==
X-Gm-Message-State: AN3rC/6DNA7rsAJCL4pni3BUPYelYUYSlo/Na+dgPqmaxAQLsivnZOdr N8nBza7Z2LlZvnEGXEtqiFTZYjNXsg==
X-Received: by 10.107.190.193 with SMTP id o184mr15006393iof.95.1493918069045;  Thu, 04 May 2017 10:14:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.17.218 with HTTP; Thu, 4 May 2017 10:14:28 -0700 (PDT)
In-Reply-To: 
References: 
From: Udayasree Palle 
Date: Thu, 4 May 2017 13:14:28 -0400
Message-ID: 
To: Jonathan Hardwick 
Cc: "pce@ietf.org" ,  "draft-dhody-pce-applicability-actn@ietf.org" ,  "pce-chairs@ietf.org" 
Content-Type: multipart/alternative; boundary=001a114f3b30d4611a054eb5e7c1
Archived-At: 
Subject: Re: [Pce] Poll for adoption: draft-dhody-pce-applicability-actn-02
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 May 2017 17:14:33 -0000

--001a114f3b30d4611a054eb5e7c1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Yes/support

Regards,
Udayasree

On Tue, Apr 25, 2017 at 12:25 PM, Jonathan Hardwick <
Jonathan.Hardwick@metaswitch.com> wrote:

> All,
>
>
>
> This is the start of a two week poll on making
> draft-dhody-pce-applicability-actn-02 a PCE working group document.
>
> https://datatracker.ietf.org/doc/draft-dhody-pce-applicability-actn/
>
>
>
> Please review the draft and send an email to the list indicating
> =E2=80=9Cyes/support=E2=80=9D or =E2=80=9Cno/do not support=E2=80=9D.  If=
 indicating no, please state your
> reasons.  If yes, please also feel free to provide comments you'd like to
> see addressed once the document is a WG document.
>
>
>
> The poll ends on Tuesday, May 9.
>
>
>
> Many thanks,
>
> Jon
>
>
>
>
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
>

--001a114f3b30d4611a054eb5e7c1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Yes/support

Regards,
Udayasre=
e

On T=
ue, Apr 25, 2017 at 12:25 PM, Jonathan Hardwick <Jonathan.H=
ardwick@metaswitch.com> wrote:











All,


=C2=A0


This is the start of a two week poll on making draft=
-dhody-pce-applicability-actn-02 a PCE working group document.<=
u>


https://datatracker.ietf.org=
/doc/draft-dhody-pce-applicability-actn/


=C2=A0


Please review the draft and =
send an email to the list indicating =E2=80=9Cyes/support=E2=80=9D or =E2=
=80=9Cno/do not support=E2=80=9D.=C2=A0 If indicating no, please state your=
 reasons.=C2=A0 If yes, please also feel free to provide comments you'd=
 like to see addressed once
 the document is a WG document.


=C2=A0


The poll ends on Tuesday, Ma=
y 9.


=C2=A0


Many thanks,

Jon


=C2=A0


=C2=A0







_______________________________________________

Pce mailing list

Pce@ietf.org

https://www.ietf.org/mailman/listinfo/pce





--001a114f3b30d4611a054eb5e7c1--


From nobody Thu May  4 14:27:33 2017
Return-Path: 
X-Original-To: pce@ietf.org
Delivered-To: pce@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 651E51294D4; Thu,  4 May 2017 14:27:32 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Secretariat 
To: 
Cc: pce@ietf.org, ipr-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.50.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149393325240.6861.15801464215162854394@ietfa.amsl.com>
Date: Thu, 04 May 2017 14:27:32 -0700
Archived-At: 
Subject: [Pce] IPR Disclosure Cisco's Statement about IPR related to draft-ietf-pce-stateful-pce-auto-bandwidth
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 May 2017 21:27:32 -0000

Dear Dhruv Dhody, Rakesh Gandhi, Ravi Singh, Luyuan Fang, Udayasree Palle:


An IPR disclosure that pertains to your Internet-Draft entitled "PCEP
Extensions for MPLS-TE LSP Automatic Bandwidth Adjustment with Stateful
PCE" (draft-ietf-pce-stateful-pce-auto-bandwidth) was submitted to the IETF
Secretariat on  and has been posted on the "IETF Page of Intellectual Property
Rights Disclosures" (https://datatracker.ietf.org/ipr/2996/). The title of the
IPR disclosure is "Cisco's Statement about IPR related to
draft-ietf-pce-stateful-pce-auto-bandwidth"


Thank you

IETF Secretariat


From nobody Fri May  5 01:22:30 2017
Return-Path: 
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A65129483 for ; Fri,  5 May 2017 01:22:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNka44ocDBmi for ; Fri,  5 May 2017 01:22:27 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B5C2129477 for ; Fri,  5 May 2017 01:22:26 -0700 (PDT)
Received: from [192.168.0.101] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 2C48318013D1 for ; Fri,  5 May 2017 10:22:25 +0200 (CEST)
To: pce@ietf.org
References: <149393325240.6861.15801464215162854394@ietfa.amsl.com>
From: Loa Andersson 
Message-ID: <7786d1a8-6933-9f02-15c3-0a8f0a46b3d1@pi.nu>
Date: Fri, 5 May 2017 10:22:22 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <149393325240.6861.15801464215162854394@ietfa.amsl.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Pce] IPR Disclosure Cisco's Statement about IPR related to draft-ietf-pce-stateful-pce-auto-bandwidth
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 May 2017 08:22:28 -0000

Folks,

I see no problem progressing this draft, the licensing terms are OK.

However there is another problem.

The disclosed IPR was applied for in 2006, and granted 2011. The draft
was first posted in early 2013. What is the explanation for this late
disclosure?

/Loaq


On 2017-05-04 23:27, IETF Secretariat wrote:
> Dear Dhruv Dhody, Rakesh Gandhi, Ravi Singh, Luyuan Fang, Udayasree Palle:
>
>
> An IPR disclosure that pertains to your Internet-Draft entitled "PCEP
> Extensions for MPLS-TE LSP Automatic Bandwidth Adjustment with Stateful
> PCE" (draft-ietf-pce-stateful-pce-auto-bandwidth) was submitted to the IETF
> Secretariat on  and has been posted on the "IETF Page of Intellectual Property
> Rights Disclosures" (https://datatracker.ietf.org/ipr/2996/). The title of the
> IPR disclosure is "Cisco's Statement about IPR related to
> draft-ietf-pce-stateful-pce-auto-bandwidth"
>
>
> Thank you
>
> IETF Secretariat
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>

-- 


Loa Andersson                        email: loa@mail01.huawei.com
Senior MPLS Expert                          loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64


From nobody Fri May  5 10:37:57 2017
Return-Path: 
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5AF129AFE for ; Fri,  5 May 2017 10:37:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Level: 
X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9SJtbobvI0O for ; Fri,  5 May 2017 10:37:54 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ED67129AEB for ; Fri,  5 May 2017 10:37:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2580; q=dns/txt; s=iport; t=1494005874; x=1495215474; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=BIiYiGHnzRdU5tYXjBPmvihACKfEHL9hRkx40V0ffmU=; b=U9tU2Z2GdD5RYMFSW2v4V/sbiZsWvVyooOxdh+H7dDHMB9sKFTucjuk2 584SkTpOCYSzxhkeLMFlUJlZDVfbdguv6Jy5QyywojV/0yYZvLdmVi+2e ozOeZJJq7UdW24l2CJ9pAO71Xpi7poXV6adA5B7WtvVIiv74Qwm8UKU21 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CVAQB2twxZ/5NdJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VigQwHg2GKGJE1IZVwgg8hC4V4AhqELz8YAQIBAQEBAQEBayi?= =?us-ascii?q?FFgEBAQMBASERNwMZAgIBCBgCAh8HAgICGQwLFRACBAESiiAOsR+CJopoAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGAUFgQaFVIFdASsLgmWENBIBHBcjgkwugjEFnW8?= =?us-ascii?q?BhxqLfIIEhTmKK5Q2AR84fwtvFRwqEgGFFYFKdoZHgSEBgQwBAQE?=
X-IronPort-AV: E=Sophos;i="5.38,293,1491264000"; d="scan'208";a="419419623"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 May 2017 17:37:53 +0000
Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v45HbrGr019182 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 5 May 2017 17:37:53 GMT
Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 5 May 2017 12:37:52 -0500
Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1210.000; Fri, 5 May 2017 12:37:52 -0500
From: "Rakesh Gandhi (rgandhi)" 
To: Loa Andersson , "pce@ietf.org" 
Thread-Topic: [Pce] IPR Disclosure Cisco's Statement about IPR related to draft-ietf-pce-stateful-pce-auto-bandwidth
Thread-Index: AQHSxR0+jOkOIkiUKka0hQGDnDuIQKHluwcAgABYKwA=
Date: Fri, 5 May 2017 17:37:52 +0000
Message-ID: <11EBFD0D-EA15-4003-95CB-B20265E68CF5@cisco.com>
References: <149393325240.6861.15801464215162854394@ietfa.amsl.com> <7786d1a8-6933-9f02-15c3-0a8f0a46b3d1@pi.nu>
In-Reply-To: <7786d1a8-6933-9f02-15c3-0a8f0a46b3d1@pi.nu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.1d.0.161209
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [161.44.212.220]
Content-Type: text/plain; charset="utf-8"
Content-ID: <8A173AB6F39D3B42A51298526DAADA09@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Pce] IPR Disclosure Cisco's Statement about IPR related to draft-ietf-pce-stateful-pce-auto-bandwidth
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 May 2017 17:37:56 -0000

SGkgTG9hLA0KDQpQbGVhc2Ugc2VlIGlubGluZSB3aXRoIDxSRz4uDQoNCk9uIDIwMTctMDUtMDUs
IDQ6MjIgQU0sICJQY2Ugb24gYmVoYWxmIG9mIExvYSBBbmRlcnNzb24iIDxwY2UtYm91bmNlc0Bp
ZXRmLm9yZyBvbiBiZWhhbGYgb2YgbG9hQHBpLm51PiB3cm90ZToNCg0KICAgIEZvbGtzLA0KICAg
IA0KICAgIEkgc2VlIG5vIHByb2JsZW0gcHJvZ3Jlc3NpbmcgdGhpcyBkcmFmdCwgdGhlIGxpY2Vu
c2luZyB0ZXJtcyBhcmUgT0suDQogICAgDQo8Ukc+IEdyZWF0LCB0aGFua3MuDQoNCiAgICBIb3dl
dmVyIHRoZXJlIGlzIGFub3RoZXIgcHJvYmxlbS4NCiAgICANCiAgICBUaGUgZGlzY2xvc2VkIElQ
UiB3YXMgYXBwbGllZCBmb3IgaW4gMjAwNiwgYW5kIGdyYW50ZWQgMjAxMS4gVGhlIGRyYWZ0DQog
ICAgd2FzIGZpcnN0IHBvc3RlZCBpbiBlYXJseSAyMDEzLiBXaGF0IGlzIHRoZSBleHBsYW5hdGlv
biBmb3IgdGhpcyBsYXRlDQogICAgZGlzY2xvc3VyZT8NCg0KPFJHPiBUaGlzIHdhcyBkaXNjbG9z
ZWQgYXMgc29vbiBhcyBhbiBhdXRob3IgbGVhcm5lZCBhYm91dCBpdC4NCg0KVGhhbmtzLA0KUmFr
ZXNoDQoNCg0KICAgIA0KICAgIC9Mb2FxDQogICAgDQogICAgDQogICAgT24gMjAxNy0wNS0wNCAy
MzoyNywgSUVURiBTZWNyZXRhcmlhdCB3cm90ZToNCiAgICA+IERlYXIgRGhydXYgRGhvZHksIFJh
a2VzaCBHYW5kaGksIFJhdmkgU2luZ2gsIEx1eXVhbiBGYW5nLCBVZGF5YXNyZWUgUGFsbGU6DQog
ICAgPg0KICAgID4NCiAgICA+IEFuIElQUiBkaXNjbG9zdXJlIHRoYXQgcGVydGFpbnMgdG8geW91
ciBJbnRlcm5ldC1EcmFmdCBlbnRpdGxlZCAiUENFUA0KICAgID4gRXh0ZW5zaW9ucyBmb3IgTVBM
Uy1URSBMU1AgQXV0b21hdGljIEJhbmR3aWR0aCBBZGp1c3RtZW50IHdpdGggU3RhdGVmdWwNCiAg
ICA+IFBDRSIgKGRyYWZ0LWlldGYtcGNlLXN0YXRlZnVsLXBjZS1hdXRvLWJhbmR3aWR0aCkgd2Fz
IHN1Ym1pdHRlZCB0byB0aGUgSUVURg0KICAgID4gU2VjcmV0YXJpYXQgb24gIGFuZCBoYXMgYmVl
biBwb3N0ZWQgb24gdGhlICJJRVRGIFBhZ2Ugb2YgSW50ZWxsZWN0dWFsIFByb3BlcnR5DQogICAg
PiBSaWdodHMgRGlzY2xvc3VyZXMiIChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8y
OTk2LykuIFRoZSB0aXRsZSBvZiB0aGUNCiAgICA+IElQUiBkaXNjbG9zdXJlIGlzICJDaXNjbydz
IFN0YXRlbWVudCBhYm91dCBJUFIgcmVsYXRlZCB0bw0KICAgID4gZHJhZnQtaWV0Zi1wY2Utc3Rh
dGVmdWwtcGNlLWF1dG8tYmFuZHdpZHRoIg0KICAgID4NCiAgICA+DQogICAgPiBUaGFuayB5b3UN
CiAgICA+DQogICAgPiBJRVRGIFNlY3JldGFyaWF0DQogICAgPg0KICAgID4gX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+IFBjZSBtYWlsaW5nIGxp
c3QNCiAgICA+IFBjZUBpZXRmLm9yZw0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9wY2UNCiAgICA+DQogICAgDQogICAgLS0gDQogICAgDQogICAgDQogICAgTG9h
IEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOiBsb2FAbWFpbDAxLmh1YXdl
aS5jb20NCiAgICBTZW5pb3IgTVBMUyBFeHBlcnQgICAgICAgICAgICAgICAgICAgICAgICAgIGxv
YUBwaS5udQ0KICAgIEh1YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1bHRhbnQpICAgICBwaG9uZTog
KzQ2IDczOSA4MSAyMSA2NA0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQogICAgUGNlIG1haWxpbmcgbGlzdA0KICAgIFBjZUBpZXRmLm9y
Zw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNlDQogICAgDQoN
Cg==


From nobody Sun May  7 18:30:56 2017
Return-Path: 
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94277128B8F; Sun,  7 May 2017 18:30:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.502
X-Spam-Level: 
X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9JZaixoYGSQ; Sun,  7 May 2017 18:30:52 -0700 (PDT)
Received: from post-send.kddi.com (athena2.kddi.com [27.90.165.195]) by ietfa.amsl.com (Postfix) with ESMTP id AFA92128A32; Sun,  7 May 2017 18:30:52 -0700 (PDT)
Received: from LTMC2121.kddi.com (LTMC2121.kddi.com [10.206.0.61]) by post-send.kddi.com (KDDI Mail) with ESMTP id F3ED6E004A; Mon,  8 May 2017 10:30:51 +0900 (JST)
Received: from LTMC2144.kddi.com ([10.206.0.236] [10.206.0.236]) by LTMC2121.kddi.com with ESMTP; Mon, 8 May 2017 10:30:51 +0900
Received: from LTMC2144.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id CCEF34C0058; Mon,  8 May 2017 10:30:51 +0900 (JST)
Received: from LTMC2154.kddi.com (post-incheck [10.206.0.239]) by LTMC2144.kddi.com (Postfix) with ESMTP id C1CF44C0051; Mon,  8 May 2017 10:30:51 +0900 (JST)
Received: from LTMC2154.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC2154.kddi.com  with ESMTP id v481UpwR022420; Mon, 8 May 2017 10:30:51 +0900
Received: from LTMC2154.kddi.com.mid_4146640 (localhost.localdomain [127.0.0.1]) by LTMC2154.kddi.com  with ESMTP id v481Kjb8008483; Mon, 8 May 2017 10:20:45 +0900
X-SA-MID: 4146640
Received: from KDDI1312PC0461 ([10.210.106.177] [10.210.106.177]) by post-smtp2.kddi.com with ESMTPA; Mon, 8 May 2017 10:20:45 +0900
From: "Takuya Miyasaka" 
To: "'Jonathan Hardwick'" , 
Cc: , 
References: 
In-Reply-To: 
Date: Mon, 8 May 2017 10:20:45 +0900
Message-ID: <01d001d2c799$515abaf0$f41030d0$@kddi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQECI6sKHHnBBaatXoxFWtlJE+lDPaOK6tvg
Content-Language: ja
X-TM-AS-MML: disable
Archived-At: 
Subject: Re: [Pce] Poll for adoption: draft-dhody-pce-applicability-actn-02
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 May 2017 01:30:55 -0000

Yes/support


Regards,
Takuya

> -----Original Message-----
> From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Jonathan Hardwick
> Sent: Wednesday, April 26, 2017 1:26 AM
> To: pce@ietf.org
> Cc: draft-dhody-pce-applicability-actn@ietf.org; pce-chairs@ietf.org
> Subject: [Pce] Poll for adoption: draft-dhody-pce-applicability-actn-02
> 
> All,
> 
> 
> 
> This is the start of a two week poll on making draft-dhody-pce-applicability-actn-02 a PCE working group document.
> 
> https://datatracker.ietf.org/doc/draft-dhody-pce-applicability-actn/
> 
> 
> 
> Please review the draft and send an email to the list indicating "yes/support" or "no/do not support".  If indicating
> no, please state your reasons.  If yes, please also feel free to provide comments you'd like to see addressed once
> the document is a WG document.
> 
> 
> 
> The poll ends on Tuesday, May 9.
> 
> 
> 
> Many thanks,
> 
> Jon
> 
> 
> 
> 



From nobody Sun May  7 21:01:41 2017
Return-Path: 
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E31127873; Sun,  7 May 2017 21:01:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFl89JyLdloU; Sun,  7 May 2017 21:01:38 -0700 (PDT)
Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AC34126C26; Sun,  7 May 2017 21:01:38 -0700 (PDT)
Received: by mail-it0-x229.google.com with SMTP id c15so59243527ith.0; Sun, 07 May 2017 21:01:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RJ21nTk7UmSXQ7nDAVfutyuQpsZmRnit+Xu5ZhKkrg8=; b=cRaQ65rwgHauA7YQj1LfgNulNB9c0Qg2TPVBdGfuI4WY3q5rtA7+HaQqIMplepf4uO xkyoIEwRL/CnkB7qZAMaJzd98mmmGMMUMVslF1Or2tNa0fl49gjageVUS0Y/JrjhEvnC 080jlvEOxFf1pCx8fYyUu+IKuRn2jPDRwRl88VEbGsFmDb7cxLtHFzvjBKkEoM2tlAcL pWZOFkiN4v3TjTxvBHwbNH1zv1a5G/XqOuw/iFsS6MtJoCDsoSxrV7y2XMR4it8EngaC b3KtQmB6ksaAukjfJSJ4QukmFOQ+M6BDFyt2Rb+T/6Bd4PXj0jwsUWTNClIt5Xck+BQO sIwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RJ21nTk7UmSXQ7nDAVfutyuQpsZmRnit+Xu5ZhKkrg8=; b=WPI0XnoV6QPIzVdIqrP10YzQkrfcDqKifFR3sL6I5t8mNBsJWTiSaYxc6/dGQ+1b9K NGxMO8idTo1otW3l6ej0avRA0oB5B0QrJQ3tcDdRfPydFNKGjfmQtQyNzpxTEOEhisvN P7m1FHCT7JW9nIojLrUrj524pWs8gFwT5hGUrxB/atyP68E1EvueUzoQTzLdfsedhAMx R7i6TPuWFBhlNfIqTGzd6E5B1tZgZ0JWZuTPFnw4GCMcYu37GdJ+INgGAGCI4gTprzgr en9Ayrn/nVUwXDwa0qSpVOIUFbMnwqJhc7mga3AoYfzWnoXzxmHUfc4HfwDdZH/A9N7M 2pnQ==
X-Gm-Message-State: AODbwcDIZbacplXxUIhs53+yCiv+KCL6LrQB9duYiISueiDXqtD9n2La wifE2goqChK5B/75xlGrVr/dOZmrYw==
X-Received: by 10.36.242.1 with SMTP id j1mr8481033ith.115.1494216097664; Sun, 07 May 2017 21:01:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.161.143 with HTTP; Sun, 7 May 2017 21:01:37 -0700 (PDT)
In-Reply-To: 
References: 
From: Satish K 
Date: Mon, 8 May 2017 09:31:37 +0530
Message-ID: 
To: Jonathan Hardwick 
Cc: "pce@ietf.org" ,  "draft-dhody-pce-applicability-actn@ietf.org" ,  "pce-chairs@ietf.org" 
Content-Type: multipart/alternative; boundary=94eb2c121ebeb8153a054efb4b9d
Archived-At: 
Subject: Re: [Pce] Poll for adoption: draft-dhody-pce-applicability-actn-02
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 May 2017 04:01:40 -0000

--94eb2c121ebeb8153a054efb4b9d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Yes/Support

Thanks,
Satish


On Tue, Apr 25, 2017 at 9:55 PM, Jonathan Hardwick <
Jonathan.Hardwick@metaswitch.com> wrote:

> All,
>
>
>
> This is the start of a two week poll on making
> draft-dhody-pce-applicability-actn-02 a PCE working group document.
>
> https://datatracker.ietf.org/doc/draft-dhody-pce-applicability-actn/
>
>
>
> Please review the draft and send an email to the list indicating
> =E2=80=9Cyes/support=E2=80=9D or =E2=80=9Cno/do not support=E2=80=9D.  If=
 indicating no, please state your
> reasons.  If yes, please also feel free to provide comments you'd like to
> see addressed once the document is a WG document.
>
>
>
> The poll ends on Tuesday, May 9.
>
>
>
> Many thanks,
>
> Jon
>
>
>
>
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
>

--94eb2c121ebeb8153a054efb4b9d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Yes/Support

Thanks,
Satish=



On Tue, Apr 25, 2017 at 9:55 PM, Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com> wrote:











All,


=C2=A0


This is the start of a two week poll on making draft=
-dhody-pce-applicability-actn-02 a PCE working group document.<=
u>


https://datatracker.ietf.org=
/doc/draft-dhody-pce-applicability-actn/


=C2=A0


Please review the draft and=
 send an email to the list indicating =E2=80=9Cyes/support=E2=80=9D or =E2=
=80=9Cno/do not support=E2=80=9D.=C2=A0 If indicating no, please state your=
 reasons.=C2=A0 If yes, please also feel free to provide comments you'd=
 like to see addressed once
 the document is a WG document.


=C2=A0


The poll ends on Tuesday, M=
ay 9.


=C2=A0


Many thanks,<=
/p>

Jon


=C2=A0


=C2=A0







_______________________________________________

Pce mailing list

Pce@ietf.org

https://www.ietf.org/mailman/listinfo/pce





--94eb2c121ebeb8153a054efb4b9d--


From nobody Mon May  8 09:19:16 2017
Return-Path: 
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40458126C0F for ; Mon,  8 May 2017 09:19:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=metaswitch.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0t1FtNZ0zU9d for ; Mon,  8 May 2017 09:19:11 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0096.outbound.protection.outlook.com [104.47.34.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D70812441E for ; Mon,  8 May 2017 09:19:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZqHSnYUqRi5Bab+DphCWCHJ77fmNkmme6PO1r9ydLhs=; b=loULrwJ5dOsE5O7IuTHIpXDnQHEPMgM8fnAFMAX0L5dedaUNVrxY0Qk4kQtKcM6edBye2OAcKdbuOeOYRSXpm4kN0prcDRHafk4FwLaEmA8oWx0tLIvrW8CUZ1zg5Tui+wSUwNK+iMybytgSMYGvhKXuCEV+iWYzXRRQ0oZSOz8=
Received: from BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) by BY2PR0201MB1909.namprd02.prod.outlook.com (10.163.75.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.11; Mon, 8 May 2017 16:19:09 +0000
Received: from BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) by BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) with mapi id 15.01.1075.019; Mon, 8 May 2017 16:19:09 +0000
From: Jonathan Hardwick 
To: "pce@ietf.org" 
Thread-Topic: Stateful PCE: inconsistency in "resource limit" text
Thread-Index: AdLIFcW0FlKFj/hRS7i+bnJA6UAqeA==
Date: Mon, 8 May 2017 16:19:08 +0000
Message-ID: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=metaswitch.com;
x-originating-ip: [86.132.79.244]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2PR0201MB1909; 7:48VfG7c/CE7oZcHgxFE/UQsNHIeXZ7JHl0Qsf4cVJ0KAy3PosmCG1EB2PKmfTAZOiPm0Eko20a3ZNWBJviPQxPJINTJJ4xKgwMG/8/dmqCy8TsEoFlFnJmbK/hYxaw5ocQnBPc8AMIDvmC9TTs0uBtAg3wgf0lG9SXQyc43S7eUzddHIcBLE41eu7nx+N8TgjXKRMm77hQWGNlcbDZNlNpkJq2vAvW2bYLz8qbe8gKZGwGdcftC8axR7GWRWq8ylJVqDGToeFTq2X+7alqq/SGZ+cT7MH2ngUl8vy6KRh69GVG8koXMF0JCxXxcl6M7RoZgUmYH9B5HV1D63XgIK8Q==
x-ms-office365-filtering-correlation-id: 32251b33-721f-4be2-1145-08d4962df4c7
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BY2PR0201MB1909; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123558100)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(6072148); SRVR:BY2PR0201MB1909; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0201MB1909; 
x-forefront-prvs: 0301360BF5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39450400003)(39410400002)(39400400002)(60444003)(66654002)(33656002)(86362001)(5630700001)(1730700003)(8676002)(81166006)(478600001)(5660300001)(8936002)(7696004)(189998001)(4326008)(50986999)(54356999)(66066001)(2900100001)(9686003)(54896002)(3660700001)(38730400002)(74316002)(53936002)(7736002)(6306002)(25786009)(6116002)(99286003)(102836003)(790700001)(3846002)(2906002)(6506006)(6436002)(2351001)(77096006)(3280700002)(110136004)(2501003)(5640700003)(122556002)(6916009)(55016002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0201MB1909; H:BY2PR0201MB1910.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR0201MB1910A2EEBAD7BB4F0E236C5584EE0BY2PR0201MB1910_"
MIME-Version: 1.0
X-OriginatorOrg: metaswitch.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2017 16:19:08.7371 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1909
Archived-At: 
Subject: [Pce] Stateful PCE: inconsistency in "resource limit" text
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 May 2017 16:19:13 -0000

--_000_BY2PR0201MB1910A2EEBAD7BB4F0E236C5584EE0BY2PR0201MB1910_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi PCE WG

I've been tidying up the stateful PCE draft to prepare it for publication a=
nd I have discovered an inconsistency in how the stateful PCE is supposed t=
o handle an overflow of its per-PCC resource limit.  In section 5.6 it says=
:

   A PCE implementing a limit on the resources a single PCC can occupy,
   MUST send a PCNtf message with Notification Type to be allocated by
   IANA (Stateful PCE resource limit exceeded) and Notification Value to
   be allocated by IANA (Entering resource limit exceeded state) in
   response to the PCRpt message triggering this condition in the
   synchronization phase and MUST terminate the session.

Whereas in section 6.1 it says:


   A PCE may choose to implement a limit on the resources a single PCC

   can occupy.  If a PCRpt is received that causes the PCE to exceed

   this limit, the PCE MUST notify the PCC using a PCNtf message with

   Notification Type to be allocated by IANA (Stateful PCE resource

   limit exceeded) and Notification Value to be allocated by IANA

   (Entering resource limit exceeded state) and MAY terminate the

   session.

These sections are inconsistent because the first says the PCE MUST termina=
te the session whereas the second says the PCE MAY terminate the session.

Furthermore, in section 8.6, the following notification is defined for "exi=
ting resource limit exceeded state", but this notification is not reference=
d anywhere in the text.


    Notification-Type  Meaning

       4        Stateful PCE resource limit exceeded

                 Notification-value=3D2:   Exiting resource limit exceeded

                                         state

Please could I ask all implementers:

-        MUST the PCE terminate the session if its state limit is exceeded,=
 or MAY it leave it open?

-        Has anybody implemented the "exiting resource limit exceeded state=
" notification?  If so, how are you using it?

Your swiftest answers would be very much appreciated!

If I don't get any contradictory replies, my default action will be to say =
that the session MUST be terminated and to remove the unreferenced notifica=
tion-value.

Many thanks
Jon


--_000_BY2PR0201MB1910A2EEBAD7BB4F0E236C5584EE0BY2PR0201MB1910_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi PCE WG


 


I’ve been tidying up the stateful PCE draft to=
 prepare it for publication and I have discovered an inconsistency in how t=
he stateful PCE is supposed to handle an overflow of its per-PCC resource l=
imit.  In section 5.6 it says:


 


   A PCE implementing=
 a limit on the resources a single PCC can occupy,


   MUST send a PCNtf =
message with Notification Type to be allocated by


   IANA (Stateful PCE=
 resource limit exceeded) and Notification Value to


   be allocated by IA=
NA (Entering resource limit exceeded state) in


   response to the PC=
Rpt message triggering this condition in the


   synchronization ph=
ase
and MUST terminate the session.=



 


Whereas in section 6.1 it says:


 


   A PCE may choose to implement a limit on the resources a =
single PCC


   can occupy.  If a PCRpt is received that causes the =
PCE to exceed


   this limit, the PCE MUST notify the PCC using a PCNtf mes=
sage with


   Notification Type to be allocated by IANA (Stateful PCE r=
esource


   limit exceeded) and Notification Value to be allocated by=
 IANA


   (Entering resource limit exceeded state) and MAY terminate the


   session.

 


These sections are inconsistent because the first sa=
ys the PCE MUST terminate the session whereas the second says the PCE MAY t=
erminate the session.


 


Furthermore, in section 8.6, the following notificat=
ion is defined for “exiting resource limit exceeded state”, but=
 this notification is not referenced anywhere in the text.


 


    Notification-Type  Meaning


       4     &n=
bsp;  Stateful PCE resource limit exceeded


           &nbs=
p;     Notification-value=3D2:   Exiting reso=
urce limit exceeded


           &nbs=
p;            &=
nbsp;           &nbs=
p;    state


 


Please could I ask all implementers:


-     &=
nbsp; 
MUST the PCE terminate the session if its state lim=
it is exceeded, or MAY it leave it open?


-     &=
nbsp; 
Has anybody implemented the “exiting resource=
 limit exceeded state” notification?  If so, how are you using i=
t?


 


Your swiftest answers would be very much appreciated=
!


 


If I don’t get any contradictory replies, my d=
efault action will be to say that the session MUST be terminated and to rem=
ove the unreferenced notification-value.


 


Many thanks


Jon


 






--_000_BY2PR0201MB1910A2EEBAD7BB4F0E236C5584EE0BY2PR0201MB1910_--


From nobody Mon May  8 11:11:12 2017
Return-Path: 
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD2C12896F for ; Mon,  8 May 2017 11:11:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.811
X-Spam-Level: 
X-Spam-Status: No, score=0.811 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqOtgtaPsFTH for ; Mon,  8 May 2017 11:11:06 -0700 (PDT)
Received: from cica-lavadora-l1mail2.puc.rediris.es (arce.puc.rediris.es [IPv6:2001:720:418:ca02::18]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69027129566 for ; Mon,  8 May 2017 11:11:05 -0700 (PDT)
X-IPAS-Result: =?us-ascii?q?A+ApBAAxtBBZjLBAASCH4YnAINCAz3+P8oj2FFweBgyDD4E?= =?us-ascii?q?roGCYAYYkAoRlVwECAQEBAQECEwEBASZXhRYBAgIBLUcVCw05VxMIAQGKFAkDA?= =?us-ascii?q?bVbJgIDikoBAQgBAQEBJIZfgV4rgnCENQuGDAEEnXmCEIg/iEmCBIU8g0MXhlK?= =?us-ascii?q?MEIguVoELT4YAgW4DhyOCPAEBAQ?=
X-IronPort-AV: E=Sophos; i="5.38,310,1491256800"; d="scan'208,217"; a="77929764"
Received: from unknown (HELO leo.cttc.es) ([IPv6:2001:40b0:7c22:6020:a00:27ff:fe42:3b14]) by smtpout.puc.rediris.es with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 May 2017 20:11:02 +0200
Received: from [192.168.1.130] (253.45.133.37.dynamic.jazztel.es [37.133.45.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by leo.cttc.es (Postfix) with ESMTPSA id 232AD1FDB7 for ; Mon,  8 May 2017 20:11:01 +0200 (CEST)
To: pce@ietf.org
References: 
From: Ramon Casellas 
Message-ID: 
Date: Mon, 8 May 2017 20:11:01 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Thunderbird/53.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------B6082737BD3450EB11A0BBCB"
Content-Language: en-US
Archived-At: 
Subject: Re: [Pce] Stateful PCE: inconsistency in "resource limit" text
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 May 2017 18:11:11 -0000

This is a multi-part message in MIME format.
--------------B6082737BD3450EB11A0BBCB
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Hi all,

FWIW
>
> Please could I ask all implementers:
>
> -MUST the PCE terminate the session if its state limit is exceeded, or 
> MAY it leave it open?
>
Honestly, I am not 100% sure, although I may be more in favor of : MUST 
terminate the session

Rationale:
I am assuming resources in the"pce" process (as in memory, CPU cycles ... )

1) If it is a soft-limit or a PCE transient state, it MAY leave it open. 
Leaving it open suggests that the PCC can retry / resend at a later 
stage that PCRpt in order to hopefully complete the sync. That would 
mean using PCNtf as NACK - maybe not adequate.

2) if it is a hard limit (as it seems to be the case -- note that it is 
not stated how a PCC can discover its limits --) leaving it open and the 
PCNtf it tells the PCC it hit a limit. The PCC could proceed assuming 
that it can report "up to N" and consider the sync done. Deducing this 
by repeatedly setting up sessions is IMHO more complex. However, not 
sure of the implications of having partial LSPDB sync

3) Re-reading the relevant sections,  error cases in the section seem to 
explicitly state "MUST close the session". If hitting a hard limit is an 
error, it MUST terminate the session (uniform). The question then is 
"why is the PCE sending a PCNtf and not a PCErr in that case"? AFAIK 
PCNtf seems to be more permissive.


> -Has anybody implemented the exiting resource limit exceeded state 
> notification?  If so, how are you using it?
>
No. Currently, we only track the "number of LSPs reported per PCC" but 
without actual per PCC limits

>
> If I dont get any contradictory replies, my default action will be to 
> say that the session MUST be terminated and to remove the unreferenced 
> notification-value.
>
Would you consider changing the PCNtf to PCErr ?

Regards
Ramon


--------------B6082737BD3450EB11A0BBCB
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi all,

    

    FWIW

    
    

      

        
Please could I ask all implementers:

        
-
            MUST the PCE terminate the
          session if its state limit is exceeded, or MAY it leave it
          open?

      

    

    Honestly, I am not 100% sure, although I may be more in favor of :
    MUST terminate the session

    

    Rationale: 

    I am assuming resources in the"pce" process (as in memory, CPU
    cycles ... )

    

    1) If it is a soft-limit or a PCE transient state, it MAY leave it
    open. Leaving it open suggests that the PCC can retry / resend at a
    later stage that PCRpt in order to hopefully complete the sync. That
    would mean using PCNtf as NACK - maybe not adequate.

    

    2) if it is a hard limit (as it seems to be the case -- note that it
    is not stated how a PCC can discover its limits --) leaving it open
    and the PCNtf it tells the PCC it hit a limit. The PCC could proceed
    assuming that it can report "up to N" and consider the sync done.
    Deducing this by repeatedly setting up sessions is IMHO more
    complex. However, not sure of the implications of having partial
    LSPDB sync

    

    3) Re-reading the relevant sections, error cases in the section
    seem to explicitly state "MUST close the session". If hitting a hard
    limit is an error, it MUST terminate the session (uniform). The
    question then is "why is the PCE sending a PCNtf and not a PCErr in
    that case"? AFAIK PCNtf seems to be more permissive.

    

    

    

      

        
-
            Has anybody implemented the
          exiting resource limit exceeded state notification? If so,
          how are you using it?

      

    

    No. Currently, we only track the "number of LSPs reported per PCC"
    but without actual per PCC limits

    

    

      

        

        

        
If I dont get any contradictory replies,
          my default action will be to say that the session MUST be
          terminated and to remove the unreferenced notification-value.

      

    

    Would you consider changing the PCNtf to PCErr ? 

    

    Regards

    Ramon

    

  


--------------B6082737BD3450EB11A0BBCB--


From nobody Mon May  8 14:09:43 2017
Return-Path: 
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D48124B0A for ; Mon,  8 May 2017 14:09:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaXcIqho1kka for ; Mon,  8 May 2017 14:09:40 -0700 (PDT)
Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F0881201F8 for ; Mon,  8 May 2017 14:09:40 -0700 (PDT)
Received: by mail-qk0-x22f.google.com with SMTP id k74so63652730qke.1 for ; Mon, 08 May 2017 14:09:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dQ6m7dVcObsfiBAQJ1URewRyADP5ny6HPSnfmthJNSQ=; b=CvEakdOLX+XhNM8yiLyNzb1CQB0+xSFIQnCWryqWLgwHoFv1bBrcojXxDApiCChIm6 DpXp1FeFb0rc3IN2e6yOJzLLSpc4TvicnFRL76j8dNDYzpls3Gvw8aM+M/VcZhBSd0nH dRtwVNUWmiyh5qAfBb/9hxOPCQssvgUyY8JLqbe//N35txHvszIwMG68bPSv8k4NPKiw 7ierPPZFQMdekK9wSqdccIEEjTaVvNYJTP+4236a7Jlw3aotge/x0eCT5tuCEwggoG7h nDefi6394TCJLNAX4rJPaeDNrX/s0tqu5jwQnCkAgETEtDGEkvBUOyI2UvIdBca7hlWI TQgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dQ6m7dVcObsfiBAQJ1URewRyADP5ny6HPSnfmthJNSQ=; b=A41D5b7CLkG5z8C/KMKaqBWQ5fR//8MU0fKli1e9cAkw5ydCdNiThzmKqRQrCQM3Ny oitzfhYg8h/OpgfgGqR8BS8BngBQf3BVLNqH2l8CRUbV9IE7c+2RCzaUGyh8tqVFTpeT fqO/y3wE5ORVG3CXlz8MsEqBIbr/DCLlqzlX6q8AVmC7oiFECN88Uugx+CHG9a9IBY52 0e/9eznryh+TUpvUemX6CFgjl/bKSfBVY4odDea+aVU2Rjd6F6/XTqgHD2dIRMbZ4LNA zaww4fnhkMhql93/xVIqwLX3XAePfim/CPLazEXLXRDomJi21eDS8uE67sZybhIarwmq 8FpQ==
X-Gm-Message-State: AODbwcCeBIURTJVhWK17ONUlAun7dTvSBmPqA6X8/99WkyEkOJJKvOjz EcNk4EMJ2GYDQV/KzjOuOnmbDbueqg==
X-Received: by 10.55.157.198 with SMTP id g189mr10574444qke.111.1494277779586;  Mon, 08 May 2017 14:09:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.154.145 with HTTP; Mon, 8 May 2017 14:09:39 -0700 (PDT)
In-Reply-To: 
References: 
From: Cyril Margaria 
Date: Mon, 8 May 2017 17:09:39 -0400
Message-ID: 
To: Jonathan Hardwick 
Cc: "pce@ietf.org" 
Content-Type: multipart/alternative; boundary=94eb2c06d7f43f824f054f09a882
Archived-At: 
Subject: Re: [Pce] Stateful PCE: inconsistency in "resource limit" text
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 May 2017 21:09:42 -0000

--94eb2c06d7f43f824f054f09a882
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

>From what I recall, the limit exceeded can refer to the number of LSPs,
memory, ..etc and the notification was introduced to support the same logic
as rfc5440 "Overloaded PCE" notification.

To keep that and to support soft/administrative limits, I am in favor of
MAY terminate the session. If the Peer decides to terminate the session, a
specific code must be used, otherwise the other peer will reconnect and the
session will keep flapping.

BR,
Cyril

On 8 May 2017 at 12:19, Jonathan Hardwick 
wrote:

> Hi PCE WG
>
>
>
> I=E2=80=99ve been tidying up the stateful PCE draft to prepare it for pub=
lication
> and I have discovered an inconsistency in how the stateful PCE is suppose=
d
> to handle an overflow of its per-PCC resource limit.  In section 5.6 it
> says:
>
>
>
>    A PCE implementing a limit on the resources a single PCC can occupy,
>
>    MUST send a PCNtf message with Notification Type to be allocated by
>
>    IANA (Stateful PCE resource limit exceeded) and Notification Value to
>
>    be allocated by IANA (Entering resource limit exceeded state) in
>
>    response to the PCRpt message triggering this condition in the
>
>    synchronization phase and MUST terminate the session.
>
>
>
> Whereas in section 6.1 it says:
>
>
>
>    A PCE may choose to implement a limit on the resources a single PCC
>
>    can occupy.  If a PCRpt is received that causes the PCE to exceed
>
>    this limit, the PCE MUST notify the PCC using a PCNtf message with
>
>    Notification Type to be allocated by IANA (Stateful PCE resource
>
>    limit exceeded) and Notification Value to be allocated by IANA
>
>    (Entering resource limit exceeded state) and MAY terminate the
>
>    session.
>
>
>
> These sections are inconsistent because the first says the PCE MUST
> terminate the session whereas the second says the PCE MAY terminate the
> session.
>
>
>
> Furthermore, in section 8.6, the following notification is defined for
> =E2=80=9Cexiting resource limit exceeded state=E2=80=9D, but this notific=
ation is not
> referenced anywhere in the text.
>
>
>
>     Notification-Type  Meaning
>
>        4        Stateful PCE resource limit exceeded
>
>                  Notification-value=3D2:   Exiting resource limit exceede=
d
>
>                                          state
>
>
>
> Please could I ask all implementers:
>
> -        MUST the PCE terminate the session if its state limit is
> exceeded, or MAY it leave it open?
>
> -        Has anybody implemented the =E2=80=9Cexiting resource limit exce=
eded
> state=E2=80=9D notification?  If so, how are you using it?
>
>
>
> Your swiftest answers would be very much appreciated!
>
>
>
> If I don=E2=80=99t get any contradictory replies, my default action will =
be to say
> that the session MUST be terminated and to remove the unreferenced
> notification-value.
>
>
>
> Many thanks
>
> Jon
>
>
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
>

--94eb2c06d7f43f824f054f09a882
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,=C2=A0

From what I recall, the limit=
 exceeded can refer to the number of LSPs, memory, ..etc and the notificati=
on was introduced to support the same logic as rfc5440 "Overloaded PCE" notification.

To keep that and to support soft/administrat=
ive limits, I am in favor of MAY terminate the session. If the Peer decides=
 to terminate the session, a specific code must be used, otherwise the othe=
r peer will reconnect and the session will keep flapping.

BR,
Cyril

On 8 May 2017 at 12:19, Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com> wrote:











Hi PCE WG


=C2=A0


I=E2=80=99ve been tidying up the stateful PCE draft =
to prepare it for publication and I have discovered an inconsistency in how=
 the stateful PCE is supposed to handle an overflow of its per-PCC resource=
 limit.=C2=A0 In section 5.6 it says:


=C2=A0


=C2=A0=C2=A0 A PCE implementing a limit on the resources a=
 single PCC can occupy,


=C2=A0=C2=A0 MUST send a PCNtf message with Notification T=
ype to be allocated by


=C2=A0=C2=A0 IANA (Stateful PCE resource limit exceeded) a=
nd Notification Value to


=C2=A0=C2=A0 be allocated by IANA (Entering resource limit=
 exceeded state) in


=C2=A0=C2=A0 response to the PCRpt message triggering this=
 condition in the


=C2=A0=C2=A0 synchronization phase
and MUST terminate the session.<=
/u>


=C2=A0


Whereas in section 6.1 it says:


=C2=A0


=C2=A0=C2=A0 A PCE may choose to implement a limit on the resources a =
single PCC


=C2=A0=C2=A0 can occupy.=C2=A0 If a PCRpt is received that causes the =
PCE to exceed


=C2=A0=C2=A0 this limit, the PCE MUST notify the PCC using a PCNtf mes=
sage with


=C2=A0=C2=A0 Notification Type to be allocated by IANA (Stateful PCE r=
esource


=C2=A0=C2=A0 limit exceeded) and Notification Value to be allocated by=
 IANA


=C2=A0=C2=A0 (Entering resource limit exceeded state) and MAY terminate the


=C2=A0=C2=A0 session.

=C2=A0


These sections are inconsistent because the first sa=
ys the PCE MUST terminate the session whereas the second says the PCE MAY t=
erminate the session.


=C2=A0


Furthermore, in section 8.6, the following notificat=
ion is defined for =E2=80=9Cexiting resource limit exceeded state=E2=80=9D,=
 but this notification is not referenced anywhere in the text.


=C2=A0


=C2=A0=C2=A0=C2=A0 Notification-Type=C2=A0 Meaning


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 4=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 Stateful PCE resource limit exceeded


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 Notification-value=3D2:=C2=A0=C2=A0 Exiting res=
ource limit exceeded


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 state


=C2=A0


Please could I ask all implementers:

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0
MUST the PCE terminate the session if its state limit =
is exceeded, or MAY it leave it open?


-=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0
Has anybody implemented the =E2=80=9Cexiting resource =
limit exceeded state=E2=80=9D notification?=C2=A0 If so, how are you using =
it?


=C2=A0


Your swiftest answers would be very much appreciated=
!


=C2=A0


If I don=E2=80=99t get any contradictory replies, my=
 default action will be to say that the session MUST be terminated and to r=
emove the unreferenced notification-value.


=C2=A0


Many thanks


Jon


=C2=A0







_______________________________________________

Pce mailing list

Pce@ietf.org

https://www.ietf.org/mailman/listinfo/pce





--94eb2c06d7f43f824f054f09a882--


From nobody Mon May  8 23:22:30 2017
Return-Path: 
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B551B129ADE for ; Mon,  8 May 2017 23:22:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Level: 
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQoob6ZMLSXH for ; Mon,  8 May 2017 23:22:25 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E60321200ED for ; Mon,  8 May 2017 23:22:24 -0700 (PDT)
Received: from [192.168.0.103] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 0CAC318014F3; Tue,  9 May 2017 08:22:23 +0200 (CEST)
To: "Rakesh Gandhi (rgandhi)" , "pce@ietf.org" 
References: <149393325240.6861.15801464215162854394@ietfa.amsl.com> <7786d1a8-6933-9f02-15c3-0a8f0a46b3d1@pi.nu> <11EBFD0D-EA15-4003-95CB-B20265E68CF5@cisco.com>
From: Loa Andersson 
Message-ID: <4353489d-eaec-6c65-5ed0-e8445b8cd9b7@pi.nu>
Date: Tue, 9 May 2017 08:22:21 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <11EBFD0D-EA15-4003-95CB-B20265E68CF5@cisco.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Pce] IPR Disclosure Cisco's Statement about IPR related to draft-ietf-pce-stateful-pce-auto-bandwidth
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 May 2017 06:22:29 -0000

Rakesh,

inline please.

On 2017-05-05 19:37, Rakesh Gandhi (rgandhi) wrote:
> Hi Loa,
>
> Please see inline with .
>
> On 2017-05-05, 4:22 AM, "Pce on behalf of Loa Andersson"  wrote:
>
>     Folks,
>
>     I see no problem progressing this draft, the licensing terms are OK.
>
>  Great, thanks.
>
>     However there is another problem.
>
>     The disclosed IPR was applied for in 2006, and granted 2011. The draft
>     was first posted in early 2013. What is the explanation for this late
>     disclosure?
>
>  This was disclosed as soon as an author learned about it.

OK - fair enough, tnx for the disclosure. At the same time I take this
to mean that no inventor are subscribed to the PCE working group mailing
list.

/Loa
>
> Thanks,
> Rakesh
>
>
>
>     /Loaq
>
>
>     On 2017-05-04 23:27, IETF Secretariat wrote:
>     > Dear Dhruv Dhody, Rakesh Gandhi, Ravi Singh, Luyuan Fang, Udayasree Palle:
>     >
>     >
>     > An IPR disclosure that pertains to your Internet-Draft entitled "PCEP
>     > Extensions for MPLS-TE LSP Automatic Bandwidth Adjustment with Stateful
>     > PCE" (draft-ietf-pce-stateful-pce-auto-bandwidth) was submitted to the IETF
>     > Secretariat on  and has been posted on the "IETF Page of Intellectual Property
>     > Rights Disclosures" (https://datatracker.ietf.org/ipr/2996/). The title of the
>     > IPR disclosure is "Cisco's Statement about IPR related to
>     > draft-ietf-pce-stateful-pce-auto-bandwidth"
>     >
>     >
>     > Thank you
>     >
>     > IETF Secretariat
>     >
>     > _______________________________________________
>     > Pce mailing list
>     > Pce@ietf.org
>     > https://www.ietf.org/mailman/listinfo/pce
>     >
>
>     --
>
>
>     Loa Andersson                        email: loa@mail01.huawei.com
>     Senior MPLS Expert                          loa@pi.nu
>     Huawei Technologies (consultant)     phone: +46 739 81 21 64
>
>     _______________________________________________
>     Pce mailing list
>     Pce@ietf.org
>     https://www.ietf.org/mailman/listinfo/pce
>
>

-- 


Loa Andersson                        email: loa@mail01.huawei.com
Senior MPLS Expert                          loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64


From nobody Tue May  9 01:35:32 2017
Return-Path: 
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1D9129B39 for ; Tue,  9 May 2017 01:35:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.235
X-Spam-Level: 
X-Spam-Status: No, score=-0.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTX3HfGy3rDp for ; Tue,  9 May 2017 01:35:30 -0700 (PDT)
Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [161.106.1.3]) by ietfa.amsl.com (Postfix) with ESMTP id C5772129412 for ; Tue,  9 May 2017 01:35:29 -0700 (PDT)
Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 40323E300A4; Tue,  9 May 2017 10:35:28 +0200 (CEST)
Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail2.rd.orange.com (Postfix) with ESMTP id 25AFBE3009F; Tue,  9 May 2017 10:35:28 +0200 (CEST)
Received: from [10.193.71.226] (10.193.71.226) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.319.2; Tue, 9 May 2017 10:35:27 +0200
To: Jonathan Hardwick 
References:  
CC: Cyril Margaria , "pce@ietf.org" 
From: Julien Meuric 
Organization: Orange
Message-ID: <24b92f98-0702-a2d9-ac36-ab257a128e4c@orange.com>
Date: Tue, 9 May 2017 10:35:25 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Pce] Stateful PCE: inconsistency in "resource limit" text
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 May 2017 08:35:31 -0000

Hi Ramon,

Indeed, the I-D used to consider an error for this case, but RFC 5440
gives the pace and 2 codepoints were allocated:
- PCErr are associated to PCEP issues ("when a protocol error condition
is met or when the request is not compliant with the PCEP specification");
- PCNtf are typically used for other cases, including PCE state (e.g.
overload) and policy (e.g. threshold).

Please note also that the current (orphan) text of the I-D allows to use
the PCNtf for "Exiting resource limit exceeded state". I am not saying
the latter should be kept, but considering this option sustains the idea
of having 2 possible messages/behaviors in PCEP.

Thanks for your feedback,

Julien


May. 08, 2017 - cyril.margaria@gmail.com:
> Hi, 
>
> From what I recall, the limit exceeded can refer to the number of
> LSPs, memory, ..etc and the notification was introduced to support the
> same logic as rfc5440 "Overloaded PCE" notification.
>
> To keep that and to support soft/administrative limits, I am in favor
> of MAY terminate the session. If the Peer decides to terminate the
> session, a specific code must be used, otherwise the other peer will
> reconnect and the session will keep flapping.
>
> BR,
> Cyril
>
> On 8 May 2017 at 12:19, Jonathan Hardwick
>  > wrote:
>
>     Hi PCE WG
>
>      
>
>     Ive been tidying up the stateful PCE draft to prepare it for
>     publication and I have discovered an inconsistency in how the
>     stateful PCE is supposed to handle an overflow of its per-PCC
>     resource limit.  In section 5.6 it says:
>
>      
>
>        A PCE implementing a limit on the resources a single PCC can
>     occupy,
>
>        MUST send a PCNtf message with Notification Type to be allocated by
>
>        IANA (Stateful PCE resource limit exceeded) and Notification
>     Value to
>
>        be allocated by IANA (Entering resource limit exceeded state) in
>
>        response to the PCRpt message triggering this condition in the
>
>        synchronization phase and MUST terminate the session.
>
>      
>
>     Whereas in section 6.1 it says:
>
>      
>
>        A PCE may choose to implement a limit on the resources a single PCC
>
>        can occupy.  If a PCRpt is received that causes the PCE to exceed
>
>        this limit, the PCE MUST notify the PCC using a PCNtf message with
>
>        Notification Type to be allocated by IANA (Stateful PCE resource
>
>        limit exceeded) and Notification Value to be allocated by IANA
>
>        (Entering resource limit exceeded state) and MAY terminate the
>
>        session.
>
>      
>
>     These sections are inconsistent because the first says the PCE
>     MUST terminate the session whereas the second says the PCE MAY
>     terminate the session.
>
>      
>
>     Furthermore, in section 8.6, the following notification is defined
>     for exiting resource limit exceeded state, but this notification
>     is not referenced anywhere in the text.
>
>      
>
>         Notification-Type  Meaning
>
>            4        Stateful PCE resource limit exceeded
>
>                      Notification-value=2:   Exiting resource limit exceeded
>
>                                              state
>
>      
>
>     Please could I ask all implementers:
>
>     -        MUST the PCE terminate the session if its state limit is
>     exceeded, or MAY it leave it open?
>
>     -        Has anybody implemented the exiting resource limit
>     exceeded state notification?  If so, how are you using it?
>
>      
>
>     Your swiftest answers would be very much appreciated!
>
>      
>
>     If I dont get any contradictory replies, my default action will
>     be to say that the session MUST be terminated and to remove the
>     unreferenced notification-value.
>
>      
>
>     Many thanks
>
>     Jon
>
>      
>
>     _______________________________________________ Pce mailing list
>     Pce@ietf.org 
>     https://www.ietf.org/mailman/listinfo/pce
>      
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce


From nobody Tue May  9 01:51:15 2017
Return-Path: 
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1E151243FE for ; Tue,  9 May 2017 01:51:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.01
X-Spam-Level: 
X-Spam-Status: No, score=0.01 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9d7oaz5IAX1o for ; Tue,  9 May 2017 01:51:09 -0700 (PDT)
Received: from cica-lavadora-l1mail1v.puc.rediris.es (adrastea.puc.rediris.es [IPv6:2001:720:418:ca02::11]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F69A12946C for ; Tue,  9 May 2017 01:51:09 -0700 (PDT)
X-IPAS-Result: =?us-ascii?q?A2AuAQCGghFZjNA+WFRbHQEFAQsBgm6QVpFXlXKCD4YkAoR?= =?us-ascii?q?nPxgBAgEBAQEBAQETAQEBJleFFgECA4EJCxguVxMIAQGKIQG0WSuKTDKGX4FeK?= =?us-ascii?q?4JwhDULhgwFngOCEJEJggSFO4NDhmmMEYgvHzeBC0+GAIFxhy2CPAEBAQ?=
X-IronPort-AV: E=Sophos; i="5.38,313,1491256800"; d="scan'208,217"; a="56348577"
Received: from leo.cttc.es ([84.88.62.208]) by smtpout.puc.rediris.es with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 May 2017 10:50:09 +0200
Received: from [84.88.61.50] (unknown [84.88.61.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by leo.cttc.es (Postfix) with ESMTPSA id 68AC01FDD0 for ; Tue,  9 May 2017 10:50:08 +0200 (CEST)
To: pce@ietf.org
References:   <24b92f98-0702-a2d9-ac36-ab257a128e4c@orange.com>
From: Ramon Casellas 
Message-ID: <858927fd-6a06-0d10-6c24-1dc6a3faa80c@cttc.es>
Date: Tue, 9 May 2017 10:50:06 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Thunderbird/53.0
MIME-Version: 1.0
In-Reply-To: <24b92f98-0702-a2d9-ac36-ab257a128e4c@orange.com>
Content-Type: multipart/alternative; boundary="------------F3480DA0055B95043515ED90"
Content-Language: en-US
Archived-At: 
Subject: Re: [Pce] Stateful PCE: inconsistency in "resource limit" text
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 May 2017 08:51:13 -0000

This is a multi-part message in MIME format.
--------------F3480DA0055B95043515ED90
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

On 9/5/17 10:35, Julien Meuric wrote:
> Hi Ramon,
>
> Indeed, the I-D used to consider an error for this case, but RFC 5440
> gives the pace and 2 codepoints were allocated:
> - PCErr are associated to PCEP issues ("when a protocol error condition
> is met or when the request is not compliant with the PCEP specification");
> - PCNtf are typically used for other cases, including PCE state (e.g.
> overload) and policy (e.g. threshold).
>
> Please note also that the current (orphan) text of the I-D allows to use
> the PCNtf for "Exiting resource limit exceeded state". I am not saying
> the latter should be kept, but considering this option sustains the idea
> of having 2 possible messages/behaviors in PCEP.

Hi Julien,

This is indeed making me raise more questions than expected.

- Reading the section I got the feeling that any event preventing to 
reach full sync state caused a PCErr (now PCNtf) and a MUST session 
close. was it the intent?

- As a minor comment, I see your point on the PCErr / PCNtf "macroscopic 
use", although I would humbly object, notably in view of the whole PCErr 
5: policy violation, that includes cases such as "global concurrent 
optimization not allowed" or "objective function not allowed" so, while 
I can agree with your view, IMHO it is not black/white.
In particular, I think you are not fully quoting RFC5440

    The PCEP Error message (also referred to as a PCErr message) is sent
    in several situations: when a protocol error condition is met or when
    the request is not compliant with the PCEP specification (e.g.,
    reception of a malformed message, reception of a message with a
    mandatory missing object, policy violation, unexpected message,
    unknown request reference)


It seems to me that policiy violation is a PCErr.  However, the main 
question is:

- Is not reaching full sync considered a protocol error? (for whatever 
reason, and beyond a single message exchange but more as a transactional 
thing/sequence)  If yes, I would vote for a PCErr / MUST close

- If it is not an error (I am not fully aware of the implications) then 
we should allow PCNtf + MAY leave it open. Otherwise, my view remains 
PCErr + MUST close.

Thanks!
Ramon




--------------F3480DA0055B95043515ED90
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 9/5/17 10:35, Julien Meuric wrote:

    

    

      
Hi Ramon,

Indeed, the I-D used to consider an error for this case, but RFC 5440
gives the pace and 2 codepoints were allocated:
- PCErr are associated to PCEP issues ("when a protocol error condition
is met or when the request is not compliant with the PCEP specification");
- PCNtf are typically used for other cases, including PCE state (e.g.
overload) and policy (e.g. threshold).

Please note also that the current (orphan) text of the I-D allows to use
the PCNtf for "Exiting resource limit exceeded state". I am not saying
the latter should be kept, but considering this option sustains the idea
of having 2 possible messages/behaviors in PCEP.


    

    

    Hi Julien, 

    

    This is indeed making me raise more questions than expected. 

    

    - Reading the section I got the feeling that any event preventing to
    reach full sync state caused a PCErr (now PCNtf) and a MUST session
    close. was it the intent?

    

    - As a minor comment, I see your point on the PCErr / PCNtf
    "macroscopic use", although I would humbly object, notably in view
    of the whole PCErr 5: policy violation, that includes cases such as
    "global concurrent optimization not allowed" or "objective function
    not allowed" so, while I can agree with your view, IMHO it is not
    black/white.

    In particular, I think you are not fully quoting RFC5440 

    

    
   The PCEP Error message (also referred to as a PCErr message) is sent
   in several situations: when a protocol error condition is met or when
   the request is not compliant with the PCEP specification (e.g.,
   reception of a malformed message, reception of a message with a
   mandatory missing object, policy violation, unexpected message,
   unknown request reference)

    

    It seems to me that policiy violation is a PCErr. However, the main
    question is:

    

    - Is not reaching full sync considered a protocol error? (for
    whatever reason, and beyond a single message exchange but more as a
    transactional thing/sequence) If yes, I would vote for a PCErr /
    MUST close

    

    - If it is not an error (I am not fully aware of the implications)
    then we should allow PCNtf + MAY leave it open. Otherwise, my view
    remains PCErr + MUST close.

    

    Thanks!

    Ramon

    

    

    

  


--------------F3480DA0055B95043515ED90--


From nobody Tue May  9 02:30:27 2017
Return-Path: 
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B02129BAF for ; Tue,  9 May 2017 02:30:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ySU-IiKWcHS for ; Tue,  9 May 2017 02:30:23 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05776129BAA for ; Tue,  9 May 2017 02:30:21 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGG28553; Tue, 09 May 2017 09:30:19 +0000 (GMT)
Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 9 May 2017 10:29:49 +0100
Received: from BLREML501-MBB.china.huawei.com ([10.20.5.200]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0301.000; Tue, 9 May 2017 14:59:37 +0530
From: Dhruv Dhody 
To: Jonathan Hardwick , "pce@ietf.org" 
Thread-Topic: Stateful PCE: inconsistency in "resource limit" text
Thread-Index: AdLIFcW0FlKFj/hRS7i+bnJA6UAqeAAkAkbQ
Date: Tue, 9 May 2017 09:29:36 +0000
Message-ID: <23CE718903A838468A8B325B80962F9B8CAD4965@blreml501-mbb>
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.149.39]
Content-Type: multipart/alternative; boundary="_000_23CE718903A838468A8B325B80962F9B8CAD4965blreml501mbb_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.59118C2C.0083, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 2d4b6bed24854ce46984d99861305264
Archived-At: 
Subject: Re: [Pce] Stateful PCE: inconsistency in "resource limit" text
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 May 2017 09:30:25 -0000

--_000_23CE718903A838468A8B325B80962F9B8CAD4965blreml501mbb_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Jon, WG,

I feel this was done to differentiate two cases -


(1)   The resource limit happened during state synchronization (section 5.6=
) - with MUST close session

(2)   The resource limit happened during normal state report - with MAY clo=
se session

We could make this explicit and differentiate the two scenarios?

Regards,
Dhruv



From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Jonathan Hardwick
Sent: 08 May 2017 21:49
To: pce@ietf.org
Subject: [Pce] Stateful PCE: inconsistency in "resource limit" text

Hi PCE WG

I've been tidying up the stateful PCE draft to prepare it for publication a=
nd I have discovered an inconsistency in how the stateful PCE is supposed t=
o handle an overflow of its per-PCC resource limit.  In section 5.6 it says=
:

   A PCE implementing a limit on the resources a single PCC can occupy,
   MUST send a PCNtf message with Notification Type to be allocated by
   IANA (Stateful PCE resource limit exceeded) and Notification Value to
   be allocated by IANA (Entering resource limit exceeded state) in
   response to the PCRpt message triggering this condition in the
   synchronization phase and MUST terminate the session.

Whereas in section 6.1 it says:


   A PCE may choose to implement a limit on the resources a single PCC

   can occupy.  If a PCRpt is received that causes the PCE to exceed

   this limit, the PCE MUST notify the PCC using a PCNtf message with

   Notification Type to be allocated by IANA (Stateful PCE resource

   limit exceeded) and Notification Value to be allocated by IANA

   (Entering resource limit exceeded state) and MAY terminate the

   session.

These sections are inconsistent because the first says the PCE MUST termina=
te the session whereas the second says the PCE MAY terminate the session.

Furthermore, in section 8.6, the following notification is defined for "exi=
ting resource limit exceeded state", but this notification is not reference=
d anywhere in the text.


    Notification-Type  Meaning

       4        Stateful PCE resource limit exceeded

                 Notification-value=3D2:   Exiting resource limit exceeded

                                         state

Please could I ask all implementers:

-          MUST the PCE terminate the session if its state limit is exceede=
d, or MAY it leave it open?

-          Has anybody implemented the "exiting resource limit exceeded sta=
te" notification?  If so, how are you using it?

Your swiftest answers would be very much appreciated!

If I don't get any contradictory replies, my default action will be to say =
that the session MUST be terminated and to remove the unreferenced notifica=
tion-value.

Many thanks
Jon


--_000_23CE718903A838468A8B325B80962F9B8CAD4965blreml501mbb_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Jo=
n, WG,


=
 


I fee=
l this was done to differentiate two cases –



=
 


(1)  
The resource limit happened during state synchronization (section 5.6) &=
#8211; with MUST close session


(2)  
The resource limit happened during normal state report – with MAY =
close session



=
 


We co=
uld make this explicit and differentiate the two scenarios?



=
 


Regar=
ds,


Dhruv=



=
 


=
 


=
 








From:<=
/span> Pce [mailto:pce-bounc=
es@ietf.org]
On Behalf Of Jonathan Hardwick

Sent: 08 May 2017 21:49

To: pce@ietf.org

Subject: [Pce] Stateful PCE: inconsistency in "resource limit&q=
uot; text






 


Hi PCE WG


 


I’ve been tidying up the =
stateful PCE draft to prepare it for publication and I have discovered an i=
nconsistency in how the stateful PCE is supposed to handle an overflow of i=
ts per-PCC resource limit.  In section 5.6
 it says:


 


   A P=
CE implementing a limit on the resources a single PCC can occupy,


   MUS=
T send a PCNtf message with Notification Type to be allocated by=



   IAN=
A (Stateful PCE resource limit exceeded) and Notification Value to


   be =
allocated by IANA (Entering resource limit exceeded state) in


   res=
ponse to the PCRpt message triggering this condition in the


   syn=
chronization phase
and MUST terminate the session.=



 


Whereas in section 6.1 it says:=



 


   A PCE may choose to implement a limi=
t on the resources a single PCC


   can occupy.  If a PCRpt is rece=
ived that causes the PCE to exceed


   this limit, the PCE MUST notify the =
PCC using a PCNtf message with


   Notification Type to be allocated by=
 IANA (Stateful PCE resource


   limit exceeded) and Notification Val=
ue to be allocated by IANA


   (Entering resource limit exceeded st=
ate) and MAY terminate the


   session.


 


These sections are inconsistent=
 because the first says the PCE MUST terminate the session whereas the seco=
nd says the PCE MAY terminate the session.


 


Furthermore, in section 8.6, th=
e following notification is defined for “exiting resource limit excee=
ded state”, but this notification is not referenced anywhere in the t=
ext.


 


    Notification-Type  Meanin=
g


       4  =
;      Stateful PCE resource limit exceeded


        &=
nbsp;        Notification-value=3D2:&nbs=
p;  Exiting resource limit exceeded


        &=
nbsp;           &nbs=
p;            &=
nbsp;       state


 


Please could I ask all implemen=
ters:


-  =
;       
MUST the PCE terminate =
the session if its state limit is exceeded, or MAY it leave it open?


-  =
;       
Has anybody implemented=
 the “exiting resource limit exceeded state” notification? =
; If so, how are you using it?


 


Your swiftest answers would be =
very much appreciated!


 


If I don’t get any contra=
dictory replies, my default action will be to say that the session MUST be =
terminated and to remove the unreferenced notification-value.


 


Many thanks

Jon


 








--_000_23CE718903A838468A8B325B80962F9B8CAD4965blreml501mbb_--


From nobody Tue May  9 03:18:34 2017
Return-Path: 
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A903129BC6 for ; Tue,  9 May 2017 03:18:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.535
X-Spam-Level: 
X-Spam-Status: No, score=-3.535 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSLPl-U8lD10 for ; Tue,  9 May 2017 03:18:30 -0700 (PDT)
Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 15864126DFB for ; Tue,  9 May 2017 03:18:30 -0700 (PDT)
Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id F2031A44165; Tue,  9 May 2017 12:18:28 +0200 (CEST)
Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail1.rd.orange.com (Postfix) with ESMTP id DECC1A4411E; Tue,  9 May 2017 12:18:28 +0200 (CEST)
Received: from [10.193.71.226] (10.193.71.226) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.319.2; Tue, 9 May 2017 12:18:28 +0200
To: Ramon Casellas 
References:   <24b92f98-0702-a2d9-ac36-ab257a128e4c@orange.com> <858927fd-6a06-0d10-6c24-1dc6a3faa80c@cttc.es>
From: Julien Meuric 
Organization: Orange
CC: 
Message-ID: <21880171-6d8e-d011-6607-fbe8d7f8ecf0@orange.com>
Date: Tue, 9 May 2017 12:18:26 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <858927fd-6a06-0d10-6c24-1dc6a3faa80c@cttc.es>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Pce] Stateful PCE: inconsistency in "resource limit" text
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 May 2017 10:18:32 -0000

Hi again Ramon,

We are tackling 2 topics here: the stateful I-D on the table and PCErr
vs. PCNtf at large (see [JM] below).

On the former, we must not forget that:
- the use of PCNtf is consistent with the overload case in RFC 5440,
- draft-ietf-pce-stateful-pce passed IESG review (as well as previous WG
and IETF LCs),
- draft-ietf-pce-stateful-pce has early allocated codepoints.
As a result, the PCNtf is not an open question in the current case.

Then in the text...


May. 09, 2017 - ramon.casellas@cttc.es:
> On 9/5/17 10:35, Julien Meuric wrote:
>> Hi Ramon,
>>
>> Indeed, the I-D used to consider an error for this case, but RFC 5440
>> gives the pace and 2 codepoints were allocated:
>> - PCErr are associated to PCEP issues ("when a protocol error condition
>> is met or when the request is not compliant with the PCEP specification");
>> - PCNtf are typically used for other cases, including PCE state (e.g.
>> overload) and policy (e.g. threshold).
>>
>> Please note also that the current (orphan) text of the I-D allows to use
>> the PCNtf for "Exiting resource limit exceeded state". I am not saying
>> the latter should be kept, but considering this option sustains the idea
>> of having 2 possible messages/behaviors in PCEP.
>
> Hi Julien,
>
> This is indeed making me raise more questions than expected.
>
> - Reading the section I got the feeling that any event preventing to
> reach full sync state caused a PCErr (now PCNtf) and a MUST session
> close. was it the intent?

[JM] Allow me to rephrase a bit: "preventing to reach full sync state
caused an error advertised using a PCNtf". The impact on session closure
is the only discussed topic.

>
> - As a minor comment, I see your point on the PCErr / PCNtf
> "macroscopic use", although I would humbly object, notably in view of
> the whole PCErr 5: policy violation, that includes cases such as
> "global concurrent optimization not allowed" or "objective function
> not allowed" so, while I can agree with your view, IMHO it is not
> black/white.
> In particular, I think you are not fully quoting RFC5440
>
>    The PCEP Error message (also referred to as a PCErr message) is sent
>    in several situations: when a protocol error condition is met or when
>    the request is not compliant with the PCEP specification (e.g.,
>    reception of a malformed message, reception of a message with a
>    mandatory missing object, policy violation, unexpected message,
>    unknown request reference)
>
> It seems to me that policiy violation is a PCErr.  

[JM] You are right, it is not black/white. E.g. there are various types
of policy violations:
- operations the PCEP peer is not allowed to do (it may even be aware
before trying);
- live situation changes, like overload or threshold crossing (here, a
PCC is not necessarily misbehaving but hitting a PCE-local value);
- etc.
Generally speaking, I do not see in RFC 5440 a very strict line
splitting between PCErr and PCNtf, the discussion on ties should happen
on a case by case basis. We should at least avoid to decide based on the
message name. The actual question is: does a given feature match the
5/12 message/object kind or the 6/13 one? An opportunity (even if not
specified) to exit a faced situation (like overload or threshold
crossing) may often suggest to consider PCNtf, but this is not a strict
definition.

> However, the main question is:
>
> - Is not reaching full sync considered a protocol error? (for whatever
> reason, and beyond a single message exchange but more as a
> transactional thing/sequence)  If yes, I would vote for a PCErr / MUST
> close
>
> - If it is not an error (I am not fully aware of the implications)
> then we should allow PCNtf + MAY leave it open. Otherwise, my view
> remains PCErr + MUST close.

[JM] I do not think message type and session closure are so tied. In the
current document, PCNtf is no more questionable. Consequently, can we
consider your statement as a voice for "MAY" in the document?

Thanks,

Julien

>
> Thanks!
> Ramon
>
>
>
>
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce


From nobody Tue May  9 03:20:50 2017
Return-Path: 
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC8D4129BC7 for ; Tue,  9 May 2017 03:20:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zv1yMsBg2WGb for ; Tue,  9 May 2017 03:20:47 -0700 (PDT)
Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [161.106.1.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB41129BC6 for ; Tue,  9 May 2017 03:20:47 -0700 (PDT)
Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2AE8541025D; Tue,  9 May 2017 12:20:44 +0200 (CEST)
Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail1.rd.orange.com (Postfix) with ESMTP id 1CAFC41025A; Tue,  9 May 2017 12:20:44 +0200 (CEST)
Received: from [10.193.71.226] (10.193.71.226) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.319.2; Tue, 9 May 2017 12:20:43 +0200
To: Dhruv Dhody 
References:  <23CE718903A838468A8B325B80962F9B8CAD4965@blreml501-mbb>
CC: Jonathan Hardwick , "pce@ietf.org" 
From: Julien Meuric 
Organization: Orange
Message-ID: <13af5bdc-85b1-51f9-44d1-d0afc85cd923@orange.com>
Date: Tue, 9 May 2017 12:20:41 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <23CE718903A838468A8B325B80962F9B8CAD4965@blreml501-mbb>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Pce] Stateful PCE: inconsistency in "resource limit" text
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 May 2017 10:20:49 -0000

Hi Dhruv,

At this stage, it seems a bit late to introduce this change into the
document. However, keeping only "MAY" would allow implementations to
behave the way you suggest. Do we consider your feedback as supporting
"MAY"?

Thanks,

Julien


May. 09, 2017 - dhruv.dhody@huawei.com:
>
> Hi Jon, WG,
>
>  
>
> I feel this was done to differentiate two cases 
>
>  
>
> (1)   The resource limit happened during state synchronization
> (section 5.6)  with MUST close session
>
> (2)   The resource limit happened during normal state report  with
> MAY close session
>
>  
>
> We could make this explicit and differentiate the two scenarios?
>
>  
>
> Regards,
>
> Dhruv
>
>  
>
>  
>
>  
>
> *From:*Pce [mailto:pce-bounces@ietf.org] *On Behalf Of *Jonathan Hardwick
> *Sent:* 08 May 2017 21:49
>
>  
>
> Hi PCE WG
>
>  
>
> Ive been tidying up the stateful PCE draft to prepare it for
> publication and I have discovered an inconsistency in how the stateful
> PCE is supposed to handle an overflow of its per-PCC resource limit. 
> In section 5.6 it says:
>
>  
>
>    A PCE implementing a limit on the resources a single PCC can occupy,
>
>    MUST send a PCNtf message with Notification Type to be allocated by
>
>    IANA (Stateful PCE resource limit exceeded) and Notification Value to
>
>    be allocated by IANA (Entering resource limit exceeded state) in
>
>    response to the PCRpt message triggering this condition in the
>
>    synchronization phase and MUST terminate the session.
>
>  
>
> Whereas in section 6.1 it says:
>
>  
>
>    A PCE may choose to implement a limit on the resources a single PCC
>    can occupy.  If a PCRpt is received that causes the PCE to exceed
>    this limit, the PCE MUST notify the PCC using a PCNtf message with
>    Notification Type to be allocated by IANA (Stateful PCE resource
>    limit exceeded) and Notification Value to be allocated by IANA
>    (Entering resource limit exceeded state) and MAY terminate the
>    session.
>
>  
>
> These sections are inconsistent because the first says the PCE MUST
> terminate the session whereas the second says the PCE MAY terminate
> the session.
>
>  
>
> Furthermore, in section 8.6, the following notification is defined for
> exiting resource limit exceeded state, but this notification is not
> referenced anywhere in the text.
>
>  
>
>     Notification-Type  Meaning
>        4        Stateful PCE resource limit exceeded
>                  Notification-value=2:   Exiting resource limit exceeded
>                                          state
>
>  
>
> Please could I ask all implementers:
>
> -          MUST the PCE terminate the session if its state limit is
> exceeded, or MAY it leave it open?
>
> -          Has anybody implemented the exiting resource limit
> exceeded state notification?  If so, how are you using it?
>
>  
>
> Your swiftest answers would be very much appreciated!
>
>  
>
> If I dont get any contradictory replies, my default action will be to
> say that the session MUST be terminated and to remove the unreferenced
> notification-value.
>
>  
>
> Many thanks
>
> Jon
>
>  
>
>
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce


From nobody Tue May  9 03:50:30 2017
Return-Path: 
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF20A129BF2 for ; Tue,  9 May 2017 03:50:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.81
X-Spam-Level: 
X-Spam-Status: No, score=0.81 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRDy0zHIavyK for ; Tue,  9 May 2017 03:50:27 -0700 (PDT)
Received: from telmad-lavadora-l1mail2.puc.rediris.es (egeon.puc.rediris.es [IPv6:2001:720:418:ca03::81]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F113129BDA for ; Tue,  9 May 2017 03:50:26 -0700 (PDT)
X-IPAS-Result: =?us-ascii?q?A+BiAgCcnRFZjLBAASCH4YnAINCAz3+P8oj2FFsaAQEBAQI?= =?us-ascii?q?BAQEBCAEBAQGDD6FrIZgBhiQChGdXAQIBAQEBAQITAQEBJleFFgECAzhBEAsNC?= =?us-ascii?q?y5XBg0IAQGKHgMBtHYmAopPAQEBAQYBAQEBAQEihl+BXisLgmWEQIYMAQSWbYc?= =?us-ascii?q?YghCRCYsCF4ZSjBGIL1aBC0+GAIFxhy2CPAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.38,314,1491256800"; d="scan'208";a="82008798"
Received: from unknown (HELO leo.cttc.es) ([IPv6:2001:40b0:7c22:6020:a00:27ff:fe42:3b14]) by smtpout.puc.rediris.es with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 May 2017 12:50:24 +0200
Received: from [84.88.61.50] (unknown [84.88.61.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by leo.cttc.es (Postfix) with ESMTPSA id D61E41FDD0; Tue,  9 May 2017 12:50:23 +0200 (CEST)
To: Julien Meuric 
Cc: pce@ietf.org
References:   <24b92f98-0702-a2d9-ac36-ab257a128e4c@orange.com> <858927fd-6a06-0d10-6c24-1dc6a3faa80c@cttc.es> <21880171-6d8e-d011-6607-fbe8d7f8ecf0@orange.com>
From: Ramon Casellas 
Message-ID: <26015a9e-7247-42b7-077e-d8e197e03caf@cttc.es>
Date: Tue, 9 May 2017 12:50:22 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Thunderbird/53.0
MIME-Version: 1.0
In-Reply-To: <21880171-6d8e-d011-6607-fbe8d7f8ecf0@orange.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Pce] Stateful PCE: inconsistency in "resource limit" text
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 May 2017 10:50:29 -0000

On 9/5/17 12:18, Julien Meuric wrote:
> On the former, we must not forget that:
> - the use of PCNtf is consistent with the overload case in RFC 5440,
> - draft-ietf-pce-stateful-pce passed IESG review (as well as previous WG
> and IETF LCs),
> - draft-ietf-pce-stateful-pce has early allocated codepoints.
> As a result, the PCNtf is not an open question in the current case.
(snip)

Hi again Julien,

Thanks for reminding me of the specific question and sorry for diverging 
in multiple ways :) In view of your further comments and draft 
constraints, my preference remains as follows:

I still consider not being able to complete sync as a serious error and 
I would suggest a MUST close the session, regardless of the actual 
message to indicate such failure.

Thanks
R.


From nobody Tue May  9 04:20:15 2017
Return-Path: 
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0E81270A7 for ; Tue,  9 May 2017 04:20:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.222
X-Spam-Level: 
X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIWHHVGjiI80 for ; Tue,  9 May 2017 04:20:10 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DCAE1201FA for ; Tue,  9 May 2017 04:20:09 -0700 (PDT)
Received: from 172.18.7.190 (EHLO LHREML710-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGG46742; Tue, 09 May 2017 11:20:07 +0000 (GMT)
Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 9 May 2017 12:20:02 +0100
Received: from BLREML501-MBB.china.huawei.com ([10.20.5.200]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0301.000; Tue, 9 May 2017 16:49:49 +0530
From: Dhruv Dhody 
To: Julien Meuric 
CC: Jonathan Hardwick , "pce@ietf.org" 
Thread-Topic: [Pce] Stateful PCE: inconsistency in "resource limit" text
Thread-Index: AdLIFcW0FlKFj/hRS7i+bnJA6UAqeAAkAkbQ//+0AID//5OxYA==
Date: Tue, 9 May 2017 11:19:47 +0000
Message-ID: <23CE718903A838468A8B325B80962F9B8CAD49D2@blreml501-mbb>
References:  <23CE718903A838468A8B325B80962F9B8CAD4965@blreml501-mbb> <13af5bdc-85b1-51f9-44d1-d0afc85cd923@orange.com>
In-Reply-To: <13af5bdc-85b1-51f9-44d1-d0afc85cd923@orange.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.149.39]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.5911A5E8.0019, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 7c5f30cc0aa7d6730b70f1b0001c944e
Archived-At: 
Subject: Re: [Pce] Stateful PCE: inconsistency in "resource limit" text
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 May 2017 11:20:13 -0000

Hi Julien,=20

I agree. So "MAY" is the best way forward.=20

Regards,
Dhruv

> -----Original Message-----
> From: Julien Meuric [mailto:julien.meuric@orange.com]
> Sent: 09 May 2017 15:51
> To: Dhruv Dhody 
> Cc: Jonathan Hardwick ; pce@ietf.org
> Subject: Re: [Pce] Stateful PCE: inconsistency in "resource limit" text
>=20
> Hi Dhruv,
>=20
> At this stage, it seems a bit late to introduce this change into the
> document. However, keeping only "MAY" would allow implementations to
> behave the way you suggest. Do we consider your feedback as supporting
> "MAY"?
>=20
> Thanks,
>=20
> Julien
>=20
>=20
> May. 09, 2017 - dhruv.dhody@huawei.com:
> >
> > Hi Jon, WG,
> >
> >
> >
> > I feel this was done to differentiate two cases -
> >
> >
> >
> > (1)   The resource limit happened during state synchronization
> > (section 5.6) - with MUST close session
> >
> > (2)   The resource limit happened during normal state report - with
> > MAY close session
> >
> >
> >
> > We could make this explicit and differentiate the two scenarios?
> >
> >
> >
> > Regards,
> >
> > Dhruv
> >
> >
> >
> >
> >
> >
> >
> > *From:*Pce [mailto:pce-bounces@ietf.org] *On Behalf Of *Jonathan
> > Hardwick
> > *Sent:* 08 May 2017 21:49
> >
> >
> >
> > Hi PCE WG
> >
> >
> >
> > I've been tidying up the stateful PCE draft to prepare it for
> > publication and I have discovered an inconsistency in how the stateful
> > PCE is supposed to handle an overflow of its per-PCC resource limit.
> > In section 5.6 it says:
> >
> >
> >
> >    A PCE implementing a limit on the resources a single PCC can
> > occupy,
> >
> >    MUST send a PCNtf message with Notification Type to be allocated by
> >
> >    IANA (Stateful PCE resource limit exceeded) and Notification Value
> > to
> >
> >    be allocated by IANA (Entering resource limit exceeded state) in
> >
> >    response to the PCRpt message triggering this condition in the
> >
> >    synchronization phase and MUST terminate the session.
> >
> >
> >
> > Whereas in section 6.1 it says:
> >
> >
> >
> >    A PCE may choose to implement a limit on the resources a single PCC
> >    can occupy.  If a PCRpt is received that causes the PCE to exceed
> >    this limit, the PCE MUST notify the PCC using a PCNtf message with
> >    Notification Type to be allocated by IANA (Stateful PCE resource
> >    limit exceeded) and Notification Value to be allocated by IANA
> >    (Entering resource limit exceeded state) and MAY terminate the
> >    session.
> >
> >
> >
> > These sections are inconsistent because the first says the PCE MUST
> > terminate the session whereas the second says the PCE MAY terminate
> > the session.
> >
> >
> >
> > Furthermore, in section 8.6, the following notification is defined for
> > "exiting resource limit exceeded state", but this notification is not
> > referenced anywhere in the text.
> >
> >
> >
> >     Notification-Type  Meaning
> >        4        Stateful PCE resource limit exceeded
> >                  Notification-value=3D2:   Exiting resource limit excee=
ded
> >                                          state
> >
> >
> >
> > Please could I ask all implementers:
> >
> > -          MUST the PCE terminate the session if its state limit is
> > exceeded, or MAY it leave it open?
> >
> > -          Has anybody implemented the "exiting resource limit
> > exceeded state" notification?  If so, how are you using it?
> >
> >
> >
> > Your swiftest answers would be very much appreciated!
> >
> >
> >
> > If I don't get any contradictory replies, my default action will be to
> > say that the session MUST be terminated and to remove the unreferenced
> > notification-value.
> >
> >
> >
> > Many thanks
> >
> > Jon
> >
> >
> >
> >
> >
> > _______________________________________________
> > Pce mailing list
> > Pce@ietf.org
> > https://www.ietf.org/mailman/listinfo/pce


From nobody Tue May  9 05:02:49 2017
Return-Path: 
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABE2212943A for ; Tue,  9 May 2017 05:02:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.535
X-Spam-Level: 
X-Spam-Status: No, score=-3.535 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ao38GQM1fVE for ; Tue,  9 May 2017 05:02:46 -0700 (PDT)
Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 2F25A127868 for ; Tue,  9 May 2017 05:02:46 -0700 (PDT)
Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5BE76A44191; Tue,  9 May 2017 14:02:44 +0200 (CEST)
Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail1.rd.orange.com (Postfix) with ESMTP id 3AC2BA4418F; Tue,  9 May 2017 14:02:44 +0200 (CEST)
Received: from [10.193.71.226] (10.193.71.226) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.319.2; Tue, 9 May 2017 14:02:43 +0200
To: Ramon Casellas 
References:   <24b92f98-0702-a2d9-ac36-ab257a128e4c@orange.com> <858927fd-6a06-0d10-6c24-1dc6a3faa80c@cttc.es> <21880171-6d8e-d011-6607-fbe8d7f8ecf0@orange.com> <26015a9e-7247-42b7-077e-d8e197e03caf@cttc.es>
CC: 
From: Julien Meuric 
Organization: Orange
Message-ID: <2c3910db-83e8-8d26-0a2d-603ed6174ce4@orange.com>
Date: Tue, 9 May 2017 14:02:41 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <26015a9e-7247-42b7-077e-d8e197e03caf@cttc.es>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Pce] Stateful PCE: inconsistency in "resource limit" text
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 May 2017 12:02:48 -0000

Ramon,

Thanks a lot for your feedback, this is very helpful.

Julien


May. 09, 2017 - ramon.casellas@cttc.es:
> On 9/5/17 12:18, Julien Meuric wrote:
>> On the former, we must not forget that:
>> - the use of PCNtf is consistent with the overload case in RFC 5440,
>> - draft-ietf-pce-stateful-pce passed IESG review (as well as previous WG
>> and IETF LCs),
>> - draft-ietf-pce-stateful-pce has early allocated codepoints.
>> As a result, the PCNtf is not an open question in the current case.
> (snip)
> 
> Hi again Julien,
> 
> Thanks for reminding me of the specific question and sorry for diverging
> in multiple ways :) In view of your further comments and draft
> constraints, my preference remains as follows:
> 
> I still consider not being able to complete sync as a serious error and
> I would suggest a MUST close the session, regardless of the actual
> message to indicate such failure.
> 
> Thanks
> R.
> 


From nobody Tue May  9 23:57:06 2017
Return-Path: 
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25164120454 for ; Tue,  9 May 2017 23:57:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level: 
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zvkjzG24Ds9 for ; Tue,  9 May 2017 23:57:03 -0700 (PDT)
Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3D1D12714F for ; Tue,  9 May 2017 23:57:02 -0700 (PDT)
Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 347ED16029D; Wed, 10 May 2017 08:57:01 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.41]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 18719180067; Wed, 10 May 2017 08:57:01 +0200 (CEST)
Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0339.000; Wed, 10 May 2017 08:57:00 +0200
From: 
To: MEURIC Julien IMT/OLN , Dhruv Dhody 
CC: "pce@ietf.org" 
Thread-Topic: [Pce] Stateful PCE: inconsistency in "resource limit" text
Thread-Index: AdLIFcW0FlKFj/hRS7i+bnJA6UAqeAAkAkbQ///urYD//oYTcA==
Date: Wed, 10 May 2017 06:56:59 +0000
Message-ID: <17837_1494399421_5912B9BD_17837_10374_1_dee8f8f0-d44e-40da-a942-b2181d9b7de8@OPEXCLILM31.corporate.adroot.infra.ftgroup>
References:  <23CE718903A838468A8B325B80962F9B8CAD4965@blreml501-mbb> <13af5bdc-85b1-51f9-44d1-d0afc85cd923@orange.com>
In-Reply-To: <13af5bdc-85b1-51f9-44d1-d0afc85cd923@orange.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.3]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Pce] Stateful PCE: inconsistency in "resource limit" text
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 May 2017 06:57:05 -0000

Hi,

I think the main point is what does the session reset bring here ? IMO noth=
ing in that case, your session will constantly bounce until the someone red=
uce the number of states sent by a particular PCC which will create even mo=
re load on the PCE. This is an event that cannot be corrected by the sessio=
n reset.
Logging the Notification is a better approach that would allow the operator=
 to be informed and trigger a fix.

So I do not think that "MUST terminate" is a good way to go.

Brgds,

Stephane


-----Original Message-----
From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Julien Meuric
Sent: Tuesday, May 09, 2017 12:21
To: Dhruv Dhody
Cc: pce@ietf.org
Subject: Re: [Pce] Stateful PCE: inconsistency in "resource limit" text

Hi Dhruv,

At this stage, it seems a bit late to introduce this change into the docume=
nt. However, keeping only "MAY" would allow implementations to behave the w=
ay you suggest. Do we consider your feedback as supporting "MAY"?

Thanks,

Julien


May. 09, 2017 - dhruv.dhody@huawei.com:
>
> Hi Jon, WG,
>
>=20=20
>
> I feel this was done to differentiate two cases -
>
>=20=20
>
> (1)   The resource limit happened during state synchronization
> (section 5.6) - with MUST close session
>
> (2)   The resource limit happened during normal state report - with
> MAY close session
>
>=20=20
>
> We could make this explicit and differentiate the two scenarios?
>
>=20=20
>
> Regards,
>
> Dhruv
>
>=20=20
>
>=20=20
>
>=20=20
>
> *From:*Pce [mailto:pce-bounces@ietf.org] *On Behalf Of *Jonathan=20
> Hardwick
> *Sent:* 08 May 2017 21:49
>
>=20=20
>
> Hi PCE WG
>
>=20=20
>
> I've been tidying up the stateful PCE draft to prepare it for=20
> publication and I have discovered an inconsistency in how the stateful=20
> PCE is supposed to handle an overflow of its per-PCC resource limit.
> In section 5.6 it says:
>
>=20=20
>
>    A PCE implementing a limit on the resources a single PCC can=20
> occupy,
>
>    MUST send a PCNtf message with Notification Type to be allocated by
>
>    IANA (Stateful PCE resource limit exceeded) and Notification Value=20
> to
>
>    be allocated by IANA (Entering resource limit exceeded state) in
>
>    response to the PCRpt message triggering this condition in the
>
>    synchronization phase and MUST terminate the session.
>
>=20=20
>
> Whereas in section 6.1 it says:
>
>=20=20
>
>    A PCE may choose to implement a limit on the resources a single PCC
>    can occupy.  If a PCRpt is received that causes the PCE to exceed
>    this limit, the PCE MUST notify the PCC using a PCNtf message with
>    Notification Type to be allocated by IANA (Stateful PCE resource
>    limit exceeded) and Notification Value to be allocated by IANA
>    (Entering resource limit exceeded state) and MAY terminate the
>    session.
>
>=20=20
>
> These sections are inconsistent because the first says the PCE MUST=20
> terminate the session whereas the second says the PCE MAY terminate=20
> the session.
>
>=20=20
>
> Furthermore, in section 8.6, the following notification is defined for=20
> "exiting resource limit exceeded state", but this notification is not=20
> referenced anywhere in the text.
>
>=20=20
>
>     Notification-Type  Meaning
>        4        Stateful PCE resource limit exceeded
>                  Notification-value=3D2:   Exiting resource limit exceeded
>                                          state
>
>=20=20
>
> Please could I ask all implementers:
>
> -          MUST the PCE terminate the session if its state limit is
> exceeded, or MAY it leave it open?
>
> -          Has anybody implemented the "exiting resource limit
> exceeded state" notification?  If so, how are you using it?
>
>=20=20
>
> Your swiftest answers would be very much appreciated!
>
>=20=20
>
> If I don't get any contradictory replies, my default action will be to=20
> say that the session MUST be terminated and to remove the unreferenced=20
> notification-value.
>
>=20=20
>
> Many thanks
>
> Jon
>
>=20=20
>
>
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce

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

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From nobody Wed May 10 00:08:26 2017
Return-Path: 
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330FA1200ED for ; Wed, 10 May 2017 00:08:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.811
X-Spam-Level: 
X-Spam-Status: No, score=0.811 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMFLzHd-rlfG for ; Wed, 10 May 2017 00:08:23 -0700 (PDT)
Received: from cica-lavadora-l1mail2.puc.rediris.es (arce.puc.rediris.es [IPv6:2001:720:418:ca02::18]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CBDE1200E5 for ; Wed, 10 May 2017 00:08:22 -0700 (PDT)
X-IPAS-Result: =?us-ascii?q?A2BeAgBWuxJZjNA+WFRdHAEBBAEBCgEBhUODaZttmAGGJAK?= =?us-ascii?q?Ec1cBAgEBAQEBAhMBAQEmV4UVAQEBAQIBIxVGCwsYAgImAgJXEwYCAQGKFQwBs?= =?us-ascii?q?kaCJop0MoELhVSBXiuCcIRAb4JCgmABBJ4FghCRCosChmmME4gvVoELT4YCgXF?= =?us-ascii?q?0hl2CPAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.38,318,1491256800"; d="scan'208";a="78616939"
Received: from leo.cttc.es ([84.88.62.208]) by smtpout.puc.rediris.es with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 May 2017 09:08:10 +0200
Received: from [84.88.61.50] (unknown [84.88.61.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by leo.cttc.es (Postfix) with ESMTPSA id 9A3501FDD0 for ; Wed, 10 May 2017 09:08:09 +0200 (CEST)
To: pce@ietf.org
References:  <23CE718903A838468A8B325B80962F9B8CAD4965@blreml501-mbb> <13af5bdc-85b1-51f9-44d1-d0afc85cd923@orange.com> <17837_1494399421_5912B9BD_17837_10374_1_dee8f8f0-d44e-40da-a942-b2181d9b7de8@OPEXCLILM31.corporate.adroot.infra.ftgroup>
From: Ramon Casellas 
Message-ID: 
Date: Wed, 10 May 2017 09:08:06 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Thunderbird/53.0
MIME-Version: 1.0
In-Reply-To: <17837_1494399421_5912B9BD_17837_10374_1_dee8f8f0-d44e-40da-a942-b2181d9b7de8@OPEXCLILM31.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Pce] Stateful PCE: inconsistency in "resource limit" text
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 May 2017 07:08:26 -0000

On 10/5/17 8:56, stephane.litkowski@orange.com wrote:
> Hi,
>
> I think the main point is what does the session reset bring here ? IMO nothing in that case, your session will constantly bounce until the someone reduce the number of states sent by a particular PCC which will create even more load on the PCE. This is an event that cannot be corrected by the session reset.
I don't have a strong opinion after all, but before closing the session 
you get the proper PCNtf. There is no need to constantly bounce. To your 
question, IMHO closing the session accomplishes precisely 
(deterministically) that either you reach end of sync or not; not 
allowing to get a "half-sync" state.

> Logging the Notification is a better approach that would allow the operator to be informed and trigger a fix.
You log it anyway. The session is not "abruptly" closed.

At the end, I am fine with either choice. Even if I consider not being 
able to complete sync an issue, I also consider setting a policy that 
prevents a pcc to sync another (unrelated) issue.

Regards
Ramon


From nobody Thu May 11 06:34:10 2017
Return-Path: 
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAFC312EE46; Thu, 11 May 2017 06:34:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level: 
X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mm.st header.b=cAtkwAPl; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=pXlASUJz
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 HNJs26b918RQ; Thu, 11 May 2017 06:34:00 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2B0912EBFE; Thu, 11 May 2017 06:31:05 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 36EF120AC3; Thu, 11 May 2017 09:31:05 -0400 (EDT)
Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Thu, 11 May 2017 09:31:05 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mm.st; h=cc :content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=h4AjGDF5FSlDtB/R7CAKaA1O2uzgpcSiPcVTP1B8OYc=; b=cAtkwAPl EfnVpW8NItd2xJCq70Cy9X6fT+zQOlFhJCA8OOEGvV3mFeWYqpGVb9zzjm2AytIY 6f+YPDcsAkpNQAkGyq0f5jMjiOYrrnDKe+UhAWT7MmvHFFU9pGSp0XfZb/RYY2OQ JGJTmzvx8aiCf+ybsYAXl2o01waKRz0y/XyhL3lsbVIpjwI3XWFJcFfrOh8trSSW cJcI08iBTzA2ZM2wlDIUEFl6o6AFs1pqTCUJ2Qno367CszQVFNVCZQO7hniG/VPL fj1I4OCaJX9VmbhT0RKIRI5MkLARk1TRTiIzDijQs/MCAWxiXwp5zb6r3Rj3crkH DO+KqhkvzTx4tg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=h4AjGDF5FSlDtB/R7CAKaA1O2uzgp cSiPcVTP1B8OYc=; b=pXlASUJzDSpR2/CUjEBQErJusC+nj1xk6IaVMe+l+9u8a GDMj1Igy9eLNoOEG3GkItL50di0c1B5CzfMUPgeqIw8c6ePMP6BM8pQI7iogsS7Y khpO8syX/kTJbZ0/e7pXrVcpITzZ2mqPvQdF95E2DfbqSlKur/gLQs6mRl9SexvT AZO6huclnPfOcnPfM5/o0z/Y1u1XRjkO+qe8vHWTo778DMvUukKZyp1BzDDcxRuN 6wJpLbQ7ZqPc6hziZGR0+KGm+yrH29SEdZ92RscUYlLyZJH1WSTc0K5FhmamTAO3 lkpFw80r3TH5hgfDPULlo+WAe6AGM4h7ho7O+7V5w==
X-ME-Sender: 
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 039BC9E259; Thu, 11 May 2017 09:31:04 -0400 (EDT)
Message-Id: <1494509464.34491.973270680.4CBC76C2@webmail.messagingengine.com>
From: Dan Frost 
To: rtg-ads@ietf.org
Cc: rtg-dir@ietf.org, draft-ietf-pce-pceps.all@ietf.org, pce@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-6cc55fe1
Date: Thu, 11 May 2017 14:31:04 +0100
Archived-At: 
Subject: [Pce] RtgDir review: draft-ietf-pce-pceps-12
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 May 2017 13:34:03 -0000

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and
sometimes on special request. The purpose of the review is to provide
assistance to the Routing ADs. For more information about the Routing
Directorate, please see
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF
Last Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-pce-pceps-12
Reviewer: Dan Frost
Review Date: 2017-05-11
IETF LC End Date: 
Intended Status: Standards Track

Summary:

I have significant concerns about this document and recommend that the
Routing ADs discuss these issues further with the authors.

Comments:

This document proposes to add a STARTTLS mechanism to the PCE protocol.
If this basic approach is accepted, then the document is in good shape.
It's clear, complete, and straightforward. The question is whether
mandating STARTTLS is actually a good idea.

Major Issues:

My main concern with this document is that it takes as given that
STARTTLS is the right way to secure PCEP with TLS. Perhaps this argument
was already had at some point and this draft is the result, but if so
then at a bare minimum it needs rationale explaining why STARTTLS was
chosen over alternatives, and text that addresses weaknesses and
mitigations associated with STARTTLS processing, in particular the
possibility and relative ease of downgrade attacks.

The obvious alternative would be to not use STARTTLS and simply allocate
another TCP port for PCEP-over-TLS. This avoids complicating the PCE
protocol and introducing the potential for downgrade attacks based on
STARTTLS. PCE is used to convey critical path-determination information
in carrier networks, among other things. That it's not fully
authenticated and encrypted in all cases already is an unfortunate
legacy of a bygone era. Ideally operators should move as quickly as
possible to secure PCEP and aim to entirely remove the unsecure form.
STARTTLS serves a weaker goal of "opportunistic" security, which, while
it has its uses, makes little sense for PCE compared to simply
deprecating the unsecured version.

Minor Issues:

* Section 3.3: "A RECOMMENDED value for StartTLSWait timer is 60
seconds." This seems like a very long time to wait for an initial reply
on an already-established TCP connection.

* Section 3.2, fifth paragraph (beginning with "A PCEP speaker
receiving..."):

This paragraph states: "A PCEP speaker receiving any other message apart
from StartTLS, open, or PCErr MUST treat it as an unexpected message..."

As written this is confusing and seems to imply that no other PCEP
messages can ever be sent. It looks like this is meant to be scoped to
the context of the first message sent/received on session initiation?

* Section 8.6

The subsection titles of Section 8 have been taken from Section 8 of RFC
5440, but Section 8.6 here is called "Impact on Network Operations"
while in RFC 5440 it's called "Impact on Network Operation". Funnily
enough, that final "s" makes a difference. Without it, the section
refers to an impact on the functioning of the network itself. With it,
it would usually be taken to refer to impact on human operations and
management procedures.

It looks correct to say that the mechanism of this draft should not
significantly impact the functioning of the network. On the other hand,
it certainly does impact operations and management procedures, as staff
have to develop policies around security requirements for PCEP within
the organization, methods for verifying whether device security
parameters are configured correctly, checking for unexpected downgrades
to insecure sessions, etc. It would be an improvement for the document
to address the impact of PCEPS on operational processes.

Nits:

Sec 3.1, first paragraph:
OLD
    The steps involved in the PCEPS establishment consists of following
    successive steps:
NEW
    The steps involved in establishing a PCEPS session are as follows:
END

Sec 3.4, Step 3:
s/Any attempt of initiate a TLS/Any attempt to initiate a TLS/


Cheers,
-d


From nobody Thu May 11 09:44:53 2017
Return-Path: 
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A011294A6; Thu, 11 May 2017 09:44:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.222
X-Spam-Level: 
X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZn9SsUgZL3H; Thu, 11 May 2017 09:44:48 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96CE2129412; Thu, 11 May 2017 09:38:19 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DMS87338; Thu, 11 May 2017 16:38:17 +0000 (GMT)
Received: from BLREML408-HUB.china.huawei.com (10.20.4.47) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 11 May 2017 17:38:15 +0100
Received: from BLREML501-MBB.china.huawei.com ([10.20.5.200]) by BLREML408-HUB.china.huawei.com ([10.20.4.47]) with mapi id 14.03.0301.000; Thu, 11 May 2017 22:07:57 +0530
From: Dhruv Dhody 
To: Dan Frost , "rtg-ads@ietf.org" 
CC: "rtg-dir@ietf.org" , "draft-ietf-pce-pceps.all@ietf.org" , "pce@ietf.org" 
Thread-Topic: [Pce] RtgDir review: draft-ietf-pce-pceps-12
Thread-Index: AQHSyltYC6H+jHLTg06wAJfoFK1pl6HvJ+jQ
Date: Thu, 11 May 2017 16:37:56 +0000
Message-ID: <23CE718903A838468A8B325B80962F9B8CAD810B@blreml501-mbb>
References: <1494509464.34491.973270680.4CBC76C2@webmail.messagingengine.com>
In-Reply-To: <1494509464.34491.973270680.4CBC76C2@webmail.messagingengine.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.195.40.152]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0202.59149379.015F, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 47fe5610a508270e0cfe67eaa0713e17
Archived-At: 
Subject: Re: [Pce] RtgDir review: draft-ietf-pce-pceps-12
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 May 2017 16:44:51 -0000

Hi Dan,=20

Thanks for your review. Please see inline...=20

> -----Original Message-----
> From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Dan Frost
> Sent: 11 May 2017 19:01
> To: rtg-ads@ietf.org
> Cc: rtg-dir@ietf.org; draft-ietf-pce-pceps.all@ietf.org; pce@ietf.org
> Subject: [Pce] RtgDir review: draft-ietf-pce-pceps-12
>=20
>=20
> Hello,
>=20
> I have been selected as the Routing Directorate reviewer for this draft.
> The Routing Directorate seeks to review all routing or routing-related dr=
afts as
> they pass through IETF last call and IESG review, and sometimes on specia=
l
> request. The purpose of the review is to provide assistance to the Routin=
g ADs.
> For more information about the Routing Directorate, please see
> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>=20
> Although these comments are primarily for the use of the Routing ADs, it =
would
> be helpful if you could consider them along with any other IETF Last Call
> comments that you receive, and strive to resolve them through discussion =
or by
> updating the draft.
>=20
> Document: draft-ietf-pce-pceps-12
> Reviewer: Dan Frost
> Review Date: 2017-05-11
> IETF LC End Date:
> Intended Status: Standards Track
>=20
> Summary:
>=20
> I have significant concerns about this document and recommend that the
> Routing ADs discuss these issues further with the authors.
>=20
> Comments:
>=20
> This document proposes to add a STARTTLS mechanism to the PCE protocol.
> If this basic approach is accepted, then the document is in good shape.
> It's clear, complete, and straightforward. The question is whether mandat=
ing
> STARTTLS is actually a good idea.
>=20
[Dhruv] Yes, this has been discussed in the WG.=20
The individual draft in fact asked for another port no, and during the WG a=
doption process, it was discussed in the WG as well as with security expert=
s, and concluded that we should use STARTTLS.=20
As far as I am aware, use of different port for secured version of a protoc=
ol has not been followed by IETF for some time now.  =20

> Major Issues:
>=20
> My main concern with this document is that it takes as given that STARTTL=
S is
> the right way to secure PCEP with TLS. Perhaps this argument was already =
had at
> some point and this draft is the result, but if so then at a bare minimum=
 it needs
> rationale explaining why STARTTLS was chosen over alternatives, and text =
that
> addresses weaknesses and mitigations associated with STARTTLS processing,=
 in
> particular the possibility and relative ease of downgrade attacks.
>=20
[Dhruv] I see the benefit of adding text, something in line of -=20

"As per the recommendation from [RFC7525], PCEP peers that support PCEPS, S=
HOULD prefer strict TLS configuration i.e. do not allow non-TLS PCEP sessio=
ns to be established."

I will discuss further with my co-authors/chairs/AD, if we also need to spe=
ll out the full rationale here. =20

> The obvious alternative would be to not use STARTTLS and simply allocate
> another TCP port for PCEP-over-TLS. This avoids complicating the PCE prot=
ocol
> and introducing the potential for downgrade attacks based on STARTTLS. PC=
E is
> used to convey critical path-determination information in carrier network=
s,
> among other things. That it's not fully authenticated and encrypted in al=
l cases
> already is an unfortunate legacy of a bygone era. Ideally operators shoul=
d move
> as quickly as possible to secure PCEP and aim to entirely remove the unse=
cure
> form.
> STARTTLS serves a weaker goal of "opportunistic" security, which, while i=
t has its
> uses, makes little sense for PCE compared to simply deprecating the unsec=
ured
> version.
>=20
> Minor Issues:
>=20
> * Section 3.3: "A RECOMMENDED value for StartTLSWait timer is 60 seconds.=
"
> This seems like a very long time to wait for an initial reply on an alrea=
dy-
> established TCP connection.
>=20
[Dhruv] We saw a benefit in keeping this same as the OpenWait time in the P=
CEP session establishment. =20

> * Section 3.2, fifth paragraph (beginning with "A PCEP speaker
> receiving..."):
>=20
> This paragraph states: "A PCEP speaker receiving any other message apart =
from
> StartTLS, open, or PCErr MUST treat it as an unexpected message..."
>=20
> As written this is confusing and seems to imply that no other PCEP messag=
es can
> ever be sent. It looks like this is meant to be scoped to the context of =
the first
> message sent/received on session initiation?
>=20
[Dhruv] Yes. I will add clarification that this is for the first message.=20

> * Section 8.6
>=20
> The subsection titles of Section 8 have been taken from Section 8 of RFC =
5440,
> but Section 8.6 here is called "Impact on Network Operations"
> while in RFC 5440 it's called "Impact on Network Operation". Funnily enou=
gh,
> that final "s" makes a difference. Without it, the section refers to an i=
mpact on
> the functioning of the network itself. With it, it would usually be taken=
 to refer
> to impact on human operations and management procedures.
>=20
> It looks correct to say that the mechanism of this draft should not signi=
ficantly
> impact the functioning of the network. On the other hand, it certainly do=
es
> impact operations and management procedures, as staff have to develop
> policies around security requirements for PCEP within the organization, m=
ethods
> for verifying whether device security parameters are configured correctly=
,
> checking for unexpected downgrades to insecure sessions, etc. It would be=
 an
> improvement for the document to address the impact of PCEPS on operationa=
l
> processes.
>=20
[Dhruv] Agreed. I will work on text in this section, along these lines.=20

> Nits:
[Dhruv] Ack for all.=20

Thanks for your review.=20

Regards,
Dhruv

>=20
> Sec 3.1, first paragraph:
> OLD
>     The steps involved in the PCEPS establishment consists of following
>     successive steps:
> NEW
>     The steps involved in establishing a PCEPS session are as follows:
> END
>=20
> Sec 3.4, Step 3:
> s/Any attempt of initiate a TLS/Any attempt to initiate a TLS/
>=20
>=20
> Cheers,
> -d
>=20
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce


From nobody Thu May 11 11:28:28 2017
Return-Path: 
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A85B1293D6; Thu, 11 May 2017 11:28:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.08
X-Spam-Level: 
X-Spam-Status: No, score=0.08 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0zJo0DS9Dqx; Thu, 11 May 2017 11:28:18 -0700 (PDT)
Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 860C6129B0A; Thu, 11 May 2017 11:22:31 -0700 (PDT)
Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v4BIMLFW019211; Thu, 11 May 2017 19:22:21 +0100
Received: from 950129200 (73.204.115.87.dyn.plus.net [87.115.204.73]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v4BIMKDg019191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 May 2017 19:22:21 +0100
Reply-To: 
From: "Adrian Farrel" 
To: "'Dhruv Dhody'" , "'Dan Frost'" , 
Cc: , , 
References: <1494509464.34491.973270680.4CBC76C2@webmail.messagingengine.com> <23CE718903A838468A8B325B80962F9B8CAD810B@blreml501-mbb>
In-Reply-To: <23CE718903A838468A8B325B80962F9B8CAD810B@blreml501-mbb>
Date: Thu, 11 May 2017 19:22:13 +0100
Message-ID: <08f801d2ca83$838df1d0$8aa9d570$@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: AQJJcu8a0d6PWR3WtIJBOBWDqgn9PwJKnsZjoO/K9YA=
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23064.001
X-TM-AS-Result: No--14.894-10.0-31-10
X-imss-scan-details: No--14.894-10.0-31-10
X-TMASE-MatchedRID: oTBA/+sdKaYn2WEbWzq9rXBRIrj8R47FG05a723w5ydcKZwALwMGs8i4 GR3ZCO6riOa7fw0bKuIWcqsxeJi+6wH/zrweiLuz8eSmTJSmEv2Hxi2fvkKUM5W/KlV6zYxFUiE kc086x3bdB9WdCbsnuhETDGyRSLo4wV5ZD2sQLdVswYo64ufkVeiY+s2L3xQETiKNDvuWVeGhqe T3Vbva/cuVSg9BRaEQxJf2YEv66abwz7Dn+9MyvZ4CIKY/Hg3AtOt1ofVlaoKYGUPdON1eXvoLR 4+zsDTtjoczmuoPCq0VBVGu21RXHVlBP+PgdpFD72LTUzxP7LEyXL0FQkFBlEMyXKmJaB0e
Archived-At: 
Subject: Re: [Pce] [RTG-DIR]  RtgDir review: draft-ietf-pce-pceps-12
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 May 2017 18:28:20 -0000

> > This document proposes to add a STARTTLS mechanism to the PCE protocol.
> > If this basic approach is accepted, then the document is in good shape.
> > It's clear, complete, and straightforward. The question is whether mandating
> > STARTTLS is actually a good idea.
> >
> [Dhruv] Yes, this has been discussed in the WG.
> The individual draft in fact asked for another port no, and during the WG
> adoption process, it was discussed in the WG as well as with security experts,
and
> concluded that we should use STARTTLS.
> As far as I am aware, use of different port for secured version of a protocol
has
> not been followed by IETF for some time now.

Right. Burning additional ports has been frowned upon for a while.

I don't think it is right for a draft to explain why one solution was chosen
over another. The question is: does the chosen solution work?

But Dan is right that any weaknesses need to be highlighted and
addressed/mitigated/warned.

Cheers,
Adrian


From nobody Thu May 11 11:51:07 2017
Return-Path: 
X-Original-To: pce@ietf.org
Delivered-To: pce@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 011DD129BA5; Thu, 11 May 2017 11:50:59 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: pce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.50.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149452865895.16699.13751504228688725212@ietfa.amsl.com>
Date: Thu, 11 May 2017 11:50:58 -0700
Archived-At: 
Subject: [Pce] I-D Action: draft-ietf-pce-pcep-stateful-pce-gmpls-05.txt
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 May 2017 18:50:59 -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 of the IETF.

        Title           : Path Computation Element (PCE) Protocol Extensions for Stateful PCE Usage in GMPLS-controlled Networks
        Authors         : Xian Zhang
                          Young Lee
                          Fatai Zhang
                          Ramon Casellas
                          Oscar Gonzalez de Dios
                          Zafar Ali
	Filename        : draft-ietf-pce-pcep-stateful-pce-gmpls-05.txt
	Pages           : 13
	Date            : 2017-05-11

Abstract:
   The Path Computation Element (PCE) facilitates Traffic Engineering
   (TE) based path calculation in large, multi-domain, multi-region, or
   multi-layer networks. The PCE communication Protocol (PCEP) has been
   extended to support stateful PCE functions where the PCE retains
   information about the paths already present in the network, but
   those extensions are technology-agnostic. This memo provides
   extensions required for PCEP so as to enable the usage of a stateful
   PCE capability in GMPLS-controlled networks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-stateful-pce-gmpls/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-pcep-stateful-pce-gmpls-05
https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-stateful-pce-gmpls-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-stateful-pce-gmpls-05


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Thu May 11 12:01:35 2017
Return-Path: 
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C44412EC5B for ; Thu, 11 May 2017 12:01:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJZOrGL4g3Ts for ; Thu, 11 May 2017 12:01:32 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FC0D1314C4 for ; Thu, 11 May 2017 11:55:21 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGK72416; Thu, 11 May 2017 18:55:20 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 11 May 2017 19:55:19 +0100
Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.161]) by SJCEML701-CHM.china.huawei.com ([169.254.3.175]) with mapi id 14.03.0235.001;  Thu, 11 May 2017 11:55:15 -0700
From: Leeyoung 
To: "pce@ietf.org" 
Thread-Topic: [Pce] I-D Action: draft-ietf-pce-pcep-stateful-pce-gmpls-05.txt
Thread-Index: AQHSyoevVqFjyIqQCEuFcRUEm5yBzaHvemRQ
Date: Thu, 11 May 2017 18:55:14 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172B2C2D70@SJCEML702-CHM.china.huawei.com>
References: <149452865895.16699.13751504228688725212@ietfa.amsl.com>
In-Reply-To: <149452865895.16699.13751504228688725212@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.218.137.193]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5914B398.01DE, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.4.161, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: e4d83b792254690a8fa20df6fc13e3d1
Archived-At: 
Subject: [Pce] FW: I-D Action: draft-ietf-pce-pcep-stateful-pce-gmpls-05.txt
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 May 2017 19:01:34 -0000

Hi,

This is to revive the draft with editorial updates.=20

Thanks,
Young (on behalf of co-authors/contributors)

-----Original Message-----
From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.o=
rg
Sent: Thursday, May 11, 2017 1:51 PM
To: i-d-announce@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-ietf-pce-pcep-stateful-pce-gmpls-05.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 of the IETF.

        Title           : Path Computation Element (PCE) Protocol Extension=
s for Stateful PCE Usage in GMPLS-controlled Networks
        Authors         : Xian Zhang
                          Young Lee
                          Fatai Zhang
                          Ramon Casellas
                          Oscar Gonzalez de Dios
                          Zafar Ali
	Filename        : draft-ietf-pce-pcep-stateful-pce-gmpls-05.txt
	Pages           : 13
	Date            : 2017-05-11

Abstract:
   The Path Computation Element (PCE) facilitates Traffic Engineering
   (TE) based path calculation in large, multi-domain, multi-region, or
   multi-layer networks. The PCE communication Protocol (PCEP) has been
   extended to support stateful PCE functions where the PCE retains
   information about the paths already present in the network, but
   those extensions are technology-agnostic. This memo provides
   extensions required for PCEP so as to enable the usage of a stateful
   PCE capability in GMPLS-controlled networks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-stateful-pce-gmpls/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-pcep-stateful-pce-gmpls-05
https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-stateful-pce-gmpl=
s-05

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


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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


From nobody Fri May 12 08:35:08 2017
Return-Path: 
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1BE129B95 for ; Fri, 12 May 2017 08:35:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YOVSKTo4fRf for ; Fri, 12 May 2017 08:35:03 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8577913147C for ; Fri, 12 May 2017 08:29:32 -0700 (PDT)
X-AuditID: c1b4fb3a-b7dff70000005025-24-5915d4d9fb81
Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F0.AA.20517.9D4D5195; Fri, 12 May 2017 17:29:30 +0200 (CEST)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.63) with Microsoft SMTP Server (TLS) id 14.3.339.0; Fri, 12 May 2017 17:29:29 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gp71wcU8UourufFas4+fnOiYwg+1eH85HJs7IDVxZTk=; b=S6lgTvb7/ugZcluZ2JqFL9RsCRWy6j1gXRzSxeVw8Fpm0eL/BhWU+HBfx5i/U+D5wwqXnehJReUg/ZfRBcwzCMoyMNFmfTEaCnaOlpI7GGmFAlWhNaY+QUBU8I/gt5Mq+QJ/iOW8GFz3MuDKZMNXVOWe3b4DAF1vdr+ZCABB7Ac=
Received: from AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) by AM4PR07MB1522.eurprd07.prod.outlook.com (10.165.248.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Fri, 12 May 2017 15:29:28 +0000
Received: from AM2PR07MB0994.eurprd07.prod.outlook.com ([fe80::9d48:60f4:c92:7443]) by AM2PR07MB0994.eurprd07.prod.outlook.com ([fe80::9d48:60f4:c92:7443%17]) with mapi id 15.01.1084.020; Fri, 12 May 2017 15:29:28 +0000
From: Daniele Ceccarelli 
To: "pce@ietf.org" 
Thread-Topic: New Version Notification for draft-lazzeri-pce-residual-bw-00.txt
Thread-Index: AQHSyzQoMquCg77r/0CKE6l/Ey/ECqHw0gqA
Date: Fri, 12 May 2017 15:29:28 +0000
Message-ID: 
References: <149460276214.13384.2616136547374107579.idtracker@ietfa.amsl.com>
In-Reply-To: <149460276214.13384.2616136547374107579.idtracker@ietfa.amsl.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [151.0.200.100]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM4PR07MB1522; 7:183FEhgumw9UwF24iIc1zGN/KJCAjrGWdqm0OuUPrbVheA8Zum0EhL5sjOfDCPDgseSS9mbFECw4kWSIl4rbBPkwmBvbaFeerrhOR6lAbtfQAGH2Qu4yyE+YBhdt/mM1kIHaImHjabl6y6MW1TrKhk+GwX9jTXr7d9XcAuloZcckc2Oh8pfCRTJC2UIKCBoCuNyLfXqwSIfXs0dA2QdlSLiE6Gp92bDgG9zQTb9tk/GiXSqs9MVDAsPKoN/KBZ0IPpsGwZvA1ERZZHk4mTtDh5921vVyKm+sDlGM6NGltzT6CKG83sVUPmdDNaD1sCXTgWKmPLxwHicPkUHV4YY2vQ==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(39400400002)(39410400002)(39850400002)(39450400003)(39840400002)(13464003)(377424004)(54356999)(6436002)(6506006)(76176999)(50986999)(3846002)(102836003)(66066001)(6116002)(2501003)(2900100001)(229853002)(6306002)(74316002)(99286003)(2351001)(7736002)(305945005)(5640700003)(25786009)(230783001)(189998001)(3660700001)(53546009)(2906002)(6246003)(3280700002)(55016002)(33656002)(5250100002)(15650500001)(4326008)(38730400002)(110136004)(81166006)(1730700003)(5660300001)(7696004)(2950100002)(8676002)(478600001)(53936002)(6916009)(8936002)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB1522; H:AM2PR07MB0994.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-ms-office365-filtering-correlation-id: 1209fd7c-2573-4a5f-1323-08d4994badb6
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM4PR07MB1522; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(37575265505322)(120809045254105)(50582790962513); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700036)(100105000095)(100000701036)(100105300095)(100000702036)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(100000703036)(100105400095)(93006095)(93001095)(10201501046)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(100000704036)(100105200095)(100000705036)(100105500095); SRVR:AM4PR07MB1522; BCL:0; PCL:0; RULEID:(100000800036)(100110000095)(100000801036)(100110300095)(100000802036)(100110100095)(100000803036)(100110400095)(100000804036)(100110200095)(100000805036)(100110500095); SRVR:AM4PR07MB1522; 
x-forefront-prvs: 0305463112
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2017 15:29:28.1289 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1522
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42KZGbHdXvfWFdFIg1l95hbT5rlaNN2/we7A 5NFy5C2rx5IlP5kCmKK4bFJSczLLUov07RK4MpqurGQp+CZZsXLrS+YGxgWSXYycHBICJhJb Np1l72Lk4hASOMIo8ffyXhYI5wSjxPq2GawgDotAL7NE860brBCZ6UwSu2/+Y4RwHjJKzJ25 BmgABwebgJXEk0M+IHNFBBQlvt9YzQZiMwtESnxp+swEYgsL+Em82HqZHaImUOJt/05mkFYR ASOJrl3qIGEWAVWJnauWgZXwCsRING98xQpSIiTgKzFxnxtImBNoyvU/mxlBbEYBWYkJuxcx QmwSl7j1ZD4TxGcCEkv2nGeGsEUlXj7+B3Y+o0A3o8SHedegihQlLqyaBWXLSlya3w32loRA D7NEw5UnzBDOB1aJ0+dnQlX5Smw8+RHKrpM4+qSLFcLOlvg3+TA7hB0tsePbGajmQ6wSb6df gmqQkbiyuIkdEhJSEnevdDJOYNSaheT0WUCfMgtoSqzfpQ8RVpSY0v2QfRY4MAQlTs58wrKA kWUVo2hxanFxbrqRkV5qUWZycXF+nl5easkmRmDSOLjlt9UOxoPPHQ8xCnAwKvHwPtgvGinE mlhWXJl7iFGCg1lJhDfnBFCINyWxsiq1KD++qDQntfgQozQHi5I4r8O+CxFCAumJJanZqakF qUUwWSYOTqkGRsFlwrHuLTNzX2zZ+lH43+qPgr3OViEuNpWndySrfV4Q6rJcXPDebkcpTqEu foffrRY/D592cuF+OW+B6C0lvR/fb67eqX3z9iQJ8ZkhkTu7XXYzd75mU1e5G5Lo4R4reTmN wyNusdnsaa03d7d31zM+ueR4Y4VV/Ps6nWxLxSUznfUui6YdUGIpzkg01GIuKk4EAOjdDEsW AwAA
Archived-At: 
Subject: Re: [Pce] New Version Notification for draft-lazzeri-pce-residual-bw-00.txt
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 May 2017 15:35:06 -0000

SGkgV0csDQoNCldlIGp1c3QgdXBsb2FkZWQgYSBuZXcgZHJhZnQgZGVmaW5pbmcgdGhlIGV4dGVu
c2lvbnMgdG8gUENFUCBmb3IgdGhlIHVzYWdlIG9mIHRoZSBQYXRoIFJlc2lkdWFsIEJhbmR3ZGl0
aC4NClBsZWFzZSBzZWUgdGhlIGFic3RyYWN0IGJlbG93Lg0KDQpUaGFua3MNCkZyYW5jZXNjbywg
WW91bmcsIERhbmllbGUgIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50
ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSAN
ClNlbnQ6IHZlbmVyZMOsIDEyIG1hZ2dpbyAyMDE3IDE3OjI2DQpUbzogRnJhbmNlc2NvIExhenpl
cmkgPGZyYW5jZXNjby5sYXp6ZXJpQGVyaWNzc29uLmNvbT47IERhbmllbGUgQ2VjY2FyZWxsaSA8
ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbT47IFlvdW5nIExlZSA8bGVleW91bmdAaHVh
d2VpLmNvbT4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGF6
emVyaS1wY2UtcmVzaWR1YWwtYnctMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy
YWZ0LWxhenplcmktcGNlLXJlc2lkdWFsLWJ3LTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5
IHN1Ym1pdHRlZCBieSBEYW5pZWxlIENlY2NhcmVsbGkgYW5kIHBvc3RlZCB0byB0aGUgSUVURiBy
ZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtbGF6emVyaS1wY2UtcmVzaWR1YWwtYncNClJldmlz
aW9uOgkwMA0KVGl0bGU6CQlFeHRlbnNpb25zIHRvIHRoZSBQYXRoIENvbXB1dGF0aW9uIEVsZW1l
bnQgUHJvdG9jb2wgKFBDRVApIGZvciByZXNpZHVhbCBwYXRoIGJhbmR3aWR0aCBzdXBwb3J0DQpE
b2N1bWVudCBkYXRlOgkyMDE3LTA1LTEyDQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0K
UGFnZXM6CQkxNg0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0
LWRyYWZ0cy9kcmFmdC1sYXp6ZXJpLXBjZS1yZXNpZHVhbC1idy0wMC50eHQNClN0YXR1czogICAg
ICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1sYXp6ZXJpLXBjZS1y
ZXNpZHVhbC1idy8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv
ZHJhZnQtbGF6emVyaS1wY2UtcmVzaWR1YWwtYnctMDANCkh0bWxpemVkOiAgICAgICBodHRwczov
L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWxhenplcmktcGNlLXJlc2lkdWFs
LWJ3LTAwDQoNCg0KQWJzdHJhY3Q6DQogICAgIFRoZSBhYmlsaXR5IG9mIGEgaGllcmFyY2h5IG9m
IFBDRXMgdG8gY29tcHV0ZSBhY2N1cmF0ZSBlbmQtdG8tZW5kDQogICBwYXRocyBhY3Jvc3MgbXVs
dGlwbGUgZG9tYWlucyBpcyByZWNvZ25pemVkIGFzIGFuIGltcG9ydGFudA0KICAgcmVxdWlyZW1l
bnQgaW4gbWFueSBhcHBsaWNhdGlvbnMuDQogICAgICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBl
eHRlbnNpb25zIHRvIHRoZSBQQ0UgQ29tbXVuaWNhdGlvbg0KICAgUHJvdG9jb2wgKFBDRVApIGlu
IG9yZGVyIHRvIHByb3ZpZGUgbmV3IHBhdGgtcmVsYXRlZCBiYW5kd2lkdGgNCiAgIG1ldHJpY3Ms
IHdoaWNoIGEgUENDLCBsaWtlIGEgSC1QQ0UgKGVpdGhlciBzdGF0ZWZ1bCBvciBzdGF0ZWxlc3Mp
LA0KICAgY2FuIHVzZSBmcm9tIGFuIGVyc3R3aGlsZSBwYXRoIGNvbXB1dGF0aW9uIHRvIGRlcGxv
eSBtdWx0aXBsZSBMU1BzDQogICAoaGF2aW5nIHRoZSBzYW1lIGVuZC1wb2ludHMgYW5kIGNvbnN0
cmFpbnRzKSB3aXRob3V0IGFkZGl0aW9uYWwNCiAgIHJlcXVlc3RzLCB1bnRpbCBlaXRoZXIgdGhl
IHJlbWFpbmluZyBiYW5kd2lkdGggYWxvbmcgdGhhdCBwYXRoIGlzDQogICBhbGwgYWxsb2NhdGVk
IG9yIGEgZGVwbG95bWVudCBmYWlscy4NCiAgICAgIFRoaXMgaW5mb3JtYXRpb24gd291bGQgYWxz
byBiZSBiZW5lZmljaWFsIGZvciBpbXBsZW1lbnRpbmcNCiAgIGFic3RyYWN0aW9ucyBvZiB0aGUg
ZG9tYWluIHRvcG9sb2d5LCBidWlsZGluZyB0aGUgYWJzdHJhY3QNCiAgIGNvbm5lY3Rpdml0eSBp
bmNyZW1lbnRhbGx5LCBiYXNlZCBvbmx5IG9uIHJlYWxseSB1c2VkIGNvbnN0cmFpbnRzLA0KICAg
YXMgc29vbiBhcyBwYXRoIGNvbXB1dGF0aW9uIHJlc3VsdHMgYXJlIHJldHVybmVkLg0KDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBh
IGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUg
aHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3Jn
Lg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo=


From nobody Sat May 13 03:12:01 2017
Return-Path: 
X-Original-To: pce@ietf.org
Delivered-To: pce@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA95129485; Sat, 13 May 2017 03:11:59 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: pce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.50.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149467031937.13464.8616040256450007968@ietfa.amsl.com>
Date: Sat, 13 May 2017 03:11:59 -0700
Archived-At: 
Subject: [Pce] I-D Action: draft-ietf-pce-stateful-pce-p2mp-03.txt
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 May 2017 10:12:00 -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 of the IETF.

        Title           : Path Computation Element (PCE) Protocol Extensions for Stateful PCE usage for Point-to-Multipoint Traffic Engineering Label Switched Paths
        Authors         : Udayasree Palle
                          Dhruv Dhody
                          Yosuke Tanaka
                          Vishnu Pavan Beeram
	Filename        : draft-ietf-pce-stateful-pce-p2mp-03.txt
	Pages           : 32
	Date            : 2017-05-13

Abstract:
   The Path Computation Element (PCE) has been identified as an
   appropriate technology for the determination of the paths of point-
   to-multipoint (P2MP) TE LSPs.  This document provides extensions
   required for Path Computation Element communication Protocol (PCEP)
   so as to enable the usage of a stateful PCE capability in supporting
   P2MP TE LSPs.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-p2mp-03
https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-pce-p2mp-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-pce-p2mp-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 Sat May 13 07:00:32 2017
Return-Path: 
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5964A129B45; Sat, 13 May 2017 07:00:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.702
X-Spam-Level: 
X-Spam-Status: No, score=-4.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4AykyWMeD2N; Sat, 13 May 2017 07:00:24 -0700 (PDT)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50119.outbound.protection.outlook.com [40.107.5.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A3EB129B9D; Sat, 13 May 2017 06:58:32 -0700 (PDT)
Received: from DB6PR0601MB2167.eurprd06.prod.outlook.com (10.168.57.26) by DB6PR0601MB2166.eurprd06.prod.outlook.com (10.168.57.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.11; Sat, 13 May 2017 13:58:27 +0000
Received: from DB6PR0601MB2167.eurprd06.prod.outlook.com ([fe80::e824:5992:bf27:6643]) by DB6PR0601MB2167.eurprd06.prod.outlook.com ([fe80::e824:5992:bf27:6643%16]) with mapi id 15.01.1075.026; Sat, 13 May 2017 13:58:27 +0000
From: "Diego R. Lopez" 
To: Dan Frost 
CC: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-pce-pceps.all@ietf.org" , "pce@ietf.org" 
Thread-Topic: RtgDir review: draft-ietf-pce-pceps-12
Thread-Index: AQHSylt1ZRa8At1SrEClaZOroEkISaHyTCYA
Date: Sat, 13 May 2017 13:58:26 +0000
Message-ID: <940558E0-FF0F-4461-8122-F99C64D32C39@telefonica.com>
References: <1494509464.34491.973270680.4CBC76C2@webmail.messagingengine.com>
In-Reply-To: <1494509464.34491.973270680.4CBC76C2@webmail.messagingengine.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: mm.st; dkim=none (message not signed) header.d=none;mm.st; dmarc=none action=none header.from=telefonica.com;
x-originating-ip: [195.76.232.154]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB6PR0601MB2166; 7:iJgcIpMMs3aFXnQ2EjBFnli+iMiNTZut8jum+SexQK4xaVpSbtgYSA+jHqNIe04gpTx7NTN6S9TPodIOZ5ZaA3AxTFWItKouv+mLr+Upz27gH7IOuBEeQt+xc5ud1847ulK2dglnwBpTV69D9Ltw4Ca2dnLovp1jnjSwTX38QMF9MMh8Za/w471vvjJUiG/d7dWEL/zyDuBKQarccIGUr+MCSfh5xZmc0d57CtJKlu5nTJZd3Iql5R/lGujHLU9q2fnwyV9MMpM+1mJXhcflG3gdRcwQVF/376tkp8yvlLS6xV88ehXyepDg4HwDhYG8liggK031AMpHKBBHQQ2oSQ==
x-ms-office365-filtering-correlation-id: bd1b6ec8-699a-4b79-65cd-08d49a08210b
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081);  SRVR:DB6PR0601MB2166; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(40392960112811)(192374486261705)(21532816269658); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123558100)(20161123555025)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148); SRVR:DB6PR0601MB2166; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0601MB2166; 
x-forefront-prvs: 0306EE2ED4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39840400002)(39450400003)(39850400002)(39400400002)(39860400002)(40134004)(51914003)(377424004)(76104003)(377454003)(252514010)(24454002)(53546009)(2900100001)(606005)(6486002)(229853002)(6506006)(6436002)(10000500002)(2950100002)(6916009)(1720100001)(99286003)(33656002)(82746002)(53936002)(110136004)(966004)(6246003)(36756003)(38730400002)(4326008)(478600001)(83716003)(3660700001)(3280700002)(5250100002)(76176999)(54356999)(50986999)(25786009)(5660300001)(8676002)(3846002)(8936002)(6116002)(102836003)(81166006)(561944003)(66066001)(189998001)(230783001)(6512007)(6306002)(54906002)(53946003)(86362001)(7906003)(236005)(2906002)(7736002)(559001)(299355004)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0601MB2166; H:DB6PR0601MB2167.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: telefonica.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 May 2017 13:58:26.8891 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0601MB2166
Archived-At: 
Subject: Re: [Pce] RtgDir review: draft-ietf-pce-pceps-12
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 May 2017 14:00:30 -0000

--Apple-Mail=3D_9FEB5268-98BA-4654-BECA-5C16B7883EF6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=3Dutf-8

Hi Dan,

> On 11 May 2017, at 14:31 , Dan Frost  wrote:
>=3D20
>=3D20
> Hello,
>=3D20
> I have been selected as the Routing Directorate reviewer for this =3D
draft.
> The Routing Directorate seeks to review all routing or routing-related
> drafts as they pass through IETF last call and IESG review, and
> sometimes on special request. The purpose of the review is to provide
> assistance to the Routing ADs. For more information about the Routing
> Directorate, please see
> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>=3D20
> Although these comments are primarily for the use of the Routing ADs, =3D
it
> would be helpful if you could consider them along with any other IETF
> Last Call comments that you receive, and strive to resolve them =3D
through
> discussion or by updating the draft.
>=3D20
> Document: draft-ietf-pce-pceps-12
> Reviewer: Dan Frost
> Review Date: 2017-05-11
> IETF LC End Date:=3D20
> Intended Status: Standards Track
>=3D20
> Summary:
>=3D20
> I have significant concerns about this document and recommend that the
> Routing ADs discuss these issues further with the authors.
>=3D20
> Comments:
>=3D20
> This document proposes to add a STARTTLS mechanism to the PCE =3D
protocol.
> If this basic approach is accepted, then the document is in good =3D
shape.
> It's clear, complete, and straightforward. The question is whether
> mandating STARTTLS is actually a good idea.
>=3D20
> Major Issues:
>=3D20
> My main concern with this document is that it takes as given that
> STARTTLS is the right way to secure PCEP with TLS. Perhaps this =3D
argument
> was already had at some point and this draft is the result, but if so
> then at a bare minimum it needs rationale explaining why STARTTLS was
> chosen over alternatives, and text that addresses weaknesses and
> mitigations associated with STARTTLS processing, in particular the
> possibility and relative ease of downgrade attacks.
>=3D20
> The obvious alternative would be to not use STARTTLS and simply =3D
allocate
> another TCP port for PCEP-over-TLS. This avoids complicating the PCE
> protocol and introducing the potential for downgrade attacks based on
> STARTTLS. PCE is used to convey critical path-determination =3D
information
> in carrier networks, among other things. That it's not fully
> authenticated and encrypted in all cases already is an unfortunate
> legacy of a bygone era. Ideally operators should move as quickly as
> possible to secure PCEP and aim to entirely remove the unsecure form.
> STARTTLS serves a weaker goal of "opportunistic" security, which, =3D
while
> it has its uses, makes little sense for PCE compared to simply
> deprecating the unsecured version.

Thanks for the review. Regarding your major concern, let me try to give =3D
you and the Routing ADs the context for the use of the STARTTLS command. =
=3D
In the original versions of the draft we followed the proposal you =3D
suggest, with a dedicated port for the PCEPS protocol. Here you go the =3D
part of the -00 version (just after WG adoption, the last one proposing =3D
a dedicated port) regarding this point:

8<=3DE2=3D80=3D94
3.1.  TCP ports

   Since PCEP can operate either with or without TLS, it is necessary
   for the PCEP speaker to indicate whether it wants to set up a TLS
   connection or not.  There are two main ways of achieving this:

   o  One option is to use a different port number for TLS connections
      (for example, the port 443 used for HTTPS)

   o  The other is to use the regular port number and have the PCEP
      speaker request that the PCE switch the connection to TLS using a
      protocol-specific mechanism (for example, the STARTTLS for mail
      and news protocols)

   To avoid requiring a specific PCEP extension to request TLS, this
   document proposes the usage of the former solution to implement
   PCEPS.

   The default destination port number for PCEPS is TCP/XXXX.

   NOTE: This port has to be agreed and registered as PCEPS with IANA.
8<=3DE2=3D80=3D94

During the discussions for adoption, the community decided to contact =3D
experts from the TSVWG group to validate this and other proposals, and =3D
the connection with potentially related techniques like TCP-AO and what =3D
was being discussed in the TCPINC WG, now included in the "Security =3D
Considerations". During these discussions, those experts were extremely =3D
wary of the dedicated port approach, and the final decision was to move =3D
towards the STARTTLS approach. You have the complete record of the =3D
debate in the list archives, but I am including a excerpt of it below:

8<=3DE2=3D80=3D94

On 7/1/2014 7:45 AM, Diego R. Lopez wrote:
> On 30 Jun 2014, at 18:28 , Joe Touch > wrote:
>>>=3D20
>>> We are not proposing to use STARTTLS because, after discussing the
>>> different options for doing so in PCEP, we believe including it =3D
would
>>> translate into a change of the PCEP protocol:
>>> (1) against the original commitment of not changing it
>>> (2) would translate into a much longer adoption by implementations
>>=3D20
>> I don't understand or agree with either position. STARTTLS does not =3D
change the protocol; it precedes it.
>>=3D20
>> The complex mechanism below is, IMO, much less likely to be =3D
successfuly adopted than STARTTLS, which is widely used.
>=3D20
> As far as I know (RFC 2595, RFC 3207, RFC 4217, RFC 6120, RFC 2830,
> RFC 4642)

RFC4217 doesn't appear to use STARTTLS.
RFC6120 just refers completely back to RFC2595.

Section 2.1 of RFC2830 is a good example of performing STARTTLS in a =3D
non-plaintext command/response protocol (LDAP), and how simple it can =3D
and should be.

I now see your concern, but RFC2830 provides a great example of a very =3D
simple way to extend a protocol to address this issue. This further =3D
ensures that the security state (secure vs. not) is integrated within =3D
the protocol, so the protocol itself can disable commands if needed when =
=3D
security isn't available.

FWIW, Section 7 of RFC2595 gives a good summary of reasons why using a =3D
separate security port should be discouraged.

Joe


> STARTTLS is directly applicable to communication protocols
> based on plain-text command/response protocols. PCEP does not follow
> this model, so STARTTLS should become a new message or an object in =3D
the
> Open message. Both options imply changes in the PCEP protocol that =3D
look
> more complex than the suggested mechanism (or a dedicated port, if you
> pay attention to the discussion shared in the original message by Qin)


>=3D20
> Be goode,
>=3D20
>>=3D20
>> Joe
>>=3D20
>>>=3D20
>>> Be goode,
>>>=3D20
>>> On 28 Jun 2014, at 06:35 , Joe Touch > wrote:
>>>=3D20
>>>> Hi,
>>>>=3D20
>>>> On 6/24/2014 4:03 AM, Qin Wu wrote:
>>>>> Hi, Joe:
>>>>> Sorry for late reply.
>>>>>=3D20
>>>>> Authors have been discussing a mechanism to enable secure PCEP via
>>>>> TLS without making changes to the current PCEP protocol or state
>>>>> machine.
>>>>>=3D20
>>>>> Since having a separate port has been discouraged, we suggest the
>>>> ? following approach based on discovery mechanisms or configuration =
=3D
and
>>>>> initial transport security assessment by the peer.
>>>>>=3D20
>>>>> 1) A PCE (given a combination of IP address and port) only =3D
supports
>>>>> one type of connection, either TLS or not.
>>>>=3D20
>>>> I'm not sure why that needs to be the case, given STARTTLS.
>>>>=3D20
>>>>> Note that a different IP
>>>>> address SHOULD be used for supporting both and will be considered =3D
as
>>>>> different PCEs.
>>>>=3D20
>>>> I don't quite understand this. Different IP addresses should be =3D
different PCEs anyway. If you want to support both encrypted and =3D
non-encrypted, why not use the existing TLS mechanism for that - =3D
STARTTLS?
>>>>=3D20
>>>>> 2) The PCC MAY discover whether the PCE is willing to connect,
>>>>> requires TLS or not via any of the discovery mechanisms.
>>>>=3D20
>>>> That seems reasonable, but doesn't answer why a PCE needs to =3D
support only one type of connection. The discovery could indicate =3D
"either" and let the client decide, e.g., if both are supported (again, =3D
via STARTTLS)
>>>>=3D20
>>>>> 3) When connecting to a PCE that enforces TLS, the PCC MUST start =3D
a
>>>>> TLS connection prior to any exchange of PCEP messages.
>>>>=3D20
>>>> Isn't that already what happens if TLS-only is used?
>>>>=3D20
>>>>> Any PCEP message
>>>>> received out of an appropriate TLS context will be rejected by the =
=3D
PCE
>>>>> with a PCErr (Error-Type=3D3D1, Error-value=3D3D3, TLV identifying th=
e =3D
need for
>>>>> TLS) message. [Existing error message, new TLV]
>>>>=3D20
>>>> If non-TLS connections are rejected, then there shouldn't be any =3D
such messages seen AFAICT. I.e., that would be a TLS port that is =3D
configured to not support STARTTLS.
>>>>=3D20
>>>>> 4) If a PCC attempts to start a TLS connection with a PCE without
>>>>> success, it MAY attempt a further connection attempt without TLS =3D
on a
>>>>> different IP address if known, though that could imply a security
>>>>> degradation.
>>>>=3D20
>>>> I don't understand why a different address would be considered =3D
degraded access to the same PCE. That seems like a different PCE, as =3D
noted above.
>>>>=3D20
>>>> If you want to support degraded (non-secure) access, why not just =3D
support STARTTLS?
>>>>=3D20
>>>>> Several flows become possible this way, and discovery can be used =3D
to
>>>> simplify them but it is not essential for them to work. Let's =3D
consider them
>>>>>=3D20
>>>>> * With discovery (or config)
>>>>> 1.- PCC learn via discovery that the desired PCE require TLS.
>>>>> 2.- PCC initiates TCP connection and TLS handshake
>>>>> 3.- PCEP exchange within TLS context
>>>>=3D20
>>>> Makes sense.
>>>>=3D20
>>>>> ---
>>>>> 1.- PCC learn via discovery that the desired PCE does not use TLS.
>>>>> 2.- PCC initiates TCP connection
>>>>> 3.- PCEP exchange over TCP
>>>>=3D20
>>>> Makes sense.
>>>>=3D20
>>>>> * Without discovery - PCE requiring TLS
>>>>> 1.- PCC initiates TCP connection and TLS handshake
>>>>=3D20
>>>> Wouldn't the TLS handshake here fail? Why would the rest of the =3D
exchange occur?
>>>>=3D20
>>>>> 2.- PCEP exchange within TLS context
>>>>> ---
>>>>> 1.- PCC initiates TCP connection and attempts a PCEP OPEN message
>>>>> 2.- PCE rejects the message with a PCErr message (Error-Type=3D3D1, =
=3D
Error-value=3D3D3, TLV identifying the need for TLS(optionally))
>>>>> 3.- PCC initiates TCP connection and TLS handshake
>>>>> 4.- PCEP exchange within TLS context
>>>>=3D20
>>>> (see issue above)
>>>>=3D20
>>>>> * Without discovery - PCE not requiring TLS
>>>>> 1.- PCC initiates TCP connection
>>>>> 2.- PCEP exchange over TCP
>>>>> ---
>>>>> 1.- PCC initiates TCP connection and TLS handshake
>>>>=3D20
>>>> Why is this even attempted?
>>>>=3D20
>>>>> 2.- No TLS context established with PCE or error message received
>>>>> (optionally)
>>>>> 3.- PCC initiates TCP connection
>>>>> 4.- PCEP exchange over TCP
>>>>>=3D20
>>>>> What do you think of this approach?
>>>>>=3D20
>>>>> Also we like to point a related discussion happened on UTA mailing =
=3D
list:
>>>>> http://www.ietf.org/mail-archive/web/uta/current/msg00423.html =3D

>>>>=3D20
>>>> Those points were raised on the TSVWG list too, but fail to address =
=3D
the key issue - insecure ports are insecure. Regardless of how many =3D
ports we allocate, it's no longer clear we should continue to deploy new =
=3D
insecure services on the Internet.
>>>>=3D20
>>>> Joe
>>>>=3D20
>>>>>=3D20
>>>>> Regards,
>>>>> Authors
>>>>> -----=3DE9=3D82=3DAE=3DE4=3DBB=3DB6=3DE5=3D8E=3D9F=3DE4=3DBB=3DB6----=
-
>>>>> =3DE5=3D8F=3D91=3DE4=3DBB=3DB6=3DE4=3DBA=3DBA: Joe Touch [mailto:touc=
h@isi.edu =3D
]
>>>>> =3DE5=3D8F=3D91=3DE9=3D80=3D81=3DE6=3D97=3DB6=3DE9=3D97=3DB4: 2014=3D=
E5=3DB9=3DB43=3DE6=3D9C=3D8813=3DE6=3D97=3D
=3DA5 23:58
>>>>> =3DE6=3D94=3DB6=3DE4=3DBB=3DB6=3DE4=3DBA=3DBA: Qin Wu; Diego R. Lopez=
; tcpm@ietf.org =3D

>>>>> =3DE6=3D8A=3D84=3DE9=3D80=3D81: draft-ietf-pce-pceps@tools.ietf.org =
=3D

>>>>> =3DE4=3DB8=3DBB=3DE9=3DA2=3D98: Re: [tcpm] Looking for advice on a dr=
aft from =3D
the PCE working group
>>>>>=3D20
>>>>> Hi, Qin,
>>>>>=3D20
>>>>> On 3/13/2014 3:35 AM, Qin Wu wrote:
>>>>>> Hi, Joe:
>>>>>>=3D20
>>>>>> It is still not clear to me when we choose the same port and when =
=3D
we
>>>>>> choose the different port if we apply TLS to different protocols,
>>>>>=3D20
>>>>> It's simple to determine:
>>>>>=3D20
>>>>>      - if you designed your service before STARTTLS, then you =3D
needed
>>>>>      a separate port
>>>>>=3D20
>>>>>      - if you are designing your port now, you don't
>>>>>=3D20
>>>>>> Take SMTP, POP3,IMAP as examples:
>>>>> ...
>>>>>> It looks to me when we apply SSL to SMTP,POP3,IMAP, then SMTP, =3D
POP3
>>>>>> and IMAP with SSL support(i.e.,SMTPS,POP3S,IMAPS)
>>>>>>=3D20
>>>>>> Will usually choose the different ports.
>>>>>>=3D20
>>>>>> The same rule above is also applied to HTTP when we apply SSL to
>>>>>> HTTP(i.e., HTTPS).
>>>>>=3D20
>>>>> All of the above are good examples of the first part of the rule.
>>>>>=3D20
>>>>> Note that we have other assignments that now would be declined, =3D
because we've learned to do better. E.g., there would not be a POP2 or =3D
POP3 because we would expect POP to indicate the protocol version =3D
in-band. We also no longer assign multiple names for the same service, =3D
as was done for http/www, nor do we now assign multiple ports for the =3D
same service (80, 8080), nor do we now assign ports for development =3D
purposes  (http-dev).
>>>>>=3D20
>>>>> We've learned to do better.
>>>>>=3D20
>>>>> Joe
>>>>>=3D20
>>>=3D20


8<=3DE2=3D80=3D94

So we decided to go STARTTLS a-la-LDAP, so to say.=3D20

> Minor Issues:
>=3D20
> * Section 3.3: "A RECOMMENDED value for StartTLSWait timer is 60
> seconds." This seems like a very long time to wait for an initial =3D
reply
> on an already-established TCP connection.

This value was proposed to be of the order of magnitude of the KeepAlive =
=3D
PCEP timer (recommended to be of 30 seconds in RFC 5440) Since the =3D
StartTLS message is required to happen before any other message, it is =3D
not possible to rely on the timer negotiation during the Open message =3D
exchange. I agree the value looks very long, and we are open to any =3D
suggestion on this, either as recommending a concrete value or by =3D
recommending an interval (between 5 and 30 secs?)

> * Section 3.2, fifth paragraph (beginning with "A PCEP speaker
> receiving..."):
>=3D20
> This paragraph states: "A PCEP speaker receiving any other message =3D
apart
> from StartTLS, open, or PCErr MUST treat it as an unexpected =3D
message..."
>=3D20
> As written this is confusing and seems to imply that no other PCEP
> messages can ever be sent. It looks like this is meant to be scoped to
> the context of the first message sent/received on session initiation?

You are completely right. It should read: =3DE2=3D80=3D9CA PCEP speaker =3D
receiving as first message any other message apart
from StartTLS, Open, or PCErr MUST treat it as an unexpected message=3DE2=
=3D80=3D
=3DA6"

It is corrected in the new version I am editing right now.

> * Section 8.6
>=3D20
> The subsection titles of Section 8 have been taken from Section 8 of =3D
RFC
> 5440, but Section 8.6 here is called "Impact on Network Operations"
> while in RFC 5440 it's called "Impact on Network Operation". Funnily
> enough, that final "s" makes a difference. Without it, the section
> refers to an impact on the functioning of the network itself. With it,
> it would usually be taken to refer to impact on human operations and
> management procedures.
>=3D20
> It looks correct to say that the mechanism of this draft should not
> significantly impact the functioning of the network. On the other =3D
hand,
> it certainly does impact operations and management procedures, as =3D
staff
> have to develop policies around security requirements for PCEP within
> the organization, methods for verifying whether device security
> parameters are configured correctly, checking for unexpected =3D
downgrades
> to insecure sessions, etc. It would be an improvement for the document
> to address the impact of PCEPS on operational processes.

I believe all these operational policy aspects are discussed in the =3D
other subsections of section 8, and therefore making a explicit mention =3D
to them under 8.6 would be enough. BTW, in order to be consistent to RFC =
=3D
5440 I have deleted the =3DE2=3D80=3D9Cs=3DE2=3D80=3D9D in the title of the=
 =3D
section...

> Nits:
>=3D20
> Sec 3.1, first paragraph:
> OLD
>    The steps involved in the PCEPS establishment consists of following
>    successive steps:
> NEW
>    The steps involved in establishing a PCEPS session are as follows:
> END

Corrected.

> Sec 3.4, Step 3:
> s/Any attempt of initiate a TLS/Any attempt to initiate a TLS/

Corrected as well.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------


--Apple-Mail=3D_9FEB5268-98BA-4654-BECA-5C16B7883EF6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=3Dutf-8

Hi Dan,

On =
11 =3D
May 2017, at 14:31 , Dan Frost <frost@mm.st> wrote:


Hello,

I have been selected a=
s =3D
the Routing Directorate reviewer for this draft.
The =3D
Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, =
=3D
and
sometimes on special request. The purpose of the =3D
review is to provide
assistance to the Routing ADs. For =3D
more information about the Routing
Directorate, please =3D
see
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the=
 =3D
use of the Routing ADs, it
would be helpful if you could =
=3D
consider them along with any other IETF
Last Call comments =
=3D
that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-pce-pceps-12
Reviewer: Da=
n =3D
Frost
Review Date: 2017-05-11
IETF LC End =
=3D
Date: 
Intended Status: Standards Track

Summary:

I h=
ave =3D
significant concerns about this document and recommend that the
Routing ADs discuss these issues further with the authors.

Comments:

Th=
is =3D
document proposes to add a STARTTLS mechanism to the PCE protocol.
If this basic approach is accepted, then the document is in =
=3D
good shape.
It's clear, complete, and straightforward. The =
=3D
question is whether
mandating STARTTLS is actually a good =
=3D
idea.

Major Issues:

My main concern with this document is that it takes as given =
=3D
that
STARTTLS is the right way to secure PCEP with TLS. =3D
Perhaps this argument
was already had at some point and =3D
this draft is the result, but if so
then at a bare minimum =
=3D
it needs rationale explaining why STARTTLS was
chosen over =
=3D
alternatives, and text that addresses weaknesses and
mitigations associated with STARTTLS processing, in =3D
particular the
possibility and relative ease of downgrade =
=3D
attacks.

The obvious alternative would be =
=3D
to not use STARTTLS and simply allocate
another TCP port =
=3D
for PCEP-over-TLS. This avoids complicating the PCE
protoco=
l=3D
 and introducing the potential for downgrade attacks based on
STARTTLS. PCE is used to convey critical path-determination =
=3D
information
in carrier networks, among other things. That =
=3D
it's not fully
authenticated and encrypted in all cases =3D
already is an unfortunate
legacy of a bygone era. Ideally =
=3D
operators should move as quickly as
possible to secure =3D
PCEP and aim to entirely remove the unsecure form.
STARTTLS=
 =3D
serves a weaker goal of "opportunistic" security, which, while
it has its uses, makes little sense for PCE compared to =3D
simply
deprecating the unsecured version.

Thanks for the review. Regarding your major concern, let me =
=3D
try to give you and the Routing ADs the context for the use of the =3D
STARTTLS command. In the original versions of the draft we followed the =3D
proposal you suggest, with a dedicated port for the PCEPS protocol. Here =
=3D
you go the part of the -00 version (just after WG adoption, the last one =
=3D
proposing a dedicated port) regarding this point:
8<=3DE2=3D80=3D94
3.1.  TCP =
=3D
ports

   Since PCEP can operate =3D
either with or without TLS, it is necessary
   for the PCEP speaker =
=3D
to indicate whether it wants to set up a TLS
   connection or =3D
not.  There are two main ways of achieving this:

   o  One option is to use a =3D
different port number for TLS connections
      (for example, =
=3D
the port 443 used for HTTPS)

   o  The other is to use the regular port =3D
number and have the PCEP
      speaker request that the PCE =3D
switch the connection to TLS using a
      protocol-specific =
=3D
mechanism (for example, the STARTTLS for mail
      and news =3D
protocols)

   To avoid requiring a =
=3D
specific PCEP extension to request TLS, this
   document proposes the =
=3D
usage of the former solution to implement
   PCEPS.

   The default destination port number for =
=3D
PCEPS is TCP/XXXX.

   NOTE: This port has =
=3D
to be agreed and registered as PCEPS with IANA.
8<=3DE2=3D80=3D94

<=
/div>
During the discussions for adoption, the community decided to =
=3D
contact experts from the TSVWG group to validate this and other =3D
proposals, and the connection with potentially related techniques like =3D
TCP-AO and what was being discussed in the TCPINC WG, now included in =3D
the "Security Considerations". During these discussions, those experts =3D
were extremely wary of the dedicated port approach, and the final =3D
decision was to move towards the STARTTLS approach. You have the =3D
complete record of the debate in the list archives, but I am including a =
=3D
excerpt of it below:

8<=3DE2=3D80=3D94

<=
/div>
On 7/1/201=
4 =3D
7:45 AM, Diego R. Lopez wrote:
On 30 Jun 2014, at 18:28 , Joe Touch <touch@isi.edu> wrote:

We are not proposing to use STARTTLS because,=
 =3D
after discussing the
different options for doing so in =3D
PCEP, we believe including it would
translate into a =3D
change of the PCEP protocol:
(1) against the original =3D
commitment of not changing it
(2) would translate into a =
=3D
much longer adoption by implementations

I don't understand or agree with either position. STARTTLS =3D
does not change the protocol; it precedes it.

The complex mechanism below is, IMO, much less likely to be =
=3D
successfuly adopted than STARTTLS, which is widely used.

As far as I know (RFC 2595, RFC =
=3D
3207, RFC 4217, RFC 6120, RFC 2830,
RFC 4642)

RFC4217 =
=3D
doesn't appear to use STARTTLS.
RFC6120 ju=
st =3D
refers completely back to RFC2595.

Section 2.1 of RFC2830 is a =
=3D
good example of performing STARTTLS in a non-plaintext command/response =3D
protocol (LDAP), and how simple it can and should be.

I=
 =3D
now see your concern, but RFC2830 provides a great example of a very =3D
simple way to extend a protocol to address this issue. This further =3D
ensures that the security state (secure vs. not) is integrated within =3D
the protocol, so the protocol itself can disable commands if needed when =
=3D
security isn't available.

FWIW, Section 7 of RFC2595 =
=3D
gives a good summary of reasons why using a separate security port =3D
should be discouraged.

Joe


STARTTLS is directly applicable to communication protocols
based on plain-text command/response protocols. PCEP does not =
=3D
follow
this model, so STARTTLS should become a new message =
=3D
or an object in the
Open message. Both options imply =3D
changes in the PCEP protocol that look
more complex than =
=3D
the suggested mechanism (or a dedicated port, if you
pay =
=3D
attention to the discussion shared in the original message by Qin)



Be goode,

Joe


Be goode,

On=
 28 =3D
Jun 2014, at 06:35 , Joe Touch <touch@isi.edu> wrote:

Hi,
<=
br =3D
class=3D3D"">On 6/24/2014 4:03 AM, Qin Wu wrote:
Hi, Joe:
Sorry for late reply.=


Authors have been discussing a mechanism to =
=3D
enable secure PCEP via
TLS without making changes to the =
=3D
current PCEP protocol or state
machine.
Since having a separate port has been discouraged, we suggest =
=3D
the
? following approach based on discovery =
=3D
mechanisms or configuration and
initial transport security assessment by the peer.

1) A PCE (given a combination of IP address =
=3D
and port) only supports
one type of connection, either TLS =
=3D
or not.

I'm not sure why that=
 =3D
needs to be the case, given STARTTLS.

Note that a different=
 =3D
IP
address SHOULD be used for supporting both and will be =
=3D
considered as
different PCEs.
=
I don't quite understand this. Different IP addresses should =
=3D
be different PCEs anyway. If you want to support both encrypted and =3D
non-encrypted, why not use the existing TLS mechanism for that - =3D
STARTTLS?

2) The PCC MAY discover whether the PCE is willing to =3D
connect,
requires TLS or not via any of the discovery =3D
mechanisms.

That seems =3D
reasonable, but doesn't answer why a PCE needs to support only one type =3D
of connection. The discovery could indicate "either" and let the client =3D
decide, e.g., if both are supported (again, via STARTTLS)

3) W=
hen =3D
connecting to a PCE that enforces TLS, the PCC MUST start a
TLS connection prior to any exchange of PCEP messages.

Isn't that already what happens =
=3D
if TLS-only is used?

Any PCEP message
received out =
of =3D
an appropriate TLS context will be rejected by the PCE
with=
 =3D
a PCErr (Error-Type=3D3D1, Error-value=3D3D3, TLV identifying the need =3D
for
TLS) message. [Existing error message, new TLV]

If non-TLS connections are =3D
rejected, then there shouldn't be any such messages seen AFAICT. I.e., =3D
that would be a TLS port that is configured to not support STARTTLS.

4) I=
f a =3D
PCC attempts to start a TLS connection with a PCE without
success, it MAY attempt a further connection attempt without =
=3D
TLS on a
different IP address if known, though that could =
=3D
imply a security
degradation.
=
I don't understand why a different address would be =3D
considered degraded access to the same PCE. That seems like a different =3D
PCE, as noted above.

If you want to suppor=
t =3D
degraded (non-secure) access, why not just support STARTTLS?

Seve=
ral =3D
flows become possible this way, and discovery can be used to
simplify them but it is not essential for them =
=3D
to work. Let's consider them

* With discovery (or config)
=
1.- =3D
PCC learn via discovery that the desired PCE require TLS.
2.- PCC initiates TCP connection and TLS handshake
3.- PCEP exchange within TLS context

Makes sense.
---
1=
.- =3D
PCC learn via discovery that the desired PCE does not use TLS.
2.- PCC initiates TCP connection
3.- PCEP =3D
exchange over TCP

Makes =3D
sense.

*=3D
 Without discovery - PCE requiring TLS
1.- PCC initiates =
=3D
TCP connection and TLS handshake

Wouldn't the TLS handshake here fail? Why would the rest of =
=3D
the exchange occur?

2.- PCEP exchange within TLS context
---
1.- PCC initiates TCP connection and attempts a PCEP OPEN =3D
message
2.- PCE rejects the message with a PCErr message =
=3D
(Error-Type=3D3D1, Error-value=3D3D3, TLV identifying the need for =3D
TLS(optionally))
3.- PCC initiates TCP connection and TLS =
=3D
handshake
4.- PCEP exchange within TLS context

(see issue above)
* Without discovery =
- =3D
PCE not requiring TLS
1.- PCC initiates TCP connection
2.- PCEP exchange over TCP
---
1.- =3D
PCC initiates TCP connection and TLS handshake

Why is this even attempted?

2.- =
No =3D
TLS context established with PCE or error message received
(optionally)
3.- PCC initiates TCP =3D
connection
4.- PCEP exchange over TCP

What do you think of this approach?

Also we like to point a related discussion happened on UTA =3D
mailing list:
http://www.ietf.org/mail-archive/web/uta/current/msg00423.html=
<=3D
/a>

Those points were raised =
=3D
on the TSVWG list too, but fail to address the key issue - insecure =3D
ports are insecure. Regardless of how many ports we allocate, it's no =3D
longer clear we should continue to deploy new insecure services on the =3D
Internet.

Joe


Rega=
rds,Authors
-----=3DE9=3D82=3DAE=3DE4=3DBB=3DB6=
=3DE5=3D8E=3D9F=3DE4=3DBB=3DB6=3D
-----
=3DE5=3D8F=3D91=3DE4=3DBB=3DB6=3DE4=3DBA=3DBA: Joe To=
uch [mailto:touch@isi.edu]
=3DE5=3D8F=3D91=3DE9=3D80=3D81=3DE6=3D97=3DB6=3DE9=3D97=3DB4: =
2014=3DE5=3DB9=3DB43=3DE6=3D9C=3D8813=3D
=3DE6=3D97=3DA5 23:58
=3DE6=3D94=3DB6=3DE4=3DBB=3DB6=3DE4=
=3DBA=3DBA: Qin Wu; Diego =3D
R. Lopez; tcpm@ietf.org
=3DE6=3D8A=3D84=3DE9=3D80=3D=
81: draft-ietf-pce-pceps@tools.ietf.org
=3DE4=
=3DB8=3DBB=3D
=3DE9=3DA2=3D98: Re: [tcpm] Looking for advice on a draft from the PCE work=
ing =3D
group

Hi, Qin,

On 3/13/2014 3:35 AM, Qin Wu wrote:
Hi, Joe:

It i=
s =3D
still not clear to me when we choose the same port and when we
choose the different port if we apply TLS to different =3D
protocols,

It's simple to =3D
determine:

     -=
 =3D
if you designed your service before STARTTLS, then you needed
     a separate port
=
     - if you are designing your =3D
port now, you don't

Take SMTP, POP3,IMAP as examples:
...
It looks to me when we apply SSL to SMTP,POP3,IMAP, then =3D
SMTP, POP3
and IMAP with SSL =3D
support(i.e.,SMTPS,POP3S,IMAPS)

Will =3D
usually choose the different ports.

The =
=3D
same rule above is also applied to HTTP when we apply SSL to
HTTP(i.e., HTTPS).

All of the above are good examples of the first part of the =
=3D
rule.

Note that we have other assignments =
=3D
that now would be declined, because we've learned to do better. E.g., =3D
there would not be a POP2 or POP3 because we would expect POP to =3D
indicate the protocol version in-band. We also no longer assign multiple =
=3D
names for the same service, as was done for http/www, nor do we now =3D
assign multiple ports for the same service (80, 8080), nor do we now =3D
assign ports for development purposes  (http-dev).
We've learned to do better.

J=
oe


8<=3DE2=3D80=3D94<=
/div>

So we decided to go =
=3D
STARTTLS a-la-LDAP, so to say. 

Minor Issues:

* Section 3.3: "A RECOMMENDED value for StartTLSWait timer is =
=3D
60
seconds." This seems like a very long time to wait for =
=3D
an initial reply
on an already-established TCP =3D
connection.

This value was proposed to be of the order of =3D
magnitude of the KeepAlive PCEP timer (recommended to be of 30 seconds =3D
in RFC 5440) Since the StartTLS message is required to happen before any =
=3D
other message, it is not possible to rely on the timer negotiation =3D
during the Open message exchange. I agree the value looks very long, and =
=3D
we are open to any suggestion on this, either as recommending a concrete =
=3D
value or by recommending an interval (between 5 and 30 secs?)

* =
=3D
Section 3.2, fifth paragraph (beginning with "A PCEP speaker
receiving..."):

This paragrap=
h =3D
states: "A PCEP speaker receiving any other message apart
from StartTLS, open, or PCErr MUST treat it as an unexpected =
=3D
message..."

As written this is confusing =
=3D
and seems to imply that no other PCEP
messages can ever be =
=3D
sent. It looks like this is meant to be scoped to
the =3D
context of the first message sent/received on session initiation?

You are =
=3D
completely right. It should read: =3DE2=3D80=3D9CA PCEP speaker receiving a=
s =3D
first message any other message apart
from =3D
StartTLS, Open, or PCErr MUST treat it as an unexpected =3D
message=3DE2=3D80=3DA6"

It is correct=
ed in =3D
the new version I am editing right now.

* Section 8.6

The subsection titles of Section 8 have been taken from =3D
Section 8 of RFC
5440, but Section 8.6 here is called =3D
"Impact on Network Operations"
while in RFC 5440 it's =3D
called "Impact on Network Operation". Funnily
enough, that =
=3D
final "s" makes a difference. Without it, the section
refer=
s=3D
 to an impact on the functioning of the network itself. With it,
it would usually be taken to refer to impact on human =3D
operations and
management procedures.

It looks correct to say that the mechanism of this draft =3D
should not
significantly impact the functioning of the =3D
network. On the other hand,
it certainly does impact =3D
operations and management procedures, as staff
have to =3D
develop policies around security requirements for PCEP within
the organization, methods for verifying whether device =3D
security
parameters are configured correctly, checking for =
=3D
unexpected downgrades
to insecure sessions, etc. It would =
=3D
be an improvement for the document
to address the impact =
=3D
of PCEPS on operational processes.

I believe =
=3D
all these operational policy aspects are discussed in the other =3D
subsections of section 8, and therefore making a explicit mention to =3D
them under 8.6 would be enough. BTW, in order to be consistent to RFC =3D
5440 I have deleted the =3DE2=3D80=3D9Cs=3DE2=3D80=3D9D in the title of the=
 =3D
section...

Nits:

Sec 3=
.1, =3D
first paragraph:
OLD
    The=
 =3D
steps involved in the PCEPS establishment consists of following
    successive steps:
NEW
    The steps involved in establishing a PCEPS =
=3D
session are as follows:
END

Corrected.

Sec =3D
3.4, Step 3:
s/Any attempt of initiate a TLS/Any attempt =
=3D
to initiate a TLS/

Corrected as well.

Be goode,



--
"Esta vez no fallaremos, Doctor Infierno"
Dr Diego R. Lopez
Telefonica =
=3D
I+D
http://people.tid.es/diego.lopez/

e-mail: diego.r.lopez@telefonica.com
Tel: =3D
   +34 913 129 041
Mobile: +34 682 051 091
----------------------------------





=3D

--Apple-Mail=3D_9FEB5268-98BA-4654-BECA-5C16B7883EF6--

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu=
ede contener informaci=F3n privilegiada o confidencial y es para uso exclus=
ivo de la persona o entidad de destino. Si no es usted. el destinatario ind=
icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o=
 copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci=
=F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo =
comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti=
al information intended only for the use of the individual or entity named =
above. If the reader of this message is not the intended recipient, you are=
 hereby notified that any dissemination, distribution or copying of this co=
mmunication is strictly prohibited. If you have received this transmission =
in error, do not read it. Please immediately reply to the sender that you h=
ave received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio=
, pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex=
clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des=
tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div=
ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude=
 da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe =
que nos o comunique imediatamente por esta mesma via e proceda a sua destru=
i=E7=E3o


From nobody Tue May 16 00:55:05 2017
Return-Path: 
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A5212EAB6; Tue, 16 May 2017 00:55:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.466
X-Spam-Level: *
X-Spam-Status: No, score=1.466 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDU3SoLEJu3n; Tue, 16 May 2017 00:55:02 -0700 (PDT)
Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [161.106.1.3]) by ietfa.amsl.com (Postfix) with ESMTP id 60C271272E1; Tue, 16 May 2017 00:51:58 -0700 (PDT)
Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AB434E300A7; Tue, 16 May 2017 09:51:56 +0200 (CEST)
Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail2.rd.orange.com (Postfix) with ESMTP id 95203E300A2; Tue, 16 May 2017 09:51:56 +0200 (CEST)
Received: from [10.193.71.226] (10.193.71.226) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.319.2; Tue, 16 May 2017 09:51:56 +0200
References: <039fda74-e8e4-18a5-326c-c36b7242bf01@orange.com>
To: "draft-ietf-pce-lsp-setup-type@ietf.org" 
CC: 
From: Julien Meuric 
Organization: Orange
Message-ID: <38476f4c-e7c9-724e-c66b-495b5ecad6bc@orange.com>
Date: Tue, 16 May 2017 09:51:55 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <039fda74-e8e4-18a5-326c-c36b7242bf01@orange.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Pce] WG Last Call of draft-ietf-pce-lsp-setup-type-04
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 07:55:04 -0000

Hi all,

This LC has ended. Authors, please resolve the open comment on this I-D
so that we can send it to the IESG.

Thanks,

Jon, JP & Julien


May. 02, 2017 - Julien Meuric:
> Dear all,
>
> The aforementioned I-D has been stable for a while. This message
> initiates a 2-week WG Last Call on draft-ietf-pce-lsp-setup-type-04.
> Please send your comments to the PCE mailing list by May 15.
>
> Thanks,
>
> Jon, JP & Julien
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>


From nobody Tue May 16 00:59:18 2017
Return-Path: 
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA59129C36; Tue, 16 May 2017 00:59:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.465
X-Spam-Level: *
X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyLscat-V9Ii; Tue, 16 May 2017 00:59:16 -0700 (PDT)
Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [161.106.1.3]) by ietfa.amsl.com (Postfix) with ESMTP id 0797F129496; Tue, 16 May 2017 00:55:25 -0700 (PDT)
Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 67FFAE300A8; Tue, 16 May 2017 09:55:24 +0200 (CEST)
Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail2.rd.orange.com (Postfix) with ESMTP id 45A47E300A6; Tue, 16 May 2017 09:55:24 +0200 (CEST)
Received: from [10.193.71.226] (10.193.71.226) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.319.2; Tue, 16 May 2017 09:55:23 +0200
From: Julien Meuric 
To: "draft-ietf-pce-lsp-setup-type@ietf.org" 
CC: "pce@ietf.org" 
Organization: Orange
Message-ID: 
Date: Tue, 16 May 2017 09:55:23 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [Pce] Final IPR Check for draft-ietf-pce-lsp-setup-type
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 07:59:17 -0000

Dear authors,

 

Could you please send an email to the PCE mailing list saying whether
you are aware of any IPR that applies to draft-ietf-pce-lsp-setup-type
and, if so, if it has been disclosed in compliance with IETF IPR rules?
(See RFCs 3979, 4879, 3669 and 5378 for more details.)  If you are not
aware of any IPR that applies, please reply saying "I am not aware of
any IPR that applies to this draft".

 

A reply is required from each of you before we can proceed.

 

Many thanks,


Julien


From nobody Wed May 17 04:56:21 2017
Return-Path: 
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 294B712EB69 for ; Wed, 17 May 2017 04:56:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.699
X-Spam-Level: 
X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk
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 aQHDWOoMZrc0 for ; Wed, 17 May 2017 04:56:18 -0700 (PDT)
Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49F7E127599 for ; Wed, 17 May 2017 04:51:40 -0700 (PDT)
Received: from nitebug.localdomain (46.229.239.158.host.vnet.sk [46.229.239.158]) by mail.hq.sk (Postfix) with ESMTPSA id 2F2A02401FC; Wed, 17 May 2017 13:51:38 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1495021898; bh=i9qWSCAeu4NWXX6QHjzTPvjf38hlm+pTmCjgflmECKU=; h=Subject:To:References:From:Date:In-Reply-To; b=qiCi4QOaH1FCz/VpS5vObG0HnBkiy4w/kYiuh3Cmw/hDlHZgOvdUGSEoljtr2iyTt 8VcgmKaZQyPThp+rlYNIgx4kWTU1IPLfLJ8nF+xd3D4GavMWy/+rA2KjpOwQup1XUG oSdqdZhahLyiy15zyfAQgI0fcakLDTx0aY+3V3Uw=
To: Ramon Casellas , pce@ietf.org
References:   <24b92f98-0702-a2d9-ac36-ab257a128e4c@orange.com> <858927fd-6a06-0d10-6c24-1dc6a3faa80c@cttc.es>
From: Robert Varga 
Message-ID: 
Date: Wed, 17 May 2017 13:51:37 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0
MIME-Version: 1.0
In-Reply-To: <858927fd-6a06-0d10-6c24-1dc6a3faa80c@cttc.es>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Xhg0PaUqTr9LQEF4336XVUAJOicql6eXh"
Archived-At: 
Subject: Re: [Pce] Stateful PCE: inconsistency in "resource limit" text
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 May 2017 11:56:20 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Xhg0PaUqTr9LQEF4336XVUAJOicql6eXh
Content-Type: multipart/mixed; boundary="s8rvTiaHLJjHqtcc06moJoErk5JreHuPC";
 protected-headers="v1"
From: Robert Varga 
To: Ramon Casellas , pce@ietf.org
Message-ID: 
Subject: Re: [Pce] Stateful PCE: inconsistency in "resource limit" text
References: 
 
 <24b92f98-0702-a2d9-ac36-ab257a128e4c@orange.com>
 <858927fd-6a06-0d10-6c24-1dc6a3faa80c@cttc.es>
In-Reply-To: <858927fd-6a06-0d10-6c24-1dc6a3faa80c@cttc.es>

--s8rvTiaHLJjHqtcc06moJoErk5JreHuPC
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 09/05/17 10:50, Ramon Casellas wrote:
> Hi Julien,
>=20
> This is indeed making me raise more questions than expected.
>=20
> - Reading the section I got the feeling that any event preventing to
> reach full sync state caused a PCErr (now PCNtf) and a MUST session
> close. was it the intent?

Hello Ramon,

with a co-author hat on, but without loading the draft completely into
brain again, yes, this was the intent. The reasoning behind is to
provide an initial baseline for the state present on the PCC, agreed by
both PCE and PCC.

This simplifies the protocol design a bit, as we do not have to deal
with state synchronization being half-done.

Furthermore it gives the PCE a chance to attempt to re-negotiate the
session parameters based on the problem it has seen with the PCRpt.

Regards,
Robert


--s8rvTiaHLJjHqtcc06moJoErk5JreHuPC--

--Xhg0PaUqTr9LQEF4336XVUAJOicql6eXh
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIoBAEBCgASBQJZHDlJCxxuaXRlQGhxLnNrAAoJECsDwSqgzwDTF5wQAJrAg1DW
3OWRqFW3EyHm1shHWGBUjKZyN4kxt43NTZzBUz8Gz8nG15i+gso8+D47/pn/tg2G
7S8O/+svtMhAQHp06Qg4UJDN+Q29b0F6UU4ngReuixF/ioenythTM84NML+NSMCM
R81j/VWcSrGB9Cz2vzE59W7Ge8mtAPD1vr11zbpEtMkW1uULJge+jRokUedzwsO+
wZYD6yu24cAoND+AoxJCP+XQlWLJweo3TISIDQr/2qZSL6BiPcoEGSoG3Wu3D4J6
6jpCucXlHnRdMrIXVm57JJ1wj9CcGqSDJ1jHJ2OgJLQ0TRiaQrg7YOatD/M3zEWT
Q98wsGPKNdr+qR0Zn0staWBf/RR+b7YaAf2VLsXPQFyidMJE0XzcK8nSU899cfuX
kHxSoJ569/oQM0H0bGagmba+5q8J7B9DZ9FhyIiZ5Hq8O2pmRzGlol/XUda7I29L
29LxVydaFA74mddODRxCjSRTCE+bMC4/azyQyr3cZGZFTr5nO3ajs+F59PbT4w+F
Xx3AY45NFfLnigvy5meK/rpX/Qp8Ljo6ARxCF/A+vX8hg5pfq9P0pCZAtgp9VJ9I
Z0xcfpXh454+RwELPL5pVsbJ19TBRTYQmKW4lDIE/oZoOm1AOWIV5qgaudtyymUz
kYH6OQfe3ev7KI8Lc0B5VUEQVanj+AfBwxt4
=JWle
-----END PGP SIGNATURE-----

--Xhg0PaUqTr9LQEF4336XVUAJOicql6eXh--


From nobody Wed May 17 06:43:09 2017
Return-Path: 
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B4B12EC95 for ; Wed, 17 May 2017 06:43:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_SPF_HELO_TEMPERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=metaswitch.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWmwGcHK8XPh for ; Wed, 17 May 2017 06:43:01 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0102.outbound.protection.outlook.com [104.47.33.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AC9012EC07 for ; Wed, 17 May 2017 06:37:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=g4wevPeDuUHMomxOdyd/TEykJP52z4Uga3EznlfKn3E=; b=lF3Erw/KmHz97tIuHH7RMngO5VkDq3m/Rm6g2xKDPRke8ZKtznjXOIgcV6uvOkg9riJxszpnMvQfA3mRgPlY9p2K7rWbEmoV63ENhzWpt68ldctSQIFeb8c+5Aeb0X4HldE6EUh7LF10ub5kXe1l5BcKPU40clWkusVXHpJPYU4=
Received: from BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) by BY2PR0201MB1911.namprd02.prod.outlook.com (10.163.75.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.16; Wed, 17 May 2017 13:37:09 +0000
Received: from BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) by BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) with mapi id 15.01.1084.030; Wed, 17 May 2017 13:37:09 +0000
From: Jonathan Hardwick 
To: Robert Varga , Ramon Casellas , "stephane.litkowski@orange.com" , Dhruv Dhody , Julien Meuric 
CC: "pce@ietf.org" 
Thread-Topic: [Pce] Stateful PCE: inconsistency in "resource limit" text
Thread-Index: AdLIFcW0FlKFj/hRS7i+bnJA6UAqeAAKaGqAABfzPIABmVpPEAADJ4MQ
Date: Wed, 17 May 2017 13:37:08 +0000
Message-ID: 
References:   <24b92f98-0702-a2d9-ac36-ab257a128e4c@orange.com> <858927fd-6a06-0d10-6c24-1dc6a3faa80c@cttc.es> 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: hq.sk; dkim=none (message not signed) header.d=none;hq.sk; dmarc=none action=none header.from=metaswitch.com;
x-originating-ip: [86.137.0.176]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2PR0201MB1911; 7:sR8TaEJguSbYIEoTslJg/lV09LdAiYfyOhpbyW+TWJa2dJMOwLtT97Jc2ECAWPlEq6yaQN3esRpYjwB9eDY3vtPOCsouBs9Nvb7OioTXDj1hugd1M7bX/CdazWIYOPMObsSLMFkvs7Nn0JUg2Xq9PWerp4z1RxVQbW7pPnbynOQKsA7fR6ZnUseJhiC08K9QFm89Oj5X4H3fs+N2TKfrwfAd2d3C1dLng/4mO2D/tdhy1ZNNiMCmYYcV2UrZHm/0UmoWUOoq88Usgyu5wB9qi7WlATv5uSumns5TTuoqixGLRhtW6HOTLLsNLQ1WrS/sE2zN2qqsHMMPqosBkqNVSA==
x-ms-office365-filtering-correlation-id: 2672e7d7-da5e-497e-41ac-08d49d29d0ff
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BY2PR0201MB1911; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123560025)(20161123558100)(20161123555025)(6072148); SRVR:BY2PR0201MB1911; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0201MB1911; 
x-forefront-prvs: 0310C78181
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39840400002)(39410400002)(39400400002)(39850400002)(66654002)(13464003)(24454002)(53754006)(4326008)(189998001)(5660300001)(3660700001)(2900100001)(72206003)(66066001)(9686003)(39060400002)(81166006)(8676002)(2906002)(6506006)(6436002)(8936002)(74316002)(76176999)(54356999)(99286003)(55016002)(86362001)(50986999)(229853002)(53936002)(77096006)(478600001)(102836003)(6116002)(3846002)(33656002)(7696004)(122556002)(6246003)(7736002)(305945005)(38730400002)(25786009)(2950100002)(3280700002)(53546009)(2501003)(93886004); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0201MB1911; H:BY2PR0201MB1910.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: metaswitch.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2017 13:37:08.9700 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1911
Archived-At: 
Subject: Re: [Pce] Stateful PCE: inconsistency in "resource limit" text
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 May 2017 13:43:07 -0000

Hi all

Thanks for your feedback on this issue.  I think we are probably in a posit=
ion to close this issue down.  To summarize:

- The original intent was that the PCE MUST close the session.
- It seems that nobody has implemented the "exiting resource limit exceeded=
 state" notification.

On the other hand, if we did weaken "MUST close" to "MAY close", then the d=
raft provides no guidance about what the PCC and PCE are supposed to do nex=
t with this session in which only part of the state has been kept by the PC=
E.  I don't want to start drafting that guidance at this late stage.

My conclusion is that we should specify that the PCE MUST close the session=
, and we should release the code point currently allocated to the "exiting =
resource limit exceeded state" notification.

If anyone has strong objections to this, please shout ASAP.

Many thanks
Jon


-----Original Message-----
From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Robert Varga
Sent: 17 May 2017 12:52
To: Ramon Casellas ; pce@ietf.org
Subject: Re: [Pce] Stateful PCE: inconsistency in "resource limit" text

On 09/05/17 10:50, Ramon Casellas wrote:
> Hi Julien,
>=20
> This is indeed making me raise more questions than expected.
>=20
> - Reading the section I got the feeling that any event preventing to=20
> reach full sync state caused a PCErr (now PCNtf) and a MUST session=20
> close. was it the intent?

Hello Ramon,

with a co-author hat on, but without loading the draft completely into brai=
n again, yes, this was the intent. The reasoning behind is to provide an in=
itial baseline for the state present on the PCC, agreed by both PCE and PCC=
.

This simplifies the protocol design a bit, as we do not have to deal with s=
tate synchronization being half-done.

Furthermore it gives the PCE a chance to attempt to re-negotiate the sessio=
n parameters based on the problem it has seen with the PCRpt.

Regards,
Robert


From nobody Wed May 17 06:44:20 2017
Return-Path: 
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9F8112EB40; Wed, 17 May 2017 06:44:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.022
X-Spam-Level: 
X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=metaswitch.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ke2_3BczgWWO; Wed, 17 May 2017 06:44:17 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0119.outbound.protection.outlook.com [104.47.33.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE92112EB42; Wed, 17 May 2017 06:38:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=I+3o1j5NQcHpyC3TI1RWtwrCT8VDTErLhyzPCwkfV4Q=; b=prUkWDaJQ0i9ImrAzO0L4F2V8cX/4tA75qExxKj9dO6hRbOD7iFcN6thVnqEklk4EH9iT5d9AQnfXpz3343LO9Y10zdHq6iEQCL38dvhPqABlwepIvlwziTqQnrXc0gbWRIbJiB/ggFu6kJzYD9+DtMugK/9ff6lBRpzCjCx9BQ=
Received: from BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) by BY2PR0201MB1911.namprd02.prod.outlook.com (10.163.75.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.16; Wed, 17 May 2017 13:38:04 +0000
Received: from BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) by BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) with mapi id 15.01.1084.030; Wed, 17 May 2017 13:38:04 +0000
From: Jonathan Hardwick 
To: Julien Meuric , "draft-ietf-pce-lsp-setup-type@ietf.org" 
CC: "pce@ietf.org" 
Thread-Topic: Final IPR Check for draft-ietf-pce-lsp-setup-type
Thread-Index: AQHSzhpSqD+xtGl5fUi5BghTOaanbqH4iVLg
Date: Wed, 17 May 2017 13:38:03 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=metaswitch.com;
x-originating-ip: [86.137.0.176]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2PR0201MB1911; 7:R9iaMbwqurQcMpyS7+LdODhaCm/l/bgfkEUe2nW0vHqZDWlRUSLslgFjrPVBFKTTLuNQmPgU6aSduB30u5w8nk+c13aTd5f2FEIG2pqMuFJjo2jykY4WPFxwuUBCA4XZs/UQOGWMqygkUZsu1XyB8Ws0OU4eAkF1oBpoJ8oBd/UM9ugTv1GeEMjZmsBNlE7Hg3EqCn8JqVVpQO3DzGc8v5Hyln7YYenz86Qmnf99jo8Q3jf8zxq8pAg1XndMuTHmJwj3XfRLYIoCE7UmzT3fGt5nz6GVlpiOE938rB7Gk8zpIlBUS/UU7/rcrydRMW5CJjZyyJz1jO6Ojjcxq6sHEA==
x-ms-office365-filtering-correlation-id: afb5624f-1c81-4295-3399-08d49d29f1c0
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BY2PR0201MB1911; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(18271650672692);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123560025)(20161123558100)(20161123555025)(6072148); SRVR:BY2PR0201MB1911; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0201MB1911; 
x-forefront-prvs: 0310C78181
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39840400002)(39410400002)(39400400002)(39850400002)(66654002)(13464003)(189998001)(5660300001)(3660700001)(2900100001)(72206003)(66066001)(9686003)(81166006)(8676002)(2906002)(6506006)(6436002)(8936002)(74316002)(76176999)(54356999)(99286003)(55016002)(86362001)(50986999)(229853002)(53936002)(77096006)(478600001)(102836003)(3846002)(230783001)(33656002)(7696004)(122556002)(6246003)(7736002)(305945005)(38730400002)(25786009)(2950100002)(3280700002)(53546009)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0201MB1911; H:BY2PR0201MB1910.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: metaswitch.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2017 13:38:03.8225 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1911
Archived-At: 
Subject: Re: [Pce] Final IPR Check for draft-ietf-pce-lsp-setup-type
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 May 2017 13:44:19 -0000

SSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdC4NCg0K
QmVzdCByZWdhcmRzDQpKb24NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEp1
bGllbiBNZXVyaWMgW21haWx0bzpqdWxpZW4ubWV1cmljQG9yYW5nZS5jb21dIA0KU2VudDogMTYg
TWF5IDIwMTcgMDg6NTUNClRvOiBkcmFmdC1pZXRmLXBjZS1sc3Atc2V0dXAtdHlwZUBpZXRmLm9y
Zw0KQ2M6IHBjZUBpZXRmLm9yZw0KU3ViamVjdDogRmluYWwgSVBSIENoZWNrIGZvciBkcmFmdC1p
ZXRmLXBjZS1sc3Atc2V0dXAtdHlwZQ0KDQpEZWFyIGF1dGhvcnMsDQoNCiANCg0KQ291bGQgeW91
IHBsZWFzZSBzZW5kIGFuIGVtYWlsIHRvIHRoZSBQQ0UgbWFpbGluZyBsaXN0IHNheWluZyB3aGV0
aGVyIHlvdSBhcmUgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQtaWV0Zi1w
Y2UtbHNwLXNldHVwLXR5cGUgYW5kLCBpZiBzbywgaWYgaXQgaGFzIGJlZW4gZGlzY2xvc2VkIGlu
IGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcz8NCihTZWUgUkZDcyAzOTc5LCA0ODc5LCAz
NjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMuKSAgSWYgeW91IGFyZSBub3QgYXdhcmUgb2Yg
YW55IElQUiB0aGF0IGFwcGxpZXMsIHBsZWFzZSByZXBseSBzYXlpbmcgIkkgYW0gbm90IGF3YXJl
IG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQiLg0KDQogDQoNCkEgcmVwbHkg
aXMgcmVxdWlyZWQgZnJvbSBlYWNoIG9mIHlvdSBiZWZvcmUgd2UgY2FuIHByb2NlZWQuDQoNCiAN
Cg0KTWFueSB0aGFua3MsDQoNCg0KSnVsaWVuDQoNCg==


From nobody Wed May 17 07:46:34 2017
Return-Path: 
X-Original-To: pce@ietf.org
Delivered-To: pce@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C187212EB38; Wed, 17 May 2017 07:46:31 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: pce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149503239173.6626.10130454757655472955@ietfa.amsl.com>
Date: Wed, 17 May 2017 07:46:31 -0700
Archived-At: 
Subject: [Pce] I-D Action: draft-ietf-pce-stateful-pce-19.txt
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 May 2017 14:46:32 -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 of the IETF.

        Title           : PCEP Extensions for Stateful PCE
        Authors         : Edward Crabbe
                          Ina Minei
                          Jan Medved
                          Robert Varga
	Filename        : draft-ietf-pce-stateful-pce-19.txt
	Pages           : 54
	Date            : 2017-05-17

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 are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-19
https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-pce-19

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-pce-19


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed May 17 07:47:07 2017
Return-Path: 
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1032412EC59; Wed, 17 May 2017 07:47:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2M_8usNyZlUy; Wed, 17 May 2017 07:47:04 -0700 (PDT)
Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 125E712EBA6; Wed, 17 May 2017 07:41:06 -0700 (PDT)
Received: by mail-it0-x244.google.com with SMTP id 67so1718435itx.2; Wed, 17 May 2017 07:41:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=gdrd1trhLiNR39GfAl+Y66GU9NSCQC2w2h0NLApA+iQ=; b=f76MshfNwsU2wH9G2hGiTPWh/KC4GhRDZp3s+ZXcrg0mGoYekCB0rOxpPsxf7wXCUI jSfARKLUfScNHh0/fTXL0MNDYRo7FamIMfJEBYZCzgvYFusGUh9vcJm39yLDN8qvswPI j2l5Yj8z6bmMpu4DW/QtIgVdG/VV+1mDvDYaSBCgvpD8m5e0ki9ccDC8wPJfmssZ2WRg A0eftfSv2Afewv8J2YP+IoEymrfhpmFUqJZOxwaJh3vo3Hsyl7M7COGqCpyaAVU3+ZvJ ySkwGaZK0vatT5oMtXg4j+r8wB5Z871JfL5n1vySlGmYSRKYF2jrfOfh/udnzxsqw1ol UJUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=gdrd1trhLiNR39GfAl+Y66GU9NSCQC2w2h0NLApA+iQ=; b=Q0JpgqryIYxL/vVzgM0Wm4q/rqyMQ3AUTlQRGOLOeDq86CDzehx2izeGmkxCXhxiJK 9qK41BgUl5G86kaWb69h+YTzPM+IPAEeUSRLrs/07eoNVBCX3m79MeMbeCO3HPgFeUtK DVmUhP4Pvnan7VEb64TPpRn3LYMqZNUBBXVwgSClBTTnW2h4QEEZ19jEUvHEkJhnFT8n gaoDp4OJe074cXq1qTY4bC3c/YVyp7lN03XY2G3TbvjSNL/lQXjNSGWvCvK21wYMHXXg oZ/7CJ4U46TCz+XlRljmpJHW4cljYZ2B5538VXtVrZD0HAZbw32dZXxpGXOpL+/uU/fF Bsdg==
X-Gm-Message-State: AODbwcDoWmdd2/xTW0bJIZzVS7Xj1CiDoVprLydEVpe2O+xxvfsnGP8Z CzLbFEaQWY9E1A==
X-Received: by 10.36.80.194 with SMTP id m185mr16075412itb.24.1495032065468; Wed, 17 May 2017 07:41:05 -0700 (PDT)
Received: from [172.20.9.56] (marriott-chateau-champlain-montreal.sites.intello.com. [66.171.169.34]) by smtp.gmail.com with ESMTPSA id 9sm7408076itm.12.2017.05.17.07.41.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 May 2017 07:41:04 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/f.21.0.170409
Date: Wed, 17 May 2017 07:41:02 -0700
From: Jeff Tantsura 
To: Julien Meuric , "draft-ietf-pce-lsp-setup-type@ietf.org" 
CC: "pce@ietf.org" , Jonathan Hardwick 
Message-ID: 
Thread-Topic: Final IPR Check for draft-ietf-pce-lsp-setup-type
References:  
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
Archived-At: 
Subject: Re: [Pce] Final IPR Check for draft-ietf-pce-lsp-setup-type
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 May 2017 14:47:06 -0000

Julien,

I am not aware of any IPR that applies to this draft.
 
Cheers,
Jeff

    -----Original Message-----
    From: Julien Meuric [mailto:julien.meuric@orange.com] 
    Sent: 16 May 2017 08:55
    To: draft-ietf-pce-lsp-setup-type@ietf.org
    Cc: pce@ietf.org
    Subject: Final IPR Check for draft-ietf-pce-lsp-setup-type
    
    Dear authors,
    
     
    
    Could you please send an email to the PCE mailing list saying whether you are aware of any IPR that applies to draft-ietf-pce-lsp-setup-type and, if so, if it has been disclosed in compliance with IETF IPR rules?
    (See RFCs 3979, 4879, 3669 and 5378 for more details.)  If you are not aware of any IPR that applies, please reply saying "I am not aware of any IPR that applies to this draft".
    
     
    
    A reply is required from each of you before we can proceed.
    
     
    
    Many thanks,
    
    
    Julien
    
    



From nobody Wed May 17 08:26:50 2017
Return-Path: 
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 599CC12EA98; Wed, 17 May 2017 08:26:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.022
X-Spam-Level: 
X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=metaswitch.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDFdBBpUIxUy; Wed, 17 May 2017 08:26:39 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0116.outbound.protection.outlook.com [104.47.41.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF1DC129479; Wed, 17 May 2017 08:21:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=abDub9AOLfS+/5649qsyihtdwI/gJD8eihrJRSl+N4I=; b=URYMZTXCvJFLGi9pUotUZcIoR+lv/KVexKZKciEAhGbpiU4l4t6X9+q8V+MH0ksP5OKLSyyKQhXKZaghFuRF2rvQWGbAt37zRIr0YmOXgvrA9Nd0DXQHUK6pY4kx8sRWpksS3rVbYo3N2JHkWvSsT+sMvMD/hc+zWzeKOqm929c=
Received: from BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) by BY2PR0201MB1911.namprd02.prod.outlook.com (10.163.75.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.16; Wed, 17 May 2017 15:21:30 +0000
Received: from BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) by BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) with mapi id 15.01.1084.030; Wed, 17 May 2017 15:21:30 +0000
From: Jonathan Hardwick 
To: "pce@ietf.org" , "rtg-dir@ietf.org" 
Thread-Topic: [Pce] I-D Action: draft-ietf-pce-stateful-pce-19.txt
Thread-Index: AQHSzxxjO2V3bn0kd0uoNPFUux7BraH4o6Hg
Date: Wed, 17 May 2017 15:21:30 +0000
Message-ID: 
References: <149503239173.6626.10130454757655472955@ietfa.amsl.com>
In-Reply-To: <149503239173.6626.10130454757655472955@ietfa.amsl.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=metaswitch.com;
x-originating-ip: [86.137.0.176]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2PR0201MB1911; 7:VwJOgvYI18pO6Dr/JlRLTbx2/Miij64keGiFiNStevg5uw9YlOzXDy8Af2G5J3zIQMEqNI1GaonE6Oiauahxuz6iuxxY6ZdDOM8Wd2+Vp+1/wST8DDJ66WTMLR3PIo6iK+4HRhRt06EMHQxxJ6/JLEuVhqDQKN+wymezAKDa19bQJpQXpwIViOErpa+Uo6pfTO5IYEWN4Fd+AJp43bhGAFaeuSOBaP/L4ckUKGxYJoCDcs64sQmuVuWz1YeLyyNhb8F+y/qeMGOBL59QOEPdnoa1jzWMTlz8/3e9BFhGheSBkJD6ig26BLVLyurRUUEDq/FPseynTkgSDTlIzmEGkA==
x-ms-office365-filtering-correlation-id: 5cf882b5-4f28-4753-c91f-08d49d3864e6
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BY2PR0201MB1911; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(120809045254105)(131327999870524);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123560025)(20161123558100)(20161123555025)(6072148); SRVR:BY2PR0201MB1911; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0201MB1911; 
x-forefront-prvs: 0310C78181
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39400400002)(39840400002)(39850400002)(39450400003)(377424004)(13464003)(7736002)(122556002)(305945005)(38730400002)(33656002)(3846002)(102836003)(230783001)(7696004)(2501003)(2950100002)(3280700002)(25786009)(53546009)(966005)(3660700001)(5660300001)(2900100001)(189998001)(450100002)(66066001)(9686003)(72206003)(6306002)(99286003)(55016002)(86362001)(50986999)(54356999)(74316002)(76176999)(478600001)(53936002)(229853002)(77096006)(8676002)(2906002)(81166006)(6436002)(8936002)(6506006); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0201MB1911; H:BY2PR0201MB1910.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: metaswitch.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2017 15:21:30.1257 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1911
Archived-At: 
Subject: [Pce] FW:  I-D Action: draft-ietf-pce-stateful-pce-19.txt
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 May 2017 15:26:42 -0000

This new version of the stateful PCE draft resolves the comments received d=
uring IETF last call.
Thanks for your patience!

Best regards
Jon

-----Original Message-----
From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.o=
rg
Sent: 17 May 2017 15:47
To: i-d-announce@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-ietf-pce-stateful-pce-19.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 of the IETF.

        Title           : PCEP Extensions for Stateful PCE
        Authors         : Edward Crabbe
                          Ina Minei
                          Jan Medved
                          Robert Varga
	Filename        : draft-ietf-pce-stateful-pce-19.txt
	Pages           : 54
	Date            : 2017-05-17

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 are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-19
https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-pce-19

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-stateful-pce-19


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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


From nobody Wed May 17 12:05:35 2017
Return-Path: 
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755CD129AFF; Wed, 17 May 2017 12:05:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.699
X-Spam-Level: 
X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk
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 JhBsnlVf1Dkn; Wed, 17 May 2017 12:05:32 -0700 (PDT)
Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B8E512EC22; Wed, 17 May 2017 11:59:51 -0700 (PDT)
Received: from nitebug.localdomain (chello085216197060.chello.sk [85.216.197.60]) by mail.hq.sk (Postfix) with ESMTPSA id 834A3240205; Wed, 17 May 2017 20:59:49 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1495047589; bh=dAi/bzNo5XjcC74AQQl34IGUoxJyeYY6+4yguHDkq/g=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=Oc4oP8iy8qB1P9I2Q7rGOiHAJp54EzBx90FBE7j/L3jT7j5Bp27HbM7+ig7vcIIm0 JBdgBt/SKg+LSKNIPcMbf7vLPM2QE9ZE0PNGvrE9Wg6TnvqADTPxK9HOL2CdwA47s2 bf/S+NBiac/V61G8kERgwG9GYfMf8Ha3ETDfkLMo=
To: Julien Meuric , "draft-ietf-pce-lsp-setup-type@ietf.org" 
Cc: "pce@ietf.org" 
References: 
From: Robert Varga 
Message-ID: 
Date: Wed, 17 May 2017 20:59:30 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1cESPwmnXoFTmIc4C59GiQFU461FM04Dh"
Archived-At: 
Subject: Re: [Pce] Final IPR Check for draft-ietf-pce-lsp-setup-type
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 May 2017 19:05:33 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--1cESPwmnXoFTmIc4C59GiQFU461FM04Dh
Content-Type: multipart/mixed; boundary="B8IgiwpgbvGwTtFTan3MDb93KEJegbiu5";
 protected-headers="v1"
From: Robert Varga 
To: Julien Meuric ,
 "draft-ietf-pce-lsp-setup-type@ietf.org"
 
Cc: "pce@ietf.org" 
Message-ID: 
Subject: Re: [Pce] Final IPR Check for draft-ietf-pce-lsp-setup-type
References: 
In-Reply-To: 

--B8IgiwpgbvGwTtFTan3MDb93KEJegbiu5
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 16/05/17 09:55, Julien Meuric wrote:
> Dear authors,
>=20
> =20
>=20
> Could you please send an email to the PCE mailing list saying whether
> you are aware of any IPR that applies to draft-ietf-pce-lsp-setup-type
> and, if so, if it has been disclosed in compliance with IETF IPR rules?=

> (See RFCs 3979, 4879, 3669 and 5378 for more details.)  If you are not
> aware of any IPR that applies, please reply saying "I am not aware of
> any IPR that applies to this draft".

I am not aware of any IPR that applies to this draft.

Regards,
Robert


--B8IgiwpgbvGwTtFTan3MDb93KEJegbiu5--

--1cESPwmnXoFTmIc4C59GiQFU461FM04Dh
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIoBAEBCgASBQJZHJ2TCxxuaXRlQGhxLnNrAAoJECsDwSqgzwDTpisP/0e0brg6
xeKZnwAqL6tXw0jWesEFLIBNHeSLLPs/0yJWtolnpfCv4PouT1F7mN7mPDfZT4CV
4prAwqqfRhJyuDbEbCy5ZcvqPhcvQuGdtAfVlHkjJ007Ehx3hMzfGSstT8aS99nb
RAwH+fe6RkJo1GRAPRRzO+ZPgwdf7f0mjDeTsIV6tVbOf2dukZ/Pnd5iwQhqWSEE
D6ZSa43hbqnIZiCzPnnsJScZHd3CyLQkqwXEG7hcuQch+zI7zyE8yZCShzPuaezZ
EbsmrJuCcGs9RJKdXB+KRGPh7y6iImXuDiUc1HAcvUb9DPadLBciVFGmcgQb4HlS
E84m/FeS/is8LByhpMl+fgw6GpPne3+eyY8HlDZ88ntxzxP6o1C9vyZIjWTQ+wr3
WuOHK4REd5Oi41qeS8gWWg2kHQpQwyeky+SJ7vYp9o0tSuS8TtxL0t3Fhz4lHZFq
fgASIlatcgcdQ5tk9jZMD2QjxuvS0JIhiSM7Bb4HkRH0yuFgpbrZaQh4/wIKsE9X
wHpOHDhiCHmzECqpbhS2BP4fmvmFeaLwR2B8mEZlAxyxMH1dlblBTqSWR5laGcJ5
Ip0IZirTCZDpgGgRb9fbbGhBRPgtP85OslevNFuT9mPSeZZJzfeKX/RH1GLMf3u8
edWWWU30Go9IbC6kNLwLUOxtX9dFUgV1hWew
=Taxs
-----END PGP SIGNATURE-----

--1cESPwmnXoFTmIc4C59GiQFU461FM04Dh--


From nobody Thu May 18 09:34:30 2017
Return-Path: 
X-Original-To: pce@ietf.org
Delivered-To: pce@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 91ACB1273B1; Thu, 18 May 2017 08:49:52 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Liaison Statement Management Tool 
To: "Daniele Ceccarelli" , "Julien Meuric" , "Jonathan Hardwick" , "Fatai Zhang" , "George Swallow" , "Nicolai Leymann" , "Loa Andersson" , "Lou Berger" , "Vishnu Pavan Beeram" , "JP Vasseur" 
Cc: Alvaro Retana , Deborah Brungard , david.sinicrope@ericsson.com, Julien Meuric , Multiprotocol Label Switching Discussion List , David Sinicrope , Jonathan Hardwick , Fatai Zhang , George Swallow ,  Path Computation Element Discussion List , Vishnu Beeram , Alia Atlas , Daniele Ceccarelli , Traffic Engineering Architecture and Signaling Discussion List , Loa Andersson , Lou Berger , Common Control and Measurement Plane Discussion List , michael.fargano@centurylink.com, JP Vasseur , Nicolai Leymann 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149512259248.6703.11615243589366763423.idtracker@ietfa.amsl.com>
Date: Thu, 18 May 2017 08:49:52 -0700
Archived-At: 
X-Mailman-Approved-At: Thu, 18 May 2017 09:34:28 -0700
Subject: [Pce] New Liaison Statement, "Liaison to IETF on Flex Ethernet for IP/MPLS Networks"
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 May 2017 15:49:53 -0000

Title: Liaison to IETF on Flex Ethernet for IP/MPLS Networks
Submission Date: 2017-05-18
URL of the IETF Web page: https://datatracker.ietf.org/liaison/1523/

From: Michael Fargano 
To: Vishnu Pavan Beeram , Lou Berger ,Nicolai Leymann ,Loa Andersson ,George Swallow ,Jonathan Hardwick ,JP Vasseur ,Julien Meuric ,Daniele Ceccarelli ,Fatai Zhang 
Cc: Alvaro Retana ,Deborah Brungard ,Julien Meuric ,Multiprotocol Label Switching Discussion List ,David Sinicrope ,Jonathan Hardwick ,Fatai Zhang ,George Swallow ,Path Computation Element Discussion List ,JP Vasseur ,Vishnu Beeram ,Alia Atlas ,Daniele Ceccarelli ,Traffic Engineering Architecture and Signaling Discussion List ,Loa Andersson ,Lou Berger ,Common Control and Measurement Plane Discussion List ,Nicolai Leymann 
Response Contacts: michael.fargano@centurylink.com, david.sinicrope@ericsson.com
Technical Contacts: 
Purpose: For information

Body: At our 2017Q2 meeting in Taipei, the Broadband Forum initiated a new project entitled “Applicability of
Flex Ethernet in IP/MPLS Networks”. This project addresses the architecture, requirements and use cases in IP/MPLS networks to deploy Flex Ethernet (a.k.a. FlexE) as a new type of nodal interface.

OIF published “Flex Ethernet Implementation Agreement” (IA OIF-FLEXE-01.0) in March 2016. Our
project intends to use FlexE and its related aspects specified by that document including data plane
characteristics and provisioning requirements in IP/MPLS networks, including:

• Interconnection between routers on FlexE interfaces in IP/MPLS networks.
• End-to-end MPLS LSPs on FlexE-based channels.
• Control plane protocols (e.g. RSVP-TE, PCEP) including their extensions and their applicability
aspects for managing FlexE based MPLS LSP.
• Aspects of using FlexE interfaces and FlexE-based MPLS LSP as a network slicing instance.
• Co-existence of FlexE-based and other data link based MPLS LSPs and their operation.
• New services and applications that FlexE-capable IP/MPLS networks can enable.

We are sending this liaison to inform you about our intention.

We noticed that there are IETF drafts at CCAMP WG that propose to use GMPLS protocols with extensions to support FlexE based MPLS LSP; we are interested in learning the progress and status of the progress.

Sincerely,
Michael Fargano,
Broadband Forum Technical Committee Chair
Attachments:

    Liaison to IETF CCAMP on FlexE-Cheng-Huawei
    https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2017-05-18-broadband-forum-mpls-ccamp-pce-teas-liaison-to-ietf-on-flex-ethernet-for-ipmpls-networks-attachment-1.pdf


From nobody Sat May 20 08:12:40 2017
Return-Path: 
X-Original-To: pce@ietf.org
Delivered-To: pce@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D0D129B48; Sat, 20 May 2017 08:12:32 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: pce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149529315264.1159.2062359868211773791@ietfa.amsl.com>
Date: Sat, 20 May 2017 08:12:32 -0700
Archived-At: 
Subject: [Pce] I-D Action: draft-ietf-pce-pceps-13.txt
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 May 2017 15:12: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 of the IETF.

        Title           : Secure Transport for PCEP
        Authors         : Diego R. Lopez
                          Oscar Gonzalez de Dios
                          Qin Wu
                          Dhruv Dhody
	Filename        : draft-ietf-pce-pceps-13.txt
	Pages           : 19
	Date            : 2017-05-20

Abstract:
   The Path Computation Element Communication Protocol (PCEP) defines
   the mechanisms for the communication between a Path Computation
   Client (PCC) and a Path Computation Element (PCE), or among PCEs.
   This document describe the usage of Transport Layer Security (TLS) to
   enhance PCEP security, hence the PCEPS acronym proposed for it.  The
   additional security mechanisms are provided by the transport protocol
   supporting PCEP, and therefore they do not affect the flexibility and
   extensibility of PCEP.

   This document updates RFC 5440 regarding the PCEP initialization
   phase specification.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-pceps/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-pceps-13
https://datatracker.ietf.org/doc/html/draft-ietf-pce-pceps-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pceps-13


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Sat May 20 08:17:23 2017
Return-Path: 
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7D5126BF3; Sat, 20 May 2017 08:17:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVWE4WpZSjCb; Sat, 20 May 2017 08:17:18 -0700 (PDT)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8572B1277BB; Sat, 20 May 2017 08:17:18 -0700 (PDT)
Received: by mail-qk0-x236.google.com with SMTP id k74so80585054qke.1; Sat, 20 May 2017 08:17:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=dfxGH1LB26TMQACgqmSRqjj5M+J76JsheqUD6SHLePM=; b=QTKLBH+OeoS73/L4L6YJ/Eeis7YzX7BwR3aPPDVXwbUTRGOcv/N9ZM7YCzQq/1phep lagGp2Qeym/q8a6s97+bBWuECGW0fLpKPaIhoSrMxKyguMvzZq+HPtd0K/ZwZyZi8k0T fs7QTGj6mF6rlBdNlF7O7HuGv5Py++RkAT6fee0whxXyMd9J9m2wYgaOoCc8hkMZpavH isEHf1jQzgox24bETuInR5LyBryCCnaS0YXWtvjXsR4StBe/ErMW5+czcuRbZzueR/jO 72DWJVc1Zlv5O8T2hCC3qCfJwDPDsvhZKTe9jqEVIRjWo3FvG6GaGotsKWvLdW+Gst4Z puUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=dfxGH1LB26TMQACgqmSRqjj5M+J76JsheqUD6SHLePM=; b=DFzbkf4n5JSn4mX8PWeCQB6rrUze5cMcFddqUix3CAceMdqJTUEN6B9L/Cr7IhZ4y6 ni9ksevzU8JB+4dBBFJZdN8vKA7suDDkvPbTx2Ra4wcTk2LXGNVaS4cEHjh5FSIXAcQy DU3YvJ5CG+Nv9KuqXJDRT1Chol+O758L+zPWXXU9YiE17jpz89i9F0aNvvcoeV7qDrAO neLsqhE9W9s7znO2Kb61bwb60qUDL6szSXzDVS22kvlgKE/NEgM9iK4l/iq4o8shyVXj YolF3tr0tgNqRjR67x+rV7D1Tgq+4vgNOU5IfoBi3g9CplZSoc3jjuNZbkZGpDSrE3lT 3s1A==
X-Gm-Message-State: AODbwcCz4hU6BT/Jmi74W8xyI2ixZTHGXWDOSJNOpQhWXIbrrFdzsCLz zuKvvdW6XgrnAy969HeT2Abk//oOiQ==
X-Received: by 10.55.43.144 with SMTP id r16mr14774458qkr.213.1495293437730; Sat, 20 May 2017 08:17:17 -0700 (PDT)
MIME-Version: 1.0
Sender: dhruvdhody@gmail.com
X-Google-Sender-Delegation: dhruvdhody@gmail.com
Received: by 10.200.55.212 with HTTP; Sat, 20 May 2017 08:17:17 -0700 (PDT)
In-Reply-To: <23CE718903A838468A8B325B80962F9B8CAD810B@blreml501-mbb>
References: <1494509464.34491.973270680.4CBC76C2@webmail.messagingengine.com> <23CE718903A838468A8B325B80962F9B8CAD810B@blreml501-mbb>
From: Dhruv Dhody 
Date: Sat, 20 May 2017 20:47:17 +0530
X-Google-Sender-Auth: Rm3yI1sf2KI74msHUTuV1aqLRIQ
Message-ID: 
To: Dan Frost 
Cc: "rtg-ads@ietf.org" ,  "draft-ietf-pce-pceps.all@ietf.org" , "pce@ietf.org" , Dhruv Dhody 
Content-Type: multipart/alternative; boundary="001a1147164830e5f0054ff62278"
Archived-At: 
Subject: Re: [Pce] RtgDir review: draft-ietf-pce-pceps-12
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 May 2017 15:17:22 -0000

--001a1147164830e5f0054ff62278
Content-Type: text/plain; charset="UTF-8"

Hi All,

A new version handling the RTGDIR comments is posted.
https://datatracker.ietf.org/doc/draft-ietf-pce-pceps/

See diff at - https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pceps-13

Thanks Dan for the comments.

Regards,
Dhruv


On Thu, May 11, 2017 at 10:07 PM, Dhruv Dhody 
wrote:

> Hi Dan,
>
> Thanks for your review. Please see inline...
>
> > -----Original Message-----
> > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Dan Frost
> > Sent: 11 May 2017 19:01
> > To: rtg-ads@ietf.org
> > Cc: rtg-dir@ietf.org; draft-ietf-pce-pceps.all@ietf.org; pce@ietf.org
> > Subject: [Pce] RtgDir review: draft-ietf-pce-pceps-12
> >
> >
> > Hello,
> >
> > I have been selected as the Routing Directorate reviewer for this draft.
> > The Routing Directorate seeks to review all routing or routing-related
> drafts as
> > they pass through IETF last call and IESG review, and sometimes on
> special
> > request. The purpose of the review is to provide assistance to the
> Routing ADs.
> > For more information about the Routing Directorate, please see
> > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> >
> > Although these comments are primarily for the use of the Routing ADs, it
> would
> > be helpful if you could consider them along with any other IETF Last Call
> > comments that you receive, and strive to resolve them through discussion
> or by
> > updating the draft.
> >
> > Document: draft-ietf-pce-pceps-12
> > Reviewer: Dan Frost
> > Review Date: 2017-05-11
> > IETF LC End Date:
> > Intended Status: Standards Track
> >
> > Summary:
> >
> > I have significant concerns about this document and recommend that the
> > Routing ADs discuss these issues further with the authors.
> >
> > Comments:
> >
> > This document proposes to add a STARTTLS mechanism to the PCE protocol.
> > If this basic approach is accepted, then the document is in good shape.
> > It's clear, complete, and straightforward. The question is whether
> mandating
> > STARTTLS is actually a good idea.
> >
> [Dhruv] Yes, this has been discussed in the WG.
> The individual draft in fact asked for another port no, and during the WG
> adoption process, it was discussed in the WG as well as with security
> experts, and concluded that we should use STARTTLS.
> As far as I am aware, use of different port for secured version of a
> protocol has not been followed by IETF for some time now.
>
> > Major Issues:
> >
> > My main concern with this document is that it takes as given that
> STARTTLS is
> > the right way to secure PCEP with TLS. Perhaps this argument was already
> had at
> > some point and this draft is the result, but if so then at a bare
> minimum it needs
> > rationale explaining why STARTTLS was chosen over alternatives, and text
> that
> > addresses weaknesses and mitigations associated with STARTTLS
> processing, in
> > particular the possibility and relative ease of downgrade attacks.
> >
> [Dhruv] I see the benefit of adding text, something in line of -
>
> "As per the recommendation from [RFC7525], PCEP peers that support PCEPS,
> SHOULD prefer strict TLS configuration i.e. do not allow non-TLS PCEP
> sessions to be established."
>
> I will discuss further with my co-authors/chairs/AD, if we also need to
> spell out the full rationale here.
>
> > The obvious alternative would be to not use STARTTLS and simply allocate
> > another TCP port for PCEP-over-TLS. This avoids complicating the PCE
> protocol
> > and introducing the potential for downgrade attacks based on STARTTLS.
> PCE is
> > used to convey critical path-determination information in carrier
> networks,
> > among other things. That it's not fully authenticated and encrypted in
> all cases
> > already is an unfortunate legacy of a bygone era. Ideally operators
> should move
> > as quickly as possible to secure PCEP and aim to entirely remove the
> unsecure
> > form.
> > STARTTLS serves a weaker goal of "opportunistic" security, which, while
> it has its
> > uses, makes little sense for PCE compared to simply deprecating the
> unsecured
> > version.
> >
> > Minor Issues:
> >
> > * Section 3.3: "A RECOMMENDED value for StartTLSWait timer is 60
> seconds."
> > This seems like a very long time to wait for an initial reply on an
> already-
> > established TCP connection.
> >
> [Dhruv] We saw a benefit in keeping this same as the OpenWait time in the
> PCEP session establishment.
>
> > * Section 3.2, fifth paragraph (beginning with "A PCEP speaker
> > receiving..."):
> >
> > This paragraph states: "A PCEP speaker receiving any other message apart
> from
> > StartTLS, open, or PCErr MUST treat it as an unexpected message..."
> >
> > As written this is confusing and seems to imply that no other PCEP
> messages can
> > ever be sent. It looks like this is meant to be scoped to the context of
> the first
> > message sent/received on session initiation?
> >
> [Dhruv] Yes. I will add clarification that this is for the first message.
>
> > * Section 8.6
> >
> > The subsection titles of Section 8 have been taken from Section 8 of RFC
> 5440,
> > but Section 8.6 here is called "Impact on Network Operations"
> > while in RFC 5440 it's called "Impact on Network Operation". Funnily
> enough,
> > that final "s" makes a difference. Without it, the section refers to an
> impact on
> > the functioning of the network itself. With it, it would usually be
> taken to refer
> > to impact on human operations and management procedures.
> >
> > It looks correct to say that the mechanism of this draft should not
> significantly
> > impact the functioning of the network. On the other hand, it certainly
> does
> > impact operations and management procedures, as staff have to develop
> > policies around security requirements for PCEP within the organization,
> methods
> > for verifying whether device security parameters are configured
> correctly,
> > checking for unexpected downgrades to insecure sessions, etc. It would
> be an
> > improvement for the document to address the impact of PCEPS on
> operational
> > processes.
> >
> [Dhruv] Agreed. I will work on text in this section, along these lines.
>
> > Nits:
> [Dhruv] Ack for all.
>
> Thanks for your review.
>
> Regards,
> Dhruv
>
> >
> > Sec 3.1, first paragraph:
> > OLD
> >     The steps involved in the PCEPS establishment consists of following
> >     successive steps:
> > NEW
> >     The steps involved in establishing a PCEPS session are as follows:
> > END
> >
> > Sec 3.4, Step 3:
> > s/Any attempt of initiate a TLS/Any attempt to initiate a TLS/
> >
> >
> > Cheers,
> > -d
> >
> > _______________________________________________
> > Pce mailing list
> > Pce@ietf.org
> > https://www.ietf.org/mailman/listinfo/pce
>

--001a1147164830e5f0054ff62278
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi All,=C2=A0

A new ve=
rsion handling the RTGDIR comments is posted.=C2=A0
https://datatr=
acker.ietf.org/doc/draft-ietf-pce-pceps/
See diff at -=C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-pceps-=
13

Thanks Dan for the comments.=C2=A0

Regards,
Dhruv

On =
Thu, May 11, 2017 at 10:07 PM, Dhruv Dhody <dhruv.dhody@huawei.com> wrote:
Hi Dan,



Thanks for your review. Please see inline...




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

> From: Pce [mailto:pce-bounces@=
ietf.org] On Behalf Of Dan Frost

> Sent: 11 May 2017 19:01

> To: rtg-ads@ietf.org

> Cc: rtg-dir@ietf.org; draft-ietf-pce-pceps.all@ietf=
.org; pce@ietf.org

> Subject: [Pce] RtgDir review: draft-ietf-pce-pceps-12

>

>

> Hello,

>

> I have been selected as the Routing Directorate reviewer for this draf=
t.

> The Routing Directorate seeks to review all routing or routing-related=
 drafts as

> they pass through IETF last call and IESG review, and sometimes on spe=
cial

> request. The purpose of the review is to provide assistance to the Rou=
ting ADs.

> For more information about the Routing Directorate, please see

> http://trac.tools.ietf.org/area/rtg/=
trac/wiki/RtgDir

>

> Although these comments are primarily for the use of the Routing ADs, =
it would

> be helpful if you could consider them along with any other IETF Last C=
all

> comments that you receive, and strive to resolve them through discussi=
on or by

> updating the draft.

>

> Document: draft-ietf-pce-pceps-12

> Reviewer: Dan Frost

> Review Date: 2017-05-11

> IETF LC End Date:

> Intended Status: Standards Track

>

> Summary:

>

> I have significant concerns about this document and recommend that the=


> Routing ADs discuss these issues further with the authors.

>

> Comments:

>

> This document proposes to add a STARTTLS mechanism to the PCE protocol=
.

> If this basic approach is accepted, then the document is in good shape=
.

> It's clear, complete, and straightforward. The question is whether=
 mandating

> STARTTLS is actually a good idea.

>


[Dhruv] Yes, this has been discussed in the WG.

The individual draft in fact asked for another port no, and during the WG a=
doption process, it was discussed in the WG as well as with security expert=
s, and concluded that we should use STARTTLS.

As far as I am aware, use of different port for secured version of a protoc=
ol has not been followed by IETF for some time now.



> Major Issues:

>

> My main concern with this document is that it takes as given that STAR=
TTLS is

> the right way to secure PCEP with TLS. Perhaps this argument was alrea=
dy had at

> some point and this draft is the result, but if so then at a bare mini=
mum it needs

> rationale explaining why STARTTLS was chosen over alternatives, and te=
xt that

> addresses weaknesses and mitigations associated with STARTTLS processi=
ng, in

> particular the possibility and relative ease of downgrade attacks.

>

[Dhruv] I see the benefit of adding text, something in line of -



"As per the recommendation from [RFC7525], PCEP peers that support PCE=
PS, SHOULD prefer strict TLS configuration i.e. do not allow non-TLS PCEP s=
essions to be established."



I will discuss further with my co-authors/chairs/AD, if we also need to spe=
ll out the full rationale here.



> The obvious alternative would be to not use STARTTLS and simply alloca=
te

> another TCP port for PCEP-over-TLS. This avoids complicating the PCE p=
rotocol

> and introducing the potential for downgrade attacks based on STARTTLS.=
 PCE is

> used to convey critical path-determination information in carrier netw=
orks,

> among other things. That it's not fully authenticated and encrypte=
d in all cases

> already is an unfortunate legacy of a bygone era. Ideally operators sh=
ould move

> as quickly as possible to secure PCEP and aim to entirely remove the u=
nsecure

> form.

> STARTTLS serves a weaker goal of "opportunistic" security, w=
hich, while it has its

> uses, makes little sense for PCE compared to simply deprecating the un=
secured

> version.

>

> Minor Issues:

>

> * Section 3.3: "A RECOMMENDED value for StartTLSWait timer is 60 =
seconds."

> This seems like a very long time to wait for an initial reply on an al=
ready-

> established TCP connection.

>

[Dhruv] We saw a benefit in keeping this same as the OpenWait time i=
n the PCEP session establishment.



> * Section 3.2, fifth paragraph (beginning with "A PCEP speaker
> receiving..."):

>

> This paragraph states: "A PCEP speaker receiving any other messag=
e apart from

> StartTLS, open, or PCErr MUST treat it as an unexpected message...&quo=
t;

>

> As written this is confusing and seems to imply that no other PCEP mes=
sages can

> ever be sent. It looks like this is meant to be scoped to the context =
of the first

> message sent/received on session initiation?

>

[Dhruv] Yes. I will add clarification that this is for the first mes=
sage.



> * Section 8.6

>

> The subsection titles of Section 8 have been taken from Section 8 of R=
FC 5440,

> but Section 8.6 here is called "Impact on Network Operations"=
;

> while in RFC 5440 it's called "Impact on Network Operation&qu=
ot;. Funnily enough,

> that final "s" makes a difference. Without it, the section r=
efers to an impact on

> the functioning of the network itself. With it, it would usually be ta=
ken to refer

> to impact on human operations and management procedures.

>

> It looks correct to say that the mechanism of this draft should not si=
gnificantly

> impact the functioning of the network. On the other hand, it certainly=
 does

> impact operations and management procedures, as staff have to develop<=
br>
> policies around security requirements for PCEP within the organization=
, methods

> for verifying whether device security parameters are configured correc=
tly,

> checking for unexpected downgrades to insecure sessions, etc. It would=
 be an

> improvement for the document to address the impact of PCEPS on operati=
onal

> processes.

>

[Dhruv] Agreed. I will work on text in this section, along these lin=
es.



> Nits:

[Dhruv] Ack for all.



Thanks for your review.



Regards,

Dhruv



>

> Sec 3.1, first paragraph:

> OLD

>=C2=A0 =C2=A0 =C2=A0The steps involved in the PCEPS establishment consi=
sts of following

>=C2=A0 =C2=A0 =C2=A0successive steps:

> NEW

>=C2=A0 =C2=A0 =C2=A0The steps involved in establishing a PCEPS session =
are as follows:

> END

>

> Sec 3.4, Step 3:

> s/Any attempt of initiate a TLS/Any attempt to initiate a TLS/

>

>

> Cheers,

> -d

>

> _______________________________________________

> Pce mailing list

> Pce@ietf.org

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





--001a1147164830e5f0054ff62278--


From nobody Mon May 22 08:15:32 2017
Return-Path: 
X-Original-To: pce@ietf.org
Delivered-To: pce@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 957611200C5; Mon, 22 May 2017 08:15:30 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: pce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149546613054.20744.2325640517270321107@ietfa.amsl.com>
Date: Mon, 22 May 2017 08:15:30 -0700
Archived-At: 
Subject: [Pce] I-D Action: draft-ietf-pce-pceps-14.txt
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 15:15:30 -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 of the IETF.

        Title           : Secure Transport for PCEP
        Authors         : Diego R. Lopez
                          Oscar Gonzalez de Dios
                          Qin Wu
                          Dhruv Dhody
	Filename        : draft-ietf-pce-pceps-14.txt
	Pages           : 19
	Date            : 2017-05-22

Abstract:
   The Path Computation Element Communication Protocol (PCEP) defines
   the mechanisms for the communication between a Path Computation
   Client (PCC) and a Path Computation Element (PCE), or among PCEs.
   This document describe the usage of Transport Layer Security (TLS) to
   enhance PCEP security, hence the PCEPS acronym proposed for it.  The
   additional security mechanisms are provided by the transport protocol
   supporting PCEP, and therefore they do not affect the flexibility and
   extensibility of PCEP.

   This document updates RFC 5440 regarding the PCEP initialization
   phase specification.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-pceps/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-pceps-14
https://datatracker.ietf.org/doc/html/draft-ietf-pce-pceps-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pceps-14


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Thu May 25 05:02:53 2017
Return-Path: 
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6251294FD for ; Thu, 25 May 2017 05:02:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Level: 
X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3pz-wXL4IsK for ; Thu, 25 May 2017 05:02:48 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C61411294F0 for ; Thu, 25 May 2017 05:02:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3372; q=dns/txt; s=iport; t=1495713767; x=1496923367; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=sgf28a/XEv7sLWJW4sll6vfMMJdaRTYXNUUMtpL5PsY=; b=IU3GMytIpfA60m1TRsz8UZJDtUomS5nNdqG9xCfW4TkpDb0uvBb3b3So 1pIsCzNMv5dQku+hMBZDYVhnnvPpXE8y57qlvmu+IBOPMLocLtNwaDIXT KnSnz69TF26cTJW1AJAU/4bBS3Tgmitt8fSNbDJ8ybfruw+/PzGiALZtt A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQAExyZZ/5BdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VigQwHg2iKGJE8lhmCDy6FdhyCYT8YAQIBAQEBAQEBax0LhUI?= =?us-ascii?q?RRRIBIgImAgQwFRIEDgWKJw6vZIImi0UBAQEBAQEBAQEBAQEBAQEBAQEBAQEdg?= =?us-ascii?q?QuFVIFeKwuGCoFZgnsvgjEFkCmNegGBWoVFjAiCBlWEZ4o1lE0BHziBCnMVHDw?= =?us-ascii?q?Bhmd2AYg0gQ0BAQE?=
X-IronPort-AV: E=Sophos;i="5.38,391,1491264000"; d="scan'208";a="31756666"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 May 2017 12:02:46 +0000
Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v4PC2kpV018790 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 25 May 2017 12:02:46 GMT
Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 25 May 2017 07:02:46 -0500
Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1210.000; Thu, 25 May 2017 07:02:46 -0500
From: "Rakesh Gandhi (rgandhi)" 
To: "pce@ietf.org" 
CC: Colby Barth , Bin Wen 
Thread-Topic: Updated draft-barth-pce-association-bidir
Thread-Index: AQHS1U7Sh/zJBpdof0yfnu3/hJUluw==
Date: Thu, 25 May 2017 12:02:46 +0000
Message-ID: <1160EFDF-5AF3-4015-B640-887CFB9E0CDC@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.1d.0.161209
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.248.123]
Content-Type: text/plain; charset="utf-8"
Content-ID: <580A86A4B43DF6479AEABC5B43C2C001@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: [Pce] Updated draft-barth-pce-association-bidir
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 May 2017 12:02:49 -0000

SEkgV0csDQoNClRoaXMgZHJhZnQgd2FzIHByZXNlbnRlZCBhdCB0aGUgbGFzdCBJRVRGIG1lZXRp
bmcgKGluIENoaWNhZ28pLiBUaGUgZHJhZnQgaGFzIGJlZW4gdXBkYXRlZCBhcyBmb2xsb3dpbmc6
DQoNCkFkZGVkIHRleHQgaW4gU2VjdGlvbnMgMSwgMy4xIGFuZCAzLjIgZm9yIEZhc3QgcmVyb3V0
ZSBwcm9jZWR1cmUgKHVzaW5nIGlldGYtdGVhcy1hc3NvYy1jb3JvdXRlZC1iaWRpci1mcnIpDQpB
ZGRlZCBwYXRoIHJlcXVlc3RzIHdpdGggU3RhdGVsZXNzIFBDRQ0KVmFyaW91cyBlZGl0b3JpYWwg
Y2hhbmdlcw0KDQpXZSB3ZWxjb21lIHlvdXIgcmV2aWV3IGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9u
cy4NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmFy
dGgtcGNlLWFzc29jaWF0aW9uLWJpZGlyLTAyDQoNClRoYW5rcywNClJha2VzaCAoZm9yIGF1dGhv
cnMpDQoNCg0KT24gMjAxNy0wNS0yMSwgMTA6NTcgUE0sICJpbnRlcm5ldC1kcmFmdHNAaWV0Zi5v
cmciIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KDQogICAgDQogICAgQSBuZXcg
dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWJhcnRoLXBjZS1hc3NvY2lhdGlvbi1iaWRpci0wMi50eHQN
CiAgICBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFJha2VzaCBHYW5kaGkgYW5k
IHBvc3RlZCB0byB0aGUNCiAgICBJRVRGIHJlcG9zaXRvcnkuDQogICAgDQogICAgTmFtZToJCWRy
YWZ0LWJhcnRoLXBjZS1hc3NvY2lhdGlvbi1iaWRpcg0KICAgIFJldmlzaW9uOgkwMg0KICAgIFRp
dGxlOgkJUENFUCBFeHRlbnNpb25zIGZvciBBc3NvY2lhdGVkIEJpZGlyZWN0aW9uYWwgTGFiZWwg
U3dpdGNoZWQgUGF0aHMgKExTUHMpDQogICAgRG9jdW1lbnQgZGF0ZToJMjAxNy0wNS0yMQ0KICAg
IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQogICAgUGFnZXM6CQkxNA0KICAgIFVSTDog
ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYmFy
dGgtcGNlLWFzc29jaWF0aW9uLWJpZGlyLTAyLnR4dA0KICAgIFN0YXR1czogICAgICAgICBodHRw
czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1iYXJ0aC1wY2UtYXNzb2NpYXRpb24t
YmlkaXIvDQogICAgSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k
cmFmdC1iYXJ0aC1wY2UtYXNzb2NpYXRpb24tYmlkaXItMDINCiAgICBIdG1saXplZDogICAgICAg
aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1iYXJ0aC1wY2UtYXNz
b2NpYXRpb24tYmlkaXItMDINCiAgICBEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvcmZjZGlmZj91cmwyPWRyYWZ0LWJhcnRoLXBjZS1hc3NvY2lhdGlvbi1iaWRpci0wMg0KICAg
IA0KICAgIEFic3RyYWN0Og0KICAgICAgIFRoZSBQYXRoIENvbXB1dGF0aW9uIEVsZW1lbnQgQ29t
bXVuaWNhdGlvbiBQcm90b2NvbCAoUENFUCkgcHJvdmlkZXMNCiAgICAgICBtZWNoYW5pc21zIGZv
ciBQYXRoIENvbXB1dGF0aW9uIEVsZW1lbnRzIChQQ0VzKSB0byBwZXJmb3JtIHBhdGgNCiAgICAg
ICBjb21wdXRhdGlvbnMgaW4gcmVzcG9uc2UgdG8gUGF0aCBDb21wdXRhdGlvbiBDbGllbnRzIChQ
Q0NzKSByZXF1ZXN0cy4NCiAgICAgICAgVGhlIFN0YXRlZnVsIFBDRSBleHRlbnNpb25zIGFsbG93
IHN0YXRlZnVsIGNvbnRyb2wgb2YgTXVsdGlwcm90b2NvbA0KICAgICAgIExhYmVsIFN3aXRjaGlu
ZyAoTVBMUykgVHJhZmZpYyBFbmdpbmVlcmluZyAoVEUpIExhYmVsIFN3aXRjaGVkIFBhdGhzDQog
ICAgICAgKExTUHMpIHVzaW5nIFBDRVAuDQogICAgDQogICAgICAgVGhpcyBkb2N1bWVudCBkZWZp
bmVzIFBDRVAgZXh0ZW5zaW9ucyBmb3IgYmluZGluZyB0d28gcmV2ZXJzZQ0KICAgICAgIHVuaWRp
cmVjdGlvbmFsIE1QTFMgVEUgTFNQcyBpbnRvIGFuIEFzc29jaWF0ZWQgQmlkaXJlY3Rpb25hbCBM
YWJlbA0KICAgICAgIFN3aXRjaGVkIFBhdGggKExTUCkgd2hlbiB1c2luZyBhIFN0YXRlZnVsIFBD
RSBmb3IgYm90aCBQQ0UtSW5pdGlhdGVkDQogICAgICAgYW5kIFBDQy1Jbml0aWF0ZWQgTFNQcyBh
cyB3ZWxsIGFzIHdoZW4gdXNpbmcgYSBTdGF0ZWxlc3MgUENFLg0KICAgIA0KICAgIA0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICANCiAgICANCiAgICANCiAgICBQbGVhc2Ugbm90ZSB0aGF0
IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNz
aW9uDQogICAgdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs
ZSBhdCB0b29scy5pZXRmLm9yZy4NCiAgICANCiAgICBUaGUgSUVURiBTZWNyZXRhcmlhdA0KICAg
IA0KICAgIA0KDQo=