From nobody Mon Nov 6 00:00: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 E476213FB1B for ; Mon, 6 Nov 2017 00:00:18 -0800 (PST) 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 zbryjOMlrWM4 for ; Mon, 6 Nov 2017 00:00:12 -0800 (PST) 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 281C713FB10 for ; Mon, 6 Nov 2017 00:00:12 -0800 (PST) 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 DSA93081; Mon, 06 Nov 2017 08:00:10 +0000 (GMT) Received: from DGGEML404-HUB.china.huawei.com (10.3.17.39) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 6 Nov 2017 08:00:09 +0000 Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.204]) by DGGEML404-HUB.china.huawei.com ([fe80::b177:a243:7a69:5ab8%31]) with mapi id 14.03.0361.001; Mon, 6 Nov 2017 16:00:00 +0800 From: Zhenghaomian To: "pce@ietf.org" Thread-Topic: New Version Notification for draft-zhang-pce-resource-sharing-05.txt Thread-Index: AdNW1IKWVD4FgfG6TXiW2DKUSDnAMA== Date: Mon, 6 Nov 2017 08:00:00 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.57.78.212] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.5A00168A.00C9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.204, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2ad94048b4c76d888ede22a83b545c3d Archived-At: Subject: [Pce] Fw: New Version Notification for draft-zhang-pce-resource-sharing-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: Mon, 06 Nov 2017 08:00:19 -0000 SGksIFBDRSBXRywgDQoNCldlIGhhdmUgcmVjZW50bHkgdXBkYXRlZCB0aGlzIHdvcmsgYW5kIHdv dWxkIGxpa2UgdG8gaW52aXRlIHlvdXIgcmV2aWV3IGFuZCBjb21tZW50cy4gDQoNClRoaXMgd29y ayBoYXMgYmVlbiBzaWxlbnQgZm9yIGFib3V0IDIgeWVhcnMsIHdpdGggdHJ5aW5nIHRvIGNsYXJp ZnkgdGhlIHJlbGF0aW9uc2hpcCB3aXRoIGFzc29jaWF0aW9uIGdyb3VwIHdvcmtzLiBBZnRlciB0 aGUgcmVsYXRpb25zaGlwIGNsZWFybHkgY2xhcmlmaWVkLCB0aGlzIHdvcmsgaXMgcmVzdGFydGVk IGFzIGEgY29tcGxlbWVudGFyeSBwYXJ0IG9mIGRyYWZ0LWlldGYtcGNlLWFzc29jaWF0aW9uLWdy b3VwLiBUaGUgZHJhZnQtaWV0Zi1wY2UtYXNzb2NpYXRpb24tZGl2ZXJzaXR5IGlzIHVzZWQgdG8g ZGVzY3JpYmUgdGhlIHNjZW5hcmlvIGZvciBkaXNqb2ludG5lc3MsIGFuZCB0aGlzIGRyYWZ0IGNh biBiZSB1c2VkIHRvIGRlc2NyaWJlIGFub3RoZXIgc2NlbmFyaW8sIHJlc291cmNlIHNoYXJpbmcu IFRoZSBjb3JyZXNwb25kaW5nIG9iamVjdCBhbmQgVExWIGRlZmluaXRpb24gaGFzIGFsc28gYmVl biB1cGRhdGVkIHRvIGJlIGNvbnNpc3RlbnQgd2l0aCB0aGUgYXNzb2NpYXRpb24gZ3JvdXAgZHJh ZnQuIA0KDQpQbGVhc2UgZmVlbCBmcmVlIHRvIHJhaXNlIGFueSBjb21tZW50cywgdGhhbmsgeW91 IHZlcnkgbXVjaC4gDQoNCkJlc3Qgd2lzaGVzLA0KSGFvbWlhbg0KDQotLS0tLemCruS7tuWOn+S7 ti0tLS0tDQrlj5Hku7bkuro6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQrlj5HpgIHml7bpl7Q6IDIwMTflubQxMOaciDMw5pelIDE2 OjAwDQrmlLbku7bkuro6IE9zY2FyIGRlIERpb3MgPG9nb25kaW9AdGlkLmVzPjsgWmhlbmdoYW9t aWFuIDx6aGVuZ2hhb21pYW5AaHVhd2VpLmNvbT47IFZpY3RvciBMb3BleiA8dmxvcGV6QHRpZC5l cz47IFpoYW5neGlhbiAoWGlhbikgPHpoYW5nLnhpYW5AaHVhd2VpLmNvbT47IE9zY2FyIEdvbnph bGV6IGRlIERpb3MgPG9nb25kaW9AdGlkLmVzPjsgWmhlbmdoYW9taWFuIDx6aGVuZ2hhb21pYW5A aHVhd2VpLmNvbT4NCuS4u+mimDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC16 aGFuZy1wY2UtcmVzb3VyY2Utc2hhcmluZy0wNS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEkt RCwgZHJhZnQtemhhbmctcGNlLXJlc291cmNlLXNoYXJpbmctMDUudHh0DQpoYXMgYmVlbiBzdWNj ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEhhb21pYW4gWmhlbmcgYW5kIHBvc3RlZCB0byB0aGUgSUVU RiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtemhhbmctcGNlLXJlc291cmNlLXNoYXJpbmcN ClJldmlzaW9uOgkwNQ0KVGl0bGU6CQlFeHRlbnNpb25zIHRvIFBhdGggQ29tcHV0YXRpb24gRWxl bWVudCBQcm90b2NvbCAoUENFUCkgdG8gU3VwcG9ydCBSZXNvdXJjZSBTaGFyaW5nLWJhc2VkIFBh dGggQ29tcHV0YXRpb24NCkRvY3VtZW50IGRhdGU6CTIwMTctMTAtMzANCkdyb3VwOgkJSW5kaXZp ZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTEzDQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXpoYW5nLXBjZS1yZXNvdXJjZS1zaGFyaW5n LTA1LnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LXpoYW5nLXBjZS1yZXNvdXJjZS1zaGFyaW5nLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1wY2UtcmVzb3VyY2Utc2hhcmluZy0w NQ0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwv ZHJhZnQtemhhbmctcGNlLXJlc291cmNlLXNoYXJpbmctMDUNCkRpZmY6ICAgICAgICAgICBodHRw czovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtemhhbmctcGNlLXJlc291cmNlLXNo YXJpbmctMDUNCg0KQWJzdHJhY3Q6DQogICBSZXNvdXJjZSBzaGFyaW5nIGluIGEgbmV0d29yayBt ZWFucyB0d28gb3IgbW9yZSBMYWJlbCBTd2l0Y2hlZCBQYXRocw0KICAgKExTUHMpIHVzZSBjb21t b24gcGllY2Uocykgb2YgcmVzb3VyY2UgYWxvbmcgdGhlaXIgcGF0aHMuIFRoaXMgY2FuDQogICBo ZWxwIHNhdmUgbmV0d29yayByZXNvdXJjZSBhbmQgaXMgdXNlZnVsIGluIHNjZW5hcmlvcyBzdWNo IGFzIExTUA0KICAgcmVjb3Zlcnkgb3Igd2hlbiB0d28gTFNQcyBkbyBub3QgbmVlZCB0byBiZSBh Y3RpdmUgYXQgdGhlIHNhbWUgdGltZS4NCiAgIEEgUGF0aCBDb21wdXRhdGlvbiBFbGVtZW50IChQ Q0UpIGlzIHJlc3BvbnNpYmxlIGZvciBwYXRoIGNvbXB1dGF0aW9uDQogICB3aXRoIHN1Y2ggcmVx dWlyZW1lbnQuIEdpdmVuIHRoaXMgZmVhdHVyZSBhbmQgaXRzIGFjY2VzcyB0byB0aGUNCiAgIG5l dHdvcmsgcmVzb3VyY2UgaW5mb3JtYXRpb24gYW5kIHBvc3NpYmx5IGFjdGl2ZSBMU1BzIGluZm9y bWF0aW9uLA0KICAgaXQgY2FuIGJlIHVzZWQgdG8gc3VwcG9ydCByZXNvdXJjZS1zaGFyaW5nLWJh c2VkIHBhdGggY29tcHV0YXRpb24NCiAgIHdpdGggYmV0dGVyIGVmZmljaWVuY3kuDQoNCiAgIFRo aXMgZG9jdW1lbnQgZXh0ZW5kcyB0aGUgUGF0aCBDb21wdXRhdGlvbiBFbGVtZW50IFByb3RvY29s IChQQ0VQKQ0KICAgaW4gb3JkZXIgdG8gc3VwcG9ydCByZXNvdXJjZSBzaGFyaW5nLWJhc2VkIHBh dGggY29tcHV0YXRpb24uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ug bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv ZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFp bGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Mon Nov 6 03:21: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 DAC4213FB4C; Mon, 6 Nov 2017 03:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 zVkSWLCT6UeS; Mon, 6 Nov 2017 03:21:19 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 1003A13FB45; Mon, 6 Nov 2017 03:21:19 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id p186so15236383ioe.12; Mon, 06 Nov 2017 03:21:19 -0800 (PST) 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=hBt+tQJkRz3t6vryx/IzoFsXMgSbWsPoBdhuSdSRwrc=; b=iDVXTeWdfTV4cv3eYV2Cbs4+1J2xRlg+71pj2enEDnDz78iSE751HEi8ABzQ78SFZo kynti5UiFIrxWE+aiu3g0SlrgpeqX+6DQbYQzsU5BqNrnnGQMm/AMUSsnPZFLU1wtTsH iTM3f28XGIMNMTKt0agtRiyAu03ZZbMKWyRa413s3gFobt1Dz6S9kM6urtUZCLzWOs/d Wk8P0ceo8sflCHR8eUJZCXynlltpDRxx9wfGdQ6bte9WEOT/L6B+KVzgCdP901K7jAhA 41S9SwaMUPv8AupGK9qBgnq7pvD8QRVgKO2S25ISj3yzshvce8rW6wth/h1cjnaO8P7v 5kew== 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=hBt+tQJkRz3t6vryx/IzoFsXMgSbWsPoBdhuSdSRwrc=; b=qpzry7tFjezNKy7fp8HR5/QJrF1P0lUTzk0Ff8uwcJROTrR/9D7mfH3GMtoKK/B7WV bxLy1eWDRQNSSyNIyiXGRc4Ef0q0nhRzDlPQug0U7WIq2e1sL+0Q7VlYmU52dL+sZK2+ 22un01v3DbVjfYx3/ri8d9JMp7b9BN0hOF+d0O4joGa1Ql3win8Jl+0Rnrdb8Lk/HE54 05GEtcyrGQeWOcy9DKEqFVQykzfSZ9Zt99EpoUIjCmWC5+CwbJGnew6Lx1sXrFtUphY6 xU5YsTD/V5xCFsNCQDz8eEaVF1w689q6dwaysEELcZ42BO8WYW2sTV/B+EKA2tBCC0/j oNhw== X-Gm-Message-State: AMCzsaXh/6Ev93FzZ7d+5wHRnW0fEGR8r8/N2B0k7fo7Km1YIN3WowgH Z4NZ5JsZLimlRtWQGCXvOzoAf30ZNR/buHdix2A= X-Google-Smtp-Source: ABhQp+Txf+sF1gxZsDu5XHkPyF6J0ljvjmGyRCM/zKrkA5kJIzFVxaalEkWLKHjg2B7EXasVdwWxbH9DSK4ILM2z+TQ= X-Received: by 10.107.162.67 with SMTP id l64mr16385489ioe.278.1509967278460; Mon, 06 Nov 2017 03:21:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.62.85 with HTTP; Mon, 6 Nov 2017 03:21:18 -0800 (PST) In-Reply-To: References: From: Satish K Date: Mon, 6 Nov 2017 16:51:18 +0530 Message-ID: To: Jonathan Hardwick Cc: "pce@ietf.org" , "draft-ietf-pce-pcep-exp-codepoints@ietf.org" , "pce-chairs@ietf.org" Content-Type: multipart/alternative; boundary="001a113e964241556c055d4ea759" Archived-At: Subject: Re: [Pce] Working group last call (including final IPR check) for draft-ietf-pce-pcep-exp-codepoints 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, 06 Nov 2017 11:21:21 -0000 --001a113e964241556c055d4ea759 Content-Type: text/plain; charset="UTF-8" Hi Chairs, I have reviewed the document and also as a developer of PCE in ONOS controller some of these code points we had used for our tests. I feel it's ready for publication. Regards, Satish. On Fri, Oct 27, 2017 at 12:38 PM, Jonathan Hardwick < Jonathan.Hardwick@metaswitch.com> wrote: > Dear PCE working group > > > > This email starts a working group last call for draft-ietf-pce-pcep-exp- > codepoints-02. > > https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-exp-codepoints/ > > > > Please read the document and reply to the PCE mailing list whether you > believe this document is ready to be published, or not (including any > comments on why not). The last call will end on *Friday 10 November*. > > > > We are also polling for knowledge of any undisclosed IPR that applies to > draft-ietf-pce-pcep-exp-codepoints-02, to ensure that IPR has been > disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and > 5378 for more details) prior to moving forward. If you are a document > author, please respond to this email and indicate whether or not you are > aware of any relevant undisclosed IPR. The document won't progress without > answers from all the authors. No IPR disclosures currently exist against > this document. > > > > Best regards > > Jon and Julien > > > > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > --001a113e964241556c055d4ea759 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Chairs,

I have reviewed the docum= ent and also as a developer of PCE in ONOS controller some of these code po= ints we had used for our tests.

I feel it'= s ready for publication.

Regards,
Satish.

On Fri, Oct 2= 7, 2017 at 12:38 PM, Jonathan Hardwick <Jonathan.Hardwick@m= etaswitch.com> wrote:

Dear PCE working group

=C2=A0

This email starts a working group last call for draf= t-ietf-pce-pcep-exp-codepoints-02.

https://datatracker.ietf.org= /doc/draft-ietf-pce-pcep-exp-codepoints/

=C2=A0

Please read the document and reply to the PCE mailin= g list whether you believe this document is ready to be published, or not (= including any comments on why not).=C2=A0 The last call will end on Friday 10 November.

=C2=A0

We are also polling for knowledge of any undisclosed= IPR that applies to draft-ietf-pce-pcep-exp-codepoints-02, to ensure = that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 397= 9, 4879, 3669 and 5378 for more details) prior to moving forward.=C2=A0 If you are a document author, please respon= d to this email and indicate whether or not you are aware of any relevant u= ndisclosed IPR. The document won't progress without answers from all th= e authors.=C2=A0 No IPR disclosures currently exist against this document.

=C2=A0

Best regards

Jon and Julien

=C2=A0

=C2=A0


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


--001a113e964241556c055d4ea759-- From nobody Tue Nov 7 00:09:03 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 7D7E013FC81 for ; Mon, 6 Nov 2017 13:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYKDQNx8qaNU for ; Mon, 6 Nov 2017 13:46:43 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C22613FC7E for ; Mon, 6 Nov 2017 13:46:43 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id CEE79B80D7C; Mon, 6 Nov 2017 13:46:29 -0800 (PST) To: diego.r.lopez@telefonica.com, oscar.gonzalezdedios@telefonica.com, sunseawq@huawei.com, dhruv.ietf@gmail.com, akatlas@gmail.com, db3546@att.com, aretana.ietf@gmail.com, jonathan.hardwick@metaswitch.com, julien.meuric@orange.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: housley@vigilsec.com, pce@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20171106214629.CEE79B80D7C@rfc-editor.org> Date: Mon, 6 Nov 2017 13:46:29 -0800 (PST) Archived-At: X-Mailman-Approved-At: Tue, 07 Nov 2017 00:09:01 -0800 Subject: [Pce] [Editorial Errata Reported] RFC8253 (5180) 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, 06 Nov 2017 21:46:44 -0000 The following errata report has been submitted for RFC8253, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5180 -------------------------------------- Type: Editorial Reported by: Russ Housley Section: 3.4 Original Text ------------- * PCEPS implementations MUST, at a minimum, support negotiation of the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 [RFC6460] and SHOULD support TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as well. ... Corrected Text -------------- * PCEPS implementations MUST, at a minimum, support negotiation of the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 [RFC5289] and SHOULD support TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as well. ... Notes ----- RFC 6460 makes reference to the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ciphersuites, but it does not define them. These ciphersuites are defined in RFC 5289. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8253 (draft-ietf-pce-pceps-18) -------------------------------------- Title : PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP) Publication Date : October 2017 Author(s) : D. Lopez, O. Gonzalez de Dios, Q. Wu, D. Dhody Category : PROPOSED STANDARD Source : Path Computation Element Area : Routing Stream : IETF Verifying Party : IESG From nobody Wed Nov 8 07:13: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 39986127698 for ; Wed, 8 Nov 2017 07:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 fPAZqa9SgYRw for ; Wed, 8 Nov 2017 07:13:26 -0800 (PST) Received: from r-mail2.rd.orange.com (r-mail2.rd.orange.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8472B127601 for ; Wed, 8 Nov 2017 07:13:26 -0800 (PST) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 25CDC5D8A62 for ; Wed, 8 Nov 2017 16:13:25 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail2.rd.orange.com (Postfix) with ESMTP id 0188B5D8A60 for ; Wed, 8 Nov 2017 16:13:25 +0100 (CET) Received: from [10.193.71.63] (10.193.71.63) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.361.1; Wed, 8 Nov 2017 16:13:24 +0100 To: References: <13830_1508506157_59E9FA2D_13830_345_1_8096182e-2d11-017c-bf47-1a20d4d152cb@orange.com> Reply-To: "pce-chairs@ietf.org" From: Julien Meuric Organization: Orange Message-ID: <1f7e5d6b-9118-712b-f065-a10f9b42ac56@orange.com> Date: Wed, 8 Nov 2017 16:13:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <13830_1508506157_59E9FA2D_13830_345_1_8096182e-2d11-017c-bf47-1a20d4d152cb@orange.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Pce] Building the PCE Agenda for IETF 100 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, 08 Nov 2017 15:13:28 -0000 Dear WG, You probably all had a look at the PCE agenda: https://datatracker.ietf.org/meeting/100/materials/agenda-100-pce/ (thanks Dhruv). If you have a slot, you are expected to send your slides to the chairs and secretary by Saturday 11. Please take into account the duration actually allocated to your slot, including questions. Thanks, Jon & Julien Oct. 20, 2017 - : > Hi all, > > The PCE WG session in Singapore is tentatively scheduled on Monday at > 3:50pm (facing I2RS). > If you need meeting time to progress some work, please send a request to > the chairs and secretary by Sunday October 29, including: > - the associated I-D(s), > - the expected presenter, > - the requested duration, > - the motivation to request some face-to-face time as opposed to using > the mailing list to progress your work. > > Regards, > > Jon & Julien > From nobody Sat Nov 11 20:04: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 587FB1270A0; Sat, 11 Nov 2017 20:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_H4=-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 (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 ehs_DLl1x4IV; Sat, 11 Nov 2017 20:04:22 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0121.outbound.protection.outlook.com [104.47.37.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46ADD1201FA; Sat, 11 Nov 2017 20:04:22 -0800 (PST) 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=gvipo/rUHmmdxNt0Ms0OMBziwdJ8gUOiIY/eYkkNbnY=; b=YWwt4PJAlkdYZbAwEube3vF8f0UpR6AcSEde6MXQsBqtdskNVPZ9QzMgD6+cGl8VXS2jaE6+FVOeYEH45acTDLjuNtsJej3B7k/F4Pc31hhSfshFzf0cnxRnp1jN4WlfGNDxS+qqCereG/xdQpdcLGSDApxJ2XdWPRCA0gggIXk= Received: from CY4PR0201MB3603.namprd02.prod.outlook.com (52.132.99.21) by CY4PR0201MB3603.namprd02.prod.outlook.com (52.132.99.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.12; Sun, 12 Nov 2017 04:04:20 +0000 Received: from CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::dce9:6773:68c7:10f3]) by CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::dce9:6773:68c7:10f3%13]) with mapi id 15.20.0218.011; Sun, 12 Nov 2017 04:04:20 +0000 From: Jonathan Hardwick To: "draft-ietf-pce-pcep-exp-codepoints@ietf.org" CC: "pce@ietf.org" , "pce-chairs@ietf.org" Thread-Topic: Shepherd's review of draft-ietf-pce-pcep-exp-codepoints Thread-Index: AdNbazxoJX1mpJIUTGiD0iKyZXkw0w== Date: Sun, 12 Nov 2017 04:04:20 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-originating-ip: [2001:67c:1232:144:38ce:368e:58a3:4004] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR0201MB3603; 6:qzKT3ENkwAL+2oaJfqVSwYoCWeqTn8TVC+opFBwIlsjYYkLsuXcZsRJWjzrVjc6B4MuDD0u2I3/ZbDpCxrw62f0pKZ647y07v2yAKRTt9zErkkwxkYh4cS6DJ4yY+XmGQiKRqilCMbfGZacBb4gA0BE7c0Y+yseSPi8UlL+CAgLTCAtEvvF4WxdxX3bwfZmXZdymS+zBHVoGJO2JaMjYhOryLbSxgUKxdxK48+4gZJioe7W7QBA+pPnOTm/1DadcnNtMuIXIS/opmHXtuMN1TFrroG+oIHoQKICIeC0W6E3A1gaIYU+zcy/9MevHunYvvO5Jm43MXEFRLgJoJra8RQWkBkhsdaziboYhZ62pFi0=; 5:sLNaMyIqqCiG08T3t6uOhBGVYKJI54K12wYTnbUHrKV8FrNp9NVtN6q9ehg3BDxDJwmZ2LWOvVEQDsQr/RyPDTMNdBHLTNw0/eFwjWTddjFvREVmVIg8fMsjhEiGnTW4ismVRyrnv9jWnim+PY8LSe9yi9cvD2Asr4/FilT0mEY=; 24:dBcdYexirjOQqO8sRSsht9Aox4gYGy8HckC3ba84B+3dwpWV8BPv3S99LPQ80iOjJ6+0T7KTHVzyphGchm+o6RkHrjGevyiDkCz74sn+VOs=; 7:/ZkSZzMdB1KyrgssRJSLM8oqm7JQLiqcn4bzfoctvldafiAeQjb9XFZEPnPzJYmixegqHneJ1H4Kwmg0PWD808fWeanhbvhVrIYs+rq+qvlaQzQT+DYOkv6H0XQN/ZCvAwcnuNcuIn7rL020D7MYSrgAa5XLC7PQlkjDjGAd6Fn0gAyULfoUZcHwgi+Z1JBcV5SWuD0OxEN4NR4aD/HP+TU5rwbSvp98zkrgc1fuw46EFWT1LF/cSp/G4HZWw1eX x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ea7af2ec-fa61-4a5c-99d5-08d5298273bf x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:CY4PR0201MB3603; x-ms-traffictypediagnostic: CY4PR0201MB3603: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(131327999870524)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3231022)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR0201MB3603; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR0201MB3603; x-forefront-prvs: 0489CFBAC9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(189002)(199003)(2351001)(790700001)(6506006)(3660700001)(316002)(86362001)(450100002)(54906003)(106356001)(105586002)(4326008)(2906002)(7736002)(81156014)(3280700002)(14454004)(8676002)(6436002)(81166006)(8936002)(5640700003)(6116002)(55016002)(25786009)(102836003)(33656002)(54896002)(6306002)(230783001)(7696004)(5660300001)(9686003)(50986999)(2501003)(53936002)(99286004)(72206003)(189998001)(478600001)(54356999)(6916009)(5250100002)(101416001)(2900100001)(97736004)(5630700001)(53546010)(68736007)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR0201MB3603; H:CY4PR0201MB3603.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR0201MB36030DD4394ABF68124A5CFA842A0CY4PR0201MB3603_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-Network-Message-Id: ea7af2ec-fa61-4a5c-99d5-08d5298273bf X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2017 04:04:20.6279 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0201MB3603 Archived-At: Subject: [Pce] Shepherd's review of draft-ietf-pce-pcep-exp-codepoints 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: Sun, 12 Nov 2017 04:04:25 -0000 --_000_CY4PR0201MB36030DD4394ABF68124A5CFA842A0CY4PR0201MB3603_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re-sending to the correct DL :) From: Jonathan Hardwick Sent: 12 November 2017 12:02 To: 'draft-ietf-pce-exp-codepoints@ietf.org' Cc: 'pce@ietf.org' ; pce-chairs@ietf.org Subject: Shepherd's review of draft-ietf-pce-exp-codepoints Hi there I am the document shepherd for this draft. Please find my review of the dr= aft below. Many thanks for writing this draft. It looks in good shape overall. There= are just a few clarifications I would like to make before we forward it to= the IESG for publication. Cheers Jon Abstract This sentence about new sub-registries is misleading - the allocation polic= y for new sub-registries is decided by the drafts that create the sub-regis= tries and does not have to be IETF Review. I propose: OLD IANA established a new top-level registry to contain all PCEP codepoints and sub-registries. The allocation policy for each new registry is by IETF Review. NEW IANA established a top-level registry to contain all PCEP codepoints and sub-registries. This top-level registry contains sub-registries for PCEP message, object and TLV types. The allocation policy for each of these sub-registries is IETF Review. END Introduction OLD 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. NEW The Path Computation Element communication Protocol (PCEP) [RFC5440] pro= vides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. END i.e. add reference to RFC 5440. The second paragraph is superfluous - I suggest deleting: Further, in order to support use cases described in [RFC8051], [I-D.ietf-pce-stateful-pce] specifies a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP. [I-D.ietf-pce-pce-initiated-lsp] describes the setup, maintenance and teardown of PCE-initiated LSPs under the stateful PCE model. Please apply the same comments I made for the abstract to the following tex= t: OLD IANA established a new top- level registry to contain all PCEP codepoints and sub-registries. The allocation policy for each new registry is by IETF Review as described in [RFC8126]. NEW IANA established a top- level registry to contain all PCEP codepoints and sub-registries. This top-level registry contains sub-registries for PCEP message, object and TLV types. The allocation policy for each of these sub-registries is IETF Review. END Suggested change for clarity: OLD With some recent advancement, there is an enhanced need to experiment with PCEP. NEW Recently, there have been rapid advancements in PCE technology, which has created an enhanced need to experiment with PCEP. END Section 5 The following paragraph does not tell the whole story. A PCE that does not recognize an experimental PCEP object, will reject the entire PCEP message and send a PCE error message with Error- Type=3D"Unknown Object" or "Not supported object" as described in [RFC5440]. If the P flag is clear in the object header, then the PCE MAY ignore the ob= ject instead of generating this error message. Also, you do not discuss wha= t a PCC would do on receipt of a PCUdp or PCInitiate containing an unrecogn= ised experimental object - it is inconsistent that you don't cover these ca= ses. (FWIW, RFC 8231 is a bit ambiguous about what a PCC should do about t= he PCUpd. Section 6.2 says that a PCErr should be sent, but then it refers = to section 7.3.3, which says that a PCRpt should be sent. Hmmm.) Also: s/PCE error message/PCErr message/ Section 7 Nit: add comma after "accidentally" Appendix A I think the text in this Appendix could be clearer. Here is my suggestion. OLD Based on the feedback from the WG, it was decided to focus only on the essentials in the scope of this documents. For others, Experiments can use a new experimental TLV/Object instead. NEW Based on feedback from the PCE WG, it was decided to allocate an Experimental code point range only in the message, object and TLV sub-registries. The justification for this decision is that, if an experiment finds that it wants to use a new code point in another PCEP sub-registry, it can implement the same function using a new experimental object or TLV instead. END Other Please update reference draft-ietf-pce-stateful-pce -> RFC 8231 Please update reference draft-ietf-pce-pce-initiated-lsp-10 -> draft-ietf-p= ce-pce-initiated-lsp-11 --_000_CY4PR0201MB36030DD4394ABF68124A5CFA842A0CY4PR0201MB3603_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Re-sending to the correct DL J

 

From: Jonathan Hardwick
Sent: 12 November 2017 12:02
To: 'draft-ietf-pce-exp-codepoints@ietf.org' <draft-ietf-pce-exp-= codepoints@ietf.org>
Cc: 'pce@ietf.org' <pce@ietf.org>; pce-chairs@ietf.org
Subject: Shepherd's review of draft-ietf-pce-exp-codepoints

 

Hi there

 

I am the document shepherd for this draft.  Ple= ase find my review of the draft below.

 

Many thanks for writing this draft.  It looks i= n good shape overall.  There are just a few clarifications I would lik= e to make before we forward it to the IESG for publication.

 

Cheers

Jon

 

Abstract

 

This sentence about new sub-registries is misleading= – the allocation policy for new sub-registries is decided by the dra= fts that create the sub-registries and does not have to be IETF Review.&nbs= p; I propose:

OLD

   IANA established a new top-level registry to contain all =
PCEP
   codepoints and sub-registries.  The allocation polic=
y for each new
   registry is by IETF Review.

NEW

   IANA established a top-level registry to contain all PCEP=

   codepoints and sub-registries.   This top-level=
 registry contains
   sub-registries for PCEP message, object and TLV types.&nb=
sp; The
   allocation policy for each of these sub-registries is IET=
F Review.

END

 

Introduction

 

OLD

   The Path Computation Element communication Protocol (PCEP=
) provides
   mechanisms for Path Computation Elements (PCEs) to perfor=
m path
   computations in response to Path Computation Clients (PCC=
s) requests.

NEW

   The Path Computation Element communication Protocol (PCEP=
) [RFC5440] provides
   mechanisms for Path Computation Elements (PCEs) to perfor=
m path
   computations in response to Path Computation Clients (PCC=
s) requests.

END

i.e. add reference to RFC 5440.

 

The second paragraph is superfluous – I sugges= t deleting:

   Further, in order to support use cases described in [RFC8=
051],
   [I-D.ietf-pce-stateful-pce] specifies a set of extensions=
 to PCEP to
   enable stateful control of MPLS-TE and GMPLS LSPs via PCE=
P.
   [I-D.ietf-pce-pce-initiated-lsp] describes the setup, mai=
ntenance and
   teardown of PCE-initiated LSPs under the stateful PCE mod=
el.

 

Please apply the same comments I made for the abstra= ct to the following text:

OLD

   IANA established a new top-
   level registry to contain all PCEP codepoints and sub-reg=
istries.
   The allocation policy for each new registry is by IETF Re=
view as
   described in [RFC8126].

NEW

   IANA established a top-
   level registry to contain all PCEP codepoints and sub-reg=
istries.
   This top-level registry contains sub-registries for PCEP =
message,
   object and TLV types.  The allocation policy for eac=
h of these
   sub-registries is IETF Review.

END

 

Suggested change for clarity:

OLD

   With some recent advancement, there is an enhanced need t=
o experiment
   with PCEP.

NEW

   Recently, there have been rapid advancements in PCE techn=
ology, which
   has created an enhanced need to experiment with PCEP.

END

 

Section 5

 

The following paragraph does not tell the whole stor= y.

 

   A PCE that does no= t recognize an experimental PCEP object, will

   reject the entire = PCEP message and send a PCE error message with

   Error- Type=3D&quo= t;Unknown Object" or "Not supported object" as described

   in [RFC5440].=

 

If the P flag is clear in the object header, then th= e PCE MAY ignore the object instead of generating this error message. Also,= you do not discuss what a PCC would do on receipt of a PCUdp or PCInitiate= containing an unrecognised experimental object – it is inconsistent that you don’t cover these cases.&= nbsp; (FWIW, RFC 8231 is a bit ambiguous about what a PCC should do about t= he PCUpd. Section 6.2 says that a PCErr should be sent, but then it refers = to section 7.3.3, which says that a PCRpt should be sent. Hmmm.)

 

Also: s/PCE error message/PCErr message/<= /p>

 

Section 7

Nit: add comma after “accidentally”=

 

Appendix A

I think the text in this Appendix could be clearer.&= nbsp; Here is my suggestion.

OLD

   Based on the feedback from the WG, it was decided to focu=
s only on
   the essentials in the scope of this documents.  For =
others,
   Experiments can use a new experimental TLV/Object instead=
.

NEW

   Based on feedback from the PCE WG, it was decided to allo=
cate an
   Experimental code point range only in the message, object=
 and TLV
   sub-registries.  The justification for this decision=
 is that, if
   an experiment finds that it wants to use a new code point=
 in
   another PCEP sub-registry, it can implement the same func=
tion using
   a new experimental object or TLV instead.

END


 


Other


Please update reference draft-ietf-pce-stateful-pce =
-> RFC 8231


Please update reference draft-ietf-pce-pce-initiated=
-lsp-10 -> draft-ietf-pce-pce-initiated-lsp-11


 
--_000_CY4PR0201MB36030DD4394ABF68124A5CFA842A0CY4PR0201MB3603_-- From nobody Sat Nov 11 20:12:22 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 61C06126C0F; Sat, 11 Nov 2017 20:12:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_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 NGqqnJXUl2uM; Sat, 11 Nov 2017 20:12:19 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0110.outbound.protection.outlook.com [104.47.37.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 214701201FA; Sat, 11 Nov 2017 20:12:18 -0800 (PST) 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=1VjA8FtRqdg3iyyia1f2KDEfwtjwElgmFsCV2cBMU/o=; b=Q5aVjBHPulHJitcvtZ/Bu36yN5RGjKm50BCqwirySVc3AqLE1FmK+Dopn+pRZtKyWVBHaNDCUWw94RMjszjgrt9UmN2Q0BuPCU61hGuJHXbzL1Cu4MFMN18O3TvXXIz2RT1fTSARGh8swwCUUlPpzIRBa2OGbQ1nmsW0yZBDt+k= Received: from CY4PR0201MB3603.namprd02.prod.outlook.com (52.132.99.21) by CY4PR0201MB3603.namprd02.prod.outlook.com (52.132.99.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.12; Sun, 12 Nov 2017 04:02:16 +0000 Received: from CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::dce9:6773:68c7:10f3]) by CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::dce9:6773:68c7:10f3%13]) with mapi id 15.20.0218.011; Sun, 12 Nov 2017 04:02:16 +0000 From: Jonathan Hardwick To: "draft-ietf-pce-exp-codepoints@ietf.org" CC: "pce@ietf.org" , "pce-chairs@ietf.org" Thread-Topic: Shepherd's review of draft-ietf-pce-exp-codepoints Thread-Index: AdNbZE7rmsmlgTaGQv2Kn+ITBRmVtQ== Date: Sun, 12 Nov 2017 04:02:16 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-originating-ip: [2001:67c:1232:144:38ce:368e:58a3:4004] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR0201MB3603; 6:eXeMOZMn06ssOuhSPd2dGYhIZG7zTNXVRTG1LUJpf0bDJSv6XxJasV9Uy6BI/ehXr8szuBHWMIrXeJkzMk0vsN6yBqEowLnFzBbrW1c+ADc9jiwuyI8n/ctatrVF6ErzlYsmXQoSSiEK2WBzmtVcHW5gb9hJGS1S7NOj8MSV5FT2f9f6wv5AMw1QvE8aTEk8yYCmvEYmgyowgdYcluueP94Tl2BysIBUyzWXZ/6ivftb/F1N7osenfHqTF0+rwge+pyHmTyWcA6AYAp1htOw6E3/AQJ0mXuasLPpbFGJgsESDM+w+5ZxMH9wB0BWYkxVYkyTkGEwE76se/3OBBA6ZIHVA0JN9NlnoAW7cNUXup4=; 5:zfZ57aWrfNjv9A1IAXjxzUCdeFMJb/ucms88zw5tXyNfyk00j/eXOpLn8yUqkBZ+9glxHp2oYigphYeyuxQcOTxYv2drpQoH/FvMjCmnJ0YgbdCQ1piNUFiqcYFnU1BtQQMEkHJo5wZKu+jfGaPmgUpK08JL9SjBkvtOeknn/p8=; 24:g9EuQgK9EspJXxqZ7OYBqL46+HQzqLnpcY7cF0CiHKabZCYQpcGXsskCUDHLoLpNwyEyZ74ERqcCT1D4FkoK2jiywX4Y2/sqptSERRnJcwk=; 7:wT9B3LCKxHFsw9HzOOLyDSqGZZx3i+5ZWSiakoG5/6ecrOsLA2qCGxnBUwBeEf8UOgE63ke5BJqLWKmPVzVJHVtKWEzI3PCFNNI40RM95zn+UlWFpieQcqPkf0wlXLnSPpNPjIb4rWEC6HViD2cxNXJ8zpUVMGemJj+jgKebQjFfEZRd31EJUyTsf6pzQfP8Tin/x8Bt2fX0oGG36pgncek5mOeFKcsfKxeyzn58zQj1MWgI0594UZo02Pvor2iT x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9b7181fa-c733-406a-302a-08d5298229ae x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:CY4PR0201MB3603; x-ms-traffictypediagnostic: CY4PR0201MB3603: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(131327999870524)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3231022)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR0201MB3603; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR0201MB3603; x-forefront-prvs: 0489CFBAC9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(189002)(199003)(2351001)(790700001)(6506006)(3660700001)(316002)(86362001)(450100002)(54906003)(106356001)(105586002)(4326008)(2906002)(7736002)(81156014)(3280700002)(14454004)(8676002)(6436002)(81166006)(8936002)(5640700003)(6116002)(55016002)(25786009)(102836003)(33656002)(54896002)(6306002)(230783001)(7696004)(5660300001)(9686003)(50986999)(2501003)(53936002)(99286004)(72206003)(189998001)(478600001)(54356999)(6916009)(5250100002)(101416001)(2900100001)(97736004)(5630700001)(68736007)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR0201MB3603; H:CY4PR0201MB3603.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR0201MB360364AA5FB23833864772ED842A0CY4PR0201MB3603_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9b7181fa-c733-406a-302a-08d5298229ae X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2017 04:02:16.2999 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0201MB3603 Archived-At: Subject: [Pce] Shepherd's review of draft-ietf-pce-exp-codepoints 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: Sun, 12 Nov 2017 04:12:21 -0000 --_000_CY4PR0201MB360364AA5FB23833864772ED842A0CY4PR0201MB3603_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi there I am the document shepherd for this draft. Please find my review of the dr= aft below. Many thanks for writing this draft. It looks in good shape overall. There= are just a few clarifications I would like to make before we forward it to= the IESG for publication. Cheers Jon Abstract This sentence about new sub-registries is misleading - the allocation polic= y for new sub-registries is decided by the drafts that create the sub-regis= tries and does not have to be IETF Review. I propose: OLD IANA established a new top-level registry to contain all PCEP codepoints and sub-registries. The allocation policy for each new registry is by IETF Review. NEW IANA established a top-level registry to contain all PCEP codepoints and sub-registries. This top-level registry contains sub-registries for PCEP message, object and TLV types. The allocation policy for each of these sub-registries is IETF Review. END Introduction OLD 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. NEW The Path Computation Element communication Protocol (PCEP) [RFC5440] pro= vides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. END i.e. add reference to RFC 5440. The second paragraph is superfluous - I suggest deleting: Further, in order to support use cases described in [RFC8051], [I-D.ietf-pce-stateful-pce] specifies a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP. [I-D.ietf-pce-pce-initiated-lsp] describes the setup, maintenance and teardown of PCE-initiated LSPs under the stateful PCE model. Please apply the same comments I made for the abstract to the following tex= t: OLD IANA established a new top- level registry to contain all PCEP codepoints and sub-registries. The allocation policy for each new registry is by IETF Review as described in [RFC8126]. NEW IANA established a top- level registry to contain all PCEP codepoints and sub-registries. This top-level registry contains sub-registries for PCEP message, object and TLV types. The allocation policy for each of these sub-registries is IETF Review. END Suggested change for clarity: OLD With some recent advancement, there is an enhanced need to experiment with PCEP. NEW Recently, there have been rapid advancements in PCE technology, which has created an enhanced need to experiment with PCEP. END Section 5 The following paragraph does not tell the whole story. A PCE that does not recognize an experimental PCEP object, will reject the entire PCEP message and send a PCE error message with Error- Type=3D"Unknown Object" or "Not supported object" as described in [RFC5440]. If the P flag is clear in the object header, then the PCE MAY ignore the ob= ject instead of generating this error message. Also, you do not discuss wha= t a PCC would do on receipt of a PCUdp or PCInitiate containing an unrecogn= ised experimental object - it is inconsistent that you don't cover these ca= ses. (FWIW, RFC 8231 is a bit ambiguous about what a PCC should do about t= he PCUpd. Section 6.2 says that a PCErr should be sent, but then it refers = to section 7.3.3, which says that a PCRpt should be sent. Hmmm.) Also: s/PCE error message/PCErr message/ Section 7 Nit: add comma after "accidentally" Appendix A I think the text in this Appendix could be clearer. Here is my suggestion. OLD Based on the feedback from the WG, it was decided to focus only on the essentials in the scope of this documents. For others, Experiments can use a new experimental TLV/Object instead. NEW Based on feedback from the PCE WG, it was decided to allocate an Experimental code point range only in the message, object and TLV sub-registries. The justification for this decision is that, if an experiment finds that it wants to use a new code point in another PCEP sub-registry, it can implement the same function using a new experimental object or TLV instead. END Other Please update reference draft-ietf-pce-stateful-pce -> RFC 8231 Please update reference draft-ietf-pce-pce-initiated-lsp-10 -> draft-ietf-p= ce-pce-initiated-lsp-11 --_000_CY4PR0201MB360364AA5FB23833864772ED842A0CY4PR0201MB3603_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi there

 

I am the document shepherd for this draft.  Ple= ase find my review of the draft below.

 

Many thanks for writing this draft.  It looks i= n good shape overall.  There are just a few clarifications I would lik= e to make before we forward it to the IESG for publication.

 

Cheers

Jon

 

Abstract

 

This sentence about new sub-registries is misleading= – the allocation policy for new sub-registries is decided by the dra= fts that create the sub-registries and does not have to be IETF Review.&nbs= p; I propose:

OLD

   IANA established a new top-level registry to contain all =
PCEP
   codepoints and sub-registries.  The allocation polic=
y for each new
   registry is by IETF Review.

NEW

   IANA established a top-level registry to contain all PCEP=

   codepoints and sub-registries.   This top-level=
 registry contains
   sub-registries for PCEP message, object and TLV types.&nb=
sp; The
   allocation policy for each of these sub-registries is IET=
F Review.

END

 

Introduction

 

OLD

   The Path Computation Element communication Protocol (PCEP=
) provides
   mechanisms for Path Computation Elements (PCEs) to perfor=
m path
   computations in response to Path Computation Clients (PCC=
s) requests.

NEW

   The Path Computation Element communication Protocol (PCEP=
) [RFC5440] provides
   mechanisms for Path Computation Elements (PCEs) to perfor=
m path
   computations in response to Path Computation Clients (PCC=
s) requests.

END

i.e. add reference to RFC 5440.

 

The second paragraph is superfluous – I sugges= t deleting:

   Further, in order to support use cases described in [RFC8=
051],
   [I-D.ietf-pce-stateful-pce] specifies a set of extensions=
 to PCEP to
   enable stateful control of MPLS-TE and GMPLS LSPs via PCE=
P.
   [I-D.ietf-pce-pce-initiated-lsp] describes the setup, mai=
ntenance and
   teardown of PCE-initiated LSPs under the stateful PCE mod=
el.

 

Please apply the same comments I made for the abstra= ct to the following text:

OLD

   IANA established a new top-
   level registry to contain all PCEP codepoints and sub-reg=
istries.
   The allocation policy for each new registry is by IETF Re=
view as
   described in [RFC8126].

NEW

   IANA established a top-
   level registry to contain all PCEP codepoints and sub-reg=
istries.
   This top-level registry contains sub-registries for PCEP =
message,
   object and TLV types.  The allocation policy for eac=
h of these
   sub-registries is IETF Review.

END

 

Suggested change for clarity:

OLD

   With some recent advancement, there is an enhanced need t=
o experiment
   with PCEP.

NEW

   Recently, there have been rapid advancements in PCE techn=
ology, which
   has created an enhanced need to experiment with PCEP.

END

 

Section 5

 

The following paragraph does not tell the whole stor= y.

 

   A PCE that does no= t recognize an experimental PCEP object, will

   reject the entire = PCEP message and send a PCE error message with

   Error- Type=3D&quo= t;Unknown Object" or "Not supported object" as described

   in [RFC5440].=

 

If the P flag is clear in the object header, then th= e PCE MAY ignore the object instead of generating this error message. Also,= you do not discuss what a PCC would do on receipt of a PCUdp or PCInitiate= containing an unrecognised experimental object – it is inconsistent that you don’t cover these cases.&= nbsp; (FWIW, RFC 8231 is a bit ambiguous about what a PCC should do about t= he PCUpd. Section 6.2 says that a PCErr should be sent, but then it refers = to section 7.3.3, which says that a PCRpt should be sent. Hmmm.)

 

Also: s/PCE error message/PCErr message/<= /p>

 

Section 7

Nit: add comma after “accidentally”=

 

Appendix A

I think the text in this Appendix could be clearer.&= nbsp; Here is my suggestion.

OLD

   Based on the feedback from the WG, it was decided to focu=
s only on
   the essentials in the scope of this documents.  For =
others,
   Experiments can use a new experimental TLV/Object instead=
.

NEW

   Based on feedback from the PCE WG, it was decided to allo=
cate an
   Experimental code point range only in the message, object=
 and TLV
   sub-registries.  The justification for this decision=
 is that, if
   an experiment finds that it wants to use a new code point=
 in
   another PCEP sub-registry, it can implement the same func=
tion using
   a new experimental object or TLV instead.

END


 


Other


Please update reference draft-ietf-pce-stateful-pce =
-> RFC 8231


Please update reference draft-ietf-pce-pce-initiated=
-lsp-10 -> draft-ietf-pce-pce-initiated-lsp-11


 
--_000_CY4PR0201MB360364AA5FB23833864772ED842A0CY4PR0201MB3603_-- From nobody Sun Nov 12 04:09:11 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 9C55412941D; Sun, 12 Nov 2017 04:09:09 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 8tpAnwv2j9Xc; Sun, 12 Nov 2017 04:09:07 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5BB1292D3; Sun, 12 Nov 2017 04:09:07 -0800 (PST) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id B7E6FDFFB8B55; Sun, 12 Nov 2017 12:09:04 +0000 (GMT) Received: from BLREML701-CAH.china.huawei.com (10.20.4.170) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sun, 12 Nov 2017 12:09:05 +0000 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.27]) by blreml701-cah.china.huawei.com ([::1]) with mapi id 14.03.0361.001; Sun, 12 Nov 2017 17:38:54 +0530 From: Dhruv Dhody To: Jonathan Hardwick , "draft-ietf-pce-pcep-exp-codepoints@ietf.org" CC: "pce@ietf.org" , "pce-chairs@ietf.org" , 'Dhruv Dhody' Thread-Topic: Shepherd's review of draft-ietf-pce-pcep-exp-codepoints Thread-Index: AdNbazxoJX1mpJIUTGiD0iKyZXkw0wAQjYAA Date: Sun, 12 Nov 2017 12:08:54 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8D5C30A9@BLREML503-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.76.173] Content-Type: multipart/alternative; boundary="_000_23CE718903A838468A8B325B80962F9B8D5C30A9BLREML503MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pce] Shepherd's review of draft-ietf-pce-pcep-exp-codepoints 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: Sun, 12 Nov 2017 12:09:09 -0000 --_000_23CE718903A838468A8B325B80962F9B8D5C30A9BLREML503MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, Thanks for your review. See inline... From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Jonathan Hardwick Sent: 12 November 2017 12:04 To: draft-ietf-pce-pcep-exp-codepoints@ietf.org Cc: pce@ietf.org; pce-chairs@ietf.org Subject: [Pce] Shepherd's review of draft-ietf-pce-pcep-exp-codepoints Re-sending to the correct DL :) From: Jonathan Hardwick Sent: 12 November 2017 12:02 To: 'draft-ietf-pce-exp-codepoints@ietf.org' > Cc: 'pce@ietf.org' >; pce-chairs@ietf.org= Subject: Shepherd's review of draft-ietf-pce-exp-codepoints Hi there I am the document shepherd for this draft. Please find my review of the dr= aft below. Many thanks for writing this draft. It looks in good shape overall. There= are just a few clarifications I would like to make before we forward it to= the IESG for publication. Cheers Jon Abstract This sentence about new sub-registries is misleading - the allocation polic= y for new sub-registries is decided by the drafts that create the sub-regis= tries and does not have to be IETF Review. I propose: OLD IANA established a new top-level registry to contain all PCEP codepoints and sub-registries. The allocation policy for each new registry is by IETF Review. NEW IANA established a top-level registry to contain all PCEP codepoints and sub-registries. This top-level registry contains sub-registries for PCEP message, object and TLV types. The allocation policy for each of these sub-registries is IETF Review. END [[[Dhruv Dhody]]] Ack. Introduction OLD 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. NEW The Path Computation Element communication Protocol (PCEP) [RFC5440] pro= vides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. END i.e. add reference to RFC 5440. [[[Dhruv Dhody]]] Ack. The second paragraph is superfluous - I suggest deleting: Further, in order to support use cases described in [RFC8051], [I-D.ietf-pce-stateful-pce] specifies a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP. [I-D.ietf-pce-pce-initiated-lsp] describes the setup, maintenance and teardown of PCE-initiated LSPs under the stateful PCE model. [[[Dhruv Dhody]]] Because of the comment for handling the unknown experimen= tal objects for the stateful PCE messages, I think it is better to continue= to keep this text. What do you think? Please apply the same comments I made for the abstract to the following tex= t: OLD IANA established a new top- level registry to contain all PCEP codepoints and sub-registries. The allocation policy for each new registry is by IETF Review as described in [RFC8126]. NEW IANA established a top- level registry to contain all PCEP codepoints and sub-registries. This top-level registry contains sub-registries for PCEP message, object and TLV types. The allocation policy for each of these sub-registries is IETF Review. END [[[Dhruv Dhody]]] Ack. Suggested change for clarity: OLD With some recent advancement, there is an enhanced need to experiment with PCEP. NEW Recently, there have been rapid advancements in PCE technology, which has created an enhanced need to experiment with PCEP. END [[[Dhruv Dhody]]] Ack. Section 5 The following paragraph does not tell the whole story. A PCE that does not recognize an experimental PCEP object, will reject the entire PCEP message and send a PCE error message with Error- Type=3D"Unknown Object" or "Not supported object" as described in [RFC5440]. If the P flag is clear in the object header, then the PCE MAY ignore the ob= ject instead of generating this error message. Also, you do not discuss wha= t a PCC would do on receipt of a PCUdp or PCInitiate containing an unrecogn= ised experimental object - it is inconsistent that you don't cover these ca= ses. (FWIW, RFC 8231 is a bit ambiguous about what a PCC should do about t= he PCUpd. Section 6.2 says that a PCErr should be sent, but then it refers = to section 7.3.3, which says that a PCRpt should be sent. Hmmm.) [[[Dhruv Dhody]]] Yes. How about I update to this - If the PCE does not understand or support an experimental object with the P flag set in the Object Header, in the Path Computation Request message (PCReq), the entire PCEP message is rejected and PCE responds with a PCErr message with Error-Type=3D"Unknown Object" or "Not supported object" as described in [RFC5440]. Otherwise the object is ignored. In case of stateful PCE messages [RFC8231], the P flag is ignored and the unknown object handling is as per the stateful PCE extensions. And let's try to handle the inconsistency in RFC 8231 with an errata perhap= s? And handle PCE-initiated during AUTH48? Also: s/PCE error message/PCErr message/ [[[Dhruv Dhody]]] Ack Section 7 Nit: add comma after "accidentally" [[[Dhruv Dhody]]] Ok Appendix A I think the text in this Appendix could be clearer. Here is my suggestion. OLD Based on the feedback from the WG, it was decided to focus only on the essentials in the scope of this documents. For others, Experiments can use a new experimental TLV/Object instead. NEW Based on feedback from the PCE WG, it was decided to allocate an Experimental code point range only in the message, object and TLV sub-registries. The justification for this decision is that, if an experiment finds that it wants to use a new code point in another PCEP sub-registry, it can implement the same function using a new experimental object or TLV instead. END [[[Dhruv Dhody]]] Updated Other Please update reference draft-ietf-pce-stateful-pce -> RFC 8231 Please update reference draft-ietf-pce-pce-initiated-lsp-10 -> draft-ietf-p= ce-pce-initiated-lsp-11 [[[Dhruv Dhody]]] Ack Diff: https://tools.ietf.org/rfcdiff?url2=3Dhttps://raw.githubusercontent.c= om/dhruvdhody-huawei/ietf/master/draft-ietf-pce-pcep-exp-codepoints-03.txt&= url1=3Dhttps://www.ietf.org/id/draft-ietf-pce-pcep-exp-codepoints-02.txt Thanks for the review! Regards, Dhruv --_000_23CE718903A838468A8B325B80962F9B8D5C30A9BLREML503MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,

 

Thanks for your review. See inlineR= 30;

 

From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Jonathan Hardwick
Sent: 12 November 2017 12:04
To: draft-ietf-pce-pcep-exp-codepoints@ietf.org
Cc: pce@ietf.org; pce-chairs@ietf.org
Subject: [Pce] Shepherd's review of draft-ietf-pce-pcep-exp-codepoin= ts

 

Re-sending to the correct DL J

 

From: Jonathan Hardwick
Sent: 12 November 2017 12:02
To: 'draft-ietf-pce-exp-codepoints@ietf.org' <draft-ietf-pce-exp-codepoints@ietf.o= rg>
Cc: 'pce@ietf.org' <pce@ietf.org<= /a>>; pce-chairs@ietf.org
Subject: Shepherd's review of draft-ietf-pce-exp-codepoints

 

Hi there

 

I am the document shepherd for = this draft.  Please find my review of the draft below.

 

Many thanks for writing this dr= aft.  It looks in good shape overall.  There are just a few clari= fications I would like to make before we forward it to the IESG for publica= tion.

 

Cheers

Jon

 

Abstract

 

This sentence about new sub-reg= istries is misleading – the allocation policy for new sub-registries = is decided by the drafts that create the sub-registries and does not have t= o be IETF Review.  I propose:

OLD

   IANA established a new top-level reg=
istry to contain all PCEP
   codepoints and sub-registries. =
 The allocation policy for each new
   registry is by IETF Review.

NEW

   IANA established a top-level registr=
y to contain all PCEP
   codepoints and sub-registries. =
  This top-level registry contains
   sub-registries for PCEP message, obj=
ect and TLV types.  The
   allocation policy for each of these =
sub-registries is IETF Review.

END

&n= bsp;

[[[Dhruv Dhody]]] Ack.

 

Introduction

 

OLD

   The Path Computation Element communi=
cation Protocol (PCEP) provides
   mechanisms for Path Computation Elem=
ents (PCEs) to perform path
   computations in response to Path Com=
putation Clients (PCCs) requests.

NEW

   The Path Computation Element communi=
cation Protocol (PCEP) [RFC5440] provides
   mechanisms for Path Computation Elem=
ents (PCEs) to perform path
   computations in response to Path Com=
putation Clients (PCCs) requests.

END

i.e. add reference to RFC 5440.=

&n= bsp;

[[[Dhruv Dhody]]] Ack.

 

The second paragraph is superfl= uous – I suggest deleting:

   Further, in order to support use cas=
es described in [RFC8051],
   [I-D.ietf-pce-stateful-pce] specifie=
s a set of extensions to PCEP to
   enable stateful control of MPLS-TE a=
nd GMPLS LSPs via PCEP.
   [I-D.ietf-pce-pce-initiated-lsp] des=
cribes the setup, maintenance and
   teardown of PCE-initiated LSPs under=
 the stateful PCE model.

&n= bsp;

[[[Dhruv Dhody]]] Becau= se of the comment for handling the unknown experimental objects for the sta= teful PCE messages, I think it is better to continue to keep this text. What do you think?

 

Please apply the same comments = I made for the abstract to the following text:

OLD

   IANA established a new top-
   level registry to contain all PCEP c=
odepoints and sub-registries.
   The allocation policy for each new r=
egistry is by IETF Review as
   described in [RFC8126].

NEW

   IANA established a top-
   level registry to contain all PCEP c=
odepoints and sub-registries.
   This top-level registry contains sub=
-registries for PCEP message,
   object and TLV types.  The allo=
cation policy for each of these
   sub-registries is IETF Review.<=
/o:p>

END

&n= bsp;

[[[Dhruv Dhody]]] Ack.

 

Suggested change for clarity:

OLD

   With some recent advancement, there =
is an enhanced need to experiment
   with PCEP.

NEW

   Recently, there have been rapid adva=
ncements in PCE technology, which
   has created an enhanced need to expe=
riment with PCEP.

END

&n= bsp;

[[[Dhruv Dhody]]] Ack.

 

Section 5<= /u>

 

The following paragraph does no= t tell the whole story.

 

   A P= CE that does not recognize an experimental PCEP object, will

   rej= ect the entire PCEP message and send a PCE error message with

   Err= or- Type=3D"Unknown Object" or "Not supported object" a= s described

   in = [RFC5440].

 

If the P flag is clear in the o= bject header, then the PCE MAY ignore the object instead of generating this= error message. Also, you do not discuss what a PCC would do on receipt of = a PCUdp or PCInitiate containing an unrecognised experimental object – it is inconsistent that you don&#= 8217;t cover these cases.  (FWIW, RFC 8231 is a bit ambiguous about wh= at a PCC should do about the PCUpd. Section 6.2 says that a PCErr should be= sent, but then it refers to section 7.3.3, which says that a PCRpt should be sent. Hmmm.)

&n= bsp;

[[[Dhruv Dhody]]] Yes. = How about I update to this –

 

&= nbsp;  If the PCE does not understand or support an experimental objec= t with

&= nbsp;  the P flag set in the Object Header, in the Path Computation Re= quest

&= nbsp;  message (PCReq), the entire PCEP message is rejected and PCE re= sponds

&= nbsp;  with a PCErr message with Error-Type=3D"Unknown Object&quo= t; or "Not

&= nbsp;  supported object" as described in [RFC5440].  Otherwi= se the object is

&= nbsp;  ignored.  In case of stateful PCE messages [RFC8231], the = P flag is

&= nbsp;  ignored and the unknown object handling is as per the stateful = PCE

   extensions.=

 

And let’s try to = handle the inconsistency in RFC 8231 with an errata perhaps? And handle PCE= -initiated during AUTH48?

 

Also: s/PCE error message/PCErr= message/

[[[Dhruv Dhody]]] Ack

 

Section 7<= /u>

Nit: add comma after “acc= identally”

&n= bsp;

[[[Dhruv Dhody]]] Ok

 

Appendix A=

I think the text in this Append= ix could be clearer.  Here is my suggestion.

OLD

   Based on the feedback from the WG, i=
t was decided to focus only on
   the essentials in the scope of this =
documents.  For others,
   Experiments can use a new experiment=
al TLV/Object instead.

NEW

   Based on feedback from the PCE WG, i=
t was decided to allocate an
   Experimental code point range only i=
n the message, object and TLV
   sub-registries.  The justificat=
ion for this decision is that, if
   an experiment finds that it wants to=
 use a new code point in
   another PCEP sub-registry, it can im=
plement the same function using
   a new experimental object or TLV ins=
tead.

END

&n= bsp;

[[[Dhruv Dhody]]] Updat= ed

 

Other<= /p>

Please update reference draft-i= etf-pce-stateful-pce -> RFC 8231

Please update reference draft-i= etf-pce-pce-initiated-lsp-10 -> draft-ietf-pce-pce-initiated-lsp-11=

&n= bsp;

[[[Dhruv Dhody]]] Ack

 

Diff: https://tools.iet= f.org/rfcdiff?url2=3Dhttps://raw.githubusercontent.com/dhruvdhody-huawei/ie= tf/master/draft-ietf-pce-pcep-exp-codepoints-03.txt&url1=3Dhttps://www.= ietf.org/id/draft-ietf-pce-pcep-exp-codepoints-02.txt

 

Thanks for the review!<= o:p>

Regards,

Dhruv=

--_000_23CE718903A838468A8B325B80962F9B8D5C30A9BLREML503MBXchi_-- From nobody Sun Nov 12 16:08: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 2B3A41200C5; Sun, 12 Nov 2017 16:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_H4=-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 (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 mqor6wyjwaUk; Sun, 12 Nov 2017 16:08:07 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0104.outbound.protection.outlook.com [104.47.33.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EDCE124F57; Sun, 12 Nov 2017 16:08:05 -0800 (PST) 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=cIzEBw4fzv7jnXUcUES11BNvDVFuDZ3CuXlALJO6prQ=; b=I7RRRlb6T/jOsI0yeGIo9DRw45qNypvhNMgBoV8r25QSW2+VReHdkejT59Lcqag8fevPSOlYAfeDB48d+x2bftdiaOkgKLM4tyu4o8NfrvP99SE1aSeBgLSITemcA2PCJ77xT3p+pcR4d3vxH6WLVEjjKguzMCgky13o6/2EYX0= Received: from CY4PR0201MB3603.namprd02.prod.outlook.com (52.132.99.21) by CY4PR0201MB3603.namprd02.prod.outlook.com (52.132.99.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.12; Mon, 13 Nov 2017 00:08:03 +0000 Received: from CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::dce9:6773:68c7:10f3]) by CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::dce9:6773:68c7:10f3%13]) with mapi id 15.20.0218.011; Mon, 13 Nov 2017 00:08:03 +0000 From: Jonathan Hardwick To: Dhruv Dhody , "draft-ietf-pce-pcep-exp-codepoints@ietf.org" CC: "pce@ietf.org" , "pce-chairs@ietf.org" , 'Dhruv Dhody' Thread-Topic: Shepherd's review of draft-ietf-pce-pcep-exp-codepoints Thread-Index: AdNbazxoJX1mpJIUTGiD0iKyZXkw0wAQjYAAABhtNqA= Date: Mon, 13 Nov 2017 00:08:03 +0000 Message-ID: References: <23CE718903A838468A8B325B80962F9B8D5C30A9@BLREML503-MBX.china.huawei.com> In-Reply-To: <23CE718903A838468A8B325B80962F9B8D5C30A9@BLREML503-MBX.china.huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-originating-ip: [203.127.152.4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR0201MB3603; 6:YFY/5u3PCdgYSUHXymtC9inUAqNEOIBWhdoemrtsDi7jFmCuR2FIhkL7DvmG7mdLTAi2HJp8VC23D7haoA+4IbbMDx0Fm+8w6OW9isxCAa2rscb0oROQUIWTbaN4ioSJBJJoB/4vwtJArIn+K0ejaof9nkNdZd1oR5eHzL7zwtmGZyJclfx6UT2WeWQgvO24FjjL4hvy43SQx5dm5KKO7EHHhs/xgxTCYGQpk2RvJGQ1WSKtDR3e4RGcm3IGR3UAqnpuaqrzSajoYEKay874p6K2BW6kQ6FAdFLqQ8qW8e98HgrQIu7JVYCoXVY7puMS8w7DFoGNDZUmlBIG6WAc67/e0c3wyxtqNpNSfvOUwNg=; 5:6YoyTe+Dtks5VhBj/pIRxj4i7TwTCPNABklbkysh0SS45nhoPP7spQXWG0iD0+A6Fn6Y6iPniqIVtejItI6cTFj/cTskAbVAnyiICnwVtkKgdtJ1rxrHynSACrivmQ639P4UyW3raXhrYrTV/OC4+7kjVzQPjWCAz2HfihkCe4o=; 24:lf2D/oQQejK9ryvjcsG8xmV65LWuNepNFgSUxtnAUfMYMTfSpt/RYzlwBz6mN3R5gBVUfleNkVuuER2vHcg8fsE9btJjC3YOf1+j68qBcZM=; 7:atiYMuTP0fIe0lhAsEMOZKTTTljBDwbMLcN8h7hgerlczDh6IbyptlhEyjmA2ogbs6OdFC3orE3RhiLsKHhg6gFZ4ODOgyn7RMo/3goJ7J6HKltY500P3IF4keRNKIaqN4N1FrGH5Zcik9U7Qss1SQohTUn7d+7Hf/ruxHhmABgYrRZik3AaoVHwxYpJFmBwzQqkwNUEeT1NApbpEgX8FUQmySoF2Wx4NFAdmliJDw6CPekE5JpH5Chv/fCq3Tbc x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: a343cb1c-ea50-4359-25ff-08d52a2a9bfa x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:CY4PR0201MB3603; x-ms-traffictypediagnostic: CY4PR0201MB3603: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(3231022)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR0201MB3603; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR0201MB3603; x-forefront-prvs: 0490BBA1F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(189002)(199003)(76104003)(790700001)(3660700001)(2906002)(316002)(110136005)(86362001)(54906003)(106356001)(105586002)(6506006)(4326008)(3280700002)(7736002)(8936002)(81156014)(8676002)(81166006)(229853002)(6436002)(14454004)(2950100002)(3846002)(55016002)(102836003)(54896002)(66066001)(25786009)(6116002)(39060400002)(33656002)(6306002)(76176999)(50986999)(7696004)(5660300001)(9686003)(6246003)(2501003)(189998001)(53936002)(99286004)(72206003)(54356999)(478600001)(97736004)(2900100001)(5250100002)(68736007)(101416001)(230783001)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR0201MB3603; H:CY4PR0201MB3603.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR0201MB360311691273119057CF6339842B0CY4PR0201MB3603_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-Network-Message-Id: a343cb1c-ea50-4359-25ff-08d52a2a9bfa X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2017 00:08:03.5398 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0201MB3603 Archived-At: Subject: Re: [Pce] Shepherd's review of draft-ietf-pce-pcep-exp-codepoints 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, 13 Nov 2017 00:08:09 -0000 --_000_CY4PR0201MB360311691273119057CF6339842B0CY4PR0201MB3603_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dhruv Thanks for this. Trimming to the open points: Introduction The second paragraph is superfluous - I suggest deleting: Further, in order to support use cases described in [RFC8051], [I-D.ietf-pce-stateful-pce] specifies a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP. [I-D.ietf-pce-pce-initiated-lsp] describes the setup, maintenance and teardown of PCE-initiated LSPs under the stateful PCE model. [[[Dhruv Dhody]]] Because of the comment for handling the unknown experimen= tal objects for the stateful PCE messages, I think it is better to continue= to keep this text. What do you think? [Jon] Right - OK to leave it. But then I think these have to become normat= ive references. Section 5 The following paragraph does not tell the whole story. A PCE that does not recognize an experimental PCEP object, will reject the entire PCEP message and send a PCE error message with Error- Type=3D"Unknown Object" or "Not supported object" as described in [RFC5440]. If the P flag is clear in the object header, then the PCE MAY ignore the ob= ject instead of generating this error message. Also, you do not discuss wha= t a PCC would do on receipt of a PCUdp or PCInitiate containing an unrecogn= ised experimental object - it is inconsistent that you don't cover these ca= ses. (FWIW, RFC 8231 is a bit ambiguous about what a PCC should do about t= he PCUpd. Section 6.2 says that a PCErr should be sent, but then it refers = to section 7.3.3, which says that a PCRpt should be sent. Hmmm.) [[[Dhruv Dhody]]] Yes. How about I update to this - If the PCE does not understand or support an experimental object with the P flag set in the Object Header, in the Path Computation Request message (PCReq), the entire PCEP message is rejected and PCE responds with a PCErr message with Error-Type=3D"Unknown Object" or "Not supported object" as described in [RFC5440]. Otherwise the object is ignored. In case of stateful PCE messages [RFC8231], the P flag is ignored and the unknown object handling is as per the stateful PCE extensions. And let's try to handle the inconsistency in RFC 8231 with an errata perhap= s? And handle PCE-initiated during AUTH48? [Jon] I think this is OK, but if we are just going to point the reader at R= FC8231, then we might as well do the same with RFC5440, rather than duplica= te its text. And we should write something that allows for the possibility= that more message types may be relevant in future. How about If a PCEP speaker does not understand or support an experimental object then the way it handles this situation depends on the message type. For example, a PCE handles an unknown object in the Path Computation Req= uest (PCReq) message according to the rules of [RFC5440]. A PCC handles an unknown object in an Update (PCUpd) message according to the rules of [R= FC8231] and, in an LSP Initiate Request (PCInitiate) message, according to the r= ules of [I-D.ietf-pce-pce-initiated-lsp]. Any document that adds a new PCEP mes= sage type must specify how to handle unknown objects on that message. Note that this last sentence is not an RFC2119 MUST because it defines auth= or behaviour, not device behaviour. --_000_CY4PR0201MB360311691273119057CF6339842B0CY4PR0201MB3603_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dhruv

 

Thanks for this. = Trimming to the open points:

 

Introduction

 

The second paragraph is superfluous – I sugges= t deleting:

   Further, in order to support use cases described in [RFC8=
051],
   [I-D.ietf-pce-stateful-pce] specifies a set of extensions=
 to PCEP to
   enable stateful control of MPLS-TE and GMPLS LSPs via PCE=
P.
   [I-D.ietf-pce-pce-initiated-lsp] describes the setup, mai=
ntenance and
   teardown of PCE-initiated LSPs under the stateful PCE mod=
el.

 

[[[Dhruv Dhody]]] Because of the comme= nt for handling the unknown experimental objects for the stateful PCE messa= ges, I think it is better to continue to keep this text. What do you think?

 

[Jon] Right - OK to le= ave it.  But then I think these have to become normative references.

 

Section 5

 

The following paragraph does not tell the whole stor= y.

 

   A PCE that does no= t recognize an experimental PCEP object, will

   reject the entire = PCEP message and send a PCE error message with

   Error- Type=3D&quo= t;Unknown Object" or "Not supported object" as described

   in [RFC5440].=

 

If the P flag is clear in the object header, then th= e PCE MAY ignore the object instead of generating this error message. Also,= you do not discuss what a PCC would do on receipt of a PCUdp or PCInitiate= containing an unrecognised experimental object – it is inconsistent that you don’t cover these cases.&= nbsp; (FWIW, RFC 8231 is a bit ambiguous about what a PCC should do about t= he PCUpd. Section 6.2 says that a PCErr should be sent, but then it refers = to section 7.3.3, which says that a PCRpt should be sent. Hmmm.)

 

[[[Dhruv Dhody]]] Yes. How about I upd= ate to this –

 

   If = the PCE does not understand or support an experimental object with

   the= P flag set in the Object Header, in the Path Computation Request

   mes= sage (PCReq), the entire PCEP message is rejected and PCE responds

   wit= h a PCErr message with Error-Type=3D"Unknown Object" or "Not=

   sup= ported object" as described in [RFC5440].  Otherwise the object i= s

   ign= ored.  In case of stateful PCE messages [RFC8231], the P flag is<= /o:p>

   ign= ored and the unknown object handling is as per the stateful PCE<= /span>

   extensions.

 

And let’s try to handle the inco= nsistency in RFC 8231 with an errata perhaps? And handle PCE-initiated duri= ng AUTH48?

 

[Jon] I think this is OK, but if we ar= e just going to point the reader at RFC8231, then we might as well do the s= ame with RFC5440, rather than duplicate its text.  And we should write something that allows for the possibility that more me= ssage types may be relevant in future.  How about

 

   If = a PCEP speaker does not understand or support an experimental object

   the= n the way it handles this situation depends on the message type.=

   For= example, a PCE handles an unknown object in the Path Computation Request

   (PC= Req) message according to the rules of [RFC5440].  A PCC handles an

   unk= nown object in an Update (PCUpd) message according to the rules of [RFC8231= ]

   and= , in an LSP Initiate Request (PCInitiate) message, according to the rules o= f

   [I-= D.ietf-pce-pce-initiated-lsp].  Any document that adds a new PCEP mess= age

   typ= e must specify how to handle unknown objects on that message.

 

Note that this last sentence is not an= RFC2119 MUST because it defines author behaviour, not device behaviour.

--_000_CY4PR0201MB360311691273119057CF6339842B0CY4PR0201MB3603_-- From nobody Sun Nov 12 17:37:09 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 29BDF126CB6; Sun, 12 Nov 2017 17:37:03 -0800 (PST) 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.65.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151053702309.21478.14492169207819365119@ietfa.amsl.com> Date: Sun, 12 Nov 2017 17:37:03 -0800 Archived-At: Subject: [Pce] I-D Action: draft-ietf-pce-pcep-exp-codepoints-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: Mon, 13 Nov 2017 01:37:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : Experimental Codepoint Allocation for the Path Computation Element communication Protocol (PCEP) Authors : Dhruv Dhody Daniel King Adrian Farrel Filename : draft-ietf-pce-pcep-exp-codepoints-03.txt Pages : 7 Date : 2017-11-12 Abstract: IANA assigns values to the Path Computation Element (PCE) communication Protocol (PCEP) parameters (messages, objects, TLVs). IANA established a top-level registry to contain all PCEP codepoints and sub-registries. This top-level registry contains sub-registries for PCEP message, object and TLV types. The allocation policy for each of these sub-registries is IETF Review. This document updates RFC 5440 by changing the allocation policies for these three registries to mark some of the code points as assigned for Experimental Use. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-exp-codepoints/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-pcep-exp-codepoints-03 https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-exp-codepoints-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-exp-codepoints-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 Sun Nov 12 17:40: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 EFE15126CB6; Sun, 12 Nov 2017 17:40:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25rCVg7X4gHq; Sun, 12 Nov 2017 17:40:04 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1A0126D85; Sun, 12 Nov 2017 17:40:04 -0800 (PST) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id DD01D33396029; Mon, 13 Nov 2017 01:40:01 +0000 (GMT) Received: from BLREML406-HUB.china.huawei.com (10.20.4.43) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 13 Nov 2017 01:40:02 +0000 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.27]) by BLREML406-HUB.china.huawei.com ([10.20.4.43]) with mapi id 14.03.0361.001; Mon, 13 Nov 2017 07:09:52 +0530 From: Dhruv Dhody To: Jonathan Hardwick , "draft-ietf-pce-pcep-exp-codepoints@ietf.org" CC: "pce@ietf.org" , "pce-chairs@ietf.org" , 'Dhruv Dhody' Thread-Topic: Shepherd's review of draft-ietf-pce-pcep-exp-codepoints Thread-Index: AdNbazxoJX1mpJIUTGiD0iKyZXkw0wAQjYAAABhtNqAABE94kA== Date: Mon, 13 Nov 2017 01:39:51 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8D5C3537@BLREML503-MBX.china.huawei.com> References: <23CE718903A838468A8B325B80962F9B8D5C30A9@BLREML503-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.76.173] Content-Type: multipart/alternative; boundary="_000_23CE718903A838468A8B325B80962F9B8D5C3537BLREML503MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pce] Shepherd's review of draft-ietf-pce-pcep-exp-codepoints 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, 13 Nov 2017 01:40:06 -0000 --_000_23CE718903A838468A8B325B80962F9B8D5C3537BLREML503MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, Thanks for the suggested texts, I have made the update - https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-exp-codepoints/ https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-pcep-exp-codepoints-03 Thanks! Dhruv From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com] Sent: 13 November 2017 08:08 To: Dhruv Dhody ; draft-ietf-pce-pcep-exp-codepoint= s@ietf.org Cc: pce@ietf.org; pce-chairs@ietf.org; 'Dhruv Dhody' Subject: RE: Shepherd's review of draft-ietf-pce-pcep-exp-codepoints Hi Dhruv Thanks for this. Trimming to the open points: Introduction The second paragraph is superfluous - I suggest deleting: Further, in order to support use cases described in [RFC8051], [I-D.ietf-pce-stateful-pce] specifies a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP. [I-D.ietf-pce-pce-initiated-lsp] describes the setup, maintenance and teardown of PCE-initiated LSPs under the stateful PCE model. [[[Dhruv Dhody]]] Because of the comment for handling the unknown experimen= tal objects for the stateful PCE messages, I think it is better to continue= to keep this text. What do you think? [Jon] Right - OK to leave it. But then I think these have to become normat= ive references. Section 5 The following paragraph does not tell the whole story. A PCE that does not recognize an experimental PCEP object, will reject the entire PCEP message and send a PCE error message with Error- Type=3D"Unknown Object" or "Not supported object" as described in [RFC5440]. If the P flag is clear in the object header, then the PCE MAY ignore the ob= ject instead of generating this error message. Also, you do not discuss wha= t a PCC would do on receipt of a PCUdp or PCInitiate containing an unrecogn= ised experimental object - it is inconsistent that you don't cover these ca= ses. (FWIW, RFC 8231 is a bit ambiguous about what a PCC should do about t= he PCUpd. Section 6.2 says that a PCErr should be sent, but then it refers = to section 7.3.3, which says that a PCRpt should be sent. Hmmm.) [[[Dhruv Dhody]]] Yes. How about I update to this - If the PCE does not understand or support an experimental object with the P flag set in the Object Header, in the Path Computation Request message (PCReq), the entire PCEP message is rejected and PCE responds with a PCErr message with Error-Type=3D"Unknown Object" or "Not supported object" as described in [RFC5440]. Otherwise the object is ignored. In case of stateful PCE messages [RFC8231], the P flag is ignored and the unknown object handling is as per the stateful PCE extensions. And let's try to handle the inconsistency in RFC 8231 with an errata perhap= s? And handle PCE-initiated during AUTH48? [Jon] I think this is OK, but if we are just going to point the reader at R= FC8231, then we might as well do the same with RFC5440, rather than duplica= te its text. And we should write something that allows for the possibility= that more message types may be relevant in future. How about If a PCEP speaker does not understand or support an experimental object then the way it handles this situation depends on the message type. For example, a PCE handles an unknown object in the Path Computation Req= uest (PCReq) message according to the rules of [RFC5440]. A PCC handles an unknown object in an Update (PCUpd) message according to the rules of [R= FC8231] and, in an LSP Initiate Request (PCInitiate) message, according to the r= ules of [I-D.ietf-pce-pce-initiated-lsp]. Any document that adds a new PCEP mes= sage type must specify how to handle unknown objects on that message. Note that this last sentence is not an RFC2119 MUST because it defines auth= or behaviour, not device behaviour. --_000_23CE718903A838468A8B325B80962F9B8D5C3537BLREML503MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,

 

Thanks for the suggested texts, I have= made the update –

 

https://datatracker.ietf.org/doc/draft= -ietf-pce-pcep-exp-codepoints/

https://www.ietf.org/rfcdiff?url2=3Ddr= aft-ietf-pce-pcep-exp-codepoints-03

 

Thanks!

Dhruv

 

From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com]
Sent: 13 November 2017 08:08
To: Dhruv Dhody <dhruv.dhody@huawei.com>; draft-ietf-pce-pcep-= exp-codepoints@ietf.org
Cc: pce@ietf.org; pce-chairs@ietf.org; 'Dhruv Dhody' <dhruv.ietf@= gmail.com>
Subject: RE: Shepherd's review of draft-ietf-pce-pcep-exp-codepoints=

 

Hi Dhru= v

&n= bsp;

Thanks = for this.  Trimming to the open points:

&n= bsp;

Introduction

 

The second paragraph is superfl= uous – I suggest deleting:

   Further, in order to support use cas=
es described in [RFC8051],
   [I-D.ietf-pce-stateful-pce] specifie=
s a set of extensions to PCEP to
   enable stateful control of MPLS-TE a=
nd GMPLS LSPs via PCEP.
   [I-D.ietf-pce-pce-initiated-lsp] des=
cribes the setup, maintenance and
   teardown of PCE-initiated LSPs under=
 the stateful PCE model.

&n= bsp;

[[[Dhruv Dhody]]] Becau= se of the comment for handling the unknown experimental objects for the sta= teful PCE messages, I think it is better to continue to keep this text. What do you think?

 

[Jon] R= ight - OK to leave it.  But then I think these have to become normativ= e references.

 

Section 5<= /u>

 

The following paragraph does no= t tell the whole story.

 

   A P= CE that does not recognize an experimental PCEP object, will

   rej= ect the entire PCEP message and send a PCE error message with

   Err= or- Type=3D"Unknown Object" or "Not supported object" a= s described

   in = [RFC5440].

 

If the P flag is clear in the o= bject header, then the PCE MAY ignore the object instead of generating this= error message. Also, you do not discuss what a PCC would do on receipt of = a PCUdp or PCInitiate containing an unrecognised experimental object – it is inconsistent that you don&#= 8217;t cover these cases.  (FWIW, RFC 8231 is a bit ambiguous about wh= at a PCC should do about the PCUpd. Section 6.2 says that a PCErr should be= sent, but then it refers to section 7.3.3, which says that a PCRpt should be sent. Hmmm.)

&n= bsp;

[[[Dhruv Dhody]]] Yes. = How about I update to this –

 

&= nbsp;  If the PCE does not understand or support an experimental objec= t with

&= nbsp;  the P flag set in the Object Header, in the Path Computation Re= quest

&= nbsp;  message (PCReq), the entire PCEP message is rejected and PCE re= sponds

&= nbsp;  with a PCErr message with Error-Type=3D"Unknown Object&quo= t; or "Not

&= nbsp;  supported object" as described in [RFC5440].  Otherwi= se the object is

&= nbsp;  ignored.  In case of stateful PCE messages [RFC8231], the = P flag is

&= nbsp;  ignored and the unknown object handling is as per the stateful = PCE

   extensions.=

 

And let’s try to = handle the inconsistency in RFC 8231 with an errata perhaps? And handle PCE= -initiated during AUTH48?

 

[Jon] I think this is O= K, but if we are just going to point the reader at RFC8231, then we might a= s well do the same with RFC5440, rather than duplicate its text.  And we should write something that allows for the possibil= ity that more message types may be relevant in future.  How about=

 

&= nbsp;  If a PCEP speaker does not understand or support an experimenta= l object

&= nbsp;  then the way it handles this situation depends on the message t= ype.

&= nbsp;  For example, a PCE handles an unknown object in the Path Comput= ation Request

&= nbsp;  (PCReq) message according to the rules of [RFC5440].  A PC= C handles an

&= nbsp;  unknown object in an Update (PCUpd) message according to the ru= les of [RFC8231]

&= nbsp;  and, in an LSP Initiate Request (PCInitiate) message, according= to the rules of

&= nbsp;  [I-D.ietf-pce-pce-initiated-lsp].  Any document that adds = a new PCEP message

&= nbsp;  type must specify how to handle unknown objects on that message= .

 

Note that this last sen= tence is not an RFC2119 MUST because it defines author behaviour, not devic= e behaviour.

--_000_23CE718903A838468A8B325B80962F9B8D5C3537BLREML503MBXchi_-- From nobody Sun Nov 12 22:58:04 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 30BD812008A; Sun, 12 Nov 2017 22:58:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Jonathan Hardwick To: X-Test-IDTracker: no X-IETF-IDTracker: 6.65.1 Auto-Submitted: auto-generated Precedence: bulk Cc: jonathan.hardwick@metaswitch.com, iesg-secretary@ietf.org, Jonathan Hardwick , pce@ietf.org, pce-chairs@ietf.org Message-ID: <151055628219.21482.14056856818222105009.idtracker@ietfa.amsl.com> Date: Sun, 12 Nov 2017 22:58:02 -0800 Archived-At: Subject: [Pce] Publication has been requested for draft-ietf-pce-pcep-exp-codepoints-03 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, 13 Nov 2017 06:58:02 -0000 Jonathan Hardwick has requested publication of draft-ietf-pce-pcep-exp-codepoints-03 as Proposed Standard on behalf of the PCE working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-exp-codepoints/ From nobody Mon Nov 13 00: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 1D73412773A for ; Mon, 13 Nov 2017 00:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 nZmwMSV2THr4 for ; Mon, 13 Nov 2017 00:22:21 -0800 (PST) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 158E4126B6E for ; Mon, 13 Nov 2017 00:22:20 -0800 (PST) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id EDB1C1201D3 for ; Mon, 13 Nov 2017 09:22:18 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.2]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id CE86840062 for ; Mon, 13 Nov 2017 09:22:18 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0361.001; Mon, 13 Nov 2017 09:22:18 +0100 From: To: "pce@ietf.org" Thread-Topic: draft-ietf-pce-association-diversity: relaxing constraint Thread-Index: AdNcVzD/M9KOzAxBQO6wN/0nS1cgMg== Date: Mon, 13 Nov 2017 08:22:18 +0000 Message-ID: <7688_1510561338_5A09563A_7688_271_1_9E32478DFA9976438E7A22F69B08FF921EABBDF1@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/related; boundary="_004_9E32478DFA9976438E7A22F69B08FF921EABBDF1OPEXCLILMA4corp_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: [Pce] draft-ietf-pce-association-diversity: relaxing constraint 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, 13 Nov 2017 08:22:29 -0000 --_004_9E32478DFA9976438E7A22F69B08FF921EABBDF1OPEXCLILMA4corp_ Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF921EABBDF1OPEXCLILMA4corp_" --_000_9E32478DFA9976438E7A22F69B08FF921EABBDF1OPEXCLILMA4corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi WG, In the latest version of draft-ietf-pce-association-diversity we added a ne= w TLV called RELAXED-CONSTRAINT-TLV to be used in LSP Object of a PCUpdate = message when the PCE relaxes the requested disjointness constraint. For ins= tance, if a PCC requests an SRLG disjoint path but the PCE cannot find it, = it may relax the constraint (if PCC allows it to do so) and thus informs th= e PCC through the RELAXED-CONSTRAINT-TLV. IMO, this kind of behavior is more generic rather tied to the disjointness = use case. It may be used with other constraints as well. The question is: do we need to keep this RELAXED-CONSTRAINT-TLV in the asso= ciation-diversity draft ? or do we drop it ? or do we define a TLV more spe= cific to the association diversity state ? maybe we can reuse the associati= on group object in the PCUpdate message including the DISJOINTNESS-INFORMAT= ION-TLV which reflects the actual disjointness style used by the PCE. Opinions ? Brgds, Stephane [Orange logo] Stephane Litkowski Network Architect Orange/SCE/EQUANT/OINIS/NET Orange Expert Future Networks phone: +33 2 23 06 49 83 NEW ! mobile: +33 6 71 63 27 50 NEW ! stephane.litkowski@orange.com ___________________________________________________________________________= ______________________________________________ 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. --_000_9E32478DFA9976438E7A22F69B08FF921EABBDF1OPEXCLILMA4corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi WG,

 

In the latest version of draft-ietf-pce-association-= diversity we added a new TLV called RELAXED-CONSTRAINT-TLV to be used in LS= P Object of a PCUpdate message when the PCE relaxes the requested disjointn= ess constraint. For instance, if a PCC requests an SRLG disjoint path but the PCE cannot find it, it may rela= x the constraint (if PCC allows it to do so) and thus informs the PCC throu= gh the RELAXED-CONSTRAINT-TLV.

 

IMO, this kind of behavior is more generic rather ti= ed to the disjointness use case. It may be used with other constraints as w= ell.

 

The question is: do we need to keep this RELAXED-CON= STRAINT-TLV in the association-diversity draft ? or do we drop it ? or do w= e define a TLV more specific to the association diversity state ? maybe we = can reuse the association group object in the PCUpdate message including the DISJOINTNESS-INFORMATION-TLV which r= eflects the actual disjointness style used by the PCE.

 

Opinions ?

 

 

Brgds,

 

Stephane

 

 

3D"O=

 <= o:p>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET

Orange Expert Fut= ure Networks

phone: +33 2 23 06 49 83  N= EW !
mobile: +33 6 71 63 27 50  NEW = ;!
s= tephane.litkowski@orange.com

 

______________________________________________________________________=
___________________________________________________

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.
--_000_9E32478DFA9976438E7A22F69B08FF921EABBDF1OPEXCLILMA4corp_-- --_004_9E32478DFA9976438E7A22F69B08FF921EABBDF1OPEXCLILMA4corp_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=1093; creation-date="Mon, 13 Nov 2017 08:22:17 GMT"; modification-date="Mon, 13 Nov 2017 08:22:17 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAAoACgDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD1O48f afbXMsDWl0WjcoSAuDg49aj/AOFiad/z53f5L/jXB6r/AMhe9/67v/M1Ur5Geb4pSaTX3H2dPJcJ KCbT+89H/wCFiad/z53f5L/jR/wsTTv+fO7/ACX/ABrziip/tnFd19xX9iYPs/vPR/8AhYmnf8+d 3+S/40V5xRR/bOK7r7g/sTB9n95b1X/kL3v/AF3f+ZqpW3Po17qGo3s0Cx7DdPGpeQLvbOdq56mo R4d1EmEFYVaZdyI0oDY9cda450KspNqLO2niKUYJOSvbv5GVRWwPC+qmR4zFErI/l4aUDc2A2B68 GmDw7qTQrIIkJZVYR+YN+GOAdvuan6tW/lf3FfWqH86+8yqK2bjQG0+EvqU/2dmyIgieYGI6gkHg 0VM6M4O0tGVCtCavF3R1o8Oa7BcTtbXdh5TztPGJYyxjY9xxwcUxfDniNZ1m+32DOIPs+WjJymc8 8dc96KK+y/s+l3f3s+J/tKt2X3Ie+geJZJlla/0/eswmH7s/eChfT0FXDo2rDTRCktoLoIqfaCxy NrZGPlz+GaKKpYGmr6vXzJlj6sraLTyMrUPCOuant+03lh8pJ+RGXJPUniiiisZ5Thpvmldv1N4Z xioLljZL0R//2Q== --_004_9E32478DFA9976438E7A22F69B08FF921EABBDF1OPEXCLILMA4corp_-- From nobody Mon Nov 13 00:33: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 7138C126B6E for ; Mon, 13 Nov 2017 00:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 IPvtuHVriJPx for ; Mon, 13 Nov 2017 00:33:28 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 E6EBC129535 for ; Mon, 13 Nov 2017 00:33:27 -0800 (PST) X-AuditID: c1b4fb25-1763d9c0000020f7-60-5a0958d64a8a Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E3.E9.08439.6D8590A5; Mon, 13 Nov 2017 09:33:26 +0100 (CET) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.21) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 13 Nov 2017 09:33:25 +0100 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=fq1Fb3qOSLhOkPRm/KtSpbPGl5hlQONPQvbiAZrVw/4=; b=dRTHLb7Nqx7qIhvZ7qpGXKNQkqH4MNyp8gIXN1Va+4sYKn3P1r2xGe+0EJGzVYM8mAExbv21pxRLDMaBotnl8P0CYlVdsggzLnzmRLomaZZqzCkoBoo0USbzIGEmQdeembOwuZXhepnvh8rK3Q9W+CSwjHF0J35y/c5MKaNe47E= Received: from HE1PR0701MB2714.eurprd07.prod.outlook.com (10.168.188.21) by HE1PR0701MB2714.eurprd07.prod.outlook.com (10.168.188.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Mon, 13 Nov 2017 08:33:24 +0000 Received: from HE1PR0701MB2714.eurprd07.prod.outlook.com ([fe80::c589:4ca7:2dae:5fa1]) by HE1PR0701MB2714.eurprd07.prod.outlook.com ([fe80::c589:4ca7:2dae:5fa1%16]) with mapi id 15.20.0239.004; Mon, 13 Nov 2017 08:33:24 +0000 From: Daniele Ceccarelli To: "stephane.litkowski@orange.com" , "pce@ietf.org" Thread-Topic: draft-ietf-pce-association-diversity: relaxing constraint Thread-Index: AdNcVzD/M9KOzAxBQO6wN/0nS1cgMgAAiaaQ Date: Mon, 13 Nov 2017 08:33:24 +0000 Message-ID: References: <7688_1510561338_5A09563A_7688_271_1_9E32478DFA9976438E7A22F69B08FF921EABBDF1@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: <7688_1510561338_5A09563A_7688_271_1_9E32478DFA9976438E7A22F69B08FF921EABBDF1@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com; x-originating-ip: [31.133.131.147] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2714; 6:w4IF2Q3vFJ6gxjBxph99vbW3F6se58o/iEuCG8yLU7jeRcAOvZIGK9fZaWKRbaYHqeuxGmT+5O0SF0uWarW1rPfWx5l1wFJUwIX/YGmz8hmXWEKhxKbrxofdJ7TXY89tKaL1SYQdZI67uLLTYUkRfRDkL3mRwh2TgJVyl58gFhZkrFL/S1jSZ0j5CCcuevs1PsDhY77AWMSmKUWdivdo7atFhMDI4l8JEue9VKs6SgFNljiUciQ4rYJFczE68X8vjgUPVg9HVlDAlrycvftQys7jo/PG88Ni7LrmKqbuX3Avkfr52h20WlEApqdRhSHhBU0roM3FxXr8ngs9bY28YbeRr1XaMHMyGjns+Up3pKk=; 5:hT7uIUEpVJRR4U/hysA5vV7ep+ZzBQnqBGsgKeXDKksYifFEnIzW6FUpZ2oDUBY8U1j2dHjdGbHKvypKELh8lq6MPZgz4tCU2iQGMv44U39NWQBJovmQjIUzrLcDhRlCWp+/n463fnuBtW4DTaFCVMhgWJ0TF+d7tDv7CN9mZUg=; 24:i7E6ZvsMfe0BbVMJV3vN+oDJAdQSVsPxr4gDv8CV+RKG1FxVg2bTRBCXHcw3asRy/6k/FRBSwcTvZAF00BF2XvNH/v4IofS32FmATiFBbtY=; 7:MDCSsImMATSii8RMcr+jTyVimoisK+oglDL9XWBLd1LttaU7YMB3YGcegT8U6qNlDkPJJ/W2nHwnmooxACeQ8Y7jlWgzI3q4OF2mcNyEg+69Ye4vInTlQfIBJpHST0im4EWDuQ/kkMxAO3tApjlm0ywTuz8g2APvtKkTdlf9K3KInhYbxCSOmVG0Q+EOhtMBVqmzMR0Wrbtzcqbh3War94o/lO282AubdrA4cnzu/5kEaPO2ZPIm3KaZgL9qM44x x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: b3ac0abc-e6f3-4cbd-8bf0-08d52a7134af x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258)(49563074); SRVR:HE1PR0701MB2714; x-ms-traffictypediagnostic: HE1PR0701MB2714: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(115448073456579)(81850148713716)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(5005006)(8121501046)(3002001)(3231022)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123564025)(20161123558100)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR0701MB2714; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR0701MB2714; x-forefront-prvs: 0490BBA1F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39860400002)(57704003)(189002)(199003)(2900100001)(6436002)(106356001)(5660300001)(189998001)(7736002)(8936002)(105586002)(110136005)(97736004)(53546010)(606006)(7696004)(8676002)(81166006)(14454004)(733005)(316002)(81156014)(66066001)(2501003)(229853002)(99286004)(6506006)(74316002)(2906002)(6306002)(55016002)(790700001)(54556002)(230783001)(86362001)(3280700002)(53936002)(6116002)(3660700001)(3846002)(102836003)(101416001)(2950100002)(5890100001)(6246003)(54896002)(478600001)(9686003)(54356999)(76176999)(5250100002)(236005)(68736007)(25786009)(50986999)(99936001)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2714; H:HE1PR0701MB2714.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/related; boundary="_004_HE1PR0701MB27143A67E2957A703161E6E3F02B0HE1PR0701MB2714_"; type="multipart/alternative" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b3ac0abc-e6f3-4cbd-8bf0-08d52a7134af X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2017 08:33:24.4665 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2714 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA22SfyyUcRzH+97z3D3PyW1f11kfSltX1oouHZWsKX9UVFraKtNaTp5hdGf3 YFh/YFg55kf6gRZy2FQ0VJrRujM/Kv0cqWwlQklqocOoe3yv1h/99/p83j+++2xflpL/Ejuz Udo4Tq/VxCgldnRR8F3Hjb3B0hCPvEmZd9q7PsZ7qmVAvEvkbzTOiPzTh7skh0QhdjvCuZio BE6/yTfULvJnfgcT22hAiY1DlSgFfT+ThaQsYC+YaRgQZyE7Vo7NCMb6M21DJwJLxT1GGGic Q8HZnA5GiMhxsQjKpjyIawSBufIHlYVYVoJ9YMh0QPAocDgUPG6mBF6G98DEQ5JV4L1gHD1H E1bDxUmLSGAau8JIxY3FGhkOhYv120l9BoLx+fRFjxRnIiiqSxYYYRfIa76GBKbwcngzVCoi 5yhg4PkjCWFH+DS4ICb+MKjLaLJ5lHCluIki7AIvSg1IeAxwGwOFb6ttggpu548jwoEw0Tpu 21ciGH11kLA7ZN8sYQjr4Km5U0w4GnKzx2ylg2LobOiwhVfCYG8+Q4RCCbQvzEvykHvxP1cU WzUKGxC8LpujBEGGHaCraIgmJh00W0wiwirou1AoIewGVeVjFOGNcHnBRP9vfymvzZZdDSXV nxFh60X9uasJu8NVU91fT6FhgClDshrkyHN82OkItaeK00ed4nmdVqXl4uqR9Ss+aJxzbUIv v/iZEGaR0l62L1AaIhdrEvik0ya01trz4db1Z8iZ1uq0nFIhS9tvlWXhmqRkTq87qY+P4XgT WsHSyuUyv9ZnwXIcoYnjojkultP/UUWs1DkFucUdbw04UjOcOitpufJk69J9c57dx5yaLcZ2 c7fvYKR9qOd0TK5P7arUWuctAVcdOs/P3nHzLlc5VSkm9UGJPSlr5E3MOodpj+HKbWZjj999 2vXrwuG+j76aE/FLStVHg3bnTPDRJeFeSR3f7qtfqyfer1EErmcN6aWjloJ6VcNOJc1HajZv oPS85jeNdzk2kgMAAA== Archived-At: Subject: Re: [Pce] draft-ietf-pce-association-diversity: relaxing constraint 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, 13 Nov 2017 08:33:30 -0000 --_004_HE1PR0701MB27143A67E2957A703161E6E3F02B0HE1PR0701MB2714_ Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB27143A67E2957A703161E6E3F02B0HE1PR0701MB2714_" --_000_HE1PR0701MB27143A67E2957A703161E6E3F02B0HE1PR0701MB2714_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Stephane, definitely needed. My opinion is that a way to say that a constraint was relaxed is very usefu= l. As you said there are different types of constraints that can be relaxed= , e.g. diversity or a TE bound. I would make the TLV as generic as possible and maybe define multiple sub-T= LV (or maybe just multiple values) depending on the constraint that was rel= axed. BR Daniele From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of stephane.litkowski@ora= nge.com Sent: luned=EC 13 novembre 2017 16:22 To: pce@ietf.org Subject: [Pce] draft-ietf-pce-association-diversity: relaxing constraint Hi WG, In the latest version of draft-ietf-pce-association-diversity we added a ne= w TLV called RELAXED-CONSTRAINT-TLV to be used in LSP Object of a PCUpdate = message when the PCE relaxes the requested disjointness constraint. For ins= tance, if a PCC requests an SRLG disjoint path but the PCE cannot find it, = it may relax the constraint (if PCC allows it to do so) and thus informs th= e PCC through the RELAXED-CONSTRAINT-TLV. IMO, this kind of behavior is more generic rather tied to the disjointness = use case. It may be used with other constraints as well. The question is: do we need to keep this RELAXED-CONSTRAINT-TLV in the asso= ciation-diversity draft ? or do we drop it ? or do we define a TLV more spe= cific to the association diversity state ? maybe we can reuse the associati= on group object in the PCUpdate message including the DISJOINTNESS-INFORMAT= ION-TLV which reflects the actual disjointness style used by the PCE. Opinions ? Brgds, Stephane [Orange logo] Stephane Litkowski Network Architect Orange/SCE/EQUANT/OINIS/NET Orange Expert Future Networks phone: +33 2 23 06 49 83 NEW ! mobile: +33 6 71 63 27 50 NEW ! stephane.litkowski@orange.com ___________________________________________________________________________= ______________________________________________ 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. --_000_HE1PR0701MB27143A67E2957A703161E6E3F02B0HE1PR0701MB2714_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Stepha= ne,

&nbs= p;

definitely needed.

My opinion is that a way to say that a constraint was relaxed is very= useful. As you said there are different types of constraints that can be r= elaxed, e.g. diversity or a TE bound.

I would make the TLV as generic as possible and maybe define multiple= sub-TLV (or maybe just multiple values) depending on the constraint that w= as relaxed.

 

BR
Daniele 

 

From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of stephane.litkowski@orange.com
Sent: luned=EC 13 novembre 2017 16:22
To: pce@ietf.org
Subject: [Pce] draft-ietf-pce-association-diversity: relaxing constr= aint

 

Hi WG,

 

In the latest version of draft-= ietf-pce-association-diversity we added a new TLV called RELAXED-CONSTRAINT= -TLV to be used in LSP Object of a PCUpdate message when the PCE relaxes th= e requested disjointness constraint. For instance, if a PCC requests an SRLG disjoint path but the PCE cannot f= ind it, it may relax the constraint (if PCC allows it to do so) and thus in= forms the PCC through the RELAXED-CONSTRAINT-TLV.

 

IMO, this kind of behavior is m= ore generic rather tied to the disjointness use case. It may be used with o= ther constraints as well.

 

The question is: do we need to = keep this RELAXED-CONSTRAINT-TLV in the association-diversity draft ? or do= we drop it ? or do we define a TLV more specific to the association divers= ity state ? maybe we can reuse the association group object in the PCUpdate message including the DISJOINTNESS-INFORMATIO= N-TLV which reflects the actual disjointness style used by the PCE.

 

Opinions ?

 

 

Brgds,

 

Stephane

 

 

3D"Orange

&nbs= p;

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET

Orange Expert Future Networks=

phone: +33 2 23 06 49 83  N= EW !
mobile: +33 6 71 63 27 50  NEW = ;!
stephane.litk= owski@orange.com

 

_________________________________________________=
________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir=
 des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler=

a l'expediteur et le detruire ainsi que les piece=
s jointes. Les messages electroniques etant susceptibles d'alteration,=

Orange decline toute responsabilite si ce message=
 a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain conf=
idential or privileged information that may be protected by law;=

they should not be distributed, used or copied wi=
thout authorisation.
If you have received this email in error, please =
notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable fo=
r messages that have been modified, changed or falsified.=

Thank you.
--_000_HE1PR0701MB27143A67E2957A703161E6E3F02B0HE1PR0701MB2714_-- --_004_HE1PR0701MB27143A67E2957A703161E6E3F02B0HE1PR0701MB2714_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=1093; creation-date="Mon, 13 Nov 2017 08:33:22 GMT"; modification-date="Mon, 13 Nov 2017 08:33:22 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAAoACgDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD1O48f afbXMsDWl0WjcoSAuDg49aj/AOFiad/z53f5L/jXB6r/AMhe9/67v/M1Ur5Geb4pSaTX3H2dPJcJ KCbT+89H/wCFiad/z53f5L/jR/wsTTv+fO7/ACX/ABrziip/tnFd19xX9iYPs/vPR/8AhYmnf8+d 3+S/40V5xRR/bOK7r7g/sTB9n95b1X/kL3v/AF3f+ZqpW3Po17qGo3s0Cx7DdPGpeQLvbOdq56mo R4d1EmEFYVaZdyI0oDY9cda450KspNqLO2niKUYJOSvbv5GVRWwPC+qmR4zFErI/l4aUDc2A2B68 GmDw7qTQrIIkJZVYR+YN+GOAdvuan6tW/lf3FfWqH86+8yqK2bjQG0+EvqU/2dmyIgieYGI6gkHg 0VM6M4O0tGVCtCavF3R1o8Oa7BcTtbXdh5TztPGJYyxjY9xxwcUxfDniNZ1m+32DOIPs+WjJymc8 8dc96KK+y/s+l3f3s+J/tKt2X3Ie+geJZJlla/0/eswmH7s/eChfT0FXDo2rDTRCktoLoIqfaCxy NrZGPlz+GaKKpYGmr6vXzJlj6sraLTyMrUPCOuant+03lh8pJ+RGXJPUniiiisZ5Thpvmldv1N4Z xioLljZL0R//2Q== --_004_HE1PR0701MB27143A67E2957A703161E6E3F02B0HE1PR0701MB2714_-- From nobody Mon Nov 13 00:40: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 EDFF8126DED for ; Mon, 13 Nov 2017 00:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 VxNI8yKagRzz for ; Mon, 13 Nov 2017 00:40:45 -0800 (PST) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAE2B126B6E for ; Mon, 13 Nov 2017 00:40:44 -0800 (PST) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 798E41209D9; Mon, 13 Nov 2017 09:40:43 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.62]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 5AA6BC0067; Mon, 13 Nov 2017 09:40:43 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM5E.corporate.adroot.infra.ftgroup ([fe80::2912:bfa5:91d3:bf63%18]) with mapi id 14.03.0361.001; Mon, 13 Nov 2017 09:40:42 +0100 From: To: Daniele Ceccarelli , "pce@ietf.org" Thread-Topic: draft-ietf-pce-association-diversity: relaxing constraint Thread-Index: AdNcVzD/M9KOzAxBQO6wN/0nS1cgMgAAiaaQAABEwvA= Date: Mon, 13 Nov 2017 08:40:41 +0000 Message-ID: <2637_1510562443_5A095A8B_2637_480_1_9E32478DFA9976438E7A22F69B08FF921EABBE39@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <7688_1510561338_5A09563A_7688_271_1_9E32478DFA9976438E7A22F69B08FF921EABBDF1@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/related; boundary="_004_9E32478DFA9976438E7A22F69B08FF921EABBE39OPEXCLILMA4corp_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: Re: [Pce] draft-ietf-pce-association-diversity: relaxing constraint 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, 13 Nov 2017 08:40:47 -0000 --_004_9E32478DFA9976438E7A22F69B08FF921EABBE39OPEXCLILMA4corp_ Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF921EABBE39OPEXCLILMA4corp_" --_000_9E32478DFA9976438E7A22F69B08FF921EABBE39OPEXCLILMA4corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Daniele, Thanks for your feedback. If we go to a generic mechanism, IMO, this should be addressed in a separat= e document. In addition, we need a generic way for a PCC to tell the PCE th= at a constraint is relaxable or strict. For diversity, we have a dedicated = flag within the DISJOINTNESS TLV for that purpose. Maybe we should make it = generic as well. Do you agree ? Brgds, From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Monday, November 13, 2017 16:33 To: LITKOWSKI Stephane OBS/OINIS; pce@ietf.org Subject: RE: draft-ietf-pce-association-diversity: relaxing constraint Hi Stephane, definitely needed. My opinion is that a way to say that a constraint was relaxed is very usefu= l. As you said there are different types of constraints that can be relaxed= , e.g. diversity or a TE bound. I would make the TLV as generic as possible and maybe define multiple sub-T= LV (or maybe just multiple values) depending on the constraint that was rel= axed. BR Daniele From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of stephane.litkowski@ora= nge.com Sent: luned=EC 13 novembre 2017 16:22 To: pce@ietf.org Subject: [Pce] draft-ietf-pce-association-diversity: relaxing constraint Hi WG, In the latest version of draft-ietf-pce-association-diversity we added a ne= w TLV called RELAXED-CONSTRAINT-TLV to be used in LSP Object of a PCUpdate = message when the PCE relaxes the requested disjointness constraint. For ins= tance, if a PCC requests an SRLG disjoint path but the PCE cannot find it, = it may relax the constraint (if PCC allows it to do so) and thus informs th= e PCC through the RELAXED-CONSTRAINT-TLV. IMO, this kind of behavior is more generic rather tied to the disjointness = use case. It may be used with other constraints as well. The question is: do we need to keep this RELAXED-CONSTRAINT-TLV in the asso= ciation-diversity draft ? or do we drop it ? or do we define a TLV more spe= cific to the association diversity state ? maybe we can reuse the associati= on group object in the PCUpdate message including the DISJOINTNESS-INFORMAT= ION-TLV which reflects the actual disjointness style used by the PCE. Opinions ? Brgds, Stephane [Orange logo] Stephane Litkowski Network Architect Orange/SCE/EQUANT/OINIS/NET Orange Expert Future Networks phone: +33 2 23 06 49 83 NEW ! mobile: +33 6 71 63 27 50 NEW ! stephane.litkowski@orange.com ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. --_000_9E32478DFA9976438E7A22F69B08FF921EABBE39OPEXCLILMA4corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Daniele,=

 

Thanks for your feedba= ck.

If we go to a generic = mechanism, IMO, this should be addressed in a separate document. In additio= n, we need a generic way for a PCC to tell the PCE that a constraint is rel= axable or strict. For diversity, we have a dedicated flag within the DISJOINTNESS TLV for that purpose. Maybe = we should make it generic as well.

 

Do you agree ?

 

Brgds,

 

 

From: Daniele = Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Monday, November 13, 2017 16:33
To: LITKOWSKI Stephane OBS/OINIS; pce@ietf.org
Subject: RE: draft-ietf-pce-association-diversity: relaxing constrai= nt

 

Hi Stephane,

 

definitely needed.

My opinion is that a way to say that a constraint wa= s relaxed is very useful. As you said there are different types of constrai= nts that can be relaxed, e.g. diversity or a TE bound.

I would make the TLV as generic as possible and mayb= e define multiple sub-TLV (or maybe just multiple values) depending on the = constraint that was relaxed.

 

BR
Daniele 

 

From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of stepha= ne.litkowski@orange.com
Sent: luned=EC 13 novembre 2017 16:22
To: pce@ietf.org
Subject: [Pce] draft-ietf-pce-association-diversity: relaxing constr= aint

 

Hi WG,

 

In the latest version of draft-ietf-pce-association-= diversity we added a new TLV called RELAXED-CONSTRAINT-TLV to be used in LS= P Object of a PCUpdate message when the PCE relaxes the requested disjointn= ess constraint. For instance, if a PCC requests an SRLG disjoint path but the PCE cannot find it, it may rela= x the constraint (if PCC allows it to do so) and thus informs the PCC throu= gh the RELAXED-CONSTRAINT-TLV.

 

IMO, this kind of behavior is more generic rather ti= ed to the disjointness use case. It may be used with other constraints as w= ell.

 

The question is: do we need to keep this RELAXED-CON= STRAINT-TLV in the association-diversity draft ? or do we drop it ? or do w= e define a TLV more specific to the association diversity state ? maybe we = can reuse the association group object in the PCUpdate message including the DISJOINTNESS-INFORMATION-TLV which r= eflects the actual disjointness style used by the PCE.

 

Opinions ?

 

 

Brgds,

 

Stephane

 

 

3D"Orange

 <= o:p>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET

Orange Expert Fut= ure Networks

phone: +33 2 23 06 49 83  N= EW !
mobile: +33 6 71 63 27 50  NEW = ;!
s= tephane.litkowski@orange.com

 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________

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.
--_000_9E32478DFA9976438E7A22F69B08FF921EABBE39OPEXCLILMA4corp_-- --_004_9E32478DFA9976438E7A22F69B08FF921EABBE39OPEXCLILMA4corp_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=1093; creation-date="Mon, 13 Nov 2017 08:40:39 GMT"; modification-date="Mon, 13 Nov 2017 08:40:39 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAAoACgDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD1O48f afbXMsDWl0WjcoSAuDg49aj/AOFiad/z53f5L/jXB6r/AMhe9/67v/M1Ur5Geb4pSaTX3H2dPJcJ KCbT+89H/wCFiad/z53f5L/jR/wsTTv+fO7/ACX/ABrziip/tnFd19xX9iYPs/vPR/8AhYmnf8+d 3+S/40V5xRR/bOK7r7g/sTB9n95b1X/kL3v/AF3f+ZqpW3Po17qGo3s0Cx7DdPGpeQLvbOdq56mo R4d1EmEFYVaZdyI0oDY9cda450KspNqLO2niKUYJOSvbv5GVRWwPC+qmR4zFErI/l4aUDc2A2B68 GmDw7qTQrIIkJZVYR+YN+GOAdvuan6tW/lf3FfWqH86+8yqK2bjQG0+EvqU/2dmyIgieYGI6gkHg 0VM6M4O0tGVCtCavF3R1o8Oa7BcTtbXdh5TztPGJYyxjY9xxwcUxfDniNZ1m+32DOIPs+WjJymc8 8dc96KK+y/s+l3f3s+J/tKt2X3Ie+geJZJlla/0/eswmH7s/eChfT0FXDo2rDTRCktoLoIqfaCxy NrZGPlz+GaKKpYGmr6vXzJlj6sraLTyMrUPCOuant+03lh8pJ+RGXJPUniiiisZ5Thpvmldv1N4Z xioLljZL0R//2Q== --_004_9E32478DFA9976438E7A22F69B08FF921EABBE39OPEXCLILMA4corp_-- From nobody Mon Nov 13 00:42:42 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 1645E129457 for ; Mon, 13 Nov 2017 00:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-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 vwwqzeKKgfZ7 for ; Mon, 13 Nov 2017 00:42:39 -0800 (PST) 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 58F89126B6E for ; Mon, 13 Nov 2017 00:42:38 -0800 (PST) X-AuditID: c1b4fb3a-c73ff70000004c48-04-5a095afc4650 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 46.E0.19528.CFA590A5; Mon, 13 Nov 2017 09:42:36 +0100 (CET) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.57) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 13 Nov 2017 09:42:35 +0100 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=xfkMJ5uSQwZBzJE9w3DVBY7jEk2txIsPqvSKNOWRr0g=; b=eIE6Yd1BpSPv2F71DvEGIf/YFOdwQUJnG1YpWAS8KGWUFsQtXn+sInwduz2TSfOcTuI+EHJR3wuZJ3te6CNFmbv66IOa0sMzva2DTJGP0xfv+SwMDmz/lYFQygH+QmroJ838hvEEmL4glGcRyUgTw5WwM/+C8pplQQP5650Lok0= Received: from HE1PR0701MB2714.eurprd07.prod.outlook.com (10.168.188.21) by HE1PR0701MB2715.eurprd07.prod.outlook.com (10.168.188.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.4; Mon, 13 Nov 2017 08:42:34 +0000 Received: from HE1PR0701MB2714.eurprd07.prod.outlook.com ([fe80::c589:4ca7:2dae:5fa1]) by HE1PR0701MB2714.eurprd07.prod.outlook.com ([fe80::c589:4ca7:2dae:5fa1%16]) with mapi id 15.20.0239.004; Mon, 13 Nov 2017 08:42:34 +0000 From: Daniele Ceccarelli To: "stephane.litkowski@orange.com" , "pce@ietf.org" Thread-Topic: draft-ietf-pce-association-diversity: relaxing constraint Thread-Index: AdNcVzD/M9KOzAxBQO6wN/0nS1cgMgAAiaaQAABEwvAAADmx8A== Date: Mon, 13 Nov 2017 08:42:34 +0000 Message-ID: References: <7688_1510561338_5A09563A_7688_271_1_9E32478DFA9976438E7A22F69B08FF921EABBDF1@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <2637_1510562443_5A095A8B_2637_480_1_9E32478DFA9976438E7A22F69B08FF921EABBE39@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: <2637_1510562443_5A095A8B_2637_480_1_9E32478DFA9976438E7A22F69B08FF921EABBE39@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com; x-originating-ip: [31.133.131.147] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2715; 6:wqcUvpAelSKJT+Ohyk+RxeB9GdLZ87T3fA+9G83Sf47iri/kZ5KiNDm4hZsLbwPDC04x0jOrmN1MaouSZ7pK6ZX1UA7kIGz0hVty5CMlS1wmZ5e6YeH3GE/+sdCyYMPqG9jb9w6Qkn2gSRvuUa1/AxYislCiaRo8eCRRSX/UYAWL16vb//wbakNW2dBX78DOfQbDSybwE6yn7iBCI1BpB4CJvKhnJmc4vZXHnry2oZOiaGOYM7Gjw+OmsQLBrJhyvBPej2Ap70C1JGHTubUC7iRpqc5AaMNJU2Z1XUMxhlsHjTyBnE/TMuRic7ElpeOV+oPO5haIi+Ee17ZTpTCZ9hmGbX6/iAFLnjR3uMIcy4g=; 5:2hWpXANeTh8r21UlkNRLdOoyKc7jmXN42Gntt3vf1S2E0vny4n/n61UNvPt4Nnjkd4B414SNO1K2x2Q1OhxoHfX7wD/Xi6PbpNGOIIfTE0CFfjhHfUeVFaV8LGtWhHvPZiddW4KArJvdDpOSH3Ga/w2JK7xLWPp+GnR/nHmcLzU=; 24:0T1Hlwm2YkWw4rEGgvEAXivYydUYBPfELZfsbj9FhH5WKOd/Awk8QNt5oCkxzzBSxpub45pTue9Xe4Vgpud7ZeWoK72DNkeVyeTLI0r6cJE=; 7:7HV27MoFObztsrMSXYjd62o7otTiU1wSNJyHkpi/UJnYQFD60L+pDrua6eR8s7Qc5PykNekJAmhr406gzuKv+IF/VCctvfhQ6UF2Vq1ZUJ+ODunhl5dUpOR92XxoV4iyKjOEOmsonEasvlTsEW7+5owpOUQ91hgdw2WwJVTnFbvYK+Gbxy4XldoH/rUmhMKMoMY6HVlh3C/UzQPC3DUmj69aBDIY8m+090rYa/hLyudGGQz10NDbRRhOyJ/2XtGA x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 105120f2-a11c-451f-063b-08d52a727ca2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199)(49563074); SRVR:HE1PR0701MB2715; x-ms-traffictypediagnostic: HE1PR0701MB2715: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(115448073456579)(81850148713716)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(5005006)(8121501046)(3002001)(3231022)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123560025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR0701MB2715; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR0701MB2715; x-forefront-prvs: 0490BBA1F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(199003)(189002)(57704003)(5660300001)(229853002)(99286004)(6436002)(97736004)(733005)(6506006)(53546010)(2950100002)(9686003)(236005)(316002)(102836003)(790700001)(6116002)(3280700002)(3846002)(86362001)(2906002)(8936002)(230783001)(110136005)(2900100001)(14454004)(68736007)(3660700001)(54356999)(76176999)(7696004)(53936002)(8676002)(81156014)(101416001)(99936001)(6246003)(7736002)(606006)(81166006)(66066001)(5250100002)(33656002)(6306002)(54896002)(2501003)(106356001)(105586002)(54556002)(189998001)(25786009)(55016002)(5890100001)(74316002)(50986999)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2715; H:HE1PR0701MB2714.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/related; boundary="_004_HE1PR0701MB2714C7797C586533FC68890BF02B0HE1PR0701MB2714_"; type="multipart/alternative" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 105120f2-a11c-451f-063b-08d52a727ca2 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2017 08:42:34.6393 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2715 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA2WSa0iTYRTHed7L9k4cPdnEgxbVqLDyklKgdlOJErpgFGR+yZkvaukme020 PmSagkoypxhO85Za6IeZmZdMya2L3XWFTLPUNLUglVC0vLXtmSD07X/+v/85530OL0c7pYlc uVhlIq9WKuLkIgemKKzZ33MxXBK+5938Tr+0QbPYb7Z9mA2kQqqq/lAhN8deiUKpcIcDUXxc bBKv9j4U4RDTanRLqJlDyXOmJZSKOqZRNuI4wHthdAKykQPnhI0IvvTNMqToQqA39tDWgsG3 aKjo6xURoqPg/mKHvRhH8EPbyFpniXAAjBpOZCMJJ8NRoH3bRlv1BnwUpl6/FBP/GFRNZDFE B8OL+g82n8HbYUVrQlYtxRGQrjGzZL6Zgv4ho+2bJDgTwfTdQsqaQngTaNoqbR00doH+0TKb D1gGwz1vREQ7w4+RZZbkI0Gf0WLPyKFE10ITvQlMZTnIugDwMzFMvV9iCPCCR3m/ENEn4c/z LnuoGkF3W7MdeIC+v40lWgX1C2b75muQ88gkJg0jLEw+rRYTsBFGevPsoEAEd9pNrAZ56NY8 Q2dhNM6x3P9hHtLZLrIeXhWNMiSkgoHvWSKd5eA03gn6x97E3goFOcNiot0ho+SO+H/fE25r nlGrfvG9n4jssryotG7aDjzgRUsutba5HElrkbPAC0J8tK+vF6+OvSgIKqWXkk9sQJa/sbNx IaAFdY4HGRDmkNxRikIl4U6sIklIiTegbZY53+rrupEro1QpeblMmnbcgqVRipSrvFp1QX0l jhcMyI1j5C7SwI7uMCccrUjkL/N8Aq9epRQncU1Fp0v90197SJl9xekbv0YWNw2y4+aY0O5g 9xntUH5y4IbN53zUNzUd5obDmUGe1/U1RZUjNQdT111qbN0d/7lYsyDLD3ugad4xNyn7qx0+ 42houjGfWEj5xMxU1J5fflc+UGHsPbJlLORTOZU7pqRWSibqPoa57H8SfPbzNuZUQ/ZvOSPE KHx20WpB8Q/MrPm0lQMAAA== Archived-At: Subject: Re: [Pce] draft-ietf-pce-association-diversity: relaxing constraint 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, 13 Nov 2017 08:42:41 -0000 --_004_HE1PR0701MB2714C7797C586533FC68890BF02B0HE1PR0701MB2714_ Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB2714C7797C586533FC68890BF02B0HE1PR0701MB2714_" --_000_HE1PR0701MB2714C7797C586533FC68890BF02B0HE1PR0701MB2714_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gZXZlcnl0aGluZyDwn5iKDQoNCkZyb206IHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29t IFttYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb21dDQpTZW50OiBsdW5lZMOsIDEz IG5vdmVtYnJlIDIwMTcgMTY6NDENClRvOiBEYW5pZWxlIENlY2NhcmVsbGkgPGRhbmllbGUuY2Vj Y2FyZWxsaUBlcmljc3Nvbi5jb20+OyBwY2VAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBkcmFmdC1p ZXRmLXBjZS1hc3NvY2lhdGlvbi1kaXZlcnNpdHk6IHJlbGF4aW5nIGNvbnN0cmFpbnQNCg0KSGkg RGFuaWVsZSwNCg0KVGhhbmtzIGZvciB5b3VyIGZlZWRiYWNrLg0KSWYgd2UgZ28gdG8gYSBnZW5l cmljIG1lY2hhbmlzbSwgSU1PLCB0aGlzIHNob3VsZCBiZSBhZGRyZXNzZWQgaW4gYSBzZXBhcmF0 ZSBkb2N1bWVudC4gSW4gYWRkaXRpb24sIHdlIG5lZWQgYSBnZW5lcmljIHdheSBmb3IgYSBQQ0Mg dG8gdGVsbCB0aGUgUENFIHRoYXQgYSBjb25zdHJhaW50IGlzIHJlbGF4YWJsZSBvciBzdHJpY3Qu IEZvciBkaXZlcnNpdHksIHdlIGhhdmUgYSBkZWRpY2F0ZWQgZmxhZyB3aXRoaW4gdGhlIERJU0pP SU5UTkVTUyBUTFYgZm9yIHRoYXQgcHVycG9zZS4gTWF5YmUgd2Ugc2hvdWxkIG1ha2UgaXQgZ2Vu ZXJpYyBhcyB3ZWxsLg0KDQpEbyB5b3UgYWdyZWUgPw0KDQpCcmdkcywNCg0KDQpGcm9tOiBEYW5p ZWxlIENlY2NhcmVsbGkgW21haWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tXQ0K U2VudDogTW9uZGF5LCBOb3ZlbWJlciAxMywgMjAxNyAxNjozMw0KVG86IExJVEtPV1NLSSBTdGVw aGFuZSBPQlMvT0lOSVM7IHBjZUBpZXRmLm9yZzxtYWlsdG86cGNlQGlldGYub3JnPg0KU3ViamVj dDogUkU6IGRyYWZ0LWlldGYtcGNlLWFzc29jaWF0aW9uLWRpdmVyc2l0eTogcmVsYXhpbmcgY29u c3RyYWludA0KDQpIaSBTdGVwaGFuZSwNCg0KZGVmaW5pdGVseSBuZWVkZWQuDQpNeSBvcGluaW9u IGlzIHRoYXQgYSB3YXkgdG8gc2F5IHRoYXQgYSBjb25zdHJhaW50IHdhcyByZWxheGVkIGlzIHZl cnkgdXNlZnVsLiBBcyB5b3Ugc2FpZCB0aGVyZSBhcmUgZGlmZmVyZW50IHR5cGVzIG9mIGNvbnN0 cmFpbnRzIHRoYXQgY2FuIGJlIHJlbGF4ZWQsIGUuZy4gZGl2ZXJzaXR5IG9yIGEgVEUgYm91bmQu DQpJIHdvdWxkIG1ha2UgdGhlIFRMViBhcyBnZW5lcmljIGFzIHBvc3NpYmxlIGFuZCBtYXliZSBk ZWZpbmUgbXVsdGlwbGUgc3ViLVRMViAob3IgbWF5YmUganVzdCBtdWx0aXBsZSB2YWx1ZXMpIGRl cGVuZGluZyBvbiB0aGUgY29uc3RyYWludCB0aGF0IHdhcyByZWxheGVkLg0KDQpCUg0KRGFuaWVs ZQ0KDQpGcm9tOiBQY2UgW21haWx0bzpwY2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPG1haWx0bzpzdGVwaGFuZS5saXRrb3dza2lA b3JhbmdlLmNvbT4NClNlbnQ6IGx1bmVkw6wgMTMgbm92ZW1icmUgMjAxNyAxNjoyMg0KVG86IHBj ZUBpZXRmLm9yZzxtYWlsdG86cGNlQGlldGYub3JnPg0KU3ViamVjdDogW1BjZV0gZHJhZnQtaWV0 Zi1wY2UtYXNzb2NpYXRpb24tZGl2ZXJzaXR5OiByZWxheGluZyBjb25zdHJhaW50DQoNCkhpIFdH LA0KDQpJbiB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgZHJhZnQtaWV0Zi1wY2UtYXNzb2NpYXRpb24t ZGl2ZXJzaXR5IHdlIGFkZGVkIGEgbmV3IFRMViBjYWxsZWQgUkVMQVhFRC1DT05TVFJBSU5ULVRM ViB0byBiZSB1c2VkIGluIExTUCBPYmplY3Qgb2YgYSBQQ1VwZGF0ZSBtZXNzYWdlIHdoZW4gdGhl IFBDRSByZWxheGVzIHRoZSByZXF1ZXN0ZWQgZGlzam9pbnRuZXNzIGNvbnN0cmFpbnQuIEZvciBp bnN0YW5jZSwgaWYgYSBQQ0MgcmVxdWVzdHMgYW4gU1JMRyBkaXNqb2ludCBwYXRoIGJ1dCB0aGUg UENFIGNhbm5vdCBmaW5kIGl0LCBpdCBtYXkgcmVsYXggdGhlIGNvbnN0cmFpbnQgKGlmIFBDQyBh bGxvd3MgaXQgdG8gZG8gc28pIGFuZCB0aHVzIGluZm9ybXMgdGhlIFBDQyB0aHJvdWdoIHRoZSBS RUxBWEVELUNPTlNUUkFJTlQtVExWLg0KDQpJTU8sIHRoaXMga2luZCBvZiBiZWhhdmlvciBpcyBt b3JlIGdlbmVyaWMgcmF0aGVyIHRpZWQgdG8gdGhlIGRpc2pvaW50bmVzcyB1c2UgY2FzZS4gSXQg bWF5IGJlIHVzZWQgd2l0aCBvdGhlciBjb25zdHJhaW50cyBhcyB3ZWxsLg0KDQpUaGUgcXVlc3Rp b24gaXM6IGRvIHdlIG5lZWQgdG8ga2VlcCB0aGlzIFJFTEFYRUQtQ09OU1RSQUlOVC1UTFYgaW4g dGhlIGFzc29jaWF0aW9uLWRpdmVyc2l0eSBkcmFmdCA/IG9yIGRvIHdlIGRyb3AgaXQgPyBvciBk byB3ZSBkZWZpbmUgYSBUTFYgbW9yZSBzcGVjaWZpYyB0byB0aGUgYXNzb2NpYXRpb24gZGl2ZXJz aXR5IHN0YXRlID8gbWF5YmUgd2UgY2FuIHJldXNlIHRoZSBhc3NvY2lhdGlvbiBncm91cCBvYmpl Y3QgaW4gdGhlIFBDVXBkYXRlIG1lc3NhZ2UgaW5jbHVkaW5nIHRoZSBESVNKT0lOVE5FU1MtSU5G T1JNQVRJT04tVExWIHdoaWNoIHJlZmxlY3RzIHRoZSBhY3R1YWwgZGlzam9pbnRuZXNzIHN0eWxl IHVzZWQgYnkgdGhlIFBDRS4NCg0KT3BpbmlvbnMgPw0KDQoNCkJyZ2RzLA0KDQpTdGVwaGFuZQ0K DQoNCltPcmFuZ2UgbG9nb108aHR0cDovL3d3dy5vcmFuZ2UuY29tLz4NCg0KU3RlcGhhbmUgTGl0 a293c2tpDQpOZXR3b3JrIEFyY2hpdGVjdA0KT3JhbmdlL1NDRS9FUVVBTlQvT0lOSVMvTkVUDQpP cmFuZ2UgRXhwZXJ0IEZ1dHVyZSBOZXR3b3Jrcw0KcGhvbmU6ICszMyAyIDIzIDA2IDQ5IDgzIDxo dHRwczovL21vbnNpLnNzby5mcmFuY2V0ZWxlY29tLmZyL2luZGV4LmFzcD90YXJnZXQ9aHR0cCUz QSUyRiUyRmNsaWN2b2ljZS5zc28uZnJhbmNldGVsZWNvbS5mciUyRkNsaWN2b2ljZVYyJTJGVG9v bEJhci5kbyUzRmFjdGlvbiUzRGRlZmF1bHQlMjZyb290c2VydmljZSUzRFNJR05BVFVSRSUyNnRv JTNEKzMzJTIwMiUyMDIzJTIwMjglMjA0OSUyMDgzJTIwPiAgTkVXICENCm1vYmlsZTogKzMzIDYg NzEgNjMgMjcgNTAgPGh0dHBzOi8vbW9uc2kuc3NvLmZyYW5jZXRlbGVjb20uZnIvaW5kZXguYXNw P3RhcmdldD1odHRwJTNBJTJGJTJGY2xpY3ZvaWNlLnNzby5mcmFuY2V0ZWxlY29tLmZyJTJGQ2xp Y3ZvaWNlVjIlMkZUb29sQmFyLmRvJTNGYWN0aW9uJTNEZGVmYXVsdCUyNnJvb3RzZXJ2aWNlJTNE U0lHTkFUVVJFJTI2dG8lM0QrMzMlMjA2JTIwMzclMjA4NiUyMDk3JTIwNTIlMjA+ICBORVcgIQ0K c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb208bWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3NraUBv cmFuZ2UuY29tPg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCg0KDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBq b2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMg b3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KDQpwYXMgZXRyZSBkaWZmdXNlcywg ZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3Ug Y2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KDQphIGwnZXhwZWRp dGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVz c2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KDQpP cmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFs dGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNCg0KDQpUaGlzIG1lc3NhZ2UgYW5k IGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBp bmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KDQp0aGV5IHNob3VsZCBu b3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4N Cg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMu DQoNCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1l c3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCg0K VGhhbmsgeW91Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9p bnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91 IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4 cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNl IG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCg0KYSBsJ2V4cGVkaXRl dXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3Nh Z2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0KT3Jh bmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRl cmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBp dHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5m b3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCg0KdGhleSBzaG91bGQgbm90 IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQoN CklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0K DQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNz YWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoNClRo YW5rIHlvdS4NCg== --_000_HE1PR0701MB2714C7797C586533FC68890BF02B0HE1PR0701MB2714_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7 DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBD aGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsc2Fucy1zZXJpZjt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1h bDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21z by1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEi LHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4u RW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjYN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3 Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iSVQiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+T24gZXZlcnl0aGluZyA8L3NwYW4+DQo8 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkgRW1vamkmcXVvdDssc2Fucy1z ZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+JiMxMjg1MjI7PC9zcGFuPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi PiBzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbSBbbWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3Nr aUBvcmFuZ2UuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IGx1bmVkw6wgMTMgbm92ZW1icmUgMjAx NyAxNjo0MTxicj4NCjxiPlRvOjwvYj4gRGFuaWVsZSBDZWNjYXJlbGxpICZsdDtkYW5pZWxlLmNl Y2NhcmVsbGlAZXJpY3Nzb24uY29tJmd0OzsgcGNlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJFOiBkcmFmdC1pZXRmLXBjZS1hc3NvY2lhdGlvbi1kaXZlcnNpdHk6IHJlbGF4aW5nIGNv bnN0cmFpbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkhpIERhbmllbGUsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PlRoYW5rcyBmb3IgeW91ciBmZWVkYmFjay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPklm IHdlIGdvIHRvIGEgZ2VuZXJpYyBtZWNoYW5pc20sIElNTywgdGhpcyBzaG91bGQgYmUgYWRkcmVz c2VkIGluIGEgc2VwYXJhdGUgZG9jdW1lbnQuIEluIGFkZGl0aW9uLCB3ZSBuZWVkIGEgZ2VuZXJp YyB3YXkgZm9yIGEgUENDIHRvIHRlbGwgdGhlIFBDRSB0aGF0IGEgY29uc3RyYWludCBpcyByZWxh eGFibGUgb3Igc3RyaWN0LiBGb3IgZGl2ZXJzaXR5LA0KIHdlIGhhdmUgYSBkZWRpY2F0ZWQgZmxh ZyB3aXRoaW4gdGhlIERJU0pPSU5UTkVTUyBUTFYgZm9yIHRoYXQgcHVycG9zZS4gTWF5YmUgd2Ug c2hvdWxkIG1ha2UgaXQgZ2VuZXJpYyBhcyB3ZWxsLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkRvIHlvdSBhZ3JlZSA/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPkJyZ2RzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5z LXNlcmlmIj4gRGFuaWVsZSBDZWNjYXJlbGxpIFs8YSBocmVmPSJtYWlsdG86ZGFuaWVsZS5jZWNj YXJlbGxpQGVyaWNzc29uLmNvbSI+bWFpbHRvOmRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5j b208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgTm92ZW1iZXIgMTMsIDIwMTcgMTY6 MzM8YnI+DQo8Yj5Ubzo8L2I+IExJVEtPV1NLSSBTdGVwaGFuZSBPQlMvT0lOSVM7IDxhIGhyZWY9 Im1haWx0bzpwY2VAaWV0Zi5vcmciPnBjZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUkU6IGRyYWZ0LWlldGYtcGNlLWFzc29jaWF0aW9uLWRpdmVyc2l0eTogcmVsYXhpbmcgY29u c3RyYWludDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgU3RlcGhhbmUsPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5kZWZpbml0ZWx5IG5lZWRlZC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TXkgb3Bpbmlv biBpcyB0aGF0IGEgd2F5IHRvIHNheSB0aGF0IGEgY29uc3RyYWludCB3YXMgcmVsYXhlZCBpcyB2 ZXJ5IHVzZWZ1bC4gQXMgeW91IHNhaWQgdGhlcmUgYXJlIGRpZmZlcmVudCB0eXBlcyBvZiBjb25z dHJhaW50cyB0aGF0IGNhbiBiZSByZWxheGVkLCBlLmcuIGRpdmVyc2l0eSBvciBhIFRFIGJvdW5k LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5JIHdvdWxkIG1ha2UgdGhlIFRMViBhcyBnZW5lcmljIGFzIHBvc3NpYmxlIGFuZCBt YXliZSBkZWZpbmUgbXVsdGlwbGUgc3ViLVRMViAob3IgbWF5YmUganVzdCBtdWx0aXBsZSB2YWx1 ZXMpIGRlcGVuZGluZyBvbiB0aGUgY29uc3RyYWludCB0aGF0IHdhcyByZWxheGVkLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+QlI8YnI+DQpEYW5pZWxlJm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVT Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBQY2UgWzxhIGhyZWY9Im1haWx0 bzpwY2UtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnBjZS1ib3VuY2VzQGlldGYub3JnPC9hPl0N CjxiPk9uIEJlaGFsZiBPZiA8L2I+PGEgaHJlZj0ibWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3NraUBv cmFuZ2UuY29tIj5zdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTwvYT48YnI+DQo8Yj5TZW50 OjwvYj4gbHVuZWTDrCAxMyBub3ZlbWJyZSAyMDE3IDE2OjIyPGJyPg0KPGI+VG86PC9iPiA8YSBo cmVmPSJtYWlsdG86cGNlQGlldGYub3JnIj5wY2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVj dDo8L2I+IFtQY2VdIGRyYWZ0LWlldGYtcGNlLWFzc29jaWF0aW9uLWRpdmVyc2l0eTogcmVsYXhp bmcgY29uc3RyYWludDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBXRyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkluIHRoZSBs YXRlc3QgdmVyc2lvbiBvZiBkcmFmdC1pZXRmLXBjZS1hc3NvY2lhdGlvbi1kaXZlcnNpdHkgd2Ug YWRkZWQgYSBuZXcgVExWIGNhbGxlZCBSRUxBWEVELUNPTlNUUkFJTlQtVExWIHRvIGJlIHVzZWQg aW4gTFNQIE9iamVjdCBvZiBhIFBDVXBkYXRlIG1lc3NhZ2Ugd2hlbiB0aGUgUENFIHJlbGF4ZXMg dGhlIHJlcXVlc3RlZCBkaXNqb2ludG5lc3MgY29uc3RyYWludC4NCiBGb3IgaW5zdGFuY2UsIGlm IGEgUENDIHJlcXVlc3RzIGFuIFNSTEcgZGlzam9pbnQgcGF0aCBidXQgdGhlIFBDRSBjYW5ub3Qg ZmluZCBpdCwgaXQgbWF5IHJlbGF4IHRoZSBjb25zdHJhaW50IChpZiBQQ0MgYWxsb3dzIGl0IHRv IGRvIHNvKSBhbmQgdGh1cyBpbmZvcm1zIHRoZSBQQ0MgdGhyb3VnaCB0aGUgUkVMQVhFRC1DT05T VFJBSU5ULVRMVi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPklNTywgdGhpcyBraW5kIG9mIGJlaGF2aW9y IGlzIG1vcmUgZ2VuZXJpYyByYXRoZXIgdGllZCB0byB0aGUgZGlzam9pbnRuZXNzIHVzZSBjYXNl LiBJdCBtYXkgYmUgdXNlZCB3aXRoIG90aGVyIGNvbnN0cmFpbnRzIGFzIHdlbGwuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5UaGUgcXVlc3Rpb24gaXM6IGRvIHdlIG5lZWQgdG8ga2VlcCB0aGlzIFJFTEFY RUQtQ09OU1RSQUlOVC1UTFYgaW4gdGhlIGFzc29jaWF0aW9uLWRpdmVyc2l0eSBkcmFmdCA/IG9y IGRvIHdlIGRyb3AgaXQgPyBvciBkbyB3ZSBkZWZpbmUgYSBUTFYgbW9yZSBzcGVjaWZpYyB0byB0 aGUgYXNzb2NpYXRpb24gZGl2ZXJzaXR5IHN0YXRlID8gbWF5YmUgd2UgY2FuIHJldXNlIHRoZSBh c3NvY2lhdGlvbg0KIGdyb3VwIG9iamVjdCBpbiB0aGUgUENVcGRhdGUgbWVzc2FnZSBpbmNsdWRp bmcgdGhlIERJU0pPSU5UTkVTUy1JTkZPUk1BVElPTi1UTFYgd2hpY2ggcmVmbGVjdHMgdGhlIGFj dHVhbCBkaXNqb2ludG5lc3Mgc3R5bGUgdXNlZCBieSB0aGUgUENFLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+T3BpbmlvbnMgPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJyZ2RzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+U3RlcGhhbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cDovL3d3dy5vcmFuZ2UuY29t LyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LHNlcmlmO3RleHQtZGVjb3JhdGlvbjpub25lIj48aW1nIGJvcmRlcj0i MCIgd2lkdGg9IjQwIiBoZWlnaHQ9IjQwIiBzdHlsZT0id2lkdGg6LjQxNjZpbjtoZWlnaHQ6LjQx NjZpbiIgaWQ9IlBpY3R1cmVfeDAwMjBfMSIgc3JjPSJjaWQ6aW1hZ2UwMDEuanBnQDAxRDM1QzlF LjYyQkI4MTQwIiBhbHQ9Ik9yYW5nZSBsb2dvIj48L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LHNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+U3RlcGhh bmUgTGl0a293c2tpDQo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYi Pjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+TmV0 d29yayBBcmNoaXRlY3QNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48 YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk9yYW5n ZS9TQ0UvRVFVQU5UL09JTklTL05FVDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNl cmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+T3JhbmdlIEV4cGVydCBGdXR1cmUgTmV0d29y a3M8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPnBob25lOg0KPGEgaHJlZj0iaHR0cHM6Ly9tb25zaS5zc28uZnJhbmNldGVsZWNvbS5m ci9pbmRleC5hc3A/dGFyZ2V0PWh0dHAlM0ElMkYlMkZjbGljdm9pY2Uuc3NvLmZyYW5jZXRlbGVj b20uZnIlMkZDbGljdm9pY2VWMiUyRlRvb2xCYXIuZG8lM0ZhY3Rpb24lM0RkZWZhdWx0JTI2cm9v dHNlcnZpY2UlM0RTSUdOQVRVUkUlMjZ0byUzRCYjNDM7MzMlMjAyJTIwMjMlMjAyOCUyMDQ5JTIw ODMlMjAiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mIzQzOzMzIDIgMjMgPGI+MDY8L2I+ IDQ5IDgzIDwvc3Bhbj48L2E+Jm5ic3A7TkVXJm5ic3A7ITwvc3Bhbj48c3BhbiBsYW5nPSJGUiIg c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LHNlcmlmIj48YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPm1vYmlsZToNCjxhIGhyZWY9Imh0dHBzOi8vbW9uc2kuc3NvLmZyYW5jZXRlbGVjb20u ZnIvaW5kZXguYXNwP3RhcmdldD1odHRwJTNBJTJGJTJGY2xpY3ZvaWNlLnNzby5mcmFuY2V0ZWxl Y29tLmZyJTJGQ2xpY3ZvaWNlVjIlMkZUb29sQmFyLmRvJTNGYWN0aW9uJTNEZGVmYXVsdCUyNnJv b3RzZXJ2aWNlJTNEU0lHTkFUVVJFJTI2dG8lM0QmIzQzOzMzJTIwNiUyMDM3JTIwODYlMjA5NyUy MDUyJTIwIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+JiM0MzszMyA2IDcxIDYzIDI3IDUw IDwvc3Bhbj48L2E+Jm5ic3A7TkVXJm5ic3A7ITwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LHNlcmlmIj48YnI+DQo8YSBocmVmPSJtYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5j b20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6I0ZGNjYwMCI+c3RlcGhhbmUubGl0a293c2tpQG9yYW5n ZS5jb208L3NwYW4+PC9hPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw cmU+PHNwYW4gbGFuZz0iRU4tVVMiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBsYW5nPSJFTi1VUyI+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1 dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxl Z2llZXMgZXQgbmUgZG9pdmVudCBkb25jPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIGxhbmc9IkVOLVVTIj5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBz YW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVy LCB2ZXVpbGxleiBsZSBzaWduYWxlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyI+YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxl cyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2Vw dGlibGVzIGQnYWx0ZXJhdGlvbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRU4tVVMiPk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1l c3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+VGhpcyBtZXNzYWdlIGFuZCBp dHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5m b3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmli dXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+SWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUg dGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5n ZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hh bmdlZCBvciBmYWxzaWZpZWQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIj5UaGFuayB5b3UuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjxw cmU+PHNwYW4gbGFuZz0iRU4tVVMiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBsYW5nPSJFTi1VUyI+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1 dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxl Z2llZXMgZXQgbmUgZG9pdmVudCBkb25jPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIGxhbmc9IkVOLVVTIj5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBz YW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVy LCB2ZXVpbGxleiBsZSBzaWduYWxlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyI+YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxl cyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2Vw dGlibGVzIGQnYWx0ZXJhdGlvbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRU4tVVMiPk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1l c3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+VGhpcyBtZXNzYWdlIGFuZCBp dHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5m b3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmli dXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+SWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUg dGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5n ZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hh bmdlZCBvciBmYWxzaWZpZWQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIj5UaGFuayB5b3UuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_HE1PR0701MB2714C7797C586533FC68890BF02B0HE1PR0701MB2714_-- --_004_HE1PR0701MB2714C7797C586533FC68890BF02B0HE1PR0701MB2714_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=1093; creation-date="Mon, 13 Nov 2017 08:42:33 GMT"; modification-date="Mon, 13 Nov 2017 08:42:33 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAAoACgDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD1O48f afbXMsDWl0WjcoSAuDg49aj/AOFiad/z53f5L/jXB6r/AMhe9/67v/M1Ur5Geb4pSaTX3H2dPJcJ KCbT+89H/wCFiad/z53f5L/jR/wsTTv+fO7/ACX/ABrziip/tnFd19xX9iYPs/vPR/8AhYmnf8+d 3+S/40V5xRR/bOK7r7g/sTB9n95b1X/kL3v/AF3f+ZqpW3Po17qGo3s0Cx7DdPGpeQLvbOdq56mo R4d1EmEFYVaZdyI0oDY9cda450KspNqLO2niKUYJOSvbv5GVRWwPC+qmR4zFErI/l4aUDc2A2B68 GmDw7qTQrIIkJZVYR+YN+GOAdvuan6tW/lf3FfWqH86+8yqK2bjQG0+EvqU/2dmyIgieYGI6gkHg 0VM6M4O0tGVCtCavF3R1o8Oa7BcTtbXdh5TztPGJYyxjY9xxwcUxfDniNZ1m+32DOIPs+WjJymc8 8dc96KK+y/s+l3f3s+J/tKt2X3Ie+geJZJlla/0/eswmH7s/eChfT0FXDo2rDTRCktoLoIqfaCxy NrZGPlz+GaKKpYGmr6vXzJlj6sraLTyMrUPCOuant+03lh8pJ+RGXJPUniiiisZ5Thpvmldv1N4Z xioLljZL0R//2Q== --_004_HE1PR0701MB2714C7797C586533FC68890BF02B0HE1PR0701MB2714_-- From nobody Mon Nov 13 08:32:11 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 ECEE2129B04 for ; Mon, 13 Nov 2017 08:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.217 X-Spam-Level: X-Spam-Status: No, score=0.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_BRBL_LASTEXT=1.449, 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 SvqQxA9xMuJr for ; Mon, 13 Nov 2017 08:32:07 -0800 (PST) Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [161.106.1.3]) by ietfa.amsl.com (Postfix) with ESMTP id CE321120454 for ; Mon, 13 Nov 2017 08:32:06 -0800 (PST) Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 381FDE300B4; Mon, 13 Nov 2017 17:32:03 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail2.rd.orange.com (Postfix) with ESMTP id 12995E300B3; Mon, 13 Nov 2017 17:32:03 +0100 (CET) Received: from [10.193.71.231] (10.193.71.231) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.361.1; Mon, 13 Nov 2017 17:32:02 +0100 To: , Daniele Ceccarelli , "pce@ietf.org" References: <7688_1510561338_5A09563A_7688_271_1_9E32478DFA9976438E7A22F69B08FF921EABBDF1@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <2637_1510562443_5A095A8B_2637_480_1_9E32478DFA9976438E7A22F69B08FF921EABBE39@OPEXCLILMA4.corporate.adroot.infra.ftgroup> From: Olivier Dugeon Organization: Orange Labs Message-ID: <9f1405b5-b166-9ad0-304c-b17d1830ae78@orange.com> Date: Mon, 13 Nov 2017 17:32:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <2637_1510562443_5A095A8B_2637_480_1_9E32478DFA9976438E7A22F69B08FF921EABBE39@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------F5B51868805BA6A7B54D6257" Content-Language: en-GB Archived-At: Subject: Re: [Pce] draft-ietf-pce-association-diversity: relaxing constraint 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, 13 Nov 2017 16:32:10 -0000 --------------F5B51868805BA6A7B54D6257 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Stephane, all In fact, these mechanism is already available in RFC 5440. First, Metric Object has been defined with a B flag to indicate if this m= etric (i.e. constraint) must be bound or not. See https://tools.ietf.org/= html/rfc5440#section-7.8. Terminology is not exactly the same, but, the g= oal is similar. It allows a PCC to indicate to the PCE if the metric must= be strictly respected or not. Note, also that it is possible to indicate= many similar Metric object with different value, as well as different va= lue for the B-flagfor more flexibility. For example, for the Disjointness= , we could image a first Metric with SRLG disjoint path and B-Flag set to= one and a second one with SRLG-and-Node disjoint path with B-Flag clear.= This indicate to the PCE that we want at least an SRLG disjoint path, bu= t if it could compute an SRLG and Node disjoint path we'll be very happy.= PCC could also set the C-Flag to indicate to the PCE that it would in tur= n the computed Metric. For disjointness, it could indicate which type of = disjointness it successfully used for the computed path. If a metric could not be met, PCE will return a No-PATH object with the d= efault metric to indicate which constraints could not be met. Now, to indicate that a metric (constraint) should be relaxed, there is 2= possibilities: send a new PCEP message with the B-Flag of this Metric cl= eared, or a PCEP message without the given Metric. see again RFC 5440 end= of section 7.8 page 38(https://tools.ietf.org/html/rfc5440#page-38). So, I think the generic mechanism is already available and to inherit fro= m this behaviour, the Disjointeness TLV should be a new Metric Object ins= tead of a dedicated new TLV. But, I understand that the draft and solutio= n have not been design with this in mind. So I let authors decided if it = is feasible or not. Regards Olivier Le 13/11/2017 =C3=A0 09:40, stephane.litkowski@orange.com a =C3=A9crit=C2= =A0: > > Hi Daniele, > > =C2=A0 > > Thanks for your feedback. > > If we go to a generic mechanism, IMO, this should be addressed in a sep= arate document. In addition, we need a generic way for a PCC to tell the = PCE that a constraint is relaxable or strict. For diversity, we have a de= dicated flag within the DISJOINTNESS TLV for that purpose. Maybe we shoul= d make it generic as well. > > =C2=A0 > > Do you agree ? > > =C2=A0 > > Brgds, > > =C2=A0 > > =C2=A0 > > *From:*Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > *Sent:* Monday, November 13, 2017 16:33 > *To:* LITKOWSKI Stephane OBS/OINIS; pce@ietf.org > *Subject:* RE: draft-ietf-pce-association-diversity: relaxing constrain= t > > =C2=A0 > > Hi Stephane, > > =C2=A0 > > definitely needed. > > My opinion is that a way to say that a constraint was relaxed is very u= seful. As you said there are different types of constraints that can be r= elaxed, e.g. diversity or a TE bound. > > I would make the TLV as generic as possible and maybe define multiple s= ub-TLV (or maybe just multiple values) depending on the constraint that w= as relaxed. > > =C2=A0 > > BR > Daniele=C2=A0 > > =C2=A0 > > *From:* Pce [mailto:pce-bounces@ietf.org] *On Behalf Of *stephane.litko= wski@orange.com > *Sent:* luned=C3=AC 13 novembre 2017 16:22 > *To:* pce@ietf.org > *Subject:* [Pce] draft-ietf-pce-association-diversity: relaxing constra= int > > =C2=A0 > > Hi WG, > > =C2=A0 > > In the latest version of draft-ietf-pce-association-diversity we added = a new TLV called RELAXED-CONSTRAINT-TLV to be used in LSP Object of a PCU= pdate message when the PCE relaxes the requested disjointness constraint.= For instance, if a PCC requests an SRLG disjoint path but the PCE cannot= find it, it may relax the constraint (if PCC allows it to do so) and thu= s informs the PCC through the RELAXED-CONSTRAINT-TLV. > > =C2=A0 > > IMO, this kind of behavior is more generic rather tied to the disjointn= ess use case. It may be used with other constraints as well. > > =C2=A0 > > The question is: do we need to keep this RELAXED-CONSTRAINT-TLV in the = association-diversity draft ? or do we drop it ? or do we define a TLV mo= re specific to the association diversity state ? maybe we can reuse the a= ssociation group object in the PCUpdate message including the DISJOINTNES= S-INFORMATION-TLV which reflects the actual disjointness style used by th= e PCE. > > =C2=A0 > > Opinions ? > > =C2=A0 > > =C2=A0 > > Brgds, > > =C2=A0 > > Stephane > > =C2=A0 > > =C2=A0 > > Orange logo > > =C2=A0 > > *Stephane Litkowski * > Network Architect > Orange/SCE/EQUANT/OINIS/NET > > Orange Expert Future Networks > > phone: +33 2 23 *06* 49 83 =C2=A0NEW=C2=A0! > mobile: +33 6 71 63 27 50 =C2=A0NEW=C2=A0! > stephane.litkowski@orange.com > > =C2=A0 > > _______________________________________________________________________= __________________________________________________ > =C2=A0 > Ce message et ses pieces jointes peuvent contenir des informations conf= identielles 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 message= s electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme= ou falsifie. Merci. > =C2=A0 > This message and its attachments may contain confidential or privileged= information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have b= een modified, changed or falsified. > Thank you. > _______________________________________________________________________= __________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations conf= identielles 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 message= s electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme= ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged= information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have b= een modified, changed or falsified. > Thank you. > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce --------------F5B51868805BA6A7B54D6257 Content-Type: multipart/related; boundary="------------2BCA67980E3C2120B18C8A8B" --------------2BCA67980E3C2120B18C8A8B Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hello Stephane, all

In fact, these mechani= sm is already available in RFC 5440.

= First, Metric Object has been defined with a B flag to indicate if this metric (i.e. constraint) must be bound or not. See https://tools.ietf.org/html/rfc5440#section-7.8. Terminology is not exactly the same, but, the goal is similar. It allows a PCC to indicate to the PCE if the metric must be strictly respected o<= font face=3D"Ubuntu">r not. Note, also that it is possible to indicate many similar Metric object with different value, as well as different value for the B-flag for more flexibility. For example, for the Disjointness, we could image a first Metric with SRLG disjoint path and B-Flag set to one and a second one with SRLG-and-Node disjoint path with B-Flag clear. This indicate to the PCE that we want at least an SRLG disjoint path, but if it could compute a= n SRLG and Node disjoint path we'll be very happy.=

= PCC could also se= t the C-Flag to indicate to the PCE that it would in turn the computed Metric= =2E For disjointness, it could indicate which type of disjointness it successfully used for the computed path.

= If a metric could not be met, PCE will return a No-PATH object with the default metric to indicate which constraints could not be met.<= br>

= Now, to indicate that a<= /font> metric (constraint) s= hould be relaxed, there is 2 possibilities: send= a new PCEP message with= the B-Flag of this Metric cleared, or a PCEP message without the given Metric. see again= RFC 5440 end of section 7.8 page 38 (<= a moz-do-not-send=3D"true= " href=3D"https://tools.ietf.org/html/rfc5440#page-38">https://tools.ietf.o= rg/html/rfc5440#page-38).

So, I think the generic mechanism is already available and to inherit from this behaviour, the Disjointeness TLV should be a new Metric Object instead of a dedicated new TLV. But, I understand that the draft and solution have not been design with this in mind. So I let authors decided if it is feasible or not.

Regards

Olivier


Le 13/11/2017 =C3=A0 09:40, stephane.litkowski@orange.com a =C3=A9crit=C2=A0:

Hi Daniele,<= o:p>

=C2=A0<= /o:p>

Thanks for y= our feedback.

If we go to = a generic mechanism, IMO, this should be addressed in a separate document. In addition, we need a generic way for a PCC to tell the PCE that a constraint is relaxable or strict. For diversity, we have a dedicated flag within the DISJOINTNESS TLV for that purpose. Maybe we should make it generic as well.

=C2=A0<= /o:p>

Do you agree= ?

=C2=A0<= /o:p>

Brgds,<= /o:p>

=C2=A0<= /o:p>

=C2=A0<= /o:p>

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Monday, November 13, 2017 16:33
To: LITKOWSKI Stephane OBS/OINIS; pce@ietf.org
Subject: RE: draft-ietf-pce-association-diversity: relaxing constraint

=C2=A0

Hi Stephane,<= /span>

=C2=A0=

definitely needed.

My opinion is that a way to say that a constraint was relaxed is very useful. As you said there are different types of constraints that can be relaxed, e.g. diversity or a TE bound.

I would make the TLV as generic as possibl= e and maybe define multiple sub-TLV (or maybe just multiple values) depending on the constraint that was relaxed.

=C2=A0

BR
Daniele=C2=A0

=C2=A0

=C2=A0

Hi WG,

=C2=A0

In the latest version of draft-ietf-pce-association-diversity we added a new TLV called RELAXED-CONSTRAINT-TLV to be used in LSP Object of a PCUpdate message when the PCE relaxes the requested disjointness constraint. For instance, if a PCC requests an SRLG disjoint path but the PCE cannot find it, it may relax the constraint (if PCC allows it to do so) and thus informs the PCC through the RELAXED-CONSTRAINT-TLV.

=C2=A0

IMO, this kind of behavior is more generic rather tied to the disjointness use case. It may be used with other constraints as well.

=C2=A0

The question is: do we need to keep this= RELAXED-CONSTRAINT-TLV in the association-diversity draft ? or do we drop it ? or do we define a TLV more specific to the association diversity state ? maybe we can reuse the association group object in the PCUpdate message including the DISJOINTNESS-INFORMATION-TLV which reflects the actual disjointness style used by the PCE.

=C2=A0

Opinions ?

=C2=A0

=C2=A0

Brgds,

=C2=A0

Stephane

=C2=A0

=

=C2=A0

=

3D"Orange

=C2=A0

=

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET

Orange Expert Future Networks

phone: +33 2 23 06 49 83 =C2=A0NEW=C2=A0!
mobile: +33 6 71 63 27 50 = =C2=A0NEW=C2=A0!
stephane.litkowski@orange.com

=C2=A0

__________________________________________________________=
_______________________________________________________________
=C2=A0
Ce message et ses pieces jointes peuvent contenir des info=
rmations confidentielles ou privilegiees et ne doivent donc
          
pas etre diffuses, exploites ou copies sans autorisation. =
Si vous avez recu ce message par erreur, veuillez le signaler<=
/pre>
          
a l'expediteur et le detruire ainsi que les pieces jointes=
=2E Les messages electroniques etant susceptibles d'alteration,

          
Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

          
=C2=A0

          
This message and its attachments may contain confidential =
or privileged information that may be protected by law;

          
they should not be distributed, used or copied without aut=
horisation.

          
If you have received this email in error, please notify th=
e sender and delete this message and its attachments.

          
As emails may be altered, Orange is not liable for message=
s that have been modified, changed or falsified.

          
Thank you.

        
______________________________________________________________=
___________________________________________________________

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

This message and its attachments may contain confidential or privileged i=
nformation 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 de=
lete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
Thank you.



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

--------------2BCA67980E3C2120B18C8A8B Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="image001.jpg" /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAAR CAAoACgDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD1O48fafbXMsDWl0WjcoSAuDg49aj/AOFi ad/z53f5L/jXB6r/AMhe9/67v/M1Ur5Geb4pSaTX3H2dPJcJKCbT+89H/wCFiad/z53f5L/j R/wsTTv+fO7/ACX/ABrziip/tnFd19xX9iYPs/vPR/8AhYmnf8+d3+S/40V5xRR/bOK7r7g/ sTB9n95b1X/kL3v/AF3f+ZqpW3Po17qGo3s0Cx7DdPGpeQLvbOdq56moR4d1EmEFYVaZdyI0 oDY9cda450KspNqLO2niKUYJOSvbv5GVRWwPC+qmR4zFErI/l4aUDc2A2B68GmDw7qTQrIIk JZVYR+YN+GOAdvuan6tW/lf3FfWqH86+8yqK2bjQG0+EvqU/2dmyIgieYGI6gkHg0VM6M4O0 tGVCtCavF3R1o8Oa7BcTtbXdh5TztPGJYyxjY9xxwcUxfDniNZ1m+32DOIPs+WjJymc88dc9 6KK+y/s+l3f3s+J/tKt2X3Ie+geJZJlla/0/eswmH7s/eChfT0FXDo2rDTRCktoLoIqfaCxy NrZGPlz+GaKKpYGmr6vXzJlj6sraLTyMrUPCOuant+03lh8pJ+RGXJPUniiiisZ5Thpvmldv 1N4ZxioLljZL0R//2Q== --------------2BCA67980E3C2120B18C8A8B-- --------------F5B51868805BA6A7B54D6257-- From nobody Mon Nov 13 08:38: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 686EB1293E8 for ; Mon, 13 Nov 2017 08:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.397 X-Spam-Level: X-Spam-Status: No, score=-5.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 t15dSBFM9Wtp for ; Mon, 13 Nov 2017 08:38:17 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 118D3120454 for ; Mon, 13 Nov 2017 08:38:17 -0800 (PST) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id E2D85C042F for ; Mon, 13 Nov 2017 17:38:15 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id C07F91A0062 for ; Mon, 13 Nov 2017 17:38:15 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0361.001; Mon, 13 Nov 2017 17:38:15 +0100 From: To: "pce@ietf.org" Thread-Topic: Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing Thread-Index: AdNcnZvYi2xVxqg4QzKXbgSaVFI8tA== Date: Mon, 13 Nov 2017 16:38:14 +0000 Message-ID: <20853_1510591095_5A09CA77_20853_54_2_9E32478DFA9976438E7A22F69B08FF921EABC22A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/related; boundary="_004_9E32478DFA9976438E7A22F69B08FF921EABC22AOPEXCLILMA4corp_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing 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, 13 Nov 2017 16:38:19 -0000 --_004_9E32478DFA9976438E7A22F69B08FF921EABC22AOPEXCLILMA4corp_ Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF921EABC22AOPEXCLILMA4corp_" --_000_9E32478DFA9976438E7A22F69B08FF921EABC22AOPEXCLILMA4corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi WG, I'm facing an interop issue between two PCEP implementations. PCE from vendor1 sends the PCInitiate for an SRTE LSP using the PST=3D1 in = the SRP Object. PCC from vendor2 handles it correctly and delegates the LSP to the PCE usin= g PST=3D1. When the PCE sends a PCUpdate message, it does not set the PST TLV in the S= RP Object. The PCC rejects the PCUpdate because of a bad ERO subobject type. It reads = the PCUpdate as having PST type=3D0. Based on my reading of draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segme= nt-routing. PST draft tells that for the PCE Initiation case, the PCE MAY include the P= ST if the message does not ave any other means of indicating the path setup= type. SR draft tells "In order to setup an SR-TE LSP using SR, RP or SRP o= bject MUST include PATH-SETUP-TYPE TLV". Unfortunately it does not specify = explicitly in which message. From a reading perspective, we can understand = from "In order to setup" that it applies to the PCInitiate message. But not= hing tells about the PCUpdate message. However draft-ietf-pce-lsp-setup-type tells for the stateful PCE case that:= "if the path setup type cannot be unambiguously inferred from ERO or any o= ther object or TLV, PATH-SETUP-TYPE TLV MAY be used in PCRpt and PCUpd mess= ages." In our case (PCE initiated) as the LSP has initially been setup through a P= CInitiate message having the PST TLV, the PCC can infer that futher updates= will use EROs associated with the same PST. Or do we allow to change the PST through PCUpdate messages which may requir= e to always set the PST ? (moving from RSVP-TE to SR or the other way for = a particular LSP) I would like to hear opinions of the WG on that problem ? Thanks, Brgds, [Orange logo] Stephane Litkowski Network Architect Orange/SCE/EQUANT/OINIS/NET Orange Expert Future Networks phone: +33 2 23 06 49 83 NEW ! mobile: +33 6 71 63 27 50 NEW ! stephane.litkowski@orange.com ___________________________________________________________________________= ______________________________________________ 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. --_000_9E32478DFA9976438E7A22F69B08FF921EABC22AOPEXCLILMA4corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi WG,

 

I’m facing an interop issue between two PCEP i= mplementations.

PCE from vendor1 sends the PCInitiate for an SRTE LS= P using the PST=3D1 in the SRP Object.

PCC from vendor2 handles it correctly and delegates = the LSP to the PCE using PST=3D1.

When the PCE sends a PCUpdate message, it does not s= et the PST TLV in the SRP Object.

The PCC rejects the PCUpdate because of a bad ERO su= bobject type. It reads the PCUpdate as having PST type=3D0.

 

Based on my reading of draft-ietf-pce-lsp-setup-type= & draft-ietf-pce-segment-routing.

PST draft tells that for the PCE Initiation case, th= e PCE MAY include the PST if the message does not ave any other means of in= dicating the path setup type. SR draft tells “In order to setup an SR= -TE LSP using SR, RP or SRP object MUST include PATH-SETUP-TYPE TLV”. Unfortunately it does not specify expl= icitly in which message. From a reading perspective, we can understand from= “In order to setup” that it applies to the PCInitiate message.= But nothing tells about the PCUpdate message.

However draft-ietf-pce-lsp-setup-type tells for the = stateful PCE case that: “if the path setup type cannot be unambiguous= ly inferred from ERO or any other object or TLV, PATH-SETUP-TYPE TLV MAY be= used in PCRpt and PCUpd messages.”

In our case (PCE initiated) as the LSP has initially= been setup through a PCInitiate message having the PST TLV, the PCC can in= fer that futher updates will use EROs associated with the same PST.

 

Or do we allow to change the PST through PCUpdate me= ssages which may require to  always set the PST ? (moving from RSVP-TE= to SR or the other way for a particular LSP)

 

I would like to hear opinions of the= WG on that problem ?

 

Thanks,

 

Brgds,

 

 

3D"O=

 <= o:p>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET

Orange Expert Future Networks=

phone: +33 2 23 06 49 83  NEW !
mobile: +33 6 71 63 27 50  NEW = ;!
s= tephane.litkowski@orange.com

 

______________________________________________________________________=
___________________________________________________

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.
--_000_9E32478DFA9976438E7A22F69B08FF921EABC22AOPEXCLILMA4corp_-- --_004_9E32478DFA9976438E7A22F69B08FF921EABC22AOPEXCLILMA4corp_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=1093; creation-date="Mon, 13 Nov 2017 16:38:14 GMT"; modification-date="Mon, 13 Nov 2017 16:38:14 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAAoACgDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD1O48f afbXMsDWl0WjcoSAuDg49aj/AOFiad/z53f5L/jXB6r/AMhe9/67v/M1Ur5Geb4pSaTX3H2dPJcJ KCbT+89H/wCFiad/z53f5L/jR/wsTTv+fO7/ACX/ABrziip/tnFd19xX9iYPs/vPR/8AhYmnf8+d 3+S/40V5xRR/bOK7r7g/sTB9n95b1X/kL3v/AF3f+ZqpW3Po17qGo3s0Cx7DdPGpeQLvbOdq56mo R4d1EmEFYVaZdyI0oDY9cda450KspNqLO2niKUYJOSvbv5GVRWwPC+qmR4zFErI/l4aUDc2A2B68 GmDw7qTQrIIkJZVYR+YN+GOAdvuan6tW/lf3FfWqH86+8yqK2bjQG0+EvqU/2dmyIgieYGI6gkHg 0VM6M4O0tGVCtCavF3R1o8Oa7BcTtbXdh5TztPGJYyxjY9xxwcUxfDniNZ1m+32DOIPs+WjJymc8 8dc96KK+y/s+l3f3s+J/tKt2X3Ie+geJZJlla/0/eswmH7s/eChfT0FXDo2rDTRCktoLoIqfaCxy NrZGPlz+GaKKpYGmr6vXzJlj6sraLTyMrUPCOuant+03lh8pJ+RGXJPUniiiisZ5Thpvmldv1N4Z xioLljZL0R//2Q== --_004_9E32478DFA9976438E7A22F69B08FF921EABC22AOPEXCLILMA4corp_-- From nobody Mon Nov 13 09:18:38 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 CC509129B17 for ; Mon, 13 Nov 2017 09:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 gX8r41fdRqsV for ; Mon, 13 Nov 2017 09:18:34 -0800 (PST) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C266A129B16 for ; Mon, 13 Nov 2017 09:18:33 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 11C5D409F7; Mon, 13 Nov 2017 18:18:32 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.59]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id DD4D71A005F; Mon, 13 Nov 2017 18:18:31 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c%19]) with mapi id 14.03.0361.001; Mon, 13 Nov 2017 18:18:29 +0100 From: To: DUGEON Olivier IMT/OLN , Daniele Ceccarelli , "pce@ietf.org" Thread-Topic: [Pce] draft-ietf-pce-association-diversity: relaxing constraint Thread-Index: AdNcVzD/M9KOzAxBQO6wN/0nS1cgMgAAiaaQAABEwvAADoitAAADN6OA Date: Mon, 13 Nov 2017 17:18:28 +0000 Message-ID: <29540_1510593512_5A09D3E7_29540_488_1_87fe0df4-6382-476e-b0d7-edea0347d307@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <7688_1510561338_5A09563A_7688_271_1_9E32478DFA9976438E7A22F69B08FF921EABBDF1@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <2637_1510562443_5A095A8B_2637_480_1_9E32478DFA9976438E7A22F69B08FF921EABBE39@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <9f1405b5-b166-9ad0-304c-b17d1830ae78@orange.com> In-Reply-To: <9f1405b5-b166-9ad0-304c-b17d1830ae78@orange.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/related; boundary="_004_87fe0df46382476eb0d7edea0347d307OPEXCLILM43corporateadr_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: Re: [Pce] draft-ietf-pce-association-diversity: relaxing constraint 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, 13 Nov 2017 17:18:37 -0000 --_004_87fe0df46382476eb0d7edea0347d307OPEXCLILM43corporateadr_ Content-Type: multipart/alternative; boundary="_000_87fe0df46382476eb0d7edea0347d307OPEXCLILM43corporateadr_" --_000_87fe0df46382476eb0d7edea0347d307OPEXCLILM43corporateadr_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgT2xpdmllciwNCg0KSSBkbyBub3QgYWdyZWUgd2l0aCB3aGF0IHlvdSBtZW50aW9uZWQuDQpU aGUgbWV0cmljIG9iamVjdCBpcyBkZWZpbmVkIChidXQgbm90IGxpbWl0ZWQgdG8pIHRvIHNldCBh IGNvbnN0cmFpbnQgb24gdGhlIG1ldHJpYzogd2hhdCBJIHNob3VsZCBvcHRpbWl6ZSBmb3IgKElH UCBtZXRyaWMsIFRFIG1ldHJpYywgYm90aOKApikgYW5kIGlzIHRoZXJlIGEgYm91bmRhcnkgdGhh dCBJIHNob3VsZCBub3QgZXhjZWVkLg0KTm90aGluZyBzYXlzIHRoYXQgdGhlIGNvbnN0cmFpbnQg Y2FuIGJlIHJlbGF4ZWQgYnkgdGhlIFBDRS4gSWYgYSBQQ0UgcmVjZWl2ZXMgYSBjb21wdXRhdGlv biByZXF1ZXN0IG9yIG5lZWRzIHRvIGNvbXB1dGUgYSBwYXRoIGZvciBhbiBMU1AgaGF2aW5nIGZv ciBpbnN0YW5jZSBhIG1ldHJpYyBvYmplY3Qgd2l0aCB0eXBlPVRFIGFuZCBib3VuZD0xMDAuIElm IGl0IGNhbm5vdCBmb3VuZCBhIHBhdGgsIGl0IHdpbGwgcmV0dXJuIE5PLVBBVEggd2l0aG91dCBy ZWxheGluZyB0aGUgY29uc3RyYWludC4gUmVsYXhpbmcgdGhlIGNvbnN0cmFpbnQgbWVhbnMgdGhh dCB0aGUgUENDIGFsbG93cyB0aGUgUENFIHRvIGNvbXB1dGUgYSBwYXRoIHdpdGhvdXQgdXNpbmcg dGhlIHJlcXVlc3RlZCBjb25zdHJhaW50IGlmIHRoZSBQQ0UgY2Fubm90IGZpbmQgYSBwYXRoIHRo YXQgZmlsbHMgdGhpcyBjb25zdHJhaW50Lg0KU28gaW4gY2FzZSBvZiB0aGUgTUVUUklDIG9iamVj dCBhbmQgdGhlIGJvdW5kYXJ5IGNhc2UsIGlmIHRoZSBQQ0MgYWxsb3dzIHRoZSBQQ0UgdG8gcmVs YXggdGhlIGNvbnN0cmFpbnQsIGlmIGl0IGRvZXMgbm90IGZpbmQgYSBwYXRoIGZpdHRpbmcgdGhl IGJvdW5kYXJ5LCBpdCB3aWxsIHByb3ZpZGUgYSBwYXRoIGV4Y2VlZGluZyB0aGlzIGJvdW5kYXJ5 IGluc3RlYWQgb2YgcmV0dXJuaW5nIE5PLVBBVEguDQoNCk5vdyB0aGUgTUVUUklDIG9iamVjdCBk b2VzIG5vdCBoYXZlIGFueXRoaW5nIHRvIGRvIHdpdGggdGhlIGRpc2pvaW50bmVzcy4gRXhjZXB0 IHRoYXQgd2UgY2FuIGNvbWJpbmUgYm90aCBpZiBuZWVkZWQgIQ0KDQpGb3IgdGhlIGRpc2pvaW50 bmVzcywgd2UgaGF2ZSB0d28gY2FzZXMgd2hlbiB0aGUgUENDIGFsbG93ZWQgdGhlIFBDRSB0byBy ZWxheCB0aGUgY29uc3RyYWludDoNCg0KLSAgICAgICAgICBUaGUgUENFIGhhcyBzdWNjZXNzZnVs bHkgY29tcHV0ZWQgYSBkaXNqb2ludCBwYXRoIGJ1dCB3aXRoIGEgbG93ZXIgZGlzam9pbnRuZXNz IHR5cGUgKGxpbmsgaW5zdGVhZCBvZiBub2RlIGZvciBpbnN0YW5jZSkgPT4gdGhpcyBjb3VsZCBi ZSBzZWVuIGFzIGEgcGFydGlhbGx5IHJlbGF4ZWQgY29uc3RyYWludCBhbmQgSSBhZ3JlZSB0aGF0 IHRoZSBzdGF0ZSBjb3VsZCBiZSBzZW50IGJ5IGFkZGluZyB0aGUgYXNzb2NpYXRpb24gZ3JvdXAg YW5kIGZpbGxpbmcgdGhlIOKAnGNvbXB1dGVkIHN0YXRl4oCdIG9mIHRoZSBkaXNqb2ludG5lc3Mg aW4gdGhlIERJU0pPSU5UTkVTUy1JTkZPUk1BVElPTiBUTFYgKE1FVFJJQyBvYmplY3QgaGFzIG5v dGhpbmcgdG8gZG8gaGVyZSkuDQoNCi0gICAgICAgICAgVGhlIFBDRSBjYW5ub3QgY29tcHV0ZSBh IGRpc2pvaW50IHBhdGggYXQgYWxsIGFuZCBjb21wbGV0ZWx5IHJlbGF4ZWQgdGhlIGNvbnN0cmFp bnQuDQoNClNvIHdlIGRvIG5vdCBoYXZlIGFueSB3YXkgeWV0IChBRkFJSykgdG8gdGVsbCB0aGUg UENFIHRoYXQgYSBwYXJ0aWN1bGFyIGNvbnN0cmFpbnQgY2FuIGJlIHJlbGF4ZWQgKGFub3RoZXIg ZXhhbXBsZSBpcyB0aGUgYmFuZHdpZHRoIGNvbnN0cmFpbnQgPT4gSSBkbyBub3QgdGhpbmsgdGhh dCBpdCBpcyBhIGdvb2QgZXhhbXBsZSBidXQgd2h5IG5vdOKApikuDQpUaGVuIHRoZSBQQ0UgbmVl ZHMgdG8gdGVsbCB0aGUgUENDIHRoYXQgaXQgaGFzIHJlbGF4ZWQgYSBjb25zdHJhaW50ID0+IHRo aXMgY2FuIGJlIGRlZHVjZWQgZnJvbSBhIOKAnGNvbXB1dGVkIHN0YXRl4oCdIHByb3ZpZGVkIGJ5 IHRoZSBQQ0UgZm9yIGVhY2ggY29uc3RyYWludCwgYnV0IGEgbW9yZSBjbGVhciBpbmZvcm1hdGlv biBtYXkgYmUgYmV0dGVyIChwb3NzaWJseSBpbiBhZGRpdGlvbiB0byB0aGUg4oCcY29tcHV0ZWQg c3RhdGXigJ0pLg0KDQpCcmdkcywNCg0KRnJvbTogT2xpdmllciBEdWdlb24gW21haWx0bzpvbGl2 aWVyLmR1Z2VvbkBvcmFuZ2UuY29tXQ0KU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTQsIDIwMTcg MDA6MzINClRvOiBMSVRLT1dTS0kgU3RlcGhhbmUgT0JTL09JTklTOyBEYW5pZWxlIENlY2NhcmVs bGk7IHBjZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtQY2VdIGRyYWZ0LWlldGYtcGNlLWFzc29j aWF0aW9uLWRpdmVyc2l0eTogcmVsYXhpbmcgY29uc3RyYWludA0KDQoNCkhlbGxvIFN0ZXBoYW5l LCBhbGwNCg0KSW4gZmFjdCwgdGhlc2UgbWVjaGFuaXNtIGlzIGFscmVhZHkgYXZhaWxhYmxlIGlu IFJGQyA1NDQwLg0KDQpGaXJzdCwgTWV0cmljIE9iamVjdCBoYXMgYmVlbiBkZWZpbmVkIHdpdGgg YSBCIGZsYWcgdG8gaW5kaWNhdGUgaWYgdGhpcyBtZXRyaWMgKGkuZS4gY29uc3RyYWludCkgbXVz dCBiZSBib3VuZCBvciBub3QuIFNlZSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTQ0 MCNzZWN0aW9uLTcuOC4gVGVybWlub2xvZ3kgaXMgbm90IGV4YWN0bHkgdGhlIHNhbWUsIGJ1dCwg dGhlIGdvYWwgaXMgc2ltaWxhci4gSXQgYWxsb3dzIGEgUENDIHRvIGluZGljYXRlIHRvIHRoZSBQ Q0UgaWYgdGhlIG1ldHJpYyBtdXN0IGJlIHN0cmljdGx5IHJlc3BlY3RlZCBvciBub3QuIE5vdGUs IGFsc28gdGhhdCBpdCBpcyBwb3NzaWJsZSB0byBpbmRpY2F0ZSBtYW55IHNpbWlsYXIgTWV0cmlj IG9iamVjdCB3aXRoIGRpZmZlcmVudCB2YWx1ZSwgYXMgd2VsbCBhcyBkaWZmZXJlbnQgdmFsdWUg Zm9yIHRoZSBCLWZsYWcgZm9yIG1vcmUgZmxleGliaWxpdHkuIEZvciBleGFtcGxlLCBmb3IgdGhl IERpc2pvaW50bmVzcywgd2UgY291bGQgaW1hZ2UgYSBmaXJzdCBNZXRyaWMgd2l0aCBTUkxHIGRp c2pvaW50IHBhdGggYW5kIEItRmxhZyBzZXQgdG8gb25lIGFuZCBhIHNlY29uZCBvbmUgd2l0aCBT UkxHLWFuZC1Ob2RlIGRpc2pvaW50IHBhdGggd2l0aCBCLUZsYWcgY2xlYXIuIFRoaXMgaW5kaWNh dGUgdG8gdGhlIFBDRSB0aGF0IHdlIHdhbnQgYXQgbGVhc3QgYW4gU1JMRyBkaXNqb2ludCBwYXRo LCBidXQgaWYgaXQgY291bGQgY29tcHV0ZSBhbiBTUkxHIGFuZCBOb2RlIGRpc2pvaW50IHBhdGgg d2UnbGwgYmUgdmVyeSBoYXBweS4NCg0KUENDIGNvdWxkIGFsc28gc2V0IHRoZSBDLUZsYWcgdG8g aW5kaWNhdGUgdG8gdGhlIFBDRSB0aGF0IGl0IHdvdWxkIGluIHR1cm4gdGhlIGNvbXB1dGVkIE1l dHJpYy4gRm9yIGRpc2pvaW50bmVzcywgaXQgY291bGQgaW5kaWNhdGUgd2hpY2ggdHlwZSBvZiBk aXNqb2ludG5lc3MgaXQgc3VjY2Vzc2Z1bGx5IHVzZWQgZm9yIHRoZSBjb21wdXRlZCBwYXRoLg0K DQpJZiBhIG1ldHJpYyBjb3VsZCBub3QgYmUgbWV0LCBQQ0Ugd2lsbCByZXR1cm4gYSBOby1QQVRI IG9iamVjdCB3aXRoIHRoZSBkZWZhdWx0IG1ldHJpYyB0byBpbmRpY2F0ZSB3aGljaCBjb25zdHJh aW50cyBjb3VsZCBub3QgYmUgbWV0Lg0KDQpOb3csIHRvIGluZGljYXRlIHRoYXQgYSBtZXRyaWMg KGNvbnN0cmFpbnQpIHNob3VsZCBiZSByZWxheGVkLCB0aGVyZSBpcyAyIHBvc3NpYmlsaXRpZXM6 IHNlbmQgYSBuZXcgUENFUCBtZXNzYWdlIHdpdGggdGhlIEItRmxhZyBvZiB0aGlzIE1ldHJpYyBj bGVhcmVkLCBvciBhIFBDRVAgbWVzc2FnZSB3aXRob3V0IHRoZSBnaXZlbiBNZXRyaWMuIHNlZSBh Z2FpbiBSRkMgNTQ0MCBlbmQgb2Ygc2VjdGlvbiA3LjggcGFnZSAzOCAoaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzU0NDAjcGFnZS0zOCkuDQoNClNvLCBJIHRoaW5rIHRoZSBnZW5lcmlj IG1lY2hhbmlzbSBpcyBhbHJlYWR5IGF2YWlsYWJsZSBhbmQgdG8gaW5oZXJpdCBmcm9tIHRoaXMg YmVoYXZpb3VyLCB0aGUgRGlzam9pbnRlbmVzcyBUTFYgc2hvdWxkIGJlIGEgbmV3IE1ldHJpYyBP YmplY3QgaW5zdGVhZCBvZiBhIGRlZGljYXRlZCBuZXcgVExWLiBCdXQsIEkgdW5kZXJzdGFuZCB0 aGF0IHRoZSBkcmFmdCBhbmQgc29sdXRpb24gaGF2ZSBub3QgYmVlbiBkZXNpZ24gd2l0aCB0aGlz IGluIG1pbmQuIFNvIEkgbGV0IGF1dGhvcnMgZGVjaWRlZCBpZiBpdCBpcyBmZWFzaWJsZSBvciBu b3QuDQoNClJlZ2FyZHMNCg0KT2xpdmllcg0KDQpMZSAxMy8xMS8yMDE3IMOgIDA5OjQwLCBzdGVw aGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTxtYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5n ZS5jb20+IGEgw6ljcml0IDoNCkhpIERhbmllbGUsDQoNClRoYW5rcyBmb3IgeW91ciBmZWVkYmFj ay4NCklmIHdlIGdvIHRvIGEgZ2VuZXJpYyBtZWNoYW5pc20sIElNTywgdGhpcyBzaG91bGQgYmUg YWRkcmVzc2VkIGluIGEgc2VwYXJhdGUgZG9jdW1lbnQuIEluIGFkZGl0aW9uLCB3ZSBuZWVkIGEg Z2VuZXJpYyB3YXkgZm9yIGEgUENDIHRvIHRlbGwgdGhlIFBDRSB0aGF0IGEgY29uc3RyYWludCBp cyByZWxheGFibGUgb3Igc3RyaWN0LiBGb3IgZGl2ZXJzaXR5LCB3ZSBoYXZlIGEgZGVkaWNhdGVk IGZsYWcgd2l0aGluIHRoZSBESVNKT0lOVE5FU1MgVExWIGZvciB0aGF0IHB1cnBvc2UuIE1heWJl IHdlIHNob3VsZCBtYWtlIGl0IGdlbmVyaWMgYXMgd2VsbC4NCg0KRG8geW91IGFncmVlID8NCg0K QnJnZHMsDQoNCg0KRnJvbTogRGFuaWVsZSBDZWNjYXJlbGxpIFttYWlsdG86ZGFuaWVsZS5jZWNj YXJlbGxpQGVyaWNzc29uLmNvbV0NClNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMTMsIDIwMTcgMTY6 MzMNClRvOiBMSVRLT1dTS0kgU3RlcGhhbmUgT0JTL09JTklTOyBwY2VAaWV0Zi5vcmc8bWFpbHRv OnBjZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBkcmFmdC1pZXRmLXBjZS1hc3NvY2lhdGlvbi1k aXZlcnNpdHk6IHJlbGF4aW5nIGNvbnN0cmFpbnQNCg0KSGkgU3RlcGhhbmUsDQoNCmRlZmluaXRl bHkgbmVlZGVkLg0KTXkgb3BpbmlvbiBpcyB0aGF0IGEgd2F5IHRvIHNheSB0aGF0IGEgY29uc3Ry YWludCB3YXMgcmVsYXhlZCBpcyB2ZXJ5IHVzZWZ1bC4gQXMgeW91IHNhaWQgdGhlcmUgYXJlIGRp ZmZlcmVudCB0eXBlcyBvZiBjb25zdHJhaW50cyB0aGF0IGNhbiBiZSByZWxheGVkLCBlLmcuIGRp dmVyc2l0eSBvciBhIFRFIGJvdW5kLg0KSSB3b3VsZCBtYWtlIHRoZSBUTFYgYXMgZ2VuZXJpYyBh cyBwb3NzaWJsZSBhbmQgbWF5YmUgZGVmaW5lIG11bHRpcGxlIHN1Yi1UTFYgKG9yIG1heWJlIGp1 c3QgbXVsdGlwbGUgdmFsdWVzKSBkZXBlbmRpbmcgb24gdGhlIGNvbnN0cmFpbnQgdGhhdCB3YXMg cmVsYXhlZC4NCg0KQlINCkRhbmllbGUNCg0KRnJvbTogUGNlIFttYWlsdG86cGNlLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTxtYWls dG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20+DQpTZW50OiBsdW5lZMOsIDEzIG5vdmVt YnJlIDIwMTcgMTY6MjINClRvOiBwY2VAaWV0Zi5vcmc8bWFpbHRvOnBjZUBpZXRmLm9yZz4NClN1 YmplY3Q6IFtQY2VdIGRyYWZ0LWlldGYtcGNlLWFzc29jaWF0aW9uLWRpdmVyc2l0eTogcmVsYXhp bmcgY29uc3RyYWludA0KDQpIaSBXRywNCg0KSW4gdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIGRyYWZ0 LWlldGYtcGNlLWFzc29jaWF0aW9uLWRpdmVyc2l0eSB3ZSBhZGRlZCBhIG5ldyBUTFYgY2FsbGVk IFJFTEFYRUQtQ09OU1RSQUlOVC1UTFYgdG8gYmUgdXNlZCBpbiBMU1AgT2JqZWN0IG9mIGEgUENV cGRhdGUgbWVzc2FnZSB3aGVuIHRoZSBQQ0UgcmVsYXhlcyB0aGUgcmVxdWVzdGVkIGRpc2pvaW50 bmVzcyBjb25zdHJhaW50LiBGb3IgaW5zdGFuY2UsIGlmIGEgUENDIHJlcXVlc3RzIGFuIFNSTEcg ZGlzam9pbnQgcGF0aCBidXQgdGhlIFBDRSBjYW5ub3QgZmluZCBpdCwgaXQgbWF5IHJlbGF4IHRo ZSBjb25zdHJhaW50IChpZiBQQ0MgYWxsb3dzIGl0IHRvIGRvIHNvKSBhbmQgdGh1cyBpbmZvcm1z IHRoZSBQQ0MgdGhyb3VnaCB0aGUgUkVMQVhFRC1DT05TVFJBSU5ULVRMVi4NCg0KSU1PLCB0aGlz IGtpbmQgb2YgYmVoYXZpb3IgaXMgbW9yZSBnZW5lcmljIHJhdGhlciB0aWVkIHRvIHRoZSBkaXNq b2ludG5lc3MgdXNlIGNhc2UuIEl0IG1heSBiZSB1c2VkIHdpdGggb3RoZXIgY29uc3RyYWludHMg YXMgd2VsbC4NCg0KVGhlIHF1ZXN0aW9uIGlzOiBkbyB3ZSBuZWVkIHRvIGtlZXAgdGhpcyBSRUxB WEVELUNPTlNUUkFJTlQtVExWIGluIHRoZSBhc3NvY2lhdGlvbi1kaXZlcnNpdHkgZHJhZnQgPyBv ciBkbyB3ZSBkcm9wIGl0ID8gb3IgZG8gd2UgZGVmaW5lIGEgVExWIG1vcmUgc3BlY2lmaWMgdG8g dGhlIGFzc29jaWF0aW9uIGRpdmVyc2l0eSBzdGF0ZSA/IG1heWJlIHdlIGNhbiByZXVzZSB0aGUg YXNzb2NpYXRpb24gZ3JvdXAgb2JqZWN0IGluIHRoZSBQQ1VwZGF0ZSBtZXNzYWdlIGluY2x1ZGlu ZyB0aGUgRElTSk9JTlRORVNTLUlORk9STUFUSU9OLVRMViB3aGljaCByZWZsZWN0cyB0aGUgYWN0 dWFsIGRpc2pvaW50bmVzcyBzdHlsZSB1c2VkIGJ5IHRoZSBQQ0UuDQoNCk9waW5pb25zID8NCg0K DQpCcmdkcywNCg0KU3RlcGhhbmUNCg0KDQpbT3JhbmdlIGxvZ29dPGh0dHA6Ly93d3cub3Jhbmdl LmNvbS8+DQoNClN0ZXBoYW5lIExpdGtvd3NraQ0KTmV0d29yayBBcmNoaXRlY3QNCk9yYW5nZS9T Q0UvRVFVQU5UL09JTklTL05FVA0KT3JhbmdlIEV4cGVydCBGdXR1cmUgTmV0d29ya3MNCnBob25l OiArMzMgMiAyMyAwNiA0OSA4MyA8aHR0cHM6Ly9tb25zaS5zc28uZnJhbmNldGVsZWNvbS5mci9p bmRleC5hc3A/dGFyZ2V0PWh0dHAlM0ElMkYlMkZjbGljdm9pY2Uuc3NvLmZyYW5jZXRlbGVjb20u ZnIlMkZDbGljdm9pY2VWMiUyRlRvb2xCYXIuZG8lM0ZhY3Rpb24lM0RkZWZhdWx0JTI2cm9vdHNl cnZpY2UlM0RTSUdOQVRVUkUlMjZ0byUzRCszMyUyMDIlMjAyMyUyMDI4JTIwNDklMjA4MyUyMD4g IE5FVyAhDQptb2JpbGU6ICszMyA2IDcxIDYzIDI3IDUwIDxodHRwczovL21vbnNpLnNzby5mcmFu Y2V0ZWxlY29tLmZyL2luZGV4LmFzcD90YXJnZXQ9aHR0cCUzQSUyRiUyRmNsaWN2b2ljZS5zc28u ZnJhbmNldGVsZWNvbS5mciUyRkNsaWN2b2ljZVYyJTJGVG9vbEJhci5kbyUzRmFjdGlvbiUzRGRl ZmF1bHQlMjZyb290c2VydmljZSUzRFNJR05BVFVSRSUyNnRvJTNEKzMzJTIwNiUyMDM3JTIwODYl MjA5NyUyMDUyJTIwPiAgTkVXICENCnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPG1haWx0 bzpzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbT4NCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0KDQpDZSBt ZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1h dGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMN Cg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRp b24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUg c2lnbmFsZXINCg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBw aWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGli bGVzIGQnYWx0ZXJhdGlvbiwNCg0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUg c2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0K DQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlk ZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5 IGxhdzsNCg0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3 aXRob3V0IGF1dGhvcmlzYXRpb24uDQoNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwg aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5n ZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hh bmdlZCBvciBmYWxzaWZpZWQuDQoNClRoYW5rIHlvdS4NCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVz c2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRp b25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQoN CnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9u LiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNp Z25hbGVyDQoNCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGll Y2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxl cyBkJ2FsdGVyYXRpb24sDQoNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNp IGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0K DQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBs YXc7DQoNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0 aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGlu IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cy4NCg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2Ug aXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5n ZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5b3UuDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClBjZSBtYWlsaW5nIGxpc3QNCg0KUGNl QGlldGYub3JnPG1haWx0bzpQY2VAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcGNlDQoNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMg am9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVz IG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4 cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNl IG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIg ZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2Vz IGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRl Y2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRl Zm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhh dCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVk LCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVs ZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFs dGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBt b2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== --_000_87fe0df46382476eb0d7edea0347d307OPEXCLILM43corporateadr_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAw IDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpVYnVudHU7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAg MCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4gXCwg c2VyaWYiOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGlu aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlw ZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9 DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6 YmxhY2s7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFy IjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4w cHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30N CnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJh Z3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1h dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi Ow0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjYNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjExNDE1MzMyNDY7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOjEwNzM1NDE5MTggNjUwNjQ2MTc4IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxl dmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6OTU7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFt aWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0K QGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGww OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRv bTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdj b2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+SGkgT2xpdmllciw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPkkgZG8gbm90IGFncmVlIHdpdGggd2hhdCB5b3UgbWVudGlvbmVkLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5UaGUgbWV0cmljIG9iamVjdCBpcyBkZWZpbmVkIChidXQgbm90IGxpbWl0ZWQgdG8p IHRvIHNldCBhIGNvbnN0cmFpbnQgb24gdGhlIG1ldHJpYzogd2hhdCBJIHNob3VsZCBvcHRpbWl6 ZSBmb3IgKElHUCBtZXRyaWMsIFRFIG1ldHJpYywgYm90aOKApikgYW5kIGlzIHRoZXJlIGEgYm91 bmRhcnkgdGhhdCBJIHNob3VsZCBub3QgZXhjZWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Ob3RoaW5nIHNh eXMgdGhhdCB0aGUgY29uc3RyYWludCBjYW4gYmUgcmVsYXhlZCBieSB0aGUgUENFLiBJZiBhIFBD RSByZWNlaXZlcyBhIGNvbXB1dGF0aW9uIHJlcXVlc3Qgb3IgbmVlZHMgdG8gY29tcHV0ZSBhIHBh dGggZm9yIGFuIExTUCBoYXZpbmcgZm9yIGluc3RhbmNlIGEgbWV0cmljIG9iamVjdCB3aXRoIHR5 cGU9VEUgYW5kIGJvdW5kPTEwMC4gSWYgaXQNCiBjYW5ub3QgZm91bmQgYSBwYXRoLCBpdCB3aWxs IHJldHVybiBOTy1QQVRIIHdpdGhvdXQgcmVsYXhpbmcgdGhlIGNvbnN0cmFpbnQuIFJlbGF4aW5n IHRoZSBjb25zdHJhaW50IG1lYW5zIHRoYXQgdGhlIFBDQyBhbGxvd3MgdGhlIFBDRSB0byBjb21w dXRlIGEgcGF0aCB3aXRob3V0IHVzaW5nIHRoZSByZXF1ZXN0ZWQgY29uc3RyYWludCBpZiB0aGUg UENFIGNhbm5vdCBmaW5kIGEgcGF0aCB0aGF0IGZpbGxzIHRoaXMgY29uc3RyYWludC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+U28gaW4gY2FzZSBvZiB0aGUgTUVUUklDIG9iamVjdCBhbmQgdGhlIGJvdW5kYXJ5 IGNhc2UsIGlmIHRoZSBQQ0MgYWxsb3dzIHRoZSBQQ0UgdG8gcmVsYXggdGhlIGNvbnN0cmFpbnQs IGlmIGl0IGRvZXMgbm90IGZpbmQgYSBwYXRoIGZpdHRpbmcgdGhlIGJvdW5kYXJ5LCBpdCB3aWxs IHByb3ZpZGUgYSBwYXRoIGV4Y2VlZGluZyB0aGlzIGJvdW5kYXJ5IGluc3RlYWQNCiBvZiByZXR1 cm5pbmcgTk8tUEFUSC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk5vdyB0 aGUgTUVUUklDIG9iamVjdCBkb2VzIG5vdCBoYXZlIGFueXRoaW5nIHRvIGRvIHdpdGggdGhlIGRp c2pvaW50bmVzcy4gRXhjZXB0IHRoYXQgd2UgY2FuIGNvbWJpbmUgYm90aCBpZiBuZWVkZWQgITxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Rm9yIHRoZSBkaXNqb2ludG5lc3Ms IHdlIGhhdmUgdHdvIGNhc2VzIHdoZW4gdGhlIFBDQyBhbGxvd2VkIHRoZSBQQ0UgdG8gcmVsYXgg dGhlIGNvbnN0cmFpbnQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48c3Bh biBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhlIFBDRSBoYXMgc3VjY2Vzc2Z1bGx5IGNvbXB1dGVk IGEgZGlzam9pbnQgcGF0aCBidXQgd2l0aCBhIGxvd2VyIGRpc2pvaW50bmVzcyB0eXBlIChsaW5r IGluc3RlYWQgb2Ygbm9kZSBmb3IgaW5zdGFuY2UpID0mZ3Q7IHRoaXMgY291bGQgYmUgc2VlbiBh cyBhIHBhcnRpYWxseSByZWxheGVkIGNvbnN0cmFpbnQgYW5kIEkgYWdyZWUgdGhhdCB0aGUNCiBz dGF0ZSBjb3VsZCBiZSBzZW50IGJ5IGFkZGluZyB0aGUgYXNzb2NpYXRpb24gZ3JvdXAgYW5kIGZp bGxpbmcgdGhlIOKAnGNvbXB1dGVkIHN0YXRl4oCdIG9mIHRoZSBkaXNqb2ludG5lc3MgaW4gdGhl IERJU0pPSU5UTkVTUy1JTkZPUk1BVElPTiBUTFYgKE1FVFJJQyBvYmplY3QgaGFzIG5vdGhpbmcg dG8gZG8gaGVyZSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEi PjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+VGhlIFBDRSBjYW5ub3QgY29tcHV0ZSBhIGRpc2pvaW50IHBh dGggYXQgYWxsIGFuZCBjb21wbGV0ZWx5IHJlbGF4ZWQgdGhlIGNvbnN0cmFpbnQuDQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlNvIHdlIGRvIG5vdCBoYXZlIGFueSB3YXkg eWV0IChBRkFJSykgdG8gdGVsbCB0aGUgUENFIHRoYXQgYSBwYXJ0aWN1bGFyIGNvbnN0cmFpbnQg Y2FuIGJlIHJlbGF4ZWQgKGFub3RoZXIgZXhhbXBsZSBpcyB0aGUgYmFuZHdpZHRoIGNvbnN0cmFp bnQgPSZndDsgSSBkbyBub3QgdGhpbmsgdGhhdCBpdCBpcyBhIGdvb2QgZXhhbXBsZSBidXQgd2h5 IG5vdOKApikuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoZW4gdGhlIFBDRSBuZWVkcyB0byB0ZWxsIHRoZSBQ Q0MgdGhhdCBpdCBoYXMgcmVsYXhlZCBhIGNvbnN0cmFpbnQgPSZndDsgdGhpcyBjYW4gYmUgZGVk dWNlZCBmcm9tIGEg4oCcY29tcHV0ZWQgc3RhdGXigJ0gcHJvdmlkZWQgYnkgdGhlIFBDRSBmb3Ig ZWFjaCBjb25zdHJhaW50LCBidXQgYSBtb3JlIGNsZWFyIGluZm9ybWF0aW9uIG1heSBiZSBiZXR0 ZXIgKHBvc3NpYmx5DQogaW4gYWRkaXRpb24gdG8gdGhlIOKAnGNvbXB1dGVkIHN0YXRl4oCdKS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkJyZ2RzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBPbGl2aWVyIER1Z2VvbiBbbWFpbHRvOm9saXZpZXIu ZHVnZW9uQG9yYW5nZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTm92ZW1iZXIg MTQsIDIwMTcgMDA6MzI8YnI+DQo8Yj5Ubzo8L2I+IExJVEtPV1NLSSBTdGVwaGFuZSBPQlMvT0lO SVM7IERhbmllbGUgQ2VjY2FyZWxsaTsgcGNlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbUGNlXSBkcmFmdC1pZXRmLXBjZS1hc3NvY2lhdGlvbi1kaXZlcnNpdHk6IHJlbGF4aW5n IGNvbnN0cmFpbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VWJ1bnR1JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5IZWxsbyBTdGVw aGFuZSwgYWxsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1VidW50dSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+SW4gZmFjdCwgdGhlc2Ug bWVjaGFuaXNtIGlzIGFscmVhZHkgYXZhaWxhYmxlIGluIFJGQyA1NDQwLg0KPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1VidW50dSZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+Rmlyc3QsIE1ldHJpYyBPYmplY3QgaGFzIGJlZW4gZGVmaW5l ZCB3aXRoIGEgQiBmbGFnIHRvIGluZGljYXRlIGlmIHRoaXMgbWV0cmljIChpLmUuIGNvbnN0cmFp bnQpIG11c3QgYmUgYm91bmQgb3Igbm90LiBTZWUNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM1NDQwI3NlY3Rpb24tNy44Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNTQ0MCNzZWN0aW9uLTcuODwvYT4uIFRlcm1pbm9sb2d5IGlzIG5vdCBleGFjdGx5IHRo ZSBzYW1lLCBidXQsIHRoZSBnb2FsIGlzIHNpbWlsYXIuIEl0IGFsbG93cyBhIFBDQyB0byBpbmRp Y2F0ZSB0byB0aGUgUENFIGlmIHRoZSBtZXRyaWMgbXVzdCBiZSBzdHJpY3RseSByZXNwZWN0ZWQg b3INCiBub3QuIE5vdGUsIGFsc28gdGhhdCBpdCBpcyBwb3NzaWJsZSB0byBpbmRpY2F0ZSBtYW55 IHNpbWlsYXIgTWV0cmljIG9iamVjdCB3aXRoIGRpZmZlcmVudCB2YWx1ZSwgYXMgd2VsbCBhcyBk aWZmZXJlbnQgdmFsdWUgZm9yIHRoZSBCLWZsYWcgZm9yIG1vcmUgZmxleGliaWxpdHkuIEZvciBl eGFtcGxlLCBmb3IgdGhlIERpc2pvaW50bmVzcywgd2UgY291bGQgaW1hZ2UgYSBmaXJzdCBNZXRy aWMgd2l0aCBTUkxHIGRpc2pvaW50IHBhdGggYW5kIEItRmxhZw0KIHNldCB0byBvbmUgYW5kIGEg c2Vjb25kIG9uZSB3aXRoIFNSTEctYW5kLU5vZGUgZGlzam9pbnQgcGF0aCB3aXRoIEItRmxhZyBj bGVhci4gVGhpcyBpbmRpY2F0ZSB0byB0aGUgUENFIHRoYXQgd2Ugd2FudCBhdCBsZWFzdCBhbiBT UkxHIGRpc2pvaW50IHBhdGgsIGJ1dCBpZiBpdCBjb3VsZCBjb21wdXRlIGFuIFNSTEcgYW5kIE5v ZGUgZGlzam9pbnQgcGF0aCB3ZSdsbCBiZSB2ZXJ5IGhhcHB5Ljwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtVYnVudHUmcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPlBDQyBjb3VsZCBhbHNvIHNldCB0aGUgQy1GbGFnIHRvIGluZGljYXRlIHRv IHRoZSBQQ0UgdGhhdCBpdCB3b3VsZCBpbiB0dXJuIHRoZSBjb21wdXRlZCBNZXRyaWMuIEZvciBk aXNqb2ludG5lc3MsIGl0IGNvdWxkIGluZGljYXRlIHdoaWNoIHR5cGUgb2YgZGlzam9pbnRuZXNz IGl0IHN1Y2Nlc3NmdWxseSB1c2VkIGZvciB0aGUgY29tcHV0ZWQgcGF0aC48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VWJ1bnR1JnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij5JZiBhIG1ldHJpYyBjb3VsZCBub3QgYmUgbWV0LCBQQ0Ugd2ls bCByZXR1cm4gYSBOby1QQVRIIG9iamVjdCB3aXRoIHRoZSBkZWZhdWx0IG1ldHJpYyB0byBpbmRp Y2F0ZSB3aGljaCBjb25zdHJhaW50cyBjb3VsZCBub3QgYmUgbWV0Ljwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtVYnVudHUmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPk5vdywgdG8gaW5kaWNhdGUgdGhhdCBhIG1ldHJpYyAoY29uc3RyYWlu dCkgc2hvdWxkIGJlIHJlbGF4ZWQsIHRoZXJlIGlzIDIgcG9zc2liaWxpdGllczogc2VuZCBhIG5l dyBQQ0VQIG1lc3NhZ2Ugd2l0aCB0aGUgQi1GbGFnIG9mIHRoaXMgTWV0cmljIGNsZWFyZWQsIG9y IGEgUENFUCBtZXNzYWdlIHdpdGhvdXQgdGhlIGdpdmVuIE1ldHJpYy4gc2VlIGFnYWluIFJGQw0K IDU0NDAgZW5kIG9mIHNlY3Rpb24gNy44IHBhZ2UgMzggKDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM1NDQwI3BhZ2UtMzgiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM1NDQwI3BhZ2UtMzg8L2E+KS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD5TbywgSSB0 aGluayB0aGUgZ2VuZXJpYyBtZWNoYW5pc20gaXMgYWxyZWFkeSBhdmFpbGFibGUgYW5kIHRvIGlu aGVyaXQgZnJvbSB0aGlzIGJlaGF2aW91ciwgdGhlIERpc2pvaW50ZW5lc3MgVExWIHNob3VsZCBi ZSBhIG5ldyBNZXRyaWMgT2JqZWN0IGluc3RlYWQgb2YgYSBkZWRpY2F0ZWQgbmV3IFRMVi4gQnV0 LCBJIHVuZGVyc3RhbmQgdGhhdCB0aGUgZHJhZnQgYW5kIHNvbHV0aW9uIGhhdmUgbm90IGJlZW4g ZGVzaWduIHdpdGggdGhpcyBpbg0KIG1pbmQuIFNvIEkgbGV0IGF1dGhvcnMgZGVjaWRlZCBpZiBp dCBpcyBmZWFzaWJsZSBvciBub3QuPG86cD48L286cD48L3A+DQo8cD5SZWdhcmRzPG86cD48L286 cD48L3A+DQo8cD5PbGl2aWVyPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MZSAxMy8x MS8yMDE3IMOgIDA5OjQwLCA8YSBocmVmPSJtYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5n ZS5jb20iPg0Kc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb208L2E+IGEgw6ljcml0Jm5ic3A7 OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5IaSBEYW5pZWxlLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+VGhhbmtzIGZvciB5b3VyIGZlZWRiYWNrLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JZiB3 ZSBnbyB0byBhIGdlbmVyaWMgbWVjaGFuaXNtLCBJTU8sIHRoaXMgc2hvdWxkIGJlIGFkZHJlc3Nl ZCBpbiBhIHNlcGFyYXRlIGRvY3VtZW50LiBJbiBhZGRpdGlvbiwgd2UgbmVlZCBhIGdlbmVyaWMg d2F5IGZvciBhIFBDQyB0byB0ZWxsIHRoZSBQQ0UgdGhhdCBhIGNvbnN0cmFpbnQgaXMgcmVsYXhh YmxlIG9yIHN0cmljdC4gRm9yIGRpdmVyc2l0eSwgd2UNCiBoYXZlIGEgZGVkaWNhdGVkIGZsYWcg d2l0aGluIHRoZSBESVNKT0lOVE5FU1MgVExWIGZvciB0aGF0IHB1cnBvc2UuIE1heWJlIHdlIHNo b3VsZCBtYWtlIGl0IGdlbmVyaWMgYXMgd2VsbC4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+RG8geW91IGFncmVlID88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPkJyZ2RzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBEYW5pZWxlIENlY2NhcmVs bGkgWzxhIGhyZWY9Im1haWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tIj5tYWls dG86ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gTW9uZGF5LCBOb3ZlbWJlciAxMywgMjAxNyAxNjozMzxicj4NCjxiPlRvOjwvYj4gTElUS09X U0tJIFN0ZXBoYW5lIE9CUy9PSU5JUzsgPGEgaHJlZj0ibWFpbHRvOnBjZUBpZXRmLm9yZyI+cGNl QGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogZHJhZnQtaWV0Zi1wY2UtYXNz b2NpYXRpb24tZGl2ZXJzaXR5OiByZWxheGluZyBjb25zdHJhaW50PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iSVQiPkhpIFN0ZXBoYW5l LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IklUIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5k ZWZpbml0ZWx5IG5lZWRlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk15 IG9waW5pb24gaXMgdGhhdCBhIHdheSB0byBzYXkgdGhhdCBhIGNvbnN0cmFpbnQgd2FzIHJlbGF4 ZWQgaXMgdmVyeSB1c2VmdWwuIEFzIHlvdSBzYWlkIHRoZXJlIGFyZSBkaWZmZXJlbnQgdHlwZXMg b2YgY29uc3RyYWludHMgdGhhdCBjYW4gYmUgcmVsYXhlZCwgZS5nLiBkaXZlcnNpdHkgb3IgYSBU RSBib3VuZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgbWFr ZSB0aGUgVExWIGFzIGdlbmVyaWMgYXMgcG9zc2libGUgYW5kIG1heWJlIGRlZmluZSBtdWx0aXBs ZSBzdWItVExWIChvciBtYXliZSBqdXN0IG11bHRpcGxlIHZhbHVlcykgZGVwZW5kaW5nIG9uIHRo ZSBjb25zdHJhaW50IHRoYXQgd2FzIHJlbGF4ZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJS PGJyPg0KRGFuaWVsZSZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwv Yj4gUGNlIFs8YSBocmVmPSJtYWlsdG86cGNlLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpwY2Ut Ym91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPjxhIGhyZWY9Im1haWx0 bzpzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbSI+c3RlcGhhbmUubGl0a293c2tpQG9yYW5n ZS5jb208L2E+PGJyPg0KPGI+U2VudDo8L2I+IGx1bmVkw6wgMTMgbm92ZW1icmUgMjAxNyAxNjoy Mjxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnBjZUBpZXRmLm9yZyI+cGNlQGlldGYu b3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbUGNlXSBkcmFmdC1pZXRmLXBjZS1hc3NvY2lh dGlvbi1kaXZlcnNpdHk6IHJlbGF4aW5nIGNvbnN0cmFpbnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJJVCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgV0csPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkluIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiBkcmFmdC1pZXRmLXBjZS1h c3NvY2lhdGlvbi1kaXZlcnNpdHkgd2UgYWRkZWQgYSBuZXcgVExWIGNhbGxlZCBSRUxBWEVELUNP TlNUUkFJTlQtVExWIHRvIGJlIHVzZWQgaW4gTFNQIE9iamVjdCBvZiBhIFBDVXBkYXRlIG1lc3Nh Z2Ugd2hlbiB0aGUgUENFIHJlbGF4ZXMgdGhlIHJlcXVlc3RlZCBkaXNqb2ludG5lc3MgY29uc3Ry YWludC4gRm9yIGluc3RhbmNlLCBpZiBhDQogUENDIHJlcXVlc3RzIGFuIFNSTEcgZGlzam9pbnQg cGF0aCBidXQgdGhlIFBDRSBjYW5ub3QgZmluZCBpdCwgaXQgbWF5IHJlbGF4IHRoZSBjb25zdHJh aW50IChpZiBQQ0MgYWxsb3dzIGl0IHRvIGRvIHNvKSBhbmQgdGh1cyBpbmZvcm1zIHRoZSBQQ0Mg dGhyb3VnaCB0aGUgUkVMQVhFRC1DT05TVFJBSU5ULVRMVi48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SU1PLCB0aGlzIGtpbmQgb2YgYmVoYXZpb3IgaXMgbW9yZSBnZW5lcmljIHJhdGhlciB0aWVk IHRvIHRoZSBkaXNqb2ludG5lc3MgdXNlIGNhc2UuIEl0IG1heSBiZSB1c2VkIHdpdGggb3RoZXIg Y29uc3RyYWludHMgYXMgd2VsbC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHF1ZXN0aW9u IGlzOiBkbyB3ZSBuZWVkIHRvIGtlZXAgdGhpcyBSRUxBWEVELUNPTlNUUkFJTlQtVExWIGluIHRo ZSBhc3NvY2lhdGlvbi1kaXZlcnNpdHkgZHJhZnQgPyBvciBkbyB3ZSBkcm9wIGl0ID8gb3IgZG8g d2UgZGVmaW5lIGEgVExWIG1vcmUgc3BlY2lmaWMgdG8gdGhlIGFzc29jaWF0aW9uIGRpdmVyc2l0 eSBzdGF0ZSA/IG1heWJlIHdlIGNhbiByZXVzZSB0aGUgYXNzb2NpYXRpb24gZ3JvdXAgb2JqZWN0 DQogaW4gdGhlIFBDVXBkYXRlIG1lc3NhZ2UgaW5jbHVkaW5nIHRoZSBESVNKT0lOVE5FU1MtSU5G T1JNQVRJT04tVExWIHdoaWNoIHJlZmxlY3RzIHRoZSBhY3R1YWwgZGlzam9pbnRuZXNzIHN0eWxl IHVzZWQgYnkgdGhlIFBDRS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T3BpbmlvbnMgPzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkJyZ2RzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TdGVwaGFuZTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuICwgc2VyaWYmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiAsIHNlcmlmJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8vd3d3 Lm9yYW5nZS5jb20vIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDt0ZXh0LWRlY29yYXRp b246bm9uZSI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSI0MCIgaGVpZ2h0PSI0MCIgaWQ9IlBpY3R1 cmVfeDAwMjBfMSIgc3JjPSJjaWQ6aW1hZ2UwMDEuanBnQDAxRDM1Q0U1LjQzNThERTAwIiBhbHQ9 Ik9yYW5nZSBsb2dvIj48L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuICwgc2VyaWYmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlN0ZXBoYW5lIExpdGtvd3Nr aQ0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4gLCBzZXJpZiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJy Pg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk5ldHdvcmsgQXJjaGl0ZWN0DQo8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuICwgc2VyaWYmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PcmFuZ2UvU0NFL0VRVUFOVC9PSU5JUy9ORVQ8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJG UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+T3JhbmdlIEV4cGVydCBGdXR1cmUgTmV0d29ya3M8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+cGhvbmU6DQo8YSBocmVmPSJodHRwczovL21vbnNpLnNzby5m cmFuY2V0ZWxlY29tLmZyL2luZGV4LmFzcD90YXJnZXQ9aHR0cCUzQSUyRiUyRmNsaWN2b2ljZS5z c28uZnJhbmNldGVsZWNvbS5mciUyRkNsaWN2b2ljZVYyJTJGVG9vbEJhci5kbyUzRmFjdGlvbiUz RGRlZmF1bHQlMjZyb290c2VydmljZSUzRFNJR05BVFVSRSUyNnRvJTNEJiM0MzszMyUyMDIlMjAy MyUyMDI4JTIwNDklMjA4MyUyMCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiYjNDM7MzMg MiAyMyA8Yj4wNjwvYj4gNDkgODMgPC9zcGFuPjwvYT4mbmJzcDtORVcmbmJzcDshPC9zcGFuPjxz cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4gLCBzZXJpZiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJyPg0KPC9z cGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5tb2JpbGU6DQo8YSBocmVm PSJodHRwczovL21vbnNpLnNzby5mcmFuY2V0ZWxlY29tLmZyL2luZGV4LmFzcD90YXJnZXQ9aHR0 cCUzQSUyRiUyRmNsaWN2b2ljZS5zc28uZnJhbmNldGVsZWNvbS5mciUyRkNsaWN2b2ljZVYyJTJG VG9vbEJhci5kbyUzRmFjdGlvbiUzRGRlZmF1bHQlMjZyb290c2VydmljZSUzRFNJR05BVFVSRSUy NnRvJTNEJiM0MzszMyUyMDYlMjAzNyUyMDg2JTIwOTclMjA1MiUyMCI+DQo8c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiYjNDM7MzMgNiA3MSA2MyAyNyA1MCA8L3NwYW4+PC9hPiZuYnNwO05FVyZu YnNwOyE8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiAsIHNlcmlmJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij48YnI+DQo8YSBocmVmPSJtYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0ZGNjYwMCI+c3RlcGhhbmUubGl0a293 c2tpQG9yYW5nZS5jb208L3NwYW4+PC9hPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cHJlPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5DZSBtZXNzYWdl IGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMg Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBz YW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVy LCB2ZXVpbGxleiBsZSBzaWduYWxlcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmEgbCdleHBlZGl0 ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNz YWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPG86cD48 L286cD48L3ByZT4NCjxwcmU+T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kg Y2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoaXMgbWVz c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2 aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7PG86cD48L286 cD48L3ByZT4NCjxwcmU+dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNv cGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPG86cD48L286cD48L3ByZT4NCjxwcmU+SWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPG86cD48L286 cD48L3ByZT4NCjxwcmU+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxp YWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFs c2lmaWVkLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoYW5rIHlvdS48bzpwPjwvbzpwPjwvcHJl Pg0KPC9kaXY+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPg0KPHByZT5DZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2 ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVn aWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5wYXMgZXRyZSBk aWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBh dmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1 ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1 c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPG86cD48L286cD48L3ByZT4NCjxwcmU+T3JhbmdlIGRl Y2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRl Zm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1h eSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5 IGJlIHByb3RlY3RlZCBieSBsYXc7PG86cD48L286cD48L3ByZT4NCjxwcmU+dGhleSBzaG91bGQg bm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24u PG86cD48L286cD48L3ByZT4NCjxwcmU+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMuPG86cD48L286cD48L3ByZT4NCjxwcmU+QXMgZW1haWxzIG1h eSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZl IGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPlRoYW5rIHlvdS48bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+UGNlIG1haWxpbmcgbGlzdDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpQY2VAaWV0Zi5vcmciPlBjZUBpZXRmLm9y ZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3BjZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9wY2U8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8UFJFPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBp ZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRp ZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNl cywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJl Y3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRp dGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVz c2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFu Z2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVy ZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlv biB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJp YnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFu ZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkg YmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBi ZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91Lgo8L1BSRT48L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_87fe0df46382476eb0d7edea0347d307OPEXCLILM43corporateadr_-- --_004_87fe0df46382476eb0d7edea0347d307OPEXCLILM43corporateadr_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=1093; creation-date="Mon, 13 Nov 2017 17:18:28 GMT"; modification-date="Mon, 13 Nov 2017 17:18:28 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAAoACgDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD1O48f afbXMsDWl0WjcoSAuDg49aj/AOFiad/z53f5L/jXB6r/AMhe9/67v/M1Ur5Geb4pSaTX3H2dPJcJ KCbT+89H/wCFiad/z53f5L/jR/wsTTv+fO7/ACX/ABrziip/tnFd19xX9iYPs/vPR/8AhYmnf8+d 3+S/40V5xRR/bOK7r7g/sTB9n95b1X/kL3v/AF3f+ZqpW3Po17qGo3s0Cx7DdPGpeQLvbOdq56mo R4d1EmEFYVaZdyI0oDY9cda450KspNqLO2niKUYJOSvbv5GVRWwPC+qmR4zFErI/l4aUDc2A2B68 GmDw7qTQrIIkJZVYR+YN+GOAdvuan6tW/lf3FfWqH86+8yqK2bjQG0+EvqU/2dmyIgieYGI6gkHg 0VM6M4O0tGVCtCavF3R1o8Oa7BcTtbXdh5TztPGJYyxjY9xxwcUxfDniNZ1m+32DOIPs+WjJymc8 8dc96KK+y/s+l3f3s+J/tKt2X3Ie+geJZJlla/0/eswmH7s/eChfT0FXDo2rDTRCktoLoIqfaCxy NrZGPlz+GaKKpYGmr6vXzJlj6sraLTyMrUPCOuant+03lh8pJ+RGXJPUniiiisZ5Thpvmldv1N4Z xioLljZL0R//2Q== --_004_87fe0df46382476eb0d7edea0347d307OPEXCLILM43corporateadr_-- From nobody Mon Nov 13 14:40:10 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 3295C124239; Mon, 13 Nov 2017 14:40:03 -0800 (PST) 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.65.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151061280311.5997.1912223376900753631@ietfa.amsl.com> Date: Mon, 13 Nov 2017 14:40:03 -0800 Archived-At: Subject: [Pce] I-D Action: draft-ietf-pce-pcep-stateful-pce-gmpls-06.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, 13 Nov 2017 22:40:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : Path Computation Element (PCE) Protocol Extensions for Stateful PCE Usage 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-06.txt Pages : 13 Date : 2017-11-13 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-06 https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-stateful-pce-gmpls-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-stateful-pce-gmpls-06 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 Mon Nov 13 14:42: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 2F1FC120721 for ; Mon, 13 Nov 2017 14:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.218 X-Spam-Level: X-Spam-Status: No, score=-4.218 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jouD6KD_xq-4 for ; Mon, 13 Nov 2017 14:42:03 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 790351200E5 for ; Mon, 13 Nov 2017 14:42:03 -0800 (PST) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id C339B11566D81 for ; Mon, 13 Nov 2017 22:41:58 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 13 Nov 2017 22:42:00 +0000 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML703-CHM.china.huawei.com ([169.254.5.96]) with mapi id 14.03.0361.001; Mon, 13 Nov 2017 14:41:57 -0800 From: Leeyoung To: "pce@ietf.org" Thread-Topic: [Pce] I-D Action: draft-ietf-pce-pcep-stateful-pce-gmpls-06.txt Thread-Index: AQHTXNBvYM+7Iiu1ZkWpTuWDfdyKBaMS51qw Date: Mon, 13 Nov 2017 22:41:57 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E173CF4F03B@sjceml521-mbx.china.huawei.com> References: <151061280311.5997.1912223376900753631@ietfa.amsl.com> In-Reply-To: <151061280311.5997.1912223376900753631@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.39.52] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pce] I-D Action: draft-ietf-pce-pcep-stateful-pce-gmpls-06.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: Mon, 13 Nov 2017 22:42:05 -0000 Just to refresh the draft, Thanks. Young -----Original Message----- From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.o= rg Sent: Monday, November 13, 2017 4:40 PM To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-pcep-stateful-pce-gmpls-06.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Path Computation Element WG of the IETF. Title : 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-06.txt Pages : 13 Date : 2017-11-13 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-06 https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-stateful-pce-gmpl= s-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-pcep-stateful-pce-gmpls-= 06 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 Mon Nov 13 14:52:11 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 50F9F120724; Mon, 13 Nov 2017 14:52:09 -0800 (PST) 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.65.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151061352929.6005.5652318503094379694@ietfa.amsl.com> Date: Mon, 13 Nov 2017 14:52:09 -0800 Archived-At: Subject: [Pce] I-D Action: draft-ietf-pce-remote-initiated-gmpls-lsp-04.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, 13 Nov 2017 22:52:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : Path Computation Element Communication Protocol (PCEP) Extensions for remote-initiated GMPLS LSP Setup Authors : Zafar Ali Siva Sivabalan Clarence Filsfils Robert Varga Victor Lopez Oscar Gonzalez de Dios Xian Zhang Filename : draft-ietf-pce-remote-initiated-gmpls-lsp-04.txt Pages : 9 Date : 2017-11-13 Abstract: Draft [I-D. draft-ietf-pce-pce-initiated-lsp] specifies procedures that can be used for creation and deletion of PCE-initiated LSPs in the active stateful PCE model. However, this specification focuses on MPLS networks, and does not cover remote instantiation of paths in GMPLS-controlled networks. This document complements [I-D. draft-ietf-pce-pce-initiated-lsp] by addressing the requirements for remote-initiated GMPLS LSPs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-remote-initiated-gmpls-lsp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-remote-initiated-gmpls-lsp-04 https://datatracker.ietf.org/doc/html/draft-ietf-pce-remote-initiated-gmpls-lsp-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-remote-initiated-gmpls-lsp-04 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 Mon Nov 13 15:05: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 D8D3B1288A9; Mon, 13 Nov 2017 15:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 SmWmFVLXW_l7; Mon, 13 Nov 2017 15:05:18 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6824412717E; Mon, 13 Nov 2017 15:05:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3510; q=dns/txt; s=iport; t=1510614318; x=1511823918; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=zQakpC/j+8g3OkBk/7oD5YhBh5wbR2doQrixN2pPE24=; b=UsMy5W48abqQCYYedTCBTAEI7ji05P+Y0Idw402YF/iyUYu9CqYqlLQ+ jGgnPYSsM7NY6a8r2/KNDaOw0WkGzszG20+docKfhj69647gkUk3vJjpI kSgyFRiehRHcjvHUku+MQ6vw+PBO6WA5tMU+D4P8i5Ju8bp53TiXa4ueG 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CgAACdJApa/5ldJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM1ZG4nB4N3ih+PL4FXjFiKHhCCAQolhRYchEs/GAEBAQEBAQE?= =?us-ascii?q?BAWsohUgRRRIBIgImAgQwFRIEAQ0FiiIQq16CJ4sPAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBHYEPgiWCB4FVgWkpC4Y6gRcEAYNMMYIyBZFokEICgXGFeI0ZghVfhAu?= =?us-ascii?q?BHoslijGCN4kPAhEZAYE4AR84gXJ6FR9XAYI2CYRWdwGGGYEzgREBAQE?= X-IronPort-AV: E=Sophos;i="5.44,389,1505779200"; d="scan'208";a="318351537" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Nov 2017 23:04:56 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vADN4tlh009916 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 13 Nov 2017 23:04:56 GMT Received: from xch-rtp-018.cisco.com (64.101.220.158) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 13 Nov 2017 18:04:55 -0500 Received: from xch-rtp-018.cisco.com ([64.101.220.158]) by XCH-RTP-018.cisco.com ([64.101.220.158]) with mapi id 15.00.1320.000; Mon, 13 Nov 2017 18:04:49 -0500 From: "Zafar Ali (zali)" To: "pce-chairs@ietf.org" , "pce@ietf.org" CC: "Zafar Ali (zali)" , Oscar de Dios , "Siva Sivabalan (msiva)" , Victor Lopez , "Xian Zhang" , Oscar Gonzalez de Dios , "pce-chairs@ietf.org" Thread-Topic: Status update on Thread-Index: AQHTXNPOlL4y3iwomk+xhD9EkpPVzQ== Date: Mon, 13 Nov 2017 23:04:49 +0000 Message-ID: <2BF8DB32-A96C-4394-A76C-7D6DAB27F388@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.75.234.165] Content-Type: text/plain; charset="utf-8" Content-ID: <5E21FF90D64E7643B3E2655E61D317DF@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Pce] Status update on 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, 13 Nov 2017 23:05:20 -0000 RGVhciBXRyBhbmQgdGhlIENoYWlycywNCiANClNvcnJ5IGZvciB0aGUgZGVsYXkgaW4gcHJvdmlk aW5nIHRoaXMgc3RhdHVzIHVwZGF0ZS4gDQoNClRoZSBmb2xsb3dpbmcgaXMgYSBzdGF0dXMgdXBk YXRlIGZvciBkcmFmdC1pZXRmLXBjZS1yZW1vdGUtaW5pdGlhdGVkLWdtcGxzLWxzcC0wNC50eHQu IA0KDQpDdXJyZW50IFN0YXR1czoNCuKAoiBBIGZyZXNoIHdhcyBkb25lIG9uIE5vdmVtYmVyIDEz LCAyMDE3IChkcmFmdC1pZXRmLXBjZS1yZW1vdGUtaW5pdGlhdGVkLWdtcGxzLWxzcC0wNC50eHQp Lg0K4oCiIERyYWZ0IGhhcyBiZWVuIHN0YWJsZSBmb3IgcXVpdGUgc29tZSB0aW1lLg0KDQpPcGVu IElzc3VlczogDQrigKIgTm9uZSAodGhhdCBJIGFtIGF3YXJlIG9mLyByZWNhbGwpLg0KDQpOZXh0 IFN0ZXBzOg0K4oCiIEFkZHJlc3MgYW55IG5lZWQgZm9yIGFsaWdubWVudCB3aXRoIHRoZSBkcmFm dCB3aXRoIGRyYWZ0LWlldGYtcGNlLXBjZS1pbml0aWF0ZWQtbHNwLTExLiANCuKAoiBSZXF1ZXN0 IGEgTEMgb24gdGhlIHVwZGF0ZWQgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQuIA0KDQpQbGVhc2Ug YWR2aXNlIG9mIGFueSBjb21tZW50cyB5b3UgbWF5IGhhdmU7IHdlIGNhbiBhZGRyZXNzIGl0IGlu IHRoZSBuZXh0IHJldmlzaW9uLiANCiANCk5leHQgU3RlcHM6DQoNClRoYW5rcw0KIA0KUmVnYXJk cyDigKYgWmFmYXIgDQogDQoNCk9uIDExLzEzLzE3LCA1OjUyIFBNLCAiaW50ZXJuZXQtZHJhZnRz QGlldGYub3JnIiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiB3cm90ZToNCg0KICAgIA0KICAg IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLXBjZS1yZW1vdGUtaW5pdGlhdGVkLWdt cGxzLWxzcC0wNC50eHQNCiAgICBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFph ZmFyIEFsaSBhbmQgcG9zdGVkIHRvIHRoZQ0KICAgIElFVEYgcmVwb3NpdG9yeS4NCiAgICANCiAg ICBOYW1lOgkJZHJhZnQtaWV0Zi1wY2UtcmVtb3RlLWluaXRpYXRlZC1nbXBscy1sc3ANCiAgICBS ZXZpc2lvbjoJMDQNCiAgICBUaXRsZToJCVBhdGggQ29tcHV0YXRpb24gRWxlbWVudCBDb21tdW5p Y2F0aW9uIFByb3RvY29sIChQQ0VQKSBFeHRlbnNpb25zIGZvciByZW1vdGUtaW5pdGlhdGVkIEdN UExTIExTUCBTZXR1cA0KICAgIERvY3VtZW50IGRhdGU6CTIwMTctMTEtMTMNCiAgICBHcm91cDoJ CXBjZQ0KICAgIFBhZ2VzOgkJOQ0KICAgIFVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1wY2UtcmVtb3RlLWluaXRpYXRlZC1nbXBs cy1sc3AtMDQudHh0DQogICAgU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcGNlLXJlbW90ZS1pbml0aWF0ZWQtZ21wbHMtbHNwLw0KICAg IEh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1w Y2UtcmVtb3RlLWluaXRpYXRlZC1nbXBscy1sc3AtMDQNCiAgICBIdG1saXplZDogICAgICAgaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXBjZS1yZW1vdGUt aW5pdGlhdGVkLWdtcGxzLWxzcC0wNA0KICAgIERpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1wY2UtcmVtb3RlLWluaXRpYXRlZC1nbXBs cy1sc3AtMDQNCiAgICANCiAgICBBYnN0cmFjdDoNCiAgICAgICAgIERyYWZ0IFtJLUQuIGRyYWZ0 LWlldGYtcGNlLXBjZS1pbml0aWF0ZWQtbHNwXSBzcGVjaWZpZXMgcHJvY2VkdXJlcw0KICAgICAg ICAgdGhhdCBjYW4gYmUgdXNlZCBmb3IgY3JlYXRpb24gYW5kIGRlbGV0aW9uIG9mIFBDRS1pbml0 aWF0ZWQgTFNQcyBpbg0KICAgICAgICAgdGhlIGFjdGl2ZSBzdGF0ZWZ1bCBQQ0UgbW9kZWwuIEhv d2V2ZXIsIHRoaXMgc3BlY2lmaWNhdGlvbiBmb2N1c2VzDQogICAgICAgICBvbiBNUExTIG5ldHdv cmtzLCBhbmQgZG9lcyBub3QgY292ZXIgcmVtb3RlIGluc3RhbnRpYXRpb24gb2YgcGF0aHMNCiAg ICAgICAgIGluIEdNUExTLWNvbnRyb2xsZWQgbmV0d29ya3MuIFRoaXMgZG9jdW1lbnQgY29tcGxl bWVudHMgW0ktRC4NCiAgICAgICAgIGRyYWZ0LWlldGYtcGNlLXBjZS1pbml0aWF0ZWQtbHNwXSBi eSBhZGRyZXNzaW5nIHRoZSByZXF1aXJlbWVudHMNCiAgICAgICAgIGZvciByZW1vdGUtaW5pdGlh dGVkIEdNUExTIExTUHMuDQogICAgDQogICAgDQogICAgICAgICANCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQogICAgDQogICAgDQogICAgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KICAgIHVu dGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMu aWV0Zi5vcmcuDQogICAgDQogICAgVGhlIElFVEYgU2VjcmV0YXJpYXQNCiAgICANCiAgICANCg0K From nobody Tue Nov 14 17:28:17 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 AE19812940B for ; Tue, 14 Nov 2017 17:28:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 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_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=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 t1QYqZvJdOO5 for ; Tue, 14 Nov 2017 17:28:12 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0100.outbound.protection.outlook.com [104.47.33.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AE54126CD6 for ; Tue, 14 Nov 2017 17:28:12 -0800 (PST) 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=fHK3+mAGLYhSsBTJ1J/ociHI+YN7MLFssQFiFVfMCUg=; b=nbNwgcZ+a66H3rDINbAf2qG+h4gDrpNe9/q57d1xiBexxw3Uycx7xM1tLXA17FsvG0zWd67Kzu9FdxyTRPVPWbn+/fRIPkgsIykAkfGVEp6yVtg07HOg8+9mOUXYkmnDWSIJXAev6M6LNxdJ6WZ2ixE546MJYxxR+z0jTlTju7k= Received: from CY4PR0201MB3603.namprd02.prod.outlook.com (52.132.99.21) by CY4PR0201MB3603.namprd02.prod.outlook.com (52.132.99.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.12; Wed, 15 Nov 2017 01:28:10 +0000 Received: from CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::dce9:6773:68c7:10f3]) by CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::dce9:6773:68c7:10f3%13]) with mapi id 15.20.0218.015; Wed, 15 Nov 2017 01:28:10 +0000 From: Jonathan Hardwick To: "stephane.litkowski@orange.com" , "pce@ietf.org" Thread-Topic: Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing Thread-Index: AdNcnZvYi2xVxqg4QzKXbgSaVFI8tABEh7zw Date: Wed, 15 Nov 2017 01:28:10 +0000 Message-ID: References: <20853_1510591095_5A09CA77_20853_54_2_9E32478DFA9976438E7A22F69B08FF921EABC22A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: <20853_1510591095_5A09CA77_20853_54_2_9E32478DFA9976438E7A22F69B08FF921EABC22A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-originating-ip: [2001:67c:370:128:49d6:2dcb:a92f:5c33] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR0201MB3603; 6:+Rkgaeb6NTRzZITOU+C5xVNDl7NvcwCkAomjmnS1yni0A5te3zx61K/roVAbPNyL2atZVagrH3n8a/+yWC368UB9nPHHUihRIitcNhDM+nUAybiKClNqlGQ5kDBRPMAqh5zDERkAcind6mLLxNpbO6WGLyZzxtql1NjZ1YVBzmKddoPw03Gc7V2iBX3+AnwvjfaIzBwofIYUq14Nd8K9755OL35bdOiuGEHUB/e9JvUlPZspc6zYlHFYICITmLw03LbOlF1mzo+JYCooRza/YC2DX0J+Cxc7JX8VCOQxG/+WTsge64+N9nKSm3ju1d4bF1G6bTtn23eYicnaV6zSxU9q4qol3s70YqpyWMW4k8E=; 5:PdOHilum2J9MV5V1DmNd1DTrkGCWzkrMQlnRIf5PovZAH0f0l332UEhDW5xT83T06tCwqQitiCUSkLVBu8VmPsB4gUe4d03h944f2uurYxaWywecp2TcmWsv5hxrETZhxFsiijxjYy6OXz8r9zWzJi2lnrkyPOCSnoTR26+AElM=; 24:OdQfryc/BVAZrwKenzClJgVGXcZBczaC35vhQkh68YRD5CMP3E3ytfvhh2njqC/3CG4xj/gnJu9RfJm58M/vEoO9MRG6mSqQNwHJ+7ZKcrU=; 7:48sWsJVoAm5rN+1tCyjBKoYnZ3unZZGsbTou93mZDC5LD6ANJxqj8WU/2NJXYQQv9xGHK8cupc4Na0HL0p6lmiKgvXYXBYhg+BpvCPVTkfZ7xpZOZ9z2vCW6XhY9CttFE0sxKxaSQyIHxw+SUR5kF3QmjWIBJjutOBrABA6j7GxCdVSL48rWNoWKVS8f/p321qLHjz7r9b7qWeueRsNaXQrbTu+OFoLF7MFxYHnuZck7fh2jWAYjt/U07fkI6q2Z x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 255db46a-742b-4e39-27bd-08d52bc821d1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199)(49563074); SRVR:CY4PR0201MB3603; x-ms-traffictypediagnostic: CY4PR0201MB3603: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(115448073456579)(81850148713716)(227612066756510)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3231022)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR0201MB3603; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR0201MB3603; x-forefront-prvs: 0492FD61DD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(37854004)(199003)(189002)(106356001)(50986999)(478600001)(110136005)(7736002)(5660300001)(5890100001)(105586002)(72206003)(7696004)(2501003)(99286004)(230783001)(316002)(97736004)(99936001)(606006)(189998001)(53546010)(76176999)(2950100002)(54356999)(6116002)(14454004)(6436002)(2900100001)(54896002)(54556002)(101416001)(102836003)(8936002)(74316002)(9686003)(3280700002)(53936002)(236005)(229853002)(6506006)(68736007)(8676002)(33656002)(3660700001)(6306002)(86362001)(2906002)(55016002)(5250100002)(81156014)(6246003)(25786009)(733005)(81166006)(790700001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR0201MB3603; H:CY4PR0201MB3603.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/related; boundary="_004_CY4PR0201MB36034BB2B53F02BB9DAABA5584290CY4PR0201MB3603_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-Network-Message-Id: 255db46a-742b-4e39-27bd-08d52bc821d1 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2017 01:28:10.3133 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0201MB3603 Archived-At: Subject: Re: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing 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, 15 Nov 2017 01:28:15 -0000 --_004_CY4PR0201MB36034BB2B53F02BB9DAABA5584290CY4PR0201MB3603_ Content-Type: multipart/alternative; boundary="_000_CY4PR0201MB36034BB2B53F02BB9DAABA5584290CY4PR0201MB3603_" --_000_CY4PR0201MB36034BB2B53F02BB9DAABA5584290CY4PR0201MB3603_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think it should be acceptable for the PCUpd not to include the PATH-SETUP= -TYPE, with the implication that there is no change to the path type. Although I'm not convinced it would be a good idea operationally, I don't t= hink there's any need to prevent the path type changing on the PCUpd, if an= explicit PATH-SETUP-TYPE is given. That is, draft-ietf-pce-lsp-setup-type= , as a base draft, should allow that flexibility. A given device may choos= e not to allow that, of course. Does that sound reasonable? Cheers Jon From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of stephane.litkowski@ora= nge.com Sent: 14 November 2017 00:38 To: pce@ietf.org Subject: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-t= ype & draft-ietf-pce-segment-routing Hi WG, I'm facing an interop issue between two PCEP implementations. PCE from vendor1 sends the PCInitiate for an SRTE LSP using the PST=3D1 in = the SRP Object. PCC from vendor2 handles it correctly and delegates the LSP to the PCE usin= g PST=3D1. When the PCE sends a PCUpdate message, it does not set the PST TLV in the S= RP Object. The PCC rejects the PCUpdate because of a bad ERO subobject type. It reads = the PCUpdate as having PST type=3D0. Based on my reading of draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segme= nt-routing. PST draft tells that for the PCE Initiation case, the PCE MAY include the P= ST if the message does not ave any other means of indicating the path setup= type. SR draft tells "In order to setup an SR-TE LSP using SR, RP or SRP o= bject MUST include PATH-SETUP-TYPE TLV". Unfortunately it does not specify = explicitly in which message. From a reading perspective, we can understand = from "In order to setup" that it applies to the PCInitiate message. But not= hing tells about the PCUpdate message. However draft-ietf-pce-lsp-setup-type tells for the stateful PCE case that:= "if the path setup type cannot be unambiguously inferred from ERO or any o= ther object or TLV, PATH-SETUP-TYPE TLV MAY be used in PCRpt and PCUpd mess= ages." In our case (PCE initiated) as the LSP has initially been setup through a P= CInitiate message having the PST TLV, the PCC can infer that futher updates= will use EROs associated with the same PST. Or do we allow to change the PST through PCUpdate messages which may requir= e to always set the PST ? (moving from RSVP-TE to SR or the other way for = a particular LSP) I would like to hear opinions of the WG on that problem ? Thanks, Brgds, [Orange logo] Stephane Litkowski Network Architect Orange/SCE/EQUANT/OINIS/NET Orange Expert Future Networks phone: +33 2 23 06 49 83 NEW ! mobile: +33 6 71 63 27 50 NEW ! stephane.litkowski@orange.com ___________________________________________________________________________= ______________________________________________ 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. --_000_CY4PR0201MB36034BB2B53F02BB9DAABA5584290CY4PR0201MB3603_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think i= t should be acceptable for the PCUpd not to include the PATH-SETUP-TYPE, wi= th the implication that there is no change to the path type.

&nbs= p;

Although = I’m not convinced it would be a good idea operationally, I don’= t think there’s any need to prevent the path type changing on the PCU= pd, if an explicit PATH-SETUP-TYPE is given.  That is, draft-ietf-pce-lsp-setup-type, as a base draft, should allow that flexibil= ity.  A given device may choose not to allow that, of course.

&nbs= p;

Does that= sound reasonable?

Cheers

Jon<= /o:p>

&nbs= p;

&nbs= p;

From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of stephane.litkowski@orange.com
Sent: 14 November 2017 00:38
To: pce@ietf.org
Subject: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-= setup-type & draft-ietf-pce-segment-routing

 

Hi WG,

 

I’m facing an interop iss= ue between two PCEP implementations.

PCE from vendor1 sends the PCIn= itiate for an SRTE LSP using the PST=3D1 in the SRP Object.

PCC from vendor2 handles it cor= rectly and delegates the LSP to the PCE using PST=3D1.

When the PCE sends a PCUpdate m= essage, it does not set the PST TLV in the SRP Object.

The PCC rejects the PCUpdate be= cause of a bad ERO subobject type. It reads the PCUpdate as having PST type= =3D0.

 

Based on my reading of draft-ie= tf-pce-lsp-setup-type & draft-ietf-pce-segment-routing.

PST draft tells that for the PC= E Initiation case, the PCE MAY include the PST if the message does not ave = any other means of indicating the path setup type. SR draft tells “In= order to setup an SR-TE LSP using SR, RP or SRP object MUST include PATH-SETUP-TYPE TLV”. Unfortunately it do= es not specify explicitly in which message. From a reading perspective, we = can understand from “In order to setup” that it applies to the = PCInitiate message. But nothing tells about the PCUpdate message.

However draft-ietf-pce-lsp-setu= p-type tells for the stateful PCE case that: “if the path setup type = cannot be unambiguously inferred from ERO or any other object or TLV, PATH-= SETUP-TYPE TLV MAY be used in PCRpt and PCUpd messages.”

In our case (PCE initiated) as = the LSP has initially been setup through a PCInitiate message having the PS= T TLV, the PCC can infer that futher updates will use EROs associated with = the same PST.

 

Or do we allow to change the PS= T through PCUpdate messages which may require to  always set the PST ?= (moving from RSVP-TE to SR or the other way for a particular LSP)

 

I would like to hear opinions of = the WG on that problem ?

 

Thanks,

 

Brgds,

 

 

3D"Orange

&nbs= p;

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET

Orange Expert Future Netwo= rks

phone: +33 2 23 06 49 83  NEW ! mobile: +33 6 71 63 27 50  NEW = ;!
stephane.litk= owski@orange.com

 

_________________________________________________=
________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir=
 des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler=

a l'expediteur et le detruire ainsi que les piece=
s jointes. Les messages electroniques etant susceptibles d'alteration,=

Orange decline toute responsabilite si ce message=
 a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain conf=
idential or privileged information that may be protected by law;=

they should not be distributed, used or copied wi=
thout authorisation.
If you have received this email in error, please =
notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable fo=
r messages that have been modified, changed or falsified.=

Thank you.
--_000_CY4PR0201MB36034BB2B53F02BB9DAABA5584290CY4PR0201MB3603_-- --_004_CY4PR0201MB36034BB2B53F02BB9DAABA5584290CY4PR0201MB3603_ Content-Type: image/jpeg; name="image002.jpg" Content-Description: image002.jpg Content-Disposition: inline; filename="image002.jpg"; size=1119; creation-date="Wed, 15 Nov 2017 01:28:09 GMT"; modification-date="Wed, 15 Nov 2017 01:28:09 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCAAyADIDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD02bxP pcMrRvcAOpwRg00eLNJx/wAfI/I1wepD/iZXP++arV8/LNKsZWsj6KnlFKcE7s9F/wCEt0n/AJ+R +Ro/4S3Sf+fkfka86xRip/tar2Rf9jUf5mei/wDCW6T/AM/I/I0f8JbpP/PyPyNedYoxR/a1Xsg/ saj/ADM9G/4S3Sf+fkfkaK85xRR/a1Xsg/saj/My1qf/ACErn/fNVcYq1qg/4mlyP9s1V5Oa86p8 R6dD+HEB0ooHQetFZmtwooooAKKOPUUUWFc1Z9MlvNRvZFkSOOOTDSOeAaRvD10ElaSSKNI8fMTw a1W07V4bq6Edmk1vO+4qx4NNubPX7u3khktE2SEHg/dx2r1vqsL3cWeKsZNJJSVjMbw/di0Nwrxu qgdKWXw5dxKxDxOyEBkU8jPStd4/EDwPGbGIb1CnB9KaLbXjcSyfZEHm7dxB54o+qU9PdYfXauvv RMp/Dt0uQrxO4cKyKeQTUkuhDT4zNqDFo87f3RyVNdDew3/ksbS0YXDMrlyAOR61l31hrl/EY5LJ EBO5ip6mnPCwgnaLuKGMqVGuaaSMEi0BOGlx9KKu/wDCK6qefsv60Vx+xqfyM7vrFL/n4vvPR+5/ Cl9aKK+pPkhe1J/eoop9hMT+7TgKKKb3FHYjJOTRRRVgf//Z --_004_CY4PR0201MB36034BB2B53F02BB9DAABA5584290CY4PR0201MB3603_-- From nobody Tue Nov 14 21:52: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 54ABA1294F0 for ; Tue, 14 Nov 2017 21:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 ntwA6_8xxbrk for ; Tue, 14 Nov 2017 21:52:29 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 884E41294D3 for ; Tue, 14 Nov 2017 21:52:26 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 987D240B35; Wed, 15 Nov 2017 06:52:21 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.34]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 749B41A0054; Wed, 15 Nov 2017 06:52:21 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM6F.corporate.adroot.infra.ftgroup ([fe80::bd00:88f8:8552:3349%17]) with mapi id 14.03.0361.001; Wed, 15 Nov 2017 06:52:21 +0100 From: To: Jonathan Hardwick , "pce@ietf.org" Thread-Topic: Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing Thread-Index: AdNcnZvYi2xVxqg4QzKXbgSaVFI8tABEh7zwAAjZZHA= Date: Wed, 15 Nov 2017 05:52:20 +0000 Message-ID: <1346_1510725141_5A0BD615_1346_83_1_9E32478DFA9976438E7A22F69B08FF921EABE047@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <20853_1510591095_5A09CA77_20853_54_2_9E32478DFA9976438E7A22F69B08FF921EABC22A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: multipart/related; boundary="_004_9E32478DFA9976438E7A22F69B08FF921EABE047OPEXCLILMA4corp_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: Re: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing 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, 15 Nov 2017 05:52:35 -0000 --_004_9E32478DFA9976438E7A22F69B08FF921EABE047OPEXCLILMA4corp_ Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF921EABE047OPEXCLILMA4corp_" --_000_9E32478DFA9976438E7A22F69B08FF921EABE047OPEXCLILMA4corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, Thanks for your feedback. I see two possibilities here. 1) When the PATH-SETUP-TYPE is not present in a PCUpd, it should be in= ferred from the latest one received (in a PCInitiate or in a PCUpd). When i= nitiating an LSP, the PCInitiate contains the PST to let the PCC know about= the path type. Then, it can be omitted in further PCUpd except when the PC= E wants to change the path type. At that time, it sends a PCUpd with a new = PATH-SETUP-TYPE value and then it does not need to include it in further up= dates until the PCE needs to change it again. 2) We mandate the PCE to put the PATH-SETUP-TYPE in all PCUpd. IMO, solution 2) is easier for implementations and operation. Brgd, Stephane From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com] Sent: Wednesday, November 15, 2017 09:28 To: LITKOWSKI Stephane OBS/OINIS; pce@ietf.org Subject: RE: Clarifications on PST handling in draft-ietf-pce-lsp-setup-typ= e & draft-ietf-pce-segment-routing I think it should be acceptable for the PCUpd not to include the PATH-SETUP= -TYPE, with the implication that there is no change to the path type. Although I'm not convinced it would be a good idea operationally, I don't t= hink there's any need to prevent the path type changing on the PCUpd, if an= explicit PATH-SETUP-TYPE is given. That is, draft-ietf-pce-lsp-setup-type= , as a base draft, should allow that flexibility. A given device may choos= e not to allow that, of course. Does that sound reasonable? Cheers Jon From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of stephane.litkowski@ora= nge.com Sent: 14 November 2017 00:38 To: pce@ietf.org Subject: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-t= ype & draft-ietf-pce-segment-routing Hi WG, I'm facing an interop issue between two PCEP implementations. PCE from vendor1 sends the PCInitiate for an SRTE LSP using the PST=3D1 in = the SRP Object. PCC from vendor2 handles it correctly and delegates the LSP to the PCE usin= g PST=3D1. When the PCE sends a PCUpdate message, it does not set the PST TLV in the S= RP Object. The PCC rejects the PCUpdate because of a bad ERO subobject type. It reads = the PCUpdate as having PST type=3D0. Based on my reading of draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segme= nt-routing. PST draft tells that for the PCE Initiation case, the PCE MAY include the P= ST if the message does not ave any other means of indicating the path setup= type. SR draft tells "In order to setup an SR-TE LSP using SR, RP or SRP o= bject MUST include PATH-SETUP-TYPE TLV". Unfortunately it does not specify = explicitly in which message. From a reading perspective, we can understand = from "In order to setup" that it applies to the PCInitiate message. But not= hing tells about the PCUpdate message. However draft-ietf-pce-lsp-setup-type tells for the stateful PCE case that:= "if the path setup type cannot be unambiguously inferred from ERO or any o= ther object or TLV, PATH-SETUP-TYPE TLV MAY be used in PCRpt and PCUpd mess= ages." In our case (PCE initiated) as the LSP has initially been setup through a P= CInitiate message having the PST TLV, the PCC can infer that futher updates= will use EROs associated with the same PST. Or do we allow to change the PST through PCUpdate messages which may requir= e to always set the PST ? (moving from RSVP-TE to SR or the other way for = a particular LSP) I would like to hear opinions of the WG on that problem ? Thanks, Brgds, [Orange logo] Stephane Litkowski Network Architect Orange/SCE/EQUANT/OINIS/NET Orange Expert Future Networks phone: +33 2 23 06 49 83 NEW ! mobile: +33 6 71 63 27 50 NEW ! stephane.litkowski@orange.com ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. --_000_9E32478DFA9976438E7A22F69B08FF921EABE047OPEXCLILMA4corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,

 

Thanks for your feedba= ck.

I see two possibilitie= s here.

1)&n= bsp;     When the PATH-= SETUP-TYPE is not present in a PCUpd, it should be inferred from the latest= one received (in a PCInitiate or in a PCUpd). When initiating an LSP, the = PCInitiate contains the PST to let the PCC know about the path type. Then, it can be omitted in further PCUpd= except when the PCE wants to change the path type. At that time, it sends = a PCUpd with a new PATH-SETUP-TYPE value and then it does not need to inclu= de it in further updates until the PCE needs to change it again.

2)&n= bsp;     We mandate the= PCE to put the PATH-SETUP-TYPE in all PCUpd.

 

IMO, solution 2) is ea= sier for implementations and operation.

 

Brgd,

 

Stephane

 

 

From: Jonathan= Hardwick [mailto:Jonathan.Hardwick@metaswitch.com]
Sent: Wednesday, November 15, 2017 09:28
To: LITKOWSKI Stephane OBS/OINIS; pce@ietf.org
Subject: RE: Clarifications on PST handling in draft-ietf-pce-lsp-se= tup-type & draft-ietf-pce-segment-routing

 

I think it should be acceptable= for the PCUpd not to include the PATH-SETUP-TYPE, with the implication tha= t there is no change to the path type.

 

Although I’m not convince= d it would be a good idea operationally, I don’t think there’s = any need to prevent the path type changing on the PCUpd, if an explicit PAT= H-SETUP-TYPE is given.  That is, draft-ietf-pce-lsp-setup-type, as a base draft, should allow that flexibility.  A given device may c= hoose not to allow that, of course.

 

Does that sound reasonable?

Cheers

Jon

 

 

From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of stepha= ne.litkowski@orange.com
Sent: 14 November 2017 00:38
To: pce@ietf.org
Subject: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-= setup-type & draft-ietf-pce-segment-routing

 

Hi WG,

 

I’m facing an interop issue between two PCEP i= mplementations.

PCE from vendor1 sends the PCInitiate for an SRTE LS= P using the PST=3D1 in the SRP Object.

PCC from vendor2 handles it correctly and delegates = the LSP to the PCE using PST=3D1.

When the PCE sends a PCUpdate message, it does not s= et the PST TLV in the SRP Object.

The PCC rejects the PCUpdate because of a bad ERO su= bobject type. It reads the PCUpdate as having PST type=3D0.

 

Based on my reading of draft-ietf-pce-lsp-setup-type= & draft-ietf-pce-segment-routing.

PST draft tells that for the PCE Initiation case, th= e PCE MAY include the PST if the message does not ave any other means of in= dicating the path setup type. SR draft tells “In order to setup an SR= -TE LSP using SR, RP or SRP object MUST include PATH-SETUP-TYPE TLV”. Unfortunately it does not specify expl= icitly in which message. From a reading perspective, we can understand from= “In order to setup” that it applies to the PCInitiate message.= But nothing tells about the PCUpdate message.

However draft-ietf-pce-lsp-setup-type tells for the = stateful PCE case that: “if the path setup type cannot be unambiguous= ly inferred from ERO or any other object or TLV, PATH-SETUP-TYPE TLV MAY be= used in PCRpt and PCUpd messages.”

In our case (PCE initiated) as the LSP has initially= been setup through a PCInitiate message having the PST TLV, the PCC can in= fer that futher updates will use EROs associated with the same PST.

 

Or do we allow to change the PST through PCUpdate me= ssages which may require to  always set the PST ? (moving from RSVP-TE= to SR or the other way for a particular LSP)

 

I would like to hear opinions of the= WG on that problem ?

 

Thanks,

 

Brgds,

 

 

3D"Orange

 <= o:p>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET

Orange Expert Future Networks=

phone: +33 2 23 06 49 83  NEW !
mobile: +33 6 71 63 27 50  NEW = ;!
s= tephane.litkowski@orange.com

 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________

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.
--_000_9E32478DFA9976438E7A22F69B08FF921EABE047OPEXCLILMA4corp_-- --_004_9E32478DFA9976438E7A22F69B08FF921EABE047OPEXCLILMA4corp_ Content-Type: image/jpeg; name="image002.jpg" Content-Description: image002.jpg Content-Disposition: inline; filename="image002.jpg"; size=998; creation-date="Wed, 15 Nov 2017 05:52:19 GMT"; modification-date="Wed, 15 Nov 2017 05:52:19 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCAAoACgDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDvp/Gt pDO8f2eYlG2k4HNJ/wAJ1Z/8+0/6Vx9/xf3H/XQ1BXzcsyrp2v8AgfTU8qoSim0/vO2/4Tqz/wCf af8AIUf8J1Z/8+0/5CuJ4o4qf7Ur9/wNP7Jw/n9523/CdWf/AD7T/kKK4niij+1K/f8AAX9k4fz+ 8nv/APkIXH/XQ1B1IrSl0y5u7y5kjC7fOKgs2Nx9BTBol7uRSsYZ1yELc1zSo1G3aJ1UsRTjBJyR QorR/sG/3MnloCrbeW6nGeKb/Yl6UDCMZIB2bvmwTjOKn6vV/lK+tUv5kUKK0bjSHsY919IIi3CB RuB+tFJ0ZRdmhxrwmrxZ0X9garFNKYJ7fy2kMih1yVJ7j3pBoOteeJvtVsXCeXkr1FFFfTfVoeZ8 n9an5fcOfRNbkkDtdW24PvHy98Yq0+laj9jCK8IuMBfNz6HNFFUsNDXcl4mbtovuM688Matf48+4 tztORtBGT60UUVlLAUZu8r/ebxzGvBcsbfcf/9k= --_004_9E32478DFA9976438E7A22F69B08FF921EABE047OPEXCLILMA4corp_-- From nobody Tue Nov 14 23:56: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 4AA4B124BE8 for ; Tue, 14 Nov 2017 23:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 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_H4=-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=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 fHnQMLJJew7w for ; Tue, 14 Nov 2017 23:56:53 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0120.outbound.protection.outlook.com [104.47.34.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE0EC12953B for ; Tue, 14 Nov 2017 23:56:53 -0800 (PST) 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=xuwQK7EKWxRWg9+JHZYGZbah6f23/zlb3pKbvoWa13U=; b=GnApDNFklVshGeclY7g8Sj6sq4LnRZlG261GrhNiuS0k5f8dDgcz2bxVa1VrrZV4Yme+G4Q9mDkVfdtPZTpWk5A3iySyjJ4l96OXEaVHhWSr2Q49ODu3ckJ8P0lFWCPDtiNR+TWp52AhvvoJ2CVQYDZgGn8IFa/7wKFOrsOEHbo= Received: from CY4PR0201MB3603.namprd02.prod.outlook.com (52.132.99.21) by CY4PR0201MB3603.namprd02.prod.outlook.com (52.132.99.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.12; Wed, 15 Nov 2017 07:56:52 +0000 Received: from CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::dce9:6773:68c7:10f3]) by CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::dce9:6773:68c7:10f3%13]) with mapi id 15.20.0218.015; Wed, 15 Nov 2017 07:56:52 +0000 From: Jonathan Hardwick To: "stephane.litkowski@orange.com" , "pce@ietf.org" Thread-Topic: Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing Thread-Index: AdNcnZvYi2xVxqg4QzKXbgSaVFI8tABEh7zwAAz268A= Date: Wed, 15 Nov 2017 07:56:52 +0000 Message-ID: References: <20853_1510591095_5A09CA77_20853_54_2_9E32478DFA9976438E7A22F69B08FF921EABC22A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-originating-ip: [2001:67c:370:128:90b6:90d1:8393:7ca0] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR0201MB3603; 6:x2sPavghtuEJoKucEZeqy4QuWrF2CIMRRQrL4WS7dx8WSYhGn5KEGT53WcTI9A4JSljASVC30Jb4d+g9QVGZnmBtXqu4uOkMFRgJr68PHqKdeq7UOqNbjtlNvHkPpvfPGLqNny2M5jH86xnC02MoGzK2GHiqdZm3bAqb4mcop8TMpqGU5S/VBAqQKKYsmgrEfBTwaDLm7JMHWEowmFu3jJgfr72qel7UtjC7UMcVHf/vVabMfMgDTCkVXZxXVjg9lWCz4Mud6/zyvo/6zYlvmEual1qBfgVrrEtViigi2vck0nOVts8ipDyVbxyltcKeUG+/wZ8gaBVNeCd8gcPQqiVoJHcGpEREK6cqucKmiD0=; 5:OkGwT10OJ7mjPdSbBgnPEeiG8Y11ZgMzQxbUwHRQFXAmm46bVF45sVrxmASew560Yc1x5WciDhJ79771KhJ1FhXrD9lEDE1gNe4kyLyHzPtjOnlPTiPVEkWzy6pvMHHtO9FOwMgzfABFMisppZtBC0lMKGPF2mkZj/Vm0TnhnE4=; 24:e9gs3GIVQyPRp7lAMjjfgJBSTcX2stah6hbApaqM/nm5j4IsFKfNNq3rkLKYhl5NjIbBTg4/VI56qEL3ajVonEls0Zmq3vM2Hd6AaD/Dhuc=; 7:ACoa3BkYoZPlg16BD9sRuY8E1WOYQS9zaAFzNdz6WbJ6DDN0HfE+F+WFUJxKYmMXB5SR2H0PPiKEnPoN3Enzgnh0AG6KTsf4o+qRXRb1zefcGLVYwcpKcmX9RaWpyUyrDqP+8jiaDgJUHtYBhfs6H1rCQUaeHQVymCUqbg04u3e4iHMjulWqryOKr+fI56XeN8AKaZoXTc8FYhg/TqSKw9gmDgcugZLJ+nXR8NFTU8j54hU6I8PpfSogV1thtLuY x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 441d4e6a-27fc-426b-9384-08d52bfe6f19 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199)(49563074); SRVR:CY4PR0201MB3603; x-ms-traffictypediagnostic: CY4PR0201MB3603: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(115448073456579)(81850148713716)(227612066756510)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231022)(10201501046)(3002001)(100000703101)(100105400095)(6041248)(20161123562025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR0201MB3603; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR0201MB3603; x-forefront-prvs: 0492FD61DD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(37854004)(199003)(189002)(50986999)(106356001)(478600001)(2501003)(110136005)(7736002)(5660300001)(7696004)(5890100001)(105586002)(72206003)(99286004)(230783001)(316002)(97736004)(99936001)(606006)(189998001)(2940100002)(53546010)(54356999)(2950100002)(76176999)(14454004)(6436002)(2900100001)(54556002)(54896002)(236005)(101416001)(8936002)(74316002)(102836003)(3280700002)(9686003)(53936002)(229853002)(6506006)(33656002)(68736007)(8676002)(3660700001)(6306002)(81156014)(2906002)(86362001)(5250100002)(55016002)(6246003)(25786009)(81166006)(733005)(790700001)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR0201MB3603; H:CY4PR0201MB3603.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/related; boundary="_004_CY4PR0201MB3603F77E8D355A6D74E741C584290CY4PR0201MB3603_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-Network-Message-Id: 441d4e6a-27fc-426b-9384-08d52bfe6f19 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2017 07:56:52.7177 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0201MB3603 Archived-At: Subject: Re: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing 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, 15 Nov 2017 07:56:56 -0000 --_004_CY4PR0201MB3603F77E8D355A6D74E741C584290CY4PR0201MB3603_ Content-Type: multipart/alternative; boundary="_000_CY4PR0201MB3603F77E8D355A6D74E741C584290CY4PR0201MB3603_" --_000_CY4PR0201MB3603F77E8D355A6D74E741C584290CY4PR0201MB3603_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Actually, since I wrote this: > I think it should be acceptable for the PCUpd not to include the PATH-SET= UP-TYPE, with the implication that there is no change to the path type. I read this in draft-ietf-pce-lsp-setup-type: > The absence of the PATH-SETUP-TYPE TLV is equivalent to an PATH-SETUP-TYP= E TLV with an PST value of 0. What it doesn't say, but I think it means to say, is "... unless there is s= ome other way to infer the path setup type from the message." So, if we fo= llow my suggestion below, we would have to make it explicit that the path s= etup type for a PCUpd can be inferred from the current path setup type of t= he LSP (unless it is given explicitly), which is a change to draft-ietf-pce= -lsp-setup-type. Does anyone else have an opinion on this? Thanks Jon From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Jonathan Hardwick Sent: 15 November 2017 09:28 To: stephane.litkowski@orange.com; pce@ietf.org Subject: Re: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-set= up-type & draft-ietf-pce-segment-routing I think it should be acceptable for the PCUpd not to include the PATH-SETUP= -TYPE, with the implication that there is no change to the path type. Although I'm not convinced it would be a good idea operationally, I don't t= hink there's any need to prevent the path type changing on the PCUpd, if an= explicit PATH-SETUP-TYPE is given. That is, draft-ietf-pce-lsp-setup-type= , as a base draft, should allow that flexibility. A given device may choos= e not to allow that, of course. Does that sound reasonable? Cheers Jon From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of stephane.litkowski@ora= nge.com Sent: 14 November 2017 00:38 To: pce@ietf.org Subject: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-t= ype & draft-ietf-pce-segment-routing Hi WG, I'm facing an interop issue between two PCEP implementations. PCE from vendor1 sends the PCInitiate for an SRTE LSP using the PST=3D1 in = the SRP Object. PCC from vendor2 handles it correctly and delegates the LSP to the PCE usin= g PST=3D1. When the PCE sends a PCUpdate message, it does not set the PST TLV in the S= RP Object. The PCC rejects the PCUpdate because of a bad ERO subobject type. It reads = the PCUpdate as having PST type=3D0. Based on my reading of draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segme= nt-routing. PST draft tells that for the PCE Initiation case, the PCE MAY include the P= ST if the message does not ave any other means of indicating the path setup= type. SR draft tells "In order to setup an SR-TE LSP using SR, RP or SRP o= bject MUST include PATH-SETUP-TYPE TLV". Unfortunately it does not specify = explicitly in which message. From a reading perspective, we can understand = from "In order to setup" that it applies to the PCInitiate message. But not= hing tells about the PCUpdate message. However draft-ietf-pce-lsp-setup-type tells for the stateful PCE case that:= "if the path setup type cannot be unambiguously inferred from ERO or any o= ther object or TLV, PATH-SETUP-TYPE TLV MAY be used in PCRpt and PCUpd mess= ages." In our case (PCE initiated) as the LSP has initially been setup through a P= CInitiate message having the PST TLV, the PCC can infer that futher updates= will use EROs associated with the same PST. Or do we allow to change the PST through PCUpdate messages which may requir= e to always set the PST ? (moving from RSVP-TE to SR or the other way for = a particular LSP) I would like to hear opinions of the WG on that problem ? Thanks, Brgds, [Orange logo] Stephane Litkowski Network Architect Orange/SCE/EQUANT/OINIS/NET Orange Expert Future Networks phone: +33 2 23 06 49 83 NEW ! mobile: +33 6 71 63 27 50 NEW ! stephane.litkowski@orange.com ___________________________________________________________________________= ______________________________________________ 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. --_000_CY4PR0201MB3603F77E8D355A6D74E741C584290CY4PR0201MB3603_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Actually,= since I wrote this:

&nbs= p;

> I think it should be acceptab= le for the PCUpd not to include the PATH-SETUP-TYPE, with the implication t= hat there is no change to the path type.

&nbs= p;

I read th= is in draft-ietf-pce-lsp-setup-type:

&nbs= p;

> The = absence of the PATH-SETUP-TYPE TLV is equivalent to an PATH-SETUP-TYPE TLV = with an PST value of 0.

&nbs= p;

What it d= oesn’t say, but I think it means to say, is “… unless the= re is some other way to infer the path setup type from the message.”&= nbsp; So, if we follow my suggestion below, we would have to make it explicit that the path setup type for a PCUpd can be inferred from the = current path setup type of the LSP (unless it is given explicitly), which i= s a change to draft-ietf-pce-lsp-setup-type.

&nbs= p;

Does anyo= ne else have an opinion on this?

&nbs= p;

Thanks

Jon<= /o:p>

&nbs= p;

&nbs= p;

From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Jonathan Hardwick
Sent: 15 November 2017 09:28
To: stephane.litkowski@orange.com; pce@ietf.org
Subject: Re: [Pce] Clarifications on PST handling in draft-ietf-pce-= lsp-setup-type & draft-ietf-pce-segment-routing

 

I think i= t should be acceptable for the PCUpd not to include the PATH-SETUP-TYPE, wi= th the implication that there is no change to the path type.

&nbs= p;

Although = I’m not convinced it would be a good idea operationally, I don’= t think there’s any need to prevent the path type changing on the PCU= pd, if an explicit PATH-SETUP-TYPE is given.  That is, draft-ietf-pce-lsp-setup-type, as a base draft, should allow that flexibil= ity.  A given device may choose not to allow that, of course.

&nbs= p;

Does that= sound reasonable?

Cheers

Jon<= /o:p>

&nbs= p;

&nbs= p;

From: Pce [mailto:pce-bounces= @ietf.org] On Behalf Of stepha= ne.litkowski@orange.com
Sent: 14 November 2017 00:38
To: pce@ietf.org
Subject: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-= setup-type & draft-ietf-pce-segment-routing

 

Hi WG,

 

I’m facing an interop iss= ue between two PCEP implementations.

PCE from vendor1 sends the PCIn= itiate for an SRTE LSP using the PST=3D1 in the SRP Object.

PCC from vendor2 handles it cor= rectly and delegates the LSP to the PCE using PST=3D1.

When the PCE sends a PCUpdate m= essage, it does not set the PST TLV in the SRP Object.

The PCC rejects the PCUpdate be= cause of a bad ERO subobject type. It reads the PCUpdate as having PST type= =3D0.

 

Based on my reading of draft-ie= tf-pce-lsp-setup-type & draft-ietf-pce-segment-routing.

PST draft tells that for the PC= E Initiation case, the PCE MAY include the PST if the message does not ave = any other means of indicating the path setup type. SR draft tells “In= order to setup an SR-TE LSP using SR, RP or SRP object MUST include PATH-SETUP-TYPE TLV”. Unfortunately it do= es not specify explicitly in which message. From a reading perspective, we = can understand from “In order to setup” that it applies to the = PCInitiate message. But nothing tells about the PCUpdate message.

However draft-ietf-pce-lsp-setu= p-type tells for the stateful PCE case that: “if the path setup type = cannot be unambiguously inferred from ERO or any other object or TLV, PATH-= SETUP-TYPE TLV MAY be used in PCRpt and PCUpd messages.”

In our case (PCE initiated) as = the LSP has initially been setup through a PCInitiate message having the PS= T TLV, the PCC can infer that futher updates will use EROs associated with = the same PST.

 

Or do we allow to change the PS= T through PCUpdate messages which may require to  always set the PST ?= (moving from RSVP-TE to SR or the other way for a particular LSP)

 

I would like to hear opinions of = the WG on that problem ?

 

Thanks,

 

Brgds,

 

 

3D"Orange

&nbs= p;

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET

Orange Expert Future Netwo= rks

phone: +33 2 23 06 49 83  NEW ! mobile: +33 6 71 63 27 50  NEW = ;!
stephane.litk= owski@orange.com

 

_________________________________________________=
________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir=
 des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler=

a l'expediteur et le detruire ainsi que les piece=
s jointes. Les messages electroniques etant susceptibles d'alteration,=

Orange decline toute responsabilite si ce message=
 a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain conf=
idential or privileged information that may be protected by law;=

they should not be distributed, used or copied wi=
thout authorisation.
If you have received this email in error, please =
notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable fo=
r messages that have been modified, changed or falsified.=

Thank you.
--_000_CY4PR0201MB3603F77E8D355A6D74E741C584290CY4PR0201MB3603_-- --_004_CY4PR0201MB3603F77E8D355A6D74E741C584290CY4PR0201MB3603_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=1119; creation-date="Wed, 15 Nov 2017 07:56:51 GMT"; modification-date="Wed, 15 Nov 2017 07:56:51 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCAAyADIDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD02bxP pcMrRvcAOpwRg00eLNJx/wAfI/I1wepD/iZXP++arV8/LNKsZWsj6KnlFKcE7s9F/wCEt0n/AJ+R +Ro/4S3Sf+fkfka86xRip/tar2Rf9jUf5mei/wDCW6T/AM/I/I0f8JbpP/PyPyNedYoxR/a1Xsg/ saj/ADM9G/4S3Sf+fkfkaK85xRR/a1Xsg/saj/My1qf/ACErn/fNVcYq1qg/4mlyP9s1V5Oa86p8 R6dD+HEB0ooHQetFZmtwooooAKKOPUUUWFc1Z9MlvNRvZFkSOOOTDSOeAaRvD10ElaSSKNI8fMTw a1W07V4bq6Edmk1vO+4qx4NNubPX7u3khktE2SEHg/dx2r1vqsL3cWeKsZNJJSVjMbw/di0Nwrxu qgdKWXw5dxKxDxOyEBkU8jPStd4/EDwPGbGIb1CnB9KaLbXjcSyfZEHm7dxB54o+qU9PdYfXauvv RMp/Dt0uQrxO4cKyKeQTUkuhDT4zNqDFo87f3RyVNdDew3/ksbS0YXDMrlyAOR61l31hrl/EY5LJ EBO5ip6mnPCwgnaLuKGMqVGuaaSMEi0BOGlx9KKu/wDCK6qefsv60Vx+xqfyM7vrFL/n4vvPR+5/ Cl9aKK+pPkhe1J/eoop9hMT+7TgKKKb3FHYjJOTRRRVgf//Z --_004_CY4PR0201MB3603F77E8D355A6D74E741C584290CY4PR0201MB3603_-- From nobody Wed Nov 15 07:31: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 EE2BB1241FC for ; Wed, 15 Nov 2017 07:31:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PW60iag_mCt for ; Wed, 15 Nov 2017 07:31:38 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5F21204DA for ; Wed, 15 Nov 2017 07:31:38 -0800 (PST) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id B5B351C5D3C69 for ; Wed, 15 Nov 2017 15:31:34 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 15 Nov 2017 15:31:36 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.246]) by SJCEML702-CHM.china.huawei.com ([169.254.4.7]) with mapi id 14.03.0361.001; Wed, 15 Nov 2017 07:31:24 -0800 From: Hesham ElBakoury To: "pce@ietf.org" Thread-Topic: Call for Papers for IEEE Communications Standards Magazine Feature Topic Issue on Standards for Major Internet Disruptors: Blockchain, Intents, and Related Paradigms Thread-Index: AQHTXibLs36ShrobykeaHhGCQBgDzw== Date: Wed, 15 Nov 2017 15:31:23 +0000 Message-ID: References: <20853_1510591095_5A09CA77_20853_54_2_9E32478DFA9976438E7A22F69B08FF921EABC22A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.195.34.252] Content-Type: multipart/alternative; boundary="_000_C3855D43D6701846AD1151A536E7A0583C84BD03SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Pce] Call for Papers for IEEE Communications Standards Magazine Feature Topic Issue on Standards for Major Internet Disruptors: Blockchain, Intents, and Related Paradigms 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, 15 Nov 2017 15:31:41 -0000 --_000_C3855D43D6701846AD1151A536E7A0583C84BD03SJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Colleagues IEEE ComSoc is having a special issue on current and coming disruptive tech= nologies including Blockchain, Intents and related technology. The details= of the CFP is in IEEE Comsoc website: http://www.comsoc.org/comstandardsmag/cfp/standards= -major-internet-disruptors-blockchain-intents-and-related-paradigms I do invite you to submit a paper detailing your current research or deploy= ments in these exciting areas. Please note the following important dates: * Manuscript Submission: January 15, 2018 * Decision Notification: May 1 2018 * Final Manuscripts Due: June 15, 2018 * Feature Topic Publication Date: September 2018 Please do not hesitate to contact me if you have any questions. Sincerely yours Hesham (hesham.elbakoury@huawei.com --_000_C3855D43D6701846AD1151A536E7A0583C84BD03SJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Colleagues

 

IEEE ComSoc is having = a special issue on current and coming disruptive technologies including Blo= ckchain, Intents and  related technology. The details of the CFP is

in IEEE Coms= oc website: http://www.comsoc.org/comstandardsmag/cfp/standards-major-internet-disrupto= rs-blockchain-intents-and-related-paradigms

 

I do invite you to sub= mit a paper detailing your current research or deployments in these excitin= g areas.

 

Please note the follow= ing important dates:

  • Manuscript = Submission: January 15, 2018<= span lang=3D"EN">
  • Decision No= tification: May 1 2018
  • Final Manus= cripts Due: June 15, 2018
  • Feature Top= ic Publication Date: September 2018<= /span>

Please do not hesitate= to contact me if you have any questions.

 

Sincerely yours

 

Hesham (hesham.elbakoury@huawei.com

--_000_C3855D43D6701846AD1151A536E7A0583C84BD03SJCEML701CHMchi_-- From nobody Wed Nov 15 19:50: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 E1AB112025C for ; Wed, 15 Nov 2017 19:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_H4=-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 (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 IYw5HFxJ1bNJ for ; Wed, 15 Nov 2017 19:50:51 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0091.outbound.protection.outlook.com [104.47.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 411C3124BE8 for ; Wed, 15 Nov 2017 19:50:51 -0800 (PST) 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=/pb5wUTaJDBViRa3mX+YUpcRFx9hSjL2ivYusG02YGQ=; b=cWYtGJuNBYfOzq8CzxuLkytHK1gNByltYNuP0GYdr2dpEbHz8Lus77Wrr6bWGsEfF8deVpT/bmn5rWR8iaFwa/tkNMY/PhKAcsnWtbYuyT/JuEWvHznAUAPKrhf90oRSsN3qs1yYGnfoy7tJWmJPxqDFm0NuTX6KL+qlv8HxOq0= Received: from CY4PR0201MB3603.namprd02.prod.outlook.com (52.132.99.21) by CY4PR0201MB3603.namprd02.prod.outlook.com (52.132.99.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.12; Thu, 16 Nov 2017 03:50:49 +0000 Received: from CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::dce9:6773:68c7:10f3]) by CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::dce9:6773:68c7:10f3%13]) with mapi id 15.20.0218.015; Thu, 16 Nov 2017 03:50:49 +0000 From: Jonathan Hardwick To: "stephane.litkowski@orange.com" , "pce@ietf.org" Thread-Topic: Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing Thread-Index: AdNcnZvYi2xVxqg4QzKXbgSaVFI8tABEh7zwAAjZZHAALpQtsA== Date: Thu, 16 Nov 2017 03:50:48 +0000 Message-ID: References: <20853_1510591095_5A09CA77_20853_54_2_9E32478DFA9976438E7A22F69B08FF921EABC22A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <1346_1510725141_5A0BD615_1346_83_1_9E32478DFA9976438E7A22F69B08FF921EABE047@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: <1346_1510725141_5A0BD615_1346_83_1_9E32478DFA9976438E7A22F69B08FF921EABE047@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-originating-ip: [2001:67c:370:128:c33:bcef:414c:a6aa] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR0201MB3603; 6:4i/CSAG1oVwoK1NCvWolQ/UZvF8Gmrgt2wFGumOkNbvZ57U9hcnUcbUF/F9w4Yp6E11H1SnKetU+9vDyGBSUJfjXkDLYM+uZyN+yRa5OIGkf4aamBqw62F+Swv2Jm6uBiK4di8oS83b2aDSFMvcPSP7rWOZ6suX8hPnhkLJQ9umjutdItgcthPnJdQBk3d/YfbWFxKJE9uVTvGeTI2V4RNAoS9pROcSD8WOgOdR+fYHvdrDPMRr1jkv5no7+wytLXu4nf8eHrNeHko7CkV1Y/pfe4rP90O1M0ppUafsNPd45rKFspDocs9ODvXuycyQl4pqjVa+dHW0xVGoFaccXTapbpThXxsQq5ykgvC10Am8=; 5:sv5rTOb+P7+zj7jIK73OkDoyd2vybsNgMztGjXdnth0h96oNA76mDVnweYu0cEvTHaqSZ3U0Toy+YpLOpRjWkRdYJRF0mtqeOkVd5LxkJGMJScqJGNf8EdhkM8OsR7E8dO/FOBU0JZo68zmVTmGz2kw/iuvVFcO+biG0LAPgt00=; 24:NvDJjI8/M3tyukIwrbRvhLEtW/rgIK2cfqL2Mmbvl2+Zw01H/QGHacFGeYlZFPgAU8Pyyh08OBCgw3F01KqtG2nexm+9M9KX1o97U4Zo6cU=; 7:6602TlH7f4SuJf1Qt42VpEbsS8B1MfOOQjuNqHQP/gAoYo46Ommhxq8dVd0xslRWmLJRqWdLYgeRas8ldrUKGNtc++kpKvRwWrwTj6F9KhCb+GWdDnjqSGoutrzSg03aPvtuOjUPeyoy5vLcsQPd5Ggy26KopPCDrmeL3YIj6kt/60vF5dsnrtAb3jR0TMgok3PS1E/XTxuWmUNPuuQCqBm+JzSVYX+Op5dOdgastA+OrxSSnYEFHzLMxgOzGcsU x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: b9986b9b-73d0-4906-b1ab-08d52ca539aa x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199)(49563074); SRVR:CY4PR0201MB3603; x-ms-traffictypediagnostic: CY4PR0201MB3603: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(115448073456579)(81850148713716)(227612066756510)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(10201501046)(3231022)(93006095)(93001095)(6041248)(20161123564025)(20161123558100)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR0201MB3603; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR0201MB3603; x-forefront-prvs: 0493852DA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(51914003)(189002)(37854004)(199003)(53546010)(106356001)(478600001)(2501003)(7696004)(7736002)(110136005)(5660300001)(5890100001)(105586002)(316002)(72206003)(99286004)(230783001)(97736004)(606006)(99936001)(189998001)(50986999)(54356999)(2950100002)(76176999)(2900100001)(14454004)(6436002)(236005)(54556002)(101416001)(8936002)(102836003)(74316002)(55016002)(9686003)(229853002)(53936002)(68736007)(33656002)(54896002)(6306002)(3660700001)(8676002)(81166006)(86362001)(81156014)(5250100002)(2906002)(3280700002)(6246003)(6116002)(25786009)(790700001)(733005)(6506006); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR0201MB3603; H:CY4PR0201MB3603.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/related; boundary="_004_CY4PR0201MB3603964BD2AE1FA4799044A0842E0CY4PR0201MB3603_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-Network-Message-Id: b9986b9b-73d0-4906-b1ab-08d52ca539aa X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2017 03:50:48.9944 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0201MB3603 Archived-At: Subject: Re: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing 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, 16 Nov 2017 03:50:54 -0000 --_004_CY4PR0201MB3603964BD2AE1FA4799044A0842E0CY4PR0201MB3603_ Content-Type: multipart/alternative; boundary="_000_CY4PR0201MB3603964BD2AE1FA4799044A0842E0CY4PR0201MB3603_" --_000_CY4PR0201MB3603964BD2AE1FA4799044A0842E0CY4PR0201MB3603_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Stephane OK, let's go with solution (2). That is, if the PATH-SETUP-TYPE is not pre= sent in a message, then it unambiguously means that the path setup type is = RSVP-TE. Then implementations don't have to try to infer the path setup ty= pe from other objects or previous messages. I am revising draft-ietf-pce-lsp-setup-type at the moment to address an ear= lier comment from Julien, so I will include this clarification in the next = revision. Thanks for the input! Cheers Jon From: stephane.litkowski@orange.com [mailto:stephane.litkowski@orange.com] Sent: 15 November 2017 13:52 To: Jonathan Hardwick ; pce@ietf.org Subject: RE: Clarifications on PST handling in draft-ietf-pce-lsp-setup-typ= e & draft-ietf-pce-segment-routing Hi Jon, Thanks for your feedback. I see two possibilities here. 1. When the PATH-SETUP-TYPE is not present in a PCUpd, it should be infe= rred from the latest one received (in a PCInitiate or in a PCUpd). When ini= tiating an LSP, the PCInitiate contains the PST to let the PCC know about t= he path type. Then, it can be omitted in further PCUpd except when the PCE = wants to change the path type. At that time, it sends a PCUpd with a new PA= TH-SETUP-TYPE value and then it does not need to include it in further upda= tes until the PCE needs to change it again. 2. We mandate the PCE to put the PATH-SETUP-TYPE in all PCUpd. IMO, solution 2) is easier for implementations and operation. Brgd, Stephane From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com] Sent: Wednesday, November 15, 2017 09:28 To: LITKOWSKI Stephane OBS/OINIS; pce@ietf.org Subject: RE: Clarifications on PST handling in draft-ietf-pce-lsp-setup-typ= e & draft-ietf-pce-segment-routing I think it should be acceptable for the PCUpd not to include the PATH-SETUP= -TYPE, with the implication that there is no change to the path type. Although I'm not convinced it would be a good idea operationally, I don't t= hink there's any need to prevent the path type changing on the PCUpd, if an= explicit PATH-SETUP-TYPE is given. That is, draft-ietf-pce-lsp-setup-type= , as a base draft, should allow that flexibility. A given device may choos= e not to allow that, of course. Does that sound reasonable? Cheers Jon From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of stephane.litkowski@ora= nge.com Sent: 14 November 2017 00:38 To: pce@ietf.org Subject: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-t= ype & draft-ietf-pce-segment-routing Hi WG, I'm facing an interop issue between two PCEP implementations. PCE from vendor1 sends the PCInitiate for an SRTE LSP using the PST=3D1 in = the SRP Object. PCC from vendor2 handles it correctly and delegates the LSP to the PCE usin= g PST=3D1. When the PCE sends a PCUpdate message, it does not set the PST TLV in the S= RP Object. The PCC rejects the PCUpdate because of a bad ERO subobject type. It reads = the PCUpdate as having PST type=3D0. Based on my reading of draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segme= nt-routing. PST draft tells that for the PCE Initiation case, the PCE MAY include the P= ST if the message does not ave any other means of indicating the path setup= type. SR draft tells "In order to setup an SR-TE LSP using SR, RP or SRP o= bject MUST include PATH-SETUP-TYPE TLV". Unfortunately it does not specify = explicitly in which message. From a reading perspective, we can understand = from "In order to setup" that it applies to the PCInitiate message. But not= hing tells about the PCUpdate message. However draft-ietf-pce-lsp-setup-type tells for the stateful PCE case that:= "if the path setup type cannot be unambiguously inferred from ERO or any o= ther object or TLV, PATH-SETUP-TYPE TLV MAY be used in PCRpt and PCUpd mess= ages." In our case (PCE initiated) as the LSP has initially been setup through a P= CInitiate message having the PST TLV, the PCC can infer that futher updates= will use EROs associated with the same PST. Or do we allow to change the PST through PCUpdate messages which may requir= e to always set the PST ? (moving from RSVP-TE to SR or the other way for = a particular LSP) I would like to hear opinions of the WG on that problem ? Thanks, Brgds, [Orange logo] Stephane Litkowski Network Architect Orange/SCE/EQUANT/OINIS/NET Orange Expert Future Networks phone: +33 2 23 06 49 83 NEW ! mobile: +33 6 71 63 27 50 NEW ! stephane.litkowski@orange.com ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. --_000_CY4PR0201MB3603964BD2AE1FA4799044A0842E0CY4PR0201MB3603_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Stepha= ne

&nbs= p;

OK, let&#= 8217;s go with solution (2).  That is, if the PATH-SETUP-TYPE is not p= resent in a message, then it unambiguously means that the path setup type i= s RSVP-TE.  Then implementations don’t have to try to infer the path setup type from other objects or previous messages.<= o:p>

&nbs= p;

I am revi= sing draft-ietf-pce-lsp-setup-type at the moment to address an earlier comm= ent from Julien, so I will include this clarification in the next revision.=

&nbs= p;

Thanks fo= r the input!

Cheers

Jon<= /o:p>

&nbs= p;

&nbs= p;

From: stephane.litkowski@orange.com [mailto:stephane.litkowski@orange= .com]
Sent: 15 November 2017 13:52
To: Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com>; pce@= ietf.org
Subject: RE: Clarifications on PST handling in draft-ietf-pce-lsp-se= tup-type & draft-ietf-pce-segment-routing

 

Hi Jon,=

&n= bsp;

Thanks = for your feedback.

I see t= wo possibilities here.

  1. When the PATH-SETUP-TYPE is not present in a PCUpd, it= should be inferred from the latest one received (in a PCInitiate or in a P= CUpd). When initiating an LSP, the PCInitiate contains the PST to let the P= CC know about the path type. Then, it can be omitted in further PCUpd except when the PCE wants to change the= path type. At that time, it sends a PCUpd with a new PATH-SETUP-TYPE value= and then it does not need to include it in further updates until the PCE n= eeds to change it again.
  2. We mandate the PCE to put the PATH-SETUP-TYPE in all P= CUpd.

&n= bsp;

IMO, so= lution 2) is easier for implementations and operation.

&n= bsp;

Brgd,

&n= bsp;

Stephan= e

&n= bsp;

&n= bsp;

From: Jo= nathan Hardwick [mailto= :Jonathan.Hardwick@metaswitch.com]
Sent: Wednesday, November 15, 2017 09:28
To: LITKOWSKI Stephane OBS/OINIS; pc= e@ietf.org
Subject: RE: Clarifications on PST handling in draft-ietf-pce-lsp-se= tup-type & draft-ietf-pce-segment-routing

 

I think it should be acceptable for the PCUpd not to= include the PATH-SETUP-TYPE, with the implication that there is no change = to the path type.

 

Although I’m not convinced it would be a good = idea operationally, I don’t think there’s any need to prevent t= he path type changing on the PCUpd, if an explicit PATH-SETUP-TYPE is given= .  That is, draft-ietf-pce-lsp-setup-type, as a base draft, should allow that flexibility.  A given device may choose not = to allow that, of course.

 

Does that sound reasonable?

Cheers

Jon

 

 

From: Pce [mailto:pce-bounces= @ietf.org] On Behalf Of stepha= ne.litkowski@orange.com
Sent: 14 November 2017 00:38
To: pce@ietf.org
Subject: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-= setup-type & draft-ietf-pce-segment-routing

 

Hi WG,

 

I’m facing an interop iss= ue between two PCEP implementations.

PCE from vendor1 sends the PCIn= itiate for an SRTE LSP using the PST=3D1 in the SRP Object.

PCC from vendor2 handles it cor= rectly and delegates the LSP to the PCE using PST=3D1.

When the PCE sends a PCUpdate m= essage, it does not set the PST TLV in the SRP Object.

The PCC rejects the PCUpdate be= cause of a bad ERO subobject type. It reads the PCUpdate as having PST type= =3D0.

 

Based on my reading of draft-ie= tf-pce-lsp-setup-type & draft-ietf-pce-segment-routing.

PST draft tells that for the PC= E Initiation case, the PCE MAY include the PST if the message does not ave = any other means of indicating the path setup type. SR draft tells “In= order to setup an SR-TE LSP using SR, RP or SRP object MUST include PATH-SETUP-TYPE TLV”. Unfortunately it do= es not specify explicitly in which message. From a reading perspective, we = can understand from “In order to setup” that it applies to the = PCInitiate message. But nothing tells about the PCUpdate message.

However draft-ietf-pce-lsp-setu= p-type tells for the stateful PCE case that: “if the path setup type = cannot be unambiguously inferred from ERO or any other object or TLV, PATH-= SETUP-TYPE TLV MAY be used in PCRpt and PCUpd messages.”

In our case (PCE initiated) as = the LSP has initially been setup through a PCInitiate message having the PS= T TLV, the PCC can infer that futher updates will use EROs associated with = the same PST.

 

Or do we allow to change the PS= T through PCUpdate messages which may require to  always set the PST ?= (moving from RSVP-TE to SR or the other way for a particular LSP)

 

I would like to hear opinions of = the WG on that problem ?

 

Thanks,

 

Brgds,

 

 

3D"Orange

&nbs= p;

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET

Orange Expert Future Netwo= rks

phone: +33 2 23 06 49 83  NEW ! mobile: +33 6 71 63 27 50  NEW = ;!
stephane.litk= owski@orange.com

 

_________________________________________________=
________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir=
 des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler=

a l'expediteur et le detruire ainsi que les piece=
s jointes. Les messages electroniques etant susceptibles d'alteration,=

Orange decline toute responsabilite si ce message=
 a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain conf=
idential or privileged information that may be protected by law;=

they should not be distributed, used or copied wi=
thout authorisation.
If you have received this email in error, please =
notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable fo=
r messages that have been modified, changed or falsified.=

Thank you.
_________________________________________________=
________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir=
 des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler=

a l'expediteur et le detruire ainsi que les piece=
s jointes. Les messages electroniques etant susceptibles d'alteration,=

Orange decline toute responsabilite si ce message=
 a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain conf=
idential or privileged information that may be protected by law;=

they should not be distributed, used or copied wi=
thout authorisation.
If you have received this email in error, please =
notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable fo=
r messages that have been modified, changed or falsified.=

Thank you.
--_000_CY4PR0201MB3603964BD2AE1FA4799044A0842E0CY4PR0201MB3603_-- --_004_CY4PR0201MB3603964BD2AE1FA4799044A0842E0CY4PR0201MB3603_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=1098; creation-date="Thu, 16 Nov 2017 03:50:48 GMT"; modification-date="Thu, 16 Nov 2017 03:50:48 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCAAyADIDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0ufxN psMjRvON6deKQeLNLwP3/wClcHqCj+0Ljgdar4HpXgSzOqux79PKqU43uz0Q+K9K7z/pSf8ACV6V /wA/A/KvPNoPajaPQVP9q1fI1/sel/Mz0P8A4SvSv+fgflR/wlek/wDPwPyrzvaPQUbPYUf2rV8g /sel/Mz0X/hK9J/5+B+VFedbPYUUf2rV8g/sal/MyzqP/IQn+tVgeOtWtS/5CM496q461507cx6W HkvZoUHij8aMDgd6Mc1nobXQfjRz60YHtRikF0w59aKTPsfyoosBqS6ZLd312ysqRo2Gc0jeH7kR yPJIiIuMN61qvp+rQXVz5Vqs0Er7ird6S4tdduYGhe3j2sQQB2xXsfVYXvY8OOMqJWUkZp8P3f2c zK6OoAwPWiTw9doGIZXKkZQds1rFNe8gx/ZE6AflSJb64J3f7Oo8wjOPaj6rD+UPrtX+ZGU/h+6G djI7hgHQdRmnzaH9giM1++9B0Cdq6G8hvhCTaW+J2YMT9Kyr6x1u/jMUtqqg/eIPWiWGjFO0RQxd SbXNJIxNloeRNLj6UVcHh7VQMCE4HvRXL7B/ys7Pbr+dHo56fhQKKK+lPkhQelJnr9KKKfVB0Eye Kevaiir6kxHUUUUjQ//Z --_004_CY4PR0201MB3603964BD2AE1FA4799044A0842E0CY4PR0201MB3603_-- From nobody Wed Nov 15 21:26: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 E93EF1201F2 for ; Wed, 15 Nov 2017 21:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.398 X-Spam-Level: X-Spam-Status: No, score=-5.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHQhicMrm6zQ for ; Wed, 15 Nov 2017 21:26:01 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5B9A127010 for ; Wed, 15 Nov 2017 21:26:00 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id A0637205B8; Thu, 16 Nov 2017 06:25:59 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 7DDC11C0064; Thu, 16 Nov 2017 06:25:59 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0361.001; Thu, 16 Nov 2017 06:25:59 +0100 From: To: Jonathan Hardwick , "pce@ietf.org" Thread-Topic: Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing Thread-Index: AdNcnZvYi2xVxqg4QzKXbgSaVFI8tABEh7zwAAjZZHAALpQtsAADWOgA Date: Thu, 16 Nov 2017 05:25:58 +0000 Message-ID: <3955_1510809959_5A0D2167_3955_376_1_9E32478DFA9976438E7A22F69B08FF921EABED47@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <20853_1510591095_5A09CA77_20853_54_2_9E32478DFA9976438E7A22F69B08FF921EABC22A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <1346_1510725141_5A0BD615_1346_83_1_9E32478DFA9976438E7A22F69B08FF921EABE047@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/related; boundary="_004_9E32478DFA9976438E7A22F69B08FF921EABED47OPEXCLILMA4corp_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: Re: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing 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, 16 Nov 2017 05:26:04 -0000 --_004_9E32478DFA9976438E7A22F69B08FF921EABED47OPEXCLILMA4corp_ Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF921EABED47OPEXCLILMA4corp_" --_000_9E32478DFA9976438E7A22F69B08FF921EABED47OPEXCLILMA4corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Jon. From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com] Sent: Thursday, November 16, 2017 11:51 To: LITKOWSKI Stephane OBS/OINIS; pce@ietf.org Subject: RE: Clarifications on PST handling in draft-ietf-pce-lsp-setup-typ= e & draft-ietf-pce-segment-routing Hi Stephane OK, let's go with solution (2). That is, if the PATH-SETUP-TYPE is not pre= sent in a message, then it unambiguously means that the path setup type is = RSVP-TE. Then implementations don't have to try to infer the path setup ty= pe from other objects or previous messages. I am revising draft-ietf-pce-lsp-setup-type at the moment to address an ear= lier comment from Julien, so I will include this clarification in the next = revision. Thanks for the input! Cheers Jon From: stephane.litkowski@orange.com [= mailto:stephane.litkowski@orange.com] Sent: 15 November 2017 13:52 To: Jonathan Hardwick >; pce@ietf.org Subject: RE: Clarifications on PST handling in draft-ietf-pce-lsp-setup-typ= e & draft-ietf-pce-segment-routing Hi Jon, Thanks for your feedback. I see two possibilities here. 1. When the PATH-SETUP-TYPE is not present in a PCUpd, it should be infe= rred from the latest one received (in a PCInitiate or in a PCUpd). When ini= tiating an LSP, the PCInitiate contains the PST to let the PCC know about t= he path type. Then, it can be omitted in further PCUpd except when the PCE = wants to change the path type. At that time, it sends a PCUpd with a new PA= TH-SETUP-TYPE value and then it does not need to include it in further upda= tes until the PCE needs to change it again. 2. We mandate the PCE to put the PATH-SETUP-TYPE in all PCUpd. IMO, solution 2) is easier for implementations and operation. Brgd, Stephane From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com] Sent: Wednesday, November 15, 2017 09:28 To: LITKOWSKI Stephane OBS/OINIS; pce@ietf.org Subject: RE: Clarifications on PST handling in draft-ietf-pce-lsp-setup-typ= e & draft-ietf-pce-segment-routing I think it should be acceptable for the PCUpd not to include the PATH-SETUP= -TYPE, with the implication that there is no change to the path type. Although I'm not convinced it would be a good idea operationally, I don't t= hink there's any need to prevent the path type changing on the PCUpd, if an= explicit PATH-SETUP-TYPE is given. That is, draft-ietf-pce-lsp-setup-type= , as a base draft, should allow that flexibility. A given device may choos= e not to allow that, of course. Does that sound reasonable? Cheers Jon From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of stephane.litkowski@ora= nge.com Sent: 14 November 2017 00:38 To: pce@ietf.org Subject: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-t= ype & draft-ietf-pce-segment-routing Hi WG, I'm facing an interop issue between two PCEP implementations. PCE from vendor1 sends the PCInitiate for an SRTE LSP using the PST=3D1 in = the SRP Object. PCC from vendor2 handles it correctly and delegates the LSP to the PCE usin= g PST=3D1. When the PCE sends a PCUpdate message, it does not set the PST TLV in the S= RP Object. The PCC rejects the PCUpdate because of a bad ERO subobject type. It reads = the PCUpdate as having PST type=3D0. Based on my reading of draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segme= nt-routing. PST draft tells that for the PCE Initiation case, the PCE MAY include the P= ST if the message does not ave any other means of indicating the path setup= type. SR draft tells "In order to setup an SR-TE LSP using SR, RP or SRP o= bject MUST include PATH-SETUP-TYPE TLV". Unfortunately it does not specify = explicitly in which message. From a reading perspective, we can understand = from "In order to setup" that it applies to the PCInitiate message. But not= hing tells about the PCUpdate message. However draft-ietf-pce-lsp-setup-type tells for the stateful PCE case that:= "if the path setup type cannot be unambiguously inferred from ERO or any o= ther object or TLV, PATH-SETUP-TYPE TLV MAY be used in PCRpt and PCUpd mess= ages." In our case (PCE initiated) as the LSP has initially been setup through a P= CInitiate message having the PST TLV, the PCC can infer that futher updates= will use EROs associated with the same PST. Or do we allow to change the PST through PCUpdate messages which may requir= e to always set the PST ? (moving from RSVP-TE to SR or the other way for = a particular LSP) I would like to hear opinions of the WG on that problem ? Thanks, Brgds, [Orange logo] Stephane Litkowski Network Architect Orange/SCE/EQUANT/OINIS/NET Orange Expert Future Networks phone: +33 2 23 06 49 83 NEW ! mobile: +33 6 71 63 27 50 NEW ! stephane.litkowski@orange.com ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. --_000_9E32478DFA9976438E7A22F69B08FF921EABED47OPEXCLILMA4corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Jon.=

 

From: Jonathan= Hardwick [mailto:Jonathan.Hardwick@metaswitch.com]
Sent: Thursday, November 16, 2017 11:51
To: LITKOWSKI Stephane OBS/OINIS; pce@ietf.org
Subject: RE: Clarifications on PST handling in draft-ietf-pce-lsp-se= tup-type & draft-ietf-pce-segment-routing

 

Hi Stephane

 

OK, let’s go with solutio= n (2).  That is, if the PATH-SETUP-TYPE is not present in a message, t= hen it unambiguously means that the path setup type is RSVP-TE.  Then = implementations don’t have to try to infer the path setup type from other objects or previous messages.

 

I am revising draft-ietf-pce-ls= p-setup-type at the moment to address an earlier comment from Julien, so I = will include this clarification in the next revision.

 

Thanks for the input!

Cheers

Jon

 

 

From: stephane.litkowski@orange.com [mailto:stephane.litkowski@orange.com]
Sent: 15 November 2017 13:52
To: Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com>; pce@ietf.org
Subject: RE: Clarifications on PST handling in draft-ietf-pce-lsp-se= tup-type & draft-ietf-pce-segment-routing

 

Hi Jon,

 

Thanks for your feedba= ck.

I see two possibilitie= s here.

  1. Whe= n the PATH-SETUP-TYPE is not present in a PCUpd, it should be inferred from= the latest one received (in a PCInitiate or in a PCUpd). When initiating a= n LSP, the PCInitiate contains the PST to let the PCC know about the path type. Then, it can be omitted in furthe= r PCUpd except when the PCE wants to change the path type. At that time, it= sends a PCUpd with a new PATH-SETUP-TYPE value and then it does not need t= o include it in further updates until the PCE needs to change it again.
  2. We mandate the PCE to = put the PATH-SETUP-TYPE in all PCUpd.

 

IMO, solution 2) is ea= sier for implementations and operation.

 

Brgd,

 

Stephane

 

 

From: Jonathan= Hardwick [mailto:Jonat= han.Hardwick@metaswitch.com]
Sent: Wednesday, November 15, 2017 09:28
To: LITKOWSKI Stephane OBS/OINIS; pc= e@ietf.org
Subject: RE: Clarifications on PST handling in draft-ietf-pce-lsp-se= tup-type & draft-ietf-pce-segment-routing

 

I think it should be acceptable= for the PCUpd not to include the PATH-SETUP-TYPE, with the implication tha= t there is no change to the path type.

 

Although I’m not convince= d it would be a good idea operationally, I don’t think there’s = any need to prevent the path type changing on the PCUpd, if an explicit PAT= H-SETUP-TYPE is given.  That is, draft-ietf-pce-lsp-setup-type, as a base draft, should allow that flexibility.  A given device may c= hoose not to allow that, of course.

 

Does that sound reasonable?

Cheers

Jon

 

 

From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of stepha= ne.litkowski@orange.com
Sent: 14 November 2017 00:38
To: pce@ietf.org
Subject: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-= setup-type & draft-ietf-pce-segment-routing

 

Hi WG,

 

I’m facing an interop issue between two PCEP i= mplementations.

PCE from vendor1 sends the PCInitiate for an SRTE LS= P using the PST=3D1 in the SRP Object.

PCC from vendor2 handles it correctly and delegates = the LSP to the PCE using PST=3D1.

When the PCE sends a PCUpdate message, it does not s= et the PST TLV in the SRP Object.

The PCC rejects the PCUpdate because of a bad ERO su= bobject type. It reads the PCUpdate as having PST type=3D0.

 

Based on my reading of draft-ietf-pce-lsp-setup-type= & draft-ietf-pce-segment-routing.

PST draft tells that for the PCE Initiation case, th= e PCE MAY include the PST if the message does not ave any other means of in= dicating the path setup type. SR draft tells “In order to setup an SR= -TE LSP using SR, RP or SRP object MUST include PATH-SETUP-TYPE TLV”. Unfortunately it does not specify expl= icitly in which message. From a reading perspective, we can understand from= “In order to setup” that it applies to the PCInitiate message.= But nothing tells about the PCUpdate message.

However draft-ietf-pce-lsp-setup-type tells for the = stateful PCE case that: “if the path setup type cannot be unambiguous= ly inferred from ERO or any other object or TLV, PATH-SETUP-TYPE TLV MAY be= used in PCRpt and PCUpd messages.”

In our case (PCE initiated) as the LSP has initially= been setup through a PCInitiate message having the PST TLV, the PCC can in= fer that futher updates will use EROs associated with the same PST.

 

Or do we allow to change the PST through PCUpdate me= ssages which may require to  always set the PST ? (moving from RSVP-TE= to SR or the other way for a particular LSP)

 

I would like to hear opinions of the= WG on that problem ?

 

Thanks,

 

Brgds,

 

 

3D"Orange

 <= o:p>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET

Orange Expert Future Networks=

phone: +33 2 23 06 49 83  NEW !
mobile: +33 6 71 63 27 50  NEW = ;!
s= tephane.litkowski@orange.com

 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________

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.
--_000_9E32478DFA9976438E7A22F69B08FF921EABED47OPEXCLILMA4corp_-- --_004_9E32478DFA9976438E7A22F69B08FF921EABED47OPEXCLILMA4corp_ Content-Type: image/jpeg; name="image002.jpg" Content-Description: image002.jpg Content-Disposition: inline; filename="image002.jpg"; size=973; creation-date="Thu, 16 Nov 2017 05:25:57 GMT"; modification-date="Thu, 16 Nov 2017 05:25:57 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCAAoACgDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDvZ/Gt pDO0fkSkodpOOtJ/wnVn3t5a5C9OL6f/AH6gz7185LMqye/4H0tPK6MoptP7ztf+E5sv+fab8qP+ E6sv+feb8q4vpSVP9p1u/wCBp/ZOH8/vO1/4Tqy/59pvyorivl9aKP7Trd/wD+ycP5/eTX4/06cf 7dQAE4rRl025urq4eMLt80rlj94+gpBol7uRSsYd1yEJ5rmlRqNvQ6KWIpxgk5Ioc0c1o/2FfZK7 EBU7eT14zxTf7FvSgYRjJAOzPzY6Zqfq9XsX9apfzIoUVoXOkyWUYa9kWMscKFGQfrRUyozi7NDj iacldM6I6BqsU0hhng8tpC6hxkqT3pBoWtfaBN9qgLhdmSvUUUV9L7CJ8n9an5Dn0XW3cM1zBkNu GB3xirT6XqJtAiyRC4wB5v05ooqlh4akvEz8jOvPDOrX+PtE8JCnI2jqaKKKzlgqUndm8MfWirK3 3H//2Q== --_004_9E32478DFA9976438E7A22F69B08FF921EABED47OPEXCLILMA4corp_-- From nobody Wed Nov 15 21:36: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 37B9112421A for ; Wed, 15 Nov 2017 21:36:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 XT0orye_etdk for ; Wed, 15 Nov 2017 21:36:21 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 37293127058 for ; Wed, 15 Nov 2017 21:36:03 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id n61so39900894qte.10 for ; Wed, 15 Nov 2017 21:36:03 -0800 (PST) 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=n6JTyV9YtW30mvs0ZhtZLTNe6C+E4khkTNaoDk5kCmo=; b=YfrzmuzlDtYv6L+UD42TzgsQ0xdKSAjc4AG7lyE+RzD050vTs56huTT1ityAu8WJG1 GRy/1dTRIJpzxR0oTeqc1ODz2ZdiWWFvtdM/obs+vCA5Jf7MNwoo5sHefDQcRNRM/er3 dOw3ofG3gjAosAVQ3t20c032sBDrZpmbCPUr79lfZMe5dB+LqKWwg3W5/7NPyJ70usmU Bl5d9JiEBK5o1tY/KxstMEJNEk2q3bhp0MbGkziZFrD0Hjw4hviJPYoil6JfyYvgjwR2 jp7cvBw4PIH+9Ta2YtIhZCxeHEyZIC4hfoche9TbkFp5Ib1CMTHQVi6B/G4WjqUeE1X1 vP2A== 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=n6JTyV9YtW30mvs0ZhtZLTNe6C+E4khkTNaoDk5kCmo=; b=qw9j6fju5ZuUyCatkKxNJHBhiw11QxSmJOfMvKhrzjFvBu+52+P6YX1RznJnxn7ycb SuZ8uy4Ptlp/TpOm2guWu//jV6If3evp6Qbo8quDTcXnnqB3f3RhdGLnMLvjWHJhFAgp hJGbfgEDBAuUnaXVO5YiGDTkmMQXs8emvJxwZtH0ahyG9AX+Aexmy+zSo1kNJvM4Axx1 khdQXnsNr0zWOq7fxrOPRLuYSiR/eQObJ4H5BK5zOSTU2PUKoRP6oH6tBQ0rwhjFlLeB mpI/uGIBkm2ByPm8GX2nsWPs8i5SBsEcPegh7HhpGIcKmVXwqMDVlRyLAz3IDpJiER1k jEew== X-Gm-Message-State: AJaThX5sOZKVvell2hOH1Oejusrk7O1V5pHxIprbFdwadKQ4NYOM97f+ nruZu1V111G/zixLKCjQAveJ88ABI4yyOl0t5EE= X-Google-Smtp-Source: AGs4zMbrCx8nUnPcztmOEpiwkLSdOaN6FSJYfUokzXJ7qbg/EN5nqH/9U5Hhz7uq1z/BAp4b2A6hB7OWPhFuKmZC4CY= X-Received: by 10.55.94.129 with SMTP id s123mr711868qkb.21.1510810562171; Wed, 15 Nov 2017 21:36:02 -0800 (PST) MIME-Version: 1.0 Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.140.86.17 with HTTP; Wed, 15 Nov 2017 21:36:01 -0800 (PST) In-Reply-To: <3955_1510809959_5A0D2167_3955_376_1_9E32478DFA9976438E7A22F69B08FF921EABED47@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <20853_1510591095_5A09CA77_20853_54_2_9E32478DFA9976438E7A22F69B08FF921EABC22A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <1346_1510725141_5A0BD615_1346_83_1_9E32478DFA9976438E7A22F69B08FF921EABE047@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <3955_1510809959_5A0D2167_3955_376_1_9E32478DFA9976438E7A22F69B08FF921EABED47@OPEXCLILMA4.corporate.adroot.infra.ftgroup> From: Dhruv Dhody Date: Thu, 16 Nov 2017 13:36:01 +0800 X-Google-Sender-Auth: jmOQy_kviBUmM8PHYg8XXz3G_qs Message-ID: To: stephane.litkowski@orange.com Cc: Jonathan Hardwick , "pce@ietf.org" Content-Type: multipart/related; boundary="001a114e2248e1c7af055e12fe88" Archived-At: Subject: Re: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing 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, 16 Nov 2017 05:36:25 -0000 --001a114e2248e1c7af055e12fe88 Content-Type: multipart/alternative; boundary="001a114e2248e1c7ac055e12fe87" --001a114e2248e1c7ac055e12fe87 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 Thanks Jon! On Thu, Nov 16, 2017 at 1:25 PM, wrote: > Thanks Jon. > > > > *From:* Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com] > *Sent:* Thursday, November 16, 2017 11:51 > > *To:* LITKOWSKI Stephane OBS/OINIS; pce@ietf.org > *Subject:* RE: Clarifications on PST handling in > draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing > > > > Hi Stephane > > > > OK, let=E2=80=99s go with solution (2). That is, if the PATH-SETUP-TYPE = is not > present in a message, then it unambiguously means that the path setup typ= e > is RSVP-TE. Then implementations don=E2=80=99t have to try to infer the = path setup > type from other objects or previous messages. > > > > I am revising draft-ietf-pce-lsp-setup-type at the moment to address an > earlier comment from Julien, so I will include this clarification in the > next revision. > > > > Thanks for the input! > > Cheers > > Jon > > > > > > *From:* stephane.litkowski@orange.com [mailto:stephane.litkowski@ > orange.com ] > *Sent:* 15 November 2017 13:52 > *To:* Jonathan Hardwick ; pce@ietf.org > *Subject:* RE: Clarifications on PST handling in > draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing > > > > Hi Jon, > > > > Thanks for your feedback. > > I see two possibilities here. > > 1. When the PATH-SETUP-TYPE is not present in a PCUpd, it should be > inferred from the latest one received (in a PCInitiate or in a PCUpd).= When > initiating an LSP, the PCInitiate contains the PST to let the PCC know > about the path type. Then, it can be omitted in further PCUpd except w= hen > the PCE wants to change the path type. At that time, it sends a PCUpd = with > a new PATH-SETUP-TYPE value and then it does not need to include it in > further updates until the PCE needs to change it again. > 2. We mandate the PCE to put the PATH-SETUP-TYPE in all PCUpd. > > > > IMO, solution 2) is easier for implementations and operation. > > > > Brgd, > > > > Stephane > > > > > > *From:* Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com > ] > *Sent:* Wednesday, November 15, 2017 09:28 > *To:* LITKOWSKI Stephane OBS/OINIS; pce@ietf.org > *Subject:* RE: Clarifications on PST handling in > draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing > > > > I think it should be acceptable for the PCUpd not to include the > PATH-SETUP-TYPE, with the implication that there is no change to the path > type. > > > > Although I=E2=80=99m not convinced it would be a good idea operationally,= I don=E2=80=99t > think there=E2=80=99s any need to prevent the path type changing on the P= CUpd, if > an explicit PATH-SETUP-TYPE is given. That is, > draft-ietf-pce-lsp-setup-type, as a base draft, should allow that > flexibility. A given device may choose not to allow that, of course. > > > > Does that sound reasonable? > > Cheers > > Jon > > > > > > *From:* Pce [mailto:pce-bounces@ietf.org ] *On > Behalf Of *stephane.litkowski@orange.com > *Sent:* 14 November 2017 00:38 > *To:* pce@ietf.org > *Subject:* [Pce] Clarifications on PST handling in > draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing > > > > Hi WG, > > > > I=E2=80=99m facing an interop issue between two PCEP implementations. > > PCE from vendor1 sends the PCInitiate for an SRTE LSP using the PST=3D1 i= n > the SRP Object. > > PCC from vendor2 handles it correctly and delegates the LSP to the PCE > using PST=3D1. > > When the PCE sends a PCUpdate message, it does not set the PST TLV in the > SRP Object. > > The PCC rejects the PCUpdate because of a bad ERO subobject type. It read= s > the PCUpdate as having PST type=3D0. > > > > Based on my reading of draft-ietf-pce-lsp-setup-type & > draft-ietf-pce-segment-routing. > > PST draft tells that for the PCE Initiation case, the PCE MAY include the > PST if the message does not ave any other means of indicating the path > setup type. SR draft tells =E2=80=9CIn order to setup an SR-TE LSP using = SR, RP or > SRP object MUST include PATH-SETUP-TYPE TLV=E2=80=9D. Unfortunately it do= es not > specify explicitly in which message. From a reading perspective, we can > understand from =E2=80=9CIn order to setup=E2=80=9D that it applies to th= e PCInitiate > message. But nothing tells about the PCUpdate message. > > However draft-ietf-pce-lsp-setup-type tells for the stateful PCE case > that: =E2=80=9Cif the path setup type cannot be unambiguously inferred fr= om ERO or > any other object or TLV, PATH-SETUP-TYPE TLV MAY be used in PCRpt and PCU= pd > messages.=E2=80=9D > > In our case (PCE initiated) as the LSP has initially been setup through a > PCInitiate message having the PST TLV, the PCC can infer that futher > updates will use EROs associated with the same PST. > > > > Or do we allow to change the PST through PCUpdate messages which may > require to always set the PST ? (moving from RSVP-TE to SR or the other > way for a particular LSP) > > > > I would like to hear opinions of the WG on that problem ? > > > > Thanks, > > > > Brgds, > > > > > > [image: Orange logo] > > > > *Stephane Litkowski * > Network Architect > Orange/SCE/EQUANT/OINIS/NET > > Orange Expert Future Networks > > phone: +33 2 23 *06* 49 83 > > NEW ! > mobile: +33 6 71 63 27 50 > > NEW ! > stephane.litkowski@orange.com > > > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > > Thank you. > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > > Thank you. > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > --001a114e2248e1c7ac055e12fe87 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1=C2=A0

Thanks Jon!=C2=A0

On Thu, Nov 16, 2017 at 1:25 PM, <= ;stephan= e.litkowski@orange.com> wrote:

Thanks Jon.<= /u>

=C2=A0

From: Jonathan= Hardwick [mailto:Jonathan.Hardwick@metaswitch.com]
Sent: Thursday, November 16, 2017 11:51


To: LITKOWSKI Stephane OBS/OINIS; pce@ietf.org
Subject: RE: Clarifications on PST handling in draft-ietf-pce-lsp-se= tup-type & draft-ietf-pce-segment-routing

<= /p>

=C2=A0

Hi Stephane

=C2=A0

OK, let=E2=80=99s go with solut= ion (2).=C2=A0 That is, if the PATH-SETUP-TYPE is not present in a message,= then it unambiguously means that the path setup type is RSVP-TE.=C2=A0 The= n implementations don=E2=80=99t have to try to infer the path setup type from other objects or previous messages.

=C2=A0

I am revising draft-ietf-pce-ls= p-setup-type at the moment to address an earlier comment from Julien, so I = will include this clarification in the next revision.<= /p>

=C2=A0

Thanks for the input!=

Cheers

Jon

=C2=A0

=C2=A0

From: stephane.litkowski@orange.com [mailto:stephane.litkowski@orange.com]
Sent: 15 November 2017 13:52
To: Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com>; pce@ietf.org
Subject: RE: Clarifications on PST handling in draft-ietf-pce-lsp-se= tup-type & draft-ietf-pce-segment-routing

=C2=A0

Hi Jon,<= /span>

=C2=A0

Thanks for your feedba= ck.

I see two possibilitie= s here.

  1. When the PATH-SETUP-TYPE is= not present in a PCUpd, it should be inferred from the latest one received= (in a PCInitiate or in a PCUpd). When initiating an LSP, the PCInitiate co= ntains the PST to let the PCC know about the path type. Then, it can be omitted in furthe= r PCUpd except when the PCE wants to change the path type. At that time, it= sends a PCUpd with a new PATH-SETUP-TYPE value and then it does not need t= o include it in further updates until the PCE needs to change it again.
  2. We mandate the PCE to put the PATH-SETUP-TY= PE in all PCUpd.

=C2=A0

IMO, solution 2) is ea= sier for implementations and operation.

=C2=A0

Brgd,

=C2=A0

Stephane=

=C2=A0

=C2=A0

From: Jonathan= Hardwick [mailto:Jonathan.Hardwick@metaswitch.com]
Sent: Wednesday, November 15, 2017 09:28
To: LITKOWSKI Stephane OBS/OINIS; pce@ietf.org
Subject: RE: Clarifications on PST handling in draft-ietf-pce-lsp-se= tup-type & draft-ietf-pce-segment-routing

=C2=A0

I think it should be acceptable= for the PCUpd not to include the PATH-SETUP-TYPE, with the implication tha= t there is no change to the path type.

=C2=A0

Although I=E2=80=99m not convin= ced it would be a good idea operationally, I don=E2=80=99t think there=E2= =80=99s any need to prevent the path type changing on the PCUpd, if an expl= icit PATH-SETUP-TYPE is given.=C2=A0 That is, draft-ietf-pce-lsp-setup-type= , as a base draft, should allow that flexibility.=C2=A0 A given device may c= hoose not to allow that, of course.

=C2=A0

Does that sound reasonable?<= /u>

Cheers

Jon

=C2=A0

=C2=A0

=C2=A0

Hi WG,

=C2=A0

I=E2=80=99m facing an interop issue between two PCEP= implementations.

PCE from vendor1 sends the PCInitiate for an SRTE LS= P using the PST=3D1 in the SRP Object.

PCC from vendor2 handles it correctly and delegates = the LSP to the PCE using PST=3D1.

When the PCE sends a PCUpdate message, it does not s= et the PST TLV in the SRP Object.

The PCC rejects the PCUpdate because of a bad ERO su= bobject type. It reads the PCUpdate as having PST type=3D0.

=C2=A0

Based on my reading of draft-ietf-pce-lsp-setup-type= & draft-ietf-pce-segment-routing.

PST draft tells that for the PCE Initiation case, th= e PCE MAY include the PST if the message does not ave any other means of in= dicating the path setup type. SR draft tells =E2=80=9CIn order to setup an = SR-TE LSP using SR, RP or SRP object MUST include PATH-SETUP-TYPE TLV=E2=80=9D. Unfortunately it does not specify ex= plicitly in which message. From a reading perspective, we can understand fr= om =E2=80=9CIn order to setup=E2=80=9D that it applies to the PCInitiate me= ssage. But nothing tells about the PCUpdate message.

However draft-ietf-pce-lsp-setup-type tells for the = stateful PCE case that: =E2=80=9Cif the path setup type cannot be unambiguo= usly inferred from ERO or any other object or TLV, PATH-SETUP-TYPE TLV MAY = be used in PCRpt and PCUpd messages.=E2=80=9D

In our case (PCE initiated) as the LSP has initially= been setup through a PCInitiate message having the PST TLV, the PCC can in= fer that futher updates will use EROs associated with the same PST.<= u>

=C2=A0

Or do we allow to change the PST through PCUpdate me= ssages which may require to =C2=A0always set the PST ? (moving from RSVP-TE= to SR or the other way for a particular LSP)

=C2=A0

I would like to hear opinions of the= WG on that problem ?

=C2=A0

Thanks,

=C2=A0

Brgds,

=C2=A0

=C2=A0

3D"Orange<= u>

=C2=A0<= u>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET

Orange Expert Future Networks=

phone: +33 2 23 06 49 83 =C2=A0NEW=C2=A0!
mobile: +33 6 71 63 27 50 =C2=A0NEW=C2=A0!
stephane.litkowski@orange.com

=C2=A0

____________________________________________________________=
_____________________________________________________________<=
/u>
=C2=A0
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 me=
ssages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


=C2=A0


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
u>


If you have received this email in error, please notify the sender and=
 delete this message and its attachments.


As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.


Thank you.


____________________________________________________________=
_____________________________________________________________<=
/u>


=C2=A0


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 me=
ssages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


=C2=A0


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
u>


If you have received this email in error, please notify the sender and=
 delete this message and its attachments.


As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.


Thank you.


____________________________________________________________=
_____________________________________________________________

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 message=
s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged 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.

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


--001a114e2248e1c7ac055e12fe87-- --001a114e2248e1c7af055e12fe88 Content-Type: image/jpeg; name="image002.jpg" Content-Disposition: inline; filename="image002.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 7d060c03aa2d054e_0.0.1 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCAAoACgDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDvZ/Gt pDO0fkSkodpOOtJ/wnVn3t5a5C9OL6f/AH6gz7185LMqye/4H0tPK6MoptP7ztf+E5sv+fab8qP+ E6sv+feb8q4vpSVP9p1u/wCBp/ZOH8/vO1/4Tqy/59pvyorivl9aKP7Trd/wD+ycP5/eTX4/06cf 7dQAE4rRl025urq4eMLt80rlj94+gpBol7uRSsYd1yEJ5rmlRqNvQ6KWIpxgk5Ioc0c1o/2FfZK7 EBU7eT14zxTf7FvSgYRjJAOzPzY6Zqfq9XsX9apfzIoUVoXOkyWUYa9kWMscKFGQfrRUyozi7NDj iacldM6I6BqsU0hhng8tpC6hxkqT3pBoWtfaBN9qgLhdmSvUUUV9L7CJ8n9an5Dn0XW3cM1zBkNu GB3xirT6XqJtAiyRC4wB5v05ooqlh4akvEz8jOvPDOrX+PtE8JCnI2jqaKKKzlgqUndm8MfWirK3 3H//2Q== --001a114e2248e1c7af055e12fe88-- From nobody Thu Nov 16 01:27: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 98925120227 for ; Thu, 16 Nov 2017 01:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=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 RXRYkYv-R3qf for ; Thu, 16 Nov 2017 01:27:46 -0800 (PST) Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [161.106.1.2]) by ietfa.amsl.com (Postfix) with ESMTP id DCCD91200CF for ; Thu, 16 Nov 2017 01:27:45 -0800 (PST) Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CA47A7CC01A; Thu, 16 Nov 2017 10:27:44 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail1.rd.orange.com (Postfix) with ESMTP id BBB7D7CC00E; Thu, 16 Nov 2017 10:27:44 +0100 (CET) Received: from [10.193.71.63] (10.193.71.63) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.361.1; Thu, 16 Nov 2017 10:27:44 +0100 To: Jonathan Hardwick , "stephane.litkowski@orange.com" References: <20853_1510591095_5A09CA77_20853_54_2_9E32478DFA9976438E7A22F69B08FF921EABC22A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <1346_1510725141_5A0BD615_1346_83_1_9E32478DFA9976438E7A22F69B08FF921EABE047@OPEXCLILMA4.corporate.adroot.infra.ftgroup> From: Julien Meuric Organization: Orange CC: "pce@ietf.org" Message-ID: Date: Thu, 16 Nov 2017 10:27:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing 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, 16 Nov 2017 09:27:48 -0000 Hi, Glad to see we are converging. To make sure we are on the same page (solution (2) referring to a shortcut), the conclusion is that, as soon as PST is not 0 (i.e. RSVP-TE), we always include the PST TLV in PCReq, PCRep, PCUpd, PCRpt and PCInitiate: is that right? This leads me to another question. Over a PCEP session supporting multiple types, we do not have a mean to send a PCReq leaving the type selection to the PCE (no TLV implying type 0). Do we consider a mean to support that? (Could be 0xFF or a flag from the "Reserved" field.) Thanks, Julien Nov. 16, 2017 - Jonathan.Hardwick@metaswitch.com: > > Hi Stephane > >   > > OK, let’s go with solution (2).  That is, if the PATH-SETUP-TYPE is > not present in a message, then it unambiguously means that the path > setup type is RSVP-TE.  Then implementations don’t have to try to > infer the path setup type from other objects or previous messages. > >   > > I am revising draft-ietf-pce-lsp-setup-type at the moment to address > an earlier comment from Julien, so I will include this clarification > in the next revision. > >   > > Thanks for the input! > > Cheers > > Jon > >   > >   > > *From:*stephane.litkowski@orange.com > [mailto:stephane.litkowski@orange.com] > *Sent:* 15 November 2017 13:52 > >   > > Hi Jon, > >   > > Thanks for your feedback. > > I see two possibilities here. > > 1. When the PATH-SETUP-TYPE is not present in a PCUpd, it should be > inferred from the latest one received (in a PCInitiate or in a > PCUpd). When initiating an LSP, the PCInitiate contains the PST to > let the PCC know about the path type. Then, it can be omitted in > further PCUpd except when the PCE wants to change the path type. > At that time, it sends a PCUpd with a new PATH-SETUP-TYPE value > and then it does not need to include it in further updates until > the PCE needs to change it again. > 2. We mandate the PCE to put the PATH-SETUP-TYPE in all PCUpd. > >   > > IMO, solution 2) is easier for implementations and operation. > >   > > Brgd, > >   > > Stephane > >   > >   > > *From:*Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com] > *Sent:* Wednesday, November 15, 2017 09:28 > *To:* LITKOWSKI Stephane OBS/OINIS; pce@ietf.org > *Subject:* RE: Clarifications on PST handling in > draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing > >   > > I think it should be acceptable for the PCUpd not to include the > PATH-SETUP-TYPE, with the implication that there is no change to the > path type. > >   > > Although I’m not convinced it would be a good idea operationally, I > don’t think there’s any need to prevent the path type changing on the > PCUpd, if an explicit PATH-SETUP-TYPE is given.  That is, > draft-ietf-pce-lsp-setup-type, as a base draft, should allow that > flexibility.  A given device may choose not to allow that, of course. > >   > > Does that sound reasonable? > > Cheers > > Jon > >   > >   > > *From:*Pce [mailto:pce-bounces@ietf.org] *On Behalf Of > *stephane.litkowski@orange.com > *Sent:* 14 November 2017 00:38 > *To:* pce@ietf.org > *Subject:* [Pce] Clarifications on PST handling in > draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing > >   > > Hi WG, > >   > > I’m facing an interop issue between two PCEP implementations. > > PCE from vendor1 sends the PCInitiate for an SRTE LSP using the PST=1 > in the SRP Object. > > PCC from vendor2 handles it correctly and delegates the LSP to the PCE > using PST=1. > > When the PCE sends a PCUpdate message, it does not set the PST TLV in > the SRP Object. > > The PCC rejects the PCUpdate because of a bad ERO subobject type. It > reads the PCUpdate as having PST type=0. > >   > > Based on my reading of draft-ietf-pce-lsp-setup-type & > draft-ietf-pce-segment-routing. > > PST draft tells that for the PCE Initiation case, the PCE MAY include > the PST if the message does not ave any other means of indicating the > path setup type. SR draft tells “In order to setup an SR-TE LSP using > SR, RP or SRP object MUST include PATH-SETUP-TYPE TLV”. Unfortunately > it does not specify explicitly in which message. From a reading > perspective, we can understand from “In order to setup” that it > applies to the PCInitiate message. But nothing tells about the > PCUpdate message. > > However draft-ietf-pce-lsp-setup-type tells for the stateful PCE case > that: “if the path setup type cannot be unambiguously inferred from > ERO or any other object or TLV, PATH-SETUP-TYPE TLV MAY be used in > PCRpt and PCUpd messages.” > > In our case (PCE initiated) as the LSP has initially been setup > through a PCInitiate message having the PST TLV, the PCC can infer > that futher updates will use EROs associated with the same PST. > >   > > Or do we allow to change the PST through PCUpdate messages which may > require to  always set the PST ? (moving from RSVP-TE to SR or the > other way for a particular LSP) > >   > > I would like to hear opinions of the WG on that problem ? > >   > > Thanks, > >   > > Brgds, > >   > >   > > Orange logo > >   > > *Stephane Litkowski * > Network Architect > Orange/SCE/EQUANT/OINIS/NET > > Orange Expert Future Networks > > phone: +33 2 23 *06* 49 83 >  NEW ! > mobile: +33 6 71 63 27 50 >  NEW ! > stephane.litkowski@orange.com > >   > > _________________________________________________________________________________________________________________________ >   > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, > deforme ou falsifie. Merci. >   > This message and its attachments may contain confidential or > privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > Thank you. > _________________________________________________________________________________________________________________________ >   > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, > deforme ou falsifie. Merci. >   > This message and its attachments may contain confidential or > privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > Thank you. > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From nobody Thu Nov 16 02:21: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 47AC8127977 for ; Thu, 16 Nov 2017 02:21:14 -0800 (PST) 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, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id watGUW6_jINw for ; Thu, 16 Nov 2017 02:21:07 -0800 (PST) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17979120046 for ; Thu, 16 Nov 2017 02:21:07 -0800 (PST) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id B18E02059C; Thu, 16 Nov 2017 11:21:05 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.63]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 946F11A0059; Thu, 16 Nov 2017 11:21:05 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM6E.corporate.adroot.infra.ftgroup ([fe80::f5a7:eab1:c095:d9ec%18]) with mapi id 14.03.0361.001; Thu, 16 Nov 2017 11:21:00 +0100 From: To: MEURIC Julien IMT/OLN , Jonathan Hardwick CC: "pce@ietf.org" Thread-Topic: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing Thread-Index: AdNcnZvYi2xVxqg4QzKXbgSaVFI8tABEh7zwAAjZZHAALpQtsAAJ1VgAAAOwmVA= Date: Thu, 16 Nov 2017 10:21:00 +0000 Message-ID: <30614_1510827665_5A0D6691_30614_51_1_24be56ce-4f37-4b40-906b-c6ca200d7ad9@OPEXCLILM6E.corporate.adroot.infra.ftgroup> References: <20853_1510591095_5A09CA77_20853_54_2_9E32478DFA9976438E7A22F69B08FF921EABC22A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <1346_1510725141_5A0BD615_1346_83_1_9E32478DFA9976438E7A22F69B08FF921EABE047@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing 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, 16 Nov 2017 10:21:14 -0000 Hi Julien, > Over a PCEP session supporting multiple types, we do not have a mean to s= end a PCReq leaving the type selection to the PCE (no TLV implying type 0). I do not see the use case here. In addition, I'm not sure that the PCE always know what are the setup type= s actively supported by the PCC. As a consequence it may pick one which is = not supported and the LSP setup will fail. For SR, the PCE may know it thro= ugh the SR cap, but for RSVP, can the PCE deduce it from another informatio= n ? Brgds, -----Original Message----- From: Julien Meuric [mailto:julien.meuric@orange.com]=20 Sent: Thursday, November 16, 2017 17:28 To: Jonathan Hardwick; LITKOWSKI Stephane OBS/OINIS Cc: pce@ietf.org Subject: Re: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-set= up-type & draft-ietf-pce-segment-routing Hi, Glad to see we are converging. To make sure we are on the same page (soluti= on (2) referring to a shortcut), the conclusion is that, as soon as PST is = not 0 (i.e. RSVP-TE), we always include the PST TLV in PCReq, PCRep, PCUpd,= PCRpt and PCInitiate: is that right? This leads me to another question. Over a PCEP session supporting multiple = types, we do not have a mean to send a PCReq leaving the type selection to = the PCE (no TLV implying type 0). Do we consider a mean to support that? (C= ould be 0xFF or a flag from the "Reserved" field.) Thanks, Julien Nov. 16, 2017 - Jonathan.Hardwick@metaswitch.com: > > Hi Stephane > > =A0 > > OK, let's go with solution (2).=A0 That is, if the PATH-SETUP-TYPE is=20 > not present in a message, then it unambiguously means that the path=20 > setup type is RSVP-TE.=A0 Then implementations don't have to try to=20 > infer the path setup type from other objects or previous messages. > > =A0 > > I am revising draft-ietf-pce-lsp-setup-type at the moment to address=20 > an earlier comment from Julien, so I will include this clarification=20 > in the next revision. > > =A0 > > Thanks for the input! > > Cheers > > Jon > > =A0 > > =A0 > > *From:*stephane.litkowski@orange.com > [mailto:stephane.litkowski@orange.com] > *Sent:* 15 November 2017 13:52 > > =A0 > > Hi Jon, > > =A0 > > Thanks for your feedback. > > I see two possibilities here. > > 1. When the PATH-SETUP-TYPE is not present in a PCUpd, it should be > inferred from the latest one received (in a PCInitiate or in a > PCUpd). When initiating an LSP, the PCInitiate contains the PST to > let the PCC know about the path type. Then, it can be omitted in > further PCUpd except when the PCE wants to change the path type. > At that time, it sends a PCUpd with a new PATH-SETUP-TYPE value > and then it does not need to include it in further updates until > the PCE needs to change it again. > 2. We mandate the PCE to put the PATH-SETUP-TYPE in all PCUpd. > > =A0 > > IMO, solution 2) is easier for implementations and operation. > > =A0 > > Brgd, > > =A0 > > Stephane > > =A0 > > =A0 > > *From:*Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com] > *Sent:* Wednesday, November 15, 2017 09:28 > *To:* LITKOWSKI Stephane OBS/OINIS; pce@ietf.org > *Subject:* RE: Clarifications on PST handling in=20 > draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing > > =A0 > > I think it should be acceptable for the PCUpd not to include the=20 > PATH-SETUP-TYPE, with the implication that there is no change to the=20 > path type. > > =A0 > > Although I'm not convinced it would be a good idea operationally, I=20 > don't think there's any need to prevent the path type changing on the=20 > PCUpd, if an explicit PATH-SETUP-TYPE is given.=A0 That is,=20 > draft-ietf-pce-lsp-setup-type, as a base draft, should allow that=20 > flexibility.=A0 A given device may choose not to allow that, of course. > > =A0 > > Does that sound reasonable? > > Cheers > > Jon > > =A0 > > =A0 > > *From:*Pce [mailto:pce-bounces@ietf.org] *On Behalf Of=20 > *stephane.litkowski@orange.com > *Sent:* 14 November 2017 00:38 > *To:* pce@ietf.org > *Subject:* [Pce] Clarifications on PST handling in=20 > draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing > > =A0 > > Hi WG, > > =A0 > > I'm facing an interop issue between two PCEP implementations. > > PCE from vendor1 sends the PCInitiate for an SRTE LSP using the PST=3D1= =20 > in the SRP Object. > > PCC from vendor2 handles it correctly and delegates the LSP to the PCE=20 > using PST=3D1. > > When the PCE sends a PCUpdate message, it does not set the PST TLV in=20 > the SRP Object. > > The PCC rejects the PCUpdate because of a bad ERO subobject type. It=20 > reads the PCUpdate as having PST type=3D0. > > =A0 > > Based on my reading of draft-ietf-pce-lsp-setup-type &=20 > draft-ietf-pce-segment-routing. > > PST draft tells that for the PCE Initiation case, the PCE MAY include=20 > the PST if the message does not ave any other means of indicating the=20 > path setup type. SR draft tells "In order to setup an SR-TE LSP using=20 > SR, RP or SRP object MUST include PATH-SETUP-TYPE TLV". Unfortunately=20 > it does not specify explicitly in which message. From a reading=20 > perspective, we can understand from "In order to setup" that it=20 > applies to the PCInitiate message. But nothing tells about the=20 > PCUpdate message. > > However draft-ietf-pce-lsp-setup-type tells for the stateful PCE case > that: "if the path setup type cannot be unambiguously inferred from=20 > ERO or any other object or TLV, PATH-SETUP-TYPE TLV MAY be used in=20 > PCRpt and PCUpd messages." > > In our case (PCE initiated) as the LSP has initially been setup=20 > through a PCInitiate message having the PST TLV, the PCC can infer=20 > that futher updates will use EROs associated with the same PST. > > =A0 > > Or do we allow to change the PST through PCUpdate messages which may=20 > require to =A0always set the PST ? (moving from RSVP-TE to SR or the=20 > other way for a particular LSP) > > =A0 > > I would like to hear opinions of the WG on that problem ? > > =A0 > > Thanks, > > =A0 > > Brgds, > > =A0 > > =A0 > > Orange logo > > =A0 > > *Stephane Litkowski * > Network Architect > Orange/SCE/EQUANT/OINIS/NET > > Orange Expert Future Networks > > phone: +33 2 23 *06* 49 83 > =A0NEW=A0! > mobile: +33 6 71 63 27 50 > =A0NEW=A0! > stephane.litkowski@orange.com > > =A0 > > ______________________________________________________________________ > ___________________________________________________ > =A0 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 > que les pieces jointes. Les messages electroniques etant susceptibles=20 > d'alteration, Orange decline toute responsabilite si ce message a ete=20 > altere, deforme ou falsifie. Merci. > =A0 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not=20 > be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and=20 > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have=20 > been modified, changed or falsified. > Thank you. > ______________________________________________________________________ > ___________________________________________________ > =A0 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 > que les pieces jointes. Les messages electroniques etant susceptibles=20 > d'alteration, Orange decline toute responsabilite si ce message a ete=20 > altere, deforme ou falsifie. Merci. > =A0 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not=20 > be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and=20 > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have=20 > been modified, changed or falsified. > Thank you. > > > _______________________________________________ > 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 Thu Nov 16 03:18: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 1702D129426 for ; Thu, 16 Nov 2017 03:18:55 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-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 (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 hzGThGrBXQid for ; Thu, 16 Nov 2017 03:18:52 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0093.outbound.protection.outlook.com [104.47.34.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C739128B88 for ; Thu, 16 Nov 2017 03:18:52 -0800 (PST) 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=e7BBVhybfoaCi4bSrUf+zQ4EFokUZB8t/mWxmkjSeU0=; b=NvFDjAKJuAjCudp3hmMT30rHNXfLFIHqI+CKXWjuCHC6mGIxmgm5kfY4Q+f6Kd8gpdcfvtdOwz7tnCOHHTPpAoRLSlQjwYyJVOqY2y54lxGRK+ccHAyK7//h7v7Ode5JsmdNCFQ+f5tUunj5j6SWe1gso/xNT1d/pMh0tYL0J6c= Received: from CY4PR0201MB3603.namprd02.prod.outlook.com (52.132.99.21) by CY4PR0201MB3602.namprd02.prod.outlook.com (52.132.99.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.12; Thu, 16 Nov 2017 11:18:51 +0000 Received: from CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::dce9:6773:68c7:10f3]) by CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::dce9:6773:68c7:10f3%13]) with mapi id 15.20.0218.015; Thu, 16 Nov 2017 11:18:51 +0000 From: Jonathan Hardwick To: Julien Meuric , "stephane.litkowski@orange.com" CC: "pce@ietf.org" Thread-Topic: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing Thread-Index: AdNcnZvYi2xVxqg4QzKXbgSaVFI8tABEh7zwAAjZZHAALpQtsAAL7ckAAAPTIQA= Date: Thu, 16 Nov 2017 11:18:51 +0000 Message-ID: References: <20853_1510591095_5A09CA77_20853_54_2_9E32478DFA9976438E7A22F69B08FF921EABC22A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <1346_1510725141_5A0BD615_1346_83_1_9E32478DFA9976438E7A22F69B08FF921EABE047@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [203.127.152.4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR0201MB3602; 6:NSoNx+s6fM3D9ui2hEOmbHDEguBvGZGW+kpqxLXodsSCRP9kLV+yEtMcvbk58JBhmNDQfIvOKe5fL+NsijKPJZ+qmb9XAZdVQXEFNYuKhDnMcKyx4g5eBd4hFHAznlueqwqYwoRndX/j9Z0WDP8hJohdl/uX6iYK6HcGn5e5F4MCqYuvj5KS7stq4ws4++4b8Ldzkl6mpSDLONybZDOSmCuB4QbwXZ5mqWKPSvwOwbX6bPxx+WlWyoTjJJLz/YJlX+Fm/MZdWPSNqB2VSjX4waGmhLHPbJqJNWyO+qxX1cYvVg3sgbmmkbPQm46t8s3/Rg8+D2PN+SQ8XcbZwn72UQfvweMvCBSC1S88SwSVPW0=; 5:Q3IYTCm49TZwLe0CvOjFWq2vonLjXjuIZXRY8lQK+x+/Woff+xHG4m2wjMYuR5/F6MGRwBehJx/RezdgRPFXRLXs9g8a2rmt7bfmJabV7F843HMjUg3u7IsjM4au9o0FNr83uOb+o5MIv0FxtoeojevdbFVws1CzDmzV59Kl5pY=; 24:3NN9j0e08bAO1OFUCriAYtPQ7kP+hXJejJ+YSpHpcBkYsqhhumAeMnoiq/bvevI0viqsoSERhsBzL4ixjjPq1bAINPzHtlVHi7BlQhs4+Mg=; 7:DKI82QLWBQ7qO9qTpPSxhdqH/rOOOW8dUcWK5jcLkKl4r6ftr0HSjdSW5LjmY4dAExExMS7uVKJ+mHtMv8jstd68ahTZV+DcyNtslGirO42cnxQ37cWqLCPRjBqORwtA5xxQKBQcX5TzyeB0QeKadqM/XQyX0kCwLuy2+4SONFHhJcck3QYy9GN8NP/m2Ii1VdAWxSOe+vCnxzX8UC40v7wGjHSi9LEKBncj2T27g8Ba5CccRs9r5FWlIN4aouZN x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 8be7d589-0ac3-4053-2fd3-08d52ce3d0ae x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:CY4PR0201MB3602; x-ms-traffictypediagnostic: CY4PR0201MB3602: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(115448073456579)(81850148713716)(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(3231022)(10201501046)(3002001)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR0201MB3602; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR0201MB3602; x-forefront-prvs: 0493852DA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(57704003)(13464003)(199003)(51914003)(37854004)(189002)(966005)(99286004)(4326008)(101416001)(3660700001)(54356999)(2906002)(81166006)(3280700002)(9686003)(14454004)(6116002)(53936002)(5660300001)(2900100001)(55016002)(50986999)(76176999)(6306002)(53546010)(68736007)(8936002)(81156014)(8676002)(33656002)(3846002)(102836003)(72206003)(478600001)(25786009)(2950100002)(189998001)(7696004)(229853002)(6246003)(5250100002)(106356001)(6436002)(316002)(230783001)(7736002)(74316002)(93886005)(66066001)(6506006)(86362001)(2501003)(5890100001)(305945005)(105586002)(97736004)(110136005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR0201MB3602; H:CY4PR0201MB3603.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8be7d589-0ac3-4053-2fd3-08d52ce3d0ae X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2017 11:18:51.1661 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0201MB3602 Archived-At: Subject: Re: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing 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, 16 Nov 2017 11:18:55 -0000 Hi Julien, see [Jon]s below... -----Original Message----- From: Julien Meuric [mailto:julien.meuric@orange.com]=20 Sent: 16 November 2017 17:28 To: Jonathan Hardwick ; stephane.litkowsk= i@orange.com Cc: pce@ietf.org Subject: Re: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-set= up-type & draft-ietf-pce-segment-routing Hi, Glad to see we are converging. To make sure we are on the same page (soluti= on (2) referring to a shortcut), the conclusion is that, as soon as PST is = not 0 (i.e. RSVP-TE), we always include the PST TLV in PCReq, PCRep, PCUpd,= PCRpt and PCInitiate: is that right? [Jon] Yes. This leads me to another question. Over a PCEP session supporting multiple = types, we do not have a mean to send a PCReq leaving the type selection to = the PCE (no TLV implying type 0). Do we consider a mean to support that? (C= ould be 0xFF or a flag from the "Reserved" field.) [Jon] It could be done, but do we need it? This could be added later witho= ut penalty. Thanks, Julien Nov. 16, 2017 - Jonathan.Hardwick@metaswitch.com: > > Hi Stephane > > =A0 > > OK, let's go with solution (2).=A0 That is, if the PATH-SETUP-TYPE is=20 > not present in a message, then it unambiguously means that the path=20 > setup type is RSVP-TE.=A0 Then implementations don't have to try to=20 > infer the path setup type from other objects or previous messages. > > =A0 > > I am revising draft-ietf-pce-lsp-setup-type at the moment to address=20 > an earlier comment from Julien, so I will include this clarification=20 > in the next revision. > > =A0 > > Thanks for the input! > > Cheers > > Jon > > =A0 > > =A0 > > *From:*stephane.litkowski@orange.com > [mailto:stephane.litkowski@orange.com] > *Sent:* 15 November 2017 13:52 > > =A0 > > Hi Jon, > > =A0 > > Thanks for your feedback. > > I see two possibilities here. > > 1. When the PATH-SETUP-TYPE is not present in a PCUpd, it should be > inferred from the latest one received (in a PCInitiate or in a > PCUpd). When initiating an LSP, the PCInitiate contains the PST to > let the PCC know about the path type. Then, it can be omitted in > further PCUpd except when the PCE wants to change the path type. > At that time, it sends a PCUpd with a new PATH-SETUP-TYPE value > and then it does not need to include it in further updates until > the PCE needs to change it again. > 2. We mandate the PCE to put the PATH-SETUP-TYPE in all PCUpd. > > =A0 > > IMO, solution 2) is easier for implementations and operation. > > =A0 > > Brgd, > > =A0 > > Stephane > > =A0 > > =A0 > > *From:*Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com] > *Sent:* Wednesday, November 15, 2017 09:28 > *To:* LITKOWSKI Stephane OBS/OINIS; pce@ietf.org > *Subject:* RE: Clarifications on PST handling in=20 > draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing > > =A0 > > I think it should be acceptable for the PCUpd not to include the=20 > PATH-SETUP-TYPE, with the implication that there is no change to the=20 > path type. > > =A0 > > Although I'm not convinced it would be a good idea operationally, I=20 > don't think there's any need to prevent the path type changing on the=20 > PCUpd, if an explicit PATH-SETUP-TYPE is given.=A0 That is,=20 > draft-ietf-pce-lsp-setup-type, as a base draft, should allow that=20 > flexibility.=A0 A given device may choose not to allow that, of course. > > =A0 > > Does that sound reasonable? > > Cheers > > Jon > > =A0 > > =A0 > > *From:*Pce [mailto:pce-bounces@ietf.org] *On Behalf Of=20 > *stephane.litkowski@orange.com > *Sent:* 14 November 2017 00:38 > *To:* pce@ietf.org > *Subject:* [Pce] Clarifications on PST handling in=20 > draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing > > =A0 > > Hi WG, > > =A0 > > I'm facing an interop issue between two PCEP implementations. > > PCE from vendor1 sends the PCInitiate for an SRTE LSP using the PST=3D1=20 > in the SRP Object. > > PCC from vendor2 handles it correctly and delegates the LSP to the PCE=20 > using PST=3D1. > > When the PCE sends a PCUpdate message, it does not set the PST TLV in=20 > the SRP Object. > > The PCC rejects the PCUpdate because of a bad ERO subobject type. It=20 > reads the PCUpdate as having PST type=3D0. > > =A0 > > Based on my reading of draft-ietf-pce-lsp-setup-type &=20 > draft-ietf-pce-segment-routing. > > PST draft tells that for the PCE Initiation case, the PCE MAY include=20 > the PST if the message does not ave any other means of indicating the=20 > path setup type. SR draft tells "In order to setup an SR-TE LSP using=20 > SR, RP or SRP object MUST include PATH-SETUP-TYPE TLV". Unfortunately=20 > it does not specify explicitly in which message. From a reading=20 > perspective, we can understand from "In order to setup" that it=20 > applies to the PCInitiate message. But nothing tells about the=20 > PCUpdate message. > > However draft-ietf-pce-lsp-setup-type tells for the stateful PCE case > that: "if the path setup type cannot be unambiguously inferred from=20 > ERO or any other object or TLV, PATH-SETUP-TYPE TLV MAY be used in=20 > PCRpt and PCUpd messages." > > In our case (PCE initiated) as the LSP has initially been setup=20 > through a PCInitiate message having the PST TLV, the PCC can infer=20 > that futher updates will use EROs associated with the same PST. > > =A0 > > Or do we allow to change the PST through PCUpdate messages which may=20 > require to =A0always set the PST ? (moving from RSVP-TE to SR or the=20 > other way for a particular LSP) > > =A0 > > I would like to hear opinions of the WG on that problem ? > > =A0 > > Thanks, > > =A0 > > Brgds, > > =A0 > > =A0 > > Orange logo > > =A0 > > *Stephane Litkowski * > Network Architect > Orange/SCE/EQUANT/OINIS/NET > > Orange Expert Future Networks > > phone: +33 2 23 *06* 49 83 > =A0NEW=A0! > mobile: +33 6 71 63 27 50 > =A0NEW=A0! > stephane.litkowski@orange.com > > =A0 > > ______________________________________________________________________ > ___________________________________________________ > =A0 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 > que les pieces jointes. Les messages electroniques etant susceptibles=20 > d'alteration, Orange decline toute responsabilite si ce message a ete=20 > altere, deforme ou falsifie. Merci. > =A0 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not=20 > be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and=20 > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have=20 > been modified, changed or falsified. > Thank you. > ______________________________________________________________________ > ___________________________________________________ > =A0 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 > que les pieces jointes. Les messages electroniques etant susceptibles=20 > d'alteration, Orange decline toute responsabilite si ce message a ete=20 > altere, deforme ou falsifie. Merci. > =A0 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not=20 > be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and=20 > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have=20 > been modified, changed or falsified. > Thank you. > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From nobody Thu Nov 16 06:35: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 CEB2A127137 for ; Thu, 16 Nov 2017 06:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.215 X-Spam-Level: X-Spam-Status: No, score=0.215 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_BRBL_LASTEXT=1.449, 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 I_c2uIT53a8X for ; Thu, 16 Nov 2017 06:34:55 -0800 (PST) Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [161.106.1.3]) by ietfa.amsl.com (Postfix) with ESMTP id CF1481292F5 for ; Thu, 16 Nov 2017 06:34:54 -0800 (PST) Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1314AE300C3; Thu, 16 Nov 2017 15:34:54 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail2.rd.orange.com (Postfix) with ESMTP id EA458E300C2; Thu, 16 Nov 2017 15:34:53 +0100 (CET) Received: from [10.193.71.63] (10.193.71.63) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.361.1; Thu, 16 Nov 2017 15:34:53 +0100 To: LITKOWSKI Stephane OBS/OINIS CC: Jonathan Hardwick , "pce@ietf.org" References: <20853_1510591095_5A09CA77_20853_54_2_9E32478DFA9976438E7A22F69B08FF921EABC22A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <1346_1510725141_5A0BD615_1346_83_1_9E32478DFA9976438E7A22F69B08FF921EABE047@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <9E32478DFA9976438E7A22F69B08FF921EABF0E2@OPEXCLILMA4.corporate.adroot.infra.ftgroup> From: Julien Meuric Organization: Orange Message-ID: <3787228d-05b7-27f7-4ae2-0f0585bb1244@orange.com> Date: Thu, 16 Nov 2017 15:34:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <9E32478DFA9976438E7A22F69B08FF921EABF0E2@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing 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, 16 Nov 2017 14:34:58 -0000 Hi Stéphane, Of course, that type of request would only make sense when the PCE knows about supported types. Static configuration could allow that, but the update that Jon is going to include in the I-D allows the PCE to be aware of the supported capabilities by the PCC. Anyway, I am fine with leaving that open for the future. I just want to make sure that we have consensus on the exact scope of the document before we freeze it. Thanks for the feedback, Julien Nov. 16, 2017 - stephane.litkowski@orange.com: > Hi Julien, > >> Over a PCEP session supporting multiple types, we do not have a mean to send a PCReq leaving the type selection to the PCE (no TLV implying type 0). > > I do not see the use case here. > In addition, I'm not sure that the PCE always know what are the setup types actively supported by the PCC. As a consequence it may pick one which is not supported and the LSP setup will fail. For SR, the PCE may know it through the SR cap, but for RSVP, can the PCE deduce it from another information ? > > > Brgds, > > > -----Original Message----- > From: Julien Meuric [mailto:julien.meuric@orange.com] > Sent: Thursday, November 16, 2017 17:28 > > Hi, > > Glad to see we are converging. To make sure we are on the same page (solution (2) referring to a shortcut), the conclusion is that, as soon as PST is not 0 (i.e. RSVP-TE), we always include the PST TLV in PCReq, PCRep, PCUpd, PCRpt and PCInitiate: is that right? > > This leads me to another question. Over a PCEP session supporting multiple types, we do not have a mean to send a PCReq leaving the type selection to the PCE (no TLV implying type 0). Do we consider a mean to support that? (Could be 0xFF or a flag from the "Reserved" field.) > > Thanks, > > Julien > > > Nov. 16, 2017 - Jonathan.Hardwick@metaswitch.com: >> >> Hi Stephane >> >>   >> >> OK, let's go with solution (2).  That is, if the PATH-SETUP-TYPE is >> not present in a message, then it unambiguously means that the path >> setup type is RSVP-TE.  Then implementations don't have to try to >> infer the path setup type from other objects or previous messages. >> >>   >> >> I am revising draft-ietf-pce-lsp-setup-type at the moment to address >> an earlier comment from Julien, so I will include this clarification >> in the next revision. >> >>   >> >> Thanks for the input! >> >> Cheers >> >> Jon >> >>   >> >>   >> >> *From:*stephane.litkowski@orange.com >> [mailto:stephane.litkowski@orange.com] >> *Sent:* 15 November 2017 13:52 >> >>   >> >> Hi Jon, >> >>   >> >> Thanks for your feedback. >> >> I see two possibilities here. >> >> 1. When the PATH-SETUP-TYPE is not present in a PCUpd, it should be >> inferred from the latest one received (in a PCInitiate or in a >> PCUpd). When initiating an LSP, the PCInitiate contains the PST to >> let the PCC know about the path type. Then, it can be omitted in >> further PCUpd except when the PCE wants to change the path type. >> At that time, it sends a PCUpd with a new PATH-SETUP-TYPE value >> and then it does not need to include it in further updates until >> the PCE needs to change it again. >> 2. We mandate the PCE to put the PATH-SETUP-TYPE in all PCUpd. >> >>   >> >> IMO, solution 2) is easier for implementations and operation. >> >>   >> >> Brgd, >> >>   >> >> Stephane >> >>   >> >>   >> >> *From:*Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com] >> *Sent:* Wednesday, November 15, 2017 09:28 >> *To:* LITKOWSKI Stephane OBS/OINIS; pce@ietf.org >> *Subject:* RE: Clarifications on PST handling in >> draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing >> >>   >> >> I think it should be acceptable for the PCUpd not to include the >> PATH-SETUP-TYPE, with the implication that there is no change to the >> path type. >> >>   >> >> Although I'm not convinced it would be a good idea operationally, I >> don't think there's any need to prevent the path type changing on the >> PCUpd, if an explicit PATH-SETUP-TYPE is given.  That is, >> draft-ietf-pce-lsp-setup-type, as a base draft, should allow that >> flexibility.  A given device may choose not to allow that, of course. >> >>   >> >> Does that sound reasonable? >> >> Cheers >> >> Jon >> >>   >> >>   >> >> *From:*Pce [mailto:pce-bounces@ietf.org] *On Behalf Of >> *stephane.litkowski@orange.com >> *Sent:* 14 November 2017 00:38 >> *To:* pce@ietf.org >> *Subject:* [Pce] Clarifications on PST handling in >> draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing >> >>   >> >> Hi WG, >> >>   >> >> I'm facing an interop issue between two PCEP implementations. >> >> PCE from vendor1 sends the PCInitiate for an SRTE LSP using the PST=1 >> in the SRP Object. >> >> PCC from vendor2 handles it correctly and delegates the LSP to the PCE >> using PST=1. >> >> When the PCE sends a PCUpdate message, it does not set the PST TLV in >> the SRP Object. >> >> The PCC rejects the PCUpdate because of a bad ERO subobject type. It >> reads the PCUpdate as having PST type=0. >> >>   >> >> Based on my reading of draft-ietf-pce-lsp-setup-type & >> draft-ietf-pce-segment-routing. >> >> PST draft tells that for the PCE Initiation case, the PCE MAY include >> the PST if the message does not ave any other means of indicating the >> path setup type. SR draft tells "In order to setup an SR-TE LSP using >> SR, RP or SRP object MUST include PATH-SETUP-TYPE TLV". Unfortunately >> it does not specify explicitly in which message. From a reading >> perspective, we can understand from "In order to setup" that it >> applies to the PCInitiate message. But nothing tells about the >> PCUpdate message. >> >> However draft-ietf-pce-lsp-setup-type tells for the stateful PCE case >> that: "if the path setup type cannot be unambiguously inferred from >> ERO or any other object or TLV, PATH-SETUP-TYPE TLV MAY be used in >> PCRpt and PCUpd messages." >> >> In our case (PCE initiated) as the LSP has initially been setup >> through a PCInitiate message having the PST TLV, the PCC can infer >> that futher updates will use EROs associated with the same PST. >> >>   >> >> Or do we allow to change the PST through PCUpdate messages which may >> require to  always set the PST ? (moving from RSVP-TE to SR or the >> other way for a particular LSP) >> >>   >> >> I would like to hear opinions of the WG on that problem ? >> >>   >> >> Thanks, >> >>   >> >> Brgds, >> >>   >> >>   >> >> Orange logo >> >>   >> >> *Stephane Litkowski * >> Network Architect >> Orange/SCE/EQUANT/OINIS/NET >> >> Orange Expert Future Networks >> >> phone: +33 2 23 *06* 49 83 >>  NEW ! >> mobile: +33 6 71 63 27 50 >>  NEW ! >> stephane.litkowski@orange.com >> >>   >> >> ______________________________________________________________________ >> ___________________________________________________ >>   >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> exploites ou copies sans autorisation. Si vous avez recu ce message >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi >> que les pieces jointes. Les messages electroniques etant susceptibles >> d'alteration, Orange decline toute responsabilite si ce message a ete >> altere, deforme ou falsifie. Merci. >>   >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; they should not >> be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have >> been modified, changed or falsified. >> Thank you. >> ______________________________________________________________________ >> ___________________________________________________ >>   >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> exploites ou copies sans autorisation. Si vous avez recu ce message >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi >> que les pieces jointes. Les messages electroniques etant susceptibles >> d'alteration, Orange decline toute responsabilite si ce message a ete >> altere, deforme ou falsifie. Merci. >>   >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; they should not >> be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have >> been modified, changed or falsified. >> Thank you. >> >> >> _______________________________________________ >> Pce mailing list >> Pce@ietf.org >> https://www.ietf.org/mailman/listinfo/pce > From nobody Thu Nov 16 13:18: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 D7C23127058 for ; Thu, 16 Nov 2017 13:18:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpKNlYf6Dlyb for ; Thu, 16 Nov 2017 13:18:04 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0121.outbound.protection.outlook.com [104.47.2.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA926124D6C for ; Thu, 16 Nov 2017 13:18:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BqedYLxHy2KJFVmufpqgsNw5Yvrcc9emb0J547k1/Ow=; b=je4kaExFFXKNWoD1NaQpLPifIMyT6n6Rx/X/Yq5zDMoTUYkUvJlmf3AXRi3k+s1Bw7y0VwC18IKHAHFKsR/Nu/ubo8XiQf9MrrAj5E5dv74E/K792tbPYVINU+4kTKohzKYMxmcVb925GrZL4VQEqjvbv2+euodhn0eYDMfysC0= Received: from HE1PR07MB0953.eurprd07.prod.outlook.com (10.162.27.147) by HE1PR07MB0956.eurprd07.prod.outlook.com (10.162.27.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.4; Thu, 16 Nov 2017 21:18:00 +0000 Received: from HE1PR07MB0953.eurprd07.prod.outlook.com ([fe80::346f:91d6:9009:3817]) by HE1PR07MB0953.eurprd07.prod.outlook.com ([fe80::346f:91d6:9009:3817%14]) with mapi id 15.20.0239.005; Thu, 16 Nov 2017 21:18:00 +0000 From: "Aissaoui, Mustapha (Nokia - CA/Ottawa)" To: Jonathan Hardwick , Julien Meuric , "stephane.litkowski@orange.com" CC: "pce@ietf.org" Thread-Topic: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing Thread-Index: AdNcnZvYi2xVxqg4QzKXbgSaVFI8tABEh7zwAAjZZHAALpQtsAAL7ckAAAPTIQAAE+hFsA== Date: Thu, 16 Nov 2017 21:18:00 +0000 Message-ID: References: <20853_1510591095_5A09CA77_20853_54_2_9E32478DFA9976438E7A22F69B08FF921EABC22A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <1346_1510725141_5A0BD615_1346_83_1_9E32478DFA9976438E7A22F69B08FF921EABE047@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mustapha.aissaoui@nokia.com; x-originating-ip: [135.245.20.8] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB0956; 6:oS+XI5QcTh3uQJHGsLk236ZrlNnrptRN1Vt9ASILxBLCDomJahg7c3ToIqsjXvZc4aPYJr3zpEA8fUto2MKStLx5NMQT1PAS4vZ0bBsmbuCrmzTN5PLAgq/CQFGDlkeOPYlZRH4xb3TqQlSMeELrUvRaW068ioD/hFJLPEWv9RE0qS2B6oPBo3xiol5KDVap5ta8gQKIXZsYiFR+5Wj0kJy5lBz9I/xAvUK0JCCrUQp4TQrtXwOuu1MFQYW2CxIB83GnIhxD6H0BySNoMoSeQW59acmnU1l3ziOGr5ZJdQROxht8GCzK8XjBZwTlgxIKhGQhqoeUGZnc02/MTUaZI+GYArApq+LZMmpypAqPLrA=; 5:FHSuq6PWLOxk+dMaByXEJl9oH7amQpvgM87bZgda6LHXgRDEICt/YXjsNuvW3Hg6KfwX6vzh0hLBlHISiu2ceyN75Jd7G5GBKKJkUuZ8SrtDNVkntz4E0TJL7cIPJx+uX/rZ6j1l4lbyIolqdn4PZTvd6kbkXIznN1jTuy/dO18=; 24:3GdP+9RtEXzpuZlNyiGW68UYZgAXMfk3WaIdtUqItJQJ3/Lu6O+Mty9RgDOk6SyM93HtRjLq0jZUJbSNv9S0E1gVsQZ3YCcSPiL5xR2PCfw=; 7:kp/FAfqT35IqnZgeKfx6DElJ8M6NFIr9Wj3qc3UOs2taAZXvpkKySUNkGZzd9wkeQDOAKZKiSY0AOo1vsw7VUwgyLcdRPePbjTrxLuuHHANNdXlEGiw6+N0pWJbFrMx+1jGJ6NfqUbSp2g7Ri4TlHzcgwTFhkop85yTRBdu2fOdYlgNILXXZg7645fk2Fnr8+u3+6R/k3mauqn79cu7ib/BmPUaEQCtlVctOCg7sk4La/9KNrK+Zira4XDUKYL2K x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: c5cb85e6-8173-412a-6aa5-08d52d378400 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603199); SRVR:HE1PR07MB0956; x-ms-traffictypediagnostic: HE1PR07MB0956: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(115448073456579)(81850148713716)(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3002001)(3231022)(10201501046)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR07MB0956; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR07MB0956; x-forefront-prvs: 0493852DA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(57704003)(13464003)(199003)(37854004)(189002)(51914003)(8936002)(93886005)(81166006)(105586002)(81156014)(86362001)(7696004)(5660300001)(3846002)(305945005)(102836003)(6116002)(189998001)(2950100002)(33656002)(6506006)(316002)(110136005)(6436002)(74316002)(97736004)(8676002)(25786009)(99286004)(106356001)(54356999)(50986999)(66066001)(76176999)(478600001)(3280700002)(14454004)(4326008)(68736007)(55016002)(7736002)(3660700001)(230783001)(229853002)(53936002)(53546010)(9686003)(6306002)(101416001)(5250100002)(5890100001)(2501003)(2900100001)(966005)(6246003)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB0956; H:HE1PR07MB0953.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: c5cb85e6-8173-412a-6aa5-08d52d378400 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2017 21:18:00.2457 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB0956 Archived-At: Subject: Re: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing 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, 16 Nov 2017 21:18:08 -0000 Jon, While I do not have an issue with enforcing the PST TLV be included in the = below message types, we still need to answer Stephane's last question in hi= s original email. That is whether the PST is allowed to change during the l= ifetime of the LSP. I am hoping the answer is no meaning that once a LSP wi= th a PLSP-ID is established, a subsequent PCUpd message with a PST type tha= t does not match the type in the original message which created that PLSP-I= D (PCReq or PCInitiate) should result in the PCC returning a PCErr message = with Error-Type =3D 21 (Traffic engineering path setup error) and Error-Val= ue =3D 2 (Mismatched path setup type). If that is the understanding of this group, we should explicitly document i= t in draft-ietf-pce-lsp-setup-type. Mustapha. > -----Original Message----- > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Jonathan Hardwick > Sent: Thursday, November 16, 2017 6:19 AM > To: Julien Meuric ; stephane.litkowski@orange.c= om > Cc: pce@ietf.org > Subject: Re: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-s= etup-type & > draft-ietf-pce-segment-routing >=20 > Hi Julien, see [Jon]s below... >=20 > -----Original Message----- > From: Julien Meuric [mailto:julien.meuric@orange.com] > Sent: 16 November 2017 17:28 > To: Jonathan Hardwick ; > stephane.litkowski@orange.com > Cc: pce@ietf.org > Subject: Re: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-s= etup-type & > draft-ietf-pce-segment-routing >=20 > Hi, >=20 > Glad to see we are converging. To make sure we are on the same page (solu= tion > (2) referring to a shortcut), the conclusion is that, as soon as PST is n= ot 0 (i.e. > RSVP-TE), we always include the PST TLV in PCReq, PCRep, PCUpd, PCRpt and > PCInitiate: is that right? >=20 > [Jon] Yes. >=20 > This leads me to another question. Over a PCEP session supporting multipl= e > types, we do not have a mean to send a PCReq leaving the type selection t= o the > PCE (no TLV implying type 0). Do we consider a mean to support that? (Cou= ld be > 0xFF or a flag from the "Reserved" field.) >=20 > [Jon] It could be done, but do we need it? This could be added later wit= hout > penalty. >=20 > Thanks, >=20 > Julien >=20 >=20 > Nov. 16, 2017 - Jonathan.Hardwick@metaswitch.com: > > > > Hi Stephane > > > > > > > > OK, let's go with solution (2).=A0 That is, if the PATH-SETUP-TYPE is > > not present in a message, then it unambiguously means that the path > > setup type is RSVP-TE.=A0 Then implementations don't have to try to > > infer the path setup type from other objects or previous messages. > > > > > > > > I am revising draft-ietf-pce-lsp-setup-type at the moment to address > > an earlier comment from Julien, so I will include this clarification > > in the next revision. > > > > > > > > Thanks for the input! > > > > Cheers > > > > Jon > > > > > > > > > > > > *From:*stephane.litkowski@orange.com > > [mailto:stephane.litkowski@orange.com] > > *Sent:* 15 November 2017 13:52 > > > > > > > > Hi Jon, > > > > > > > > Thanks for your feedback. > > > > I see two possibilities here. > > > > 1. When the PATH-SETUP-TYPE is not present in a PCUpd, it should be > > inferred from the latest one received (in a PCInitiate or in a > > PCUpd). When initiating an LSP, the PCInitiate contains the PST to > > let the PCC know about the path type. Then, it can be omitted in > > further PCUpd except when the PCE wants to change the path type. > > At that time, it sends a PCUpd with a new PATH-SETUP-TYPE value > > and then it does not need to include it in further updates until > > the PCE needs to change it again. > > 2. We mandate the PCE to put the PATH-SETUP-TYPE in all PCUpd. > > > > > > > > IMO, solution 2) is easier for implementations and operation. > > > > > > > > Brgd, > > > > > > > > Stephane > > > > > > > > > > > > *From:*Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com] > > *Sent:* Wednesday, November 15, 2017 09:28 > > *To:* LITKOWSKI Stephane OBS/OINIS; pce@ietf.org > > *Subject:* RE: Clarifications on PST handling in > > draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing > > > > > > > > I think it should be acceptable for the PCUpd not to include the > > PATH-SETUP-TYPE, with the implication that there is no change to the > > path type. > > > > > > > > Although I'm not convinced it would be a good idea operationally, I > > don't think there's any need to prevent the path type changing on the > > PCUpd, if an explicit PATH-SETUP-TYPE is given.=A0 That is, > > draft-ietf-pce-lsp-setup-type, as a base draft, should allow that > > flexibility.=A0 A given device may choose not to allow that, of course. > > > > > > > > Does that sound reasonable? > > > > Cheers > > > > Jon > > > > > > > > > > > > *From:*Pce [mailto:pce-bounces@ietf.org] *On Behalf Of > > *stephane.litkowski@orange.com > > *Sent:* 14 November 2017 00:38 > > *To:* pce@ietf.org > > *Subject:* [Pce] Clarifications on PST handling in > > draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing > > > > > > > > Hi WG, > > > > > > > > I'm facing an interop issue between two PCEP implementations. > > > > PCE from vendor1 sends the PCInitiate for an SRTE LSP using the PST=3D1 > > in the SRP Object. > > > > PCC from vendor2 handles it correctly and delegates the LSP to the PCE > > using PST=3D1. > > > > When the PCE sends a PCUpdate message, it does not set the PST TLV in > > the SRP Object. > > > > The PCC rejects the PCUpdate because of a bad ERO subobject type. It > > reads the PCUpdate as having PST type=3D0. > > > > > > > > Based on my reading of draft-ietf-pce-lsp-setup-type & > > draft-ietf-pce-segment-routing. > > > > PST draft tells that for the PCE Initiation case, the PCE MAY include > > the PST if the message does not ave any other means of indicating the > > path setup type. SR draft tells "In order to setup an SR-TE LSP using > > SR, RP or SRP object MUST include PATH-SETUP-TYPE TLV". Unfortunately > > it does not specify explicitly in which message. From a reading > > perspective, we can understand from "In order to setup" that it > > applies to the PCInitiate message. But nothing tells about the > > PCUpdate message. > > > > However draft-ietf-pce-lsp-setup-type tells for the stateful PCE case > > that: "if the path setup type cannot be unambiguously inferred from > > ERO or any other object or TLV, PATH-SETUP-TYPE TLV MAY be used in > > PCRpt and PCUpd messages." > > > > In our case (PCE initiated) as the LSP has initially been setup > > through a PCInitiate message having the PST TLV, the PCC can infer > > that futher updates will use EROs associated with the same PST. > > > > > > > > Or do we allow to change the PST through PCUpdate messages which may > > require to =A0always set the PST ? (moving from RSVP-TE to SR or the > > other way for a particular LSP) > > > > > > > > I would like to hear opinions of the WG on that problem ? > > > > > > > > Thanks, > > > > > > > > Brgds, > > > > > > > > > > > > Orange logo > > > > > > > > *Stephane Litkowski * > > Network Architect > > Orange/SCE/EQUANT/OINIS/NET > > > > Orange Expert Future Networks > > > > phone: +33 2 23 *06* 49 83 > > > so.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26root > service%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>=A0NE > W=A0! > > mobile: +33 6 71 63 27 50 > > > so.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26root > service%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>=A0NE > W=A0! > > stephane.litkowski@orange.com > > > > > > > > > ______________________________________________________________________ > > ___________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > > exploites ou copies sans autorisation. Si vous avez recu ce message > > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi > > que les pieces jointes. Les messages electroniques etant susceptibles > > d'alteration, Orange decline toute responsabilite si ce message a ete > > altere, deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; they should not > > be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and > > delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have > > been modified, changed or falsified. > > Thank you. > > > ______________________________________________________________________ > > ___________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > > exploites ou copies sans autorisation. Si vous avez recu ce message > > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi > > que les pieces jointes. Les messages electroniques etant susceptibles > > d'alteration, Orange decline toute responsabilite si ce message a ete > > altere, deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; they should not > > be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and > > delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have > > been modified, changed or falsified. > > Thank you. > > > > > > _______________________________________________ > > Pce mailing list > > Pce@ietf.org > > https://www.ietf.org/mailman/listinfo/pce >=20 > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From nobody Thu Nov 16 14:32:25 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 26B171271FD for ; Thu, 16 Nov 2017 14:32:24 -0800 (PST) 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 bXK26RQQIcvp for ; Thu, 16 Nov 2017 14:32:21 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2FA12717E for ; Thu, 16 Nov 2017 14:32:21 -0800 (PST) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id AB00D1D4C86A for ; Thu, 16 Nov 2017 22:32:17 +0000 (GMT) Received: from BLREML701-CAH.china.huawei.com (10.20.4.170) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 16 Nov 2017 22:32:19 +0000 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.27]) by blreml701-cah.china.huawei.com ([::1]) with mapi id 14.03.0361.001; Fri, 17 Nov 2017 04:02:07 +0530 From: Dhruv Dhody To: "Aissaoui, Mustapha (Nokia - CA/Ottawa)" , Jonathan Hardwick , Julien Meuric , "stephane.litkowski@orange.com" CC: "pce@ietf.org" , 'Dhruv Dhody' Thread-Topic: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing Thread-Index: AdNcnZvYi2xVxqg4QzKXbgSaVFI8tABEh7zwAAjZZHAALpQtsAAAZ1sAAAPhdoAAFOzRAAANtfJQ Date: Thu, 16 Nov 2017 22:32:06 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8D5C827C@BLREML503-MBX.china.huawei.com> References: <20853_1510591095_5A09CA77_20853_54_2_9E32478DFA9976438E7A22F69B08FF921EABC22A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <1346_1510725141_5A0BD615_1346_83_1_9E32478DFA9976438E7A22F69B08FF921EABE047@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.39.90] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing 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, 16 Nov 2017 22:32:24 -0000 Hi Mustapha,=20 Jon said this in his earlier mail -=20 > Although I'm not convinced it would be a good idea operationally,=20 > I don't think there's any need to prevent the path type changing=20 > on the PCUpd, if an explicit PATH-SETUP-TYPE is given. That is,=20 > draft-ietf-pce-lsp-setup-type, as a base draft, should allow that=20 > flexibility. A given device may choose not to allow that, of course. And I agree with that. In case of message which is in a "response" such as = PCRep, PCRpt it MUST have the same PST.=20 But PCUpd and PCInitiate are different and keeping a door open for allowing= the change of PST could allow better migration from RSVP-TE to SR for exis= ting tunnels.=20 How about we update the text in the draft to explicitly say that this is ab= out PCC's local policy and PCC MAY send an error in case the local policy d= oesn't allow changing of PST?=20 Thanks!=20 Dhruv=20 PS. And for what's it's worth, I agree with leaving the selection of PST fo= r a future extension. > -----Original Message----- > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Aissaoui, Mustapha > (Nokia - CA/Ottawa) > Sent: 17 November 2017 05:18 > To: Jonathan Hardwick ; Julien Meuric > ; stephane.litkowski@orange.com > Cc: pce@ietf.org > Subject: Re: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp- > setup-type & draft-ietf-pce-segment-routing >=20 > Jon, > While I do not have an issue with enforcing the PST TLV be included in th= e > below message types, we still need to answer Stephane's last question in > his original email. That is whether the PST is allowed to change during > the lifetime of the LSP. I am hoping the answer is no meaning that once a > LSP with a PLSP-ID is established, a subsequent PCUpd message with a PST > type that does not match the type in the original message which created > that PLSP-ID (PCReq or PCInitiate) should result in the PCC returning a > PCErr message with Error-Type =3D 21 (Traffic engineering path setup erro= r) > and Error-Value =3D 2 (Mismatched path setup type). >=20 > If that is the understanding of this group, we should explicitly document > it in draft-ietf-pce-lsp-setup-type. >=20 > Mustapha. >=20 > > -----Original Message----- > > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Jonathan Hardwick > > Sent: Thursday, November 16, 2017 6:19 AM > > To: Julien Meuric ; > > stephane.litkowski@orange.com > > Cc: pce@ietf.org > > Subject: Re: [Pce] Clarifications on PST handling in > > draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing > > > > Hi Julien, see [Jon]s below... > > > > -----Original Message----- > > From: Julien Meuric [mailto:julien.meuric@orange.com] > > Sent: 16 November 2017 17:28 > > To: Jonathan Hardwick ; > > stephane.litkowski@orange.com > > Cc: pce@ietf.org > > Subject: Re: [Pce] Clarifications on PST handling in > > draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing > > > > Hi, > > > > Glad to see we are converging. To make sure we are on the same page > > (solution > > (2) referring to a shortcut), the conclusion is that, as soon as PST is > not 0 (i.e. > > RSVP-TE), we always include the PST TLV in PCReq, PCRep, PCUpd, PCRpt > > and > > PCInitiate: is that right? > > > > [Jon] Yes. > > > > This leads me to another question. Over a PCEP session supporting > > multiple types, we do not have a mean to send a PCReq leaving the type > > selection to the PCE (no TLV implying type 0). Do we consider a mean > > to support that? (Could be 0xFF or a flag from the "Reserved" field.) > > > > [Jon] It could be done, but do we need it? This could be added later > > without penalty. > > > > Thanks, > > > > Julien > > > > > > Nov. 16, 2017 - Jonathan.Hardwick@metaswitch.com: > > > > > > Hi Stephane > > > > > > > > > > > > OK, let's go with solution (2).=A0 That is, if the PATH-SETUP-TYPE is > > > not present in a message, then it unambiguously means that the path > > > setup type is RSVP-TE.=A0 Then implementations don't have to try to > > > infer the path setup type from other objects or previous messages. > > > > > > > > > > > > I am revising draft-ietf-pce-lsp-setup-type at the moment to address > > > an earlier comment from Julien, so I will include this clarification > > > in the next revision. > > > > > > > > > > > > Thanks for the input! > > > > > > Cheers > > > > > > Jon > > > > > > > > > > > > > > > > > > *From:*stephane.litkowski@orange.com > > > [mailto:stephane.litkowski@orange.com] > > > *Sent:* 15 November 2017 13:52 > > > > > > > > > > > > Hi Jon, > > > > > > > > > > > > Thanks for your feedback. > > > > > > I see two possibilities here. > > > > > > 1. When the PATH-SETUP-TYPE is not present in a PCUpd, it should be > > > inferred from the latest one received (in a PCInitiate or in a > > > PCUpd). When initiating an LSP, the PCInitiate contains the PST t= o > > > let the PCC know about the path type. Then, it can be omitted in > > > further PCUpd except when the PCE wants to change the path type. > > > At that time, it sends a PCUpd with a new PATH-SETUP-TYPE value > > > and then it does not need to include it in further updates until > > > the PCE needs to change it again. > > > 2. We mandate the PCE to put the PATH-SETUP-TYPE in all PCUpd. > > > > > > > > > > > > IMO, solution 2) is easier for implementations and operation. > > > > > > > > > > > > Brgd, > > > > > > > > > > > > Stephane > > > > > > > > > > > > > > > > > > *From:*Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com] > > > *Sent:* Wednesday, November 15, 2017 09:28 > > > *To:* LITKOWSKI Stephane OBS/OINIS; pce@ietf.org > > > > > > *Subject:* RE: Clarifications on PST handling in > > > draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing > > > > > > > > > > > > I think it should be acceptable for the PCUpd not to include the > > > PATH-SETUP-TYPE, with the implication that there is no change to the > > > path type. > > > > > > > > > > > > Although I'm not convinced it would be a good idea operationally, I > > > don't think there's any need to prevent the path type changing on > > > the PCUpd, if an explicit PATH-SETUP-TYPE is given.=A0 That is, > > > draft-ietf-pce-lsp-setup-type, as a base draft, should allow that > > > flexibility.=A0 A given device may choose not to allow that, of cours= e. > > > > > > > > > > > > Does that sound reasonable? > > > > > > Cheers > > > > > > Jon > > > > > > > > > > > > > > > > > > *From:*Pce [mailto:pce-bounces@ietf.org] *On Behalf Of > > > *stephane.litkowski@orange.com > > > > > > *Sent:* 14 November 2017 00:38 > > > *To:* pce@ietf.org > > > *Subject:* [Pce] Clarifications on PST handling in > > > draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing > > > > > > > > > > > > Hi WG, > > > > > > > > > > > > I'm facing an interop issue between two PCEP implementations. > > > > > > PCE from vendor1 sends the PCInitiate for an SRTE LSP using the > > > PST=3D1 in the SRP Object. > > > > > > PCC from vendor2 handles it correctly and delegates the LSP to the > > > PCE using PST=3D1. > > > > > > When the PCE sends a PCUpdate message, it does not set the PST TLV > > > in the SRP Object. > > > > > > The PCC rejects the PCUpdate because of a bad ERO subobject type. It > > > reads the PCUpdate as having PST type=3D0. > > > > > > > > > > > > Based on my reading of draft-ietf-pce-lsp-setup-type & > > > draft-ietf-pce-segment-routing. > > > > > > PST draft tells that for the PCE Initiation case, the PCE MAY > > > include the PST if the message does not ave any other means of > > > indicating the path setup type. SR draft tells "In order to setup an > > > SR-TE LSP using SR, RP or SRP object MUST include PATH-SETUP-TYPE > > > TLV". Unfortunately it does not specify explicitly in which message. > > > From a reading perspective, we can understand from "In order to > > > setup" that it applies to the PCInitiate message. But nothing tells > > > about the PCUpdate message. > > > > > > However draft-ietf-pce-lsp-setup-type tells for the stateful PCE > > > case > > > that: "if the path setup type cannot be unambiguously inferred from > > > ERO or any other object or TLV, PATH-SETUP-TYPE TLV MAY be used in > > > PCRpt and PCUpd messages." > > > > > > In our case (PCE initiated) as the LSP has initially been setup > > > through a PCInitiate message having the PST TLV, the PCC can infer > > > that futher updates will use EROs associated with the same PST. > > > > > > > > > > > > Or do we allow to change the PST through PCUpdate messages which may > > > require to =A0always set the PST ? (moving from RSVP-TE to SR or the > > > other way for a particular LSP) > > > > > > > > > > > > I would like to hear opinions of the WG on that problem ? > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Brgds, > > > > > > > > > > > > > > > > > > Orange logo > > > > > > > > > > > > *Stephane Litkowski * > > > Network Architect > > > Orange/SCE/EQUANT/OINIS/NET > > > > > > Orange Expert Future Networks > > > > > > phone: +33 2 23 *06* 49 83 > > > > > > voice.s > > so.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26ro > > ot service%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>=A0NE W=A0= ! > > > mobile: +33 6 71 63 27 50 > > > > > > voice.s > > so.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26ro > > ot service%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>=A0NE W=A0= ! > > > stephane.litkowski@orange.com > > > > > > > > > > > > > > ______________________________________________________________________ > > > ___________________________________________________ > > > > > > Ce message et ses pieces jointes peuvent contenir des informations > > > confidentielles ou privilegiees et ne doivent donc pas etre > > > diffuses, exploites ou copies sans autorisation. Si vous avez recu > > > ce message par erreur, veuillez le signaler a l'expediteur et le > > > detruire ainsi que les pieces jointes. Les messages electroniques > > > etant susceptibles d'alteration, Orange decline toute responsabilite > > > si ce message a ete altere, deforme ou falsifie. Merci. > > > > > > This message and its attachments may contain confidential or > > > privileged information that may be protected by law; they should not > > > be distributed, used or copied without authorisation. > > > If you have received this email in error, please notify the sender > > > and delete this message and its attachments. > > > As emails may be altered, Orange is not liable for messages that > > > have been modified, changed or falsified. > > > Thank you. > > > > > ______________________________________________________________________ > > > ___________________________________________________ > > > > > > Ce message et ses pieces jointes peuvent contenir des informations > > > confidentielles ou privilegiees et ne doivent donc pas etre > > > diffuses, exploites ou copies sans autorisation. Si vous avez recu > > > ce message par erreur, veuillez le signaler a l'expediteur et le > > > detruire ainsi que les pieces jointes. Les messages electroniques > > > etant susceptibles d'alteration, Orange decline toute responsabilite > > > si ce message a ete altere, deforme ou falsifie. Merci. > > > > > > This message and its attachments may contain confidential or > > > privileged information that may be protected by law; they should not > > > be distributed, used or copied without authorisation. > > > If you have received this email in error, please notify the sender > > > and delete this message and its attachments. > > > As emails may be altered, Orange is not liable for messages that > > > have been modified, changed or falsified. > > > Thank you. > > > > > > > > > _______________________________________________ > > > 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 >=20 > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From nobody Thu Nov 16 14:47: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 4C7B4126C0F for ; Thu, 16 Nov 2017 14:47:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-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 (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5e0akNrGLRw for ; Thu, 16 Nov 2017 14:47:25 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0118.outbound.protection.outlook.com [104.47.2.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0174F1250B8 for ; Thu, 16 Nov 2017 14:47:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GSHnLhXDheUxauWuxhKJ+LyuTN9w4DHgS+hAoE+OlsU=; b=UV7Y+jbISe3RyYAFNGIrgzlucs632JXyJ24VwWAFpvQe4K6nM0+qErOdGagKbPZ+y9Kab1joGRYdrllLCI3sdETliWo7XBVxCWIAj6vAC4KR1dpdCwFydA1BKn1ORBHaxixDQ8JdORAyK8Jo49XDFiEsWlpZXq19GJOeLsoJAiQ= Received: from HE1PR07MB0953.eurprd07.prod.outlook.com (10.162.27.147) by HE1PR07MB0955.eurprd07.prod.outlook.com (10.162.27.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.4; Thu, 16 Nov 2017 22:47:21 +0000 Received: from HE1PR07MB0953.eurprd07.prod.outlook.com ([fe80::346f:91d6:9009:3817]) by HE1PR07MB0953.eurprd07.prod.outlook.com ([fe80::346f:91d6:9009:3817%14]) with mapi id 15.20.0239.005; Thu, 16 Nov 2017 22:47:21 +0000 From: "Aissaoui, Mustapha (Nokia - CA/Ottawa)" To: Dhruv Dhody , Jonathan Hardwick , Julien Meuric , "stephane.litkowski@orange.com" CC: "pce@ietf.org" , 'Dhruv Dhody' Thread-Topic: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing Thread-Index: AdNcnZvYi2xVxqg4QzKXbgSaVFI8tABEh7zwAAjZZHAALpQtsAAL7ckAAAPTIQAAE+hFsAADqWMAAAB1fBA= Date: Thu, 16 Nov 2017 22:47:21 +0000 Message-ID: References: <20853_1510591095_5A09CA77_20853_54_2_9E32478DFA9976438E7A22F69B08FF921EABC22A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <1346_1510725141_5A0BD615_1346_83_1_9E32478DFA9976438E7A22F69B08FF921EABE047@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <23CE718903A838468A8B325B80962F9B8D5C827C@BLREML503-MBX.china.huawei.com> In-Reply-To: <23CE718903A838468A8B325B80962F9B8D5C827C@BLREML503-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.245.20.8] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB0955; 6:8Pao7eVGAGxjmVbJ+prH7/Jcp8fxUDIy5qeuF2FVP9rU2mtCkKPQSmIrdDPF9jJLHsA4vKEa5UvB13GMdzRjS+y+fUgmBZorym8rw3fEov8YHqEKLFl4/LPQAvT5FG6NbboNEqoolUAo1FHbZEut704HtOwwAjFmOcPfW+su4ncxqJkXQF3R/IeeJmH1ZWSUU7TCvvXSQ5F3OHBhpccb/KvAFkoORZqsRDEotXufa5QJR028Tr5sGNe6HAuAyWvFtYnrefpxrLsUYtIV9DuALgXyw4XIlYm/FvAvYCwhESbqk3M49Z/5UdlSOh6aI+uI6GP2Ph7Ic4Dd4SgHLScM1OooLuPdDwWerG//tuO7nPY=; 5:1mw59m9rPEpvadmDnE2CGQmSm28gmdiotes/GSpeQ68tGqRosXTUl3mDSRm91RfgfaHaaZAucybed1+wYQgIp4AITTPreotmYbJcIxtSikYr8hbudgAX3ADHxUKn1jD756zSS/BxIt6WrmKJk+oMTF+LStHWyoO68PpRkIAjgqQ=; 24:yy/DpsyOcXVH8RkCPnKOeNvV1EmFqYkrA71FirP7CXqoVi0XKfqFHcdoe7F6s1qD7T7SPsQjrjBRytlgf0CzBeShw7eaa2hKrSV1O1KuVAQ=; 7:dHFu9tYhxA93M7eFdUKYL7lgEZ2FTY+18elrnGPzR2Qj/ISt0dAEycXfuJWNes+Pw1+vWbXkL7a2mcaq0fcnac5Tk3ff0o8aMxbgX2FE5V296Y++kidtiNMfyA8Q03xhP30jZQ/G4T+40K5K7JsOZCFgYAPd27d26K8ktA79dUNg7yKuMoOw4Yd3YFcHhYlUGauhNzD9o3c414N2MTmd6R1ITQhnuHTKKdWDQ+omgvZM9DltCHam1RacjcbKT7PV x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 03c55c86-5293-405b-30e8-08d52d43ff95 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603258); SRVR:HE1PR07MB0955; x-ms-traffictypediagnostic: HE1PR07MB0955: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mustapha.aissaoui@nokia.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(115448073456579)(50582790962513)(82608151540597)(81850148713716)(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3231022)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR07MB0955; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR07MB0955; x-forefront-prvs: 0493852DA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(346002)(376002)(199003)(37854004)(51914003)(189002)(13464003)(57704003)(74316002)(6306002)(99286004)(8936002)(66066001)(7696004)(54906003)(25786009)(110136005)(4326008)(53546010)(966005)(305945005)(6116002)(2900100001)(93886005)(7736002)(102836003)(478600001)(97736004)(5660300001)(2906002)(2950100002)(316002)(86362001)(3846002)(6506006)(101416001)(6436002)(3280700002)(76176999)(8676002)(3660700001)(50986999)(39060400002)(54356999)(2501003)(9686003)(53936002)(55016002)(68736007)(5250100002)(5890100001)(230783001)(81156014)(33656002)(189998001)(14454004)(81166006)(229853002)(106356001)(6246003)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB0955; H:HE1PR07MB0953.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 03c55c86-5293-405b-30e8-08d52d43ff95 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2017 22:47:21.5256 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB0955 Archived-At: Subject: Re: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing 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, 16 Nov 2017 22:47:29 -0000 Thanks Dhruv. I am fine with making sure we have the proper PCErr message listed in case = a PCC rejects such a change. However, it seems to me that we should describ= e the procedures for a PCC which honors it. I am not sure that I understand how it helps migration. It seems too compli= cated for its own sake. Mustapha. > -----Original Message----- > From: Dhruv Dhody [mailto:dhruv.dhody@huawei.com] > Sent: Thursday, November 16, 2017 5:32 PM > To: Aissaoui, Mustapha (Nokia - CA/Ottawa) ; > Jonathan Hardwick ; Julien Meuric > ; stephane.litkowski@orange.com > Cc: pce@ietf.org; 'Dhruv Dhody' > Subject: RE: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-s= etup-type & > draft-ietf-pce-segment-routing >=20 > Hi Mustapha, >=20 > Jon said this in his earlier mail - >=20 > > Although I'm not convinced it would be a good idea operationally, I > > don't think there's any need to prevent the path type changing on the > > PCUpd, if an explicit PATH-SETUP-TYPE is given. That is, > > draft-ietf-pce-lsp-setup-type, as a base draft, should allow that > > flexibility. A given device may choose not to allow that, of course. >=20 > And I agree with that. In case of message which is in a "response" such a= s PCRep, > PCRpt it MUST have the same PST. > But PCUpd and PCInitiate are different and keeping a door open for allowi= ng the > change of PST could allow better migration from RSVP-TE to SR for existin= g > tunnels. >=20 > How about we update the text in the draft to explicitly say that this is = about PCC's > local policy and PCC MAY send an error in case the local policy doesn't a= llow > changing of PST? >=20 > Thanks! > Dhruv >=20 > PS. And for what's it's worth, I agree with leaving the selection of PST = for a future > extension. >=20 > > -----Original Message----- > > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Aissaoui, > > Mustapha (Nokia - CA/Ottawa) > > Sent: 17 November 2017 05:18 > > To: Jonathan Hardwick ; Julien > > Meuric ; stephane.litkowski@orange.com > > Cc: pce@ietf.org > > Subject: Re: [Pce] Clarifications on PST handling in > > draft-ietf-pce-lsp- setup-type & draft-ietf-pce-segment-routing > > > > Jon, > > While I do not have an issue with enforcing the PST TLV be included in > > the below message types, we still need to answer Stephane's last > > question in his original email. That is whether the PST is allowed to > > change during the lifetime of the LSP. I am hoping the answer is no > > meaning that once a LSP with a PLSP-ID is established, a subsequent > > PCUpd message with a PST type that does not match the type in the > > original message which created that PLSP-ID (PCReq or PCInitiate) > > should result in the PCC returning a PCErr message with Error-Type =3D > > 21 (Traffic engineering path setup error) and Error-Value =3D 2 (Mismat= ched path > setup type). > > > > If that is the understanding of this group, we should explicitly > > document it in draft-ietf-pce-lsp-setup-type. > > > > Mustapha. > > > > > -----Original Message----- > > > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Jonathan > > > Hardwick > > > Sent: Thursday, November 16, 2017 6:19 AM > > > To: Julien Meuric ; > > > stephane.litkowski@orange.com > > > Cc: pce@ietf.org > > > Subject: Re: [Pce] Clarifications on PST handling in > > > draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing > > > > > > Hi Julien, see [Jon]s below... > > > > > > -----Original Message----- > > > From: Julien Meuric [mailto:julien.meuric@orange.com] > > > Sent: 16 November 2017 17:28 > > > To: Jonathan Hardwick ; > > > stephane.litkowski@orange.com > > > Cc: pce@ietf.org > > > Subject: Re: [Pce] Clarifications on PST handling in > > > draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing > > > > > > Hi, > > > > > > Glad to see we are converging. To make sure we are on the same page > > > (solution > > > (2) referring to a shortcut), the conclusion is that, as soon as PST > > > is > > not 0 (i.e. > > > RSVP-TE), we always include the PST TLV in PCReq, PCRep, PCUpd, > > > PCRpt and > > > PCInitiate: is that right? > > > > > > [Jon] Yes. > > > > > > This leads me to another question. Over a PCEP session supporting > > > multiple types, we do not have a mean to send a PCReq leaving the > > > type selection to the PCE (no TLV implying type 0). Do we consider a > > > mean to support that? (Could be 0xFF or a flag from the "Reserved" > > > field.) > > > > > > [Jon] It could be done, but do we need it? This could be added > > > later without penalty. > > > > > > Thanks, > > > > > > Julien > > > > > > > > > Nov. 16, 2017 - Jonathan.Hardwick@metaswitch.com: > > > > > > > > Hi Stephane > > > > > > > > > > > > > > > > OK, let's go with solution (2).=A0 That is, if the PATH-SETUP-TYPE > > > > is not present in a message, then it unambiguously means that the > > > > path setup type is RSVP-TE.=A0 Then implementations don't have to > > > > try to infer the path setup type from other objects or previous mes= sages. > > > > > > > > > > > > > > > > I am revising draft-ietf-pce-lsp-setup-type at the moment to > > > > address an earlier comment from Julien, so I will include this > > > > clarification in the next revision. > > > > > > > > > > > > > > > > Thanks for the input! > > > > > > > > Cheers > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > *From:*stephane.litkowski@orange.com > > > > [mailto:stephane.litkowski@orange.com] > > > > *Sent:* 15 November 2017 13:52 > > > > > > > > > > > > > > > > Hi Jon, > > > > > > > > > > > > > > > > Thanks for your feedback. > > > > > > > > I see two possibilities here. > > > > > > > > 1. When the PATH-SETUP-TYPE is not present in a PCUpd, it should b= e > > > > inferred from the latest one received (in a PCInitiate or in a > > > > PCUpd). When initiating an LSP, the PCInitiate contains the PST= to > > > > let the PCC know about the path type. Then, it can be omitted i= n > > > > further PCUpd except when the PCE wants to change the path type= . > > > > At that time, it sends a PCUpd with a new PATH-SETUP-TYPE value > > > > and then it does not need to include it in further updates unti= l > > > > the PCE needs to change it again. > > > > 2. We mandate the PCE to put the PATH-SETUP-TYPE in all PCUpd. > > > > > > > > > > > > > > > > IMO, solution 2) is easier for implementations and operation. > > > > > > > > > > > > > > > > Brgd, > > > > > > > > > > > > > > > > Stephane > > > > > > > > > > > > > > > > > > > > > > > > *From:*Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com] > > > > *Sent:* Wednesday, November 15, 2017 09:28 > > > > *To:* LITKOWSKI Stephane OBS/OINIS; pce@ietf.org > > > > > > > > *Subject:* RE: Clarifications on PST handling in > > > > draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing > > > > > > > > > > > > > > > > I think it should be acceptable for the PCUpd not to include the > > > > PATH-SETUP-TYPE, with the implication that there is no change to > > > > the path type. > > > > > > > > > > > > > > > > Although I'm not convinced it would be a good idea operationally, > > > > I don't think there's any need to prevent the path type changing > > > > on the PCUpd, if an explicit PATH-SETUP-TYPE is given.=A0 That is, > > > > draft-ietf-pce-lsp-setup-type, as a base draft, should allow that > > > > flexibility.=A0 A given device may choose not to allow that, of cou= rse. > > > > > > > > > > > > > > > > Does that sound reasonable? > > > > > > > > Cheers > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > *From:*Pce [mailto:pce-bounces@ietf.org] *On Behalf Of > > > > *stephane.litkowski@orange.com > > > > > > > > *Sent:* 14 November 2017 00:38 > > > > *To:* pce@ietf.org > > > > *Subject:* [Pce] Clarifications on PST handling in > > > > draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing > > > > > > > > > > > > > > > > Hi WG, > > > > > > > > > > > > > > > > I'm facing an interop issue between two PCEP implementations. > > > > > > > > PCE from vendor1 sends the PCInitiate for an SRTE LSP using the > > > > PST=3D1 in the SRP Object. > > > > > > > > PCC from vendor2 handles it correctly and delegates the LSP to the > > > > PCE using PST=3D1. > > > > > > > > When the PCE sends a PCUpdate message, it does not set the PST TLV > > > > in the SRP Object. > > > > > > > > The PCC rejects the PCUpdate because of a bad ERO subobject type. > > > > It reads the PCUpdate as having PST type=3D0. > > > > > > > > > > > > > > > > Based on my reading of draft-ietf-pce-lsp-setup-type & > > > > draft-ietf-pce-segment-routing. > > > > > > > > PST draft tells that for the PCE Initiation case, the PCE MAY > > > > include the PST if the message does not ave any other means of > > > > indicating the path setup type. SR draft tells "In order to setup > > > > an SR-TE LSP using SR, RP or SRP object MUST include > > > > PATH-SETUP-TYPE TLV". Unfortunately it does not specify explicitly = in > which message. > > > > From a reading perspective, we can understand from "In order to > > > > setup" that it applies to the PCInitiate message. But nothing > > > > tells about the PCUpdate message. > > > > > > > > However draft-ietf-pce-lsp-setup-type tells for the stateful PCE > > > > case > > > > that: "if the path setup type cannot be unambiguously inferred > > > > from ERO or any other object or TLV, PATH-SETUP-TYPE TLV MAY be > > > > used in PCRpt and PCUpd messages." > > > > > > > > In our case (PCE initiated) as the LSP has initially been setup > > > > through a PCInitiate message having the PST TLV, the PCC can infer > > > > that futher updates will use EROs associated with the same PST. > > > > > > > > > > > > > > > > Or do we allow to change the PST through PCUpdate messages which > > > > may require to =A0always set the PST ? (moving from RSVP-TE to SR o= r > > > > the other way for a particular LSP) > > > > > > > > > > > > > > > > I would like to hear opinions of the WG on that problem ? > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > Brgds, > > > > > > > > > > > > > > > > > > > > > > > > Orange logo > > > > > > > > > > > > > > > > *Stephane Litkowski * > > > > Network Architect > > > > Orange/SCE/EQUANT/OINIS/NET > > > > > > > > Orange Expert Future Networks > > > > > > > > phone: +33 2 23 *06* 49 83 > > > > > > > > > ic > > > voice.s > > > so.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26 > > > ro ot > service%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>=A0NE > > > W=A0! > > > > mobile: +33 6 71 63 27 50 > > > > > > > > > ic > > > voice.s > > > so.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26 > > > ro ot > service%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>=A0NE > > > W=A0! > > > > stephane.litkowski@orange.com > > > > > > > > > > > > > > > > > > > > > > > > ____________________________________________________________________ > > > __ > > > > ___________________________________________________ > > > > > > > > Ce message et ses pieces jointes peuvent contenir des informations > > > > confidentielles ou privilegiees et ne doivent donc pas etre > > > > diffuses, exploites ou copies sans autorisation. Si vous avez recu > > > > ce message par erreur, veuillez le signaler a l'expediteur et le > > > > detruire ainsi que les pieces jointes. Les messages electroniques > > > > etant susceptibles d'alteration, Orange decline toute > > > > responsabilite si ce message a ete altere, deforme ou falsifie. Mer= ci. > > > > > > > > This message and its attachments may contain confidential or > > > > privileged information that may be protected by law; they should > > > > not be distributed, used or copied without authorisation. > > > > If you have received this email in error, please notify the sender > > > > and delete this message and its attachments. > > > > As emails may be altered, Orange is not liable for messages that > > > > have been modified, changed or falsified. > > > > Thank you. > > > > > > > > ____________________________________________________________________ > > > __ > > > > ___________________________________________________ > > > > > > > > Ce message et ses pieces jointes peuvent contenir des informations > > > > confidentielles ou privilegiees et ne doivent donc pas etre > > > > diffuses, exploites ou copies sans autorisation. Si vous avez recu > > > > ce message par erreur, veuillez le signaler a l'expediteur et le > > > > detruire ainsi que les pieces jointes. Les messages electroniques > > > > etant susceptibles d'alteration, Orange decline toute > > > > responsabilite si ce message a ete altere, deforme ou falsifie. Mer= ci. > > > > > > > > This message and its attachments may contain confidential or > > > > privileged information that may be protected by law; they should > > > > not be distributed, used or copied without authorisation. > > > > If you have received this email in error, please notify the sender > > > > and delete this message and its attachments. > > > > As emails may be altered, Orange is not liable for messages that > > > > have been modified, changed or falsified. > > > > Thank you. > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > _______________________________________________ > > Pce mailing list > > Pce@ietf.org > > https://www.ietf.org/mailman/listinfo/pce From nobody Thu Nov 16 16:41: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 9A0EE1274A5 for ; Thu, 16 Nov 2017 16:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_H4=-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=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 C9TiNyNbHizW for ; Thu, 16 Nov 2017 16:41:02 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0109.outbound.protection.outlook.com [104.47.36.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A69F126D0C for ; Thu, 16 Nov 2017 16:41:01 -0800 (PST) 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=IRA2bYgOI7Kt8FC5OVXGiDiah5d4hDXKtaBrJPd9Sec=; b=IQ5OPd4iYZd4PxJHXSYjWJSRlKM7EudTSC2fmnhrQnmowSU2BjIBFHWhJDVFycaR88Uw+AEVn2ML5xtbLKYJFNUBhLlepA6i1A0t5S/tJomUS8ROBz+dDn/zh/Affua7tXEGbg1cwH4dhQZtzihCpcsvMAfhQLQLjp96XV/Isss= Received: from CY4PR0201MB3603.namprd02.prod.outlook.com (52.132.99.21) by CY4PR0201MB3602.namprd02.prod.outlook.com (52.132.99.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.12; Fri, 17 Nov 2017 00:41:00 +0000 Received: from CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::dce9:6773:68c7:10f3]) by CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::dce9:6773:68c7:10f3%13]) with mapi id 15.20.0218.015; Fri, 17 Nov 2017 00:41:00 +0000 From: Jonathan Hardwick To: "Aissaoui, Mustapha (Nokia - CA/Ottawa)" , Dhruv Dhody , Julien Meuric , "stephane.litkowski@orange.com" CC: "pce@ietf.org" , 'Dhruv Dhody' Thread-Topic: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing Thread-Index: AdNcnZvYi2xVxqg4QzKXbgSaVFI8tABEh7zwAAjZZHAALpQtsAAL7ckAAAPTIQAAE+hFsAADqWMAAAB1fBAAA69EAA== Date: Fri, 17 Nov 2017 00:40:59 +0000 Message-ID: References: <20853_1510591095_5A09CA77_20853_54_2_9E32478DFA9976438E7A22F69B08FF921EABC22A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <1346_1510725141_5A0BD615_1346_83_1_9E32478DFA9976438E7A22F69B08FF921EABE047@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <23CE718903A838468A8B325B80962F9B8D5C827C@BLREML503-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [202.55.67.146] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR0201MB3602; 6:8bm8O4ZO3gQF2gpFjnBYptgn80PttH/HpK2sSM/NqGHjm1mBILOrrzTO95Q3qGBcd9JmsZLn9XTRiFTDdyl0+HahnAKzhfp4TliXZp8JLSgBuiDbcrnOeQHm50nKT/Uul5onGw3u/0ZowR3+YxESq9Wrzf2wf0OMiuKrMArx+yNh0CEKjsR7ZOoMAbvu2VZE+mL/JF8kaPGAhAzOCwLtPzOaF5S3+E8WBnHCAtrdJYqxA72LAkayOkINXCWV2rOwUzEagArA/Ne3w0TAyt+za69X1kBYnsO+AyxecBvR5bBpVLZCUv//rGdnpDtKFbItAINjUIkIyn0Ib0/Co7yAYbW5RZZN5jPa9RSaPEGogBw=; 5:gFLv7bZw6z1e3XVy50627npreG0OjiIhvNVbfxCOyHOOww1T9OoDTpyfugVTJQT0YewaRe6Wl5TNs+ZzFcDM0OFAoGMAQAssCyb3C9r/cENWE00llInSEM4GyHom8NWFerg1XRh8AdnqVWGglX0+V3WzlbeBwCW/Fmz1pYwy1zc=; 24:N9hzlPBhFicMdbc83LKbUrHCh3/FtnpF/hmml3i7qBDd5oRC1IW4CqImgGj3NrzXG342HgPERWLwVr8deH01or7LPSTGI7AfsciF7cOZjRY=; 7:LnjMv/Z9XxPiODfKbw7zCp9bnKPrKbOi68XS98h2tThxBQhWwOutTUIULvOMlow8gpf7onJ9srXi3lC8FRNTD/mLYAEUYkCQOHJ9KzzsrJV56B22JkMHPxVF9AtZicLWTPJugHUdrZn5mtazqi5PkQiZLHL7Y0ZymF2u46rsFri7H6ggH+3iD6YLoVQ0ptVV0jgbI2iPNZHOPV2ftivjUFPK899NvOndeufq8ZQ27cBtFZ+5U32ZtQfAWkf8yx5E x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 944124ef-9a0a-4a64-5aaf-08d52d53dfc1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:CY4PR0201MB3602; x-ms-traffictypediagnostic: CY4PR0201MB3602: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(115448073456579)(50582790962513)(82608151540597)(81850148713716)(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(10201501046)(3231022)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123558100)(20161123562025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR0201MB3602; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR0201MB3602; x-forefront-prvs: 049486C505 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(51914003)(189002)(37854004)(57704003)(13464003)(199003)(106356001)(316002)(6436002)(230783001)(2501003)(7696004)(2950100002)(25786009)(54906003)(5250100002)(6246003)(229853002)(189998001)(39060400002)(86362001)(5890100001)(105586002)(305945005)(8656006)(110136005)(74316002)(7736002)(93886005)(66066001)(6506006)(97736004)(5660300001)(55016002)(6116002)(2900100001)(53936002)(50986999)(53546010)(14454004)(76176999)(6306002)(99286004)(966005)(54356999)(3660700001)(2906002)(3280700002)(81166006)(9686003)(101416001)(102836003)(3846002)(8936002)(53946003)(72206003)(478600001)(4326008)(68736007)(8676002)(81156014)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR0201MB3602; H:CY4PR0201MB3603.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-Network-Message-Id: 944124ef-9a0a-4a64-5aaf-08d52d53dfc1 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2017 00:41:00.0288 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0201MB3602 Archived-At: Subject: Re: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing 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, 17 Nov 2017 00:41:06 -0000 Mustapha, Dhruv, Thanks for the feedback. The procedures that a PCC should follow to update the LSP setup type are a = local matter for the PCC, and in any case are impossible to say in a draft = that is agnostic of the specific LSP setup types being used. The use case = for doing this seems sufficiently unclear that I don't think we should add = text to try to describe it in more detail. I just don't want to artificial= ly remove the flexibility from the draft. If it is found to be useful in f= uture we can consider whether any procedures need to be documented for the = case at hand. The PCC can always decide not to act on a PCUpd. I think RFC 8231 already = has this covered adequately: If the PCC decides that the LSP parameters proposed in the PCUpd message are unacceptable, it MUST report this error by including the LSP-ERROR-CODE TLV (Section 7.3.3) with LSP error-value=3D"Unacceptable parameters" in the LSP object in the PCRpt message to the PCE. Based on local policy, it MAY react further to this error by revoking the delegation. Regards Jon -----Original Message----- From: Aissaoui, Mustapha (Nokia - CA/Ottawa) [mailto:mustapha.aissaoui@noki= a.com]=20 Sent: 17 November 2017 06:47 To: Dhruv Dhody ; Jonathan Hardwick ; Julien Meuric ; stephane.lit= kowski@orange.com Cc: pce@ietf.org; 'Dhruv Dhody' Subject: RE: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-set= up-type & draft-ietf-pce-segment-routing Thanks Dhruv. I am fine with making sure we have the proper PCErr message listed in case = a PCC rejects such a change. However, it seems to me that we should describ= e the procedures for a PCC which honors it. I am not sure that I understand how it helps migration. It seems too compli= cated for its own sake. Mustapha. > -----Original Message----- > From: Dhruv Dhody [mailto:dhruv.dhody@huawei.com] > Sent: Thursday, November 16, 2017 5:32 PM > To: Aissaoui, Mustapha (Nokia - CA/Ottawa)=20 > ; Jonathan Hardwick=20 > ; Julien Meuric=20 > ; stephane.litkowski@orange.com > Cc: pce@ietf.org; 'Dhruv Dhody' > Subject: RE: [Pce] Clarifications on PST handling in=20 > draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing >=20 > Hi Mustapha, >=20 > Jon said this in his earlier mail - >=20 > > Although I'm not convinced it would be a good idea operationally, I=20 > > don't think there's any need to prevent the path type changing on=20 > > the PCUpd, if an explicit PATH-SETUP-TYPE is given. That is,=20 > > draft-ietf-pce-lsp-setup-type, as a base draft, should allow that=20 > > flexibility. A given device may choose not to allow that, of course. >=20 > And I agree with that. In case of message which is in a "response"=20 > such as PCRep, PCRpt it MUST have the same PST. > But PCUpd and PCInitiate are different and keeping a door open for=20 > allowing the change of PST could allow better migration from RSVP-TE=20 > to SR for existing tunnels. >=20 > How about we update the text in the draft to explicitly say that this=20 > is about PCC's local policy and PCC MAY send an error in case the=20 > local policy doesn't allow changing of PST? >=20 > Thanks! > Dhruv >=20 > PS. And for what's it's worth, I agree with leaving the selection of=20 > PST for a future extension. >=20 > > -----Original Message----- > > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Aissaoui,=20 > > Mustapha (Nokia - CA/Ottawa) > > Sent: 17 November 2017 05:18 > > To: Jonathan Hardwick ; Julien=20 > > Meuric ; stephane.litkowski@orange.com > > Cc: pce@ietf.org > > Subject: Re: [Pce] Clarifications on PST handling in > > draft-ietf-pce-lsp- setup-type & draft-ietf-pce-segment-routing > > > > Jon, > > While I do not have an issue with enforcing the PST TLV be included=20 > > in the below message types, we still need to answer Stephane's last=20 > > question in his original email. That is whether the PST is allowed=20 > > to change during the lifetime of the LSP. I am hoping the answer is=20 > > no meaning that once a LSP with a PLSP-ID is established, a=20 > > subsequent PCUpd message with a PST type that does not match the=20 > > type in the original message which created that PLSP-ID (PCReq or=20 > > PCInitiate) should result in the PCC returning a PCErr message with=20 > > Error-Type =3D > > 21 (Traffic engineering path setup error) and Error-Value =3D 2=20 > > (Mismatched path > setup type). > > > > If that is the understanding of this group, we should explicitly=20 > > document it in draft-ietf-pce-lsp-setup-type. > > > > Mustapha. > > > > > -----Original Message----- > > > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Jonathan=20 > > > Hardwick > > > Sent: Thursday, November 16, 2017 6:19 AM > > > To: Julien Meuric ;=20 > > > stephane.litkowski@orange.com > > > Cc: pce@ietf.org > > > Subject: Re: [Pce] Clarifications on PST handling in=20 > > > draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing > > > > > > Hi Julien, see [Jon]s below... > > > > > > -----Original Message----- > > > From: Julien Meuric [mailto:julien.meuric@orange.com] > > > Sent: 16 November 2017 17:28 > > > To: Jonathan Hardwick ; > > > stephane.litkowski@orange.com > > > Cc: pce@ietf.org > > > Subject: Re: [Pce] Clarifications on PST handling in=20 > > > draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing > > > > > > Hi, > > > > > > Glad to see we are converging. To make sure we are on the same=20 > > > page (solution > > > (2) referring to a shortcut), the conclusion is that, as soon as=20 > > > PST is > > not 0 (i.e. > > > RSVP-TE), we always include the PST TLV in PCReq, PCRep, PCUpd,=20 > > > PCRpt and > > > PCInitiate: is that right? > > > > > > [Jon] Yes. > > > > > > This leads me to another question. Over a PCEP session supporting=20 > > > multiple types, we do not have a mean to send a PCReq leaving the=20 > > > type selection to the PCE (no TLV implying type 0). Do we consider=20 > > > a mean to support that? (Could be 0xFF or a flag from the "Reserved" > > > field.) > > > > > > [Jon] It could be done, but do we need it? This could be added=20 > > > later without penalty. > > > > > > Thanks, > > > > > > Julien > > > > > > > > > Nov. 16, 2017 - Jonathan.Hardwick@metaswitch.com: > > > > > > > > Hi Stephane > > > > > > > > > > > > > > > > OK, let's go with solution (2).=A0 That is, if the PATH-SETUP-TYPE= =20 > > > > is not present in a message, then it unambiguously means that=20 > > > > the path setup type is RSVP-TE.=A0 Then implementations don't have= =20 > > > > to try to infer the path setup type from other objects or previous = messages. > > > > > > > > > > > > > > > > I am revising draft-ietf-pce-lsp-setup-type at the moment to=20 > > > > address an earlier comment from Julien, so I will include this=20 > > > > clarification in the next revision. > > > > > > > > > > > > > > > > Thanks for the input! > > > > > > > > Cheers > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > *From:*stephane.litkowski@orange.com > > > > [mailto:stephane.litkowski@orange.com] > > > > *Sent:* 15 November 2017 13:52 > > > > > > > > > > > > > > > > Hi Jon, > > > > > > > > > > > > > > > > Thanks for your feedback. > > > > > > > > I see two possibilities here. > > > > > > > > 1. When the PATH-SETUP-TYPE is not present in a PCUpd, it should b= e > > > > inferred from the latest one received (in a PCInitiate or in a > > > > PCUpd). When initiating an LSP, the PCInitiate contains the PST= to > > > > let the PCC know about the path type. Then, it can be omitted i= n > > > > further PCUpd except when the PCE wants to change the path type= . > > > > At that time, it sends a PCUpd with a new PATH-SETUP-TYPE value > > > > and then it does not need to include it in further updates unti= l > > > > the PCE needs to change it again. > > > > 2. We mandate the PCE to put the PATH-SETUP-TYPE in all PCUpd. > > > > > > > > > > > > > > > > IMO, solution 2) is easier for implementations and operation. > > > > > > > > > > > > > > > > Brgd, > > > > > > > > > > > > > > > > Stephane > > > > > > > > > > > > > > > > > > > > > > > > *From:*Jonathan Hardwick=20 > > > > [mailto:Jonathan.Hardwick@metaswitch.com] > > > > *Sent:* Wednesday, November 15, 2017 09:28 > > > > *To:* LITKOWSKI Stephane OBS/OINIS; pce@ietf.org=20 > > > > > > > > *Subject:* RE: Clarifications on PST handling in=20 > > > > draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing > > > > > > > > > > > > > > > > I think it should be acceptable for the PCUpd not to include the=20 > > > > PATH-SETUP-TYPE, with the implication that there is no change to=20 > > > > the path type. > > > > > > > > > > > > > > > > Although I'm not convinced it would be a good idea=20 > > > > operationally, I don't think there's any need to prevent the=20 > > > > path type changing on the PCUpd, if an explicit PATH-SETUP-TYPE=20 > > > > is given.=A0 That is, draft-ietf-pce-lsp-setup-type, as a base=20 > > > > draft, should allow that flexibility.=A0 A given device may choose = not to allow that, of course. > > > > > > > > > > > > > > > > Does that sound reasonable? > > > > > > > > Cheers > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > *From:*Pce [mailto:pce-bounces@ietf.org] *On Behalf Of=20 > > > > *stephane.litkowski@orange.com=20 > > > > > > > > *Sent:* 14 November 2017 00:38 > > > > *To:* pce@ietf.org > > > > *Subject:* [Pce] Clarifications on PST handling in=20 > > > > draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing > > > > > > > > > > > > > > > > Hi WG, > > > > > > > > > > > > > > > > I'm facing an interop issue between two PCEP implementations. > > > > > > > > PCE from vendor1 sends the PCInitiate for an SRTE LSP using the > > > > PST=3D1 in the SRP Object. > > > > > > > > PCC from vendor2 handles it correctly and delegates the LSP to=20 > > > > the PCE using PST=3D1. > > > > > > > > When the PCE sends a PCUpdate message, it does not set the PST=20 > > > > TLV in the SRP Object. > > > > > > > > The PCC rejects the PCUpdate because of a bad ERO subobject type. > > > > It reads the PCUpdate as having PST type=3D0. > > > > > > > > > > > > > > > > Based on my reading of draft-ietf-pce-lsp-setup-type &=20 > > > > draft-ietf-pce-segment-routing. > > > > > > > > PST draft tells that for the PCE Initiation case, the PCE MAY=20 > > > > include the PST if the message does not ave any other means of=20 > > > > indicating the path setup type. SR draft tells "In order to=20 > > > > setup an SR-TE LSP using SR, RP or SRP object MUST include=20 > > > > PATH-SETUP-TYPE TLV". Unfortunately it does not specify=20 > > > > explicitly in > which message. > > > > From a reading perspective, we can understand from "In order to=20 > > > > setup" that it applies to the PCInitiate message. But nothing=20 > > > > tells about the PCUpdate message. > > > > > > > > However draft-ietf-pce-lsp-setup-type tells for the stateful PCE=20 > > > > case > > > > that: "if the path setup type cannot be unambiguously inferred=20 > > > > from ERO or any other object or TLV, PATH-SETUP-TYPE TLV MAY be=20 > > > > used in PCRpt and PCUpd messages." > > > > > > > > In our case (PCE initiated) as the LSP has initially been setup=20 > > > > through a PCInitiate message having the PST TLV, the PCC can=20 > > > > infer that futher updates will use EROs associated with the same PS= T. > > > > > > > > > > > > > > > > Or do we allow to change the PST through PCUpdate messages which=20 > > > > may require to =A0always set the PST ? (moving from RSVP-TE to SR=20 > > > > or the other way for a particular LSP) > > > > > > > > > > > > > > > > I would like to hear opinions of the WG on that problem ? > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > Brgds, > > > > > > > > > > > > > > > > > > > > > > > > Orange logo > > > > > > > > > > > > > > > > *Stephane Litkowski * > > > > Network Architect > > > > Orange/SCE/EQUANT/OINIS/NET > > > > > > > > Orange Expert Future Networks > > > > > > > > phone: +33 2 23 *06* 49 83 > > > > > > > > > cl > > > ic > > > voice.s > > > so.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault% > > > 26 > > > ro ot > service%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>=A0NE > > > W=A0! > > > > mobile: +33 6 71 63 27 50 > > > > > > > > > cl > > > ic > > > voice.s > > > so.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault% > > > 26 > > > ro ot > service%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>=A0NE > > > W=A0! > > > > stephane.litkowski@orange.com > > > > > > > > > > > > > > > > > > > > > > > > ____________________________________________________________________ > > > __ > > > > ___________________________________________________ > > > > > > > > Ce message et ses pieces jointes peuvent contenir des=20 > > > > informations confidentielles ou privilegiees et ne doivent donc=20 > > > > pas etre diffuses, exploites ou copies sans autorisation. Si=20 > > > > vous avez recu ce message par erreur, veuillez le signaler a=20 > > > > l'expediteur et le detruire ainsi que les pieces jointes. Les=20 > > > > messages electroniques etant susceptibles d'alteration, Orange=20 > > > > decline toute responsabilite si ce message a ete altere, deforme ou= falsifie. Merci. > > > > > > > > This message and its attachments may contain confidential or=20 > > > > privileged information that may be protected by law; they should=20 > > > > not be distributed, used or copied without authorisation. > > > > If you have received this email in error, please notify the=20 > > > > sender and delete this message and its attachments. > > > > As emails may be altered, Orange is not liable for messages that=20 > > > > have been modified, changed or falsified. > > > > Thank you. > > > > > > > > ____________________________________________________________________ > > > __ > > > > ___________________________________________________ > > > > > > > > Ce message et ses pieces jointes peuvent contenir des=20 > > > > informations confidentielles ou privilegiees et ne doivent donc=20 > > > > pas etre diffuses, exploites ou copies sans autorisation. Si=20 > > > > vous avez recu ce message par erreur, veuillez le signaler a=20 > > > > l'expediteur et le detruire ainsi que les pieces jointes. Les=20 > > > > messages electroniques etant susceptibles d'alteration, Orange=20 > > > > decline toute responsabilite si ce message a ete altere, deforme ou= falsifie. Merci. > > > > > > > > This message and its attachments may contain confidential or=20 > > > > privileged information that may be protected by law; they should=20 > > > > not be distributed, used or copied without authorisation. > > > > If you have received this email in error, please notify the=20 > > > > sender and delete this message and its attachments. > > > > As emails may be altered, Orange is not liable for messages that=20 > > > > have been modified, changed or falsified. > > > > Thank you. > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > _______________________________________________ > > Pce mailing list > > Pce@ietf.org > > https://www.ietf.org/mailman/listinfo/pce From nobody Thu Nov 16 17:03:00 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 1DBFD126D0C for ; Thu, 16 Nov 2017 17:02:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.789 X-Spam-Level: X-Spam-Status: No, score=-4.789 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_H2=-2.8, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 0yRi7ixZcCNH for ; Thu, 16 Nov 2017 17:02:54 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0130.outbound.protection.outlook.com [104.47.33.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6FDC126CD8 for ; Thu, 16 Nov 2017 17:02:53 -0800 (PST) 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=ZPDjrgvCpCDdyexiDJ6gcmuFLAUYk/NxmPklZ/bWe+c=; b=oVNi4Q8AgFmwK0YhbTKVnklit2NH8waPgShqH0tqi8DdeOKbZGEUzLaSQBagTDt49ca2ailddJVBlyKO664QQ0byA0A0OR+5BtTUZ/Nl+StV/461xw71AIl/qobJJ3E/t3exWqc1C3eQchnLdfd3HDKMecfw6WiWIjv/OuVLXAM= Received: from CY4PR0201MB3603.namprd02.prod.outlook.com (52.132.99.21) by CY4PR0201MB3604.namprd02.prod.outlook.com (52.132.99.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.12; Fri, 17 Nov 2017 01:02:51 +0000 Received: from CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::dce9:6773:68c7:10f3]) by CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::dce9:6773:68c7:10f3%13]) with mapi id 15.20.0218.015; Fri, 17 Nov 2017 01:02:52 +0000 From: Jonathan Hardwick To: "stephane.litkowski@orange.com" , "DUGEON Olivier IMT/OLN" , Daniele Ceccarelli , "pce@ietf.org" Thread-Topic: [Pce] draft-ietf-pce-association-diversity: relaxing constraint Thread-Index: AdNcVzD/M9KOzAxBQO6wN/0nS1cgMgAAiaaQAABEwvAADoitAAADN6OAAKdjyFA= Date: Fri, 17 Nov 2017 01:02:51 +0000 Message-ID: References: <7688_1510561338_5A09563A_7688_271_1_9E32478DFA9976438E7A22F69B08FF921EABBDF1@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <2637_1510562443_5A095A8B_2637_480_1_9E32478DFA9976438E7A22F69B08FF921EABBE39@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <9f1405b5-b166-9ad0-304c-b17d1830ae78@orange.com> <29540_1510593512_5A09D3E7_29540_488_1_87fe0df4-6382-476e-b0d7-edea0347d307@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: <29540_1510593512_5A09D3E7_29540_488_1_87fe0df4-6382-476e-b0d7-edea0347d307@OPEXCLILM43.corporate.adroot.infra.ftgroup> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-originating-ip: [202.55.67.146] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR0201MB3604; 6:qKwBaleN6qI19l8adfgTc8YOQIK1Cyat0tWlgXIWxD8ykZfUzr6Ljw0zyWU1WHdUkKLUJx0mOR79RncuctmIuX238j/6tS1iRdz77W8hRyNwDmp1avgCIbRBU+cTAT5UmRc93uP0HrJIKZuFY48ETbnG9EeA6xL6tnR9FjNzBD37uo9xRHQNk98jj2fEJT0ijPT+fO5l4Y8qvACJb2L67qxyxoG9anojA3JaN2nrT+OEkPxdbdnmKpAEOcgGlM4itZrmsH+Auo8NA9OjXPzrFcU2bkEKPwCuqP1PMSruexbMUQwgVddf7CEZlAgvpzTx7VOOI5/OQi9YqAfsITTPItLOdL8boJFEvQ7+RB8/Fgk=; 5:n4PHIQDkt9FSrClrvxuwwSZRJgTDw97GU2uI9IDyH9knPFQUPlOWgRiEt1UGb2G5Y8MNcwr8VPYdd2XC2KculbhN6RuriJpqGFmDLo0AEOL3trQJYATU8ZgQQWQKhVygNxjJPO73g66XKt4AGTIwsfYWMx5rOUqIyUpcLic0QJg=; 24:lfdJi2my0Y5Fr6g1TwFPkgEBs9U0FgAgMqdE3LDra/KCPvZGG36Ybca2BOVUPS/9i5D9Wjh4rUiOnvib4NHkNlnrOMD/9JnAOKRUPod134I=; 7:TyN/leTHSrKiVyL5QbwejO1UHenmmQ3a0Glw55igS9jWj/opKkEzTd8esrzh4NLOc0/pYFLjpKqW8+iqnNFFpSYGpmAslCf4iTit8LR5EHAa7/wtJdgWAz8NcXWQc5bJlcajgDyeTMPKHj339+ftfI6YiWEpH20vt2yd4z8dJQUlGHz9a/X2byFUM+WebRzc7AcdUB4DlnMOwl5VHqsvZ5mlT6F3MX0AxdGpDwaAucXkkjfV8hC4aZ3+Z+B/Ysya x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 2fd671c6-752d-4433-39ef-08d52d56eda3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199)(49563074); SRVR:CY4PR0201MB3604; x-ms-traffictypediagnostic: CY4PR0201MB3604: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(115448073456579)(81850148713716)(227612066756510)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(100000703101)(100105400095)(3231022)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123555025)(20161123558100)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR0201MB3604; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR0201MB3604; x-forefront-prvs: 049486C505 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(199003)(189002)(57704003)(8936002)(733005)(2906002)(606006)(6306002)(72206003)(316002)(68736007)(14454004)(53936002)(3280700002)(53546010)(966005)(6246003)(478600001)(110136005)(6436002)(81166006)(81156014)(99286004)(54556002)(7696004)(105586002)(93886005)(6506006)(3660700001)(5660300001)(9686003)(55016002)(86362001)(189998001)(97736004)(236005)(54896002)(8676002)(5250100002)(66066001)(74316002)(5890100001)(2950100002)(106356001)(33656002)(99936001)(101416001)(25786009)(2900100001)(230783001)(790700001)(7736002)(3846002)(102836003)(50986999)(2501003)(229853002)(54356999)(6116002)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR0201MB3604; H:CY4PR0201MB3603.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/related; boundary="_004_CY4PR0201MB36039E445122E1E6B6C4E2BB842F0CY4PR0201MB3603_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2fd671c6-752d-4433-39ef-08d52d56eda3 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2017 01:02:51.9034 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0201MB3604 Archived-At: Subject: Re: [Pce] draft-ietf-pce-association-diversity: relaxing constraint 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, 17 Nov 2017 01:02:58 -0000 --_004_CY4PR0201MB36039E445122E1E6B6C4E2BB842F0CY4PR0201MB3603_ Content-Type: multipart/alternative; boundary="_000_CY4PR0201MB36039E445122E1E6B6C4E2BB842F0CY4PR0201MB3603_" --_000_CY4PR0201MB36039E445122E1E6B6C4E2BB842F0CY4PR0201MB3603_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3RlcGhhbmUNCg0KSeKAmW0gbm90IG5lY2Vzc2FyaWx5IHNheWluZyB0aGF0IHRoaXMgaXMg dGhlIHdheSB0byBnbywgYnV0IEkgd291bGQgbGlrZSB0byBwb2ludCBvdXQgdGhlIFAgZmxhZyBh bmQgdGhlIEkgZmxhZyBpbiB0aGUgUENFUCBjb21tb24gb2JqZWN0IGhlYWRlci4gIElmIGEgY29u c3RyYWludCBjYW4gYmUgcmVsYXhlZCwgdGhlIFBDQyBzZW5kcyB0aGUgcmVsZXZhbnQgb2JqZWN0 KHMpIHdpdGggUD0wLiAgSWYgdGhlIFBDRSBkZWNpZGVzIHRvIHJlbGF4IGEgY29uc3RyYWludCwg aXQgaW5jbHVkZXMgdGhlIHJlbGV2YW50IG9iamVjdChzKSBpbiB0aGUgUENSZXAgd2l0aCBJPTEu ICBEb2VzIHRoYXQgY2hhbmdlIHlvdXIgb3BpbmlvbiBvZiB3aGV0aGVyIGEgc3VpdGFibGUgbWVj aGFuaXNtIGZvciB0aGlzIGFscmVhZHkgZXhpc3RzPw0KDQpDaGVlcnMNCkpvbg0KDQoNCkZyb206 IFBjZSBbbWFpbHRvOnBjZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Ygc3RlcGhhbmUu bGl0a293c2tpQG9yYW5nZS5jb20NClNlbnQ6IDE0IE5vdmVtYmVyIDIwMTcgMDE6MTgNClRvOiBE VUdFT04gT2xpdmllciBJTVQvT0xOIDxvbGl2aWVyLmR1Z2VvbkBvcmFuZ2UuY29tPjsgRGFuaWVs ZSBDZWNjYXJlbGxpIDxkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tPjsgcGNlQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW1BjZV0gZHJhZnQtaWV0Zi1wY2UtYXNzb2NpYXRpb24tZGl2ZXJz aXR5OiByZWxheGluZyBjb25zdHJhaW50DQoNCkhpIE9saXZpZXIsDQoNCkkgZG8gbm90IGFncmVl IHdpdGggd2hhdCB5b3UgbWVudGlvbmVkLg0KVGhlIG1ldHJpYyBvYmplY3QgaXMgZGVmaW5lZCAo YnV0IG5vdCBsaW1pdGVkIHRvKSB0byBzZXQgYSBjb25zdHJhaW50IG9uIHRoZSBtZXRyaWM6IHdo YXQgSSBzaG91bGQgb3B0aW1pemUgZm9yIChJR1AgbWV0cmljLCBURSBtZXRyaWMsIGJvdGjigKYp IGFuZCBpcyB0aGVyZSBhIGJvdW5kYXJ5IHRoYXQgSSBzaG91bGQgbm90IGV4Y2VlZC4NCk5vdGhp bmcgc2F5cyB0aGF0IHRoZSBjb25zdHJhaW50IGNhbiBiZSByZWxheGVkIGJ5IHRoZSBQQ0UuIElm IGEgUENFIHJlY2VpdmVzIGEgY29tcHV0YXRpb24gcmVxdWVzdCBvciBuZWVkcyB0byBjb21wdXRl IGEgcGF0aCBmb3IgYW4gTFNQIGhhdmluZyBmb3IgaW5zdGFuY2UgYSBtZXRyaWMgb2JqZWN0IHdp dGggdHlwZT1URSBhbmQgYm91bmQ9MTAwLiBJZiBpdCBjYW5ub3QgZm91bmQgYSBwYXRoLCBpdCB3 aWxsIHJldHVybiBOTy1QQVRIIHdpdGhvdXQgcmVsYXhpbmcgdGhlIGNvbnN0cmFpbnQuIFJlbGF4 aW5nIHRoZSBjb25zdHJhaW50IG1lYW5zIHRoYXQgdGhlIFBDQyBhbGxvd3MgdGhlIFBDRSB0byBj b21wdXRlIGEgcGF0aCB3aXRob3V0IHVzaW5nIHRoZSByZXF1ZXN0ZWQgY29uc3RyYWludCBpZiB0 aGUgUENFIGNhbm5vdCBmaW5kIGEgcGF0aCB0aGF0IGZpbGxzIHRoaXMgY29uc3RyYWludC4NClNv IGluIGNhc2Ugb2YgdGhlIE1FVFJJQyBvYmplY3QgYW5kIHRoZSBib3VuZGFyeSBjYXNlLCBpZiB0 aGUgUENDIGFsbG93cyB0aGUgUENFIHRvIHJlbGF4IHRoZSBjb25zdHJhaW50LCBpZiBpdCBkb2Vz IG5vdCBmaW5kIGEgcGF0aCBmaXR0aW5nIHRoZSBib3VuZGFyeSwgaXQgd2lsbCBwcm92aWRlIGEg cGF0aCBleGNlZWRpbmcgdGhpcyBib3VuZGFyeSBpbnN0ZWFkIG9mIHJldHVybmluZyBOTy1QQVRI Lg0KDQpOb3cgdGhlIE1FVFJJQyBvYmplY3QgZG9lcyBub3QgaGF2ZSBhbnl0aGluZyB0byBkbyB3 aXRoIHRoZSBkaXNqb2ludG5lc3MuIEV4Y2VwdCB0aGF0IHdlIGNhbiBjb21iaW5lIGJvdGggaWYg bmVlZGVkICENCg0KRm9yIHRoZSBkaXNqb2ludG5lc3MsIHdlIGhhdmUgdHdvIGNhc2VzIHdoZW4g dGhlIFBDQyBhbGxvd2VkIHRoZSBQQ0UgdG8gcmVsYXggdGhlIGNvbnN0cmFpbnQ6DQoNCiAgKiAg IFRoZSBQQ0UgaGFzIHN1Y2Nlc3NmdWxseSBjb21wdXRlZCBhIGRpc2pvaW50IHBhdGggYnV0IHdp dGggYSBsb3dlciBkaXNqb2ludG5lc3MgdHlwZSAobGluayBpbnN0ZWFkIG9mIG5vZGUgZm9yIGlu c3RhbmNlKSA9PiB0aGlzIGNvdWxkIGJlIHNlZW4gYXMgYSBwYXJ0aWFsbHkgcmVsYXhlZCBjb25z dHJhaW50IGFuZCBJIGFncmVlIHRoYXQgdGhlIHN0YXRlIGNvdWxkIGJlIHNlbnQgYnkgYWRkaW5n IHRoZSBhc3NvY2lhdGlvbiBncm91cCBhbmQgZmlsbGluZyB0aGUg4oCcY29tcHV0ZWQgc3RhdGXi gJ0gb2YgdGhlIGRpc2pvaW50bmVzcyBpbiB0aGUgRElTSk9JTlRORVNTLUlORk9STUFUSU9OIFRM ViAoTUVUUklDIG9iamVjdCBoYXMgbm90aGluZyB0byBkbyBoZXJlKS4NCiAgKiAgIFRoZSBQQ0Ug Y2Fubm90IGNvbXB1dGUgYSBkaXNqb2ludCBwYXRoIGF0IGFsbCBhbmQgY29tcGxldGVseSByZWxh eGVkIHRoZSBjb25zdHJhaW50Lg0KDQpTbyB3ZSBkbyBub3QgaGF2ZSBhbnkgd2F5IHlldCAoQUZB SUspIHRvIHRlbGwgdGhlIFBDRSB0aGF0IGEgcGFydGljdWxhciBjb25zdHJhaW50IGNhbiBiZSBy ZWxheGVkIChhbm90aGVyIGV4YW1wbGUgaXMgdGhlIGJhbmR3aWR0aCBjb25zdHJhaW50ID0+IEkg ZG8gbm90IHRoaW5rIHRoYXQgaXQgaXMgYSBnb29kIGV4YW1wbGUgYnV0IHdoeSBub3TigKYpLg0K VGhlbiB0aGUgUENFIG5lZWRzIHRvIHRlbGwgdGhlIFBDQyB0aGF0IGl0IGhhcyByZWxheGVkIGEg Y29uc3RyYWludCA9PiB0aGlzIGNhbiBiZSBkZWR1Y2VkIGZyb20gYSDigJxjb21wdXRlZCBzdGF0 ZeKAnSBwcm92aWRlZCBieSB0aGUgUENFIGZvciBlYWNoIGNvbnN0cmFpbnQsIGJ1dCBhIG1vcmUg Y2xlYXIgaW5mb3JtYXRpb24gbWF5IGJlIGJldHRlciAocG9zc2libHkgaW4gYWRkaXRpb24gdG8g dGhlIOKAnGNvbXB1dGVkIHN0YXRl4oCdKS4NCg0KQnJnZHMsDQoNCkZyb206IE9saXZpZXIgRHVn ZW9uIFttYWlsdG86b2xpdmllci5kdWdlb25Ab3JhbmdlLmNvbV0NClNlbnQ6IFR1ZXNkYXksIE5v dmVtYmVyIDE0LCAyMDE3IDAwOjMyDQpUbzogTElUS09XU0tJIFN0ZXBoYW5lIE9CUy9PSU5JUzsg RGFuaWVsZSBDZWNjYXJlbGxpOyBwY2VAaWV0Zi5vcmc8bWFpbHRvOnBjZUBpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbUGNlXSBkcmFmdC1pZXRmLXBjZS1hc3NvY2lhdGlvbi1kaXZlcnNpdHk6IHJl bGF4aW5nIGNvbnN0cmFpbnQNCg0KDQpIZWxsbyBTdGVwaGFuZSwgYWxsDQoNCkluIGZhY3QsIHRo ZXNlIG1lY2hhbmlzbSBpcyBhbHJlYWR5IGF2YWlsYWJsZSBpbiBSRkMgNTQ0MC4NCg0KRmlyc3Qs IE1ldHJpYyBPYmplY3QgaGFzIGJlZW4gZGVmaW5lZCB3aXRoIGEgQiBmbGFnIHRvIGluZGljYXRl IGlmIHRoaXMgbWV0cmljIChpLmUuIGNvbnN0cmFpbnQpIG11c3QgYmUgYm91bmQgb3Igbm90LiBT ZWUgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU0NDAjc2VjdGlvbi03LjguIFRlcm1p bm9sb2d5IGlzIG5vdCBleGFjdGx5IHRoZSBzYW1lLCBidXQsIHRoZSBnb2FsIGlzIHNpbWlsYXIu IEl0IGFsbG93cyBhIFBDQyB0byBpbmRpY2F0ZSB0byB0aGUgUENFIGlmIHRoZSBtZXRyaWMgbXVz dCBiZSBzdHJpY3RseSByZXNwZWN0ZWQgb3Igbm90LiBOb3RlLCBhbHNvIHRoYXQgaXQgaXMgcG9z c2libGUgdG8gaW5kaWNhdGUgbWFueSBzaW1pbGFyIE1ldHJpYyBvYmplY3Qgd2l0aCBkaWZmZXJl bnQgdmFsdWUsIGFzIHdlbGwgYXMgZGlmZmVyZW50IHZhbHVlIGZvciB0aGUgQi1mbGFnIGZvciBt b3JlIGZsZXhpYmlsaXR5LiBGb3IgZXhhbXBsZSwgZm9yIHRoZSBEaXNqb2ludG5lc3MsIHdlIGNv dWxkIGltYWdlIGEgZmlyc3QgTWV0cmljIHdpdGggU1JMRyBkaXNqb2ludCBwYXRoIGFuZCBCLUZs YWcgc2V0IHRvIG9uZSBhbmQgYSBzZWNvbmQgb25lIHdpdGggU1JMRy1hbmQtTm9kZSBkaXNqb2lu dCBwYXRoIHdpdGggQi1GbGFnIGNsZWFyLiBUaGlzIGluZGljYXRlIHRvIHRoZSBQQ0UgdGhhdCB3 ZSB3YW50IGF0IGxlYXN0IGFuIFNSTEcgZGlzam9pbnQgcGF0aCwgYnV0IGlmIGl0IGNvdWxkIGNv bXB1dGUgYW4gU1JMRyBhbmQgTm9kZSBkaXNqb2ludCBwYXRoIHdlJ2xsIGJlIHZlcnkgaGFwcHku DQoNClBDQyBjb3VsZCBhbHNvIHNldCB0aGUgQy1GbGFnIHRvIGluZGljYXRlIHRvIHRoZSBQQ0Ug dGhhdCBpdCB3b3VsZCBpbiB0dXJuIHRoZSBjb21wdXRlZCBNZXRyaWMuIEZvciBkaXNqb2ludG5l c3MsIGl0IGNvdWxkIGluZGljYXRlIHdoaWNoIHR5cGUgb2YgZGlzam9pbnRuZXNzIGl0IHN1Y2Nl c3NmdWxseSB1c2VkIGZvciB0aGUgY29tcHV0ZWQgcGF0aC4NCg0KSWYgYSBtZXRyaWMgY291bGQg bm90IGJlIG1ldCwgUENFIHdpbGwgcmV0dXJuIGEgTm8tUEFUSCBvYmplY3Qgd2l0aCB0aGUgZGVm YXVsdCBtZXRyaWMgdG8gaW5kaWNhdGUgd2hpY2ggY29uc3RyYWludHMgY291bGQgbm90IGJlIG1l dC4NCg0KTm93LCB0byBpbmRpY2F0ZSB0aGF0IGEgbWV0cmljIChjb25zdHJhaW50KSBzaG91bGQg YmUgcmVsYXhlZCwgdGhlcmUgaXMgMiBwb3NzaWJpbGl0aWVzOiBzZW5kIGEgbmV3IFBDRVAgbWVz c2FnZSB3aXRoIHRoZSBCLUZsYWcgb2YgdGhpcyBNZXRyaWMgY2xlYXJlZCwgb3IgYSBQQ0VQIG1l c3NhZ2Ugd2l0aG91dCB0aGUgZ2l2ZW4gTWV0cmljLiBzZWUgYWdhaW4gUkZDIDU0NDAgZW5kIG9m IHNlY3Rpb24gNy44IHBhZ2UgMzggKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NDQw I3BhZ2UtMzgpLg0KDQpTbywgSSB0aGluayB0aGUgZ2VuZXJpYyBtZWNoYW5pc20gaXMgYWxyZWFk eSBhdmFpbGFibGUgYW5kIHRvIGluaGVyaXQgZnJvbSB0aGlzIGJlaGF2aW91ciwgdGhlIERpc2pv aW50ZW5lc3MgVExWIHNob3VsZCBiZSBhIG5ldyBNZXRyaWMgT2JqZWN0IGluc3RlYWQgb2YgYSBk ZWRpY2F0ZWQgbmV3IFRMVi4gQnV0LCBJIHVuZGVyc3RhbmQgdGhhdCB0aGUgZHJhZnQgYW5kIHNv bHV0aW9uIGhhdmUgbm90IGJlZW4gZGVzaWduIHdpdGggdGhpcyBpbiBtaW5kLiBTbyBJIGxldCBh dXRob3JzIGRlY2lkZWQgaWYgaXQgaXMgZmVhc2libGUgb3Igbm90Lg0KDQpSZWdhcmRzDQoNCk9s aXZpZXINCg0KTGUgMTMvMTEvMjAxNyDDoCAwOTo0MCwgc3RlcGhhbmUubGl0a293c2tpQG9yYW5n ZS5jb208bWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPiBhIMOpY3JpdCA6DQpI aSBEYW5pZWxlLA0KDQpUaGFua3MgZm9yIHlvdXIgZmVlZGJhY2suDQpJZiB3ZSBnbyB0byBhIGdl bmVyaWMgbWVjaGFuaXNtLCBJTU8sIHRoaXMgc2hvdWxkIGJlIGFkZHJlc3NlZCBpbiBhIHNlcGFy YXRlIGRvY3VtZW50LiBJbiBhZGRpdGlvbiwgd2UgbmVlZCBhIGdlbmVyaWMgd2F5IGZvciBhIFBD QyB0byB0ZWxsIHRoZSBQQ0UgdGhhdCBhIGNvbnN0cmFpbnQgaXMgcmVsYXhhYmxlIG9yIHN0cmlj dC4gRm9yIGRpdmVyc2l0eSwgd2UgaGF2ZSBhIGRlZGljYXRlZCBmbGFnIHdpdGhpbiB0aGUgRElT Sk9JTlRORVNTIFRMViBmb3IgdGhhdCBwdXJwb3NlLiBNYXliZSB3ZSBzaG91bGQgbWFrZSBpdCBn ZW5lcmljIGFzIHdlbGwuDQoNCkRvIHlvdSBhZ3JlZSA/DQoNCkJyZ2RzLA0KDQoNCkZyb206IERh bmllbGUgQ2VjY2FyZWxsaSBbbWFpbHRvOmRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb21d DQpTZW50OiBNb25kYXksIE5vdmVtYmVyIDEzLCAyMDE3IDE2OjMzDQpUbzogTElUS09XU0tJIFN0 ZXBoYW5lIE9CUy9PSU5JUzsgcGNlQGlldGYub3JnPG1haWx0bzpwY2VAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSRTogZHJhZnQtaWV0Zi1wY2UtYXNzb2NpYXRpb24tZGl2ZXJzaXR5OiByZWxheGluZyBj b25zdHJhaW50DQoNCkhpIFN0ZXBoYW5lLA0KDQpkZWZpbml0ZWx5IG5lZWRlZC4NCk15IG9waW5p b24gaXMgdGhhdCBhIHdheSB0byBzYXkgdGhhdCBhIGNvbnN0cmFpbnQgd2FzIHJlbGF4ZWQgaXMg dmVyeSB1c2VmdWwuIEFzIHlvdSBzYWlkIHRoZXJlIGFyZSBkaWZmZXJlbnQgdHlwZXMgb2YgY29u c3RyYWludHMgdGhhdCBjYW4gYmUgcmVsYXhlZCwgZS5nLiBkaXZlcnNpdHkgb3IgYSBURSBib3Vu ZC4NCkkgd291bGQgbWFrZSB0aGUgVExWIGFzIGdlbmVyaWMgYXMgcG9zc2libGUgYW5kIG1heWJl IGRlZmluZSBtdWx0aXBsZSBzdWItVExWIChvciBtYXliZSBqdXN0IG11bHRpcGxlIHZhbHVlcykg ZGVwZW5kaW5nIG9uIHRoZSBjb25zdHJhaW50IHRoYXQgd2FzIHJlbGF4ZWQuDQoNCkJSDQpEYW5p ZWxlDQoNCkZyb206IFBjZSBbbWFpbHRvOnBjZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2Ygc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb208bWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3Nr aUBvcmFuZ2UuY29tPg0KU2VudDogbHVuZWTDrCAxMyBub3ZlbWJyZSAyMDE3IDE2OjIyDQpUbzog cGNlQGlldGYub3JnPG1haWx0bzpwY2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbUGNlXSBkcmFmdC1p ZXRmLXBjZS1hc3NvY2lhdGlvbi1kaXZlcnNpdHk6IHJlbGF4aW5nIGNvbnN0cmFpbnQNCg0KSGkg V0csDQoNCkluIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiBkcmFmdC1pZXRmLXBjZS1hc3NvY2lhdGlv bi1kaXZlcnNpdHkgd2UgYWRkZWQgYSBuZXcgVExWIGNhbGxlZCBSRUxBWEVELUNPTlNUUkFJTlQt VExWIHRvIGJlIHVzZWQgaW4gTFNQIE9iamVjdCBvZiBhIFBDVXBkYXRlIG1lc3NhZ2Ugd2hlbiB0 aGUgUENFIHJlbGF4ZXMgdGhlIHJlcXVlc3RlZCBkaXNqb2ludG5lc3MgY29uc3RyYWludC4gRm9y IGluc3RhbmNlLCBpZiBhIFBDQyByZXF1ZXN0cyBhbiBTUkxHIGRpc2pvaW50IHBhdGggYnV0IHRo ZSBQQ0UgY2Fubm90IGZpbmQgaXQsIGl0IG1heSByZWxheCB0aGUgY29uc3RyYWludCAoaWYgUEND IGFsbG93cyBpdCB0byBkbyBzbykgYW5kIHRodXMgaW5mb3JtcyB0aGUgUENDIHRocm91Z2ggdGhl IFJFTEFYRUQtQ09OU1RSQUlOVC1UTFYuDQoNCklNTywgdGhpcyBraW5kIG9mIGJlaGF2aW9yIGlz IG1vcmUgZ2VuZXJpYyByYXRoZXIgdGllZCB0byB0aGUgZGlzam9pbnRuZXNzIHVzZSBjYXNlLiBJ dCBtYXkgYmUgdXNlZCB3aXRoIG90aGVyIGNvbnN0cmFpbnRzIGFzIHdlbGwuDQoNClRoZSBxdWVz dGlvbiBpczogZG8gd2UgbmVlZCB0byBrZWVwIHRoaXMgUkVMQVhFRC1DT05TVFJBSU5ULVRMViBp biB0aGUgYXNzb2NpYXRpb24tZGl2ZXJzaXR5IGRyYWZ0ID8gb3IgZG8gd2UgZHJvcCBpdCA/IG9y IGRvIHdlIGRlZmluZSBhIFRMViBtb3JlIHNwZWNpZmljIHRvIHRoZSBhc3NvY2lhdGlvbiBkaXZl cnNpdHkgc3RhdGUgPyBtYXliZSB3ZSBjYW4gcmV1c2UgdGhlIGFzc29jaWF0aW9uIGdyb3VwIG9i amVjdCBpbiB0aGUgUENVcGRhdGUgbWVzc2FnZSBpbmNsdWRpbmcgdGhlIERJU0pPSU5UTkVTUy1J TkZPUk1BVElPTi1UTFYgd2hpY2ggcmVmbGVjdHMgdGhlIGFjdHVhbCBkaXNqb2ludG5lc3Mgc3R5 bGUgdXNlZCBieSB0aGUgUENFLg0KDQpPcGluaW9ucyA/DQoNCg0KQnJnZHMsDQoNClN0ZXBoYW5l DQoNCg0KW09yYW5nZSBsb2dvXTxodHRwOi8vd3d3Lm9yYW5nZS5jb20vPg0KDQpTdGVwaGFuZSBM aXRrb3dza2kNCk5ldHdvcmsgQXJjaGl0ZWN0DQpPcmFuZ2UvU0NFL0VRVUFOVC9PSU5JUy9ORVQN Ck9yYW5nZSBFeHBlcnQgRnV0dXJlIE5ldHdvcmtzDQpwaG9uZTogKzMzIDIgMjMgMDYgNDkgODMg PGh0dHBzOi8vbW9uc2kuc3NvLmZyYW5jZXRlbGVjb20uZnIvaW5kZXguYXNwP3RhcmdldD1odHRw JTNBJTJGJTJGY2xpY3ZvaWNlLnNzby5mcmFuY2V0ZWxlY29tLmZyJTJGQ2xpY3ZvaWNlVjIlMkZU b29sQmFyLmRvJTNGYWN0aW9uJTNEZGVmYXVsdCUyNnJvb3RzZXJ2aWNlJTNEU0lHTkFUVVJFJTI2 dG8lM0QrMzMlMjAyJTIwMjMlMjAyOCUyMDQ5JTIwODMlMjA+ICBORVcgIQ0KbW9iaWxlOiArMzMg NiA3MSA2MyAyNyA1MCA8aHR0cHM6Ly9tb25zaS5zc28uZnJhbmNldGVsZWNvbS5mci9pbmRleC5h c3A/dGFyZ2V0PWh0dHAlM0ElMkYlMkZjbGljdm9pY2Uuc3NvLmZyYW5jZXRlbGVjb20uZnIlMkZD bGljdm9pY2VWMiUyRlRvb2xCYXIuZG8lM0ZhY3Rpb24lM0RkZWZhdWx0JTI2cm9vdHNlcnZpY2Ul M0RTSUdOQVRVUkUlMjZ0byUzRCszMyUyMDYlMjAzNyUyMDg2JTIwOTclMjA1MiUyMD4gIE5FVyAh DQpzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTxtYWlsdG86c3RlcGhhbmUubGl0a293c2tp QG9yYW5nZS5jb20+DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2Vz IGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxl cyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQoNCnBhcyBldHJlIGRpZmZ1c2Vz LCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVj dSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQoNCmEgbCdleHBl ZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBt ZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQoN Ck9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUg YWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoNClRoaXMgbWVzc2FnZSBh bmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2Vk IGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQoNCnRoZXkgc2hvdWxk IG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9u Lg0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50 cy4NCg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3Ig bWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0K DQpUaGFuayB5b3UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCg0KDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBq b2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMg b3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KDQpwYXMgZXRyZSBkaWZmdXNlcywg ZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3Ug Y2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KDQphIGwnZXhwZWRp dGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVz c2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KDQpP cmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFs dGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNCg0KDQpUaGlzIG1lc3NhZ2UgYW5k IGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBp bmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KDQp0aGV5IHNob3VsZCBu b3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4N Cg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMu DQoNCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1l c3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCg0K VGhhbmsgeW91Lg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCg0KUGNlIG1haWxpbmcgbGlzdA0KDQpQY2VAaWV0Zi5vcmc8bWFpbHRvOlBjZUBp ZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wY2UNCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50 IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVl cyBldCBuZSBkb2l2ZW50IGRvbmMNCg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBj b3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFy IGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0 cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9u aXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0KT3JhbmdlIGRlY2xpbmUg dG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUg b3UgZmFsc2lmaWUuIE1lcmNpLg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhh dCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCg0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1 dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQoNCklmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBh bmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpBcyBlbWFpbHMg bWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhh dmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoNClRoYW5rIHlvdS4NCg== --_000_CY4PR0201MB36039E445122E1E6B6C4E2BB842F0CY4PR0201MB3603_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6 MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlVidW50dTsNCglwYW5vc2UtMTowIDAgMCAw IDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biBcLCBzZXJpZiI7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdp bjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0FjZXRhdGUsIGxp Lk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21h IixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNv TGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5 OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRv bTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30N CnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxl LW5hbWU6bXNvbm9ybWFsOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uQmFsbG9vblRleHRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCnNwYW4uRW1haWxTdHlsZTI2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyOQ0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBw dCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBM aXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMTQxNTMzMjQ2Ow0K CW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMDczNTQxOTE4 IDY1MDY0NjE3OCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2 NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVs LXN0YXJ0LWF0Ojk1Ow0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNv LWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxp c3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6 bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1 bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0 ZSIgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3 aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBTdGVwaGFuZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3 aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93 dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SeKAmW0gbm90IG5lY2Vzc2FyaWx5IHNh eWluZyB0aGF0IHRoaXMgaXMgdGhlIHdheSB0byBnbywgYnV0IEkgd291bGQgbGlrZSB0byBwb2lu dCBvdXQgdGhlIFAgZmxhZyBhbmQgdGhlIEkgZmxhZyBpbiB0aGUgUENFUCBjb21tb24gb2JqZWN0 IGhlYWRlci4mbmJzcDsgSWYgYSBjb25zdHJhaW50IGNhbiBiZSByZWxheGVkLA0KIHRoZSBQQ0Mg c2VuZHMgdGhlIHJlbGV2YW50IG9iamVjdChzKSB3aXRoIFA9MC4mbmJzcDsgSWYgdGhlIFBDRSBk ZWNpZGVzIHRvIHJlbGF4IGEgY29uc3RyYWludCwgaXQgaW5jbHVkZXMgdGhlIHJlbGV2YW50IG9i amVjdChzKSBpbiB0aGUgUENSZXAgd2l0aCBJPTEuJm5ic3A7IERvZXMgdGhhdCBjaGFuZ2UgeW91 ciBvcGluaW9uIG9mIHdoZXRoZXIgYSBzdWl0YWJsZSBtZWNoYW5pc20gZm9yIHRoaXMgYWxyZWFk eSBleGlzdHM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaGVlcnM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Sm9uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndp bmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0 ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4gUGNl IFttYWlsdG86cGNlLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPnN0ZXBo YW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPGJyPg0KPGI+U2VudDo8L2I+IDE0IE5vdmVtYmVyIDIw MTcgMDE6MTg8YnI+DQo8Yj5Ubzo8L2I+IERVR0VPTiBPbGl2aWVyIElNVC9PTE4gJmx0O29saXZp ZXIuZHVnZW9uQG9yYW5nZS5jb20mZ3Q7OyBEYW5pZWxlIENlY2NhcmVsbGkgJmx0O2RhbmllbGUu Y2VjY2FyZWxsaUBlcmljc3Nvbi5jb20mZ3Q7OyBwY2VAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtQY2VdIGRyYWZ0LWlldGYtcGNlLWFzc29jaWF0aW9uLWRpdmVyc2l0eTogcmVs YXhpbmcgY29uc3RyYWludDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SGkgT2xpdmll ciw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+SSBkbyBub3QgYWdyZWUgd2l0aCB3aGF0IHlvdSBtZW50aW9uZWQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5UaGUgbWV0cmljIG9iamVjdCBpcyBkZWZpbmVkIChidXQgbm90 IGxpbWl0ZWQgdG8pIHRvIHNldCBhIGNvbnN0cmFpbnQgb24gdGhlIG1ldHJpYzogd2hhdCBJIHNo b3VsZCBvcHRpbWl6ZSBmb3IgKElHUCBtZXRyaWMsIFRFIG1ldHJpYywgYm90aOKApikgYW5kIGlz IHRoZXJlIGEgYm91bmRhcnkgdGhhdCBJIHNob3VsZCBub3QgZXhjZWVkLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+Tm90aGluZyBzYXlzIHRoYXQgdGhlIGNvbnN0cmFpbnQgY2FuIGJlIHJl bGF4ZWQgYnkgdGhlIFBDRS4gSWYgYSBQQ0UgcmVjZWl2ZXMgYSBjb21wdXRhdGlvbiByZXF1ZXN0 IG9yIG5lZWRzIHRvIGNvbXB1dGUgYSBwYXRoIGZvciBhbiBMU1AgaGF2aW5nIGZvciBpbnN0YW5j ZSBhIG1ldHJpYyBvYmplY3Qgd2l0aCB0eXBlPVRFIGFuZCBib3VuZD0xMDAuDQogSWYgaXQgY2Fu bm90IGZvdW5kIGEgcGF0aCwgaXQgd2lsbCByZXR1cm4gTk8tUEFUSCB3aXRob3V0IHJlbGF4aW5n IHRoZSBjb25zdHJhaW50LiBSZWxheGluZyB0aGUgY29uc3RyYWludCBtZWFucyB0aGF0IHRoZSBQ Q0MgYWxsb3dzIHRoZSBQQ0UgdG8gY29tcHV0ZSBhIHBhdGggd2l0aG91dCB1c2luZyB0aGUgcmVx dWVzdGVkIGNvbnN0cmFpbnQgaWYgdGhlIFBDRSBjYW5ub3QgZmluZCBhIHBhdGggdGhhdCBmaWxs cyB0aGlzIGNvbnN0cmFpbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5TbyBpbiBjYXNl IG9mIHRoZSBNRVRSSUMgb2JqZWN0IGFuZCB0aGUgYm91bmRhcnkgY2FzZSwgaWYgdGhlIFBDQyBh bGxvd3MgdGhlIFBDRSB0byByZWxheCB0aGUgY29uc3RyYWludCwgaWYgaXQgZG9lcyBub3QgZmlu ZCBhIHBhdGggZml0dGluZyB0aGUgYm91bmRhcnksIGl0IHdpbGwgcHJvdmlkZSBhIHBhdGggZXhj ZWVkaW5nIHRoaXMgYm91bmRhcnkNCiBpbnN0ZWFkIG9mIHJldHVybmluZyBOTy1QQVRILjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5Ob3cgdGhlIE1FVFJJQyBvYmplY3QgZG9lcyBub3QgaGF2ZSBhbnl0aGluZyB0byBkbyB3aXRo IHRoZSBkaXNqb2ludG5lc3MuIEV4Y2VwdCB0aGF0IHdlIGNhbiBjb21iaW5lIGJvdGggaWYgbmVl ZGVkICE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+Rm9yIHRoZSBkaXNqb2ludG5lc3MsIHdlIGhhdmUgdHdvIGNhc2VzIHdoZW4g dGhlIFBDQyBhbGxvd2VkIHRoZSBQQ0UgdG8gcmVsYXggdGhlIGNvbnN0cmFpbnQ6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBjbSIgdHlwZT0iZGlzYyI+DQo8 bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJjb2xvcjojMUY0OTdEO21hcmdpbi1s ZWZ0OjBjbTttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+VGhl IFBDRSBoYXMgc3VjY2Vzc2Z1bGx5IGNvbXB1dGVkIGEgZGlzam9pbnQgcGF0aCBidXQgd2l0aCBh IGxvd2VyIGRpc2pvaW50bmVzcyB0eXBlIChsaW5rIGluc3RlYWQgb2Ygbm9kZSBmb3IgaW5zdGFu Y2UpID0mZ3Q7IHRoaXMgY291bGQgYmUgc2VlbiBhcyBhIHBhcnRpYWxseSByZWxheGVkIGNvbnN0 cmFpbnQgYW5kIEkgYWdyZWUgdGhhdCB0aGUgc3RhdGUgY291bGQgYmUgc2VudCBieSBhZGRpbmcg dGhlIGFzc29jaWF0aW9uDQogZ3JvdXAgYW5kIGZpbGxpbmcgdGhlIOKAnGNvbXB1dGVkIHN0YXRl 4oCdIG9mIHRoZSBkaXNqb2ludG5lc3MgaW4gdGhlIERJU0pPSU5UTkVTUy1JTkZPUk1BVElPTiBU TFYgKE1FVFJJQyBvYmplY3QgaGFzIG5vdGhpbmcgdG8gZG8gaGVyZSkuPG86cD48L286cD48L3Nw YW4+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJjb2xvcjojMUY0OTdE O21hcmdpbi1sZWZ0OjBjbTttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8c3BhbiBsYW5nPSJF Ti1VUyI+VGhlIFBDRSBjYW5ub3QgY29tcHV0ZSBhIGRpc2pvaW50IHBhdGggYXQgYWxsIGFuZCBj b21wbGV0ZWx5IHJlbGF4ZWQgdGhlIGNvbnN0cmFpbnQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2xp PjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+U28gd2UgZG8g bm90IGhhdmUgYW55IHdheSB5ZXQgKEFGQUlLKSB0byB0ZWxsIHRoZSBQQ0UgdGhhdCBhIHBhcnRp Y3VsYXIgY29uc3RyYWludCBjYW4gYmUgcmVsYXhlZCAoYW5vdGhlciBleGFtcGxlIGlzIHRoZSBi YW5kd2lkdGggY29uc3RyYWludCA9Jmd0OyBJIGRvIG5vdCB0aGluayB0aGF0IGl0IGlzIGEgZ29v ZCBleGFtcGxlIGJ1dCB3aHkNCiBub3TigKYpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ VGhlbiB0aGUgUENFIG5lZWRzIHRvIHRlbGwgdGhlIFBDQyB0aGF0IGl0IGhhcyByZWxheGVkIGEg Y29uc3RyYWludCA9Jmd0OyB0aGlzIGNhbiBiZSBkZWR1Y2VkIGZyb20gYSDigJxjb21wdXRlZCBz dGF0ZeKAnSBwcm92aWRlZCBieSB0aGUgUENFIGZvciBlYWNoIGNvbnN0cmFpbnQsIGJ1dCBhIG1v cmUgY2xlYXIgaW5mb3JtYXRpb24gbWF5IGJlIGJldHRlcg0KIChwb3NzaWJseSBpbiBhZGRpdGlv biB0byB0aGUg4oCcY29tcHV0ZWQgc3RhdGXigJ0pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Ccmdkcyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gT2xpdmllciBEdWdlb24g WzxhIGhyZWY9Im1haWx0bzpvbGl2aWVyLmR1Z2VvbkBvcmFuZ2UuY29tIj5tYWlsdG86b2xpdmll ci5kdWdlb25Ab3JhbmdlLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTm92 ZW1iZXIgMTQsIDIwMTcgMDA6MzI8YnI+DQo8Yj5Ubzo8L2I+IExJVEtPV1NLSSBTdGVwaGFuZSBP QlMvT0lOSVM7IERhbmllbGUgQ2VjY2FyZWxsaTsgPGEgaHJlZj0ibWFpbHRvOnBjZUBpZXRmLm9y ZyI+DQpwY2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbUGNlXSBkcmFm dC1pZXRmLXBjZS1hc3NvY2lhdGlvbi1kaXZlcnNpdHk6IHJlbGF4aW5nIGNvbnN0cmFpbnQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VWJ1bnR1JnF1b3Q7LHNlcmlm Ij5IZWxsbyBTdGVwaGFuZSwgYWxsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1VidW50dSZxdW90OyxzZXJpZiI+SW4gZmFjdCwgdGhlc2UgbWVjaGFuaXNtIGlzIGFscmVh ZHkgYXZhaWxhYmxlIGluIFJGQyA1NDQwLg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1VidW50dSZxdW90OyxzZXJpZiI+Rmlyc3QsIE1ldHJpYyBPYmplY3QgaGFzIGJl ZW4gZGVmaW5lZCB3aXRoIGEgQiBmbGFnIHRvIGluZGljYXRlIGlmIHRoaXMgbWV0cmljIChpLmUu IGNvbnN0cmFpbnQpIG11c3QgYmUgYm91bmQgb3Igbm90LiBTZWUNCjxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NDQwI3NlY3Rpb24tNy44Ij5odHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjNTQ0MCNzZWN0aW9uLTcuODwvYT4uIFRlcm1pbm9sb2d5IGlzIG5vdCBl eGFjdGx5IHRoZSBzYW1lLCBidXQsIHRoZSBnb2FsIGlzIHNpbWlsYXIuIEl0IGFsbG93cyBhIFBD QyB0byBpbmRpY2F0ZSB0byB0aGUgUENFIGlmIHRoZSBtZXRyaWMgbXVzdCBiZSBzdHJpY3RseSBy ZXNwZWN0ZWQgb3INCiBub3QuIE5vdGUsIGFsc28gdGhhdCBpdCBpcyBwb3NzaWJsZSB0byBpbmRp Y2F0ZSBtYW55IHNpbWlsYXIgTWV0cmljIG9iamVjdCB3aXRoIGRpZmZlcmVudCB2YWx1ZSwgYXMg d2VsbCBhcyBkaWZmZXJlbnQgdmFsdWUgZm9yIHRoZSBCLWZsYWcgZm9yIG1vcmUgZmxleGliaWxp dHkuIEZvciBleGFtcGxlLCBmb3IgdGhlIERpc2pvaW50bmVzcywgd2UgY291bGQgaW1hZ2UgYSBm aXJzdCBNZXRyaWMgd2l0aCBTUkxHIGRpc2pvaW50IHBhdGggYW5kIEItRmxhZw0KIHNldCB0byBv bmUgYW5kIGEgc2Vjb25kIG9uZSB3aXRoIFNSTEctYW5kLU5vZGUgZGlzam9pbnQgcGF0aCB3aXRo IEItRmxhZyBjbGVhci4gVGhpcyBpbmRpY2F0ZSB0byB0aGUgUENFIHRoYXQgd2Ugd2FudCBhdCBs ZWFzdCBhbiBTUkxHIGRpc2pvaW50IHBhdGgsIGJ1dCBpZiBpdCBjb3VsZCBjb21wdXRlIGFuIFNS TEcgYW5kIE5vZGUgZGlzam9pbnQgcGF0aCB3ZSdsbCBiZSB2ZXJ5IGhhcHB5Ljwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtVYnVudHUmcXVvdDssc2VyaWYiPlBDQyBjb3Vs ZCBhbHNvIHNldCB0aGUgQy1GbGFnIHRvIGluZGljYXRlIHRvIHRoZSBQQ0UgdGhhdCBpdCB3b3Vs ZCBpbiB0dXJuIHRoZSBjb21wdXRlZCBNZXRyaWMuIEZvciBkaXNqb2ludG5lc3MsIGl0IGNvdWxk IGluZGljYXRlIHdoaWNoIHR5cGUgb2YgZGlzam9pbnRuZXNzIGl0IHN1Y2Nlc3NmdWxseSB1c2Vk IGZvciB0aGUgY29tcHV0ZWQgcGF0aC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VWJ1bnR1JnF1b3Q7LHNlcmlmIj5JZiBhIG1ldHJpYyBjb3VsZCBub3QgYmUgbWV0LCBQ Q0Ugd2lsbCByZXR1cm4gYSBOby1QQVRIIG9iamVjdCB3aXRoIHRoZSBkZWZhdWx0IG1ldHJpYyB0 byBpbmRpY2F0ZSB3aGljaCBjb25zdHJhaW50cyBjb3VsZCBub3QgYmUgbWV0Ljwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtVYnVudHUmcXVvdDssc2VyaWYiPk5vdywgdG8g aW5kaWNhdGUgdGhhdCBhIG1ldHJpYyAoY29uc3RyYWludCkgc2hvdWxkIGJlIHJlbGF4ZWQsIHRo ZXJlIGlzIDIgcG9zc2liaWxpdGllczogc2VuZCBhIG5ldyBQQ0VQIG1lc3NhZ2Ugd2l0aCB0aGUg Qi1GbGFnIG9mIHRoaXMgTWV0cmljIGNsZWFyZWQsIG9yIGEgUENFUCBtZXNzYWdlIHdpdGhvdXQg dGhlIGdpdmVuIE1ldHJpYy4gc2VlDQogYWdhaW4gUkZDIDU0NDAgZW5kIG9mIHNlY3Rpb24gNy44 IHBhZ2UgMzggKDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NDQwI3Bh Z2UtMzgiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NDQwI3BhZ2UtMzg8L2E+KS48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFu IGxhbmc9IkVOLVVTIj5TbywgSSB0aGluayB0aGUgZ2VuZXJpYyBtZWNoYW5pc20gaXMgYWxyZWFk eSBhdmFpbGFibGUgYW5kIHRvIGluaGVyaXQgZnJvbSB0aGlzIGJlaGF2aW91ciwgdGhlIERpc2pv aW50ZW5lc3MgVExWIHNob3VsZCBiZSBhIG5ldyBNZXRyaWMgT2JqZWN0IGluc3RlYWQgb2YgYSBk ZWRpY2F0ZWQgbmV3IFRMVi4gQnV0LCBJIHVuZGVyc3RhbmQgdGhhdCB0aGUgZHJhZnQgYW5kIHNv bHV0aW9uIGhhdmUgbm90IGJlZW4NCiBkZXNpZ24gd2l0aCB0aGlzIGluIG1pbmQuIFNvIEkgbGV0 IGF1dGhvcnMgZGVjaWRlZCBpZiBpdCBpcyBmZWFzaWJsZSBvciBub3QuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+T2xpdmllcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPkxlIDEzLzExLzIwMTcgw6AgMDk6NDAsIDxhIGhyZWY9Im1haWx0bzpzdGVwaGFuZS5saXRr b3dza2lAb3JhbmdlLmNvbSI+DQpzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTwvYT4gYSDD qWNyaXQmbmJzcDs6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SGkgRGFu aWVsZSw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPlRoYW5rcyBmb3IgeW91ciBmZWVkYmFjay48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SWYgd2UgZ28gdG8gYSBnZW5lcmljIG1lY2hh bmlzbSwgSU1PLCB0aGlzIHNob3VsZCBiZSBhZGRyZXNzZWQgaW4gYSBzZXBhcmF0ZSBkb2N1bWVu dC4gSW4gYWRkaXRpb24sIHdlIG5lZWQgYSBnZW5lcmljIHdheSBmb3IgYSBQQ0MgdG8gdGVsbCB0 aGUgUENFIHRoYXQgYSBjb25zdHJhaW50IGlzIHJlbGF4YWJsZSBvciBzdHJpY3QuIEZvciBkaXZl cnNpdHksDQogd2UgaGF2ZSBhIGRlZGljYXRlZCBmbGFnIHdpdGhpbiB0aGUgRElTSk9JTlRORVNT IFRMViBmb3IgdGhhdCBwdXJwb3NlLiBNYXliZSB3ZSBzaG91bGQgbWFrZSBpdCBnZW5lcmljIGFz IHdlbGwuDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPkRvIHlvdSBhZ3JlZSA/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Ccmdkcyw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1z ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+IERhbmll bGUgQ2VjY2FyZWxsaSBbPGEgaHJlZj0ibWFpbHRvOmRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nv bi5jb20iPm1haWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tPC9hPl0NCjxicj4N CjxiPlNlbnQ6PC9iPiBNb25kYXksIE5vdmVtYmVyIDEzLCAyMDE3IDE2OjMzPGJyPg0KPGI+VG86 PC9iPiBMSVRLT1dTS0kgU3RlcGhhbmUgT0JTL09JTklTOyA8YSBocmVmPSJtYWlsdG86cGNlQGll dGYub3JnIj5wY2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBkcmFmdC1p ZXRmLXBjZS1hc3NvY2lhdGlvbi1kaXZlcnNpdHk6IHJlbGF4aW5nIGNvbnN0cmFpbnQ8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iSVQiPkhpIFN0 ZXBoYW5lLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iSVQiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPmRlZmluaXRlbHkgbmVlZGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5NeSBvcGluaW9uIGlz IHRoYXQgYSB3YXkgdG8gc2F5IHRoYXQgYSBjb25zdHJhaW50IHdhcyByZWxheGVkIGlzIHZlcnkg dXNlZnVsLiBBcyB5b3Ugc2FpZCB0aGVyZSBhcmUgZGlmZmVyZW50IHR5cGVzIG9mIGNvbnN0cmFp bnRzIHRoYXQgY2FuIGJlIHJlbGF4ZWQsIGUuZy4gZGl2ZXJzaXR5IG9yIGEgVEUgYm91bmQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPkkgd291bGQgbWFrZSB0aGUgVExWIGFzIGdlbmVyaWMgYXMgcG9zc2libGUgYW5kIG1heWJl IGRlZmluZSBtdWx0aXBsZSBzdWItVExWIChvciBtYXliZSBqdXN0IG11bHRpcGxlIHZhbHVlcykg ZGVwZW5kaW5nIG9uIHRoZSBjb25zdHJhaW50IHRoYXQgd2FzIHJlbGF4ZWQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5CUjxicj4NCkRhbmllbGUmbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZy b206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFBjZSBbPGEgaHJlZj0ibWFpbHRvOnBj ZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86cGNlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+ T24gQmVoYWxmIE9mIDwvYj48YSBocmVmPSJtYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5n ZS5jb20iPnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPC9hPjxicj4NCjxiPlNlbnQ6PC9i PiBsdW5lZMOsIDEzIG5vdmVtYnJlIDIwMTcgMTY6MjI8YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9 Im1haWx0bzpwY2VAaWV0Zi5vcmciPnBjZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gW1BjZV0gZHJhZnQtaWV0Zi1wY2UtYXNzb2NpYXRpb24tZGl2ZXJzaXR5OiByZWxheGluZyBj b25zdHJhaW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IklUIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5IaSBXRyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkluIHRoZSBsYXRlc3QgdmVyc2lv biBvZiBkcmFmdC1pZXRmLXBjZS1hc3NvY2lhdGlvbi1kaXZlcnNpdHkgd2UgYWRkZWQgYSBuZXcg VExWIGNhbGxlZCBSRUxBWEVELUNPTlNUUkFJTlQtVExWIHRvIGJlIHVzZWQgaW4gTFNQIE9iamVj dCBvZiBhIFBDVXBkYXRlIG1lc3NhZ2Ugd2hlbiB0aGUgUENFIHJlbGF4ZXMgdGhlIHJlcXVlc3Rl ZCBkaXNqb2ludG5lc3MgY29uc3RyYWludC4NCiBGb3IgaW5zdGFuY2UsIGlmIGEgUENDIHJlcXVl c3RzIGFuIFNSTEcgZGlzam9pbnQgcGF0aCBidXQgdGhlIFBDRSBjYW5ub3QgZmluZCBpdCwgaXQg bWF5IHJlbGF4IHRoZSBjb25zdHJhaW50IChpZiBQQ0MgYWxsb3dzIGl0IHRvIGRvIHNvKSBhbmQg dGh1cyBpbmZvcm1zIHRoZSBQQ0MgdGhyb3VnaCB0aGUgUkVMQVhFRC1DT05TVFJBSU5ULVRMVi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPklNTywgdGhpcyBraW5kIG9mIGJlaGF2aW9yIGlzIG1vcmUgZ2Vu ZXJpYyByYXRoZXIgdGllZCB0byB0aGUgZGlzam9pbnRuZXNzIHVzZSBjYXNlLiBJdCBtYXkgYmUg dXNlZCB3aXRoIG90aGVyIGNvbnN0cmFpbnRzIGFzIHdlbGwuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5U aGUgcXVlc3Rpb24gaXM6IGRvIHdlIG5lZWQgdG8ga2VlcCB0aGlzIFJFTEFYRUQtQ09OU1RSQUlO VC1UTFYgaW4gdGhlIGFzc29jaWF0aW9uLWRpdmVyc2l0eSBkcmFmdCA/IG9yIGRvIHdlIGRyb3Ag aXQgPyBvciBkbyB3ZSBkZWZpbmUgYSBUTFYgbW9yZSBzcGVjaWZpYyB0byB0aGUgYXNzb2NpYXRp b24gZGl2ZXJzaXR5IHN0YXRlID8gbWF5YmUgd2UgY2FuIHJldXNlIHRoZSBhc3NvY2lhdGlvbg0K IGdyb3VwIG9iamVjdCBpbiB0aGUgUENVcGRhdGUgbWVzc2FnZSBpbmNsdWRpbmcgdGhlIERJU0pP SU5UTkVTUy1JTkZPUk1BVElPTi1UTFYgd2hpY2ggcmVmbGVjdHMgdGhlIGFjdHVhbCBkaXNqb2lu dG5lc3Mgc3R5bGUgdXNlZCBieSB0aGUgUENFLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T3BpbmlvbnMg PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJyZ2RzLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+U3RlcGhhbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuICwgc2VyaWYmcXVvdDssc2VyaWYiPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiAsIHNlcmlmJnF1b3Q7LHNlcmlmIj4mbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwOi8vd3d3Lm9yYW5nZS5jb20v Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDt0ZXh0LWRlY29yYXRpb246bm9uZSI+PGlt ZyBib3JkZXI9IjAiIHdpZHRoPSI0MCIgaGVpZ2h0PSI0MCIgc3R5bGU9IndpZHRoOi40MTY2aW47 aGVpZ2h0Oi40MTY2aW4iIGlkPSJQaWN0dXJlX3gwMDIwXzEiIHNyYz0iY2lkOmltYWdlMDAyLmpw Z0AwMUQzNUY4Mi44RTcxMTg0MCIgYWx0PSJPcmFuZ2UgbG9nbyI+PC9zcGFuPjwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6 MTUuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuICwgc2VyaWYmcXVvdDssc2VyaWYiPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlN0ZXBoYW5lIExpdGtv d3NraQ0KPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuICwgc2VyaWYmcXVvdDssc2VyaWYi Pjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+TmV0d29yayBBcmNoaXRl Y3QNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuICwgc2VyaWYmcXVvdDssc2VyaWYiPjxicj4N Cjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+T3JhbmdlL1NDRS9FUVVBTlQvT0lO SVMvTkVUPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+T3JhbmdlIEV4cGVy dCBGdXR1cmUgTmV0d29ya3M8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5w aG9uZToNCjxhIGhyZWY9Imh0dHBzOi8vbW9uc2kuc3NvLmZyYW5jZXRlbGVjb20uZnIvaW5kZXgu YXNwP3RhcmdldD1odHRwJTNBJTJGJTJGY2xpY3ZvaWNlLnNzby5mcmFuY2V0ZWxlY29tLmZyJTJG Q2xpY3ZvaWNlVjIlMkZUb29sQmFyLmRvJTNGYWN0aW9uJTNEZGVmYXVsdCUyNnJvb3RzZXJ2aWNl JTNEU0lHTkFUVVJFJTI2dG8lM0QmIzQzOzMzJTIwMiUyMDIzJTIwMjglMjA0OSUyMDgzJTIwIj4N CjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+JiM0MzszMyAyIDIzIDxiPjA2PC9iPiA0OSA4MyA8 L3NwYW4+PC9hPiZuYnNwO05FVyZuYnNwOyE8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiAsIHNlcmlm JnF1b3Q7LHNlcmlmIj48YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPm1vYmls ZToNCjxhIGhyZWY9Imh0dHBzOi8vbW9uc2kuc3NvLmZyYW5jZXRlbGVjb20uZnIvaW5kZXguYXNw P3RhcmdldD1odHRwJTNBJTJGJTJGY2xpY3ZvaWNlLnNzby5mcmFuY2V0ZWxlY29tLmZyJTJGQ2xp Y3ZvaWNlVjIlMkZUb29sQmFyLmRvJTNGYWN0aW9uJTNEZGVmYXVsdCUyNnJvb3RzZXJ2aWNlJTNE U0lHTkFUVVJFJTI2dG8lM0QmIzQzOzMzJTIwNiUyMDM3JTIwODYlMjA5NyUyMDUyJTIwIj4NCjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+JiM0MzszMyA2IDcxIDYzIDI3IDUwIDwvc3Bhbj48L2E+ Jm5ic3A7TkVXJm5ic3A7ITwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuICwgc2VyaWYmcXVvdDssc2Vy aWYiPjxicj4NCjxhIGhyZWY9Im1haWx0bzpzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojRkY2NjAwIj5zdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNv bTwvc3Bhbj48L2E+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkNlIG1lc3NhZ2UgZXQg c2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25m aWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+cGFzIGV0cmUgZGlmZnVzZXMs IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1 IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPmEgbCdleHBlZGl0ZXVyIGV0IGxl IGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVj dHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5PcmFuZ2UgZGVjbGluZSB0b3V0ZSBy ZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxz aWZpZS4gTWVyY2kuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t VVMiPlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBs YXc7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj50aGV5 IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9y aXNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMi PklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+QXMgZW1haWxz IG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBo YXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPC9kaXY+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkNlIG1lc3NhZ2UgZXQg c2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25m aWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+cGFzIGV0cmUgZGlmZnVzZXMs IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1 IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPmEgbCdleHBlZGl0ZXVyIGV0IGxl IGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVj dHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5PcmFuZ2UgZGVjbGluZSB0b3V0ZSBy ZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxz aWZpZS4gTWVyY2kuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t VVMiPlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBs YXc7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj50aGV5 IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9y aXNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMi PklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+QXMgZW1haWxz IG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBo YXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48YnI+DQo8YnI+DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBsYW5nPSJFTi1VUyI+UGNlIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0ibWFpbHRvOlBjZUBpZXRm Lm9yZyI+UGNlQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9wY2UiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNlPC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5DZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMg am9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVz IG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMg b3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdl IHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5hIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBh aW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBl dGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBsYW5nPSJFTi1VUyI+T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxp dGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNp LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGlzIG1l c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJp dmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OzxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+dGhleSBzaG91bGQgbm90 IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5JZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg YW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkFzIGVtYWlscyBtYXkgYmUgYWx0 ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1v ZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rIHlvdS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY4PR0201MB36039E445122E1E6B6C4E2BB842F0CY4PR0201MB3603_-- --_004_CY4PR0201MB36039E445122E1E6B6C4E2BB842F0CY4PR0201MB3603_ Content-Type: image/jpeg; name="image002.jpg" Content-Description: image002.jpg Content-Disposition: inline; filename="image002.jpg"; size=1119; creation-date="Fri, 17 Nov 2017 01:02:49 GMT"; modification-date="Fri, 17 Nov 2017 01:02:49 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCAAyADIDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD02bxP pcMrRvcAOpwRg00eLNJx/wAfI/I1wepD/iZXP++arV8/LNKsZWsj6KnlFKcE7s9F/wCEt0n/AJ+R +Ro/4S3Sf+fkfka86xRip/tar2Rf9jUf5mei/wDCW6T/AM/I/I0f8JbpP/PyPyNedYoxR/a1Xsg/ saj/ADM9G/4S3Sf+fkfkaK85xRR/a1Xsg/saj/My1qf/ACErn/fNVcYq1qg/4mlyP9s1V5Oa86p8 R6dD+HEB0ooHQetFZmtwooooAKKOPUUUWFc1Z9MlvNRvZFkSOOOTDSOeAaRvD10ElaSSKNI8fMTw a1W07V4bq6Edmk1vO+4qx4NNubPX7u3khktE2SEHg/dx2r1vqsL3cWeKsZNJJSVjMbw/di0Nwrxu qgdKWXw5dxKxDxOyEBkU8jPStd4/EDwPGbGIb1CnB9KaLbXjcSyfZEHm7dxB54o+qU9PdYfXauvv RMp/Dt0uQrxO4cKyKeQTUkuhDT4zNqDFo87f3RyVNdDew3/ksbS0YXDMrlyAOR61l31hrl/EY5LJ EBO5ip6mnPCwgnaLuKGMqVGuaaSMEi0BOGlx9KKu/wDCK6qefsv60Vx+xqfyM7vrFL/n4vvPR+5/ Cl9aKK+pPkhe1J/eoop9hMT+7TgKKKb3FHYjJOTRRRVgf//Z --_004_CY4PR0201MB36039E445122E1E6B6C4E2BB842F0CY4PR0201MB3603_-- From nobody Thu Nov 16 17:07: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 74A0E1270AB for ; Thu, 16 Nov 2017 17:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 nT0zeFhr1Etl for ; Thu, 16 Nov 2017 17:07:04 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 3B52B126CD8 for ; Thu, 16 Nov 2017 17:07:04 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id h42so2295759qtk.11 for ; Thu, 16 Nov 2017 17:07:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wy5DnlMeo1T699c31ZG3kL5WZInYCBD2lrQZPpsGEeY=; b=Hmdex8IdLAlwdDDu7rJjtg9I5M0n0JWmNCSPxasc9oI1rTyD5kPK6N+ZMuiM7G5yjn zaQpmvymCGIS8k7AZ6tMjIZ69VkMYyx/cqV+eKVUIsDp+uNipkZugACHuacmhsJSOuu0 yAyJs6jCIqdC2wlFJ4Dxly0zrxf9WjzzZQIfBRT5UiU3jCVium9rRmkL99nUREAxwptL JR3mhIe0WQrgT0XsZURn+73HUck9/d8xXaWO7XUjiRrTw1KBMp0TnBiqOF+CccZSrFEh 5yABDpet0b8fMc7WI0TJEwVXTAl9UHNL99y37yGPHe27/xx0MFpiE0D29xkSE4rxnwKu rspQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wy5DnlMeo1T699c31ZG3kL5WZInYCBD2lrQZPpsGEeY=; b=lgxZ38bbJUeJcEXiaPLPQW5p915xHgAie/dVUqXourruxoCIt6v4GxpKXkaRb+L8Ml +xfKdphLZPjGqMri2gt2bR9fdWCpJlblco/p4XDsSNc3uj0H6L+29eK3v+CpjOf02GnK 6Efhj9kimnNHLqyl1lGVSHRSgHNeUuWxsj5kZbilGyEbvas9qfbUSymkuLJMDTvUQiP2 9LnIzSJZiKNrgOj7h78CRj38AlVJjP0Rr4DQ1fX+jo533z2GTOf35LYW/kEQKNcP/K6q 4YU6DSFU3M42c3HZJg8scip04d56sykl7f35UcBhlVEXbsBDeCyiqDM4/FP/ImSadF3i jD2g== X-Gm-Message-State: AJaThX78dUZC4RiiR7L/bvq2HeCEYp0tq4EW/5XIPMFVhNdWdX2d/WK2 ZGVz20IO+4WvS5Mqcj7xuJ2tVuaB7khT8fnuwuA= X-Google-Smtp-Source: AGs4zMYnogkkww14FI89ZjpiffFIJIhCkSK1auYijusNf9Dy5CqrE5Cf5vANZwbLphZ+nFgpKBY8lMBk/1JR+wxR1dw= X-Received: by 10.200.17.1 with SMTP id c1mr5456908qtj.252.1510880823163; Thu, 16 Nov 2017 17:07:03 -0800 (PST) MIME-Version: 1.0 References: <7688_1510561338_5A09563A_7688_271_1_9E32478DFA9976438E7A22F69B08FF921EABBDF1@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <2637_1510562443_5A095A8B_2637_480_1_9E32478DFA9976438E7A22F69B08FF921EABBE39@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <9f1405b5-b166-9ad0-304c-b17d1830ae78@orange.com> <29540_1510593512_5A09D3E7_29540_488_1_87fe0df4-6382-476e-b0d7-edea0347d307@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: From: Dhruv Dhody Date: Fri, 17 Nov 2017 01:06:52 +0000 Message-ID: To: Jonathan Hardwick Cc: "DUGEON Olivier IMT/OLN" , Daniele Ceccarelli , "pce@ietf.org" , "stephane.litkowski@orange.com" Content-Type: multipart/mixed; boundary="089e08265168c35c6e055e235a68" Archived-At: Subject: Re: [Pce] draft-ietf-pce-association-diversity: relaxing constraint 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, 17 Nov 2017 01:07:08 -0000 --089e08265168c35c6e055e235a68 Content-Type: multipart/alternative; boundary="089e08265168c35c6b055e235a66" --089e08265168c35c6b055e235a66 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jon, Stephane and I discussed this earlier in the week. And this could be an interesting direction to explore! Will come back to the WG with a proposal soon. Thanks! Dhruv On Fri, 17 Nov 2017 at 9:03 AM, Jonathan Hardwick < Jonathan.Hardwick@metaswitch.com> wrote: > Hi Stephane > > > > I=E2=80=99m not necessarily saying that this is the way to go, but I woul= d like to > point out the P flag and the I flag in the PCEP common object header. If= a > constraint can be relaxed, the PCC sends the relevant object(s) with P=3D= 0. > If the PCE decides to relax a constraint, it includes the relevant > object(s) in the PCRep with I=3D1. Does that change your opinion of whet= her > a suitable mechanism for this already exists? > > > > Cheers > > Jon > > > > > > *From:* Pce [mailto:pce-bounces@ietf.org] *On Behalf Of * > stephane.litkowski@orange.com > *Sent:* 14 November 2017 01:18 > *To:* DUGEON Olivier IMT/OLN ; Daniele > Ceccarelli ; pce@ietf.org > > > *Subject:* Re: [Pce] draft-ietf-pce-association-diversity: relaxing > constraint > > > > Hi Olivier, > > > > I do not agree with what you mentioned. > > The metric object is defined (but not limited to) to set a constraint on > the metric: what I should optimize for (IGP metric, TE metric, both=E2=80= =A6) and > is there a boundary that I should not exceed. > > Nothing says that the constraint can be relaxed by the PCE. If a PCE > receives a computation request or needs to compute a path for an LSP havi= ng > for instance a metric object with type=3DTE and bound=3D100. If it cannot= found > a path, it will return NO-PATH without relaxing the constraint. Relaxing > the constraint means that the PCC allows the PCE to compute a path withou= t > using the requested constraint if the PCE cannot find a path that fills > this constraint. > > So in case of the METRIC object and the boundary case, if the PCC allows > the PCE to relax the constraint, if it does not find a path fitting the > boundary, it will provide a path exceeding this boundary instead of > returning NO-PATH. > > > > Now the METRIC object does not have anything to do with the disjointness. > Except that we can combine both if needed ! > > > > For the disjointness, we have two cases when the PCC allowed the PCE to > relax the constraint: > > - The PCE has successfully computed a disjoint path but with a lower > disjointness type (link instead of node for instance) =3D> this could = be seen > as a partially relaxed constraint and I agree that the state could be = sent > by adding the association group and filling the =E2=80=9Ccomputed stat= e=E2=80=9D of the > disjointness in the DISJOINTNESS-INFORMATION TLV (METRIC object has no= thing > to do here). > > > - The PCE cannot compute a disjoint path at all and completely relaxed > the constraint. > > > > So we do not have any way yet (AFAIK) to tell the PCE that a particular > constraint can be relaxed (another example is the bandwidth constraint = =3D> I > do not think that it is a good example but why not=E2=80=A6). > > Then the PCE needs to tell the PCC that it has relaxed a constraint =3D> > this can be deduced from a =E2=80=9Ccomputed state=E2=80=9D provided by t= he PCE for each > constraint, but a more clear information may be better (possibly in > addition to the =E2=80=9Ccomputed state=E2=80=9D). > > > > Brgds, > > > > *From:* Olivier Dugeon [mailto:olivier.dugeon@orange.com > ] > *Sent:* Tuesday, November 14, 2017 00:32 > *To:* LITKOWSKI Stephane OBS/OINIS; Daniele Ceccarelli; pce@ietf.org > *Subject:* Re: [Pce] draft-ietf-pce-association-diversity: relaxing > constraint > > > > Hello Stephane, all > > In fact, these mechanism is already available in RFC 5440. > > First, Metric Object has been defined with a B flag to indicate if this > metric (i.e. constraint) must be bound or not. See > https://tools.ietf.org/html/rfc5440#section-7.8. Terminology is not > exactly the same, but, the goal is similar. It allows a PCC to indicate t= o > the PCE if the metric must be strictly respected or not. Note, also that = it > is possible to indicate many similar Metric object with different value, = as > well as different value for the B-flag for more flexibility. For example, > for the Disjointness, we could image a first Metric with SRLG disjoint pa= th > and B-Flag set to one and a second one with SRLG-and-Node disjoint path > with B-Flag clear. This indicate to the PCE that we want at least an SRLG > disjoint path, but if it could compute an SRLG and Node disjoint path we'= ll > be very happy. > > PCC could also set the C-Flag to indicate to the PCE that it would in tur= n > the computed Metric. For disjointness, it could indicate which type of > disjointness it successfully used for the computed path. > > If a metric could not be met, PCE will return a No-PATH object with the > default metric to indicate which constraints could not be met. > > Now, to indicate that a metric (constraint) should be relaxed, there is 2 > possibilities: send a new PCEP message with the B-Flag of this Metric > cleared, or a PCEP message without the given Metric. see again RFC 5440 e= nd > of section 7.8 page 38 (https://tools.ietf.org/html/rfc5440#page-38). > > So, I think the generic mechanism is already available and to inherit fro= m > this behaviour, the Disjointeness TLV should be a new Metric Object inste= ad > of a dedicated new TLV. But, I understand that the draft and solution hav= e > not been design with this in mind. So I let authors decided if it is > feasible or not. > > Regards > > Olivier > > > > Le 13/11/2017 =C3=A0 09:40, stephane.litkowski@orange.com a =C3=A9crit : > > Hi Daniele, > > > > Thanks for your feedback. > > If we go to a generic mechanism, IMO, this should be addressed in a > separate document. In addition, we need a generic way for a PCC to tell t= he > PCE that a constraint is relaxable or strict. For diversity, we have a > dedicated flag within the DISJOINTNESS TLV for that purpose. Maybe we > should make it generic as well. > > > > Do you agree ? > > > > Brgds, > > > > > > *From:* Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com > ] > *Sent:* Monday, November 13, 2017 16:33 > *To:* LITKOWSKI Stephane OBS/OINIS; pce@ietf.org > *Subject:* RE: draft-ietf-pce-association-diversity: relaxing constraint > > > > Hi Stephane, > > > > definitely needed. > > My opinion is that a way to say that a constraint was relaxed is very > useful. As you said there are different types of constraints that can be > relaxed, e.g. diversity or a TE bound. > > I would make the TLV as generic as possible and maybe define multiple > sub-TLV (or maybe just multiple values) depending on the constraint that > was relaxed. > > > > BR > Daniele > > > > *From:* Pce [mailto:pce-bounces@ietf.org ] *On > Behalf Of *stephane.litkowski@orange.com > *Sent:* luned=C3=AC 13 novembre 2017 16:22 > *To:* pce@ietf.org > *Subject:* [Pce] draft-ietf-pce-association-diversity: relaxing constrain= t > > > > Hi WG, > > > > In the latest version of draft-ietf-pce-association-diversity we added a > new TLV called RELAXED-CONSTRAINT-TLV to be used in LSP Object of a > PCUpdate message when the PCE relaxes the requested disjointness > constraint. For instance, if a PCC requests an SRLG disjoint path but the > PCE cannot find it, it may relax the constraint (if PCC allows it to do s= o) > and thus informs the PCC through the RELAXED-CONSTRAINT-TLV. > > > > IMO, this kind of behavior is more generic rather tied to the disjointnes= s > use case. It may be used with other constraints as well. > > > > The question is: do we need to keep this RELAXED-CONSTRAINT-TLV in the > association-diversity draft ? or do we drop it ? or do we define a TLV mo= re > specific to the association diversity state ? maybe we can reuse the > association group object in the PCUpdate message including the > DISJOINTNESS-INFORMATION-TLV which reflects the actual disjointness style > used by the PCE. > > > > Opinions ? > > > > > > Brgds, > > > > Stephane > > > > > > [image: Orange logo] > > > > *Stephane Litkowski * > Network Architect > Orange/SCE/EQUANT/OINIS/NET > > Orange Expert Future Networks > > phone: +33 2 23 *06* 49 83 > > NEW ! > mobile: +33 6 71 63 27 50 > > NEW ! > stephane.litkowski@orange.com > > > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > > Thank you. > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > > Thank you. > > > > _______________________________________________ > > Pce mailing list > > Pce@ietf.org > > https://www.ietf.org/mailman/listinfo/pce > > > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > > Thank you. > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > --089e08265168c35c6b055e235a66 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jon,=C2=A0

=
Stephane and I discussed this earlier in the week. And th= is could be an interesting direction to explore! Will come back to the WG w= ith a proposal soon.=C2=A0

Thanks!=C2=A0
Dhruv=C2=A0

On Fri, 17 Nov 2017 at 9:03 AM, Jonathan Hardwick <Jonathan= .Hardwick@metaswitch.com> wrote:

Hi Stephane<= u>

=C2=A0

I=E2=80=99m not nec= essarily saying that this is the way to go, but I would like to point out t= he P flag and the I flag in the PCEP common object header.=C2=A0 If a const= raint can be relaxed, the PCC sends the relevant object(s) with P=3D0.=C2=A0 If the PCE decides = to relax a constraint, it includes the relevant object(s) in the PCRep with= I=3D1.=C2=A0 Does that change your opinion of whether a suitable mechanism= for this already exists?

=C2=A0

Cheers

Jon

=C2=A0

=C2=A0

F= rom: Pce [mailto= :pce-bounces@ietf= .org] On Behalf Of stephane.litkowski@orange.com
Sent: 14 November 2017 01:18
To: DUGEON Olivier IMT/OLN <olivier.dugeon@orange.com>; Daniele Ceccar= elli <daniele.ceccarelli@ericsson.com>; pce@ietf.org

<= p class=3D"MsoNormal">
Subject: Re: [Pce] draft-ietf-pce-association-diversity: relaxing co= nstraint

=C2=A0

Hi Oliv= ier,

= =C2=A0

I do no= t agree with what you mentioned.

The met= ric object is defined (but not limited to) to set a constraint on the metri= c: what I should optimize for (IGP metric, TE metric, both=E2=80=A6) and is= there a boundary that I should not exceed.

Nothing= says that the constraint can be relaxed by the PCE. If a PCE receives a co= mputation request or needs to compute a path for an LSP having for instance= a metric object with type=3DTE and bound=3D100. If it cannot found a path, it will return NO-PATH without relaxing the con= straint. Relaxing the constraint means that the PCC allows the PCE to compu= te a path without using the requested constraint if the PCE cannot find a p= ath that fills this constraint.

So in c= ase of the METRIC object and the boundary case, if the PCC allows the PCE t= o relax the constraint, if it does not find a path fitting the boundary, it= will provide a path exceeding this boundary instead of returning NO-PATH.

= =C2=A0

Now the= METRIC object does not have anything to do with the disjointness. Except t= hat we can combine both if needed !

= =C2=A0

For the= disjointness, we have two cases when the PCC allowed the PCE to relax the = constraint:

  • The PCE has successfully computed a disjoint path but = with a lower disjointness type (link instead of node for instance) =3D> = this could be seen as a partially relaxed constraint and I agree that the s= tate could be sent by adding the association group and filling the =E2=80=9Ccomputed state=E2=80=9D of the disjointness= in the DISJOINTNESS-INFORMATION TLV (METRIC object has nothing to do here)= .
  • The PCE cannot compute a disjoint path at all and comp= letely relaxed the constraint.

= =C2=A0

So we d= o not have any way yet (AFAIK) to tell the PCE that a particular constraint= can be relaxed (another example is the bandwidth constraint =3D> I do n= ot think that it is a good example but why not=E2=80=A6).

Then th= e PCE needs to tell the PCC that it has relaxed a constraint =3D> this c= an be deduced from a =E2=80=9Ccomputed state=E2=80=9D provided by the PCE f= or each constraint, but a more clear information may be better (possibly in addition to the =E2=80=9Ccomputed state=E2=80=9D).<= /u>

= =C2=A0

Brgds,<= u>

= =C2=A0

From:<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Tahoma"= ;,sans-serif;color:windowtext"> Olivier Dugeon [mailto:olivier.dugeon@orange.com]
Sent: Tuesday, November 14, 2017 00:32
To: LITKOWSKI Stephane OBS/OINIS; Daniele Ceccarelli; pce@ietf.org
Subject: Re: [Pce] draft-ietf-pce-association-diversity: relaxing co= nstraint

=C2=A0

Hell= o Stephane, all

In f= act, these mechanism is already available in RFC 5440.

Firs= t, Metric Object has been defined with a B flag to indicate if this metric = (i.e. constraint) must be bound or not. See https://tools.ietf.org/html/rfc5440#section-7.8. Terminology is not = exactly the same, but, the goal is similar. It allows a PCC to indicate to = the PCE if the metric must be strictly respected or not. Note, also that it is possible to indicate many similar Metric object= with different value, as well as different value for the B-flag for more f= lexibility. For example, for the Disjointness, we could image a first Metri= c with SRLG disjoint path and B-Flag set to one and a second one with SRLG-and-Node disjoint path with B-Flag c= lear. This indicate to the PCE that we want at least an SRLG disjoint path,= but if it could compute an SRLG and Node disjoint path we'll be very h= appy.

PCC = could also set the C-Flag to indicate to the PCE that it would in turn the = computed Metric. For disjointness, it could indicate which type of disjoint= ness it successfully used for the computed path.

If a= metric could not be met, PCE will return a No-PATH object with the default= metric to indicate which constraints could not be met.

Now,= to indicate that a metric (constraint) should be relaxed, there is 2 possi= bilities: send a new PCEP message with the B-Flag of this Metric cleared, o= r a PCEP message without the given Metric. see again RFC 5440 end of section 7.8 page 38 (https://tools.ietf.org/html/rfc5= 440#page-38).

So, I think the generic mechanism is already availa= ble and to inherit from this behaviour, the Disjointeness TLV should be a n= ew Metric Object instead of a dedicated new TLV. But, I understand that the= draft and solution have not been design with this in mind. So I let authors decided if it is feasible or no= t.

Regards

Olivier

=C2=A0

Le 13/11/2017 =C3=A0 09:40, stephane.litkowski@orange.com a =C3=A9crit=C2=A0:<= /p>

Hi Dani= ele,

=C2=A0<= /span>

Thanks = for your feedback.

If we g= o to a generic mechanism, IMO, this should be addressed in a separate docum= ent. In addition, we need a generic way for a PCC to tell the PCE that a co= nstraint is relaxable or strict. For diversity, we have a dedicated flag within the DISJOINTNESS TLV for that purpose. May= be we should make it generic as well.

=C2=A0<= /span>

Do you = agree ?

=C2=A0<= /span>

Brgds,<= /span>

=C2=A0<= /span>

=C2=A0<= /span>

From: Da= niele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Monday, November 13, 2017 16:33
To: LITKOWSKI Stephane OBS/OINIS; pce@ietf.org
Subject: RE: draft-ietf-pce-association-diversity: relaxing constrai= nt

=C2=A0

Hi Stephane,

=C2=A0=

definitely needed.

My opinion is that a way to say= that a constraint was relaxed is very useful. As you said there are differ= ent types of constraints that can be relaxed, e.g. diversity or a TE bound.=

I would make the TLV as generic= as possible and maybe define multiple sub-TLV (or maybe just multiple valu= es) depending on the constraint that was relaxed.

=C2=A0

BR
Daniele=C2=A0

=C2=A0

=C2=A0=

Hi WG,

=C2=A0

In the latest version of draft-= ietf-pce-association-diversity we added a new TLV called RELAXED-CONSTRAINT= -TLV to be used in LSP Object of a PCUpdate message when the PCE relaxes th= e requested disjointness constraint. For instance, if a PCC requests an SRLG disjoint path but the PCE cannot f= ind it, it may relax the constraint (if PCC allows it to do so) and thus in= forms the PCC through the RELAXED-CONSTRAINT-TLV.

=C2=A0

IMO, this kind of behavior is m= ore generic rather tied to the disjointness use case. It may be used with o= ther constraints as well.

=C2=A0

The question is: do we need to = keep this RELAXED-CONSTRAINT-TLV in the association-diversity draft ? or do= we drop it ? or do we define a TLV more specific to the association divers= ity state ? maybe we can reuse the association group object in the PCUpdate message including the DISJOINTNESS-INFORMATIO= N-TLV which reflects the actual disjointness style used by the PCE.<= u>

=C2=A0

Opinions ?=

=C2=A0

=C2=A0

Brgds,

=C2=A0

Stephane

=C2=A0

=C2=A0

3D"Orange

=C2=A0

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET

Orange Expert Future Networks

phone: +33 2 23 06 49 83 =C2=A0NEW= =C2=A0!
mobile: +33 6 71 63 27 50 =C2=A0NEW=C2=A0!
stephane.litkowski@orange.com

=C2=A0

_________________________________________________=
________________________________________________________________________=

=C2=A0
Ce message et ses pieces jointes peuvent contenir=
 des informations confidentielles ou privilegiees et ne doivent donc=

pas etre diffuses, exploites ou copies sans autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les p=
ieces jointes. Les messages electroniques etant susceptibles d'alterati=
on,
Orange decline toute responsabilite si ce message=
 a ete altere, deforme ou falsifie. Merci.
=C2=A0
This message and its attachments may contain conf=
idential or privileged information that may be protected by law;<=
/u>
they should not be distributed, used or copied wi=
thout authorisation.
If you have received this email in error, please =
notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable fo=
r messages that have been modified, changed or falsified.
Thank you.
_________________________________________________=
________________________________________________________________________=

=C2=A0
Ce message et ses pieces jointes peuvent contenir=
 des informations confidentielles ou privilegiees et ne doivent donc=

pas etre diffuses, exploites ou copies sans autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les p=
ieces jointes. Les messages electroniques etant susceptibles d'alterati=
on,
Orange decline toute responsabilite si ce message=
 a ete altere, deforme ou falsifie. Merci.
=C2=A0
This message and its attachments may contain conf=
idential or privileged information that may be protected by law;<=
/u>
they should not be distributed, used or copied wi=
thout authorisation.
If you have received this email in error, please =
notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable fo=
r messages that have been modified, changed or falsified.
Thank you.


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

=C2=A0

_________________________________________________=
________________________________________________________________________=

=C2=A0
Ce message et ses pieces jointes peuvent contenir=
 des informations confidentielles ou privilegiees et ne doivent donc=

pas etre diffuses, exploites ou copies sans autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les p=
ieces jointes. Les messages electroniques etant susceptibles d'alterati=
on,
Orange decline toute responsabilite si ce message=
 a ete altere, deforme ou falsifie. Merci.
=C2=A0
This message and its attachments may contain conf=
idential or privileged information that may be protected by law;<=
/u>
they should not be distributed, used or copied wi=
thout authorisation.
If you have received this email in error, please =
notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable fo=
r messages that have been modified, changed or falsified.
Thank you.
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
--089e08265168c35c6b055e235a66-- --089e08265168c35c6e055e235a68 Content-Type: image/jpeg; name="image002.jpg" Content-Disposition: attachment; filename="image002.jpg" Content-Transfer-Encoding: base64 Content-ID: <60F12BE0-D605-400E-8799-DD4A4A267212> X-Attachment-Id: 60F12BE0-D605-400E-8799-DD4A4A267212 /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCAAyADIDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD02bxP pcMrRvcAOpwRg00eLNJx/wAfI/I1wepD/iZXP++arV8/LNKsZWsj6KnlFKcE7s9F/wCEt0n/AJ+R +Ro/4S3Sf+fkfka86xRip/tar2Rf9jUf5mei/wDCW6T/AM/I/I0f8JbpP/PyPyNedYoxR/a1Xsg/ saj/ADM9G/4S3Sf+fkfkaK85xRR/a1Xsg/saj/My1qf/ACErn/fNVcYq1qg/4mlyP9s1V5Oa86p8 R6dD+HEB0ooHQetFZmtwooooAKKOPUUUWFc1Z9MlvNRvZFkSOOOTDSOeAaRvD10ElaSSKNI8fMTw a1W07V4bq6Edmk1vO+4qx4NNubPX7u3khktE2SEHg/dx2r1vqsL3cWeKsZNJJSVjMbw/di0Nwrxu qgdKWXw5dxKxDxOyEBkU8jPStd4/EDwPGbGIb1CnB9KaLbXjcSyfZEHm7dxB54o+qU9PdYfXauvv RMp/Dt0uQrxO4cKyKeQTUkuhDT4zNqDFo87f3RyVNdDew3/ksbS0YXDMrlyAOR61l31hrl/EY5LJ EBO5ip6mnPCwgnaLuKGMqVGuaaSMEi0BOGlx9KKu/wDCK6qefsv60Vx+xqfyM7vrFL/n4vvPR+5/ Cl9aKK+pPkhe1J/eoop9hMT+7TgKKKb3FHYjJOTRRRVgf//Z --089e08265168c35c6e055e235a68-- From nobody Fri Nov 17 09:29:40 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 4B9B8128C9C; Fri, 17 Nov 2017 09:29:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.94 X-Spam-Level: X-Spam-Status: No, score=0.94 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_BRBL_LASTEXT=1.449, 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 cEP0Ip88EAD4; Fri, 17 Nov 2017 09:29:36 -0800 (PST) Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [161.106.1.3]) by ietfa.amsl.com (Postfix) with ESMTP id 244EC1292F5; Fri, 17 Nov 2017 09:29:36 -0800 (PST) Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3989DE300C6; Fri, 17 Nov 2017 18:29:35 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail2.rd.orange.com (Postfix) with ESMTP id 18F2AE300BF; Fri, 17 Nov 2017 18:29:35 +0100 (CET) Received: from [10.193.71.63] (10.193.71.63) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.361.1; Fri, 17 Nov 2017 18:29:34 +0100 From: Julien Meuric To: Dhruv Dhody , Jonathan Hardwick CC: "draft-ietf-pce-pcep-exp-codepoints@ietf.org" , "pce@ietf.org" , 'Dhruv Dhody' References: <23CE718903A838468A8B325B80962F9B8D5C30A9@BLREML503-MBX.china.huawei.com> <23CE718903A838468A8B325B80962F9B8D5C3537@BLREML503-MBX.china.huawei.com> Organization: Orange Message-ID: <62ab8db3-ba39-99f6-a038-264f9800ea39@orange.com> Date: Fri, 17 Nov 2017 18:29:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <23CE718903A838468A8B325B80962F9B8D5C3537@BLREML503-MBX.china.huawei.com> Content-Type: text/html; charset="windows-1252" Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Pce] Shepherd's review of draft-ietf-pce-pcep-exp-codepoints 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, 17 Nov 2017 17:29:38 -0000 Hi,

IMHO, the correct wording lies in between. RFC 5440 set the default for PCEP ("A PCEP-ERROR object is used to report a PCEP error"). Further specification (e.g. RFC 8231) MAY add message-specific behavior, but I think it is wrong to mandate a new behavior for each new message. I would thus suggest :

   If the PCE does not understand or support an experimental object with

   the P flag set in the Object Header, in the Path Computation Request

   message (PCReq), the entire PCEP message is rejected and PCE responds

   with a PCErr message with Error-Type="Unknown Object" or "Not

   supported object" as described in [RFC5440]. Otherwise, the object is

   ignored. Message-specific behavior MAY be specified (e.g., [RFC8231]

   defines rules for a PCC to handle an unknown object in an Update

   (PCUpd) message).


My 2 cents,

Julien


Nov. 13, 2017 - dhruv.dhody@huawei.com:
<snip>

 

Section 5

 

The following paragraph does not tell the whole story.

 

   A PCE that does not recognize an experimental PCEP object, will

   reject the entire PCEP message and send a PCE error message with

   Error- Type="Unknown Object" or "Not supported object" as described

   in [RFC5440].

 

If the P flag is clear in the object header, then the PCE MAY ignore the object instead of generating this error message. Also, you do not discuss what a PCC would do on receipt of a PCUdp or PCInitiate containing an unrecognised experimental object – it is inconsistent that you don’t cover these cases.  (FWIW, RFC 8231 is a bit ambiguous about what a PCC should do about the PCUpd. Section 6.2 says that a PCErr should be sent, but then it refers to section 7.3.3, which says that a PCRpt should be sent. Hmmm.)

 

[[[Dhruv Dhody]]] Yes. How about I update to this –

 

   If the PCE does not understand or support an experimental object with

   the P flag set in the Object Header, in the Path Computation Request

   message (PCReq), the entire PCEP message is rejected and PCE responds

   with a PCErr message with Error-Type="Unknown Object" or "Not

   supported object" as described in [RFC5440].  Otherwise the object is

   ignored.  In case of stateful PCE messages [RFC8231], the P flag is

   ignored and the unknown object handling is as per the stateful PCE

   extensions.

 

And let’s try to handle the inconsistency in RFC 8231 with an errata perhaps? And handle PCE-initiated during AUTH48?

 

[Jon] I think this is OK, but if we are just going to point the reader at RFC8231, then we might as well do the same with RFC5440, rather than duplicate its text.  And we should write something that allows for the possibility that more message types may be relevant in future.  How about

 

   If a PCEP speaker does not understand or support an experimental object

   then the way it handles this situation depends on the message type.

   For example, a PCE handles an unknown object in the Path Computation Request

   (PCReq) message according to the rules of [RFC5440].  A PCC handles an

   unknown object in an Update (PCUpd) message according to the rules of [RFC8231]

   and, in an LSP Initiate Request (PCInitiate) message, according to the rules of

   [I-D.ietf-pce-pce-initiated-lsp].  Any document that adds a new PCEP message

   type must specify how to handle unknown objects on that message.

 

Note that this last sentence is not an RFC2119 MUST because it defines author behaviour, not device behaviour.


From nobody Sun Nov 19 06:43:36 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 5A044127444; Sun, 19 Nov 2017 06:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.091 X-Spam-Level: X-Spam-Status: No, score=0.091 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_KAM_HTML_FONT_INVALID=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 NU8ncybHUZ3u; Sun, 19 Nov 2017 06:43:32 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36047126DFF; Sun, 19 Nov 2017 06:43:30 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id vAJEhBwC002009; Sun, 19 Nov 2017 14:43:11 GMT Received: from 950129200 (116.133.112.87.dyn.plus.net [87.112.133.116]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id vAJEh6ej001981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Nov 2017 14:43:07 GMT Reply-To: From: "Adrian Farrel" To: "'Julien Meuric'" , "'Dhruv Dhody'" , "'Jonathan Hardwick'" Cc: , References: <23CE718903A838468A8B325B80962F9B8D5C30A9@BLREML503-MBX.china.huawei.com> <23CE718903A838468A8B325B80962F9B8D5C3537@BLREML503-MBX.china.huawei.com> <62ab8db3-ba39-99f6-a038-264f9800ea39@orange.com> In-Reply-To: <62ab8db3-ba39-99f6-a038-264f9800ea39@orange.com> Date: Sun, 19 Nov 2017 14:43:05 -0000 Message-ID: <192d01d36144$b7882660$26987320$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_192E_01D36144.B837A040" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGm2dMpzjo1KlnAomFEgjMX+8EKHwHALQ0+AP61i3QCjWwzpAJZU3uJozenuAA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23476.000 X-TM-AS-Result: No--9.293-10.0-31-10 X-imss-scan-details: No--9.293-10.0-31-10 X-TMASE-MatchedRID: 8HTFlOrbAtGs/r1De3um7n8c8oKMbgYYKVrLOZD1BXSOtR/F4zYXtD11 qDA2H+XsGf6fKkNuGyXzMV/yV0DYhkaWGOeKmQYQT7jCYv2QJPFWjiXAsVR2KwDqzaYhcjeQvWi 5ex0jCdKazNelTUd65jZt4KJQgKL78FLksoJC8fTKl4yJoI+fG4sz4mJ0Fhs2nWBUWlAKnBOlb6 juAbBDgeJG5Pg8+CYhNDWsJtFTOuUJS/QEXhWG8hj42LMyJUg81wL0WtLXyRooDMZ3xV44iD9AT 5NSrsCCC/CSdzKN+BPwIQ8TEKBvADZTv/1nu5StDPhWwJzVhb4dQSyPGb6mCCBs0OU9P6tbPd3q wUsPUgzPbEvPk0wrx4FDgIrlIU/9o4XUuMvTVpRtD1qg9KZYkYHSaqO6kWzlRUZL9AeG8IInOOO AFMb8+SM5BJR/sbr9oFIi5+lEOmNufzckypRuve9VsdrlGzy3Q6/DFZugyt0wODfUl7mJKf4ZAU sty2ENewo8j91GeTG6RgENsA/90MsesOAiftrl9iItFUn3XkM7r2Gtb9iBYU8dFP+NPq6+dXDbH Fxm2F+dv7RrSohAJCkm8kuls98/aEoHA+Yew8W7vYqkCS0dL7YidXoBo/qVlSFPfwjN9pHsoEFn ZAFTLE+J83GmsfZy66Wuu9SwKD8JG55i6ynXHMu00lnG8+PWMrX+p1uNztA93acSBBsAmvBYRo0 6eVj38vzD3/0Zl0qCRqPcZOXffFkb4pg11AKq+KUzuemidPxfohHCqSnabhUZTfM00s4+++vNJK ekcWQo1qU88HwltZ7FIsFagzgEUhIJtkjMIFmeAiCmPx4NwGmRqNBHmBvevqq8s2MNhPDPPeN6H N6d7OdLjQU97e0WxDLtK8W3eGeNdZtCXpomSMvEzTPLByiZhvp8GXTgcSRvHk22zMxk1rAnxZ/5 9U7FMMbdB5b4l2cHf02e9Jk7ujkv7ew5+Nwl/katnb2or7I= Archived-At: Subject: Re: [Pce] Shepherd's review of draft-ietf-pce-pcep-exp-codepoints 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: Sun, 19 Nov 2017 14:43:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_192E_01D36144.B837A040 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit That works for me, although I would probably lower-case the "MAY". A From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Julien Meuric Sent: 17 November 2017 17:30 To: Dhruv Dhody; Jonathan Hardwick Cc: draft-ietf-pce-pcep-exp-codepoints@ietf.org; pce@ietf.org Subject: Re: [Pce] Shepherd's review of draft-ietf-pce-pcep-exp-codepoints Hi, IMHO, the correct wording lies in between. RFC 5440 set the default for PCEP ("A PCEP-ERROR object is used to report a PCEP error"). Further specification (e.g. RFC 8231) MAY add message-specific behavior, but I think it is wrong to mandate a new behavior for each new message. I would thus suggest : If the PCE does not understand or support an experimental object with the P flag set in the Object Header, in the Path Computation Request message (PCReq), the entire PCEP message is rejected and PCE responds with a PCErr message with Error-Type="Unknown Object" or "Not supported object" as described in [RFC5440]. Otherwise, the object is ignored. Message-specific behavior MAY be specified (e.g., [RFC8231] defines rules for a PCC to handle an unknown object in an Update (PCUpd) message). My 2 cents, Julien Nov. 13, 2017 - dhruv.dhody@huawei.com: Section 5 The following paragraph does not tell the whole story. A PCE that does not recognize an experimental PCEP object, will reject the entire PCEP message and send a PCE error message with Error- Type="Unknown Object" or "Not supported object" as described in [RFC5440]. If the P flag is clear in the object header, then the PCE MAY ignore the object instead of generating this error message. Also, you do not discuss what a PCC would do on receipt of a PCUdp or PCInitiate containing an unrecognised experimental object - it is inconsistent that you don't cover these cases. (FWIW, RFC 8231 is a bit ambiguous about what a PCC should do about the PCUpd. Section 6.2 says that a PCErr should be sent, but then it refers to section 7.3.3, which says that a PCRpt should be sent. Hmmm.) [[[Dhruv Dhody]]] Yes. How about I update to this - If the PCE does not understand or support an experimental object with the P flag set in the Object Header, in the Path Computation Request message (PCReq), the entire PCEP message is rejected and PCE responds with a PCErr message with Error-Type="Unknown Object" or "Not supported object" as described in [RFC5440]. Otherwise the object is ignored. In case of stateful PCE messages [RFC8231], the P flag is ignored and the unknown object handling is as per the stateful PCE extensions. And let's try to handle the inconsistency in RFC 8231 with an errata perhaps? And handle PCE-initiated during AUTH48? [Jon] I think this is OK, but if we are just going to point the reader at RFC8231, then we might as well do the same with RFC5440, rather than duplicate its text. And we should write something that allows for the possibility that more message types may be relevant in future. How about If a PCEP speaker does not understand or support an experimental object then the way it handles this situation depends on the message type. For example, a PCE handles an unknown object in the Path Computation Request (PCReq) message according to the rules of [RFC5440]. A PCC handles an unknown object in an Update (PCUpd) message according to the rules of [RFC8231] and, in an LSP Initiate Request (PCInitiate) message, according to the rules of [I-D.ietf-pce-pce-initiated-lsp]. Any document that adds a new PCEP message type must specify how to handle unknown objects on that message. Note that this last sentence is not an RFC2119 MUST because it defines author behaviour, not device behaviour. ------=_NextPart_000_192E_01D36144.B837A040 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That works for me, = although I would probably lower-case the = "MAY".

 

A

 

From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Julien = Meuric
Sent: 17 November 2017 17:30
To: Dhruv Dhody; = Jonathan Hardwick
Cc: = draft-ietf-pce-pcep-exp-codepoints@ietf.org; = pce@ietf.org
Subject: Re: [Pce] Shepherd's review of = draft-ietf-pce-pcep-exp-codepoints

 

Hi,

IMHO, the = correct wording lies in between. RFC 5440 set the default for PCEP = ("A PCEP-ERROR object is used to report a PCEP error"). = Further specification (e.g. RFC 8231) MAY add message-specific behavior, = but I think it is wrong to mandate a new behavior for each new message. = I would thus suggest :

   If the PCE does not understand or support an = experimental object with

   the P flag set in the Object Header, in the Path = Computation Request

   message (PCReq), the entire PCEP message is rejected = and PCE responds

   with a PCErr message with Error-Type=3D"Unknown = Object" or "Not

   supported object" as described in [RFC5440]. = Otherwise, the object is

   ignored. Message-specific behavior MAY be specified = (e.g., [RFC8231]

   defines rules for a PCC to handle an unknown object = in an Update

   (PCUpd) message).


My 2 = cents,

Julien

Nov. 13, 2017 - dhruv.dhody@huawei.com:

<snip>

 

Section = 5

 

The following paragraph does not tell the whole = story.

 

   A PCE = that does not recognize an experimental PCEP object, = will

   reject the entire PCEP message = and send a PCE error message with

   Error- = Type=3D"Unknown Object" or "Not supported object" as = described

   in = [RFC5440].

 

If the P flag is clear in the object header, then the = PCE MAY ignore the object instead of generating this error message. = Also, you do not discuss what a PCC would do on receipt of a PCUdp or = PCInitiate containing an unrecognised experimental object – it is = inconsistent that you don’t cover these cases.  (FWIW, RFC = 8231 is a bit ambiguous about what a PCC should do about the PCUpd. = Section 6.2 says that a PCErr should be sent, but then it refers to = section 7.3.3, which says that a PCRpt should be sent. = Hmmm.)

 

[[[Dhruv Dhody]]] Yes. How about I update to this – =

 

   If the PCE does not understand or = support an experimental object with

   the P flag set in the Object = Header, in the Path Computation Request

   message (PCReq), the entire PCEP = message is rejected and PCE responds

   with a PCErr message with = Error-Type=3D"Unknown Object" or = "Not

   supported object" as = described in [RFC5440].  Otherwise the object = is

   ignored.  In case of stateful = PCE messages [RFC8231], the P flag is

   ignored and the unknown object = handling is as per the stateful PCE

   = extensions.

 

And let’s try to handle the inconsistency in RFC 8231 with an = errata perhaps? And handle PCE-initiated during AUTH48? =

 

[Jon] I think this is OK, but if we are just going to point the reader = at RFC8231, then we might as well do the same with RFC5440, rather than = duplicate its text.  And we should write something that allows for = the possibility that more message types may be relevant in future.  = How about

 

   If a PCEP speaker does not = understand or support an experimental object

   then the way it handles this = situation depends on the message type.

   For example, a PCE handles an = unknown object in the Path Computation Request

   (PCReq) message according to the = rules of [RFC5440].  A PCC handles an

   unknown object in an Update = (PCUpd) message according to the rules of = [RFC8231]

   and, in an LSP Initiate Request = (PCInitiate) message, according to the rules of

  =  [I-D.ietf-pce-pce-initiated-lsp].  Any document that adds a = new PCEP message

   type must specify how to handle = unknown objects on that message.

 

Note that this last sentence is not an RFC2119 MUST because it defines = author behaviour, not device = behaviour.

 

------=_NextPart_000_192E_01D36144.B837A040-- From nobody Mon Nov 20 04:32:54 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 B1DBF1201F8; Mon, 20 Nov 2017 04:32:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 AXZZsDTbxUpa; Mon, 20 Nov 2017 04:32:49 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0134.outbound.protection.outlook.com [104.47.42.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 651B212956C; Mon, 20 Nov 2017 04:32:49 -0800 (PST) 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=7XOHJ9dXqT40BUXpKiwZY4Kh86Cs5IBLnVn+RymuokY=; b=XedOp6odBIx/PYcnOTGXu5qQzNB0fCf4mqJM52IZPjBmms4DrZYH88ujAo4jptGjstHgzvhAm+dOFOSJ1k55jZgnmkTn68eVRVpDUPNv+gzHAcxt6TwM6mEitukNmrJC76q7HY4bOi50yyb9bJmsNFXoWi4iXNn5LLGlTNweFxc= Received: from CY4PR0201MB3603.namprd02.prod.outlook.com (52.132.99.21) by CY4PR0201MB3602.namprd02.prod.outlook.com (52.132.99.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Mon, 20 Nov 2017 12:32:47 +0000 Received: from CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::2475:224a:642f:a02b]) by CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::2475:224a:642f:a02b%13]) with mapi id 15.20.0239.009; Mon, 20 Nov 2017 12:32:47 +0000 From: Jonathan Hardwick To: "adrian@olddog.co.uk" , 'Julien Meuric' , 'Dhruv Dhody' CC: "draft-ietf-pce-pcep-exp-codepoints@ietf.org" , "pce@ietf.org" Thread-Topic: [Pce] Shepherd's review of draft-ietf-pce-pcep-exp-codepoints Thread-Index: AdNbazxoJX1mpJIUTGiD0iKyZXkw0wAQjYAAABhtNqAA7p95eQBexAWAACt2tdA= Date: Mon, 20 Nov 2017 12:32:47 +0000 Message-ID: References: <23CE718903A838468A8B325B80962F9B8D5C30A9@BLREML503-MBX.china.huawei.com> <23CE718903A838468A8B325B80962F9B8D5C3537@BLREML503-MBX.china.huawei.com> <62ab8db3-ba39-99f6-a038-264f9800ea39@orange.com> <192d01d36144$b7882660$26987320$@olddog.co.uk> In-Reply-To: <192d01d36144$b7882660$26987320$@olddog.co.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.132.73.252] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR0201MB3602; 6:s8YVbJxAuyQ+bWtl0rWDENUhmJ8UREKF4ghauPQA47aoFPHuD99f5daYs+ju+qLh6vWIWsIiG2E/NMeiebUZkQbK3MIivw1LrJc7NdjiWv4aIAhNDEjvCwOpCeV78FoKVoWqJL/dB7cfludCv+ukl9QeO2DKMOHUwMnqJG/GBo31WjjfUK+CseemRnkDnuo/S3fehcSqhbbMe5OmX76BKxp073KGsgJS7AxSFRZhjwHQZZ1SN8To32cPNH93005/aS6XWd3kYqW4Va2llju+1D4CcKwy6XHk2ts2RcoUjNo+hegiehWbtS2FNohmz5AhgHJChr4bvD3Vow3MdIzjpzNl59YKW3WKfvGrwTA9IFY=; 5:j8VBlxcLZFeLaWh+WBYWsZ+pr3M0aEHWSVtfWArf+dLiCmyFHwTpkCYKVcLkpQathB4Gmmc+IhSV5GG+licKhbzqYiNQX4igt1RjQxXIo1fYGoo30jkjpg5P3rIVJ4q7qDwcGCctvchANDUpikMmIfe86PkpDCipZ/h1yLImXo4=; 24:ki+19I5QrPK/4jESi+TBQBEqo9yjY56ahVlaXJllLekhXGWFRiXic4rmvw41Q/A+/n2OxCO/vGCNGDcH8fMLxxco3pR3oTpnxN5rnPbknOc=; 7:LHvuog1wMAETo5xD1ZzQ6OpA4WFxG7Oi9afgAMInelbHSJvS+T0uQFQiwTCHVkDE8+AytD1cL4VqfNmtc1OA/EYz0VrnXG279/CKb1sjF8Psk/cy0i/niSP7lulYd0uocH9RWV+UbcpiH/QzUJ6AlnW0hGYRG9UQXS+rMH7WClCCQzusdYsolwaK6p10pEKPI2CUX7eL7ZWJ8qVaEdXzMify63rzfgK2jo2hrMPpByHPut2BsZMOHfNEqeAXm0IP x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 34cb65c1-af66-4411-73d1-08d53012ce87 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:CY4PR0201MB3602; x-ms-traffictypediagnostic: CY4PR0201MB3602: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(50582790962513)(227612066756510)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231022)(100000703101)(100105400095)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123558100)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR0201MB3602; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR0201MB3602; x-forefront-prvs: 04976078F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(199003)(189002)(54906003)(2950100002)(5250100002)(3280700002)(66066001)(230783001)(68736007)(86362001)(25786009)(93886005)(3660700001)(53546010)(7696004)(54356999)(76176999)(6436002)(316002)(50986999)(33656002)(106356001)(101416001)(4326008)(2900100001)(110136005)(6506006)(55016002)(105586002)(5660300001)(2906002)(236005)(53936002)(9686003)(6306002)(54896002)(99286004)(97736004)(72206003)(6246003)(478600001)(14454004)(102836003)(6116002)(3846002)(189998001)(790700001)(229853002)(8676002)(74316002)(8936002)(2501003)(81166006)(7736002)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR0201MB3602; H:CY4PR0201MB3603.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR0201MB36039DA65E9E2C3258990F8584220CY4PR0201MB3603_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-Network-Message-Id: 34cb65c1-af66-4411-73d1-08d53012ce87 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2017 12:32:47.2977 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0201MB3602 Archived-At: Subject: Re: [Pce] Shepherd's review of draft-ietf-pce-pcep-exp-codepoints 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, 20 Nov 2017 12:32:53 -0000 --_000_CY4PR0201MB36039DA65E9E2C3258990F8584220CY4PR0201MB3603_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm OK with downgrading the "must" to a "may" (in lowercase). Cheers Jon From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: 19 November 2017 14:43 To: 'Julien Meuric' ; 'Dhruv Dhody' ; Jonathan Hardwick Cc: draft-ietf-pce-pcep-exp-codepoints@ietf.org; pce@ietf.org Subject: RE: [Pce] Shepherd's review of draft-ietf-pce-pcep-exp-codepoints That works for me, although I would probably lower-case the "MAY". A From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Julien Meuric Sent: 17 November 2017 17:30 To: Dhruv Dhody; Jonathan Hardwick Cc: draft-ietf-pce-pcep-exp-codepoints@ietf.org; pce@ietf.org Subject: Re: [Pce] Shepherd's review of draft-ietf-pce-pcep-exp-codepoints Hi, IMHO, the correct wording lies in between. RFC 5440 set the default for PCE= P ("A PCEP-ERROR object is used to report a PCEP error"). Further specifica= tion (e.g. RFC 8231) MAY add message-specific behavior, but I think it is w= rong to mandate a new behavior for each new message. I would thus suggest : If the PCE does not understand or support an experimental object with the P flag set in the Object Header, in the Path Computation Request message (PCReq), the entire PCEP message is rejected and PCE responds with a PCErr message with Error-Type=3D"Unknown Object" or "Not supported object" as described in [RFC5440]. Otherwise, the object is ignored. Message-specific behavior MAY be specified (e.g., [RFC8231] defines rules for a PCC to handle an unknown object in an Update (PCUpd) message). My 2 cents, Julien Nov. 13, 2017 - dhruv.dhody@huawei.com: Section 5 The following paragraph does not tell the whole story. A PCE that does not recognize an experimental PCEP object, will reject the entire PCEP message and send a PCE error message with Error- Type=3D"Unknown Object" or "Not supported object" as described in [RFC5440]. If the P flag is clear in the object header, then the PCE MAY ignore the ob= ject instead of generating this error message. Also, you do not discuss wha= t a PCC would do on receipt of a PCUdp or PCInitiate containing an unrecogn= ised experimental object - it is inconsistent that you don't cover these ca= ses. (FWIW, RFC 8231 is a bit ambiguous about what a PCC should do about t= he PCUpd. Section 6.2 says that a PCErr should be sent, but then it refers = to section 7.3.3, which says that a PCRpt should be sent. Hmmm.) [[[Dhruv Dhody]]] Yes. How about I update to this - If the PCE does not understand or support an experimental object with the P flag set in the Object Header, in the Path Computation Request message (PCReq), the entire PCEP message is rejected and PCE responds with a PCErr message with Error-Type=3D"Unknown Object" or "Not supported object" as described in [RFC5440]. Otherwise the object is ignored. In case of stateful PCE messages [RFC8231], the P flag is ignored and the unknown object handling is as per the stateful PCE extensions. And let's try to handle the inconsistency in RFC 8231 with an errata perhap= s? And handle PCE-initiated during AUTH48? [Jon] I think this is OK, but if we are just going to point the reader at R= FC8231, then we might as well do the same with RFC5440, rather than duplica= te its text. And we should write something that allows for the possibility= that more message types may be relevant in future. How about If a PCEP speaker does not understand or support an experimental object then the way it handles this situation depends on the message type. For example, a PCE handles an unknown object in the Path Computation Req= uest (PCReq) message according to the rules of [RFC5440]. A PCC handles an unknown object in an Update (PCUpd) message according to the rules of [R= FC8231] and, in an LSP Initiate Request (PCInitiate) message, according to the r= ules of [I-D.ietf-pce-pce-initiated-lsp]. Any document that adds a new PCEP mes= sage type must specify how to handle unknown objects on that message. Note that this last sentence is not an RFC2119 MUST because it defines auth= or behaviour, not device behaviour. --_000_CY4PR0201MB36039DA65E9E2C3258990F8584220CY4PR0201MB3603_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m OK with d= owngrading the “must” to a “may” (in lowercase).

Cheers

Jon

 

 

 

From: Adrian Farrel [mailto:adrian@old= dog.co.uk]
Sent: 19 November 2017 14:43
To: 'Julien Meuric' <julien.meuric@orange.com>; 'Dhruv Dhody' = <dhruv.dhody@huawei.com>; Jonathan Hardwick <Jonathan.Hardwick@met= aswitch.com>
Cc: draft-ietf-pce-pcep-exp-codepoints@ietf.org; pce@ietf.org
Subject: RE: [Pce] Shepherd's review of draft-ietf-pce-pcep-exp-code= points

 

That works for me, alt= hough I would probably lower-case the "MAY".

 

A

 

 

Hi,

IMHO, the correct wording lies in between. RFC 5440 set the default for PCE= P ("A PCEP-ERROR object is used to report a PCEP error"). Further= specification (e.g. RFC 8231) MAY add message-specific behavior, but I thi= nk it is wrong to mandate a new behavior for each new message. I would thus suggest :

 =   If the PCE does not understand or support an experimental object wit= h

 =   the P flag set in the Object Header, in the Path Computation Request=

 =   message (PCReq), the entire PCEP message is rejected and PCE respond= s

 =   with a PCErr message with Error-Type=3D"Unknown Object" or= "Not

 =   supported object" as described in [RFC5440]. Otherwise, the obj= ect is

 =   ignored. Message-specific behavior MAY be specified (e.g., [RFC8231]=

 =   defines rules for a PCC to handle an unknown object in an Update

 =   (PCUpd) message).


My 2 cents,

Julien

Nov. 13, 2017 - dhruv.dhody@huawei.com:

<snip>

 

Section 5

 

The following paragraph does not tell the whole stor= y.

 

   A PCE = that does not recognize an experimental PCEP object, will=

   reject= the entire PCEP message and send a PCE error message with

   Error-= Type=3D"Unknown Object" or "Not supported object" as d= escribed

   in [RF= C5440].

 <= /o:p>

If the P flag is clear in the object header, then th= e PCE MAY ignore the object instead of generating this error message. Also,= you do not discuss what a PCC would do on receipt of a PCUdp or PCInitiate= containing an unrecognised experimental object – it is inconsistent that you don’t cover these cases.&= nbsp; (FWIW, RFC 8231 is a bit ambiguous about what a PCC should do about t= he PCUpd. Section 6.2 says that a PCErr should be sent, but then it refers = to section 7.3.3, which says that a PCRpt should be sent. Hmmm.)

 

[[[Dhruv Dhody]]] Yes. How about I upd= ate to this –

 

 &nb= sp; If the PCE does not understand or support an experimental object with

 &nb= sp; the P flag set in the Object Header, in the Path Computation Request

 &nb= sp; message (PCReq), the entire PCEP message is rejected and PCE responds

 &nb= sp; with a PCErr message with Error-Type=3D"Unknown Object" or &q= uot;Not

 &nb= sp; supported object" as described in [RFC5440].  Otherwise the o= bject is

 &nb= sp; ignored.  In case of stateful PCE messages [RFC8231], the P flag i= s

 &nb= sp; ignored and the unknown object handling is as per the stateful PCE

   extensions.<= /o:p>

 

And let’s try to handle the inco= nsistency in RFC 8231 with an errata perhaps? And handle PCE-initiated duri= ng AUTH48?

 

[Jon] I think this is OK, but if we ar= e just going to point the reader at RFC8231, then we might as well do the s= ame with RFC5440, rather than duplicate its text.  And we should write something that allows for the possibility that more me= ssage types may be relevant in future.  How about

 

 &nb= sp; If a PCEP speaker does not understand or support an experimental object=

 &nb= sp; then the way it handles this situation depends on the message type.

  &n= bsp;For example, a PCE handles an unknown object in the Path Computation Re= quest

 &nb= sp; (PCReq) message according to the rules of [RFC5440].  A PCC handle= s an

 &nb= sp; unknown object in an Update (PCUpd) message according to the rules of [= RFC8231]

 &nb= sp; and, in an LSP Initiate Request (PCInitiate) message, according to the = rules of

  &n= bsp;[I-D.ietf-pce-pce-initiated-lsp].  Any document that adds a new PC= EP message

 &nb= sp; type must specify how to handle unknown objects on that message.=

 

Note that this last sentence is not an= RFC2119 MUST because it defines author behaviour, not device behaviour.

 

--_000_CY4PR0201MB36039DA65E9E2C3258990F8584220CY4PR0201MB3603_-- From nobody Mon Nov 20 05:34:35 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 74A3D129A8E; Mon, 20 Nov 2017 05:34:32 -0800 (PST) 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.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151118487243.22023.11452757683008716214@ietfa.amsl.com> Date: Mon, 20 Nov 2017 05:34:32 -0800 Archived-At: Subject: [Pce] I-D Action: draft-ietf-pce-wson-rwa-ext-07.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, 20 Nov 2017 13:34: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 WG of the IETF. Title : PCEP Extension for WSON Routing and Wavelength Assignment Authors : Young Lee Ramon Casellas Filename : draft-ietf-pce-wson-rwa-ext-07.txt Pages : 25 Date : 2017-11-20 Abstract: This document provides the Path Computation Element communication Protocol (PCEP) extensions for the support of Routing and Wavelength Assignment (RWA) in Wavelength Switched Optical Networks (WSON). Lightpath provisioning in WSONs requires a routing and wavelength assignment (RWA) process. From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical light path computation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-wson-rwa-ext/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-wson-rwa-ext-07 https://datatracker.ietf.org/doc/html/draft-ietf-pce-wson-rwa-ext-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-wson-rwa-ext-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 20 06:59:17 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 0480B129AB8; Mon, 20 Nov 2017 06:59:11 -0800 (PST) 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.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151118995097.21888.1120804081240463481@ietfa.amsl.com> Date: Mon, 20 Nov 2017 06:59:11 -0800 Archived-At: Subject: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.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, 20 Nov 2017 14:59:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : Conveying path setup type in PCEP messages Authors : Siva Sivabalan Jeff Tantsura Ina Minei Robert Varga Jon Hardwick Filename : draft-ietf-pce-lsp-setup-type-06.txt Pages : 10 Date : 2017-11-20 Abstract: A Path Computation Element can compute traffic engineering paths (TE paths) through a network that are subject to various constraints. Currently, TE paths are label switched paths (LSPs) which are set up using the RSVP-TE signaling protocol. However, other TE path setup methods are possible within the PCE architecture. This document proposes an extension to PCEP to allow support for different path setup methods over a given PCEP session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-setup-type/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-lsp-setup-type-06 https://datatracker.ietf.org/doc/html/draft-ietf-pce-lsp-setup-type-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-lsp-setup-type-06 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 Mon Nov 20 07:01:31 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 363B9129AB6; Mon, 20 Nov 2017 07:01:16 -0800 (PST) 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.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151119007617.22016.916175942186279110@ietfa.amsl.com> Date: Mon, 20 Nov 2017 07:01:16 -0800 Archived-At: Subject: [Pce] I-D Action: draft-ietf-pce-segment-routing-11.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, 20 Nov 2017 15:01:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : PCEP Extensions for Segment Routing Authors : Siva Sivabalan Clarence Filsfils Jeff Tantsura Wim Henderickx Jon Hardwick Filename : draft-ietf-pce-segment-routing-11.txt Pages : 22 Date : 2017-11-20 Abstract: Segment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by Link- State Interior Gateway Protocols (IGPs). A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic Engineering (TE) paths, as well as a PCC to request a path subject to certain constraint(s) and optimization criteria in SR networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-segment-routing-11 https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-segment-routing-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 20 07:07:11 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 57FF8129A90 for ; Mon, 20 Nov 2017 07:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.579 X-Spam-Level: X-Spam-Status: No, score=-4.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" 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 nGp4xXXXwciG for ; Mon, 20 Nov 2017 07:07:05 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0125.outbound.protection.outlook.com [104.47.36.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 932AE129AB7 for ; Mon, 20 Nov 2017 07:07:05 -0800 (PST) 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=75vxCTEuHHXoFVn7MIZpDKmtSekscOCS04hTGp5ENtI=; b=bxcNHToD+0yartMnj3vus/3iKIldXPqEWw7/RpjxGZHxJy+2fG+wCvNsCKFCMg3c16FW2Zq10ez5GAHQQaHWsBfhYt9ym3j8bEbMpA0u63V6I+/c7pezgXnSfwudW6VusBoe1hYjJoPNlwXyyEHipdt8xdZEACXp6xiiJAgHqHc= Received: from CY4PR0201MB3603.namprd02.prod.outlook.com (52.132.99.21) by CY4PR0201MB3601.namprd02.prod.outlook.com (52.132.98.39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Mon, 20 Nov 2017 15:07:03 +0000 Received: from CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::2475:224a:642f:a02b]) by CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::2475:224a:642f:a02b%13]) with mapi id 15.20.0239.009; Mon, 20 Nov 2017 15:07:03 +0000 From: Jonathan Hardwick To: "pce@ietf.org" Thread-Topic: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt Thread-Index: AQHTYhAuEIDe1/ZgqE2um4OEciXm96MdXMtA Date: Mon, 20 Nov 2017 15:07:03 +0000 Message-ID: References: <151118995097.21888.1120804081240463481@ietfa.amsl.com> In-Reply-To: <151118995097.21888.1120804081240463481@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-originating-ip: [86.132.73.252] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR0201MB3601; 6:I5ljzjtUTXkZMLcY45pIOhsWZbnUq2Wo7OaeeqDkI4zAlhnAR9iTyQAknEttJVD9NibbiNSd2apw4vYaquVXOHmeeEeFmut+QqPkc3kjxKAqQ7Oqwj4eFlf4anmjNQbGjdQxQ2AwjZnlZeMvTySrU/zYbKpcLjwe7YMRXQjK1qUGNeWiaK0qzQsLBaW15cjCr0DL05BA7n4G+hoSCXwO5IazAWC0KGFtWskIAyiLLZVSqOLNX+NETs/Dbqfz+0DcGhvKMSbVuv6op/mtexQgRUgCqIJq87y55obyD1AoY9olweu4Nq6WyJD7u88xDoIEaiC82ANOBO1Bu7hSjka+jWGHV26QyC9iCj7D5i49L5I=; 5:vXhBzTKJauG7tpUM+voMr3OO+fbBKTuEjgh+fO8U5iAdB4+y8Iy+bPZmuIZ1VebomR9E1YX9n9C5gV3s2JqEdQ2O0eyNzZR/sofCNMany5nOA/serqho2/IYB3XDL97KTk0XyDNiK/jTCNdDTHfNSlbYe8A6f/Bm0Kescsqf0iE=; 24:xn+D8nbwuN/yL0mh5VIMYTYf8Cj74Dl3uNkS9ca2avKuoxazS4fvtRQ7C8g5m06KKXs31BYKuZ5BSHNFw90tSuZX62q/G5ayp0QXxCsoXSc=; 7:PLGrnFr1X94ReaEVHXdwFzxoI6O4gZRvumFil6LKnvSvc0tLQx7oKgZHZHKdlyjQqVyz0wAz3/ZsI8Us9EcpcV7qrRoMgFyau/7XqfoUl+b3ipfoI4X+PuSrhlYfWxcX7ElsH89Vvt+FFHR//3hDLLR59ncV7dCjkD6Vhd5iARR4xTUTAQHCha3Iy4pNSRCl/AvRGJEa6gvps3RUTy58/A1N0J8PHA7BhuF4KQ4LN66nUkT4x1GbqtSKK9hZ8vgd x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 635dbd32-da61-4537-8106-08d530285b79 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199)(49563074); SRVR:CY4PR0201MB3601; x-ms-traffictypediagnostic: CY4PR0201MB3601: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(3231022)(3002001)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR0201MB3601; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR0201MB3601; x-forefront-prvs: 04976078F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(37854004)(377424004)(199003)(13464003)(189002)(229853002)(8936002)(3280700002)(189998001)(14454004)(6306002)(2950100002)(99936001)(81156014)(6916009)(76176999)(50986999)(2501003)(9686003)(54356999)(2473003)(8676002)(1730700003)(81166006)(101416001)(3660700001)(99286004)(2351001)(5890100001)(4326008)(105586002)(55016002)(53546010)(478600001)(230783001)(106356001)(4001150100001)(25786009)(74316002)(966005)(305945005)(33656002)(66066001)(7736002)(97736004)(72206003)(316002)(2900100001)(7696004)(54906003)(86362001)(5640700003)(6436002)(6506006)(5660300001)(5250100002)(53936002)(2906002)(68736007)(3846002)(6116002)(102836003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR0201MB3601; H:CY4PR0201MB3603.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_002_CY4PR0201MB36034B76B667AD7714112B5184220CY4PR0201MB3603_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-Network-Message-Id: 635dbd32-da61-4537-8106-08d530285b79 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2017 15:07:03.2589 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0201MB3601 Archived-At: Subject: [Pce] FW: I-D Action: draft-ietf-pce-lsp-setup-type-06.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: Mon, 20 Nov 2017 15:07:09 -0000 --_002_CY4PR0201MB36034B76B667AD7714112B5184220CY4PR0201MB3603_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear PCE WG This new revision of the LSP setup type draft makes the following changes. 1) Added a capability TLV for the OPEN object and rules for processing it, = as discussed in the attached thread. This is to address Julien's WGLC comme= nt that there was no way for a PCEP speaker to express that it doesn't supp= ort RSVP-TE as a path setup type. 2) Made the path setup type explicit for anything other than RSVP-TE paths = (where absence of TLV implies RSVP-TE). This is to address Stephane's rece= nt comment to the list. 3) Updated the IANA / code point text to reflect that we have had an early = allocation. 4) Made some editorial fixes and clarifications. Best regards Jon -----Original Message----- From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.o= rg Sent: 20 November 2017 14:59 To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Path Computation Element WG of the IETF. Title : Conveying path setup type in PCEP messages Authors : Siva Sivabalan Jeff Tantsura Ina Minei Robert Varga Jon Hardwick Filename : draft-ietf-pce-lsp-setup-type-06.txt Pages : 10 Date : 2017-11-20 Abstract: A Path Computation Element can compute traffic engineering paths (TE paths) through a network that are subject to various constraints. Currently, TE paths are label switched paths (LSPs) which are set up using the RSVP-TE signaling protocol. However, other TE path setup methods are possible within the PCE architecture. This document proposes an extension to PCEP to allow support for different path setup methods over a given PCEP session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-setup-type/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-lsp-setup-type-06 https://datatracker.ietf.org/doc/html/draft-ietf-pce-lsp-setup-type-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-lsp-setup-type-06 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 --_002_CY4PR0201MB36034B76B667AD7714112B5184220CY4PR0201MB3603_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Mon, 20 Nov 2017 15:06:58 GMT"; modification-date="Mon, 20 Nov 2017 15:06:58 GMT" Received: from CY1PR0201MB1916.namprd02.prod.outlook.com (10.163.56.26) by BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.10 via Mailbox Transport; Tue, 25 Jul 2017 15:04:05 +0000 Received: from BN6PR02CA0032.namprd02.prod.outlook.com (10.173.146.146) by CY1PR0201MB1916.namprd02.prod.outlook.com (10.163.56.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.10; Tue, 25 Jul 2017 15:04:04 +0000 Received: from BY2FFO11FD042.protection.gbl (2a01:111:f400:7c0c::129) by BN6PR02CA0032.outlook.office365.com (2603:10b6:404:5f::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.10 via Frontend Transport; Tue, 25 Jul 2017 15:04:04 +0000 Received: from mail.ietf.org (4.31.198.44) by BY2FFO11FD042.mail.protection.outlook.com (10.1.14.227) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1240.9 via Frontend Transport; Tue, 25 Jul 2017 15:04:03 +0000 Received: by ietfa.amsl.com (Postfix, from userid 65534) id 28A1D127B60; Tue, 25 Jul 2017 08:04:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D1F13167B; Tue, 25 Jul 2017 08:04:02 -0700 (PDT) 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 ToopR84dO9Yx; Tue, 25 Jul 2017 08:03:59 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0110.outbound.protection.outlook.com [104.47.38.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B1F6127B60; Tue, 25 Jul 2017 08:03:59 -0700 (PDT) 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.1282.10; Tue, 25 Jul 2017 15:03:55 +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.1282.020; Tue, 25 Jul 2017 15:03:55 +0000 From: Jonathan Hardwick To: Mahendra Singh Negi , "adrian@olddog.co.uk" , 'Julien Meuric' , "pce@ietf.org" , Dhruv Dhody CC: "draft-ietf-pce-lsp-setup-type@ietf.org" , "draft-ietf-pce-segment-routing@ietf.org" Subject: RE: [Pce] Can we make a non-backwards compatible change to draft-ietf-pce-lsp-setup-type? Thread-Topic: [Pce] Can we make a non-backwards compatible change to draft-ietf-pce-lsp-setup-type? Thread-Index: AdMCL6Ly08SduGL5TD6iP+F1jVMo6gLb6Lt6AoGNBjECUAnrYAH07KFjARW4HJ+jLz7AQNyBH2SA///ZoFA= Date: Tue, 25 Jul 2017 15:03:55 +0000 Message-ID: References: <0eca01d3024a$84045bf0$8c0d13d0$@olddog.co.uk> <114d01d304ad$bf3c26c0$3db47440$@olddog.co.uk> <127d01d30534$a47cb1b0$ed761510$@olddog.co.uk> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Exchange-Organization-AuthSource: BY2FFO11FD042.protection.gbl X-MS-Has-Attach: X-MS-Exchange-Organization-Network-Message-Id: fa22e880-5e52-44fb-a30e-08d4d36e6377 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) x-ms-exchange-organization-originalclientipaddress: 4.31.198.44 x-ms-exchange-organization-originalserveripaddress: 10.1.14.227 x-originating-ip: [86.132.73.220] 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=wXXa9ntc6jS9v4pmq1YM/BDO8KTrYwvnA0wHTNgj/Rg=; b=EzGvQNaQPn9xDnPXYqXZJAG3k4mcbw3yyYoHv1oQLtjQRbpgGJ8Nr+EhzAqT6aOw8wAIx5//MpQW7H0P4Qq456S3RG0OlYLcNMBne+6CQOFstFqFSCBSXfY72IFrvKjq3vUHwU4nYs/4KHfJh2Pfw3YB+hWsBKhSOvH1ySH5yBc= x-virus-scanned: amavisd-new at amsl.com x-spam-level: x-spam-status: No, score=-4.79 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_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no x-spam-score: -4.79 delivered-to: xfilter-draft-ietf-pce-segment-routing@ietfa.amsl.com x-original-to: xfilter-draft-ietf-pce-segment-routing@ietfa.amsl.com x-spam-flag: NO Resent-From: authentication-results: spf=softfail (sender IP is 4.31.198.44) smtp.mailfrom=metaswitch.com; metaswitch.com; dkim=pass (signature was verified) header.d=metaswitch.com;metaswitch.com; dmarc=pass action=none header.from=metaswitch.com; x-forefront-antispam-report: CIP:4.31.198.44;IPV:NLI;CTRY:US;EFV:NLI;SFV:NSPM;SFS:(8156002)(2980300002)(51444003)(189002)(199003)(37854004)(66654002)(7596002)(7736002)(7636002)(84326002)(46386002)(90966002)(2950100002)(66066001)(561944003)(99286003)(55016002)(236005)(61614004)(77096006)(37156001)(1096003)(356003)(8676002)(45336002)(53546010)(6506006)(81446001)(260700001)(246002)(512954002)(2501003)(2900100001)(6246003)(189998001)(106466001)(107886003)(3846002)(105596002)(6116002)(93886004)(86362001)(102836003)(15003)(6522003)(229853002)(53946003)(14454004)(790700001)(230783001)(54896002)(25786009)(5660300001)(9686003)(54906002)(57326003)(33656002)(626005)(4326008)(7696004)(76176999)(54356999)(56776999)(6306002)(72206003)(50986999)(956001)(74316002);DIR:INB;SFP:;SCL:1;SRVR:CY1PR0201MB1916;H:mail.ietf.org;FPR:;SPF:SoftFail;PTR:mail.ietf.org;MX:1;A:1;LANG:en; x-ms-publictraffictype: Email X-Microsoft-Exchange-Diagnostics: 1;BY2PR0201MB1910;27:W1Jew9LfwwoqLY6biwNm1Ap86xQ7KwfaXIY4achnz5YQ0D1ZxnXnag4ZIpZLrYGYTj81LFieL7qKImKedsQ6Xvyi02UGWQpFYm/+H1FKviPxhLHPRbXVpw6tARFBnD2R1DB4OX5XRByhs88uiIASLg== Content-Type: multipart/alternative; boundary="_000_BY2PR0201MB1910141F84413E6EF976DF1684B80BY2PR0201MB1910_" MIME-Version: 1.0 --_000_BY2PR0201MB1910141F84413E6EF976DF1684B80BY2PR0201MB1910_ X-Microsoft-Exchange-Diagnostics: 1;BY2PR0201MB1910;27:W1Jew9LfwwoqLY6biwNm1Ap86xQ7KwfaXIY4achnz5YQ0D1ZxnXnag4ZIpZLrYGYTj81LFieL7qKImKedsQ6Xvyi02UGWQpFYm/+H1FKviPxhLHPRbXVpw6tARFBnD2R1DB4OX5XRByhs88uiIASLg== Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Mahendra, many thanks for your input. PCE WG, we have a backwards compatible proposal on the table which, apart f= rom making a special case of SR-PCE-CAPABILITY, seems reasonably clean (or,= at least, not seriously broken). Shall we go forwards with that? Best regards Jon From: Mahendra Singh Negi [mailto:mahendrasingh@huawei.com] Sent: 25 July 2017 13:12 To: adrian@olddog.co.uk; 'Julien Meuric' ; Jonath= an Hardwick ; pce@ietf.org; Dhruv Dhody <= dhruv.dhody@huawei.com> Cc: draft-ietf-pce-lsp-setup-type@ietf.org; draft-ietf-pce-segment-routing@= ietf.org Subject: RE: [Pce] Can we make a non-backwards compatible change to draft-i= etf-pce-lsp-setup-type? Dear All, This is to answer on implantation row, apologies for the delayed response, = YES we do have our PCEP solutions deployed in mixed SR/RSVP-TE environment= s. I am afraid any non-backward compatible changes will break our solution. So= hope we choose a backward compatible solution. Regards, Mahendra (Huawei Tech India Pvt Ltd) From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: 25 July 2017 16:26 To: 'Julien Meuric'; 'Jonathan Hardwick'; pce@ietf.org Cc: draft-ietf-pce-lsp-setup-type@ietf.org; draft-ietf-pce-segment-routing@ietf.org Subject: Re: [Pce] Can we make a non-backwards compatible change to draft-i= etf-pce-lsp-setup-type? Sighing slightly:-) If, as may be the case, there is a demand to make this work either as curre= ntly specified or to be seamlessly interoperable with what is already speci= fied then so be it. Let's make that as a conscious decision. However, I think that using 7120 as an "excuse" is a bad idea. What 7120 is= saying is that the allocated code point must show some stability in meanin= g from the point of early allocation on to RFC (just as it would need to if= the RFC was revised). But that is not saying that, upon noticing that we a= re a herd of lemmings rushing towards the cliff we must say "We have always= rushed towards the cliff. Our parents rushed towards the cliff. We must co= ntinue even if it means we plunge to our deaths." Of course, nothing so dramatic, but... If the current specification works well - stay with it. If the current specification works but is clumsy - tweak it in a backward c= ompatible way If the current specification is broken in a minor way - fix it in a backwar= d compatible way If the current specification is more seriously broken - burn a new code poi= nt to fix it In my earlier emails I was only speculating on "how I would have done this = if starting from scratch." Obviously (?) I should have participated in WG d= iscussions much earlier in the cycle, and as a result my opinion really onl= y counts if either: - the current specification is more seriously broken or - there is no WG desire to stick close to the current specification. Clearly, although people who implement against I-Ds are doing so at their o= wn risk, we should not unnecessarily burden early implementations with chan= ges just for the sake of change. There is a sliding scale of "better ways t= o do things" that incorporates "it's a bit messy," "it will be easier to ma= intain and extend," all the way up to "it's broken." The WG will want to wo= rk out where we are on that scale and weigh it against the cost and inconve= nience of change. Shipping in software may be one measure. Deployed and in = use is another measure. Cheers, Adrian From: Julien Meuric [mailto:julien.meuric@orange.com] Sent: 25 July 2017 09:31 To: Jonathan Hardwick; adrian@olddog.co.uk; pce= @ietf.org Cc: draft-ietf-pce-lsp-setup-type@ietf.org; draft-ietf-pce-segment-routing@ietf.org Subject: Re: [Pce] Can we make a non-backwards compatible change to draft-i= etf-pce-lsp-setup-type? Hi, I agree that capability bitmap with optional capability-specific sub-TLVs w= ould be the way to go from scratch. However the SR-PCE-CAPABILITY already h= as an early allocated codepoint, and RFC 7120 says that "if there is a chan= ge, implementations based on the earlier and later specifications must be s= eamlessly interoperable." As a result, it seems to me that adding this new format may require that th= e I-D keeps documenting an optional SR-PCE-CAPABILITY TLV for legacy reason= s. Cheers, Julien Jul. 25, 2017 - Jonathan.Hardwick@metaswitch.com: I agree that allowing optional sub-TLVs is a good thing. However, this = strongly suggests that SR-PCE-CAPABILITY should become a sub-TLV, which is = a non-backwards compatible change. So, we are back to my original question= . Implementers =96 any views? Cheers Jon From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: 24 July 2017 19:51 Yes to that, Jon. But what happens when the next thing comes along? Since sub-TLVs can be present, I would suggest to use a Setup-Type TLV w= ith a bit map as I previously described in my email, and add optional sub-T= LVs dependent on the bits that are set. Isn't that the best of both worlds? Adrian From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com] Sent: 24 July 2017 09:15 Adrian, The SR-PCE-CAPABILITY TLV is more than just a Boolean value - it also co= ntains information about the maximum SID depth. However, I like your idea = and I think that it gives us a better way to do this without breaking backw= ards compatibility with existing SR implementations. Suppose we introduce a setup-type TLV into the OPEN object as you propos= e, and assign a bit to each setup type. If the TLV is absent, then RSVP-TE is supported. If the TLV is absent and the SR-PCE-CAPABILITY TLV is present, then RSVP= -TE and SR are supported. This retains backwards compatibility with existi= ng SR implementations. If the TLV is present, then the bits indicate which setup types are supp= orted. We would modify the LSP setup type draft to say that implementations sup= porting path setup types other than RSVP-TE SHOULD include the setup-type T= LV. It=92s not exactly beautiful, but it=92s not as ugly as RSVP-TE-NON-SUPP= ORT. Cheers Jon From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: 21 July 2017 19:55 Well, personally, if I was designing this, I would not a whole TLV for e= ach bit flag! I would have a Setup-Type TLV. If that TLV is absent, RSVP-TE is supported. If the TLV is present, each bit means that a different setup type is sup= ported. That means... Legacy nodes don't include the TLV and are assumed to support RSVP-TE Legacy nodes that receive the TLV don't know what it means and so object= to the Open (leaving a new node to re-Open for RSVP-TE only). New nodes include the TLV and so indicate explicitly what they support. I know it is late for that type of change, so how we proceed might depen= d on what implementations have done already. Adrian From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Jonathan Hardwick Sent: 21 July 2017 16:07 Dear PCE-ers I don=92t want to distract from the SDN topic too much, but we have an i= mportant decision to make about draft-ietf-pce-lsp-setup-type. The shepherd review raised an issue that there is no way for a PCEP spea= ker to indicate that it can=92t (or won=92t) support RSVP-TE as a path setu= p type. It is entirely plausible that a node might not support RSVP-TE, or= else have it disabled, for example in an SR-only network. We think that draft-ietf-pce-lsp-setup-type should be changed to allow a= speaker to declare that they do or don=92t have support for RSVP-TE paths.= There are two proposals. 1. Change draft-ietf-pce-lsp-setup-type so that speakers MUST inclu= de a (new) RSVP-TE-CAPABILITY TLV in their OPEN object. If this TLV if mis= sing, but some other CAPABILITY TLV is present (such as SR-CAPABILITY) then= it means that the speaker does not support RSVP-TE as a path setup type. 2. Change draft-ietf-pce-lsp-setup-type so that speakers MUST inclu= de a (new) RSVP-TE-NON-SUPPORT TLV in their OPEN object if they DON=92T sup= port RSVP-TE. If this TLV is omitted, it will be assumed that they do supp= ort RSVP-TE. The problem with (1) is that it is not backwards compatible. Any existi= ng SR implementation which also supports RSVP will not currently send this = new capability. So, if we make change (1) then forwards-level implementati= ons will incorrectly conclude that such backwards-level implementations do = not support RSVP-TE. The problem with (2) is that it is ugly, and in my opinion we should onl= y do something ugly with a new protocol extension if we simply can=92t avoi= d doing it. And so the question: are there any *deployments* of PCEP in a mixed SR/R= SVP-TE environment that would be broken if we made change (1)? Thanks Jon --_000_BY2PR0201MB1910141F84413E6EF976DF1684B80BY2PR0201MB1910_ X-Microsoft-Exchange-Diagnostics: 1;BY2PR0201MB1910;27:W1Jew9LfwwoqLY6biwNm1Ap86xQ7KwfaXIY4achnz5YQ0D1ZxnXnag4ZIpZLrYGYTj81LFieL7qKImKedsQ6Xvyi02UGWQpFYm/+H1FKviPxhLHPRbXVpw6tARFBnD2R1DB4OX5XRByhs88uiIASLg== Content-Type: text/html; charset="Windows-1252" Content-ID: <5543FDFAD4A6234AACE1E6AB0F3720BD@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

Mahendra, many thanks for your input.

 

PCE WG, we have a backwards compatible proposal on the table which, ap= art from making a special case of SR-PCE-CAPABILITY, seems reasonably clean= (or, at least, not seriously broken).  Shall we go forwards with that?

 

Best regards

Jon

 

 

F= rom: Mahendra Si= ngh Negi [mailto:mahendrasingh@huawei.com]
Sent: 25 July 2017 13:12
To: adrian@olddog.co.uk; 'Julien Meuric' <julien.meuric@orange.co= m>; Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com>; pce@ietf= .org; Dhruv Dhody <dhruv.dhody@huawei.com>
Cc: draft-ietf-pce-lsp-setup-type@ietf.org; draft-ietf-pce-segment-r= outing@ietf.org
Subject: RE: [Pce] Can we make a non-backwards compatible change to = draft-ietf-pce-lsp-setup-type?

 

Dear All,

 

This is to answer o= n implantation row, apologies for the delayed response,  YES we do hav= e our PCEP solutions deployed in mixed SR/RSVP-TE environments.<= /span>

I am afraid any non= -backward compatible changes will break our solution. So hope we choose a b= ackward compatible solution.

 

Regards,=

Mahendra (Huawei Te= ch India Pvt Ltd)

&n= bsp;

From:<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Tahoma"= ;,sans-serif;color:windowtext"> Pce [mailto:pce-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: 25 July 2017 16:26
To: 'Julien Meuric'; 'Jonathan Hardwick'; pce@ietf.org
Cc: draft-ietf-pce-lsp-setup-type@ietf.org; draft-ietf-pce-segment-routing@ietf.org
Subject: Re: [Pce] Can we make a non-backwards compatible change to = draft-ietf-pce-lsp-setup-type?

 

Sighing slightly:-)

 

If, as may be the case= , there is a demand to make this work either as currently specified or to b= e seamlessly interoperable with what is already specified then so be it. Le= t's make that as a conscious decision.

 

However, I think that = using 7120 as an "excuse" is a bad idea. What 7120 is saying is t= hat the allocated code point must show some stability in meaning from the p= oint of early allocation on to RFC (just as it would need to if the RFC was revised). But that is not saying that, upon n= oticing that we are a herd of lemmings rushing towards the cliff we must sa= y "We have always rushed towards the cliff. Our parents rushed towards= the cliff. We must continue even if it means we plunge to our deaths."

 

Of course, nothing so = dramatic, but...

 

If the current specifi= cation works well - stay with it.

If the current specifi= cation works but is clumsy - tweak it in a backward compatible way

If the current specifi= cation is broken in a minor way - fix it in a backward compatible way<= /o:p>

If the current specifi= cation is more seriously broken - burn a new code point to fix it

 

In my earlier emails I= was only speculating on "how I would have done this if starting from = scratch." Obviously (?) I should have participated in WG discussions m= uch earlier in the cycle, and as a result my opinion really only counts if either:

- the current specific= ation is more seriously broken

or

- there is no WG desir= e to stick close to the current specification.

 

Clearly, although peop= le who implement against I-Ds are doing so at their own risk, we should not= unnecessarily burden early implementations with changes just for the sake = of change. There is a sliding scale of "better ways to do things" that incorporates "it's a bit= messy," "it will be easier to maintain and extend," all the= way up to "it's broken." The WG will want to work out where we a= re on that scale and weigh it against the cost and inconvenience of change. Shipping in software may be one measure. Deployed and in use is another me= asure.

 

Cheers,

Adrian

 

From:<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Tahoma"= ;,sans-serif;color:windowtext"> Julien Meuric [mailto:julien.meuric@orange.com]
Sent: 25 July 2017 09:31
To: Jonathan Hardwick; adrian@olddog.co.uk; pce@ietf.org
Cc: draft-ietf-pce-lsp-setup-type@ietf.org; draft-ietf-pce-segment-routing@ietf.org
Subject: Re: [Pce] Can we make a non-backwards compatible change to = draft-ietf-pce-lsp-setup-type?

 

Hi,

I agree that capability bitmap with optional capability-specific sub-TLVs w= ould be the way to go from scratch. However the SR-PCE-CAPABILITY already h= as an early allocated codepoint, and RFC 7120 says that "if there is a= change, implementations based on the earlier and later specifications must be seamlessly interoperable." As a result, it seems to me that adding this new format may require that th= e I-D keeps documenting an optional SR-PCE-CAPABILITY TLV for legacy reason= s.

Cheers,

Julien

I agree that allowing = optional sub-TLVs is a good thing.  However, this strongly suggests th= at SR-PCE-CAPABILITY should become a sub-TLV, which is a non-backwards comp= atible change.  So, we are back to my original question.

 

Implementers =96 any v= iews?

 

Cheers

Jon<= /p>

 

 

From: Adrian Farrel [mailto:adrian@olddog.co.uk<= /span>]
Sent: 24 July 2017 19:51

 

Yes to that, Jon. But = what happens when the next thing comes along?

 

Since sub-TLVs can be = present, I would suggest to use a Setup-Type TLV with a bit map as I previo= usly described in my email, and add optional sub-TLVs dependent on the bits= that are set.

 

Isn't that the best of= both worlds?

 

Adrian

 

Fro= m: Jonathan Hardwick [mailto:Jonathan.Hardwick@met= aswitch.com]
Sent: 24 July 2017 09:15

 

Adrian,

 

The SR-PCE-CAPABILITY = TLV is more than just a Boolean value - it also contains information about = the maximum SID depth.  However, I like your idea and I think that it = gives us a better way to do this without breaking backwards compatibility with existing SR implementations.<= o:p>

 

Suppose we introduce a= setup-type TLV into the OPEN object as you propose, and assign a bit to ea= ch setup type.

If the TLV is absent, = then RSVP-TE is supported.

If the TLV is absent a= nd the SR-PCE-CAPABILITY TLV is present, then RSVP-TE and SR are supported.=   This retains backwards compatibility with existing SR implementation= s.

If the TLV is present,= then the bits indicate which setup types are supported.<= /p>

 

We would modify the LS= P setup type draft to say that implementations supporting path setup types = other than RSVP-TE SHOULD include the setup-type TLV.

 

It=92s not exactly bea= utiful, but it=92s not as ugly as RSVP-TE-NON-SUPPORT.

 

Cheers

Jon<= /p>

 

 

From: Adrian Farrel [mailto:adrian@olddog.co.uk<= /span>]
Sent: 21 July 2017 19:55

 

Well, personally, if I= was designing this, I would not a whole TLV for each bit flag!=

I would have a Setup-T= ype TLV.

If that TLV is absent,= RSVP-TE is supported.

If the TLV is present,= each bit means that a different setup type is supported.=

 

That means...

Legacy nodes don't inc= lude the TLV and are assumed to support RSVP-TE

Legacy nodes that rece= ive the TLV don't know what it means and so object to the Open (leaving a n= ew node to re-Open for RSVP-TE only).

New nodes include the = TLV and so indicate explicitly what they support.

 

I know it is late for = that type of change, so how we proceed might depend on what implementations= have done already.

 

Adrian

 

Fro= m: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Jonathan Hardwick
Sent: 21 July 2017 16:07

 

Dear PCE-ers

 

I don=92t want to distract from the SDN topic too mu= ch, but we have an important decision to make about draft-ietf-pce-lsp-setu= p-type.

 

The shepherd review raised an issue that there is no= way for a PCEP speaker to indicate that it can=92t (or won=92t) support RS= VP-TE as a path setup type.  It is entirely plausible that a node migh= t not support RSVP-TE, or else have it disabled, for example in an SR-only network.

 

We think that draft-ietf-pce-lsp-setup-type should b= e changed to allow a speaker to declare that they do or don=92t have suppor= t for RSVP-TE paths.  There are two proposals.

 

1.&= nbsp;     Change draft-ietf-pce-lsp-setup-type so that speakers MUST include a= (new) RSVP-TE-CAPABILITY TLV in their OPEN object.  If this TLV if mi= ssing, but some other CAPABILITY TLV is present (such as SR-CAPABILITY) the= n it means that the speaker does not support RSVP-TE as a path setup type.

2.&= nbsp;     Change draft-ietf-pce-lsp-setup-type so that speakers MUST include a= (new) RSVP-TE-NON-SUPPORT TLV in their OPEN object if they DON=92T support= RSVP-TE.  If this TLV is omitted, it will be assumed that they do sup= port RSVP-TE.

 

The problem with (1) is that it is not backwards com= patible.  Any existing SR implementation which also supports RSVP will= not currently send this new capability.  So, if we make change (1) th= en forwards-level implementations will incorrectly conclude that such backwards-level implementations do not support RSVP-TE.=

 

The problem with (2) is that it is ugly, and in my o= pinion we should only do something ugly with a new protocol extension if we= simply can=92t avoid doing it.

 

And so the question: are there any *deployments* of PCEP in a mixed SR/RSVP-TE environment that would be broken if we ma= de change (1)?

 

Thanks

Jon

 

 

--_000_BY2PR0201MB1910141F84413E6EF976DF1684B80BY2PR0201MB1910_-- --_002_CY4PR0201MB36034B76B667AD7714112B5184220CY4PR0201MB3603_-- From nobody Mon Nov 20 07:08:39 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 02606129AC5 for ; Mon, 20 Nov 2017 07:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_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=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 1e-A-gOOi717 for ; Mon, 20 Nov 2017 07:08:36 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0135.outbound.protection.outlook.com [104.47.42.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73AC5129AC1 for ; Mon, 20 Nov 2017 07:08:36 -0800 (PST) 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=i137bD1UB4F4LteU0TAegwatMMXu0DinL5YqtKb6vUE=; b=oD9+MObmh1Db03a041Y6Cr1Yh3ZTw2PYM6XovwwTNdd5LTJhIAPl306UUeT9Spem7EgqVpVfaH3TPDRliPwxv6SfEGPhCt+qxupSRRK6lFNcmhyP+BLHO8IyKqRvMynn3itn1tR04qT2kY7HjMZZ5oBtVqGmG67ApnWiEhSXlPs= Received: from CY4PR0201MB3603.namprd02.prod.outlook.com (52.132.99.21) by CY4PR0201MB3604.namprd02.prod.outlook.com (52.132.99.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Mon, 20 Nov 2017 15:08:35 +0000 Received: from CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::2475:224a:642f:a02b]) by CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::2475:224a:642f:a02b%13]) with mapi id 15.20.0239.009; Mon, 20 Nov 2017 15:08:35 +0000 From: Jonathan Hardwick To: "pce@ietf.org" Thread-Topic: [Pce] I-D Action: draft-ietf-pce-segment-routing-11.txt Thread-Index: AQHTYhB7kOA2YBb76kmmLqYIeM89M6MdXliw Date: Mon, 20 Nov 2017 15:08:35 +0000 Message-ID: References: <151119007617.22016.916175942186279110@ietfa.amsl.com> In-Reply-To: <151119007617.22016.916175942186279110@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-originating-ip: [86.132.73.252] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR0201MB3604; 6:45wUzw+Z9yd7ew9z4CoW7sugQVWvb0+TXWp5y6S4qsQ0l4s2fT9e3NnLw6qUu2wyqH/bfaeEy3dXb1Ou9VcHFIY7dqytA0ENwwDhs1zImH/npvj3MzNHnA0k1auLzBckwEM9MpvKKmYTZbajElt4la4FVyCPbFR+IYCl4uLKAib1NIkJl0FdRZ1V+0nO2R+r++Ppws1SxPnBqA+uvpg7CwufBDG4ncZAcKkurPnGks3RpJex5EhSr2hyES/6IdNrPU7uUWByipBa3g2hmsn0hPvTbW82hjgtifuyALI5E0q8JaJ/QMK/JxckYss/htO+HhIYxb9dJQA7vi1kYlIAhslc178/GmmFbVdvC0f9VbQ=; 5:qaNfQbBlRNKtE6pbBx+mrePH14tUlQ0xqv76Y2rP1RJK28eElUEeHfkSDrE5qxLt0Fv3zHv83hICTWwEDUHGRKLDt4MjVTAj0Ny7+r+iMPQKZj5oA1sZnBMrW+BQF4X+UDpG6pdJK4ylgcEnNmRaRuMeefqrQpogSsCWbhHeb58=; 24:tuwMopkxW65/t6Omb7t6ERFdshmMBBefUGZIFRusg1ddcvP/bMXDIvBfcKnPBnKOtO6Rb6aX+i6gpfrmrVkKevrGiY7fagpinhTY+Z+M4lo=; 7:WGKYxTczQanjuP4KEmW6QXcY4FlCw8KmaiTjcMz9/ziH4ntF8PcBAuO/2j8+PRWpZl75EQQKJ778J0iHhxOo6UaI5w2I6ZG7GirOBNLRVNa9i5P6oGux5eks2oBORBc+oJD8AwVoq1oii3HqVfNAj/kwC+YVWERel4lCY//vV+tJJMc4skffLjN155zY3P0uT4gPD74R8QSU+YPmC+nHuOq6Zy7hVO/i5/L4CB9oa+XHWU5IbYTnH7xfyFqewVxs x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: f2c64b4d-6f3d-464a-29e0-08d53028923a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:CY4PR0201MB3604; x-ms-traffictypediagnostic: CY4PR0201MB3604: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231022)(100000703101)(100105400095)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123558100)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR0201MB3604; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR0201MB3604; x-forefront-prvs: 04976078F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(189002)(37854004)(13464003)(199003)(377424004)(97736004)(6436002)(5250100002)(6506006)(9686003)(6306002)(2473003)(478600001)(6916009)(2351001)(106356001)(7696004)(2950100002)(5660300001)(105586002)(55016002)(4001150100001)(2900100001)(25786009)(966005)(14454004)(189998001)(86362001)(229853002)(5640700003)(8936002)(53936002)(68736007)(53546010)(2906002)(3280700002)(99286004)(102836003)(6116002)(3846002)(305945005)(7736002)(54356999)(76176999)(3660700001)(72206003)(50986999)(33656002)(66066001)(230783001)(8676002)(101416001)(316002)(2501003)(1730700003)(74316002)(81156014)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR0201MB3604; H:CY4PR0201MB3603.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) 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-Network-Message-Id: f2c64b4d-6f3d-464a-29e0-08d53028923a X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2017 15:08:35.0716 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0201MB3604 Archived-At: Subject: [Pce] FW: I-D Action: draft-ietf-pce-segment-routing-11.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: Mon, 20 Nov 2017 15:08:38 -0000 This new revision brings draft-ietf-pce-segment-routing in-line with the ne= w LSP-SETUP-TYPE-CAPABILITY TLV just published in draft-ietf-pce-lsp-setup-= type-06. -----Original Message----- From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.o= rg Sent: 20 November 2017 15:01 To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-segment-routing-11.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Path Computation Element WG of the IETF. Title : PCEP Extensions for Segment Routing Authors : Siva Sivabalan Clarence Filsfils Jeff Tantsura Wim Henderickx Jon Hardwick Filename : draft-ietf-pce-segment-routing-11.txt Pages : 22 Date : 2017-11-20 Abstract: Segment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by Link- State Interior Gateway Protocols (IGPs). A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic Engineering (TE) paths, as well as a PCC to request a path subject to certain constraint(s) and optimization criteria in SR networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-segment-routing-11 https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-segment-routing-11 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 Mon Nov 20 07:34:38 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 7B68F129B21 for ; Mon, 20 Nov 2017 07:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 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, 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 Y5KtLIMfedoQ for ; Mon, 20 Nov 2017 07:34:34 -0800 (PST) Received: from 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 5FF83129B20 for ; Mon, 20 Nov 2017 07:32:32 -0800 (PST) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 0143512075E; Mon, 20 Nov 2017 16:32:31 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.34]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id D4B2518009B; Mon, 20 Nov 2017 16:32:30 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM6F.corporate.adroot.infra.ftgroup ([fe80::bd00:88f8:8552:3349%17]) with mapi id 14.03.0361.001; Mon, 20 Nov 2017 16:32:26 +0100 From: To: Jonathan Hardwick , "pce@ietf.org" Thread-Topic: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt Thread-Index: AQHTYhAzQDMEDQvNYEKzuaLKEOqgaKMdTY2AgAAWz1A= Date: Mon, 20 Nov 2017 15:32:26 +0000 Message-ID: <18833_1511191950_5A12F58E_18833_177_1_00ff1de7-767a-43b2-8c51-57fda127cb08@OPEXCLILM6F.corporate.adroot.infra.ftgroup> References: <151118995097.21888.1120804081240463481@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.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: Mon, 20 Nov 2017 15:34:36 -0000 Hi Jon, Thanks for the update. One comment regarding this paragraph: "If the peer has sent no PATH-SETUP-TYPE-CAPABILITY TLV, then the PCEP speaker MUST infer that the peer supports path setup using at least RSVP-TE. The PCEP speaker MAY also infer that the peer supports other path setup types, but the means of inference are outside the scope of this document." Why not enforcing here ? I mean if a PCEP speaker uses a PST that was not a= dvertised in the capability TLV, the PST is rejected by a PCError. During the OPEN message, peers may agree on the PST to be used on the sessi= on based on the common subset. What's your opinion on that ? Brgds, Stephane -----Original Message----- From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com]=20 Sent: Monday, November 20, 2017 16:07 To: pce@ietf.org Cc: MEURIC Julien IMT/OLN; LITKOWSKI Stephane OBS/OINIS Subject: FW: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt Dear PCE WG This new revision of the LSP setup type draft makes the following changes. 1) Added a capability TLV for the OPEN object and rules for processing it, = as discussed in the attached thread. This is to address Julien's WGLC comme= nt that there was no way for a PCEP speaker to express that it doesn't supp= ort RSVP-TE as a path setup type. 2) Made the path setup type explicit for anything other than RSVP-TE paths = (where absence of TLV implies RSVP-TE). This is to address Stephane's rece= nt comment to the list. 3) Updated the IANA / code point text to reflect that we have had an early = allocation. 4) Made some editorial fixes and clarifications. Best regards Jon -----Original Message----- From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.o= rg Sent: 20 November 2017 14:59 To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Path Computation Element WG of the IETF. Title : Conveying path setup type in PCEP messages Authors : Siva Sivabalan Jeff Tantsura Ina Minei Robert Varga Jon Hardwick Filename : draft-ietf-pce-lsp-setup-type-06.txt Pages : 10 Date : 2017-11-20 Abstract: A Path Computation Element can compute traffic engineering paths (TE paths) through a network that are subject to various constraints. Currently, TE paths are label switched paths (LSPs) which are set up using the RSVP-TE signaling protocol. However, other TE path setup methods are possible within the PCE architecture. This document proposes an extension to PCEP to allow support for different path setup methods over a given PCEP session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-setup-type/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-lsp-setup-type-06 https://datatracker.ietf.org/doc/html/draft-ietf-pce-lsp-setup-type-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-lsp-setup-type-06 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 ___________________________________________________________________________= ______________________________________________ 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 Mon Nov 20 08:32:51 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 E1438129BCD for ; Mon, 20 Nov 2017 08:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 RFeWc9Wz61dK for ; Mon, 20 Nov 2017 08:32:48 -0800 (PST) Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1E61294A3 for ; Mon, 20 Nov 2017 08:32:48 -0800 (PST) Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6FC63A442BF for ; Mon, 20 Nov 2017 17:32:47 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail1.rd.orange.com (Postfix) with ESMTP id 5E64EA442BD for ; Mon, 20 Nov 2017 17:32:47 +0100 (CET) Received: from [10.193.71.63] (10.193.71.63) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.361.1; Mon, 20 Nov 2017 17:32:46 +0100 To: "pce@ietf.org" From: Julien Meuric Organization: Orange Message-ID: <12ce495e-8ca4-ebaf-67b9-289c3ffe289a@orange.com> Date: Mon, 20 Nov 2017 17:32:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Pce] Second WG Last Call 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: Mon, 20 Nov 2017 16:32:50 -0000 Dear PCE WG, Considering the concerns discussed on the list after the 1st WG Last Call, especially about the backward compatibility of the additional TLV (please see Jon's change list), this message starts a 2nd LC on draft-ietf-pce-lsp-setup-type-06. It will end on Monday December 4. Thanks for your careful reviews, Julien From nobody Mon Nov 20 16:34: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 2A5B312EAFC for ; Mon, 20 Nov 2017 16:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LCr9VOz1Mbj for ; Mon, 20 Nov 2017 16:34:12 -0800 (PST) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (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 83F75129A9D for ; Mon, 20 Nov 2017 16:34:12 -0800 (PST) Received: by mail-pf0-x231.google.com with SMTP id r68so2395708pfe.10 for ; Mon, 20 Nov 2017 16:34:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bvewhYy6UhVzsCHtvbs7eraVKHelxkoB9OWYZx9pt4c=; b=AP7E/+xrtvawhX/+rwgS5RM0GiS7SYnhZzy25f2lMuQmzZwfLeCyeZCvN3ChIBJ+rt oDDMWCrfWZ8EN2BnNU35v3OKVhL7ZOMxQFGGYWwUQhOoXJw7Bp6kodlpYzCqcKvPDYgW cNkGje5wZcreWc8dJH1SWZrYWelKZ7T/b5TiC0O5D0PS8MxzOW6lVJT0dNwQ6Aa7wPpV Sg6YrUYWC+5srxF5DWG1sFFvJrolpjOtEbrpIDU5v6q/d9m62atst0eUlB/zmsFpK5Xo GQGFuwB65YvQminRM2tKIWjBIijXdAfCi59kb5veztrNgZH3CpXvWCWaglJjyRWuNBzw FO1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bvewhYy6UhVzsCHtvbs7eraVKHelxkoB9OWYZx9pt4c=; b=ShNCrss7p80gCsUrWpVnHOx0hOgl6I0g/QUBr/JKJKf4/qY/PmyiAcMDriHAEvbVTk k5J3X2kDYh95F7rIf4ELLB57U6y9IEsMnbTriEZ8GkLSK0HOA4a6AH0BLlLKZIOdYJ7D Im95G9TvivX/FDVbPfif/8OrM2CgAeOhumw/mKNlTZd8rBLu2NGBqjB8etJv8aul4wPH vzAd/OgU80zGGPQGaQ6Uhu5pb+dPc55xbhcVEXXdpScM8Q1pRh1JrgQMChuL1WlxR6Xh O6KuFQD1+/rU3WfbkqEj/fkIjIm16sstigXotIuiaYE9OZcHFWPDgEMROZq0fSbqpDOv DQmA== X-Gm-Message-State: AJaThX42bD2FJZA5pdKJrRLGLfSiwYNlJUWUHK/BDzj7IKCqwbh8ONqV 8YXcxcnG7jXNbdeXDNV0FJx9fMwM X-Google-Smtp-Source: AGs4zMYB3s7ekQCWvLk+LpHLQsPlkOn2GvV0RviV97CBoiBoE/tuMkvXe+WVUWM5/65G0/GBOwMx7A== X-Received: by 10.98.48.3 with SMTP id w3mr13224173pfw.219.1511224451806; Mon, 20 Nov 2017 16:34:11 -0800 (PST) Received: from [10.186.94.53] ([219.83.84.163]) by smtp.gmail.com with ESMTPSA id k2sm5430526pff.150.2017.11.20.16.34.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Nov 2017 16:34:11 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Jeff Tantsura X-Mailer: iPhone Mail (15A432) In-Reply-To: <12ce495e-8ca4-ebaf-67b9-289c3ffe289a@orange.com> Date: Tue, 21 Nov 2017 08:34:09 +0800 Cc: "pce@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: <12ce495e-8ca4-ebaf-67b9-289c3ffe289a@orange.com> To: Julien Meuric Archived-At: Subject: Re: [Pce] Second WG Last Call 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, 21 Nov 2017 00:34:14 -0000 As co-author - yes/support Regards, Jeff > On Nov 21, 2017, at 00:32, Julien Meuric wrote: > > Dear PCE WG, > > Considering the concerns discussed on the list after the 1st WG Last > Call, especially about the backward compatibility of the additional TLV > (please see Jon's change list), this message starts a 2nd LC on > draft-ietf-pce-lsp-setup-type-06. It will end on Monday December 4. > > Thanks for your careful reviews, > > Julien > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From nobody Mon Nov 20 18:42:33 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 345F612E91F; Mon, 20 Nov 2017 18:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 cJU2kIgjPtwq; Mon, 20 Nov 2017 18:42:30 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::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 87D7012E870; Mon, 20 Nov 2017 18:42:30 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id 33so8492436qtv.1; Mon, 20 Nov 2017 18:42:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=j7/y8wij9AzoYEDWgEovo1ceeqbrO+ghHNvsv1qxPpI=; b=TQ2fsGMd4DSflMtKnTlCVUD2L0L9IyUr8cFyqWd7fI/upXGJXVCz9Ae5eTbIRdrp4S sNMdvBrMzrwjt6Y54Br4XqVPj/v92dVMWl1/oAeUCJfynAH9/CFVKIrTnP0zK34veLSR N3ijp4ZG8PyfS6BQmBX4e84jk++SXc7T8n4URP+PoF5m08lHtcnPFD1TQm7M9Mm4ncHl L/T+jxrPRBM7boslNH+DiDBIYgfwwy3EVLNufDsNB6jN8tesJXY2AAw1ZMOjumEiZMA+ GmUHTiQInwLS2lle9K50kKYNcJLavd6o6KppJg40eQS5ImIzFFTCwKE41g5I1bUW9kV0 zKTQ== 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:from:date:message-id:subject :to:cc; bh=j7/y8wij9AzoYEDWgEovo1ceeqbrO+ghHNvsv1qxPpI=; b=sRKMAaFKpEmQEDYiMilvG0tuXVvWr9a94mPx9eB8J/TaLEgbdUSQ/F5E4Vrr2bBJi6 QjPLfe0TzvOieugATIVe3fpvDxQ62QZxmv0q4KkIU8tCNvqBknYUK9MXbZO1vmPTuyrz 64lkCt27rqADW8/SULaYIvqwouJ09w1mjbIbsiqA1kM/I8LCpN7QdDBmp2HG5AIqGNua y9rPDL78DJj2HZULGvVLLSz2oP0Jdzof6b74zMDgelVrulNW0AFrgY7/f9DwI5zkneh6 CmLAnpSnBldWc0Pa3cw7cJ2JBJOBcV/pvKfoG5LDkznDJ2KERiE4GBytSy5UIMUWv5xQ PcWw== X-Gm-Message-State: AJaThX50GyXitjWRH4xefO3K/wWMqzXfqk6+koUUZX70ur8/0gdFgaWG +DzxS6Jv5W/4zfQYSPNjT+WZq9M00/emsBL25hJR1xzm X-Google-Smtp-Source: AGs4zMY0Qym7M93n1zrf+9FaKasjygktLjpUvLUlU3i8h4kOu1V6N6wEqkI3JTTCVo69jmaV5cORxhZCgHsDUSsO1qY= X-Received: by 10.200.50.78 with SMTP id y14mr26012333qta.84.1511232149476; Mon, 20 Nov 2017 18:42:29 -0800 (PST) MIME-Version: 1.0 Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.140.17.97 with HTTP; Mon, 20 Nov 2017 18:42:29 -0800 (PST) From: Dhruv Dhody Date: Tue, 21 Nov 2017 08:12:29 +0530 X-Google-Sender-Auth: ndOa-ubiiljAukKLi_GsYFCwfKM Message-ID: To: "pce@ietf.org" Cc: pce-chairs@ietf.org Content-Type: multipart/alternative; boundary="001a113bef4c71581e055e752767" Archived-At: Subject: [Pce] PCE WG Minutes for IETF100 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, 21 Nov 2017 02:42:32 -0000 --001a113bef4c71581e055e752767 Content-Type: text/plain; charset="UTF-8" Hi WG, The minutes are uploaded at https://datatracker.ietf.org/ doc/minutes-100-pce/ Please let me know if there are any comments. Thanks! Dhruv --001a113bef4c71581e055e752767 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi WG,=C2=A0

The minut= es are uploaded at=C2=A0https://datatracker= .ietf.org/doc/minutes-100-pce/

Thanks!=C2= =A0
Dhruv
--001a113bef4c71581e055e752767-- From nobody Tue Nov 21 00:28: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 D09E612940D for ; Tue, 21 Nov 2017 00:28:03 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-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 (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 rvSC7imIWHar for ; Tue, 21 Nov 2017 00:28:01 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0114.outbound.protection.outlook.com [104.47.32.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F08D129409 for ; Tue, 21 Nov 2017 00:28:01 -0800 (PST) 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=hgYZ2ZD9XAwTDgswa5GaoZhGFIQIASkMg9RgWHMvaww=; b=DA7a7OwobkPYwmVvMDjPJFG76ruIlR9EVwNK/vBKrGAqo5why/ayEmmCK+e/UjW9QsxwOis73dFE8DdkrPOlwceyFZpDk/fo38cP6dFc+A2879XYQGuZVNq6y9DoB5e5B9ats95JN30jwO58n+7zsTuqlff6bn+B/MZotvIFsQM= Received: from CY4PR0201MB3603.namprd02.prod.outlook.com (52.132.99.21) by CY4PR0201MB3604.namprd02.prod.outlook.com (52.132.99.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Tue, 21 Nov 2017 08:27:59 +0000 Received: from CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::2475:224a:642f:a02b]) by CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::2475:224a:642f:a02b%13]) with mapi id 15.20.0239.009; Tue, 21 Nov 2017 08:27:59 +0000 From: Jonathan Hardwick To: "stephane.litkowski@orange.com" , "pce@ietf.org" Thread-Topic: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt Thread-Index: AQHTYhAuEIDe1/ZgqE2um4OEciXm96MdXMtAgAAInQCAARn+4A== Date: Tue, 21 Nov 2017 08:27:58 +0000 Message-ID: References: <151118995097.21888.1120804081240463481@ietfa.amsl.com> <18833_1511191950_5A12F58E_18833_177_1_00ff1de7-767a-43b2-8c51-57fda127cb08@OPEXCLILM6F.corporate.adroot.infra.ftgroup> In-Reply-To: <18833_1511191950_5A12F58E_18833_177_1_00ff1de7-767a-43b2-8c51-57fda127cb08@OPEXCLILM6F.corporate.adroot.infra.ftgroup> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-originating-ip: [86.132.73.252] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR0201MB3604; 6:TpvHS6iAstbO4H98t+WJTouLz7RX6m91bj9gKR1HVHMGpHxez6xhv9OBBJTjXvmOwq+XmQLnCg1LBbGBiQPPxGCGq2qSecNPkf5UvlVX1ZIdRSUThUGnhYis22SDYHl00O4pLMa4X9yEXyJzUU+gM3lu++NwoMDmXNbBPH8A1Y3TejLtQZR216ZX4eCf3jbasRZ21znW9jBQj450fhLPtmuZD855DoM7Is4vwqeCvvTJ5loYSLeeTu0Tr9hUm7Y1ixqBmSci7GLUreF0NACb3ZFG3La6H15jhiLNLSrX2zfCNsq51Dsgutma+iwoU+faa78i3fu6x+WykNGDnEnjbfgnubxlbW4PY/rjzVfQ16E=; 5:RK4ROIpMaKI9g7c/TEDoSzmTi1LCqXbjK1dSNYRQZqtZH2Z8np1iYcvGkgd+TBFt1sH0dg3gBIF/sSFJxVZuISt6ZDo6/qFZnFPqMA7zfz2xBIOzhlfzCiYGd9aim2rr2GsFAlDVSDpsvwsXm3G0Az47SAX9AFrI9/WICzJitNE=; 24:oV8XcrQsQTqoGw6aGOakMNHEFLfq/qbHDvADthRif7G54aIYEhFwNYUhLdXw7VzCpXxDmmMtT6/CCPmbKC3+GVcJBK4j7c4urWYy83e/dd8=; 7:xOfFJwA3A2j7k2/VLySn0aVHOQsRA8H+CeZM0JRxzKvgAfG62wu4+m89uBSpx67F7fxruYuKeKE3eEgHX0XpHTdFPutM4iHR6I2WgxBbdsglPM9CPj5hBsPIDXjdcCPUhuSFkW1OfZlOx4gmi4daEGc+FVaHa8pEZICPF7tAancHF7oQFfaga39ZgXTWh/S3m23tCR2aULRNIwJzN/n4D8Gw2QyigpFhXwQJNHHbsr5qwKz14l2nxSjGMvh7Ywrp x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d7086183-08aa-4cd6-6ec6-08d530b9c5f3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:CY4PR0201MB3604; x-ms-traffictypediagnostic: CY4PR0201MB3604: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231022)(3002001)(100000703101)(100105400095)(6041248)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR0201MB3604; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR0201MB3604; x-forefront-prvs: 049897979A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(377424004)(51914003)(199003)(189002)(37854004)(13464003)(50986999)(72206003)(3660700001)(54356999)(76176999)(3280700002)(2906002)(53546010)(7736002)(305945005)(99286004)(102836003)(6116002)(3846002)(2501003)(316002)(74316002)(81166006)(81156014)(8676002)(5890100001)(101416001)(33656002)(105586002)(5660300001)(7696004)(2950100002)(97736004)(6506006)(5250100002)(6436002)(230783001)(66066001)(6306002)(9686003)(478600001)(106356001)(14454004)(189998001)(86362001)(229853002)(966005)(53936002)(68736007)(2900100001)(6246003)(110136005)(55016002)(8936002)(25786009)(4001150100001)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR0201MB3604; H:CY4PR0201MB3603.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) 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-Network-Message-Id: d7086183-08aa-4cd6-6ec6-08d530b9c5f3 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Nov 2017 08:27:58.7347 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0201MB3604 Archived-At: Subject: Re: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.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: Tue, 21 Nov 2017 08:28:04 -0000 Hi Stephane Many thanks for the comment. This text is a compromise to accommodate impl= ementations of the previous version of the draft that have already been dep= loyed. Those implementations do not send PATH-SETUP-TYPE-CAPABILITY in the= OPEN. Instead, they send PCEP-SR-CAPABILITY. Hence, to interoperate with= those versions, a new implementation can use the presence of PCEP-SR-CAPAB= ILITY to infer support of SR, rather than PATH-SETUP-TYPE-CAPABILITY. In o= ther words, this is for backwards compatibility. It is discussed explicitl= y in the new version of draft-ietf-pce-segment-routing. If you think the wording below can be improved for clarity, then please let= me know! Cheers Jon -----Original Message----- From: stephane.litkowski@orange.com [mailto:stephane.litkowski@orange.com]= =20 Sent: 20 November 2017 15:32 To: Jonathan Hardwick ; pce@ietf.org Cc: MEURIC Julien IMT/OLN Subject: RE: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt Hi Jon, Thanks for the update. One comment regarding this paragraph: "If the peer has sent no PATH-SETUP-TYPE-CAPABILITY TLV, then the PCEP speaker MUST infer that the peer supports path setup using at least RSVP-TE. The PCEP speaker MAY also infer that the peer supports other path setup types, but the means of inference are outside the scope of this document." Why not enforcing here ? I mean if a PCEP speaker uses a PST that was not a= dvertised in the capability TLV, the PST is rejected by a PCError. During the OPEN message, peers may agree on the PST to be used on the sessi= on based on the common subset. What's your opinion on that ? Brgds, Stephane -----Original Message----- From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com] Sent: Monday, November 20, 2017 16:07 To: pce@ietf.org Cc: MEURIC Julien IMT/OLN; LITKOWSKI Stephane OBS/OINIS Subject: FW: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt Dear PCE WG This new revision of the LSP setup type draft makes the following changes. 1) Added a capability TLV for the OPEN object and rules for processing it, = as discussed in the attached thread. This is to address Julien's WGLC comme= nt that there was no way for a PCEP speaker to express that it doesn't supp= ort RSVP-TE as a path setup type. 2) Made the path setup type explicit for anything other than RSVP-TE paths = (where absence of TLV implies RSVP-TE). This is to address Stephane's rece= nt comment to the list. 3) Updated the IANA / code point text to reflect that we have had an early = allocation. 4) Made some editorial fixes and clarifications. Best regards Jon -----Original Message----- From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.o= rg Sent: 20 November 2017 14:59 To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Path Computation Element WG of the IETF. Title : Conveying path setup type in PCEP messages Authors : Siva Sivabalan Jeff Tantsura Ina Minei Robert Varga Jon Hardwick Filename : draft-ietf-pce-lsp-setup-type-06.txt Pages : 10 Date : 2017-11-20 Abstract: A Path Computation Element can compute traffic engineering paths (TE paths) through a network that are subject to various constraints. Currently, TE paths are label switched paths (LSPs) which are set up using the RSVP-TE signaling protocol. However, other TE path setup methods are possible within the PCE architecture. This document proposes an extension to PCEP to allow support for different path setup methods over a given PCEP session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-setup-type/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-lsp-setup-type-06 https://datatracker.ietf.org/doc/html/draft-ietf-pce-lsp-setup-type-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-lsp-setup-type-06 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 ___________________________________________________________________________= ______________________________________________ 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute 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 Tue Nov 21 04:47: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 AE16512947B for ; Tue, 21 Nov 2017 04:47:33 -0800 (PST) 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, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3TWAOOt_hZG for ; Tue, 21 Nov 2017 04:47:31 -0800 (PST) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B8F31243F6 for ; Tue, 21 Nov 2017 04:47:31 -0800 (PST) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 4DAFA1010A2; Tue, 21 Nov 2017 13:47:29 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.62]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 2FE776006E; Tue, 21 Nov 2017 13:47:29 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM5E.corporate.adroot.infra.ftgroup ([fe80::2912:bfa5:91d3:bf63%18]) with mapi id 14.03.0361.001; Tue, 21 Nov 2017 13:47:26 +0100 From: To: Jonathan Hardwick , "pce@ietf.org" Thread-Topic: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt Thread-Index: AQHTYhAzQDMEDQvNYEKzuaLKEOqgaKMdTY2AgAAWz1CAAQwFAIAAWTgA Date: Tue, 21 Nov 2017 12:47:26 +0000 Message-ID: <4158_1511268449_5A142061_4158_76_1_94b4c6f1-f20b-42f3-9448-4b5c027753e3@OPEXCLILM5E.corporate.adroot.infra.ftgroup> References: <151118995097.21888.1120804081240463481@ietfa.amsl.com> <18833_1511191950_5A12F58E_18833_177_1_00ff1de7-767a-43b2-8c51-57fda127cb08@OPEXCLILM6F.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.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: Tue, 21 Nov 2017 12:47:33 -0000 Sounds reasonable. Thanks -----Original Message----- From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com]=20 Sent: Tuesday, November 21, 2017 09:28 To: LITKOWSKI Stephane OBS/OINIS; pce@ietf.org Cc: MEURIC Julien IMT/OLN Subject: RE: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt Hi Stephane Many thanks for the comment. This text is a compromise to accommodate impl= ementations of the previous version of the draft that have already been dep= loyed. Those implementations do not send PATH-SETUP-TYPE-CAPABILITY in the= OPEN. Instead, they send PCEP-SR-CAPABILITY. Hence, to interoperate with= those versions, a new implementation can use the presence of PCEP-SR-CAPAB= ILITY to infer support of SR, rather than PATH-SETUP-TYPE-CAPABILITY. In o= ther words, this is for backwards compatibility. It is discussed explicitl= y in the new version of draft-ietf-pce-segment-routing. If you think the wording below can be improved for clarity, then please let= me know! Cheers Jon -----Original Message----- From: stephane.litkowski@orange.com [mailto:stephane.litkowski@orange.com]= =20 Sent: 20 November 2017 15:32 To: Jonathan Hardwick ; pce@ietf.org Cc: MEURIC Julien IMT/OLN Subject: RE: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt Hi Jon, Thanks for the update. One comment regarding this paragraph: "If the peer has sent no PATH-SETUP-TYPE-CAPABILITY TLV, then the PCEP speaker MUST infer that the peer supports path setup using at least RSVP-TE. The PCEP speaker MAY also infer that the peer supports other path setup types, but the means of inference are outside the scope of this document." Why not enforcing here ? I mean if a PCEP speaker uses a PST that was not a= dvertised in the capability TLV, the PST is rejected by a PCError. During the OPEN message, peers may agree on the PST to be used on the sessi= on based on the common subset. What's your opinion on that ? Brgds, Stephane -----Original Message----- From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com] Sent: Monday, November 20, 2017 16:07 To: pce@ietf.org Cc: MEURIC Julien IMT/OLN; LITKOWSKI Stephane OBS/OINIS Subject: FW: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt Dear PCE WG This new revision of the LSP setup type draft makes the following changes. 1) Added a capability TLV for the OPEN object and rules for processing it, = as discussed in the attached thread. This is to address Julien's WGLC comme= nt that there was no way for a PCEP speaker to express that it doesn't supp= ort RSVP-TE as a path setup type. 2) Made the path setup type explicit for anything other than RSVP-TE paths = (where absence of TLV implies RSVP-TE). This is to address Stephane's rece= nt comment to the list. 3) Updated the IANA / code point text to reflect that we have had an early = allocation. 4) Made some editorial fixes and clarifications. Best regards Jon -----Original Message----- From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.o= rg Sent: 20 November 2017 14:59 To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Path Computation Element WG of the IETF. Title : Conveying path setup type in PCEP messages Authors : Siva Sivabalan Jeff Tantsura Ina Minei Robert Varga Jon Hardwick Filename : draft-ietf-pce-lsp-setup-type-06.txt Pages : 10 Date : 2017-11-20 Abstract: A Path Computation Element can compute traffic engineering paths (TE paths) through a network that are subject to various constraints. Currently, TE paths are label switched paths (LSPs) which are set up using the RSVP-TE signaling protocol. However, other TE path setup methods are possible within the PCE architecture. This document proposes an extension to PCEP to allow support for different path setup methods over a given PCEP session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-setup-type/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-lsp-setup-type-06 https://datatracker.ietf.org/doc/html/draft-ietf-pce-lsp-setup-type-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-lsp-setup-type-06 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 ___________________________________________________________________________= ______________________________________________ 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute 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. ___________________________________________________________________________= ______________________________________________ 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 Tue Nov 21 09:08: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 96AD9129AC6; Tue, 21 Nov 2017 09:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.215 X-Spam-Level: X-Spam-Status: No, score=0.215 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_BRBL_LASTEXT=1.449, 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 J8S7duYw3Yuv; Tue, 21 Nov 2017 09:08:22 -0800 (PST) Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [161.106.1.3]) by ietfa.amsl.com (Postfix) with ESMTP id 499E9129B2A; Tue, 21 Nov 2017 09:08:18 -0800 (PST) Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 69D09E300EE; Tue, 21 Nov 2017 18:08:17 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail2.rd.orange.com (Postfix) with ESMTP id 48C40E300EC; Tue, 21 Nov 2017 18:08:17 +0100 (CET) Received: from [10.193.71.63] (10.193.71.63) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.361.1; Tue, 21 Nov 2017 18:08:16 +0100 From: Julien Meuric Organization: Orange To: "draft-ietf-pce-lsp-setup-type@ietf.org" CC: "pce@ietf.org" Message-ID: <740c7253-ea67-be4a-c76c-1a010a265412@orange.com> Date: Tue, 21 Nov 2017 18:08:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Pce] Shepherd's Review of draft-ietf-pce-lsp-setup-type-06 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, 21 Nov 2017 17:08:24 -0000 Hi, Thank you for this new version of the I-D, it has greatly improved and clarifies former loose zones. Please find my review below. ------ Abstract --- - s/traffic engineering paths (TE paths)/Traffic Engineering paths (TE paths)/ - I wonder about the expansion of "TE path" above: why not "Engineered" instead of "Engineering"? (This is global to the I-D, and beyond... RFC Editor's list includes both.) - s/label switched paths (LSPs)/Label Switched Paths (LSPs)/ ------ Status --- - "https://" was introduced in -05, but has now disappeared. ------ 1. Introduction --- - s/Path Computation Element Protocol/Path Computation Element communication Protocol/ - OLD path setup type needs to be either explicitly indicated or implied in the appropriate PCEP messages (when necessary)...    NEW path setup type needs to be explicitly indicated in the appropriate PCEP messages, unless RSVP-TE type is meant (omission implying this type)... ------ 3. Path Setup Type Capability TLV --- - s/Initialization phase/initialization phase/ - I though the discussion on the list was about using a bitmap to identify supported PSTs: any reason why it is now a list of raw octets? - The definition of length and padding mixes the words "octet" and "bytes", depending on the field (probably to due to text coming from RFC 5440). Consistency would be welcome (the comment appears to be applicable beyond this section). ------ 4. Path Setup Type TLV --- - Figure 2 explicitly includes the codepoint for the "Type" (28), the "Length" field should be treated similarly (4). - The last sentence of section 4 puzzles me. If the PATH-SETUP-TYPE TLV is not supported, the PCEP peer cares little if it was "recognized" or not. If both sub-cases are commonly handled by ignoring, an implementation always including the RSVP-TE PST will be able to interwork with an implementation knowing about the TLV without actually supporting it; the current text turns this situation into an error. (Note also that RFC 5440 does not distinguish unrecognized and unsupported in TLV processing rules.) - In case my previous comment does not fly, 3 more nits:   * s/recognizes the TLV but does not support the TLV/recognizes the TLV but does not support its use/   * s/send PCErr/send a PCErr message/   * Error-Type is 2, would not 4 fit better? ------ 5. Operation --- - s/Initialization phase/initialization phase/ - s/MUST infer/MUST consider/  [explicit => nothing to infer] - The text says multiple times "unless the intended PST is RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV". This is inconsistent with section 4: "It is RECOMMENDED that a PCEP speaker omits the TLV if the PST is RSVP-TE." Please choose between MAY and SHOULD, and align. ------ Cheers, Julien From nobody Tue Nov 21 10:02: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 B16C3129584; Tue, 21 Nov 2017 10:02:22 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 (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 6zcx9NK3YCna; Tue, 21 Nov 2017 10:02:14 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0133.outbound.protection.outlook.com [104.47.32.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AEC9129AB3; Tue, 21 Nov 2017 10:02:13 -0800 (PST) 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=lNMQBylq7iNXPOiZWSmn6miDRy6LMtlm4oLOB9ituA8=; b=cUa7aZUrxus25jW6H7pyifWZ7R0yRcMazRuf6xC+R23lTnuW0ufpCIGmubDVCbgtR7uPyhc0lzn5Evqz/7fJDsSKrsjFRtmnBawh2mDb/kxQUYwmZcNnUWabAF2hloaVJJGdZ/TfkvtNI9U2sBuc3axd4pjl79qJJR7M3GLvcOs= Received: from CY4PR0201MB3603.namprd02.prod.outlook.com (52.132.99.21) by CY4PR0201MB3603.namprd02.prod.outlook.com (52.132.99.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Tue, 21 Nov 2017 18:02:12 +0000 Received: from CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::2475:224a:642f:a02b]) by CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::2475:224a:642f:a02b%13]) with mapi id 15.20.0239.009; Tue, 21 Nov 2017 18:02:12 +0000 From: Jonathan Hardwick To: Julien Meuric , "draft-ietf-pce-lsp-setup-type@ietf.org" CC: "pce@ietf.org" Thread-Topic: Shepherd's Review of draft-ietf-pce-lsp-setup-type-06 Thread-Index: AQHTYutXzF644dRcS0yM5muvXCABDqMfG3aQ Date: Tue, 21 Nov 2017 18:02:12 +0000 Message-ID: References: <740c7253-ea67-be4a-c76c-1a010a265412@orange.com> In-Reply-To: <740c7253-ea67-be4a-c76c-1a010a265412@orange.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-originating-ip: [86.132.73.252] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR0201MB3603; 6:aVfb0sjZymoBb0KdFm/yrgVAaJYL08QGfrChT8K8W/lCcoxL027KrF4gABF9WGgroCLZAq6KWCL9XmCUtJeA5mN6RPiIxHblB1q8GlEkobX7iaeySSv7g6ZnUBiW26wqHOIKhgE92p51qNHSNNJ441EFbXKzk4CU3xwf6P2y6vWiNl6jyIEs0QkWvEXreZ7g38W/4SmTk70GZHejoxwyypLSXyomn2JEHemf1at/vPbE13FIc1hhVCiDWSaTjPCJShPJsQ3vhTeQdhz1uRpnx6kKcBESYS/Zy/XH7dwvsDRzG2oGBSb8xuESvwH8dPqNGVWcGba8Vtj2b2oq4O1wNgqBe8e7CaV06pP5vwzxGQ0=; 5:2aObDVGH9FYJe5tfR5MHyAsBBGVhZSAqlRT72BArmOmrIEIZemvAbYHTrhNkeml4KAAI56wq2j5Y5xeTgSCT8HeBSl0oHHY8Cez3/fGO3mdYpC42i9jg+DMTXodo1yMuw0TrvvmYtnHeOSP7WGN+J2k/Y9wvTvLNmj/sGkAEUhw=; 24:gPlvgAAhK3HCRFxA5K5da6EU5knjlI7H6QGJLBvgLM27uwnnLqZ7VIsnYNqem4Lkt1IHj6HlGIceqp/HlsdvNTT13ctrY0WpqrjtG5RwNaw=; 7:zl3oHPLwQ5+FX5+rC75AqWXrFd6hlFHlQKRjAd9J+FouODvfAp3a/0abGCtNqDY1gDiag1qRGHSCq6WHy57o6+A++bMTDr13cTWAb7jmWKhDppkSxy6dBRl3eDEJ1u7nF8Hz82qGBSgNRRFXWhDIvy5UK77a3Pxc2nORU8N4PAZPqVJ+RUoNbix5LwHEghounHax+i3/LLsQ4Lf66Rtdrv+E0CbKjKD6DQDVWBu6AmQdU7ERSbxMRCUXGNe74Dk+ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 12875289-8098-4141-cf76-08d53109fdd4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:CY4PR0201MB3603; x-ms-traffictypediagnostic: CY4PR0201MB3603: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(3231022)(3002001)(93006095)(93001095)(6041248)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR0201MB3603; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR0201MB3603; x-forefront-prvs: 049897979A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(37854004)(13464003)(51914003)(199003)(76104003)(189002)(3660700001)(2501003)(8936002)(6506006)(97736004)(3280700002)(3846002)(102836003)(6116002)(229853002)(6436002)(7736002)(72206003)(86362001)(6246003)(74316002)(66066001)(2950100002)(305945005)(478600001)(2900100001)(101416001)(230783001)(110136005)(7696004)(9686003)(106356001)(5660300001)(6306002)(33656002)(345774005)(25786009)(189998001)(4326008)(68736007)(2906002)(53546010)(105586002)(81156014)(53936002)(8676002)(14454004)(50986999)(76176999)(99286004)(316002)(55016002)(54356999)(81166006)(5250100002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR0201MB3603; H:CY4PR0201MB3603.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) 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-Network-Message-Id: 12875289-8098-4141-cf76-08d53109fdd4 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Nov 2017 18:02:12.5061 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0201MB3603 Archived-At: Subject: Re: [Pce] Shepherd's Review of draft-ietf-pce-lsp-setup-type-06 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, 21 Nov 2017 18:02:23 -0000 SGkgSnVsaWVuDQoNCk1hbnkgdGhhbmtzIGZvciB0aGUgc3BlZWR5IHJldmlldyEgIFBsZWFzZSBz ZWUgYSBmZXcgYW5zd2VycyBiZWxvdywgbWFya2VkIHdpdGggW0pvbl0uICAoQWxsIG90aGVyIGNv bW1lbnRzIGFyZSBhY2NlcHRlZC4pDQpJIHdpbGwgaG9sZCB0aGUgZG9jdW1lbnQgbWFyay11cHMg dW50aWwgV0dMQyBlbmRzLg0KDQpDaGVlcnMNCkpvbg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBKdWxpZW4gTWV1cmljIFttYWlsdG86anVsaWVuLm1ldXJpY0BvcmFuZ2Uu Y29tXSANClNlbnQ6IDIxIE5vdmVtYmVyIDIwMTcgMTc6MDgNClRvOiBkcmFmdC1pZXRmLXBjZS1s c3Atc2V0dXAtdHlwZUBpZXRmLm9yZw0KQ2M6IHBjZUBpZXRmLm9yZw0KU3ViamVjdDogU2hlcGhl cmQncyBSZXZpZXcgb2YgZHJhZnQtaWV0Zi1wY2UtbHNwLXNldHVwLXR5cGUtMDYNCg0KSGksDQoN ClRoYW5rIHlvdSBmb3IgdGhpcyBuZXcgdmVyc2lvbiBvZiB0aGUgSS1ELCBpdCBoYXMgZ3JlYXRs eSBpbXByb3ZlZCBhbmQgY2xhcmlmaWVzIGZvcm1lciBsb29zZSB6b25lcy4gUGxlYXNlIGZpbmQg bXkgcmV2aWV3IGJlbG93Lg0KDQotLS0tLS0NCkFic3RyYWN0DQotLS0NCi0gcy90cmFmZmljIGVu Z2luZWVyaW5nIHBhdGhzIChURSBwYXRocykvVHJhZmZpYyBFbmdpbmVlcmluZyBwYXRocyAoVEUg cGF0aHMpLw0KLSBJIHdvbmRlciBhYm91dCB0aGUgZXhwYW5zaW9uIG9mICJURSBwYXRoIiBhYm92 ZTogd2h5IG5vdCAiRW5naW5lZXJlZCINCmluc3RlYWQgb2YgIkVuZ2luZWVyaW5nIj8gKFRoaXMg aXMgZ2xvYmFsIHRvIHRoZSBJLUQsIGFuZCBiZXlvbmQuLi4gUkZDIEVkaXRvcidzIGxpc3QgaW5j bHVkZXMgYm90aC4pDQotIHMvbGFiZWwgc3dpdGNoZWQgcGF0aHMgKExTUHMpL0xhYmVsIFN3aXRj aGVkIFBhdGhzIChMU1BzKS8NCi0tLS0tLQ0KU3RhdHVzDQotLS0NCi0gImh0dHBzOi8vIiB3YXMg aW50cm9kdWNlZCBpbiAtMDUsIGJ1dCBoYXMgbm93IGRpc2FwcGVhcmVkLg0KLS0tLS0tDQoxLiBJ bnRyb2R1Y3Rpb24NCi0tLQ0KLSBzL1BhdGggQ29tcHV0YXRpb24gRWxlbWVudCBQcm90b2NvbC9Q YXRoIENvbXB1dGF0aW9uIEVsZW1lbnQgY29tbXVuaWNhdGlvbiBQcm90b2NvbC8NCg0KLSBPTEQN CnBhdGggc2V0dXAgdHlwZSBuZWVkcyB0byBiZSBlaXRoZXIgZXhwbGljaXRseSBpbmRpY2F0ZWQg b3IgaW1wbGllZCBpbiB0aGUgYXBwcm9wcmlhdGUgUENFUCBtZXNzYWdlcyAod2hlbiBuZWNlc3Nh cnkpLi4uDQrCoMKgIE5FVw0KcGF0aCBzZXR1cCB0eXBlIG5lZWRzIHRvIGJlIGV4cGxpY2l0bHkg aW5kaWNhdGVkIGluIHRoZSBhcHByb3ByaWF0ZSBQQ0VQIG1lc3NhZ2VzLCB1bmxlc3MgUlNWUC1U RSB0eXBlIGlzIG1lYW50IChvbWlzc2lvbiBpbXBseWluZyB0aGlzIHR5cGUpLi4uDQotLS0tLS0N CjMuIFBhdGggU2V0dXAgVHlwZSBDYXBhYmlsaXR5IFRMVg0KLS0tDQotIHMvSW5pdGlhbGl6YXRp b24gcGhhc2UvaW5pdGlhbGl6YXRpb24gcGhhc2UvDQotIEkgdGhvdWdoIHRoZSBkaXNjdXNzaW9u IG9uIHRoZSBsaXN0IHdhcyBhYm91dCB1c2luZyBhIGJpdG1hcCB0byBpZGVudGlmeSBzdXBwb3J0 ZWQgUFNUczogYW55IHJlYXNvbiB3aHkgaXQgaXMgbm93IGEgbGlzdCBvZiByYXcgb2N0ZXRzPw0K DQpbSm9uXSBXZSBkaWQgZGlzY3VzcyBhIGJpdCBmaWVsZCBvbiB0aGUgbGlzdC4gIFRoZSBQU1Qg ZmllbGQgaXMgYW4gOC1iaXQgdmFsdWUsIHNvIGEgbmFpdmUgaW1wbGVtZW50YXRpb24gb2YgYSBi aXQgZmllbGQgd291bGQgdXNlIDMyIGJ5dGVzLiAgVGhpcyBzZWVtcyB3YXN0ZWZ1bCBnaXZlbiB3 ZSBvbmx5IGhhdmUgdHdvIHZhbHVlcyBkZWZpbmVkIHNvIGZhciAocG9zc2libHkgMyB3aXRoIHRo ZSB1cC1jb21pbmcgSVB2Ni1TUiBkcmFmdCkuICBJIHRoZW4gbG9va2VkIGF0IHNvbWUgc2NoZW1l cyB0byBzaG9ydGVuIHRoZSBiaXQgZmllbGQsIGUuZy4gYnkgdHJ1bmNhdGluZyBpdCwgYnV0IHRo ZSByZXN1bHQgc2VlbWVkIG1vcmUgY29tcGxpY2F0ZWQgdG8gZW5jb2RlIHRoYW4ganVzdCBsaXN0 aW5nIHRoZSBwYXRoIHNldHVwIHR5cGVzLiAgKEkgYWxzbyBkaWRuJ3QgbXVjaCBsaWtlIGhhdmlu ZyBhIFBTVCBrbm93biBib3RoIGJ5IGEgdmFsdWUgYW5kIGJ5IGEgYml0IGZpZWxkIHBvc2l0aW9u LikgIFNvIEkgb3B0ZWQgdG8gbGlzdCB0aGUgUFNUcy4gIElNTyBpdCdzIG5vdCBhIHByb2JsZW0g Z2l2ZW4gdGhlIGxvdyBudW1iZXIgb2YgUFNUcyB3ZSBleHBlY3QgKGNvdWxkIGJlIGEgY2FzZSBv ZiBmYW1vdXMgbGFzdCB3b3JkcyEpICBXaGF0IGRvIHlvdSB0aGluayBvZiB0aGlzIHRyYWRlb2Zm Pw0KDQoNCi0gVGhlIGRlZmluaXRpb24gb2YgbGVuZ3RoIGFuZCBwYWRkaW5nIG1peGVzIHRoZSB3 b3JkcyAib2N0ZXQiIGFuZCAiYnl0ZXMiLCBkZXBlbmRpbmcgb24gdGhlIGZpZWxkIChwcm9iYWJs eSB0byBkdWUgdG8gdGV4dCBjb21pbmcgZnJvbSBSRkMgNTQ0MCkuIENvbnNpc3RlbmN5IHdvdWxk IGJlIHdlbGNvbWUgKHRoZSBjb21tZW50IGFwcGVhcnMgdG8gYmUgYXBwbGljYWJsZSBiZXlvbmQg dGhpcyBzZWN0aW9uKS4NCg0KW0pvbl0gTGV0J3Mgc3RhbmRhcmRpemUgb24gYnl0ZXMsIHBlciBS RkMgNTQ0MC4NCg0KDQoNCi0tLS0tLQ0KNC4gUGF0aCBTZXR1cCBUeXBlIFRMVg0KLS0tDQotIEZp Z3VyZSAyIGV4cGxpY2l0bHkgaW5jbHVkZXMgdGhlIGNvZGVwb2ludCBmb3IgdGhlICJUeXBlIiAo MjgpLCB0aGUgIkxlbmd0aCIgZmllbGQgc2hvdWxkIGJlIHRyZWF0ZWQgc2ltaWxhcmx5ICg0KS4N Ci0gVGhlIGxhc3Qgc2VudGVuY2Ugb2Ygc2VjdGlvbiA0IHB1enpsZXMgbWUuIElmIHRoZSBQQVRI LVNFVFVQLVRZUEUgVExWIGlzIG5vdCBzdXBwb3J0ZWQsIHRoZSBQQ0VQIHBlZXIgY2FyZXMgbGl0 dGxlIGlmIGl0IHdhcyAicmVjb2duaXplZCIgb3Igbm90LiBJZiBib3RoIHN1Yi1jYXNlcyBhcmUg Y29tbW9ubHkgaGFuZGxlZCBieSBpZ25vcmluZywgYW4gaW1wbGVtZW50YXRpb24gYWx3YXlzIGlu Y2x1ZGluZyB0aGUgUlNWUC1URSBQU1Qgd2lsbCBiZSBhYmxlIHRvIGludGVyd29yayB3aXRoIGFu IGltcGxlbWVudGF0aW9uIGtub3dpbmcgYWJvdXQgdGhlIFRMViB3aXRob3V0IGFjdHVhbGx5IHN1 cHBvcnRpbmcgaXQ7IHRoZSBjdXJyZW50IHRleHQgdHVybnMgdGhpcyBzaXR1YXRpb24gaW50byBh biBlcnJvci4NCihOb3RlIGFsc28gdGhhdCBSRkMgNTQ0MCBkb2VzIG5vdCBkaXN0aW5ndWlzaCB1 bnJlY29nbml6ZWQgYW5kIHVuc3VwcG9ydGVkIGluIFRMViBwcm9jZXNzaW5nIHJ1bGVzLikNCg0K W0pvbl0gSSB0aGluayB5b3UgYXJlIHJpZ2h0LiBUaGUgc2FtZSBhbHNvIGFwcGxpZXMgdG8gdGhl IGZpbmFsIHNlbnRlbmNlIG9mIHNlY3Rpb24gMywgSSBiZWxpZXZlLg0KDQoNCi0gSW4gY2FzZSBt eSBwcmV2aW91cyBjb21tZW50IGRvZXMgbm90IGZseSwgMyBtb3JlIG5pdHM6DQrCoCAqIHMvcmVj b2duaXplcyB0aGUgVExWIGJ1dCBkb2VzIG5vdCBzdXBwb3J0IHRoZSBUTFYvcmVjb2duaXplcyB0 aGUgVExWIGJ1dCBkb2VzIG5vdCBzdXBwb3J0IGl0cyB1c2UvDQrCoCAqIHMvc2VuZCBQQ0Vyci9z ZW5kIGEgUENFcnIgbWVzc2FnZS8NCsKgICogRXJyb3ItVHlwZSBpcyAyLCB3b3VsZCBub3QgNCBm aXQgYmV0dGVyPw0KLS0tLS0tDQo1LiBPcGVyYXRpb24NCi0tLQ0KLSBzL0luaXRpYWxpemF0aW9u IHBoYXNlL2luaXRpYWxpemF0aW9uIHBoYXNlLw0KLSBzL01VU1QgaW5mZXIvTVVTVCBjb25zaWRl ci/CoCBbZXhwbGljaXQgPT4gbm90aGluZyB0byBpbmZlcl0NCi0gVGhlIHRleHQgc2F5cyBtdWx0 aXBsZSB0aW1lcyAidW5sZXNzIHRoZSBpbnRlbmRlZCBQU1QgaXMgUlNWUC1URSwgaW4gd2hpY2gg Y2FzZSBpdCBNQVkgb21pdCB0aGUgUEFUSC1TRVRVUC1UWVBFIFRMViIuIFRoaXMgaXMgaW5jb25z aXN0ZW50IHdpdGggc2VjdGlvbiA0OiAiSXQgaXMgUkVDT01NRU5ERUQgdGhhdCBhIFBDRVAgc3Bl YWtlciBvbWl0cyB0aGUgVExWIGlmIHRoZSBQU1QgaXMgUlNWUC1URS4iIFBsZWFzZSBjaG9vc2Ug YmV0d2VlbiBNQVkgYW5kIFNIT1VMRCwgYW5kIGFsaWduLg0KDQpbSm9uXSBJIHRoaW5rIG91ciBp bnRlbnQgaXMgTUFZLCBzbyB3ZSBjYW4gcmV3b3JkIHRoZSB0ZXh0IGluIHNlY3Rpb24gNCB0byAi QSBQQ0VQIHNwZWFrZXIgTUFZIG9taXQgdGhlIFRMViBpZiB0aGUgUFNUIGlzIFJTVlAtVEUuIg0K DQoNCg0KLS0tLS0tDQoNCkNoZWVycywNCg0KSnVsaWVuDQoNCg== From nobody Thu Nov 23 06:05: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 BFFE4128DF6; Thu, 23 Nov 2017 06:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 XLB2sCwSqHKA; Thu, 23 Nov 2017 06:05:15 -0800 (PST) Received: from r-mail2.rd.orange.com (r-mail2.rd.orange.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 63C851292AE; Thu, 23 Nov 2017 06:05:14 -0800 (PST) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 070885D8A5C; Thu, 23 Nov 2017 15:05:13 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail2.rd.orange.com (Postfix) with ESMTP id E591A5D8A4C; Thu, 23 Nov 2017 15:05:12 +0100 (CET) Received: from [10.193.71.63] (10.193.71.63) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.361.1; Thu, 23 Nov 2017 15:05:12 +0100 From: Julien Meuric To: Jonathan Hardwick , "draft-ietf-pce-lsp-setup-type@ietf.org" CC: "pce@ietf.org" References: <740c7253-ea67-be4a-c76c-1a010a265412@orange.com> Organization: Orange Message-ID: <4e12a009-c0c8-03a5-9dbe-077c2ce1088e@orange.com> Date: Thu, 23 Nov 2017 15:05:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Pce] Shepherd's Review of draft-ietf-pce-lsp-setup-type-06 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, 23 Nov 2017 14:05:17 -0000 Hi Jon, You are welcome. All open issues are about to get closed. Please see [JM] below. Thanks, Julien Nov. 21, 2017 - Jonathan.Hardwick@metaswitch.com: > Hi Julien > > Many thanks for the speedy review! Please see a few answers below, marked with [Jon]. (All other comments are accepted.) > I will hold the document mark-ups until WGLC ends. > > Cheers > Jon > > > -----Original Message----- > From: Julien Meuric [mailto:julien.meuric@orange.com] > Sent: 21 November 2017 17:08 > > Hi, > > Thank you for this new version of the I-D, it has greatly improved and clarifies former loose zones. Please find my review below. > > ------ > Abstract > --- > - s/traffic engineering paths (TE paths)/Traffic Engineering paths (TE paths)/ > - I wonder about the expansion of "TE path" above: why not "Engineered" > instead of "Engineering"? (This is global to the I-D, and beyond... RFC Editor's list includes both.) > - s/label switched paths (LSPs)/Label Switched Paths (LSPs)/ > ------ > Status > --- > - "https://" was introduced in -05, but has now disappeared. > ------ > 1. Introduction > --- > - s/Path Computation Element Protocol/Path Computation Element communication Protocol/ > > - OLD > path setup type needs to be either explicitly indicated or implied in the appropriate PCEP messages (when necessary)... >    NEW > path setup type needs to be explicitly indicated in the appropriate PCEP messages, unless RSVP-TE type is meant (omission implying this type)... > ------ > 3. Path Setup Type Capability TLV > --- > - s/Initialization phase/initialization phase/ > - I though the discussion on the list was about using a bitmap to identify supported PSTs: any reason why it is now a list of raw octets? > > [Jon] We did discuss a bit field on the list. The PST field is an 8-bit value, so a naive implementation of a bit field would use 32 bytes. This seems wasteful given we only have two values defined so far (possibly 3 with the up-coming IPv6-SR draft). I then looked at some schemes to shorten the bit field, e.g. by truncating it, but the result seemed more complicated to encode than just listing the path setup types. (I also didn't much like having a PST known both by a value and by a bit field position.) So I opted to list the PSTs. IMO it's not a problem given the low number of PSTs we expect (could be a case of famous last words!) What do you think of this tradeoff? [JM] I do not have any strong opinion on this. If noone objects, it is reasonable to go that way from where we stand. Have you considered a more explicit figure, e.g. the following? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PST#1 | PST#2 | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // (variable size) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > - The definition of length and padding mixes the words "octet" and "bytes", depending on the field (probably to due to text coming from RFC 5440). Consistency would be welcome (the comment appears to be applicable beyond this section). > > [Jon] Let's standardize on bytes, per RFC 5440. [JM] OK > > ------ > 4. Path Setup Type TLV > --- > - Figure 2 explicitly includes the codepoint for the "Type" (28), the "Length" field should be treated similarly (4). > - The last sentence of section 4 puzzles me. If the PATH-SETUP-TYPE TLV is not supported, the PCEP peer cares little if it was "recognized" or not. If both sub-cases are commonly handled by ignoring, an implementation always including the RSVP-TE PST will be able to interwork with an implementation knowing about the TLV without actually supporting it; the current text turns this situation into an error. > (Note also that RFC 5440 does not distinguish unrecognized and unsupported in TLV processing rules.) > > [Jon] I think you are right. The same also applies to the final sentence of section 3, I believe. [JM] I agree. Good catch! > > > - In case my previous comment does not fly, 3 more nits: >   * s/recognizes the TLV but does not support the TLV/recognizes the TLV but does not support its use/ >   * s/send PCErr/send a PCErr message/ >   * Error-Type is 2, would not 4 fit better? > ------ > 5. Operation > --- > - s/Initialization phase/initialization phase/ > - s/MUST infer/MUST consider/  [explicit => nothing to infer] > - The text says multiple times "unless the intended PST is RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV". This is inconsistent with section 4: "It is RECOMMENDED that a PCEP speaker omits the TLV if the PST is RSVP-TE." Please choose between MAY and SHOULD, and align. > > [Jon] I think our intent is MAY, so we can reword the text in section 4 to "A PCEP speaker MAY omit the TLV if the PST is RSVP-TE." [JM] OK > > ------ > > Cheers, > > Julien > From nobody Mon Nov 27 21:18:57 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 EE9041201F8; Mon, 27 Nov 2017 21:18:54 -0800 (PST) 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.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151184633494.13319.16191989603382587840@ietfa.amsl.com> Date: Mon, 27 Nov 2017 21:18:54 -0800 Archived-At: Subject: [Pce] I-D Action: draft-ietf-pce-pcep-exp-codepoints-04.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: Tue, 28 Nov 2017 05:18:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : Experimental Codepoint Allocation for the Path Computation Element communication Protocol (PCEP) Authors : Dhruv Dhody Daniel King Adrian Farrel Filename : draft-ietf-pce-pcep-exp-codepoints-04.txt Pages : 7 Date : 2017-11-27 Abstract: IANA assigns values to the Path Computation Element (PCE) communication Protocol (PCEP) parameters (messages, objects, TLVs). IANA established a top-level registry to contain all PCEP codepoints and sub-registries. This top-level registry contains sub-registries for PCEP message, object and TLV types. The allocation policy for each of these sub-registries is IETF Review. This document updates RFC 5440 by changing the allocation policies for these three registries to mark some of the code points as assigned for Experimental Use. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-exp-codepoints/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-pcep-exp-codepoints-04 https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-exp-codepoints-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-exp-codepoints-04 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 Mon Nov 27 21:24: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 E506A127866; Mon, 27 Nov 2017 21:24:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhAj6p26csvs; Mon, 27 Nov 2017 21:24:00 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 48F90126B7F; Mon, 27 Nov 2017 21:24:00 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id a19so42250054qtb.3; Mon, 27 Nov 2017 21:24:00 -0800 (PST) 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=peIvpMtqrFzZ+VUrNjY1HbYl+rnWTvnm9Hg21AHw8pA=; b=mDfYne61ZlkYKQDGWlDm8F3vbAswlB+pMikkwITWrXt/IsIXvnqDNoxLspSB6OJoyq F9gi/z8G6MdIW349pt8c16cRAQL9fJrXf/Q32ysCU1WzcyizONUKTkR5F83DcELTPa+F tqtvj70oufx9pb+NTFmGqYnMEq3Urrvb02FHIcLiMM19bkHeiaK+sE7TSpKhXx8UF8gB uKaFIzUMZ51oTT6Tous0ikPi4pN1qBKwEXjqgRmk2aQe5VrII5pzeKHcsnPNJijLPAgd 4I30k3AjjI45Pu6facaQliQGLmrt1o1dZlVDO5qWfKQWpgrgbv4W6Pwlil1u6h1mdl2x sxQg== 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=peIvpMtqrFzZ+VUrNjY1HbYl+rnWTvnm9Hg21AHw8pA=; b=hv4IXmtvCxMSTaesPk4hYJ82HgyFDray6gKZsEPIHiyAQJKNux6i6++ytjw5NzoD8H 3Bfr3k2txkA3mHbzDMf4ndsYrA/tQx8Alq/R4CFYaGzM6F1pUrsDxQck19ipE8/ZWoMi +oyA8ljfPC5+nfLoM1OyVKCw8UEoJQW93tW8XLB3Jn+XrSrVsH/Zwsd4wiU7FfXYtcy3 PkON7EatWzOp7ovx0zcMBlLeh9NhXt7SqoQM8YStIWdkhpLOmFBFR7FKpopXd3cvM4G+ X4W+gspY3zJKS0mxb11Bmlg1K7b8bvUZa4RiL7Z/Cs2GNJcZnaUGYuhNTAR1Fdzw5psG XKWg== X-Gm-Message-State: AJaThX6pHvGA491lK9o5Sq01WNuvtTegw3xJTrshtjBvoT79CMLElOOs mtd8PBrsg9EJhTtEUVoFXKROlzvCSJCxaGaxw9ArAA== X-Google-Smtp-Source: AGs4zMbeMB4U1BH7cMr/ppbWEeYFrPsPeQeaWf97GJPej2eYiCoLjCTs4Bw4FzM6IAfnbyyWV0XZNsbNnRYdRKhdN88= X-Received: by 10.200.36.180 with SMTP id s49mr63909940qts.161.1511846639233; Mon, 27 Nov 2017 21:23:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.17.97 with HTTP; Mon, 27 Nov 2017 21:23:58 -0800 (PST) In-Reply-To: <151184633494.13319.16191989603382587840@ietfa.amsl.com> References: <151184633494.13319.16191989603382587840@ietfa.amsl.com> From: Dhruv Dhody Date: Tue, 28 Nov 2017 10:53:58 +0530 Message-ID: To: "pce@ietf.org" Cc: pce-chairs@ietf.org Content-Type: multipart/alternative; boundary="001a114101b0e2f137055f04398b" Archived-At: Subject: Re: [Pce] I-D Action: draft-ietf-pce-pcep-exp-codepoints-04.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: Tue, 28 Nov 2017 05:24:03 -0000 --001a114101b0e2f137055f04398b Content-Type: text/plain; charset="UTF-8" Hi WG, Just a small editing change made in the section describing unknown experimental objects after discussion with chairs. See https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-exp-codepoints-04 Thanks! Dhruv On Tue, Nov 28, 2017 at 10:48 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Path Computation Element WG of the IETF. > > Title : Experimental Codepoint Allocation for the Path > Computation Element communication Protocol (PCEP) > Authors : Dhruv Dhody > Daniel King > Adrian Farrel > Filename : draft-ietf-pce-pcep-exp-codepoints-04.txt > Pages : 7 > Date : 2017-11-27 > > Abstract: > IANA assigns values to the Path Computation Element (PCE) > communication Protocol (PCEP) parameters (messages, objects, TLVs). > IANA established a top-level registry to contain all PCEP codepoints > and sub-registries. This top-level registry contains sub-registries > for PCEP message, object and TLV types. The allocation policy for > each of these sub-registries is IETF Review. > > This document updates RFC 5440 by changing the allocation policies > for these three registries to mark some of the code points as > assigned for Experimental Use. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-exp-codepoints/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-pce-pcep-exp-codepoints-04 > https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep- > exp-codepoints-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-exp-codepoints-04 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > --001a114101b0e2f137055f04398b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi WG,=C2=A0

Just a sm= all editing change made in the section describing unknown experimental obje= cts after discussion with chairs.=C2=A0
See=C2=A0https://www= .ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-pcep-exp-codepoints-04

Th= anks!=C2=A0
Dhruv

On Tue, Nov 28, 2017 at 10= :48 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Path Computation Element WG of the IETF.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Experimental Codepoint Allocation for the Path Computation Element communi= cation Protocol (PCEP)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Dhru= v Dhody
=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 Daniel King
=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 Adrian Farrel
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-pce-pcep-exp-codepoints-04.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 7
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-11-27

Abstract:
=C2=A0 =C2=A0IANA assigns values to the Path Computation Element (PCE)
=C2=A0 =C2=A0communication Protocol (PCEP) parameters (messages, objects, T= LVs).
=C2=A0 =C2=A0IANA established a top-level registry to contain all PCEP code= points
=C2=A0 =C2=A0and sub-registries.=C2=A0 This top-level registry contains sub= -registries
=C2=A0 =C2=A0for PCEP message, object and TLV types.=C2=A0 The allocation p= olicy for
=C2=A0 =C2=A0each of these sub-registries is IETF Review.

=C2=A0 =C2=A0This document updates RFC 5440 by changing the allocation poli= cies
=C2=A0 =C2=A0for these three registries to mark some of the code points as<= br> =C2=A0 =C2=A0assigned for Experimental Use.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/dr= aft-ietf-pce-pcep-exp-codepoints-04
https://datatracker.ietf.= org/doc/html/draft-ietf-pce-pcep-exp-codepoints-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdif= f?url2=3Ddraft-ietf-pce-pcep-exp-codepoints-04


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

--001a114101b0e2f137055f04398b-- From nobody Tue Nov 28 03:10:29 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 2D9BE127369; Tue, 28 Nov 2017 03:10:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Niven-Jenkins To: Cc: pce@ietf.org, draft-ietf-pce-pcep-exp-codepoints.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151186742816.13409.4274999012117883106@ietfa.amsl.com> Date: Tue, 28 Nov 2017 03:10:28 -0800 Archived-At: Subject: [Pce] Rtgdir last call review of draft-ietf-pce-pcep-exp-codepoints-04 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, 28 Nov 2017 11:10:28 -0000 Reviewer: Ben Niven-Jenkins Review result: Ready RtgDir review: draft-ietf-pce-pcep-exp-codepoints-04 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-pcep-exp-codepoints-04 Reviewer: Ben Niven-Jenkins Review Date: 28th November 2017 IETF LC End Date: Not known Intended Status: Proposed Standard Summary: No issues found. This document is ready for publication. Comments: The document is well written and readable with clear guidance to IANA. Major Issues: No major issues found. Minor Issues: No minor issues found. Regards Ben From nobody Tue Nov 28 03:12: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 5466D126BF0; Tue, 28 Nov 2017 03:12:13 -0800 (PST) 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, 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 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 88WJhJZ5OgZs; Tue, 28 Nov 2017 03:12:11 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 B8BE81200F3; Tue, 28 Nov 2017 03:12:11 -0800 (PST) Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 17CA8EDB53E4E; Tue, 28 Nov 2017 11:12:08 +0000 (GMT) Received: from BLREML408-HUB.china.huawei.com (10.20.4.47) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 28 Nov 2017 11:12:09 +0000 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.219]) by BLREML408-HUB.china.huawei.com ([10.20.4.47]) with mapi id 14.03.0361.001; Tue, 28 Nov 2017 16:41:56 +0530 From: Dhruv Dhody To: Ben Niven-Jenkins , "rtg-dir@ietf.org" CC: "pce@ietf.org" , "draft-ietf-pce-pcep-exp-codepoints.all@ietf.org" Thread-Topic: [Pce] Rtgdir last call review of draft-ietf-pce-pcep-exp-codepoints-04 Thread-Index: AQHTaDmPNCdRCbcL3EqacLHp06r5saMpoi1A Date: Tue, 28 Nov 2017 11:11:55 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8D5E5874@BLREML503-MBX.china.huawei.com> References: <151186742816.13409.4274999012117883106@ietfa.amsl.com> In-Reply-To: <151186742816.13409.4274999012117883106@ietfa.amsl.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.149.39] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pce] Rtgdir last call review of draft-ietf-pce-pcep-exp-codepoints-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, 28 Nov 2017 11:12:13 -0000 VGhhbmtzIEJlbiBmb3IgeW91ciByZXZpZXchIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IFBjZSBbbWFpbHRvOnBjZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgQmVuIE5pdmVuLUplbmtpbnMNCj4gU2VudDogMjggTm92ZW1iZXIgMjAxNyAxNjo0MA0KPiBU bzogcnRnLWRpckBpZXRmLm9yZw0KPiBDYzogcGNlQGlldGYub3JnOyBkcmFmdC1pZXRmLXBjZS1w Y2VwLWV4cC1jb2RlcG9pbnRzLmFsbEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBbUGNlXSBSdGdkaXIg bGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLXBjZS1wY2VwLWV4cC0NCj4gY29kZXBvaW50 cy0wNA0KPiANCj4gUmV2aWV3ZXI6IEJlbiBOaXZlbi1KZW5raW5zDQo+IFJldmlldyByZXN1bHQ6 IFJlYWR5DQo+IA0KPiBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLXBjZS1wY2VwLWV4cC1jb2Rl cG9pbnRzLTA0DQo+IA0KPiBIZWxsbywNCj4gDQo+IEkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRo ZSBSb3V0aW5nIERpcmVjdG9yYXRlIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0Lg0KPiBUaGUgUm91 dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1y ZWxhdGVkDQo+IGRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQg SUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMNCj4gb24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVy cG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0bw0KPiB0aGUgUm91 dGluZyBBRHMuDQo+IEZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVj dG9yYXRlLCBwbGVhc2Ugc2VlIA0KPiBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0 Zy90cmFjL3dpa2kvUnRnRGlyDQo+IA0KPiBBbHRob3VnaCB0aGVzZSBjb21tZW50cyBhcmUgcHJp bWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQNCj4gd291bGQgYmUgaGVs cGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhlciBJRVRG IExhc3QNCj4gQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZlIHRvIHJl c29sdmUgdGhlbSB0aHJvdWdoDQo+IGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhlIGRyYWZ0 Lg0KPiANCj4gRG9jdW1lbnQ6IGRyYWZ0LWlldGYtcGNlLXBjZXAtZXhwLWNvZGVwb2ludHMtMDQN Cj4gUmV2aWV3ZXI6IEJlbiBOaXZlbi1KZW5raW5zDQo+IFJldmlldyBEYXRlOiAyOHRoIE5vdmVt YmVyIDIwMTcNCj4gSUVURiBMQyBFbmQgRGF0ZTogTm90IGtub3duDQo+IEludGVuZGVkIFN0YXR1 czogUHJvcG9zZWQgU3RhbmRhcmQNCj4gDQo+IFN1bW1hcnk6IE5vIGlzc3VlcyBmb3VuZC4gVGhp cyBkb2N1bWVudCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24uDQo+IA0KPiBDb21tZW50czogVGhl IGRvY3VtZW50IGlzIHdlbGwgd3JpdHRlbiBhbmQgcmVhZGFibGUgd2l0aCBjbGVhciBndWlkYW5j ZSB0bw0KPiBJQU5BLg0KPiANCj4gTWFqb3IgSXNzdWVzOiBObyBtYWpvciBpc3N1ZXMgZm91bmQu DQo+IA0KPiBNaW5vciBJc3N1ZXM6IE5vIG1pbm9yIGlzc3VlcyBmb3VuZC4NCj4gDQo+IFJlZ2Fy ZHMNCj4gQmVuDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBQY2UgbWFpbGluZyBsaXN0DQo+IFBjZUBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjZQ0K From nobody Thu Nov 30 04:15: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 57A3A129461 for ; Thu, 30 Nov 2017 04:15:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcdPMZUyfkXm for ; Thu, 30 Nov 2017 04:15:28 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C601F1293E9 for ; Thu, 30 Nov 2017 04:15:28 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 0F02BB80ED9; Thu, 30 Nov 2017 04:15:15 -0800 (PST) To: jeanlouis.leroux@francetelecom.com, akatlas@gmail.com, db3546@att.com, aretana.ietf@gmail.com, jonathan.hardwick@metaswitch.com, julien.meuric@orange.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: Amitkumar@explo.com, pce@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20171130121516.0F02BB80ED9@rfc-editor.org> Date: Thu, 30 Nov 2017 04:15:15 -0800 (PST) Archived-At: Subject: [Pce] [Technical Errata Reported] RFC4674 (5192) 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, 30 Nov 2017 12:15:31 -0000 The following errata report has been submitted for RFC4674, "Requirements for Path Computation Element (PCE) Discovery". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5192 -------------------------------------- Type: Technical Reported by: Amitkumar Section: 463846379684 Original Text ------------- Ok Corrected Text -------------- Ok Notes ----- Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4674 (draft-ietf-pce-discovery-reqs-05) -------------------------------------- Title : Requirements for Path Computation Element (PCE) Discovery Publication Date : October 2006 Author(s) : J.L. Le Roux, Ed. Category : INFORMATIONAL Source : Path Computation Element Area : Routing Stream : IETF Verifying Party : IESG From nobody Thu Nov 30 04:51: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 A0F7D1292F4 for ; Thu, 30 Nov 2017 04:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.533 X-Spam-Level: X-Spam-Status: No, score=-3.533 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, 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 Xsj3rlmh60np for ; Thu, 30 Nov 2017 04:51:45 -0800 (PST) Received: from r-mail2.rd.orange.com (r-mail2.rd.orange.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id C4E33126DFE for ; Thu, 30 Nov 2017 04:51:45 -0800 (PST) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 56D415D8B6C; Thu, 30 Nov 2017 13:51:44 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail2.rd.orange.com (Postfix) with ESMTP id 3E8335D8B58; Thu, 30 Nov 2017 13:51:44 +0100 (CET) Received: from [10.193.71.63] (10.193.71.63) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.361.1; Thu, 30 Nov 2017 13:51:43 +0100 To: RFC Errata System , , , CC: , , , References: <20171130121516.0F02BB80ED9@rfc-editor.org> From: Julien Meuric Organization: Orange Message-ID: Date: Thu, 30 Nov 2017 13:51:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171130121516.0F02BB80ED9@rfc-editor.org> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Pce] [Technical Errata Reported] RFC4674 (5192) 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, 30 Nov 2017 12:51:48 -0000 Hi, It looks like the errata form has become a playground. ADs, please feel free to reject. Thanks, Julien Nov. 30, 2017 - rfc-editor@rfc-editor.org: > The following errata report has been submitted for RFC4674, > "Requirements for Path Computation Element (PCE) Discovery". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5192 > > -------------------------------------- > Type: Technical > Reported by: Amitkumar > > Section: 463846379684 > > Original Text > ------------- > Ok > > Corrected Text > -------------- > Ok > > Notes > ----- > > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4674 (draft-ietf-pce-discovery-reqs-05) > -------------------------------------- > Title : Requirements for Path Computation Element (PCE) Discovery > Publication Date : October 2006 > Author(s) : J.L. Le Roux, Ed. > Category : INFORMATIONAL > Source : Path Computation Element > Area : Routing > Stream : IETF > Verifying Party : IESG > From nobody Thu Nov 30 16:41: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 7B4FE124D68 for ; Thu, 30 Nov 2017 16:41:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ooOFx1WwocD for ; Thu, 30 Nov 2017 16:41:54 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60E391201FA for ; Thu, 30 Nov 2017 16:41:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id E0A6932468; Thu, 30 Nov 2017 16:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qEEne9HSbht; Thu, 30 Nov 2017 16:41:36 -0800 (PST) Received: from [10.0.1.12] (cpe-76-168-191-223.socal.res.rr.com [76.168.191.223]) by c8a.amsl.com (Postfix) with ESMTPA id 7F7C41CAC34; Thu, 30 Nov 2017 16:41:36 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Megan Ferguson In-Reply-To: Date: Thu, 30 Nov 2017 16:41:54 -0800 Cc: RFC System , Alia Atlas , "BRUNGARD, DEBORAH A" , aretana.ietf@gmail.com, jeanlouis.leroux@orange.com, jonathan.hardwick@metaswitch.com, pce@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <591BA6FB-0D1C-48D5-B5D2-6037C8F8FD65@amsl.com> References: <20171130121516.0F02BB80ED9@rfc-editor.org> To: Julien Meuric X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [Pce] [Technical Errata Reported] RFC4674 (5192) 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, 01 Dec 2017 00:41:55 -0000 Greetings, FYI - This report has been deleted. Thank you. RFC Editor/mf On Nov 30, 2017, at 4:51 AM, Julien Meuric = wrote: > Hi, >=20 > It looks like the errata form has become a playground. ADs, please = feel > free to reject. >=20 > Thanks, >=20 > Julien >=20 >=20 > Nov. 30, 2017 - rfc-editor@rfc-editor.org: >> The following errata report has been submitted for RFC4674, >> "Requirements for Path Computation Element (PCE) Discovery". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata/eid5192 >>=20 >> -------------------------------------- >> Type: Technical >> Reported by: Amitkumar >>=20 >> Section: 463846379684 >>=20 >> Original Text >> ------------- >> Ok >>=20 >> Corrected Text >> -------------- >> Ok >>=20 >> Notes >> ----- >>=20 >>=20 >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party =20 >> can log in to change the status and edit the report, if necessary.=20 >>=20 >> -------------------------------------- >> RFC4674 (draft-ietf-pce-discovery-reqs-05) >> -------------------------------------- >> Title : Requirements for Path Computation Element (PCE) = Discovery >> Publication Date : October 2006 >> Author(s) : J.L. Le Roux, Ed. >> Category : INFORMATIONAL >> Source : Path Computation Element >> Area : Routing >> Stream : IETF >> Verifying Party : IESG >>=20 >=20 From nobody Thu Nov 30 18:36:19 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 B7CEE1273B1 for ; Thu, 30 Nov 2017 18:36:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 9w5z_gE8Ya_v for ; Thu, 30 Nov 2017 18:36:15 -0800 (PST) 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 558E8126B72 for ; Thu, 30 Nov 2017 18:36:15 -0800 (PST) Received: from [192.168.1.10] (unknown [119.94.172.11]) (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 C488C18008CB; Fri, 1 Dec 2017 03:36:11 +0100 (CET) To: Megan Ferguson , Julien Meuric Cc: aretana.ietf@gmail.com, pce@ietf.org, RFC System References: <20171130121516.0F02BB80ED9@rfc-editor.org> <591BA6FB-0D1C-48D5-B5D2-6037C8F8FD65@amsl.com> From: Loa Andersson Message-ID: Date: Fri, 1 Dec 2017 10:36:07 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <591BA6FB-0D1C-48D5-B5D2-6037C8F8FD65@amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Pce] [Technical Errata Reported] RFC4674 (5192) 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, 01 Dec 2017 02:36:18 -0000 Folks, First, I support the action to remove this. Second, what are the procedures to remove an incoming mail to an IETF mailing list, we been there before and it has not been this easy. Alvaro, Can you check on this? /Loa On 2017-12-01 08:41, Megan Ferguson wrote: > Greetings, > > FYI - This report has been deleted. > > Thank you. > > RFC Editor/mf > > On Nov 30, 2017, at 4:51 AM, Julien Meuric wrote: > >> Hi, >> >> It looks like the errata form has become a playground. ADs, please feel >> free to reject. >> >> Thanks, >> >> Julien >> >> >> Nov. 30, 2017 - rfc-editor@rfc-editor.org: >>> The following errata report has been submitted for RFC4674, >>> "Requirements for Path Computation Element (PCE) Discovery". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata/eid5192 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Amitkumar >>> >>> Section: 463846379684 >>> >>> Original Text >>> ------------- >>> Ok >>> >>> Corrected Text >>> -------------- >>> Ok >>> >>> Notes >>> ----- >>> >>> >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party >>> can log in to change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC4674 (draft-ietf-pce-discovery-reqs-05) >>> -------------------------------------- >>> Title : Requirements for Path Computation Element (PCE) Discovery >>> Publication Date : October 2006 >>> Author(s) : J.L. Le Roux, Ed. >>> Category : INFORMATIONAL >>> Source : Path Computation Element >>> Area : Routing >>> Stream : IETF >>> Verifying Party : IESG >>> >> > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > -- Loa Andersson email: loa@pi.nu Senior MPLS Expert Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Nov 30 18:49:02 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 CA8C6127868 for ; Thu, 30 Nov 2017 18:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 3O7JR9RzK8RQ for ; Thu, 30 Nov 2017 18:48:58 -0800 (PST) Received: from mail-ot0-x244.google.com (mail-ot0-x244.google.com [IPv6:2607:f8b0:4003:c0f::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 BF647127698 for ; Thu, 30 Nov 2017 18:48:55 -0800 (PST) Received: by mail-ot0-x244.google.com with SMTP id y10so7921045otg.10 for ; Thu, 30 Nov 2017 18:48:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=DBalUnAWGto6XdYw2udJA3kQO63kqV8aWtsZutyPrSw=; b=i5T82BzhUCE3hEUVulHBV+QyRAFZWMw6JNJkDinw78C1MY8EkI7by+EbceK4USfOr+ dGziz8iHArwv4wCByG4i1r/Pt8qPZAxfQRP3ITcXRfDPBsIgK7UEulMcU1e7bd/oc2HQ 6G6ZJuWDC1nTfscyEsBEHQK1B8SdY4Qjyv3ByCaGunFEEnKX5/lX3ne0RuPWzIvvVeIa XUrZoqJEi6hQ5SKin9gEGkAXiZa9ElZNYYCMG8NcRqANQS8ZKmLVu4haS1xKVq2rlHXi nAiBCtN8B5d4LeGkTw8LVFxk3Afcz20wjMetaHkr869SEwBJIdnPkgmTmYuXyV6YZ3L5 5bUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=DBalUnAWGto6XdYw2udJA3kQO63kqV8aWtsZutyPrSw=; b=bhGC9dBxtex8cBMnfRbs7XCarfhSoPLUXpwA2hG6sUTMmveXiCck4SqOrYHiKPuzG4 ESzSo0AX3oMd6xkizB1ln1TspM01EYJ3hWkbg3Vmug8aJSj2Rwe9nigC1kdRDbfKVDYq ywTXa/5hTM1R1FHj5HVy7qeceQfOXRCMEDLk+gBXQUr7YDjfzKpGyoGR7+esBjrPdcCT Gh0unC2veRsJrqM3lHTW1qEiMNqrz1QeXct38E+zmtSoLw9CLexvU7fzrEdjN9hJdpY0 PoGfQGKONuiGeZIyFn8Q1CPsrJgU28vCDPR+r8Xix85dcUa/SW06EY8dbzGJSvjcTYJB fZ1g== X-Gm-Message-State: AJaThX6Sc69i4v0/VsDC2LGkYt2QEzhb5LsnWm59cGaaap0HDhucooqI lUK4OH0xRcBy+qTHI7wtWNze77uu3vxJu/tUP/c= X-Google-Smtp-Source: AGs4zMZbqQkhnZgsw1TTWSfDxq8lMmV7bVQ8ljiJU72skmbv9zilHPmQdgrow7nZbNghP7hAAq9DRHfOFZaQgbzuaNw= X-Received: by 10.157.53.16 with SMTP id o16mr7044774otc.307.1512096535152; Thu, 30 Nov 2017 18:48:55 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 30 Nov 2017 18:48:54 -0800 From: Alvaro Retana In-Reply-To: References: <20171130121516.0F02BB80ED9@rfc-editor.org> <591BA6FB-0D1C-48D5-B5D2-6037C8F8FD65@amsl.com> X-Mailer: Airmail (461) MIME-Version: 1.0 Date: Thu, 30 Nov 2017 18:48:54 -0800 Message-ID: To: Julien Meuric , Loa Andersson , Megan Ferguson Cc: pce@ietf.org, RFC System Content-Type: multipart/alternative; boundary="001a113dff2cd80e28055f3e68b1" Archived-At: Subject: Re: [Pce] [Technical Errata Reported] RFC4674 (5192) 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, 01 Dec 2017 02:49:00 -0000 --001a113dff2cd80e28055f3e68b1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Loa: Hi! What do you mean =E2=80=9Cremove an incoming mail=E2=80=9D? If you=E2=80=99re asking about avoiding this type of report, the message ge= ts generated by the RFC Editor=E2=80=99s system, so they would have to look at= some type of access control there. I=E2=80=99m not sure how access to the syste= m is controlled. If you=E2=80=99re asking about preventing someone from posting directly to = the list (pce, for example), then the list administrator can do that (block, permit, etc.). Alvaro. On November 30, 2017 at 9:36:14 PM, Loa Andersson (loa@pi.nu) wrote: Second, what are the procedures to remove an incoming mail to an IETF mailing list, we been there before and it has not been this easy. Alvaro, Can you check on this? --001a113dff2cd80e28055f3e68b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Loa:

Hi!

What do you mean =E2=80=9Crem= ove an incoming mail=E2=80=9D?

If you=E2=80=99re asking about avoiding this type of rep= ort, the message gets generated by the RFC Editor=E2=80=99s system, so they= would have to look at some type of access control there.=C2=A0 I=E2=80=99m= not sure how access to the system is controlled.

If you=E2=80=99re asking about preven= ting someone from posting directly to the list (pce, for example), then the= list administrator can do that (block, permit, etc.).

Alvaro.

= On November 30, 2017 at 9:36:14 PM, Loa Andersson (loa@pi.nu) wrote:

Second, what are = the procedures to remove an incoming mail to an IETF=C2=A0
mailing l= ist, we been there before and it has not been this easy.=C2=A0

Alvaro,=C2=A0

Can you check on this?=C2=A0
--001a113dff2cd80e28055f3e68b1-- From nobody Thu Nov 30 21:22: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 A8B92127978; Thu, 30 Nov 2017 21:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gSH3ylvtZdz; Thu, 30 Nov 2017 21:22:37 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E5B8127909; Thu, 30 Nov 2017 21:22:35 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 6840CB8127C; Thu, 30 Nov 2017 21:22:22 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, pce@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20171201052222.6840CB8127C@rfc-editor.org> Date: Thu, 30 Nov 2017 21:22:22 -0800 (PST) Archived-At: Subject: [Pce] =?utf-8?q?RFC_8306_on_Extensions_to_the_Path_Computation_El?= =?utf-8?q?ement_Communication_Protocol_=28PCEP=29_for_Point-to-Multipoint?= =?utf-8?q?_Traffic_Engineering_Label_Switched_Paths?= 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, 01 Dec 2017 05:22:39 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8306 Title: Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths Author: Q. Zhao, D. Dhody, Ed., R. Palleti, D. King Status: Standards Track Stream: IETF Date: November 2017 Mailbox: quintin.zhao@huawei.com, dhruv.ietf@gmail.com, ramanjaneya.palleti@huawei.com, daniel@olddog.co.uk Pages: 43 Characters: 81269 Obsoletes: RFC 6006 I-D Tag: draft-ietf-pce-rfc6006bis-04.txt URL: https://www.rfc-editor.org/info/rfc8306 DOI: 10.17487/RFC8306 Point-to-point Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first need to be determined. 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 describes extensions to the PCE Communication Protocol (PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs. This document obsoletes RFC 6006. This document is a product of the Path Computation Element Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC